2.6: USB disk unusable level of data corruption

2.6: USB disk unusable level of data corruption

[Rusty Russell]

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

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[David Brownell]

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

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[Alan Stern]

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

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[David Brownell]

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

Re: 2.6: USB disk unusable level of data corruption

[Pete Zaitcev]

On Fri, 04 Feb 2005 23:16:22 +1100, Rusty Russell <rusty@rustcorp.com.au> 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

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[John Stoffel]

>> 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

Re: 2.6: USB disk unusable level of data corruption

[Parag Warudkar]

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 <rusty@rustcorp.com.au> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6: USB disk unusable level of data corruption

[Greg KH]

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

Re: 2.6: USB disk unusable level of data corruption

[Parag Warudkar]

> 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

Re: 2.6: USB disk unusable level of data corruption

[Greg KH]

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

2.6: USB Storage hangs machine on bootup for ~2 minutes

[Parag Warudkar]

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

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[Giuseppe Bilotta]

John Stoffel wrote:
> 
> 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.

I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I 
found that it works pretty fine (albeit slowly) when connected 
to the USB 1.1 ports built in my Dell Inspiron 8200, but trying 
to connect it via the Hamlet PCMCIA USB2 Card Adapter doesn't 
work (it seems it gets assigned minors 1,2,3,4,5,6,... and so 
on forever until I unplug it).

OTOH, I'm not sure if it's a PCMCIA adapter problem or USB2 
enclosure problem. Indeed, if I don't load the EHCI modules, 
and thus limit myself to the USB1.1 capabilities of the PCMCIA 
adapters, I get other errors (I'll have to write a cleaner bug 
report on this. And try the PCMCIA card with some other USB 
device. Wish I could use my softmodem under Linux :(). (Using 
kernel 2.6.10-3 from Debian.)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[Rusty Russell]

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

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[David Brownell]

On Sunday 06 February 2005 7:59 am, Giuseppe Bilotta wrote:
> 
> I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I 
> found that it works pretty fine (albeit slowly) when connected 
> to the USB 1.1 ports built in my Dell Inspiron 8200, but trying 
> to connect it via the Hamlet PCMCIA USB2 Card Adapter doesn't 
> work (it seems it gets assigned minors 1,2,3,4,5,6,... and so 
> on forever until I unplug it).

What do you mean "minors"?  Addresses or actual /dev/sdN numbers?

If it's addresses, that would be an an enumeration problem.  Some
recent changes have caused prolems there, 2.6.11-rc3-mm2 ought to
have a patch making it better.  (Well, working around one of the
two problems that'd suggest.)

If it's actual /dev/sdN numbers, that would seem to be an issue
more at the level of usb-storage.  Quite possibly related to the
bugs you didn't exactly detail (below).

- Dave


> OTOH, I'm not sure if it's a PCMCIA adapter problem or USB2 
> enclosure problem. Indeed, if I don't load the EHCI modules, 
> and thus limit myself to the USB1.1 capabilities of the PCMCIA 
> adapters, I get other errors (I'll have to write a cleaner bug 
> report on this. And try the PCMCIA card with some other USB 
> device. Wish I could use my softmodem under Linux :(). (Using 
> kernel 2.6.10-3 from Debian.)

 

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[David Brownell]

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 www.macpower.com.tw/produts/hdd2/daisycutter/dc_usb2
maybe?  The 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
> 

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[Rusty Russell]

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 www.macpower.com.tw/produts/hdd2/daisycutter/dc_usb2
> maybe?  The 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

Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption

[Giuseppe Bilotta]

David Brownell wrote:
> On Sunday 06 February 2005 7:59 am, Giuseppe Bilotta wrote:
> > 
> > I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I 
> > found that it works pretty fine (albeit slowly) when connected 
> > to the USB 1.1 ports built in my Dell Inspiron 8200, but trying 
> > to connect it via the Hamlet PCMCIA USB2 Card Adapter doesn't 
> > work (it seems it gets assigned minors 1,2,3,4,5,6,... and so 
> > on forever until I unplug it).
> 
> What do you mean "minors"?  Addresses or actual /dev/sdN numbers?
> 
> If it's addresses, that would be an an enumeration problem.  Some
> recent changes have caused prolems there, 2.6.11-rc3-mm2 ought to
> have a patch making it better.  (Well, working around one of the
> two problems that'd suggest.)

Sorry, it's addresses.

usb 5-1: new high speed USB device using ehci_hcd and address 4
usb 5-1: new high speed USB device using ehci_hcd and address 5
usb 5-1: new high speed USB device using ehci_hcd and address 6

blah blah blah, neverending. So yes, it's probably the 
enumeration problem.

Also, when I plug in the PCMCIA card I get (sorry for the 
wrapping, Gravity sucks)

PCI: Enabling device 0000:07:00.0 (0000 -> 0002)
ACPI: PCI interrupt 0000:07:00.0[A] -> GSI 11 (level, low) -> 
IRQ 11
ohci_hcd 0000:07:00.0: NEC Corporation USB
PCI: Setting latency timer of device 0000:07:00.0 to 64
ohci_hcd 0000:07:00.0: irq 11, pci mem 0x29000000
ohci_hcd 0000:07:00.0: new USB bus registered, assigned bus 
number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
PCI: Enabling device 0000:07:00.1 (0000 -> 0002)
ACPI: PCI interrupt 0000:07:00.1[B] -> GSI 11 (level, low) -> 
IRQ 11
ohci_hcd 0000:07:00.1: NEC Corporation USB (#2)
PCI: Setting latency timer of device 0000:07:00.1 to 64
ohci_hcd 0000:07:00.1: irq 11, pci mem 0x29001000
ohci_hcd 0000:07:00.1: new USB bus registered, assigned bus 
number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
PCI: Enabling device 0000:07:00.2 (0000 -> 0002)
ACPI: PCI interrupt 0000:07:00.2[C] -> GSI 11 (level, low) -> 
IRQ 11
ehci_hcd 0000:07:00.2: NEC Corporation USB 2.0
ehci_hcd 0000:07:00.2: irq 11, pci mem 0x29002000
ehci_hcd 0000:07:00.2: new USB bus registered, assigned bus 
number 5
ehci_hcd 0000:07:00.2: USB 2.0 initialized, EHCI 0.95, driver 
26 Oct 2004
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 5 ports detected 

The card only has 2 USB ports .. why 5 ports here? Is this the 
same bug?

Another interesting tidbit is that I get:

USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> 
IRQ 11
uhci_hcd 0000:00:1d.0: Intel Corp. 82801CA/CAM USB (Hub #1)
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 11, io base 0xbf80
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus 
number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 11 (level, low) -> 
IRQ 11
uhci_hcd 0000:00:1d.2: Intel Corp. 82801CA/CAM USB (Hub #3)
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 11, io base 0xbf20
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus 
number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected 

for the built-in ports ... I only have two USB ports on this 
machine though, why does it see 4 of them?

(Do you also need the lspci and/or lsusb and/or dmesg of the 
error that happens when I disable the EHCI driver and only let 
the OHCI manage the PCMCIA card?)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)