>
> You seem to contradict yourself. On the one hand you want to get
> values given by a controller, or by the BIOS, and that is what Linux
> does right now, and on the other hand you suggest a patch skipping
> BIOS or controller information and calling scsicam.c:scsicam_bios_param().
THAT IS NOT WHAT LINUX DOES RIGHT NOW. This is the origin of the original
patch. Many implementations of the bios_param driver call within the low
level don't return anything from the BIOS, or controller, or what the
drivers under other OSes might return. I know of only two that I have
thoroughly verified (qlogic and in2000). The values returned by most
others are "best guesses", and many guess wrong.
>
> But this latter routine is entirely bogus - it does not ask BIOS or
> controller, but reads the partition table and tries to guess geometry
> information by picking some random partition and hoping that the
> end_sector and end_head fields will describe the number of sectors
> and heads.
>
If the bios_param is wrong, scsicam has a better chance of returning
correct data.
> Thus, if the disk is new and does not contain a partition table,
> the patch will almost certainly yield the wrong geometry.
Correct. But if the disk is NOT new and has been pre-partitioned and the
bios_param routine is wrong, the unpatched version will return the wrong
geometery.
>
> I think such heuristics fit better in a conversational fdisk
> than in the kernel. On the other hand, we might add a bootparameter
> or ioctl to the kernel, telling it what to return for a HDIO_GETGEO
> ioctl on a given SCSI disk.
>
> Andries
>
It should go somewhere. If not in the kernel, then in the fdisk and lilo
and other programs that rely on CHS being correct.
zerucha@shell.portal.com ; finger zerucha@jobe.portal.com for PGP key