Bug 1650634

Summary: FBDEV(1): FBIOPUTCMAP and xorg fails to load
Product: Red Hat Enterprise Linux 7 Reporter: Pat Riehecky <riehecky>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.6CC: abenoit, ajb, amike, bmilar, gianluca.cecchi, herrold, jsolomon, lopresti, mihai, misterbonnie, orion, pasik, pasteur, phil, toracat, tpelka
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: xorg-x11-server-1.20.4-4.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 12:42:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg log of failed session
none
Xorg log of successful session after yum downgrade
none
anaconda log-capture none

Description Pat Riehecky 2018-11-16 16:55:25 UTC 
Created attachment 1506506 [details]
Xorg log of failed session

Description of problem:
The xorg log is filled with dozens of:

[    28.650] (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument

Which looks to be similar to another bug traced back to plymouth.  In any case Xorg fails to start.

7.5 had no issues.  Downgrade to 7.5 packages (under Additional info) restores working condition

Version-Release number of selected component (if applicable):
xorg-x11-drv-fbdev-0.5.0-1.el7
xorg-x11-drv-nouveau-1.0.15-1.el7
xorg-x11-server-Xorg-1.20.1-5.1.el7
xorg-x11-drv-vesa-2.4.0-1.el7
plymouth-0.8.9-0.31.20140113.el7

How reproducible:
100% on systems with an nVidia video card.  0% on systems with an intel card.

Steps to Reproduce:
1.Update to 7.6 on a system with an nVidia card
2.reboot
3.X fails to start

Actual results:
X fails to load GDM and hangs "waiting for plymouth" systemd service
(EE) FBDEV(1): FBIOPUTCMAP: Invalid argument

Expected results:
System boots to X as before.

Additional info:
Possibly related
https://bugzilla.redhat.com/show_bug.cgi?id=871054


If I run this command:
yum downgrade xorg-x11-drv-nouveau xorg-x11-server-Xorg xorg-x11-drv-qxl.x86_64 xorg-x11-drv-vesa xorg-x11-drv-dummy xorg-x11-drv-v4l xorg-x11-drv-ati xorg-x11-drv-vmware xorg-x11-drv-fbdev xorg-x11-drv-intel.x86_64

and reboot X starts back up again as expected.



lshw -numeric -C display
  *-display                 
       description: 3D controller
       product: G98 [Quadro NVS 450] [10DE:6FA]
       vendor: NVIDIA Corporation [10DE]
       physical id: 0
       bus info: pci@0000:03:00.0
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list rom
       configuration: driver=nouveau latency=0
       resources: irq:29 memory:f6000000-f6ffffff memory:ec000000-efffffff memory:f4000000-f5ffffff ioport:e000(size=128) memory:f7000000-f701ffff
  *-display
       description: VGA compatible controller
       product: G98 [Quadro NVS 450] [10DE:6FA]
       vendor: NVIDIA Corporation [10DE]
       physical id: 0
       bus info: pci@0000:04:00.0
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
       configuration: driver=nouveau latency=0
       resources: irq:30 memory:f2000000-f2ffffff memory:e8000000-ebffffff memory:f0000000-f1ffffff ioport:d000(size=128) memory:f3000000-f301ffff
Comment 2 Pat Riehecky 2018-11-16 16:56:05 UTC 
Created attachment 1506507 [details]
Xorg log of successful session after yum downgrade
Comment 3 Pat Riehecky 2018-11-16 17:00:27 UTC 
See also https://bugzilla.redhat.com/show_bug.cgi?id=1456010
Comment 4 Pat Riehecky 2018-11-16 17:01:33 UTC 
In general there seems to be a lot of framebuffer bits on the fedora plymouth changelog.
Comment 5 Pat Riehecky 2018-11-19 18:31:25 UTC 
Created attachment 1507316 [details]
anaconda log-capture
Comment 6 Pat Riehecky 2018-11-20 14:27:25 UTC 
This bug is not present in Fedora 29.
Comment 7 Pat Riehecky 2018-11-20 14:28:22 UTC 
The bug remains with the elrepo kernels:
kernel-ml-4.19.2-1.el7.elrepo.x86_64
kernel-lt-4.4.163-1.el7.elrepo.x86_64
Comment 8 Pat Riehecky 2018-11-20 15:46:11 UTC 
Bug resolved by rebuilding xorg-x11-server-1.20.3-1.fc29 [1] for 7.6.

With this in mind it appears to be an Xorg server bug rather than fbdev.



[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1158089
Deps:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1140367
https://koji.fedoraproject.org/koji/buildinfo?buildID=1140369
Comment 9 Pat Riehecky 2018-11-21 16:44:24 UTC 
I did a bunch of scratch builds and isolated the issue down to:
0001-linux-Make-platform-device-probe-less-fragile.patch

xorg built without that patch works as expected.
Comment 10 Pat Riehecky 2018-11-21 17:11:13 UTC 
Upstream commit https://gitlab.freedesktop.org/xorg/xserver/commit/0816e8fca6194dfb4cc94c3a7fcb2c7f2a921386

Seems to have the same goals.  A test build with that patch instead of the RHEL7.6 version works as expected.
Comment 12 Arthur Benoit 2019-03-14 11:57:59 UTC 
Note: this is seen on the Lenovo P50 corporate laptops running RHEL-7.6 CSB release.
Comment 16 Bohdan Milar 2019-05-24 14:13:36 UTC 
I only have access to P50 notebooks (my and in lab) with GM107GLM [Quadro M1000M] [10DE:13B1] graphics.

I tried with a fresh installation of RHEL 7.6 (xorg-x11-server-Xorg-1.20.1-3.el7.x86_64) and RHEL 7 CSB (xorg-x11-server-Xorg-1.20.1-6.jx1.el7.x86_64), but I was unable to reproduce the described problem - docked/undocked, with/without external screen - X started every time without problem.

So I am unable to confirm whether the fix solved the original issue.
Comment 18 Pat Riehecky 2019-07-29 15:46:47 UTC 
I believe this might be fixed in https://access.redhat.com/errata/RHBA-2019:1893
Comment 20 errata-xmlrpc 2019-08-06 12:42:44 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2079