From: Bob Breuer <breuerr@mc.net>
To: sparclinux@vger.kernel.org
Subject: vmalloc can clobber framebuffer on sparc32
Date: Mon, 12 Jun 2006 06:43:25 +0000 [thread overview]
Message-ID: <448D0D0D.8080606@mc.net> (raw)
David Miller wrote:
> From: Bob Breuer <breuerr@mc.net>
> Date: Sun, 11 Jun 2006 20:21:09 -0500
>
>> David Miller wrote:
>>> But why in the world does the scheduler "lock up" just because the
>>> migration cost is too large?
>> There is an address space collision between the vmalloc area and where
>> the prom maps the framebuffer.
>
> And this is what locks up the scheduler when a bad migration cost
> calculation is made?
The migration cost setup by default did a vmalloc of 10MB therefore
clobbering the address space used by the framebuffer. The next screen
redraw would access something other than the framebuffer, or fail if it
was vfree'd in the meantime. Either way, it silently goes downhill
because the console can't display the error messages to the screen.
> Please start a new thread if you are talking about some new topic,
> it gets confusing :-/
>
>> The vmalloc range is 0xfe600000 to 0xffc00000. I have a cg6 that gets
>> mapped to 0xfee00000, and a cg14 with 8MB vsimm that gets mapped to
>> 0xfe700000. These leave only 8MB and 1MB of usable vmalloc space before
>> bad things happen.
>>
>> We may want to find a different vm hole to put vmalloc into. Is there
>> any documentation on what address spaces are reserved with the different
>> prom versions?
>
> I don't know, but from your report it seems that OBP takes
> 0xfe000000 up to 0xfff00000.
>
> Actually, you can look at the "available" property of the
> virtual-memory node. Or, you can see if there is a "translations"
> node in the /virtual-memory node like there is on sparc64.
Ok, here are the available regions reported with a cg14 framebuffer:
00000000.fff00000.00100000
00000000.fef00000.00e00000
00000000.00000000.fe400000
00000000.ffe3f000.00081000
00000000.ffd00000.00026000
00000000.fe400000.00300000
after rearrange and fill gaps:
start - end ( size ) type
00000000-fe3fffff (fe400000) free
fe400000-fe6fffff (00300000) free
fe600000 = VMALLOC_START
fe700000-feefffff (00800000) unavail (cg14 framebuffer)
fef00000-ffcfffff (00e00000) free
ffc00000 = VMALLOC_END
ffd00000-ffd25fff (00026000) free
ffd26000-ffe3efff (00119000) unavail
ffe3f000-ffebffff (00081000) free
ffec0000-ffefffff (00040000) unavail
fff00000-ffffffff (00100000) free
The framebuffer sitting in the middle of the vmalloc range is what
causes the problem.
Bob
next reply other threads:[~2006-06-12 6:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-12 6:43 Bob Breuer [this message]
2006-06-13 6:54 ` vmalloc can clobber framebuffer on sparc32 David Miller
2006-06-13 9:23 ` Mark Fortescue
2006-06-13 16:09 ` Bob Breuer
2006-07-07 23:38 ` David Miller
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=448D0D0D.8080606@mc.net \
--to=breuerr@mc.net \
--cc=sparclinux@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.