Date: Mon, 20 Jan 2003 14:53:47 -0500 (EST) From: Kenneth Culver <culverk@yumyumyum.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Nate Lawson <nate@root.org>, Trish Lynch <trish@bsdunix.net>, <freebsd-current@FreeBSD.ORG> Subject: Re: FreeBSD panic with umass Message-ID: <20030120145222.E14910-100000@alpha.yumyumyum.org> In-Reply-To: <200301201931.h0KJVvWM070129@apollo.backplane.com>
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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030120145222.E14910-100000>