Bug 97505 - X11 does not detect nouveau when using the linux kernel EFI Loader (GRUB loader works fine)
Summary: X11 does not detect nouveau when using the linux kernel EFI Loader (GRUB load...
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-27 00:57 UTC by Jeremy Huddleston Sequoia
Modified: 2016-10-16 06:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg for the boot through grub (74.23 KB, text/plain)
2016-08-27 00:58 UTC, Jeremy Huddleston Sequoia
no flags Details
Xorg.0.log for the boot through grub (31.91 KB, text/plain)
2016-08-27 00:58 UTC, Jeremy Huddleston Sequoia
no flags Details
dmesg for the boot through the kernel's EFI boot loader (74.46 KB, text/plain)
2016-08-27 00:59 UTC, Jeremy Huddleston Sequoia
no flags Details
Xorg.0.log for the boot through the kernel's EFI boot loader (9.99 KB, text/plain)
2016-08-27 00:59 UTC, Jeremy Huddleston Sequoia
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Huddleston Sequoia 2016-08-27 00:57:42 UTC
When using the Linux Kernel's EFI Boot Loader stub, X11 1.18.3 fails to start.  Everything works fine when using GRUB as the boot loader.

The kernel is based on 4.4.15 (specifically, Ubuntu's 4.4.0-34 kernel.

Looking at dmesg shows some interesting differences regarding fb, which is why I suspect the device isn't getting automatically detected:


$ egrep '^(nouveau|.*fb).*:' dmesg.notime 
efifb: dmi detected MacBookPro3,1 - framebuffer at 0xc0030000 (1440x900, stride 8192)
efifb: probing for efifb
efifb: framebuffer at 0xc0030000, mapped to 0xffffc90000800000, using 7232k, total 7232k
efifb: mode is 1440x900x32, linelength=8192, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
fb0: EFI VGA frame buffer device
nouveau 0000:01:00.0: enabling device (0002 -> 0003)
fb: switching to nouveaufb from EFI VGA
nouveau 0000:01:00.0: NVIDIA G84 (084700a2)
nouveau 0000:01:00.0: bios: version 60.84.49.03.00
nouveau 0000:01:00.0: fb: 128 MiB GDDR3
nouveau 0000:01:00.0: DRM: VRAM: 128 MiB
nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
nouveau 0000:01:00.0: DRM: TMDS table version 2.0
nouveau 0000:01:00.0: DRM: DCB version 4.0
nouveau 0000:01:00.0: DRM: DCB outp 00: 01000123 00010034
nouveau 0000:01:00.0: DRM: DCB outp 01: 02011210 00000028
nouveau 0000:01:00.0: DRM: DCB outp 02: 02011212 00010030
nouveau 0000:01:00.0: DRM: DCB outp 03: 01011211 0080c070
nouveau 0000:01:00.0: DRM: DCB conn 00: 0040
nouveau 0000:01:00.0: DRM: DCB conn 01: 1120
nouveau 0000:01:00.0: DRM: unknown connector type 20
nouveau 0000:01:00.0: DRM: failed to create encoder 0/1/0: -19
nouveau 0000:01:00.0: DRM: MM: using CRYPT for buffer copies
nouveau 0000:01:00.0: DRM: allocated 1440x900 fb: 0x50000, bo ffff880035b24400
fbcon: nouveaufb (fb0) is primary device
nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device


linux-efi-loader $ egrep '^(nouveau|.*fb).*:' dmesg.notime 
nouveau 0000:01:00.0: enabling device (0002 -> 0003)
nouveau 0000:01:00.0: NVIDIA G84 (084700a2)
nouveau 0000:01:00.0: bios: version 60.84.49.03.00
nouveau 0000:01:00.0: fb: 128 MiB GDDR3
nouveau 0000:01:00.0: DRM: VRAM: 128 MiB
nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
nouveau 0000:01:00.0: DRM: TMDS table version 2.0
nouveau 0000:01:00.0: DRM: DCB version 4.0
nouveau 0000:01:00.0: DRM: DCB outp 00: 01000123 00010034
nouveau 0000:01:00.0: DRM: DCB outp 01: 02011210 00000028
nouveau 0000:01:00.0: DRM: DCB outp 02: 02011212 00010030
nouveau 0000:01:00.0: DRM: DCB outp 03: 01011211 0080c070
nouveau 0000:01:00.0: DRM: DCB conn 00: 0040
nouveau 0000:01:00.0: DRM: DCB conn 01: 1120
nouveau 0000:01:00.0: DRM: unknown connector type 20
nouveau 0000:01:00.0: DRM: failed to create encoder 0/1/0: -19
nouveau 0000:01:00.0: DRM: MM: using CRYPT for buffer copies
nouveau 0000:01:00.0: DRM: allocated 1440x900 fb: 0x50000, bo ffff88007f5d6400
nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device

The differences in the Xorg.0.logs for the failed/working case is essentially some memory address / time / kernel boot arg differences and then the tail hunk:
@@ -174,323 +174,13 @@ nouveau interface version: 1.3.1
 	compiled for 1.18.3, module version = 0.0.2
 	ABI class: X.Org Video Driver, version 20.0
 (WW) Falling back to old probe method for vesa
-(II) Loading sub module "dri2"
-(II) LoadModule: "dri2"
-(II) Module "dri2" already built-in
-(--) NOUVEAU(0): Chipset: "NVIDIA NV84"
-(II) NOUVEAU(0): Creating default Display subsection in Screen section
-	"Default Screen Section" for depth/fbbpp 24/32
... more - for the successful launch
+(EE) No devices detected.
...
Comment 1 Jeremy Huddleston Sequoia 2016-08-27 00:58:40 UTC
Created attachment 126063 [details]
dmesg for the boot through grub
Comment 2 Jeremy Huddleston Sequoia 2016-08-27 00:58:58 UTC
Created attachment 126064 [details]
Xorg.0.log for the boot through grub
Comment 3 Jeremy Huddleston Sequoia 2016-08-27 00:59:28 UTC
Created attachment 126065 [details]
dmesg for the boot through the kernel's EFI boot loader
Comment 4 Jeremy Huddleston Sequoia 2016-08-27 00:59:47 UTC
Created attachment 126066 [details]
Xorg.0.log for the boot through the kernel's EFI boot loader
Comment 5 Jeremy Huddleston Sequoia 2016-10-16 05:51:58 UTC
Any thoughts here?

Any suggestions for additional debugging or more information?
Comment 6 Ilia Mirkin 2016-10-16 06:07:41 UTC
I think the important difference is

[    0.134526] vgaarb: setting as boot device: PCI:0000:01:00.0

without this, X doesn't pick up the device. To be honest, I don't remember the details... it's somewhere deep in X or libdrm. And it only has to do with auto-probing.

It does seem like in your EFI boot's xorg log you have

[   488.713] (--) PCI:*(0:1:0:0) 10de:0407:106b:00a0 rev 161, Mem @ 0xd2000000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00005000/128, BIOS @ 0x????????/131072

Which is a good sign. So ... not sure. I bet adding an xorg.conf that explicitly references the BusID will fix it right up though.


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.