From owner-freebsd-current Mon Jan 20 11:32: 2 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 7227A37B401 for ; Mon, 20 Jan 2003 11:32:00 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E116643E4A for ; Mon, 20 Jan 2003 11:31:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0KJVv0i070130; Mon, 20 Jan 2003 11:31:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0KJVvWM070129; Mon, 20 Jan 2003 11:31:57 -0800 (PST) Date: Mon, 20 Jan 2003 11:31:57 -0800 (PST) From: Matthew Dillon Message-Id: <200301201931.h0KJVvWM070129@apollo.backplane.com> To: Nate Lawson Cc: Kenneth Culver , Trish Lynch , freebsd-current@FreeBSD.ORG Subject: Re: FreeBSD panic with umass References: 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 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