Hi,
Short summary:
I have HP1018 printer, and it works well in windows.
When I use in in linux, I often see messages like:
usbfs: USBDEVFS_CONTROL failed cmd python rqt 128 rq 6 len 255 ret -110
This is using hp backend that talks to printer using usbfs.
I also tried usblp, but it just doesn't say anything in kernel log. I
think it silently ignores similar errors, because the end result is the
same, the printer sometimes works, but sometimes doesn't.
(printer needs firmware to be uploaded to it, and I do upload it).
On the other hand, IF I remove _ether_ ehci-hcd or uhci-hcd from kernel,
then everything works fine, I already rebooted the printer many times,
used it to print, upload firmware, and everything just work, but as soon
as I load the second driver it fails in same way again.
USB issues with this class of printers are nothing but new, for example
see:
http://foo2zjs.rkkda.com/forum/read.php?9,374
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/54419
I compiled without CONFIG_USB_EHCI_ROOT_HUB_TT
and it did help (didn't that much testing, but at least firmware loads
ok, and no error messages)
Looking for your comments,
Best regards,
Maxim Levitsky
On Sat, Mar 07, 2009 at 09:20:44PM +0200, Maxim Levitsky wrote:
> Hi,
>
> Short summary:
>
> I have HP1018 printer, and it works well in windows.
> When I use in in linux, I often see messages like:
>
> usbfs: USBDEVFS_CONTROL failed cmd python rqt 128 rq 6 len 255 ret -110
>
> This is using hp backend that talks to printer using usbfs.
> I also tried usblp, but it just doesn't say anything in kernel log. I
> think it silently ignores similar errors, because the end result is the
> same, the printer sometimes works, but sometimes doesn't.
> (printer needs firmware to be uploaded to it, and I do upload it).
>
> On the other hand, IF I remove _ether_ ehci-hcd or uhci-hcd from kernel,
> then everything works fine, I already rebooted the printer many times,
> used it to print, upload firmware, and everything just work, but as soon
> as I load the second driver it fails in same way again.
>
> USB issues with this class of printers are nothing but new, for example
> see:
>
> http://foo2zjs.rkkda.com/forum/read.php?9,374
> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/54419
What kernel version are you using?
> I compiled without CONFIG_USB_EHCI_ROOT_HUB_TT
> and it did help (didn't that much testing, but at least firmware loads
> ok, and no error messages)
Can you provide the full kernel log messages from when you plug in your
printer? Are there any other messages saying that you need to be sure
to load one driver before the other?
thanks,
greg k-h
On Sat, 2009-03-07 at 11:52 -0800, Greg KH wrote:
> On Sat, Mar 07, 2009 at 09:20:44PM +0200, Maxim Levitsky wrote:
> > Hi,
> >
> > Short summary:
> >
> > I have HP1018 printer, and it works well in windows.
> > When I use in in linux, I often see messages like:
> >
> > usbfs: USBDEVFS_CONTROL failed cmd python rqt 128 rq 6 len 255 ret -110
> >
> > This is using hp backend that talks to printer using usbfs.
> > I also tried usblp, but it just doesn't say anything in kernel log. I
> > think it silently ignores similar errors, because the end result is the
> > same, the printer sometimes works, but sometimes doesn't.
> > (printer needs firmware to be uploaded to it, and I do upload it).
> >
> > On the other hand, IF I remove _ether_ ehci-hcd or uhci-hcd from kernel,
> > then everything works fine, I already rebooted the printer many times,
> > used it to print, upload firmware, and everything just work, but as soon
> > as I load the second driver it fails in same way again.
> >
> > USB issues with this class of printers are nothing but new, for example
> > see:
> >
> > http://foo2zjs.rkkda.com/forum/read.php?9,374
> > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/54419
>
> What kernel version are you using?
>
> > I compiled without CONFIG_USB_EHCI_ROOT_HUB_TT
> > and it did help (didn't that much testing, but at least firmware loads
> > ok, and no error messages)
>
> Can you provide the full kernel log messages from when you plug in your
> printer? Are there any other messages saying that you need to be sure
> to load one driver before the other?
I am familiar with these messages, maybe instead uhci should depend on
ehci or something like that?
Tommorow I try to load them manually in correct order.
Btw, if I unload both and then load first ehci then uhci, this is ok
(if they were loaded incorrectly)
Confirm again that without CONFIG_USB_EHCI_ROOT_HUB_TT both drivers
work.
dmesg (from /var/log/kern.log.0) attached
It shows how I rebooted the printer often.
It also have this error message about the order.
But this isn't related.
I currently blacklisted uhci-hcd, so only ehci-hcd gets loaded.
Then I loaded the uhci, and got same bug
(This is why I attached an older dmesg, if you need I reproduce that bug
again)
To be clear, usually after these error messages (... -110), printer
stops working, it is so confused, all attempts to access it hang.
Only reboot helps.
>
> thanks,
>
> greg k-h
Of course, thanks for quick reply,
Best regards,
Maxim Levitsky
>
>
> >
> > thanks,
> >
> > greg k-h
On Sat, 2009-03-07 at 22:22 +0200, Maxim Levitsky wrote:
> On Sat, 2009-03-07 at 11:52 -0800, Greg KH wrote:
> > On Sat, Mar 07, 2009 at 09:20:44PM +0200, Maxim Levitsky wrote:
> > > Hi,
> > >
> > > Short summary:
> > >
> > > I have HP1018 printer, and it works well in windows.
> > > When I use in in linux, I often see messages like:
> > >
> > > usbfs: USBDEVFS_CONTROL failed cmd python rqt 128 rq 6 len 255 ret -110
> > >
> > > This is using hp backend that talks to printer using usbfs.
> > > I also tried usblp, but it just doesn't say anything in kernel log. I
> > > think it silently ignores similar errors, because the end result is the
> > > same, the printer sometimes works, but sometimes doesn't.
> > > (printer needs firmware to be uploaded to it, and I do upload it).
> > >
> > > On the other hand, IF I remove _ether_ ehci-hcd or uhci-hcd from kernel,
> > > then everything works fine, I already rebooted the printer many times,
> > > used it to print, upload firmware, and everything just work, but as soon
> > > as I load the second driver it fails in same way again.
> > >
> > > USB issues with this class of printers are nothing but new, for example
> > > see:
> > >
> > > http://foo2zjs.rkkda.com/forum/read.php?9,374
> > > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/54419
> >
> > What kernel version are you using?
> >
> > > I compiled without CONFIG_USB_EHCI_ROOT_HUB_TT
> > > and it did help (didn't that much testing, but at least firmware loads
> > > ok, and no error messages)
> >
> > Can you provide the full kernel log messages from when you plug in your
> > printer? Are there any other messages saying that you need to be sure
> > to load one driver before the other?
> I am familiar with these messages, maybe instead uhci should depend on
> ehci or something like that?
>
> Tommorow I try to load them manually in correct order.
> Btw, if I unload both and then load first ehci then uhci, this is ok
> (if they were loaded incorrectly)
>
>
> Confirm again that without CONFIG_USB_EHCI_ROOT_HUB_TT both drivers
> work.
>
> dmesg (from /var/log/kern.log.0) attached
> It shows how I rebooted the printer often.
> It also have this error message about the order.
>
> But this isn't related.
> I currently blacklisted uhci-hcd, so only ehci-hcd gets loaded.
> Then I loaded the uhci, and got same bug
> (This is why I attached an older dmesg, if you need I reproduce that bug
> again)
>
>
> To be clear, usually after these error messages (... -110), printer
> stops working, it is so confused, all attempts to access it hang.
> Only reboot helps.
And of course, forgot, kernel is vanilla 2.6.28
with compat-wireless patches.
Best regards,
Maxim Levitsky
On Sat, 7 Mar 2009, Maxim Levitsky wrote:
> On Sat, 2009-03-07 at 11:52 -0800, Greg KH wrote:
> > On Sat, Mar 07, 2009 at 09:20:44PM +0200, Maxim Levitsky wrote:
> > > Hi,
> > >
> > > Short summary:
> > >
> > > I have HP1018 printer, and it works well in windows.
> > > When I use in in linux, I often see messages like:
> > >
> > > usbfs: USBDEVFS_CONTROL failed cmd python rqt 128 rq 6 len 255 ret -110
> > >
> > > This is using hp backend that talks to printer using usbfs.
> > > I also tried usblp, but it just doesn't say anything in kernel log. I
> > > think it silently ignores similar errors, because the end result is the
> > > same, the printer sometimes works, but sometimes doesn't.
> > > (printer needs firmware to be uploaded to it, and I do upload it).
> > >
> > > On the other hand, IF I remove _ether_ ehci-hcd or uhci-hcd from kernel,
> > > then everything works fine, I already rebooted the printer many times,
> > > used it to print, upload firmware, and everything just work, but as soon
> > > as I load the second driver it fails in same way again.
> > >
> > > USB issues with this class of printers are nothing but new, for example
> > > see:
> > >
> > > http://foo2zjs.rkkda.com/forum/read.php?9,374
> > > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/54419
> >
> > What kernel version are you using?
> >
> > > I compiled without CONFIG_USB_EHCI_ROOT_HUB_TT
> > > and it did help (didn't that much testing, but at least firmware loads
> > > ok, and no error messages)
> >
> > Can you provide the full kernel log messages from when you plug in your
> > printer? Are there any other messages saying that you need to be sure
> > to load one driver before the other?
> I am familiar with these messages, maybe instead uhci should depend on
> ehci or something like that?
No, adding a dependency won't work because it is valid to load
uhci-hcd without ehci-hcd. The only time a problem occurs is if you
load both of them in the wrong order. (And in fact it's pretty rare
for that to cause a real problem -- mostly you just get some annoying
messages in the log.)
> Tommorow I try to load them manually in correct order.
> Btw, if I unload both and then load first ehci then uhci, this is ok
> (if they were loaded incorrectly)
>
>
> Confirm again that without CONFIG_USB_EHCI_ROOT_HUB_TT both drivers
> work.
>
> dmesg (from /var/log/kern.log.0) attached
> It shows how I rebooted the printer often.
> It also have this error message about the order.
>
> But this isn't related.
> I currently blacklisted uhci-hcd, so only ehci-hcd gets loaded.
> Then I loaded the uhci, and got same bug
> (This is why I attached an older dmesg, if you need I reproduce that bug
> again)
The dmesg you attached shows that you unloaded uhci-hcd but the printer
still failed to work. This contradicts your statement above that if
you remove either driver then everything works fine.
The information in the log isn't really enough to tell what's
happening. It would be better if you could provide a usbmon trace
showing the problem.
CONFIG_USB_EHCI_ROOT_HUB_TT shouldn't make any difference at all.
That setting matters only for hardware using the ARC/TDI design, which
is not present in your Intel chipset. Likewise, provided ehci-hcd is
loaded first, it shouldn't make any difference whether uhci-hcd is
loaded or not.
Alan Stern
On Sat, 2009-03-07 at 22:27 -0500, Alan Stern wrote:
> On Sat, 7 Mar 2009, Maxim Levitsky wrote:
>
> > On Sat, 2009-03-07 at 11:52 -0800, Greg KH wrote:
> > > On Sat, Mar 07, 2009 at 09:20:44PM +0200, Maxim Levitsky wrote:
> > > > Hi,
> > > >
> > > > Short summary:
> > > >
> > > > I have HP1018 printer, and it works well in windows.
> > > > When I use in in linux, I often see messages like:
> > > >
> > > > usbfs: USBDEVFS_CONTROL failed cmd python rqt 128 rq 6 len 255 ret -110
> > > >
> > > > This is using hp backend that talks to printer using usbfs.
> > > > I also tried usblp, but it just doesn't say anything in kernel log. I
> > > > think it silently ignores similar errors, because the end result is the
> > > > same, the printer sometimes works, but sometimes doesn't.
> > > > (printer needs firmware to be uploaded to it, and I do upload it).
> > > >
> > > > On the other hand, IF I remove _ether_ ehci-hcd or uhci-hcd from kernel,
> > > > then everything works fine, I already rebooted the printer many times,
> > > > used it to print, upload firmware, and everything just work, but as soon
> > > > as I load the second driver it fails in same way again.
> > > >
> > > > USB issues with this class of printers are nothing but new, for example
> > > > see:
> > > >
> > > > http://foo2zjs.rkkda.com/forum/read.php?9,374
> > > > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/54419
> > >
> > > What kernel version are you using?
> > >
> > > > I compiled without CONFIG_USB_EHCI_ROOT_HUB_TT
> > > > and it did help (didn't that much testing, but at least firmware loads
> > > > ok, and no error messages)
> > >
> > > Can you provide the full kernel log messages from when you plug in your
> > > printer? Are there any other messages saying that you need to be sure
> > > to load one driver before the other?
> > I am familiar with these messages, maybe instead uhci should depend on
> > ehci or something like that?
>
> No, adding a dependency won't work because it is valid to load
> uhci-hcd without ehci-hcd. The only time a problem occurs is if you
> load both of them in the wrong order. (And in fact it's pretty rare
> for that to cause a real problem -- mostly you just get some annoying
> messages in the log.)
But since it can cause a problem, this has to be somehow automatically
fixed isn't it?
For example how to I ensure the correct order with udev?
>
> > Tommorow I try to load them manually in correct order.
> > Btw, if I unload both and then load first ehci then uhci, this is ok
> > (if they were loaded incorrectly)
> >
> >
> > Confirm again that without CONFIG_USB_EHCI_ROOT_HUB_TT both drivers
> > work.
> >
> > dmesg (from /var/log/kern.log.0) attached
> > It shows how I rebooted the printer often.
> > It also have this error message about the order.
> >
> > But this isn't related.
> > I currently blacklisted uhci-hcd, so only ehci-hcd gets loaded.
> > Then I loaded the uhci, and got same bug
> > (This is why I attached an older dmesg, if you need I reproduce that bug
> > again)
>
> The dmesg you attached shows that you unloaded uhci-hcd but the printer
> still failed to work. This contradicts your statement above that if
> you remove either driver then everything works fine.
We both yes and no:
#define ETIMEDOUT 110
I forgot to tell you that without CONFIG_USB_EHCI_ROOT_HUB_TT or without
one of the drivers it is still possible to see that error, if I attempt
to query printer status while firmware is loading.
I think this is not a bug, and printer works after such message.
This is what you have seen in the logs, I tried to make the printer
crash, so I tried the above.
>
> The information in the log isn't really enough to tell what's
> happening. It would be better if you could provide a usbmon trace
> showing the problem.
>
> CONFIG_USB_EHCI_ROOT_HUB_TT shouldn't make any difference at all.
> That setting matters only for hardware using the ARC/TDI design, which
> is not present in your Intel chipset. Likewise, provided ehci-hcd is
> loaded first, it shouldn't make any difference whether uhci-hcd is
> loaded or not.
Well, I retest this.
But it seems to work
> Alan Stern
>
Best regards,
Maxim Levitsky
On Sun, 8 Mar 2009, Maxim Levitsky wrote:
> > No, adding a dependency won't work because it is valid to load
> > uhci-hcd without ehci-hcd. The only time a problem occurs is if you
> > load both of them in the wrong order. (And in fact it's pretty rare
> > for that to cause a real problem -- mostly you just get some annoying
> > messages in the log.)
> But since it can cause a problem, this has to be somehow automatically
> fixed isn't it?
Can it cause a problem? I'm not so sure -- it depends on what you mean
by "problem". One person complained forcefully just because he didn't
like all the extra "disconnect" messages in the system log, even though
everything worked perfectly.
> For example how to I ensure the correct order with udev?
You can't. But you can add rules to /etc/modprobe.conf to insure that
ehci-hcd is always loaded before uhci-hcd.
> > CONFIG_USB_EHCI_ROOT_HUB_TT shouldn't make any difference at all.
> > That setting matters only for hardware using the ARC/TDI design, which
> > is not present in your Intel chipset. Likewise, provided ehci-hcd is
> > loaded first, it shouldn't make any difference whether uhci-hcd is
> > loaded or not.
> Well, I retest this.
> But it seems to work
Best would be if you could send two usbmon traces, one showing the
problem and one showing what happens when uhci-hcd isn't loaded but
everything else is the same. For each test, plug in the printer's USB
cable after starting the trace.
And don't try to confuse matters by querying the printer status while
reloading its firmware.
Alan Stern
On Sun, 2009-03-08 at 12:58 -0400, Alan Stern wrote:
> On Sun, 8 Mar 2009, Maxim Levitsky wrote:
>
> > > No, adding a dependency won't work because it is valid to load
> > > uhci-hcd without ehci-hcd. The only time a problem occurs is if you
> > > load both of them in the wrong order. (And in fact it's pretty rare
> > > for that to cause a real problem -- mostly you just get some annoying
> > > messages in the log.)
> > But since it can cause a problem, this has to be somehow automatically
> > fixed isn't it?
>
> Can it cause a problem? I'm not so sure -- it depends on what you mean
> by "problem". One person complained forcefully just because he didn't
> like all the extra "disconnect" messages in the system log, even though
> everything worked perfectly.
>
> > For example how to I ensure the correct order with udev?
>
> You can't. But you can add rules to /etc/modprobe.conf to insure that
> ehci-hcd is always loaded before uhci-hcd.
>
> > > CONFIG_USB_EHCI_ROOT_HUB_TT shouldn't make any difference at all.
> > > That setting matters only for hardware using the ARC/TDI design, which
> > > is not present in your Intel chipset. Likewise, provided ehci-hcd is
> > > loaded first, it shouldn't make any difference whether uhci-hcd is
> > > loaded or not.
> > Well, I retest this.
> > But it seems to work
>
> Best would be if you could send two usbmon traces, one showing the
> problem and one showing what happens when uhci-hcd isn't loaded but
> everything else is the same. For each test, plug in the printer's USB
> cable after starting the trace.
Will do soon.
>
> And don't try to confuse matters by querying the printer status while
> reloading its firmware.
Well, I suspected that there is some concurrent access from both usb
drivers, so I tried all options to crash it....
> Alan Stern
>
On Mon, 2009-03-09 at 12:07 +0200, Maxim Levitsky wrote:
> On Sun, 2009-03-08 at 12:58 -0400, Alan Stern wrote:
> > On Sun, 8 Mar 2009, Maxim Levitsky wrote:
> >
> > > > No, adding a dependency won't work because it is valid to load
> > > > uhci-hcd without ehci-hcd. The only time a problem occurs is if you
> > > > load both of them in the wrong order. (And in fact it's pretty rare
> > > > for that to cause a real problem -- mostly you just get some annoying
> > > > messages in the log.)
> > > But since it can cause a problem, this has to be somehow automatically
> > > fixed isn't it?
> >
> > Can it cause a problem? I'm not so sure -- it depends on what you mean
> > by "problem". One person complained forcefully just because he didn't
> > like all the extra "disconnect" messages in the system log, even though
> > everything worked perfectly.
> >
> > > For example how to I ensure the correct order with udev?
> >
> > You can't. But you can add rules to /etc/modprobe.conf to insure that
> > ehci-hcd is always loaded before uhci-hcd.
> >
> > > > CONFIG_USB_EHCI_ROOT_HUB_TT shouldn't make any difference at all.
> > > > That setting matters only for hardware using the ARC/TDI design, which
> > > > is not present in your Intel chipset. Likewise, provided ehci-hcd is
> > > > loaded first, it shouldn't make any difference whether uhci-hcd is
> > > > loaded or not.
> > > Well, I retest this.
> > > But it seems to work
> >
> > Best would be if you could send two usbmon traces, one showing the
> > problem and one showing what happens when uhci-hcd isn't loaded but
> > everything else is the same. For each test, plug in the printer's USB
> > cable after starting the trace.
Sorry, sorry, sorry.
is was the CONFIG_USB_EHCI_TT_NEWSCHED that did it.
I confused both options, without the above option printer works
flawlessly.
In addition I instructed modprobe to load ehci when it loads uhci, and
then uhci.
Truth is truth, I have again seen same timeout messages, just after I
reboot the printer. It is possible that some of the hp scripts, eg the
one that loads firmware, queries the printer while firmware loads or so,
anyway even after such message printer works (I printed a page using
it).
Now I will enable again the CONFIG_USB_EHCI_TT_NEWSCHED, and see how
fast it will fail.
Best regards,
Maxim Levitsky
On Mon, 9 Mar 2009, Maxim Levitsky wrote:
> Sorry, sorry, sorry.
>
> is was the CONFIG_USB_EHCI_TT_NEWSCHED that did it.
> I confused both options, without the above option printer works
> flawlessly.
Is your printer connected directly to the computer, or does it go
through a hub? (If it is connected directly then EHCI_TT_NEWSCHED
should not affect it at all.)
If it does go through a hub, does it behave better when you attach it
directly?
Alan Stern
On Mon, 2009-03-09 at 10:53 -0400, Alan Stern wrote:
> On Mon, 9 Mar 2009, Maxim Levitsky wrote:
>
> > Sorry, sorry, sorry.
> >
> > is was the CONFIG_USB_EHCI_TT_NEWSCHED that did it.
> > I confused both options, without the above option printer works
> > flawlessly.
>
> Is your printer connected directly to the computer, or does it go
> through a hub? (If it is connected directly then EHCI_TT_NEWSCHED
> should not affect it at all.)
>
> If it does go through a hub, does it behave better when you attach it
> directly?
>
> Alan Stern
>
No, it is connected directly.
Just tried 'bad' driver, and firmware upload failed
Do you mean that CONFIG_USB_EHCI_TT_NEWSCHED doesn't affect the driver
at all when no hub is presented?
Btw, at least according to lsusb -t, there are no internal hubs in the
printer.
But it can be a coincidence, it seems that with 'bad' driver printer
works 'better' to as it failed back few days ago much more often, maybe
cable is bad, don't know, but according to the web these printers
1018/1020.. have usb problems, there is even a readme for that in
foo2zjz
I try to use the 'good' driver
(without CONFIG_USB_EHCI_TT_NEWSCHED) for some time.
Best regards,
Maxim Levitsky
On Mon, 9 Mar 2009, Maxim Levitsky wrote:
> > Is your printer connected directly to the computer, or does it go
> > through a hub? (If it is connected directly then EHCI_TT_NEWSCHED
> > should not affect it at all.)
> >
> > If it does go through a hub, does it behave better when you attach it
> > directly?
> >
> > Alan Stern
> >
> No, it is connected directly.
> Just tried 'bad' driver, and firmware upload failed
>
> Do you mean that CONFIG_USB_EHCI_TT_NEWSCHED doesn't affect the driver
> at all when no hub is presented?
That's right. Transaction Translators (TTs) live inside hubs. If you
don't use a hub then the TT code never runs.
> Btw, at least according to lsusb -t, there are no internal hubs in the
> printer.
What does /proc/bus/usb/devices say?
> But it can be a coincidence, it seems that with 'bad' driver printer
> works 'better' to as it failed back few days ago much more often, maybe
> cable is bad, don't know, but according to the web these printers
> 1018/1020.. have usb problems, there is even a readme for that in
> foo2zjz
>
> I try to use the 'good' driver
> (without CONFIG_USB_EHCI_TT_NEWSCHED) for some time.
Please don't forget to collect usbmon traces when the problem occurs.
Alan Stern
On Mon, 2009-03-09 at 12:15 -0400, Alan Stern wrote:
> On Mon, 9 Mar 2009, Maxim Levitsky wrote:
>
> > > Is your printer connected directly to the computer, or does it go
> > > through a hub? (If it is connected directly then EHCI_TT_NEWSCHED
> > > should not affect it at all.)
> > >
> > > If it does go through a hub, does it behave better when you attach it
> > > directly?
> > >
> > > Alan Stern
> > >
> > No, it is connected directly.
> > Just tried 'bad' driver, and firmware upload failed
> >
> > Do you mean that CONFIG_USB_EHCI_TT_NEWSCHED doesn't affect the driver
> > at all when no hub is presented?
>
> That's right. Transaction Translators (TTs) live inside hubs. If you
> don't use a hub then the TT code never runs.
>
> > Btw, at least according to lsusb -t, there are no internal hubs in the
> > printer.
>
> What does /proc/bus/usb/devices say?
>
Ubuntu doesn't seem to mount usbfs on /proc/bus/usb, so:
sudo mount -tusbfs none /proc/bus/usb
maxim@maxim-laptop:~$ cat /proc/bus/usb/devices
T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 2.06
S: Manufacturer=Linux 2.6.28 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 2.06
S: Manufacturer=Linux 2.6.28 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 2.06
S: Manufacturer=Linux 2.6.28 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 2.06
S: Manufacturer=Linux 2.6.28 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1a.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 2.06
S: Manufacturer=Linux 2.6.28 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1a.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 2.06
S: Manufacturer=Linux 2.6.28 ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=0000:00:1d.7
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=03f0 ProdID=4117 Rev= 1.00
S: Manufacturer=Hewlett-Packard
S: Product=HP LaserJet 1018
S: SerialNumber=KP06J6V
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(unk. ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=064e ProdID=a101 Rev= 1.00
S: Manufacturer=SuYin
S: Product=Acer CrystalEye webcam
S: SerialNumber=CN0314-OV03-VA-R02.00.00
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS= 128 Ivl=125us
I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS= 256 Ivl=125us
I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS= 800 Ivl=125us
I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=1600 Ivl=125us
I: If#= 1 Alt= 5 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=2400 Ivl=125us
I: If#= 1 Alt= 6 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=05(Isoc) MxPS=3000 Ivl=125us
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 4
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 2.06
S: Manufacturer=Linux 2.6.28 ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=0000:00:1a.7
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
> > But it can be a coincidence, it seems that with 'bad' driver printer
> > works 'better' to as it failed back few days ago much more often, maybe
> > cable is bad, don't know, but according to the web these printers
> > 1018/1020.. have usb problems, there is even a readme for that in
> > foo2zjz
> >
> > I try to use the 'good' driver
> > (without CONFIG_USB_EHCI_TT_NEWSCHED) for some time.
> Please don't forget to collect usbmon traces when the problem occurs.
No problem, I would.
Thanks a lot,
Best regards,
Maxim Levitsky
>
> Alan Stern
>
On Mon, 9 Mar 2009, Maxim Levitsky wrote:
> T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=03f0 ProdID=4117 Rev= 1.00
> S: Manufacturer=Hewlett-Packard
> S: Product=HP LaserJet 1018
> S: SerialNumber=KP06J6V
> C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 98mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=(none)
> E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
> T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 2 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=ef(unk. ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=064e ProdID=a101 Rev= 1.00
> S: Manufacturer=SuYin
> S: Product=Acer CrystalEye webcam
> S: SerialNumber=CN0314-OV03-VA-R02.00.00
> C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
> A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
> E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=4ms
> I:* If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> E: Ad=81(I) Atr=05(Isoc) MxPS= 128 Ivl=125us
> I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> E: Ad=81(I) Atr=05(Isoc) MxPS= 256 Ivl=125us
> I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> E: Ad=81(I) Atr=05(Isoc) MxPS= 800 Ivl=125us
> I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> E: Ad=81(I) Atr=05(Isoc) MxPS=1600 Ivl=125us
> I: If#= 1 Alt= 5 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> E: Ad=81(I) Atr=05(Isoc) MxPS=2400 Ivl=125us
> I: If#= 1 Alt= 6 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> E: Ad=81(I) Atr=05(Isoc) MxPS=3000 Ivl=125us
I wonder... Does it make any difference if you unplug that webcam, or
plug it into the other high-speed bus?
Alan Stern
On Mon, 2009-03-09 at 15:12 -0400, Alan Stern wrote:
> On Mon, 9 Mar 2009, Maxim Levitsky wrote:
>
> > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0
> > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> > P: Vendor=03f0 ProdID=4117 Rev= 1.00
> > S: Manufacturer=Hewlett-Packard
> > S: Product=HP LaserJet 1018
> > S: SerialNumber=KP06J6V
> > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 98mA
> > I:* If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=(none)
> > E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> >
> > T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 2 Spd=480 MxCh= 0
> > D: Ver= 2.00 Cls=ef(unk. ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
> > P: Vendor=064e ProdID=a101 Rev= 1.00
> > S: Manufacturer=SuYin
> > S: Product=Acer CrystalEye webcam
> > S: SerialNumber=CN0314-OV03-VA-R02.00.00
> > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
> > A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
> > I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
> > E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=4ms
> > I:* If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > E: Ad=81(I) Atr=05(Isoc) MxPS= 128 Ivl=125us
> > I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > E: Ad=81(I) Atr=05(Isoc) MxPS= 256 Ivl=125us
> > I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > E: Ad=81(I) Atr=05(Isoc) MxPS= 800 Ivl=125us
> > I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > E: Ad=81(I) Atr=05(Isoc) MxPS=1600 Ivl=125us
> > I: If#= 1 Alt= 5 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > E: Ad=81(I) Atr=05(Isoc) MxPS=2400 Ivl=125us
> > I: If#= 1 Alt= 6 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > E: Ad=81(I) Atr=05(Isoc) MxPS=3000 Ivl=125us
>
> I wonder... Does it make any difference if you unplug that webcam, or
> plug it into the other high-speed bus?
Can't do so, its built-in.
Best regards,
Maxim Levitsky
On Mon, 2009-03-09 at 21:51 +0200, Maxim Levitsky wrote:
> On Mon, 2009-03-09 at 15:12 -0400, Alan Stern wrote:
> > On Mon, 9 Mar 2009, Maxim Levitsky wrote:
> >
> > > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0
> > > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> > > P: Vendor=03f0 ProdID=4117 Rev= 1.00
> > > S: Manufacturer=Hewlett-Packard
> > > S: Product=HP LaserJet 1018
> > > S: SerialNumber=KP06J6V
> > > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 98mA
> > > I:* If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=(none)
> > > E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> > > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> > >
> > > T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 2 Spd=480 MxCh= 0
> > > D: Ver= 2.00 Cls=ef(unk. ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
> > > P: Vendor=064e ProdID=a101 Rev= 1.00
> > > S: Manufacturer=SuYin
> > > S: Product=Acer CrystalEye webcam
> > > S: SerialNumber=CN0314-OV03-VA-R02.00.00
> > > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
> > > A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
> > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
> > > E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=4ms
> > > I:* If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > > I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 128 Ivl=125us
> > > I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 256 Ivl=125us
> > > I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 800 Ivl=125us
> > > I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > > E: Ad=81(I) Atr=05(Isoc) MxPS=1600 Ivl=125us
> > > I: If#= 1 Alt= 5 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > > E: Ad=81(I) Atr=05(Isoc) MxPS=2400 Ivl=125us
> > > I: If#= 1 Alt= 6 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > > E: Ad=81(I) Atr=05(Isoc) MxPS=3000 Ivl=125us
> >
> > I wonder... Does it make any difference if you unplug that webcam, or
> > plug it into the other high-speed bus?
> Can't do so, its built-in.
But I can plug printer into another usb bus, I found a single port (this
notebook has 4 ports) that is on bus #1, problem is that it it on the
other side of the notebook, and from the point where the printer stands
the cable isn't long enough to reach it.
I do some more testing soon, buy another and longer cable
Anyway couldn't crash the printer even once with 'good' driver.
In other words I was sure I found a cause for this problem, but it seems
I found nothing or maybe a bad cable (I did some tests in windows - but
as things unroll, this printer can work quite reliably sometimes that
is)
So again big thanks,
Best regards,
Maxim Levitsky