linux-kernel - Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic Toughbook S10

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]

Message-ID: <Pine.LNX.4.64.1207061631270.26974@info>
Date:	Fri, 6 Jul 2012 16:37:15 -0700 (PDT)
From:	Bill Unruh <unruh@...sics.ubc.ca>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
cc:	Jiang Liu <liuj97@...il.com>, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, bugzilla-daemon@...zilla.kernel.org
Subject: Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic
 Toughbook S10

On Fri, 6 Jul 2012, Bjorn Helgaas wrote:

> On Sat, Jun 02, 2012 at 11:30:23AM +0800, Jiang Liu wrote:
>> ... address range 0xfed98000-0xfed9ffff has been reserved by motherboard
>> device(PNP0C02).  I guess that BIOS has assigned address "0xfed98000" to
>> 0000:00:04.0 for thermal management functionality. The BAR0 of
>> 0000:00:04.0 may be locked down (can't be changed by OS) because the ACPI
>> BIOS may have dependency on the assigned address ranges.
>
> I don't think the BAR can be completely read-only.  If it were, we wouldn't
> have any way to determine its size.  We believe it is 32K in size:
>
>    pci 0000:00:04.0: reg 10: [mem 0xfed98000-0xfed9ffff 64bit]
>
> so we should have written 0xffffffff to the low 32 bits of the BAR and read
> back 0xffff8004 (32K = 2^15, so the low-order 15 bits should be read-only,
> including the prefetchable bit (0), the type bits (10 for 64-bit), and the
> memory space indicator (0)).
>
> Can you experiment with setting that BAR manually, e.g., by running these
> commands as root:
>
>    # setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1
>    # setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa00000
>    # setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1


planet:0[root]>setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1
0006
fed98004
00000000
planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa00000
planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1
fed98004
00000000
planet:0[root]


So it seems to work but does  not change the base address (or was that what
you meant by "does not work")



>
> That's basically what the kernel does in pci_update_resource(), so this
> will likely fail, too.
>
> In __pci_read_base(), where we size the BAR, we disable decoding first,
> which we *don't* do in pci_update_resource().  So if the above doesn't
> work, can you try this:
>
>    # setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1
>    # setpci -s 00:04.0 COMMAND=0
>    # setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa00000
>    # setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1

planet:0[root]>setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1
0006
fed98004
00000000
planet:0[root]>setpci -s 00:04.0 COMMAND=0
planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa00000
planet:0[root]>setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1
fed98004
00000000
planet:0[root]>

Ie, same thing-- no change in the address.


--
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/