On Sun Sep 30, 2001 at 06:31:55PM -0400, Alexander Viro wrote:
>
> One thing that doesn't work yet is support of Acorn partitions -
> I'm switching it to pagecache right now.
Well, acorn is broken anyways.... Try enabling in on a device
with native 2048 byte sectors and _no_ partition table will be
found on those devices (just an error msg resulting from acorn)
-Erik
--
Erik B. Andersen email: [email protected], formerly of Lineo
--This message was written using 73% post-consumer electrons--
On Sun, 30 Sep 2001, Erik Andersen wrote:
> On Sun Sep 30, 2001 at 06:31:55PM -0400, Alexander Viro wrote:
> >
> > One thing that doesn't work yet is support of Acorn partitions -
> > I'm switching it to pagecache right now.
>
> Well, acorn is broken anyways.... Try enabling in on a device
> with native 2048 byte sectors and _no_ partition table will be
> found on those devices (just an error msg resulting from acorn)
Could you send me an example of such animal? I don't mean the disk itself -
just the contents of relevant sectors (i.e. everything except the contents
of partitions themselves).
On Mon Oct 01, 2001 at 01:27:54AM -0400, Alexander Viro wrote:
>
>
> On Sun, 30 Sep 2001, Erik Andersen wrote:
>
> > On Sun Sep 30, 2001 at 06:31:55PM -0400, Alexander Viro wrote:
> > >
> > > One thing that doesn't work yet is support of Acorn partitions -
> > > I'm switching it to pagecache right now.
> >
> > Well, acorn is broken anyways.... Try enabling in on a device
> > with native 2048 byte sectors and _no_ partition table will be
> > found on those devices (just an error msg resulting from acorn)
>
> Could you send me an example of such animal? I don't mean the disk itself -
> just the contents of relevant sectors (i.e. everything except the contents
> of partitions themselves).
Here is what I normally see (in this case with 2.4.9-ac17):
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.1
<Adaptec 2940 Ultra SCSI adapter>
aic7880: Ultra Single Channel A, SCSI Id=7, 16/255 SCBs
(scsi0:A:4): 10.000MB/s transfers (10.000MHz, offset 15)
Vendor: OLYMPUS Model: MOS364 Rev: 1.02
Type: Optical Device ANSI SCSI revision: 02
(scsi0:A:5): 10.000MB/s transfers (10.000MHz, offset 15)
Vendor: OLYMPUS Model: MOS364 Rev: 1.02
Type: Optical Device ANSI SCSI revision: 02
[----------snip-------------]
Attached scsi removable disk sda at scsi0, channel 0, id 4, lun 0
Attached scsi removable disk sdb at scsi0, channel 0, id 5, lun 0
SCSI device sda: 310352 2048-byte hdwr sectors (636 MB)
sda: Write Protect is off
sda: sda1
SCSI device sdb: 310352 2048-byte hdwr sectors (636 MB)
sdb: Write Protect is off
sdb: sdb1
Everything looks fairly normal... I have 2 640Meg SCSI magneto optical drives
with a single partiton on the media in each (working as expected). Now lets
enable some stuff:
+CONFIG_ACORN_PARTITION=y
+CONFIG_ACORN_PARTITION_ICS=y
+CONFIG_ACORN_PARTITION_ADFS=y
+CONFIG_ACORN_PARTITION_POWERTEC=y
+CONFIG_ACORN_PARTITION_RISCIX=y
Now I see:
Attached scsi removable disk sda at scsi0, channel 0, id 4, lun 0
Attached scsi removable disk sdb at scsi0, channel 0, id 5, lun 0
SCSI device sda: 310352 2048-byte hdwr sectors (636 MB)
sda: Write Protect is off
sda:<5>ll_rw_block: device 08:00: only 2048-char blocks implemented (1024)
unable to read boot sectors / partition sectors
SCSI device sdb: 310352 2048-byte hdwr sectors (636 MB)
sdb: Write Protect is off
sdb:<5>ll_rw_block: device 08:10: only 2048-char blocks implemented (1024)
unable to read boot sectors / partition sectors
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...
-Erik
--
Erik B. Andersen email: [email protected], formerly of Lineo
--This message was written using 73% post-consumer electrons--
On Mon, 1 Oct 2001, Erik Andersen wrote:
> Here is what I normally see (in this case with 2.4.9-ac17):
> sda:<5>ll_rw_block: device 08:00: only 2048-char blocks implemented (1024)
> unable to read boot sectors / partition sectors
> SCSI device sdb: 310352 2048-byte hdwr sectors (636 MB)
> sdb: Write Protect is off
> sdb:<5>ll_rw_block: device 08:10: only 2048-char blocks implemented (1024)
> unable to read boot sectors / partition sectors
> 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...
Yes. I've finished converting this sucker and I think I understand what's
going on there. Reliance on block size being <= 1024 seems to be a
side effect of the implementation - not something fundamental. I'll
try to feed the stuff you've sent into it and see if it works - new
code shouldn't care about the block size.
On Mon, 1 Oct 2001, Erik Andersen wrote:
> 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
sector size.
I'm putting the new patch on anonftp -
ftp.math.psu.edu/pub/viro/partition-c-S11-pre1
News:
* massaged into form that should be easy to backport.
* acorn.c converted (_completely_ untested)
Folks, please help to test that sucker.
In linux-kernel, [email protected] wrote:
> 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.
Just for the record - I don't think Acorn disks can have sectors
bigger than 1k. (I never managed to get the 640Mb MO discs working, I
had to get the 512 byte sectored 512 Mb ones instead.) I just checked
in the PRM and it agrees with my very rusty memory.
I have some acorn partitioned MO discs lying around if you want to see
the first few sectors off the disc...
--
Nick Craig-Wood
[email protected]
--On Monday, 01 October, 2001 10:06 AM +0100 Nick Craig-Wood
<[email protected]> wrote:
> I don't think Acorn disks can have sectors
> bigger than 1k.
>From a very long time in the past when I used
to write interfaces to ARM stuff, I am /pretty/
sure I managed to get 4k sectors to work. As
this is about 10 years ago, and involved
some editing of some grungy BASIC HD format
program, I may be either wrong, or out of
date.
--
Alex Bligh
On Mon Oct 01, 2001 at 04:03:45AM -0400, Alexander Viro wrote:
>
> 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
Looks like your patches were folded into 2.4.10-ac3 -- and I'm pleased
to say that your patch has indeed fixed the problem. I just scratched
fixing acorn off my when-I-get-around-to-it list. Thanks!
-Erik
--
Erik B. Andersen email: [email protected], formerly of Lineo
--This message was written using 73% post-consumer electrons--