From owner-freebsd-current Mon Jan 20 11:54:43 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42E8B37B401 for ; Mon, 20 Jan 2003 11:54:41 -0800 (PST) Received: from alpha.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id CACC843F13 for ; Mon, 20 Jan 2003 11:54:39 -0800 (PST) (envelope-from culverk@yumyumyum.org) Received: from alpha.yumyumyum.org (localhost [127.0.0.1]) by alpha.yumyumyum.org (8.12.6/8.12.6) with ESMTP id h0KJrlXM015838; Mon, 20 Jan 2003 14:53:47 -0500 (EST) (envelope-from culverk@yumyumyum.org) Received: from localhost (culverk@localhost) by alpha.yumyumyum.org (8.12.6/8.12.6/Submit) with ESMTP id h0KJrlsQ015835; Mon, 20 Jan 2003 14:53:47 -0500 (EST) (envelope-from culverk@yumyumyum.org) X-Authentication-Warning: alpha.yumyumyum.org: culverk owned process doing -bs Date: Mon, 20 Jan 2003 14:53:47 -0500 (EST) From: Kenneth Culver To: Matthew Dillon Cc: Nate Lawson , Trish Lynch , Subject: Re: FreeBSD panic with umass In-Reply-To: <200301201931.h0KJVvWM070129@apollo.backplane.com> Message-ID: <20030120145222.E14910-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD,AWL version=2.31 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > :Backtrace would be useful since you shouldn't be getting a panic. At the > :worst, your usb reader just wouldn't work. > : > :-Nate > > At worse the system will crash. The problem is that USB devices > sometimes return total garbage for the READ CAPACITY command. This > isn't CAM's fault, it is a major issue with the way the USB code works > as well as a major issue with the way certain USB devices respond > to commands (or request lengths) that they do not understand. Sometimes > the USB layer does not get an error or returns the wrong sense code. > The USB code can also somtimes get out of sync with the device between > commands, causing all sorts of havoc. > > When I was tracking down the Sony DiskKey problem I hit this problem. > The Sony often returned complete garbage for READ CAPACITY until I put > the proper quirk entries in. Since the CAM/SCSI layer does not bzero() > the scsi_read_capacity_data structure, the result was random capacities > and system crashes (e.g. when a certain value would wind up 0 the CAM > layer would crash with a divide by 0). > > I added some debugging to try to catch the problem and it still happens > to be in my tree so I can give you guys the diff. This is *NOT* for > commit. It's just junk debugging code. Note that I added the M_ZERO > option to the malloc. > > -Matt Hmm, good stuff, but shouldn't something be committed anyway? I mean if it causes a panic just by plugging in the device that's totally unacceptable. I'll provide a backtrace of the crash on my computer tomorrow I suppose (I won't be home until then) and let people know if that's what's causing my crash. Ken > > Index: scsi_da.c > =================================================================== > RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v > retrieving revision 1.42.2.30 > diff -u -r1.42.2.30 scsi_da.c > --- scsi_da.c 20 Dec 2002 15:20:25 -0000 1.42.2.30 > +++ scsi_da.c 30 Dec 2002 23:22:22 -0000 > @@ -546,8 +556,10 @@ > > rcap = (struct scsi_read_capacity_data *)malloc(sizeof(*rcap), > M_TEMP, > - M_WAITOK); > - > + M_WAITOK|M_ZERO); > + scsi_ulto4b(3133333, (void *)&rcap->length); > + scsi_ulto4b(512, (void *)&rcap->addr); > + > ccb = cam_periph_getccb(periph, /*priority*/1); > scsi_read_capacity(&ccb->csio, > /*retries*/1, > @@ -1187,6 +1199,7 @@ > softc->minimum_cmd_size = 10; > else > softc->minimum_cmd_size = 6; > + printf("QUIRKS %04x MCS %d MATCH %p\n", softc->quirks, softc->minimum_cmd_size, match); > > /* > * Block our timeout handler while we > @@ -1748,6 +1761,8 @@ > dp = &softc->params; > dp->secsize = scsi_4btoul(rdcap->length); > dp->sectors = scsi_4btoul(rdcap->addr) + 1; > + printf("RDCAP SECSIZE %d\n", (int)dp->secsize); > + printf("RDCAP SECTORS %d\n", (int)dp->sectors); > /* > * Have the controller provide us with a geometry > * for this disk. The only time the geometry > @@ -1767,6 +1782,7 @@ > dp->heads = ccg.heads; > dp->secs_per_track = ccg.secs_per_track; > dp->cylinders = ccg.cylinders; > + printf("RDCAP HEADS %d SPT %d CYL %d\n", (int)ccg.heads, (int)ccg.secs_per_track, (int)ccg.cylinders); > } > > static void > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message