[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #3 from Alex Deucher 2012-01-21 06:48:47 PST --- Please attach your xorg log and dmesg output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #4 from Alexandre Demers 2012-01-21 07:06:26 PST --- Created attachment 55912 --> https://bugs.freedesktop.org/attachment.cgi?id=55912 dmesg with bad rendering after running the app -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #5 from Alexandre Demers 2012-01-21 07:06:59 PST --- Created attachment 55913 --> https://bugs.freedesktop.org/attachment.cgi?id=55913 xorg.log with bad rendering -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #6 from Alexandre Demers 2012-01-21 07:07:31 PST --- Should I add the logs from the good rendering? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=44772 --- Comment #1 from Harald Judt 2012-01-21 07:42:30 PST --- Still reproducible in 3.3-rc1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #17 from Florian Mickler 2012-01-21 08:44:59 PST --- A patch referencing this bug report has been merged in Linux v3.2-rc1: commit 77b1bad423599c9841ea282a82172f039bb2ff92 Author: Jerome Glisse Date: Wed Oct 26 11:41:22 2011 -0400 drm/radeon: flush read cache for gtt with fence on r6xx and newer GPU V3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board
https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #10 from Florian Mickler 2012-01-21 08:46:25 PST --- A patch referencing this bug report has been merged in Linux v3.2-rc1: commit 5f0a26128d66ef81613fe923d5c288942844ccdc Author: Alex Deucher Date: Fri Oct 7 14:23:47 2011 -0400 drm/radeon/kms: bail early in dvi_detect for digital only connectors -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'
https://bugs.freedesktop.org/show_bug.cgi?id=43941 --- Comment #15 from Florian Mickler 2012-01-21 08:46:56 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc1: commit cc1f71942944890c7e05fc55dc4427c94b63d4f1 Author: Dave Airlie Date: Thu Jan 5 09:55:22 2012 + drm: introduce drm_can_sleep and use in intel/radeon drivers. (v2) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #19 from Florian Mickler 2012-01-21 08:53:40 PST --- A patch referencing this bug report has been merged in Linux v3.2-rc1: commit cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd Author: Alex Deucher Date: Fri Oct 28 16:07:36 2011 -0400 drm/radeon/kms: fix DP setup on TRAVIS bridges -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #5 from Florian Mickler 2012-01-21 08:54:10 PST --- A patch referencing this bug report has been merged in Linux v3.2-rc6: commit cd5cfce856684e13b9b57d46b78bb827e9c4da3c Author: Alex Deucher Date: Mon Dec 12 09:23:48 2011 -0500 drm/radeon/kms: add some new pci ids -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Add dma-buf sharing framework maintainer
On Jan 20, 2012 4:33 PM, "Dave Airlie" wrote: > > On Thu, Jan 19, 2012 at 10:39 AM, Daniel Vetter wrote: > > On Thu, Jan 19, 2012 at 03:04:25PM +0530, Sumit Semwal wrote: > >> Adding maintainer info for dma-buf buffer sharing framework; > >> some mailing lists interested in this work are also added. > >> > >> Signed-off-by: Sumit Semwal > >> Signed-off-by: Sumit Semwal > >> Acked-by: Arnd Bergmann > > > > Acked-by: Daniel Vetter > > Acked-by: Dave Airlie > > Should just send to Linus with these acks in it. Thanks Daniel and Dave! Dave, Would it be OK for you to queue it through your for-linus, or just the patch to Linus will be enough ? > > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon issues on MacBook Pro 8,2
On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote: > > > 2. Occasional long delays when suspending. When this happens I see > > > messages like following in dmesg: > > > > > > [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than > > > 5secs aborting > > > [drm:atom_execute_table_locked] *ERROR* atombios stuck executing > > > D44E (len 62, WS 0, PS 0) @ 0xD46A > > > > > > Sometimes one of suspend or resume hangs completely, but I can't > > > tell which and am not sure whether or not it's related. I'm also > > > testing a Mac Mini with the exact same card which does not seem to > > > suffer from this issue. > > > > > > I ran a bisections that identified f8d0edd (drm/radeon/kms: improve > > > DP detect logic) as introducing problems with suspend, and reverting > > > this patch on top of 3.2.1 does seem to eliminate both issues. > > > > > > > That patch doesn't really affect the modesetting paths directly; it > > looks like a red herring to me. > > Perhaps. I just started a run of 200 s3 cycles with the patch reverted > to see if I can reproduce the issues. I can usually trigger the problem > with 15 or fewer s3 cycles. The machine completed 200 s3 cycles with the patch reverted without long delays, hangs, or any atombios error messages. Without reverting it doesn't get through many at all before experiencing the errors and long delays or hangs. I added a printout of the connector status resulting from the logic that was changed by f8d0edd. With the logic prior to this commit it consistently returns the status as disconnected, which is correct as I have nothing connected. But with the improved logic the status is sometimes reported as connected, and these coincide with the atombios errors. Seth ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote: > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation > > issue, and not really an interface". The dma-buf infrastructure is > > explicitly intended as an interface between modules/drivers, so it > > should use EXPORT_SYMBOL instead. > > + Konrad, Arnd, Mauro: there were strong objections on using > EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I > suggest we first arrive at a consensus before merging this patch. This discussion seems to have stagnated; how do we move forward here? Sumit, as the primary author and new maintainer (congrats!) of the dma-buf infrastructure, it seems like it's really your call how to proceed. I'd still like to see this be something that we can use from the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have argued in this thread. It really seems to me that this change on a technical level won't have any adverse effect on the scenarios where it can be used today, but it will allow it to be used more widely, which will prevent duplication and fragmentation in the future and be greatly appreciated by users of hardware such as Optimus. Let me know if you have any questions. Thanks, Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: remove master fd restriction on mode setting getters
Its useful to be able to call the mode setting getter ioctls.
Not requiring master fd, enables writing a simple program which
can query the state of the video system.
Since these ioctls are only "getters" there is no security or
synchronization issues which would require master fd. Opening
an new fd is already protected by the file permissions on the
device file.
Signed-off-by: Mandeep Singh Baines
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Ilija Hadzic
Cc: Jesse Barnes
Cc: Stephane Marchesin
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index ebf7d3f..d166bd0 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -135,23 +135,23 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl,
DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANE, drm_mode_getplane,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPLANE, drm_mode_setplane,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR, drm_mode_cursor_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl,
DRM_MASTER|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETGAMMA, drm_mode_gamma_set_ioctl,
DRM_MASTER|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_mode_attachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_mode_detachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl,
DRM_MASTER | DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY,
drm_mode_connector_property_set_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon issues on MacBook Pro 8,2
On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote: > On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee > wrote: > > On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote: > >> > > 2. Occasional long delays when suspending. When this happens I see > >> > > messages like following in dmesg: > >> > > > >> > > [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than > >> > > 5secs aborting > >> > > [drm:atom_execute_table_locked] *ERROR* atombios stuck executing > >> > > D44E (len 62, WS 0, PS 0) @ 0xD46A > >> > > > >> > > Sometimes one of suspend or resume hangs completely, but I can't > >> > > tell which and am not sure whether or not it's related. I'm also > >> > > testing a Mac Mini with the exact same card which does not seem to > >> > > suffer from this issue. > >> > > > >> > > I ran a bisections that identified f8d0edd (drm/radeon/kms: improve > >> > > DP detect logic) as introducing problems with suspend, and reverting > >> > > this patch on top of 3.2.1 does seem to eliminate both issues. > >> > > > >> > > >> > That patch doesn't really affect the modesetting paths directly; it > >> > looks like a red herring to me. > >> > >> Perhaps. I just started a run of 200 s3 cycles with the patch reverted > >> to see if I can reproduce the issues. I can usually trigger the problem > >> with 15 or fewer s3 cycles. > > > > The machine completed 200 s3 cycles with the patch reverted without long > > delays, hangs, or any atombios error messages. Without reverting it > > doesn't get through many at all before experiencing the errors and long > > delays or hangs. > > > > I added a printout of the connector status resulting from the logic that > > was changed by f8d0edd. With the logic prior to this commit it > > consistently returns the status as disconnected, which is correct as I > > have nothing connected. But with the improved logic the status is > > sometimes reported as connected, and these coincide with the atombios > > errors. > > > > Do any of the disconnected displayport connectors get misdetected as > connected during normal operation or does it only happen during > suspend/resume? So far I've only seen them during suspend/resume. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon issues on MacBook Pro 8,2
On Fri, Jan 20, 2012 at 04:39:31PM -0500, Alex Deucher wrote: > On Fri, Jan 20, 2012 at 4:12 PM, Seth Forshee > wrote: > > On Fri, Jan 20, 2012 at 02:38:37PM -0500, Alex Deucher wrote: > >> On Fri, Jan 20, 2012 at 10:53 AM, Seth Forshee > >> wrote: > >> > On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote: > >> >> > > 2. Occasional long delays when suspending. When this happens I see > >> >> > > messages like following in dmesg: > >> >> > > > >> >> > > [drm:atom_op_jump] *ERROR* atombios stuck in loop for more > >> >> > > than 5secs aborting > >> >> > > [drm:atom_execute_table_locked] *ERROR* atombios stuck > >> >> > > executing D44E (len 62, WS 0, PS 0) @ 0xD46A > >> >> > > > >> >> > > Sometimes one of suspend or resume hangs completely, but I can't > >> >> > > tell which and am not sure whether or not it's related. I'm also > >> >> > > testing a Mac Mini with the exact same card which does not seem > >> >> > > to > >> >> > > suffer from this issue. > >> >> > > > >> >> > > I ran a bisections that identified f8d0edd (drm/radeon/kms: > >> >> > > improve > >> >> > > DP detect logic) as introducing problems with suspend, and > >> >> > > reverting > >> >> > > this patch on top of 3.2.1 does seem to eliminate both issues. > >> >> > > > >> >> > > >> >> > That patch doesn't really affect the modesetting paths directly; it > >> >> > looks like a red herring to me. > >> >> > >> >> Perhaps. I just started a run of 200 s3 cycles with the patch reverted > >> >> to see if I can reproduce the issues. I can usually trigger the problem > >> >> with 15 or fewer s3 cycles. > >> > > >> > The machine completed 200 s3 cycles with the patch reverted without long > >> > delays, hangs, or any atombios error messages. Without reverting it > >> > doesn't get through many at all before experiencing the errors and long > >> > delays or hangs. > >> > > >> > I added a printout of the connector status resulting from the logic that > >> > was changed by f8d0edd. With the logic prior to this commit it > >> > consistently returns the status as disconnected, which is correct as I > >> > have nothing connected. But with the improved logic the status is > >> > sometimes reported as connected, and these coincide with the atombios > >> > errors. > >> > > >> > >> Do any of the disconnected displayport connectors get misdetected as > >> connected during normal operation or does it only happen during > >> suspend/resume? > > > > So far I've only seen them during suspend/resume. > > Can you track down who is calling the connector->detect() callbacks > during suspend and resume? I got two different stack traces, see below. And to slightly amend my statement above, I'm only seeing the wrong status returned on the suspend side of things. The status during resume always seems to be correct. Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu Call Trace: [] radeon_dp_detect+0x1de/0x230 [radeon] [] output_poll_execute+0xbd/0x1a0 [drm_kms_helper] [] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper] [] process_one_work+0x11a/0x480 [] worker_thread+0x164/0x370 [] ? manage_workers.isra.30+0x130/0x130 [] kthread+0x8c/0xa0 [] kernel_thread_helper+0x4/0x10 [] ? flush_kthread_worker+0xa0/0xa0 [] ? gs_change+0x13/0x13 Pid: 49, comm: kworker/0:2 Tainted: G C O 3.2.0-10-generic #17-Ubuntu Call Trace: [] radeon_dp_detect+0x1de/0x230 [radeon] [] drm_helper_probe_single_connector_modes+0x2c3/0x380 [drm_kms_helper] [] drm_fb_helper_hotplug_event+0xf2/0x150 [drm_kms_helper] [] radeon_fb_output_poll_changed+0x15/0x20 [radeon] [] radeon_output_poll_changed+0x15/0x20 [radeon] [] output_poll_execute+0x190/0x1a0 [drm_kms_helper] [] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper] [] process_one_work+0x11a/0x480 [] worker_thread+0x164/0x370 [] ? manage_workers.isra.30+0x130/0x130 [] kthread+0x8c/0xa0 [] kernel_thread_helper+0x4/0x10 [] ? flush_kthread_worker+0xa0/0xa0 [] ? gs_change+0x13/0x13 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon issues on MacBook Pro 8,2
On Fri, Jan 20, 2012 at 11:09:29PM +0200, Pasi Kärkkäinen wrote: > On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote: > > On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote: > > > On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee > > > wrote: > > > > I'm seeing several issues related to the radeon driver on a MacBook Pro > > > > 8,2 with the following graphics card: > > > > > > > > ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741] > > > > > > > > All problems were observed when using kernel version 3.2.1. None are > > > > seen when using fglrx. > > > > > > > > 1. Excessive power draw. When using the radeon driver ACPI reports a > > > > power draw of about 30W on an idle desktop. Using fglrx brings this > > > > number down to 15W. > > > > > > The power saving features of the open source driver are not yet as > > > good as the closed source driver. Please see the power management > > > section of this page (http://wiki.x.org/wiki/RadeonFeature) for more > > > info on the options currently available. > > > > The dynpm option makes a small difference, saving about 2W. I did notice > > an ocassional flash on the screen with this option, and the same flash > > each time I changed the power options. > > > > Btw how do you measure the power draw? You can get the instantaneous rate from the data under /proc/acpi/battery, but I use a tool called powerstat [1], written by my colleague Colin King. The advantage of powerstat is that it samples the ACPI data over a period of time and reports the average and standard deviation. That way I have a better idea of how much power is really being drawn and the quality of the value reported. [1] http://kernel.ubuntu.com/git?p=cking/powerstat.git ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote: > On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: > > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote: > > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation > > > issue, and not really an interface". The dma-buf infrastructure is > > > explicitly intended as an interface between modules/drivers, so it > > > should use EXPORT_SYMBOL instead. > > > > + Konrad, Arnd, Mauro: there were strong objections on using > > EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I > > suggest we first arrive at a consensus before merging this patch. > > This discussion seems to have stagnated; how do we move forward here? > > Sumit, as the primary author and new maintainer (congrats!) of the > dma-buf infrastructure, it seems like it's really your call how to > proceed. I'd still like to see this be something that we can use from > the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have > argued in this thread. It really seems to me that this change on a > technical level won't have any adverse effect on the scenarios where it > can be used today, but it will allow it to be used more widely, which > will prevent duplication and fragmentation in the future and be greatly > appreciated by users of hardware such as Optimus. Given that I've participated quite a bit in the design of dma_buf as-is, let me throw in my totally irrelevant opinion, too ;-) I'll refrain from comment on the actual patch, it's obviously a hot topic. Furthermore I might need to ask Intel's legal dep for guidance to asses things wrt my own contributions to dma_buf. Otoh I'd like nvidia to be on board, especially when we're desingned additions to dma_buf required to make it really work for multiple gpus. In additions it looks like that the nvidia blob will only be an importer of a dma_buf, at least for the use-cases discussed here. So why don't you just ditch this patch here and add a small shim to your blob to interface with drm's prime as an importing driver? I personally would deem that acceptable and I think Dave wouldn't mind too much, either. Yours, Daniel Disclaimer: This is my own opinion and I do not speak as an Intel employee here. -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec
After updating to kernel 3.3-rc1 I have experienced a lockup of my GPU. I left my KDE desktop running until the screensaver turned off the monitors. But on key presses it would not turn back on. Ctrl+Alt+F1 to switch to another virtual console also did not work. Alt+SysRq magic still worked, so I was able to force the syslog to disk and restart the system. >From the log: Jan 21 19:30:01 thoregon cron[3960]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons) Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0: GPU lockup CP stall for more than 1msec Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting for 0x0003F1F2 last fence id 0x0003F1F1) Jan 21 19:39:41 thoregon kernel: [ 6364.636341] radeon :07:00.0: GPU softreset Jan 21 19:39:41 thoregon kernel: [ 6364.636348] radeon :07:00.0: R_008010_GRBM_STATUS=0xA0003028 Jan 21 19:39:41 thoregon kernel: [ 6364.636354] radeon :07:00.0: R_008014_GRBM_STATUS2=0x0002 Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0: GPU lockup CP stall for more than 1msec Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting for 0x0003F1F2 last fence id 0x0003F1F1) Jan 21 19:39:41 thoregon kernel: [ 6364.636341] radeon :07:00.0: GPU softreset Jan 21 19:39:41 thoregon kernel: [ 6364.636348] radeon :07:00.0: R_008010_GRBM_STATUS=0xA0003028 Jan 21 19:39:41 thoregon kernel: [ 6364.636354] radeon :07:00.0: R_008014_GRBM_STATUS2=0x0002 Jan 21 19:39:41 thoregon kernel: [ 6364.636359] radeon :07:00.0: R_000E50_SRBM_STATUS=0x20C0 Jan 21 19:39:41 thoregon kernel: [ 6364.636370] radeon :07:00.0: R_008020_GRBM_SOFT_RESET=0x7FEE Jan 21 19:39:41 thoregon kernel: [ 6364.651219] radeon :07:00.0: R_008020_GRBM_SOFT_RESET=0x0001 Jan 21 19:39:41 thoregon kernel: [ 6364.667212] radeon :07:00.0: R_008010_GRBM_STATUS=0x3028 Jan 21 19:39:41 thoregon kernel: [ 6364.667217] radeon :07:00.0: R_008014_GRBM_STATUS2=0x0002 Jan 21 19:39:41 thoregon kernel: [ 6364.667223] radeon :07:00.0: R_000E50_SRBM_STATUS=0x20C0 Jan 21 19:39:41 thoregon kernel: [ 6364.668226] radeon :07:00.0: GPU reset succeed Jan 21 19:39:41 thoregon kernel: [ 6364.673142] [drm] PCIE GART of 512M enabled (table at 0x0004). Jan 21 19:39:41 thoregon kernel: [ 6364.673177] radeon :07:00.0: WB enabled Jan 21 19:39:41 thoregon kernel: [ 6364.673184] [drm] fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x880328636c00 Jan 21 19:39:41 thoregon kernel: [ 6364.719445] [drm] ring test on 0 succeeded in 1 usecs Jan 21 19:40:01 thoregon cron[3975]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons) Jan 21 19:43:37 thoregon kernel: [ 6600.390150] INFO: task X:3098 blocked for more than 120 seconds. Jan 21 19:43:37 thoregon kernel: [ 6600.390157] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 21 19:43:37 thoregon kernel: [ 6600.390163] X D 880337d50a00 0 3098 3077 0x0040 Jan 21 19:43:37 thoregon kernel: [ 6600.390174] 88031df15080 0086 8802f5087300 00010a00 Jan 21 19:43:37 thoregon kernel: [ 6600.390185] 88031bf79fd8 00010a00 88031bf78000 88031bf79fd8 Jan 21 19:43:37 thoregon kernel: [ 6600.390194] 00010a00 88031df15080 00010a00 00010a00 Jan 21 19:43:37 thoregon kernel: [ 6600.390203] Call Trace: Jan 21 19:43:37 thoregon kernel: [ 6600.390219] [] ? __mutex_lock_slowpath+0xc8/0x140 Jan 21 19:43:37 thoregon kernel: [ 6600.390230] [] ? mutex_lock+0x1a/0x40 Jan 21 19:43:37 thoregon kernel: [ 6600.390239] [] ? radeon_ib_get+0x52/0x230 Jan 21 19:43:37 thoregon kernel: [ 6600.390249] [] ? r600_ib_test+0x5a/0x300 Jan 21 19:43:37 thoregon kernel: [ 6600.390258] [] ? rv770_startup+0xf7e/0x1590 Jan 21 19:43:37 thoregon kernel: [ 6600.390267] [] ? rv770_resume+0x2c/0x90 Jan 21 19:43:37 thoregon kernel: [ 6600.390275] [] ? radeon_gpu_reset+0x11e/0x160 Jan 21 19:43:37 thoregon kernel: [ 6600.390284] [] ? radeon_fence_wait+0x363/0x3b0 Jan 21 19:43:37 thoregon kernel: [ 6600.390293] [] ? wake_up_bit+0x40/0x40 Jan 21 19:43:37 thoregon kernel: [ 6600.390301] [] ? radeon_ib_get+0x1e7/0x230 Jan 21 19:43:37 thoregon kernel: [ 6600.390310] [] ? radeon_cs_ioctl+0x27a/0x4d0 Jan 21 19:43:37 thoregon kernel: [ 6600.390319] [] ? drm_ioctl+0x3e4/0x490 Jan 21 19:43:37 thoregon kernel: [ 6600.390327] [] ? radeon_cs_finish_pages+0xa0/0xa0 Jan 21 19:43:37 thoregon kernel: [ 6600.390336] [] ? do_page_fault+0x199/0x420 Jan 21 19:43:37 thoregon kernel: [ 6600.390344] [] ? mmap_region+0x1dc/0x570 Jan 21 19:43:37 thoregon kernel: [ 6600.390352] [] ? do_vfs_ioctl+0x96/0x4e0 Jan 21 19:43:37 thoregon kernel: [ 6600.390359] [] ? __schedule+0x28c/0x630 Jan 21 19:43:37 thoregon kernel: [ 6600.390366] [] ? sys_ioctl+0x49/0x90 Jan 21 19:43:37 thoregon kernel: [ 6600.390375] [] ? system_call_fastpath+0x16/0x1b Jan 21 19:45:08 thoregon k
Re: [BUG] Intel HD Graphic QM57 chipset: Dell U3011 monitor turns to power saving mode
On Sat, 21 Jan 2012 13:56:21 -0500, Mathieu Desnoyers wrote: > Dell U3011 monitor turns to power saving mode when resolution set to 2560 x > 1600 > (intermittent) > > Reproduced with: > Linux 2.6.38-1-amd64 (Debian kernel) > Linux 3.1.0-1-amd64 (Debian kernel) > Linux 3.2.0-1-amd64 (Debian kernel) > > The computer is a Lenovo X201 Tablet (Intel QM57 chipset), on a X200 > docking station. The docking station uses a DisplayPort cable to connect > to the monitor. I tried upgrading my Bios from 1.34/1.13 to 1.38/1.14 > (latest), which did not fix the problem. I cannot use anything else > than DisplayPort in this case to connect the monitor at 2560 x 1600, > because this resolution requires either the bandwidth provided by a > dual-link DVI (which I cannot connect in my docking station), or > DisplayPort. I use this same monitor, and have run it with an X200 in the past. Can you capture a dmesg output with the kernel parameter drm.debug=0xe set? That will let us see the DP link training adventure and see what's broken. If you can, separate traces of working and non-working tries would be nice. And, of course, trying 3.3-rc1 would be helpful as that's what any test patches would be developed on top of. -- keith.pack...@intel.com pgpJ1EOiTgkEB.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board
https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #11 from Florian Mickler 2012-01-21 13:23:51 PST --- A patch referencing a commit referencing this bug report has been merged in Linux v3.2-rc1: commit 340764465aa4a586ca332e61ae64883e5ad6f183 Author: Jerome Glisse Date: Mon Oct 24 18:16:34 2011 -0400 drm/radeon: avoid bouncing connector status btw disconnected & unknown -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] New: [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Bug #: 45018 Summary: [bisected] rendering regression since added support for virtual address space on cayman v11 Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: alexandre.f.demers at gmail.com Created attachment 55888 --> https://bugs.freedesktop.org/attachment.cgi?id=55888 Good rendering When testing RenderFeatTest.bin64, the shadows on test07 are not rendered correctly anymore. Bisecting identified the following commit as culprit: bb1f0cf3508630a9a93512c79badf8c493c46743 is the first bad commit commit bb1f0cf3508630a9a93512c79badf8c493c46743 Author: Jerome Glisse Date: Fri Dec 2 10:20:29 2011 -0500 r600g: add support for virtual address space on cayman v11 I'll be attaching pictures to show the regression. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #2 from Alexandre Demers 2012-01-20 22:04:48 PST --- Created attachment 55889 --> https://bugs.freedesktop.org/attachment.cgi?id=55889 Bad rendering Projected shadows are not rendered correctly anymore. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #3 from Alex Deucher 2012-01-21 06:48:47 PST --- Please attach your xorg log and dmesg output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #4 from Alexandre Demers 2012-01-21 07:06:26 PST --- Created attachment 55912 --> https://bugs.freedesktop.org/attachment.cgi?id=55912 dmesg with bad rendering after running the app -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #5 from Alexandre Demers 2012-01-21 07:06:59 PST --- Created attachment 55913 --> https://bugs.freedesktop.org/attachment.cgi?id=55913 xorg.log with bad rendering -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #6 from Alexandre Demers 2012-01-21 07:07:31 PST --- Should I add the logs from the good rendering? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=44772 --- Comment #1 from Harald Judt 2012-01-21 07:42:30 PST --- Still reproducible in 3.3-rc1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #17 from Florian Mickler 2012-01-21 08:44:59 PST --- A patch referencing this bug report has been merged in Linux v3.2-rc1: commit 77b1bad423599c9841ea282a82172f039bb2ff92 Author: Jerome Glisse Date: Wed Oct 26 11:41:22 2011 -0400 drm/radeon: flush read cache for gtt with fence on r6xx and newer GPU V3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board
https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #10 from Florian Mickler 2012-01-21 08:46:25 PST --- A patch referencing this bug report has been merged in Linux v3.2-rc1: commit 5f0a26128d66ef81613fe923d5c288942844ccdc Author: Alex Deucher Date: Fri Oct 7 14:23:47 2011 -0400 drm/radeon/kms: bail early in dvi_detect for digital only connectors -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'
https://bugs.freedesktop.org/show_bug.cgi?id=43941 --- Comment #15 from Florian Mickler 2012-01-21 08:46:56 PST --- A patch referencing this bug report has been merged in Linux v3.3-rc1: commit cc1f71942944890c7e05fc55dc4427c94b63d4f1 Author: Dave Airlie Date: Thu Jan 5 09:55:22 2012 + drm: introduce drm_can_sleep and use in intel/radeon drivers. (v2) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #19 from Florian Mickler 2012-01-21 08:53:40 PST --- A patch referencing this bug report has been merged in Linux v3.2-rc1: commit cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd Author: Alex Deucher Date: Fri Oct 28 16:07:36 2011 -0400 drm/radeon/kms: fix DP setup on TRAVIS bridges -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #5 from Florian Mickler 2012-01-21 08:54:10 PST --- A patch referencing this bug report has been merged in Linux v3.2-rc6: commit cd5cfce856684e13b9b57d46b78bb827e9c4da3c Author: Alex Deucher Date: Mon Dec 12 09:23:48 2011 -0500 drm/radeon/kms: add some new pci ids -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote: > On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: > > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell > > wrote: > > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation > > > issue, and not really an interface". ?The dma-buf infrastructure is > > > explicitly intended as an interface between modules/drivers, so it > > > should use EXPORT_SYMBOL instead. > > > > + Konrad, Arnd, Mauro: there were strong objections on using > > EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I > > suggest we first arrive at a consensus before merging this patch. > > This discussion seems to have stagnated; how do we move forward here? > > Sumit, as the primary author and new maintainer (congrats!) of the > dma-buf infrastructure, it seems like it's really your call how to > proceed. I'd still like to see this be something that we can use from > the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have > argued in this thread. It really seems to me that this change on a > technical level won't have any adverse effect on the scenarios where it > can be used today, but it will allow it to be used more widely, which > will prevent duplication and fragmentation in the future and be greatly > appreciated by users of hardware such as Optimus. Given that I've participated quite a bit in the design of dma_buf as-is, let me throw in my totally irrelevant opinion, too ;-) I'll refrain from comment on the actual patch, it's obviously a hot topic. Furthermore I might need to ask Intel's legal dep for guidance to asses things wrt my own contributions to dma_buf. Otoh I'd like nvidia to be on board, especially when we're desingned additions to dma_buf required to make it really work for multiple gpus. In additions it looks like that the nvidia blob will only be an importer of a dma_buf, at least for the use-cases discussed here. So why don't you just ditch this patch here and add a small shim to your blob to interface with drm's prime as an importing driver? I personally would deem that acceptable and I think Dave wouldn't mind too much, either. Yours, Daniel Disclaimer: This is my own opinion and I do not speak as an Intel employee here. -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec
After updating to kernel 3.3-rc1 I have experienced a lockup of my GPU. I left my KDE desktop running until the screensaver turned off the monitors. But on key presses it would not turn back on. Ctrl+Alt+F1 to switch to another virtual console also did not work. Alt+SysRq magic still worked, so I was able to force the syslog to disk and restart the system.
No subject
/usr/sbin/run-crons && /usr/sbin/run-crons) Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0: GPU lockup CP stall for more than 1msec Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting for 0x0003F1F2 last fence id 0x0003F1F1) Jan 21 19:39:41 thoregon kernel: [ 6364.636341] radeon :07:00.0: GPU softreset Jan 21 19:39:41 thoregon kernel: [ 6364.636348] radeon :07:00.0: R_008010_GRBM_STATUS=0xA0003028 Jan 21 19:39:41 thoregon kernel: [ 6364.636354] radeon :07:00.0: R_008014_GRBM_STATUS2=0x0002 Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0: GPU lockup CP stall for more than 1msec Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting for 0x0003F1F2 last fence id 0x0003F1F1) Jan 21 19:39:41 thoregon kernel: [ 6364.636341] radeon :07:00.0: GPU softreset Jan 21 19:39:41 thoregon kernel: [ 6364.636348] radeon :07:00.0: R_008010_GRBM_STATUS=0xA0003028 Jan 21 19:39:41 thoregon kernel: [ 6364.636354] radeon :07:00.0: R_008014_GRBM_STATUS2=0x0002 Jan 21 19:39:41 thoregon kernel: [ 6364.636359] radeon :07:00.0: R_000E50_SRBM_STATUS=0x20C0 Jan 21 19:39:41 thoregon kernel: [ 6364.636370] radeon :07:00.0: R_008020_GRBM_SOFT_RESET=0x7FEE Jan 21 19:39:41 thoregon kernel: [ 6364.651219] radeon :07:00.0: R_008020_GRBM_SOFT_RESET=0x0001 Jan 21 19:39:41 thoregon kernel: [ 6364.667212] radeon :07:00.0: R_008010_GRBM_STATUS=0x3028 Jan 21 19:39:41 thoregon kernel: [ 6364.667217] radeon :07:00.0: R_008014_GRBM_STATUS2=0x0002 Jan 21 19:39:41 thoregon kernel: [ 6364.667223] radeon :07:00.0: R_000E50_SRBM_STATUS=0x20C0 Jan 21 19:39:41 thoregon kernel: [ 6364.668226] radeon :07:00.0: GPU reset succeed Jan 21 19:39:41 thoregon kernel: [ 6364.673142] [drm] PCIE GART of 512M enabled (table at 0x0004). Jan 21 19:39:41 thoregon kernel: [ 6364.673177] radeon :07:00.0: WB enabled Jan 21 19:39:41 thoregon kernel: [ 6364.673184] [drm] fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x880328636c00 Jan 21 19:39:41 thoregon kernel: [ 6364.719445] [drm] ring test on 0 succeeded in 1 usecs Jan 21 19:40:01 thoregon cron[3975]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons) Jan 21 19:43:37 thoregon kernel: [ 6600.390150] INFO: task X:3098 blocked for more than 120 seconds. Jan 21 19:43:37 thoregon kernel: [ 6600.390157] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 21 19:43:37 thoregon kernel: [ 6600.390163] X D 880337d50a00 0 3098 3077 0x0040 Jan 21 19:43:37 thoregon kernel: [ 6600.390174] 88031df15080 0086 8802f5087300 00010a00 Jan 21 19:43:37 thoregon kernel: [ 6600.390185] 88031bf79fd8 00010a00 88031bf78000 88031bf79fd8 Jan 21 19:43:37 thoregon kernel: [ 6600.390194] 00010a00 88031df15080 00010a00 00010a00 Jan 21 19:43:37 thoregon kernel: [ 6600.390203] Call Trace: Jan 21 19:43:37 thoregon kernel: [ 6600.390219] [] ? __mutex_lock_slowpath+0xc8/0x140 Jan 21 19:43:37 thoregon kernel: [ 6600.390230] [] ? mutex_lock+0x1a/0x40 Jan 21 19:43:37 thoregon kernel: [ 6600.390239] [] ? radeon_ib_get+0x52/0x230 Jan 21 19:43:37 thoregon kernel: [ 6600.390249] [] ? r600_ib_test+0x5a/0x300 Jan 21 19:43:37 thoregon kernel: [ 6600.390258] [] ? rv770_startup+0xf7e/0x1590 Jan 21 19:43:37 thoregon kernel: [ 6600.390267] [] ? rv770_resume+0x2c/0x90 Jan 21 19:43:37 thoregon kernel: [ 6600.390275] [] ? radeon_gpu_reset+0x11e/0x160 Jan 21 19:43:37 thoregon kernel: [ 6600.390284] [] ? radeon_fence_wait+0x363/0x3b0 Jan 21 19:43:37 thoregon kernel: [ 6600.390293] [] ? wake_up_bit+0x40/0x40 Jan 21 19:43:37 thoregon kernel: [ 6600.390301] [] ? radeon_ib_get+0x1e7/0x230 Jan 21 19:43:37 thoregon kernel: [ 6600.390310] [] ? radeon_cs_ioctl+0x27a/0x4d0 Jan 21 19:43:37 thoregon kernel: [ 6600.390319] [] ? drm_ioctl+0x3e4/0x490 Jan 21 19:43:37 thoregon kernel: [ 6600.390327] [] ? radeon_cs_finish_pages+0xa0/0xa0 Jan 21 19:43:37 thoregon kernel: [ 6600.390336] [] ? do_page_fault+0x199/0x420 Jan 21 19:43:37 thoregon kernel: [ 6600.390344] [] ? mmap_region+0x1dc/0x570 Jan 21 19:43:37 thoregon kernel: [ 6600.390352] [] ? do_vfs_ioctl+0x96/0x4e0 Jan 21 19:43:37 thoregon kernel: [ 6600.390359] [] ? __schedule+0x28c/0x630 Jan 21 19:43:37 thoregon kernel: [ 6600.390366] [] ? sys_ioctl+0x49/0x90 Jan 21 19:43:37 thoregon kernel: [ 6600.390375] [] ? system_call_fastpath+0x16/0x1b Jan 21 19:45:08 thoregon kernel: [ 6691.864440] SysRq : Emergency Sync Jan 21 19:45:08 thoregon kernel: [ 6691.864838] Emergency Sync complete Jan 21 19:45:14 thoregon kernel: [ 6697.476112] SysRq : Emergency Remount R/O Jan 21 19:46:33 thoregon kernel: [0.00] Linux version 3.3.0-rc1 (root at thoregon) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.0, pie-0.4.6) ) #1 SMP Fri Jan 20 09:54:26 CET 2012 I did not have any trouble with 3.2 or earlier kernel,
[BUG] Intel HD Graphic QM57 chipset: Dell U3011 monitor turns to power saving mode
On Sat, 21 Jan 2012 13:56:21 -0500, Mathieu Desnoyers wrote: > Dell U3011 monitor turns to power saving mode when resolution set to 2560 x > 1600 > (intermittent) > > Reproduced with: > Linux 2.6.38-1-amd64 (Debian kernel) > Linux 3.1.0-1-amd64 (Debian kernel) > Linux 3.2.0-1-amd64 (Debian kernel) > > The computer is a Lenovo X201 Tablet (Intel QM57 chipset), on a X200 > docking station. The docking station uses a DisplayPort cable to connect > to the monitor. I tried upgrading my Bios from 1.34/1.13 to 1.38/1.14 > (latest), which did not fix the problem. I cannot use anything else > than DisplayPort in this case to connect the monitor at 2560 x 1600, > because this resolution requires either the bandwidth provided by a > dual-link DVI (which I cannot connect in my docking station), or > DisplayPort. I use this same monitor, and have run it with an X200 in the past. Can you capture a dmesg output with the kernel parameter drm.debug=0xe set? That will let us see the DP link training adventure and see what's broken. If you can, separate traces of working and non-working tries would be nice. And, of course, trying 3.3-rc1 would be helpful as that's what any test patches would be developed on top of. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120121/8d3cddbf/attachment.pgp>
[Bug 41561] [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board
https://bugs.freedesktop.org/show_bug.cgi?id=41561 --- Comment #11 from Florian Mickler 2012-01-21 13:23:51 PST --- A patch referencing a commit referencing this bug report has been merged in Linux v3.2-rc1: commit 340764465aa4a586ca332e61ae64883e5ad6f183 Author: Jerome Glisse Date: Mon Oct 24 18:16:34 2011 -0400 drm/radeon: avoid bouncing connector status btw disconnected & unknown -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[BUG] Intel HD Graphic QM57 chipset: Dell U3011 monitor turns to power saving mode
Dell U3011 monitor turns to power saving mode when resolution set to 2560 x 1600 (intermittent) Reproduced with: Linux 2.6.38-1-amd64 (Debian kernel) Linux 3.1.0-1-amd64 (Debian kernel) Linux 3.2.0-1-amd64 (Debian kernel) The computer is a Lenovo X201 Tablet (Intel QM57 chipset), on a X200 docking station. The docking station uses a DisplayPort cable to connect to the monitor. I tried upgrading my Bios from 1.34/1.13 to 1.38/1.14 (latest), which did not fix the problem. I cannot use anything else than DisplayPort in this case to connect the monitor at 2560 x 1600, because this resolution requires either the bandwidth provided by a dual-link DVI (which I cannot connect in my docking station), or DisplayPort. The laptop Intel HD Graphic along with the X200 displayport is documented to support this resolution (ref. http://www.intel.com/products/notebook/chipsets/qm57/qm57-overview.htm). The screen works at 2560 x 1600 resolution, but it takes many attempts to get it to work. I usually need to restart the screen and reboot the laptop a few times, and shutting down the LVDS screen of the laptop seems to help (sometimes). Interesting fact, if I bring the LVDS screen back up after that, I had a few successful cases where both screens worked fine together. I sometimes had to close the lid of my laptop, which puts it to sleep, and open it to find that the two screens end up working correctly. I run this in gnome 3.2 (in "classic" mode), setup with a resolution of 2560x1600 for the Dell 30", and 1280x800 for my laptop. Both DP1 and LVDS1 displays are activated (dual-screen). In my dmesg (3.2 kernel), I sometimes get this message when I power cycle my monitor (in the cases where it does not work): [ 3486.644818] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 182 [ 3486.644824] [drm:drm_edid_block_valid] *ERROR* Raw EDID: [ 3486.644830] <3>00 ff ff ff ff ff ff 00 10 ac 65 40 34 34 30 31 ..e at 4401 [ 3486.644834] <3>15 01 04 b5 40 28 78 3a 8d 85 ad 4f 35 b1 25 0e @(x:...O5.%. [ 3486.644837] <3>50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 d1 00 d1 PT.K.qO. at ... [ 3486.644841] <3>40 01 01 01 01 e2 68 00 a0 a0 40 2e 60 30 20 36 @.h... at .`0 6 [ 3486.644845] <3>00 81 91 21 00 00 1a 00 00 00 ff 00 50 48 35 4e ...!PH5N [ 3486.644848] <3>59 31 43 39 30 34 34 4c 0a 00 00 00 fc 00 44 45 Y1C9044L..DE [ 3486.644852] <3>4c 4c 20 55 33 30 31 31 0a 20 20 00 00 00 fd 00 LL U3011. . [ 3486.644855] <3>31 56 1d 71 1c 00 0a 20 20 20 20 20 20 01 08 02 1V.q... ... I've also seen this other message (after a reboot): [ 52.638311] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting The i915 and drm drivers are used (detailed dmesg at the bottom of this email), with kms. Xorg version: % dpkg -l xorg ii xorg 1:7.6+10 X.Org X Window System % dpkg -l xserver-xorg-video-intel ii xserver-xorg-v 2:2.17.0-1 X.Org X server -- Intel i8xx, i9xx display d % dpkg -l gnome ii gnome 1:3.0+6 The GNOME Desktop Environment, with extra components xrandr -q --verbose outputs are identical (except for "Timestamp" fields) for the runs "fail" and "ok" detailed below. % xrandr -q --verbose # when the screen is in power saving mode (fail) Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 8192 x 8192 LVDS1 connected 1280x800+0+0 (0x45) normal (normal left inverted right x axis y axis) 261mm x 163mm Identifier: 0x41 Timestamp: 779491 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: EDID: 000030ae1140 00130103801a1078ea2f158a58568f26 1850540001010101010101010101 0101010101015c1d00f2502017303054 360005a310195c1d00f250201730 3054360005a31019000f0081 0a3c810a3c1e0a009e0800fe 0048563132315758362d3131300a0014 BACKLIGHT: 15 (0x000f) range: (0,15) Backlight: 15 (0x000f) range: (0,15) scaling mode: Full aspect supported: None Full Center Full aspect 1280x800 (0x45) 75.2MHz -HSync -VSync *current +preferred h: width 1280 start 1328 end 1412 total 1522 skew0 clock 49.4KHz v: height 800 start 803 end 809 total 823 clock 60.0Hz 1024x768 (0x46) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x47) 40.0MHz +HSync +VSync h: width 800 start 840 en
