Re: [PATCH 2.4.21-rc1] vesafb with large memory

Thomas Backlund (tmb@iki.fi)
Fri, 2 May 2003 03:14:01 +0300


Thomas Backlund wrote:
>Viestissä Torstai 1. Toukokuuta 2003 17:49, Alan Cox kirjoitti:
>> On Iau, 2003-05-01 at 16:01, Thomas Backlund wrote:
>> > You mean the patch that only looks at videomode, dont you...
>>
>> I do
>>
>> > Well maybe it's best to use it as default, to avoid this bug
>> > "out of the box"...
>> >
>> > But I will remake a patch to ovverride it so that the users who
>> > need/want the extra memory to be able to allocate it...
>> > since I like the idea of giving the user the choice...
>>
>> Sounds right to me
>
>>Oh well,
>I'm building my testkernel now with the above patch,
>and will be testing different vram options to "kill" my system...

And here are the results...

the testsystem:
Amd XP 1800+
nForce2 m/b
256MB DDR RAM
Geforce4 Ti4200 64MB, videomode 1024x768x32
kernel-2.4.21-0.16mdk (i586 optimized)
kernel-2.4.21-0.16mdkent (i686 optimized + HIGHMEM)

without any vram option it allocated:
vesafb: framebuffer at 0xc0000000, mapped to 0xd0800000, size 24576k
as it should...

the standard kernel maxed out at about 755 MB
the enterprise kernel maxed out at about 720 MB

with the enterprise kernel I managed to get it to boot
with an allocation request for 1536MB, but the screen
blacked out at the berginning, even if the kernel seemed
to boot without errors....

booting with 800MB or 1024MB request resulted in an direct
lockup with flashing keyboard leds....

so it seems to be the 1GB magical limit again...

So it seems useless to try and set an upper limit,
instead just leving it to the users choice to set whatever
he/she wants...

Now I have to get some sleep....

-- 
Thomas Backlund

tmb@iki.fi www.iki.fi/tmb

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/