fa.netbsd.bugs
[Top] [All Lists]

Re: kern/38273 panic: LOCKDEBUG, "lockdebug_barrier: spin lock held", fr

Subject: Re: kern/38273 panic: LOCKDEBUG, "lockdebug_barrier: spin lock held", from ld_ataraid_start_raid0()
From: Juan RP
Date: Wed, 10 Sep 2008 16:15:12 UTC
Newsgroups: fa.netbsd.bugs

The following reply was made to PR kern/38273; it has been noted by GNATS.

From: Juan RP <xtraeme@xxxxxxxxx>
To: gnats-bugs@xxxxxxxxxx
Cc: 
Subject: Re: kern/38273 panic: LOCKDEBUG,
 "lockdebug_barrier: spin lock held", from ld_ataraid_start_raid0()
Date: Wed, 10 Sep 2008 18:11:03 +0200

 Hi,
 
 I don't know exactly if the mutex needs to run at IPL_VM exactly,
 but changing it to IPL_NONE seems to do the right thing at least
 on ataraid(4).
 
 Someone with more knowledge should verify that this change is
 correct, but I'm using it as workaround for now... and I was able
 to copy/remove a few gigabytes with a DEBUG/DIAGNOSTIC/LOCKDEBUG
 kernel without any issue on an Intel MatrixRAID controller (RAID1).
 
 Index: ld.c
 ===================================================================
 RCS file: /cvsroot/src/sys/dev/ld.c,v
 retrieving revision 1.63
 diff -b -u -p -r1.63 ld.c
 --- ld.c        9 Sep 2008 12:45:39 -0000       1.63
 +++ ld.c        10 Sep 2008 16:06:25 -0000
 @@ -99,7 +99,7 @@ ldattach(struct ld_softc *sc)
  {
         char tbuf[9];
  
 -       mutex_init(&sc->sc_mutex, MUTEX_DEFAULT, IPL_VM);
 +       mutex_init(&sc->sc_mutex, MUTEX_DEFAULT, IPL_NONE);
  
         if ((sc->sc_flags & LDF_ENABLED) == 0) {
                 aprint_normal_dev(sc->sc_dv, "disabled\n");
 

<Prev in Thread] Current Thread [Next in Thread>