Re: sysctl -a causes kernel trap 12

On Mon, Jan 7, 2013 at 6:09 PM, Xin Li <delphij_at_delphij.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 01/07/13 16:02, Konstantin Belousov wrote:
> > On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>
> >> Hi,
> >>
> >> I've recently (by mid-December I think) noticed that sysctl -a
> >> can sometimes cause kernel trap 12.  Tried enabling INVARIANTS
> >> and the problem mysteriously disappeared.  After some experiments
> >> on this, it seems that this can be triggered by sysctl -a but the
> >> system have an 1 in 10 chance to survive.  When INVARIANTS is
> >> enabled however, I can not trigger the panic.  "sysctl hw"
> >> triggers the panic sometimes, but not always.
> >>
> >> Do anybody have clue on this?  The system hangs hard when it
> >> panics so kernel debugger won't work.  When it panics, the fault
> >> instruction pointer is always 0x20:0xffffffff808d61c9, which is
> >> sys/kern/subr_turnstile.c:297:
> >>
> >>> /* Resort td on the list if needed. */ if
> >>> (!turnstile_adjust_thread(ts, td)) {
> >>> mtx_unlock_spin(&ts->ts_lock); // 297 // return; }
> >>
> >> This sounds like a race condition but I haven't yet able to track
> >> it down...
> >
> > Could you try to isolate the sub-leaf under hw which causes the
> > panic ? Just shot in the dark, do you have Intel GPU gemified
> > driver loaded ?
>
> It seems that it was not hw itself that causes the problem (I thought
> about isolating to sub-leaf and at one point believed it was
> hw.acpi.battery but doing so repeatedly doesn't panic the system, with
> or without INVARIANTS; doing 'sysctl hw' sometimes causes panic but
> not always).
>
> The laptop is running nVidia but it's using i7-3610QM which does have
> Intel GPU, but I have not loaded drm2.ko and the panic is reproducible
> in single user mode.
>
> Cheers,
> - --
> Xin LI <delphij_at_delphij.net>    https://www.delphij.net/
> FreeBSD - The Power to Serve!           Live free or die
>

Xin, did you compile the NVIDIA driver port with clang? I was having this
issue until I set an exception for the NVIDIA driver port to be built with
GCC.

Actually, I just remembered (and checked), and what I'm actually doing is
setting CFLAGS for the NVIDIA driver port to -O0, and building with clang.
Clang optimizes out important bits, I didn't investigate deeply enough to
determine what was actually going awry...

-Brandon