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 -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
