From owner-freebsd-hardware  Thu Feb  7 16:48:45 2002
Delivered-To: freebsd-hardware@freebsd.org
Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12])
	by hub.freebsd.org (Postfix) with ESMTP
	id 24EFF37B41E; Thu,  7 Feb 2002 16:48:36 -0800 (PST)
Received: from pool0339.cvx22-bradley.dialup.earthlink.net ([209.179.199.84] helo=mindspring.com)
	by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 16YzDE-0006Ng-00; Thu, 07 Feb 2002 16:48:26 -0800
Message-ID: <3C631FD9.AABA00B4@mindspring.com>
Date: Thu, 07 Feb 2002 16:46:17 -0800
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
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
References: <200202072046.g17KkSM05459@lurza.secnetix.de> <20020207125449.A9620@alicia.nttmcl.com> <3C63133A.CF411A74@mindspring.com> <20020207160256.A19270@alicia.nttmcl.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hardware@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hardware.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-hardware>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-hardware>
X-Loop: FreeBSD.org

"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