Comment 11 for bug 75055

I am not an Ubuntu user, rather a Debian (unstable) user. However, since Debian has been of absolutely no use in fixing this problem and Ubuntu has, I might as well comment here.

I too have a M2R32-MVP motherboard. Installing Linux was largely a combination of the latest Debian netinst CD and Kanotix-2006-preview. However, any attempt to actually boot off the new installation was frustrated. Most combinations of boot options resulted in the boot process hanging just after all the SCSI disk partitions were listed. A couple of combinations of boot options seem to result in a successful boot, but because of a plethora of warnings about some unbound interrupt, any text console was not useful.

As I understand the hardware, we should be running with the BIOS set to AHCI (not legacy, native or anything else). Some have mentioned a BIOS setting about capturing Int 19, I don't believe that this setting will noticably effect things (but I could be wrong). It is probably that should be enabled, so that the various BIOSes in a computer can boot properly. ACPI should probably be set to 2.0: 1.0 doesn't appear to be enough support (I have a flaky 21 inch CAD monitor sensitive to this). I haven't actually run across any documentation as to what the different versions of ACPI are supposed to do, and actually provide.

In the patch notes for 2.6.17 (kernel.org?), there is a note about PCI to the effect: fix issues with extended conf space when MMCONFIG disabled because of e820. It is my opinion that either this patch is buggy, or it doesn't go far enough. This MMCONFIG/e820 business was the first thing I noticed in trying to boot either 2.6.18 or 2.6.20 kernels.

This particular motherboard has 2 SATA controllers, the listed ATI SB600 attached to this bug report, and a JMicron 360 for the external SATA connector.

In terms of this unbound interrupt making the text consoles unusable, what will stop this from happening is to set loglevel=4. (loglevel=5 isn't sufficient.) This doesn't fix the problem, it just makes the console usable. As long as this problem persists, any dmesg output is likely unusable as it is just full of this unbound interrupt.

I gather that if you see a message about MMCONFIG not being e820 reserved in booting, you need to set pci=nommconf as a boot option. What seems to be required in order to actually get the boot to work in a crippled manner, is to also set nomsi (so pci=nommconf,nomsi). This isn't a good solution, as MSI seems to be needed for PCI Express cards (or at least some of them) to work properly. The near term, better solution is to track down what MSI (and MSI-X) devices actually work properly on this motherboard (which I am starting to do), and only enable MSI on those devices with another boot option (device_msi=a,b,c where a, b, c are 16 digit hex numbers describing the deviceID and vendorID).

A common boot option in discussions on this problem is irqpoll. I gather irqpoll is the bigger hammer with respect to broken hardware compared to irqfixup. I haven't seen any evidence that it actually helps in this problem, nor that it hurts if set. I am not sure of any performance implications of either of these settings.

Since this seems to be (IMHO) a MSI problem related to SATA hardware, people might want to read the MSI-HOWTO document for their particular kernel (in the Documentation subtree of the source for the kernel) in actually getting things working. However, I am not a kernel hacker, I would much rather being doing statistics or solving differential equations. So, I could be wrong.

This business about MSI and MMCONFIG seems to be fairly active in the kernel, and so a solution for 2.6.18 may not work for other kernels. However, the process of tracking down and fixing things should probably work for 18 through 21 kernels.