FS#30333 - [linux-3.4.2] non-working inteldrmfb becomes primary device

Attached to Project: Arch Linux
Opened by Daniele C. (legolas558) - Sunday, 17 June 2012, 17:40 GMT
Last edited by Tom Gundersen (tomegun) - Saturday, 23 June 2012, 00:46 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Andreas Radke (AndyRTR)
Tom Gundersen (tomegun)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Screen is completely black, system boots normally but it's impossible to visualize anything even after starting Xorg.

By inspection of kernel log (see below), problem appears related to inteldrmfb becoming the primary device.

Currently, an Arch Linux system (with hardware comparable to mine) with linux-3.4.2 can be booted successfully only by using 'nomodeset'.

Additional info:
* linux-3.4.2 is affected, last good package was linux-3.3.8 (unaffected)

3.4.2 kernel log relevant lines:
--------------------
Jun 17 21:25:21 fester3 kernel: [ 4.966119] ACPI Warning: 0x0000000000007000-0x000000000000701f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20120320/utaddress-251)
Jun 17 21:25:21 fester3 kernel: [ 4.966131] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Jun 17 21:25:21 fester3 kernel: [ 4.979368] [drm] Initialized drm 1.1.0 20060810
Jun 17 21:25:21 fester3 kernel: [ 4.981941] agpgart-intel 0000:00:00.0: Intel HD Graphics Chipset
Jun 17 21:25:21 fester3 kernel: [ 4.982090] agpgart-intel 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable
Jun 17 21:25:21 fester3 kernel: [ 4.982792] agpgart-intel 0000:00:00.0: detected 32768K stolen memory
Jun 17 21:25:21 fester3 kernel: [ 4.982948] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000
Jun 17 21:25:21 fester3 kernel: [ 5.187016] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Jun 17 21:25:21 fester3 kernel: [ 5.187017] [drm] Driver supports precise vblank timestamp query.
Jun 17 21:25:21 fester3 kernel: [ 5.187051] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
Jun 17 21:25:21 fester3 kernel: [ 6.764166] fbcon: inteldrmfb (fb0) is primary device
Jun 17 21:25:21 fester3 kernel: [ 7.630669] Console: switching to colour frame buffer device 160x50
Jun 17 21:25:21 fester3 kernel: [ 7.635935] fb0: inteldrmfb frame buffer device
--------------------

3.3.8 relevant kernel log lines:
--------------------
Jun 17 21:26:59 fester3 kernel: [ 1.173873] Linux agpgart interface v0.103
Jun 17 21:26:59 fester3 kernel: [ 4.604797] agpgart-intel 0000:00:00.0: Intel HD Graphics Chipset
Jun 17 21:26:59 fester3 kernel: [ 4.604894] agpgart-intel 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable
Jun 17 21:26:59 fester3 kernel: [ 4.605576] agpgart-intel 0000:00:00.0: detected 32768K stolen memory
Jun 17 21:26:59 fester3 kernel: [ 4.605732] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000
Jun 17 21:26:59 fester3 kernel: [ 5.654711] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Jun 17 21:26:59 fester3 kernel: [ 5.654712] [drm] No driver support for vblank timestamp query.
Jun 17 21:26:59 fester3 kernel: [ 5.715875] ACPI: Video Device [VID1] (multi-head: yes rom: no post: no)
Jun 17 21:26:59 fester3 kernel: [ 5.715926] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

--------------------

Steps to reproduce:
* upgrade linux package from 3.3.8 to 3.4.2
* reboot
This task depends upon

Closed by  Tom Gundersen (tomegun)
Saturday, 23 June 2012, 00:46 GMT
Reason for closing:  Upstream
Comment by Tom Gundersen (tomegun) - Sunday, 17 June 2012, 19:13 GMT
Setting up fb0 is as expected. It being broken is obviously not. If you want to avoid it you can simply add "i915 options modeset=0" to /etc/modprobe.d/i915.conf, or alternatively put i915.modeset=0 on the kernel commandline.

Probably a good idea to report the broken framebuffer upstream to lkml though, I guess you'd want to use that if it worked?
Comment by Daniele C. (legolas558) - Sunday, 17 June 2012, 21:42 GMT
Thanks Tom, however I disagree that setting up fb0 should be expected. framebuffer drivers are (in)famous for their (in)stability: I have at least another different hardware configuration where the intel framebuffer driver never managed to work properly in years, till I gave up by using exactly that 'i915.modeset=0' line.

Ideally, an Arch Linux upgrade should not enable fb0 if it were not before

I will investigate more on the nature of the framebuffer failure and report back a link to upstream issue; may I suggest having i915.modeset=0 by default?
Comment by Tom Gundersen (tomegun) - Sunday, 17 June 2012, 21:59 GMT
We have been enabling the intel framebuffer support in our kernels for a long time, so this is the intended behavior. For most people this should be the desired configuration.

If you are unlucky enough to have problems with this, I suggest reporting it upstream and possibly using the modeset=0 workaround until it has been fixed.

Loading...