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

Alex Riesen
2003-05-14T14:00:17Z

mikpe@csd.uu.se, 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.