[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #13 from Tom Stellard 2011-01-28 00:20:29 PST --- I'm pretty sure this is a bug in the scheduler. I'm attaching screenshots comparing running with this patch: https://bugs.freedesktop.org/attachment.cgi?id=42514 to running with RADEON_DEBUG=noopt. The screenshots look very similar, but I think the shadow with RADEON_DEBUG=noopt is darker. As for performance difference between RADEON_DEBUG=noopt and with optimizations. I think we are seeing this because Lightsmark compiles new shaders while running the benchmark and the longer compile time for optimized shaders is lowering the FPS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #14 from Tom Stellard 2011-01-28 00:21:18 PST --- Created an attachment (id=42626) --> (https://bugs.freedesktop.org/attachment.cgi?id=42626) Screenshot with RADEON_DEBUG=noopt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #15 from Tom Stellard 2011-01-28 00:22:12 PST --- Created an attachment (id=42627) --> (https://bugs.freedesktop.org/attachment.cgi?id=42627) Screenshot with scheduler patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.
On Thu, Jan 27, 2011 at 10:28:45AM +0100, Thomas Hellstrom wrote: > Konrad, Dave > > Given our previous discussion on the list, I believe these patches > shouldn't introduce any regressions in the non-Xen case, however we > should probably be prepared to back them out quickly if that turns > out to be the case... Absolutly. I've rebased the patches with your review comments (thought I am not seeing the indentation issues in the source code - not sure why?). Stuck the patches on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/ttm.pci-api.v4 Let me ask some of the radeon drivers to take a look at the radeon/ttm/PCIe: Use dma_addr if TTM has set it. patch. Thank you very much for taking a look at the patches! -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #16 from Pavel Ondračka 2011-01-28 00:53:06 PST --- I'm puzzled, because here with mesa master + disable scheduler rewrite patch, I get the wrong behavior (right part of https://bugs.freedesktop.org/attachment.cgi?id=42516 ). However your screenshot in Comment 15 looks almost completely good. To be sure I did once again git clean -fdx, git reset --hard origin/master, patch again and recompile, but nothing changed. Some hardware difference or my setup is broken? Maybe someone with the same card as mine (RV530) can test your patch to confirm if it indeed fixes the shadows? Any chance you have also some other patches applied? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned?
On Thu, 27 Jan 2011 17:33:04 -0500 (EST), "Robert P. J. Day" wrote: > > one more observation which should nail things down: > > On Thu, 27 Jan 2011, Robert P. J. Day wrote: > > > ok, i'm getting different results from this morning, not sure why, > > but i'm fairly confident i've isolated it to this extent. here's the > > salient part of the git log i'm looking at: > > > > = git log = > > > > commit abb72c828878a2c69b2cfb33ac30007c8ecd735e > > Merge: 58bbf01 8e934db > > Author: Dave Airlie > > Date: Tue Jan 25 08:41:58 2011 +1000 > > > > Merge branch 'drm-intel-fixes-2' of > > ssh://master.kernel.org/pub/scm/linux/kernel/g > > > > * 'drm-intel-fixes-2' of > > ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr > > drm/i915: Prevent uninitialised reads during error state capture > > drm/i915: Use consistent mappings for OpRegion between ACPI and i915 > > drm/i915: Handle the no-interrupts case for UMS by polling > > drm/i915: Disable high-precision vblank timestamping for UMS > > drm/i915: Increase the amount of defense before computing vblank > > timestamps > > drm/i915,agp/intel: Do not clear stolen entries > > Remove MAYBE_BUILD_BUG_ON > > BUILD_BUG_ON: make it handle more cases > > module: fix missing semicolons in MODULE macro usage > > param: add null statement to compiled-in module params > > module: fix linker error for MODULE_VERSION when !MODULE and > > CONFIG_SYSFS=n > > module: show version information for built-in modules in sysfs > > selinux: return -ENOMEM when memory allocation fails > > tpm: fix panic caused by "tpm: Autodetect itpm devices" > > TPM: Long default timeout fix > > trusted keys: Fix a memory leak in trusted_update(). > > keys: add trusted and encrypted maintainers > > encrypted-keys: rename encrypted_defined files to encrypted > > trusted-keys: rename trusted_defined files to trusted > > drm/i915: Recognise non-VGA display devices > > ... > > > > commit 58bbf018a70c562437eeae121a5d021ba7fe56a5 > > Author: Alex Deucher > > Date: Mon Jan 24 17:14:26 2011 -0500 > > > > drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq > > > > Needed for timer queries in the 3D driver. > > > > Signed-off-by: Alex Deucher > > Signed-off-by: Dave Airlie > > > > = git log = > > > > now: > > > > * commit 58bbf018 appears to be fine, boots reliably > > * commit 8e934dbf causes black screen issue > > > > as you can see, rather than test the *merge* above, i decided to back > > up one level and test the commit that was part of that merge, and it > > failed. is this helpful? here's the log entry: > > > > commit 8e934dbf264418afe4d1dff34ce074ecc14280db > > Author: Chris Wilson > > Date: Mon Jan 24 12:34:00 2011 + > > > > drm/i915: Prevent uninitialised reads during error state capture > > > > error_bo and pinned_bo could be used uninitialised if there were no > > active buffers. > > > > Caught by kmemcheck. > > > > Signed-off-by: Chris Wilson > > > > > > i'm going to go on and test the merge itself, abb72c82, since i > > thought that was working fine earlier today. but you can see which > > commit now seems to fail. does this make any sense? > > i did indeed test commit abb72c82 (the merge of the above), and it > failed. not sure why i posted earlier today that it worked, i must > have built something incorrectly. so, in conclusion: > > * commit 58bbf018 appears to be fine, boots reliably > * commit 8e934dbf causes black screen issue > * commit abb72c82 also causes black screen issue > > and on that note, signing off for the evening. > > rday > > -- > > > Robert P. J. Day Waterloo, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > From: Chris Wilson Subject: Re: has the i915 "black screen" boot issue returned? To: "Robert P. J. Day" Cc: dri-devel@lists.freedesktop.org Bcc: ch...@chris-wilson.co.uk In-Reply-To: References: <1bdc18$jdg...@fmsmga002.fm.intel.com> <0d30dc$kso...@orsmga001.jf.intel.com> On Thu, 27 Jan 2011 16:39:20 -0500 (EST), "Robert P. J. Day" wrote: > ok, i'm getting different results from this morning, not sure why, > but i'm fairly confident i've isolated it to this extent. here's the > salient part of the git log i'm looking at: Well, we have two endpoints, so let git attack: $ git bisect start $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e That shouldn't take more than a few recompiles
[Bug 32296] [r300g] Screen corruption with WoW when HyperZ enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=32296 Fabio Pedretti changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from Fabio Pedretti 2011-01-28 01:00:19 PST --- I am still seeing the white clouds but I suspect they are related to the zigzagged edges which seems to be a know issue. Also no more lockups. My card: r300: DRM version: 2.7.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2 r300: GART size: 509 MB, VRAM size: 256 MB r300: AA compression: NO, Z compression: YES, HiZ: YES Closing since Chris problem is fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned?
On Fri, 28 Jan 2011, Chris Wilson wrote: > Well, we have two endpoints, so let git attack: > > $ git bisect start > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e > > That shouldn't take more than a few recompiles to identify the > troublemaker. ok, i can get to that in a bit. might take a while since this system is not exactly a screamer but i'm curious -- have you heard no other reports of people running into this issue? i'm going to be embarrassed if it turns out it's something *i've* done but, at this point, it seems fairly reproducible. are there any kernel command-line parms i might try that would be informative? anything involving modesetting? rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned?
On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day" wrote: > On Fri, 28 Jan 2011, Chris Wilson wrote: > > > Well, we have two endpoints, so let git attack: > > > > $ git bisect start > > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 > > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e > > > > That shouldn't take more than a few recompiles to identify the > > troublemaker. > > ok, i can get to that in a bit. might take a while since this > system is not exactly a screamer but i'm curious -- have you heard no > other reports of people running into this issue? i'm going to be > embarrassed if it turns out it's something *i've* done but, at this > point, it seems fairly reproducible. This is the first I'm aware of. It could just be the tip of the iceberg... > are there any kernel command-line parms i might try that would be > informative? anything involving modesetting? Sure: add drm.debug=0xe to your boot parameters (or to your modprobe conf). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #17 from Tom Stellard 2011-01-28 01:36:08 PST --- The right side of this screenshot that you posted: https://bugs.freedesktop.org/attachment.cgi?id=42516 Looks a lot like what I see when I disable the reg rename pass. I've double checked the results with the scheduler patch and they are the same as the screenshot I posted. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32945] Lower part of the screen corrupt with HyperZ enabled
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #15 from Marek Olšák 2011-01-28 03:08:44 PST --- If the latest commits don't help, please add the following line at the end of r300_chipset.c and test again: caps->hiz_ram = 0; -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned?
On Fri, 28 Jan 2011, Chris Wilson wrote: > Well, we have two endpoints, so let git attack: > > $ git bisect start > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e > > That shouldn't take more than a few recompiles to identify the > troublemaker. it appears i have one bisection left to make but, just a bit of info, the black screen issue kicks in when the kernel tries to change the font size of the early kernel messages to a much smaller font (or at least it happens around that time). typically, regardless of the kernel, i get a couple of large font messages (/dev/pts and one other, memory fails me), at which point a good kernel will switch to a much smaller font and continue. with a "bad" kernel, the display on my laptop goes black and stays that way, despite the fact that the boot is obviously still progressing. you can decide if that is at all helpful. back to bisecting. should be getting close. rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #18 from Pavel Ondračka 2011-01-28 03:42:50 PST --- (In reply to comment #17) > The right side of this screenshot that you posted: > https://bugs.freedesktop.org/attachment.cgi?id=42516 > Looks a lot like what I see when I disable the reg rename pass. > > I've double checked the results with the scheduler patch and they are the same > as the screenshot I posted. This is getting weird, because Marek in comment 12 mentioned that the penumbra shadows are rendered correctly with register rename pass disabled. I guess he also have RV530? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32945] Lower part of the screen corrupt with HyperZ enabled
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #16 from Sven Arvidsson 2011-01-28 04:38:04 PST --- No change with the latest commits, but caps->hiz_ram = 0; makes the problem go away. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33648] New: Black line in Lightsmark with Z compression enabled (RV530)
https://bugs.freedesktop.org/show_bug.cgi?id=33648 Summary: Black line in Lightsmark with Z compression enabled (RV530) Product: Mesa Version: git Platform: Other URL: http://dee.cz/lightsmark/Lightsmark2008.2.0.tar.bz2 OS/Version: All Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: dra...@centrum.cz After recent zbuffer compression rework Lightsmark is the only remaining app I've tested which is still not working properly here on RV530. There is a thick black line across the screen in some scenes, particularly: "no radiosity","soft shadows", "penumbra shadows" and the last scene. Maybe this is a known issue and there are many open bugs about HyperZ, however according to db299a9f8244d53d9041fcdbd396a77ebe1f9e3e comment RV530 should just work. So I'm reporting it isn't. Also this is not a regression, it was much worse before and this is the only remaining issue here. To be sure this isn't HiZ issue I've changed line 367 in r300_chipset.c to "caps->hiz_ram = 0;" and it haven't changed anything. r300: AA compression: NO, Z compression: YES, HiZ: NO -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote: > On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day" > wrote: > > On Fri, 28 Jan 2011, Chris Wilson wrote: > > > > > Well, we have two endpoints, so let git attack: > > > > > > $ git bisect start > > > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 > > > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e > > > > > > That shouldn't take more than a few recompiles to identify the > > > troublemaker. > > > > ok, i can get to that in a bit. might take a while since this > > system is not exactly a screamer but i'm curious -- have you heard no > > other reports of people running into this issue? i'm going to be > > embarrassed if it turns out it's something *i've* done but, at this > > point, it seems fairly reproducible. > > This is the first I'm aware of. It could just be the tip of the iceberg... the git bisection finally resolved to: BAD: b705120e GOOD: 8a327f23 so the culprit appears to be: b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit commit b705120e4198315f4ae043de06c62f65e0851fd3 Author: Michael Karcher Date: Sun Jan 23 18:17:17 2011 + drm/i915: Use consistent mappings for OpRegion between ACPI and i915 The opregion is a shared memory region between ACPI and the graphics driver. As the ACPI mapping has been changed to cachable in commit 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion non-cachable now fails. As no bus-master hardware is involved in the opregion, cachable map should do no harm. Tested on a Fujitsu Lifebook P8010. Signed-off-by: Michael Karcher [ickle: convert to acpi_os_ioremap for consistency] Signed-off-by: Chris Wilson thoughts? once again, the salient output from "lspci -v": 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Device 031c Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at d000 (64-bit, non-prefetchable) [size=4M] Memory at c000 (64-bit, prefetchable) [size=256M] I/O ports at 3050 [size=8] Expansion ROM at [disabled] Capabilities: Kernel driver in use: i915 Kernel modules: i915 rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33648] Black line in Lightsmark with Z compression enabled (RV530)
https://bugs.freedesktop.org/show_bug.cgi?id=33648 --- Comment #1 from Pavel Ondračka 2011-01-28 05:54:33 PST --- Created an attachment (id=42642) --> (https://bugs.freedesktop.org/attachment.cgi?id=42642) screenshot -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day"
wrote:
> so the culprit appears to be:
>
> b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> commit b705120e4198315f4ae043de06c62f65e0851fd3
> Author: Michael Karcher
> Date: Sun Jan 23 18:17:17 2011 +
>
> drm/i915: Use consistent mappings for OpRegion between ACPI and i915
>
> The opregion is a shared memory region between ACPI and the graphics
> driver. As the ACPI mapping has been changed to cachable in commit
> 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> non-cachable now fails. As no bus-master hardware is involved in the
> opregion, cachable map should do no harm.
>
> Tested on a Fujitsu Lifebook P8010.
>
> Signed-off-by: Michael Karcher
> [ickle: convert to acpi_os_ioremap for consistency]
> Signed-off-by: Chris Wilson
>
>
> thoughts? once again, the salient output from "lspci -v":
Indeed looks like using ioremap_cache is not as safe as was assumed. Does
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
index 7180013..42108ab 100644
--- a/include/linux/acpi_io.h
+++ b/include/linux/acpi_io.h
@@ -7,7 +7,7 @@
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
- return ioremap_cache(phys, size);
+ return ioremap_wc(phys, size);
}
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
fix your boot issue or do we need to go back to using uncached:
+ return ioremap(phys, size);
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day"
> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author: Michael Karcher
> > Date: Sun Jan 23 18:17:17 2011 +
> >
> > drm/i915: Use consistent mappings for OpRegion between ACPI and i915
> >
> > The opregion is a shared memory region between ACPI and the graphics
> > driver. As the ACPI mapping has been changed to cachable in commit
> > 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> > non-cachable now fails. As no bus-master hardware is involved in the
> > opregion, cachable map should do no harm.
> >
> > Tested on a Fujitsu Lifebook P8010.
> >
> > Signed-off-by: Michael Karcher
> > [ickle: convert to acpi_os_ioremap for consistency]
> > Signed-off-by: Chris Wilson
> >
> >
> > thoughts? once again, the salient output from "lspci -v":
>
> Indeed looks like using ioremap_cache is not as safe as was assumed. Does
*sigh*. there was, in fact, an "ioremap_error" message displayed
*very* early in the boot sequence, but it was generated even for
successful boots so i never paid it any mind. in hindsight, might
have been useful to have mentioned it.
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7180013..42108ab 100644
> --- a/include/linux/acpi_io.h
> +++ b/include/linux/acpi_io.h
> @@ -7,7 +7,7 @@
> static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> acpi_size size)
> {
> - return ioremap_cache(phys, size);
> + return ioremap_wc(phys, size);
> }
>
> int acpi_os_map_generic_address(struct acpi_generic_address *addr);
ok, i'll make this single change and report back shortly.
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day"
> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author: Michael Karcher
> > Date: Sun Jan 23 18:17:17 2011 +
> >
> > drm/i915: Use consistent mappings for OpRegion between ACPI and i915
> >
> > The opregion is a shared memory region between ACPI and the graphics
> > driver. As the ACPI mapping has been changed to cachable in commit
> > 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> > non-cachable now fails. As no bus-master hardware is involved in the
> > opregion, cachable map should do no harm.
> >
> > Tested on a Fujitsu Lifebook P8010.
> >
> > Signed-off-by: Michael Karcher
> > [ickle: convert to acpi_os_ioremap for consistency]
> > Signed-off-by: Chris Wilson
> >
> >
> > thoughts? once again, the salient output from "lspci -v":
>
> Indeed looks like using ioremap_cache is not as safe as was assumed. Does
>
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7180013..42108ab 100644
> --- a/include/linux/acpi_io.h
> +++ b/include/linux/acpi_io.h
> @@ -7,7 +7,7 @@
> static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> acpi_size size)
> {
> - return ioremap_cache(phys, size);
> + return ioremap_wc(phys, size);
> }
>
> int acpi_os_map_generic_address(struct acpi_generic_address *addr);
that didn't appear to make a difference. same black screen issue.
BTW, here's an excerpt from /var/log/dmesg for a *successful* boot (i
just rebooted to 8a327f23):
...
[ 24.037114] intel ips :00:1f.6: failed to get i915 symbols, graphics
turbo disabled
...
[ 27.155660] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 27.155665] i915 :00:02.0: setting latency timer to 64
[ 27.217407] mtrr: no more MTRRs available
[ 27.217411] [drm] MTRR allocation failed. Graphics performance may suffer.
[ 27.217848] ioremap error for 0xb3752000-0xb3755000, requested 0x10, got 0x0
[ 27.217933] i915 :00:02.0: irq 42 for MSI/MSI-X
[ 27.217938] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 27.217940] [drm] Driver supports precise vblank timestamp query.
...
if any of that is of any use.
> fix your boot issue or do we need to go back to using uncached:
>
> + return ioremap(phys, size);
is that the next change you want me to try?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33139] Radeon HD 5750 locks up when using 3D apps with r600g
https://bugs.freedesktop.org/show_bug.cgi?id=33139 --- Comment #6 from Benjamin Franzke 2011-01-28 06:36:27 PST --- (In reply to comment #5) > Created an attachment (id=42615) View: https://bugs.freedesktop.org/attachment.cgi?id=42615 Review: https://bugs.freedesktop.org/review?bug=33139&attachment=42615 > possible fix > > Does this drm patch help? fixes it here (tested with 2.6.37+patch on an HD 5770). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day" wrote: > > fix your boot issue or do we need to go back to using uncached: > > > > + return ioremap(phys, size); > > is that the next change you want me to try? Yes. (Replacing the current return ioremap_*(phys, size).) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] radeon/ttm/PCIe: Use dma_addr if TTM has set it.
On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
>> If the TTM layer has used the DMA API to setup pages that are
>> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
>> array for pages that are to in DMA32 pool."), lets use it
>> when programming the GART in the PCIe type cards.
>>
>> This patch skips doing the pci_map_page (and pci_unmap_page) if
>> there is a DMA addresses passed in for that page. If the dma_address
>> is zero (or DMA_ERROR_CODE), then we continue on with our old
>> behaviour.
>
> Hey Jerome,
>
> I should have CC-ed you earlier but missed that and instead just
> CC-ed the mailing list. I was wondering what your thoughts are
> about this patchset? Thomas took a look at the patchset and he is OK
> but more eyes never hurt.
>
> FYI, for clarity I hadn't made the old calls that got moved due
> to adding of "{" checkpatch.pl compliant. It complains about it being
> past 80 characters. I can naturally fix that up, but thought
> that it might detract from the nature of the patch.
What happen when we don't ask dma32 alloc to ttm ? Will this still
work in virtualized environnement ?
Code looks good but GART stuff can be picky, i will try to do a full
scale testing in next couple week.
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day"
> wrote:
> > > fix your boot issue or do we need to go back to using uncached:
> > >
> > > + return ioremap(phys, size);
> >
> > is that the next change you want me to try?
>
> Yes. (Replacing the current return ioremap_*(phys, size).)
sadly, no change -- still black screen. again, rebooted
successfully under commit 8a327f23. just to be clear, here's "git
diff":
$ git diff
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
index 7180013..e035f3c 100644
--- a/include/linux/acpi_io.h
+++ b/include/linux/acpi_io.h
@@ -7,7 +7,7 @@
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
- return ioremap_cache(phys, size);
+ return ioremap(phys, size);
}
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] radeon/ttm/PCIe: Use dma_addr if TTM has set it.
On Fri, Jan 28, 2011 at 09:42:48AM -0500, Jerome Glisse wrote:
> On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
> >> If the TTM layer has used the DMA API to setup pages that are
> >> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
> >> array for pages that are to in DMA32 pool."), lets use it
> >> when programming the GART in the PCIe type cards.
> >>
> >> This patch skips doing the pci_map_page (and pci_unmap_page) if
> >> there is a DMA addresses passed in for that page. If the dma_address
> >> is zero (or DMA_ERROR_CODE), then we continue on with our old
> >> behaviour.
> >
> > Hey Jerome,
> >
> > I should have CC-ed you earlier but missed that and instead just
> > CC-ed the mailing list. I was wondering what your thoughts are
> > about this patchset? Thomas took a look at the patchset and he is OK
> > but more eyes never hurt.
> >
> > FYI, for clarity I hadn't made the old calls that got moved due
> > to adding of "{" checkpatch.pl compliant. It complains about it being
> > past 80 characters. I can naturally fix that up, but thought
> > that it might detract from the nature of the patch.
>
> What happen when we don't ask dma32 alloc to ttm ? Will this still
> work in virtualized environnement ?
You mean if we don't pass in the TTM_PAGE_FLAG_DMA32? It will go back
to using the old mechanism - which is to allocate page using
alloc_page(GFP_HIGHUSER). Which should be OK in baremetal or
virtualized environment - and as long as the driver uses the page
for non-DMA type things, or the graphic card is 64-bit capable at which
point it has no trouble reaching it.
>
> Code looks good but GART stuff can be picky, i will try to do a full
> scale testing in next couple week.
Thank you! Much appreciated. Would it be OK if I pinged you in two weeks
time just in case?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"
wrote:
> sadly, no change -- still black screen. again, rebooted
> successfully under commit 8a327f23. just to be clear, here's "git
> diff":
>
> $ git diff
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7180013..e035f3c 100644
> --- a/include/linux/acpi_io.h
> +++ b/include/linux/acpi_io.h
> @@ -7,7 +7,7 @@
> static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> acpi_size size)
> {
> - return ioremap_cache(phys, size);
> + return ioremap(phys, size);
> }
Ok, that implies the new mapping is fine and not the cause of the issue.
Instead you have some OpRegion related regression hidden until till now
because the conflicting mapping disabled it for i915.
That would be easy to test by returning early in intel_opregion_setup():
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_
index 9efccb9..8c93201 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
u32 asls, mboxes;
int err = 0;
+ return -ENOTSUPP;
+
pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
if (asls == 0) {
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"
> wrote:
> > sadly, no change -- still black screen. again, rebooted
> > successfully under commit 8a327f23. just to be clear, here's "git
> > diff":
> >
> > $ git diff
> > diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> > index 7180013..e035f3c 100644
> > --- a/include/linux/acpi_io.h
> > +++ b/include/linux/acpi_io.h
> > @@ -7,7 +7,7 @@
> > static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > acpi_size size)
> > {
> > - return ioremap_cache(phys, size);
> > + return ioremap(phys, size);
> > }
>
> Ok, that implies the new mapping is fine and not the cause of the issue.
>
> Instead you have some OpRegion related regression hidden until till now
> because the conflicting mapping disabled it for i915.
>
> That would be easy to test by returning early in intel_opregion_setup():
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_
> index 9efccb9..8c93201 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> u32 asls, mboxes;
> int err = 0;
>
> + return -ENOTSUPP;
> +
>
> pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> if (asls == 0) {
>
so you want me to revert to a stock b705120e before doing the above?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day"
wrote:
> > That would be easy to test by returning early in intel_opregion_setup():
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_
> > index 9efccb9..8c93201 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > u32 asls, mboxes;
> > int err = 0;
> >
> > + return -ENOTSUPP;
> > +
> >
> > pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > if (asls == 0) {
> >
>
> so you want me to revert to a stock b705120e before doing the above?
Yes. (Or latter, at this point we have lots of fun ahead.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day"
> wrote:
> > > That would be easy to test by returning early in intel_opregion_setup():
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915/intel_
> > > index 9efccb9..8c93201 100644
> > > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > > u32 asls, mboxes;
> > > int err = 0;
> > >
> > > + return -ENOTSUPP;
> > > +
> > >
> > > pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> > > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > > if (asls == 0) {
> > >
> >
> > so you want me to revert to a stock b705120e before doing the above?
>
> Yes. (Or latter, at this point we have lots of fun ahead.)
victory is mine! ok, that premature return seems to have solved it,
i'm up and running under this new kernel. are we getting close?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" wrote: > victory is mine! ok, that premature return seems to have solved it, > i'm up and running under this new kernel. are we getting close? Not even close. We just disabled functionality that was working in 2.6.37; the interaction between ACPI and gfx. What a shame. Instead of return -ENOTSUPP at the start, you can return 0 before each of the if (mboxes & MBOX_*) to narrow down which function regressed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote: > On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" > wrote: > > victory is mine! ok, that premature return seems to have solved it, > > i'm up and running under this new kernel. are we getting close? > > Not even close. We just disabled functionality that was working in 2.6.37; > the interaction between ACPI and gfx. What a shame. > > Instead of return -ENOTSUPP at the start, > you can return 0 before each of the if (mboxes & MBOX_*) to narrow down > which function regressed. ok, i'll see how much of that i can get to today. but at this point, are we fairly convinced that there *is* a problem? i'd hate to go through all this, only to learn at the end that it's something stupid i did. it seems odd that no one else has mentioned running into this -- have you heard no other reports? so, before i launch into this, is there anything else i might report about my system and its current setup that someone might want to know? rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 10:54:20 -0500 (EST), "Robert P. J. Day" wrote: > On Fri, 28 Jan 2011, Chris Wilson wrote: > > > On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" > > wrote: > > > victory is mine! ok, that premature return seems to have solved it, > > > i'm up and running under this new kernel. are we getting close? > > > > Not even close. We just disabled functionality that was working in 2.6.37; > > the interaction between ACPI and gfx. What a shame. > > > > Instead of return -ENOTSUPP at the start, > > you can return 0 before each of the if (mboxes & MBOX_*) to narrow down > > which function regressed. > > ok, i'll see how much of that i can get to today. but at this > point, are we fairly convinced that there *is* a problem? i'd hate to > go through all this, only to learn at the end that it's something > stupid i did. it seems odd that no one else has mentioned running > into this -- have you heard no other reports? We're starting to get into ACPI backlight breakage territory... We have identified that the regression was much earlier, just masked by other breakage. Let's clarify the symptoms: black panel, no backlight, no output at all (not even at shallow angles), but the machine is alive? Can you remotely access the machine and grab debug logs from when it is broken? > so, before i launch into this, is there anything else i might report > about my system and its current setup that someone might want to know? We're now just looking for telltale signs of an error. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote: > We're starting to get into ACPI backlight breakage territory... We > have identified that the regression was much earlier, just masked by > other breakage. as additional info, i went through this for a while during the 2.6.37-rc* progression. it came, it went, it came back again. then everything was fine with both 2.6.38-rc1 and 2.6.38-rc2, and then this. this is on a gateway NV79 laptop running a fully-updated ubuntu 10.10. > Let's clarify the symptoms: black panel, no backlight, no output at > all (not even at shallow angles), but the machine is alive? exactly, same as it's always been when things fail. that the machine is still booting is obvious from lots of disk activity, culminating in the little ubuntu drum roll at the login screen. and, as i mentioned before, i do get a couple early kernel messages (/dev/pts, ureadahead), and that's where it goes black. for a *good* boot, what i would see at that point is the font size getting much smaller and the boot continuing. > Can you remotely access the machine and grab debug logs from when it > is broken? i'd love to, but can't at the moment. i'll see if i can scare up a second machine later and try it. if i can, what *precisely* would you like me to post? i'm guessing dmesg, Xorg.0.log, that sort of thing. > > so, before i launch into this, is there anything else i might > > report about my system and its current setup that someone might > > want to know? > > We're now just looking for telltale signs of an error. all right. and since we're beyond git bisection, can you post a list of say 2 or 3 tests you want me to try in order? as you're the expert here, it would make more sense for you to try to optimize the search pattern here. rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day" wrote: > all right. and since we're beyond git bisection, can you post a > list of say 2 or 3 tests you want me to try in order? as you're the > expert here, it would make more sense for you to try to optimize the > search pattern here. If the machine is booting (just with a blank screen), then enable drm.debug=0xe, and check that it is being written to the system log files. Then boot into the broken setup, reboot and grab the debug messages saved from the previous (broken) boot. Otherwise we shall just wait for the opportunity to log in with a second machine and look for telltales before beginning exploratory surgery. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33139] Radeon HD 5750 locks up when using 3D apps with r600g
https://bugs.freedesktop.org/show_bug.cgi?id=33139 Dave Witbrodt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Dave Witbrodt 2011-01-28 09:05:00 PST --- (In reply to comment #5) > Created an attachment (id=42615) View: https://bugs.freedesktop.org/attachment.cgi?id=42615 Review: https://bugs.freedesktop.org/review?bug=33139&attachment=42615 > possible fix > > Does this drm patch help? Well Alex, I have tried and tried to make something lock my 5750 with this patch applied, but I just can't do it! May I ask how you can work such magic from such a distance? Do you have similar hardware with which you can reproduce the bug, and then just make the bug go away on your hardware? Or do you know the code so well that you just make educated guesses about what might be the cause of the problem? Either way, much thanks! Dave W. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Fix broken locking in ttm_bo_swapout()
Signed-off-by: Matthew Bullock --- drivers/gpu/drm/ttm/ttm_bo.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index af61fc2..e4695db 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1803,6 +1803,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink) spin_unlock(&glob->lru_lock); (void) ttm_bo_cleanup_refs(bo, false, false, false); kref_put(&bo->list_kref, ttm_bo_release_list); + spin_lock(&glob->lru_lock); continue; } -- 1.7.2.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day"
> wrote:
> > all right. and since we're beyond git bisection, can you post a
> > list of say 2 or 3 tests you want me to try in order? as you're the
> > expert here, it would make more sense for you to try to optimize the
> > search pattern here.
>
> If the machine is booting (just with a blank screen), then enable
> drm.debug=0xe, and check that it is being written to the system log
> files. Then boot into the broken setup, reboot and grab the debug
> messages saved from the previous (broken) boot.
>
> Otherwise we shall just wait for the opportunity to log in with a second
> machine and look for telltales before beginning exploratory surgery.
ok, this is what works:
==
$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.
index 64fd644..645581f 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,10 +495,15 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}
+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;
}
+
+return 0; // rday
+
if (mboxes & MBOX_ASLE) {
DRM_DEBUG_DRIVER("ASLE supported\n");
opregion->asle = base + OPREGION_ASLE_OFFSET;
==
*first*, i added the *later* "return 0", and still got the black
screen. i then added the one *above* that, and got a good boot, so
one therefore concludes that it's the "SWSCI" processing that's
causing the problem. of course, that says nothing about whether or
not the later "ASLE" check could be re-enabled, or does that even make
any sense?
in any event, what's above works. next?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #19 from Marek Olšák 2011-01-28 10:56:20 PST --- I think I know the reason why it's slow with the rename_regs pass. The statistics of the most complex shader are: FRAGMENT PROGRAM ~~~ ~ 108 Instructions ~ 71 Vector Instructions (RGB) ~ 35 Scalar Instructions (Alpha) ~ 0 Flow Control Instructions ~ 36 Texture Instructions ~ 2 Presub Operations ~ 36 Temporary Registers ~~ END ~~ If you disable rename_regs, you will get: FRAGMENT PROGRAM ~~~ ~ 143 Instructions ~ 71 Vector Instructions (RGB) ~ 35 Scalar Instructions (Alpha) ~ 0 Flow Control Instructions ~ 36 Texture Instructions ~ 2 Presub Operations ~ 4 Temporary Registers ~~ END ~~ Wow, 4 temps! It definitely appears to be a register allocator issue. Even though the rename_regs pass has helped with instruction scheduling a lot, it made regalloc perform much worse. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Friday, January 28, 2011, Robert P. J. Day wrote:
> On Fri, 28 Jan 2011, Chris Wilson wrote:
>
> > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"
> > wrote:
> > > sadly, no change -- still black screen. again, rebooted
> > > successfully under commit 8a327f23. just to be clear, here's "git
> > > diff":
> > >
> > > $ git diff
> > > diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> > > index 7180013..e035f3c 100644
> > > --- a/include/linux/acpi_io.h
> > > +++ b/include/linux/acpi_io.h
> > > @@ -7,7 +7,7 @@
> > > static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > > acpi_size size)
> > > {
> > > - return ioremap_cache(phys, size);
> > > + return ioremap(phys, size);
> > > }
> >
> > Ok, that implies the new mapping is fine and not the cause of the issue.
> >
> > Instead you have some OpRegion related regression hidden until till now
> > because the conflicting mapping disabled it for i915.
> >
> > That would be easy to test by returning early in intel_opregion_setup():
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_
> > index 9efccb9..8c93201 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > u32 asls, mboxes;
> > int err = 0;
> >
> > + return -ENOTSUPP;
> > +
> >
> > pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > if (asls == 0) {
> >
>
> so you want me to revert to a stock b705120e before doing the above?
Alternatively, you could take the vanilla Linus' tree and replace
ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please try that
and see if it makes a difference.
Thanks,
Rafael
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
> On Friday, January 28, 2011, Robert P. J. Day wrote:
> > On Fri, 28 Jan 2011, Chris Wilson wrote:
> >
> > > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"
> > > wrote:
> > > > sadly, no change -- still black screen. again, rebooted
> > > > successfully under commit 8a327f23. just to be clear, here's "git
> > > > diff":
> > > >
> > > > $ git diff
> > > > diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> > > > index 7180013..e035f3c 100644
> > > > --- a/include/linux/acpi_io.h
> > > > +++ b/include/linux/acpi_io.h
> > > > @@ -7,7 +7,7 @@
> > > > static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > > > acpi_size size)
> > > > {
> > > > - return ioremap_cache(phys, size);
> > > > + return ioremap(phys, size);
> > > > }
> > >
> > > Ok, that implies the new mapping is fine and not the cause of the issue.
> > >
> > > Instead you have some OpRegion related regression hidden until till now
> > > because the conflicting mapping disabled it for i915.
> > >
> > > That would be easy to test by returning early in intel_opregion_setup():
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915/intel_
> > > index 9efccb9..8c93201 100644
> > > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > > u32 asls, mboxes;
> > > int err = 0;
> > >
> > > + return -ENOTSUPP;
> > > +
> > >
> > > pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> > > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > > if (asls == 0) {
> > >
> >
> > so you want me to revert to a stock b705120e before doing the above?
>
> Alternatively, you could take the vanilla Linus' tree and replace
> ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please try that
> and see if it makes a difference.
been there, done that, that's all so ... this morning. i continued
bisecting and playing and eventually verified the following
workaround for an earlier working version of the kernel:
$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}
+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;
this was based on a suggestion by chris wilson to deactivate the
"mboxes" tests in that single source file and see what happened.
adding the "return 0" above suddenly gave me a properly booting
kernel. i applied the same diff to the current kernel and it's
building as we speak.
rday
p.s. having that "return 0" *after* that test but before the next one
still gave me a black screen.
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
> Alternatively, you could take the vanilla Linus' tree and replace
> ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please
> try that and see if it makes a difference.
as a quick followup, i applied the following simple patch:
$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}
+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;
to the latest tree, and it gave me a booting kernel, no black screen
issue. i will not pretend to understand why that fixes the problem
but it does.
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33139] Radeon HD 5750 locks up when using 3D apps with r600g
https://bugs.freedesktop.org/show_bug.cgi?id=33139 --- Comment #8 from Alex Deucher 2011-01-28 13:10:17 PST --- (In reply to comment #7) > May I ask how you can work such magic from such a distance? Do you have > similar hardware with which you can reproduce the bug, and then just make the > bug go away on your hardware? Or do you know the code so well that you just > make educated guesses about what might be the cause of the problem? Another bug pointed to a similar issue beginning around the time I reworked the blit code, so I figured it was a likely candidate. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: Fix wrong boolean operator
This error is reported by cppcheck: drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over || always evaluates to true. Did you intend to use && instead? It looks like cppcheck is correct, so fix this. No test was run. Cc: David Airlie Cc: Alex Deucher Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Stefan Weil --- drivers/gpu/drm/radeon/radeon_encoders.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c index 5e90984..d4a5422 100644 --- a/drivers/gpu/drm/radeon/radeon_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_encoders.c @@ -1063,7 +1063,7 @@ atombios_set_edp_panel_power(struct drm_connector *connector, int action) if (!ASIC_IS_DCE4(rdev)) return; - if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) || + if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) && (action != ATOM_TRANSMITTER_ACTION_POWER_OFF)) return; -- 1.7.2.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Fix wrong boolean operator
On Fri, Jan 28, 2011 at 5:35 PM, Stefan Weil wrote: > This error is reported by cppcheck: > drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over > || always evaluates to true. Did you intend to use && instead? Yes, should be &&. Thanks, Reviewed-by: Alex Deucher > > It looks like cppcheck is correct, so fix this. No test was run. > > Cc: David Airlie > Cc: Alex Deucher > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Stefan Weil > --- > drivers/gpu/drm/radeon/radeon_encoders.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c > b/drivers/gpu/drm/radeon/radeon_encoders.c > index 5e90984..d4a5422 100644 > --- a/drivers/gpu/drm/radeon/radeon_encoders.c > +++ b/drivers/gpu/drm/radeon/radeon_encoders.c > @@ -1063,7 +1063,7 @@ atombios_set_edp_panel_power(struct drm_connector > *connector, int action) > if (!ASIC_IS_DCE4(rdev)) > return; > > - if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) || > + if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) && > (action != ATOM_TRANSMITTER_ACTION_POWER_OFF)) > return; > > -- > 1.7.2.3 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33674] New: KMS, kernel, Second Monitor becomes complete blur when loading fullscreen GL
https://bugs.freedesktop.org/show_bug.cgi?id=33674 Summary: KMS, kernel, Second Monitor becomes complete blur when loading fullscreen GL Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: highest Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: oyvi...@everdot.org On affected system: 1. Load fullscreen OpenGL something which thinks fullscreen means both attached monitors. This includes kwin and warzone. 2. Kernels 2.6.37-git15 2.6.38-rc1-git2 2.6.38-rc2-git7 show expected on first monitor and complete blur on second monitor. Total messy blur. Everything works perfectly with stable 2.6.37-gentoo kernel. I do not know what happened with <=2.6.37-git15, but I do know 2.6.37-git15 kernels and later are defective. It would be nice if someone could make two monitors work with OpenGL again (working kwin is nice). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33674] KMS, kernel, Second Monitor becomes complete blur when loading fullscreen GL
https://bugs.freedesktop.org/show_bug.cgi?id=33674 --- Comment #1 from Alex Deucher 2011-01-28 15:34:53 PST --- did you update anything other than the kernel (mesa, ddx, etc.)? If it's just the kernel can you bisect? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 22472] vga_switcheroo fails to switch from intel to ati
https://bugzilla.kernel.org/show_bug.cgi?id=22472 Radu Andries changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #15 from Radu Andries 2011-01-29 00:54:54 --- Someone fixed it somehow. In final 2.6.37 all works fine -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, radeon and nouveau fixes only, a couple of regressions, one evergreen GPU hang under load, and one big endian fix. Dave. The following changes since commit 6663050edd9c2e8b1e1f55c09459144d84c045f0: Merge branch 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-26 09:04:18 +1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (4): drm/radeon/kms: only enable HDMI mode if radeon audio is enabled drm/radeon/kms: clean up some magic numbers drm/radeon/kms: fix r6xx+ scanout on BE systems drm/radeon/kms: re-emit full context state for evergreen blits Ben Skeggs (6): drm/nouveau: remove dead function definition drm/nouveau: probe for adt7473 before f75375 drm/nvc0: fix incorrect TPC register setup drm/nvc0: implement irq handler for whatever's at 0x14 drm/nvc0/grctx: correct an off-by-one drm/nv50: fix regression on IGPs Dave Airlie (2): Merge branch 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Merge branch 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Francisco Jerez (2): drm/nouveau: Workaround incorrect DCB entry on a GeForce3 Ti 200. drm/nv50: Fix race with PFIFO during PGRAPH context destruction. Jerome Glisse (1): radeon/kms: fix dp displayport mode validation Marek Ol??k (1): drm/radeon/kms: release CMASK access in preclose_kms drivers/gpu/drm/nouveau/nouveau_bios.c | 15 ++ drivers/gpu/drm/nouveau/nouveau_drv.h |3 -- drivers/gpu/drm/nouveau/nouveau_temp.c |2 +- drivers/gpu/drm/nouveau/nv50_graph.c|3 ++ drivers/gpu/drm/nouveau/nv50_vm.c |5 --- drivers/gpu/drm/nouveau/nvc0_graph.c| 23 ++- drivers/gpu/drm/nouveau/nvc0_grctx.c|2 +- drivers/gpu/drm/radeon/atombios_crtc.c | 17 +++ drivers/gpu/drm/radeon/atombios_dp.c|4 +- drivers/gpu/drm/radeon/evergreen_blit_kms.c | 39 ++ drivers/gpu/drm/radeon/r100.c | 10 +++--- drivers/gpu/drm/radeon/r300.c |7 +++- drivers/gpu/drm/radeon/r420.c |2 +- drivers/gpu/drm/radeon/r520.c |4 +- drivers/gpu/drm/radeon/r600_reg.h |6 +++- drivers/gpu/drm/radeon/radeon_encoders.c|6 ++-- drivers/gpu/drm/radeon/radeon_kms.c |2 + drivers/gpu/drm/radeon/radeon_reg.h |2 + drivers/gpu/drm/radeon/rs400.c | 15 ++ drivers/gpu/drm/radeon/rv515.c | 10 +++--- 20 files changed, 132 insertions(+), 45 deletions(-)
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #13 from Tom Stellard 2011-01-28 00:20:29 PST --- I'm pretty sure this is a bug in the scheduler. I'm attaching screenshots comparing running with this patch: https://bugs.freedesktop.org/attachment.cgi?id=42514 to running with RADEON_DEBUG=noopt. The screenshots look very similar, but I think the shadow with RADEON_DEBUG=noopt is darker. As for performance difference between RADEON_DEBUG=noopt and with optimizations. I think we are seeing this because Lightsmark compiles new shaders while running the benchmark and the longer compile time for optimized shaders is lowering the FPS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #14 from Tom Stellard 2011-01-28 00:21:18 PST --- Created an attachment (id=42626) --> (https://bugs.freedesktop.org/attachment.cgi?id=42626) Screenshot with RADEON_DEBUG=noopt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #15 from Tom Stellard 2011-01-28 00:22:12 PST --- Created an attachment (id=42627) --> (https://bugs.freedesktop.org/attachment.cgi?id=42627) Screenshot with scheduler patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #16 from Pavel Ondra?ka 2011-01-28 00:53:06 PST --- I'm puzzled, because here with mesa master + disable scheduler rewrite patch, I get the wrong behavior (right part of https://bugs.freedesktop.org/attachment.cgi?id=42516 ). However your screenshot in Comment 15 looks almost completely good. To be sure I did once again git clean -fdx, git reset --hard origin/master, patch again and recompile, but nothing changed. Some hardware difference or my setup is broken? Maybe someone with the same card as mine (RV530) can test your patch to confirm if it indeed fixes the shadows? Any chance you have also some other patches applied? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
has the i915 "black screen" boot issue returned?
On Thu, 27 Jan 2011 17:33:04 -0500 (EST), "Robert P. J. Day" wrote: > > one more observation which should nail things down: > > On Thu, 27 Jan 2011, Robert P. J. Day wrote: > > > ok, i'm getting different results from this morning, not sure why, > > but i'm fairly confident i've isolated it to this extent. here's the > > salient part of the git log i'm looking at: > > > > = git log = > > > > commit abb72c828878a2c69b2cfb33ac30007c8ecd735e > > Merge: 58bbf01 8e934db > > Author: Dave Airlie > > Date: Tue Jan 25 08:41:58 2011 +1000 > > > > Merge branch 'drm-intel-fixes-2' of > > ssh://master.kernel.org/pub/scm/linux/kernel/g > > > > * 'drm-intel-fixes-2' of > > ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr > > drm/i915: Prevent uninitialised reads during error state capture > > drm/i915: Use consistent mappings for OpRegion between ACPI and i915 > > drm/i915: Handle the no-interrupts case for UMS by polling > > drm/i915: Disable high-precision vblank timestamping for UMS > > drm/i915: Increase the amount of defense before computing vblank > > timestamps > > drm/i915,agp/intel: Do not clear stolen entries > > Remove MAYBE_BUILD_BUG_ON > > BUILD_BUG_ON: make it handle more cases > > module: fix missing semicolons in MODULE macro usage > > param: add null statement to compiled-in module params > > module: fix linker error for MODULE_VERSION when !MODULE and > > CONFIG_SYSFS=n > > module: show version information for built-in modules in sysfs > > selinux: return -ENOMEM when memory allocation fails > > tpm: fix panic caused by "tpm: Autodetect itpm devices" > > TPM: Long default timeout fix > > trusted keys: Fix a memory leak in trusted_update(). > > keys: add trusted and encrypted maintainers > > encrypted-keys: rename encrypted_defined files to encrypted > > trusted-keys: rename trusted_defined files to trusted > > drm/i915: Recognise non-VGA display devices > > ... > > > > commit 58bbf018a70c562437eeae121a5d021ba7fe56a5 > > Author: Alex Deucher > > Date: Mon Jan 24 17:14:26 2011 -0500 > > > > drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq > > > > Needed for timer queries in the 3D driver. > > > > Signed-off-by: Alex Deucher > > Signed-off-by: Dave Airlie > > > > = git log = > > > > now: > > > > * commit 58bbf018 appears to be fine, boots reliably > > * commit 8e934dbf causes black screen issue > > > > as you can see, rather than test the *merge* above, i decided to back > > up one level and test the commit that was part of that merge, and it > > failed. is this helpful? here's the log entry: > > > > commit 8e934dbf264418afe4d1dff34ce074ecc14280db > > Author: Chris Wilson > > Date: Mon Jan 24 12:34:00 2011 + > > > > drm/i915: Prevent uninitialised reads during error state capture > > > > error_bo and pinned_bo could be used uninitialised if there were no > > active buffers. > > > > Caught by kmemcheck. > > > > Signed-off-by: Chris Wilson > > > > > > i'm going to go on and test the merge itself, abb72c82, since i > > thought that was working fine earlier today. but you can see which > > commit now seems to fail. does this make any sense? > > i did indeed test commit abb72c82 (the merge of the above), and it > failed. not sure why i posted earlier today that it worked, i must > have built something incorrectly. so, in conclusion: > > * commit 58bbf018 appears to be fine, boots reliably > * commit 8e934dbf causes black screen issue > * commit abb72c82 also causes black screen issue > > and on that note, signing off for the evening. > > rday > > -- > > > Robert P. J. Day Waterloo, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > From: Chris Wilson Subject: Re: has the i915 "black screen" boot issue returned? To: "Robert P. J. Day" Cc: dri-devel at lists.freedesktop.org Bcc: chris at chris-wilson.co.uk In-Reply-To: References: <1bdc18$jdgfni at fmsmga002.fm.intel.com> <0d30dc$ksovh8 at orsmga001.jf.intel.com> On Thu, 27 Jan 2011 16:39:20 -0500 (EST), "Robert P. J. Day" wrote: > ok, i'm getting different results from this morning, not sure why, > but i'm fairly confident i've isolated it to this extent. here's the > salient part of the git log i'm looking at: Well, we have two endpoints, so let git attack: $ git bisect start $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e That shouldn't take more than a few recomp
[Bug 32296] [r300g] Screen corruption with WoW when HyperZ enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=32296 Fabio Pedretti changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from Fabio Pedretti 2011-01-28 01:00:19 PST --- I am still seeing the white clouds but I suspect they are related to the zigzagged edges which seems to be a know issue. Also no more lockups. My card: r300: DRM version: 2.7.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2 r300: GART size: 509 MB, VRAM size: 256 MB r300: AA compression: NO, Z compression: YES, HiZ: YES Closing since Chris problem is fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
has the i915 "black screen" boot issue returned?
On Fri, 28 Jan 2011, Chris Wilson wrote: > Well, we have two endpoints, so let git attack: > > $ git bisect start > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e > > That shouldn't take more than a few recompiles to identify the > troublemaker. ok, i can get to that in a bit. might take a while since this system is not exactly a screamer but i'm curious -- have you heard no other reports of people running into this issue? i'm going to be embarrassed if it turns out it's something *i've* done but, at this point, it seems fairly reproducible. are there any kernel command-line parms i might try that would be informative? anything involving modesetting? rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
has the i915 "black screen" boot issue returned?
On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day" wrote: > On Fri, 28 Jan 2011, Chris Wilson wrote: > > > Well, we have two endpoints, so let git attack: > > > > $ git bisect start > > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 > > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e > > > > That shouldn't take more than a few recompiles to identify the > > troublemaker. > > ok, i can get to that in a bit. might take a while since this > system is not exactly a screamer but i'm curious -- have you heard no > other reports of people running into this issue? i'm going to be > embarrassed if it turns out it's something *i've* done but, at this > point, it seems fairly reproducible. This is the first I'm aware of. It could just be the tip of the iceberg... > are there any kernel command-line parms i might try that would be > informative? anything involving modesetting? Sure: add drm.debug=0xe to your boot parameters (or to your modprobe conf). -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #17 from Tom Stellard 2011-01-28 01:36:08 PST --- The right side of this screenshot that you posted: https://bugs.freedesktop.org/attachment.cgi?id=42516 Looks a lot like what I see when I disable the reg rename pass. I've double checked the results with the scheduler patch and they are the same as the screenshot I posted. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32945] Lower part of the screen corrupt with HyperZ enabled
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #15 from Marek Ol??k 2011-01-28 03:08:44 PST --- If the latest commits don't help, please add the following line at the end of r300_chipset.c and test again: caps->hiz_ram = 0; -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
has the i915 "black screen" boot issue returned?
On Fri, 28 Jan 2011, Chris Wilson wrote: > Well, we have two endpoints, so let git attack: > > $ git bisect start > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e > > That shouldn't take more than a few recompiles to identify the > troublemaker. it appears i have one bisection left to make but, just a bit of info, the black screen issue kicks in when the kernel tries to change the font size of the early kernel messages to a much smaller font (or at least it happens around that time). typically, regardless of the kernel, i get a couple of large font messages (/dev/pts and one other, memory fails me), at which point a good kernel will switch to a much smaller font and continue. with a "bad" kernel, the display on my laptop goes black and stays that way, despite the fact that the boot is obviously still progressing. you can decide if that is at all helpful. back to bisecting. should be getting close. rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #18 from Pavel Ondra?ka 2011-01-28 03:42:50 PST --- (In reply to comment #17) > The right side of this screenshot that you posted: > https://bugs.freedesktop.org/attachment.cgi?id=42516 > Looks a lot like what I see when I disable the reg rename pass. > > I've double checked the results with the scheduler patch and they are the same > as the screenshot I posted. This is getting weird, because Marek in comment 12 mentioned that the penumbra shadows are rendered correctly with register rename pass disabled. I guess he also have RV530? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32945] Lower part of the screen corrupt with HyperZ enabled
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #16 from Sven Arvidsson 2011-01-28 04:38:04 PST --- No change with the latest commits, but caps->hiz_ram = 0; makes the problem go away. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33648] New: Black line in Lightsmark with Z compression enabled (RV530)
https://bugs.freedesktop.org/show_bug.cgi?id=33648 Summary: Black line in Lightsmark with Z compression enabled (RV530) Product: Mesa Version: git Platform: Other URL: http://dee.cz/lightsmark/Lightsmark2008.2.0.tar.bz2 OS/Version: All Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: drakkk at centrum.cz After recent zbuffer compression rework Lightsmark is the only remaining app I've tested which is still not working properly here on RV530. There is a thick black line across the screen in some scenes, particularly: "no radiosity","soft shadows", "penumbra shadows" and the last scene. Maybe this is a known issue and there are many open bugs about HyperZ, however according to db299a9f8244d53d9041fcdbd396a77ebe1f9e3e comment RV530 should just work. So I'm reporting it isn't. Also this is not a regression, it was much worse before and this is the only remaining issue here. To be sure this isn't HiZ issue I've changed line 367 in r300_chipset.c to "caps->hiz_ram = 0;" and it haven't changed anything. r300: AA compression: NO, Z compression: YES, HiZ: NO -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote: > On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote: > > On Fri, 28 Jan 2011, Chris Wilson wrote: > > > > > Well, we have two endpoints, so let git attack: > > > > > > $ git bisect start > > > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5 > > > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e > > > > > > That shouldn't take more than a few recompiles to identify the > > > troublemaker. > > > > ok, i can get to that in a bit. might take a while since this > > system is not exactly a screamer but i'm curious -- have you heard no > > other reports of people running into this issue? i'm going to be > > embarrassed if it turns out it's something *i've* done but, at this > > point, it seems fairly reproducible. > > This is the first I'm aware of. It could just be the tip of the iceberg... the git bisection finally resolved to: BAD: b705120e GOOD: 8a327f23 so the culprit appears to be: b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit commit b705120e4198315f4ae043de06c62f65e0851fd3 Author: Michael Karcher Date: Sun Jan 23 18:17:17 2011 + drm/i915: Use consistent mappings for OpRegion between ACPI and i915 The opregion is a shared memory region between ACPI and the graphics driver. As the ACPI mapping has been changed to cachable in commit 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion non-cachable now fails. As no bus-master hardware is involved in the opregion, cachable map should do no harm. Tested on a Fujitsu Lifebook P8010. Signed-off-by: Michael Karcher [ickle: convert to acpi_os_ioremap for consistency] Signed-off-by: Chris Wilson thoughts? once again, the salient output from "lspci -v": 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Device 031c Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at d000 (64-bit, non-prefetchable) [size=4M] Memory at c000 (64-bit, prefetchable) [size=256M] I/O ports at 3050 [size=8] Expansion ROM at [disabled] Capabilities: Kernel driver in use: i915 Kernel modules: i915 rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[Bug 33648] Black line in Lightsmark with Z compression enabled (RV530)
https://bugs.freedesktop.org/show_bug.cgi?id=33648 --- Comment #1 from Pavel Ondra?ka 2011-01-28 05:54:33 PST --- Created an attachment (id=42642) --> (https://bugs.freedesktop.org/attachment.cgi?id=42642) screenshot -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" wrote:
> so the culprit appears to be:
>
> b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> commit b705120e4198315f4ae043de06c62f65e0851fd3
> Author: Michael Karcher
> Date: Sun Jan 23 18:17:17 2011 +
>
> drm/i915: Use consistent mappings for OpRegion between ACPI and i915
>
> The opregion is a shared memory region between ACPI and the graphics
> driver. As the ACPI mapping has been changed to cachable in commit
> 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> non-cachable now fails. As no bus-master hardware is involved in the
> opregion, cachable map should do no harm.
>
> Tested on a Fujitsu Lifebook P8010.
>
> Signed-off-by: Michael Karcher
> [ickle: convert to acpi_os_ioremap for consistency]
> Signed-off-by: Chris Wilson
>
>
> thoughts? once again, the salient output from "lspci -v":
Indeed looks like using ioremap_cache is not as safe as was assumed. Does
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
index 7180013..42108ab 100644
--- a/include/linux/acpi_io.h
+++ b/include/linux/acpi_io.h
@@ -7,7 +7,7 @@
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
- return ioremap_cache(phys, size);
+ return ioremap_wc(phys, size);
}
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
fix your boot issue or do we need to go back to using uncached:
+ return ioremap(phys, size);
--
Chris Wilson, Intel Open Source Technology Centre
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author: Michael Karcher
> > Date: Sun Jan 23 18:17:17 2011 +
> >
> > drm/i915: Use consistent mappings for OpRegion between ACPI and i915
> >
> > The opregion is a shared memory region between ACPI and the graphics
> > driver. As the ACPI mapping has been changed to cachable in commit
> > 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> > non-cachable now fails. As no bus-master hardware is involved in the
> > opregion, cachable map should do no harm.
> >
> > Tested on a Fujitsu Lifebook P8010.
> >
> > Signed-off-by: Michael Karcher
> > [ickle: convert to acpi_os_ioremap for consistency]
> > Signed-off-by: Chris Wilson
> >
> >
> > thoughts? once again, the salient output from "lspci -v":
>
> Indeed looks like using ioremap_cache is not as safe as was assumed. Does
*sigh*. there was, in fact, an "ioremap_error" message displayed
*very* early in the boot sequence, but it was generated even for
successful boots so i never paid it any mind. in hindsight, might
have been useful to have mentioned it.
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7180013..42108ab 100644
> --- a/include/linux/acpi_io.h
> +++ b/include/linux/acpi_io.h
> @@ -7,7 +7,7 @@
> static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> acpi_size size)
> {
> - return ioremap_cache(phys, size);
> + return ioremap_wc(phys, size);
> }
>
> int acpi_os_map_generic_address(struct acpi_generic_address *addr);
ok, i'll make this single change and report back shortly.
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author: Michael Karcher
> > Date: Sun Jan 23 18:17:17 2011 +
> >
> > drm/i915: Use consistent mappings for OpRegion between ACPI and i915
> >
> > The opregion is a shared memory region between ACPI and the graphics
> > driver. As the ACPI mapping has been changed to cachable in commit
> > 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> > non-cachable now fails. As no bus-master hardware is involved in the
> > opregion, cachable map should do no harm.
> >
> > Tested on a Fujitsu Lifebook P8010.
> >
> > Signed-off-by: Michael Karcher
> > [ickle: convert to acpi_os_ioremap for consistency]
> > Signed-off-by: Chris Wilson
> >
> >
> > thoughts? once again, the salient output from "lspci -v":
>
> Indeed looks like using ioremap_cache is not as safe as was assumed. Does
>
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7180013..42108ab 100644
> --- a/include/linux/acpi_io.h
> +++ b/include/linux/acpi_io.h
> @@ -7,7 +7,7 @@
> static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> acpi_size size)
> {
> - return ioremap_cache(phys, size);
> + return ioremap_wc(phys, size);
> }
>
> int acpi_os_map_generic_address(struct acpi_generic_address *addr);
that didn't appear to make a difference. same black screen issue.
BTW, here's an excerpt from /var/log/dmesg for a *successful* boot (i
just rebooted to 8a327f23):
...
[ 24.037114] intel ips :00:1f.6: failed to get i915 symbols, graphics
turbo disabled
...
[ 27.155660] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 27.155665] i915 :00:02.0: setting latency timer to 64
[ 27.217407] mtrr: no more MTRRs available
[ 27.217411] [drm] MTRR allocation failed. Graphics performance may suffer.
[ 27.217848] ioremap error for 0xb3752000-0xb3755000, requested 0x10, got 0x0
[ 27.217933] i915 :00:02.0: irq 42 for MSI/MSI-X
[ 27.217938] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 27.217940] [drm] Driver supports precise vblank timestamp query.
...
if any of that is of any use.
> fix your boot issue or do we need to go back to using uncached:
>
> + return ioremap(phys, size);
is that the next change you want me to try?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
[Bug 33139] Radeon HD 5750 locks up when using 3D apps with r600g
https://bugs.freedesktop.org/show_bug.cgi?id=33139 --- Comment #6 from Benjamin Franzke 2011-01-28 06:36:27 PST --- (In reply to comment #5) > Created an attachment (id=42615) View: https://bugs.freedesktop.org/attachment.cgi?id=42615 Review: https://bugs.freedesktop.org/review?bug=33139&attachment=42615 > possible fix > > Does this drm patch help? fixes it here (tested with 2.6.37+patch on an HD 5770). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day" wrote: > > fix your boot issue or do we need to go back to using uncached: > > > > + return ioremap(phys, size); > > is that the next change you want me to try? Yes. (Replacing the current return ioremap_*(phys, size).) -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 4/5] radeon/ttm/PCIe: Use dma_addr if TTM has set it.
On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
>> If the TTM layer has used the DMA API to setup pages that are
>> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
>> array for pages that are to in DMA32 pool."), lets use it
>> when programming the GART in the PCIe type cards.
>>
>> This patch skips doing the pci_map_page (and pci_unmap_page) if
>> there is a DMA addresses passed in for that page. If the dma_address
>> is zero (or DMA_ERROR_CODE), then we continue on with our old
>> behaviour.
>
> Hey Jerome,
>
> I should have CC-ed you earlier but missed that and instead just
> CC-ed the mailing list. I was wondering what your thoughts are
> about this patchset? Thomas took a look at the patchset and he is OK
> but more eyes never hurt.
>
> FYI, for clarity I hadn't made the old calls that got moved due
> to adding of "{" checkpatch.pl compliant. It complains about it being
> past 80 characters. I can naturally fix that up, but thought
> that it might detract from the nature of the patch.
What happen when we don't ask dma32 alloc to ttm ? Will this still
work in virtualized environnement ?
Code looks good but GART stuff can be picky, i will try to do a full
scale testing in next couple week.
Cheers,
Jerome
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > > fix your boot issue or do we need to go back to using uncached:
> > >
> > > + return ioremap(phys, size);
> >
> > is that the next change you want me to try?
>
> Yes. (Replacing the current return ioremap_*(phys, size).)
sadly, no change -- still black screen. again, rebooted
successfully under commit 8a327f23. just to be clear, here's "git
diff":
$ git diff
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
index 7180013..e035f3c 100644
--- a/include/linux/acpi_io.h
+++ b/include/linux/acpi_io.h
@@ -7,7 +7,7 @@
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
- return ioremap_cache(phys, size);
+ return ioremap(phys, size);
}
int acpi_os_map_generic_address(struct acpi_generic_address *addr);
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH 4/5] radeon/ttm/PCIe: Use dma_addr if TTM has set it.
On Fri, Jan 28, 2011 at 09:42:48AM -0500, Jerome Glisse wrote:
> On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
> >> If the TTM layer has used the DMA API to setup pages that are
> >> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
> >> array for pages that are to in DMA32 pool."), lets use it
> >> when programming the GART in the PCIe type cards.
> >>
> >> This patch skips doing the pci_map_page (and pci_unmap_page) if
> >> there is a DMA addresses passed in for that page. If the dma_address
> >> is zero (or DMA_ERROR_CODE), then we continue on with our old
> >> behaviour.
> >
> > Hey Jerome,
> >
> > I should have CC-ed you earlier but missed that and instead just
> > CC-ed the mailing list. I was wondering what your thoughts are
> > about this patchset? Thomas took a look at the patchset and he is OK
> > but more eyes never hurt.
> >
> > FYI, for clarity I hadn't made the old calls that got moved due
> > to adding of "{" checkpatch.pl compliant. It complains about it being
> > past 80 characters. I can naturally fix that up, but thought
> > that it might detract from the nature of the patch.
>
> What happen when we don't ask dma32 alloc to ttm ? Will this still
> work in virtualized environnement ?
You mean if we don't pass in the TTM_PAGE_FLAG_DMA32? It will go back
to using the old mechanism - which is to allocate page using
alloc_page(GFP_HIGHUSER). Which should be OK in baremetal or
virtualized environment - and as long as the driver uses the page
for non-DMA type things, or the graphic card is 64-bit capable at which
point it has no trouble reaching it.
>
> Code looks good but GART stuff can be picky, i will try to do a full
> scale testing in next couple week.
Thank you! Much appreciated. Would it be OK if I pinged you in two weeks
time just in case?
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" wrote:
> sadly, no change -- still black screen. again, rebooted
> successfully under commit 8a327f23. just to be clear, here's "git
> diff":
>
> $ git diff
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7180013..e035f3c 100644
> --- a/include/linux/acpi_io.h
> +++ b/include/linux/acpi_io.h
> @@ -7,7 +7,7 @@
> static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> acpi_size size)
> {
> - return ioremap_cache(phys, size);
> + return ioremap(phys, size);
> }
Ok, that implies the new mapping is fine and not the cause of the issue.
Instead you have some OpRegion related regression hidden until till now
because the conflicting mapping disabled it for i915.
That would be easy to test by returning early in intel_opregion_setup():
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_
index 9efccb9..8c93201 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
u32 asls, mboxes;
int err = 0;
+ return -ENOTSUPP;
+
pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
if (asls == 0) {
--
Chris Wilson, Intel Open Source Technology Centre
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > sadly, no change -- still black screen. again, rebooted
> > successfully under commit 8a327f23. just to be clear, here's "git
> > diff":
> >
> > $ git diff
> > diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> > index 7180013..e035f3c 100644
> > --- a/include/linux/acpi_io.h
> > +++ b/include/linux/acpi_io.h
> > @@ -7,7 +7,7 @@
> > static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > acpi_size size)
> > {
> > - return ioremap_cache(phys, size);
> > + return ioremap(phys, size);
> > }
>
> Ok, that implies the new mapping is fine and not the cause of the issue.
>
> Instead you have some OpRegion related regression hidden until till now
> because the conflicting mapping disabled it for i915.
>
> That would be easy to test by returning early in intel_opregion_setup():
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_
> index 9efccb9..8c93201 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> u32 asls, mboxes;
> int err = 0;
>
> + return -ENOTSUPP;
> +
>
> pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> if (asls == 0) {
>
so you want me to revert to a stock b705120e before doing the above?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day" wrote:
> > That would be easy to test by returning early in intel_opregion_setup():
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_
> > index 9efccb9..8c93201 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > u32 asls, mboxes;
> > int err = 0;
> >
> > + return -ENOTSUPP;
> > +
> >
> > pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > if (asls == 0) {
> >
>
> so you want me to revert to a stock b705120e before doing the above?
Yes. (Or latter, at this point we have lots of fun ahead.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > > That would be easy to test by returning early in intel_opregion_setup():
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915/intel_
> > > index 9efccb9..8c93201 100644
> > > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > > u32 asls, mboxes;
> > > int err = 0;
> > >
> > > + return -ENOTSUPP;
> > > +
> > >
> > > pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> > > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > > if (asls == 0) {
> > >
> >
> > so you want me to revert to a stock b705120e before doing the above?
>
> Yes. (Or latter, at this point we have lots of fun ahead.)
victory is mine! ok, that premature return seems to have solved it,
i'm up and running under this new kernel. are we getting close?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" wrote: > victory is mine! ok, that premature return seems to have solved it, > i'm up and running under this new kernel. are we getting close? Not even close. We just disabled functionality that was working in 2.6.37; the interaction between ACPI and gfx. What a shame. Instead of return -ENOTSUPP at the start, you can return 0 before each of the if (mboxes & MBOX_*) to narrow down which function regressed. -Chris -- Chris Wilson, Intel Open Source Technology Centre
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote: > On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote: > > victory is mine! ok, that premature return seems to have solved it, > > i'm up and running under this new kernel. are we getting close? > > Not even close. We just disabled functionality that was working in 2.6.37; > the interaction between ACPI and gfx. What a shame. > > Instead of return -ENOTSUPP at the start, > you can return 0 before each of the if (mboxes & MBOX_*) to narrow down > which function regressed. ok, i'll see how much of that i can get to today. but at this point, are we fairly convinced that there *is* a problem? i'd hate to go through all this, only to learn at the end that it's something stupid i did. it seems odd that no one else has mentioned running into this -- have you heard no other reports? so, before i launch into this, is there anything else i might report about my system and its current setup that someone might want to know? rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 10:54:20 -0500 (EST), "Robert P. J. Day" wrote: > On Fri, 28 Jan 2011, Chris Wilson wrote: > > > On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" > crashcourse.ca> wrote: > > > victory is mine! ok, that premature return seems to have solved it, > > > i'm up and running under this new kernel. are we getting close? > > > > Not even close. We just disabled functionality that was working in 2.6.37; > > the interaction between ACPI and gfx. What a shame. > > > > Instead of return -ENOTSUPP at the start, > > you can return 0 before each of the if (mboxes & MBOX_*) to narrow down > > which function regressed. > > ok, i'll see how much of that i can get to today. but at this > point, are we fairly convinced that there *is* a problem? i'd hate to > go through all this, only to learn at the end that it's something > stupid i did. it seems odd that no one else has mentioned running > into this -- have you heard no other reports? We're starting to get into ACPI backlight breakage territory... We have identified that the regression was much earlier, just masked by other breakage. Let's clarify the symptoms: black panel, no backlight, no output at all (not even at shallow angles), but the machine is alive? Can you remotely access the machine and grab debug logs from when it is broken? > so, before i launch into this, is there anything else i might report > about my system and its current setup that someone might want to know? We're now just looking for telltale signs of an error. -Chris -- Chris Wilson, Intel Open Source Technology Centre
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote: > We're starting to get into ACPI backlight breakage territory... We > have identified that the regression was much earlier, just masked by > other breakage. as additional info, i went through this for a while during the 2.6.37-rc* progression. it came, it went, it came back again. then everything was fine with both 2.6.38-rc1 and 2.6.38-rc2, and then this. this is on a gateway NV79 laptop running a fully-updated ubuntu 10.10. > Let's clarify the symptoms: black panel, no backlight, no output at > all (not even at shallow angles), but the machine is alive? exactly, same as it's always been when things fail. that the machine is still booting is obvious from lots of disk activity, culminating in the little ubuntu drum roll at the login screen. and, as i mentioned before, i do get a couple early kernel messages (/dev/pts, ureadahead), and that's where it goes black. for a *good* boot, what i would see at that point is the font size getting much smaller and the boot continuing. > Can you remotely access the machine and grab debug logs from when it > is broken? i'd love to, but can't at the moment. i'll see if i can scare up a second machine later and try it. if i can, what *precisely* would you like me to post? i'm guessing dmesg, Xorg.0.log, that sort of thing. > > so, before i launch into this, is there anything else i might > > report about my system and its current setup that someone might > > want to know? > > We're now just looking for telltale signs of an error. all right. and since we're beyond git bisection, can you post a list of say 2 or 3 tests you want me to try in order? as you're the expert here, it would make more sense for you to try to optimize the search pattern here. rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote: > On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote: > > victory is mine! ok, that premature return seems to have solved it, > > i'm up and running under this new kernel. are we getting close? > > Not even close. We just disabled functionality that was working in > 2.6.37; the interaction between ACPI and gfx. What a shame. > > Instead of return -ENOTSUPP at the start, you can return 0 before > each of the if (mboxes & MBOX_*) to narrow down which function > regressed. are there any kernel config options i should be looking at? for better or worse, i've attached my .config file. and i'm sequentially returning 0 before each of those tests starting with the last and working my way back unless you want to prioritize which tests i should deactivate. rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- next part -- # # Automatically generated make config: don't edit # Linux/x86_64 2.6.38-rc2 Kernel Configuration # Fri Jan 28 07:36:39 2011 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_TRAMPOLINE=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" # CONFIG_KTIME_SCALAR is not set CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y # CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y # CONFIG_AUTO_IRQ_AFFINITY is not set # CONFIG_IRQ_PER_CPU is not set # CONFIG_HARDIRQS_SW_RESEND is not set CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=64 # CONFIG_RCU_FANOUT_EXACT is not set CONFIG_RCU_FAST_NO_HZ=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y # CONFIG_BLK_CGROUP is not set CONFIG_
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day" wrote: > all right. and since we're beyond git bisection, can you post a > list of say 2 or 3 tests you want me to try in order? as you're the > expert here, it would make more sense for you to try to optimize the > search pattern here. If the machine is booting (just with a blank screen), then enable drm.debug=0xe, and check that it is being written to the system log files. Then boot into the broken setup, reboot and grab the debug messages saved from the previous (broken) boot. Otherwise we shall just wait for the opportunity to log in with a second machine and look for telltales before beginning exploratory surgery. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 33139] Radeon HD 5750 locks up when using 3D apps with r600g
https://bugs.freedesktop.org/show_bug.cgi?id=33139 Dave Witbrodt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Dave Witbrodt 2011-01-28 09:05:00 PST --- (In reply to comment #5) > Created an attachment (id=42615) View: https://bugs.freedesktop.org/attachment.cgi?id=42615 Review: https://bugs.freedesktop.org/review?bug=33139&attachment=42615 > possible fix > > Does this drm patch help? Well Alex, I have tried and tried to make something lock my 5750 with this patch applied, but I just can't do it! May I ask how you can work such magic from such a distance? Do you have similar hardware with which you can reproduce the bug, and then just make the bug go away on your hardware? Or do you know the code so well that you just make educated guesses about what might be the cause of the problem? Either way, much thanks! Dave W. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] Fix broken locking in ttm_bo_swapout()
Signed-off-by: Matthew Bullock --- drivers/gpu/drm/ttm/ttm_bo.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index af61fc2..e4695db 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1803,6 +1803,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink) spin_unlock(&glob->lru_lock); (void) ttm_bo_cleanup_refs(bo, false, false, false); kref_put(&bo->list_kref, ttm_bo_release_list); + spin_lock(&glob->lru_lock); continue; } -- 1.7.2.3
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Chris Wilson wrote:
> On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day" crashcourse.ca> wrote:
> > all right. and since we're beyond git bisection, can you post a
> > list of say 2 or 3 tests you want me to try in order? as you're the
> > expert here, it would make more sense for you to try to optimize the
> > search pattern here.
>
> If the machine is booting (just with a blank screen), then enable
> drm.debug=0xe, and check that it is being written to the system log
> files. Then boot into the broken setup, reboot and grab the debug
> messages saved from the previous (broken) boot.
>
> Otherwise we shall just wait for the opportunity to log in with a second
> machine and look for telltales before beginning exploratory surgery.
ok, this is what works:
==
$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.
index 64fd644..645581f 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,10 +495,15 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}
+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;
}
+
+return 0; // rday
+
if (mboxes & MBOX_ASLE) {
DRM_DEBUG_DRIVER("ASLE supported\n");
opregion->asle = base + OPREGION_ASLE_OFFSET;
==
*first*, i added the *later* "return 0", and still got the black
screen. i then added the one *above* that, and got a good boot, so
one therefore concludes that it's the "SWSCI" processing that's
causing the problem. of course, that says nothing about whether or
not the later "ASLE" check could be re-enabled, or does that even make
any sense?
in any event, what's above works. next?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
[Bug 31830] [bisected] broken shadows in Unigine Sanctuary and Lightsmark
https://bugs.freedesktop.org/show_bug.cgi?id=31830 --- Comment #19 from Marek Ol??k 2011-01-28 10:56:20 PST --- I think I know the reason why it's slow with the rename_regs pass. The statistics of the most complex shader are: FRAGMENT PROGRAM ~~~ ~ 108 Instructions ~ 71 Vector Instructions (RGB) ~ 35 Scalar Instructions (Alpha) ~ 0 Flow Control Instructions ~ 36 Texture Instructions ~ 2 Presub Operations ~ 36 Temporary Registers ~~ END ~~ If you disable rename_regs, you will get: FRAGMENT PROGRAM ~~~ ~ 143 Instructions ~ 71 Vector Instructions (RGB) ~ 35 Scalar Instructions (Alpha) ~ 0 Flow Control Instructions ~ 36 Texture Instructions ~ 2 Presub Operations ~ 4 Temporary Registers ~~ END ~~ Wow, 4 temps! It definitely appears to be a register allocator issue. Even though the rename_regs pass has helped with instruction scheduling a lot, it made regalloc perform much worse. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
has the i915 "black screen" boot issue returned? [BISECTED]
On Friday, January 28, 2011, Robert P. J. Day wrote:
> On Fri, 28 Jan 2011, Chris Wilson wrote:
>
> > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" > crashcourse.ca> wrote:
> > > sadly, no change -- still black screen. again, rebooted
> > > successfully under commit 8a327f23. just to be clear, here's "git
> > > diff":
> > >
> > > $ git diff
> > > diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> > > index 7180013..e035f3c 100644
> > > --- a/include/linux/acpi_io.h
> > > +++ b/include/linux/acpi_io.h
> > > @@ -7,7 +7,7 @@
> > > static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > > acpi_size size)
> > > {
> > > - return ioremap_cache(phys, size);
> > > + return ioremap(phys, size);
> > > }
> >
> > Ok, that implies the new mapping is fine and not the cause of the issue.
> >
> > Instead you have some OpRegion related regression hidden until till now
> > because the conflicting mapping disabled it for i915.
> >
> > That would be easy to test by returning early in intel_opregion_setup():
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_
> > index 9efccb9..8c93201 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > u32 asls, mboxes;
> > int err = 0;
> >
> > + return -ENOTSUPP;
> > +
> >
> > pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > if (asls == 0) {
> >
>
> so you want me to revert to a stock b705120e before doing the above?
Alternatively, you could take the vanilla Linus' tree and replace
ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please try that
and see if it makes a difference.
Thanks,
Rafael
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
> On Friday, January 28, 2011, Robert P. J. Day wrote:
> > On Fri, 28 Jan 2011, Chris Wilson wrote:
> >
> > > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day" > > crashcourse.ca> wrote:
> > > > sadly, no change -- still black screen. again, rebooted
> > > > successfully under commit 8a327f23. just to be clear, here's "git
> > > > diff":
> > > >
> > > > $ git diff
> > > > diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> > > > index 7180013..e035f3c 100644
> > > > --- a/include/linux/acpi_io.h
> > > > +++ b/include/linux/acpi_io.h
> > > > @@ -7,7 +7,7 @@
> > > > static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > > > acpi_size size)
> > > > {
> > > > - return ioremap_cache(phys, size);
> > > > + return ioremap(phys, size);
> > > > }
> > >
> > > Ok, that implies the new mapping is fine and not the cause of the issue.
> > >
> > > Instead you have some OpRegion related regression hidden until till now
> > > because the conflicting mapping disabled it for i915.
> > >
> > > That would be easy to test by returning early in intel_opregion_setup():
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915/intel_
> > > index 9efccb9..8c93201 100644
> > > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > > u32 asls, mboxes;
> > > int err = 0;
> > >
> > > + return -ENOTSUPP;
> > > +
> > >
> > > pci_read_config_dword(dev->pdev, PCI_ASLS, &asls);
> > > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > > if (asls == 0) {
> > >
> >
> > so you want me to revert to a stock b705120e before doing the above?
>
> Alternatively, you could take the vanilla Linus' tree and replace
> ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please try that
> and see if it makes a difference.
been there, done that, that's all so ... this morning. i continued
bisecting and playing and eventually verified the following
workaround for an earlier working version of the kernel:
$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}
+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;
this was based on a suggestion by chris wilson to deactivate the
"mboxes" tests in that single source file and see what happened.
adding the "return 0" above suddenly gave me a properly booting
kernel. i applied the same diff to the current kernel and it's
building as we speak.
rday
p.s. having that "return 0" *after* that test but before the next one
still gave me a black screen.
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
has the i915 "black screen" boot issue returned? [BISECTED]
On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:
> Alternatively, you could take the vanilla Linus' tree and replace
> ioremap_cache() with ioremap() in include/linux/acpi_io.h . Please
> try that and see if it makes a difference.
as a quick followup, i applied the following simple patch:
$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}
+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;
to the latest tree, and it gave me a booting kernel, no black screen
issue. i will not pretend to understand why that fixes the problem
but it does.
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
[Bug 33139] Radeon HD 5750 locks up when using 3D apps with r600g
https://bugs.freedesktop.org/show_bug.cgi?id=33139 --- Comment #8 from Alex Deucher 2011-01-28 13:10:17 PST --- (In reply to comment #7) > May I ask how you can work such magic from such a distance? Do you have > similar hardware with which you can reproduce the bug, and then just make the > bug go away on your hardware? Or do you know the code so well that you just > make educated guesses about what might be the cause of the problem? Another bug pointed to a similar issue beginning around the time I reworked the blit code, so I figured it was a likely candidate. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] radeon: Fix wrong boolean operator
This error is reported by cppcheck: drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over || always evaluates to true. Did you intend to use && instead? It looks like cppcheck is correct, so fix this. No test was run. Cc: David Airlie Cc: Alex Deucher Cc: dri-devel at lists.freedesktop.org Cc: linux-kernel at vger.kernel.org Signed-off-by: Stefan Weil --- drivers/gpu/drm/radeon/radeon_encoders.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c index 5e90984..d4a5422 100644 --- a/drivers/gpu/drm/radeon/radeon_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_encoders.c @@ -1063,7 +1063,7 @@ atombios_set_edp_panel_power(struct drm_connector *connector, int action) if (!ASIC_IS_DCE4(rdev)) return; - if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) || + if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) && (action != ATOM_TRANSMITTER_ACTION_POWER_OFF)) return; -- 1.7.2.3
[PATCH] radeon: Fix wrong boolean operator
On Fri, Jan 28, 2011 at 5:35 PM, Stefan Weil wrote: > This error is reported by cppcheck: > drivers/gpu/drm/radeon/radeon_encoders.c:1066: warning: Mutual exclusion over > || always evaluates to true. Did you intend to use && instead? Yes, should be &&. Thanks, Reviewed-by: Alex Deucher > > It looks like cppcheck is correct, so fix this. No test was run. > > Cc: David Airlie > Cc: Alex Deucher > Cc: dri-devel at lists.freedesktop.org > Cc: linux-kernel at vger.kernel.org > Signed-off-by: Stefan Weil > --- > ?drivers/gpu/drm/radeon/radeon_encoders.c | ? ?2 +- > ?1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c > b/drivers/gpu/drm/radeon/radeon_encoders.c > index 5e90984..d4a5422 100644 > --- a/drivers/gpu/drm/radeon/radeon_encoders.c > +++ b/drivers/gpu/drm/radeon/radeon_encoders.c > @@ -1063,7 +1063,7 @@ atombios_set_edp_panel_power(struct drm_connector > *connector, int action) > ? ? ? ?if (!ASIC_IS_DCE4(rdev)) > ? ? ? ? ? ? ? ?return; > > - ? ? ? if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) || > + ? ? ? if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) && > ? ? ? ? ? ?(action != ATOM_TRANSMITTER_ACTION_POWER_OFF)) > ? ? ? ? ? ? ? ?return; > > -- > 1.7.2.3 > >
[Bug 33674] New: KMS, kernel, Second Monitor becomes complete blur when loading fullscreen GL
https://bugs.freedesktop.org/show_bug.cgi?id=33674 Summary: KMS, kernel, Second Monitor becomes complete blur when loading fullscreen GL Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: highest Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: oyvinds at everdot.org On affected system: 1. Load fullscreen OpenGL something which thinks fullscreen means both attached monitors. This includes kwin and warzone. 2. Kernels 2.6.37-git15 2.6.38-rc1-git2 2.6.38-rc2-git7 show expected on first monitor and complete blur on second monitor. Total messy blur. Everything works perfectly with stable 2.6.37-gentoo kernel. I do not know what happened with <=2.6.37-git15, but I do know 2.6.37-git15 kernels and later are defective. It would be nice if someone could make two monitors work with OpenGL again (working kwin is nice). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33674] KMS, kernel, Second Monitor becomes complete blur when loading fullscreen GL
https://bugs.freedesktop.org/show_bug.cgi?id=33674 --- Comment #1 from Alex Deucher 2011-01-28 15:34:53 PST --- did you update anything other than the kernel (mesa, ddx, etc.)? If it's just the kernel can you bisect? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
