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] [day] [month] [year] [list]
Date:	Sun, 15 Apr 2012 13:06:18 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Steven Newbury <steve@...wbury.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Barnes, Jesse" <jesse.barnes@...el.com>,
	Dave Airlie <airlied@...ux.ie>,
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: PCI resources above 4GB

On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury <steve@...wbury.org.uk> wrote:
>>>>>>>>
>>>>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size
>>>>>>>> 0x18000000)
>>>>>>> Ah! Not enough space for the bridge window!:(
>>>>>>>
>>>
>>>>>> please append pci=norom ...
>>>
>>>>> That worked.  Except of course the radeon driver can't POST the
>>>>>  card without the ROM! :-P
>>>> Can the ROM resource be mapped above 4G?
>>> I didn't really think that through, obviously it can't because
>>> it's not on a 64-bit capable bridge.  I wonder though, could it be
>>> shadowed then disabled early before the IOMEM?
>> I see there's "#if 0"'d helper functions for exactly that in rom.c.
>> They've been disabled since 2007!
>
> solution could be one of three:
> 1. when bridge support 64bit pref, will not allocate rom bar in bridge
> pref resource.
> ====> patch: rom_pref.patch
>
> 2. unconditionally to make rom bar allocation in bridge non-pref range.
> ====> patch: rom_no_pref.patch

missed attach rom_no_pref.patch

> Looks like BIOS and at least one of other OSes is doing that.
>
> I can not find the the history why ROM res is with PREFETCH bit set.
> Maybe Linus has some idea about that.
>
> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
> that could fail.
>   so could hack it like a. disable bar 0x10 and steal BAR address,
> then set 0x30 to that address then copy ROM to ram.
>   after that, disable rom again and set back address to 0x10.
>   You try to update radeon_get_bios() to achieve that.
>
>      Yinghai

Download attachment "rom_no_pref.patch" of type "application/octet-stream" (840 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ