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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:52 EST