Date: Thu, 07 Feb 2002 16:46:17 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Eugene M. Kim" <gene@nttmcl.com> Cc: 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: <3C631FD9.AABA00B4@mindspring.com> References: <200202072046.g17KkSM05459@lurza.secnetix.de> <20020207125449.A9620@alicia.nttmcl.com> <3C63133A.CF411A74@mindspring.com> <20020207160256.A19270@alicia.nttmcl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Eugene M. Kim" wrote: > The USB development team seems to have something similar to your idea in > their mind; see the comment for rev 1.47 of: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/umass.c?f=u&only_with_tag=MAIN&logsort=date > > It mentions about `da(4) becoming more intelligent about this.' See my other posting. It's definitely a CAM thing, not a USB thing, and the handling should be automatic, with no quirks table at all. The USB code, though, then has a responsibility to retry more times, so that the failure triggers the workaround, and the with the workaround in place, the operation then succeeds transparently. I don't think this is universal, though, since I can't see this approach working for a CD burner failure which might render something unrecoverable, but I have yet to see a place it would fail. I think the person with the problem needs to turn on the CAM debugging, or a CAM-head needs to become involved. The workaround works, for now, but it's frustrating, knowing that the next time anyone OEMs the same hardware and changes the ID, it will have to grow another quirk. 8-(. -- 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?3C631FD9.AABA00B4>