On Fri, 12 Mar 2004, Matthias Andree wrote:
> (I've subscribed to the list now, no need to Cc: me on list replies.)
>
> On Thu, 11 Mar 2004, Alan Stern wrote:
>
> > From looking at your logs, I get the feeling that the initial problem
> > doesn't lies in the UHCI driver.
>
> OK, we'll take other components (drivers) into account as well.
>
> > The log shows the scanner failing to
> > accept some commands; in fact it looks like the scanner never received the
> > commands at all, or the computer never received its reply. That could be
> > the result of bad hardware or a bad cable, or maybe a bug in the scanner.
> > It is puzzling, though, because the commands needed to enumerate the
> > scanner when the USB drivers first detected it must have worked correctly.
> > Maybe the scanner isn't replying because it doesn't recognize the request?
>
> Let's summarize the tests:
>
> GOOD FreeBSD 5.2-CURRENT with xsane
> GOOD Linux 2.4.26-pre2 with vuescan
> GOOD Linux 2.4.26-pre2 with iscan
> GOOD Linux 2.6.4 with vuescan
> NO-GO Linux 2.6.4 with iscan (xsane works sometimes)
>
> Something is different between 2.4.X and 2.6.X. Something in the iscan
> (which is provided by Epson) code seems to trigger the problem quick.
> (iscan also implements an "epkowa" driver in SANE).
Also something is different between vuescan and iscan. I have no idea
what it might be, though.
> > All in all, I think the userspace program may be the biggest problem.
> > Did you say that the same program works okay on the same hardware when
> > running under Linux 2.4? What does the dmesg log for 2.4 say? I would
> > expect it to contain the same sequence of errors.
>
> Last few lines of logging before starting application (if this isn't
> sufficient, ask for more, I have USB verbose debug on and it ios just
> spamming the log at boot-up) on 2.4.26-pre2:
>
> Mar 12 00:36:18 merlin kernel: hub.c: port 2, portstatus 101, change 3, 12 Mb/s
> Mar 12 00:36:18 merlin kernel: hub.c: port 2, portstatus 101, change 2, 12 Mb/s
> Mar 12 00:36:18 merlin last message repeated 3 times
> Mar 12 00:36:18 merlin kernel: hub.c: port 2, portstatus 103, change 0, 12 Mb/s
> Mar 12 00:36:18 merlin kernel: hub.c: new USB device 00:10.1-2, assigned address 2
> Mar 12 00:36:18 merlin kernel: usb.c: kmalloc IF cc1f7640, numif 1
> Mar 12 00:36:18 merlin kernel: usb.c: new device strings: Mfr=1, Product=2,
> SerialNumber=0
> Mar 12 00:36:18 merlin kernel: usb.c: USB device number 2 default language ID 0x409
> Mar 12 00:36:18 merlin kernel: Manufacturer: EPSON
> Mar 12 00:36:18 merlin kernel: Product: EPSON Scanner
> Mar 12 00:36:18 merlin kernel: usb.c: unhandled interfaces on device
>
> And running the user-space software causes just resmgr logging and this
> line (multiple times):
>
> Mar 12 00:43:06 merlin kernel: usb.c: usbdevfs driver claimed interface cc1f7640
>
> No errors visible in the application or in the syslog. It "just works".
>
> Is the stuff that used to be handled by usbdevfs in 2.4 handled by the
> usbcore driver in 2.6?
That doesn't have a yes/no answer. usbdevfs is now (in 2.6) called usbfs
and it still handles the same functions as it used to. But it is part of
usbcore.
You know, it's entirely possible that usbfs is the problem source. It's
not working quite right at the moment, and the person who has spent the
most time on fixing it is very busy with other things now.
> Might there be timing differences between 2.4 and 2.6 that confuse the
> scanner?
I doubt it.
> Is there an easy way to sniff USB traffic, an analogon to tcpdump might
> be helpful to see if there are differences in traffic?
It would be nice if there were, but no one has written such a thing. I
could put together something quick that would work for 2.6. However,
you'd need to do it under both 2.4 and 2.6 to look for differences.
> I straced the processes for fun, here's the tail of the log - the last
> line is incomplete here, it's not a cut&paste problem.
>
> 8096 gettimeofday({1079045368, 79020}, NULL) = 0
> 8096 ioctl(3, FIONREAD, [0]) = 0
> 8096 poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}], 2, 0) = 0
> 8096 ioctl(11, USBDEVFS_BULK, 0xbfffe1e4) = 6
> 8096 ioctl(11, USBDEVFS_BULK, 0xbfffe220) = 4096
> 8096 ioctl(11, USBDEVFS_BULK, 0xbfffe220) = 4096
> 8096 ioctl(11, USBDEVFS_BULK, 0xbfffe220) = 4096
> 8096 ioctl(11, USBDEVFS_BULK, 0xbfffe220) = 4096
> 8096 ioctl(11, USBDEVFS_BULK, 0xbfffe220) = 4096
> 8096 ioctl(11, USBDEVFS_BULK
Doesn't say too much beyond the fact that the program is working... What
happens if you do the same thing for the program that hangs? Or better
yet, can you post both the strace output and the dmesg output for the same
run?
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
