From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Roman Sergeev <sungeneral@gmail.com>
Cc: linux-fbdev-devel@lists.sourceforge.net,
bugzilla-daemon@bugzilla.kernel.org,
Joseph Chan <JosephChan@via.com.tw>,
Scott Fang <ScottFang@viatech.com.cn>,
bugme-daemon@bugzilla.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Bugme-new] [Bug 13976] New: viafb + vmalloc
Date: Fri, 14 Aug 2009 10:49:43 +0200 [thread overview]
Message-ID: <4A852527.7040705@gmx.de> (raw)
In-Reply-To: <FE2B7370-64DF-43D4-B0E3-C65EB1AD1986@gmail.com>
Roman Sergeev schrieb:
> 01:00.0 VGA compatible controller: VIA Technologies, Inc. P4M900 [Chrome
> 9 HC] (rev 01)
> with shadow ram (total 2Gb, but system see 1768Mb... maybe 280Mb)
This makes sense:
2 GB physical RAM
- 256 MB used as shared memory video RAM
= 1792 MB available
I don't know where the other memory is lost but the video memory size
seems to be detected correctly.
> after modprobe viafb don't die, they going to new state
> viafb 75212 1 - Loading 0xef642000
I don't know if I get you right here:
After "modprobe viafb viafb_accel=0" the module does no longer crash?
But I don't know what state you are talking about. Is the module usable?
(i.e. does "modprobe fbcon" give you a working framebuffer console?) Or
can you otherwise post a new log?
An alternative to disabling the hardware acceleration might be to
increase vmalloc=260M to a value greater than 256+16 MB, like
vmalloc=300MB or so.
Okay, I think I have a deeper understanding now:
- the driver tries to remap 256 MB (video framebuffer) and 16 MB (MMIO
registers)
- the free region is per default only 128 MB and is only on systems with
significant less physical RAM than kernel virtual memory space bigger
So in addition to handle the second ioremap failure (for which I have
already a patch prepared) one of the following might be nice
- add/reuse module/boot parameter to limit the available video memory size
- automatically try to remap smaller parts of the video memory if the
first ioremap fails
- after having checked the code again I think it uses very rarely the
remapped video memory. If I didn't miss a big thing after having my
recent patches applied there might be 2-3 places left that use a few
kilobytes of it. Nothing that justifies permanently remapping the whole
bunch. If no one speaks against it I'll try to replace this big remap
with one or two small ones. Though this might take a while.
Any comments?
Regards,
Florian Tobias Schandinat
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
next prev parent reply other threads:[~2009-08-14 8:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-13976-10286@http.bugzilla.kernel.org/>
2009-08-13 19:36 ` [Bugme-new] [Bug 13976] New: viafb + vmalloc Andrew Morton
2009-08-13 21:24 ` Florian Tobias Schandinat
2009-08-14 6:38 ` Roman Sergeev
2009-08-14 8:49 ` Florian Tobias Schandinat [this message]
2009-08-14 10:46 ` Roman Sergeev
2009-08-14 12:44 ` Florian Tobias Schandinat
2009-08-14 16:33 ` Roman Sergeev
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=4A852527.7040705@gmx.de \
--to=florianschandinat@gmx.de \
--cc=JosephChan@via.com.tw \
--cc=ScottFang@viatech.com.cn \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=sungeneral@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).