Nouveau - Sep 2013 - Resource map sanity check fails after GRUB "keeps" the gfx mode

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

On Fri, 27 Sep 2013 10:33:26 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 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
Good to hear that my patch actually makes more than cosmetic difference
for somebody.  My system doesn't hang even with the stack trace.  

I posted another patch on the bug page.  It widens the BOOTFB resource
to match the PCI BAR instead of making it busy. With the new patch,
nvidiafb doesn't report that the resource is busy, it reports
unsupported hardware, which is true.

Old patch:
nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff
64bit pref]
nvidiafb: cannot request PCI regions

New patch:
nvidiafb: Device ID: 10de0ffc
nvidiafb: unknown NV_ARCH

I'll send the patch to x86 at kernel.org, it's clearly not an nvidia
issue.

-- 
Regards,
Pavel Roskin

Hi

On Fri, Sep 27, 2013 at 5:37 PM, Pavel Roskin <proski at gnu.org>
wrote:
> On Fri, 27 Sep 2013 10:33:26 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> 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
>
> Good to hear that my patch actually makes more than cosmetic difference
> for somebody.  My system doesn't hang even with the stack trace.
I am aware of this and there is already a fix pending from 2 weeks
ago. Unfortunately, I have been in the US for the last 2 weeks and
haven't really been able to push on that. Anyhow, it should really be
just a cosmetic issue. We need to mark the sysfb FB as busy to avoid
the nasty warnings. Other than that, this shouldn't cause any issues.

Thanks
David
> I posted another patch on the bug page.  It widens the BOOTFB resource
> to match the PCI BAR instead of making it busy. With the new patch,
> nvidiafb doesn't report that the resource is busy, it reports
> unsupported hardware, which is true.
>
> Old patch:
> nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff
> 64bit pref]
> nvidiafb: cannot request PCI regions
>
> New patch:
> nvidiafb: Device ID: 10de0ffc
> nvidiafb: unknown NV_ARCH
>
> I'll send the patch to x86 at kernel.org, it's clearly not an
nvidia issue.
>
> --
> Regards,
> Pavel Roskin