> Note the ll_rw_block msg from where the acorn stuff is not reading in units
> of the physical sector size? Also notice the "unable to read..." msg, which
> is where acorn chokes the partition table scanning...
> So now, while fdisk is still able to see that partitions exist
> [andersen@dillweed andersen]$ fdisk -l /dev/sda
> Note: sector size is 2048 (not 512)
> Disk /dev/sda: 64 heads, 32 sectors, 151 cylinders
> Units = cylinders of 2048 * 2048 bytes
> Device Boot Start End Blocks Id System
> /dev/sda1 * 1 151 618432 83 Linux
> the acorn stuff has caused the partition scan to abort prematurely, such that
> proc partitions (and Linux) know nothing about the device's partitions. I can
> give you a dd from one of these disks, but I doubt that would show the error...
OK, first of all, it's _not_ an acorn partition table at all.
It's a garden-variety DOS partition table.
Actually, you've found a rather nasty bug in acorn.c - code in
the current tree fails if it tries to look for acorn-style partition
table on a large-sector disk. Fails with IO error, and reports that
to high-level code in check_partitions(). Which decides to stop.
msdos_partition() would be called after acorn_partition(), so it
doesn't get called at all.
Lovely... OK, there are two possible fixes - one is to
add check for block size into acorn_partition() (it's checked on
almost all branches, but there's one where it's missing). Another
is to switch to new partition code, which works with any physical
I'm putting the new patch on anonftp -
* massaged into form that should be easy to backport.
* acorn.c converted (_completely_ untested)
Folks, please help to test that sucker.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/