Messages in this thread | | | From | BROWN Nick <> | Subject | RE: The WHY's (RE: ide drive w/dma ... system crash) | Date | Tue, 11 May 1999 19:16:20 +0200 |
| |
>The problem is that it needs to be moved to a high/different location than >ide-probe.c. There is a compile problem if ide is modular with scsi >default. Since this is currently limited to i386 arch, make a suggestion >of were to place this animal. >As stated before, Andries work is part of the patch and reports for IDE, >but SCSI is stubbed out. Suggestion where it should go?
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/
| |