Bug 105964

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.