Okay, I'll take the bait, but I'm not a kernel hacker, either, so someone
should feel free to rebut *my* comments as well.
>but it is my understanding that the kernel uses your system BIOS for actual
>reads/writes at the hardware level,
No. There are many reasons this isn't done, but a big one is:
BIOS = real mode
Kernel = protected mode
The kernel makes use of some BIOS *tables* (which are coped to known
locations before the Big Switch), but actual BIOS interrupt routines are used
only during the early stages of boot. Aside from the RM/PM issue, the BIOS
isn't used because it is 16-bit, slow, and generally buggy.
See Alan Cox's paper on kernel BIOS usage posted back on 6/22/01 for a nice
discussion of what use the kernel has for the BIOS.
>When you turn BIOS to <NONE> the OS does what it can, but
>the BIOS in your system *SHOULD* refuse to process the call, instead it's
>doing the read/writes, but not the same way as if IDE was turned on.
An interesting theory, but off the mark.
That said, I don't know what the Right Answer for Martin is, but here are a
few ideas:
* I notice the boot log shows a CMD646 IDE controller. Make sure the CMD640
bug-fix support is enabled in your kernel (assuming this applies to 64x
chips). If you're using a vendor's kernel it almost certainly is already, but
if you built your own, make sure.
* It is possible that when a drive is assigned in the BIOS, the BIOS will do
some configuration of the controller or the drive itself which the kernel is
not doing on its own. I don't know what the state of kernel support for that
646 chipset is.
* That's a pretty old drive, so I wouldn't rule out hardware problems.
Strange that it only fails when not configured in the BIOS, though.
Regards,
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/