Quoth Hiroki Sato on Friday, 19 August 2011: > Chip Camden <sterl...@camdensoftware.com> wrote > in <20110818025550.ga1...@libertas.local.camdensoftware.com>: > > st> Quoth Attilio Rao on Thursday, 18 August 2011: > st> > In callout_cpu_switch() if a low priority thread is migrating the > st> > callout and gets preempted after the outcoming cpu queue lock is left > st> > (and scheduled much later) we get this problem. > st> > > st> > In order to fix this bug it could be enough to use a critical section, > st> > but I think this should be really interrupt safe, thus I'd wrap them > st> > up with spinlock_enter()/spinlock_exit(). Fortunately > st> > callout_cpu_switch() should be called rarely and also we already do > st> > expensive locking operations in callout, thus we should not have > st> > problem performance-wise. > st> > > st> > Can the guys I also CC'ed here try the following patch, with all the > st> > initial kernel options that were leading you to the deadlock? (thus > st> > revert any debugging patch/option you added for the moment): > st> > http://www.freebsd.org/~attilio/callout-fixup.diff > st> > > st> > Please note that this patch is for STABLE_8, if you can confirm the > st> > good result I'll commit to -CURRENT and then backmarge as soon as > st> > possible. > st> > > st> > Thanks, > st> > Attilio > st> > > st> > st> Thanks, Attilio. I've applied the patch and removed the extra debug > st> options I had added (though keeping debug symbols). I'll let you know if > st> I experience any more panics. > > No panic for 20 hours at this moment, FYI. For my NFS server, I > think another 24 hours would be sufficient to confirm the stability. > I will see how it works... > > -- Hiroki
Likewise: $ uptime 5:37PM up 21:45, 5 users, load averages: 0.68, 0.45, 0.63 So far, so good (knocks on head). -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com
pgpkzPv5qfAnG.pgp
Description: PGP signature
