Bug 845745 - kernel version 3.5.0-2 hangs at boot with modesetting: "conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver"
kernel version 3.5.0-2 hangs at boot with modesetting: "conflicting fb hw us...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
19
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
:
: 845631 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-04 09:18 EDT by Lyonel Vincent
Modified: 2015-06-27 05:44 EDT (History)
39 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-06 13:06:59 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
photograph of the boot screen (removed quiet and rhgb) (2.05 MB, image/jpeg)
2012-08-04 09:18 EDT, Lyonel Vincent
no flags Details
Screenshot of where boot process halted wit 3.5.4-1.fc17.x86_64 kernel (493.08 KB, image/png)
2012-09-22 05:23 EDT, E.Patton
no flags Details
can't boot... (1.95 MB, image/jpeg)
2012-09-22 16:02 EDT, dobs
no flags Details
3.6.11-1.fc17.x86_64 (1.11 MB, image/jpeg)
2013-01-06 09:12 EST, dobs
no flags Details
3.7.2-204.fc18.x86_64 (66.27 KB, image/png)
2013-01-20 08:20 EST, dobs
no flags Details
ati rv515 fix by reverting pci bus mastering commit (3.04 KB, patch)
2013-05-14 19:02 EDT, Vladimir Brkic
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 843826 None None None 2012-08-04 09:18:01 EDT

  None (edit)
Description Lyonel Vincent 2012-08-04 09:18:01 EDT
Created attachment 602246 [details]
photograph of the boot screen (removed quiet and rhgb)

Description of problem:
the system hangs during boot

Version-Release number of selected component (if applicable):
kernel 3.5.0-2 of x86_64 F17

How reproducible:
every time

Steps to Reproduce:
1. update to kernel 3.5.0-2
2. boot
3.
  
Actual results:
system frozen with error message
"conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver"


Expected results:
system booting


Additional info:
similar to bug #843826
Comment 1 Peter Bieringer 2012-08-05 09:19:08 EDT
This problem hits me also, extension of "linux" line in grub2.cfg with kernel option "nomodeset" is a workaround.
Comment 2 Josh Boyer 2012-08-05 10:30:42 EDT
Do any of you see this "conflicting fb hw.." message in dmesg for 3.4 boots?
Comment 3 Peter Bieringer 2012-08-05 11:10:54 EDT
I had already this workaround active since longer time already, probably since installing F17 and hoped that this is gone with 3.5...but it isn't.
Comment 4 Lyonel Vincent 2012-08-05 12:33:00 EDT
the same error message shows up with 3.4.6-2.fc17.x86_64 but without hanging:

[    1.361722] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
[    1.410046] usb 3-1: new full-speed USB device number 2 using uhci_hcd
[    1.415146] Console: switching to colour dummy device 80x25
[    1.416169] [drm] initializing kernel modesetting (RV515 0x1002:0x7188 0x103C:0x30C1).
[    1.416194] [drm] register mmio base: 0xD8400000
[    1.416196] [drm] register mmio size: 65536
[    1.416335] ATOM BIOS: M64S
[    1.416353] [drm] Generation 2 PCI interface, using max accessible memory
[    1.416359] radeon 0000:01:00.0: VRAM: 128M 0x0000000000000000 - 0x0000000007FFFFFF (128M used)
[    1.416362] radeon 0000:01:00.0: GTT: 512M 0x0000000008000000 - 0x0000000027FFFFFF
[    1.416391] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    1.416393] [drm] Driver supports precise vblank timestamp query.
[    1.416406] [drm] radeon: irq initialized.
[    1.418277] [drm] Detected VRAM RAM=128M, BAR=64M
[    1.418281] [drm] RAM width 64bits DDR
[    1.418355] [TTM] Zone  kernel: Available graphics memory: 1025852 kiB
[    1.418358] [TTM] Initializing pool allocator
[    1.418363] [TTM] Initializing DMA pool allocator
[    1.418391] [drm] radeon: 128M of VRAM memory ready
[    1.418393] [drm] radeon: 512M of GTT memory ready.
[    1.418418] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    1.419345] [drm] radeon: ib pool ready.
[    1.420435] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[    1.421391] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[    1.421418] radeon 0000:01:00.0: WB enabled
[    1.421422] [drm] fence driver on ring 0 use gpu addr 0x08000000 and cpu addr 0xffff880036428000
[    1.421854] [drm] Loading R500 Microcode
[    1.422630] [drm] radeon: ring at 0x0000000008001000
[    1.422663] [drm] ring test succeeded in 9 usecs
[    1.422897] [drm] ib test succeeded in 0 usecs
[    1.423580] [drm] Radeon Display Connectors
[    1.423583] [drm] Connector 0:
[    1.423584] [drm]   VGA
[    1.423587] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[    1.423589] [drm]   Encoders:
[    1.423590] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    1.423592] [drm] Connector 1:
[    1.423593] [drm]   LVDS
[    1.423595] [drm]   DDC: 0xc54 0xc54 0xc58 0xc58 0xc5c 0xc5c 0xc60 0xc60
[    1.423597] [drm]   Encoders:
[    1.423598] [drm]     LCD1: INTERNAL_LVTM1
[    1.423600] [drm] Connector 2:
[    1.423602] [drm]   S-video
[    1.423603] [drm]   Encoders:
[    1.423604] [drm]     TV1: INTERNAL_KLDSCP_DAC2
[    1.423606] [drm] Connector 3:
[    1.423607] [drm]   DVI-I
[    1.423609] [drm]   HPD1
[    1.423611] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[    1.423612] [drm]   Encoders:
[    1.423614] [drm]     DFP1: INTERNAL_KLDSCP_TMDS1
[    1.423621] [drm] Possible lm63 thermal controller at 0x4c
[    1.423705] [drm] radeon: power management initialized
Comment 5 Lyonel Vincent 2012-08-11 08:09:12 EDT
same problem with 3.5.1-1.fc17
Comment 6 Lyonel Vincent 2012-08-11 08:12:49 EDT
I'm pretty sure it has nothing to do with X11 (it isn't even configured to start X11)
Comment 7 Dave Jones 2012-08-14 14:01:29 EDT
graphics bugs get filed against the X driver, even if they are kernel, as there's no way to sub-categorise kernel bugs by driver easily.
Comment 8 Dave Jones 2012-08-14 14:01:51 EDT
*** Bug 845631 has been marked as a duplicate of this bug. ***
Comment 9 D S 2012-08-14 14:33:16 EDT
There may be useful information contained in 845388 and 845631 concerning this bug. (There may be other related bugs.)

I have this same issue on my Acer Ferrari 4006 (I included output from dmesg output from FC17 3.4 on Acer Ferrari 4006 and sudo lspci -vvnn output from Acer Ferrari 4006 to bug 845388 (links below)

https://bugzilla.redhat.com/attachment.cgi?id=604055
https://bugzilla.redhat.com/attachment.cgi?id=604056

I'm a business user not a Fedora guru. I'm happy to help, but I ask that you give me instructions in layman's terms.
Comment 10 Timothy Davis 2012-08-16 11:12:20 EDT
(In reply to comment #5)
> same problem with 3.5.1-1.fc17
Same problem, Compaq 6910p laptop, X2300 video
Comment 11 Harald Reindl 2012-08-16 17:52:35 EDT
and here the first bugreport for this problem directly after koji-build was finsihed why i do not undrstand stop buil 3.4.x kernels and push 3.5.x to stable updates

https://bugzilla.redhat.com/show_bug.cgi?id=843826
Comment 12 Daniele Viganò 2012-08-22 03:22:24 EDT
I can confirm the bug on my Samsung NP305U1A (AMD E-450).

Fedora 17 with kernel 3.5.2-1.fc17.x86_64. Sometimes it works (randomly).
No problems at all with 3.4.x kernels.
Comment 13 Noman Khanzada 2012-08-23 03:59:51 EDT

I am also facing problem with kernel 3.5.2-3.fc17.i686, that freeze up and not do anything. My laptop not boot
Comment 14 Noman Khanzada 2012-08-23 06:50:01 EDT
my hardware detail

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     T6400  @ 2.00GHz
stepping	: 10
microcode	: 0xa07
cpu MHz		: 1200.000
cache size	: 2048 KB
Comment 15 Noman Khanzada 2012-08-23 06:54:52 EDT
    product: Inspiron 1545 ()
    vendor: Dell Inc.
Comment 16 Timothy Davis 2012-09-05 13:14:12 EDT
3.5.3 kernel, same problem: "conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver"
and my laptop freezes after that
Comment 17 Lyonel Vincent 2012-09-05 13:24:30 EDT
same problem with 3.5.3
Comment 18 Richard Gration 2012-09-05 22:52:38 EDT
Confirmed that the same problem exists with 3.5.3 using a HP/Compaq NC6400, which has Mobility Radeon X1300 graphics hardware. Worked fine will the 3.4 kernels but has never booted successfully with the 3.5 kernels unless I add a 'nomodeset' to the boot parameters. It then boots OK into the X environment, but the graphics resolution is poor.
Comment 19 D S 2012-09-07 12:45:11 EDT
Is there a workaround for this problem (using FC17 3.5)?

bug 845388 suggests "nomodeset" and use the VESA driver - doing so is intolerably slow on my laptop (Ferrari 4006)

bug 845631  Priority: 	unspecified Severity: urgent says it's a duplicate of this bug (845745) and says "nomodeset" is the only way 3.5 will boot for those affected (are there really just a few of us?)

So far it appears the most of us continue to use FC17 3.4 - Is this issue addressed in FC18?
Comment 20 Timothy Davis 2012-09-07 12:54:42 EDT
(In reply to comment #19)
> Is there a workaround for this problem (using FC17 3.5)?
> 
> bug 845388 suggests "nomodeset" and use the VESA driver - doing so is
> intolerably slow on my laptop (Ferrari 4006)
> 
> bug 845631  Priority: 	unspecified Severity: urgent says it's a duplicate of
> this bug (845745) and says "nomodeset" is the only way 3.5 will boot for
> those affected (are there really just a few of us?)
> 
> So far it appears the most of us continue to use FC17 3.4 - Is this issue
> addressed in FC18?

It's still there in FC18, my laptop has been stuck on 3.4.6 kernel. (ATI X2300 GPU)
Comment 21 Josh Boyer 2012-09-07 15:54:19 EDT
We've been unable to recreate the issue locally.  If someone wants to be very helpful and bisect when this was introduced in the 3.5 development window, we would be very appreciative.
Comment 22 Timothy Davis 2012-09-07 16:02:46 EDT
(In reply to comment #21)
> We've been unable to recreate the issue locally.  If someone wants to be
> very helpful and bisect when this was introduced in the 3.5 development
> window, we would be very appreciative.

When the first 3.5 kernel was introduced in Fedora 17
I'll be glad to help with any debugging including installing any kernel needed.
Comment 23 Josh Boyer 2012-09-07 16:38:18 EDT
Koji has all of the 3.5 development kernels built.  They were built in fc18, but that shouldn't really matter.  Below are the major RC points:

http://koji.fedoraproject.org/koji/buildinfo?buildID=330762 RC7
http://koji.fedoraproject.org/koji/buildinfo?buildID=329593 RC6
http://koji.fedoraproject.org/koji/buildinfo?buildID=328776 RC5
http://koji.fedoraproject.org/koji/buildinfo?buildID=327500 RC4
http://koji.fedoraproject.org/koji/buildinfo?buildID=326041 RC3
http://koji.fedoraproject.org/koji/buildinfo?buildID=323266 RC2
http://koji.fedoraproject.org/koji/buildinfo?buildID=321702 RC1

we also have a bunch of rc0.gitX kernels as well that we can use.  If we're lucky, an older RCX still works and a newer one breaks.  If so, it was introduced between those RCs and we have a narrower window of commits to look at.  If we aren't lucky, it's broken in RC1 and we need to delve into the rc0.gitX builds.

If someone wants to try these and report the first one that works and the first one that breaks, that would be helpful.
Comment 24 E.Patton 2012-09-07 17:32:09 EDT
Breaks with RC1 on a Compaq 6910p.

(01:00.0 VGA compatible controller: ATI Technologies Inc M64-S [Mobility Radeon X2300])

I'm willing to try earlier builds if you point me to them.
Comment 25 E.Patton 2012-09-07 19:04:27 EDT
For completeness, I tested the remaining RC kernels (all x86_64) and they all exhibited the same failure (as detailed in the original comment).
Comment 26 Timothy Davis 2012-09-07 23:32:14 EDT
Compaq 6910p with ATI IGP X2300 
Tried kernel vmlinuz-3.5.0-0.rc0.git12.1.fc18.x86_64 -- same thing, boot freezes
but kernel vmlinuz-3.5.0-0.rc0.git3.1.fc18.x86_64 works
Somewhere between rc0 git12 and rc0 git3 it broke
Running Fedora 17
Comment 27 Josh Boyer 2012-09-10 09:43:17 EDT
(In reply to comment #26)
> Compaq 6910p with ATI IGP X2300 
> Tried kernel vmlinuz-3.5.0-0.rc0.git12.1.fc18.x86_64 -- same thing, boot
> freezes
> but kernel vmlinuz-3.5.0-0.rc0.git3.1.fc18.x86_64 works
> Somewhere between rc0 git12 and rc0 git3 it broke
> Running Fedora 17

That's great to know.  Is there any chance you can try rc0.git4..rc0.git11?  There are ~7446 commits between rc0.git3 and rc0.git12.  Narrowing down the window as much as possible is going to help.
Comment 28 Timothy Davis 2012-09-10 09:56:09 EDT
(In reply to comment #27)
> (In reply to comment #26)
> > Compaq 6910p with ATI IGP X2300 
> > Tried kernel vmlinuz-3.5.0-0.rc0.git12.1.fc18.x86_64 -- same thing, boot
> > freezes
> > but kernel vmlinuz-3.5.0-0.rc0.git3.1.fc18.x86_64 works
> > Somewhere between rc0 git12 and rc0 git3 it broke
> > Running Fedora 17
> 
> That's great to know.  Is there any chance you can try rc0.git4..rc0.git11? 
> There are ~7446 commits between rc0.git3 and rc0.git12.  Narrowing down the
> window as much as possible is going to help.

Send me a link and I'll try them all, hard time sifting through koji
Comment 30 Timothy Davis 2012-09-10 10:40:28 EDT
(In reply to comment #28)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > Compaq 6910p with ATI IGP X2300 
> > > Tried kernel vmlinuz-3.5.0-0.rc0.git12.1.fc18.x86_64 -- same thing, boot
> > > freezes
> > > but kernel vmlinuz-3.5.0-0.rc0.git3.1.fc18.x86_64 works
> > > Somewhere between rc0 git12 and rc0 git3 it broke
> > > Running Fedora 17
> > 
> > That's great to know.  Is there any chance you can try rc0.git4..rc0.git11? 
> > There are ~7446 commits between rc0.git3 and rc0.git12.  Narrowing down the
> > window as much as possible is going to help.
> 
> Send me a link and I'll try them all, hard time sifting through koji

Nevermind, 3.5.0-0.rc0.git6 works while 3.5.0-0.rc0.git7 doesn't, same message:
fb:conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
Comment 31 E.Patton 2012-09-10 10:56:28 EDT
(In reply to comment #30)

> Nevermind, 3.5.0-0.rc0.git6 works while 3.5.0-0.rc0.git7 doesn't, same
> message:
> fb:conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
Confirmed. 
Same result here Same hardware).
Comment 32 Dave Jones 2012-09-10 11:24:13 EDT
ok, that narrows it down, but unfortunately not enough.
We now know that the bug is somewhere between commits 56edab3 (good) and f936991 (bad). That's a big delta, including (unsurprisingly) the DRM merge for 3.5

We're going to need someone who can reproduce this to hand-build an upstream kernel and do a git-bisect on this. It's quite an involved process..

First do this..
git clone git://git.kernel.org/pub/scm/linux
cd linux
git bisect start
git bisect good 56edab3
git bisect bad f936991

Now you're to do a loop where you decide if a kernel is good/bad.

1. cp /boot/config-$(uname -r) .config
2. make
(you may be asked some questions, just take the default answers and hit return)
3. eventually the build should complete. At this point, su to root, and do..
make modules_install
make install
4. Now, reboot, and choose the kernel that just got built.
Make a note if it boots or not. If it doesn't, boot back into a known-good kernel.
5. cd back into where the kernel source was, and type either 'git bisect good' or 'git bisect bad' depending on whether the test kernel booted.

6. Go back to (1) and keep doing this until eventually git bisect will tell you something like 'First bad commit is...'


Any volunteers?
Comment 33 Dave Jones 2012-09-10 11:33:01 EDT
the git clone command should have been..

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
Comment 34 Joshua Roys 2012-09-10 12:28:41 EDT
Hello all,

I happened to mention this bug in FreeNode/#radeon, and Alex Deucher (agd5f) mentioned this:

<agd5f> autonymous, roysjosh: I think this patch should fix that bug: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d8636a2717bb3da2a7ce2154bf08de90bb8c87b0
Comment 35 Josh Boyer 2012-09-10 13:27:54 EDT
(In reply to comment #34)
> Hello all,
> 
> I happened to mention this bug in FreeNode/#radeon, and Alex Deucher (agd5f)
> mentioned this:
> 
> <agd5f> autonymous, roysjosh: I think this patch should fix that bug:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;
> h=d8636a2717bb3da2a7ce2154bf08de90bb8c87b0

Fedora is already carrying that patch.  It was added in 3.5.2-2, and we have had a number of reports that it still hits with 3.5.3
Comment 36 Noman Khanzada 2012-09-10 13:44:29 EDT
I am sad, all my efforts fail. Latest kernel is not working freezeup the screen.
Comment 37 E.Patton 2012-09-10 14:04:51 EDT
(In reply to comment #32)

> Any volunteers?
I'll bite.

Just compiling the first kernel. 

I can spend the rest of this evening on this (~4hrs) so I hope we have an answer before then.
Comment 38 Timothy Davis 2012-09-10 14:06:36 EDT
(In reply to comment #37)
> (In reply to comment #32)
> 
> > Any volunteers?
> I'll bite.
> 
> Just compiling the first kernel. 
> 
> I can spend the rest of this evening on this (~4hrs) so I hope we have an
> answer before then.

Already biting it ;D
Comment 39 E.Patton 2012-09-11 07:58:26 EDT
Slightly nervous about this result as none of the kernels that I built failed. 

Anyway,

"f9369910a6225b8d4892c3f20ae740a711cd5ace is the first bad commit"
Comment 40 Timothy Davis 2012-09-11 08:20:08 EDT
(In reply to comment #39)
> Slightly nervous about this result as none of the kernels that I built
> failed. 
> 
> Anyway,
> 
> "f9369910a6225b8d4892c3f20ae740a711cd5ace is the first bad commit"

Darn, I didn't a chance to finish.
Comment 41 E.Patton 2012-09-11 08:26:50 EDT
(In reply to comment #40)
> Darn, I didn't a chance to finish.
I think it would be valuable for you to confirm the result. 

As I noted, I wasn't quite convinced that I had managed to do everything properly.
Comment 42 Dave Jones 2012-09-11 10:03:41 EDT
(In reply to comment #39)
> Slightly nervous about this result as none of the kernels that I built
> failed. 
> 
> Anyway,
> 
> "f9369910a6225b8d4892c3f20ae740a711cd5ace is the first bad commit"

Yeah, that's just a merge commit which isn't particularly helpful. Ugh.

Hopefully Timothy's bisect will lead to something more concrete.

Thanks for trying anyway.
Comment 43 Timothy Davis 2012-09-12 13:51:55 EDT
Same results
Comment 44 Justin M. Forbes 2012-09-21 11:37:45 EDT
Does this kernel help things at all?:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4509129
Comment 45 Vladimir Brkic 2012-09-21 13:43:34 EDT
(In reply to comment #44)
> Does this kernel help things at all?:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4509129

Nope. Stuck at same place.
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
Comment 46 E.Patton 2012-09-22 05:23:35 EDT
Created attachment 615719 [details]
Screenshot of where boot process halted wit 3.5.4-1.fc17.x86_64 kernel

Just tried with the 3.5.4-1.fc17.x86_64 kernel that was pushed this morning. Still hangs around the same area but with a slightly different message.
Comment 47 dobs 2012-09-22 16:02:24 EDT
Created attachment 615904 [details]
can't boot...

+1
Last work kernel 3.5.4-1.fc17.x86_64
Comment 48 Seppo Yli-Olli 2012-09-29 16:02:23 EDT
As far as I've found out, the message seems to be about Grub2 graphics driver being attempted to be unloaded by kernel. You can set GRUB_TERMINAL in /etc/defaults/grub according to http://www.gnu.org/software/grub/manual/grub.html#Simple-configuration (for me it was console) to get rid of the message but it still hangs on boot.
Comment 49 Seppo Yli-Olli 2012-09-29 16:20:47 EDT
Additionally when I was talking about this on #radeon, Alex Deucher mentioned this http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d8636a2717bb3da2a7ce2154bf08de90bb8c87b0 Different driver, identical end result description
Comment 50 Harald Reindl 2012-09-29 16:24:26 EDT
this is NOT a radeon problem 

you will find the same crap with all sort of graphics divers
as long modeset is used starting with 3.5.x

https://bugzilla.redhat.com/show_bug.cgi?id=843826

so this is CLEARLY a kernel regression
Comment 51 Steve Tyler 2012-09-29 16:49:39 EDT
(In reply to comment #48)
> As far as I've found out, the message seems to be about Grub2 graphics
> driver being attempted to be unloaded by kernel. You can set GRUB_TERMINAL
> in /etc/defaults/grub according to
> http://www.gnu.org/software/grub/manual/grub.html#Simple-configuration (for
> me it was console) to get rid of the message but it still hangs on boot.

Thanks for your report. For the record, could you confirm that you ran:
# grub2-mkconfig -o /boot/grub2/grub.cfg
after modifying /etc/defaults/grub?

When it hangs on boot, what does your display show? How do you recover?
Comment 52 Seppo Yli-Olli 2012-09-30 06:27:44 EDT
(In reply to comment #50)
> this is NOT a radeon problem 
> 
> you will find the same crap with all sort of graphics divers
> as long modeset is used starting with 3.5.x
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=843826
> 
> so this is CLEARLY a kernel regression
Yes, it is a kernel regression and more generic than radeon. (as in radeon kernel driver; the component xorg-x11-drv-ati was wrong in the first place) It just appears there might be two different kernel regressions. One which is making console not being printed on boot that hides the errors from the thing that is actually making the kernel hang and then the thing that is making the kernel hang.
(In reply to comment #51)
> (In reply to comment #48)
> > As far as I've found out, the message seems to be about Grub2 graphics
> > driver being attempted to be unloaded by kernel. You can set GRUB_TERMINAL
> > in /etc/defaults/grub according to
> > http://www.gnu.org/software/grub/manual/grub.html#Simple-configuration (for
> > me it was console) to get rid of the message but it still hangs on boot.
> 
> Thanks for your report. For the record, could you confirm that you ran:
> # grub2-mkconfig -o /boot/grub2/grub.cfg
> after modifying /etc/defaults/grub?
> 
> When it hangs on boot, what does your display show? How do you recover?
It is excessively easy to verify this without even booting. The lines
"if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
"get replaced by lines
"terminal_input console
terminal_output console" if you put the stanza in /etc/defaults/grub and run grub2-mkconfig.
Last thing in kernel config was the same as in working kernel's dmesg
radeon 0000:01:00.0: radeon: using MSI. It is possible that fbcon is being annoying (and keeping console locked) and we're not seeing the real error under modesetting because of that. So the first thing we need honestly is to make sure fbcon isn't hiding errors.
Only way to recover here is hard poweroff (since keyboard becomes unresponsive when hitting the kernel lockup) and reboot into 3.4.6-2 which I've kept because of this issue.
Comment 53 Seppo Yli-Olli 2012-09-30 06:32:36 EDT
Sorry for the spam but also verifying here that Fedora 17 updates-testing kernel 3.5.4-2.fc17.i686 does *not* fix this issue.
Comment 54 Peter Bieringer 2012-09-30 07:49:12 EDT
(In reply to comment #3)
> I had already this workaround active since longer time already, probably
> since installing F17 and hoped that this is gone with 3.5...but it isn't.

Just as an update from my system: I've got only hit now only sometimes by this bug using latest 3.5.x kernels, a CTRL-ALT-DEL still works and afterwards system boots fine...so in my case it turned from a persistent problem to a sporadic one.
Comment 55 Steve Tyler 2012-09-30 12:24:41 EDT
Thanks, Seppo and Peter -- your reports prompted me to reenable gfxterm to see what happens ... :-)

In about a dozen trials, I had one boot-hang with the "fb: conflicting ..." message. The keyboard was responsive (caps-lock and num-lock controlled their respective keyboard lights). Rebooting with ctrl-alt-del succeeded.

Linux walnut 3.5.4-2.fc17.x86_64 #1 SMP Wed Sep 26 21:58:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
xorg-x11-drv-ati-6.14.4-6.20120602git930760942.fc17.x86_64
grub2-2.0-0.38.beta6.fc17.x86_64

$ sudo grep terminal_output /boot/grub2/grub.cfg
terminal_output gfxterm

$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
#GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm.lv=vg_neptune/lv_walnut_root rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8"
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm.lv=vg_neptune/lv_walnut_root rd.dm=0  KEYTABLE=us SYSFONT=latarcyrheb-sun16 rd.luks=0 LANG=en_US.UTF-8"
#GRUB_TERMINAL_OUTPUT="console"
Comment 56 Steve Tyler 2012-09-30 13:18:44 EDT
(In reply to comment #52)
...
> Last thing in kernel config was the same as in working kernel's dmesg
> radeon 0000:01:00.0: radeon: using MSI. It is possible that fbcon is being
> annoying (and keeping console locked) and we're not seeing the real error
> under modesetting because of that. So the first thing we need honestly is to
> make sure fbcon isn't hiding errors.
> Only way to recover here is hard poweroff (since keyboard becomes
> unresponsive when hitting the kernel lockup) and reboot into 3.4.6-2 which
> I've kept because of this issue.

Thanks for the additional details. How often do you see the boot-hang with kernel 3.5.4-2?

> radeon 0000:01:00.0: radeon: using MSI.

That message does not occur on my system:

$ dmesg | egrep 'MSI|radeon|Kernel'
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.5.4-2.fc17.x86_64 root=/dev/mapper/vg_neptune-lv_walnut_root ro rd.md=0 rd.lvm.lv=vg_neptune/lv_walnut_root rd.dm=0 KEYTABLE=us SYSFONT=latarcyrheb-sun16 rd.luks=0 LANG=en_US.UTF-8
[    0.248983] pci 0000:00:01.0: >MSI quirk detected; subordinate MSI disabled
[    0.891871] pcieport 0000:00:07.0: >irq 40 for MSI/MSI-X
[    8.911765] [drm] radeon defaulting to kernel modesetting.
[    8.960892] [drm] radeon kernel modesetting enabled.
[    8.960955] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
[    9.274369] radeon 0000:01:05.0: >VRAM: 256M 0x00000000C0000000 - 0x00000000CFFFFFFF (256M used)
[    9.274384] radeon 0000:01:05.0: >GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[    9.275257] [drm] radeon: 256M of VRAM memory ready
[    9.275265] [drm] radeon: 512M of GTT memory ready.
[    9.275367] [drm] radeon: irq initialized.
[    9.281631] radeon 0000:01:05.0: >WB enabled
[    9.281634] radeon 0000:01:05.0: >fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff880115031c00
[    9.281858] radeon 0000:01:05.0: >setting latency timer to 64
[    9.313956] [drm] radeon: power management initialized
[    9.393175] fbcon: radeondrmfb (fb0) is primary device
[    9.423432] fb0: radeondrmfb frame buffer device
[    9.423610] [drm] Initialized radeon 2.18.0 20080528 for 0000:01:05.0 on minor 0
[   19.480295] r8169 0000:02:00.0: >irq 41 for MSI/MSI-X
Comment 57 Harald Reindl 2012-10-01 05:53:21 EDT
maybe fedora should give the today released 3.6 a chance since nobody knows what in 3.5.x goes wrong compared with 3.4.x
Comment 58 Josh Boyer 2012-10-01 07:46:22 EDT
(In reply to comment #57)
> maybe fedora should give the today released 3.6 a chance since nobody knows
> what in 3.5.x goes wrong compared with 3.4.x

We'll be rebasing to that very soon.  I'll post a test kernel here once it's rebased for people interested.  Or you could use the kernel in F18 for now.
Comment 59 Seppo Yli-Olli 2012-10-14 11:29:58 EDT
(In reply to comment #56)
> (In reply to comment #52)
> ...
> > Last thing in kernel config was the same as in working kernel's dmesg
> > radeon 0000:01:00.0: radeon: using MSI. It is possible that fbcon is being
> > annoying (and keeping console locked) and we're not seeing the real error
> > under modesetting because of that. So the first thing we need honestly is to
> > make sure fbcon isn't hiding errors.
> > Only way to recover here is hard poweroff (since keyboard becomes
> > unresponsive when hitting the kernel lockup) and reboot into 3.4.6-2 which
> > I've kept because of this issue.
> 
> Thanks for the additional details. How often do you see the boot-hang with
> kernel 3.5.4-2?
Always
> > radeon 0000:01:00.0: radeon: using MSI.
> 
> That message does not occur on my system:
> 
> [    0.248983] pci 0000:00:01.0: >MSI quirk detected; subordinate MSI
> disabled
Might be a significant difference, looks that disabled some part of MSI-based interrupts handling. Iirc that doesn't happen on my laptop. I would have tried with MSI disabled but I haven't been able to access the laptop.
Comment 60 Richard Gration 2012-10-20 07:59:18 EDT
I just tried kernel 3.6.2-4 and it still has this same bug on my HP Compaq NC6400 laptop, which has a Mobility Radeon X1300 graphics hardware.  Unlike others on this thread who appear to be able to boot occasionally with the 3.5 kernel, I have never been able to boot any 3.5 or 3.6 kernel.  The last working kernel that I have is 3.4.6-2.
Comment 61 Harald Reindl 2012-10-20 08:05:10 EDT
@Richard: Have you REALLY commented out the line "terminal_output=gfxterm" in "/boot/grub2/grub.cfg"? on all my machines after that never a problem again and this grub-bullshit does even not exist in all installations if they are only updated from F15->F16->F17 without grub2-mkconfig touched again
Comment 62 Richard Gration 2012-10-22 07:20:03 EDT
@Harald: Thanks for that.  Yes, I have commented out the line "terminal_output=gfxterm", but it doesn't fix the problem.  The 3.6.2-4 kernel still hangs every time on boot, but I get different messages before the laptop hangs than the "conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver". The last 12 lines are:

[1.871878] [drm] Initialized drm 1.1.0 20060810
[1.891814] [drm] radeon defaulting to kernel modesetting.
[1.891898] [drm] radeon kernel modesetting enabled
[1.892406] [drm] initializing kernel modesetting (RV515 0x1002:0x714A 0x103C:0x30AC).
[1.892527] [drm] register mmio base: 0xE4600000
[1.902602] [drm] register mmio size: 65536
[1.892800] ATOM BIOS: M52T
[1.892885] [drm] Generation 2 PCI interface, using max accessible memory
[1.892970] radeon 0000:01:00.0: VRAM: 128M 0x0000000000000000 - 0x0000000007FFFFFF (128M used)
[1.893086] radeon 0000:01:00.0: GTT: 512M 0x0000000008000000 - 0X0000000027FFFFFF
[1.893202] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[1.893275] [drm] Driver supports precise vblank timestamp query

and then the only way to recover from there is to power off (CTRL-ALT-DEL doesn't do anything)
Comment 63 Steve Tyler 2012-10-22 07:23:35 EDT
I'm seeing occasional boot hangs with kernel 3.6.2-4.fc17.x86_64: [1]

While hung, the caps lock and num lock keys control their respective keyboard lights. Pressing ctrl-alt-del does not produce a reboot, and the caps lock and num lock keys no longer control their lights after that. Pressing reset is required to reboot.

# grep terminal_output /boot/grub2/grub.cfg
terminal_output gfxterm

Two experiments to try:
1. Hold down a key while booting (e.g. the ctrl key)
   (or continuously move the mouse).
2. Run memtest86+ for a while before booting.

[1] Hangs at the "conflicting fb hw usage" message. After a successful boot, dmesg shows these lines:
[    9.356605] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
[    9.413496] Console: switching to colour dummy device 80x25
[    9.414860] [drm] initializing kernel modesetting (RS880 0x1002:0x9715 0x1565:0x1706).

There is a 57 ms (0.056891 sec) interval between the 'fb' and 'Console' messages. Is that expected?
Comment 64 Steve Tyler 2012-10-22 07:44:13 EDT
(In reply to comment #63)
...
> [1] Hangs at the "conflicting fb hw usage" message. After a successful boot,
> dmesg shows these lines:
> [    9.356605] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
> removing generic driver
> [    9.413496] Console: switching to colour dummy device 80x25
> [    9.414860] [drm] initializing kernel modesetting (RS880 0x1002:0x9715
> 0x1565:0x1706).
> 
> There is a 57 ms (0.056891 sec) interval between the 'fb' and 'Console'
> messages. Is that expected?

The dmesg output in Comment 4 shows a 53 ms (0.053424 sec) interval between the 'fb' and 'Console' messages.
Comment 65 Steve Tyler 2012-10-22 08:25:22 EDT
(In reply to comment #62)
> @Harald: Thanks for that.  Yes, I have commented out the line
> "terminal_output=gfxterm", but it doesn't fix the problem.  The 3.6.2-4
> kernel still hangs every time on boot, but I get different messages before
> the laptop hangs than the "conflicting fb hw usage radeondrmfb vs VESA VGA -
> removing generic driver". The last 12 lines are:
...
> and then the only way to recover from there is to power off (CTRL-ALT-DEL
> doesn't do anything)

Thanks for your report. Rather than commenting out that line, you could try adding this line to /etc/default/grub:
GRUB_TERMINAL_OUTPUT="console"
and running:
# grub2-mkconfig -o /boot/grub2/grub.cfg

/etc/default/grub is the grub2 configuration file:
GNU GRUB Manual 2.00~rc1
5.1 Simple configuration handling
http://www.gnu.org/software/grub/manual/grub.html#Simple-configuration
Comment 66 Mads Kiilerich 2012-10-22 08:40:39 EDT
Bug 862083 has some of the same symptoms but ends with an oops. That could perhaps help finding some common root cause.
Comment 67 charles.unix.pro 2012-10-27 14:38:00 EDT
Additional data point:
  Gateway NV55C laptop (Intel i915 graphics) running Fedora 17.1, kernel  3.6.2-4.fc17.i686.

Laptop hangs at boot ~50% of the time, suggesting a race condition?

'nomodeset' did not help.

'GRUB_TERMINAL_OUTPUT="console"' seems to fix it and causes the 'conflicting' message to disappear.
Comment 68 Seppo Yli-Olli 2012-10-28 14:11:31 EDT
Firstly: still happens on my laptop with 3.6.2-4.rc17.i686

Secondly: since I don't have enough time to actively debug this myself in a timescale that would benefit anyone else but me: while talking on #radeon I was told that it's possible to get sort of a kernel dump over firewire even if the kernel locks up. So if any of you wants to pursue this matter, firewire debugging and actively contacting the graphics driver upstream (nouveau in the case of nVidia, radeon in the case of ATi and afaik just intel in the case of Intel), we might actually get this resolved.

Thirdly: Could someone finally please fix the component so it doesn't point to the radeon X display driver but kernel? This is a generic DRM issue in kernel, more likely. This bug was filed wrong and this slows down the solving.
Comment 69 Richard Gration 2012-10-29 08:02:07 EDT
Reply to comment #65:

Steve,

I added GRUB_TERMINAL_OUTPUT="console" as suggested and tried with the new kernel 3.6.3, but got exactly the same result.  The last 4 lines were:


[1.588964] radeon 0000:01:00.0: VRAM: 128M 0x0000000000000000 - 0x0000000007FFFFFF (128M used)
[1.588964] radeon 0000:01:00.0: GTT: 512M 0x0000000008000000 - 0X0000000027FFFFFF
[1.589189] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[1.589263] [drm] Driver supports precise vblank timestamp query.

and then the boot freezes and I have to power off to restart. Significant code execution appears to be occuring because if I leave it for 5 minutes or so stopped at the above output the CPU really starts to heat up and the laptop cooling fan becomes audibly much louder.
Comment 70 Steve Tyler 2012-10-29 10:49:53 EDT
Intermittent boot hangs with kernel-3.6.3-1.fc17.x86_64.
Possibly more frequent than with kernel-3.6.2-4.fc17.x86_64.

$ sudo grep terminal_output /boot/grub2/grub.cfg
terminal_output gfxterm
Comment 71 Timothy Davis 2012-11-01 16:58:31 EDT
I installed Slackware 14 on my laptop (Compaq 6910p radeon X2300) with kernel 3.2.29, grabbed the latest 3.7 RC3 kernel source and compiled/installed; same issue with KMS and freezing. Grabbed the radeon_kms.c from the 3.2.29 and dropped in the 3.7 RC3 source tree (modified the include statements to work) and compiled/installed. Voila! fixed. whatever they did after 3.4.x fails for older chips. Maybe one of the kernel devs can diff them and find out what happened.
Comment 73 Harald Reindl 2012-11-01 18:20:44 EDT
the problem here is that it is NOT a radeon-problem
this bug belongs to the kernel and affects nvidia and intel also

look HERE: https://bugzilla.redhat.com/show_bug.cgi?id=843826

my bugreport was also WRONG changed to intel-graphics driver
shortly after i submitted it to the kernel and corrected
back to the kernel!
Comment 74 Steve Tyler 2012-11-02 12:37:06 EDT
Boot hangs with kernel 3.6.3-1.fc17.x86_64.

Sorry if you see this twice, I accidentally posted to Bug 843826, which is for intel, but I have radeon. Of course, if Bug 843826 is really the same bug as this one, one of the two should be closed/dupe ...
Comment 75 Václav Mocek 2012-11-12 08:28:02 EST
I have a similar issue with the infamous Lenovo S205 based on E-350/E-450 (Radeon HD 6310). When I boot F18 I get the following error:  

"fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver"

and after that the system hangs and the content of the screen is corrupted. It looks like the video buffer is being overwritten by something else in the final stage. 

The laptop has UEFI bios, Fedora 17 works like a charm, Fedora 18 doesn't  work.

Both versions have more or less the same kernel 3.6.x, the only difference is that F17 uses the old grub for UEFI boot and F18 uses the new grub2.

I suspect that the way how grub2 initializes the video controller might be somehow incompatible with the current intel/radeo/nouveau kernel drivers otherwise I am not able to explain such regression.
Comment 76 Harald Reindl 2012-11-12 10:44:46 EST
> The laptop has UEFI bios, Fedora 17 works like a charm, Fedora 18 doesn't work.
> Both versions have more or less the same kernel 3.6.x, the only difference is 
> that F17 uses the old grub for UEFI boot and F18 uses the new grub2

but all this bugreports are for F17 and not F18

what i REALLY do NOT understand is that there is a ton of bugreports
with most of them assigned to any graphics driver while it was pretty
clear that it is a regression in kernel/grub-loading from the begin
because the only updated package was the kernel

i was WAY realier with https://bugzilla.redhat.com/show_bug.cgi?id=843826
which was also WRONGLY assigend to intel-graphics

"terminal_output=gfxterm" is a workaround on Core i7-2600 AND Core i7-3770

CAN SOMEONE CLOSE THE DUPLICATE BUGREPORTS FOR INTEL/RADEON/NVIDIA AND
SET A FINAL LINK TO A COMMON BUGREPORT SO THAT WE ALL NOT GET A MIX OF REPLIES FROM DIFFERENT BUG-ID'S
Comment 77 Václav Mocek 2012-11-12 11:26:26 EST
> but all this bugreports are for F17 and not F18

Yes, but F18 has clearly the same problem. Some F17 users with UEFI have been saved so far, but they are going to be hit when F18 is out.

I was about to open a new bug report for F18, but you are probably right - a common bug report is needed now. The same kernel, the same grub2, the same problem.
Comment 78 Peter Bieringer 2012-11-12 14:18:35 EST
Just as an additional information, it seems that also during a working boot procedure, this "fb: conflicting fb hw usage..." is shown on my system, but then passing further on.

And as an side-note: Alt-SysRq key will not work when hanging, need to hard reset the system - somehow unexpected, because kernel.sysrq=1 was given on boot command line.
Comment 79 Harald Reindl 2012-11-12 17:27:42 EST
this happens so early that Alt-SysRq is not available yet and/or sicne the kernel hangs it is not interested in key-combinations
Comment 80 David Byrne 2012-11-12 19:27:06 EST
It's not a problem with Grub2. The same thing happens with Grub.
Comment 81 Franck Waechter 2012-11-15 13:16:06 EST
Same problem here on F17 (Same error message)
I hope this will be fixed in F18

[franck@noran ~]$ lspci | grep Radeon
01:00.0 VGA compatible controller: ATI Technologies Inc M64-S [Mobility Radeon X2300]
[franck@noran ~]$ uname -r
3.4.5-2.fc17.x86_64 => no problem with this kernel but problems with 3.6.x
Comment 82 Harald Reindl 2012-11-15 13:28:49 EST
> I hope this will be fixed in F18

since it is not a F16/F17/F18 problem it will be fixed in any or none release
something is different in the combination kernel/grub2/systemd and how
exactly the boot works on specific hardware

AFAIK nobody knows what happens, you find the problem all over the internet
so if it will get fixed for F18 and would also be fixed in F16/F17
Comment 83 Mahesh R S 2012-11-23 14:15:09 EST
Hi!

I had been seeing this problem on my system and here's a small change that SEEMS to work for me. Please see if this "could" be a valid solution.

(First off, I am a total n00b, so don't beat me up if something is incorrectly stated here. Please help me correct my mistakes. :) )

Alright, so first about my system: I am running fedora 17 (32-bit with PAE kernel) on a lenovo x120e netbook with AMD APU and therefore Radeon graphics card.

Earlier I ran Fedora 16 on this netbook and the thing worked properly (no boot time hangs) consistently. But, since I installed F17 on it, the netbook has CONSISTENTLY hanged. 

My system had been hanging consistently even after all the regular updates (kernel and apps). I looked all throughout the web but found no solution.

* Now for some of the steps I went through before I came to the solution that works for me: -+-+-+-+-
I suspected that plymouth was causing the system-hang so i removed it and even removed "rhgb" from /etc/default/grub, but, that did not change things one bit.

I  suspected that selinux could be causing the system-hang and was moments away from setting "selinux=0" but I desisted. :)

(Please note that my suspicions on plymouth and selinux were more out of my biases against them than any scientific/technical know-how.)

* Now for the actual solution: -+-+-+-+-
Finally, I made an interesting observation: every time my notebook was plugged-into the wall outlet (i.e. connected to the power brick/whatever) the system would hang. A cold restart (in which I would pull out the power cable and also pull out the battery and then restart the notebook) would get it to work again. I observed this so CONSISTENTLY that it led me to the "assumption" that some stale system state was being left back somewhere. Since I had seen a whole bunch of X11 files in /tmp I figured the stale state "could" be in /tmp.

I have never quite understood how "tmpwatch" works ... or even when it works so I did not feel mucking around with the /etc/cron.daily/tmpwatch file. And tmpwatch anyway ignores the X11 files/dirs in /tmp. So, the next thing I decided to try was to put /tmp into tmpfs ... i.e. into the RAM. This would ensure all the files in /tmp would be destroyed at every reboot.

So, once I changed /tmp into tmpfs the "hang-at-boot" problem seemed to go away!!

Bottom line: I feel that this whole problem is caused by some stale state left back either by X11 or GNOME or both. So, I would request all of you to try this method out. And if we find the "stale state of X11/GNOME in /tmp" to be the problem then I would suggest that we point fingers at X11 and GNOME and NOT the kernel. What say you?

(Fairly happy, that my system boots consistenly. :) )

Please give this a try and let us know if it works for you.

Rgds
Mahesh R S
Comment 84 David Byrne 2012-11-26 11:48:46 EST
Thanks, Mahesh. I'm glad that it's working for you.

I've just tried to clear /tmp and reboot the system. Still the same problem :(.
/tmp in RAM is not a solution or even a valid walkaround.

Maybe some tech-smart people will figure it out, I hope. It's way above my competencies.
Comment 85 Richard Gration 2012-11-30 20:25:22 EST
If anyone is still following this bug thread, I have just tried Kernel 3.6.7-4.fc17.x86_64 and it still hangs on boot on my HP Compaq NC6400 laptop, which has a Mobility Radeon X1300 graphics hardware, with the same symptoms as for every kernel I have tried since 3.4.

The last two lines before the laptop hangs as has to be powered off are:

[1.429189] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[1.432263] [drm] Driver supports precise vblank timestamp query.

As before, I can get the kernel to boot by adding a 'nomodeset' to the kernel parameters, but obviously the graphics are pretty ordinary afterwards.
Comment 86 Timothy Davis 2012-12-01 00:48:03 EST
I have a Radeon X2300 with the same problem, even the latest 3.6 kernel and 3.7 rc kernel exhibit the same issue. I installed the old 3.4 kernel FC16
Comment 87 Steve Tyler 2012-12-01 07:28:39 EST
I'm getting occasional boot hangs with kernel 3.6.7-4.fc17.x86_64.
Comment 88 Mikko Huhtala 2012-12-07 07:39:58 EST
I get random hangs at boot on both 3.6.7-5.fc18.i686 and the latest 3.6.9-4.fc18.i686 on F18 beta. I'm running it on an old Acer Travelmate laptop with a Radeon Mobility X1600 (ATI M56P) card. I get the "fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver" message every time, regardless of whether the boot succeeds or not.
Comment 89 Richard Gration 2012-12-08 18:53:15 EST
I have just tried Kernel 3.6.9-2.fc17.x86_64 and it still hangs on every boot on my HP Compaq NC6400 laptop (Mobility Radeon X1300 graphics hardware), with the same symptoms as for all kernels since 3.4.

With GRUB_TERMINAL_OUTPUT="console", the last two lines displayed before the laptop hangs as has to be powered off are:

[1.591981] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[1.592075] [drm] Driver supports precise vblank timestamp query.

As before, I can get the kernel to boot by adding a 'nomodeset' to the kernel parameters
Comment 90 PS 2012-12-11 12:20:10 EST
I'd like to let you guys know I have the same bug (there are many of us!) on HP Compaq 6910p with Mobility Radeon X2300. I have to say I'm very disappointed this has not been fixed.
Comment 91 Mikko Huhtala 2012-12-12 04:21:09 EST
There seems to be something else going on besides a kernel bug, at least on my system. I get the random hangs at boot even with a 2.6 kernel from F15 on my otherwise up-to-date F18 system. The kernel I tried is

2.6.43.8-1.fc15.i686

I still needed to try four or five times before I got a successful boot. On the other hand, the F18 live system boots from a USB stick every time, without hanging, and as far as I know, modesetting is enabled there.

So, it seems to me that this has possibly more to do with systemd than kernel, and something about booting from a USB flash drive as opposed to hard drive prevents the boot from hanging.
Comment 92 Bahador Bakhshi 2012-12-25 08:40:55 EST
I had the same problem (the laptop hangs randomly!!!). I found a workaround for this problem: Boot the kernel in text mode.

As the error message mentioned, kernel tries to replace the generic VGA driver by the Radeon driver which fails (I don't know why!!!). So, if kernel boots in text mode, the generic driver is not loaded and the problem is solve :D 

This generic driver is loaded by GRUB2. To disable loading the driver I commented the following lines in the GRUB2 config file (please note the this is not the optimal solution to disable the VGA driver, but, anyway, it works for me)

 #if loadfont $font ; then
 #  set gfxmode=auto
 #  load_video
 #  insmod gfxterm
 #  set locale_dir=$prefix/locale
 #  set lang=en_US
 #  insmod gettext
 #fi

 #terminal_output gfxterm

 menuentry 'Fedora (3.6. ....' {
      # load_video
      # set gfxpayload=keep
	insmod gzio
	insmod part_msdos
Comment 93 dobs 2013-01-06 09:12:46 EST
Created attachment 673352 [details]
3.6.11-1.fc17.x86_64
Comment 94 Panormitis Petrou 2013-01-13 12:14:25 EST
I'm having the same problem too, my graphic card is a radeon 7850.
My kernel version is 3.6.11-1.fc17.x86_64

My system would hang most of the time (around 8 times out of 10).
I ended up renaming /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/radeon/radeon.ko to stop the system from hanging.
I'm using kmod-catalyst so renaming the radeon driver probably doesn't hurt. I know what I did is not a proper solution (it's just a quick and dirty temporary workaround) but at least my system does not hang anymore.

basically what I did was:
su -
cd /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/radeon
mv radeon.ko radeon.koDEACTIVATED

On the same system I have also kernel-3.3.4-5.fc17.x86_64 installed.
I didn't expirience this problem with that kernel.
Comment 95 dobs 2013-01-16 14:06:28 EST
With this bug, we cannot install fc18!!!
Comment 96 Steve Tyler 2013-01-16 14:48:44 EST
(In reply to comment #95)
> With this bug, we cannot install fc18!!!

As a workaround, you might be able to install in basic graphics mode.

Basic graphics mode can be selected from the Troubleshooting menu.
Pressing the tab key will show you what it does.
Comment 97 dobs 2013-01-17 13:29:22 EST
Thanks, I did not know. Yesterday I made it by /dev/as*... I installed FC17 and then rolled updates %)
Comment 98 dobs 2013-01-17 13:33:52 EST
Forgot to say, with kernel 3.7.2 I can't boot, but I have 3.3.4 and he works
Comment 99 Ferdinand Galko 2013-01-17 14:32:34 EST
I think that due to this problem Fedora 17 is ultimate for many of us.
Comment 100 dobs 2013-01-20 08:20:52 EST
Created attachment 683548 [details]
3.7.2-204.fc18.x86_64
Comment 101 dennisn 2013-01-23 13:32:23 EST
I just hit this recently, after upgrading (my Gentoo linux system) from linux kernel 3.1.5 to 3.6.11+ or 3.7.* -- simply by doing a "make oldconfig" -- i.e. the .config file shouldn't have changed. I'm only able to boot the newer kernels if I disable KMS (if CONFIG_DRM_RADEON_KMS is not set).

The kernel bootup process hangs just after drm gets initialized and modesetting is enabled... the last visible line is always "kernel: radeon 0000:01:00.0: radeon: using MSI." ... I think the next lines /should/ be (based on 3.1.5's kms-kernel):

  kernel: [drm] radeon: irq initialized.
  kernel: [drm] Detected VRAM RAM=128M, BAR=128M
  ...

But that never happens.

My video card:
  01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X700 (PCIE)

Has anyone made any progress with this? Is this even the same problem as the original bug description? (I don't use radeondrmfb, and don't get that "conflicting fb" message.)
Comment 102 Seppo Yli-Olli 2013-01-27 10:15:21 EST
(In reply to comment #91)
> There seems to be something else going on besides a kernel bug, at least on
> my system. I get the random hangs at boot even with a 2.6 kernel from F15 on
> my otherwise up-to-date F18 system. The kernel I tried is
> 
> 2.6.43.8-1.fc15.i686
> 
> I still needed to try four or five times before I got a successful boot. On
> the other hand, the F18 live system boots from a USB stick every time,
> without hanging, and as far as I know, modesetting is enabled there.
> 
> So, it seems to me that this has possibly more to do with systemd than
> kernel, and something about booting from a USB flash drive as opposed to
> hard drive prevents the boot from hanging.
For me pre-3.5 kernels worked okay so it's likely different. Just out of curiosity; try booting with nomodeset, then after system has rebooted, get rid of X and run modprobe -r radeon and modprobe -r drm followed by modprobe radeon modeset=1.

Adding this since for me booting with KMS on triggers the lockup with X700 but booting without KMS and enabling it post-boot is fine.
Comment 103 Steve Tyler 2013-01-27 17:48:08 EST
Further, systemd starts after the point at which booting hangs:
$ dmesg | grep -iE 'console|radeon|dracut|systemd'
Comment 104 Lyonel Vincent 2013-01-27 18:51:41 EST
(In reply to comment #102)
> (In reply to comment #91)
> > There seems to be something else going on besides a kernel bug, at least on
> > my system. I get the random hangs at boot even with a 2.6 kernel from F15 on
> > my otherwise up-to-date F18 system. The kernel I tried is
> > 
> > 2.6.43.8-1.fc15.i686
> > 
> > I still needed to try four or five times before I got a successful boot. On
> > the other hand, the F18 live system boots from a USB stick every time,
> > without hanging, and as far as I know, modesetting is enabled there.
> > 
> > So, it seems to me that this has possibly more to do with systemd than
> > kernel, and something about booting from a USB flash drive as opposed to
> > hard drive prevents the boot from hanging.
> For me pre-3.5 kernels worked okay so it's likely different. Just out of
> curiosity; try booting with nomodeset, then after system has rebooted, get
> rid of X and run modprobe -r radeon and modprobe -r drm followed by modprobe
> radeon modeset=1.
> 
> Adding this since for me booting with KMS on triggers the lockup with X700
> but booting without KMS and enabling it post-boot is fine.

this workaround works on my HP Compaq 6910p (GT513UC#ABB) !

I can now use F17 w/ kernel 3.7.3-101.fc17.x86_64

I've added nomodeset in GRUB2's command line (using GRUB_CMDLINE_LINUX in /etc/default/grub) and the following to /etc/rc.d/rc.local:
modprobe -r radeon
modprobe -r drm
modprobe radeon modeset=1
Comment 105 Ferdinand Galko 2013-01-28 10:34:47 EST
(In reply to comment #104)  
> I've added nomodeset in GRUB2's command line (using GRUB_CMDLINE_LINUX in
> /etc/default/grub) and the following to /etc/rc.d/rc.local:
> modprobe -r radeon
> modprobe -r drm
> modprobe radeon modeset=1

I can corfirm that it works for me too.
I have HP Compaq 6820s with ATI Mobility RADEON X1350.
Comment 106 Timothy Davis 2013-01-28 11:57:36 EST
I can confirm as well, Compaq 6910p with X2300 Radeon
So start without X, then start X afterwards
This proves it is not an X driver issue but a kernel issue
Comment 107 Josh Boyer 2013-01-28 12:02:30 EST
(In reply to comment #106)
> This proves it is not an X driver issue but a kernel issue

The same people work on both, and we assign kernel drm bugs to the xorg equivalent because they are much easier to see outside of the ocean of kernel bugs.
Comment 108 Brennan Ashton 2013-02-01 11:44:56 EST
Perhaps this will help some of the people here.  I had a horrible time getting F18 to install because of this in UEFI. It would lock up soon after GRUB on the install with garbled graphics and require a power cycle.  I disabled the silent boot mode and rhgb and which is when I could see it lock on the "conflicting fb hw usage" message.  Adding nomodeset to grub allowed me to install.  Then when I would get the GRUB boot screen and try to edit a line there GRUB would lock. If I did not edit a line I would get the VESA driver with very poor performance. I edited /etc/default/grub to include thise:

GRUB_TERMINAL=console
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap nomodeset rd.md=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora/root rhgb radeon.modeset=1"

Then applied the configuration:
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg


Everything seemed to work after that
Comment 109 Harald Reindl 2013-02-01 12:03:11 EST
> Then when I would get the GRUB boot screen and try to 
> edit a line there GRUB would lock

oh yeah - i know this way too good and not reproduceable

that said: 
GRUB2 is the first bootmanager in my life which hangs this way
GRUB2 is as far as we know triggering this problem at all
GRUB2 cripples down protect bottmanager with password
GRUB2 has a unacceptable turng-language as config

what exactly were the improvements GRUB2 should bring starting with F16?
Comment 110 Chris W 2013-02-03 12:28:40 EST
(In reply to comment #104)  
> I've added nomodeset in GRUB2's command line (using GRUB_CMDLINE_LINUX in
> /etc/default/grub) and the following to /etc/rc.d/rc.local:
> modprobe -r radeon
> modprobe -r drm
> modprobe radeon modeset=1

I can confirm that the fix in comment #104 works:

I've added nomodeset in GRUB2's command line (using GRUB_CMDLINE_LINUX in /etc/default/grub) and the following to /etc/rc.d/rc.local:
modprobe -r radeon
modprobe -r drm
modprobe radeon modeset=1

File placed in /etc/rc.d/rc.local:
#!/bin/sh

modprobe -r radeon
modprobe -r drm
modprobe radeon modeset=1

Grub default:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0  KEYTABLE=us SYSFONT=True rd.lvm.lv=vg/lv_root rd.luks=0 rd.lvm.lv=vg/lv_swap LANG=en_US.UTF-8 rhgb quiet nomodeset"
#GRUB_THEME="/boot/grub2/themes/system/theme.txt"
GRUB_CMDLINE_LINUX_DEFAULT="noplymouth"

GRUB_GFXMODE=auto
SYSFONT=latarcyrheb-sun16

#set pager=1
#set debug=all

Kernel:
3.7.3-101.fc17.i686 with F17
Comment 111 Richard Gration 2013-03-10 08:13:20 EDT
(In reply to comment #110)
> (In reply to comment #104)  
> 
> I can confirm that the fix in comment #104 works:

This fix also worked perfectly for me with F17 on my HP Compaq NC6400 laptop with Mobility Radeon X1300 graphics hardware, so I decide to upgrade to F18 hoping that the same technique would work there.

I had to do the install with 'Basic Graphics' selected, which worked fine and F18 was up and running with 'nomodeset' inserted automatically into grub.conf by the install process.

However, after then putting rc.local into /etc/rc.d with the content referred to in #110 and rebooting, the boot process was fine until the point where the screen flickered on what I assume was execution of the 'modprobe radeon modeset=1' command.  The screen then just stayed blank.  I was able to switch to the console screen by pressing CTRL ALT F1 and then login in a non-graphic environment, but the X server screen would just stay blank.

However, if I boot the machine to init state 3 (ie. non-graphic) with the same rc.local in place, the console screen works fine in 'radeon modeset=1' mode.  If I then login as root and type 'init 5' to change to graphic mode everything works perfectly until the next boot.

So the workaround I am using is to boot to init state 3, login as root and then manually change to init state 5.  A bit cumbersome, but at least it works.

These symptoms suggest to me that there is a timing issue with the radeon kernel module and that the code is not waiting to finish initialising after doing the modeset before trying to start the graphics mode.

Has anyone else had any success with F18 on hardware that has this problem?
Comment 112 dennisn 2013-05-03 11:31:26 EDT
I think there are a couple bugs being referred to in this report. The one that I and Richard Gration are having can probably be solved by undoing kernel patch 2099810f903caa1920f3ef6014fb7f36e4786490: drm/radeon: "enable pci bus mastering after card is initialised (v2)". (Booting with radeon.modeset=0 is an ugly hack :p.)

(FWIW, I also got resuming/suspending to work on my x700 video card, using radeontool and a few regset's. I'm currently using the 3.9.0 kernel.)
Comment 113 Rolf Fokkens 2013-05-10 07:20:31 EDT
I'm having my system hang as well after "conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver". I'm actually also having a random graphics pattern on my screen, but after that the system hangs.

Hardware: Asus C60M1-I
Kernels with this isuue:

kernel-3.8.5-201.fc18.x86_64
kernel-3.8.6-203.fc18.x86_64
kernel-3.8.8-202.fc18.x86_64
kernel-3.8.9-200.fc18.x86_64
kernel-3.8.11-200.fc18.x86_64

Ever after upgrading to F18 this issue has been there. Under some circumstances (hitting the keyboard, position of the moon?) the system was able to boot, but it was very uncertain.

Current workaround: radeon.modeset=0
Comment 114 Vladimir Brkic 2013-05-14 18:22:21 EDT
(In reply to comment #112)
> I think there are a couple bugs being referred to in this report. The one
> that I and Richard Gration are having can probably be solved by undoing
> kernel patch 2099810f903caa1920f3ef6014fb7f36e4786490: drm/radeon: "enable
> pci bus mastering after card is initialised (v2)". (Booting with
> radeon.modeset=0 is an ugly hack :p.)
> 
> (FWIW, I also got resuming/suspending to work on my x700 video card, using
> radeontool and a few regset's. I'm currently using the 3.9.0 kernel.)

That's it, I have reverted the commit https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=2099810f903caa1920f3ef6014fb7f36e4786490 and kms is working now without workaround #110 in my arch linux. Yeaaah.

The bug definitely hits similar hw configurations on all distros:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1108457/comments/10

I can confirm exactly the same bug (boot freezing with message conflicting fb hw usage radeondrmfb...) in f17, f18, arch, slax and ubuntu since 3.5.0 on my laptop:
HP Compaq 6820s
ATI RV516 [Mobility Radeon X1350]
Kernel driver in use: radeon

I have just tested the reverting commit on arch with 3.8.12 and 3.9.2 and it's now working perfectly.

However I have no idea if this breaks something else or if there is better solution than just reverting the commit.
If someone have better idea how this should be properly fixed I will try.
I did some random testing with keeping 2099810f903caa1920f3ef6014fb7f36e4786490 and moving pci_set_master all around with no luck but I must confess I don't know what I'm doing.

Btw,
nomodeset is not working since 3.9, only radeon.modeset=0
radeon reload workaround #110 is not working anymore for me since 3.9.
Comment 115 Vladimir Brkic 2013-05-14 19:02:23 EDT
Created attachment 747965 [details]
ati rv515 fix by reverting pci bus mastering commit

The patch fixes boot freezing for ATI RV515 in 3.9.2 for me by reverting 2099810f903caa1920f3ef6014fb7f36e4786490 commit and probably breaks something else.
Comment 116 dobs 2013-05-17 13:11:45 EDT
3.9.2-200.fc18.x86_64 - can't boot :(((
Comment 117 dobs 2013-05-20 13:49:56 EDT
radeon.modeset=0 fix boot, but I have low screen resolution and only one detected monitor
Comment 118 oliver 2013-06-08 11:38:05 EDT
[drm ]driver supports precise vblank timestamp query ,it is  stopped,
Install fedora18,  how to solve?
Comment 119 dobs 2013-07-03 15:33:07 EDT
I checked, with Mobility Radeon X1300 can't install new Fedora :(
Seems I need new PC o_0
Comment 120 Fedora End Of Life 2013-07-04 00:28:59 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora 
'version' of '17'.

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 prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life.

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 121 dobs 2013-07-17 16:13:42 EDT
Hi guys!
I found solution how to run FC 19 on old PC, in text-mode installer does not work, so I install FC on new PC at the work, then I moved HDD to old PC and run it - Fedora 19 works fine!
Comment 122 Andre Klapper 2013-08-19 05:51:07 EDT
The commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e49f3959a96dc279860af7e86e6dbcfda50580a5 (committed 2013-06-03) links to this RH bug report (as pointed out in bug 858837).

As http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tag/?id=v3.10 lists 2013-06-30 as the tag date, it would be great to retest this problem with 3.10.
Comment 123 Lyonel Vincent 2013-08-19 13:23:56 EDT
I can confirm that the issue is gone on F19 with kernel 3.10
Comment 124 Andre Klapper 2013-11-06 06:30:32 EST
Confirming that this is not a problem anymore in F19 with Kernel 3.10 on a HP Compaq 6820s. Please close.

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