Messages in this thread | | | From | BROWN Nick <> | Subject | RE: The WHY's (RE: ide drive w/dma ... system crash) | Date | Wed, 12 May 1999 10:48:16 +0200 |
| |
>I won't contradict you, but please - not so impatient. >The two of you are talking as if there is a proposed kernel patch >by me involving HDIO_GETBIOS, but there is no such patch. > You should note that it is not impliment for full use yet. > It is present for a test-touch-feel. Only a fool would try to make this > standard in its infant form. If is a direction that needs to be > considered.
Ah, _this_ makes sense. Maybe we need two patches: one for the IDE improvements, and one for "get BIOS info to INITSEG". Perhaps a comment in the latter could say "HDIO_GETBIOS: don't even think about using this without registering with Andries".
>And no, we are not able to get all the information we need >from the IDE controller. You see, the information we talk >about have nothing to do with the actual disk hardware - >what fdisk and LILO would like to know is what geometry or geometries >the BIOS and other operating systems will invent for this hardware. >So far they did not try to determine this themselves, but asked >the kernel using the HDIO_GETGEO ioctl. However, this ioctl >returns the wrong results (as you know) and it is far easier >to let the kernel make all relevant information available to >user space than to make the kernel decide.
I sat and stared at the code until my eyes went round in circles, and I came to the following conclusions:
1. Getting the BIOS info with all of Andries's methods may or may not be sensible. I suspect it will lead to screwups, because there is no way to ask the BIOS if a disk is IDE or SCSI. But... this is Andries's problem for fdisk, and should not be a kernel problem. 2. The kernel should not use the numbers from the various BIOS info calls under any circumstances. If we do collect this data in setup.S, it should be there on an "as-is" basis for fdisk and lilo. We know that this data is just plain wrong in many cases. 3. Therefore, we should be able to remove probe_cmos_for_drives(). All this currently does on most systems, is to initialise (thus preempting do_probe) the CHS numbers for hda and hdb (only) with BIOS-translated geometry, which (a) may well be completely wrong, (b) is not necessary for the kernel, and (c) causes a drive to show different geometry in dmesg depending on whether it's hda or hdc.
So my proposed patch to Golf is trivial: put #if 0... #endif around probe_cmos_for_drives() (and the call to it in probe_hwif()). The setup.S code (even the existing code, before patching) should be marked "do not use in kernel - if you use it all, do so with extreme caution".
[Puts on flame-proof suit and waits to find out why this won't work...]
The knowledge of how various BIOSes and other OSes choose to interpret the ATA numbers is something that (IMHO) should be in the utilities which need to take those other systems into account, not the kernel. So let's by all means provide Andries with the raw info he needs, but just because we're collecting it, doesn't mean we should use it. (I'd hope that it might be possible instead, to generate from the disk's actual geometry, a list of plausible pseudo-geometries that other views of the disk might use.)
At that point, also, the bug on my PC which got me involved in all this (lilo can't reconcile the BIOS geometry with the disk, because the BIOS numbers are wrong, because /dev/sda is hd0 in setup.S) becomes... a lilo bug (failure to take into account the actual geometry of the disk), as it should be, not a kernel bug.
Nick Brown, Strasbourg, France (Nick(dot)Brown(at)coe(dot)int)
__________________________________________________________
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/
| |