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.

-- 
Sata disk not identified during install (Ati sb600)
https://bugs.launchpad.net/bugs/75055
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to