Re: kern/38273 panic: LOCKDEBUG, "lockdebug_barrier: spin lock held", from ld_ataraid_start_raid0()

["Greg A. Woods" <woods%planix.com@localhost>]

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 Romero Pardines <xtraeme%gmail.com@localhost>
Subject: Re: kern/38273 panic: LOCKDEBUG, "lockdebug_barrier: spin lock held", 
from ld_ataraid_start_raid0()
Date: Wed, 17 Sep 2008 15:59:14 -0400

 --pgp-sign-Multipart_Wed_Sep_17_15:59:14_2008-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 At Wed, 17 Sep 2008 19:25:02 +0000 (UTC), Juan Romero Pardines wrote:
 Subject: Re: kern/38273 panic: LOCKDEBUG, "lockdebug_barrier: spin lock hel=
 d", from ld_ataraid_start_raid0()
 >=20
 >  Do you have any local changes in ld.c? I'd like to know why the mutex ha=
 sn't
 >  been acquired in ldstart().
 =20
 Indeed I do.  I have the following changes, the meat of which were
 suggested on August 25 by Juergen Hannken-Illjes in response to this PR,
 but in private mail.
 
 As I recall they changed the behaviour from a panic to then just causing
 the newfs process to hang, so they sort of improved things, but not really.
 
 I'll try reverting them now and see what happens, but to my naive eyes
 they do look logical and proper.
 
 
 Index: sys/dev/ld.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvs/master/m-NetBSD/main/src/sys/dev/ld.c,v
 retrieving revision 1.63
 diff -u -r1.63 ld.c
 --- sys/dev/ld.c       9 Sep 2008 12:45:39 -0000       1.63
 +++ sys/dev/ld.c       10 Sep 2008 19:00:20 -0000
 @@ -106,6 +106,10 @@
                return;
        }
 =20
 +#ifdef DIAGNOSTIC
 +      aprint_normal_dev(sc->sc_dv, "ldattach(): unit %d\n", 
device_unit(sc->sc_=
 dv));
 +#endif
 +
        /* Initialise and attach the disk structure. */
        disk_init(&sc->sc_dk, device_xname(sc->sc_dv), &lddkdriver);
        disk_attach(&sc->sc_dk);
 @@ -650,19 +654,16 @@
 =20
        while (sc->sc_queuecnt < sc->sc_maxqueuecnt) {
                /* See if there is work to do. */
 -              if ((bp =3D BUFQ_PEEK(sc->sc_bufq)) =3D=3D NULL)
 +              if ((bp =3D BUFQ_GET(sc->sc_bufq)) =3D=3D NULL)
                        break;
 =20
                disk_busy(&sc->sc_dk);
                sc->sc_queuecnt++;
 =20
 -              if (__predict_true((error =3D (*sc->sc_start)(sc, bp)) =3D=3D 
0)) {
 -                      /*
 -                       * The back-end is running the job; remove it from
 -                       * the queue.
 -                       */
 -                      (void) BUFQ_GET(sc->sc_bufq);
 -              } else  {
 +              mutex_exit(&sc->sc_mutex);
 +              error =3D (*sc->sc_start)(sc, bp);
 +              mutex_enter(&sc->sc_mutex);
 +              if (__predict_false(error !=3D 0)) {
                        disk_unbusy(&sc->sc_dk, 0, (bp->b_flags & B_READ));
                        sc->sc_queuecnt--;
                        if (error =3D=3D EAGAIN) {
 @@ -674,9 +675,9 @@
                                 * XXX We might consider a watchdog timer
                                 * XXX to make sure we are kicked into action.
                                 */
 +                              BUFQ_PUT(sc->sc_bufq, bp);
                                break;
                        } else {
 -                              (void) BUFQ_GET(sc->sc_bufq);
                                bp->b_error =3D error;
                                bp->b_resid =3D bp->b_bcount;
                                mutex_exit(&sc->sc_mutex);
 @@ -918,5 +919,6 @@
  ld_config_interrupts (struct device *d)
  {
        struct ld_softc *sc =3D device_private(d);
 +
        dkwedge_discover(&sc->sc_dk);
  }
 
 
 --=20
                                                Greg A. Woods
                                                Planix, Inc.
 
 <woods%planix.com@localhost>     +1 416 489-5852 x122     
http://www.planix.com/
 
 --pgp-sign-Multipart_Wed_Sep_17_15:59:14_2008-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNATURE-----
 Version: PGPfreeware 5.0i for non-commercial use
 MessageID: 1c0CBXcRxn01uJjHfGHshesz4zeQ7Le+
 
 iQA/AwUBSNFhkmZ9cbd4v/R/EQKbyQCglIeoBb8hVhZENclWvxLZK/rZQO4AnRlz
 slWd7z7OI7HdS8LIEbH/t5Mn
 =tBwh
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Wed_Sep_17_15:59:14_2008-1--