Date: Fri, 19 Aug 2011 09:28:11 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: attilio@FreeBSD.org Cc: freebsd-stable@FreeBSD.org, sterling@camdensoftware.com, avg@FreeBSD.org, Nick Esborn <nick@desert.net>, kostikbel@gmail.com, mdtansca@FreeBSD.org Subject: Re: panic: spin lock held too long (RELENG_8 from today) Message-ID: <20110819.092811.1087267565626420460.hrs@allbsd.org> In-Reply-To: <20110818025550.GA1971@libertas.local.camdensoftware.com> References: <20110818.091600.831954331552558249.hrs@allbsd.org> <CAJ-FndCL70m41dQ9FPmzUg0V8a9JacvLOnjmMQL=3PfN7NmPfQ@mail.gmail.com> <20110818025550.GA1971@libertas.local.camdensoftware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Fri_Aug_19_09_28_11_2011_956)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chip Camden <sterling@camdensoftware.com> wrote in <20110818025550.GA1971@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 ----Security_Multipart(Fri_Aug_19_09_28_11_2011_956)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5NrhsACgkQTyzT2CeTzy1O/ACeJPyJpjyI8X68PscHDXRU7iXu 8M0An23TY3RL9ZPaL1R+FCLHmhe9Mqi7 =FHX7 -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Aug_19_09_28_11_2011_956)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110819.092811.1087267565626420460.hrs>