Kernel unable to read partition table on USB Memory Key

Kernel unable to read partition table on USB Memory Key

[Roberts-Thomson, James]

Hi,

I'm trying to diagnose an issue with a USB "Memory Key" (128Mb Flash drive)
on my workstation (i386 Linux 2.6.12 kernel, using udev 058).

When connecting the key, the kernel fails to read the partition table, and
therefore the block device /dev/sda1 isn't created, so I can't mount the
volume.  Calling "fdisk" manually, however, makes it all work.

When I plug the device into the USB port, the kernel prints the following:

Jul  5 16:18:38 pc196344 kernel: usb 1-6: new high speed USB device using
ehci_hcd and address 3
Jul  5 16:18:39 pc196344 kernel: Initializing USB Mass Storage driver...
Jul  5 16:18:39 pc196344 kernel: scsi2 : SCSI emulation for USB Mass Storage
devices
Jul  5 16:18:39 pc196344 kernel: usbcore: registered new driver usb-storage
Jul  5 16:18:39 pc196344 kernel: USB Mass Storage support registered.
Jul  5 16:18:39 pc196344 kernel: usb-storage: device found at 3
Jul  5 16:18:39 pc196344 kernel: usb-storage: waiting for device to settle
before scanning
Jul  5 16:18:44 pc196344 kernel:   Vendor: OTi       Model: Flash Disk
Rev: 2.00
Jul  5 16:18:44 pc196344 kernel:   Type:   Direct-Access
ANSI SCSI revision: 02
Jul  5 16:18:44 pc196344 kernel: Attached scsi generic sg1 at scsi2, channel
0, id 0, lun 0,  type 0
Jul  5 16:18:44 pc196344 kernel: usb-storage: device scan complete
Jul  5 16:18:44 pc196344 scsi.agent[12708]: disk at
/devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/host2/target2:0:0/2:0:0:0
Jul  5 16:18:44 pc196344 kernel: sda: Unit Not Ready, sense:
Jul  5 16:18:44 pc196344 kernel: : Current: sense key: Unit Attention
Jul  5 16:18:44 pc196344 kernel:     Additional sense: Not ready to ready
change, medium may have changed
Jul  5 16:18:44 pc196344 kernel: sda : READ CAPACITY failed.
Jul  5 16:18:44 pc196344 kernel: sda : status=1, message=00, host=0,
driver=08
Jul  5 16:18:44 pc196344 kernel: sd: Current: sense key: Unit Attention
Jul  5 16:18:44 pc196344 kernel:     Additional sense: Not ready to ready
change, medium may have changed
Jul  5 16:18:44 pc196344 kernel: sda: test WP failed, assume Write Enabled
Jul  5 16:18:44 pc196344 kernel: sda: assuming drive cache: write through
Jul  5 16:18:44 pc196344 kernel: sda: Unit Not Ready, sense:
Jul  5 16:18:44 pc196344 kernel: : Current: sense key: Unit Attention
Jul  5 16:18:44 pc196344 kernel:     Additional sense: Not ready to ready
change, medium may have changed
Jul  5 16:18:44 pc196344 kernel: sda : READ CAPACITY failed.
Jul  5 16:18:44 pc196344 kernel: sda : status=1, message=00, host=0,
driver=08
Jul  5 16:18:44 pc196344 kernel: sd: Current: sense key: Unit Attention
Jul  5 16:18:44 pc196344 kernel:     Additional sense: Not ready to ready
change, medium may have changed
Jul  5 16:18:44 pc196344 kernel: sda: test WP failed, assume Write Enabled
Jul  5 16:18:44 pc196344 kernel: sda: assuming drive cache: write through
Jul  5 16:18:44 pc196344 kernel: sda: Unit Not Ready, sense:
Jul  5 16:18:44 pc196344 kernel: : Current: sense key: Unit Attention
Jul  5 16:18:44 pc196344 kernel:     Additional sense: Not ready to ready
change, medium may have changed
Jul  5 16:18:44 pc196344 kernel: sda : READ CAPACITY failed.
Jul  5 16:18:44 pc196344 kernel: sda : status=1, message=00, host=0,
driver=08
Jul  5 16:18:44 pc196344 kernel: sd: Current: sense key: Unit Attention
Jul  5 16:18:44 pc196344 kernel:     Additional sense: Not ready to ready
change, medium may have changed
Jul  5 16:18:44 pc196344 kernel: sda: test WP failed, assume Write Enabled
Jul  5 16:18:44 pc196344 kernel: sda: assuming drive cache: write through
Jul  5 16:18:44 pc196344 kernel:
/dev/scsi/host2/bus0/target0/lun0:end_request: I/O error, dev sda, sector 0
Jul  5 16:18:44 pc196344 kernel: Buffer I/O error on device sda, logical
block 0
Jul  5 16:18:44 pc196344 kernel: Buffer I/O error on device sda, logical
block 0
Jul  5 16:18:44 pc196344 kernel:  unable to read partition table
Jul  5 16:18:44 pc196344 kernel: Attached scsi removable disk sda at scsi2,
channel 0, id 0, lun 0

Clearly, something isn't right here, and the kernel is unable to read block
0 (the parition table).  I've tried using the "delay_use" parameter to the
usb-storage module to increase the delay time to 10 seconds, but still no
difference.

If I run "fdisk /dev/sda" however, then the kernel realises there is a
partition table and it all just works, thus:

Jul  5 16:24:27 pc196344 sudo:  james : TTY=pts/1 ;
PWD=/usr/src/linux-2.6.12-jrt1 ; USER=root ; COMMAND=/sbin/fdisk /dev/sda
Jul  5 16:24:27 pc196344 kernel: SCSI device sda: 255488 512-byte hdwr
sectors (131 MB)
Jul  5 16:24:27 pc196344 kernel: sda: Write Protect is off
Jul  5 16:24:27 pc196344 kernel: sda: Mode Sense: 03 00 00 00
Jul  5 16:24:27 pc196344 kernel: sda: assuming drive cache: write through
Jul  5 16:24:27 pc196344 kernel: SCSI device sda: 255488 512-byte hdwr
sectors (131 MB)
Jul  5 16:24:27 pc196344 kernel: sda: Write Protect is off
Jul  5 16:24:27 pc196344 kernel: sda: Mode Sense: 03 00 00 00
Jul  5 16:24:27 pc196344 kernel: sda: assuming drive cache: write through
Jul  5 16:24:27 pc196344 kernel:  /dev/scsi/host2/bus0/target0/lun0: p1

In the case above, I'd not done anything inside fdisk apart from "q" to
exit.  

However, I have tried reparitioning the device; using "dd if=/dev/zero
of=/dev/sda bs=512 count=1" to zero the partition table and recreate;
returning the device to the vendor and getting another one - no difference
at all.

The key itself is a NZ vendor "own-name" rebadge, made in Taiwan.  According
to the vendor's (Dick Smith Electronics, if anyone is interested) website,
<http://www.dse.co.nz/cgi-bin/dse.storefront/42ca0f440021d23e273fc0a87f9906a
8/Product/View/XH8250> the product is based on an "OTi-2168 USB2.0 mass
storage class controller".

lsusb -v identifies the following:

Bus 001 Device 004: ID 0ea0:2168 Ours Technology, Inc. Transcend JetFlash
2.0
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0ea0 Ours Technology, Inc.
  idProduct          0x2168 Transcend JetFlash 2.0
  bcdDevice            2.00
  iManufacturer           1 USB
  iProduct                2 Flash Disk
  iSerial                 3 A8933C31BB2C00E2
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize        512
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize        512
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               none
        wMaxPacketSize          2
        bInterval               1
  Language IDs: (length=4)
     0409 English(US)

My previous USB-Key (an IBM 32Mb device which developed a memory "hole" and
died) worked fine.  This new key also fails to work in a colleagues Fedora
Core 2 2.4.x kernel machine which much the same issue.  It "just works" when
used in Windows XP.

Any help highly valued at this point, and a direct "cc" on any reply would
also be appreciated.

Thanks,

James Roberts-Thomson
----------
Hardware:  The parts of a computer system that can be kicked.

Mailing list Readers:  Please ignore the following disclaimer - this email
is
explicitly declared to be non confidential and does not contain privileged
information.

This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.

Re: Kernel unable to read partition table on USB Memory Key

[Stefano Rivoir]

Roberts-Thomson, James wrote:
> Hi,
> 
> I'm trying to diagnose an issue with a USB "Memory Key" (128Mb Flash drive)
> on my workstation (i386 Linux 2.6.12 kernel, using udev 058).
> 
> When connecting the key, the kernel fails to read the partition table, and
> therefore the block device /dev/sda1 isn't created, so I can't mount the
> volume.  Calling "fdisk" manually, however, makes it all work.
> 
> 
> Bus 001 Device 004: ID 0ea0:2168 Ours Technology, Inc. Transcend JetFlash
> 2.0

Hi all,

Just a "vote" for this: same USB key, same symptoms, same inability to 
use the key: I can create the fs and use it, but once unmounted it won't 
be mounted anymore.

Bye

-- 
Stefano RIVOIR

Re: [linux-usb-devel] Kernel unable to read partition table on USB Memory Key

[Alan Stern]

On Tue, 5 Jul 2005, Roberts-Thomson, James wrote:

> Hi,
> 
> I'm trying to diagnose an issue with a USB "Memory Key" (128Mb Flash drive)
> on my workstation (i386 Linux 2.6.12 kernel, using udev 058).
> 
> When connecting the key, the kernel fails to read the partition table, and
> therefore the block device /dev/sda1 isn't created, so I can't mount the
> volume.  Calling "fdisk" manually, however, makes it all work.

You don't even have to call fdisk.  Probably "touch /dev/sda" would be 
enough.

> When I plug the device into the USB port, the kernel prints the following:
> 
> Jul  5 16:18:38 pc196344 kernel: usb 1-6: new high speed USB device using
> ehci_hcd and address 3
> Jul  5 16:18:39 pc196344 kernel: Initializing USB Mass Storage driver...
> Jul  5 16:18:39 pc196344 kernel: scsi2 : SCSI emulation for USB Mass Storage
> devices
> Jul  5 16:18:39 pc196344 kernel: usbcore: registered new driver usb-storage
> Jul  5 16:18:39 pc196344 kernel: USB Mass Storage support registered.
> Jul  5 16:18:39 pc196344 kernel: usb-storage: device found at 3
> Jul  5 16:18:39 pc196344 kernel: usb-storage: waiting for device to settle
> before scanning
> Jul  5 16:18:44 pc196344 kernel:   Vendor: OTi       Model: Flash Disk
> Rev: 2.00
> Jul  5 16:18:44 pc196344 kernel:   Type:   Direct-Access
> ANSI SCSI revision: 02
> Jul  5 16:18:44 pc196344 kernel: Attached scsi generic sg1 at scsi2, channel
> 0, id 0, lun 0,  type 0
> Jul  5 16:18:44 pc196344 kernel: usb-storage: device scan complete
> Jul  5 16:18:44 pc196344 scsi.agent[12708]: disk at
> /devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/host2/target2:0:0/2:0:0:0
> Jul  5 16:18:44 pc196344 kernel: sda: Unit Not Ready, sense:
> Jul  5 16:18:44 pc196344 kernel: : Current: sense key: Unit Attention
> Jul  5 16:18:44 pc196344 kernel:     Additional sense: Not ready to ready
> change, medium may have changed
> Jul  5 16:18:44 pc196344 kernel: sda : READ CAPACITY failed.
> Jul  5 16:18:44 pc196344 kernel: sda : status=1, message=00, host=0,
> driver=08
> Jul  5 16:18:44 pc196344 kernel: sd: Current: sense key: Unit Attention
> Jul  5 16:18:44 pc196344 kernel:     Additional sense: Not ready to ready
> change, medium may have changed

<snip>

> Clearly, something isn't right here, and the kernel is unable to read block
> 0 (the parition table).  I've tried using the "delay_use" parameter to the
> usb-storage module to increase the delay time to 10 seconds, but still no
> difference.

The device is not supposed to send the "Unit Attention, Not ready to ready
change" message more than once.  It's violating the SCSI protocol by doing 
so.  (In fact it's not supposed to send that message at all; it's 
supposed to send "Power on or reset".)

> If I run "fdisk /dev/sda" however, then the kernel realises there is a
> partition table and it all just works, thus:

For some reason, the device stopped sending that error code and started 
working.

> In the case above, I'd not done anything inside fdisk apart from "q" to
> exit.  
> 
> However, I have tried reparitioning the device; using "dd if=/dev/zero
> of=/dev/sda bs=512 count=1" to zero the partition table and recreate;
> returning the device to the vendor and getting another one - no difference
> at all.

What's stored in the partition table won't matter because the kernel isn't
able to read it in the first place.  Replacing the device won't help,
because the device is behaving as designed and the design is broken.

> The key itself is a NZ vendor "own-name" rebadge, made in Taiwan.  According
> to the vendor's (Dick Smith Electronics, if anyone is interested) website,
> <http://www.dse.co.nz/cgi-bin/dse.storefront/42ca0f440021d23e273fc0a87f9906a
> 8/Product/View/XH8250> the product is based on an "OTi-2168 USB2.0 mass
> storage class controller".

> My previous USB-Key (an IBM 32Mb device which developed a memory "hole" and
> died) worked fine.  This new key also fails to work in a colleagues Fedora
> Core 2 2.4.x kernel machine which much the same issue.  It "just works" when
> used in Windows XP.
> 
> Any help highly valued at this point, and a direct "cc" on any reply would
> also be appreciated.

What might help would be a direct comparison of the commands being sent by 
Linux and by Windows.  If you turn on USB Mass Storage verbose debugging 
(CONFIG_USB_STORAGE_DEBUG) in the kernel configuration then the system 
debugging log will contain the commands sent by usb-storage.  You can use 
a USB sniffer program like USB Snoop (available from Sourceforge) to 
record the commands sent by Windows.  Perhaps looking over the two logs 
will reveal what magic command the device is waiting for.

Alan Stern

Re: Kernel unable to read partition table on USB Memory Key

[Vid Strpic]

[-- Attachment #1.1: Type: text/plain, Size: 1147 bytes --]

On Tue, Jul 05, 2005 at 11:24:51AM +0200, Stefano Rivoir wrote:
> Roberts-Thomson, James wrote:
> >I'm trying to diagnose an issue with a USB "Memory Key" (128Mb Flash drive)
> >on my workstation (i386 Linux 2.6.12 kernel, using udev 058).
> >When connecting the key, the kernel fails to read the partition table, and
> >therefore the block device /dev/sda1 isn't created, so I can't mount the
> >volume.  Calling "fdisk" manually, however, makes it all work.
> >Bus 001 Device 004: ID 0ea0:2168 Ours Technology, Inc. Transcend JetFlash
> >2.0
> Just a "vote" for this: same USB key, same symptoms, same inability to 
> use the key: I can create the fs and use it, but once unmounted it won't 
> be mounted anymore.

I have the same memory key (128Mb also), I didn't try it on recent 2.6,
but on previous ones (like, 2.6.8 for example), I know it DID work...
without problems... with factory partitioning though, I didn't
repartition...

-- 
           vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
Linux moria 2.6.11 #1 Wed Mar 9 19:08:59 CET 2005 i686
 12:10:51 up 18 days, 17:21,  1 user,  load average: 0.04, 0.49, 0.68

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: sanitizer.log --]
[-- Type: text/sanitizer-log, Size: 349 bytes --]

This message has been 'sanitized'.  This means that potentially
dangerous content has been rewritten or removed.  The following
log describes which actions were taken.

Sanitizer (start="1120644779"):
  Forcing message to be multipart/mixed, to facilitate logging.


Anomy 0.0.0 : Sanitizer.pm
$Id: Sanitizer.pm,v 1.87 2004/05/07 17:42:12 bre Exp $