Hi Pavel On Sat, Oct 5, 2013 at 12:11 AM, Pavel Roskin <[email protected]> wrote: > On Fri, 4 Oct 2013 01:08:34 +0200 > David Herrmann <[email protected]> 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 _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
