[Nouveau] Resource map sanity check fails after GRUB "keeps" the gfx mode

[David Herrmann]

Hi Pavel

On Sat, Oct 5, 2013 at 12:11 AM, Pavel Roskin <proski at gnu.org> wrote:
> On Fri, 4 Oct 2013 01:08:34 +0200
> David Herrmann <dh.herrmann at gmail.com> wrote:
>
>> > CONFIG_X86_SYSFB is always defined.  I doubt an x86 kernel would
>> > compile without it.  create_simplefb() is used in
>> > arch/x86/kernel/sysfb.c that is compiled unconditionally and that
>> > function is defined in arch/x86/kernel/sysfb_simplefb.c that is only
>> > compiled if CONFIG_X86_SYSFB is defined.
>>
>> You can set CONFIG_X86_SYSFB=n and everything works fine. It's the
>> default and is what pre-3.12 kernels always did.
>
> Of course, you are right, I missed sysfb.h.
>
>> > I tried four combinations: with and without IORESOURCE_BUSY and with
>> > and without the PCI resource adjustment.  The only combination when
>> > nvidiafb probes the hardware is when IORESOURCE_BUSY is not used and
>> > the BOOTFP resource is adjusted to match the PCI BAR.
>>
>> A dmesg log would be nice, but I assume nvidiafb fails because it
>> cannot map its BAR regions?
>
> The logs are adjusted and so it the kernel config file.
>
> $ grep nvidiafb *
> dm-busy-adjust:nvidiafb_setup START
> dm-busy-adjust:nvidiafb_probe START
> dm-busy-adjust:nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem
> 0xf0000000-0xf1ffffff 64bit pref] dm-busy-adjust:nvidiafb: cannot
> request PCI regions dm-busy-noadjust:nvidiafb_setup START
> dm-busy-noadjust:nvidiafb_probe START
> dm-busy-noadjust:nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem
> 0xf0000000-0xf1ffffff 64bit pref] dm-busy-noadjust:nvidiafb: cannot
> request PCI regions dm-nobusy-adjust:nvidiafb_setup START
> dm-nobusy-adjust:nvidiafb_probe START
> dm-nobusy-adjust:nvidiafb: Device ID: 10de0ffc
> dm-nobusy-adjust:nvidiafb: unknown NV_ARCH
> dm-nobusy-noadjust:nvidiafb_setup START
> dm-nobusy-noadjust:nvidiafb_probe START
> dm-nobusy-noadjust:nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem
> 0xf0000000-0xf1ffffff 64bit pref] dm-nobusy-noadjust:nvidiafb: cannot
> request PCI regions
>
> The error comes from pci_request_regions() called in
> drivers/video/nvidia/nvidia.c
>
>> > It means that your patch by itself won't prevent nvidiafb from
>> > getting the resource on my hardware (ThinkPad W530).  However, if
>> > the BOOTFP resource matches the PCI BAR for the video card, adding
>> > IORESOURCE_BUSY might prevent some framebuffer drivers from
>> > accessing the resource.
>>
>> Meh! I now understand the problem:
>
> Great!
>
>> In other words: The fact that we used to not reserve
>> platform-framebuffer regions before 3.12 trips us now because it is
>> actually _wrong_ to load real hw drivers like nvidiafb while the
>> platform-framebuffer is still available. So the failure we get now
>> just tells us that nvidiafb and friends do horrible things.
>
> I actually hoped to hear from you something like that.  It's good to
> have limitations if they are well understood and not arbitrary.
>
>> Fortunately, no real DRM drivers actually request pci regions (why
>> would they? pci-probing already guarantees exclusive access) and the
>> platform-FB drivers have already been converted. So this bug can only
>> be triggered with legacy hw-fbdev drivers (a simple search for
>> pci_request_regions in ./drivers/video/ shows them).
>
> It's very reassuring.  Your work is greatly appreciated!

2 months late, but there's a patch pending on LKML:
http://thread.gmane.org/gmane.linux.kernel/1616367/focus=1616583

This should fix your issues as it removes simple-framebuffer devices
on remove_conflicting_framebuffers() now.

Thanks
David