Bug 74982

Summary: System crash with HD7770
Product: xorg Reporter: Martin Davey <martind574>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: julien.isorce
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
screenshot
none
dmesg output
none
Xorg log
none
dmesg none

Description Martin Davey 2014-02-14 14:22:52 UTC
Hi,

I have a Radeon HD7770 with an abit pro motherboard, running Fedora 20.

xorg-x11-server reports version 1.14.4-6.fc20.

I have a repeatable complete system crash (screen goes blank, numlock un-responsive etc), in some conditions when a drop down is selected in certain programs.

Under XFCE4, if I load gimp and select export, a drop down list appears. If I click on this, everything freezes, screen goes blank, and system crashes.

I get the same now with inkscape, and some graphical export functions under freecad.

Given that both these programs have graphics functions , I kind of got the feeling that it may be related to the graphics driver. I can't think of any way of proving this however.

Oddly the same happens in audacity when click the drop-down bar to change audio, not obviously this is not a graphical application. But again the crash is occurring on a drop down box.

This used to happen in eclipse under KDE... actually when I expanded a tree view in the debug window. But then I switched to XFCE4 so not sure if that issue is still present. 

Sorry if this does not belong here. Please let me know if there is anything else I can do or try to help with the debug.


Thanks,



Martin.
Comment 1 Alex Deucher 2014-02-14 14:30:29 UTC
Please attach your xorg log and dmesg output.
Comment 2 Martin Davey 2014-02-14 15:03:07 UTC
Actually I have just tried this in gnome-classic, and I have not managed to crash the system as yet.

Sounds like something related to XFCE and the graphics driver perhaps?


Martin.
Comment 3 Vadim Girlin 2014-02-14 15:20:26 UTC
Created attachment 94073 [details]
screenshot

I think I've seen the same issue sometimes on pitcairn. Now I've looked into it a bit and found the way that reliably reproduces it for me with eclipse Kepler SR1 and XFCE on Fedora 20 (compositor is disabled):
 
1. Select "Window" - "Preferences" in the eclipse menu.
2. In the "Preferences" dialog, select the Formatter tab in the tree ("C++"-"Code style"-"Formatter")
3. Click on the "Active profile" combobox to open the list of formatter profiles. I have few custom profiles added there and when the last of them is selected as current, the listbox is goes beyond the borders of the "Preferences" dialog (as shown on the attached screenshot). If the "Preferences" window itself is close enough to the top of the screen so that the part of the listbox would end up outside of the screen area, then it always results in gpu lockup, otherwise it works as expected.
Comment 4 Martin Davey 2014-02-14 15:50:19 UTC
Created attachment 94075 [details]
dmesg output
Comment 5 Martin Davey 2014-02-14 15:50:42 UTC
Created attachment 94076 [details]
Xorg log
Comment 6 Martin Davey 2014-02-14 15:52:33 UTC
Thanks Vadim, I'll try and reproduce your steps in Eclipse.
Comment 7 Michel Dänzer 2014-02-17 07:28:46 UTC
(In reply to comment #3)
> If the "Preferences" window itself is close enough to the top of the screen so
> that the part of the listbox would end up outside of the screen area, then it
> always results in gpu lockup, otherwise it works as expected.

Sounds like it ends up trying to render outside of the screen boundaries... for which compositing (even just xcompmgr -a) should be a good workaround.

Is there anything about GPU VM protection faults and/or the lockup itself in dmesg when it happens? If so, can you attach that here?
Comment 8 Martin Davey 2014-02-17 08:22:14 UTC
Hi,

I was able to re-produce Vadim's Eclipse fault. As soon as there is enough menu items to go beyond the top of the screen the system locks up.

I cannot see anything in dmesg that relates to a GPU fault.


Martin.
Comment 9 Vadim Girlin 2014-02-17 19:46:56 UTC
Created attachment 94235 [details]
dmesg

I've managed to switch to VT afer lockup (it doesn't always work), and there is some output regarding the lockup in the attached dmesg.
Comment 10 ualaezza 2014-07-14 18:23:34 UTC
Hello, this is my first time commenting a bug report, so, sorry for my english
and sorry if I don't do it right...

I managed to figure it out, trying a simple test, on XFCE;
if you are using the Adwaita Theme, changing it to default
XFCE theme the problem with the drop-down list is gone, so,
I don't know if the problem is the radeon driver, maybe is
related to GTK+3 and Adwaita.

Steps to reproduce.

(with Adwaita Theme)
1. Launch xfce4-terminal
2. Edit --> Preference
3. Go to Advanced Tab
4. Click on Codification drop-down list
5. Your X server freezes, or monitor turns off (my case)
   with out been able to do nothing no even switch VTs...

(now with XFCE Default theme)
1. Launch xfce4-terminal
2. Edit --> Preference
3. Go to Advanced Tab
4. Click on Codification drop-down list
5. Voila!!, nothing happens you can change your codification
   and use any drop-down list with out hesitate or have afraid
   of lose the work...

(my hard)
AMD FX-8150 - ASUS M5A99FX PRO r2.0 - Sapphire Radeon HD 7770
Comment 11 ualaezza 2014-07-14 18:25:27 UTC
I forgot to say that I tryed this steps in Fedora 20
and Gentoo (NO vanilla, NO hardened)...
Comment 12 mirh 2018-10-16 13:24:40 UTC
Is this still a thing?
Comment 13 Martin Peres 2019-11-19 07:45:09 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/95.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.