David Herrmann
2013-Oct-03 23:08 UTC
[Nouveau] Resource map sanity check fails after GRUB "keeps" the gfx mode
Hi Pavel On Fri, Oct 4, 2013 at 12:10 AM, Pavel Roskin <proski at gnu.org> wrote:> Hi David, > > On Thu, 3 Oct 2013 00:19:56 +0200 > David Herrmann <dh.herrmann at gmail.com> wrote: > >> >> And your PCI-BAR adjustment doesn't change >> >> anything either, sorry. >> > >> > I simply tried another approach to pacify the resource checker. >> > >> > However, there is some difference. nvidiafb cannot access the >> > resources if IORESOURCE_BUSY is used. >> >> Are you sure this is related to IORESOURCE_BUSY? Or is it related to >> CONFIG_X86_SYSFB? > > 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.> 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?> 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: The resource.c resource-management allows creating sub-regions of existing regions. However, a sub-region must always be a real child of its parent, it cannot span multiple parents. Therefore, if we create the simplefb region before the pci BAR is mapped, we need your patches to bump the simplefb region to at least the size of the respective PCI region. Otherwise, nvidia tries allocating a sub-region that spans wider than the simplefb region and thus failing. On the other hand, sub-mappings of BUSY regions are _never_ allowed. A BUSY region gives exclusive access to the holder of the region. But dropping BUSY from the simplefb region is wrong. We have to mark the system-framebuffer as BUSY, otherwise we might end up with a corrupted framebuffer after loading other real hw drivers. 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. TL;DR To fix this, we want real hardware drivers to remove platform-framebuffer devices and release their resources before acquiring them again. I recommend CONFIG_X86_SYSFB=n for anyone seeing these issues. For 3.13 I will try to fix the framebuffer-handover. 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).> This complexity doesn't seem right. I think specific drivers should > trump generic once and DRI drivers should trump non-DRI. It shouldn't > matter whether the BOOTFP area from screen_info coincides with the PCI > BAR or occupies a part of it.I will try to write a patch as part of the SimpleDRM series which allows removing platform-framebuffer devices. We simply do this during framebuffer probing and we should be fine. Thanks David
Pavel Roskin
2013-Oct-04 22:11 UTC
[Nouveau] Resource map sanity check fails after GRUB "keeps" the gfx mode
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! -- Regards, Pavel Roskin -------------- next part -------------- A non-text attachment was scrubbed... Name: dm-busy-adjust Type: application/octet-stream Size: 39611 bytes Desc: not available URL: <lists.freedesktop.org/archives/nouveau/attachments/20131004/69a66737/attachment-0005.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: dm-busy-noadjust Type: application/octet-stream Size: 39586 bytes Desc: not available URL: <lists.freedesktop.org/archives/nouveau/attachments/20131004/69a66737/attachment-0006.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: dm-nobusy-adjust Type: application/octet-stream Size: 39684 bytes Desc: not available URL: <lists.freedesktop.org/archives/nouveau/attachments/20131004/69a66737/attachment-0007.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: dm-nobusy-noadjust Type: application/octet-stream Size: 42466 bytes Desc: not available URL: <lists.freedesktop.org/archives/nouveau/attachments/20131004/69a66737/attachment-0008.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel.config Type: application/octet-stream Size: 76349 bytes Desc: not available URL: <lists.freedesktop.org/archives/nouveau/attachments/20131004/69a66737/attachment-0009.obj>
David Herrmann
2013-Dec-18 14:14 UTC
[Nouveau] Resource map sanity check fails after GRUB "keeps" the gfx mode
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: 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
Seemingly Similar Threads
- Resource map sanity check fails after GRUB "keeps" the gfx mode
- Resource map sanity check fails after GRUB "keeps" the gfx mode
- Resource map sanity check fails after GRUB "keeps" the gfx mode
- Resource map sanity check fails after GRUB "keeps" the gfx mode
- Resource map sanity check fails after GRUB "keeps" the gfx mode