Date: Wed, 6 Aug 2014 17:10:43 -0400 (EDT) From: wollman@bimajority.org To: killing@multiplay.co.uk Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers Message-ID: <201408062110.s76LAhhE079487@hergotha.csail.mit.edu> References: <21474.34330.572142.206098@hergotha.csail.mit.edu> <4DE72E01E8A64E98A31920FCFCAA5D26@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <4DE72E01E8A64E98A31920FCFCAA5D26@multiplay.co.uk>, killing@multiplay.co.uk writes: >The stack from the panic would be a good start. As I said, it's in the middle of the USB code, which does not appear, from my previous bisection, to be connected with the bug at all. (The panic is the result of an unhandled trap that happens during interrupt-driven probing, and it's nearly always in the USB code. By loading different modules I can make it happen at slightly different times and places.) Six months ago, I found that enabling any form of memory debugging suppresses the symptoms, although it also kills performance, of course. I haven't tried that yet this time around. Once I get a serial console hooked up I'll be in a better position to capture the full data (although obviously not a core dump). -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408062110.s76LAhhE079487>