Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Jan 2003 05:50:03 -0800 (PST)
From:      Henning Meier-Geinitz <henning@meier-geinitz.de>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/41281: USB scanning works only once
Message-ID:  <200301151350.h0FDo3DR046163@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/41281; it has been noted by GNATS.

From: Henning Meier-Geinitz <henning@meier-geinitz.de>
To: Nate Lawson <nate@root.org>
Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@freebsd.org
Subject: Re: kern/41281: USB scanning works only once
Date: Wed, 15 Jan 2003 14:50:01 +0100

 Hi,
 
 On Sun, Aug 25, 2002 at 12:48:29PM +0200, Henning Meier-Geinitz wrote:
 [Bug report about some Mustek USB scanners only working once in FreeBSD]
 
 After some more investigation and discussion with the Linux kernel USB
 people it seems to be clear now, that it's a hardware issue.
 
 The Mustek USB scanners that are based on the MA1017 chip (ScanExpress
 1200 CU, 1200 CU Plus, 600 CU, 1200 UB), don't reset the data toggle.
 Never (but replugging/power-cycling). That means, whenever according
 to the USB spec the toggle is set to DATA0 (clear_halt,
 set_configuration, ...), it's only done on the host and the scanner
 doesn't do it. The result is that there is a 50% chance of lost
 packets.
 
 It doesn't happen with the Linux kernel scanner driver because that
 driver doesn't call any of the functions that reset the toggle during
 open/close. However, when reloading the scanner module the timeout
 problems also occurs.
 
 The only workaround seems to be don't do any togggle resetting after
 the first read/write access. I guess it's not worth the trouble if
 these scanners are the only device that exhibit this bug.
 
 Bye,
   Henning

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301151350.h0FDo3DR046163>