Gutsy tribe 2 amd64 hangs on Intel DG33BU motherboard without pci=nommconf boot option

[Roland Dreier]

Binary package hint: linux-source-2.6.22

I just tried booting the Gutsy tribe 2 amd64 alternate CD on a system with an Intel DG33BU motherboard (pretty new, G33 + ICH9 chipset) with a Core 2 Duo E6320 and up-to-date BIOS 0249. If I don't change anything except get rid of the "quiet" kernel option, I can see that the boot hangs just after printing:

PCI: Using MMCONFIG at f0000000 - f7ffffff
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)

if I add "pci=nommconfig" to the command line, then the boot reaches the installer.

This is a system with no adapter cards installed -- in fact it happens with nothing but memory and a SATA CD-ROM attached to the motherboard.

[Brian Murray (brian-murray)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description doesn't yet have enough information.
Please include as attachments the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command 'uname -a' in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command 'dmesg > dmesg.log' and attach the resulting file 'dmesg.log' to this bug report.
3. Please run the command 'sudo lspci -vvnn > lspci-vvnn.log' and attach the resulting file 'lspci-vvnn.log' to this bug report.
For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks in advance!

[Roland Dreier (roland.dreier)]

Thanks for taking the time to triage this bug. Unfortunately, I'm not sure the normal requirements make sense, since this is a hang early in boot and therefore getting the requested information is not possible unless I use the workaround, which causes the bug not to trigger. So the dmesg/lspci stuff will be coming from a system where the bug didn't actually happen.

Anyway, I'll have access to the system again on Tuesday and I'll attach the requested stuff then.

[Roland Dreier (roland.dreier)]

OK, uname -a is:

Linux ubuntu 2.6.22-7-generic #1 SMP Mon Jun 25 17:07:55 GMT 2007 x86_64 GNU/Linux

Attaching dmesg...

[Roland Dreier (roland.dreier)]

...and lspci as requested.

[Roland Dreier (roland.dreier)]

(By the way, I confirmed that this problem still exists will the daily live CD from today, 2007-07-10)

[Ben Collins (ben-collins)]

We have a patch for this. Kyle will get it integrated.

[Kyle McMartin (kyle)]

Thanks, we'll get this fixed before tribe4. One last (optional) request if you've got time. Could you attach the output of dmidecode so we can add this chipset to an MMCONF blacklist as well?

Thanks,
 Kyle

[Roland Dreier (roland.dreier)]

no problem, here's the dmidecode output

[Kyle McMartin (kyle)]

marking fix released (ages ago)