Skip to contentSkip to conversation

USB troubles in rc2

DISCUSSION Luis Miguel García Mancebo 8 participants 24 messages Aug 2, 2004 – Aug 10, 2004

lore
Share & tools
lore
#0 lore raw

Hello,

I have a nforce2 motherboard. I have to report that recent changes in usb
code make my board don't work at all.

In 2.6.7-mm7, I just reverted the bk-usb.patch and the things started to
work, but now it's on mainstream, so I cannot make it work.

Do you want for me to do some tests?

Thanks.

P.S.: Please, CC me as I'm not subscribed.

Signature · 3 lines
Luis Miguel García Mancebo
Universidad de Deusto / Deusto University
Spain
#1 lore raw
Quoted 9 lines · Luis Miguel Garc?a Mancebo

Hello,

I have a nforce2 motherboard. I have to report that recent changes in usb
code make my board don't work at all.

In 2.6.7-mm7, I just reverted the bk-usb.patch and the things started to
work, but now it's on mainstream, so I cannot make it work.

Do you want for me to do some tests?

Yes please. What exactly "does not work"?

Also, let's cc: the linux-usb-devel mailing list to try to help out here...

thanks,

greg k-h

#2 lore raw

I have an nforce2 motherboard also (Asus A7N8X Deluxe). And I'm having issues as well, like the parent poster I had to previously revert bk-usb.patch when using mm kernels. Now the problem persists in vanilla 2.6.8-rc2. Specifically my problem is that Starting Cups hangs during bootup. I removed USB support and it booted fine, but I can't live without USB, keyboard, mouse, and external hard drive are all USB. Below is my config file hopefully it will help.

Quoted 27 lines · Greg KH
Quoted 9 lines · Luis Miguel Garc?a Mancebo

Hello,

I have a nforce2 motherboard. I have to report that recent changes in usb
code make my board don't work at all.

In 2.6.7-mm7, I just reverted the bk-usb.patch and the things started to
work, but now it's on mainstream, so I cannot make it work.

Do you want for me to do some tests?

Yes please. What exactly "does not work"?

Also, let's cc: the linux-usb-devel mailing list to try to help out here...

thanks,

greg k-h

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#3 lore raw

I have the same board. I cannot get USB and 1394 to cohabitate. On my system, when I insert a USB device, the 1394 system shows itself as handling the interrupt and the USB remains dormant.

Trever

Quoted 7 lines · Michael Guterl

I have an nforce2 motherboard also (Asus A7N8X Deluxe). And I'm having issues as well, like the parent poster I had to previously revert bk-usb.patch when using mm kernels. Now the problem persists in vanilla 2.6.8-rc2. Specifically my problem is that Starting Cups hangs during bootup. I removed USB support and it booted fine, but I can't live without USB, keyboard, mouse, and external hard drive are all USB. Below is my config file hopefully it will help.

--
"You can surrender Without a prayer But never ever pray Pray without surrender You can fight Fight without ever wining But you can never ever win Win without fight" -- Niel Peart

#4 lore raw
In reply to Greg KH

Well, sorry, here is the info:

I think the problem is with the ohci_hcd:
____________________________________________________________________________________
With 2.6.8-rc2-mm2 (and even with bk-usb.patch reverted), my digital camera don't work in usb-storage mode nor ptp mode. My usb tablet don't work either. And I get this (even the camera is on, but it don't appear):

root@evanescence / # cat /proc/bus/usb/devices

T:  Bus=01 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=01 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.8-rc2-love3 ehci_hcd
S:  Product=nVidia Corporation nForce2 USB Controller
S:  SerialNumber=0000:00:02.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=256ms

___________________________________________________________________________________

With 2.6.7-mm7 don't work either, but I can revert the bk-usb.patch in the andrew tree and all works ok. Even the camera:

root@evanescence /home/ktech # cat /proc/bus/usb/devices

T:  Bus=03 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=01 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.7-love8-udev2 ehci_hcd
S:  Product=nVidia Corporation nForce2 USB Controller
S:  SerialNumber=0000:00:02.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=256ms
T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.7-love8-udev2 ohci_hcd
S:  Product=nVidia Corporation nForce2 USB Controller (#2)
S:  SerialNumber=0000:00:02.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=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.7-love8-udev2 ohci_hcd
S:  Product=nVidia Corporation nForce2 USB Controller
S:  SerialNumber=0000:00:02.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=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=054c ProdID=0010 Rev= 4.10
S:  Manufacturer=Sony
S:  Product=Sony DSC
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=ff Prot=01 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=255ms

So I think the changes went mainstream, so I don't have nothing to revert now. If any of you want me to try something, please ask me (CC me as I'm not subscribed).

Thanks.

Quoted 19 lines · Greg KH
Quoted 9 lines · Luis Miguel Garc?a Mancebo

Hello,

I have a nforce2 motherboard. I have to report that recent changes in
usb code make my board don't work at all.

In 2.6.7-mm7, I just reverted the bk-usb.patch and the things started to
work, but now it's on mainstream, so I cannot make it work.

Do you want for me to do some tests?

Yes please. What exactly "does not work"?

Also, let's cc: the linux-usb-devel mailing list to try to help out here...

thanks,

greg k-h

Signature · 3 lines
Luis Miguel García Mancebo
Universidad de Deusto / Deusto University
Spain
#5 lore raw
Quoted 2 lines · Luis Miguel Garc?a Mancebo

With 2.6.7-mm7 don't work either, but I can revert the bk-usb.patch in the andrew tree and all works ok. Even the camera:

So 2.6.7 (with no patches) worked for you? Did 2.6.8-rc1 break? Or was it 2.6.8-rc2 that broke your box?

thanks,

greg k-h

#6 lore raw
Quoted 10 lines · Greg KH
Quoted 2 lines · Luis Miguel Garc?a Mancebo

With 2.6.7-mm7 don't work either, but I can revert the bk-usb.patch in the andrew tree and all works ok. Even the camera:

So 2.6.7 (with no patches) worked for you? Did 2.6.8-rc1 break? Or was it 2.6.8-rc2 that broke your box?

thanks,

greg k-h

I have been testing various kernels. Here's the restult:

2.6.7-mm7 DON'T WORK
2.6.7-mm7 (with bk-usb.patch reverted) WORKS

2.6.7-rc1 DON'T WORK
2.6.7-rc2 DON'T WORK

So I think the problems started on vanilla in 2.6.8-rc1 but was already there in 2.6.7-mm7.

Thanks a lot. Any patch do you want for me to test?

Signature · 3 lines
Luis Miguel García Mancebo
Universidad de Deusto / Deusto University
Spain
#7 lore raw

2.6.7-mm7 doesn't work
2.6.7-mm7 (with bk-usb.patch reverted) works

2.6.8-rc2 doesn't work
2.6.8-rc2-mm2 doesn't work
2.6.8-rc2-mm2 (with bk-usb.patch reverted) doesn't work

I will test rc1 later tonight once I get off work and post the results.

As stated earlier machine hangs on Starting cups. If I disconnect all USB devices it boots, but when I plug my keyboard in, nothing works unless I hold down a key for a few seconds. Then the input is shown on the machine but repeatedly, like I was holding the key. Example I'll hold the "s" key and it appears after a few seconds, but like "sssssssssssssssssssssssssss" if I hit backspace nothing, but if I hold it, it will erase all the characters.

Please CC to linux-usb-devel as I am not subscribed.

Quoted 37 lines · Luis Miguel García Mancebo
Quoted 10 lines · Greg KH
Quoted 2 lines · Luis Miguel Garc?a Mancebo

With 2.6.7-mm7 don't work either, but I can revert the bk-usb.patch in the andrew tree and all works ok. Even the camera:

So 2.6.7 (with no patches) worked for you? Did 2.6.8-rc1 break? Or was it 2.6.8-rc2 that broke your box?

thanks,

greg k-h

I have been testing various kernels. Here's the restult:

2.6.7-mm7 DON'T WORK
2.6.7-mm7 (with bk-usb.patch reverted) WORKS

2.6.7-rc1 DON'T WORK
2.6.7-rc2 DON'T WORK

So I think the problems started on vanilla in 2.6.8-rc1 but was already there in 2.6.7-mm7.

Thanks a lot. Any patch do you want for me to test?

--
Luis Miguel García Mancebo
Universidad de Deusto / Deusto University
Spain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#8 lore raw
Quoted 1 line · Michael Guterl

As stated earlier machine hangs on Starting cups.

The "usblp" driver hasn't changed recently.

Quoted 3 lines

If I disconnect all
USB devices it boots, but when I plug my keyboard in, nothing works unless I hold down a key for a few seconds.

One data point: rc3 worked just fine for me on one machine, OHCI and EHCI under light testing (which included a keyboard).

Please be sure to provide full debug info with future reports, including "lspci -vv" info, "dmesg" output showing usb init and showing the failure, info about the USB devices you're using, and "how I broke it" info. "alt-sysrq-t" traces are good for kernel hangs...

There seem to be a bunch of reports floating around that are basically "it doesn't work for me" ... and devoid of enough info that anyone could actually track down the problem

#9 lore raw

Okay, due to my lack of detail from previous posts, I thought I'd restate everything with a little more detail. Previously I was using 2.6.7-mm7 (bk-acpi.patch and bk-usb.patch were reversed), everything worked fine. Upgraded to 2.6.8-rc2 and my machine would just stop at starting cupsd. Previous to reversing bk-acpi.patch and bk-usb.patch, 2.6.7-mm7 showed the same behavior. I unplugged all my USB devices, and booted, and 2.6.8-rc2 started fine. I plugged in the keyboard and I tried to use the keyboard and the result was whichever key was pressed, that character was repeated numerous times. No matter what I could not get a single character to appear, the always appeared like "sssssssssssssssssssssss". Went and grabbed an old PS/2 Keyboard, and proceeded to gather the information David Brownell suggested.

Attached are my dmesg's from each kernel, each time I booted fully, then plugged the USB keyboard in, and then the USB mouse. My kernel config is also attached, along with the output of lspci -v, (David Brownell mentioned "lspci -w" but this isn't a valid option, and I assume he meant -v). Also thought it might be worth mentioning that I'm using a Belkin USB Keyboard, and Logitech USB Mouse. It might also be worth mentioning I don't have a USB printer at all, I use cups for network printing.

Quoted 25 lines · David Brownell
Quoted 1 line · Michael Guterl

As stated earlier machine hangs on Starting cups.

The "usblp" driver hasn't changed recently.

Quoted 3 lines

If I disconnect all
USB devices it boots, but when I plug my keyboard in, nothing works unless I hold down a key for a few seconds.

One data point: rc3 worked just fine for me on one machine, OHCI and EHCI under light testing (which included a keyboard).

Please be sure to provide full debug info with future reports, including "lspci -vv" info, "dmesg" output showing usb init and showing the failure, info about the USB devices you're using, and "how I broke it" info. "alt-sysrq-t" traces are good for kernel hangs...

There seem to be a bunch of reports floating around that are basically "it doesn't work for me" ... and devoid of enough info that anyone could actually track down the problem

#10 lore raw
Quoted 4 lines · Michael Guterl

Attached are my dmesg's from each kernel, each time I booted fully, then plugged the USB keyboard in, and then the USB mouse. My kernel config is also attached, along with the output of lspci -v, (David Brownell mentioned "lspci -w" but this isn't a valid option, and I

Actually that was "-vv" (two v's, not double-v), but don't bother.

The dmesg output shows this is a HID failure. It's likely connected with some changes in the unlink logic, since that's what returns the "-ENOENT" status. The usb_kill_urb() changes added a new URB state as I recall, maybe that's part of the issue here... since that routine replaced the previous "synchronous unlink" logic.

- Dave

#11 lore raw

Thanks for the reply David, but where exactly does this leave me and the others experiencing this problem? Is there any more information I can provide that might help? Any possible solutions, patches, etc?

Quoted 18 lines · David Brownell
Quoted 4 lines · Michael Guterl

Attached are my dmesg's from each kernel, each time I booted fully, then plugged the USB keyboard in, and then the USB mouse. My kernel config is also attached, along with the output of lspci -v, (David Brownell mentioned "lspci -w" but this isn't a valid option, and I

Actually that was "-vv" (two v's, not double-v), but don't bother.

The dmesg output shows this is a HID failure. It's likely connected with some changes in the unlink logic, since that's what returns the "-ENOENT" status. The usb_kill_urb() changes added a new URB state as I recall, maybe that's part of the issue here... since that routine replaced the previous "synchronous unlink" logic.

- Dave

#12 lore raw
Quoted 3 lines · Michael Guterl

Thanks for the reply David, but where exactly does this leave me and the others experiencing this problem? Is there any more information I can provide that might help? Any possible solutions, patches, etc?

It leaves you (and others) with the problem partially isolated, so that someone with time to track it down will have that much less work to do.

The most effective solutions involve someone who has the problem actually stepping up and debugging the whole thing, then providing a patch fixing the problem.

A second-best would be collaboration between someone who has the time (not me!) and someone who has the problem (you?) to remotely debug the problem.

A third-best would be for someone (you?) to find out exactly which patch caused the problem -- a binary search of the USB patches, luckily it's made easier by the fact that it could only be a change in HID, usbcore, or some HCD. (And most likely IMO it's usbcore.) Then that patch can either be further debugged, or reverted.

- Dave

Quoted 1 line

On Thu, 5 Aug 2004 08:34:27 -0700, David Brownell <[email protected]>

Quoted 12 lines · wrote:
Quoted 11 lines

....

The dmesg output shows this is a HID failure. It's likely connected with some changes in the unlink logic, since that's what returns the "-ENOENT" status. The usb_kill_urb() changes added a new URB state as I recall, maybe that's part of the issue here... since that routine replaced the previous "synchronous unlink" logic.

- Dave

#13 lore raw
Quoted 18 lines · David Brownell
Quoted 5 lines · Michael Guterl

Thanks for the reply David, but where exactly does this leave me and the others experiencing this problem? Is there any more information I can provide that might help? Any possible solutions, patches, etc?

It leaves you (and others) with the problem partially isolated, so that someone with time to track it down will have that much less work to do. [...]
A third-best would be for someone (you?) to find out exactly which patch caused the problem -- a binary search of the USB patches, luckily it's made easier by the fact that it could only be a change in HID, usbcore, or some HCD. (And most likely IMO it's usbcore.) Then that patch can either be further debugged, or reverted.

Quoted 4 lines

- Dave

OK, I'm willing since I'm stuck with 2.6.7-ck5 which eventually bugs due to some USB problems. I'm not a developer so I need a little help learning how to get the USB patches added somewhere in between 2.6.7 and 2.6.7-mm2/2.6.8-rc1. I'm kinda busy right now so maybe I didn't search the kernel.org website well enough, but I've reached the conclusion I'll need to use bk or the cvs interface. So if someone can give me a quick and dirty tutorial or point me to where I can read up on this (or just give me some google search terms) I'd be willing to apply patches until it breaks and try to figure out what's going wrong.

Thanks,

Wes

#14 lore raw
In reply to David Brownell

What if Alan's assumptions that it is in ACPI and not USB are correct?
Personally I don't know enough to handle really any of the tasks you
suggested. I figured the fact that reverting bk-acpi.patch and bk-usb.patch would throw up some kind of red flag, that something in there was maybe messed up and merged in.

Quoted 42 lines · David Brownell
Quoted 3 lines · Michael Guterl

Thanks for the reply David, but where exactly does this leave me and the others experiencing this problem? Is there any more information I can provide that might help? Any possible solutions, patches, etc?

It leaves you (and others) with the problem partially isolated, so that someone with time to track it down will have that much less work to do.

The most effective solutions involve someone who has the problem actually stepping up and debugging the whole thing, then providing a patch fixing the problem.

A second-best would be collaboration between someone who has the time (not me!) and someone who has the problem (you?) to remotely debug the problem.

A third-best would be for someone (you?) to find out exactly which patch caused the problem -- a binary search of the USB patches, luckily it's made easier by the fact that it could only be a change in HID, usbcore, or some HCD. (And most likely IMO it's usbcore.) Then that patch can either be further debugged, or reverted.

- Dave

Quoted 1 line

On Thu, 5 Aug 2004 08:34:27 -0700, David Brownell <[email protected]>

Quoted 14 lines · wrote:
Quoted 13 lines

....

The dmesg output shows this is a HID failure. It's likely connected with some changes in the unlink logic, since that's what returns the "-ENOENT" status. The usb_kill_urb() changes added a new URB state as I recall, maybe that's part of the issue here... since that routine replaced the previous "synchronous unlink" logic.

- Dave

#15 lore raw
Quoted 5 lines · Michael Guterl

What if Alan's assumptions that it is in ACPI and not USB are correct?
Personally I don't know enough to handle really any of the tasks you
suggested. I figured the fact that reverting bk-acpi.patch and bk-usb.patch would throw up some kind of red flag, that something in there was maybe messed up and merged in.

It was a guess, not an assumption!

You could test this guess by reverting bk-usb.patch while leaving bk-acpi.patch intact.

Alan Stern

#16 lore raw

Yeah I have to work today, Sunday!?!? After I get off if I have time I'll start messing with the bk-usb and bk-acpi patches.

Quoted 16 lines · Alan Stern
Quoted 5 lines · Michael Guterl

What if Alan's assumptions that it is in ACPI and not USB are correct?
Personally I don't know enough to handle really any of the tasks you
suggested. I figured the fact that reverting bk-acpi.patch and bk-usb.patch would throw up some kind of red flag, that something in there was maybe messed up and merged in.

It was a guess, not an assumption!

You could test this guess by reverting bk-usb.patch while leaving bk-acpi.patch intact.

Alan Stern

#17 lore raw

Okay some new information regarding this problem. It seems that USB is not entirely broken, because I can use my USB mouse in X while using a PS/2 keyboard.

I turned USB and ACPI debugging on in the kernel. I am recreating this problem by booting the machine with no USB devices plugged in, then plugging the keyboard in, and then unplugging the keyboard. I am recreating the problem with 2.6.8-rc3-mm1, but any 2.6.8-rc* kernel seems to reproduce the same errors, and yes I have tried 2.6.8-rc4 as well.

When I plug the USB keyboard in here is what dmesg shows.

ehci_hcd 0000:00:02.2: GetStatus port 3 status 001403 POWER sig=k CSC CONNECT hub 1-0:1.0: port 3, status 0501, change 0001, 480 Mb/s
hub 1-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x501 ehci_hcd 0000:00:02.2: port 3 low speed --> companion
ehci_hcd 0000:00:02.2: GetStatus port 3 status 003402 POWER OWNER sig=k CSC ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00010301 CSC LSDA PPS CCS
hub 3-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301 ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA PPS PES CCS
usb 3-1: new low speed USB device using address 2
usb 3-1: skipped 1 descriptor after interface
usb 3-1: skipped 1 descriptor after interface
usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: default language 0x0409
usb 3-1: Product: USB Keyboar?
usb 3-1: Manufacturer: ABBAHOME
usb 3-1: hotplug
usb 3-1: adding 3-1:1.0 (config #1, interface 0)
usb 3-1:1.0: hotplug
usbhid 3-1:1.0: usb_probe_interface
usbhid 3-1:1.0: usb_probe_interface - got id
usb 3-1: control timeout on ep0in
drivers/usb/input/hid-core.c: ctrl urb status -2 received drivers/usb/input/hid-core.c: timeout initializing reports

input: USB HID v1.10 Keyboard [ABBAHOME USB Keyboar?] on usb-0000:00:02.1-1 usb 3-1: adding 3-1:1.1 (config #1, interface 1)
usb 3-1:1.1: hotplug
usbhid 3-1:1.1: usb_probe_interface
usbhid 3-1:1.1: usb_probe_interface - got id drivers/usb/input/hid-core.c: ctrl urb status -2 received drivers/usb/input/hid-core.c: usb_submit_urb(ctrl) failed

When I unplug the keyboard this is what is shown, and the latter portion is repeated over and over again.

:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110

However, when I plug in my USB mouse and then unplug it, with the same kernel here is what is shown from dmesg.

ehci_hcd 0000:00:02.2: GetStatus port 3 status 001403 POWER sig=k CSC CONNECT hub 1-0:1.0: port 3, status 0501, change 0001, 480 Mb/s
hub 1-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x501 ehci_hcd 0000:00:02.2: port 3 low speed --> companion
ehci_hcd 0000:00:02.2: GetStatus port 3 status 003402 POWER OWNER sig=k CSC ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00010301 CSC LSDA PPS CCS
hub 3-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301 ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00100303 PRSC LSDA PPS PES CCS
usb 3-1: new low speed USB device using address 2
usb 3-1: skipped 1 descriptor after interface
usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: default language 0x0409
usb 3-1: Product: USB-PS/2 Optical Mouse
usb 3-1: Manufacturer: Logitech
usb 3-1: hotplug
usb 3-1: adding 3-1:1.0 (config #1, interface 0)
usb 3-1:1.0: hotplug
usbhid 3-1:1.0: usb_probe_interface
usbhid 3-1:1.0: usb_probe_interface - got id
input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:02.1-1
ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00030300 PESC CSC LSDA PPS
hub 3-0:1.0: port 1, status 0300, change 0003, 1.5 Mb/s
usb 3-1: USB disconnect, address 2
usb 3-1: usb_disable_device nuking all URBs
usb 3-1: unregistering interface 3-1:1.0
usb 3-1:1.0: hotplug
usb 3-1: unregistering device
usb 3-1: hotplug
hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x300 ehci_hcd 0000:00:02.2: GetStatus port 3 status 001002 POWER sig=se0 CSC hub 1-0:1.0: port 3, status 0100, change 0001, 12 Mb/s
hub 1-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x100

I have attached the entire dmesg output from 2.6.8-rc3-mm1 prior to plugging in any USB devices as well. If anyone wants to see the dmesg output from my last working config I can post that as well.

Quoted 24 lines · Michael Guterl

Yeah I have to work today, Sunday!?!? After I get off if I have time I'll start messing with the bk-usb and bk-acpi patches.

Quoted 16 lines · Alan Stern
Quoted 5 lines · Michael Guterl

What if Alan's assumptions that it is in ACPI and not USB are correct?
Personally I don't know enough to handle really any of the tasks you
suggested. I figured the fact that reverting bk-acpi.patch and bk-usb.patch would throw up some kind of red flag, that something in there was maybe messed up and merged in.

It was a guess, not an assumption!

You could test this guess by reverting bk-usb.patch while leaving bk-acpi.patch intact.

Alan Stern

#18 lore raw
Quoted 8 lines · Michael Guterl

I turned USB and ACPI debugging on in the kernel. I am recreating this problem by booting the machine with no USB devices plugged in, then plugging the keyboard in, and then unplugging the keyboard. I am recreating the problem with 2.6.8-rc3-mm1, but any 2.6.8-rc* kernel seems to reproduce the same errors, and yes I have tried 2.6.8-rc4 as well.

When I plug the USB keyboard in here is what dmesg shows.

<...>

Quoted 12 lines

usb 3-1: control timeout on ep0in drivers/usb/input/hid-core.c: ctrl urb status -2 received drivers/usb/input/hid-core.c: timeout initializing reports

input: USB HID v1.10 Keyboard [ABBAHOME USB Keyboar?] on usb-0000:00:02.1-1 usb 3-1: adding 3-1:1.1 (config #1, interface 1)
usb 3-1:1.1: hotplug
usbhid 3-1:1.1: usb_probe_interface
usbhid 3-1:1.1: usb_probe_interface - got id drivers/usb/input/hid-core.c: ctrl urb status -2 received drivers/usb/input/hid-core.c: usb_submit_urb(ctrl) failed

Quoted 7 lines

When I unplug the keyboard this is what is shown, and the latter portion is repeated over and over again.

:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110

This is very strange. You might get a little more helpful information if you edit drivers/usb/input/hid-core.c and replace the line that says "#undef DEBUG" with "#define DEBUG".

Alan Stern

#19 lore raw

Okay I changed #undef DEBUG to #define DEBUG

attached are two files, the first being the complete dmesg during boot, and the keyboard plugged in after booting completed, the second file contains what happens when the keyboard is unplugged.

Quoted 38 lines · Alan Stern
Quoted 8 lines · Michael Guterl

I turned USB and ACPI debugging on in the kernel. I am recreating this problem by booting the machine with no USB devices plugged in, then plugging the keyboard in, and then unplugging the keyboard. I am recreating the problem with 2.6.8-rc3-mm1, but any 2.6.8-rc* kernel seems to reproduce the same errors, and yes I have tried 2.6.8-rc4 as well.

When I plug the USB keyboard in here is what dmesg shows.

<...>

Quoted 12 lines

usb 3-1: control timeout on ep0in drivers/usb/input/hid-core.c: ctrl urb status -2 received drivers/usb/input/hid-core.c: timeout initializing reports

input: USB HID v1.10 Keyboard [ABBAHOME USB Keyboar?] on usb-0000:00:02.1-1 usb 3-1: adding 3-1:1.1 (config #1, interface 1)
usb 3-1:1.1: hotplug
usbhid 3-1:1.1: usb_probe_interface
usbhid 3-1:1.1: usb_probe_interface - got id drivers/usb/input/hid-core.c: ctrl urb status -2 received drivers/usb/input/hid-core.c: usb_submit_urb(ctrl) failed

Quoted 7 lines

When I unplug the keyboard this is what is shown, and the latter portion is repeated over and over again.

:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110 ohci_hcd 0000:00:02.1: urb c134c460 path 1 ep1in 5f160000 cc 5 --> status -110

This is very strange. You might get a little more helpful information if you edit drivers/usb/input/hid-core.c and replace the line that says "#undef DEBUG" with "#define DEBUG".

Alan Stern

#21 lore raw

Thanks for the info Kevin, but the issue still persists for me in 2.6.8-rc3-mm1.

Quoted 5 lines · Kevin O'Shea

Just thought you guys would like to know I had this same problem since 2.6.7-mm6, but it is now fixed for me in 2.6.8-rc3-mm1.

I have an intel 865PE chipset.

#22 lore raw
In reply to Michael Guterl
Quoted 4 lines · Michael Guterl

Okay, due to my lack of detail from previous posts, I thought I'd restate everything with a little more detail. Previously I was using 2.6.7-mm7 (bk-acpi.patch and bk-usb.patch were reversed), everything worked fine. Upgraded to 2.6.8-rc2 and my machine would just stop at

Quoted 8 lines

starting cupsd. Previous to reversing bk-acpi.patch and bk-usb.patch, 2.6.7-mm7 showed the same behavior. I unplugged all my USB devices, and booted, and 2.6.8-rc2 started fine. I plugged in the keyboard and I tried to use the keyboard and the result was whichever key was pressed, that character was repeated numerous times. No matter what I could not get a single character to appear, the always appeared like "sssssssssssssssssssssss". Went and grabbed an old PS/2 Keyboard, and proceeded to gather the information David Brownell suggested.

To me this suggests you may be seeing a problem with ACPI, not USB. That's the only way to explain why starting cupsd could lead to problems.

For more information, you could try turning on the USB debugging option in your kernel's configuration.

Alan Stern

#23 lore raw
In reply to David Brownell

Ooops I forgot to attach my .config as well.

Quoted 25 lines · David Brownell
Quoted 1 line · Michael Guterl

As stated earlier machine hangs on Starting cups.

The "usblp" driver hasn't changed recently.

Quoted 3 lines

If I disconnect all
USB devices it boots, but when I plug my keyboard in, nothing works unless I hold down a key for a few seconds.

One data point: rc3 worked just fine for me on one machine, OHCI and EHCI under light testing (which included a keyboard).

Please be sure to provide full debug info with future reports, including "lspci -vv" info, "dmesg" output showing usb init and showing the failure, info about the USB devices you're using, and "how I broke it" info. "alt-sysrq-t" traces are good for kernel hangs...

There seem to be a bunch of reports floating around that are basically "it doesn't work for me" ... and devoid of enough info that anyone could actually track down the problem