Pavel Roskin
2013-Sep-26 00:07 UTC
[Nouveau] Resource map sanity check fails after GRUB "keeps" the gfx mode
Hello! I'm getting this backtrace every time I boot: resource map sanity check conflict: 0xf0000000 0xf1ffffff 0xf1000000 0xf112bfff BOOTFB ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1 at /home/proskin/src/linux/arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() Info: mapping multiple BARs. Your kernel is fine. Modules linked in: CPU: 6 PID: 1 Comm: swapper/0 Not tainted 3.12.0-rc1-00021-g8f98ef7 #28 Hardware name: LENOVO 2441AA2/2441AA2, BIOS G5ET30WW (1.08 ) 06/01/2012 00000000000000ab ffff88040bca3818 ffffffff816a61ef 0000000000000072 ffff88040bca3868 ffff88040bca3858 ffffffff81083d1c ffff88040bca3878 ffffc90005300000 00000000f0000000 00000000f0000000 0000000002000000 Call Trace: [<ffffffff816a61ef>] dump_stack+0x46/0x58 [<ffffffff81083d1c>] warn_slowpath_common+0x8c/0xc0 [<ffffffff81083e06>] warn_slowpath_fmt+0x46/0x50 [<ffffffff81079512>] __ioremap_caller+0x372/0x380 [<ffffffff813a8de0>] ? nouveau_bar_create_+0x80/0xb0 [<ffffffff81079577>] ioremap_nocache+0x17/0x20 [<ffffffff813a8de0>] nouveau_bar_create_+0x80/0xb0 [<ffffffff813a984b>] nvc0_bar_ctor+0x4b/0x440 [<ffffffff813a733e>] nouveau_object_ctor+0x3e/0xf0 [<ffffffff813cdfd5>] nouveau_devobj_ctor+0x195/0x700 [<ffffffff813a733e>] nouveau_object_ctor+0x3e/0xf0 [<ffffffff813a7cf7>] nouveau_object_new+0x197/0x250 [<ffffffff81404a6d>] nouveau_drm_load+0x1cd/0x7a0 [<ffffffff8144203e>] ? device_register+0x1e/0x30 [<ffffffff81389206>] ? drm_sysfs_device_add+0x86/0xb0 [<ffffffff81387bed>] drm_get_pci_dev+0x13d/0x310 [<ffffffff812dd81b>] ? __pci_set_master+0x2b/0x90 [<ffffffff814041ca>] nouveau_drm_probe+0x25a/0x290 [<ffffffff812e3b89>] pci_device_probe+0x99/0xe0 [<ffffffff81444c9b>] driver_probe_device+0x7b/0x240 [<ffffffff81444f0b>] __driver_attach+0xab/0xb0 [<ffffffff81444e60>] ? driver_probe_device+0x240/0x240 [<ffffffff81442ede>] bus_for_each_dev+0x5e/0x90 [<ffffffff8144479e>] driver_attach+0x1e/0x20 [<ffffffff81444244>] bus_add_driver+0x104/0x2a0 [<ffffffff814455e4>] driver_register+0x64/0xf0 [<ffffffff81d0ee34>] ? ttm_init+0x62/0x62 [<ffffffff812e2b3b>] __pci_register_driver+0x4b/0x50 [<ffffffff81387ed5>] drm_pci_init+0x115/0x130 [<ffffffff81d0ee34>] ? ttm_init+0x62/0x62 [<ffffffff81d0ee77>] nouveau_drm_init+0x43/0x45 [<ffffffff8100023f>] do_one_initcall+0x3f/0x150 [<ffffffff81cd7f47>] kernel_init_freeable+0x138/0x1c7 [<ffffffff81cd7837>] ? do_early_param+0x86/0x86 [<ffffffff8169e590>] ? rest_init+0x80/0x80 [<ffffffff8169e59e>] kernel_init+0xe/0xf0 [<ffffffff816ad9ac>] ret_from_fork+0x7c/0xb0 [<ffffffff8169e590>] ? rest_init+0x80/0x80 ---[ end trace 0bc6b5945c0022a8 ]--- It is not showing if I enable GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub I'm attaching the kernel configuration and the kernel log for the good and the bad cases (with the timestamps stripped). There is one interesting part of the diff: --- dmesg.good 2013-09-25 08:41:35.814705791 -0400 +++ dmesg.bad 2013-09-25 09:41:01.972012919 -0400 @@ -174,12 +174,12 @@ CONFIG_RCU_FANOUT set to non-default value of 32 RCU dyntick-idle grace-period acceleration is enabled. NR_IRQS:4352 nr_irqs:744 16 -Console: colour VGA+ 80x25 +Console: colour dummy device 80x25 I believe GRUB does something to the videocard so that drivers/video/console/vgacon.c passes control to drivers/video/console/dummycon.c and that somehow confuses nouveau and makes it map multiple BARs in one call. Ironically, GRUB uses text mode on that system. Perhaps it cannot enable the GFX mode. Yet it must be doing something bad when passing control to the kernel. I'm using 32-bit Lubuntu 12.04 with a 64-bit kernel. The GRUB version is 1.99-21ubuntu3.10. The hardware is Lenovo ThinkPad W530, model 2441AA2. The BIOS is set to always use the discreet graphics. I can reproduce the problem on the current master branch of the nouveau repository, git://anongit.freedesktop.org/nouveau/linux-2.6 -- Regards, Pavel Roskin -------------- next part -------------- A non-text attachment was scrubbed... Name: config Type: application/octet-stream Size: 73680 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20130925/a9771ef6/attachment-0003.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.bad Type: application/octet-stream Size: 42326 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20130925/a9771ef6/attachment-0004.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.good Type: application/octet-stream Size: 39767 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20130925/a9771ef6/attachment-0005.obj>
Pavel Roskin
2013-Sep-26 22:37 UTC
[Nouveau] Resource map sanity check fails after GRUB "keeps" the gfx mode
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 :) sysfb_simplefb: mark BOOTFB resource as busy From: Pavel Roskin <proski at gnu.org> This fixes a warning when nouveau tries to allocate a larger iomem area: resource map sanity check conflict: 0xf0000000 0xf1ffffff 0xf1000000 0xf112bfff BOOTFB iomem_map_sanity_check() specifically excludes busy regions from checking. --- arch/x86/kernel/sysfb_simplefb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/sysfb_simplefb.c b/arch/x86/kernel/sysfb_simplefb.c index 22513e9..b7bb615 100644 --- a/arch/x86/kernel/sysfb_simplefb.c +++ b/arch/x86/kernel/sysfb_simplefb.c @@ -79,7 +79,7 @@ __init int create_simplefb(const struct screen_info *si, /* setup IORESOURCE_MEM as framebuffer memory */ memset(&res, 0, sizeof(res)); - res.flags = IORESOURCE_MEM; + res.flags = IORESOURCE_MEM | IORESOURCE_BUSY; res.name = simplefb_resname; res.start = si->lfb_base; res.end = si->lfb_base + len - 1; -- Regards, Pavel Roskin
Emil Velikov
2013-Sep-27 09:33 UTC
[Nouveau] 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
Maybe Matching Threads
- Resource map sanity check fails after GRUB "keeps" the gfx mode
- Resource map sanity check fails after GRUB "keeps" the gfx mode
- [Bug 69488] New: GF108 (NVC1) GPU lockup
- Resource map sanity check fails after GRUB "keeps" the gfx mode
- Resource map sanity check fails after GRUB "keeps" the gfx mode