Re: Resource map sanity check fails after GRUB "keeps" the gfx mode

[Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 26/09/13 23:37, Pavel Roskin wrote:
> Hello!
> 
> I have spent some time on the issue.  I'm not sure it's a nouveau bug.
> I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only.
> 
> GRUB actually uses graphic mode on my card.  That mode is supported by
> simplefb.  However, the resource conflict happens regardless of whether
> simplefb is enabled.  It's sysfb_simplefb that causes it, a completely
> different driver.
> 
> If GRUB keeps the graphic mode, I have this entry in /proc/iomem:
> 
>       f1000000-f112bfff : BOOTFB
> 
> It is reserved by sysfb_simplefb.  Nouveau tries to map an area at
> 0xf0000000-0xf1ffffff, so it includes the existing resource without
> being equivalent to it.
> 
> Nouveau correctly calls remove_conflicting_framebuffers() before trying
> to map that resource.  However, sysfb_simplefb is not a real
> framebuffer, so it doesn't free its resources.
> 
> iomem_map_sanity_check() doesn't check regions with IORESOURCE_BUSY
> set.  That's the comment from the code:
> 
>     /*
>      * if a resource is "BUSY", it's not a hardware resource
>      * but a driver mapping of such a resource; we don't want
>      * to warn for those; some drivers legitimately map only
>      * partial hardware resources. (example: vesafb)
>      */
> 
> So I added IORESOURCE_BUSY to sysfb_simplefb.c and the problem is fixed
> now.  Actually, it prevents nvidiafb from claiming the device:
> 
> nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff
> 64bit pref]
> 
> But maybe that's the point of sysfb_simplefb?  Anyway, here's the
> patch/hack, signed off in case it's correct :)
> 
> 
FWIW another nvc0 user is experiencing the same/similar issue and the
patch seems to resolve the problem in his case.

https://bugs.freedesktop.org/show_bug.cgi?id=69488

Thanks Pavel :)


Cheers
Emil