[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/38273 panic: LOCKDEBUG, "lockdebug_barrier: spin lock held", from ld_ataraid_start_raid0()
The following reply was made to PR kern/38273; it has been noted by GNATS.
From: "Greg A. Woods" <woods%planix.com@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: Juan RP <xtraeme%gmail.com@localhost>
Subject: Re: kern/38273 panic: LOCKDEBUG, "lockdebug_barrier: spin lock held",
Date: Fri, 19 Sep 2008 16:20:17 -0400
Content-Type: text/plain; charset=US-ASCII
At Thu, 18 Sep 2008 20:10:05 +0000 (UTC), Juan RP wrote:
Subject: Re: kern/38273 panic: LOCKDEBUG, "lockdebug_barrier: spin lock hel=
d", from ld_ataraid_start_raid0()
> I'm out of ideas then. No idea how we will fix this if we are calling
> buf_init() with the ld's spin lock held!
> Or ldstart() is wrong and it should not acquire the spin lock there
> (AFAIK is the correct way) or the only option is to release/reacquire
> the spin lock as I had done in the patch.
> Also as the spin lock is held, acquiring the adaptive mutex from v_inter=
> will also cause another "spin lock held" panic later on (which I address=
> with the softint(9)).
Perhaps we should post some further details about these issues on
I'm certainly not knowledgeable enough about the twisty new maze of
locking necessary for disk drivers, especially not middle-layer drivers
like this one, to be of much help sorting this out. (I would like to
learn, but I'd like to do it from a detailed design document but I don't
think one currently exists.)
Perhaps someone else cognizant of all the issues could lend a hand.
Greg A. Woods
<woods%planix.com@localhost> +1 416 489-5852 x122
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
-----END PGP SIGNATURE-----
Main Index |
Thread Index |