From owner-freebsd-current Thu Dec 19 9:13:45 2002 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 6A65137B401; Thu, 19 Dec 2002 09:13:44 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B2F643ED8; Thu, 19 Dec 2002 09:13:44 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id gBJHDdOM041184; Thu, 19 Dec 2002 09:13:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id gBJHDdtt041183; Thu, 19 Dec 2002 09:13:39 -0800 (PST) (envelope-from dillon) Date: Thu, 19 Dec 2002 09:13:39 -0800 (PST) From: Matthew Dillon Message-Id: <200212191713.gBJHDdtt041183@apollo.backplane.com> To: Bernd Walter Cc: "Brian F. Feldman" , Josef Karthauser , freebsd-current@FreeBSD.ORG Subject: Re: UMASS USB bug? (getting the Sony disk-on-key device working). References: <200212191032.gBJAWNj0039522@apollo.backplane.com> <20021219131211.GA29286@cicely8.cicely.de> 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 : :> Note that my other UMASS device, a compact flash reader, has always :> worked fine with just the Quirk entry. I really need a USB expert to :> tell me what is going on :-) : :The problem is that an umass bulk only umass device is allowed to stall the :comunication pipe on an invalid command. :I got the impression that the umass driver doesn't clear the pipe on :errors. : :-- :B.Walter COSMO-Project http://www.cosmo-project.de In my traces I did occassionally see a command wind up in a STALLED state, but most of the time it either wound up in a BABBLE state or in a NAK state and hit the 5 second timeout. Since I removed the conditional (the #if 0 in the patch I posted earlier), I have not seen either state. These problems always occured while the CAM layer was probing the device (e.g. doing a READ CAPACITY, telling the lower layer to not allow user removal (as if that helps)). Once the CAM layer was actually able to get past that state the actual READs and WRITEs worked fine with just the Quirk entry, before my #if 0 patch. Prior to the patch it took a lot of random pulling of the device, putting it back in, pulling it again, putting it back in, camcontrol reset 1, camcontrol rescan 1, that sort of thing, before I would either get the device to work or the system would panic :-). After the patch everything works fine (though I'm sure pulling the device without unmounting it first will still lead to problems similar to those describde by Frode). p.s. the patch was against -stable. -current was crashing on me too much while playing with the disk key, but I'm sure it applies to -current too. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message