Bugzilla – Bug 105964
iPod being found as full speed device
Last modified: 2006-02-03 10:28:06 UTC
After plugging my iPod in and copying some songs to it, I noticed that things were going pretty slow. Upon inspection, it looks like the kernel is treating it as a USB 1.1 (full speed) device instead of a USB 2.0 (hi-speed) device. usb 2-2: new full speed USB device using uhci_hcd and address 8 scsi2 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 8 usb-storage: waiting for device to settle before scanning Vendor: Apple Model: iPod Rev: 1.53 Type: Direct-Access ANSI SCSI revision: 00 In SuSE 9.3, it was correctly using USB 2.0 on this same machine.
Assigning to Greg for now.
please provide the full hwinfo output.
Hubert, do you have such an ipod?
Hubert is gone for a while, will find one tomorrow.
Strangely, it seems that if you plug/unplug the device enough times, it will show up as a hi-speed device. I'm attaching hwinfo output now.
Created attachment 47240 [details] hwinfo output
This looks very much like a HW problem (-71 is EPROTO, which means bad bitstuffing or similar problem). I'd suggest replacing the iPod USB cable. <6>usb 4-4: USB disconnect, address 64 <6>usb 2-2: new full speed USB device using uhci_hcd and address 79 <3>usb 2-2: device descriptor read/64, error -71 <3>usb 2-2: device descriptor read/64, error -71 <6>usb 2-2: new full speed USB device using uhci_hcd and address 80 <3>usb 2-2: device descriptor read/64, error -71 <3>usb 2-2: device descriptor read/64, error -71 <6>usb 2-2: new full speed USB device using uhci_hcd and address 81 <3>usb 2-2: device not accepting address 81, error -71 <6>usb 2-2: new full speed USB device using uhci_hcd and address 82 <3>usb 2-2: device not accepting address 82, error -71 <6>usb 4-4: new high speed USB device using ehci_hcd and address 66 <6>scsi34 : SCSI emulation for USB Mass Storage devices
I can confirm this problem exists under SuSE 10 Beta 2, with three different iPods... a 30GB Photo, a 20GB Regular, each with different cables, and the real test: an iPod shuffle, which doesn't have a cable, and a SanDisk 128MB USB Key Drive. The output from all four devices is identical with the exception of vendor specific product data. All I have to do to reproduce... plug in a USB Storage Device. usb 2-1: new full speed USB device using uhci_hcd and address 40 usb 2-1: device descriptor read/64, error -71 usb 2-1: device descriptor read/64, error -71 usb 2-1: new full speed USB device using uhci_hcd and address 42 usb 2-1: device descriptor read/64, error -71 usb 2-1: configuration #1 chosen from 2 choices scsi16 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 42 usb-storage: waiting for device to settle before scanning Vendor: Apple Model: iPod Rev: 2.70 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sda: 1010432 512-byte hdwr sectors (517 MB) sda: Write Protect is off sda: Mode Sense: 64 00 00 08 sda: assuming drive cache: write through SCSI device sda: 1010432 512-byte hdwr sectors (517 MB) sda: Write Protect is off sda: Mode Sense: 64 00 00 08 sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi16, channel 0, id 0, lun 0 usb-storage: device scan complete
Can you also confirm it doesn't exist in 9.3 with the same configuration?
My previous comment was valid on a Thinkpad T40P. I can confirm this problem persists on a desktop machine as well. Also, my previous comment was slightly incorrect: all four devices are detected as full-speed devices, and can be mounted without a problem, however, only the iPod shuffle produces the -71 error for me. All other devices have this message: usb 3-1: new full speed USB device using uhci_hcd and address 7 scsi5 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 7 usb-storage: waiting for device to settle before scanning ... Furthermore, rebooting on the same desktop into Ubuntu Breezy, all four devices are detected as hi-speed USB mass storage devices, so I can't believe it's a hardware issue.
While I never had SuSE 9.3 on my desktop machine, all of my iPods were detected as hi-speed devices on SuSE 9.3 and 9.3.1 STABLE 2 on the Thinkpad.
My machine is also a Thinkpad T40P, and things were showing up as high speed devices with this computer running 9.3.
OK. Another possibility for the EPROTO error would be if the UHCI and EHCI drivers were fighting to control the device. This could either be a bug in those drivers, or it could be caused by the EHCI driver being loaded at the same time the device is enumerated or not loaded at all. Can you try to disable HAL and hotplug and try again?
This is in fact the issue... modprobe -r ehci_hcd uhci_hcd modprobe ehci_hcd <plug in ipod> The ipod is then detected as a high speed device. However, I obviously loose all low/full speed devices (mouse died, lucky I had the keyboard on PS/2). modprobe uhci_hcd Brings the mouse back, but if I then eject the iPod and re-insert it, it is detected as a full speed device again, because both EHCI/UCHI drivers are fighting, and it looks like UHCI wins
I've scourged through our patches and we don't have any in the CVS that would affect this. So I expect that current bleeding edge vanilla should have the same problem. Can anyone verify that? It's likely that the uhci/ehci handshaking was broken by some of the recent patches to the USB stack. I did take a look, but can't pinpoint any real suspects, so a binary search for the change that broke it is the best I can suggest right now.
I see it here as well. will try older kernels.
I'm a bit confused here: ate:~ # dmesg | grep speed ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx usb 1-1: new full speed USB device using ohci_hcd and address 2 usb 1-1.1: new low speed USB device using ohci_hcd and address 3 usb 1-1.2: new low speed USB device using ohci_hcd and address 4 usb 3-1: new high speed USB device using ehci_hcd and address 2 date:~ # dd if=/dev/sda bs=1M of=/dev/null count=3 3+0 records in 3+0 records out 3145728 bytes (3.1 MB) copied, 0.577341 seconds, 5.4 MB/s date:~ # uname -a Linux date 2.6.13-rc7-20050824083945-default #1 Wed Aug 24 08:39:45 UTC 2005 ppc ppc ppc GNU/Linux 3-1 is the ipod, so it appears to work for me. using uhci_hcd instead gives 900k
What baffles me is how can you use uhci_hcd on a machine that has OHCI? The fact that your machine has OHCI might also be the reason why you don't have any problems - it likely doesn't fight with EHCI.
this G4 has onboard ohci, and I added a usb2/firewire card today (to get usb2 support).
does it work better if you put the ehci_hcd module into initrd or /etc/sysconfig/kernel:MODULES_TO_LOAD_ON_BOOT?
This looks exactly like my problem with a normal USB stick, which works fine on SUSE 9.3 and is extremely slow writing both with 10.0 Beta 2 and 3. bug #114024
*** Bug 114024 has been marked as a duplicate of this bug. ***
Well, since my bug has been marked as a duplicate, I might as well provide the needinfo for my USB stick: no, neither MODULES_TO_LOAD_ON_BOOT nor putting ehci-hcd (not ehci_hcd!) in initrd changed anything. I will attach the /proc/mount needinfo from my ticket to this one now.
Created attachment 48267 [details] procmount.tar.gz /proc/mounts, /proc/modules and dmesg from SUSE 9.3 and 10.0b3 on same system, the timed dd after putting into initrd and rebooting
ok, I notice both have the sync mount option. Does it work better if you manually mount the partition without sync? have to find a host with a such a problem here.
I suspect sync or not will not help
I have my notebook at home so I cannot test until this evening. I will try to bring it along to work tomorrow for faster turnover of testing.
actually, the sync idea seems the right directiont - mounting manually with defaults did help: ### subfs mount # grep sda1 /proc/mounts /dev/sda1 /media/USBSTICK subfs rw,sync,nosuid,nodev 0 0 /dev/sda1 /media/USBSTICK vfat rw,sync,nodiratime,nosuid,nodev,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,utf8 0 0 # dd if=/dev/zero of=/media/USBSTICK/deleteme bs=1M count=3 3+0 records in 3+0 records out 3145728 bytes (3.1 MB) copied, 123.241 seconds, 25.5 kB/s ### manual mount (mount /dev/sda1 /mnt) # grep sda1 /proc/mounts /dev/sda1 /mnt vfat rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1 0 0 # dd if=/dev/zero of=/mnt/deleteme bs=1M count=3 3+0 records in 3+0 records out 3145728 bytes (3.1 MB) copied, 0.023177 seconds, 136 MB/s
need to get rid of sync, kernel needs a sync_intervall option. perhaps via a sysfs thing like the 'removeable' flag.
Ok, so Kevin has a (very) different problem than James. Can you please split this off so that we don't pollute this bug?
Again: this bug was about an uhci/ehci conflict, and did have nothing to do with sync mounting ....
Pushing back to olaf. If there's a specific problem, please open a report for it, I don't have time to spend ages digging out a specific problem from a 30+ comments.
I mixed that up. Also, asked around here at SuSE, noone else had this issue with high/full speed detection. James, Aaron, did you try the 'safe settings' boot option? Aaron, can you also attach your hwinfo output? Maybe your hardware has something in common.
They were ThinkPads IIRC.
Stefan, do we have a T40p here, can you test the ipod from mmichna?
We've one here, yes. I talked to Timo who has it currently, he will check it today.
*** Bug 100533 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > I mixed that up. > Also, asked around here at SuSE, noone else had this issue with high/full speed > detection. So you did not ask me :) I have this issue - see duplicate entry of bug #100533 - and I have a USB memory stick to reproduce it. Let me know if you want to lend it.
It is not the attached device, but the hostcontroller. provide the hwinfo output from the failing system, I will build a testkernel to see when it broke.
Created attachment 49244 [details] hwinfo of host cohen.suse.de This is the hwinfo output of one of the hosts, where I found the USB error
Created attachment 49245 [details] This is the hwinfo ouput of host belana.suse.de This is the hwinfo output of one of the hosts, where I found the USB error
*** Bug 115858 has been marked as a duplicate of this bug. ***
try the ~olh/bugs/105964/bzImage kernel on belana if you can reproduce it with a 10.0 kernel. add something like this to menu.lst title test kernel (hd0,0)/bzImage panic=42 root=/dev/sda2 sysrq=1 3
assign it back to me once you have tested it.
Sorry, the error still occures with your kernel image. Still the same error messages in the logs.
will test a few kernels on Belana, next week.
Can you try ftp://ftp.suse.com/pub/people/olh/kernel/bug105964/ before I start to build old kernels? Its current 2.6.14.
none of the kernels I tried today works, from 2.6.5 to 2.6.15rc2. They all give err -71 on that usb stick on belana. its not clear what rev your "8i915p Duo" is, there is an update to F7 available http://tw.giga-byte.com/Motherboard/Support/BIOS/BIOS_List.htm 9.3 doesnt work either.
Is James Willcox still on board? If so, can you try the 2.6.14 kernel from the /pub/people dir mentionend above?
I tried that usbstick on a G5, doesnt work there either. It is recognized on a powerbook g4, but ejecting the icon doesnt work. It may work if the hostcontroller is forced into usb1.1 mode by not loading ehci_hcd. After all, that usbstick is a different bug, not fixable by SuSE.
test 10.1 beta4.