Created attachment 82209 [details] dmesg System Environment: -------------------------- Platform: Pineview Kernel: drm-intel-fixes 8bbbb45b2125a28ea1de657e7893a521b44b60c3 Bug detailed description: ----------------------------- It happens on pineview with drm-intel-fixes kernel, It works well on drm-intel-next-queued kernel. The first bad commit could be any of: 035dc1e0f9008b48630e02bf0eaa7cc547416d1d 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e 15fdeefeb69a3a21fb483d1621517c2c8e0cf31a output: Using 768 1MiB buffers Verifying initialisation...done Cyclic blits, forward...verifying...done Cyclic blits, backward...verifying...done Random blits...verifying...done Reproduce steps: ---------------------------- 1. ./gen3_render_mixed_blits
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
Closing old verified.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.