Summary: | Blank screen with only mouse pointer after 7.10 radeon driver update; display does not switch to tty7 upon lightdm start; Xorg.0.log quickly grows | ||
---|---|---|---|
Product: | xorg | Reporter: | james.m.coulthard |
Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> |
Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | medium | CC: | james.m.coulthard |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
URL: | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati-hwe-16.04/+bug/1750393 | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Description
james.m.coulthard
2018-02-22 22:35:06 UTC
(In reply to james.coulthard from comment #0) > > It upgraded the following libraries (`/var/log/dpkg.log [pkg][old ver][new > ver]`): Are those the only packages that were upgraded? > I appear to be booting to the wrong VT display. All of the symptoms above > are true; however, if I perform a > <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>F1</kbd> (up to <kbd>F6</kbd>) at > startup and then immediately perform a > <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>F7</kbd>, which switches the VT, I go to > my normal desktop as if it had booted correctly. That sounds like an Ubuntu startup issue then. Does the problem also occur using the Xorg modesetting driver instead of radeon? If not, please attach the corresponding Xorg log file. > I think something is hosed with the 7.10 radeon driver in mesa 17.2.8, The Xorg radeon driver is independent from Mesa. This issue doesn't look directly related to Mesa. (In reply to Michel Dänzer from comment #1) > (In reply to james.coulthard from comment #0) > > > > It upgraded the following libraries (`/var/log/dpkg.log [pkg][old ver][new > > ver]`): > > Are those the only packages that were upgraded? [JMC] Yes, these are exactly the packages that upgraded at the time of the issue. Nothing else. Definitively not unity or compiz packages. I held off taking those updates. > > > > I appear to be booting to the wrong VT display. All of the symptoms above > > are true; however, if I perform a > > <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>F1</kbd> (up to <kbd>F6</kbd>) at > > startup and then immediately perform a > > <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>F7</kbd>, which switches the VT, I go to > > my normal desktop as if it had booted correctly. > > That sounds like an Ubuntu startup issue then. [JMC] Possibly, but, I've seen other posts online where an issue with the driver causes the blank screen and mouse pointer. I'm thinking it might be a delay or race condition with Upstart or LightDM waiting on Xorg to start, but, root cause stems from radeon (ie. the warning messages.) Also, Xorg.0.log shouldn't fill up with 30MB of warning messages in 8 hours... > > Does the problem also occur using the Xorg modesetting driver instead of > radeon? If not, please attach the corresponding Xorg log file. > [JMC] I have not tried this. Will try it and report back. > > > I think something is hosed with the 7.10 radeon driver in mesa 17.2.8, > > The Xorg radeon driver is independent from Mesa. This issue doesn't look > directly related to Mesa. [JMC] Agree. I believe it was just coincident that radeon and Mesa updated at the same time. [JMC] Thanks for taking the time to look at this Michael. Pls let me know if there is anything you would like to see form the system. Created attachment 137559 [details]
Xorg.0.log of modesetting driver session
This is the Xorg.0.log of the environment when the modesetting driver is used in stead of 7.10 radeon. The issue disappears from the log and display behavior changes.
Result of changing to modesetting driver: The system booted straight to desktop without the need to manually switch to VT7. Screen was not blank at startup; however, the screen did not display correctly. The desktop was skewed and looked like a set of wavy lines, like those found on an old style analog television when the vertical and/or horizontal scan timing is off. Mouse pointer appeared unaffected. Could not stay on modesetting driver and switched back. Xorg.0.log of the session has been provided. Warning messages are not found in the new logfile. Michael, here is a thought... I can't roll back to 7.9 radeon in Ubuntu because Canonical has already pulled that version from the update PPA. I can't apt-get install <pkg>=<ver> to get back. It will only allow me to roll back to 11.2. (the default 16.04LTS version) Do you knwo of another PPA or online location of the *.deb of the 7.9 ati driver package for the x86_64 architecture? A Debian repo or something? I could roll back that one package and demonstrate the issue comes in with version 9.10. Just a thought... I believe I found the 7.9 Ubuntu package at: https://launchpad.net/ubuntu/xenial/amd64/xserver-xorg-video-radeon-hwe-16.04/1:7.9.0-0ubuntu1~16.04.1 I will try to install this single package with dpkg, then update the dependencies. If successful, will "hold" this version in apt. I will update this thread once completed. That fixed it. I downloaded the 7.9 *.deb. I executed: > sudo dpkg -i xserver-xorg-video-radeon-hwe-16.04_7.9.0-0ubuntu1_16.04.1_amd64.deb > sudo apt-get -f install > sudo apt-mark hold xserver-xorg-video-radeon-hwe-16.04 This downgraded the radeon driver package, fixed dependencies, and held the driver pkg from further updates. Rebooted and issue is resolved. No other files were touched. It's definitely something in the 7.10 changes. I will upload a new Xorg.0.log of the 7.9 behavior. Created attachment 137560 [details]
Xorg.0.log of 7.9 radeon driver session
A r300, so accordign to your log, the driver uses DRI2 + EXA. I think this would hit the bug which iirc was introduced in 7.10.0 which causes pageflipping failure under DRI2, which was fixed in master by Michel's commit 733f606dd6ca8350 ("Always use screen depth/bpp for KMS framebuffers"). Might explain what you see. James, does Option "DRI" "3" avoid the problem? If so, it's probably the issue Mario mentioned. If not, please attach the corresponding Xorg log file again. (In reply to Michel Dänzer from comment #10) > James, does > > Option "DRI" "3" > > avoid the problem? If so, it's probably the issue Mario mentioned. If not, > please attach the corresponding Xorg log file again. Hi Michael, and thank you, Mario, for the comments. I'm not familiar with that configuration setting. Can you elaborate on what file and line you would like me to change, and I would be happy to do so? Just looked at Michael's change... hah, look at that. DRI option 3 must force 32 bit depth? If you create a file named /etc/X11/xorg.conf with this text snippet... Section "Device" Identifier "Card0" Driver "ati" Option "DRI" "3" EndSection ... and restart lightdm, it should do the trick. (In reply to Mario Kleiner from comment #13) > If you create a file named /etc/X11/xorg.conf > > with this text snippet... > > Section "Device" > Identifier "Card0" > Driver "ati" > Option "DRI" "3" > EndSection > > ... and restart lightdm, it should do the trick. Hi Mario, I attempted this just now. I was able to successfully set the DRI option to 3 in Xorg. I then upgraded the radeon driver to 7.10 and rebooted. Unfortunately, this did not help the problem. Same symptoms appeared. I rolled back radeon driver to 7.9. Any other suggestions? Created attachment 137593 [details]
Xorg.0.log of DRI Option 3 setting on 7.10 - incorrect, I attached wrong file. pls ignore.
Comment on attachment 137593 [details]
Xorg.0.log of DRI Option 3 setting on 7.10 - incorrect, I attached wrong file. pls ignore.
incorrect file, I attached wrong file. pls ignore.
Hmm. That incorrect file actually looked good. DRI3+Present enabled, pageflip errors gone as expected. Date also seemed to be plausible. Are you sure that was wrong? -- 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/180. |
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.