Johannes Erdfelt wrote: > On Tue, May 07, 2002, Peter Denison <[EMAIL PROTECTED]> wrote: > > Turning my HP PSC750 printer/scanner off and on again during a session, > > results in the following trace - pay particular attention to the 5th line. > > This is true for at least 2.5.14 and 2.5.11, and probably 2.5.10 and > > 2.5.8. All USB drivers loaded as modules, using the uhci.o driver variant > > (have to otherwise the PSC750 doesn't work) > > You mean usb-uhci.o doesn't work at all with the device?
Yes, there appears to be a problem with some people, where usb-uhci doesn't work but uhci does, with no apparent correspondence with a particular kernel version. When I say "doesn't work", here's what I mean. ptal-mlcd (the user-mode IEEE 1284.4 driver that's part of the HP OfficeJet Linux driver project, http://hpoj.sf.net) opens up /dev/usb/lpX, reads the printer's device ID string, writes an 8-byte 1284.4 Init packet, and sits around waiting to receive a 9-byte 1284.4 InitReply packet (actually in two separate chunks: 6-byte header and 3-bytes of data). In some cases, the InitReply packet is never received when using usb-uhci, and ptal-mlcd times out after 15 seconds. However, in the vast majority of these cases, one can switch to uhci, reboot or power-cycle the computer (this step is necessary), and it starts working (except for an unpatched 2.4.18 kernel). Unfortunately, I am unable to personally reproduce this problem on any of my equipment; this workaround was discovered and suggested by other people. Both usb-uhci and uhci work fine on the one laptop I have that has UHCI. Actually, I have a PC with integrated UHCI, which as I recall worked OK most of the time, but occasionally lost data when scanning on a LaserJet 3200. I never tried switching to uhci, but instead assumed that the HC was bad (due to the many bus errors that a CATC USB Chief analyzer reported) and installed an OHCI PCI card, which made the problem go away. In addition, there have been a small number of people who have reported similar problems with usb-ohci, and in a few other cases with usb-ohci, ptal-mlcd actually blocks indefinitely while writing data to the printer device. Of course, switching to a UHCI driver doesn't help here. :-) One thing I should point out, and this may or may not make a difference, is that ptal-mlcd mostly revolves around select()ing for read() on the /dev/usb/lpX file descriptor. However, with all of these models, an IN request on the bulk-IN endpoint always returns a packet containing zero bytes of data, rather than NAKing and causing the host controller to retry. Is it possible that getting lots of empty packets could overwhelm the Linux USB subsystem, or more specifically, the usb-uhci HCD? If you need any more information, just ask. I've been meaning to bring this up here but was going to try a few more things first, but since Peter made you ask, I thought I should go ahead and tell you what I know. :-) David _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
