Description of problem: gfx test day live cd fails to boot on Macbook Pro Version-Release number of selected component (if applicable): gfx_test_week_20110221_x86-64.iso How reproducible: Tried with both cold and warm boots with the same result. Steps to Reproduce: 1. download gfx_test_week_20110221_x86-64.iso aka 'graphics_test_week_20' 2. burn to cd 3. insert cd 4. shut down machine 5. start machine 6. hold down 'c' briefly to boot from the cd-rom Actual results: CD drive spins up, bios-y underscore cursor appears for a fraction of a second, then fedora bootloader screen appears and counts down. Screen turns light gray, some dark horizontal bars flicker briefly, and then following lines are printed at the top of the screen, gray text on black: [ 2.101533] [drm] nouveau 0000:02:00.0: DCB I2C entry invalid [ 3.849383] [drm] nouveau 0000:02:00.0: PRAMIN flush timeout [ 5.469452] [drm] nouveau 0000:02:00.0: PRAMIN flush timeout Machine is locked hard and shutdown must be forced by holding down the power button for 5 seconds. Expected results: Boot to LiveCD desktop. Additional info: Under MacOS, 'System Profiler' says the machine is: MacBookPro5,1 Intel Core 2 Duo 2.4 GHz 4 GB ram NVidia GeForce 9400M (device 10de:0863 rev 0x00b1 rom 3437 256 MB PCI) NVidia GeForce 9600M GT (device 10de:0647 rev 0x00a1 rom 3437 256 MB PCIe/x16) native display is 1440x900 LCD Booting with 'basic video' (vesa driver) and running smoltSendProfile generated http://smolts.org/client/show/pub_7466589a-35d5-4fae-9bf2-c49a62cf3695
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information especially concerning your hardware we require that will be helpful in our diagnosis of this issue. If the anaconda crashes during the switching to the graphic mode, most likely the problem lies in Xorg support for your graphics chip. There are couple of options how we can obtain information necessary for resolving the issue. If the computer is not completely frozen when installation fails, switch to the console (Ctrl+Alt+F2) and copy /tmp/X* and /var/log/anaconda.xlog to some other place -- USB stick, some other computer via network, somewhere on the Internet, and please attach it to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. If the computer is completely useless after installation fails, you can also install Fedora with a VESA mode driver (see http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/ for more information on that). Then after successful installation you can collect /var/log/anaconda.xlog, /var/log/Xorg.0.log, and the output of the program dmesg instead. Or you can install Fedora in a text mode completely, and then start X after that. If it fails, still /var/log/Xorg.0.log and the output of dmesg program from the failed attempt to start X would be useful. We will review this issue again once you've had a chance to attach this information. Thank you very much in advance.
I tried again with 'Fedora-15-Alpha-i686-Live-Desktop.iso' downloaded today. The machine hangs hard at while starting up. Booting in 'basic video' mode it completes and shows the gnome2 fallback. I wasn't installing, just trying the live cd, so I don't know if the attached logs are helpful. FWIW, here they are.
Created attachment 486702 [details] VESA livecd boot Xorg.0.log
Created attachment 486703 [details] VESA livecd boot /var/log/messages
*** Bug 694503 has been marked as a duplicate of this bug. ***
Okay, I have only one theory of what could be happening here so far. Do either of you guys have an actual install so that you could try a test kernel for me?
I don't have an install (not my machine) but I can probably hack up a live image.
Okay, I've done a scratch kernel build that's available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2983210 I'll leave NEEDINFO set until someone has tested it :)
I went ahead and did a full install on my macbook this morning. Pulled down all available updates, installed your kernel build, rebooted, and still the same message for me.
I spend some time trying to hack something this morning, but didn't succeed in the allotted time. In case it's relevant, I also tried the April 7 boot.iso, sha256sum 14d8ce7d72430d9a387ddb3fc48b13c88191e91697be861992df8ae979270216 boot.iso And got as far as starting anaconda in text mode before it hung on 'waiting for hardware to initialize'.
(In reply to comment #10) > I went ahead and did a full install on my macbook this morning. Pulled down > all available updates, installed your kernel build, rebooted, and still the > same message for me. Can I get your dmesg output from after it's failed?
Ben - I've posted a mmiotrace https://bugs.freedesktop.org/show_bug.cgi?id=27501#c9 of the nvidia binary driver on the upstream corresponding bug if thats any help - basically simply modprobing nouveau on latest Fedora / Ubuntu is enough to get this hang on my MacBook Pro 5,1 - ie. the modprobe doesn't even succeed - yet it is fine with the binary driver - the mmiotrace output is quite short though so hopefully it can help. Unfortunately the screen becomes corrupted after trying to modprobe nouveau so I can't see the dmesg output.
Created attachment 511713 [details] screen capture of dmesg from warm reboot Captured this after rebooting from my Ubuntu desktop with the NVIDIA driver loaded into the Fedora 15 Desktop ISO.
Created attachment 511715 [details] screen capture of dmesg from cold boot back into Fedora 15 I then hard powered off my machine and cold booted into the Fedora 15 ISO and got this shorter dump - in both cases the machine was hard locked at the point of capture. I am guessing the reason the first one is longer is the warm reboot left the card better initialised from the NVIDIA driver beforehand whereas on this cold boot nouveau did a worse job. Ben anything helpful here? Anything more I can try and get for you? Would love to see this get fixed.
Any news on this bug? I have the same problem with my MBP (5,2) and the F16 alpha release (3.1.0-0.rc3.git0.0.fc16.i686).
Still present in F16b1 + updates (3.1.0-0.rc9.git0.0.fc16.x86_64). Is there anything I can do to help?
Created attachment 529374 [details] kmsg dump including dump_stack() output when loading the driver manually I inserted a dump_stack() call to the nv84_instmem_flush routine using kernel 3.1.0-0.rc10.git0. Don't know if it helps...
Had the same problem on my MacBook pro with Ubuntu. Try temporarily changing the kernel boot option to " nomodeset" to boot, then change it permanently in the grub config file. Instructions here: http://ubuntuforums.org/showthread.php?t=1613132
*** Bug 816695 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping