From: Thomas Backlund <tmb@iki.fi>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2.4.21-rc1] vesafb with large memory
Date: Fri, 2 May 2003 03:14:01 +0300 [thread overview]
Message-ID: <200305020314.01875.tmb@iki.fi> (raw)
In-Reply-To: <1051800568.21442.16.camel@dhcp22.swansea.linux.org.uk>
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
next prev parent reply other threads:[~2003-05-02 0:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-30 21:33 [PATCH 2.4.21-rc1] vesafb with large memory O.Sezer
2003-05-01 12:00 ` Thomas Backlund
2003-05-01 12:07 ` Alan Cox
2003-05-01 15:01 ` Thomas Backlund
2003-05-01 14:49 ` Alan Cox
2003-05-01 17:39 ` Thomas Backlund
2003-05-02 0:14 ` Thomas Backlund [this message]
2003-05-02 13:03 ` Willy Tarreau
2003-05-03 12:46 ` Thomas Backlund
2003-05-03 21:58 ` Willy Tarreau
2003-05-04 9:49 ` Willy TARREAU
2003-05-06 0:21 ` Thomas Backlund
-- strict thread matches above, loose matches on Subject: below --
2003-05-06 15:58 Walt H
2003-05-01 14:20 O.Sezer
2003-05-01 15:03 ` Thomas Backlund
2003-05-01 15:09 ` O.Sezer
2003-04-30 18:58 O.Sezer
2003-04-30 8:09 Adam Mercer
2003-04-30 11:26 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200305020314.01875.tmb@iki.fi \
--to=tmb@iki.fi \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox