> Lets say that this is not a kernel bug, but a BIOS / hardware
> related issue. How does one tell if the devices on the system
> should be edge, or level triggered?
That's a hard question to answer. It depends a lot on chipsets and undocumented
hardware behaviour. That's why we need a BIOS at this moment. It will
initialize a lot of strange things for us. And even the documented things tend
to change so rapidly, that we can't follow it.
We can, however, make a handler that's capable of handling both, but with extra
overhead. This is in fact the only 'general' solution I can think of.
> Also should the kernel be 'responsible' for BIOS related bugs,
> like the kernel handles hardware bugs (eg F00F)?
Maybe. If we can get the information on how to do it, it would be nice. But if
you look at the source for what we already hunt for bugs in the BIOS, then you
can image what the trouble will be.
I think that the BIOS should be corrected. If someone should take it up, then
it's the BIOS maker. The problem is however, that because of economical issues,
these things will _not_ be solved. The solution could be OpenBIOS, but that is
not currently usable for this _and_ you can not (presently) expect the
producers of motherboards to support the OpenBIOS team to let their motherboard
work correctly with there BIOS (patents and things like that). So we end up
like it is now.
It could be a solution if the hardware would become more a standard. (PCI is
on its way, but the initialization is not as it should be.) There's a long
way to go.
What will happen I think, is that we will try to find out a way to work around
(check for board XYZ revision 3-6; if found, then put irqs on level) or some
safer but slower method (unified irq handler or someting like that).
<dreaming>If we ever get the source of those BIOSes with the docs, then we will
be able to correct such silly tables ourselves, and post the nescessary changes
back to the internet</dreaming>
In short: we will do everyting we can. But as many boards out there are simply
too buggy to run properly, we've got a hard time.
Simplest solution is and will be too in the future to make a 'black list' of
boards that need additional parameters to let it work. That would imply a
little bit of overhead of extra code in the kernel, but it can be left out
when not nescessary.
Greetings,
Jos van de Ven
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
