Message-Id: <200811071051.32830.elendil@planet.nl>
Date:	Fri, 7 Nov 2008 10:51:31 +0100
From:	Frans Pop <elendil@...net.nl>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	linux-kernel@...r.kernel.org, Rene Herman <rene.herman@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [bisected][resend] pnp: Huge number of "io resource overlap" messages

(Info below was also posted in reply to the announcement mail for .28-rc3 
(http://lkml.org/lkml/2008/11/3/201); reposting to the original thread as
there was no response yet.)

On Tuesday 09 September 2008, Bjorn Helgaas wrote:
> On Tuesday 09 September 2008 10:26:17 am Frans Pop wrote:
> Yup, this all looks reasonable to me, too.  But these regions must be
> different than they were when the PNP quirk ran.  I wonder if the BIOS
> left them unprogrammed, we ran the PNP quirk and discovered all these
> "conflicts," then PCI came along and assigned resources.
>
> Your dmesg shows power state changes for the PCI devices.  Maybe
> the BIOS left them in D3 and unprogrammed:
>
>   Intel ICH Modem 0000:00:1f.6: power state changed by ACPI to D0
>   Intel ICH 0000:00:1f.5: power state changed by ACPI to D0
>   Intel ICH 0000:00:1f.5: enabling device (0000 -> 0003)
>
> If the PCI device isn't fully initialized, it doesn't seem right to
> check it for resource conflicts.  But I don't know how to tell that.

It appears there's been a fundamental change between .28-rc2 and .28-rc3
that fixes this issue. I no longer get the "io resource overlap" messages
when the BIOS is set to let PCI devices be "Set up by OS".

I now get the exact same /proc/io{mem,ports} as with the BIOS set to
"initialize all PCI devices". It very much looks as if the two devices that
caused the messages now get activated much earlier.

This shows best in a diff between the dmesgs for .28-rc2 and .28-rc3. Here are
the relevant bits for the two devices:
# I now immediately get good resources assigned:
-pci 0000:00:1f.5: reg 10 io port: [0x00-0xff]
-pci 0000:00:1f.5: reg 14 io port: [0x00-0x3f]
-pci 0000:00:1f.5: reg 18 32bit mmio: [0x000000-0x0001ff]
-pci 0000:00:1f.5: reg 1c 32bit mmio: [0x000000-0x0000ff]
+pci 0000:00:1f.5: reg 10 io port: [0xbe00-0xbeff]
+pci 0000:00:1f.5: reg 14 io port: [0xbdc0-0xbdff]
+pci 0000:00:1f.5: reg 18 32bit mmio: [0xcfdffe00-0xcfdfffff]
+pci 0000:00:1f.5: reg 1c 32bit mmio: [0xcfdffd00-0xcfdffdff]
 pci 0000:00:1f.5: PME# supported from D0 D3hot D3cold
 pci 0000:00:1f.5: PME# disabled
-pci 0000:00:1f.6: reg 10 io port: [0x00-0xff]
-pci 0000:00:1f.6: reg 14 io port: [0x00-0x7f]
+pci 0000:00:1f.6: reg 10 io port: [0xba00-0xbaff]
+pci 0000:00:1f.6: reg 14 io port: [0xb980-0xb9ff]
 pci 0000:00:1f.6: PME# supported from D0 D3hot D3cold
 pci 0000:00:1f.6: PME# disabled
[...]
# The block of 78 "io resource overlap" messages are now gone:
-pnp 00:08: io resource (0x2e-0x2f) overlaps 0000:00:1f.5 BAR 0 (0x0-0xff), disabling
-pnp 00:08: io resource (0x62-0x62) overlaps 0000:00:1f.5 BAR 0 (0x0-0xff), disabling
[75 similar messages omitted]
-pnp 00:08: io resource (0x72-0x77) overlaps 0000:00:1f.6 BAR 1 (0x0-0x7f), disabling
[... much later]
# Apparently there is no longer any need to enable the device later on:
 Intel ICH 0000:00:1f.5: power state changed by ACPI to D0
-Intel ICH 0000:00:1f.5: enabling device (0000 -> 0003)
 Intel ICH 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
 Intel ICH 0000:00:1f.5: setting latency timer to 64
 Intel ICH Modem 0000:00:1f.6: power state changed by ACPI to D0
 Intel ICH Modem 0000:00:1f.6: PCI INT B -> GSI 17 (level, low) -> IRQ 17
 Intel ICH Modem 0000:00:1f.6: setting latency timer to 64

The most likely cause of this change is the following commit from Linus:
commit 1f98757776eafe31065be9118db6051afcf8643c
Author: Linus Torvalds <torvalds@...ux-foundation.org>
Date:   Sat Nov 1 10:17:22 2008 -0700
    x86: Clean up late e820 resource allocation

But I'm not 100% sure of that. Anyway, it looks as if #11550 can be closed.

Cheers,
FJP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists