On Sun, Sep 20, 2009 at 4:05 PM, Frantisek Rysanek <Frantisek.Rysanek@xxxxxxx> wrote: > 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. >> > you mean completely bogus? Well it may not be completely bogus as you explained -- however things have changed in the Linux kernel too. particularly from 2.4 to 2.6. And I could not find anywhere where the kernel parses the MBR to find CHS values though fdisk certainly tries. I have a 4G USB key that I used to test "wholedisk" with a preformatted geometry (as I could see in the DOS boot sector) of CHS=978/128/63; however HDIO_GETGEO reported CHS=1017/125/62. This value was invented by setsize() in the Linux kernel's drivers/scsi/scsicam.c. Similarly, there's ata_std_bios_param() in drivers/ata/libata-scsi.c which invents xxx/255/63 (the standard values used for large hard disks nowadays). Linux fdisk even says 5922/37/36 because it parses the MBR, assuming that the partition ends at a cylinder boundary (it does not; the MBR is Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 80 0 9 0 36 36 978 8 7888888 0b 2 00 0 0 0 0 0 0 0 0 00 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00 so it stops a little before the boundary). All I wanted in DOSEMU was some kind of geometry that agrees with the MBR so DOS can make sense of it (and FreeDOS boots without warnings). And an "S" value of 63 is very common so I put some code there to check whether that values makes sense. Of course in reality for modern OSes CHS is irrelevant but the older DOSes that also may get used in DOSEMU such as MSDOS 6.22 only use CHS. Bart -- 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
