Bug 66726

This happens at boot-up, not when running a testcase. It's a new check added with

commit 15fdeefeb69a3a21fb483d1621517c2c8e0cf31a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jul 4 12:28:35 2013 +0100

    drm/i915: Verify that our stolen memory doesn't conflict

Can you please attach the contents of /proc/iomem for this machine?

Created attachment 82213 [details]
iomem

In this case, the memory region should be reserved I think by

[    0.766505] pci_bus 0000:00: root bus resource [mem 0x7f700000-0xffffffff]

So it is a genuine busy, and we should try and filter this warning. Or somehow make a child resource of it.

(In reply to comment #3)
> In this case, the memory region should be reserved I think by
> 
> [    0.766505] pci_bus 0000:00: root bus resource [mem 0x7f700000-0xffffffff]
> 
> So it is a genuine busy, and we should try and filter this warning. Or
> somehow make a child resource of it.

The following explicit resources are in that range:

  7f700000-7f8fffff : PCI Bus 0000:01
  7f900000-7f900fff : Intel Flush Page
  7f904000-7f907fff : i915 MCHBAR

That feels like a real conflict, or alternatively our flush page setup in intel-gtt.c is totally bogus. I'll attach the patch to rework the stolen detection to check this.

Created attachment 82230 [details] [review]
fixup stolen detection on pnv

Please test this patch.

Adding Paulo since he reported a conflict on his hsw machine, too.

Fyi I've moved the stolen range request_region check from -fixes to dinq. There's simply too much fallout to dump it into -fixes right now. We need to tackle those issues first.

Created attachment 82236 [details] [review]
dump conflicting region

Please apply this debug patch to a broken kernel and then please attach dmesg from booting it. Hopefully this explains why the request_region fails.

Created attachment 82253 [details]
dmesg with patch

Test with the patch.
*ERROR* conflict detected with stolen region: [0x7f800000 - 0x80000000] goes away.

Following error in dmesg:
 dmesg | grep ERROR
[   25.794381] rmmod[3343]: ERROR: Module scsi_wait_scan does not exist in /proc/modules
[   25.821654] rmmod[3348]: ERROR: Module scsi_wait_scan does not exist in /proc/modules

(In reply to comment #9)
> Created attachment 82253 [details]
> dmesg with patch
> 
> Test with the patch.
> *ERROR* conflict detected with stolen region: [0x7f800000 - 0x80000000] goes
> away.

Is this really on latest -nightly? Note that I've removed the patch which caused this ERROR output from -fixes, so if you used that as a baseline then you need to retest.

(In reply to comment #9)
> Created attachment 82253 [details]
> dmesg with patch
> 
> Test with the patch.
> *ERROR* conflict detected with stolen region: [0x7f800000 - 0x80000000] goes
> away.
> 
> Following error in dmesg:
>  dmesg | grep ERROR
> [   25.794381] rmmod[3343]: ERROR: Module scsi_wait_scan does not exist in
> /proc/modules
> [   25.821654] rmmod[3348]: ERROR: Module scsi_wait_scan does not exist in
> /proc/modules

Sorry, Test on -dinq kernel.

It also happens on SNB.

Test on -nightly branch with the patch, It still exists.

-nightly commit: 88de8dd7d0415bf7a13df6cfdf15a612dcde822f(Merge: 09fa6ed 18097b9).

dmesg -r | egrep "<[1-3]>" |grep drm
<3>[    1.006430] [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: [0xcba00000 - 0xcfa00000]

Created attachment 82256 [details]
dmesg

Created attachment 82259 [details] [review]
dump conflicting region v2

Oops, the debug patch was broken and didn't actually dump the information we're interested in. Can you please apply this updated patch on top of latest -nightly and grab a new dmesg?

Created attachment 82316 [details]
dmesg

Test with the patch, It still happens.

Ignoring that I fail at printf we have

conflict with resource 0xcb000000 - 0xcbffffff: RAM buffer, flags=0x80000000 (IORESOURCE_BUSY)

[drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: [0xcba00000 - 0xcfa00000]

But that's now on an snb machine, which makes this bug report massively confusing, since those values don't match up at all for PNV.

Lu Hua can you please file a new bug report for SNB? Please attach debug dmesg with the debug patch (I'll attach a v3 shortly with fixed up output) and /proc/iomem

We need to restrict ourselves to this specific pnv machine here to avoid confusion.

Created attachment 82326 [details] [review]
debug patch v3

Please use this patch here to grab a new drm debug dmesg for both this bug report (about pnv) and the new bug report for snb.

Thanks, Daniel

Created attachment 82360 [details]
dmesg with debug patch v3

Reported Bug 66844 about SNB.

This still loosk like a legit conflict ... I guess we should disable stolen if we detect such a case.

Jesse Barnes volunteered to write an rfc patch to reserve stolen in early platform code and submit it to the x86 maintainers for feedback.

Can you try these two patches and then post your dmesg and /proc/iomem again?

http://lists.freedesktop.org/archives/intel-gfx/2013-July/030775.html
http://lists.freedesktop.org/archives/intel-gfx/2013-July/030774.html

It doesn't happen on drm-intel-fixes kernel(363202bb22467ea1de6dd2).
Close it.

Verified.Fixed.

The patch which detects stolen conflicts is moved to dinq, and the bug should still be there. Please recheck that and then test the two patches from Jesse.

(In reply to comment #21)
> Can you try these two patches and then post your dmesg and /proc/iomem again?
> 
> http://lists.freedesktop.org/archives/intel-gfx/2013-July/030775.html
> http://lists.freedesktop.org/archives/intel-gfx/2013-July/030774.html

Fixed by these 2 patches.

Created attachment 82981 [details]
dmesg with patch 030775/030774

Created attachment 82982 [details]
iomem with patch 030775/030774

Should be fixed on dinq with

commit ee75f952998e8365da90300cf1d421fc6c7dafa2
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Jul 26 13:32:52 2013 -0700

    x86: add early quirk for reserving Intel graphics stolen memory v5

Verified.Fixed.

Closing old verified.