It's a almost certainly a buggy BIOS.

Not surprising, it's one of the issues we've always had - the 32-bit BIOS interfaces tend to be buggy because they are never tested. When the PCI code calls into the BIOS to find out the interrupt routing, the BIOS gets confused and craps all over. The code to call into the BIOS for the irq number is new as of 2.3.19 or so..

Martin, let's just change the defaults: NOT call the BIOS by default (and maybe have a kernel command line to say "pciirq=bios" for the two people who need it and have a working BIOS) because I'll bet this is not going to be the only report on machines not booting when more people start testing. And it's not as if we got the interrupt numbes wrong by just looking them up by hand.

Getting a irq wrong occasionally is better than crashing mysteriously at boot. A device may not work, but at least it is a lot more debuggable. And it's probably (almost certainly) more likely that there are more broken 32-bit BIOS interfaces than there are broken machines where we have trouble guessing the irq number without the BIOS.

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.

Well, the thing is that even if they ended up there, they'd just shake their heads and say "tough luck". Even if they cared enough to fix the bug for newer versions of their BIOS (big if), that would still leave existing BIOSes with the bug. And while you can update the BIOS on pretty much all modern machines (that didn't use to be the case - remember EPROMs?), it's still not something most people want to do..

And yes, it's a bad circle. Because BIOSes have been buggy in this area, nobody uses them (including MS), so nobody tests them in real use, so they never get fixed, so...

This is why it's best to consider the BIOS just a glorified loader and not much more. Depend on it to set up the machine in a close to usable state, but be ready to do everything else on your own.

This paper proposes and evaluates soft timers, a new operating system facility that allows the efficient scheduling of software events at a granularity down to tens of microseconds. Soft timers can be used to avoid interrupts and reduce context switches associated with network processing without sacrificing low communication delays.

More specifically, soft timers enable transport protocols like TCP to efficiently perform rate-based clocking of packet transmissions. Experiments show that rate-based clocking can improve HTTP response time over connections with high bandwidth-delay products by up to 89% and that soft timers allow a server to employ rate-based clocking with little CPU overhead (2--6%) at high aggregate bandwidths.

Soft timers can also be used to perform network polling, which eliminates network interrupts and increases the memory access locality of the network subsystem without sacrificing delay. Experiments show that this technique can improve the throughput of a Web server by up to 25%.

This seems to be due to the excessively clever IRQ routing code that is new as of 2.3.19, which thinks that it should fix up things that the BIOS left disabled.

Which is absolutely deadly, because the BIOS in this case apparently left the irq routing disabled for a very good reason: it is probably routing the USB IRQ into an SMI, and doing the magic "emulate old devices with USB" in SMM mode thing.

When the new PCI code then changes the IRQ routing without being aware of the two levels of drivers that are using the interrupts (the kernel driver for a PS/2 mouse, and the SMM-mode BIOS driver that has the USB device enabled), you end up with an endless stream of USB interrupts that go to the wrong driver (which won't know what to do with them, so they'll keep coming - PCI interrupts are level-triggered, and once they start with nobody to shut them off they will just never stop).

That's because when the USB irq is enabled, the BIOS won't have activated the USB controller because it thinks that the OS will handle the USB interrupt natively (you don't happen to have the USB driver enabled, so in your case the OS will _not_ have enabled the USB controller either, and you never get an endless stream of interrupts, because in this case there won't be any confusion - the only driver that will actually use irq12 is the PS/2 driver and it will be able to correctly handle all incoming interrupts - none of the crossed wires as in the bad case).

Martin, the 2.3.19 code must go. It cannot be fixed up, and this cannot continue.

Maybe NOW you understand why I have harped and harped on the issue of NOT trying to fix up random PCI state without having the driver explicitly ask for it? This is going to keep on happening as long as the PCI subsystem continues to think that it can know what the "RightThing(tm)" to do is. But the PCI subsystem really doesn't know enough in the absense of a driver, and there may be some really good reason why an IO area is not mapped or an IRQ is not enabled.

This is why missing interrupt routing stuff and missing IO mappings etc should be enabled ONLY by the driver. Because by the time the driver enables them, we know that they will be managed properly (or at least at that time it can be considered a driver bug and fixed at the proper level). Not before.

I don't think you lived through the horror of Minix and having user-space FP emulation. It's a horrible pain - either overloading SIGFPE with all that implies, or another magic hidden signal with ld.so loading a FP library on demand etc - and then core-dumps tend to be impossible to figure out etc etc.

So it definitely was a lot better off in kernel space - the user space solution would just have made everybody go slightly mad after the five hundreth bug in some shared library configuration. With the kernel solution there were no surprising interactions, just a lot of reasonably complex code that had mostly been written earlier anyway.

HOWEVER, it may be that times have changed, and that it _now_ would be better off in user space simply because it's almost never an issue any more, and user space can do some hacks that you can't do in kernel space due to security reasons etc.

At the same time it also doesn't really matter any more. I don't think the FP emulator has been changed in the last year or so, and it works. It has some slightly painful issues with fp state saving etc, but they are at least _solved_ issues.