Limiting BAR resource region size allocation (device claims 2x what it needs) ?

Limiting BAR resource region size allocation (device claims 2x what it needs) ?

[TJ]

Is there a way to over-ride a device's BAR region-size allocation? I've been looking but the only way I can identify is via a quirk.

I'm dealing with a Nvidia GeForce Go 7600 (NV8B) in a Sony Vaio VGN-FE41Z laptop. The device requests and is assigned a VRAM window of 256MB. However, there is only 128MB of physical VRAM.

>From my research it seems that some versions of the Go 7600 did have 256MB VRAM and the device is programmed
to request that regardless of the physically installed VRAM.

Combined with other PCI devices in the system the assignment of a 256MB window means that maximum RAM in the laptop is severely limited.

The CPU is 64-bit but the i945PM northbridge is 32-bit (so no physical > 4GB addressing). With PCI allocations as they are the system is limited to 2GB of RAM under Linux (3GB on Windows Vista).


$ sudo lspci -vnn -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce Go 7600] [10de:0398] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Sony Corporation Device [104d:81ef]
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at d5000000 (32-bit, non-prefetchable) [size=16M]
	Memory at b0000000 (64-bit, prefetchable) [size=256M]
	Memory at d4000000 (64-bit, non-prefetchable) [size=16M]
	I/O ports at 2000 [disabled] [size=128]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [60] Power Management version 2
	Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [78] Express Endpoint, MSI 00
	Capabilities: [100] Virtual Channel
	Capabilities: [128] Power Budgeting <?>
	Kernel driver in use: nvidia
	Kernel modules: nvidia_current_updates, nouveau, nvidiafb

Re: Limiting BAR resource region size allocation (device claims 2x what it needs) ?

[Matthew Wilcox]

On Wed, Aug 29, 2012 at 01:50:47PM +0100, TJ wrote:
> The CPU is 64-bit but the i945PM northbridge is 32-bit (so no physical > 4GB addressing). With PCI allocations as they are the system is limited to 2GB of RAM under Linux (3GB on Windows Vista).

According to the laptop specs, it's limited to 2GB RAM:

http://www.sony.co.uk/support/en/product/VGN-FE41Z/specifications

Personally, I'm not terribly excited about doing much work to enhance
a 6 year old laptop...

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Limiting BAR resource region size allocation (device claims 2x what it needs) ?

[TJ]

On 29/08/12 14:24, Matthew Wilcox wrote:
> On Wed, Aug 29, 2012 at 01:50:47PM +0100, TJ wrote:
>> The CPU is 64-bit but the i945PM northbridge is 32-bit (so no physical > 4GB addressing). With PCI allocations as they are the system is limited to 2GB of RAM under Linux (3GB on Windows Vista).
> 
> According to the laptop specs, it's limited to 2GB RAM:
> 
> http://www.sony.co.uk/support/en/product/VGN-FE41Z/specifications
> 
> Personally, I'm not terribly excited about doing much work to enhance
> a 6 year old laptop...
> 
I've had it from new. It supports 4GB physically - 2 SO-DIM slots @ 2GB each.

Up until now I've been using my own resource allocation patches I wrote in 2009 to do things the same way as Windows does, to allow access to 3GB of RAM. At that time I discussed them with Jesse
Barnes and analysed the problem comprehensively. See http://tjworld.net/wiki/Linux/Kernel/Bug/PciAllocationAlgorithm

I'd now like to work with a mainline kernel but that would force me to lose 1/3 of RAM as things stand.

As things have changed significantly in PCI-land since I wrote my patches they no longer fit so I'm looking to find a way to use mainline and keep the 3GB of RAM.

Relatively recently I realised the VRAM is only 128MB so I wondered if there might be a slightly easier way by forcing the region size allocation to match. Reducing the region size to 128MB would also
mean double the number of boundaries it could align to. That might avoid the need for my custom patches to shuffle allocations around.