On Sun, Oct 16, 2016 at 12:45:36AM -0700, Philip Guenther wrote: > On Sun, 16 Oct 2016, Matthieu Herrb wrote: > > my Sabre Lite board paniced during the night for the 1st time in several > > month. Here is the information I collected: > > > > kernel diagnostic assertion "p->p_wchan == NULL" failed: file > > "/usr/src/sys/ker > > n/kern_sched.c", line 333 > > This means a thread was somehow in the CPU's run-queue...but had a wait > channel as if it was waiting to be woken. > > ... > > ddb> ps > > TID PPID PGRP UID S FLAGS WAIT COMMAND > ... > > 86009 0 0 0 2 0x40014200 miiaut idle0 > > Bingo: S=2 --> SRUN! Or in this case, WTF!? idle threads must *NEVER* > have a wait channel. That smells like someone called tsleep() from an > interrupt and arm doesn't have the low-level machinery to detect and panic > at the call. > > mii_phy_auto() is the source of the "miiaut" wait channel; are the mii > flags not set right that it's taking the tsleep() path instead of > timeout_* path?
Looks like. I don't see a reason why anything using interrupts should set that flag. So fec/sxie seem to get this wrong. arch/armv7/imx/if_fec.c: mii->mii_flags = MIIF_AUTOTSLEEP; arch/armv7/sunxi/sxie.c: mii->mii_flags = MIIF_AUTOTSLEEP; dev/usb/if_aue.c: mii->mii_flags = MIIF_AUTOTSLEEP; dev/usb/if_axe.c: mii->mii_flags = MIIF_AUTOTSLEEP; dev/usb/if_mos.c: mii->mii_flags = MIIF_AUTOTSLEEP; dev/usb/if_udav.c: mii->mii_flags = MIIF_AUTOTSLEEP; dev/usb/if_url.c: mii->mii_flags = MIIF_AUTOTSLEEP; dev/usb/if_smsc.c: mii->mii_flags = MIIF_AUTOTSLEEP; dev/usb/if_axen.c: mii->mii_flags = MIIF_AUTOTSLEEP; dev/usb/if_ure.c: mii->mii_flags = MIIF_AUTOTSLEEP;
