Re: 2.5.69+bk: oops in apmd after waking up from suspend mode

[email protected], Wed, May 14, 2003 16:03:55 +0200:
> > > Since 2.5.69-bk8 or so, apm.c will invoke restore_processor_state()
> > > at resume-time. This is needed to reinitialise the SYSENTER MSRs
> > > used by 2.5's new system call mechanism.
> > 
> > and it supposed to go oops?
> 
> Of course not. It doesn't oops my Dell Latitude: on that laptop it
> prevents oopses since otherwise user-space processes will oops the kernel
> as soon as they make a system call or return from a system call. But this
> only happens if both the CPU and glibc are capable of using SYSENTER.
> 

I'm not sure if my glibc uses sysenter. But I'd like to have the system
prepared if I eventually get one which does.

>  > >  >  <6>note: kapmd[4] exited with preempt_count 2
>  > > This I don't like. I'm not convinced the resume path is preempt-safe.
>  > > Please try again, either with CONFIG_PREEMPT disabled, or with a
>  > > preempt_disable() / preempt_enable() pair around apm.c's suspend code,
>  > > like in the patch below. (Untested, you may need to stick an #include
>  > > <preempt.h> somewhere in apm.c to make it compile.)
>  > 
>  > It changed things a bit. preempt_count is 3 now.
>  > Oops didn't change.
> 
> Ok so it wasn't preempt.
> Can you identify in which statement the oops occurs?

not really. Somewhere fix_processor_context+0x5f/0x100, that's where EIP
points. But latest bk doesn't have this anymore, so I think I'll try it
first.

> And can you confirm that commenting out the calls in apm.c to
> save_processor_state() and restore_processor_state() eliminates the oops?

after I have tried it.