Created attachment 337955 [details] screen after nouveau attempted to load When I boot my MacBookPro from EFI, nouveau doesn't work. Not only that, but it messes up the screen so that efifb no longer works correctly either. [drm] Initialized drm 1.1.0 20060810 nouveau 0000:01:00.0: enabling device (0002 -> 0003) nouveau 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 nouveau 0000:01:00.0: setting latency timer to 64 [drm] Detected an NV50 generation card (0x084700a2) [drm] Allocating FIFO number 1 [drm] nouveau_fifo_alloc: initialised FIFO 1 [drm:nv_valid_bios] *ERROR* BIOS signature not found. [drm:nv_valid_bios] *ERROR* BIOS signature not found. nouveau 0000:01:00.0: PCI INT A disabled nouveau: probe of 0000:01:00.0 failed with error -22
And what happens if you boot without nouveau.modeset=1 set? Nouveau fails to find a usable VBIOS image in your case. The next update I do to do kernel side of nouveau should hopefully fix that. However, you've exposed another bug. If nouveau fails initial card initialisation, it won't even attempt to clean up after itself. I will look into that too!
If I boot without nouveau.modeset=1 set, I get a normal 1920x1200 screen from efifb. X doesn't work with either nv or nouveau drivers though. Actually, if I boot _normally_ (not from EFI) without nouveau.modeset=1, X with the nouveau driver doesn't work then either -- is that expected, or should I report it separately? And if I boot with nouveau.modeset=1 and use the nv driver, switching from X to a VT puts the screen into VGA text mode, with lots of flashing text.
Can I see your /var/log/Xorg.0.log and the output of "dmesg" from after trying to start X with nouveau?
In which case? There are four: EFI/normal boot, with/without nouveau.modeset=1. Only one of the four actually gives me working X... which of the other three are you interested in today? :) The EFI-booted ones all look much like this: (II) NOUVEAU(0): Attempting to load BIOS image from PROM (!!) NOUVEAU(0): ... BIOS signature not found (II) NOUVEAU(0): Attempting to load BIOS image from PRAMIN (!!) NOUVEAU(0): ... BIOS signature not found (II) NOUVEAU(0): Attempting to load BIOS image from PCI ROM (!!) NOUVEAU(0): ... BIOS signature not found (EE) NOUVEAU(0): No valid BIOS image found (II) NOUVEAU(0): NV50DispPreInit is called. Backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e99e6] 1: /usr/bin/Xorg(xf86SigHandler+0x6f) [0x47ddef] 2: /lib64/libc.so.6 [0x7fb6488b3400] 3: /usr/lib64/xorg/modules/drivers//nouveau_drv.so(NV50OutputSetup+0x49) [0x7fb6 45fe7fa9] 4: /usr/lib64/xorg/modules/drivers//nouveau_drv.so [0x7fb645fc4ed5] 5: /usr/bin/Xorg(InitOutput+0x507) [0x467817] 6: /usr/bin/Xorg(main+0x20c) [0x42cedc] 7: /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fb64889e6cd] 8: /usr/bin/Xorg [0x42c509] Fatal server error: Caught signal 11. Server aborting If you want the one from a normal boot without nouveau.modeset=1, should I open a separate bug for that?
~Attention~ This bug appears to pertain to an important F11 feature, EFI, which the Fedora Community will be testing in an upcoming Fedora Test Day. Your participation in the action would be greatly appreciated! More information: https://fedoraproject.org/wiki/QA/Test_Days/2009-04-09 https://fedoraproject.org/wiki/Features/EFI
Can you please update to xorg-x11-drv-nouveau-0.0.12-24.20090408git960a5c8.fc11 and report if you see any change in the EFI boot + modeset=0 case? It might also be worth updating to kernel-2.6.29.1-54.fc11 to test the modeset=1 case. I'd be interested in seeing logs (output of "dmesg" command primarily) for that still whether it works or not. Thanks, Ben.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.
(In reply to comment #6) > Can you please update to xorg-x11-drv-nouveau-0.0.12-24.20090408git960a5c8.fc11 > and report if you see any change in the EFI boot + modeset=0 case? > > It might also be worth updating to kernel-2.6.29.1-54.fc11 to test the > modeset=1 case. I'd be interested in seeing logs (output of "dmesg" command > primarily) for that still whether it works or not. I think this bug is still a problem in F15 alpha, see this bug: https://bugzilla.redhat.com/show_bug.cgi?id=691609 F15 Live CD fails to boot Macbook Pro 4,1 with EFI. Works fine with BIOS emulation. Full dmesg reported with that bug, which is based on default kernel line set by the Live CD. If I edit that line to end with modeset=1, ultimately get the same results. Will post dmesg.
Created attachment 488844 [details] dmesg, kernel line using modeset=1
I think you'll find the binary driver will also fail in this case with "NVRM: failed to copy vbios to system memory". Unless there's some other magic way of retrieving the VBIOS image on these machines, there's not a lot we can do. The later MBP actually provide the VBIOS image via some method (can't recall which one) that nouveau supports.
It's interesting that here: http://grub.enbug.org/TestingOnMacbook This same Macbook Pro 4,1 is listed as a tested configuration with linux 2.6.35.4 and GRUB EFI 1.99 beta. But it's unclear what steps were used to successfully boot this machine natively via EFI. None of the bios options in GRUB 1.99 RC1 worked for me with kernels 2.6.35.6 and 2.6.35.11. So I'm not sure who wrote up the TestingOnMacbook page, and exactly how they got it working. But even if they do get EFI booting to work, it sounds like from what you're saying, this would probably not be possible to incorporate into a Live CD by a major distribution. It would be up to someone else to produce their own spin. Yes? Clearly Apple is getting the information they need in order to support this hardware for native EFI booting, so is this just a matter of non-documentation on their part? (I get the impression that Apple assumes native EFI is for them, and BIOS emulation is for everyone else.)
Apple likely have everything they need to know to setup the chip hardcoded in the driver they ship.
I will post on grub-dev and see who is responsible for TestingOnMacbook page and see if a more clear step by step for reproducing a successful EFI boot on Macbook Pro 4,1. If it's reproducible, perhaps the workaround would be to use GRUB2 EFI and loadbios.
*** Bug 691609 has been marked as a duplicate of this bug. ***
*** Bug 691605 has been marked as a duplicate of this bug. ***