Discussion:
2.6.23.11 : ehci not working with a710 camera
matthieu castet
2007-12-16 14:52:15 UTC
Permalink
Hi,

when I plug my canon a710 camera on my ehci (via) controller I got
endless "new high speed USB device using ehci_hcd and address" [1].

AFAIK it was working nice with 2.6.21 kernel.

Removing ehci module make work the camera, but the transfert is slow
(and that not a solution).

What could be done to make the camera work again ?


Thanks.


Matthieu


[1]
[ 469.067541] usb 4-6: new high speed USB device using ehci_hcd and
address 2
[ 469.387255] usb 4-6: new high speed USB device using ehci_hcd and
address 3
[ 469.697460] usb 4-6: new high speed USB device using ehci_hcd and
address 4
[ 470.006745] usb 4-6: new high speed USB device using ehci_hcd and
address 5
[ 470.316491] usb 4-6: new high speed USB device using ehci_hcd and
address 6
[ 470.626238] usb 4-6: new high speed USB device using ehci_hcd and
address 7
[ 470.936045] usb 4-6: new high speed USB device using ehci_hcd and
address 8
[ 471.245727] usb 4-6: new high speed USB device using ehci_hcd and
address 9
[ 471.555468] usb 4-6: new high speed USB device using ehci_hcd and
address 10
[ 471.865212] usb 4-6: new high speed USB device using ehci_hcd and
address 11
[ 472.174958] usb 4-6: new high speed USB device using ehci_hcd and
address 12
[ 472.687888] usb 4-6: device not accepting address 12, error -71
[ 472.794450] usb 4-6: new high speed USB device using ehci_hcd and
address 13
[ 473.104208] usb 4-6: new high speed USB device using ehci_hcd and
address 14
[ 473.597127] usb 4-6: new high speed USB device using ehci_hcd and
address 16
[ 473.906857] usb 4-6: new high speed USB device using ehci_hcd and
address 17
[ 474.216604] usb 4-6: new high speed USB device using ehci_hcd and
address 18
[ 474.729522] usb 4-6: device not accepting address 18, error -71
[ 474.836098] usb 4-6: new high speed USB device using ehci_hcd and
address 19
[ 475.145846] usb 4-6: new high speed USB device using ehci_hcd and
address 20
[ 475.455583] usb 4-6: new high speed USB device using ehci_hcd and
address 21
[ 475.775323] usb 4-6: new high speed USB device using ehci_hcd and
address 22
[ 476.261581] usb 4-6: new high speed USB device using ehci_hcd and
address 24
[ 476.571328] usb 4-6: new high speed USB device using ehci_hcd and
address 25
[ 476.881075] usb 4-6: new high speed USB device using ehci_hcd and
address 26
[ 477.190819] usb 4-6: new high speed USB device using ehci_hcd and
address 27
[ 477.500561] usb 4-6: new high speed USB device using ehci_hcd and
address 28
[ 477.810317] usb 4-6: new high speed USB device using ehci_hcd and
address 29
[ 478.120063] usb 4-6: new high speed USB device using ehci_hcd and
address 30
[ 478.429790] usb 4-6: new high speed USB device using ehci_hcd and
address 31
[ 478.739548] usb 4-6: new high speed USB device using ehci_hcd and
address 32
[ 479.049300] usb 4-6: new high speed USB device using ehci_hcd and
address 33
[ 479.372347] usb 4-6: new high speed USB device using ehci_hcd and
address 34
[ 479.682095] usb 4-6: new high speed USB device using ehci_hcd and
address 35
[ 480.011821] usb 4-6: new high speed USB device using ehci_hcd and
address 36
[ 480.321575] usb 4-6: new high speed USB device using ehci_hcd and
address 37
[ 480.633198] usb 4-6: new high speed USB device using ehci_hcd and
address 38
[ 481.124464] usb 4-6: new high speed USB device using ehci_hcd and
address 40
[ 481.610501] usb 4-6: new high speed USB device using ehci_hcd and
address 42
[ 481.900279] usb 4-6: new high speed USB device using ehci_hcd and
address 43
[ 482.219997] usb 4-6: new high speed USB device using ehci_hcd and
address 44
[ 482.529753] usb 4-6: new high speed USB device using ehci_hcd and
address 45
[ 482.839489] usb 4-6: new high speed USB device using ehci_hcd and
address 46
[ 483.159237] usb 4-6: new high speed USB device using ehci_hcd and
address 47
[ 483.655489] usb 4-6: new high speed USB device using ehci_hcd and
address 49
[ 483.965220] usb 4-6: new high speed USB device using ehci_hcd and
address 50
[ 484.274965] usb 4-6: new high speed USB device using ehci_hcd and
address 51
[ 484.584709] usb 4-6: new high speed USB device using ehci_hcd and
address 52
[ 484.894455] usb 4-6: new high speed USB device using ehci_hcd and
address 53
[ 485.204205] usb 4-6: new high speed USB device using ehci_hcd and
address 54
[ 485.513941] usb 4-6: new high speed USB device using ehci_hcd and
address 55
[ 485.833682] usb 4-6: new high speed USB device using ehci_hcd and
address 56
[ 486.143426] usb 4-6: new high speed USB device using ehci_hcd and
address 57

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Alan Stern
2007-12-16 16:04:34 UTC
Permalink
Post by matthieu castet
Hi,
when I plug my canon a710 camera on my ehci (via) controller I got
endless "new high speed USB device using ehci_hcd and address" [1].
AFAIK it was working nice with 2.6.21 kernel.
Is it still working with 2.6.21? You should make sure, because it's
possible that something in the _camera_ has broken. And if 2.6.21 is
still working, you might want to check out 2.6.22, just to try and
find exactly when the breakage occurred.
Post by matthieu castet
Removing ehci module make work the camera, but the transfert is slow
(and that not a solution).
What could be done to make the camera work again ?
You have to provide more information. Start by turning on
CONFIG_USB_DEBUG and sending the dmesg log.
Post by matthieu castet
[1]
[ 469.067541] usb 4-6: new high speed USB device using ehci_hcd and
address 2
[ 469.387255] usb 4-6: new high speed USB device using ehci_hcd and
address 3
...
Post by matthieu castet
[ 486.143426] usb 4-6: new high speed USB device using ehci_hcd and
address 57
By the way, 2 or 3 iterations would have been enough to get the idea
across. You didn't need to post all 56. :-)

Alan Stern


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
matthieu castet
2007-12-16 17:37:01 UTC
Permalink
Post by Alan Stern
You have to provide more information. Start by turning on
CONFIG_USB_DEBUG and sending the dmesg log.
Okay I have strange result :
When I plug the camera I got [1]. When I plug a pendrive i got [3].
When I plug the camera on another port I got [2].

Could it be an hadware problem on the port. But then why it works with
the pen drive ?

Thanks

Matthieu

[1]
[ 133.765504] usb usb2: usb resume
[ 133.765826] ehci_hcd 0000:00:10.3: resume root hub
[ 133.806161] hub 2-0:1.0: hub_resume
[ 133.806455] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ 133.806748] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001803
POWER sig=j CSC CONNECT
[ 133.806941] hub 2-0:1.0: port 6, status 0501, change 0001, 480 Mb/s
[ 133.926087] hub 2-0:1.0: debounce: port 6: total 100ms stable 100ms
status 0x501
[ 133.979571] ehci_hcd 0000:00:10.3: port 6 high speed
[ 133.979579] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001005
POWER sig=se0 PE CONNECT
[ 134.032641] usb 2-6: new high speed USB device using ehci_hcd and
address 2
[ 134.033015] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.033388] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.033763] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.086183] ehci_hcd 0000:00:10.3: port 6 high speed
[ 134.086193] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001007
POWER sig=se0 PE CSC CONNECT
[ 134.086643] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0040
[ 134.086855] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001002
POWER sig=se0 CSC
[ 134.087048] hub 2-0:1.0: port 6, status 0100, change 0001, 12 Mb/s
[ 134.115900] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001803
POWER sig=j CSC CONNECT
[ 134.235799] hub 2-0:1.0: debounce: port 6: total 125ms stable 100ms
status 0x501
[ 134.289378] ehci_hcd 0000:00:10.3: port 6 high speed
[ 134.289389] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001005
POWER sig=se0 PE CONNECT
[ 134.342388] usb 2-6: new high speed USB device using ehci_hcd and
address 3
[ 134.342809] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.343182] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.343557] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.395977] ehci_hcd 0000:00:10.3: port 6 high speed
[...]


[2]
[ 1795.601805] usb usb2: usb resume
[ 1795.602148] ehci_hcd 0000:00:10.3: resume root hub
[ 1795.642237] hub 2-0:1.0: hub_resume
[ 1795.642439] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ 1795.642659] ehci_hcd 0000:00:10.3: GetStatus port 5 status 001803
POWER sig=j CSC CONNECT
[ 1795.642861] hub 2-0:1.0: port 5, status 0501, change 0001, 480 Mb/s
[ 1795.762133] hub 2-0:1.0: debounce: port 5: total 100ms stable 100ms
status 0x501
[ 1795.815681] ehci_hcd 0000:00:10.3: port 5 high speed
[ 1795.815689] ehci_hcd 0000:00:10.3: GetStatus port 5 status 001005
POWER sig=se0 PE CONNECT
[ 1795.868704] usb 2-5: new high speed USB device using ehci_hcd and
address 25
[ 1795.922290] ehci_hcd 0000:00:10.3: port 5 high speed
[ 1795.922301] ehci_hcd 0000:00:10.3: GetStatus port 5 status 001005
POWER sig=se0 PE CONNECT
[ 1796.004178] usb 2-5: default language 0x0409
[ 1796.014851] usb 2-5: new device strings: Mfr=1, Product=2, SerialNumber=3
[ 1796.015045] usb 2-5: Product: Canon Digital Camera
[ 1796.015247] usb 2-5: Manufacturer: Canon Inc.
[ 1796.015440] usb 2-5: SerialNumber:
[ 1796.015776] usb 2-5: uevent
[ 1796.016848] usb 2-5: usb_probe_device
[ 1796.017697] usb 2-5: configuration #1 chosen from 1 choice
[ 1796.019362] usb 2-5: adding 2-5:1.0 (config #1, interface 0)
[ 1796.019676] usb 2-5:1.0: uevent
[ 1796.019871] usb 2-5:1.0: uevent
[ 1796.022102] drivers/usb/core/inode.c: creating file '025'


[3]
[ 2050.564073] usb usb2: usb resume
[ 2050.564426] ehci_hcd 0000:00:10.3: resume root hub
[ 2050.603011] hub 2-0:1.0: hub_resume
[ 2050.603212] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ 2050.603435] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001803
POWER sig=j CSC CONNECT
[ 2050.603637] hub 2-0:1.0: port 6, status 0501, change 0001, 480 Mb/s
[ 2050.722933] hub 2-0:1.0: debounce: port 6: total 100ms stable 100ms
status 0x501
[ 2050.776450] ehci_hcd 0000:00:10.3: port 6 high speed
[ 2050.776458] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001005
POWER sig=se0 PE CONNECT
[ 2050.829590] usb 2-6: new high speed USB device using ehci_hcd and
address 39
[ 2050.883061] ehci_hcd 0000:00:10.3: port 6 high speed
[ 2050.883070] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001005
POWER sig=se0 PE CONNECT
[ 2050.953769] usb 2-6: default language 0x0409
[ 2050.954771] usb 2-6: new device strings: Mfr=1, Product=2, SerialNumber=3
[ 2050.954973] usb 2-6: Product: USB Mass Storage Device

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Alan Stern
2007-12-16 19:42:20 UTC
Permalink
Post by matthieu castet
Post by Alan Stern
You have to provide more information. Start by turning on
CONFIG_USB_DEBUG and sending the dmesg log.
When I plug the camera I got [1]. When I plug a pendrive i got [3].
When I plug the camera on another port I got [2].
Could it be an hadware problem on the port. But then why it works with
the pen drive ?
Maybe the cable makes a bad connection with the port. If you use a
different port or a different cable then it works.

Alan Stern


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2007-12-16 20:31:41 UTC
Permalink
Post by matthieu castet
When I plug the camera I got [1]. When I plug a pendrive i got [3].
When I plug the camera on another port I got [2].
(Appended text is slightly edited to remove line wraps.)

Summary: [1] failed, but [2] and [3] worked.
Post by matthieu castet
Could it be an hadware problem on the port. But then why it works with
the pen drive ?
Clearly there is *some* difference at the hardware level. Different
devices (even of the same make/model) have different characteristics.
So do different host ports and cables. I'd try using different cables
with that camera, to start with.

But I don't like blaming this on hardware, since I still recall that
these problems started to crop up sometime in the 2.6.5 to 2.6.10 time
frame ... making me suspect changes that were made in that period were
a bit less hardware-friendly than before.

I'm going to dust off some old patches and send you one to try...

One interesting point is that in all three cases there were about
53.5 msec between the "new high speed USB device..." message and
the "port N high speed" messages. I'd have thought the failure
case would have taken a bit more time.

- Dave
Post by matthieu castet
[1]
[ 133.765504] usb usb2: usb resume
[ 133.765826] ehci_hcd 0000:00:10.3: resume root hub
[ 133.806161] hub 2-0:1.0: hub_resume
[ 133.806455] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ 133.806748] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001803 POWER sig=j CSC CONNECT
[ 133.806941] hub 2-0:1.0: port 6, status 0501, change 0001, 480 Mb/s
[ 133.926087] hub 2-0:1.0: debounce: port 6: total 100ms stable 100ms status 0x501
[ 133.979571] ehci_hcd 0000:00:10.3: port 6 high speed
[ 133.979579] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001005 POWER sig=se0 PE CONNECT
[ 134.032641] usb 2-6: new high speed USB device using ehci_hcd and address 2
[ 134.033015] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.033388] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.033763] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.086183] ehci_hcd 0000:00:10.3: port 6 high speed
[ 134.086193] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001007 POWER sig=se0 PE CSC CONNECT
[ 134.086643] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0040
[ 134.086855] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001002 POWER sig=se0 CSC
[ 134.087048] hub 2-0:1.0: port 6, status 0100, change 0001, 12 Mb/s
[ 134.115900] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001803 POWER sig=j CSC CONNECT
[ 134.235799] hub 2-0:1.0: debounce: port 6: total 125ms stable 100ms status 0x501
[ 134.289378] ehci_hcd 0000:00:10.3: port 6 high speed
[ 134.289389] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001005 POWER sig=se0 PE CONNECT
[ 134.342388] usb 2-6: new high speed USB device using ehci_hcd and address 3
[ 134.342809] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.343182] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.343557] ehci_hcd 0000:00:10.3: devpath 6 ep0in 3strikes
[ 134.395977] ehci_hcd 0000:00:10.3: port 6 high speed
[...]
[2]
[ 1795.601805] usb usb2: usb resume
[ 1795.602148] ehci_hcd 0000:00:10.3: resume root hub
[ 1795.642237] hub 2-0:1.0: hub_resume
[ 1795.642439] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ 1795.642659] ehci_hcd 0000:00:10.3: GetStatus port 5 status 001803 POWER sig=j CSC CONNECT
[ 1795.642861] hub 2-0:1.0: port 5, status 0501, change 0001, 480 Mb/s
[ 1795.762133] hub 2-0:1.0: debounce: port 5: total 100ms stable 100ms status 0x501
[ 1795.815681] ehci_hcd 0000:00:10.3: port 5 high speed
[ 1795.815689] ehci_hcd 0000:00:10.3: GetStatus port 5 status 001005 POWER sig=se0 PE CONNECT
[ 1795.868704] usb 2-5: new high speed USB device using ehci_hcd and address 25
[ 1795.922290] ehci_hcd 0000:00:10.3: port 5 high speed
[ 1795.922301] ehci_hcd 0000:00:10.3: GetStatus port 5 status 001005 POWER sig=se0 PE CONNECT
[ 1796.004178] usb 2-5: default language 0x0409
[ 1796.014851] usb 2-5: new device strings: Mfr=1, Product=2, SerialNumber=3
[ 1796.015045] usb 2-5: Product: Canon Digital Camera
[ 1796.015247] usb 2-5: Manufacturer: Canon Inc.
[ 1796.015776] usb 2-5: uevent
[ 1796.016848] usb 2-5: usb_probe_device
[ 1796.017697] usb 2-5: configuration #1 chosen from 1 choice
[ 1796.019362] usb 2-5: adding 2-5:1.0 (config #1, interface 0)
[ 1796.019676] usb 2-5:1.0: uevent
[ 1796.019871] usb 2-5:1.0: uevent
[ 1796.022102] drivers/usb/core/inode.c: creating file '025'
[3]
[ 2050.564073] usb usb2: usb resume
[ 2050.564426] ehci_hcd 0000:00:10.3: resume root hub
[ 2050.603011] hub 2-0:1.0: hub_resume
[ 2050.603212] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ 2050.603435] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001803 POWER sig=j CSC CONNECT
[ 2050.603637] hub 2-0:1.0: port 6, status 0501, change 0001, 480 Mb/s
[ 2050.722933] hub 2-0:1.0: debounce: port 6: total 100ms stable 100ms status 0x501
[ 2050.776450] ehci_hcd 0000:00:10.3: port 6 high speed
[ 2050.776458] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001005 POWER sig=se0 PE CONNECT
[ 2050.829590] usb 2-6: new high speed USB device using ehci_hcd and address 39
[ 2050.883061] ehci_hcd 0000:00:10.3: port 6 high speed
[ 2050.883070] ehci_hcd 0000:00:10.3: GetStatus port 6 status 001005 POWER sig=se0 PE CONNECT
[ 2050.953769] usb 2-6: default language 0x0409
[ 2050.954771] usb 2-6: new device strings: Mfr=1, Product=2, SerialNumber=3
[ 2050.954973] usb 2-6: Product: USB Mass Storage Device
... truncated ...
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2007-12-19 18:31:05 UTC
Permalink
Post by David Brownell
Post by matthieu castet
When I plug the camera I got [1]. When I plug a pendrive i got [3].
When I plug the camera on another port I got [2].
(Appended text is slightly edited to remove line wraps.)
Summary: [1] failed, but [2] and [3] worked.
Post by matthieu castet
Could it be an hadware problem on the port. But then why it works with
the pen drive ?
Clearly there is *some* difference at the hardware level. Different
devices (even of the same make/model) have different characteristics.
So do different host ports and cables. I'd try using different cables
with that camera, to start with.
But I don't like blaming this on hardware, since I still recall that
these problems started to crop up sometime in the 2.6.5 to 2.6.10 time
frame ... making me suspect changes that were made in that period were
a bit less hardware-friendly than before.
I'm going to dust off some old patches and send you one to try...
Here's that patch. Please give it at try with USB_DEBUG enabled.
Note that the patch has two behavioral changes -- avoid the "what
maxpacket should I use?" dance that's not needed, and use a longer
delay at one point -- plus a diagnostic change to make EHCI report
what control transfers are making trouble.

We should at least be able to find out just what calls are making
the trouble (and at what point in the sequence), even if the behavior
changes don't help. :)

- Dave


================
EXPERIMENTAL ...

* During enumeration, only full speed USB devices need the "ask for
partial descriptor, then reset" dance to get the maxpacket size for
ep0. Don't dance except with those devices.

* Allow a bit more time for devices to recover after SET_ADDRESS.

* When debugging, dump ep0 status for EHCI so we can find out which
highspeed calls are borked in one hardware config

---
drivers/usb/core/hub.c | 39 +++++++++++++++++++++++++++------------
drivers/usb/host/ehci-q.c | 3 ++-
2 files changed, 29 insertions(+), 13 deletions(-)

--- g26.orig/drivers/usb/core/hub.c 2007-12-16 11:32:09.000000000 -0800
+++ g26/drivers/usb/core/hub.c 2007-12-16 12:39:00.000000000 -0800
@@ -2216,9 +2216,11 @@ hub_port_init (struct usb_hub *hub, stru
*/
switch (udev->speed) {
case USB_SPEED_VARIABLE: /* fixed at 512 */
+ udev->descriptor.bMaxPacketSize0 =
udev->ep0.desc.wMaxPacketSize = __constant_cpu_to_le16(512);
break;
case USB_SPEED_HIGH: /* fixed at 64 */
+ udev->descriptor.bMaxPacketSize0 =
udev->ep0.desc.wMaxPacketSize = __constant_cpu_to_le16(64);
break;
case USB_SPEED_FULL: /* 8, 16, 32, or 64 */
@@ -2229,12 +2231,13 @@ hub_port_init (struct usb_hub *hub, stru
udev->ep0.desc.wMaxPacketSize = __constant_cpu_to_le16(64);
break;
case USB_SPEED_LOW: /* fixed at 8 */
+ udev->descriptor.bMaxPacketSize0 =
udev->ep0.desc.wMaxPacketSize = __constant_cpu_to_le16(8);
break;
default:
goto fail;
}
-
+
type = "";
switch (udev->speed) {
case USB_SPEED_LOW: speed = "low"; break;
@@ -2260,11 +2263,20 @@ hub_port_init (struct usb_hub *hub, stru
udev->tt = &hub->tt;
udev->ttport = port1;
}
-
- /* Why interleave GET_DESCRIPTOR and SET_ADDRESS this way?
- * Because device hardware and firmware is sometimes buggy in
- * this area, and this is how Linux has done it for ages.
- * Change it cautiously.
+
+ /* There are three tasks getting interleaved here:
+ * (a) for fullspeed, determine ep0 maxpacket;
+ * (b) set nonzero device address;
+ * (c) read the full device descriptor.
+ *
+ * Device hardware and firmware is sometimes buggy in this early
+ * enumeration stage. Change with caution; few devices get much
+ * more testing here than "does windows work", so legal protocol
+ * sequences may easily fail. The "old" scheme is what Linux used
+ * before about 2.6.8; the "new" one is used by later kernels and
+ * works more like MS-Windows. (Although now they've been modified
+ * to understand that ep0 maxpacket is always known except for full
+ * speed devices.)
*
* NOTE: If USE_NEW_SCHEME() is true we will start by issuing
* a 64-byte GET_DESCRIPTOR request. This is what Windows does,
@@ -2274,7 +2286,8 @@ hub_port_init (struct usb_hub *hub, stru
* value.
*/
for (i = 0; i < GET_DESCRIPTOR_TRIES; (++i, msleep(100))) {
- if (USE_NEW_SCHEME(retry_counter)) {
+ if (USE_NEW_SCHEME(retry_counter)
+ && !udev->descriptor.bMaxPacketSize0) {
struct usb_device_descriptor *buf;
int r = 0;

@@ -2307,6 +2320,7 @@ hub_port_init (struct usb_hub *hub, stru
default:
if (r == 0)
r = -EPROTO;
+ buf->bMaxPacketSize0 = 0;
break;
}
if (r == 0)
@@ -2347,13 +2361,14 @@ hub_port_init (struct usb_hub *hub, stru
devnum, retval);
goto fail;
}
-
+
/* cope with hardware quirkiness:
* - let SET_ADDRESS settle, some device hardware wants it
- * - read ep0 maxpacket even for high and low speed,
- */
- msleep(10);
- if (USE_NEW_SCHEME(retry_counter))
+ * - read ep0 maxpacket iff needed
+ */
+ msleep(50);
+ if (udev->descriptor.bMaxPacketSize0
+ || USE_NEW_SCHEME(retry_counter))
break;

retval = usb_get_device_descriptor(udev, 8);
--- g26.orig/drivers/usb/host/ehci-q.c 2007-12-16 19:51:09.000000000 -0800
+++ g26/drivers/usb/host/ehci-q.c 2007-12-16 19:52:09.000000000 -0800
@@ -189,7 +189,8 @@ static int qtd_copy_status (
else /* unknown */
status = -EPROTO;

- ehci_vdbg (ehci,
+ if (usb_pipeendpoint(urb->pipe) == 0) ehci_dbg (ehci,
+ // ehci_vdbg (ehci,
"dev%d ep%d%s qtd token %08x --> status %d\n",
usb_pipedevice (urb->pipe),
usb_pipeendpoint (urb->pipe),

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Alan Stern
2007-12-19 21:04:27 UTC
Permalink
Post by David Brownell
Here's that patch. Please give it at try with USB_DEBUG enabled.
Note that the patch has two behavioral changes -- avoid the "what
maxpacket should I use?" dance that's not needed, and use a longer
delay at one point -- plus a diagnostic change to make EHCI report
what control transfers are making trouble.
We should at least be able to find out just what calls are making
the trouble (and at what point in the sequence), even if the behavior
changes don't help. :)
I agree it's worth trying this. For the future, however, I would be
cautious about removing that "determine maxpacket" code for low- and
high-speed devices. Windows uses it always, regardless of the device
speed, and quite likely some devices won't work without it.

Alan Stern


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2007-12-19 21:21:10 UTC
Permalink
Post by Alan Stern
Post by David Brownell
Here's that patch. Please give it at try with USB_DEBUG enabled.
Note that the patch has two behavioral changes -- avoid the "what
maxpacket should I use?" dance that's not needed, and use a longer
delay at one point -- plus a diagnostic change to make EHCI report
what control transfers are making trouble.
We should at least be able to find out just what calls are making
the trouble (and at what point in the sequence), even if the behavior
changes don't help. :)
I agree it's worth trying this. For the future, however, I would be
cautious about removing that "determine maxpacket" code for low- and
high-speed devices. Windows uses it always, regardless of the device
speed, and quite likely some devices won't work without it.
I'm trying to understand the failure mode you imply:

<reset>
(a)
Read device descriptor, 64 bytes worth (too big)
--> returns 18 bytes "short" packet
<reset>
(b)
Set address
Read device desriptor, 18 byte worth
--> returns 18 bytes "exact match"

What's removed is the stuff between (a) and (b) right? So if a
device can notice a difference, it's because it goofs the reset.

- Dave

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Alan Stern
2007-12-19 22:01:07 UTC
Permalink
Post by David Brownell
<reset>
(a)
Read device descriptor, 64 bytes worth (too big)
--> returns 18 bytes "short" packet
<reset>
(b)
Set address
Read device desriptor, 18 byte worth
--> returns 18 bytes "exact match"
What's removed is the stuff between (a) and (b) right? So if a
device can notice a difference, it's because it goofs the reset.
Or it won't execute the Set-Address without doing a
Get-Device-Descriptor first. Or something like that. I guess you
could call this "goofing the reset".

Remember, the whole reason for implementing the "new scheme" was that
some devices didn't work with the "old scheme". This suggests
modifying the new scheme may not be a good idea.

Likewise, I have avoided removing the old scheme entirely, because of
one or two reports that some devices appear to need it. (Those reports
may not be very reliable; any device that doesn't work with the new
scheme probably doesn't work with Windows either.)

Alan Stern


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
matthieu castet
2007-12-22 10:21:49 UTC
Permalink
Hi,
Post by David Brownell
Post by David Brownell
Post by matthieu castet
When I plug the camera I got [1]. When I plug a pendrive i got [3].
When I plug the camera on another port I got [2].
(Appended text is slightly edited to remove line wraps.)
Here's that patch. Please give it at try with USB_DEBUG enabled.
Note that the patch has two behavioral changes -- avoid the "what
maxpacket should I use?" dance that's not needed, and use a longer
delay at one point -- plus a diagnostic change to make EHCI report
what control transfers are making trouble.
We should at least be able to find out just what calls are making
the trouble (and at what point in the sequence), even if the behavior
changes don't help. :)
Here the trace with the patch [1]

Matthieu

Loading...