Date: Mon, 20 Jan 2003 11:31:57 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Nate Lawson <nate@root.org> Cc: Kenneth Culver <culverk@yumyumyum.org>, Trish Lynch <trish@bsdunix.net>, freebsd-current@FreeBSD.ORG Subject: Re: FreeBSD panic with umass Message-ID: <200301201931.h0KJVvWM070129@apollo.backplane.com> References: <Pine.BSF.4.21.0301201115030.62414-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301201931.h0KJVvWM070129>