USB unknown partition table

[Vittorio Ballestra]

Binary package hint: linux-source-2.6.22

After upgrading to Gutzy I'm no more able to access my USB pen. I can open it with other PC and from windows. dmesg outputs 'no partition found':

[ 199.944000] scsi2 : SCSI emulation for USB Mass Storage devices
[ 199.944000] usb-storage: device found at 6
[ 199.944000] usb-storage: waiting for device to settle before scanning
[ 199.944000] usbcore: registered new interface driver usb-storage
[ 199.944000] USB Mass Storage support registered.
[ 204.944000] usb-storage: device scan complete
[ 204.944000] scsi 2:0:0:0: Direct-Access Generic Flash Disk 8.01 PQ: 0 ANSI: 2
[ 204.948000] sd 2:0:0:0: [sdb] 2047998 512-byte hardware sectors (1049 MB)
[ 204.948000] sd 2:0:0:0: [sdb] Write Protect is off
[ 204.948000] sd 2:0:0:0: [sdb] Mode Sense: 03 00 00 00
[ 204.948000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 204.952000] sd 2:0:0:0: [sdb] 2047998 512-byte hardware sectors (1049 MB)
[ 204.952000] sd 2:0:0:0: [sdb] Write Protect is off
[ 204.952000] sd 2:0:0:0: [sdb] Mode Sense: 03 00 00 00
[ 204.952000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 204.952000] sdb: unknown partition table
[ 204.956000] sd 2:0:0:0: [sdb] Attached SCSI removable disk
[ 204.956000] sd 2:0:0:0: Attached scsi generic sg2 type 0

[Leann Ogasawara (leannogasawara)]

HI Vittorio,

Sorry for the extremely delayed response. The Hardy Heron Alpha series was recently released which contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

Also, please note that we will keep this report open against the actively developed kernel. However against linux-source-2.6.22 this bug does not meet the criteria for a stable release update and is being closed. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates . Thanks!

[wolfger (wolfger)]

No response in over 3 months. We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[tommaso (tommaso-demarch)]

I have the the same problem with kubuntu 8.04

[Anthony Awtrey (tony-awtrey)]

Your description looks suspiciously like this kernel bug:

http://bugzilla.kernel.org/show_bug.cgi?id=10808

Can you post the output from:

lsusb -v -d ????:????

(where ????:???? is the product and vendor id)

Can you try running:

blockdev --rereadpt /dev/sd?

(where ? is the block device node)

If it works, the partition nodes should appear after the partition table is reread.

T

[tommaso (tommaso-demarch)]

output of lsusb -v -d ????:????

tommaso@tdm:~$ lsusb -v -d 115e:0003

Bus 001 Device 006: ID 115e:0003
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x115e
  idProduct 0x0003
  bcdDevice 1.00
  iManufacturer 5
  iProduct 2
  iSerial 3
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 39
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xc0
      Self Powered
    MaxPower 400mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 3
      bInterfaceClass 8 Mass Storage
      bInterfaceSubClass 6 SCSI
      bInterfaceProtocol 80 Bulk (Zip)
      iInterface 4
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0008 1x 8 bytes
        bInterval 10
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x03 EP 3 OUT
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
can't get device qualifier: Operation not permitted
can't get debug descriptor: Operation not permitted
cannot read device status, Operation not permitted (1)

what is block device node? (i'm italian)
tanks,
tommaso

[Leann Ogasawara (leannogasawara)]

Hi Tommaso,

Please refer to the upstream bug report for more information:

http://bugzilla.kernel.org/show_bug.cgi?id=10808

[Aimo Parru (aimoparru)]

I've got the same problem with Diel Roc mp4 player. I tried the upstream bug fix, but rereading the partition table wasn't the right solution for me.

If I try:
blockdev --rereadpt /dev/sdc
(c is the node)

I still get: sdc: unknown partition table

I'm using the little scripts that can be found in the other bug, which rereads the partition table again automatically.

Log:
kernel [ 3616.529759] usb 1-1.1: new full speed USB device using uhci_hcd and address 12
kernel [ 3621.646949] usb 1-1.1: configuration #1 chosen from 1 choice
kernel [ 3621.667154] scsi9 : SCSI emulation for USB Mass Storage devices
kernel [ 3621.669485] usb-storage: device found at 12
kernel [ 3621.669495] usb-storage: waiting for device to settle before scanning
NetworkManager <debug> [1223399445.873994] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_115e_3_A55A55A55A55').
NetworkManager <debug> [1223399446.053516] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_115e_3_A55A55A55A55_if0').
kernel [ 3626.661967] usb-storage: device scan complete
kernel [ 3626.664971] scsi 9:0:0:0: Direct-Access Anyka PMP2501 Opn Disk PQ: 0 ANSI: 2
kernel [ 3626.667990] scsi 9:0:0:1: Direct-Access Anyka PMP2501 SD & MMC PQ: 0 ANSI: 2
kernel [ 3626.681904] sd 9:0:0:0: [sdc] 497536 2048-byte hardware sectors (1019 MB)
kernel [ 3626.684904] sd 9:0:0:0: [sdc] Write Protect is off
kernel [ 3626.684919] sd 9:0:0:0: [sdc] Mode Sense: 0b 00 00 08
kernel [ 3626.684924] sd 9:0:0:0: [sdc] Assuming drive cache: write through
kernel [ 3626.693933] sd 9:0:0:0: [sdc] 497536 2048-byte hardware sectors (1019 MB)
kernel [ 3626.696952] sd 9:0:0:0: [sdc] Write Protect is off
kernel [ 3626.696966] sd 9:0:0:0: [sdc] Mode Sense: 0b 00 00 08
kernel [ 3626.696972] sd 9:0:0:0: [sdc] Assuming drive cache: write through
kernel [ 3626.696986] sdc: unknown partition table
kernel [ 3626.721020] sd 9:0:0:0: [sdc] Attached SCSI removable disk
kernel [ 3626.721135] sd 9:0:0:0: Attached scsi generic sg4 type 0
kernel [ 3626.733956] sd 9:0:0:1: [sdd] Attached SCSI removable disk
kernel [ 3626.734064] sd 9:0:0:1: Attached scsi generic sg5 type 0
NetworkManager <debug> [1223399451.239635] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_115e_3_A55A55A55A55_if0_scsi_host').
NetworkManager <debug> [1223399451.249271] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_115e_3_A55A55A55A55_if0_scsi_host_scsi_device_lun0').
NetworkManager <debug> [1223399451.293046] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_115e_3_A55A55A55A55_if0_scsi_host_scsi_device_lun0_scsi_generic').
NetworkManager <debug> [1223399451.339355] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_115e_3_A55A55A55A55_if0_scsi_host_scsi_device_lun1').
NetworkManager <debug> [1223399451.387679] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_115e_3_A55A55A55A55_if0_scsi_host_scsi_device_lun1_scsi_generic').
NetworkManager <d...

[zcat (zcat)]

The kernel developers attitude on this bugs me. A brief summary;

1) The device works perfectly in Windows and OSX, but not in Linux

2) The reason seems to be very simple. The device return 'garbage' data on the first read, and the real data on subsequent reads. Linux uses the first read. Windows and OSX ignore it and read again to get the 'real' data.

3) The fix seems painfully obvious; do what Windows does.

4) The kernel developers apparently won't fix this because the USB standard says devices shouldn't behave this way. They want to follow the standard 'to the letter' even though this differs from the actual implementation used in the the two major OSes and apparently as implemented a non-trivial number of devices.

SO: Can someone who doesn't have a stick up their ass please provide a patch against a recent kernel that performs a 'garbage' read or two from USB mass-storage devices before probing for the real data, so that I can actually use my new MP3 player without having to open a root shell every time, please?

[zcat (zcat)]

Time for me to eat some humble pie; my mp3 player does work in Intrepid, it just doesn't work in whatever passes for a recent kernel in Hardy. I guess it's time to upgrade...

Also the problem _was_ much worse than just not mounting. I later noticed that the kernel was spewing all kinds of USB errors and the filesystem on the mp3 player ended up horribly corrupted.. I have yet to test this thoroughly in intrepid.

[teledyn (garym-teledyn)]

I have this problem with a new 4GB usb stick, and here is the REALLY curious thing that's worth reporting to the list here: It works just fine on an ASUS Eee-pc running Linux 2.6.21.4; the mount table lists the device there identical to any other vfat insert, vfat and cp850

I realize this is a "will not fix" issue, but the ASUS _is_ a linux machine, so we know that support for these things IS possible.

fwiw, lsusb says

Bus 005 Device 005: ID 1221:3234
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x1221
  idProduct 0x3234
  bcdDevice 0.00
  iManufacturer 1
  iProduct 2 Flash Disk
  iSerial 3 1000000000001039
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0x80
      (Bus Powered)
    MaxPower 100mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 2
      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
          Usage Type Data
        wMaxPacketSize 0x0200 1x 512 bytes
        bInterval 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x01 EP 1 OUT
        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
Device Status: 0x0000
  (Bus Powered)

[teledyn (garym-teledyn)]

forgot to mention: I'm seeing that no-paritition error in 8.10

[TJ (tj)]

Looking at the changes between v2.6.21 and v2.6.27 I see this. It may explain why v2.6.21 works and Intrepid (v2.6.27) doesn't:

git log --pretty=format:"%h %ci %s" v2.6.21..v2.6.27 -- fs/partitions/msdos.c
0607fd0 2008-04-28 08:58:47 -0700 fat: detect media without partition table correctly
b84d879 2007-07-30 00:27:28 -0700 [PARTITION] MSDOS: Fix Sun num_partitions handling.

Of which 0607fd0 looks to have some involvement in this area, albeit to detect non-partitioned FAT-formatted devices:

commit 0607fd02587a6b4b086dc746d63123c1f284db68
Author: Frank Seidel <email address hidden>
Date: Mon Apr 28 02:16:31 2008 -0700

    fat: detect media without partition table correctly

    I received a complaint that some FAT formated medias (e.g. sd memory cards)
    trigger a "unknown partition table" message even though there is no partition
    table and they work correctly, while in general (when e.g. formated with
    mkdosfs or even Windows Vista) this message is not shown.

    Currently this seems only to happen when the medias get formatted with Windows
    XP (and possibly Win 2000). Then the boot indicator byte contains garbage
    (part of text message) and so do the other parts checked by msdos_paritition
    which then later triggers this message.

    References: novell bug #364365

    Most fat formatted media without partition table contains zeros in the boot
    indication and the other tested bytes and so falls through the checks in
    msdos_partition, leading it to return with 1 (all is fine).

    But some (e.g. WinXP formatted) fat fomated medias don't use boot_ind and so
    the check fails and causes a "unkown partition table" warning eventhough there
    is none and everything would be fine.

    This additional check directly verifies if there is a fat formatted medium
    without a partition table.

    Signed-off-by: Frank Seidel <email address hidden>
    Cc: Andreas Dilger <email address hidden>
    Acked-by: OGAWA Hirofumi <email address hidden>
    Signed-off-by: Andrew Morton <email address hidden>
    Signed-off-by: Linus Torvalds <email address hidden>

[zcat (zcat)]

> Looking at the changes between v2.6.21 and v2.6.27 I see this. It may
> explain why v2.6.21 works and Intrepid (v2.6.27) doesn't:

Just to clarify; My mpx player is still working 'acceptably' in Hardy,
Intrepid and the Jaunty beta. That is to say it appears on the desktop
and opens automatically and I can transfer files in both directions.

Vast numbers of IO errors and retries show up in the logs,
occasionally it disconnects itself, and file transfers are much slower
than for other players and USB devices. However the player performs
just as poorly under Windows, so I've concluded that this is a result
of bad design in the player and it's probably not possible to make it
work any better than it currently does.

I consider the bug 'fixed'