linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).