Messages in this thread | | | Date | Mon, 11 Oct 1999 17:14:10 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 2.3.20 will not boot (PCI problem) |
| |
On Mon, 11 Oct 1999, Alex Nicolaou wrote: > > Why not do it both ways? If the BIOS and the kernel disagree, log a > message about the problem to the console, and use the kernel's result. > Since this is a boot-time issue only, the overhead is irrelevant, and > having a message about it will make it easier to debug for those for > whom the kernel's method is incorrect.
It's not about "when you disagree"..
If the BIOS is buggy and you call into it, the machine will crash. Hard. There is no way to recover gracefully.
That's why I don't want BIOS calls. Every single time we've called a BIOS routine (APM, standard PCI config routines, and now PCI interrupt info), there has been a non-negligible subset of BIOSes that have been buggy enough to crash the machine when called.
That's why parsing tables in memory is fine - when you parse the tables you can at least try to recover from buggy tables.
Note that this is partially why I moved the APM stuff into a separate process: it still crashes, but now a crashing BIOS can at least occasionally be somewhat contained (I'm not saying it's secure or anything like that, but the stupid random bugs that are due to the BIOS expecting DOS and Windows data structures at certain addresses tend to cause a clean kill rather than anything worse).
But I don't want to have something as critical as PCI scanning be dependent on something that is known to be unreliable. Doing it by hand may be painful too, but at least we can fix the bugs and we can analyze what goes wrong when it is done by hand.
Linus
- 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/
| |