OK, I recently made the mistake of buying a USB case with a drive in it
and putting my home directory on it. I have since then had multiple
ext3 and ext2 errors: 2.6.8, 2.6.9, 2.6.10 and 2.6.11-rc3 all exhibit
the problem within an hour of stress (untarring a fresh kernel tree, cp
-al'ing to apply patches repeatedly, my normal workload). I haven't had
any similar problems on my internal IDE drive. 2.4 succeeded once, and
once had data corruption (although nowhere near as as bad as the 2.6
corruption, and it got much further).
I realize "ub" exists, but it doesn't seem to want to deal with a disk
device.
Is USB/SCSI just terminally broken under 2.6? I'll be getting a power
supply to test the drive using firewire, which it also supports, to
ensure this isn't a disk issue (although the 2.4 goodness undermines
this theory).
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
usb 2-1: USB disconnect, address 2
usb 4-3: new high speed USB device using address 2
scsi1 : SCSI emulation for USB Mass Storage devices
Vendor: HTS72606 Model: 0M9AT00 Rev: MH4O
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
sda: assuming drive cache: write through
/dev/scsi/host1/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 >
Attached scsi disk sda at scsi1, channel 0, id 0, lun 0
USB Mass Storage device found at 2
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
On Friday 04 February 2005 4:16 am, Rusty Russell wrote:
>
> Is USB/SCSI just terminally broken under 2.6?
I don't think so, but there are problems that appear in some
hardware configs and not others. Many folk report no problems;
a (very) few report nothing but.
If you've verified this on 2.6.10, then you certainly have
have the ehci-hcd (re)queueing race fix that has made a big
difference for some folk. I don't know of any other issues
in that driver that could explain usb-storage problems.
What hardware config do you have?
- Whose EHCI controller and revision? I've never had
good luck with VIA VT6202. ("lspci -v".)
- Whose USB storage adapter? ("lsusb -v", or in this
case the /proc/bus/usb/devices entry would be ok.)
GeneSys adapters have been the most problematic,
but they're hardly the only ones with quirks.
Thing is, that driver stack isn't especially thin: SCSI isn't
the top, and it's got usb-storage, usbcore, and a USB HCD under
it. That makes it harder to track down root causes, even when
there is just a single one and it's in those drivers (rather
than being hardware misbehavior).
- Dave
On Fri, 4 Feb 2005, Rusty Russell wrote:
> OK, I recently made the mistake of buying a USB case with a drive in it
> and putting my home directory on it. I have since then had multiple
> ext3 and ext2 errors: 2.6.8, 2.6.9, 2.6.10 and 2.6.11-rc3 all exhibit
> the problem within an hour of stress (untarring a fresh kernel tree, cp
> -al'ing to apply patches repeatedly, my normal workload). I haven't had
> any similar problems on my internal IDE drive. 2.4 succeeded once, and
> once had data corruption (although nowhere near as as bad as the 2.6
> corruption, and it got much further).
>
> I realize "ub" exists, but it doesn't seem to want to deal with a disk
> device.
>
> Is USB/SCSI just terminally broken under 2.6? I'll be getting a power
> supply to test the drive using firewire, which it also supports, to
> ensure this isn't a disk issue (although the 2.4 goodness undermines
> this theory).
Right now we have no reason to believe there's anything wrong with the USB
stack or the usb-storage/SCSI drivers. A few other people have also
reported data corruption at about the same level as you; we've only been
able to trace a couple of them to software errors. And those generally
involved a higher error rate than you're seeing.
The most likely explanation seems to be hardware problems. Particularly
for high-speed USB devices, 2.6 drives the hardware much closer to the
limit than 2.4 or Windows (to judge by the problem reports we've seen).
One case came up just a couple of days ago, in which this sort of data
corruption was definitively traced to a known erratum in the peripheral's
USB interface. (The controller chip was an old revision which has been
supplanted, but who knows what sort of hardware lurks in the hearts of
commercial drives?)
Alan Stern
On Fri, 04 Feb 2005 23:16:22 +1100, Rusty Russell <[email protected]> wrote:
> [...] I have since then had multiple
> ext3 and ext2 errors: 2.6.8, 2.6.9, 2.6.10 and 2.6.11-rc3 all exhibit
> the problem within an hour of stress (untarring a fresh kernel tree, cp
> -al'ing to apply patches repeatedly, my normal workload).
> I realize "ub" exists, but it doesn't seem to want to deal with a disk
> device.
In case your EHCI disconnects devices under load, ub won't help.
You probably heard my claims that ub helps against certain memory
pressure related lockups and against problems in the SCSI stack,
which my even be true. Jury is still out on those and your case
seems different anyway. Please work with David Brownell on the EHCI
issues. I applied a few patches of his to the 2.4 which made a difference
in similar circumstances.
Good luck,
-- Pete
On Friday 04 February 2005 12:55 pm, Alan Stern wrote:
>
> The most likely explanation seems to be hardware problems. Particularly
> for high-speed USB devices, 2.6 drives the hardware much closer to the
> limit than 2.4 or Windows (to judge by the problem reports we've seen).
Agreed ... though limiting usb-storage I/O requests to 64 KB does tend to
mask that difference. Some network adapters get better throughput than
Windows, too. URB queueing does the trick ... not really usable on 2.4
kernels, but the costs on 2.6 seem substantially lower than on Windows.
> One case came up just a couple of days ago, in which this sort of data
> corruption was definitively traced to a known erratum in the peripheral's
> USB interface. (The controller chip was an old revision which has been
> supplanted, but who knows what sort of hardware lurks in the hearts of
> commercial drives?)
If you're thinking of that net2280 issue, that erratum was specific
to full speed modes, and never appeared at high speed. Also, that chip
wouldn't be used in mass market IDE adapters. (Too pricey compared to
the custom chips that have no need for a CPU or PCI.)
But the point is good: it's easy for hardware to have bugs there.
- Dave
>> Is USB/SCSI just terminally broken under 2.6?
David> I don't think so, but there are problems that appear in some
David> hardware configs and not others. Many folk report no problems;
David> a (very) few report nothing but.
This is just a chime in to let people know others are seeing problems
with USB/SCSI external enclosures.
I haven't tried lately, but my USB/FireWire enclosure never worked
with Linux (or WinNT under firewire, sigh...) so I haven't touched it
in months. Money down the drain.
David> If you've verified this on 2.6.10, then you certainly have have
David> the ehci-hcd (re)queueing race fix that has made a big
David> difference for some folk. I don't know of any other issues in
David> that driver that could explain usb-storage problems.
I should try it again and see how it works under USB/Firewire, my last
attempts were under 2.6.[78] or so time frame.
John
I don't know if it's related, but -
I have been using Maxtor OneTouch USB Drive,so far without problems, but
today after upgrading to FC3 2.6.10-760 kernel I just recieved this in
dmesg
usb 1-1: USB disconnect, address 2
scsi0 (0:0): rejecting I/O to device being removed
scsi0 (0:0): rejecting I/O to device being removed
Buffer I/O error on device sda2, logical block 6352
lost page write due to I/O error on sda2
Aborting journal on device sda2.
journal commit I/O error
scsi0 (0:0): rejecting I/O to device being removed
Buffer I/O error on device sda2, logical block 15859714
lost page write due to I/O error on sda2
ext3_abort called.
EXT3-fs error (device sda2): ext3_journal_start_sb: Detected aborted
journal
Remounting filesystem read-only
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
usb 1-1: new high speed USB device using ehci_hcd and address 5
usb 1-1: device descriptor read/64, error -71
scsi2 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
Vendor: Maxtor Model: OneTouch Rev: 0201
Type: Direct-Access ANSI SCSI revision: 00
SCSI device sdc: 398295040 512-byte hdwr sectors (203927 MB)
sdc: assuming drive cache: write through
SCSI device sdc: 398295040 512-byte hdwr sectors (203927 MB)
sdc: assuming drive cache: write through
sdc: sdc1 sdc2
Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0
usb-storage: device scan complete
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
scsi0 (0:0): rejecting I/O to dead device
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is
recommended
EXT3 FS on sdc2, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
warning: many lost ticks.
Your time source seems to be instable or some driver is hogging
interupts
rip acpi_processor_idle+0x10e/0x274
usb 1-1: USB disconnect, address 5
scsi2 (0:0): rejecting I/O to dead device
Buffer I/O error on device sdc2, logical block 0
lost page write due to I/O error on sdc2
usb 1-1: new high speed USB device using ehci_hcd and address 6
usb 1-1: device descriptor read/64, error -71
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 6
EXT3 FS on sdc2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
scsi0 (0:0): rejecting I/O to dead device
EXT3-fs error (device sda2): ext3_readdir: directory #6783511 contains a
hole at offset 0
scsi0 (0:0): rejecting I/O to dead device
EXT3-fs error (device sda2): ext3_readdir: directory #6783511 contains a
hole at offset 0
On Fri, 2005-02-04 at 13:37 -0800, Pete Zaitcev wrote:
> On Fri, 04 Feb 2005 23:16:22 +1100, Rusty Russell <[email protected]> wrote:
>
> > [...] I have since then had multiple
> > ext3 and ext2 errors: 2.6.8, 2.6.9, 2.6.10 and 2.6.11-rc3 all exhibit
> > the problem within an hour of stress (untarring a fresh kernel tree, cp
> > -al'ing to apply patches repeatedly, my normal workload).
>
> > I realize "ub" exists, but it doesn't seem to want to deal with a disk
> > device.
>
> In case your EHCI disconnects devices under load, ub won't help.
> You probably heard my claims that ub helps against certain memory
> pressure related lockups and against problems in the SCSI stack,
> which my even be true. Jury is still out on those and your case
> seems different anyway. Please work with David Brownell on the EHCI
> issues. I applied a few patches of his to the 2.4 which made a difference
> in similar circumstances.
>
> Good luck,
> -- Pete
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Fri, Feb 04, 2005 at 07:40:13PM -0500, Parag Warudkar wrote:
> I don't know if it's related, but -
> I have been using Maxtor OneTouch USB Drive,so far without problems, but
> today after upgrading to FC3 2.6.10-760 kernel I just recieved this in
> dmesg
Does 2.6.11-rc3 have this same issue?
thanks,
greg k-h
> Does 2.6.11-rc3 have this same issue?
>
> thanks,
>
> greg k-h
I just compiled 2.6.11-rc3 booted and then again did a kernel compile on
the USB disk - no problems.
With FC 2.6.10 kernel I am able to reproduce the problem within no time
- seems something is seriously broken in FC3 latest kernel.
Parag
On Fri, Feb 04, 2005 at 09:30:45PM -0500, Parag Warudkar wrote:
>
> > Does 2.6.11-rc3 have this same issue?
> >
> > thanks,
> >
> > greg k-h
>
> I just compiled 2.6.11-rc3 booted and then again did a kernel compile on
> the USB disk - no problems.
Great!
> With FC 2.6.10 kernel I am able to reproduce the problem within no time
> - seems something is seriously broken in FC3 latest kernel.
Go file a bug in the redhat bugzilla :)
Good luck,
greg k-h
I am running FC3 on a AMD64 laptop. The laptop has 3 USB ports. If I
attach any usb-storage device (Sandisk Cruiser usb drive, iPod, Maxtor
external drive etc.) the kernel hangs while booting. The hang occurs
shortly after the usb-storage module is loaded. The machine does not
respond to anything other than the power button. This hang lasts for
about 2 minutes after which boot resumes and goes on fine.
When it is hung, the usb storage devices are not being accessed - the
iPOD for e.g does not show the Do not Disconnect sign when it is hung -
it shows that after the boot resumes. Might have something to do with
the recent "Waiting for device to settle" change in usb-storage?
A
The boot goes on without a hang if there are no usb-storage devices
attached to the system. (USB mouse is fine for example, so the hang
happens only in case of usb-storage devices.)
PS - This bug was also reported to Redhat Bugzilla some time ago - I
haven't got any feedback so far.
Parag
On Fri, 2005-02-04 at 12:41 -0800, David Brownell wrote:
> On Friday 04 February 2005 4:16 am, Rusty Russell wrote:
> >
> > Is USB/SCSI just terminally broken under 2.6?
>
> I don't think so, but there are problems that appear in some
> hardware configs and not others. Many folk report no problems;
> a (very) few report nothing but.
>
> If you've verified this on 2.6.10, then you certainly have
> have the ehci-hcd (re)queueing race fix that has made a big
> difference for some folk. I don't know of any other issues
> in that driver that could explain usb-storage problems.
>
> What hardware config do you have?
>
> - Whose EHCI controller and revision? I've never had
> good luck with VIA VT6202. ("lspci -v".)
OK, it's an IBM Thinkpad X31:
0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI
Controller (rev 01) (prog-if 20 [EHCI])
Subsystem: IBM: Unknown device 052e
Flags: bus master, medium devsel, latency 0, IRQ 11
Memory at c0000000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #0a [2080]
Kernel messages when plugged in:
usb 4-3: new high speed USB device using address 5
scsi3 : SCSI emulation for USB Mass Storage devices
Vendor: HTS72606 Model: 0M9AT00 Rev: MH4O
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
sda: assuming drive cache: write through
/dev/scsi/host3/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 >
Attached scsi disk sda at scsi3, channel 0, id 0, lun 0
USB Mass Storage device found at 5
> - Whose USB storage adapter? ("lsusb -v", or in this
> case the /proc/bus/usb/devices entry would be ok.)
> GeneSys adapters have been the most problematic,
> but they're hardly the only ones with quirks.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0dc4 Macpower Peripherals, Ltd
idProduct 0x00c4
bcdDevice 0.02
iManufacturer 1 Macpower
iProduct 2 2.5HDD
iSerial 3 8000D1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 Myson 8818
bmAttributes 0xc0
Self Powered
MaxPower 10mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 5 SFF-8070i
bInterfaceProtocol 80
iInterface 5 USB2.0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
> Thing is, that driver stack isn't especially thin: SCSI isn't
> the top, and it's got usb-storage, usbcore, and a USB HCD under
> it. That makes it harder to track down root causes, even when
> there is just a single one and it's in those drivers (rather
> than being hardware misbehavior).
I have some spare partitions on the disk, so I've written a program
which writes using DIRECT_IO and verifies the results. It took less
than an hour under my filesystem load, so I'll see if I can get this to
trigger it (currently N children writing to separate blocks, but if that
doesn't trigger it I'll get more sophisticated with readers and
writers).
Thanks for the response,
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
On Sunday 06 February 2005 6:55 pm, Rusty Russell wrote:
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x0dc4 Macpower Peripherals, Ltd
> idProduct 0x00c4
> bcdDevice 0.02
> iManufacturer 1 Macpower
> iProduct 2 2.5HDD
> iSerial 3 8000D1
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 32
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 4 Myson 8818
Not one I'd be familiar with, but that doesn't mean anything.
And I didn't see an "unusual_devs.h" entry for it, but it does
look to need the CONFIG_USB_STORAGE_HP8200e support, which I
see is labeled "experimental". I don't know how solid the
support for that is. But I see Greg's checked in a big patch
against the file with that driver, which should make the next
MM patchset against 2.6.11-rc3 ... mostly to support some
new hardware, but with that many changes I suspect there'll
be some bugfixes too.
This would be http://www.macpower.com.tw/produts/hdd2/daisycutter/dc_usb2
maybe? The http://www.qbik.ch/usb/devices database has a report from one
user saying they had problems with a different MacPower adapter until
they fixed its jumpers. Also worth a check.
- Dave
> bmAttributes 0xc0
> Self Powered
> MaxPower 10mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 5 SFF-8070i
> bInterfaceProtocol 80
> iInterface 5 USB2.0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Device Qualifier (for other device speed):
> bLength 10
> bDescriptorType 6
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> bNumConfigurations 1
>
On Sun, 2005-02-06 at 21:15 -0800, David Brownell wrote:
> And I didn't see an "unusual_devs.h" entry for it, but it does
> look to need the CONFIG_USB_STORAGE_HP8200e support, which I
> see is labeled "experimental". I don't know how solid the
> support for that is. But I see Greg's checked in a big patch
> against the file with that driver, which should make the next
> MM patchset against 2.6.11-rc3 ... mostly to support some
> new hardware, but with that many changes I suspect there'll
> be some bugfixes too.
OK, I'll check once that comes through, thanks.
> This would be http://www.macpower.com.tw/produts/hdd2/daisycutter/dc_usb2
> maybe? The http://www.qbik.ch/usb/devices database has a report from one
> user saying they had problems with a different MacPower adapter until
> they fixed its jumpers. Also worth a check.
Actually, it's
http://www.macpower.com.tw/products/hdd2/clearlight/cl_400plus
I didn't put the drive in myself, but I'll unscrew it and check the
jumpers.
A simple DIRECT_IO 4096-byte read-write on the block device does reveal
corruption after an hour or so, so I should be able to track this down.
Might move my home dir back off it for a while though 8)
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman