# [SOLVED]gentoo-sources-4.0.3 radeon framebuffer = no display

## Havin_it

Hi,

I did a slew of updates yesterday and have been left with no display on my laptop (pure UEFI ~amd64 system, HP dm1 subnotebook).

The notable updates were gentoo-sources from 4.0 to 4.0.3, and mesa from [whatever it was about a month ago] to 10.5.5. I rebuilt xorg-server and its drivers afterwards, after the problems arose.

After the kernel and mesa updates I rebooted but didn't look at the screen while I did more updating (working over ssh). When I opened the lid this morning I saw a snowstorm (best description - not far off old CRT TV "snow") of graphic artefacts and couldn't VT-switch away.

On next reboot, the screen went black just at the point where it normally "hiccups" (where it switches to radeondrmfb?) and stayed that way.

It does seem to be kernel-related, because my desktop is there if I vnc into it (using libvnc.so xorg module from tigervnc). Booting the machine into gentoo-sources-4.0.0 or Windows (ptui!) is also fine.

I wondered if using distcc for the kernel build could have been the problem, but I did a make clean and rebuilt without it (still using ccache) to no avail.

So, how can I get a bead on this? My kernel config for graphics hasn't changed since probably about linux-3.12 and had been fine up until now. I have only the FB_SIMPLE framebuffer enabled (not FB_RADEON or FB_EFI), and have had AGP support disabled for at least as long (the machine has an APU). Nothing in dmesg has changed, the output looks identical and there are no error messages. Xorg seems perfectly happy too.

I'm currently looking for debug knobs to turn up for more information, but any ideas would be welcome. Thanks in advance!Last edited by Havin_it on Mon May 25, 2015 12:35 pm; edited 1 time in total

----------

## VoidMage

On the off chance, anything potentially interesting in the diff between those two .config files ?

----------

## Havin_it

 *VoidMage wrote:*   

> On the off chance, anything potentially interesting in the diff between those two .config files ?

 

Nothing at all, apart from the debugging options I've just turned on. My kernel upgrade script always just pulls in a copy of the last kernel's .config and runs make oldconfig, so there are usually only any changes on major-version updates.

I might try rebuilding everything tonight with distcc and ccache both disabled. I know I'm not doing any of the usual silly things that make them problematic at times, but you never know.

----------

## Havin_it

I diffed the dmesg from booting the two kernels. Not much jumping out at me there either, apart from different gcc versions used to build the kernel:

```
4,5c4,5

<  Linux version 4.0.0-gentoo (root@happy) (gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) ) #1 SMP Fri Apr 17 17:01:06 BST 2015

<  Command line: BOOT_IMAGE=/boot/kernel-4.0.0-gentoo root=/dev/sda7 ro raid=noautodetect rootfstype=ext4 radeon.audio=1 radeon.dpm=1

---

>  Linux version 4.0.3-gentoo (root@happy) (gcc version 4.9.2 (Gentoo 4.9.2 p1.3, pie-0.6.2) ) #3 SMP Wed May 20 14:05:06 BST 2015

>  Command line: BOOT_IMAGE=/boot/kernel-4.0.3-gentoo root=/dev/sda7 ro raid=noautodetect rootfstype=ext4 radeon.audio=1 radeon.dpm=1

```

Here's the diff from where the GPU is initialised:

```
917,918c911,912

<  radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000018000c00 and cpu addr 0xffff8800dddccc00

<  radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000018000c0c and cpu addr 0xffff8800dddccc0c

---

>  radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000018000c00 and cpu addr 0xffff8800dd023c00

>  radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000018000c0c and cpu addr 0xffff8800dd023c0c

925d918

<  r8169 0000:06:00.0 eno1: renamed from eth0

927c920

<  ring test on 3 succeeded in 3 usecs

---

>  ring test on 3 succeeded in 2 usecs

932,952c925

<  ib test on ring 5 succeeded

<  input: HP WMI hotkeys as /devices/virtual/input/input10

<  radeon atom DIG backlight initialized

<  Radeon Display Connectors

<  Connector 0:

<    LVDS-1

<    HPD1

<    DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c

<    Encoders:

<      LCD1: INTERNAL_UNIPHY

<  Connector 1:

<    HDMI-A-1

<    HPD2

<    DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c

<    Encoders:

<      DFP1: INTERNAL_UNIPHY

<  Connector 2:

<    VGA-1

<    DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4 0x64e4

<    Encoders:

<      CRT1: INTERNAL_KLDSCP_DAC1

---

>  r8169 0000:06:00.0 eno1: renamed from eth0

985,990c958,977

<  rt2800pci 0000:02:00.0 wlo1: renamed from wlan0

<  usbcore: registered new interface driver uas

<  ums-realtek 3-4:1.0: USB Mass Storage device detected

<  usb 3-4: USB disconnect, device number 2

<  scsi host1: usb-storage 3-4:1.0

<  usbcore: registered new interface driver ums-realtek

---

>  ib test on ring 5 succeeded

>  radeon atom DIG backlight initialized

>  Radeon Display Connectors

>  Connector 0:

>    LVDS-1

>    HPD1

>    DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c

>    Encoders:

>      LCD1: INTERNAL_UNIPHY

>  Connector 1:

>    HDMI-A-1

>    HPD2

>    DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c

>    Encoders:

>      DFP1: INTERNAL_UNIPHY

>  Connector 2:

>    VGA-1

>    DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4 0x64e4

>    Encoders:

>      CRT1: INTERNAL_KLDSCP_DAC1

```

Not seeing any significant differences there either.

----------

## Havin_it

Just to fill in the blanks, <=4.0.2-gentoo are also OK, so 4.0.3 is where the problem first arises (or I'm still doing something silly with the builds).

Time for some bisectin' fun...

UPDATE: Whew, someone did it for me. Reversing the commit named there restores the screen.

----------

## skwang

 *Havin_it wrote:*   

> Just to fill in the blanks, <=4.0.2-gentoo are also OK, so 4.0.3 is where the problem first arises (or I'm still doing something silly with the builds).
> 
> Time for some bisectin' fun...
> 
> UPDATE: Whew, someone did it for me. Reversing the commit named there restores the screen.

 

@Havin_it

I think I just ran into the same problem, but with different "numbers". I had gentoo-sources 4.0.5 running on my laptop. I believe the hardware is a Radeon mobility X1400. Then I updated the kernel to 4.1.12. In the new kernel, after booting the screen goes blank after the radeon frame-buffer is suppose to take over[1].

My question is, has this been fixed or did you hack the kernel? What exactly was your solution? Thanks in advance.

[1] Interestingly for me, I thought the screen was blank, but upon a very close inspection I could see that it was in fact very very dim, so dim that I could only barely make out the KDE login splash screen.

----------

## Havin_it

Hi skwang,

It's been a while but if memory serves I patched the 4.0.3 kernel by reversing the commit in my link above (it's a pretty small edit), and then it was reverted/fixed in mainline for the next version.

Funny you should bring this up now as I'm having issues again at the moment. Symptoms are SDDM being very unresponsive and login never completing or ending in a black screen (with cursor). I mention this because it actually seems to be the radeon xorg driver that's to blame: xf86-video-ati-7.6.1 is bad, 7.5.0 is okay. Maybe worth checking on?

----------

## skwang

 *Havin_it wrote:*   

> Hi skwang,
> 
> It's been a while but if memory serves I patched the 4.0.3 kernel by reversing the commit in my link above (it's a pretty small edit), and then it was reverted/fixed in mainline for the next version.
> 
> Funny you should bring this up now as I'm having issues again at the moment. Symptoms are SDDM being very unresponsive and login never completing or ending in a black screen (with cursor). I mention this because it actually seems to be the radeon xorg driver that's to blame: xf86-video-ati-7.6.1 is bad, 7.5.0 is okay. Maybe worth checking on?

 

Thanks for the information. If what your saying is correct, the patch you speak of should be in BOTH versions of the kernel I have: 4.0.5 and 4.1.12. This makes diagnosing the problem very confusing.

Update: Just in case someone finds this thread. I managed to "solve" my problem by upgrading to gentoo-sources 4.2.6. Whatever changes in the kernel resulted in my laptop booting normally with a functioning framebuffer.

----------

