Date: Fri, 08 Feb 2002 10:04:55 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Oliver Fromme <oliver.fromme@secnetix.de> Cc: "Eugene M. Kim" <gene@nttmcl.com>, Oliver Fromme <olli@secnetix.de>, FreeBSD Hardware Mailing List <hardware@freebsd.org>, FreeBSD Hackers Mailing List <hackers@freebsd.org> Subject: Re: USB "Memorybird" quirks Message-ID: <3C641347.ADE06FAD@mindspring.com> References: <200202081724.g18HOlZ40937@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver Fromme wrote: > > Could this be "auto-quirked"? [ ... ] > It seems to me that umass_scsi_transform() in umass.c is > the place intended for this kind of things. After the > first failure (which is detected in umass_bbb_state()), > a flag (quirk) should be set in the softc, and afterwards > umass_scsi_transform should translate 6-byte commands to > 10-byte commands. Doesn't sound too complicated to me. After looking at the code in more detail, then puzzling and puzzling 'til mu puzzler was sore, then sitting back down, and puzzling some more... It very obviously needs to be generic in the CAM layer in the da handler, since it's applicable to all devices in the quirks table, not just the USB devices. It still needs a failuter trace from the CAM_DEBUG stuff. Strange as it may seem, I look through quirks lists before I buy hardware, and if it has a quirk, I don't buy it. So I'm not in a position to run the test, or test a fix. The USB stuff still needs to retry more than it does, though, if those logs were an accurate retry count, or the fix of automatically moving from 6->10 byte commands won't work transparently, and you'll end up having to do the disklabel a couple of times before it sticks. This is pretty unacceptable behaviour (it violates POLA all to heck). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C641347.ADE06FAD>