On 01/20/15 11:47, Slawa Olhovchenkov wrote:
On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote:
On 01/17/15 23:18, Hans Petter Selasky wrote:
On 01/17/15 20:11, Jason Wolfe wrote:
HPS,
Just to give a quick status update, this patch has most certainly
resolved our spin lock held too long panics on stable/10.
Thank you to JHB for spending some time digging into the issue and
leading us to td_slpcallout as the culprit, and HPS for your rewrite.
I had heard rumors of other being affected by similar issues, so this
seems like a fine candidate for an MFC if possible.
Jason
Hi Jason,
I'm glad to hear that my patch has resolved your issue and I'm happy we
now have a more stable system.
It was actually a co-worker at work which wrote some bad code which I
started debugging which then lead me to look at the callout subsystem.
One bug kills the other ;-)
I'm planning a MFC to 10-stable - yes, and will possibly add the
_callout_stop_safe() function to not break binary compatibility with
existing drivers as part of the MFC.
--HPS
Hi,
Here is a followup patch for the TCP stack like I mentioned in the
beginning of the work done on the callout subsystem:
https://reviews.freebsd.org/D1563
If someone has a setup for massive TCP testing please give it a spin.
I have on 10.1 (with applied r261906).
FYI:
r277213 is going to be pulled out from -current in at maximum a few
hours from now, because developers need more time to review patches in
surrounding areas like the TCP stack area to restore distribution of
callouts on multiple CPUs when using MPSAFE callouts to avoid congestion
in the TCP stack.
--HPS
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
