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] dmesg (hang) 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 2.6.35.4 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] Everest log
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: ACPI Hardware ID ACPI\PNP0103 PnP Device High Precision Event Timer IRQ 00 IRQ 08 Memory FED00000-FED003FF PCI 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 from Linux? 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 2.6.35.4 dmesg from 2.6.35.4. Yes, it's 2.6.35.4 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 2.6.35.4 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? 2.6.33-rc6 (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 BIOS Information Vendor: Award Software International, Inc. Version: F8 Release Date: 03/03/2008 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 512 kB Characteristics: ... Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: Gigabyte Technology Co., Ltd. Product Name: GA-MA69VM-S2 Version: x.x Serial Number:
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.