From owner-cvs-all Sat Dec 21 17:20:44 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB70637B401 for ; Sat, 21 Dec 2002 17:20:40 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 813A543EE8 for ; Sat, 21 Dec 2002 17:20:39 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 67587 invoked by uid 1000); 22 Dec 2002 01:20:40 -0000 Date: Sat, 21 Dec 2002 17:20:40 -0800 (PST) From: Nate Lawson To: Matt Dillon Cc: cvs-all@freebsd.org, cvs-committers@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb umass.c In-Reply-To: <20021220185703.6D4F137B431@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 20 Dec 2002, Matt Dillon wrote: > Modified files: > sys/dev/usb umass.c > Log: > Modify the fake cylinders calculation so it is >= the size of the device, > not < the size of the device. This avoids geom complaints. See previous email -- I think this change is wrong and the problem lies elsewhere. > Fix a serious bug in the handling of the RS_NO_CLEAR_UA quirk. When we > go and insert the test-unit-ready command the umass_cam_quirk_cb() function > sets the status as if the READ_CAPACITY command suceeded when, in fact, it > did not. This leads to the CAM layer trying to use garbage in the return > buffer and panicing the system (or doing other bad things). This change looks correct. > Add a quirk entry for MSYSTEMS DISK-ON-KEY, which is sold under the Sony > brand as a solid state disk-on-key usb device. This device requires > several quirks to work properly. This appears correct. > Note that the disk-on-key device will not work properly until CAM also > gets a quirk entry for it, which has been submitted to the CAM maintainer, I have replied to your pr, kern/46386 > and you may have to temporarily uncomment the DELAY() as well. -current > does not properly wait for devices to power up so you may also have > to temporarily uncomment the DELAY(300000) to make your device work. > A solution must be found to that issue. I'd like to hear more about this one and see what it is in umass that is possibly rescanning too fast. Maybe there should be a SLOWPROBE quirk there for this. Is the device in spec? -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message