Opened 13 years ago

Last modified 13 years ago

#4516 new bug

Flash card partition table not parsed correctly (r33137)

Reported by: monni Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers/Disk Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: x86


I have a Kingston 2 GB microSD card with 1966080 (0x001E0000) hardware sectors which is detected as 960 MB instead of 1920 MB.

partition table says...

partition 0: start = 0x000000FF, size = 0x003BFF01

Experienced behaviour: Doesn't mount

Expected behaviour: Should mount and show correct partition size

Change History (4)

comment:1 by axeld, 13 years ago

That is strange at least, as the only reason I could imagine this to happen would be a fixed block size somewhere, but my iPod with a 4K block size works without a problem.

Can you provide a syslog?

comment:2 by monni, 13 years ago

relevant part of syslog:

KERN: usb_disk: request_sense: media changed
KERN: Media changed from /dev/disk/usb/0/2/raw
KERN: KDiskDeviceManager::_ScanPartition(/dev/disk/usb/0/2/raw)
KERN:   trying: partitioning_systems/intel/extended/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/intel/map/v1
KERN: intel: pm_identify_partition(12, 5: 0, 1006632960, 512)
KERN: Partition::SetTo(): active: 0
KERN: Partition::CheckLocation() - end after session: 2013265920 (session: 1006632960)
KERN: intel: _ParsePrimary(): partition 0: bad location, ignoring
KERN: Partition::SetTo(): active: 0
KERN:   returned: 0.5
KERN:   trying: file_systems/bfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/devfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/rootfs/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/amiga_rdb/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/apple/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/efi_gpt/v1
KERN:   returned: -1
KERN:   trying: partitioning_systems/session/v1
KERN:   returned: -1
KERN:   trying: file_systems/attribute_overlay/v1
KERN:   returned: -1
KERN:   trying: file_systems/cdda/v1
KERN: usb_disk: unhandled ioctl 10102
KERN:   returned: -1
KERN:   trying: file_systems/ext2/v1
KERN:   returned: -1
KERN:   trying: file_systems/fat/v1
KERN:   returned: -1
KERN:   trying: file_systems/iso9660/v1
KERN: identify(12, 0x8115ba40)
KERN:   returned: -1
KERN:   trying: file_systems/nfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/ntfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/reiserfs/v1
KERN:   returned: -1
KERN:   trying: file_systems/write_overlay/v1
KERN:   returned: -1
KERN:   scanning with: partitioning_systems/intel/map/v1
KERN: intel: pm_scan_partition(12, 5: 0, 1006632960, 512)

comment:3 by axeld, 13 years ago

Owner: changed from marcusoverhagen to mmlr

Can you try to find out which block size Linux detects for the device? The syslog output looks good, and since it detects exactly half of the actual size, I suspect a block size problem indeed. This should then be in the usb_disk driver, though.

comment:4 by monni, 13 years ago

Linux shows two devices for it: /dev/sdd1 and /dev/sdi1

mika@palermo:~$ scsi_readcap /dev/sdd1
sg_readcap   /dev/sdd1
Read Capacity results:
   Last logical block address=1966079 (0x1dffff), Number of blocks=1966080
   Logical block length=512 bytes
   Device size: 1006632960 bytes, 960.0 MiB, 1.01 GB
mika@palermo:~$ scsi_readcap /dev/sdi1
sg_readcap   /dev/sdi1
Read Capacity results:
   Last logical block address=3932159 (0x3bffff), Number of blocks=3932160
   Logical block length=512 bytes
   Device size: 2013265920 bytes, 1920.0 MiB, 2.01 GB

First one looks same as Haiku detects now, which seems weird... Both device paths are readable.

Note: See TracTickets for help on using tickets.