If you mean the HDIO_GETBIOS ioctl which is currently in "#if 0" in
sd_ioctl.c, then I think it should go to the trash, because I think we may
be in danger of building a house of cards here. The whole ioctl can be
removed, I think (*).
My current line of thought about the way we check for IDE disks (please
critique) is:
- The CMOS probe for drives is a complete joke these days
- We should be able to get all the information we need from the IDE
controller, and treat the BIOS values as a last resort - we currently *have*
to do this for all drives beyond the first two anyway, leading to bizarre
boot time messages where two identical drives have wildly different CHS
numbers (albeit with the same product).
- We maybe can't trust the BIOS data completely, but we can trust some parts
of it more than others. Notably, if INT 13h AH=08h doesn't give a sensible
answer, the machine probably won't boot DOS; I suspect that new machines in
this category won't often have IDE drives anyway. (Some makers now
explicitly don't _support_ DOS, but you can be sure it boots, if only to
load the BIOS flasher.)
- I don't think I'm insulting Andries if I say that his patch has introduced
a non-trivial amount of hair; notably the manual calculation of the 0x22c
offset to more_drive_info which is an "accident waiting to happen".
- So, we should turn the code upside down. Ask the controller for the drive
info in each case. Only use the BIOS info if we can see that it clearly
conflicts with the controller - for example, if it gives us plausible
geometry for a disk when the controller gives us a junk or empty reply.
This would presumably handle obscure, older ST506 emulations, for example.
At that point, Andries's whole patch to setup.S can be removed, and replaced
with a simple loop of BIOS calls to get the BIOS geometry of the first few
disks. I wrote such a loop a couple of weeks ago, although Andries had some
problems with it (the exact nature of which I have now forgotten, of
course). I intended it to work for two drives (mainly because it replaced
the INT 41h/46h "vector" lookup), but it could be made to work for eight
drives, using only the 32 bytes from 0x80-0x9f in INITSEG which the current
setup uses (by copying the whole 16-byte FDPE each time).
I gave this a trivial test just now on my PC here at work by commenting out
(in probe_hwif()) the call to probe_cmos_for_drives() altogether, and it
booted just fine and gave me correct disk geometry (not BIOS-translated, of
course). This evening I plan to desert my family again, and try to write a
version which works with probe_cmos_for_drives (or rather, its
non-CMOS-probing descendant) at the bottom of probe_hwif.
---------------------------------------------------------------
Nick Brown, Strasbourg, France (Nick(dot)Brown(at)coe(dot)int)
---------------------------------------------------------------
(*) One of two things is happening here:
(a) Newbie who thinks he understands, is wasting everyone's time with his
lack of knowledge of all those buggy IDE controllers and BIOSes out there
or
(b) A fresh pair of eyeballs is seeing a new possibility
My money is on (a), but we'll see.
__________________________________________________________
email address updates : @coe.int replaces @coe.fr
for more information, http://dct.coe.int/info/emfci001.htm
__________________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/