Date: Sat, 1 Apr 2000 09:51:02 +0200 (CEST) From: Soren Schmidt <sos@freebsd.dk> To: grog@lemis.com (Greg Lehey) Cc: vallo@matti.ee, freebsd-current@FreeBSD.ORG Subject: Re: Deadlock with vinum raid5 Message-ID: <200004010751.JAA48796@freebsd.dk> In-Reply-To: <20000401091140.A51727@freebie.lemis.com> from Greg Lehey at "Apr 1, 2000 09:11:40 am"
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Greg Lehey wrote: > > The problem that Søren and I are looking at is usually a panic. We > don't really know where it's happening, but we're each sure it's not > in *our* code :-) From a Vinum standpoint, it happens between the time > that Vinum sends a request to the driver and when the I/O completes, > so it's difficult to blame Vinum. On the other hand, we've seen it > with SCSI as well, so it's difficult to blame the driver. I'm half > guessing that it's something else altogether which is spamming freed > data. Vinum mallocs the buffer headers rather than using geteblk(), > which could explain why it happens only with Vinum. It happens also with the wd driver, so its 3 drivers against one :) What seems to be happening is that *something* is corrupting the buf structure, or the pointer to it. What I see in most cases is that the buf structure I get in adstrategy has gotten some of its fields changed when I get to work on it in ad_start. That should _not_ be happening, and doesn't when vinum is not involved. Somehow I think that vinums shuffleing around with buf's and copies of them at some point gets confused. I'm still instrumenting my kernel to locate where it happens, and I havn't got anything definite yet... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004010751.JAA48796>