Bug 1650634 - FBDEV(1): FBIOPUTCMAP and xorg fails to load
Summary: FBDEV(1): FBIOPUTCMAP and xorg fails to load
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xorg-x11-server
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Adam Jackson
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-16 16:55 UTC by Pat Riehecky
Modified: 2019-06-12 11:05 UTC (History)
16 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)
Xorg log of failed session (42.46 KB, text/plain)
2018-11-16 16:55 UTC, Pat Riehecky
no flags Details
Xorg log of successful session after yum downgrade (88.83 KB, text/plain)
2018-11-16 16:56 UTC, Pat Riehecky
no flags Details
anaconda log-capture (100.62 KB, application/x-bzip)
2018-11-19 18:31 UTC, Pat Riehecky
no flags Details

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 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 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.


Note You need to log in before you can comment on or make changes to this bug.