Bug 1050437

Summary: boot hangs during/after the drm radeon kernel modesetting.
Product: [Fedora] Fedora Reporter: Didier Lecardez <d.lecardez>
Component: xorg-x11-drv-atiAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 22CC: xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 18:59:47 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
dmesg of a normal boot
none
Xorg.0.log of a normal boot none

Description Didier Lecardez 2014-01-08 22:34:50 UTC
Created attachment 847359 [details]
dmesg of a normal boot

Description of problem:

Laptop hp dv6 with ATI Mobility Radeon HD 5000 Series

Kernels: 3.11.10-301.fc20 
         3.12.6-300.fc20

The boot process stops during/after the drm radeon kernel modesetting.
This happens 70/80% of the time.

The latest lines I see on the screen are:
[ OK ] Started Setup Virtual Console
[ OK ] Started udev Coldplug all devices.
       Starting dracut initqueue hook ...
       Starting Show Plymouth Boot Screen ...
[ OK ] Reached target System Initialization
[ 10.274487 ] usb 1-1.3: new full-speed USB device number 4  using ehci-pci
[ 10.342903 ] [drm] Initialized drm 1.1.0 20060810

At this point it hangs forever.
Unfortunately, at this stage there is no info in /var/log/messages that can be viewed at next successful reboot.

Nevertheless, a dmesg of a no hang boot shows:

[    5.901806] tsc: Refined TSC clocksource calibration: 1596.095 MHz
[    5.922427] usb 2-1: New USB device found, idVendor=8087, idProduct=0020
[    5.922652] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    5.923342] hub 2-1:1.0: USB hub found
[    5.923637] hub 2-1:1.0: 8 ports detected
[    5.999166] usb 1-1.2: new high-speed USB device number 3 using ehci-pci
[    6.047922] [drm] Initialized drm 1.1.0 20060810
[    6.084233] usb 1-1.2: New USB device found, idVendor=0409, idProduct=005a
[    6.084453] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    6.085176] hub 1-1.2:1.0: USB hub found
[    6.085483] hub 1-1.2:1.0: 4 ports detected
<----------------  if the system hangs, it is at this point ------------->
[    6.112607] [drm] radeon kernel modesetting enabled.
[    6.112904] pcieport 0000:00:03.0: driver skip pci_set_master, fix it!
[    6.113306] [drm] initializing kernel modesetting (REDWOOD 0x1002:0x68C1 0x103C:0x1448).
[    6.113647] [drm] register mmio base: 0xD4000000
[    6.113847] [drm] register mmio size: 131072
[    6.114156] ATOM BIOS: MADISON
                         .......
                         .......     

The problem already started with latest Fedora 19 kernels:
 With: 3.9.5-301.fc19  --> Never got any boot problems.
 If I remember, problem started with version  3.10.x.x.
 With: 3.12.5-200.fc19 Exactly the same problem than with Fedora 20

If 'nomodeset' is used the problem disappears. But I cannot use an external monitor.


Steps to Reproduce:
1- boot with a kernel > 3.9.x with an ATI Mobility Radeon HD 5000 Series 
 
Actual results:
Boot hangs 70/80% of the time just after screen message "[drm] Initialized drm"

Expected results:
No boot hang as with 3.9.x.x kernel

Comment 1 Didier Lecardez 2014-01-08 22:38:03 UTC
Created attachment 847370 [details]
Xorg.0.log of a normal boot

Comment 2 Didier Lecardez 2014-01-24 09:37:03 UTC
Hello,

I see no activity with this case since it has been opened.
Can you at least confirm if xorg-x11-drv-ati is the correct place.

Regards,

Didier

Comment 3 Fedora End Of Life 2015-05-29 10:23:59 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Didier Lecardez 2015-05-29 10:44:19 UTC
I keep this bug open because I've just installed Fedora 22 and I still have the same problem. The problem description was for FC19/20/21 but still applies for fc22. The only difference is that this occurs with 100% boots.

I do not need a fix for  Fc20/21. A Fc22 fix will be very appreciated as I
have no other choice to stay in Fc19 because of this bug.

Comment 5 Fedora End Of Life 2016-07-19 18:59:47 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.