Description of problem: I have notebook HP Compaq 6820s with graphic card ATI Mobility RADEON X1350 128MB. I have tried live Fedora-18-Alpha-i686-Live-KDE.iso Booting stops at these last lines (quiet kernel option removed): ... [ 10.863452][drm] radeon defaulting to kernel modesetting [ 10.863624][drm] radeon kernel modesetting enabled [ 10.895274][drm] initializing kernel modesetting (RV 0x1002:0x7196 0x103C:0x30D7) [ 10.895615][drm] register mmio base: 0xDC400000 [ 10.895771][drm] register mmio size: 65536 [ 10.896606] ATOM BIOS: M62S [ 10.896855][drm] Generation 2 PCI interface, using max accessible memory [ 10.897049] radeon 0000:01:00.0: VRAM: 128M 0x0000000000000000 - 0x0000000007FFFFFF (128M used) [ 10.897252] radeon 0000:01:00.0: GTT: 512M 0x0000000000000000 - 0x0000000027FFFFFF [ 10.902770][drm] Supports vblank timestamp caching Rev 1 (10.10.2010) [ 10.902941][drm] Driver supports precise vblank timestamp query Booting via Troubleshooting -> Start Fedora 18 in basic graphic mode works but it has strange display resolution. This time I use Fedora 17 with basic kernel 3.3.4-5.fc17.i686.PAE because kernels 3.5.x have problem with my graphics too. Booting stops at line: fb: conflicting fb usage radeondrmfb vs VESA VGA - removing generic driver.
Ferdinand wanted to propose this as Fedora 18 blocker, but used summary instead of Blocks field. Fixing.
The same output with Live CD 20120924-test_days-i386.iso
Same hw, same output with both F18 alpha and 20120924-test_days-i386.iso. Btw, last working kernel in F17 is 3.4.6-2.fc17.x86_64.
Discussed at 2012-10-04 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker-review-2.1.2012-10-04-16.00.log.txt . As this looks like a single-system X showstopper, we reject it as a blocker by established precedent (X bugs that affect only a single system or small range of systems are not considered to be wide enough to be blockers; we don't have the development capacity to commit to fixing all such bugs). If it turns out to affect a wider range of systems, it can be re-proposed as a blocker.
Am effected as well same hardware as Ferdinand. Have to use radeon.modeset=0 to get it to boot. Broke after a kernel upgrade at some stage during F17, so its a little hardass to say we wont fix after we broke it. Any suggestions on where to start looking to fix?
Fedora kernels just track upstream, now - we don't stick on a single kernel series for each release. So it does happen than when we go from kernel 3.x to 3.y, some stuff breaks. "Any suggestions on where to start looking to fix?" Upstream, would be the one-word answer :) If you want to fix it for yourself, er, start looking up the guides to writing Linux kernel graphics driver code (have fun with that). If you mean checking if it's already fixed elsewhere, grab a 3.8 kernel from upstream or Rawhide and see if that works. If it does, try and narrow down when the fix came in, by booting various kernel builds.
Confirming that this is still an issue on Fedora 19 Live CD, exactly same output as in comment 0. Whoever has permissions to bump the Version field may do so. Cannot find a dedicated issue in bugs.freedesktop.org or bugzilla.kernel.org yet. Might be worth to upstream it by Fedora QA / some triager who has a clue (not me). But maybe I just failed to find it... http://superuser.com/questions/544023/kms-linux-kernel-3-7-and-ati-mobility-radeon-x1350 and https://mynixworld.wordpress.com/2012/12/18/linux-ati-radeon-kms/ cover the same ugly workarounds.
It seems like bug 845745 comment 110 lists an "interesting" workaround and bug 845745 comment 114 potentially isolated the culprit.
I think this should be fixed with this commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e49f3959a96dc279860af7e86e6dbcfda50580a5
Alex: Thanks for the heads-up! Looks like I should give 3.10 a try on that machine.
Confirming that using the Fedora 19 live CD with "nomodeset" and its default kernel 3.9, using it for installation, installing available updates including a bump to kernel 3.10, and rebooting the machine without "nomodeset" works fine on a HP Compaq 6820s with an ATI Mobility Radeon X1350. Hence "doesn't boot LiveCD" would be fixed in Fedora 20 for this specific bug. Leaving it to RH QA what to do with this bug report - for Fedora 19's Live CD it's not fixable.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
If Red Hat actually had people who looked at bug reports, comment 11 would not have been ignored and this would not be open anymore...
It always makes my day just *so* much nicer and me just *so* much more inclined to help people out with crap to wake up to that kind of sarcasm. Thanks.