Red Hat Bugzilla – Bug 860712
[6550D SUMO] problems with second monitor on VGA, causing GPU lockups
Last modified: 2014-09-13 14:58:53 EDT
Created attachment 617572 [details] first_part_of_dmesg.txt Description of problem: Two monitors. One 1920x1080 connected on DVI. (works fine) But if is connected second on VGA (1680x1050): Version-Release number of selected component (if applicable): kernel vanilla 3.5 .. 3.6.0-rc5 kernel ~agd5f/linux origin/drm-next-3.7-wip xorg 1.13 ati ddx - git How reproducible: Run Xorg. Steps to Reproduce: * with agd5f/linux kernel it boots without errors, dvi is OK and set to 1680x1050 and VGA is off. * when I run startx it start rebooting gpu Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GPU lockup CP stall for more than 10000msec Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GPU lockup (waiting for 0x0000000000000004 last fence id 0x0000000000000002) Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: Saved 55 dwords of commands on ring 0. Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GPU softreset Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS=0xB2703828 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS_SE0=0x1C000007 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS_SE1=0x00000007 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: SRBM_STATUS=0x20000840 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: R_008674_CP_STALLED_STAT1 = 0x00000000 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: R_008678_CP_STALLED_STAT2 = 0x40000000 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: R_00867C_CP_BUSY_STAT = 0x00008000 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: R_008680_CP_STAT = 0x80228647 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GRBM_SOFT_RESET=0x00007F6B Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS=0x00003828 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS_SE0=0x00000007 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS_SE1=0x00000007 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: SRBM_STATUS=0x20000040 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: R_008674_CP_STALLED_STAT1 = 0x00000000 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: R_008678_CP_STALLED_STAT2 = 0x00000000 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: R_00867C_CP_BUSY_STAT = 0x00000000 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: R_008680_CP_STAT = 0x00000000 Sep 26 16:05:38 localhost kernel: radeon 0000:00:01.0: GPU reset succeeded, trying to resume Sep 26 16:05:39 localhost kernel: [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). Sep 26 16:05:39 localhost kernel: radeon 0000:00:01.0: WB enabled Sep 26 16:05:39 localhost kernel: radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880215fc3c00 Sep 26 16:05:39 localhost kernel: [drm] ring test on 0 succeeded in 2 usecs Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GPU lockup CP stall for more than 10000msec Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GPU lockup (waiting for 0x0000000000000005 last fence id 0x0000000000000003) Sep 26 16:05:49 localhost kernel: [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35). Sep 26 16:05:49 localhost kernel: [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35). Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: ib ring test failed (-35). Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GPU softreset Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS=0xB2703828 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS_SE0=0x1C000007 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS_SE1=0x00000007 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: SRBM_STATUS=0x20000840 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: R_008674_CP_STALLED_STAT1 = 0x00000000 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: R_008678_CP_STALLED_STAT2 = 0x40000000 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: R_00867C_CP_BUSY_STAT = 0x00008000 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: R_008680_CP_STAT = 0x80228643 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GRBM_SOFT_RESET=0x00007F6B Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS=0x00003828 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS_SE0=0x00000007 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GRBM_STATUS_SE1=0x00000007 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: SRBM_STATUS=0x20000040 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: R_008674_CP_STALLED_STAT1 = 0x00000000 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: R_008678_CP_STALLED_STAT2 = 0x00000000 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: R_00867C_CP_BUSY_STAT = 0x00000000 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: R_008680_CP_STAT = 0x00000000 Sep 26 16:05:49 localhost kernel: radeon 0000:00:01.0: GPU reset succeeded, trying to resume Sep 26 16:05:50 localhost kernel: [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). Sep 26 16:05:50 localhost kernel: radeon 0000:00:01.0: WB enabled Sep 26 16:05:50 localhost kernel: radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880215fc3c00 Sep 26 16:05:50 localhost kernel: [drm] ring test on 0 succeeded in 2 usecs Sep 26 16:05:50 localhost kernel: [drm] ib test on ring 0 succeeded in 0 usecs and when I switch to console, both monitors are functional. Actual results: gpu lockups Expected results: gpu without lockups Additional info:
(In reply to comment #0) > Created attachment 617572 [details] > first_part_of_dmesg.txt > > Description of problem: > Two monitors. > One 1920x1080 connected on DVI. (works fine) > But if is connected second on VGA (1680x1050): > > Version-Release number of selected component (if applicable): > kernel vanilla 3.5 .. 3.6.0-rc5 > kernel ~agd5f/linux origin/drm-next-3.7-wip > xorg 1.13 > ati ddx - git That isn't a Fedora kernel. Fedora bugzilla is not the correct place to report issues with upstream kernels. Your bug report is possibly useful to the upstream kernel/xorg developers. I would suggested reporting your issues to the dri-devel list. *** This bug has been marked as a duplicate of bug 126342 ***
Really? So you think it going to tell me it will work with fedora compiled kernel?
(In reply to comment #2) > Really? So you think it going to tell me it will work with fedora compiled > kernel? I didn't say it would work on a Fedora kernel. What I do know is that it isn't a Fedora kernel and you're already using patches that are queued for the 3.7 merge window marked work in progress. Which tells me that reporting it to Fedora is clearly the wrong place. You should be reporting it to the upstream developers. It also tells me that Fedora isn't going to go off and try and solve this particular bug directly. *** This bug has been marked as a duplicate of bug 126342 ***
Created attachment 617638 [details] dmesg_from_fedora_cd X freeze with dualmonitor setup.
so, now it's tested with 3.6.0 from Fedora CD made for this, so I can clearly say, it's broken on Fedora.
more information here http://212.158.157.7/bugreport.html
Discussed at 2012-10-04 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker-review-2.1.2012-10-04-16.00.log.txt . As this looks like a single-system X issue, we reject it as a blocker by established precedent (X bugs that affect only a single system or small range of systems are not considered to be wide enough to be blockers; we don't have the development capacity to commit to fixing all such bugs).
(In reply to comment #6) > more information here > > http://212.158.157.7/bugreport.html This link is broken. Please add more informations as a comment or attachment in Bugzilla.
http://212.158.157.7/bugreport.html is fixed, sorry for unavailability.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still a problem with 3.9 based F19 kernels?
I dont have secondary ASUS monitor anymore.