> 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 (*).
Wait.......Andries busted his nuts to get this to work and it took a 2x4
framing board over my head to believe him. The fact is that he has a
viable option and should be considered.
Since there is no options to pass into the kernel like ::
bootme=scsi or bootme=ide
> 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
No comment as that I use offboard chipsets that have no BIOS reporting.
> - 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).
Yeah, I can buy that line you are selling, but there are still some cases
that we screw up the geometry on drives that do not comply.
> - 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".
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.
> - 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.
In principle, that is what I do because I have ZERO BIOS data to extract.
> 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).
Prove your case and bring a 2x4.........I recall weeks of discussion near
battle for me to see Andries point. Ask him about it and prepare for the
long haul.
> 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.
Well share the crashing with all of us.......it is always fun to wipe a
drive and always start fron scratch.
> (*) 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.
Well case (b) is getting everyone a crack at active chipset code tuning
for those "buggy IDE controllers and BIOSes". Where case (a) is modified
to "second generation" starting cutting teeth on 1.2.8.
************************
First Generation linux-0.X.X->1.1.X
Second Generation linux-1.2.X->1.3.X
Third Generation linux-2.0.X->2.1.X
Fourth Generation linux-2.2.X->2.3.X
************************
Andre Hedrick
The Linux IDE guy
Candidate for pre-patch-2.2.8-series or pre-patch-2.2.9-series
http://www.dyer.vanderbilt.edu/server/udma/
2.2.7.uniform-ide-6.19.golf.patch.gz
http://www.dyer.vanderbilt.edu/server/udma/2.2.7.uniform-ide-6.19.patch.gz
http://www.dyer.vanderbilt.edu/server/udma/ide.2.0.37pre11+pat7.gz
http://www.dyer.vanderbilt.edu/server/udma/hdparm-3.5i.patch.gz
APC UPS Daemon Support Center.
http://www.brisse.dk/site/apcupsd/
GPLed source on April 7, 1999
-
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/