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
next prev parent 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.