From: "steve.glass@optusnet.com.au" <steve.glass@optusnet.com.au>
To: linux-kernel@vger.kernel.org
Subject: Boot time OOPS when using large (128MB) frame buffer with VESA fb driver
Date: Sat, 24 May 2003 22:33:44 +1000 [thread overview]
Message-ID: <3ECF66A8.8070002@optusnet.com.au> (raw)
Hi,
/[1.] One line summary of the problem:/
Immediately after getting the "booting linux" message the screen clears
and the machine freezes.
/
[2.] Full description of the problem/report:/
After upgrading my PC from 512MB to 1GB of RAM and repeatably got the
above behaviour. Using a serial console it is clear that the kernel is
issuing an OOPS but the video card hasn't finished initialization.
/[2.1.] Problem cause:
/
Very early in the boot sequence, vesafb_init(at line 540) calls
ioremap() to map the frame buffer. Eventually, __ioremap() calls
get_vm_area() to request is to find a 128MB block (the size of my Ti4200
frame buffer). This should be a problem because the whole non-contiguous
memory is only 128MB and get_vm_area() adds PAGE_SIZE (another 8MB
sanity space) for good measure. Unfortunately, a bug in get_vm_area()
means that the memory wrap-around check is not performed during first
call - and this is the first time it is called!
As a result, the block is erroneously allocated and returned.
Fortunately, __ioremap() does a redundant check that the start address
plus size does not wrap around and this test fails so it BUGs out at
line 73. The video card hasn't been initialized yet so the user never
gets to see the OOPS message (I used a serial console).
/[2.2.] Solution:
/
The problem is fixed by changing the definition of __VMALLOC_RESERVE so
it reserves more memory for the non-contiguous address pool. E.g.
changing line 143 of include/asm-i386/page.h to allocate 192MB of addresses.
#define __VMALLOC_RESERVE (192 << 20)
With this done there is no need to fix the bug in get_vm_area();
although I can provide the code for that.
/[3.] Keywords (i.e., modules, networking, kernel):
/
kernel, vesafb, i386, non-contiguous memory manager, get_vm_area()
[4.] Kernel version (from /proc/version):
2.4.19, 2.4.20, 2.4.21rc1
...
[7.] Environment
PC, Athlon, ASUS A7V333 mobo, 1GB RAM, Ti4200 128MB video card.
Hope that is good, its working perfectly with just that 1-line change.
Steve
reply other threads:[~2003-05-24 12:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3ECF66A8.8070002@optusnet.com.au \
--to=steve.glass@optusnet.com.au \
--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