Well, either that, or fix the code in setup.S which initialises it by
copying the BIOS drive parameter tables that are lying around in the INT
41h/46h pseudo-vectors, which is what seems to be causing the problem in
this case; it's the kind of thing that could easily get forgotten by a BIOS
maker. I can see two ways:
- call INT 13h AH=8 and use the resulting ES:DI pointer as the FDP table.
- call INT 13h AH=8 and fill in head, cylinders, sectors, and the control
byte (just the "head > 8" flag) by hand.
Of course, if probe_cmos_for_drives() were to die, the setup.S code might
well be redundant. I didn't see the drive_info_struct{} data being widely
used during my quick pass through the 2.0.36 source. As far as I can see,
probe_cmos_for_drives() could be replaced by a simple calculation of the
BIOS's idea of the number of fictional heads/cylinders. And asking the CMOS
if there's a drive there strikes me as very optimistic.
Meanwhile I'll patch setup.S in my kernel to fix my motherboard problem. If
anyone else wants the patch, let me know.
Nick Brown, Strasbourg, France (Nick(dot)Brown(at)coe(dot)fr)
-
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/