Bug 18482

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.