Re: sysctl -a causes kernel trap 12

d wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 1/7/13 5:33 PM, Brandon Gooch wrote:
> > On Mon, Jan 7, 2013 at 6:09 PM, Xin Li <delphij_at_delphij.net
> > <mailto: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
> > <mailto: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...
> 
> Yes my nVidia driver is compiled with clang. I'll try gcc tomorrow,
> thanks for the pointer.
> 
> (Note that the panic was a NULL pointer deference and it's a race
> condition so I doubt if it's compiler related but will try).
> 
I saw this crash once, on an i386 (No X windows setup) with just
the GENERIC kernel config + "options DEBIG_VFS_LOCKS" built with gcc,
so I don't think it would be caused by the NVIDIA driver.

Just one more data point, rick

> Cheers,
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBCAAGBQJQ64cNAAoJEG80Jeu8UPuzkLwIAKgjgbcBaow64mWzrJ0XtczM
> 6Xi4mC0Oq5kdomx0y+Vgks/qTvq28Ff/JqyxN8osD959Vwaq0vbQumFiDtbWCr0h
> /MD0w5m7Asdbf8KzJE80il90Vv1/nJrOVdwj3qoNIqtKIomi12CHDKL5zFs2Ja2i
> rscN22SBh8+3vV1rBSE6NGzJ7jPSs/B0o73YuIdwj6bUYMiBqHWWGGTfFStNhc4U
> 1JX6WWsDdiWxNvGPH5lE3HelSgya+WCltD+B6/8mYaByBQbXD+JBOA9AvX97h2kk
> muQROSMOz6OVdGmtM6U/19Bsiv/8kUtItJF2k19Y/eTQEohH/2xBhq+37EG8cqg=
> =b9UF
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"