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
This problem hits me also, extension of "linux" line in grub2.cfg with kernel option "nomodeset" is a workaround.
Do any of you see this "conflicting fb hw.." message in dmesg for 3.4 boots?
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.
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
same problem with 3.5.1-1.fc17
I'm pretty sure it has nothing to do with X11 (it isn't even configured to start X11)
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.
*** Bug 845631 has been marked as a duplicate of this bug. ***
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.
(In reply to comment #5) > same problem with 3.5.1-1.fc17 Same problem, Compaq 6910p laptop, X2300 video
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
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.
I am also facing problem with kernel 3.5.2-3.fc17.i686, that freeze up and not do anything. My laptop not boot
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
product: Inspiron 1545 () vendor: Dell Inc.
3.5.3 kernel, same problem: "conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver" and my laptop freezes after that
same problem with 3.5.3
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.
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?
(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)
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.
(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.
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.
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.
For completeness, I tested the remaining RC kernels (all x86_64) and they all exhibited the same failure (as detailed in the original comment).
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
(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.
(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
http://koji.fedoraproject.org/koji/buildinfo?buildID=321345 git11 http://koji.fedoraproject.org/koji/buildinfo?buildID=321298 git10 http://koji.fedoraproject.org/koji/buildinfo?buildID=321163 git9 http://koji.fedoraproject.org/koji/buildinfo?buildID=320723 git8 http://koji.fedoraproject.org/koji/buildinfo?buildID=320549 git7 http://koji.fedoraproject.org/koji/buildinfo?buildID=320374 git6 http://koji.fedoraproject.org/koji/buildinfo?buildID=320309 git5 I'd start with git5 (we didn't build git4), and report the first kernel you hit that has the same issue.
(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
(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).
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?
the git clone command should have been.. git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
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
(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
I am sad, all my efforts fail. Latest kernel is not working freezeup the screen.
(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.
(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
Slightly nervous about this result as none of the kernels that I built failed. Anyway, "f9369910a6225b8d4892c3f20ae740a711cd5ace is the first bad commit"
(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.
(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.
(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.
Same results
Does this kernel help things at all?: http://koji.fedoraproject.org/koji/taskinfo?taskID=4509129
(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
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.
Created attachment 615904 [details] can't boot... +1 Last work kernel 3.5.4-1.fc17.x86_64
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.
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
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
(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?
(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.
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.
(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.
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"
(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
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
(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.
(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.
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.
@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
@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)
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?
(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.
(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
Bug 862083 has some of the same symptoms but ends with an oops. That could perhaps help finding some common root cause.
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.
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.
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.
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
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.
Sounds promising. The gitweb log for radeon_kms.c is there: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=history;f=drivers/gpu/drm/radeon/radeon_kms.c;h=dc781c49b96b3848c116cb6fe013dd8abd669ddc;hb=HEAD
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!
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 ...
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.
> 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
> 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.
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.
this happens so early that Alt-SysRq is not available yet and/or sicne the kernel hangs it is not interested in key-combinations
It's not a problem with Grub2. The same thing happens with Grub.
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
> 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
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
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.
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.
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
I'm getting occasional boot hangs with kernel 3.6.7-4.fc17.x86_64.
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.
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
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.
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.
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
Created attachment 673352 [details] 3.6.11-1.fc17.x86_64
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.
With this bug, we cannot install fc18!!!
(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.
Thanks, I did not know. Yesterday I made it by /dev/as*... I installed FC17 and then rolled updates %)
Forgot to say, with kernel 3.7.2 I can't boot, but I have 3.3.4 and he works
I think that due to this problem Fedora 17 is ultimate for many of us.
Created attachment 683548 [details] 3.7.2-204.fc18.x86_64
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.)
(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.
Further, systemd starts after the point at which booting hangs: $ dmesg | grep -iE 'console|radeon|dracut|systemd'
(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
(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.
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
(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.
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
> 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?
(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
(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?
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.)
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
(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.
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.
3.9.2-200.fc18.x86_64 - can't boot :(((
radeon.modeset=0 fix boot, but I have low screen resolution and only one detected monitor
[drm ]driver supports precise vblank timestamp query ,it is stopped, Install fedora18, how to solve?
I checked, with Mobility Radeon X1300 can't install new Fedora :( Seems I need new PC o_0
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.
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!
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.
I can confirm that the issue is gone on F19 with kernel 3.10
Confirming that this is not a problem anymore in F19 with Kernel 3.10 on a HP Compaq 6820s. Please close.