[Bug 53971] New: radeon:Soft reset GPU in StarCraft2 under Wine
https://bugzilla.kernel.org/show_bug.cgi?id=53971 Summary: radeon:Soft reset GPU in StarCraft2 under Wine Product: Drivers Version: 2.5 Kernel Version: 3.8.0-rc7 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: stalkerg at gmail.com Regression: No Random GPU resets and freeze on Radeon 6770 with SC2 game under wine 1.5.23 (GLSL disable, pbuffer enable). Linux sagita 3.8.0-rc7 #1 SMP PREEMPT Sat Feb 16 18:13:51 MSK 2013 x86_64 AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux Mesa 9.2-devel (git-f1ab67c) radeon :01:00.0: GPU lockup CP stall for more than 1msec radeon :01:00.0: GPU lockup (waiting for 0x0002236b last fence id 0x0002235e) radeon :01:00.0: Saved 407 dwords of commands on ring 0. radeon :01:00.0: GPU softreset: 0x0003 radeon :01:00.0: GRBM_STATUS = 0xE4002CA4 radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 radeon :01:00.0: GRBM_STATUS_SE1 = 0xC005 radeon :01:00.0: SRBM_STATUS = 0x20C0 radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x0400 radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x0004 radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00048402 radeon :01:00.0: R_008680_CP_STAT = 0x80860243 radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B radeon :01:00.0: GRBM_STATUS = 0x3828 radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 radeon :01:00.0: SRBM_STATUS = 0x20C0 radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x radeon :01:00.0: R_008680_CP_STAT = 0x radeon :01:00.0: GPU reset succeeded, trying to resume [drm] probing gen 2 caps for device 1002:5a16 = 2/0 [drm] PCIE gen 2 link speeds already enabled [drm] PCIE GART of 512M enabled (table at 0x0004). radeon :01:00.0: WB enabled radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x8802321edc00 radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x8802321edc0c [drm] ring test on 0 succeeded in 3 usecs [drm] ring test on 3 succeeded in 1 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 1 usecs -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 60969] New: [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 Priority: medium Bug ID: 60969 Assignee: dri-devel at lists.freedesktop.org Summary: [r600g] Lockup while playing OpenGL games with HD6450 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: rankincj at googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa HD6450 (CAICOS), kernel 3.7.7-201.fc18.x86_64 The PC quickly locks up while playing either WoW or Minecraft 1.4.7 with Mesa from git. However, I have an earlier version of Mesa-git that plays both games correctly. The mouse cursor continues to move after the freeze, but the keyboard no longer responds. The HEAD for my working Mesa is: commit 0e2f26d5ea26febd16173aa8bbf7427b090e320f Author: Ian Romanick Date: Fri Feb 8 18:03:33 2013 -0800 intel: Do not expose OES_compressed_ETC1_RGB8_texture or ARB_texture_rgb10_a Older hardware cannot do ARB_texture_rgb10_a2ui, and the translation code for OES_compressed_ETC1_RGB8_texture was never implemented in the i915 driver. I will try and bisect this issue when I have more time with the affected PC. Note that this issue does not happen with either my HD4670 or HD4890. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130216/97c07d02/attachment.html>
[Bug 60965] New: [r300g] Anno1701: flickering colorful corruption over some models
https://bugs.freedesktop.org/show_bug.cgi?id=60965 Priority: medium Bug ID: 60965 Assignee: dri-devel at lists.freedesktop.org Summary: [r300g] Anno1701: flickering colorful corruption over some models Severity: normal Classification: Unclassified OS: All Reporter: pavel.ondracka at email.cz Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Created attachment 74949 --> https://bugs.freedesktop.org/attachment.cgi?id=74949=edit RADEON_DEBUG=fp,vp In Anno1701, there are flickering colorful spots over some models. It looks similar to the bug 60552, except the spots are colorful instead of black and they don't go away with RADEON_DEBUG=noopt. Setting Wine to use ARB shader rendering backend instead of GLSL makes the problem go away indicating another bug in the shader compiler. Apitrace here http://pavel.ondracka.cz/Anno1701.trace (renders fine with proprietary NVIDIA drivers). Wine: 1.5.23 GPU: RV530 Mesa: f1ab67c13ab97f19c08d99c6ba101edc7d7b80e6 Kernel: 3.7.3-101.fc17.i686 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130216/2007a7c8/attachment-0001.html>
[Bug 60963] New: [r300g] Anno1701: some models are red
https://bugs.freedesktop.org/show_bug.cgi?id=60963 Priority: medium Bug ID: 60963 Assignee: dri-devel at lists.freedesktop.org Summary: [r300g] Anno1701: some models are red Severity: normal Classification: Unclassified OS: All Reporter: pavel.ondracka at email.cz Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Created attachment 74948 --> https://bugs.freedesktop.org/attachment.cgi?id=74948=edit RADEON_DEBUG=fp,vp In Anno1701, some models are red, however they are rendered with correct colors when RADEON_DEBUG=noopt is used (or with glsl disabled in Wine). Apitrace here http://pavel.ondracka.cz/Anno1701.trace (renders fine with proprietary NVIDIA drivers). Wine: 1.5.23 GPU: RV530 Mesa: f1ab67c13ab97f19c08d99c6ba101edc7d7b80e6 Kernel: 3.7.3-101.fc17.i686 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130216/f709195b/attachment.html>
Debugging Thinkpad T430s occasional suspend failure.
On Sat, 16 Feb 2013, Hugh Dickins wrote:
> On Sat, 16 Feb 2013, Linus Torvalds wrote:
> >
> > I think it's worth it to give them a heads-up already. So I've cc'd
> > the main suspects here..
>
> Okay, thanks.
>
> >
> > Daniel, Dave - any comments about a NULL fb in
> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
> > googling shows this:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
>
> Great, yes, I'm sure that's the same (though it says "suspend"
> and I say "resume").
>
> >
> > which sounds remarkably similar, and is also during a suspend attempt
> > (but apparently Satish got a full oops out).. Some timing race with a
> > worker entry?
Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
on lid open", whose force_restore case now passes down crtc->base.fb. But
I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
your timing race with a worker entry, perhaps.
And 45e2b5f640b3 contains a fine history of going back and forth, so I
wouldn't want to play further with it out of ignorance - though tempted
to replace the "if (force_restore) {" by an interim safe-seeming
compromise of "if (force_restore && crtc->base.fb) {".
Hugh
Debugging Thinkpad T430s occasional suspend failure.
On Sat, 16 Feb 2013, Linus Torvalds wrote:
> On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins wrote:
> >
> > I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
> > yesterday, to save an oopsing core kernel ip there, instead of hashed
> > pm trace info (it makes sense in this case to invert your sequence,
> > putting the high order into years and the low order into minutes).
>
> That sounds like a good idea in general. The PM_TRACE() thing was done
> to figure out things that locked up the PCI bus etc, but encoding the
> oopses during suspend sounds like a really good idea too.
Yes, it can and should be generalized, but needs more than I gave it.
>
> Is your patch clean enough to just be made part of the standard
> PM_TRACE infrastructure, or was it something really hacky and one-off?
Not really hacky, but three reasons why it cannot be standard without
more work (I am supposing that it should not be tied to suspend/resume,
but could be used for any oops which gets hidden by graphic screen,
and also fails to reach /var/log/messages).
1. Because I usually have a version of KDB patched into my kernels
("forked" many years ago, never time to integrate with that subset
which eventually went into 2.6.??), it was easiest to implement as
a pair of KDB commands (needing keyboard input: I already knew I
could "reboot" from KDB in this state). (Sidenote: using KDB can
prevent getting a trace into /var/log/messages: so I had tried
without it, but still failed to get one.)
2. I don't use initrd, have very little in modules, and a pared down
kernel: so for me it was not a serious restriction to limit to core
kernel addresses, which easily fitted within the limit; but we ought
to put thought into handling module addresses too.
3. Needs care on the interface: a debug config option presumably,
but perhaps also needs to tie in with panic_on_oops or something -
I don't like my date getting messed up by surprise, and there's no
point in messing it up unless there's reason to believe the machine
will very quickly be rebooted. Since I had to open the lid to resume
to hit the oops, in this case we could rely on me quickly rebooting.
But I've appended what I had below, so it's on the record, and can
be taken further if (likely) someone gets there sooner than I do.
>
> > Rewarded last night by reboot to Feb 21 14:45:53 2006. Which is
> > 812d60ed intel_choose_pipe_bpp_dither.isra.13+0x216/0x2d6
> >
> > /home/hugh/3087X/drivers/gpu/drm/i915/intel_display.c:4159
> > * enable dithering as needed, but that costs bandwidth. So choose
> > * the minimum value that expresses the full color range of the fb
> > but
> > * also stays within the max display bpc discovered above.
> > */
> >
> > switch (fb->depth) {
> > 812d60e9: 48 8b 55 c0 mov-0x40(%rbp),%rdx
> > 812d60ed: 8b 02 mov(%rdx),%eax
> >
> > (gcc chose to pass a pointer to fb->depth down to the function,
> > instead of fb itself, since that is the only use of it there.)
> >
> > I expect that fb is NULL; but with an average of one failure to resume
> > per day, and ~26 bits of info per crash, this is not a fast procedure!
> >
> > I notice that intel_pipe_set_base() allows for NULL fb,
> > so I'm currently running with the oops-in-rtc hackery, plus
> > - switch (fb->depth) {
> > + if (WARN_ON(!fb))
> > + bpc = 8;
> > + else switch (fb->depth) {
> >
> > There's been a fair bit of change to intel_display.c since 3.7 (if
> > my 3.7 was indeed good), mainly splitting intel_ into haswell_ versus
> > ironlake_, but I've not yet spotted anything obvious; nor yet looked
> > to see where fb would originate from anyway.
> >
> > Once I've got just a little more info out of it, I'll start another
> > thread addressed principally to the drm/gpu/i915 guys.
>
> I think it's worth it to give them a heads-up already. So I've cc'd
> the main suspects here..
Okay, thanks.
>
> Daniel, Dave - any comments about a NULL fb in
> intel_choose_pipe_bpp_dither() during either suspend or resume? Some
> googling shows this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=895123
Great, yes, I'm sure that's the same (though it says "suspend"
and I say "resume").
>
> which sounds remarkably similar, and is also during a suspend attempt
> (but apparently Satish got a full oops out).. Some timing race with a
> worker entry?
>
> Linus
#include
#include
/*
* HughD adapted the following from drivers/base/power/trace.c:
*
* Copyright (C) 2006 Linus Torvalds
*
* Trace facility for suspend/resume problems, when none of the
* devices may be working.
*
* Horrid, horrid, horrid.
*
* It turns out that the _only_ piece of hardware that actually
* keeps its value across a hard boot (and, more importantly, the
* POST init sequence) is literally the realtime clock.
*
* Never mind that an RTC chip
Debugging Thinkpad T430s occasional suspend failure.
On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins wrote:
>
> I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
> yesterday, to save an oopsing core kernel ip there, instead of hashed
> pm trace info (it makes sense in this case to invert your sequence,
> putting the high order into years and the low order into minutes).
That sounds like a good idea in general. The PM_TRACE() thing was done
to figure out things that locked up the PCI bus etc, but encoding the
oopses during suspend sounds like a really good idea too.
Is your patch clean enough to just be made part of the standard
PM_TRACE infrastructure, or was it something really hacky and one-off?
> Rewarded last night by reboot to Feb 21 14:45:53 2006. Which is
> 812d60ed intel_choose_pipe_bpp_dither.isra.13+0x216/0x2d6
>
> /home/hugh/3087X/drivers/gpu/drm/i915/intel_display.c:4159
> * enable dithering as needed, but that costs bandwidth. So choose
> * the minimum value that expresses the full color range of the fb but
> * also stays within the max display bpc discovered above.
> */
>
> switch (fb->depth) {
> 812d60e9: 48 8b 55 c0 mov-0x40(%rbp),%rdx
> 812d60ed: 8b 02 mov(%rdx),%eax
>
> (gcc chose to pass a pointer to fb->depth down to the function,
> instead of fb itself, since that is the only use of it there.)
>
> I expect that fb is NULL; but with an average of one failure to resume
> per day, and ~26 bits of info per crash, this is not a fast procedure!
>
> I notice that intel_pipe_set_base() allows for NULL fb,
> so I'm currently running with the oops-in-rtc hackery, plus
> - switch (fb->depth) {
> + if (WARN_ON(!fb))
> + bpc = 8;
> + else switch (fb->depth) {
>
> There's been a fair bit of change to intel_display.c since 3.7 (if
> my 3.7 was indeed good), mainly splitting intel_ into haswell_ versus
> ironlake_, but I've not yet spotted anything obvious; nor yet looked
> to see where fb would originate from anyway.
>
> Once I've got just a little more info out of it, I'll start another
> thread addressed principally to the drm/gpu/i915 guys.
I think it's worth it to give them a heads-up already. So I've cc'd
the main suspects here..
Daniel, Dave - any comments about a NULL fb in
intel_choose_pipe_bpp_dither() during either suspend or resume? Some
googling shows this:
https://bugzilla.redhat.com/show_bug.cgi?id=895123
which sounds remarkably similar, and is also during a suspend attempt
(but apparently Satish got a full oops out).. Some timing race with a
worker entry?
Linus
[PATCH] gma500: Fix n, m1 and m2 clock limits for sdvo and lvds
The values of n, m1 and m2 needs to be subtracted by 2 before writing them to
the FP register. The dot clock calculation already thinks of these values in
register form so we must also specify them as such.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 8033526..9edb190 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -85,14 +85,14 @@ struct psb_intel_limit_t {
#define I9XX_DOT_MAX40
#define I9XX_VCO_MIN 140
#define I9XX_VCO_MAX 280
-#define I9XX_N_MIN 3
-#define I9XX_N_MAX 8
+#define I9XX_N_MIN 1
+#define I9XX_N_MAX 6
#define I9XX_M_MIN 70
#define I9XX_M_MAX 120
-#define I9XX_M1_MIN 10
-#define I9XX_M1_MAX 20
-#define I9XX_M2_MIN 5
-#define I9XX_M2_MAX 9
+#define I9XX_M1_MIN 8
+#define I9XX_M1_MAX 18
+#define I9XX_M2_MIN 3
+#define I9XX_M2_MAX 7
#define I9XX_P_SDVO_DAC_MIN 5
#define I9XX_P_SDVO_DAC_MAX 80
#define I9XX_P_LVDS_MIN 7
--
1.7.10.4
[Intel-gfx] [PATCH] drm/i915: Set i9xx lvds clock limits according to specifications
On Fri, Feb 15, 2013 at 2:30 PM, Patrik Jakobsson wrote: > On Fri, Feb 15, 2013 at 1:51 PM, Chris Wilson > wrote: >> On Fri, Feb 15, 2013 at 12:18:49AM +, Chris Wilson wrote: >>> On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote: >>> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 >>> > and 5-9. >>> > Since we do all calculations based on them being register values (which >>> > are >>> > subtracted by 2) we need to specify them accordingly. >>> >>> One thing I've just noticed is that intel_limits_i9xx_sdvo is reused by >>> g4x, so I'll double check that in the morning unless someone beats me to >>> it. >> >> Okay, so gen4 share the same values for sdvo as gen3, so we are okay in >> fixing those up. However, the same offset-by-2 exists for the g4x values >> of m1,m2. And one begins to suspect all the m values. >> -Chris > > Seems to be all M values. As we discussed on IRC this is confusing and it > might > be worth treating all values as according to specification and fix them up at > register read/write time. Makes it easier to read, but then again, the specs > play a trick on us by assuming that m1 and m2 are what we read from the regs > when calculating M. > > -Patrik Spotted one more thing. Dot clock min and max are based on all display modes combined. E.g. i9xx_sdvo is set to 20-400 MHz but should be 100-270 MHz and i9xx_lvds is set to 20-400 MHz but should be 20-112 MHz (single channel) and 80-224 MHz (dual channel). -Patrik
3.8.0-rc7, nouveau, possible recursive locking, nouveau_instobj_create_ and nv50_disp_data_ctor
On Sat, Feb 16, 2013 at 12:57:07AM +0200, Denys Fedoryshchenko wrote: > Hi > > Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce > 310M], latest rc, and got this. > Please let me know if you need additional information. It's harmless and already quieted down in Linus' tree (post 3.8-rc7). (Commit 5f97ab913cf0fbc378ea8ffc3ee66f4890d11c55) Marcin
Including drm-intel tree to linux-next
Hi Daniel, On Fri, 15 Feb 2013 10:43:52 +0100 Daniel Vetter wrote: > > The patches in my next queue are fully reviewed and (should) have seen > at least basic testing. The additional QA on top is just normal > regression testing and about every 2 weeks a manual testing cycle for > things like hotplug on the bazillion configurations we support (since > that takes our QA team about 1 week to complete we can't do higher > frequency there). The reason we've put that next queue buffer into > place was that before the pulls to Dave received essentially 0 testing > from our QA, resulting in lots more regressions slipping through. > -next-queued is also what I run here on all my machines and what patch > development is usually based on for drm/i915. > > Does that put your concerns at ease? Some what, thanks. -- Cheers, Stephen Rothwellsfr at canb.auug.org.au -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130216/39f24aa9/attachment.pgp>
3.8.0-rc7, nouveau, possible recursive locking, nouveau_instobj_create_ and nv50_disp_data_ctor
Hi
Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce
310M], latest rc, and got this.
Please let me know if you need additional information.
[ 16.595094] [TTM] Zone dma32: Available graphics memory: 2097152
kiB
[ 16.595096] [TTM] Initializing pool allocator
[ 16.595147] [TTM] Initializing DMA pool allocator
[ 16.600363] nouveau [ DRM] VRAM: 512 MiB
[ 16.600367] nouveau [ DRM] GART: 512 MiB
[ 16.600387] nouveau [ DRM] BIT BIOS found
[ 16.600391] nouveau [ DRM] Bios version 70.18.5f.00
[ 16.600394] nouveau [ DRM] TMDS table version 2.0
[ 16.600397] nouveau [ DRM] DCB version 4.0
[ 16.600400] nouveau [ DRM] DCB outp 00: 01000323 00010034
[ 16.600419] nouveau [ DRM] DCB outp 01: 02011300
[ 16.600421] nouveau [ DRM] DCB outp 02: 08022382 00020010
[ 16.600424] nouveau [ DRM] DCB conn 00: 0040
[ 16.600427] nouveau [ DRM] DCB conn 01: 0100
[ 16.600430] nouveau [ DRM] DCB conn 02: 2261
[ 16.677661]
[ 16.678006] =
[ 16.678006] [ INFO: possible recursive locking detected ]
[ 16.678006] 3.8.0-rc7-lap #1 Tainted: GW
[ 16.678006] -
[ 16.678006] udevd/1236 is trying to acquire lock:
[ 16.678006] (>mutex){+.+.+.}, at: []
nouveau_instobj_create_+0x3c/0x7a [nouveau]
[ 16.678006]
[ 16.678006] but task is already holding lock:
[ 16.678006] (>mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x40/0xaf [nouveau]
[ 16.678006]
[ 16.678006] other info that might help us debug this:
[ 16.678006] Possible unsafe locking scenario:
[ 16.678006]
[ 16.678006]CPU0
[ 16.678006]
[ 16.678006] lock(>mutex);
[ 16.678006] lock(>mutex);
[ 16.678006]
[ 16.678006] *** DEADLOCK ***
[ 16.678006]
[ 16.678006] May be due to missing lock nesting notation
[ 16.678006]
[ 16.678006] 4 locks held by udevd/1236:
[ 16.678006] #0: (&__lockdep_no_validate__){..}, at:
[] device_lock+0xf/0x11
[ 16.678006] #1: (&__lockdep_no_validate__){..}, at:
[] device_lock+0xf/0x11
[ 16.678006] #2: (drm_global_mutex){+.+.+.}, at:
[] drm_get_pci_dev+0xb9/0x265
[ 16.678006] #3: (>mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x40/0xaf [nouveau]
[ 16.678006]
[ 16.678006] stack backtrace:
[ 16.678006] Pid: 1236, comm: udevd Tainted: GW
3.8.0-rc7-lap #1
[ 16.678006] Call Trace:
[ 16.678006] [] __lock_acquire+0xaa2/0xebc
[ 16.678006] [] ? __module_text_address+0xd/0x5a
[ 16.678006] [] ? is_module_text_address+0x1d/0x29
[ 16.678006] [] lock_acquire+0x7e/0x94
[ 16.678006] [] ?
nouveau_instobj_create_+0x3c/0x7a [nouveau]
[ 16.678006] [] __mutex_lock_common+0x5c/0x379
[ 16.678006] [] ?
nouveau_instobj_create_+0x3c/0x7a [nouveau]
[ 16.678006] [] ?
nouveau_instobj_create_+0x3c/0x7a [nouveau]
[ 16.678006] [] mutex_lock_nested+0x3b/0x40
[ 16.678006] [] nouveau_instobj_create_+0x3c/0x7a
[nouveau]
[ 16.678006] [] nv50_instobj_ctor+0x45/0xde
[nouveau]
[ 16.678006] [] nouveau_object_ctor+0x28/0x9c
[nouveau]
[ 16.678006] [] nv50_instmem_alloc+0x21/0x23
[nouveau]
[ 16.678006] [] nouveau_gpuobj_create_+0xaa/0x22a
[nouveau]
[ 16.678006] [] ?
trace_hardirqs_on_caller+0x121/0x158
[ 16.678006] [] nouveau_engctx_create_+0xaf/0x199
[nouveau]
[ 16.678006] [] nv50_disp_data_ctor+0x8c/0xaf
[nouveau]
[ 16.678006] [] ? nouveau_subdev_reset+0x52/0x56
[nouveau]
[ 16.678006] [] nouveau_object_ctor+0x28/0x9c
[nouveau]
[ 16.678006] [] nouveau_object_new+0x129/0x1fb
[nouveau]
[ 16.678006] [] nv50_display_create+0x158/0x7c4
[nouveau]
[ 16.678006] [] ? __cancel_work_timer+0x81/0xaf
[ 16.678006] [] ? __cancel_work_timer+0x9c/0xaf
[ 16.678006] [] nouveau_display_create+0x40a/0x466
[nouveau]
[ 16.678006] [] nouveau_drm_load+0x245/0x4c0
[nouveau]
[ 16.678006] [] ? device_register+0x19/0x1e
[ 16.678006] [] ? drm_get_minor+0x226/0x280
[ 16.678006] [] drm_get_pci_dev+0x15a/0x265
[ 16.678006] [] ? __pci_set_master+0x1f/0x67
[ 16.678006] [] nouveau_drm_probe+0x1dd/0x201
[nouveau]
[ 16.678006] [] local_pci_probe+0x39/0x61
[ 16.678006] [] pci_device_probe+0x63/0x8d
[ 16.678006] [] ? driver_sysfs_add+0x6b/0x90
[ 16.678006] [] driver_probe_device+0xab/0x1c4
[ 16.678006] [] __driver_attach+0x4a/0x6b
[ 16.678006] [] ? driver_probe_device+0x1c4/0x1c4
[ 16.678006] [] bus_for_each_dev+0x57/0x84
[ 16.678006] [] driver_attach+0x19/0x1b
[ 16.678006] [] bus_add_driver+0xa8/0x1fa
[ 16.678006] [] driver_register+0x8e/0x108
[ 16.678006] [] __pci_register_driver+0x5f/0x64
[ 16.678006] [] drm_pci_init+0x85/0xea
[ 16.678006] [] ? 0xa0334fff
[ 16.678006] [] ? 0xa0334fff
[ 16.678006] [] nouveau_drm_init+0x4d/0x4f
[nouveau]
[ 16.678006] [] do_one_initcall+0x7a/0x130
[ 16.678006] [] load_module+0x168b/0x19c0
[ 16.678006] [] ?
Re: 3.8.0-rc7, nouveau, possible recursive locking, nouveau_instobj_create_ and nv50_disp_data_ctor
On Sat, Feb 16, 2013 at 12:57:07AM +0200, Denys Fedoryshchenko wrote: Hi Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce 310M], latest rc, and got this. Please let me know if you need additional information. It's harmless and already quieted down in Linus' tree (post 3.8-rc7). (Commit 5f97ab913cf0fbc378ea8ffc3ee66f4890d11c55) Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Set i9xx lvds clock limits according to specifications
On Fri, Feb 15, 2013 at 2:30 PM, Patrik Jakobsson patrik.r.jakobs...@gmail.com wrote: On Fri, Feb 15, 2013 at 1:51 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Feb 15, 2013 at 12:18:49AM +, Chris Wilson wrote: On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote: The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9. Since we do all calculations based on them being register values (which are subtracted by 2) we need to specify them accordingly. One thing I've just noticed is that intel_limits_i9xx_sdvo is reused by g4x, so I'll double check that in the morning unless someone beats me to it. Okay, so gen4 share the same values for sdvo as gen3, so we are okay in fixing those up. However, the same offset-by-2 exists for the g4x values of m1,m2. And one begins to suspect all the m values. -Chris Seems to be all M values. As we discussed on IRC this is confusing and it might be worth treating all values as according to specification and fix them up at register read/write time. Makes it easier to read, but then again, the specs play a trick on us by assuming that m1 and m2 are what we read from the regs when calculating M. -Patrik Spotted one more thing. Dot clock min and max are based on all display modes combined. E.g. i9xx_sdvo is set to 20-400 MHz but should be 100-270 MHz and i9xx_lvds is set to 20-400 MHz but should be 20-112 MHz (single channel) and 80-224 MHz (dual channel). -Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gma500: Fix n, m1 and m2 clock limits for sdvo and lvds
The values of n, m1 and m2 needs to be subtracted by 2 before writing them to
the FP register. The dot clock calculation already thinks of these values in
register form so we must also specify them as such.
Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
---
drivers/gpu/drm/gma500/psb_intel_display.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 8033526..9edb190 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -85,14 +85,14 @@ struct psb_intel_limit_t {
#define I9XX_DOT_MAX40
#define I9XX_VCO_MIN 140
#define I9XX_VCO_MAX 280
-#define I9XX_N_MIN 3
-#define I9XX_N_MAX 8
+#define I9XX_N_MIN 1
+#define I9XX_N_MAX 6
#define I9XX_M_MIN 70
#define I9XX_M_MAX 120
-#define I9XX_M1_MIN 10
-#define I9XX_M1_MAX 20
-#define I9XX_M2_MIN 5
-#define I9XX_M2_MAX 9
+#define I9XX_M1_MIN 8
+#define I9XX_M1_MAX 18
+#define I9XX_M2_MIN 3
+#define I9XX_M2_MAX 7
#define I9XX_P_SDVO_DAC_MIN 5
#define I9XX_P_SDVO_DAC_MAX 80
#define I9XX_P_LVDS_MIN 7
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37 ++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..8b2c0ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,7 +19,9 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -877,16 +879,43 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = pdata-panel.timing;
+ ret = of_get_fb_videomode(dev-of_node, fbmode,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed: devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/1] Add display-timing node parsing to exynos drm fimd
Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v5: - addressed comments from Inki Dae inki@samsung.com, to remove the allocation of 'fbmode' and replaced '-1'in of_get_fb_videomode(dev-of_node, fbmode, -1) with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel paulepan...@users.sourceforge.net, to modify the commit message changes since v3: - addressed comments from Sean Paul seanp...@chromium.org, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev-dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma r.sh.o...@gmail.com) changes since v1: - addressed comments from Sean Paul seanp...@chromium.org Vikas Sajjan (1): video: drm: exynos: Add display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37 ++ 1 file changed, 33 insertions(+), 4 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
3.8.0-rc7, nouveau, possible recursive locking, nouveau_instobj_create_ and nv50_disp_data_ctor
Hi
Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce
310M], latest rc, and got this.
Please let me know if you need additional information.
[ 16.595094] [TTM] Zone dma32: Available graphics memory: 2097152
kiB
[ 16.595096] [TTM] Initializing pool allocator
[ 16.595147] [TTM] Initializing DMA pool allocator
[ 16.600363] nouveau [ DRM] VRAM: 512 MiB
[ 16.600367] nouveau [ DRM] GART: 512 MiB
[ 16.600387] nouveau [ DRM] BIT BIOS found
[ 16.600391] nouveau [ DRM] Bios version 70.18.5f.00
[ 16.600394] nouveau [ DRM] TMDS table version 2.0
[ 16.600397] nouveau [ DRM] DCB version 4.0
[ 16.600400] nouveau [ DRM] DCB outp 00: 01000323 00010034
[ 16.600419] nouveau [ DRM] DCB outp 01: 02011300
[ 16.600421] nouveau [ DRM] DCB outp 02: 08022382 00020010
[ 16.600424] nouveau [ DRM] DCB conn 00: 0040
[ 16.600427] nouveau [ DRM] DCB conn 01: 0100
[ 16.600430] nouveau [ DRM] DCB conn 02: 2261
[ 16.677661]
[ 16.678006] =
[ 16.678006] [ INFO: possible recursive locking detected ]
[ 16.678006] 3.8.0-rc7-lap #1 Tainted: GW
[ 16.678006] -
[ 16.678006] udevd/1236 is trying to acquire lock:
[ 16.678006] (subdev-mutex){+.+.+.}, at: [a0291ca4]
nouveau_instobj_create_+0x3c/0x7a [nouveau]
[ 16.678006]
[ 16.678006] but task is already holding lock:
[ 16.678006] (subdev-mutex){+.+.+.}, at: [a02993be]
nv50_disp_data_ctor+0x40/0xaf [nouveau]
[ 16.678006]
[ 16.678006] other info that might help us debug this:
[ 16.678006] Possible unsafe locking scenario:
[ 16.678006]
[ 16.678006]CPU0
[ 16.678006]
[ 16.678006] lock(subdev-mutex);
[ 16.678006] lock(subdev-mutex);
[ 16.678006]
[ 16.678006] *** DEADLOCK ***
[ 16.678006]
[ 16.678006] May be due to missing lock nesting notation
[ 16.678006]
[ 16.678006] 4 locks held by udevd/1236:
[ 16.678006] #0: (__lockdep_no_validate__){..}, at:
[812daaf4] device_lock+0xf/0x11
[ 16.678006] #1: (__lockdep_no_validate__){..}, at:
[812daaf4] device_lock+0xf/0x11
[ 16.678006] #2: (drm_global_mutex){+.+.+.}, at:
[812c6fa7] drm_get_pci_dev+0xb9/0x265
[ 16.678006] #3: (subdev-mutex){+.+.+.}, at: [a02993be]
nv50_disp_data_ctor+0x40/0xaf [nouveau]
[ 16.678006]
[ 16.678006] stack backtrace:
[ 16.678006] Pid: 1236, comm: udevd Tainted: GW
3.8.0-rc7-lap #1
[ 16.678006] Call Trace:
[ 16.678006] [81070969] __lock_acquire+0xaa2/0xebc
[ 16.678006] [81077bd4] ? __module_text_address+0xd/0x5a
[ 16.678006] [8107b745] ? is_module_text_address+0x1d/0x29
[ 16.678006] [810711a4] lock_acquire+0x7e/0x94
[ 16.678006] [a0291ca4] ?
nouveau_instobj_create_+0x3c/0x7a [nouveau]
[ 16.678006] [815372a3] __mutex_lock_common+0x5c/0x379
[ 16.678006] [a0291ca4] ?
nouveau_instobj_create_+0x3c/0x7a [nouveau]
[ 16.678006] [a0291ca4] ?
nouveau_instobj_create_+0x3c/0x7a [nouveau]
[ 16.678006] [815376bb] mutex_lock_nested+0x3b/0x40
[ 16.678006] [a0291ca4] nouveau_instobj_create_+0x3c/0x7a
[nouveau]
[ 16.678006] [a029275b] nv50_instobj_ctor+0x45/0xde
[nouveau]
[ 16.678006] [a027c893] nouveau_object_ctor+0x28/0x9c
[nouveau]
[ 16.678006] [a029259c] nv50_instmem_alloc+0x21/0x23
[nouveau]
[ 16.678006] [a027b3af] nouveau_gpuobj_create_+0xaa/0x22a
[nouveau]
[ 16.678006] [810715e6] ?
trace_hardirqs_on_caller+0x121/0x158
[ 16.678006] [a027a366] nouveau_engctx_create_+0xaf/0x199
[nouveau]
[ 16.678006] [a029940a] nv50_disp_data_ctor+0x8c/0xaf
[nouveau]
[ 16.678006] [a027db0d] ? nouveau_subdev_reset+0x52/0x56
[nouveau]
[ 16.678006] [a027c893] nouveau_object_ctor+0x28/0x9c
[nouveau]
[ 16.678006] [a027d0a3] nouveau_object_new+0x129/0x1fb
[nouveau]
[ 16.678006] [a02f2458] nv50_display_create+0x158/0x7c4
[nouveau]
[ 16.678006] [81045117] ? __cancel_work_timer+0x81/0xaf
[ 16.678006] [81045132] ? __cancel_work_timer+0x9c/0xaf
[ 16.678006] [a02e16b5] nouveau_display_create+0x40a/0x466
[nouveau]
[ 16.678006] [a02d4d7c] nouveau_drm_load+0x245/0x4c0
[nouveau]
[ 16.678006] [812d9092] ? device_register+0x19/0x1e
[ 16.678006] [812c5db0] ? drm_get_minor+0x226/0x280
[ 16.678006] [812c7048] drm_get_pci_dev+0x15a/0x265
[ 16.678006] [8123d7a0] ? __pci_set_master+0x1f/0x67
[ 16.678006] [a02d47b5] nouveau_drm_probe+0x1dd/0x201
[nouveau]
[ 16.678006] [81240de3] local_pci_probe+0x39/0x61
[ 16.678006] [81241ce5] pci_device_probe+0x63/0x8d
[ 16.678006] [812dae6e] ? driver_sysfs_add+0x6b/0x90
[
[Bug 60955] New: [R600g] pyschonauts produces GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=60955 Priority: medium Bug ID: 60955 Assignee: dri-devel@lists.freedesktop.org Summary: [R600g] pyschonauts produces GPU lockup Severity: major Classification: Unclassified OS: Linux (All) Reporter: lordhea...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa * Kernel 3.7.7 * mesa from git (git-34dc4d6) on AMD BARTS * libdrm 2.4.42 Psychonauts locks the GPU in the intro, filling kernel log with: févr. 16 15:45:13 archMain kernel: radeon :01:00.0: GPU lockup CP stall for more than 1msec févr. 16 15:45:13 archMain systemd-journal[206]: Forwarding to syslog missed 2 messages. févr. 16 15:45:13 archMain kernel: radeon :01:00.0: GPU lockup (waiting for 0x7bc4 last fence id 0x7ba4) févr. 16 15:45:13 archMain kernel: radeon :01:00.0: couldn't schedule ib févr. 16 15:45:13 archMain kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! févr. 16 15:45:13 archMain kernel: radeon :01:00.0: couldn't schedule ib févr. 16 15:45:13 archMain kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Apitrace can reproduce the lockup on my computer: http://pkgbuild.com/~lcarlier/traces/Psychonauts.trace.tar.gz -- 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 60963] New: [r300g] Anno1701: some models are red
https://bugs.freedesktop.org/show_bug.cgi?id=60963 Priority: medium Bug ID: 60963 Assignee: dri-devel@lists.freedesktop.org Summary: [r300g] Anno1701: some models are red Severity: normal Classification: Unclassified OS: All Reporter: pavel.ondra...@email.cz Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Created attachment 74948 -- https://bugs.freedesktop.org/attachment.cgi?id=74948action=edit RADEON_DEBUG=fp,vp In Anno1701, some models are red, however they are rendered with correct colors when RADEON_DEBUG=noopt is used (or with glsl disabled in Wine). Apitrace here http://pavel.ondracka.cz/Anno1701.trace (renders fine with proprietary NVIDIA drivers). Wine: 1.5.23 GPU: RV530 Mesa: f1ab67c13ab97f19c08d99c6ba101edc7d7b80e6 Kernel: 3.7.3-101.fc17.i686 -- 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 60969] New: [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 Priority: medium Bug ID: 60969 Assignee: dri-devel@lists.freedesktop.org Summary: [r600g] Lockup while playing OpenGL games with HD6450 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: ranki...@googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa HD6450 (CAICOS), kernel 3.7.7-201.fc18.x86_64 The PC quickly locks up while playing either WoW or Minecraft 1.4.7 with Mesa from git. However, I have an earlier version of Mesa-git that plays both games correctly. The mouse cursor continues to move after the freeze, but the keyboard no longer responds. The HEAD for my working Mesa is: commit 0e2f26d5ea26febd16173aa8bbf7427b090e320f Author: Ian Romanick ian.d.roman...@intel.com Date: Fri Feb 8 18:03:33 2013 -0800 intel: Do not expose OES_compressed_ETC1_RGB8_texture or ARB_texture_rgb10_a Older hardware cannot do ARB_texture_rgb10_a2ui, and the translation code for OES_compressed_ETC1_RGB8_texture was never implemented in the i915 driver. I will try and bisect this issue when I have more time with the affected PC. Note that this issue does not happen with either my HD4670 or HD4890. -- 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: Debugging Thinkpad T430s occasional suspend failure.
On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins hu...@google.com wrote:
I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
yesterday, to save an oopsing core kernel ip there, instead of hashed
pm trace info (it makes sense in this case to invert your sequence,
putting the high order into years and the low order into minutes).
That sounds like a good idea in general. The PM_TRACE() thing was done
to figure out things that locked up the PCI bus etc, but encoding the
oopses during suspend sounds like a really good idea too.
Is your patch clean enough to just be made part of the standard
PM_TRACE infrastructure, or was it something really hacky and one-off?
Rewarded last night by reboot to Feb 21 14:45:53 2006. Which is
812d60ed intel_choose_pipe_bpp_dither.isra.13+0x216/0x2d6
/home/hugh/3087X/drivers/gpu/drm/i915/intel_display.c:4159
* enable dithering as needed, but that costs bandwidth. So choose
* the minimum value that expresses the full color range of the fb but
* also stays within the max display bpc discovered above.
*/
switch (fb-depth) {
812d60e9: 48 8b 55 c0 mov-0x40(%rbp),%rdx
812d60ed: 8b 02 mov(%rdx),%eax
(gcc chose to pass a pointer to fb-depth down to the function,
instead of fb itself, since that is the only use of it there.)
I expect that fb is NULL; but with an average of one failure to resume
per day, and ~26 bits of info per crash, this is not a fast procedure!
I notice that intel_pipe_set_base() allows for NULL fb,
so I'm currently running with the oops-in-rtc hackery, plus
- switch (fb-depth) {
+ if (WARN_ON(!fb))
+ bpc = 8;
+ else switch (fb-depth) {
There's been a fair bit of change to intel_display.c since 3.7 (if
my 3.7 was indeed good), mainly splitting intel_ into haswell_ versus
ironlake_, but I've not yet spotted anything obvious; nor yet looked
to see where fb would originate from anyway.
Once I've got just a little more info out of it, I'll start another
thread addressed principally to the drm/gpu/i915 guys.
I think it's worth it to give them a heads-up already. So I've cc'd
the main suspects here..
Daniel, Dave - any comments about a NULL fb in
intel_choose_pipe_bpp_dither() during either suspend or resume? Some
googling shows this:
https://bugzilla.redhat.com/show_bug.cgi?id=895123
which sounds remarkably similar, and is also during a suspend attempt
(but apparently Satish got a full oops out).. Some timing race with a
worker entry?
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60981] New: dri/r600: severe screen corruption with Radeon HD 6570
https://bugs.freedesktop.org/show_bug.cgi?id=60981 Priority: medium Bug ID: 60981 Assignee: dri-devel@lists.freedesktop.org Summary: dri/r600: severe screen corruption with Radeon HD 6570 Severity: major Classification: Unclassified OS: Linux (All) Reporter: st...@steve-m.de Hardware: Other Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 74957 -- https://bugs.freedesktop.org/attachment.cgi?id=74957action=edit lspci, xorg log and glxinfo With my VTX3D Radeon HD 6570 card the entire screen content is corrupted, see the images and video. The proprietary AMD driver works fine. This problem is nothing new, I've seen it since I got the card with Ubuntu 12.04, 12.10 and now 13.04 (+xorg-edgers-ppa). http://steve-m.de/pics/radeon_artifacts.png http://steve-m.de/pics/radeon_corruption.ogv Also see the attached logfiles. -- 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
