From owner-freebsd-current Sun Mar 26 1:26:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 0A41A37B891; Sun, 26 Mar 2000 01:26:37 -0800 (PST) (envelope-from ticso@cicely9.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.9.3/8.9.3) with ESMTP id LAA26230; Sun, 26 Mar 2000 11:25:15 +0200 (MET DST) Received: from cicely9.cicely.de (cicely9.cicely.de [10.1.7.11]) by mail.cicely.de (8.9.3/8.9.0) with ESMTP id LAA39290; Sun, 26 Mar 2000 11:26:13 +0200 (CEST) Received: (from ticso@localhost) by cicely9.cicely.de (8.10.0.Beta12/8.10.0.Beta12) id e2Q9QDl01534; Sun, 26 Mar 2000 11:26:13 +0200 (CEST) Date: Sun, 26 Mar 2000 11:26:12 +0200 From: Bernd Walter To: Alfred Perlstein Cc: current@FreeBSD.ORG, phk@FreeBSD.ORG, grog@FreeBSD.ORG Subject: Re: vinum possible casulty of B_* patches? Message-ID: <20000326112612.A1462@cicely9.cicely.de> References: <20000326011506.R21029@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" X-Mailer: Mutt 1.0i In-Reply-To: <20000326011506.R21029@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Mar 26, 2000 at 01:15:07AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii On Sun, Mar 26, 2000 at 01:15:07AM -0800, Alfred Perlstein wrote: > I'm about to wander down vinum's source again. > > With a kernel and vinum module dated approx Tue Feb 29 06:53:56 > PST 2000 everything works fine. > > I recently (tonight) I cvsup'd to 5.0 to play with Matt's SMP stuff > and came across a problem where it seems that 5.0 doesn't get any > IO down to my vinum striped disks. > > I'll get panics, but then rebooting both my old and new kernels+modules > the vinum volume is "clean" which leads me to belive that somewhere > writes just aren't making it through to my disks. > > If I do a reboot I'll loose something like thousands of buffers > but yet my vinum drive is "marked clean" on boot without the need > for fsck. > > Anyhow, I just wanted to let you guys know what's going on hopefully > you'll have a solution faster than I will. I already fixed that and send it to Greg -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff Index: vinuminterrupt.c =================================================================== RCS file: /vol/cvs/src/sys/dev/vinum/vinuminterrupt.c,v retrieving revision 1.27 diff -u -u -r1.27 vinuminterrupt.c --- vinuminterrupt.c 2000/03/20 11:28:32 1.27 +++ vinuminterrupt.c 2000/03/25 19:14:25 @@ -342,7 +342,8 @@ if ((rqe->b.b_iocmd == BIO_READ) /* this was a read */ &&((rqe->flags & XFR_BAD_SUBDISK) == 0)) { /* and we can write this block */ - rqe->b.b_flags &= ~B_DONE; /* we're writing now */ + rqe->b.b_flags &= ~B_DONE; /* we're not done */ + rqe->b.b_iocmd = BIO_WRITE; /* we're writing now */ rqe->b.b_iodone = complete_rqe; /* call us here when done */ rqe->flags &= ~XFR_PARITYOP; /* reset flags that brought us here */ rqe->b.b_data = &bp->b_data[rqe->useroffset << DEV_BSHIFT]; /* point to the user data */ @@ -381,7 +382,8 @@ } /* Finally, write the parity block */ rqe = &rqg->rqe[0]; - rqe->b.b_flags &= ~B_DONE; /* we're writing now */ + rqe->b.b_flags &= ~B_DONE; /* we're not done */ + rqe->b.b_iocmd = BIO_WRITE; /* writing now */ rqe->b.b_iodone = complete_rqe; /* call us here when done */ rqg->flags &= ~XFR_PARITYOP; /* reset flags that brought us here */ rqe->b.b_bcount = rqe->buflen << DEV_BSHIFT; /* length to write */ Index: vinumraid5.c =================================================================== RCS file: /vol/cvs/src/sys/dev/vinum/vinumraid5.c,v retrieving revision 1.7 diff -u -u -r1.7 vinumraid5.c --- vinumraid5.c 2000/03/20 10:44:13 1.7 +++ vinumraid5.c 2000/03/25 20:40:59 @@ -493,7 +493,7 @@ rqe->driveno = sd->driveno; if (build_rq_buffer(rqe, plex)) /* build the buffer */ return REQUEST_ENOMEM; /* can't do it */ - rqe->b.b_iocmd == BIO_READ; /* we must read first */ + rqe->b.b_iocmd = BIO_READ; /* we must read first */ m.sdcount++; /* adjust the subdisk count */ rqno++; /* and point to the next request */ } Index: vinumrequest.c =================================================================== RCS file: /vol/cvs/src/sys/dev/vinum/vinumrequest.c,v retrieving revision 1.46 diff -u -u -r1.46 vinumrequest.c --- vinumrequest.c 2000/03/20 11:28:34 1.46 +++ vinumrequest.c 2000/03/25 23:54:29 @@ -792,11 +792,11 @@ /* Initialize the buf struct */ /* copy these flags from user bp */ bp->b_flags = ubp->b_flags & (B_ORDERED | B_NOCACHE | B_ASYNC); - bp->b_iocmd = BIO_READ; /* inform us when it's done */ + bp->b_iocmd = ubp->b_iocmd; BUF_LOCKINIT(bp); /* get a lock for the buffer */ BUF_LOCK(bp, LK_EXCLUSIVE); /* and lock it */ - bp->b_iodone = complete_rqe; /* by calling us here */ + bp->b_iodone = complete_rqe; /* calling us here when done */ /* * You'd think that we wouldn't need to even * build the request buffer for a dead subdisk, @@ -921,6 +921,7 @@ } bzero(sbp, sizeof(struct sdbuf)); /* start with nothing */ sbp->b.b_flags = bp->b_flags; + sbp->b.b_iocmd = bp->b_iocmd; sbp->b.b_bufsize = bp->b_bufsize; /* buffer size */ sbp->b.b_bcount = bp->b_bcount; /* number of bytes to transfer */ sbp->b.b_resid = bp->b_resid; /* and amount waiting */ Index: vinumrevive.c =================================================================== RCS file: /vol/cvs/src/sys/dev/vinum/vinumrevive.c,v retrieving revision 1.23 diff -u -u -r1.23 vinumrevive.c --- vinumrevive.c 2000/03/20 10:44:14 1.23 +++ vinumrevive.c 2000/03/25 17:33:57 @@ -213,7 +213,7 @@ "Relaunch revive conflict sd %d: %p\n%s dev %d.%d, offset 0x%x, length %ld\n", rq->sdno, rq, - rq->bp->b_flags == BIO_READ ? "Read" : "Write", + rq->bp->b_iocmd == BIO_READ ? "Read" : "Write", major(rq->bp->b_dev), minor(rq->bp->b_dev), rq->bp->b_blkno, --FL5UXtIhxfXey3p5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message