Bug 6413

Summary: CompactFlash & Ext2 Mount Problems: Bug Or Feature?
Product: Drivers Reporter: William Ross (newsbeast)
Component: USBAssignee: Greg Kroah-Hartman (greg)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: stern
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.16 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 5089    

Description William Ross 2006-04-19 14:43:07 UTC
Most recent kernel where this bug did not occur: don't know will try a 2.4
series later
Distribution: Slackware 10.2
Hardware Environment: AMD Athlon xp2000 K7S5a Pro Rev 5.0 512M Ram
Software Environment: Gnome 2.12.3 from dropline
Problem Description:

The motherboard provides 4 usb 2.0 ports and 6 usb 1.1 ports, the latter  from
headers on the board. When I attach my Datafab CompactFlash  Reader  to the USB
2.0 ports at he back of the unit everything mounts with out a problem, wether
the format of the  CompactFlash card is ext2-3 or msdos. However if I try to
mount the card on the  1.1 ports with the filesystem type as ext2 or 3,  the 
card will not mount. msdos filesystems will mount fine or either the usb 2.0 or
1.1 ports. Is this a bug or a feature? I know there is really little reason to
even use anything like ext2-3 on a compactflash card, but this is a puzzle all
the same. I fiddled withe the block size. Still no go so far.

I have enforce bandwidth set too.

Steps to reproduce:

format a compactflash card with either ext2 or ext3 filesystem. Try to mount the
card through my 1.1 usb ports. Mount fails, keeps trying though reset errors:
Apr 19 13:38:56 banjo kernel: sda: test WP failed, assume Write Enabled
Apr 19 13:38:56 banjo kernel: sda: assuming drive cache: write through
Apr 19 13:38:56 banjo kernel: sda: test WP failed, assume Write Enabled
Apr 19 13:38:56 banjo kernel: sda: assuming drive cache: write through
Apr 19 13:39:00 banjo kernel: sdb: assuming drive cache: write through
Apr 19 13:39:00 banjo kernel: sdb: assuming drive cache: write through
Apr 19 13:39:04 banjo kernel: end_request: I/O error, dev sda, sector 64
Apr 19 13:39:04 banjo kernel: printk: 129 messages suppressed.
Apr 19 13:39:04 banjo kernel: Buffer I/O error on device sda, logical block 64
Apr 19 13:39:12 banjo kernel: end_request: I/O error, dev sda, sector 65
Apr 19 13:39:12 banjo kernel: Buffer I/O error on device sda, logical block 65
Apr 19 13:39:17 banjo kernel: usb 2-2: device not accepting address 9, error -110
Apr 19 13:39:18 banjo kernel: end_request: I/O error, dev sda, sector 66
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 66
Apr 19 13:39:18 banjo kernel: sd 14:0:0:0: rejecting I/O to device being removed
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 67
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 68
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 69
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 70
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 71
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 72
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 73
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 74
Apr 19 13:39:18 banjo kernel: Buffer I/O error on device sda, logical block 75
Apr 19 13:39:18 banjo kernel:  14:0:0:0: rejecting I/O to dead device
Apr 19 13:39:18 banjo kernel:  14:0:0:0: rejecting I/O to dead device
Apr 19 13:39:26 banjo kernel: sda: test WP failed, assume Write Enabled
Apr 19 13:39:26 banjo kernel: sda: assuming drive cache: write through
Apr 19 13:39:26 banjo kernel: sda: test WP failed, assume Write Enabled
Apr 19 13:39:26 banjo kernel: sda: assuming drive cache: write through
Apr 19 13:39:29 banjo kernel: sdb: assuming drive cache: write through
Apr 19 13:39:29 banjo kernel: sdb: assuming drive cache: write through
Apr 19 13:52:17 banjo kernel:  17:0:0:0: rejecting I/O to dead device

ad infinitum...

Same card will mount on my usb 2.0 port no problems....either ext type fs or
msdos...worth repeating..sorry.

Thanks for looking...

ps: I have yet to find a similar bug related to a similar hardware issue: ie CF
card readers.
please advise
Comment 1 Alan Stern 2006-04-20 07:07:02 UTC
This probably has more to do with the quality of the cables running to the
various ports or the quality of the CF card than with the filesystem type.  Have
you tried the test of using the same card in the reader and attaching the reader
to all the ports?  Do it with the card formatted one way and then do it again
with the same card formatted the other way.  Then try the same thing with a
different card.

Also, how do you know which ports are 1.1 and which are 2.0?
Comment 2 William Ross 2006-04-20 16:18:58 UTC
I eliminated the cables from the equation entirely by plugging the card reader
directly into the port.  Keep in mind the usb 1.1 ports require a cable from the
header to the front panel anyway. And I have confidence  in the quality of the
header cable.

And as for determining which ports are usb 2.0 and usb 1.1, the motherboard
manual gives me this information. As well, when I plug in stuff I can see whats
going on via USB view or something like HAL Device Manager.  And there's always
dmesg or  tail -f messages & co. I have tried the card reader on every port with
 other devices present, and as the ONLY device  plugged in and still the  USB
1.1 ports from the  pin headers will not  mount a CF card, as long as it is
formatted with ext2 & co filesystem(s). msdos mounts just fine on ANY of my ports.

Why would a bad cable prevent one type of filesystem from mounting, yet allow
another to mount  just fine? Could it a Microsoft Conspiracy  ;)
Comment 3 William Ross 2006-04-20 19:18:15 UTC
Update:

Kernel 2.4.32 works fine. It is understood that udev does not play a role  in
kernel 2.4.32. I also disabled hal and dbus while running 2.4.32 and the CF card
Still mounted fine on ANY usb port here. Switched the  CF reader between ports a
dozen times within a session too. And again in an  isolated and mixed usb
peripheral setting. Works.

I  disabled hal and dbus while running  a  2.6.16.9 kernel. No difference. Still
 will only mount on the 2.0 ports. Of course the CF reader still appears as a
usb 1.1 device on a 1.1 UHCI port.

Note the CF reader Needs the uhci  driver to be present. Otherwise it will NOT
mount on Any Port. 

I still might have missed out on some config variable between kernel versions,
but I can't see any so far. The glaring difference between the kernels is the
lack of udev in the 2.4.32 series. Might the problem lie therein? 

I also have the same issues with Ubuntu 5.10 live edition which features a late
2.6x series kernel and obviously  not myconfig either. Just my hardware.

If anyone running a similar hardware and kernel setup who does not have this
problem please chime in.
Comment 4 Alan Stern 2006-04-21 07:14:03 UTC
Some of the things you say don't make sense.  First of all, the card reader
can't switch between being a 1.1 or a 2.0 device depending on the port it's
attached to.  Either it is 1.1 or else it is 2.0, period.  And for our purposes,
it doesn't matter anyway.

Secondly, it doesn't really mean anything to say that a port is 1.1 or 2.0. 
It's much better to be explicit and say what you actually mean.  What types of
USB host controllers is the port connected to?  That's what does matter.

It's all well and good for you to have USBview or HAL device manager or dmesg,
but you haven't provided any of that information in the bug report.  You haven't
even provided the contents of /proc/bus/usb/devices with the reader plugged into
various ports (hint).

The best way to diagnose the problem will be for you to turn on USB verbose
debugging and USB Mass Storage verbose debugging in the kernel configuration
(CONFIG_USB_DEBUG and CONFIG_USB_STORAGE_DEBUG) and rebuild the 2.6 kernel. 
Then send the dmesg log showing what happens when you plug in the reader with an
ext2-formatted card inserted.  Do this for both types of port, so we can see
what a success looks like as well as a failure.  For thoroughness, also do it
for a FAT-formatted card in a "1.1" port.

Comment 5 Greg Kroah-Hartman 2006-08-30 00:55:09 UTC
Closing due to inactivity.  If this is still an issue, please reopen with the
requested information.