Prev: Wake On Lan from ACPI state G3?
Next: Die Gier (haben, haben) ist greosser
From: Jordan Hazen on 14 Jul 2008 17:51
I'm having trouble with spontaneous port resets during heavy write
operations to usb-storage devices, on an old IBM Thinkpad 240 laptop
that supports only USB 1.1 (UHCI, Intel chipset). Kernel is 2.6.24
w/PREEMPT.

So long as the only USB device attached is the thumb drive or hard
drive, everything works OK (albeit slowly, as expected with a 1.1
bus).

But, if any other device is actively sharing the USB bus, sustained
writes will cause the storage device's port to reset within 5-10
minutes, resulting in a failed write operation. Unmounting, then
rmmod'ing and reloading the usb-storage module brings it back to
"normal" (absent sustained writes) without having to physically unplug
anything. Other USB targets, on the same bus & hub continue working
OK throughout.

*Reading* files from usb-storage never seems to trigger this, no
matter how much is read, or how active other USB targets might be.

The laptop has only a single USB port, necessitating the use of a hub,
but I've tried swapping out the hub with several others, and that
makes no difference.

I thought at first the bus-powered 2.5" hard drive might not be
getting enough power, but a different model, with its own AC adapter
fails in the same way, as do three different brands of USB flash-key.

Choice of filesystem (ext2, ext3, fat16/vfat) also makes no
difference.

I tried turning max_sectors down from 240 to 32, as suggested in some
other threads involving mostly USB 2.0 glitches:

echo 32 >/sys/block/sda/device/max_sectors

but that didn't help.

Other devices sharing the bus include a USB serial port, Dallas 1-wire
controller, and a Sanyo cellphone, all of which identify as "full
speed" 12Mb/s targets. None come anywhere close to hogging the bus,
at only 5-6 transactions per minute per device.

lsusb:
Bus 001 Device 055: ID 04cf:8818 Myson Century, Inc.
Bus 001 Device 053: ID 0474:0701 Sanyo Electric Co., Ltd
Bus 001 Device 052: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Bus 001 Device 051: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 050: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 001 Device 001: ID 0000:0000

dmesg after the fault:
usb 1-1.1: new full speed USB device using uhci_hcd and address 55
usb 1-1.1: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi13 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 55
usb-storage: waiting for device to settle before scanning
scsi 13:0:0:0: Direct-Access IC25N040 ATMR04-0 MO2O PQ: 0
ANSI: 0 CC
S
sd 13:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB)
sd 13:0:0:0: [sda] Write Protect is off
sd 13:0:0:0: [sda] Mode Sense: 00 14 00 00
sd 13:0:0:0: [sda] Assuming drive cache: write through
sd 13:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB)
sd 13:0:0:0: [sda] Write Protect is off
sd 13:0:0:0: [sda] Mode Sense: 00 14 00 00
sd 13:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 13:0:0:0: [sda] Attached SCSI disk
usb-storage: device scan complete
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: mounting fs with errors, running e2fsck is
recommended
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
usb 1-1.1: reset full speed USB device using uhci_hcd and address 55
usb 1-1.1: reset full speed USB device using uhci_hcd and address 55
usb 1-1.1: reset full speed USB device using uhci_hcd and address 55
usb 1-1.1: reset full speed USB device using uhci_hcd and address 55
usb 1-1.1: reset full speed USB device using uhci_hcd and address 55
usb 1-1.1: reset full speed USB device using uhci_hcd and address 55
usb 1-1.1: reset full speed USB device using uhci_hcd and address 55
sd 13:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 1200023
printk: 20 messages suppressed.
Buffer I/O error on device sda1, logical block 149995
lost page write due to I/O error on sda1
Buffer I/O error on device sda1, logical block 149996
lost page write due to I/O error on sda1
Buffer I/O error on device sda1, logical block 149997
lost page write due to I/O error on sda1
Buffer I/O error on device sda1, logical block 149998
lost page write due to I/O error on sda1
Buffer I/O error on device sda1, logical block 149999
lost page write due to I/O error on sda1
Buffer I/O error on device sda1, logical block 150000
[etc ..]

That happened within 3 minutes of starting a 200MB file copy on a a
2.5" HD. Doing the same with a flash key formatted as FAT16, errors
are the same, except there are fewer reset & I/O error messages (only
2 at a time).


Apart from max_sectors, are there any config "knobs" I might adjust
that could help with this sort of problem? Perhaps some transaction
timeout that needs to be increased? Performance doesn't matter much
in this application, so long as the storage device can keep up with
about 500 KByte/s in sustained writes.

The same set of devices was working on another machine, also on a UHCI
1.1 bus, but that host had a VIA chipset rather than Intel, and was
running a 2.6.16 kernel without preemption.

Might PREEMPT be the culprit? Worth compiling a kernel without?

Any suggestions would be much appreciated.
--
Jordan.
 | 
Pages: 1
Prev: Wake On Lan from ACPI state G3?
Next: Die Gier (haben, haben) ist greosser