linux-kernel - Re: linux-next: Tree for September 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Sep 2008 00:14:18 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Stephen Rothwell" <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: Tree for September 3

On Wed, Sep 3, 2008 at 10:33 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Wed, 3 Sep 2008 22:21:54 -0700 (PDT) Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>>
>>
>> On Wed, 3 Sep 2008, Andrew Morton wrote:
>> >
>> > 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..
>
>> 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

View attachment "pci_res_print_out.patch" of type "text/x-patch" (2471 bytes)

View attachment "split_e820_reserve.patch" of type "text/x-patch" (3574 bytes)

View attachment "split_e820_reserve_xx2.patch" of type "text/x-patch" (5150 bytes)

View attachment "insert_resource_debug_x.patch" of type "text/x-patch" (3755 bytes)