Nouveau - Sep 2013 - 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>

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

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