Bug 105217 - 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
Summary: Blank screen with only mouse pointer after 7.10 radeon driver update; display...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL: https://bugs.launchpad.net/ubuntu/+so...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-22 22:35 UTC by james.m.coulthard
Modified: 2019-11-19 08:01 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (29.52 MB, text/plain)
2018-02-22 22:35 UTC, james.m.coulthard
no flags Details
Xorg.0.log of modesetting driver session (58.95 KB, text/plain)
2018-02-23 15:25 UTC, james.m.coulthard
no flags Details
Xorg.0.log of 7.9 radeon driver session (45.33 KB, text/plain)
2018-02-23 16:48 UTC, james.m.coulthard
no flags Details
Xorg.0.log of DRI Option 3 setting on 7.10 - incorrect, I attached wrong file. pls ignore. (47.16 KB, text/plain)
2018-02-25 15:57 UTC, james.m.coulthard
no flags Details

Description james.m.coulthard 2018-02-22 22:35:06 UTC
Created attachment 137544 [details]
Xorg.0.log

I get a blank screen with only mouse pointer upon boot, after the splash. This started after the mesa driver update on 2/15/18, which included xserver-xorg-video-radeon-hwe-16.04:amd64 1:7.10.0-1~16.04.1. (7.10 of the radeon driver) The display does not appear to switch to tty7 upon lightdm start.
 Xorg.0.log quickly grows and continues to grow.

I believe `lightdm` is not starting `Xorg` on the correct display, but, I don't know how to determine this from the logs.

Here is the command line `lightdm` uses to launch `Xorg`:

    ~$ ps -ef | grep lightdm
    root 1261 1 0 18:23 ? 00:00:00 /usr/sbin/lightdm
    root 1316 1261 6 18:23 tty7 00:00:03 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    root 1350 1261 0 18:23 ? 00:00:00 lightdm --session-child 12 15

*OCCURRENCE ON 2/15/18:*

I performed a normal upgrade on 2/15/18 through the software manager in Ubuntu 16.04LTS.

It upgraded the following libraries (`/var/log/dpkg.log [pkg][old ver][new ver]`):

    libegl1-mesa-dev:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libwayland-egl1-mesa:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-ubuntu0~16.04.1
    libwayland-egl1-mesa:i386 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libegl1-mesa:i386 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libegl1-mesa:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libgbm1:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libgbm1:i386 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libosmesa6:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libosmesa6:i386 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libgles2-mesa:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libgl1-mesa-glx:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libgl1-mesa-glx:i386 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libglapi-mesa:i386 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libglapi-mesa:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libgl1-mesa-dri:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libgl1-mesa-dri:i386 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    libxatracker2:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    linux-firmware:all 1.157.15 1.157.16
    mesa-vdpau-drivers:i386 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    mesa-vdpau-drivers:amd64 17.2.4-0ubuntu1~16.04.4 17.2.8-0ubuntu0~16.04.1
    xserver-xorg-video-radeon-hwe-16.04:amd64 1:7.9.0-0ubuntu1~16.04.1 
1:7.10.0-1~16.04.1
    xserver-xorg-video-ati-hwe-16.04:amd64 1:7.9.0-0ubuntu1~16.04.1 1:7.10.0-1~16.04.1

I should note, this is *not* the compiz/unity update package list. It is the mesa drivers.

Upon reboot, I started getting a blank screen with only a mouse pointer when the display manager started.

I press <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>F1</kbd> to go into console, and I can find the following in the `Xorg.0.log`:

    [ 4800.851] (WW) RADEON(0): flip queue failed: Invalid argument
    [ 4800.851] (WW) RADEON(0): Page flip failed: Invalid argument

These warning messages are *constantly* streaming into the log file, and it *keeps growing*. This wasn't present before the library update. I have provided a log file.

Video h/w on my laptop:

     *-display

       description: VGA compatible controller
       product: RV516/M64-S [Mobility Radeon X2300]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 0
       bus info: pci@0000:01:00.0
       version: 00
       width: 32 bits
       clock: 33MHz
       capabilities: pm pciexpress msi vga_controller bus_master cap_list rom
       configuration: driver=radeon latency=0
       resources: irq:16 memory:d0000000-d3ffffff ioport:4000(size=256) memory:d8300000-d830ffff memory:c0000-dffff

1st lines of modinfo output:

   filename: /lib/modules/4.13.0-26-generic/kernel/drivers/gpu/drm/radeon/radeon.ko
    license: GPL and additional rights
    description: ATI Radeon

*UPDATE 2/16/18:*

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. <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>F7</kbd> without first going to console does not do anything. Lightdm seems to start Xorg on the wrong display. I tried a vt.handoff=7 on the linux kernel command line, and this did not help.

Here is the output of `w` immediately after pressing <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>F7</kbd> and going to the normal desktop:

     09:38:01 up 44 min, 1 user, load average: 0.60, 0.67, 0.82
    USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
    user1 tty7 :0 08:53 44:14 6:16 0.29s /sbin/upstart -

This display listing appears normal.

I should note that compiz and unity still seem to function. The desktop is fully available and already loaded when I switch to tty7, but its just blank with a mouse cursor without switching the VT.

*UPDATE 2/19/18:*

I don't believe this to be a duplicate of the compiz/unity issue. The issue I observed resulted from the mesa driver update on the morning of 2/15/18. The compiz/unity update has yet to be applied to my system. In fact, there is one other post that looks to be the same issue as I am seeing, it is: https://askubuntu.com/questions/1006264/var-log-xorg-0-log-file-growing-fast

I think something is hosed with the 7.10 radeon driver in mesa 17.2.8, but I can't find the 17.2.4 pkgs to roll back and test the theory. The 17.2.4 was pulled from updates and proposed lines. I'm hesitant to rollback to 11.2.

The warning string in the Xorg.0.log, "flip queue failed", is found in the following driver:
/usr/lib/xorg/modules/drivers/radeon_drv.so
found in package: xserver-xorg-video-radeon-hwe-16.04

This module is loaded in Xorg on my machine. I downloaded the source and looked through the code.

Specifically, the source file:

    ./src/drmmode_display.c:	xf86DrvMsg(scrn->scrnIndex, X_WARNING, "flip queue failed: %s\n",

Line 3093 in the source code of `drmmode_display.c`:

    flip_error:
     xf86DrvMsg(scrn->scrnIndex, X_WARNING, "flip queue failed: %s\n",
         strerror(errno));

    error:
     if (drm_queue_seq)
      radeon_drm_abort_entry(drm_queue_seq);
     else if (crtc)
      drmmode_flip_abort(crtc, flipdata);
     else {
      abort(NULL, data);
      drmmode_fb_reference(pRADEONEnt->fd, &flipdata->fb, NULL);
      free(flipdata);
     }

     xf86DrvMsg(scrn->scrnIndex, X_WARNING, "Page flip failed: %s\n",
         strerror(errno));

Okay, a little code inspection leads to one of these three function calls failing, first at line 3062:

  if (crtc == ref_crtc) {
   if (drmmode_page_flip_target_absolute(pRADEONEnt,
             drmmode_crtc,
             fb->handle,
             flip_flags,
             drm_queue_seq,
             target_msc) != 0)
    goto flip_error;
  } else {
   if (drmmode_page_flip_target_relative(pRADEONEnt,
             drmmode_crtc,
             fb->handle,
             flip_flags,
             drm_queue_seq, 0) != 0)
    goto flip_error;
  }

Then at Line 3039 in the source can also cause the message:

   if (flip_sync == FLIP_ASYNC) {
    if (!drmmode_wait_vblank(crtc,
        DRM_VBLANK_RELATIVE |
        DRM_VBLANK_EVENT,
        0, drm_queue_seq,
        NULL, NULL))
     goto flip_error;
    goto next;
   }
Comment 1 Michel Dänzer 2018-02-23 09:17:41 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.
Comment 2 james.m.coulthard 2018-02-23 13:50:08 UTC
(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.
Comment 3 james.m.coulthard 2018-02-23 15:25:21 UTC
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.
Comment 4 james.m.coulthard 2018-02-23 15:29:37 UTC
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.
Comment 5 james.m.coulthard 2018-02-23 15:41:00 UTC
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...
Comment 6 james.m.coulthard 2018-02-23 15:58:38 UTC
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.
Comment 7 james.m.coulthard 2018-02-23 16:27:14 UTC
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.
Comment 8 james.m.coulthard 2018-02-23 16:48:32 UTC
Created attachment 137560 [details]
Xorg.0.log of 7.9 radeon driver session
Comment 9 Mario Kleiner 2018-02-23 20:04:10 UTC
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.
Comment 10 Michel Dänzer 2018-02-23 20:16:44 UTC
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.
Comment 11 james.m.coulthard 2018-02-23 22:04:40 UTC
(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?
Comment 12 james.m.coulthard 2018-02-23 22:21:41 UTC
Just looked at Michael's change...  hah, look at that. 
DRI option 3 must force 32 bit depth?
Comment 13 Mario Kleiner 2018-02-23 23:01:26 UTC
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.
Comment 14 james.m.coulthard 2018-02-25 15:55:25 UTC
(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?
Comment 15 james.m.coulthard 2018-02-25 15:57:07 UTC
Created attachment 137593 [details]
Xorg.0.log of DRI Option 3 setting on 7.10 - incorrect, I attached wrong file.  pls ignore.
Comment 16 james.m.coulthard 2018-02-25 16:00:01 UTC
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.
Comment 17 Mario Kleiner 2018-02-28 21:33:48 UTC
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?
Comment 18 Martin Peres 2019-11-19 08:01:50 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/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.