On Tue, Jul 7, 2009 at 4:18 AM, Attilio Rao<[email protected]> wrote: > 2009/7/7 Dan Naumov <[email protected]>: >> I just got a panic following by a reboot a few seconds after running >> "portsnap update", /var/log/messages shows the following: >> >> Jul 7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel >> Jul 7 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock >> 1) held by 0xffffff00017d8370 (tid 100054) too long >> Jul 7 03:49:38 atom kernel: panic: spin lock held too long > > That's a known bug, affecting -CURRENT as well. > The cpustop IPI is handled though an NMI, which means it could > interrupt a CPU in any moment, even while holding a spinlock, > violating one well known FreeBSD rule. > That means that the cpu can stop itself while the thread was holding > the sched lock spinlock and not releasing it (there is no way, modulo > highly hackish, to fix that). > In the while hardclock() wants to schedule something else to run and > got stuck on the thread lock. > > Ideal fix would involve not using a NMI for serving the cpustop while > having a cheap way (not making the common path too hard) to tell > hardclock() to avoid scheduling while cpustop is in flight. > > Thanks, > Attilio
Any idea if a fix is being worked on and how unlucky must one be to run into this issue, should I expect it to happen again? Is it basically completely random? - Sincerely, Dan Naumov _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
