Re: [PATCH] Resource management for fbdev.

[Miles Lane <miles.lane@gmail.com>]

Is this video memory issue related to the problem I reported with
nvidiafb requiring too much (128M) memory at boot time?  I have had to
set vmalloc=256M to get my machine to boot using nvidiafb.  I am
testing on a AMD Athlon machine.

Randy Dunlap wrote:
>I started looking at vmalloc() and what it calls (which is
> __get_vm_area).  _get_vm_area() always allocates one extra
> page (called a "guard page") between all vmalloc allocations,
> so even though 128 MB is the default amount and the amount
> that nvidiafb wants to use, the kernel wants to allocate
> 128 MB + PAGE_SIZE (4 KB on x86; are you on x86?), so even
> if nvidiafb is the only caller, the vmalloc() call will fail.

Booting with vmalloc=256M works, but Andrew Morton thinks that
nvidiafb should not be requiring 128M in the first place.

Thanks,
           Miles

On Apr 7, 2005 6:52 PM, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sat, 2005-03-26 at 00:34 +0000, James Simmons wrote:
> > I have a new resource management for testing. Its is a clenaup of the
> > handling the drawing plane and the cursor. I have tested it on
> >
> > New NVIDIA fbdev driver.
> > NeoMagic
> > ATY Mach64
> > Radeon
> > Vesa
> >
> > Please try it out. The patch is over 40K so grab it from the below link
> >
> > http://www.infradead.org/~jsimmons/resource.diff
> 
> I had a quick look, and I'm fairly confused. That patch introduces a lot
> of changes all over the place without any comment or explanation, in
> code that has proven in the past to be fragile and prone to side
> effects. Also, I see no explanation of the rationale for the resource
> manager and it's API. At a minimum, the patch should be split into
> 
>  - implementation of the resource manager with appropriate explanations
> and documentation
>  - driver updates
> 
> Have you worked at all with the DRM folks ? We have a bad need to merge
> DRM and fbdev as soon as possible and we need while doing so to impement
> some kind of efficient memory manager for the card video RAM. I'm not
> sure your proposal fits into this picture.
> 
> Also, we need to properly deal with the fact that real soon now, not all
> of the video memory will be accessible from the CPU (not only from the
> kernel, but from the CPU in general). There are already cards whose PCI
> aperture is too small to enclose the entire video memory, and some funky
> issues with aperture control on radeons might make me also limit the
> amount of video memory accessible.
> 
> Ben.
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click