All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org>
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	David Herrmann
	<dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: Resource map sanity check fails after GRUB "keeps" the gfx mode
Date: Thu, 26 Sep 2013 18:37:43 -0400	[thread overview]
Message-ID: <20130926183743.0d2420c4@IRBT4585> (raw)
In-Reply-To: <20130925200706.2e6f5947@IRBT4585>

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-mXXj517/zsQ@public.gmane.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

  reply	other threads:[~2013-09-26 22:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26  0:07 Resource map sanity check fails after GRUB "keeps" the gfx mode Pavel Roskin
2013-09-26 22:37 ` Pavel Roskin [this message]
2013-09-27  9:33   ` Emil Velikov
     [not found]     ` <524550E6.6040909-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-09-27 15:37       ` Pavel Roskin
2013-09-27 18:08         ` David Herrmann
     [not found]           ` <CANq1E4STGCp8X+i-OOd1KYCZQEoUeYuEw8=tkWuXY8_8wcieuw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-27 19:40             ` Pavel Roskin
     [not found]               ` <20130927154031.khkhbl17s0ow4sgc-cebfxv-2RFepEojUI3Rd1RZctBqVdHuzzzSOjJt@public.gmane.org>
2013-10-02 14:47                 ` David Herrmann
     [not found]                   ` <CANq1E4T6Wa5ReKqBd=-3fDKGs8frMCQ5RQxAOM19C4dnwL_sOA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-02 21:46                     ` Pavel Roskin
2013-10-02 22:19                       ` David Herrmann
     [not found]                         ` <CANq1E4TxPg5ZM6WxDZiqi_ZFsY-qqhh8C56aBgSDVKzqt0m2pg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-03 22:10                           ` Pavel Roskin
2013-10-03 23:08                             ` David Herrmann
     [not found]                               ` <CANq1E4Sib6+Z4H3B-DnsB_Eqk4X7ni2Ttj6AgW9gBKcaBf=z6w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-04 22:11                                 ` Pavel Roskin
2013-12-18 14:14                                   ` David Herrmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130926183743.0d2420c4@IRBT4585 \
    --to=proski-mxxj517/zsq@public.gmane.org \
    --cc=dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.