Thread (44 messages) 44 messages, 12 authors, 2008-09-09

Re: linux-next: Tree for September 3

From: Yinghai Lu <hidden>
Date: 2008-09-04 07:14:29
Also in: lkml

On Wed, Sep 3, 2008 at 10:33 PM, Andrew Morton
[off-list ref] wrote:
quoted hunk ↗ jump to hunk
On Wed, 3 Sep 2008 22:21:54 -0700 (PDT) Linus Torvalds [off-list ref] wrote:
quoted

On Wed, 3 Sep 2008, Andrew Morton wrote:
quoted
The Vaio says:

calling  init_acpi_pm_clocksource+0x0/0x14a
initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
calling  pcibios_assign_resources+0x0/0x70
pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
Hmm. This should not be a new warning, afaik.

But it looks totally bogus.

The code does:

      r_size = r->end - r->start + 1;
      /* For bridges size != alignment */
      align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
      order = __ffs(align) - 20;
      if (order > 11) {
              dev_warn(&dev->dev, "BAR %d too large: "
                      "%#016llx-%#016llx\n", i,
                      (unsigned long long)r->start,
                      (unsigned long long)r->end);

and the thing is, that's a bridge resource, so it chooses r_start as the
alignment. Which is zero. so now __ffs(align) returns a bogus value, and
you get the bogus warning.

But CARDBUS bridges are _different_ from normal PCI bridges, and the
alignment value isn't r->start. Strictly speaking it's not r_size either,
it's always a fixed alignment of 4096 for MMIO bridging, i think. Maybe.
Whatever. But our resource handling code can't handle that, and always
wants either size alignment or start alignment.

But for cardbus bridges, we should be doing size alignment, and the
problem is that that code doesn't do the proper "resource_alignment()"
use.

Can you apply this patch, just to see if it fixes things.
Below..
quoted
And do you know when this started happening? It shouldn't have been all
that recent. Maybe you haven't tried your Vaio in a while?
Yes, the Vaio had a vacation in New York.  Last kernel it booted was
2.6.26-rc8-mm1.
--- x   2008-09-03 21:38:24.000000000 -0700
+++ y   2008-09-03 22:29:04.000000000 -0700
...
@@ -503,15 +503,15 @@
 calling  init_acpi_pm_clocksource+0x0/0x14a
 initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
 calling  pcibios_assign_resources+0x0/0x70
-pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
 pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
 pci 0000:06:05.0:   IO window: 0x002400-0x0024ff
 pci 0000:06:05.0:   IO window: 0x002800-0x0028ff
-pci 0000:06:05.0:   MEM window: 0x54000000-0x57ffffff
+pci 0000:06:05.0:   PREFETCH window: 0x50000000-0x53ffffff
+pci 0000:06:05.0:   MEM window: 0x58000000-0x5bffffff
 pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
 pci 0000:00:1e.0:   IO window: 0x2000-0x2fff
 pci 0000:00:1e.0:   MEM window: 0xb0100000-0xb01fffff
-pci 0000:00:1e.0:   PREFETCH window: disabled
+pci 0000:00:1e.0:   PREFETCH window: 0x00000050000000-0x00000053ffffff
 pci 0000:00:1e.0: setting latency timer to 64
 pci 0000:06:05.0: power state changed by ACPI to D0
06:05.0 is under 00:1e.0

wonder if some pci code change cause that.... doesn't get pref mem assigned.

can you apply attached patches to get more dump?

YH

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help