Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > On 2012.12.20 at 14:45 +0100, Markus Trippelsdorf wrote: > > On 2012.12.20 at 08:30 -0500, Alex Deucher wrote: > > > On Wed, Dec 19, 2012 at 9:33 AM, Markus Trippelsdorf > > > wrote: > > > > On 2012.12.19 at 15:18 +0100, Maarten Lankhorst wrote: > > > >> Fix regression introduced by 85b144f860176 > > > > > > > > (EE) [mi] EQ overflow continuing. 100 events have been dropped. > > > > (EE) > > > > (EE) Backtrace: > > > > (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x584f1d] > > > > (EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x44a792] > > > > (EE) 2: /usr/bin/X (xf86PostButtonEvent+0xd5) [0x4829b5] > > > > (EE) 3: /usr/lib64/xorg/modules/input/mouse_drv.so > > > > (0x7ff8f2501000+0x6b70) [0x7ff8f2507b70] > > > > (EE) 4: /usr/lib64/xorg/modules/input/mouse_drv.so > > > > (0x7ff8f2501000+0x73a0) [0x7ff8f25083a0] > > > > (EE) 5: /usr/lib64/xorg/modules/input/mouse_drv.so > > > > (0x7ff8f2501000+0x428c) [0x7ff8f250528c] > > > > (EE) 6: /usr/bin/X (0x40+0x71cd8) [0x471cd8] > > > > (EE) 7: /usr/bin/X (0x40+0x9a2ab) [0x49a2ab] > > > > (EE) 8: /lib/libpthread.so.0 (0x7ff8f1edc000+0xf260) [0x7ff8f1eeb260] > > > > (EE) 9: /lib/libc.so.6 (ioctl+0x7) [0x7ff8f19bd127] > > > > (EE) 10: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0x7ff8f246a634] > > > > (EE) 11: /usr/lib/libdrm.so.2 (drmCommandWriteRead+0x1f) > > > > [0x7ff8f246cbdf] > > > > (EE) 12: /usr/lib/libdrm_radeon.so.1 (0x7ff8f250e000+0x27bf) > > > > [0x7ff8f25107bf] > > > > (EE) 13: /usr/lib64/xorg/modules/drivers/radeon_drv.so > > > > (0x7ff8f154f000+0x407ec) [0x7ff8f158f7ec] > > > > (EE) 14: /usr/bin/X (_CallCallbacks+0x34) [0x438894] > > > > (EE) 15: /usr/bin/X (FlushAllOutput+0x2c) [0x5880ec] > > > > (EE) 16: /usr/bin/X (0x40+0x33aa1) [0x433aa1] > > > > (EE) 17: /usr/bin/X (0x40+0x230cd) [0x4230cd] > > > > (EE) 18: /lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff8f19088b5] > > > > (EE) 19: /usr/bin/X (0x40+0x22c09) [0x422c09] > > > > (EE) > > > > (EE) [mi] EQ overflow continuing. 200 events have been dropped. > > > > > > > > And the pictures get distorted on the test-webpage. See attached > > > > screenshot. > > > > > > > > > > Anything in your kernel log that corresponds to the errors in your xorg > > > log? > > > > No. But I've found out that the errors in the xorg log are unrelated to > > the image corruption. > > I use one of those Logitech mice with this "hyper" fast scrolling > > feature. And I guess the Xorg mouse driver just can't keep up with the > > fast input. So it's just a harmless warning that can be ignored, I > > guess. > > And just in case it got lost in the noise yesterday: > The image corruption is caused by Dave's commit: > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > Author: Dave Airlie > Date: Fri Dec 14 21:04:46 2012 +1000 > > radeon: fix regression with eviction since evict caching changes > > Reverting it 'fixes' the issue. Ping. The issue still happens with todays Linus git tree. Can you please have a look at this Dave? Thanks. -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
Hi,
I am getting this during hibernate/resume with current Linus' head
(5f738967e89584f99c6a11c6bf09b16c50b6a03e).
==
[ INFO: possible circular locking dependency detected ]
3.8.0-rc2-00038-ge93d369 #178 Not tainted
---
s2disk/3024 is trying to acquire lock:
((fb_notifier_list).rwsem){.+}, at: []
__blocking_notifier_call_chain+0x5a/0xd0
but task is already holding lock:
(console_lock){+.+.+.}, at: [] do_fb_ioctl+0x455/0x590
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] lock_acquire+0x121/0x190
[] console_lock+0x6f/0x80
[] register_con_driver+0x5d/0x160
[] take_over_console+0x2d/0x70
[] fbcon_takeover+0x63/0xc0
[] fbcon_fb_registered+0xc5/0x170
[] fbcon_event_notify+0x1d8/0x690
[] notifier_call_chain+0x93/0x140
[] __blocking_notifier_call_chain+0x71/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] do_register_framebuffer+0x221/0x2e0
[] register_framebuffer+0x22/0x40
[] drm_fb_helper_single_fb_probe+0x2bc/0x300
[drm_kms_helper]
[] drm_fb_helper_initial_config+0x92/0xd0
[drm_kms_helper]
[] intel_fbdev_init+0x8b/0xc0 [i915]
[] i915_load_modeset_init+0x113/0x1d0 [i915]
[] i915_driver_load+0x5e5/0x940 [i915]
[] drm_get_pci_dev+0x196/0x2a0 [drm]
[] i915_pci_probe+0x3d/0x90 [i915]
[] local_pci_probe+0x49/0x80
[] __pci_device_probe+0xd9/0xe0
[] pci_device_probe+0x36/0x60
[] really_probe+0x79/0x350
[] driver_probe_device+0x54/0xa0
[] __driver_attach+0x9b/0xa0
[] bus_for_each_dev+0x68/0x90
[] driver_attach+0x1c/0x20
[] bus_add_driver+0x1d8/0x290
[] driver_register+0x63/0x150
[] __pci_register_driver+0x62/0x70
[] drm_pci_init+0x10c/0x120 [drm]
[] tpm_bios_measurements_start+0x5d/0xa0 [tpm_bios]
[] do_one_initcall+0x3d/0x180
[] do_init_module+0x6b/0x1d0
[] load_module+0x6fe/0x7e0
[] sys_init_module+0x9b/0xc0
[] system_call_fastpath+0x16/0x1b
-> #0 ((fb_notifier_list).rwsem){.+}:
[] check_prev_add+0x3de/0x440
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] lock_acquire+0x121/0x190
[] down_read+0x42/0x60
[] __blocking_notifier_call_chain+0x5a/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_var+0x232/0x3e0
[] do_fb_ioctl+0x468/0x590
[] fb_ioctl+0x3d/0x50
[] do_vfs_ioctl+0x9d/0x350
[] sys_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
*** DEADLOCK ***
2 locks held by s2disk/3024:
#0: (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x22/0x50
#1: (console_lock){+.+.+.}, at: [] do_fb_ioctl+0x455/0x590
stack backtrace:
Pid: 3024, comm: s2disk Not tainted 3.8.0-rc2-00038-ge93d369 #178
Call Trace:
[] print_circular_bug+0x10f/0x120
[] check_prev_add+0x3de/0x440
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] ? trace_hardirqs_on+0xd/0x10
[] lock_acquire+0x121/0x190
[] ? __blocking_notifier_call_chain+0x5a/0xd0
[] down_read+0x42/0x60
[] ? __blocking_notifier_call_chain+0x5a/0xd0
[] __blocking_notifier_call_chain+0x5a/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_var+0x232/0x3e0
[] ? do_fb_ioctl+0x455/0x590
[] ? trace_hardirqs_on+0xd/0x10
[] do_fb_ioctl+0x468/0x590
[] ? __lock_acquire+0x359/0x580
[] ? fget_light+0xbc/0x480
[] fb_ioctl+0x3d/0x50
[] do_vfs_ioctl+0x9d/0x350
[] ? fget_light+0x37/0x480
[] sys_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 runetmem...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from runetmem...@gmail.com --- INVALID then? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Resume regression with nouveau 3.8rc1 (bisected)
On Sat, Jan 05, 2013 at 10:10:06AM +0100, Pontus Fuchs wrote: > On 01/03/2013 08:12 PM, Marcin Slusarz wrote: > > On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote: > >> I bisected the problem down to this commit: > >> > >> 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > >> > >> Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. > >> There's already open bug report for that: > >> https://bugs.freedesktop.org/show_bug.cgi?id=58729 > > Yay, a bug fix was just posted there ;). > > Hi, I tried that patch but it didn't help :( > > I see this in my kernel log after resume: > > nouveau E[ PFB][:01:00.0] trapped read at 0x002001a020 on > channel 0x7b23 SEMAPHORE_BG/PFIFO_READ/00 reason: PAGE_NOT_PRESENT > nouveau E[1177] failed to idle channel 0x > [TTM] Failed to expire sync object before buffer eviction > [TTM] Failed to expire sync object before buffer eviction > [TTM] Failed to expire sync object before buffer eviction Sigh, this seems to be another issue :/ Please follow http://nouveau.freedesktop.org/wiki/Bugs and open new bug report. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon CS parser refactoring
[SNIP] On 05.01.2013 00:42, Alex Deucher wrote: R6xx and r7xx are really all you need to worry about in this case. R1xx-r5xx UMS uses a different kernel interface for command submission and evergreen and later don't have UMS drm support. UMS r6xx/r7xx support used the same kernel interface for command submission but the kernel side was much simpler. Additionally, UMS requires the old non-gallium 3D drivers. It sounds like some other change in the ddx broke UMS support for r6xx/r7xx. UMS support was dropped for xf86-video-ati 7.0.0, so we mostly want to try and avoid breaking things for users with ancient userspace stacks and a new kernel. That said, I'm not sure there are that many UMS users left. Alex Wouldn't it be a good idea to finally get ride of the old UMS stuff inside the kernel driver? Maybe making it a config option with default N as first step and then wait for a year or two and see if anybody starts complaining? Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54133] [radeon][RV620] Resuming from suspend/hibernation randomly fails since kernel 3.5.0
https://bugs.freedesktop.org/show_bug.cgi?id=54133 --- Comment #5 from aaa...@gmail.com --- Since upgrade to kernel 3.7.1 (from openSUSE Tumbleweed) I can no longer replicate this. For me this problem appears to be fixed. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #51 from Alexandre Demers --- Since the patch was submitted and applied on kernel 3.7, should this bug be closed? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 Serkan Hosca changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #52 from Serkan Hosca --- Yes this is fixed. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #24 from Alexandre Demers --- (In reply to comment #23) > (In reply to comment #22) > > "Is this a regression? Does it happen with older versions of mesa or > > kernel?" > > Yes. Previous kernel 3.7 doesn't show this problem. > > Can you bisect? Is it the same commit Thomas landed on or another one? Pretty sure it is the same problem. With kernel 3.8.0-rcx, just launching Gnome Shell starts flooding my logs of: radeon :0X:00.0: GPU fault detected: 146 0x00xx radeon :0X:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x radeon :0X:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x I'll bisect between 3.7 and 3.8-rc1 and see if I end up at the same thing. Having a crash here and there from time to time may be coming from something different, but the incessant flood is a big one. In a single session, I end up with kernel.log and everything.log being over 52GB each. I'm also sure this message have to be triggered is something wrong is going on. I'll let you know when I'm done bisecting to figure out what is triggering this flood. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #25 from Thomas Rohloff --- (In reply to comment #24) > I'll bisect between 3.7 and 3.8-rc1 and see if I end up at the same thing. Maybe you should just compile http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.8&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb (bad) and http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.8&id=9d89d78e3a20980205966fba6345645547e59ceb (good). It would be faster than bisecting and if you get another result than me you can still do a full bisect afterwards. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #26 from Alexandre Demers --- (In reply to comment #25) > (In reply to comment #24) > > I'll bisect between 3.7 and 3.8-rc1 and see if I end up at the same thing. > > Maybe you should just compile > http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3. > 8&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb (bad) and > http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3. > 8&id=9d89d78e3a20980205966fba6345645547e59ceb (good). It would be faster > than bisecting and if you get another result than me you can still do a full > bisect afterwards. That's what I'll do, it makes sense. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #27 from Alexandre Demers --- (In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > I'll bisect between 3.7 and 3.8-rc1 and see if I end up at the same thing. > > > > Maybe you should just compile > > http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3. > > 8&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb (bad) and > > http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3. > > 8&id=9d89d78e3a20980205966fba6345645547e59ceb (good). It would be faster > > than bisecting and if you get another result than me you can still do a full > > bisect afterwards. > > That's what I'll do, it makes sense. It seems both are bad: crashed on logon with 9d89d and both flooded my logs. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #28 from Alexandre Demers --- The flood is caused by: Commit: 4ac0533abaec2b83a7f2c675010eedd55664bc26 Author: Jerome Glisse 2012-12-13 12:08:11 Committer: Alex Deucher 2012-12-14 10:45:24 Parent: 9af20792124850369e764965690b99b20623dfc4 (drm/radeon: fix fence locking in the pageflip callback) Branch: remotes/origin/master Follows: v3.7-rc7 Precedes: v3.8-rc1 drm/radeon: fix htile buffer size computation for command stream checker Fix the size computation of the htile buffer. Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher However, I think this is not related to the lockups/crashes. So, the bug's description points actually to two different bugs: the flood and the crashes. Should I open a different bug for the flood of GPU fault detected? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 --- Comment #10 from Adam Jorgensen --- Okay, so I updated the 32-bit sabayon I use for performing chroot work stuff, installed Steam and then ran the application via the 32-bit chroot and the application works perfectly. I guess it is thus likely that the sabayon multilibs are currently running a bit behind. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/34c5f9c4/attachment.html>
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #45 from Alexandre Demers --- If I had a virtual machine, would it help debug? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/6445e20f/attachment.html>
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > On 2012.12.20 at 14:45 +0100, Markus Trippelsdorf wrote: > > On 2012.12.20 at 08:30 -0500, Alex Deucher wrote: > > > On Wed, Dec 19, 2012 at 9:33 AM, Markus Trippelsdorf > > > wrote: > > > > On 2012.12.19 at 15:18 +0100, Maarten Lankhorst wrote: > > > >> Fix regression introduced by 85b144f860176 > > > > > > > > (EE) [mi] EQ overflow continuing. 100 events have been dropped. > > > > (EE) > > > > (EE) Backtrace: > > > > (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x584f1d] > > > > (EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x44a792] > > > > (EE) 2: /usr/bin/X (xf86PostButtonEvent+0xd5) [0x4829b5] > > > > (EE) 3: /usr/lib64/xorg/modules/input/mouse_drv.so > > > > (0x7ff8f2501000+0x6b70) [0x7ff8f2507b70] > > > > (EE) 4: /usr/lib64/xorg/modules/input/mouse_drv.so > > > > (0x7ff8f2501000+0x73a0) [0x7ff8f25083a0] > > > > (EE) 5: /usr/lib64/xorg/modules/input/mouse_drv.so > > > > (0x7ff8f2501000+0x428c) [0x7ff8f250528c] > > > > (EE) 6: /usr/bin/X (0x40+0x71cd8) [0x471cd8] > > > > (EE) 7: /usr/bin/X (0x40+0x9a2ab) [0x49a2ab] > > > > (EE) 8: /lib/libpthread.so.0 (0x7ff8f1edc000+0xf260) [0x7ff8f1eeb260] > > > > (EE) 9: /lib/libc.so.6 (ioctl+0x7) [0x7ff8f19bd127] > > > > (EE) 10: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0x7ff8f246a634] > > > > (EE) 11: /usr/lib/libdrm.so.2 (drmCommandWriteRead+0x1f) > > > > [0x7ff8f246cbdf] > > > > (EE) 12: /usr/lib/libdrm_radeon.so.1 (0x7ff8f250e000+0x27bf) > > > > [0x7ff8f25107bf] > > > > (EE) 13: /usr/lib64/xorg/modules/drivers/radeon_drv.so > > > > (0x7ff8f154f000+0x407ec) [0x7ff8f158f7ec] > > > > (EE) 14: /usr/bin/X (_CallCallbacks+0x34) [0x438894] > > > > (EE) 15: /usr/bin/X (FlushAllOutput+0x2c) [0x5880ec] > > > > (EE) 16: /usr/bin/X (0x40+0x33aa1) [0x433aa1] > > > > (EE) 17: /usr/bin/X (0x40+0x230cd) [0x4230cd] > > > > (EE) 18: /lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff8f19088b5] > > > > (EE) 19: /usr/bin/X (0x40+0x22c09) [0x422c09] > > > > (EE) > > > > (EE) [mi] EQ overflow continuing. 200 events have been dropped. > > > > > > > > And the pictures get distorted on the test-webpage. See attached > > > > screenshot. > > > > > > > > > > Anything in your kernel log that corresponds to the errors in your xorg > > > log? > > > > No. But I've found out that the errors in the xorg log are unrelated to > > the image corruption. > > I use one of those Logitech mice with this "hyper" fast scrolling > > feature. And I guess the Xorg mouse driver just can't keep up with the > > fast input. So it's just a harmless warning that can be ignored, I > > guess. > > And just in case it got lost in the noise yesterday: > The image corruption is caused by Dave's commit: > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > Author: Dave Airlie > Date: Fri Dec 14 21:04:46 2012 +1000 > > radeon: fix regression with eviction since evict caching changes > > Reverting it 'fixes' the issue. Ping. The issue still happens with todays Linus git tree. Can you please have a look at this Dave? Thanks. -- Markus
3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
Hi,
I am getting this during hibernate/resume with current Linus' head
(5f738967e89584f99c6a11c6bf09b16c50b6a03e).
==
[ INFO: possible circular locking dependency detected ]
3.8.0-rc2-00038-ge93d369 #178 Not tainted
---
s2disk/3024 is trying to acquire lock:
((fb_notifier_list).rwsem){.+}, at: []
__blocking_notifier_call_chain+0x5a/0xd0
but task is already holding lock:
(console_lock){+.+.+.}, at: [] do_fb_ioctl+0x455/0x590
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] lock_acquire+0x121/0x190
[] console_lock+0x6f/0x80
[] register_con_driver+0x5d/0x160
[] take_over_console+0x2d/0x70
[] fbcon_takeover+0x63/0xc0
[] fbcon_fb_registered+0xc5/0x170
[] fbcon_event_notify+0x1d8/0x690
[] notifier_call_chain+0x93/0x140
[] __blocking_notifier_call_chain+0x71/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] do_register_framebuffer+0x221/0x2e0
[] register_framebuffer+0x22/0x40
[] drm_fb_helper_single_fb_probe+0x2bc/0x300
[drm_kms_helper]
[] drm_fb_helper_initial_config+0x92/0xd0
[drm_kms_helper]
[] intel_fbdev_init+0x8b/0xc0 [i915]
[] i915_load_modeset_init+0x113/0x1d0 [i915]
[] i915_driver_load+0x5e5/0x940 [i915]
[] drm_get_pci_dev+0x196/0x2a0 [drm]
[] i915_pci_probe+0x3d/0x90 [i915]
[] local_pci_probe+0x49/0x80
[] __pci_device_probe+0xd9/0xe0
[] pci_device_probe+0x36/0x60
[] really_probe+0x79/0x350
[] driver_probe_device+0x54/0xa0
[] __driver_attach+0x9b/0xa0
[] bus_for_each_dev+0x68/0x90
[] driver_attach+0x1c/0x20
[] bus_add_driver+0x1d8/0x290
[] driver_register+0x63/0x150
[] __pci_register_driver+0x62/0x70
[] drm_pci_init+0x10c/0x120 [drm]
[] tpm_bios_measurements_start+0x5d/0xa0 [tpm_bios]
[] do_one_initcall+0x3d/0x180
[] do_init_module+0x6b/0x1d0
[] load_module+0x6fe/0x7e0
[] sys_init_module+0x9b/0xc0
[] system_call_fastpath+0x16/0x1b
-> #0 ((fb_notifier_list).rwsem){.+}:
[] check_prev_add+0x3de/0x440
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] lock_acquire+0x121/0x190
[] down_read+0x42/0x60
[] __blocking_notifier_call_chain+0x5a/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_var+0x232/0x3e0
[] do_fb_ioctl+0x468/0x590
[] fb_ioctl+0x3d/0x50
[] do_vfs_ioctl+0x9d/0x350
[] sys_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
*** DEADLOCK ***
2 locks held by s2disk/3024:
#0: (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x22/0x50
#1: (console_lock){+.+.+.}, at: [] do_fb_ioctl+0x455/0x590
stack backtrace:
Pid: 3024, comm: s2disk Not tainted 3.8.0-rc2-00038-ge93d369 #178
Call Trace:
[] print_circular_bug+0x10f/0x120
[] check_prev_add+0x3de/0x440
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] ? trace_hardirqs_on+0xd/0x10
[] lock_acquire+0x121/0x190
[] ? __blocking_notifier_call_chain+0x5a/0xd0
[] down_read+0x42/0x60
[] ? __blocking_notifier_call_chain+0x5a/0xd0
[] __blocking_notifier_call_chain+0x5a/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_var+0x232/0x3e0
[] ? do_fb_ioctl+0x455/0x590
[] ? trace_hardirqs_on+0xd/0x10
[] do_fb_ioctl+0x468/0x590
[] ? __lock_acquire+0x359/0x580
[] ? fget_light+0xbc/0x480
[] fb_ioctl+0x3d/0x50
[] do_vfs_ioctl+0x9d/0x350
[] ? fget_light+0x37/0x480
[] sys_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
--
Jiri Kosina
SUSE Labs
[Bug 59015] Steam Beta: Graphical Corruption in certain parts of application tied to "kernel rejected CS" messages
https://bugs.freedesktop.org/show_bug.cgi?id=59015 runetmember at gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from runetmember at gmail.com --- INVALID then? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/deec0680/attachment.html>
Resume regression with nouveau 3.8rc1 (bisected)
On Sat, Jan 05, 2013 at 10:10:06AM +0100, Pontus Fuchs wrote: > On 01/03/2013 08:12 PM, Marcin Slusarz wrote: > > On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote: > >> I bisected the problem down to this commit: > >> > >> 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > >> > >> Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. > >> There's already open bug report for that: > >> https://bugs.freedesktop.org/show_bug.cgi?id=58729 > > Yay, a bug fix was just posted there ;). > > Hi, I tried that patch but it didn't help :( > > I see this in my kernel log after resume: > > nouveau E[ PFB][:01:00.0] trapped read at 0x002001a020 on > channel 0x7b23 SEMAPHORE_BG/PFIFO_READ/00 reason: PAGE_NOT_PRESENT > nouveau E[1177] failed to idle channel 0x > [TTM] Failed to expire sync object before buffer eviction > [TTM] Failed to expire sync object before buffer eviction > [TTM] Failed to expire sync object before buffer eviction Sigh, this seems to be another issue :/ Please follow http://nouveau.freedesktop.org/wiki/Bugs and open new bug report. Marcin
radeon CS parser refactoring
[SNIP] On 05.01.2013 00:42, Alex Deucher wrote: > R6xx and r7xx are really all you need to worry about in this case. > R1xx-r5xx UMS uses a different kernel interface for command submission > and evergreen and later don't have UMS drm support. UMS r6xx/r7xx > support used the same kernel interface for command submission but the > kernel side was much simpler. Additionally, UMS requires the old > non-gallium 3D drivers. It sounds like some other change in the ddx > broke UMS support for r6xx/r7xx. UMS support was dropped for > xf86-video-ati 7.0.0, so we mostly want to try and avoid breaking > things for users with ancient userspace stacks and a new kernel. That > said, I'm not sure there are that many UMS users left. > > Alex Wouldn't it be a good idea to finally get ride of the old UMS stuff inside the kernel driver? Maybe making it a config option with default N as first step and then wait for a year or two and see if anybody starts complaining? Christian.
[Bug 54133] [radeon][RV620] Resuming from suspend/hibernation randomly fails since kernel 3.5.0
https://bugs.freedesktop.org/show_bug.cgi?id=54133 --- Comment #5 from aaannz at gmail.com --- Since upgrade to kernel 3.7.1 (from openSUSE Tumbleweed) I can no longer replicate this. For me this problem appears to be fixed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/4496c45a/attachment.html>
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 --- Comment #51 from Alexandre Demers --- Since the patch was submitted and applied on kernel 3.7, should this bug be closed? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/e1c808ab/attachment.html>
[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)
https://bugs.freedesktop.org/show_bug.cgi?id=55692 Serkan Hosca changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #52 from Serkan Hosca --- Yes this is fixed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/56a25eca/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #24 from Alexandre Demers --- (In reply to comment #23) > (In reply to comment #22) > > "Is this a regression? Does it happen with older versions of mesa or > > kernel?" > > Yes. Previous kernel 3.7 doesn't show this problem. > > Can you bisect? Is it the same commit Thomas landed on or another one? Pretty sure it is the same problem. With kernel 3.8.0-rcx, just launching Gnome Shell starts flooding my logs of: radeon :0X:00.0: GPU fault detected: 146 0x00xx radeon :0X:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x radeon :0X:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x I'll bisect between 3.7 and 3.8-rc1 and see if I end up at the same thing. Having a crash here and there from time to time may be coming from something different, but the incessant flood is a big one. In a single session, I end up with kernel.log and everything.log being over 52GB each. I'm also sure this message have to be triggered is something wrong is going on. I'll let you know when I'm done bisecting to figure out what is triggering this flood. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/23a57416/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #25 from Thomas Rohloff --- (In reply to comment #24) > I'll bisect between 3.7 and 3.8-rc1 and see if I end up at the same thing. Maybe you should just compile http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.8&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb (bad) and http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.8&id=9d89d78e3a20980205966fba6345645547e59ceb (good). It would be faster than bisecting and if you get another result than me you can still do a full bisect afterwards. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/5679396a/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #26 from Alexandre Demers --- (In reply to comment #25) > (In reply to comment #24) > > I'll bisect between 3.7 and 3.8-rc1 and see if I end up at the same thing. > > Maybe you should just compile > http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3. > 8&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb (bad) and > http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3. > 8&id=9d89d78e3a20980205966fba6345645547e59ceb (good). It would be faster > than bisecting and if you get another result than me you can still do a full > bisect afterwards. That's what I'll do, it makes sense. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130105/72e22be0/attachment.html>
Resume regression with nouveau 3.8rc1 (bisected)
On 01/03/2013 08:12 PM, Marcin Slusarz wrote: > On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote: >> I bisected the problem down to this commit: >> >> 186ecad21: drm/nv50/disp: move remaining interrupt handling into core >> >> Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. >> There's already open bug report for that: >> https://bugs.freedesktop.org/show_bug.cgi?id=58729 > Yay, a bug fix was just posted there ;). Hi, I tried that patch but it didn't help :( I see this in my kernel log after resume: nouveau E[ PFB][:01:00.0] trapped read at 0x002001a020 on channel 0x7b23 SEMAPHORE_BG/PFIFO_READ/00 reason: PAGE_NOT_PRESENT nouveau E[1177] failed to idle channel 0x [TTM] Failed to expire sync object before buffer eviction [TTM] Failed to expire sync object before buffer eviction [TTM] Failed to expire sync object before buffer eviction //Pontus
3.8-rc1: nouveau: X window session not starting
Not sure if it is a kernel issue or user-space. Truth is probably somewhere in the middle. It popped up moving to 3.8-rc1 using nouveau. Using nvidia's driver works fine. With nouveau, after entering login credentials in lightDM the user session does not start and I am back at the lightDM login screen. This is shown in the syslog: Jan 5 11:28:34 linux-e6410-1 rtkit-daemon[1888]: Successfully made thread 4920 of process 4920 (n/a) owned by '110' high priority at nice level -11. Jan 5 11:28:34 linux-e6410-1 rtkit-daemon[1888]: Supervising 9 threads of 3 processes of 2 users. Jan 5 11:28:34 linux-e6410-1 pulseaudio[4920]: [pulseaudio] pid.c: Daemon already running. Jan 5 11:28:53 linux-e6410-1 pulseaudio[2767]: [pulseaudio] x11wrap.c: XOpenDisplay() failed Jan 5 11:28:53 linux-e6410-1 pulseaudio[2767]: [pulseaudio] module.c: Failed to load module "module-x11-publish" (argument: "display=:0"): initialization failed. Jan 5 11:28:54 linux-e6410-1 kernel: [ 2454.499025] nouveau E[4780] failed to idle channel 0x I can start sessions for Xfce and 'Gnome Classic (without Effects)' so I suspect compiz to fail. Did not try xcompmgr. Gr. AvS
Bisected regression on RV610
Hello, Alex! Sorry for delay with the reply! It turns out I made a huge blunder while bisecting. I assumed that the radeon drivers would load from lib/modules, so I didn't bother running "make install" once I saw that only the modules are recompiled. In fact, the video modules were loaded from initrd (unlike, say, WiFi drivers I'm used to deal with), so skipping "make install" would leave me with the drivers from the previous iteration. The commit that introduces the problem is actually 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 drm/radeon: use async dma for ttm buffer moves on 6xx-SI I could fix it simply by reverting the first chunk, that is, the part modifying r600_asic. I tried the current mainline kernel 3.8.0-rc2+ (commit 5f243b9b46a22e5790dbbc36f574c2417af49a41) and it doesn't have the problem! However, the chunk of the "bad" patch can still be reverted with no conflicts. So I assume the problem was fixed in another place. If you want, I can make another bisect to find the commit that fixed the problem. But if you have an idea what it was, then that it :) Just a reminder, the problem is a hang when running unshield on some proprietary Windows drivers in xterm on Fedora 17 x86_64 with Radeon RV610. -- Regards, Pavel Roskin
