Linux vs. DOSEMU geometry (Was: Re: DosEMU, Ghost: VGA screen garbled...)

["Frantisek Rysanek" <Frantisek.Rysanek@post.cz>]

Thanks for your comments and for your polite attention, 
Mr. Oldeman :-)
And you're right, I forgot to convert one "perror" into the DOSEMU 
style of warnings...

On 18 Sep 2009 at 18:00, Bart Oldeman wrote:
> In fact HDIO_GETGEO gives bogus info so I changed it 
> to look at the MBR as well to determine CHS limits.
> It's now in SVN.
> 
> Bart
>
you mean completely bogus?
I understand that the cylinders value is limited by a 16bit variable 
(clamped to (ushort) -1). Other than that, I used to think that 
HDIO_GETGEO always provides whatever the Linux kernel thinks is the 
right geometry, which in my experience is as correct as it gets :-) 
At least for my purposes, that is. My benchmark of geometry 
correctness is that the drive partitioned by Linux can boot in the 
same system (same BIOS) and in other hardware setups too...

With IDE (ATA) devices, Linux is aware of two geometries: "physical" 
and "logical". Physical is what the disk drive suggests at the IDE 
level in some service registers. In addition to that, Linux takes a 
peek into the partition table, and infers some values from that - 
that's logical geometry. The "H" and "S" values for the two 
geometries can differ. If they do differ, Linux defaults to using the 
"logical" geometry, as that's how it gets the partitions to work 
right.
I guess I've discovered that Linux does not ask the system BIOS for 
its opinion about a particular drive's geometry.

The system BIOS distinguishes several "geometry styles", typically 
CHS, LBA, LARGE - and the c/h/s values do change immediately if you 
change the geometry style in the BIOS setup. So if you change the 
geometry style in the BIOS, for a factory clean drive, and then you 
partition the drive with a tool that uses BIOS calls to access the 
drives (such as DOS fdisk), and then you reboot to Linux, this is 
what Linux infers as its "logical" geometry and what it keeps on 
using. 

If you want to get rid of the logical geometry being different from 
the physical geometry, either instruct your fdisk to use some other 
explicit CHS values, or just dd if=/dev/zero of=/dev/hda bs=512 
count=1 and invoke the BLKRRPART ioctl() somehow (such as using 
'blockdev --rereadpt', or using a cold reboot).

SCSI devices are a different matter. SCSI itself doesn't mention 
drive geometry, it only speaks LBA addresses. The sytem BIOS doesn't 
care about SCSI drives, and so its choice between CHS/LBA/LARGE is 
not applicable. The BIOS option ROM of your SCSI HBA does present 
some geometry via its services, and again if you partition the drive 
with a DOS fdisk, you also get that geometry in Linux. 
For SCSI drives, Linux can only assume a single geometry. There's no 
distinction between physical and logical. Now how does it arrive at 
that single geometry?
If the SCSI drive has a valid partition table in its MBR, the 
geometry is inferred from there. If the drive is pristine (MBR all 
zeroes), caveat: Linux invents its own geometry that it considers 
plausible! And, the geometry is yet different from the common BIOS 
"cookbook of bogus geometry recipes".

Note that USB Mass Storage devices act like SCSI devices even in this 
respect. One funny aspect: note that CF cards attached to an IDE bus 
do have a "physical" geometry, possibly distinct from the "logical" 
geometry. If there is a different logical geometry, it has probably 
been mandated by some BIOS rules. In a USB card reader though, the 
card has no way of presenting its physical geometry, and acts as a 
SCSI device. If you try to partition a factory clean CF card in a USB 
reader, you'll likely end up with a geometry that's incompatible with 
any BIOS, and the card won't be bootable when attached to an IDE 
bus... Same thing if you get the card with some compatible BIOS 
geometry, but you dd all zeroes into the MBR, and call BLKRRPART. 
This is when Linux forgets about the previously inferred geometry and 
applies a new one, and because the MBR is now blank, there's nothing 
to infer, and Linux will invent its own alien SCSI geometry thing...
The same gotcha applies to all ATA drives connected via an ATA-to-USB 
(mass storage) converter. Basically the morale is: if you want the 
ATA drive to be bootable on native ATA attach under BIOS, you have to 
partition the drive on native ATA attach, rather than in a USB 
converter :-)   (unless you know ufdprep.exe, but that's likely off 
topic here)

I wouldn't go as far as saying that the geometry provided by Linux 
HDIO_GETGEO is completely bogus. The 16bit Cylinders value is clamped 
to the max for that datatype, and the rest of the geometry can indeed 
be bogus with SCSI and USB devices that were attached with a blank 
MBR. Otherwise Linux follows the pre-existing partition table. I'd 
suggest generally to trust Linux on its guess.

Then again, it's been a while since the last time I fumbled through 
the relevant kernel guts :-) I may be wrong about some details...

Frank Rysanek