Created attachment 531605 [details] screen photo at hang during boot: syslog text Description of problem: A Fedora 16 install DVD does not boot successfully on an Apple Macintosh MacBookPro. Version-Release number of selected component (if applicable): Fedora 16 x86_64 DVD RC5 How reproducible: every time (4 times so far) Steps to Reproduce: 1. Boot Fedora 16 x86_64 DVD RC5 (burned onto "8X" DVD+R) on Apple MacBookPro3,1 model A1226 ROM MBP31.0070.B07. Hold down Option key during chime after power-on, choose EFI boot. 2. 3. Actual results: Eventual hang during boot. Starts with GRUB splash screen 640x480 centered in 1440x900 display, showing night sky with aurora and text: Press any key to enter the menu Booting Fedora 16 in 4 seconds... and counting down the seconds. At zero seconds, the DVD spins and seeks. About 110 seconds later (1 minute 50 seconds: an eternity of no feedback), two Tux icons appear (one for each CPU: Intel Core 2 Duo [x86_64]) and syslog text messages from boot begin scrolling by. After about 5 or 6 seconds the scrolling stops and nothing further happens; I waited several minutes. Power-off is the only option. When the scrolling stops the bottom two lines have: [drm] nouveau 0000:01:00.0 : Detected an NV50 generation card (0x084700a2) fb: conflicting fb hw usage nouveau vs EFI VGA - removing generic driver Sometimes the rest of the screen is just the text scroll, sometimes the rest of the screen has graphics junk in the middle and at the top (see attached .JPG photographs.) Expected results: successful boot and entry to installer Additional info:
Created attachment 531606 [details] screen photo at hang during boot: syslog text with graphics junk
I'm pretty sure efibootmgr isn't right for this. pjones, brian, chris, any ideas? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Appears to be a duplicate of Bug 650949. See comment 34 from Ben Skeggs.
This exact same problem is reproduced with Macbook Pro 4,1 as well. It is possible to boot text mode only by passing 'nomodeset' kernel parameter. So far graphics is not possible.
Thanks, Chris, marking as a dupe. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 650949 ***
Hmm. My MacBook3,1 don't have nVidia card but Intel GMA X3100. And my machine faces this issue since Fedora 16. Fedora 15 or prior version can boot on MacBook3,1 with grub. http://en.wikipedia.org/wiki/MacBook http://fedora64.org/Members/jmontleon/installing-fedora-16-on-macbooks-using-grub2-efi Is this still dup. of bug 650949?
This bug's description is Macbook Pro 3,1 which does have NVidia graphics. I suggest filing a separate bug if one hasn't already been filed and I'd be really clear on whether you are using EFI mode or CSM/BIOS mode boot as that can make a huge difference.
On my MacBookPro3,1 model A1226 then Apple > About this Mac > More info > Graphics adaptors says: GE Force 8600M GT NVIDIA 0x10de Device ID 0x0407 Rev. 0x00a1 ROM 3175 I tried several times (install DVDs from Fedora 14, 15, 16 in Install, Rescue, Basic graphics, and text mode) but could not get a VT2 virtual console shell to run lspci. From the output above it looks like the result would be 10de:0407.
Un-duping as we want to split up the different NVIDIA adapters. This bug is for systems with the NVIDIA GeForce 8600M GT adapter *only* - not other GeForces, not Intel adapters. What's the status if you try a CSM boot with these cards? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
What's "CSM boot"? Booting a Fedora 16 install DVD (hold down Option key during Chime), then I see three large icons: MacinstoshHD, Windows, EFI boot. From memory (the machine is unavailable for about 6 hours), choosing Windows gives VGA-style text display but with larger characters, telling me to choose an option "1." or "2." (listed vertically, double-spaced) but no text after either number. There is no response to typing: no echo, no cursor movement, nothing. Ctrl-Alt-DEL has no effect. The only option is to force power off (hold down the PowerON button for 8 to 10 seconds until the machine shuts off.) Choosing EFI boot results in the original Description.
'CSM' is EFI BIOS emulation. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
In terms of video, CSM-BIOS boot is fine.
Very interesting...I have a successful EFI boot with the current F16 DVD. I get the same message I always have right before freeze, which is also reported in the original description: [drm] nouveau 0000:01:00.0 : Detected an NV50 generation card (0x084700a2) fb: conflicting fb hw usage nouveau vs EFI VGA - removing generic driver But this time it continues on as if nomodeset is being passed to the kernel (which it is not according to dmesg but could this be baked into the initramfs?or kernel?). I also get a graphical anaconda which appears to work. Previously I've used nomodeset and used the text installer. What has changed?
(In reply to comment #13) > What has changed? One thing that has changed is that Apple have issued an update to their EFI firmware ... but I don't know if that applies to your machine too and if it has been installed. The "conflicting fb" message is AFAIK always shown when the kernel switches from EFI video to a "real" video driver, and it do thus not indicate any problem.
MBP 4,1 has original firmware. There are no EFI firmware updates for this model, only an SMC update which was applied a year ago.
Again, hardware is a MacBookPro4,1 (2008). I am now getting a successful EFI boot and GUI startup from Fedora 16 DVD. I can install Fedora with defaults, and the resulting installation is bootable and starts X and Gnome. (It appears to stall at GRUB while loading vmlinuz/initramfs 1 in 2 times.) The only post install work I did was to mount the EFI System partition and mv /EFI/redhat /EFI/BOOT cp /EFI/BOOT/grub.efi /EFI/BOOT/BOOTX64.efi cp /EFI/BOOT/grub.conf /EFI/BOOT/BOOTX64.conf That reboot went fine, everything seemed to function normally. Subsequent reboots, I get different result for each reboot: busted GRUB menu without a splash screen on one boot, a kernel panic not finding root on another, and five in a row I just get a hang at GRUB after its time out. Anyway - completely different results than I previously experienced, which were identical to that of the original submission.
Is GeForce important? My MacBook3,1 (not MacBookPro) also fails to boot.
Takanori: yes. Please file a separate bug for your issue. We would also need specific details on what Fedora image you tried to boot and exactly *how* you tried to boot it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
MacBookPro3,1 model A1226 Confirming Comment #10, re-run on physical machine using final release Fedora 16 x86_64 install DVD. Insert DVD while MacOS is running, Apple > Restart, hold down Option key during chime, I see three large icons: MacintoshHD, Windows, EFI boot. Choosing EFI boot results in original Description above. Choosing Windows gives VGA text with five lines in upper left corner: ----- <cut here> 1. 2. Select CD-ROM Boot Type : _ ----- <cut here> where the underscore '_' indicates a blinking cursor. There is no response to typing on the keyboard. After half a minute or so the DVD head retracts, then there is silence and nothing happens.
(In reply to comment #16) > The only post install work I did was to mount the EFI System partition and The EFI system partition wasn't mounted on /boot/efi by default? Anaconda should have done that. If it didn't do that then it might indicate some fundamental problem.
(In reply to comment #19) > MacBookPro3,1 model A1226 Two requests. Can you do EFI Boot at least 10 more times (seriously) and confirm exactly the same results every time? Because on my MBP4,1 I'm getting up to four different boot behaviors boot to boot, from the DVD (verified of course), with sometimes 3-4 back to back boots being the same but then for some reason the next one is different. If this is consistent, I think we need a dmesg which you're going to have to obtain headless - you won't be able to see what you're doing. So you have to do this blindly and just trust it. If this is a single disk Macbook Pro, and you have nothing else attached, and you're booting EFI off the DVD this is the basic gist of how to do this: 1. fn-control-option-F2 (gets you to a text console) 2. Insert a FAT32 formatted USB stick or drive. Make sure you know which partition is FAT32 in advance if the disk contains more than one partition. I will assume one partition. 3. mkdir /mnt/usb mount -t vfat /dev/sdb1 /mnt/usb dmesg > dmesg.txt reboot Attach that dmesg with a very clear description: make/model, F16 DVD, EFI Boot, what the on-screen failure looked like. (In reply to comment #20) *post install* The installation went fine. I rebooted off a Recovery HD (Mac OS X 10.7), went to Terminal, mounted EFI System, and changed the name of directory and files as described, then rebooted. The default installation of grub.efi is not recognized by Apple's EFI.
(In reply to comment #21) Fatal error in step #3. Revised step 3: mkdir /mnt/usb mount -t vfat /dev/sdb1 /mnt/usb dmesg > /mnt/usb/dmesg.txt reboot
Bingo. After over 20 reboots from DVD, I finally got the reported results to occur. Previously I could reproduce this about 75% of the time. Attaching dmesg for both fail and success, and they do reveal a difference in nouveau behavior. Hardware: MacBookPro 4,1 Failure @ nouveau: [ 4.249950] [drm] nouveau 0000:01:00.0: Found Display Configuration Block version 11.15 [ 4.249954] [drm] nouveau 0000:01:00.0: Bad Display Configuration Block signature (FFDFF9FF) [ 4.261027] nouveau 0000:01:00.0: PCI INT A disabled [ 4.261043] nouveau: probe of 0000:01:00.0 failed with error -22 Successful boot to graphical anaconda: [ 4.509926] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN [ 4.509938] [drm] nouveau 0000:01:00.0: ... BIOS signature not found [ 4.509941] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PROM [ 4.509964] [drm] nouveau 0000:01:00.0: ... BIOS signature not found [ 4.509968] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PCIROM [ 4.510196] [drm] nouveau 0000:01:00.0: ... BIOS checksum invalid [ 4.510200] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from ACPI [ 4.510207] [drm] nouveau 0000:01:00.0: ... BIOS signature not found [ 4.510211] [drm] nouveau 0000:01:00.0: Using BIOS image from PCIROM [ 4.510285] [drm] nouveau 0000:01:00.0: BIT BIOS found [ 4.510289] [drm] nouveau 0000:01:00.0: Bios version 60.84.49.03 [ 4.510294] [drm] nouveau 0000:01:00.0: TMDS table version 2.0 [ 4.510297] [drm] nouveau 0000:01:00.0: Found Display Configuration Block version 4.0 [ 4.510303] [drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000123 00010034 [ 4.510307] [drm] nouveau 0000:01:00.0: Raw DCB entry 1: 02011210 00000028 [ 4.510310] [drm] nouveau 0000:01:00.0: Raw DCB entry 2: 02011212 00000030 [ 4.510314] [drm] nouveau 0000:01:00.0: Raw DCB entry 3: 01011211 0080c070 [ 4.510319] [drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x40 5 14 2 [ 4.510323] [drm] nouveau 0000:01:00.0: 0: 0x00000040: type 0x40 idx 0 tag 0xff [ 4.510328] [drm] nouveau 0000:01:00.0: 1: 0x00001120: type 0x20 idx 1 tag 0x07 [ 4.510332] [drm] nouveau 0000:01:00.0: unknown type, using 0x30 [ 4.510346] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xB06B [ 4.510350] [drm] nouveau 0000:01:00.0: BIT 'd' table not found [ 4.510354] [drm] nouveau 0000:01:00.0: 0xB06E: Init table command not found: 0x00 [ 4.510358] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xB3B8 [ 4.510363] [drm] nouveau 0000:01:00.0: 0xB3B8: Init table command not found: 0x18 [ 4.510367] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xBE05 [ 4.510371] [drm] nouveau 0000:01:00.0: 0xBE05: Init table command not found: 0xFF [ 4.510375] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xBEF7 [ 4.510380] [drm] nouveau 0000:01:00.0: 0xBEF7: Init table command not found: 0xFF [ 4.510384] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xC12A [ 4.510388] [drm] nouveau 0000:01:00.0: 0xC12A: Init table command not found: 0xFF [ 4.510392] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xC18F [ 4.510396] [drm] nouveau 0000:01:00.0: 0xC18F: Init table command not found: 0xFF [ 4.510406] [drm] nouveau 0000:01:00.0: memory timing table 0xc6 unknown [ 4.510410] [drm] nouveau 0000:01:00.0: voltage table 0x66 unknown [ 4.542457] [drm] nouveau 0000:01:00.0: 0 available performance level(s) [ 4.542478] [drm] nouveau 0000:01:00.0: c: core 275MHz shader 550MHz memory 302MHz [ 4.545595] [TTM] Zone kernel: Available graphics memory: 2023882 kiB. [ 4.545599] [TTM] Initializing pool allocator. [ 4.545611] [drm] nouveau 0000:01:00.0: Detected 512MiB VRAM [ 4.550608] [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture) [ 4.574614] [drm] nouveau 0000:01:00.0: DCB encoder 1 unknown [ 4.581153] b43-phy0: Broadcom 4321 WLAN found (core revision 12) [ 4.600077] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 4.600083] [drm] No driver support for vblank timestamp query. [ 4.714540] udevd[357]: renamed network interface eth0 to p5p1 [ 4.714775] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 4.714951] Registered led device: b43-phy0::tx [ 4.714970] Registered led device: b43-phy0::rx [ 4.714987] Registered led device: b43-phy0::radio [ 4.715018] Broadcom 43xx driver loaded [ Features: PMNLS, Firmware-ID: FW13 ] [ 4.766610] [drm] nouveau 0000:01:00.0: allocated 1440x900 fb: 0x320000, bo ffff880128400000 [ 4.766702] fbcon: nouveaufb (fb0) is primary device [ 4.797632] Console: switching to colour frame buffer device 180x56 [ 4.799485] fb0: nouveaufb frame buffer device [ 4.799499] drm: registered panic notifier [ 4.799518] [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0 Any chance this defect is related even on machines that never experience this when booting Mac OS? http://reviews.cnet.com/8301-13727_7-20018067-263.html
Created attachment 542323 [details] dmesg_mbp41_efi_f16dvd_anacondasuccess.txt
Created attachment 542324 [details] dmesg_mbp41_efi_f16dvd_hangatnouveau.txt
(In reply to comment #23) > Bingo. After over 20 reboots from DVD, I finally got the reported results to > occur. Previously I could reproduce this about 75% of the time. > > Attaching dmesg for both fail and success, and they do reveal a difference in > nouveau behavior. > > Hardware: MacBookPro 4,1 > > > > Failure @ nouveau: > [ 4.249950] [drm] nouveau 0000:01:00.0: Found Display Configuration Block > version 11.15 > [ 4.249954] [drm] nouveau 0000:01:00.0: Bad Display Configuration Block > signature (FFDFF9FF) > [ 4.261027] nouveau 0000:01:00.0: PCI INT A disabled > [ 4.261043] nouveau: probe of 0000:01:00.0 failed with error -22 I don't think this is nouveau's fault. It looks like something's corrupting the VBIOS image before nouveau gets to read it...
Seems like software related corruption to me as it was so consistently the case months ago that nouveau would always fail to initialize. Today, I can hardly get nouveau to fail. But it does still happen roughly 5-10% of the time. Now the primary problem appears to be at GRUB or shortly thereafter as it just hangs at the splash creen most of the time.
Created attachment 542614 [details] dmesg of failing EFI boot on MacBookPro3,1 This is output from dmesg upon hang when booting EFI on MacBookPro3,1 model A1226 with nvidia GeForce 8600M GT. Note the kernel Oops. [ 4.824065] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0x0041 [ 4.824076] [drm] nouveau 0000:01:00.0: 0x0041: Init table command not found: 0x00 [ 4.824082] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0x210A [ 4.824087] [drm] nouveau 0000:01:00.0: 0x210A: Init table command not found: 0xBF [ 4.824092] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0x98BE [ 4.824128] BUG: unable to handle kernel NULL pointer dereference at 000000000000000d [ 4.824135] IP: [<ffffffffa01ee7d0>] init_op_3c+0x26/0x75 [nouveau] [ 4.824166] PGD 76e36067 PUD 76e44067 PMD 0 [ 4.824172] Oops: 0000 [#1] SMP [ 4.824178] CPU 0 [ 4.824180] Modules linked in: arc4 nouveau(+) ath9k(+) ttm mac80211 drm_kms_helper ath9k_common ath9k_hw appletouch drm ath i2c_algo_bit i2c_core mxm_wmi cfg80211 wmi firewire_ohci firewire_core crc_itu_t sky2 rfkill video squashfs [ 4.824207] [ 4.824211] Pid: 394, comm: modprobe Not tainted 3.1.0-7.fc16.x86_64 #1 Apple Inc. MacBookPro3,1/Mac-F4238BC8 [ 4.824220] RIP: 0010:[<ffffffffa01ee7d0>] [<ffffffffa01ee7d0>] init_op_3c+0x26/0x75 [nouveau] [ 4.824245] RSP: 0018:ffff880076db5a28 EFLAGS: 00010286 [ 4.824249] RAX: 0000000000000000 RBX: ffff880075b01890 RCX: 0000000000000e3c [ 4.824254] RDX: ffff880076db5ab4 RSI: 00000000000098bf RDI: ffff880075b01890 [ 4.824259] RBP: ffff880076db5a48 R08: 0000000000000001 R09: 0720072007200720 [ 4.824263] R10: 0720072007200720 R11: 0720072007200720 R12: 0000000000009820 [ 4.824268] R13: 00000000ffffffff R14: 00000000000000d8 R15: ffffffffa024994b [ 4.824273] FS: 00007f6db8279700(0000) GS:ffff88007d800000(0000) knlGS:0000000000000000 [ 4.824278] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 4.824282] CR2: 000000000000000d CR3: 0000000076e46000 CR4: 00000000000006f0 [ 4.824287] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4.824291] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 4.824296] Process modprobe (pid: 394, threadinfo ffff880076db4000, task ffff88007b45dcc0) [ 4.824301] Stack: [ 4.824303] 0720072007200720 ffff880075b01890 00000000000098bf 00000000000098bf [ 4.824311] ffff880076db5a98 ffffffffa01efe90 ffff880076db5ab4 0000000276db5a68 [ 4.824319] ffffffffa0257380 ffff880075b00000 ffff88007814b000 ffff880075b01890 [ 4.824326] Call Trace: [ 4.824349] [<ffffffffa01efe90>] parse_init_table+0xfe/0x1f1 [nouveau] [ 4.824373] [<ffffffffa01f3add>] nouveau_run_vbios_init+0x25d/0x31a [nouveau] [ 4.824397] [<ffffffffa01f55ad>] nouveau_bios_init+0x1a13/0x1da6 [nouveau] [ 4.824406] [<ffffffff8122046c>] ? ioremap_page_range+0x238/0x298 [ 4.824412] [<ffffffff81105c35>] ? insert_vmalloc_vm+0x3d/0x77 [ 4.824432] [<ffffffffa01dd907>] nouveau_card_init+0xfe4/0x14e9 [nouveau] [ 4.824452] [<ffffffffa01de511>] nouveau_load+0x610/0x657 [nouveau] [ 4.824469] [<ffffffffa00b25b0>] drm_get_pci_dev+0x16e/0x26a [drm] [ 4.824477] [<ffffffff81085db7>] ? arch_local_irq_save+0x15/0x1b [ 4.824498] [<ffffffffa024078c>] nouveau_pci_probe+0x10/0x12 [nouveau] [ 4.824505] [<ffffffff8123f9b7>] local_pci_probe+0x44/0x75 [ 4.824510] [<ffffffff8124051a>] pci_device_probe+0xd0/0xff [ 4.824516] [<ffffffff812de4b7>] driver_probe_device+0x131/0x213 [ 4.824521] [<ffffffff812de5f3>] __driver_attach+0x5a/0x7e [ 4.824526] [<ffffffff812de599>] ? driver_probe_device+0x213/0x213 [ 4.824531] [<ffffffff812dd53f>] bus_for_each_dev+0x53/0x89 [ 4.824536] [<ffffffff812de096>] driver_attach+0x1e/0x20 [ 4.824541] [<ffffffff812ddcba>] bus_add_driver+0xd1/0x224 [ 4.824546] [<ffffffff812dea97>] driver_register+0x98/0x105 [ 4.824552] [<ffffffff81240ddd>] __pci_register_driver+0x56/0xc1 [ 4.824564] [<ffffffffa00b2736>] drm_pci_init+0x8a/0xef [drm] [ 4.824570] [<ffffffffa026b000>] ? 0xffffffffa026afff [ 4.824586] [<ffffffffa026b04f>] nouveau_init+0x4f/0x51 [nouveau] [ 4.824594] [<ffffffff81002099>] do_one_initcall+0x7f/0x136 [ 4.824599] [<ffffffff8108a5dd>] sys_init_module+0x88/0x1d0 [ 4.824606] [<ffffffff814bc482>] system_call_fastpath+0x16/0x1b [ 4.824610] Code: 5e 41 5f 5d c3 55 48 89 e5 41 55 41 54 53 41 52 66 66 66 66 90 48 8b 87 88 07 01 00 41 83 cd ff 0f b7 f6 48 89 fb 44 8a 64 37 21 <0f> b6 40 0d 44 0f bc e8 45 0f 44 ed 80 3a 00 74 30 45 0f b6 e4 [ 4.824653] RIP [<ffffffffa01ee7d0>] init_op_3c+0x26/0x75 [nouveau] [ 4.824677] RSP <ffff880076db5a28> [ 4.824680] CR2: 000000000000000d [ 4.824683] ---[ end trace a78f55f34f2ab692 ]---
So, how do I capture the VBIOS init table so that it can be perused? (Either under MacOS or under Linux?)
Created attachment 542669 [details] .tgz of dmesg output from 5 EFI boot attempts MacBookPro3,1 model A1226 In ten tries, I saw: 3 hangs with Oops, same or similar to Comment #28 2 hangs with failures to recognize graphics BIT BIOS 3 hangs with failed dmesg capture: LED on USB flash drive blinks upon insertion, but did not blink immediately following 'mount' like it did other times 2 early hangs attributed to power/heat issues: grub splash screen still visible, Power button gives immediate OFF instead of requiring an 8-second hold The first 8 tries were made over 56 minutes. The underside of the case, between the battery and the hinge, grew somewhat hot. I waited 42 minutes for cooling, then tried another 2 times over 7 minutes. During the wait time I re-verified the DVD on a different machine (dd if=/dev/sr0 bs=32k | cmp - Fedora-16-x86_64-DVD.iso) Attempt #6 (one of the "hot" failures) saw a message in VGA text: grub_open("/E*|") failed Press any key to enter the menu Booting Fedora 16 in 4 seconds... where the '*' in the filename is really a box-drawing character: lower right corner of box in center of character cell, one leg going left and two legs going up. The last character of the filename seemed to be either a pipe symbol or a vertical edge for box-drawing.
This is beyond my knowledge level. I can see a lot of inconsistency within a given hardware model, and no obvious pattern between the two listed hardware models. A Mac user would tend to consider inconsistent booting to be a hardware problem of some sort, hands down. But Mac OS X EFI boot is 100% consistent between reboots. And Linux CSM-BIOS boot is 100% consistent between reboots. So this suggests to my pea brain that this is software related but I don't know enough except to speculate. So feel free to ignore. Is it possible whatever is first obtaining VBIOS is getting it before that hardware has fully initialized, so it's sometimes incomplete and hence corrupt? Or are hardware bugs possible that are accounted for in EFI boot by Apple's software with Mac OS X booting, and accounted for in CSM-BIOS when booting other OS's, but is not accounted for at all with EFI boot of linux? It seems kinda strange to me that in my case I'm getting variable initramfs unpacking errors. Obviously it's not changing, but how it's being unpacked is different in some boot attempts. So I wonder if there's a much lower level bug that's causing other corruption at boot time, intermittently and VBIOS is just one possible victim.
(In reply to comment #29) > So, how do I capture the VBIOS init table so that it can be perused? (Either > under MacOS or under Linux?) No need. I can tell from the rest of the nouveau output that yours has been horrifically corrupted too before nouveau gets to it. (In reply to comment #31) > Is it possible whatever is first obtaining VBIOS is getting it before that > hardware has fully initialized, so it's sometimes incomplete and hence corrupt? I don't think this is the case. > It seems kinda strange to me that in my case I'm getting variable initramfs > unpacking errors. Obviously it's not changing, but how it's being unpacked is > different in some boot attempts. So I wonder if there's a much lower level bug > that's causing other corruption at boot time, intermittently and VBIOS is just > one possible victim. This seems somewhat likely.
I think I see the same issue on MacBookPro6,2. Someone posted a (mostly) successful dmesg from BIOS boot on bug 756866 - it shows NV50 too. Exactly the same model and USB EFI boot with KMS fails with screen corruption somewhat similar to comment 1. As a workaround I can use nomodeset and efifb.
MacBookPro 6,2 is NVidia GeForce GT 330M, which I think makes it is more related to this bug 650949. >>In reply again to comment #9 by Adam Williamson: "What's the status if you try a CSM boot with these cards?" I am finding catastrophic CSM-BIOS boot failure of MBP4,1 Geforce 8600M with RHEL/CentOS 6.1 kernel 2.6.32-131.21.1.el6.x86_64 and 2.6.32-131.12.1.el6.x86_64 (the only two -131 kernels I've tested). The 6.0 2.6.32-71 kernels tested all work OK. By catastrophic I mean, black screen during boot at nouveau, can't ssh, can't blind dmesg to a USB stick, and it happens too soon for kdump to capture. Nomodeset resolves it, as does the proprietary Nvidia driver. If this is not a known issue with this kernel series, let me know and I'll file a separate bug if the RHEL/CentOS 6.2 kernel does not resolve it. Bugzilla search turns up nothing so far - it is the first and only case of CSM-BIOS problems I've had with nouveau and this graphics adapter.
Appears to be fixed in F17 TC2, 3.3.4-1. With EFI boot, nouveau doesn't get mad, x starts up, things appear to be working. Expected?
John, please test and report the result.
My MacBookPro3,1 model A1226 failed last Friday; pushing the power button does not initiate power-up. I might be able to replace the internal "Left I/O" board (includes magsafe logic), however ifixit.com rates this repair as "difficult" and it will take at least a week in any event.
EFI Booting with F17 Beta DVD on a MacBookPro3,1 model A1226 still has the same stop with same last two lines as in original description.
Beta is old and boring; the reference to 'TC2' in comment #35 is to a substantially newer build. See http://dl.fedoraproject.org/pub/alt/stage/ ; we're up to TC5. However, hold your horses, as TC6 should improve the situation somewhat more and should land soon. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 675253 [details] dmesg_3.7.1-5_debug_multiuserT.txt This has been largely working with kernels since May. The last well working kernel is kernel-3.6.10-4.fc18. With kernel-3.6.11-1.fc17 I get a hang at nouveau similar to what's been reported before, I can ssh in. With 3.7.1-2.fc18 today I'm getting something new which is partially corrupted display content, coinciding with this message in dmesg: [ 54.737183] nouveau E[ PFB][0000:01:00.0] trapped write at 0x000053c400 on channel 0x0001fed0 BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT That's in multi-user.target. If I use graphical.target, there are so many of these that it fills the buffer completely within seconds, and dmesg contains nothing but those lines. So I have installed the debug kernel. Attached is dmesg with multi-user.target.
Created attachment 675254 [details] dmesg_3.7.1-5_debug_multiuserT.txt.zip graphical.target - I don't think there's any additional information in this, and it's really long so I zipped it.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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 to click on "Clone This Bug" 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
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.