This problem concerns IDE.C in 2.0.36 and (98% certain; I just have to run
the 2.2 code tonight, but the source looks identical) IDE-PROBE.C in 2.2.1,
but if it does turn out to be a bug, the fix might lie in setup.S.
There is a bug, and it is well-known, and it cannot easily be fixed.
The problem is that the kernel in setup.S asks the BIOS about hd0 and hd1.
But which disks are that? The IDE code assumes that these will be hda and hdb,
but there is no guarantee at all, and on many a system hd0 and hd1 are
sda and sdb, or sda and hda.
So, the kernel cannot use this BIOS information.
And it doesnt need it either - it just collects it in order to
give it to LILO and fdisk, and it is much better if the kernel
collects the raw information without interpreting it. Both LILO
and fdisk have other sources of information also.
On ftp.cwi.nl in /pub/aeb/getbios you'll find a kernel patch
2.2.2.patch-HDIO_GETBIOS and a C program getbiosdrivedata.c .
The patch adds some code to setup.S and makes it available via
an ioctl. The C program tries to interpret the results.
Especially if you have very new hardware I appreciate receiving
the program output (possibly together with kernel boot messages
about the disks involved) - mail to aeb@cwi.nl .
[I have not looked at this recently - please complain if the patch
doesnt compile anymore with 2.2.5.]
The problem appeared last week when I upgraded my home PC's motherboard's
BIOS. (QDI P5I430TX Titanium I, if anyone's remotely interested). My
system has:
- a 3098 MB Western Digital IDE disk
- a Symbios C810 (chip = NCR 53C8xx) SCSI controller
- a variety of SCSI disks depending on phase of the moon
The BIOS on this mobo is explicitly sympathetic to the NCR SCSI chip and can
use its disks as boot devices, for example.
After the BIOS upgrade, LILO wouldn't work, and neither would [c]fdisk.
They all complained (approx, I'm at work, so busking) that the BIOS geometry
didn't match the on-disk geometry.
I rebooted (this is all on 2.0.36, but bear with me, the problem still seems
to be there in 2.2.1 at least) and paid close attention to the messages.
When the IDE driver started, it said
hda: WDC AC23200L, 3098MB w/256kB Cache, CHS=1023/130/63, UDMA
Previously, this has been
hda: WDC AC23200L, 3098MB w/256kB Cache, CHS=787/128/63, UDMA
I downgraded to the old BIOS version - no problem. Upgraded - problem came
back. Made a note to call the motherboard manufacturer. Then I did some
arithmetic and found that 1023*130*63 matched my first SCSI drive (4091 MB).
Swapped the SCSI drives around, so the 2047 MB drive was first, and got
hda: WDC AC23200L, 3098MB w/256kB Cache, CHS=1023/65/63, UDMA
Hmmm. IDE provides the name, MB and cache size, SCSI provides the CHS.
Yes, precisely.
Quoting from the patch that I sent Alan and Andre Hedrick a month ago or so:
@@ -2934,6 +2903,12 @@
* The only "perfect" way to handle this would be to modify the setup.[cS] code
* to do BIOS calls Int13h/Fn08h and Int13h/Fn48h to get all of the drive info
* for us during initialization. I have the necessary docs -- any takers? -ml
+ * [I did this. But the result is more suited for user space. -aeb]
+ *
+ * Unfortunately the above is far too optimistic. One of the problems is that
+ * drives 1 and 2 may be SCSI disks (even when IDE disks are present), so that
+ * the geometry we read here from BIOS is attributed to the wrong disks.
+ * Eventually the routine below should be removed.
*/
static void probe_cmos_for_drives (ide_hwif_t *hwif)
{
...
Now, I'd be happy to dismiss this as a BIOS bug and downgrade, or boot with
hda=c,h,s - but a couple of things worry me:
No reason to worry. We understand the situation very precisely.
- There is no [adequate] sanity check. 1023*130*63 cannot be 3098 MB.
I somewhat fixed this. (As mentioned, the real fix is to remove all
this cruft from the kernel and leave it to user space.)
Unfortunately the present IDE maintainer has not so much experience
with disk geometries yet, and he changed my fix in strange ways.
I suppose things will be OK in the end.
...
Well, they aren't ignored, they are used as-is... the user doesn't get any
sort of warning like "sorry, geometry doesn't match, specify it manually".
<snip>
* The only "perfect" way to handle this would be to modify the setup.[cS]
code
* to do BIOS calls Int13h/Fn08h and Int13h/Fn48h to get all of the drive
info
* for us during initialization. I have the necessary docs -- any takers?
-ml
<end snip>
Well, I'd be happy to do it - it's a very small job, I would have thought,
especially since a cursory glance through the source suggests that the only
info which is needed anywhere is what probe_cmos_for_drives() uses.
Currently this is head, cyl, sect, and "ctl" - and here my IDE knowledge is
shown to be non-existent; how would one get the "ctl" value from a BIOS call
? If Mark or someone has the docs he mentions in the comments, I'll do it !
See above. And see the 2.2.2 patch mentioned above.
Best regards, Andries - aeb@cwi.nl - do not mail dwguest
-
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/