It's all to do with getting the right detection of the partitioning
scheme. If the order is wrong, you either can't detect a scheme, or
you mis-detect a scheme every time.
> Couldn't the acorn tests be moved further down in the list to solve
> this particular problem?
Unfortunately not (on both counts.)
There are several partitioning schemes for Acorn drives (thanks to Acorn
never defining a decent partitioning method, vendors went off and each
did their own thing.) So, we have the following schemes:
Scheme 512-byte sector offset
1. ICS 0
2. PowerTec 0
3. EESOX 7
4. Cumana 3
5. ADFS 3
Schemes 1 through 3 may (or may not) contain valid ADFS information at
sector 3. Scheme 4 definitely has valid ADFS information at sector 3.
Therefore, to correctly identify all in this list, ADFS must come last
in this list.
However, there are a large percentage of drives which have an old x86
BIOS partition table at sector 0. To prevent mis-detecting these
drives (which would render the ADFS partition check useless) the x86
BIOS partition check must come after ADFS.
So, there are three dependencies - ICS, PowerTec, EESOX before Cumana,
Cumana before ADFS, ADFS before x86 BIOS. This means PowerTec must
come before x86 BIOS.
> Also, is there a way to make the acorn test more specific?
s/acorn/powertec/
We may be able to check that start,start+size lies within the overall
drive size. Whether this solves the problem will depend upon the contents
of sector 0 for the x86 drives which clash. However, as drive sizes
increase, this test will become less and less effective (and at 2TiB
it doesn't help at all.)
Another solution would be to pass a kernel parameter like
"partition=hda:msdos,hdb:adfs" to force specific partition interpretation.
However, this could cause issues with hotplug stuff. Another alternative
is to just turn off the troublesome powertec scheme if you don't have any
drives using that scheme.
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/