[lkml]   [1999]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [W:0.060 / U:2.216 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site