Kai Gallasch wrote: > Am Fri, 12 Mar 2010 20:38:31 +0200 > schrieb Alexander Motin <m...@freebsd.org>: >> Pawel Jakub Dawidek wrote: >>> I was analizing similar problem as potential ZFS bug. It turned out >>> to be bug in ciss(4) and I believe mav@ (CCed) has fix for that. >> That my patch is already at 8-STABLE since r204873 of 2010-03-08. Make >> sure you have it. > > Updating collection src-all/cvs > .. > .. > Edit src/sys/dev/ciss/ciss.c > Edit src/sys/dev/ciss/cissvar.h > > Didn't have it! Must have been just a few hours I missed it, > when I built the last kernel. So I will rebuild my kernel and > give it a spin later on. > >> In this case trap stopped process at ciss_get_request(), which indeed >> called holding cissmtx lock. But there is no place to sleep or loop >> there, so may be it was just spontaneous. With bugs I was fixing there >> was a chance to loop indefinitely between ciss and CAM on resource >> constraint. That increases chance for such situation to be caught. >> >> You may try also look what's going on with `top -HS` and `systat -vm >> 1`. > > FYI. Without your patch of ciss.c and cissvar.h a lockup with top -HS > and systat -vm running gives following information below. Is there a > pattern visible relating to your patch of the ciss driver?
May be. You should try, -- Alexander Motin _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
