Kernel Bug Tracker – Bug 18482
GA-MA69VM-S2 requires pci=nocrs with 22.214.171.124 (HPET)
Last modified: 2012-08-13 16:32:35 UTC
Simon Arlott reports:
> With a Gigabyte GA-MA69VM-S2 690V motherboard, it stalls in
> quirk_usb_early_handoff unless pci=nocrs is used:
[ 299.177004] pci 0000:00:13.0: pci_apply_final_quirks
[ 299.177004] pci 0000:00:13.0: calling quirk_cardbus_legacy+0x0/0x21
[ 299.177004] pci 0000:00:13.0: calling quirk_usb_early_handoff+0x0/0x5dd
I'll attach the dmesg log Simon provided. From them, it looks like the
HPET appears as a PCI device, in addition to being described in the HPET
table (and possibly in the ACPI namespace):
[ 0.000000] ACPI: HPET id: 0x10b9a201 base: 0xfed00000
[ 0.454232] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.461348] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7]
[ 0.468004] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff]
[ 0.474004] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[ 0.481004] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000dffff]
[ 0.489004] pci_root PNP0A03:00: host bridge window [mem 0x80000000-0xfebfffff]
[ 1.034049] pci 0000:00:14.0: no compatible bridge window for [mem 0xfed00000-0xfed003ff]
[ 1.651998] pci 0000:00:14.0: BAR 1: assigned [mem 0x80000000-0x800003ff]
Since the 00:14.0 BAR looks invalid (it's outside all the host bridge
windows), we moved it to 0x80000000, and that probably broke the HPET
driver, which still thinks it's at 0xfed00000.
If anybody could provide the output of Everest (free trial version at
http://www.lavalys.com/), it would be a great help.
Created attachment 29982 [details]
Here's the failing console log.
Created attachment 29992 [details]
dmesg (with pci=nocrs, successful)
Here's the successful boot with "pci=nocrs".
Well, I have the same motherboard since 03/2008. It works fine on Windows (used Vista and 7). On Linux, I always had a small problem. If I boot to Windows, before I reboot to Linux, I need to go to the BIOS and change the "USB Mouse" setting from "Yes" to "No" or "No" to "Yes". Otherwise, I get "ohci_hcd 0000:00:13.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ." and the mouse won't work at all. And the keyboard, if it's USB.
Anyway, I don't see any "pci_apply_final_quirks" in my 126.96.36.199 dmesg (but have # CONFIG_HPET is not set), but am attaching the Everest output, if it's of any use for your problem.
Created attachment 30012 [details]
Created attachment 30032 [details]
hpet debug patch
Thank you very much, Frédéric! Windows shows the PNP0103 ACPI device at
0xfed00000, but it shows no resources for the PCI device:
Hardware ID ACPI\PNP0103
PnP Device High Precision Event Timer
Location Information @system32\DRIVERS\pci.sys,#65536;PCI bus %1, device %2, function %3;(0,20,0)
PCI Device ATI SB600 - SMBus Controller
If it's possible, could you turn on CONFIG_HPET and CONFIG_PNP_DEBUG_MESSAGES,
apply this patch, boot with "pnp.debug pci=nocrs", and attach the dmesg log
I think we need to make Linux ignore that 00:14.0 PCI BAR, either by
fixing the existing quirk or by doing something more generic.
I'm sorry that I don't have an idea about the USB issue. That sounds like
a topic for a different bug report.
I already had CONFIG_PNP_DEBUG_MESSAGES enabled. I turned on CONFIG_HPET, applied your patch, booted with pnp.debug pci=nocrs, but it reboots after 2-3 seconds.
Created attachment 30052 [details]
hpet debug patch (v2)
Oh, I'm sorry, that patch had some junk in it that I didn't intend.
Can you try this one instead?
Created attachment 30062 [details]
dmesg from 188.8.131.52
dmesg from 184.108.40.206. Yes, it's 220.127.116.11 with no EXTRAVERSION.
What's the last known good kernel?
Created attachment 30092 [details]
hpet test patch
It's interesting that it fails for Simon, but works for Frédéric, even
though you both have the same motherboard. Maybe there's a BIOS difference.
The HPET spec says "[the HPET] is not implemented as a standard PCI function,"
and "It is not expected that the OS will move the location of these timers
once it is set by the BIOS."
Given that we have examples where the HPET apparently *is* implemented as a
PCI function, and the fact that the HPET table provides no way to associate
an Event Timer Block with a PCI function, I think we might have to just check
every PCI function we discover against what we found in the HPET table so
we can keep from moving it.
This patch is a stab at that. Can anybody test it?
(In reply to comment #3)
> Anyway, I don't see any "pci_apply_final_quirks" in my 18.104.22.168 dmesg (but have
This was some debugging I added by raising the level of the PCI quirks logging.
(In reply to comment #9)
> What's the last known good kernel?
(In reply to comment #10)
> It's interesting that it fails for Simon, but works for Frédéric, even
> though you both have the same motherboard. Maybe there's a BIOS difference.
I did test this without any HCDs compiled in and it still did it, but if it's relevant I have EHCI disabled.
dmidecode -t 0 -t 2:
# dmidecode 2.10
SMBIOS 2.4 present.
Handle 0x0000, DMI type 0, 24 bytes
Vendor: Award Software International, Inc.
Release Date: 03/03/2008
Runtime Size: 128 kB
ROM Size: 512 kB
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: GA-MA69VM-S2
Frédéric has BIOS version F10C, and his system works fine even without
my patch (well, he does see a USB issue -- bug 18532, but I don't think
that's related to this HPET issue). So I think something was fixed in
the BIOS between versions F8 and F10C.
Simon, I guess with my patch (attachment 30092 [details]), you system still hangs
during boot ... right? I assume it still boots with "pci=nocrs"; could
you attach the dmesg log from that boot? If there's some way to capture
the log from a failing boot (use "ignore_loglevel" to get more info), such
as a serial console, netconsole, or video, that would be very helpful.
Simon, can you please attach the dmesg log from the test with the patch
(attachment 30092 [details])? Thanks!
I still haven't tried it yet; as I stated before I don't intend to reboot any time soon.
Created attachment 32612 [details]
make PCI HPET immovable
Please test this instead of the previous version.