drm/vc4: false-positive negative cursor position warning

[Daniel J Blueman]

Hi Eric et al,

In a number of windowing environments (eg GNOME 3) on Raspberry Pi 3B
on 4.16.0 arm64, the mouse cursor top-left gets down to x,y -4,-4,
tripping WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y
< 0) [1], which therefore seems false-positive.

Git history doesn't turn up any reason, eg it could cause undefined
hardware behaviour, which it doesn't appear to, so would it be better
to drop the warning, or adjust it to trip on x or y < -4 or so? If so,
I'll prepare a patch to adjust it.

[Side note: simply opening the GNOME 3 Activities menu with
libgl1-mesa-dri 17.3.7 is a reliable way to reproduce "[drm] Resetting
GPU"]

Thanks,
  Dan

-- [1]

WARNING: CPU: 3 PID: 966 at drivers/gpu/drm/vc4/vc4_plane.c:771
vc4_plane_async_set_fb+0x98/0xa0
CPU: 3 PID: 966 Comm: Xorg Tainted: G S   4.16.0+ #13
Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
pstate: 0005 (nzcv daif -PAN -UAO)
pc : vc4_plane_async_set_fb+0x98/0xa0
lr : vc4_plane_async_set_fb+0x4c/0xa0
sp : 086ab9b0
x29: 086ab9b0 x28: 
x27: 0009 x26: fffc
x25: a81b36ca8b00 x24: a81b30667c00
x23: 0040 x22: a81b30790400
x21: a81b36ca8b00 x20: a81b30a53018
x19: a81b30667c00 x18: 
x17: b4fcec50 x16: 3447cc0e8588
x15: 3447d14fbf88 x14: 344851bb337f
x13: 3447d1bb338d x12: 3447d153b000
x11: 3447d14fc7f0 x10: 3447ccb3dac8
x9 : ffd0 x8 : 0005
x7 : 3932373639343932 x6 : 056e
x5 :  x4 : 
x3 :  x2 : ed59bd53d8905e00
x1 : fffc x0 : a81b30667c00
Call trace:
 vc4_plane_async_set_fb+0x98/0xa0
 vc4_update_plane+0x124/0x1a0
 __setplane_internal+0x1f4/0x260
 drm_mode_cursor_universal+0xf4/0x220
 drm_mode_cursor_common+0x19c/0x218
 drm_mode_cursor2_ioctl+0x34/0x48
 drm_ioctl_kernel+0x70/0xd8
 drm_ioctl+0x30c/0x438
 do_vfs_ioctl+0xc4/0x880
 SyS_ioctl+0x8c/0xa8
 el0_svc_naked+0x30/0x34
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vc4: Fix memory leak during BO teardown

[Daniel J Blueman]

During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being
freed leading to leaking many 128B allocations. Fix the memory leak by
releasing it at teardown time.

To: linux-ker...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Eric Anholt <e...@anholt.net>
Cc: Dave Airlie <airl...@redhat.com>
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel J Blueman <dan...@quora.org>
---
 drivers/gpu/drm/vc4/vc4_bo.c   | 2 ++
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 2decc8e2c79f..add9cc97a3b6 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -195,6 +195,7 @@ static void vc4_bo_destroy(struct vc4_bo *bo)
vc4_bo_set_label(obj, -1);
 
if (bo->validated_shader) {
+   kfree(bo->validated_shader->uniform_addr_offsets);
kfree(bo->validated_shader->texture_samples);
kfree(bo->validated_shader);
bo->validated_shader = NULL;
@@ -591,6 +592,7 @@ void vc4_free_object(struct drm_gem_object *gem_bo)
}
 
if (bo->validated_shader) {
+   kfree(bo->validated_shader->uniform_addr_offsets);
kfree(bo->validated_shader->texture_samples);
kfree(bo->validated_shader);
bo->validated_shader = NULL;
diff --git a/drivers/gpu/drm/vc4/vc4_validate_shaders.c 
b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
index d3f15bf60900..7cf82b071de2 100644
--- a/drivers/gpu/drm/vc4/vc4_validate_shaders.c
+++ b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
@@ -942,6 +942,7 @@ vc4_validate_shader(struct drm_gem_cma_object *shader_obj)
 fail:
kfree(validation_state.branch_targets);
if (validated_shader) {
+   kfree(validated_shader->uniform_addr_offsets);
kfree(validated_shader->texture_samples);
kfree(validated_shader);
}
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

nouveau graphical corruption in 3.13.2

[Daniel J Blueman]

On 23 February 2014 11:48, Ilia Mirkin  wrote:
> On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman  
> wrote:
>> On 9 February 2014 02:57, Ilia Mirkin  wrote:
>>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman  
>>> wrote:
>>>> Interestingly, there was graphical failure booting 3.6.11, even
>>>> nvidia-current fails to initialise, but these two issues could be due
>>>> to running the Xorg stack in Ubuntu 14.04 pre-release. Using
>>>> nouveau.noaccel=1 works great for the first X session, but after
>>>> logging out, lightdm and the next session experiences this consistent
>>>> screen corruption:
>>>>
>>>> http://quora.org/nouveau-corruption.jpg
>>>
>>> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
>>> points to some key lack of understanding of... something. With
>>> noaccel, we're not using pgraph or anything fancy -- it's just a
>>> framebuffer, basically. So if we can't even render _that_ right...
>>>
>>> Hopefully someone else will pipe up re your other issues -- my
>>> knowledge base on this is exhausted :(
>>
>> Interestingly, it turns out that the screen corruption occurs on every
>> boot (booting with nouveau.noaccel=1 for now), and I can consistently
>> work around it by one suspend-resume cycle.
>
> Does booting with nouveau.config=NvForcePost=1 help?

Still no cigar with nouveau.config=NvForcePost=1.

I meant to add that restarting X or changing resolutions doesn't
resolve the issue. The corruption is consistently 16-pixel wide by 1
high stippling on a consistent address range of the framebuffer.

Thanks,
  Daniel
-- 
Daniel J Blueman

nouveau graphical corruption in 3.13.2

[Daniel J Blueman]

On 9 February 2014 02:57, Ilia Mirkin  wrote:
> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman  wrote:
>> Interestingly, there was graphical failure booting 3.6.11, even
>> nvidia-current fails to initialise, but these two issues could be due
>> to running the Xorg stack in Ubuntu 14.04 pre-release. Using
>> nouveau.noaccel=1 works great for the first X session, but after
>> logging out, lightdm and the next session experiences this consistent
>> screen corruption:
>>
>> http://quora.org/nouveau-corruption.jpg
>
> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
> points to some key lack of understanding of... something. With
> noaccel, we're not using pgraph or anything fancy -- it's just a
> framebuffer, basically. So if we can't even render _that_ right...
>
> Hopefully someone else will pipe up re your other issues -- my
> knowledge base on this is exhausted :(

Interestingly, it turns out that the screen corruption occurs on every
boot (booting with nouveau.noaccel=1 for now), and I can consistently
work around it by one suspend-resume cycle.

To that effect, I've captured kernel message output booting 3.14-rc3
with 'nouveau.noaccel=1 nouveau.debug=trace,DEVINIT=spam drm.debug=0x6
log_buf_len=16M', and performed a suspend-resume cycle:
http://quora.org/nouveau-log.txt

Ben et al, would some specific register tracing or otherwise help to
locate the issue?
-- 
Daniel J Blueman

nouveau graphical corruption in 3.13.2

[Daniel J Blueman]

On 8 February 2014 16:33, Ilia Mirkin  wrote:
> On Sat, Feb 8, 2014 at 2:58 AM, Daniel J Blueman  wrote:
>> Hi guys,
>>
>> With a GeForce 320M GPU running linux 3.13.2 and Xorg 1.15.0, I'm
>> seeing significant graphical corruption and later unrecoverable GPU
>> lockup, accompanied by thousands of ILLEGAL_MTHD or related kernel
>> messages [1]. I see similar issues on 3.12 also.
>>
>> Is there any debugging or testing I can do to help diagnose this?
>
> Is this new? i.e. was there a kernel where it all worked well?
>
> You get caught by the new disable logic in 3.13 that looks at a
> register to figure out what engines have been disabled:
>
> [6.306005] nouveau W[PCE0][:04:00.0] disabled, PCE0=1 to enable
>
> Perhaps it's actually there and we have incorrect information about
> the feature disable register -- you can force-enable it with
> nouveau.config=PCE0=1 if you like. Although this logic is new in 3.13,
> so if you also saw the issue in 3.12, that's probably not the cause.
> (Also, the in-kernel logic falls back to M2MF, and so does the DDX,
> and I don't see any usage in mesa, so even _if_ it's incorrectly
> disabled, I doubt this would be your issue.)
>
> Another thing that's new in 3.13 is MSI -- you can disable it with
> nouveau.config=NvMSI=0.
>
> There's only one currently-open bug about NVAF:
> https://bugs.freedesktop.org/show_bug.cgi?id=60150 -- unfortunately
> the bug filer wasn't very specific about the issues. But it might be
> worth trying an ancient kernel (e.g. pre-3.7 -- there was a big
> rewrite in 3.7, or even one of those 3.2-based franken-kernels that
> distros maintained.) I suppose if you were to boot with
> nouveau.noaccel=1 your problems would go away, but so would any 2d/3d
> accel.
>
> [   85.751375] nouveau E[   PFIFO][:04:00.0] DMA_PUSHER - ch 3
> [Xorg[919]] get 0x0020022a4c put 0x0020023140 ib_get 0x0391 ib_put
> 0x03c2 state 0x8000e6a8 (err: INVALID_CMD) push 0x00400040
>
> I've seen this kind of error before, on many different card types, and
> have _no clue_ how it happens -- at no point is that command actually
> written to the ring (I think). After that happens, it looks like
> things get a little upset, and basically nothing works again. When
> I've seen it before things tend to recover, but I guess they don't
> have to.
>
> I wouldn't be surprised if this was some sort of issue in the fifo
> context switch code (which I'm most unfamiliar with, but others know
> more). It has all sorts of chipset-specific stuff, and chances are
> nvaf wasn't well-represented when all those were made. Assuming there
> isn't an earlier working version of nouveau, one avenue is to do a
> mmiotrace (https://wiki.ubuntu.com/X/MMIOTracing) of the blob starting
> X and running e.g. glxgears. Then one would have to look at what
> ctxprog it uploads and reconcile that with nouveau's somehow. (But
> perhaps this is entirely wrong and nouveau's ctxprogs are fine.)

Superb writeup! Indeed, booting with nouveau.config=PCI0=1 didn't help
as you deduced, nor did nouveau.config=NvMSI=0.

Interestingly, there was graphical failure booting 3.6.11, even
nvidia-current fails to initialise, but these two issues could be due
to running the Xorg stack in Ubuntu 14.04 pre-release. Using
nouveau.noaccel=1 works great for the first X session, but after
logging out, lightdm and the next session experiences this consistent
screen corruption:

http://quora.org/nouveau-corruption.jpg

Changing to other resolutions except 1280x800 (native panel
resolution), there is no corruption, but the corruption is
consistently there when changing back to 1280x800. What would be good
to look out for to help diagnose this?

Obviously noaccel is a very useful and important fallback. For the
accelerated case, I'll wait until the Nvidia blob works in Ubuntu
14.04, then employ MMIO tracing and follow up with the differences I
find.

Many thanks,
  Daniel
-- 
Daniel J Blueman

nouveau graphical corruption in 3.13.2

[Daniel J Blueman]

Hi guys,

With a GeForce 320M GPU running linux 3.13.2 and Xorg 1.15.0, I'm
seeing significant graphical corruption and later unrecoverable GPU
lockup, accompanied by thousands of ILLEGAL_MTHD or related kernel
messages [1]. I see similar issues on 3.12 also.

Is there any debugging or testing I can do to help diagnose this?

Many thanks,
  Daniel

--- [1]

http://quora.org/nouveau-dmesg.txt
http://quora.org/nouveau-Xorg.0.log
-- 
Daniel J Blueman

3.8-rc6: nouveau lockdep recursive lock acquisition

[Daniel J Blueman]

tage 630mV
nouveau [   DRM] 4: core 1254MHz shader 2508MHz memory 1080MHz voltage 630mV
nouveau [   DRM] c:
nouveau [   DRM] MM: using COPY for buffer copies
nouveau :01:00.0: No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
nouveau [   DRM] allocated 1024x768 fb: 0x8, bo 88025b966800
nouveau :01:00.0: fb1: nouveaufb frame buffer device
[drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 1
snd_hda_intel :01:00.1: enabling device ( -> 0002)
hda-intel :01:00.1: Handle VGA-switcheroo audio client
snd_hda_intel :01:00.1: irq 49 for MSI/MSI-X
input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12
input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13
hda-intel :01:00.1: Disabling via VGA-switcheroo
VGA switcheroo: switched nouveau off
nouveau [   DRM] suspending fbcon...
nouveau [   DRM] suspending display...
nouveau [   DRM] unpinning framebuffer(s)...
nouveau [   DRM] evicting buffers...
nouveau [   DRM] suspending client object trees...
nouveau E[   I2C][:01:00.0] AUXCH(3): begin idle timeout 0x
nouveau E[   I2C][:01:00.0] AUXCH(2): begin idle timeout 0x
nouveau E[   I2C][:01:00.0] AUXCH(1): begin idle timeout 0x
applesmc: light sensor data length set to 10
nouveau E[   I2C][:01:00.0] AUXCH(1): begin idle timeout 0x
nouveau E[   I2C][:01:00.0] AUXCH(3): begin idle timeout 0x
nouveau E[   I2C][:01:00.0] AUXCH(2): begin idle timeout 0x
-- 
Daniel J Blueman

3.8-rc6: nouveau lockdep recursive lock acquisition

[Daniel J Blueman]

 [8124ad0f] __pci_register_driver+0x5f/0x70
 [812ee8a5] drm_pci_init+0x115/0x130
 [a023d000] ? 0xa023cfff
 [a023d000] ? 0xa023cfff
 [a023d04d] nouveau_drm_init+0x4d/0x1000 [nouveau]
 [810002da] do_one_initcall+0x11a/0x170
 [8109d044] load_module+0xe84/0x1470
 [81098c30] ? in_lock_functions+0x20/0x20
 [8122c22e] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [8109d6e7] sys_init_module+0xb7/0xe0
 [8155c156] system_call_fastpath+0x1a/0x1f
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
nouveau W[   DRM] voltage table 0x50 unknown
nouveau [   DRM] 4 available performance level(s)
nouveau [   DRM] 1: core 209MHz shader 419MHz memory 405MHz voltage 520mV
nouveau [   DRM] 2: core 390MHz shader 780MHz memory 1080MHz voltage 610mV
nouveau [   DRM] 3: core 1000MHz shader 2000MHz memory 1080MHz voltage 630mV
nouveau [   DRM] 4: core 1254MHz shader 2508MHz memory 1080MHz voltage 630mV
nouveau [   DRM] c:
nouveau [   DRM] MM: using COPY for buffer copies
nouveau :01:00.0: No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
nouveau [   DRM] allocated 1024x768 fb: 0x8, bo 88025b966800
nouveau :01:00.0: fb1: nouveaufb frame buffer device
[drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 1
snd_hda_intel :01:00.1: enabling device ( - 0002)
hda-intel :01:00.1: Handle VGA-switcheroo audio client
snd_hda_intel :01:00.1: irq 49 for MSI/MSI-X
input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12
input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13
hda-intel :01:00.1: Disabling via VGA-switcheroo
VGA switcheroo: switched nouveau off
nouveau [   DRM] suspending fbcon...
nouveau [   DRM] suspending display...
nouveau [   DRM] unpinning framebuffer(s)...
nouveau [   DRM] evicting buffers...
nouveau [   DRM] suspending client object trees...
nouveau E[   I2C][:01:00.0] AUXCH(3): begin idle timeout 0x
nouveau E[   I2C][:01:00.0] AUXCH(2): begin idle timeout 0x
nouveau E[   I2C][:01:00.0] AUXCH(1): begin idle timeout 0x
applesmc: light sensor data length set to 10
nouveau E[   I2C][:01:00.0] AUXCH(1): begin idle timeout 0x
nouveau E[   I2C][:01:00.0] AUXCH(3): begin idle timeout 0x
nouveau E[   I2C][:01:00.0] AUXCH(2): begin idle timeout 0x
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

nouveau v3.8-rc1: evo_wait crash

[Daniel J Blueman]

When formalising a reproducer for another noveau bug, simply switching
between integrated and discrete GPUs a few times reproduces an oops in
3.8-rc1 [1,2].

Let me know if it helps to log it into bugs.freedesktop.org.

Thanks and Happy New Year!
  Daniel

--- [1]

while :; do bash -c "echo IGD
>/sys/kernel/debug/vgaswitcheroo/switch"; bash -c "echo DIS
>/sys/kernel/debug/vgaswitcheroo/switch"; done

--- [2]

...
VGA switcheroo: switched nouveau off
nouveau [   DRM] suspending fbcon...
nouveau [   DRM] suspending display...
nouveau [   DRM] unpinning framebuffer(s)...
nouveau [   DRM] evicting buffers...
nouveau [   DRM] suspending client object trees...
nouveau E[  PDISP][:01:00.0][0xc000917e][8802647d8300] fini: 0xc0080088
nouveau E[  PDISP][:01:00.0][0xc000917e][8802647d8300] failed
suspend, -16
nouveau E[   DRM] 0xd150:0xd15c7e00 suspend failed with -16
nouveau E[   DRM] 0x:0xd150 suspend failed with -16
nouveau E[   DRM] 0x:0x suspend failed with -16
nouveau E[   DRM] 0x:0x suspend failed with -16
nouveau [   DRM] resuming display...
VGA switcheroo: switched nouveau on
nouveau [   DRM] re-enabling device...
nouveau [   DRM] resuming client object trees...
nouveau [   DRM] resuming display...
BUG: unable to handle kernel paging request at 880364785ffc
IP: [] evo_wait+0x46/0xa0 [nouveau]
PGD 180d063 PUD 0
Oops: 0002 [#1] SMP
Modules linked in: snd_hda_codec_hdmi joydev hid_apple bcm5974
coretemp kvm_intel kvm rfcomm ghash_clmulni_intel bnep b43 ssb
uvcvideo smsc75xx usbnet snd_hda_codec_cirrus mii videobuf2_core i915
videobuf2_vmalloc videobuf2_memops applesmc input_polldev
snd_hda_intel snd_hda_codec microcode bcma snd_hwdep lpc_ich mfd_core
snd_pcm nouveau apple_gmux snd_timer ttm drm_kms_helper snd hwmon
mxm_wmi snd_page_alloc apple_bl video nls_iso8859_1
CPU 5
Pid: 1627, comm: bash Not tainted 3.8.0-rc1-expert+ #55 Apple Inc.
MacBookPro10,1/Mac-C3EC7CD22292981F
RIP: 0010:[] [] evo_wait+0x46/0xa0 [nouveau]
RSP: 0018:88025eec1d38 EFLAGS: 00010246
RAX: 3fff RBX: 880264700708 RCX: 880263c03d20
RDX: 880264786000 RSI:  RDI: c9000c84
RBP: 88025eec1d48 R08: 8000 R09: 
R10: 8000 R11: c9000f58 R12: 401f
R13: 880264986800 R14: 880263c1f000 R15: 
FS: 7f1b7fea5700() GS:88026f34() knlGS:
CS: 0010 DS:  ES:  CR0: 80050033
CR2: 880364785ffc CR3: 00025fa77000 CR4: 001407e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process bash (pid: 1627, threadinfo 88025eec, task 88025f834680)
Stack:
 880264986800 880264986c38 88025eec1d68 a0101bab
 88025eec1d88 88025ec5f900 88025eec1d98 a00eb003
 880264986c30 880264986c38 880264986800 880263c1f000
Call Trace:
 [] nv50_display_init+0x2b/0x90 [nouveau]
 [] nouveau_display_init+0x43/0x110 [nouveau]
 [] nouveau_display_resume+0xe6/0x180 [nouveau]
 [] nouveau_do_resume+0x106/0x120 [nouveau]
 [] nouveau_pmops_resume+0x68/0x80 [nouveau]
 [] nouveau_switcheroo_set_state+0x98/0xc0 [nouveau]
 [] vga_switchon+0x34/0x50
 [] vga_switchto_stage1+0x38/0x40
 [] vga_switcheroo_debugfs_write+0x22b/0x380
 [] ? __alloc_fd+0x42/0x110
 [] ? filp_close+0x61/0x90
 [] vfs_write+0xa3/0x160
 [] sys_write+0x4d/0xa0
 [] ? do_page_fault+0x9/0x10
 [] system_call_fastpath+0x1a/0x1f
Code: 30 c1 e8 02 48 8d 14 85 00 00 00 00 41 01 c4 41 81 fc f7 03 00
00 77 0d 48 8b 43 18 48 01 d0 5b 41 5c 5d c3 90 48 8b 53 18 31 f6 
04 82 00 00 00 20 31 d2 48 8b 3b 48 8b 07 48 8b 40 08 ff 50
RIP [] evo_wait+0x46/0xa0 [nouveau]
 RSP 
CR2: ffff880364785ffc
-- 
Daniel J Blueman

nouveau v3.8-rc1: evo_wait crash

[Daniel J Blueman]

When formalising a reproducer for another noveau bug, simply switching
between integrated and discrete GPUs a few times reproduces an oops in
3.8-rc1 [1,2].

Let me know if it helps to log it into bugs.freedesktop.org.

Thanks and Happy New Year!
  Daniel

--- [1]

while :; do bash -c echo IGD
/sys/kernel/debug/vgaswitcheroo/switch; bash -c echo DIS
/sys/kernel/debug/vgaswitcheroo/switch; done

--- [2]

...
VGA switcheroo: switched nouveau off
nouveau [   DRM] suspending fbcon...
nouveau [   DRM] suspending display...
nouveau [   DRM] unpinning framebuffer(s)...
nouveau [   DRM] evicting buffers...
nouveau [   DRM] suspending client object trees...
nouveau E[  PDISP][:01:00.0][0xc000917e][8802647d8300] fini: 0xc0080088
nouveau E[  PDISP][:01:00.0][0xc000917e][8802647d8300] failed
suspend, -16
nouveau E[   DRM] 0xd150:0xd15c7e00 suspend failed with -16
nouveau E[   DRM] 0x:0xd150 suspend failed with -16
nouveau E[   DRM] 0x:0x suspend failed with -16
nouveau E[   DRM] 0x:0x suspend failed with -16
nouveau [   DRM] resuming display...
VGA switcheroo: switched nouveau on
nouveau [   DRM] re-enabling device...
nouveau [   DRM] resuming client object trees...
nouveau [   DRM] resuming display...
BUG: unable to handle kernel paging request at 880364785ffc
IP: [a01012b6] evo_wait+0x46/0xa0 [nouveau]
PGD 180d063 PUD 0
Oops: 0002 [#1] SMP
Modules linked in: snd_hda_codec_hdmi joydev hid_apple bcm5974
coretemp kvm_intel kvm rfcomm ghash_clmulni_intel bnep b43 ssb
uvcvideo smsc75xx usbnet snd_hda_codec_cirrus mii videobuf2_core i915
videobuf2_vmalloc videobuf2_memops applesmc input_polldev
snd_hda_intel snd_hda_codec microcode bcma snd_hwdep lpc_ich mfd_core
snd_pcm nouveau apple_gmux snd_timer ttm drm_kms_helper snd hwmon
mxm_wmi snd_page_alloc apple_bl video nls_iso8859_1
CPU 5
Pid: 1627, comm: bash Not tainted 3.8.0-rc1-expert+ #55 Apple Inc.
MacBookPro10,1/Mac-C3EC7CD22292981F
RIP: 0010:[a01012b6] [a01012b6] evo_wait+0x46/0xa0 [nouveau]
RSP: 0018:88025eec1d38 EFLAGS: 00010246
RAX: 3fff RBX: 880264700708 RCX: 880263c03d20
RDX: 880264786000 RSI:  RDI: c9000c84
RBP: 88025eec1d48 R08: 8000 R09: 
R10: 8000 R11: c9000f58 R12: 401f
R13: 880264986800 R14: 880263c1f000 R15: 
FS: 7f1b7fea5700() GS:88026f34() knlGS:
CS: 0010 DS:  ES:  CR0: 80050033
CR2: 880364785ffc CR3: 00025fa77000 CR4: 001407e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process bash (pid: 1627, threadinfo 88025eec, task 88025f834680)
Stack:
 880264986800 880264986c38 88025eec1d68 a0101bab
 88025eec1d88 88025ec5f900 88025eec1d98 a00eb003
 880264986c30 880264986c38 880264986800 880263c1f000
Call Trace:
 [a0101bab] nv50_display_init+0x2b/0x90 [nouveau]
 [a00eb003] nouveau_display_init+0x43/0x110 [nouveau]
 [a00eba36] nouveau_display_resume+0xe6/0x180 [nouveau]
 [a00db856] nouveau_do_resume+0x106/0x120 [nouveau]
 [a00db8f8] nouveau_pmops_resume+0x68/0x80 [nouveau]
 [a00dd298] nouveau_switcheroo_set_state+0x98/0xc0 [nouveau]
 [812c0684] vga_switchon+0x34/0x50
 [812c0b18] vga_switchto_stage1+0x38/0x40
 [812c0ebb] vga_switcheroo_debugfs_write+0x22b/0x380
 [8110bcb2] ? __alloc_fd+0x42/0x110
 [810ef511] ? filp_close+0x61/0x90
 [810f14f3] vfs_write+0xa3/0x160
 [810f17fd] sys_write+0x4d/0xa0
 [81028689] ? do_page_fault+0x9/0x10
 [814c9a96] system_call_fastpath+0x1a/0x1f
Code: 30 c1 e8 02 48 8d 14 85 00 00 00 00 41 01 c4 41 81 fc f7 03 00
00 77 0d 48 8b 43 18 48 01 d0 5b 41 5c 5d c3 90 48 8b 53 18 31 f6 c7
04 82 00 00 00 20 31 d2 48 8b 3b 48 8b 07 48 8b 40 08 ff 50
RIP [a01012b6] evo_wait+0x46/0xa0 [nouveau]
 RSP 88025eec1d38
CR2: 880364785ffc
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: prevent log mangling

[Daniel J Blueman]

On 3.7-rc6, add missing newline to to prevent the following kernel log
line getting appended to the current one after switching the integrated
GPU and suspending the discrete GPU.

Signed-off-by: Daniel J Blueman dan...@quora.org
---
 drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c 
b/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
index fe1ebf1..dc27e79 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
@@ -50,7 +50,7 @@ auxch_init(struct nouveau_i2c *aux, int ch)
ctrl = nv_rd32(aux, 0x00e4e4 + (ch * 0x50));
udelay(1);
if (!timeout--) {
-   AUX_ERR(begin idle timeout 0x%08x, ctrl);
+   AUX_ERR(begin idle timeout 0x%08x\n, ctrl);
return -EBUSY;
}
} while (ctrl  0x0301);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: prevent log mangling

[Daniel J Blueman]

On 3.7-rc6, add missing newline to to prevent the following kernel log
line getting appended to the current one after switching the integrated
GPU and suspending the discrete GPU.

Signed-off-by: Daniel J Blueman 
---
 drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c 
b/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
index fe1ebf1..dc27e79 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
@@ -50,7 +50,7 @@ auxch_init(struct nouveau_i2c *aux, int ch)
ctrl = nv_rd32(aux, 0x00e4e4 + (ch * 0x50));
udelay(1);
if (!timeout--) {
-   AUX_ERR("begin idle timeout 0x%08x", ctrl);
+   AUX_ERR("begin idle timeout 0x%08x\n", ctrl);
return -EBUSY;
}
} while (ctrl & 0x0301);
-- 
1.7.10.4

[PATCH, RESEND] nouveau: Prevent kernel log mangling

[Daniel J Blueman]

On 3.7-rc4, add missing newline to to prevent the following kernel log
line getting appended to the current one after switching the integrated
GPU and suspending the discrete GPU.

Signed-off-by: Daniel J Blueman 
---
 drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c 
b/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
index fe1ebf1..dc27e79 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
@@ -50,7 +50,7 @@ auxch_init(struct nouveau_i2c *aux, int ch)
ctrl = nv_rd32(aux, 0x00e4e4 + (ch * 0x50));
udelay(1);
if (!timeout--) {
-   AUX_ERR("begin idle timeout 0x%08x", ctrl);
+   AUX_ERR("begin idle timeout 0x%08x\n", ctrl);
return -EBUSY;
}
} while (ctrl & 0x0301);
-- 
1.7.10.4

[PATCH, RESEND] nouveau: Prevent kernel log mangling

[Daniel J Blueman]

On 3.7-rc4, add missing newline to to prevent the following kernel log
line getting appended to the current one after switching the integrated
GPU and suspending the discrete GPU.

Signed-off-by: Daniel J Blueman dan...@quora.org
---
 drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c 
b/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
index fe1ebf1..dc27e79 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c
@@ -50,7 +50,7 @@ auxch_init(struct nouveau_i2c *aux, int ch)
ctrl = nv_rd32(aux, 0x00e4e4 + (ch * 0x50));
udelay(1);
if (!timeout--) {
-   AUX_ERR(begin idle timeout 0x%08x, ctrl);
+   AUX_ERR(begin idle timeout 0x%08x\n, ctrl);
return -EBUSY;
}
} while (ctrl  0x0301);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau: Fix crash after D3

[Daniel J Blueman]

In 3.7-rc4, when starting X with the integrated GPU and suspending the discrete 
GPU,
after one or more 32-bit applications are used (eg Skype) and X is stopped,
we hit a panic.

Prevent this by testing if the fini function is valid.

Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-crash.txt
Xorg.log is at: http://quora.org/2012/nouveau/Xorg.0.log-crash.txt
Kernel log after fix is at: http://quora.org/2012/nouveau/dmesg-fix.txt

Signed-off-by: Daniel J Blueman 
---
 drivers/gpu/drm/nouveau/core/core/object.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/object.c 
b/drivers/gpu/drm/nouveau/core/core/object.c
index 0daab62..3da3525 100644
--- a/drivers/gpu/drm/nouveau/core/core/object.c
+++ b/drivers/gpu/drm/nouveau/core/core/object.c
@@ -354,12 +354,16 @@ static int
 nouveau_object_decf(struct nouveau_object *object)
 {
int ret;
+   struct nouveau_ofuncs *pfuncs;

nv_trace(object, "stopping...\n");

-   ret = nv_ofuncs(object)->fini(object, false);
-   if (ret)
-   nv_warn(object, "failed fini, %d\n", ret);
+   pfuncs = nv_ofuncs(object);
+   if (pfuncs->fini) {
+   ret = nv_ofuncs(object)->fini(object, false);
+   if (ret)
+   nv_warn(object, "failed fini, %d\n", ret);
+   }

if (object->engine) {
mutex_lock(_subdev(object->engine)->mutex);
-- 
1.7.10.4

[PATCH] nouveau: Fix crash after D3

[Daniel J Blueman]

In 3.7-rc4, when starting X with the integrated GPU and suspending the discrete 
GPU,
after one or more 32-bit applications are used (eg Skype) and X is stopped,
we hit a panic.

Prevent this by testing if the fini function is valid.

Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-crash.txt
Xorg.log is at: http://quora.org/2012/nouveau/Xorg.0.log-crash.txt
Kernel log after fix is at: http://quora.org/2012/nouveau/dmesg-fix.txt

Signed-off-by: Daniel J Blueman dan...@quora.org
---
 drivers/gpu/drm/nouveau/core/core/object.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/object.c 
b/drivers/gpu/drm/nouveau/core/core/object.c
index 0daab62..3da3525 100644
--- a/drivers/gpu/drm/nouveau/core/core/object.c
+++ b/drivers/gpu/drm/nouveau/core/core/object.c
@@ -354,12 +354,16 @@ static int
 nouveau_object_decf(struct nouveau_object *object)
 {
int ret;
+   struct nouveau_ofuncs *pfuncs;
 
nv_trace(object, stopping...\n);
 
-   ret = nv_ofuncs(object)-fini(object, false);
-   if (ret)
-   nv_warn(object, failed fini, %d\n, ret);
+   pfuncs = nv_ofuncs(object);
+   if (pfuncs-fini) {
+   ret = nv_ofuncs(object)-fini(object, false);
+   if (ret)
+   nv_warn(object, failed fini, %d\n, ret);
+   }
 
if (object-engine) {
mutex_lock(nv_subdev(object-engine)-mutex);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Fix nouveau hang after switcheroo

[Daniel J Blueman]

After switcherooing to integrated and starting X, when X fails to start
and causes a console switch, we get hit with a hanger (below). Fix
by checking if we're already in D3.

BUG: soft lockup - CPU#0 stuck for 22s! [Xorg:1703]
 [] nv04_timer_read+0x28/0x70 [nouveau]
 [] nouveau_timer_wait_eq+0x7c/0xe0 [nouveau]
 [] nvd0_sor_dpms+0xde/0x1a0 [nouveau]
 [] ? fb_set_var+0xe9/0x3a0
 [] ? __pte_alloc+0xa9/0x160
 [] ? nvd0_sor_dp_link_set+0x2c0/0x2c0 [nouveau]
 [] drm_helper_connector_dpms+0xbc/0x100 [drm_kms_helper]
 [] drm_fb_helper_dpms.isra.13+0xa5/0xf0 [drm_kms_helper]
 [] drm_fb_helper_blank+0x49/0x80 [drm_kms_helper]
 [] fb_blank+0x56/0xc0
 [] do_fb_ioctl+0x59b/0x5f0
 [] ? vma_interval_tree_insert+0x83/0x90
 [] fb_ioctl+0x45/0x50
 [] do_vfs_ioctl+0x8a/0x340
 [] sys_ioctl+0x91/0xb0

Signed-off-by: Daniel J Blueman 
---
 drivers/gpu/drm/nouveau/nvd0_display.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c 
b/drivers/gpu/drm/nouveau/nvd0_display.c
index c402fca..c3285bf 100644
--- a/drivers/gpu/drm/nouveau/nvd0_display.c
+++ b/drivers/gpu/drm/nouveau/nvd0_display.c
@@ -1364,6 +1364,10 @@ nvd0_sor_dpms(struct drm_encoder *encoder, int mode)
int or = nv_encoder->or;
u32 dpms_ctrl;

+   /* prevent hanging after hardware is in D3 */
+   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   return;
+
nv_encoder->last_dpms = mode;

list_for_each_entry(partner, >mode_config.encoder_list, head) {
-- 
1.7.10.4

[PATCH] Fix nouveau hang after switcheroo

[Daniel J Blueman]

After switcherooing to integrated and starting X, when X fails to start
and causes a console switch, we get hit with a hanger (below). Fix
by checking if we're already in D3.

BUG: soft lockup - CPU#0 stuck for 22s! [Xorg:1703]
 [a037c538] nv04_timer_read+0x28/0x70 [nouveau]
 [a037bfec] nouveau_timer_wait_eq+0x7c/0xe0 [nouveau]
 [a03f4f4e] nvd0_sor_dpms+0xde/0x1a0 [nouveau]
 [813871d9] ? fb_set_var+0xe9/0x3a0
 [811554a9] ? __pte_alloc+0xa9/0x160
 [a03f4e70] ? nvd0_sor_dp_link_set+0x2c0/0x2c0 [nouveau]
 [a00b2a5c] drm_helper_connector_dpms+0xbc/0x100 [drm_kms_helper]
 [a00b1665] drm_fb_helper_dpms.isra.13+0xa5/0xf0 [drm_kms_helper]
 [a00b16f9] drm_fb_helper_blank+0x49/0x80 [drm_kms_helper]
 [81386e16] fb_blank+0x56/0xc0
 [813887bb] do_fb_ioctl+0x59b/0x5f0
 [81152883] ? vma_interval_tree_insert+0x83/0x90
 [81388af5] fb_ioctl+0x45/0x50
 [8119adda] do_vfs_ioctl+0x8a/0x340
 [8119b121] sys_ioctl+0x91/0xb0

Signed-off-by: Daniel J Blueman dan...@quora.org
---
 drivers/gpu/drm/nouveau/nvd0_display.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c 
b/drivers/gpu/drm/nouveau/nvd0_display.c
index c402fca..c3285bf 100644
--- a/drivers/gpu/drm/nouveau/nvd0_display.c
+++ b/drivers/gpu/drm/nouveau/nvd0_display.c
@@ -1364,6 +1364,10 @@ nvd0_sor_dpms(struct drm_encoder *encoder, int mode)
int or = nv_encoder-or;
u32 dpms_ctrl;
 
+   /* prevent hanging after hardware is in D3 */
+   if (dev-switch_power_state == DRM_SWITCH_POWER_OFF)
+   return;
+
nv_encoder-last_dpms = mode;
 
list_for_each_entry(partner, dev-mode_config.encoder_list, head) {
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon: Prevent confusion when fimware loading fails

[Daniel J Blueman]

When firmware loading fails eg due to running a newer kernel and hardware
on an older distro, prevent the user confusing this subsequent warning
backtrace with the real issue further up, ie "failed to load firmware",
which doesn't produce a backtrace.

Signed-off-by: Daniel J Blueman 
---
 drivers/gpu/drm/radeon/evergreen.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index e93b80a..444cdf5 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2416,7 +2416,7 @@ int evergreen_irq_set(struct radeon_device *rdev)
u32 afmt1 = 0, afmt2 = 0, afmt3 = 0, afmt4 = 0, afmt5 = 0, afmt6 = 0;

if (!rdev->irq.installed) {
-   WARN(1, "Can't enable IRQ/MSI because no handler is 
installed\n");
+   dev_warn(rdev->dev, "not enabling IRQ/MSI as no handler is 
installed\n");
return -EINVAL;
}
/* don't enable anything if the ih is disabled */
-- 
1.7.9.5

[PATCH] radeon: Prevent confusion when fimware loading fails

[Daniel J Blueman]

When firmware loading fails eg due to running a newer kernel and hardware
on an older distro, prevent the user confusing this subsequent warning
backtrace with the real issue further up, ie failed to load firmware,
which doesn't produce a backtrace.

Signed-off-by: Daniel J Blueman dan...@quora.org
---
 drivers/gpu/drm/radeon/evergreen.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index e93b80a..444cdf5 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2416,7 +2416,7 @@ int evergreen_irq_set(struct radeon_device *rdev)
u32 afmt1 = 0, afmt2 = 0, afmt3 = 0, afmt4 = 0, afmt5 = 0, afmt6 = 0;
 
if (!rdev-irq.installed) {
-   WARN(1, Can't enable IRQ/MSI because no handler is 
installed\n);
+   dev_warn(rdev-dev, not enabling IRQ/MSI as no handler is 
installed\n);
return -EINVAL;
}
/* don't enable anything if the ih is disabled */
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau: Fix kernel log mangling

[Daniel J Blueman]

Add missing newline to prevent the following kernel log line getting
appended to the currnet one.

Signed-off-by: Daniel J Blueman 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 7e289d2..2a9294f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -61,7 +61,7 @@ auxch_init(struct drm_device *dev, int ch)
ctrl = nv_rd32(dev, 0x00e4e4 + (ch * 0x50));
udelay(1);
if (!timeout--) {
-   AUX_ERR("begin idle timeout 0x%08x", ctrl);
+   AUX_ERR("begin idle timeout 0x%08x\n", ctrl);
return -EBUSY;
}
} while (ctrl & 0x0301);
-- 
1.7.10.4

[PATCH] nouveau: Fix kernel log mangling

[Daniel J Blueman]

Add missing newline to prevent the following kernel log line getting
appended to the currnet one.

Signed-off-by: Daniel J Blueman dan...@quora.org
---
 drivers/gpu/drm/nouveau/nouveau_dp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 7e289d2..2a9294f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -61,7 +61,7 @@ auxch_init(struct drm_device *dev, int ch)
ctrl = nv_rd32(dev, 0x00e4e4 + (ch * 0x50));
udelay(1);
if (!timeout--) {
-   AUX_ERR(begin idle timeout 0x%08x, ctrl);
+   AUX_ERR(begin idle timeout 0x%08x\n, ctrl);
return -EBUSY;
}
} while (ctrl  0x0301);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.39-rc7] i915: kworker busily spinning...

[Daniel J Blueman]

On 24 May 2011 12:02, Andy Lutomirski  wrote:
> On 05/17/2011 07:27 AM, Daniel J Blueman wrote:
>> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
>> sometimes I find one of the kworker threads busily running with 15-20%
>> system time for some minutes, causing terrible interactivity latency.
>> I've seen it occur when plugging eg a HDMI display, and also when no
>> display has been plugged (ie only the internal LVDS connection is
>> active).
>>
>> Across multiple kernel task captures, I see the kernel thread
>> consistently reading one of the connector's EDID data [1]; I guess
>> either it's having a hard time reading from a disconnected connector
>> and retrying, or is incorrectly detecting a change when there is none.
>>
>> I'll enable DRM debugging to see what connectors it believes it needs
>> to read from. Anything else that would be handy to capture, or any
>> thoughts?
>>
>> Also, the 100ms connector change polling seems overkill, particularly
>> when power consumption is important; 1000-2000ms would be sufficient,
>> do you think?
>
> I think it's meant to be every 10 seconds.
>
> In any case, the output_poll_execute code does more work than necessary,
> which might exacerbate the problem. ?Here's an old patch I wrote that
> probably doesn't apply any more but might help.

Thanks for the patch Andy; I'll test it after we've found a fix for
the underlying issue.

Daniel
-- 
Daniel J Blueman

[2.6.39-rc7] i915: kworker busily spinning...

[Daniel J Blueman]

On 17 May 2011 12:27, Daniel J Blueman  wrote:
> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
> sometimes I find one of the kworker threads busily running with 15-20%
> system time for some minutes, causing terrible interactivity latency.
> I've seen it occur when plugging eg a HDMI display, and also when no
> display has been plugged (ie only the internal LVDS connection is
> active).
>
> Across multiple kernel task captures, I see the kernel thread
> consistently reading one of the connector's EDID data [1]; I guess
> either it's having a hard time reading from a disconnected connector
> and retrying, or is incorrectly detecting a change when there is none.
>
> I'll enable DRM debugging to see what connectors it believes it needs
> to read from. Anything else that would be handy to capture, or any
> thoughts?
>
> Also, the 100ms connector change polling seems overkill, particularly
> when power consumption is important; 1000-2000ms would be sufficient,
> do you think?
>
> Thanks,
> ?Daniel
>
> --- [1]
>
> kworker/2:2 ? ? R ?running task ? ? 5048 ? ?86 ? ? ?2 0x
> ?0002 88021e804040 88021e85f9b0 88021e804040
> ?88021e85e000 4000 8802210a4040 88021e804040
> ?0046 81c18b20 88022106c000 8270b740
> Call Trace:
> ?[] ? mark_held_locks+0x70/0xa0
> ?[] ? get_parent_ip+0x11/0x50
> ?[] ? sub_preempt_count+0x9d/0xd0
> ?[] schedule_timeout+0x175/0x250
> ?[] ? run_timer_softirq+0x2a0/0x2a0
> ?[] schedule_timeout_uninterruptible+0x19/0x20
> ?[] msleep+0x18/0x20
> ?[] gmbus_xfer+0x400/0x620 [i915]
> ?[] i2c_transfer+0xa2/0xf0
> ?[] drm_do_probe_ddc_edid+0x66/0xa0 [drm]
> ?[] drm_get_edid+0x29/0x60 [drm]
> ?[] intel_hdmi_detect+0x56/0xe0 [i915]
> ?[] output_poll_execute+0xd7/0x1a0 [drm_kms_helper]
> ?[] process_one_work+0x1a4/0x450
> ?[] ? process_one_work+0x146/0x450
> ?[] ?
> drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper]
> ?[] process_scheduled_works+0x2c/0x40
> ?[] worker_thread+0x284/0x350
> ?[] ? manage_workers.clone.23+0x120/0x120
> ?[] kthread+0xb6/0xc0
> ?[] ? trace_hardirqs_on_caller+0x13d/0x180
> ?[] kernel_thread_helper+0x4/0x10
> ?[] ? finish_task_switch+0x6f/0x100
> ?[] ? retint_restore_args+0xe/0xe
> ?[] ? __init_kthread_worker+0x70/0x70
> ?[] ? gs_change+0xb/0xb

Interestingly, I appear to observe this behaviour when the laptop
battery is charging. Anyway, we see continual connector update events
[1], booted drm.debug=0x4. This reproduces with 2.6.39.

Any thoughts?

Daniel

--- [1]

[   67.035097] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2]
status updated from 2 to 2
[   67.046549] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3]
status updated from 2 to 2
[   67.047063] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.047065] [drm:ironlake_dp_detect], DPCD: 
[   67.047066] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status
updated from 2 to 2
[   67.047578] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.047579] [drm:ironlake_dp_detect], DPCD: 
[   67.047581] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status
updated from 2 to 2
[   67.047588] [drm:intel_ironlake_crt_detect_hotplug], ironlake
hotplug adpa=0xf4, result 0
[   67.047591] [drm:intel_crt_detect], CRT not detected via hotplug
[   67.047593] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status
updated from 2 to 2
[   67.059062] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1]
status updated from 2 to 2
[   67.059573] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.059575] [drm:ironlake_dp_detect], DPCD: 
[   67.059576] [drm:output_poll_execute], [CONNECTOR:18:DP-1] status
updated from 2 to 2
[   67.059886] [drm:i915_hotplug_work_func], running encoder hotplug functions
<85 lines the same>
[   67.153172] [drm:i915_hotplug_work_func], running encoder hotplug functions
[   67.155109] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2]
status updated from 2 to 2
[   67.166569] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3]
status updated from 2 to 2
[   67.167082] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.167084] [drm:ironlake_dp_detect], DPCD: 
[   67.167086] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status
updated from 2 to 2
[   67.167598] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.167600] [drm:ironlake_dp_detect], DPCD: 
[   67.167601] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status
updated from 2 to 2
[   67.167608] [drm:intel_ironlake_crt_detect_hotplug], ironlake
hotplug adpa=0xf4, result 0
[   67.167610] [drm:intel_crt_detect], CRT not detected via hotplug
[   67.167612] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status
updated from 2 to 2
[   67.179051] [drm:output_poll_exe

Re: [2.6.39-rc7] i915: kworker busily spinning...

[Daniel J Blueman]

On 17 May 2011 12:27, Daniel J Blueman daniel.blue...@gmail.com wrote:
 With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
 sometimes I find one of the kworker threads busily running with 15-20%
 system time for some minutes, causing terrible interactivity latency.
 I've seen it occur when plugging eg a HDMI display, and also when no
 display has been plugged (ie only the internal LVDS connection is
 active).

 Across multiple kernel task captures, I see the kernel thread
 consistently reading one of the connector's EDID data [1]; I guess
 either it's having a hard time reading from a disconnected connector
 and retrying, or is incorrectly detecting a change when there is none.

 I'll enable DRM debugging to see what connectors it believes it needs
 to read from. Anything else that would be handy to capture, or any
 thoughts?

 Also, the 100ms connector change polling seems overkill, particularly
 when power consumption is important; 1000-2000ms would be sufficient,
 do you think?

 Thanks,
  Daniel

 --- [1]

 kworker/2:2     R  running task     5048    86      2 0x
  0002 88021e804040 88021e85f9b0 88021e804040
  88021e85e000 4000 8802210a4040 88021e804040
  0046 81c18b20 88022106c000 8270b740
 Call Trace:
  [8109a460] ? mark_held_locks+0x70/0xa0
  [81059261] ? get_parent_ip+0x11/0x50
  [8105933d] ? sub_preempt_count+0x9d/0xd0
  [81705a35] schedule_timeout+0x175/0x250
  [8106ec10] ? run_timer_softirq+0x2a0/0x2a0
  [81705b29] schedule_timeout_uninterruptible+0x19/0x20
  [8106f878] msleep+0x18/0x20
  [a017c620] gmbus_xfer+0x400/0x620 [i915]
  [8150c892] i2c_transfer+0xa2/0xf0
  [a002bc96] drm_do_probe_ddc_edid+0x66/0xa0 [drm]
  [a002c0f9] drm_get_edid+0x29/0x60 [drm]
  [a0176f86] intel_hdmi_detect+0x56/0xe0 [i915]
  [a00d1177] output_poll_execute+0xd7/0x1a0 [drm_kms_helper]
  [81078e14] process_one_work+0x1a4/0x450
  [81078db6] ? process_one_work+0x146/0x450
  [a00d10a0] ?
 drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper]
  [810790ec] process_scheduled_works+0x2c/0x40
  [8107c384] worker_thread+0x284/0x350
  [8107c100] ? manage_workers.clone.23+0x120/0x120
  [81080ea6] kthread+0xb6/0xc0
  [8109a5cd] ? trace_hardirqs_on_caller+0x13d/0x180
  [8170a494] kernel_thread_helper+0x4/0x10
  [8104c64f] ? finish_task_switch+0x6f/0x100
  [81708bc4] ? retint_restore_args+0xe/0xe
  [81080df0] ? __init_kthread_worker+0x70/0x70
  [8170a490] ? gs_change+0xb/0xb

Interestingly, I appear to observe this behaviour when the laptop
battery is charging. Anyway, we see continual connector update events
[1], booted drm.debug=0x4. This reproduces with 2.6.39.

Any thoughts?

Daniel

--- [1]

[   67.035097] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2]
status updated from 2 to 2
[   67.046549] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3]
status updated from 2 to 2
[   67.047063] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.047065] [drm:ironlake_dp_detect], DPCD: 
[   67.047066] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status
updated from 2 to 2
[   67.047578] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.047579] [drm:ironlake_dp_detect], DPCD: 
[   67.047581] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status
updated from 2 to 2
[   67.047588] [drm:intel_ironlake_crt_detect_hotplug], ironlake
hotplug adpa=0xf4, result 0
[   67.047591] [drm:intel_crt_detect], CRT not detected via hotplug
[   67.047593] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status
updated from 2 to 2
[   67.059062] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1]
status updated from 2 to 2
[   67.059573] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.059575] [drm:ironlake_dp_detect], DPCD: 
[   67.059576] [drm:output_poll_execute], [CONNECTOR:18:DP-1] status
updated from 2 to 2
[   67.059886] [drm:i915_hotplug_work_func], running encoder hotplug functions
85 lines the same
[   67.153172] [drm:i915_hotplug_work_func], running encoder hotplug functions
[   67.155109] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2]
status updated from 2 to 2
[   67.166569] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3]
status updated from 2 to 2
[   67.167082] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.167084] [drm:ironlake_dp_detect], DPCD: 
[   67.167086] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status
updated from 2 to 2
[   67.167598] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.167600] [drm:ironlake_dp_detect], DPCD: 
[   67.167601] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status
updated from 2 to 2
[   67.167608] [drm:intel_ironlake_crt_detect_hotplug], ironlake
hotplug adpa=0xf4

Re: [2.6.39-rc7] i915: kworker busily spinning...

[Daniel J Blueman]

On 24 May 2011 12:02, Andy Lutomirski l...@mit.edu wrote:
 On 05/17/2011 07:27 AM, Daniel J Blueman wrote:
 With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
 sometimes I find one of the kworker threads busily running with 15-20%
 system time for some minutes, causing terrible interactivity latency.
 I've seen it occur when plugging eg a HDMI display, and also when no
 display has been plugged (ie only the internal LVDS connection is
 active).

 Across multiple kernel task captures, I see the kernel thread
 consistently reading one of the connector's EDID data [1]; I guess
 either it's having a hard time reading from a disconnected connector
 and retrying, or is incorrectly detecting a change when there is none.

 I'll enable DRM debugging to see what connectors it believes it needs
 to read from. Anything else that would be handy to capture, or any
 thoughts?

 Also, the 100ms connector change polling seems overkill, particularly
 when power consumption is important; 1000-2000ms would be sufficient,
 do you think?

 I think it's meant to be every 10 seconds.

 In any case, the output_poll_execute code does more work than necessary,
 which might exacerbate the problem.  Here's an old patch I wrote that
 probably doesn't apply any more but might help.

Thanks for the patch Andy; I'll test it after we've found a fix for
the underlying issue.

Daniel
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.39-rc7] i915: kworker busily spinning...

[Daniel J Blueman]

With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
sometimes I find one of the kworker threads busily running with 15-20%
system time for some minutes, causing terrible interactivity latency.
I've seen it occur when plugging eg a HDMI display, and also when no
display has been plugged (ie only the internal LVDS connection is
active).

Across multiple kernel task captures, I see the kernel thread
consistently reading one of the connector's EDID data [1]; I guess
either it's having a hard time reading from a disconnected connector
and retrying, or is incorrectly detecting a change when there is none.

I'll enable DRM debugging to see what connectors it believes it needs
to read from. Anything else that would be handy to capture, or any
thoughts?

Also, the 100ms connector change polling seems overkill, particularly
when power consumption is important; 1000-2000ms would be sufficient,
do you think?

Thanks,
  Daniel

--- [1]

kworker/2:2 R  running task 504886  2 0x
 0002 88021e804040 88021e85f9b0 88021e804040
 88021e85e000 4000 8802210a4040 88021e804040
 0046 81c18b20 88022106c000 8270b740
Call Trace:
 [] ? mark_held_locks+0x70/0xa0
 [] ? get_parent_ip+0x11/0x50
 [] ? sub_preempt_count+0x9d/0xd0
 [] schedule_timeout+0x175/0x250
 [] ? run_timer_softirq+0x2a0/0x2a0
 [] schedule_timeout_uninterruptible+0x19/0x20
 [] msleep+0x18/0x20
 [] gmbus_xfer+0x400/0x620 [i915]
 [] i2c_transfer+0xa2/0xf0
 [] drm_do_probe_ddc_edid+0x66/0xa0 [drm]
 [] drm_get_edid+0x29/0x60 [drm]
 [] intel_hdmi_detect+0x56/0xe0 [i915]
 [] output_poll_execute+0xd7/0x1a0 [drm_kms_helper]
 [] process_one_work+0x1a4/0x450
 [] ? process_one_work+0x146/0x450
 [] ?
drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper]
 [] process_scheduled_works+0x2c/0x40
 [] worker_thread+0x284/0x350
 [] ? manage_workers.clone.23+0x120/0x120
 [] kthread+0xb6/0xc0
 [] ? trace_hardirqs_on_caller+0x13d/0x180
 [] kernel_thread_helper+0x4/0x10
 [] ? finish_task_switch+0x6f/0x100
 [] ? retint_restore_args+0xe/0xe
 [] ? __init_kthread_worker+0x70/0x70
 [] ? gs_change+0xb/0xb
-- 
Daniel J Blueman

[2.6.39-rc7] i915: kworker busily spinning...

[Daniel J Blueman]

With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
sometimes I find one of the kworker threads busily running with 15-20%
system time for some minutes, causing terrible interactivity latency.
I've seen it occur when plugging eg a HDMI display, and also when no
display has been plugged (ie only the internal LVDS connection is
active).

Across multiple kernel task captures, I see the kernel thread
consistently reading one of the connector's EDID data [1]; I guess
either it's having a hard time reading from a disconnected connector
and retrying, or is incorrectly detecting a change when there is none.

I'll enable DRM debugging to see what connectors it believes it needs
to read from. Anything else that would be handy to capture, or any
thoughts?

Also, the 100ms connector change polling seems overkill, particularly
when power consumption is important; 1000-2000ms would be sufficient,
do you think?

Thanks,
  Daniel

--- [1]

kworker/2:2 R  running task 504886  2 0x
 0002 88021e804040 88021e85f9b0 88021e804040
 88021e85e000 4000 8802210a4040 88021e804040
 0046 81c18b20 88022106c000 8270b740
Call Trace:
 [8109a460] ? mark_held_locks+0x70/0xa0
 [81059261] ? get_parent_ip+0x11/0x50
 [8105933d] ? sub_preempt_count+0x9d/0xd0
 [81705a35] schedule_timeout+0x175/0x250
 [8106ec10] ? run_timer_softirq+0x2a0/0x2a0
 [81705b29] schedule_timeout_uninterruptible+0x19/0x20
 [8106f878] msleep+0x18/0x20
 [a017c620] gmbus_xfer+0x400/0x620 [i915]
 [8150c892] i2c_transfer+0xa2/0xf0
 [a002bc96] drm_do_probe_ddc_edid+0x66/0xa0 [drm]
 [a002c0f9] drm_get_edid+0x29/0x60 [drm]
 [a0176f86] intel_hdmi_detect+0x56/0xe0 [i915]
 [a00d1177] output_poll_execute+0xd7/0x1a0 [drm_kms_helper]
 [81078e14] process_one_work+0x1a4/0x450
 [81078db6] ? process_one_work+0x146/0x450
 [a00d10a0] ?
drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper]
 [810790ec] process_scheduled_works+0x2c/0x40
 [8107c384] worker_thread+0x284/0x350
 [8107c100] ? manage_workers.clone.23+0x120/0x120
 [81080ea6] kthread+0xb6/0xc0
 [8109a5cd] ? trace_hardirqs_on_caller+0x13d/0x180
 [8170a494] kernel_thread_helper+0x4/0x10
 [8104c64f] ? finish_task_switch+0x6f/0x100
 [81708bc4] ? retint_restore_args+0xe/0xe
 [81080df0] ? __init_kthread_worker+0x70/0x70
 [8170a490] ? gs_change+0xb/0xb
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.36-rc5] VGA arbiter fixlet...

[Daniel J Blueman]

Correct function being needlessly visible outside compilation unit
when the only users are internal.

Signed-off-by: Daniel J Blueman 
Reviewed-by: Alex Deucher 

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index b87569e..f366f96 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -598,7 +598,7 @@ static inline void
vga_update_device_decodes(struct vga_device *vgadev,
 pr_debug("vgaarb: decoding count now is: %d\n", vga_decode_count);
 }

-void __vga_set_legacy_decoding(struct pci_dev *pdev, unsigned int
decodes, bool userspace)
+static void __vga_set_legacy_decoding(struct pci_dev *pdev, unsigned
int decodes, bool userspace)
 {
 struct vga_device *vgadev;
 unsigned long flags;
-- 
Daniel J Blueman

[2.6.36-rc5] radeon fixes...

[Daniel J Blueman]

Fix string interpreted as trigraph and typo.

Signed-off-by: Daniel J Blueman 
Reviewed-by: Alex Deucher 

diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 1bc72c3..fe359a2 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -4999,7 +4999,7 @@ typedef struct _SW_I2C_IO_DATA_PARAMETERS
 #define SW_I2C_CNTL_WRITE1BIT 6

 //==VESA definition
Portion===
-#define VESA_OEM_PRODUCT_REV   '01.00'
+#define VESA_OEM_PRODUCT_REV   "01.00"
 #define VESA_MODE_ATTRIBUTE_MODE_SUPPORT0xBB   //refer to VBE
spec p.32, no TTY support
 #define VESA_MODE_WIN_ATTRIBUTE
 7
 #define VESA_WIN_SIZE  
 64
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index bfdfa3e..e3b47a5 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2727,7 +2727,7 @@ int r600_ib_test(struct radeon_device *rdev)
if (i < rdev->usec_timeout) {
DRM_INFO("ib test succeeded in %u usecs\n", i);
} else {
-   DRM_ERROR("radeon: ib test failed (sracth(0x%04X)=0x%08X)\n",
+   DRM_ERROR("radeon: ib test failed (scratch(0x%04X)=0x%08X)\n",
  scratch, tmp);
            r = -EINVAL;
}
-- 
Daniel J Blueman

[2.6.36-rc5] DRM fixes...

[Daniel J Blueman]

Correct function storage class, and correct assignment type.

Signed-off-by: Daniel J Blueman 
Reviewed-by: Alex Deucher 

diff --git a/drivers/gpu/drm/drm_buffer.c b/drivers/gpu/drm/drm_buffer.c
index 55d03ed..687de5f 100644
--- a/drivers/gpu/drm/drm_buffer.c
+++ b/drivers/gpu/drm/drm_buffer.c
@@ -98,7 +98,7 @@ EXPORT_SYMBOL(drm_buffer_alloc);
  *   user_data: A pointer the data that is copied to the buffer.
  *   size: The Number of bytes to copy.
  */
-extern int drm_buffer_copy_from_user(struct drm_buffer *buf,
+int drm_buffer_copy_from_user(struct drm_buffer *buf,
 void __user *user_data, int size)
 {
 int nr_pages = size / PAGE_SIZE + 1;
@@ -163,7 +163,7 @@ void *drm_buffer_read_object(struct drm_buffer *buf,
 {
 int idx = drm_buffer_index(buf);
 int page = drm_buffer_page(buf);
-void *obj = 0;
+void *obj = NULL;

 if (idx + objsize <= PAGE_SIZE) {
 obj = >data[page][idx];
-- 
Daniel J Blueman

[2.6.36-rc5] TTM fixes...

[Daniel J Blueman]

Correct allocation flags type and function prototype for ANSI C compliance.

Signed-off-by: Daniel J Blueman 
Reviewed-by: Alex Deucher 

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index ca90479..b1e02ff 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -69,7 +69,7 @@ struct ttm_page_pool {
 spinlock_tlock;
 boolfill_lock;
 struct list_headlist;
-intgfp_flags;
+gfp_tgfp_flags;
 unsignednpages;
 char*name;
 unsigned longnfrees;
@@ -475,7 +475,7 @@ static void
ttm_handle_caching_state_failure(struct list_head *pages,
  * This function is reentrant if caller updates count depending on number of
  * pages returned in pages array.
  */
-static int ttm_alloc_new_pages(struct list_head *pages, int gfp_flags,
+static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
 int ttm_flags, enum ttm_caching_state cstate, unsigned count)
 {
 struct page **caching_array;
@@ -666,7 +666,7 @@ int ttm_get_pages(struct list_head *pages, int flags,
 {
 struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
 struct page *p = NULL;
-int gfp_flags = GFP_USER;
+gfp_t gfp_flags = GFP_USER;
 int r;

 /* set zero flag for page allocation if required */
@@ -818,7 +818,7 @@ int ttm_page_alloc_init(struct ttm_mem_global
*glob, unsigned max_pages)
 return 0;
 }

-void ttm_page_alloc_fini()
+void ttm_page_alloc_fini(void)
 {
 int i;
 --
Daniel J Blueman

[2.6.36-rc5] TTM fixes...

[Daniel J Blueman]

Correct allocation flags type and function prototype for ANSI C compliance.

Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
Reviewed-by: Alex Deucher alexdeuc...@gmail.com

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index ca90479..b1e02ff 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -69,7 +69,7 @@ struct ttm_page_pool {
 spinlock_tlock;
 boolfill_lock;
 struct list_headlist;
-intgfp_flags;
+gfp_tgfp_flags;
 unsignednpages;
 char*name;
 unsigned longnfrees;
@@ -475,7 +475,7 @@ static void
ttm_handle_caching_state_failure(struct list_head *pages,
  * This function is reentrant if caller updates count depending on number of
  * pages returned in pages array.
  */
-static int ttm_alloc_new_pages(struct list_head *pages, int gfp_flags,
+static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
 int ttm_flags, enum ttm_caching_state cstate, unsigned count)
 {
 struct page **caching_array;
@@ -666,7 +666,7 @@ int ttm_get_pages(struct list_head *pages, int flags,
 {
 struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
 struct page *p = NULL;
-int gfp_flags = GFP_USER;
+gfp_t gfp_flags = GFP_USER;
 int r;

 /* set zero flag for page allocation if required */
@@ -818,7 +818,7 @@ int ttm_page_alloc_init(struct ttm_mem_global
*glob, unsigned max_pages)
 return 0;
 }

-void ttm_page_alloc_fini()
+void ttm_page_alloc_fini(void)
 {
 int i;
 --
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.36-rc5] DRM fixes...

[Daniel J Blueman]

Correct function storage class, and correct assignment type.

Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
Reviewed-by: Alex Deucher alexdeuc...@gmail.com

diff --git a/drivers/gpu/drm/drm_buffer.c b/drivers/gpu/drm/drm_buffer.c
index 55d03ed..687de5f 100644
--- a/drivers/gpu/drm/drm_buffer.c
+++ b/drivers/gpu/drm/drm_buffer.c
@@ -98,7 +98,7 @@ EXPORT_SYMBOL(drm_buffer_alloc);
  *   user_data: A pointer the data that is copied to the buffer.
  *   size: The Number of bytes to copy.
  */
-extern int drm_buffer_copy_from_user(struct drm_buffer *buf,
+int drm_buffer_copy_from_user(struct drm_buffer *buf,
 void __user *user_data, int size)
 {
 int nr_pages = size / PAGE_SIZE + 1;
@@ -163,7 +163,7 @@ void *drm_buffer_read_object(struct drm_buffer *buf,
 {
 int idx = drm_buffer_index(buf);
 int page = drm_buffer_page(buf);
-void *obj = 0;
+void *obj = NULL;

 if (idx + objsize = PAGE_SIZE) {
 obj = buf-data[page][idx];
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.36-rc5] radeon fixes...

[Daniel J Blueman]

Fix string interpreted as trigraph and typo.

Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
Reviewed-by: Alex Deucher alexdeuc...@gmail.com

diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 1bc72c3..fe359a2 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -4999,7 +4999,7 @@ typedef struct _SW_I2C_IO_DATA_PARAMETERS
 #define SW_I2C_CNTL_WRITE1BIT 6

 //==VESA definition
Portion===
-#define VESA_OEM_PRODUCT_REV   '01.00'
+#define VESA_OEM_PRODUCT_REV   01.00
 #define VESA_MODE_ATTRIBUTE_MODE_SUPPORT0xBB   //refer to VBE
spec p.32, no TTY support
 #define VESA_MODE_WIN_ATTRIBUTE
 7
 #define VESA_WIN_SIZE  
 64
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index bfdfa3e..e3b47a5 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2727,7 +2727,7 @@ int r600_ib_test(struct radeon_device *rdev)
if (i  rdev-usec_timeout) {
DRM_INFO(ib test succeeded in %u usecs\n, i);
} else {
-   DRM_ERROR(radeon: ib test failed (sracth(0x%04X)=0x%08X)\n,
+   DRM_ERROR(radeon: ib test failed (scratch(0x%04X)=0x%08X)\n,
  scratch, tmp);
r = -EINVAL;
}
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.36-rc5] VGA arbiter fixlet...

[Daniel J Blueman]

Correct function being needlessly visible outside compilation unit
when the only users are internal.

Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
Reviewed-by: Alex Deucher alexdeuc...@gmail.com

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index b87569e..f366f96 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -598,7 +598,7 @@ static inline void
vga_update_device_decodes(struct vga_device *vgadev,
 pr_debug(vgaarb: decoding count now is: %d\n, vga_decode_count);
 }

-void __vga_set_legacy_decoding(struct pci_dev *pdev, unsigned int
decodes, bool userspace)
+static void __vga_set_legacy_decoding(struct pci_dev *pdev, unsigned
int decodes, bool userspace)
 {
 struct vga_device *vgadev;
 unsigned long flags;
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

On 17 August 2010 23:37, Alex Deucher alexdeuc...@gmail.com wrote:
 On Tue, Aug 17, 2010 at 6:12 PM, Daniel J Blueman
 daniel.blue...@gmail.com wrote:
 Hi chaps,

 On 9 August 2010 14:41, Daniel J Blueman daniel.blue...@gmail.com wrote:
 On 8 August 2010 17:36, Daniel J Blueman daniel.blue...@gmail.com wrote:
 On 5 August 2010 16:23, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, Aug 5, 2010 at 9:50 AM, Jerome Glisse gli...@freedesktop.org 
 wrote:
 On 08/05/2010 06:52 AM, Daniel J Blueman wrote:

 After around 10-30 mins of typical usage (ie cairo rendering to
 surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
 locks up, giving a blank screen.

 The only information I have is a backtrace [1]. 'radeontool regs'
 doesn't give anything - what information, /sys files etc would be
 useful here, and would it be useful to log a freedesktop.org bug
 report at this stage, assuming I haven't found a reliable reproducer?

 OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.

 Thanks,
   Daniel

 --- [1]

 radeon :02:00.0: GPU lockup CP stall for more than 1000msec
 [ cut here ]
 WARNING: at
 /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
 radeon_fence_wait+0x2b7/0x320 [radeon]()
 Hardware name: Studio 1557
 GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
 Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
 microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
 ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
 snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
 nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
 snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
 iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
 snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
 dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
 i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
 i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
 sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
 libcrc32c
 Pid: 1624, comm: Xorg Tainted: G      D     2.6.35-020635-generic 
 #020635
 Call Trace:
 ? radeon_fence_wait+0x2b7/0x320 [radeon]
 warn_slowpath_common+0x90/0xc0
 warn_slowpath_fmt+0x6e/0x70
 ? schedule_timeout+0x15a/0x2e0
 ? r600_irq_set+0x27d/0xc00 [radeon]
 ? radeon_ring_commit+0xa3/0xb0 [radeon]
 ? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
 ? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
 radeon_fence_wait+0x2b7/0x320 [radeon]
 ? autoremove_wake_function+0x0/0x40
 radeon_sync_obj_wait+0x11/0x20 [radeon]
 ttm_bo_wait+0x102/0x1b0 [ttm]
 ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
 radeon_move_blit+0x124/0x170 [radeon]
 radeon_bo_move+0xda/0x1a0 [radeon]
 ttm_bo_handle_move_mem+0xec/0x370 [ttm]
 ttm_bo_evict+0x1cc/0x270 [ttm]
 ? drm_mm_split_at_start+0x1d/0x80 [drm]
 ttm_mem_evict_first+0xed/0x180 [ttm]
 ? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
 ttm_bo_mem_force_space+0xab/0x110 [ttm]
 ttm_bo_mem_space+0x305/0x370 [ttm]
 ttm_bo_move_buffer+0xcf/0x140 [ttm]
 ? drm_mm_split_at_start+0x1d/0x80 [drm]
 ttm_bo_validate+0xd5/0x100 [ttm]
 ttm_bo_init+0x1f2/0x240 [ttm]
 radeon_bo_create+0x121/0x240 [radeon]
 ? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
 radeon_gem_object_create+0x89/0x100 [radeon]
 ? drm_gem_handle_create+0x8b/0xa0 [drm]
 radeon_gem_create_ioctl+0x58/0xe0 [radeon]
 drm_ioctl+0x283/0x460 [drm]
 ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
 ? do_readv_writev+0x16b/0x1e0
 vfs_ioctl+0x3a/0xc0
 do_vfs_ioctl+0x6d/0x1f0
 sys_ioctl+0x87/0xa0
 ? sys_writev+0x55/0xb0
 system_call_fastpath+0x16/0x1b
 ---[ end trace c0bc12025fa8386c ]---
 radeon :02:00.0: GPU softreset
 radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
 radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
 radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
 radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
 radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
 radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
 radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
 radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
 radeon :02:00.0: GPU reset succeed
 Clocks initialized !
 ring test succeeded in 1 usecs
 ib test succeeded in 1 usecs

 SO it keep reseting ? According to log there is a GPU lockup but then
 a successfull GPU reset so GPU should resume fine (that's what log says)
 Best is to open a bug and attach full dmesg + lspci -vv and context
 in which the lockup happen

 Perhaps the lockup timeout is too short or interrupts are being
 delivered late or something?  There's a fdo or kernel bugzilla entry
 where removing the lockup timeout fixed the issue.  Does something
 like this:

 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -237,9 +237,11 @@ retry:
                         * as signaled for now

GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

Hi chaps,

On 9 August 2010 14:41, Daniel J Blueman  wrote:
> On 8 August 2010 17:36, Daniel J Blueman  wrote:
>> On 5 August 2010 16:23, Alex Deucher  wrote:
>>> On Thu, Aug 5, 2010 at 9:50 AM, Jerome Glisse  
>>> wrote:
>>>> On 08/05/2010 06:52 AM, Daniel J Blueman wrote:
>>>>>
>>>>> After around 10-30 mins of typical usage (ie cairo rendering to
>>>>> surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
>>>>> locks up, giving a blank screen.
>>>>>
>>>>> The only information I have is a backtrace [1]. 'radeontool regs'
>>>>> doesn't give anything - what information, /sys files etc would be
>>>>> useful here, and would it be useful to log a freedesktop.org bug
>>>>> report at this stage, assuming I haven't found a reliable reproducer?
>>>>>
>>>>> OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.
>>>>>
>>>>> Thanks,
>>>>> ? Daniel
>>>>>
>>>>> --- [1]
>>>>>
>>>>> radeon :02:00.0: GPU lockup CP stall for more than 1000msec
>>>>> [ cut here ]
>>>>> WARNING: at
>>>>> /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
>>>>> radeon_fence_wait+0x2b7/0x320 [radeon]()
>>>>> Hardware name: Studio 1557
>>>>> GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
>>>>> Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
>>>>> microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
>>>>> ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
>>>>> snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
>>>>> nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
>>>>> snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
>>>>> iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
>>>>> snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
>>>>> dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
>>>>> i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
>>>>> i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
>>>>> sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
>>>>> libcrc32c
>>>>> Pid: 1624, comm: Xorg Tainted: G ? ? ?D ? ? 2.6.35-020635-generic #020635
>>>>> Call Trace:
>>>>> ? radeon_fence_wait+0x2b7/0x320 [radeon]
>>>>> warn_slowpath_common+0x90/0xc0
>>>>> warn_slowpath_fmt+0x6e/0x70
>>>>> ? schedule_timeout+0x15a/0x2e0
>>>>> ? r600_irq_set+0x27d/0xc00 [radeon]
>>>>> ? radeon_ring_commit+0xa3/0xb0 [radeon]
>>>>> ? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
>>>>> ? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
>>>>> radeon_fence_wait+0x2b7/0x320 [radeon]
>>>>> ? autoremove_wake_function+0x0/0x40
>>>>> radeon_sync_obj_wait+0x11/0x20 [radeon]
>>>>> ttm_bo_wait+0x102/0x1b0 [ttm]
>>>>> ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
>>>>> radeon_move_blit+0x124/0x170 [radeon]
>>>>> radeon_bo_move+0xda/0x1a0 [radeon]
>>>>> ttm_bo_handle_move_mem+0xec/0x370 [ttm]
>>>>> ttm_bo_evict+0x1cc/0x270 [ttm]
>>>>> ? drm_mm_split_at_start+0x1d/0x80 [drm]
>>>>> ttm_mem_evict_first+0xed/0x180 [ttm]
>>>>> ? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
>>>>> ttm_bo_mem_force_space+0xab/0x110 [ttm]
>>>>> ttm_bo_mem_space+0x305/0x370 [ttm]
>>>>> ttm_bo_move_buffer+0xcf/0x140 [ttm]
>>>>> ? drm_mm_split_at_start+0x1d/0x80 [drm]
>>>>> ttm_bo_validate+0xd5/0x100 [ttm]
>>>>> ttm_bo_init+0x1f2/0x240 [ttm]
>>>>> radeon_bo_create+0x121/0x240 [radeon]
>>>>> ? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
>>>>> radeon_gem_object_create+0x89/0x100 [radeon]
>>>>> ? drm_gem_handle_create+0x8b/0xa0 [drm]
>>>>> radeon_gem_create_ioctl+0x58/0xe0 [radeon]
>>>>> drm_ioctl+0x283/0x460 [drm]
>>>>> ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
>>>>> ? do_readv_writev+0x16b/0x1e0
>>>>> vfs_ioctl+0x3a/0xc0
>>>>> do_vfs_ioctl+0x6d/0x1f0
>>>>> sys_ioctl+0x87/0xa0
>>>>> ? sys_w

Re: GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

Hi chaps,

On 9 August 2010 14:41, Daniel J Blueman daniel.blue...@gmail.com wrote:
 On 8 August 2010 17:36, Daniel J Blueman daniel.blue...@gmail.com wrote:
 On 5 August 2010 16:23, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, Aug 5, 2010 at 9:50 AM, Jerome Glisse gli...@freedesktop.org 
 wrote:
 On 08/05/2010 06:52 AM, Daniel J Blueman wrote:

 After around 10-30 mins of typical usage (ie cairo rendering to
 surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
 locks up, giving a blank screen.

 The only information I have is a backtrace [1]. 'radeontool regs'
 doesn't give anything - what information, /sys files etc would be
 useful here, and would it be useful to log a freedesktop.org bug
 report at this stage, assuming I haven't found a reliable reproducer?

 OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.

 Thanks,
   Daniel

 --- [1]

 radeon :02:00.0: GPU lockup CP stall for more than 1000msec
 [ cut here ]
 WARNING: at
 /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
 radeon_fence_wait+0x2b7/0x320 [radeon]()
 Hardware name: Studio 1557
 GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
 Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
 microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
 ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
 snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
 nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
 snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
 iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
 snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
 dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
 i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
 i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
 sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
 libcrc32c
 Pid: 1624, comm: Xorg Tainted: G      D     2.6.35-020635-generic #020635
 Call Trace:
 ? radeon_fence_wait+0x2b7/0x320 [radeon]
 warn_slowpath_common+0x90/0xc0
 warn_slowpath_fmt+0x6e/0x70
 ? schedule_timeout+0x15a/0x2e0
 ? r600_irq_set+0x27d/0xc00 [radeon]
 ? radeon_ring_commit+0xa3/0xb0 [radeon]
 ? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
 ? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
 radeon_fence_wait+0x2b7/0x320 [radeon]
 ? autoremove_wake_function+0x0/0x40
 radeon_sync_obj_wait+0x11/0x20 [radeon]
 ttm_bo_wait+0x102/0x1b0 [ttm]
 ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
 radeon_move_blit+0x124/0x170 [radeon]
 radeon_bo_move+0xda/0x1a0 [radeon]
 ttm_bo_handle_move_mem+0xec/0x370 [ttm]
 ttm_bo_evict+0x1cc/0x270 [ttm]
 ? drm_mm_split_at_start+0x1d/0x80 [drm]
 ttm_mem_evict_first+0xed/0x180 [ttm]
 ? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
 ttm_bo_mem_force_space+0xab/0x110 [ttm]
 ttm_bo_mem_space+0x305/0x370 [ttm]
 ttm_bo_move_buffer+0xcf/0x140 [ttm]
 ? drm_mm_split_at_start+0x1d/0x80 [drm]
 ttm_bo_validate+0xd5/0x100 [ttm]
 ttm_bo_init+0x1f2/0x240 [ttm]
 radeon_bo_create+0x121/0x240 [radeon]
 ? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
 radeon_gem_object_create+0x89/0x100 [radeon]
 ? drm_gem_handle_create+0x8b/0xa0 [drm]
 radeon_gem_create_ioctl+0x58/0xe0 [radeon]
 drm_ioctl+0x283/0x460 [drm]
 ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
 ? do_readv_writev+0x16b/0x1e0
 vfs_ioctl+0x3a/0xc0
 do_vfs_ioctl+0x6d/0x1f0
 sys_ioctl+0x87/0xa0
 ? sys_writev+0x55/0xb0
 system_call_fastpath+0x16/0x1b
 ---[ end trace c0bc12025fa8386c ]---
 radeon :02:00.0: GPU softreset
 radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
 radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
 radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
 radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
 radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
 radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
 radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
 radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
 radeon :02:00.0: GPU reset succeed
 Clocks initialized !
 ring test succeeded in 1 usecs
 ib test succeeded in 1 usecs

 SO it keep reseting ? According to log there is a GPU lockup but then
 a successfull GPU reset so GPU should resume fine (that's what log says)
 Best is to open a bug and attach full dmesg + lspci -vv and context
 in which the lockup happen

 Perhaps the lockup timeout is too short or interrupts are being
 delivered late or something?  There's a fdo or kernel bugzilla entry
 where removing the lockup timeout fixed the issue.  Does something
 like this:

 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -237,9 +237,11 @@ retry:
                         * as signaled for now
                         */
                        rdev-gpu_lockup = true;
 +#if 0
                        r = radeon_gpu_reset(rdev);
                        if (r

GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

On 8 August 2010 17:36, Daniel J Blueman  wrote:
> On 5 August 2010 16:23, Alex Deucher  wrote:
>> On Thu, Aug 5, 2010 at 9:50 AM, Jerome Glisse  
>> wrote:
>>> On 08/05/2010 06:52 AM, Daniel J Blueman wrote:
>>>>
>>>> After around 10-30 mins of typical usage (ie cairo rendering to
>>>> surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
>>>> locks up, giving a blank screen.
>>>>
>>>> The only information I have is a backtrace [1]. 'radeontool regs'
>>>> doesn't give anything - what information, /sys files etc would be
>>>> useful here, and would it be useful to log a freedesktop.org bug
>>>> report at this stage, assuming I haven't found a reliable reproducer?
>>>>
>>>> OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.
>>>>
>>>> Thanks,
>>>> ? Daniel
>>>>
>>>> --- [1]
>>>>
>>>> radeon :02:00.0: GPU lockup CP stall for more than 1000msec
>>>> [ cut here ]
>>>> WARNING: at
>>>> /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
>>>> radeon_fence_wait+0x2b7/0x320 [radeon]()
>>>> Hardware name: Studio 1557
>>>> GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
>>>> Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
>>>> microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
>>>> ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
>>>> snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
>>>> nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
>>>> snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
>>>> iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
>>>> snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
>>>> dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
>>>> i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
>>>> i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
>>>> sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
>>>> libcrc32c
>>>> Pid: 1624, comm: Xorg Tainted: G ? ? ?D ? ? 2.6.35-020635-generic #020635
>>>> Call Trace:
>>>> ? radeon_fence_wait+0x2b7/0x320 [radeon]
>>>> warn_slowpath_common+0x90/0xc0
>>>> warn_slowpath_fmt+0x6e/0x70
>>>> ? schedule_timeout+0x15a/0x2e0
>>>> ? r600_irq_set+0x27d/0xc00 [radeon]
>>>> ? radeon_ring_commit+0xa3/0xb0 [radeon]
>>>> ? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
>>>> ? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
>>>> radeon_fence_wait+0x2b7/0x320 [radeon]
>>>> ? autoremove_wake_function+0x0/0x40
>>>> radeon_sync_obj_wait+0x11/0x20 [radeon]
>>>> ttm_bo_wait+0x102/0x1b0 [ttm]
>>>> ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
>>>> radeon_move_blit+0x124/0x170 [radeon]
>>>> radeon_bo_move+0xda/0x1a0 [radeon]
>>>> ttm_bo_handle_move_mem+0xec/0x370 [ttm]
>>>> ttm_bo_evict+0x1cc/0x270 [ttm]
>>>> ? drm_mm_split_at_start+0x1d/0x80 [drm]
>>>> ttm_mem_evict_first+0xed/0x180 [ttm]
>>>> ? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
>>>> ttm_bo_mem_force_space+0xab/0x110 [ttm]
>>>> ttm_bo_mem_space+0x305/0x370 [ttm]
>>>> ttm_bo_move_buffer+0xcf/0x140 [ttm]
>>>> ? drm_mm_split_at_start+0x1d/0x80 [drm]
>>>> ttm_bo_validate+0xd5/0x100 [ttm]
>>>> ttm_bo_init+0x1f2/0x240 [ttm]
>>>> radeon_bo_create+0x121/0x240 [radeon]
>>>> ? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
>>>> radeon_gem_object_create+0x89/0x100 [radeon]
>>>> ? drm_gem_handle_create+0x8b/0xa0 [drm]
>>>> radeon_gem_create_ioctl+0x58/0xe0 [radeon]
>>>> drm_ioctl+0x283/0x460 [drm]
>>>> ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
>>>> ? do_readv_writev+0x16b/0x1e0
>>>> vfs_ioctl+0x3a/0xc0
>>>> do_vfs_ioctl+0x6d/0x1f0
>>>> sys_ioctl+0x87/0xa0
>>>> ? sys_writev+0x55/0xb0
>>>> system_call_fastpath+0x16/0x1b
>>>> ---[ end trace c0bc12025fa8386c ]---
>>>> radeon :02:00.0: GPU softreset
>>>> radeon :02:00.0: ? R_008010_GRBM_STATUS=0xA0003028
>>>> radeon :02:00.0: ? R_008014_GRBM_STATUS2=0x0002
>>>> radeon :02:00.0: ? R_000E50_SRBM_STATUS=0x20C0
>>

GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

On 5 August 2010 16:23, Alex Deucher  wrote:
> On Thu, Aug 5, 2010 at 9:50 AM, Jerome Glisse  
> wrote:
>> On 08/05/2010 06:52 AM, Daniel J Blueman wrote:
>>>
>>> After around 10-30 mins of typical usage (ie cairo rendering to
>>> surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
>>> locks up, giving a blank screen.
>>>
>>> The only information I have is a backtrace [1]. 'radeontool regs'
>>> doesn't give anything - what information, /sys files etc would be
>>> useful here, and would it be useful to log a freedesktop.org bug
>>> report at this stage, assuming I haven't found a reliable reproducer?
>>>
>>> OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.
>>>
>>> Thanks,
>>> ? Daniel
>>>
>>> --- [1]
>>>
>>> radeon :02:00.0: GPU lockup CP stall for more than 1000msec
>>> [ cut here ]
>>> WARNING: at
>>> /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
>>> radeon_fence_wait+0x2b7/0x320 [radeon]()
>>> Hardware name: Studio 1557
>>> GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
>>> Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
>>> microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
>>> ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
>>> snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
>>> nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
>>> snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
>>> iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
>>> snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
>>> dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
>>> i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
>>> i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
>>> sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
>>> libcrc32c
>>> Pid: 1624, comm: Xorg Tainted: G ? ? ?D ? ? 2.6.35-020635-generic #020635
>>> Call Trace:
>>> ? radeon_fence_wait+0x2b7/0x320 [radeon]
>>> warn_slowpath_common+0x90/0xc0
>>> warn_slowpath_fmt+0x6e/0x70
>>> ? schedule_timeout+0x15a/0x2e0
>>> ? r600_irq_set+0x27d/0xc00 [radeon]
>>> ? radeon_ring_commit+0xa3/0xb0 [radeon]
>>> ? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
>>> ? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
>>> radeon_fence_wait+0x2b7/0x320 [radeon]
>>> ? autoremove_wake_function+0x0/0x40
>>> radeon_sync_obj_wait+0x11/0x20 [radeon]
>>> ttm_bo_wait+0x102/0x1b0 [ttm]
>>> ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
>>> radeon_move_blit+0x124/0x170 [radeon]
>>> radeon_bo_move+0xda/0x1a0 [radeon]
>>> ttm_bo_handle_move_mem+0xec/0x370 [ttm]
>>> ttm_bo_evict+0x1cc/0x270 [ttm]
>>> ? drm_mm_split_at_start+0x1d/0x80 [drm]
>>> ttm_mem_evict_first+0xed/0x180 [ttm]
>>> ? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
>>> ttm_bo_mem_force_space+0xab/0x110 [ttm]
>>> ttm_bo_mem_space+0x305/0x370 [ttm]
>>> ttm_bo_move_buffer+0xcf/0x140 [ttm]
>>> ? drm_mm_split_at_start+0x1d/0x80 [drm]
>>> ttm_bo_validate+0xd5/0x100 [ttm]
>>> ttm_bo_init+0x1f2/0x240 [ttm]
>>> radeon_bo_create+0x121/0x240 [radeon]
>>> ? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
>>> radeon_gem_object_create+0x89/0x100 [radeon]
>>> ? drm_gem_handle_create+0x8b/0xa0 [drm]
>>> radeon_gem_create_ioctl+0x58/0xe0 [radeon]
>>> drm_ioctl+0x283/0x460 [drm]
>>> ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
>>> ? do_readv_writev+0x16b/0x1e0
>>> vfs_ioctl+0x3a/0xc0
>>> do_vfs_ioctl+0x6d/0x1f0
>>> sys_ioctl+0x87/0xa0
>>> ? sys_writev+0x55/0xb0
>>> system_call_fastpath+0x16/0x1b
>>> ---[ end trace c0bc12025fa8386c ]---
>>> radeon :02:00.0: GPU softreset
>>> radeon :02:00.0: ? R_008010_GRBM_STATUS=0xA0003028
>>> radeon :02:00.0: ? R_008014_GRBM_STATUS2=0x0002
>>> radeon :02:00.0: ? R_000E50_SRBM_STATUS=0x20C0
>>> radeon :02:00.0: ? R_008020_GRBM_SOFT_RESET=0x7FEE
>>> radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
>>> radeon :02:00.0: ? R_008010_GRBM_STATUS=0x3028
>>> radeon :02:00.0: ? R_008014_GRBM_STATUS2=0x0002
>>> radeon :02:00.0: ? R_000E50_SRBM_STATUS=0x20C0
>>> radeon :02:00.0: GPU reset succeed
>

Re: GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

On 5 August 2010 16:23, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, Aug 5, 2010 at 9:50 AM, Jerome Glisse gli...@freedesktop.org wrote:
 On 08/05/2010 06:52 AM, Daniel J Blueman wrote:

 After around 10-30 mins of typical usage (ie cairo rendering to
 surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
 locks up, giving a blank screen.

 The only information I have is a backtrace [1]. 'radeontool regs'
 doesn't give anything - what information, /sys files etc would be
 useful here, and would it be useful to log a freedesktop.org bug
 report at this stage, assuming I haven't found a reliable reproducer?

 OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.

 Thanks,
   Daniel

 --- [1]

 radeon :02:00.0: GPU lockup CP stall for more than 1000msec
 [ cut here ]
 WARNING: at
 /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
 radeon_fence_wait+0x2b7/0x320 [radeon]()
 Hardware name: Studio 1557
 GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
 Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
 microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
 ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
 snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
 nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
 snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
 iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
 snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
 dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
 i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
 i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
 sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
 libcrc32c
 Pid: 1624, comm: Xorg Tainted: G      D     2.6.35-020635-generic #020635
 Call Trace:
 ? radeon_fence_wait+0x2b7/0x320 [radeon]
 warn_slowpath_common+0x90/0xc0
 warn_slowpath_fmt+0x6e/0x70
 ? schedule_timeout+0x15a/0x2e0
 ? r600_irq_set+0x27d/0xc00 [radeon]
 ? radeon_ring_commit+0xa3/0xb0 [radeon]
 ? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
 ? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
 radeon_fence_wait+0x2b7/0x320 [radeon]
 ? autoremove_wake_function+0x0/0x40
 radeon_sync_obj_wait+0x11/0x20 [radeon]
 ttm_bo_wait+0x102/0x1b0 [ttm]
 ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
 radeon_move_blit+0x124/0x170 [radeon]
 radeon_bo_move+0xda/0x1a0 [radeon]
 ttm_bo_handle_move_mem+0xec/0x370 [ttm]
 ttm_bo_evict+0x1cc/0x270 [ttm]
 ? drm_mm_split_at_start+0x1d/0x80 [drm]
 ttm_mem_evict_first+0xed/0x180 [ttm]
 ? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
 ttm_bo_mem_force_space+0xab/0x110 [ttm]
 ttm_bo_mem_space+0x305/0x370 [ttm]
 ttm_bo_move_buffer+0xcf/0x140 [ttm]
 ? drm_mm_split_at_start+0x1d/0x80 [drm]
 ttm_bo_validate+0xd5/0x100 [ttm]
 ttm_bo_init+0x1f2/0x240 [ttm]
 radeon_bo_create+0x121/0x240 [radeon]
 ? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
 radeon_gem_object_create+0x89/0x100 [radeon]
 ? drm_gem_handle_create+0x8b/0xa0 [drm]
 radeon_gem_create_ioctl+0x58/0xe0 [radeon]
 drm_ioctl+0x283/0x460 [drm]
 ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
 ? do_readv_writev+0x16b/0x1e0
 vfs_ioctl+0x3a/0xc0
 do_vfs_ioctl+0x6d/0x1f0
 sys_ioctl+0x87/0xa0
 ? sys_writev+0x55/0xb0
 system_call_fastpath+0x16/0x1b
 ---[ end trace c0bc12025fa8386c ]---
 radeon :02:00.0: GPU softreset
 radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
 radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
 radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
 radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
 radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
 radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
 radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
 radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
 radeon :02:00.0: GPU reset succeed
 Clocks initialized !
 ring test succeeded in 1 usecs
 ib test succeeded in 1 usecs

 SO it keep reseting ? According to log there is a GPU lockup but then
 a successfull GPU reset so GPU should resume fine (that's what log says)
 Best is to open a bug and attach full dmesg + lspci -vv and context
 in which the lockup happen

 Perhaps the lockup timeout is too short or interrupts are being
 delivered late or something?  There's a fdo or kernel bugzilla entry
 where removing the lockup timeout fixed the issue.  Does something
 like this:

 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -237,9 +237,11 @@ retry:
                         * as signaled for now
                         */
                        rdev-gpu_lockup = true;
 +#if 0
                        r = radeon_gpu_reset(rdev);
                        if (r)
                                return r;
 +#endif
                        WREG32(rdev-fence_drv.scratch_reg, fence-seq);
                        rdev-gpu_lockup = false

GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

After around 10-30 mins of typical usage (ie cairo rendering to
surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
locks up, giving a blank screen.

The only information I have is a backtrace [1]. 'radeontool regs'
doesn't give anything - what information, /sys files etc would be
useful here, and would it be useful to log a freedesktop.org bug
report at this stage, assuming I haven't found a reliable reproducer?

OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.

Thanks,
  Daniel

--- [1]

radeon :02:00.0: GPU lockup CP stall for more than 1000msec
[ cut here ]
WARNING: at /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
radeon_fence_wait+0x2b7/0x320 [radeon]()
Hardware name: Studio 1557
GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
libcrc32c
Pid: 1624, comm: Xorg Tainted: G  D 2.6.35-020635-generic #020635
Call Trace:
? radeon_fence_wait+0x2b7/0x320 [radeon]
warn_slowpath_common+0x90/0xc0
warn_slowpath_fmt+0x6e/0x70
? schedule_timeout+0x15a/0x2e0
? r600_irq_set+0x27d/0xc00 [radeon]
? radeon_ring_commit+0xa3/0xb0 [radeon]
? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
radeon_fence_wait+0x2b7/0x320 [radeon]
? autoremove_wake_function+0x0/0x40
radeon_sync_obj_wait+0x11/0x20 [radeon]
ttm_bo_wait+0x102/0x1b0 [ttm]
ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
radeon_move_blit+0x124/0x170 [radeon]
radeon_bo_move+0xda/0x1a0 [radeon]
ttm_bo_handle_move_mem+0xec/0x370 [ttm]
ttm_bo_evict+0x1cc/0x270 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_mem_evict_first+0xed/0x180 [ttm]
? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
ttm_bo_mem_force_space+0xab/0x110 [ttm]
ttm_bo_mem_space+0x305/0x370 [ttm]
ttm_bo_move_buffer+0xcf/0x140 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_bo_validate+0xd5/0x100 [ttm]
ttm_bo_init+0x1f2/0x240 [ttm]
radeon_bo_create+0x121/0x240 [radeon]
? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
radeon_gem_object_create+0x89/0x100 [radeon]
? drm_gem_handle_create+0x8b/0xa0 [drm]
radeon_gem_create_ioctl+0x58/0xe0 [radeon]
drm_ioctl+0x283/0x460 [drm]
? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
? do_readv_writev+0x16b/0x1e0
vfs_ioctl+0x3a/0xc0
do_vfs_ioctl+0x6d/0x1f0
sys_ioctl+0x87/0xa0
? sys_writev+0x55/0xb0
system_call_fastpath+0x16/0x1b
---[ end trace c0bc12025fa8386c ]---
radeon :02:00.0: GPU softreset
radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0: GPU reset succeed
Clocks initialized !
ring test succeeded in 1 usecs
ib test succeeded in 1 usecs
-- 
Daniel J Blueman

GPU lockup+blackout on 2.6.35 with r600...

[Daniel J Blueman]

After around 10-30 mins of typical usage (ie cairo rendering to
surfaces + compiz) on my Dell Studio 15 (model 1557), my R600 radeon
locks up, giving a blank screen.

The only information I have is a backtrace [1]. 'radeontool regs'
doesn't give anything - what information, /sys files etc would be
useful here, and would it be useful to log a freedesktop.org bug
report at this stage, assuming I haven't found a reliable reproducer?

OS is Ubuntu 10.10 development release, mesa 7.8.2, libdrm2 2.4.21.

Thanks,
  Daniel

--- [1]

radeon :02:00.0: GPU lockup CP stall for more than 1000msec
[ cut here ]
WARNING: at /home/kernel-ppa/COD/linux/drivers/gpu/drm/radeon/radeon_fence.c:235
radeon_fence_wait+0x2b7/0x320 [radeon]()
Hardware name: Studio 1557
GPU lockup (waiting for 0x8C35 last fence id 0x8C33)
Modules linked in: binfmt_misc parport_pc ppdev kvm_intel kvm
microcode snd_hda_codec_atihdmi joydev ipt_REJECT xt_limit xt_tcpudp
ipt_addrtype xt_state snd_hda_codec_idt ip6table_filter ip6_tables
snd_hda_intel nf_nat_irc nf_conntrack_irc snd_hda_codec nf_nat_ftp
nf_nat snd_hwdep nf_conntrack_ipv4 snd_seq_midi arc4 snd_pcm
snd_rawmidi nf_defrag_ipv4 radeon nf_conntrack_ftp nf_conntrack
iptable_filter snd_seq_midi_event snd_seq ip_tables ttm iwlagn video
snd_timer uvcvideo x_tables snd_seq_device output drm_kms_helper lp
dell_laptop iwlcore drm videodev dcdbas dell_wmi v4l1_compat mac80211
i7core_edac parport v4l2_compat_ioctl32 snd psmouse edac_core
i2c_algo_bit soundcore cfg80211 snd_page_alloc serio_raw sdhci_pci
sdhci ahci libahci led_class r8169 mii btrfs zlib_deflate crc32c
libcrc32c
Pid: 1624, comm: Xorg Tainted: G  D 2.6.35-020635-generic #020635
Call Trace:
? radeon_fence_wait+0x2b7/0x320 [radeon]
warn_slowpath_common+0x90/0xc0
warn_slowpath_fmt+0x6e/0x70
? schedule_timeout+0x15a/0x2e0
? r600_irq_set+0x27d/0xc00 [radeon]
? radeon_ring_commit+0xa3/0xb0 [radeon]
? r100_gpu_cp_is_lockup+0xc2/0xd0 [radeon]
? r600_gpu_is_lockup+0x1cb/0x220 [radeon]
radeon_fence_wait+0x2b7/0x320 [radeon]
? autoremove_wake_function+0x0/0x40
radeon_sync_obj_wait+0x11/0x20 [radeon]
ttm_bo_wait+0x102/0x1b0 [ttm]
ttm_bo_move_accel_cleanup+0x19e/0x230 [ttm]
radeon_move_blit+0x124/0x170 [radeon]
radeon_bo_move+0xda/0x1a0 [radeon]
ttm_bo_handle_move_mem+0xec/0x370 [ttm]
ttm_bo_evict+0x1cc/0x270 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_mem_evict_first+0xed/0x180 [ttm]
? ttm_bo_man_get_node+0xd5/0xe0 [ttm]
ttm_bo_mem_force_space+0xab/0x110 [ttm]
ttm_bo_mem_space+0x305/0x370 [ttm]
ttm_bo_move_buffer+0xcf/0x140 [ttm]
? drm_mm_split_at_start+0x1d/0x80 [drm]
ttm_bo_validate+0xd5/0x100 [ttm]
ttm_bo_init+0x1f2/0x240 [ttm]
radeon_bo_create+0x121/0x240 [radeon]
? radeon_ttm_bo_destroy+0x0/0x80 [radeon]
radeon_gem_object_create+0x89/0x100 [radeon]
? drm_gem_handle_create+0x8b/0xa0 [drm]
radeon_gem_create_ioctl+0x58/0xe0 [radeon]
drm_ioctl+0x283/0x460 [drm]
? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
? do_readv_writev+0x16b/0x1e0
vfs_ioctl+0x3a/0xc0
do_vfs_ioctl+0x6d/0x1f0
sys_ioctl+0x87/0xa0
? sys_writev+0x55/0xb0
system_call_fastpath+0x16/0x1b
---[ end trace c0bc12025fa8386c ]---
radeon :02:00.0: GPU softreset
radeon :02:00.0:   R_008010_GRBM_STATUS=0xA0003028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001
radeon :02:00.0:   R_008010_GRBM_STATUS=0x3028
radeon :02:00.0:   R_008014_GRBM_STATUS2=0x0002
radeon :02:00.0:   R_000E50_SRBM_STATUS=0x20C0
radeon :02:00.0: GPU reset succeed
Clocks initialized !
ring test succeeded in 1 usecs
ib test succeeded in 1 usecs
-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.35-rc6 patch] fix radeon mid power profile reporting

[Daniel J Blueman]

Hi Dave,

This one-liner may be a suitable late-fix for 2.6.35-final:

Fix incorrectly reporting 'default' power profile, when it is set to 'mid'.

Signed-off-by: Daniel J Blueman 

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 115d26b..3fa6984 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -333,6 +333,7 @@ static ssize_t radeon_get_pm_profile(struct device *dev,
return snprintf(buf, PAGE_SIZE, "%s\n",
(cp == PM_PROFILE_AUTO) ? "auto" :
(cp == PM_PROFILE_LOW) ? "low" :
+   (cp == PM_PROFILE_MID) ? "mid" :
(cp == PM_PROFILE_HIGH) ? "high" : "default");
 }

-- 
Daniel J Blueman

[2.6.35-rc6 patch] fix radeon mid power profile reporting

[Daniel J Blueman]

Hi Dave,

This one-liner may be a suitable late-fix for 2.6.35-final:

Fix incorrectly reporting 'default' power profile, when it is set to 'mid'.

Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 115d26b..3fa6984 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -333,6 +333,7 @@ static ssize_t radeon_get_pm_profile(struct device *dev,
return snprintf(buf, PAGE_SIZE, %s\n,
(cp == PM_PROFILE_AUTO) ? auto :
(cp == PM_PROFILE_LOW) ? low :
+   (cp == PM_PROFILE_MID) ? mid :
(cp == PM_PROFILE_HIGH) ? high : default);
 }

-- 
Daniel J Blueman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.35-rc6 patch] correct function definitions

[Daniel J Blueman]

Hi David,

Some fixes for some benign issues I spotted.

Thanks,
  Daniel

---

Correct minor issues with function definitions for compliance.

Signed-off-by: Daniel J Blueman 

diff --git a/drivers/gpu/drm/drm_buffer.c b/drivers/gpu/drm/drm_buffer.c
index 55d03ed..34a506f 100644
--- a/drivers/gpu/drm/drm_buffer.c
+++ b/drivers/gpu/drm/drm_buffer.c
@@ -98,7 +98,7 @@ EXPORT_SYMBOL(drm_buffer_alloc);
  *   user_data: A pointer the data that is copied to the buffer.
  *   size: The Number of bytes to copy.
  */
-extern int drm_buffer_copy_from_user(struct drm_buffer *buf,
+int drm_buffer_copy_from_user(struct drm_buffer *buf,
void __user *user_data, int size)
 {
int nr_pages = size / PAGE_SIZE + 1;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index ca90479..8464b56 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -818,7 +818,7 @@ int ttm_page_alloc_init(struct ttm_mem_global
*glob, unsigned max_pages)
return 0;
 }

-void ttm_page_alloc_fini()
+void ttm_page_alloc_fini(void)
 {
int i;

-- 
Daniel J Blueman