From: Florian T. S. <Flo...@gm...> - 2009-08-14 08:49:49
|
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 |