Date: Wed, 6 Aug 2014 22:26:23 -0400 From: Mark Saad <nonesuch@longcount.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org>, "<wollman@bimajority.org>" <wollman@bimajority.org> Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers Message-ID: <45558B49-C3DD-4FD0-8E04-38BC30A1AC35@longcount.org> In-Reply-To: <FE12D1B47D154D7FB165B1531CB9635A@multiplay.co.uk> References: <21474.34330.572142.206098@hergotha.csail.mit.edu> <4DE72E01E8A64E98A31920FCFCAA5D26@multiplay.co.uk> <201408062110.s76LAhhE079487@hergotha.csail.mit.edu> <FE12D1B47D154D7FB165B1531CB9635A@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Aug 6, 2014, at 5:33 PM, "Steven Hartland" <killing@multiplay.co.uk> wr= ote: >=20 > TBH that sounds like dodgy hardware. We had a similar thing a few years > back with a machine which would panic mfi badly all the time where as > other machines where solid as a rock. >=20 Why details can you provide about the hardware ? Could you upload a dmesg.bo= ot to=20 www.nycbug.org/index.cgi?action=3Ddmesgd&do=3Dhome > If its random then you could be facing the same thing. >=20 > I our case it turned out to be a faulty Intel CPU. There where on other > signs of issues just random panic in mfi. >=20 > So given the similarity and you said it only effects one out of two machin= es > have the HW replaced and see if the problem goes away. >=20 > Regards > Stev >=20 > ----- Original Message ----- From: <wollman@bimajority.org> > To: <killing@multiplay.co.uk> > Cc: <freebsd-stable@freebsd.org>; <freebsd-scsi@freebsd.org> > Sent: Wednesday, August 06, 2014 10:10 PM > Subject: Re: 9.3-RELEASE still instapanics on multi-mps(4) servers >=20 >=20 >> 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 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Mark saad | mark.saad@longcount.org=20=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45558B49-C3DD-4FD0-8E04-38BC30A1AC35>