Nouveau - Aug 2015 - [Bug 91779] New: MacBookPro3, 1 (NV84) fails to load nouveau on linux 4.1 -- Invalid ROM contents

https://bugs.freedesktop.org/show_bug.cgi?id=91779

            Bug ID: 91779
           Summary: MacBookPro3,1 (NV84) fails to load nouveau on linux
                    4.1 -- Invalid ROM contents
           Product: xorg
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: jeremyhu at freedesktop.org
        QA Contact: xorg-team at lists.x.org

I thought this may have been bug #89047, but it looks like a different issue as
it is still reproducing on the 4.1 kernel.

This may be related to or a dupe of bug #90626 or bug #91402.

I have a MacBookPro3,1 with nVidia GeForce 8600M GT.  The information below has
been taken from Ubunto 15.10 (20150826 snapshot) with the following kernel:
Linux wedge 4.1.0-3-generic #3-Ubuntu SMP Tue Jul 28 12:25:10 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux

The same behavior is observed on 3.19 kernels (Ubuntu 14.04.3 and 15.04).  I
did not try older kernels.

lspci shows:

01:00.0 VGA compatible controller: NVIDIA Corporation G84M [GeForce 8600M GT]
(rev a1) (prog-if 00 [VGA controller])
    Subsystem: Apple Inc. Device 00a0
    Physical Slot: 1
    Flags: fast devsel
    Memory at d2000000 (32-bit, non-prefetchable) [size=16M]
    Memory at c0000000 (64-bit, prefetchable) [size=256M]
    Memory at d0000000 (64-bit, non-prefetchable) [size=32M]
    I/O ports at 5000 [disabled] [size=128]
    Expansion ROM at d3000000 [disabled] [size=128K]
    Capabilities: <access denied>

In order to get a usable fb with this configuration, I need to blacklist the
nouveau kernel module.  I'm able to use X11 with fbdev, but I'm unable
to use
the fb (or X11) with nouveau.

Upon loading the nouveau kernel module, the following is logged by the kernel:

Aug 27 12:30:44 wedge kernel: [   57.905775] [drm] Initialized drm 1.1.0
20060810
Aug 27 12:30:44 wedge kernel: [   57.938200] wmi: Mapper loaded
Aug 27 12:30:44 wedge kernel: [   58.013484] checking generic (c0030000 710000)
vs hw (c0000000 10000000)
Aug 27 12:30:44 wedge kernel: [   58.013489] fb: switching to nouveaufb from
EFI VGA
Aug 27 12:30:44 wedge kernel: [   58.013567] Console: switching to colour dummy
device 80x25
Aug 27 12:30:44 wedge kernel: [   58.014140] nouveau 0000:01:00.0: enabling
device (0006 -> 0007)
Aug 27 12:30:44 wedge kernel: [   58.014535] nouveau  [  DEVICE][0000:01:00.0]
BOOT0  : 0x084700a2
Aug 27 12:30:44 wedge kernel: [   58.014540] nouveau  [  DEVICE][0000:01:00.0]
Chipset: G84 (NV84)
Aug 27 12:30:44 wedge kernel: [   58.014542] nouveau  [  DEVICE][0000:01:00.0]
Family : NV50
Aug 27 12:30:44 wedge kernel: [   58.014612] nouveau 0000:01:00.0: Invalid ROM
contents
Aug 27 12:30:44 wedge kernel: [   58.014630] nouveau ![   VBIOS][0000:01:00.0]
unable to locate usable image
Aug 27 12:30:44 wedge kernel: [   58.014636] nouveau E[  DEVICE][0000:01:00.0]
failed to create 0x10000001, -22
Aug 27 12:30:44 wedge kernel: [   58.014644] nouveau E[     DRM] failed to
create 0x00000080, -22
Aug 27 12:30:44 wedge kernel: [   58.014980] nouveau: probe of 0000:01:00.0
failed with error -22

After loading nouvea, the fb does not update.  Unloading nouveau succeeds, but
the fb stays unresponsive (it does not switch back to EFI VGA).  The following
is logged when unloading nouveau:

Aug 27 12:39:06 wedge kernel: [  559.546939] [drm] Module unloaded

---

Issues that should be addressed:
  1) Upon failing, fb should switch back to EFI VGA so as to not make the
system unusable
  2) Upon unloading the module, fb should switch back to EFI VGA
  3) The underlying error should be fixed

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150827/8b2af686/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

Jeremy Huddleston <jeremyhu at freedesktop.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.freedesktop.or
                   |                            |g/show_bug.cgi?id=89047,
                   |                            |https://bugs.freedesktop.or
                   |                            |g/show_bug.cgi?id=90626

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150827/d70ca490/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

Jeremy Huddleston <jeremyhu at freedesktop.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.freedesktop.or
                   |                            |g/show_bug.cgi?id=91402

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150827/c74c339e/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #1 from Jeremy Huddleston <jeremyhu at freedesktop.org> ---
Created attachment 117950
  --> https://bugs.freedesktop.org/attachment.cgi?id=117950&action=edit
dmesg output after loading nouveau

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150827/feab9c28/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

Jeremy Huddleston <jeremyhu at freedesktop.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|MacBookPro3,1 (NV84) fails  |Pure EFI: MacBookPro3,1
                   |to load nouveau on linux    |(NV84) fails to load
                   |4.1 -- Invalid ROM contents |nouveau on linux 4.1 --
                   |                            |Invalid ROM contents

--- Comment #2 from Jeremy Huddleston <jeremyhu at freedesktop.org> ---
Sigh, most likely my fault for booting with pure EFI.  Unfortunately, I made
the system unbootable when trying to install GRUB i386-pc for BIOS emulation
mode, but is there a ticket tracking getting a way to have nouveau work through
pure EFI that this can be duped to?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150828/7f742034/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #3 from Jeremy Huddleston <jeremyhu at freedesktop.org> ---
Or perhaps instead of duping this to a "make nouveau work in EFI"
ticket, could
we instead use this to have nouveau fail more gracefully (eg: handing fb back
to EFI VGA upon failure)?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150828/145d0bae/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> ---
I believe the situation is that the mac bios normally sticks the gpu's vbios
into either acpi or its pramin by executing the option rom. Once you've
booted
and you don't have it in ACPI or PRAMIN, the PROM and PCIROM are the only
other
places we can really try. It doesn't appear to like any of your images... I
think if you boot with nouveau.debug=VBIOS=debug that should provide a bit more
info.

If you can obtain the vbios through whatever other means and stick it in a
file, you can use
nouveau.config=NvBios=filename-that-is-loaded-by-request_firmware

As for handing fb back, unfortunately that's not really possible. Arguably
nouveau shouldn't grab the fb so early (or perhaps should check VBIOS
availability even earlier), but the way this modern hw works, VGA is all long
gone.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150828/cf3f462d/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #5 from Jeremy Huddleston <jeremyhu at freedesktop.org> ---
Thanks Ilia,

I think the most pressing issue here is to get users a working fb when they
boot in such a configuration (eg: Ubuntu's and Fedora's recent live
cds).  Can
we use this bug to track updating the nouveau kernel module to not take away
the fb until it has guaranteed that it can be used for the fb?

Currently, forums are filled with recommendations that users boot with
nomodeset, which acts as a workaround because nouveau errs out earlier if KMS
is disabled.  It would be good to ensure that this error is similarly handled
early so as to not leave the user without an fb.


As an aside, I reconfigured for BIOS-emulation and have nouveau loading fine
here.  I'd like to get back to pure EFI, so is there an easy way to have
nouveau dump the firmware to disk for my use in EFI mode?  Is it exported in
/sys somewhere?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150829/026102db/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #6 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Jeremy Huddleston from comment #5)
> Thanks Ilia,
> 
> I think the most pressing issue here is to get users a working fb when they
> boot in such a configuration (eg: Ubuntu's and Fedora's recent live
cds).
> Can we use this bug to track updating the nouveau kernel module to not take
> away the fb until it has guaranteed that it can be used for the fb?
Bug id's are cheap, I'd file a new one, but that's me. If you feel
like the
quantity of integers is quickly running out, feel free to reuse this one, just
update the subject.
> As an aside, I reconfigured for BIOS-emulation and have nouveau loading
fine
> here.  I'd like to get back to pure EFI, so is there an easy way to
have
> nouveau dump the firmware to disk for my use in EFI mode?  Is it exported
in
> /sys somewhere?
/sys/kernel/debug/dri/0/vbios.rom

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150829/57594cf3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #7 from Jeremy Huddleston <jeremyhu at freedesktop.org>
---
> I'd file a new one
OK.  Forked off to bug #91804 then.  I was just thinking that getting this
configuration to work might just not be supported, but if you want to keep
heading down this path, I'm definitely game.

In this configuration, 'sudo modprobe nouveau debug=VBIOS=debug' results
in:

Aug 29 23:19:45 wedge kernel: [  294.071101] [drm] Initialized drm 1.1.0
20060810
Aug 29 23:19:45 wedge kernel: [  294.127783] wmi: Mapper loaded
Aug 29 23:19:46 wedge kernel: [  294.190330] checking generic (c0030000 710000)
vs hw (c0000000 10000000)
Aug 29 23:19:46 wedge kernel: [  294.190337] fb: conflicting fb hw usage
nouveaufb vs EFI VGA - removing generic driver
Aug 29 23:19:46 wedge kernel: [  294.190449] Console: switching to colour dummy
device 80x25
Aug 29 23:19:46 wedge kernel: [  294.191803] nouveau 0000:01:00.0: enabling
device (0006 -> 0007)
Aug 29 23:19:46 wedge kernel: [  294.192979] [drm] hdmi device  not found 1 0 1
Aug 29 23:19:46 wedge kernel: [  294.193257] nouveau  [  DEVICE][0000:01:00.0]
BOOT0  : 0x084700a2
Aug 29 23:19:46 wedge kernel: [  294.193260] nouveau  [  DEVICE][0000:01:00.0]
Chipset: G84 (NV84)
Aug 29 23:19:46 wedge kernel: [  294.193262] nouveau  [  DEVICE][0000:01:00.0]
Family : NV50
Aug 29 23:19:46 wedge kernel: [  294.196982] nouveau  [   VBIOS][0000:01:00.0]
checking PRAMIN for image...
Aug 29 23:19:46 wedge kernel: [  294.196990] nouveau  [   VBIOS][0000:01:00.0]
... signature not found
Aug 29 23:19:46 wedge kernel: [  294.196992] nouveau  [   VBIOS][0000:01:00.0]
checking PROM for image...
Aug 29 23:19:46 wedge kernel: [  294.197010] nouveau  [   VBIOS][0000:01:00.0]
... signature not found
Aug 29 23:19:46 wedge kernel: [  294.197012] nouveau  [   VBIOS][0000:01:00.0]
checking ACPI for image...
Aug 29 23:19:46 wedge kernel: [  294.197017] nouveau  [   VBIOS][0000:01:00.0]
... signature not found
Aug 29 23:19:46 wedge kernel: [  294.197019] nouveau  [   VBIOS][0000:01:00.0]
checking PCIROM for image...
Aug 29 23:19:46 wedge kernel: [  294.197070] nouveau 0000:01:00.0: Invalid ROM
contents
Aug 29 23:19:46 wedge kernel: [  294.197084] nouveau  [   VBIOS][0000:01:00.0]
... signature not found
Aug 29 23:19:46 wedge kernel: [  294.197087] nouveau  [   VBIOS][0000:01:00.0]
checking PLATFORM for image...
Aug 29 23:19:46 wedge kernel: [  294.197089] nouveau  [   VBIOS][0000:01:00.0]
... signature not found
Aug 29 23:19:46 wedge kernel: [  294.197091] nouveau E[   VBIOS][0000:01:00.0]
unable to locate usable image
Aug 29 23:19:46 wedge kernel: [  294.197095] nouveau E[  DEVICE][0000:01:00.0]
failed to create 0x10000001, -22
Aug 29 23:19:46 wedge kernel: [  294.197098] nouveau E[     DRM] failed to
create 0x80000080, -22
Aug 29 23:19:46 wedge kernel: [  294.197627] nouveau: probe of 0000:01:00.0
failed with error -22

Note that this was done with a slightly older kernel than originally reported
with, 3.13.0-62-generic from recent Ubuntu 14.04.3.
> /sys/kernel/debug/dri/0/vbios.rom
Excellent, thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150830/3cad479e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

Jeremy Huddleston <jeremyhu at freedesktop.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.freedesktop.or
                   |                            |g/show_bug.cgi?id=91804

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150830/8922f1ef/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #8 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Jeremy Huddleston from comment #7)
> > I'd file a new one
> 
> OK.  Forked off to bug #91804 then.  I was just thinking that getting this
> configuration to work might just not be supported, but if you want to keep
> heading down this path, I'm definitely game.
You want to stick that vbios.rom into /lib/firmware and then boot with

nouveau.config=NvBios=vbios.rom

Make sure that this is available whenever nouveau loads, so if it's built-in
you have to build the vbios.rom in as extra firmware, or if it loads from
initrd it must be in the initrd.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150830/1131fac7/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #9 from Jeremy Huddleston <jeremyhu at freedesktop.org> ---
BTW, copying /sys/kernel/debug/dri/0/vbios.rom to /lib/firmware when in
BIOS-emulation mode has allowed me to get nouveau loaded when in pure EFI mode
via:

$ sudo modprobe nouveau config=NvBios=vbios.rom

However, there's some really bad screen flicker with the 3.13 kernel from
Ubuntu 14.04.3.  It looks as though the screen is refreshing at about 60Hz and
every other frame is all black (issue doesn't happen in the BIOS-emulation
mode
on the same kernel).

I'll give a newer kernel a try.

Here's from the successful load:

Aug 29 23:50:09 wedge kernel: [  366.044062] [drm] hdmi device  not found 1 0 1
Aug 29 23:50:09 wedge kernel: [  366.044343] nouveau  [  DEVICE][0000:01:00.0]
BOOT0  : 0x084700a2
Aug 29 23:50:09 wedge kernel: [  366.044346] nouveau  [  DEVICE][0000:01:00.0]
Chipset: G84 (NV84)
Aug 29 23:50:09 wedge kernel: [  366.044348] nouveau  [  DEVICE][0000:01:00.0]
Family : NV50
Aug 29 23:50:09 wedge kernel: [  366.048106] nouveau  [   VBIOS][0000:01:00.0]
image: vbios.rom
Aug 29 23:50:09 wedge kernel: [  366.048159] nouveau  [   VBIOS][0000:01:00.0]
... appears to be valid
Aug 29 23:50:09 wedge kernel: [  366.048284] nouveau  [   VBIOS][0000:01:00.0]
BIT signature found
Aug 29 23:50:09 wedge kernel: [  366.048287] nouveau  [   VBIOS][0000:01:00.0]
version 60.84.49.03.00
Aug 29 23:50:09 wedge kernel: [  366.068374] nouveau 0000:01:00.0: irq 48 for
MSI/MSI-X
Aug 29 23:50:09 wedge kernel: [  366.068393] nouveau  [     PMC][0000:01:00.0]
MSI interrupts enabled
Aug 29 23:50:09 wedge kernel: [  366.068435] nouveau  [     PFB][0000:01:00.0]
RAM type: GDDR3
Aug 29 23:50:09 wedge kernel: [  366.068438] nouveau  [     PFB][0000:01:00.0]
RAM size: 128 MiB
Aug 29 23:50:09 wedge kernel: [  366.068440] nouveau  [     PFB][0000:01:00.0] 
  ZCOMP: 1892 tags
Aug 29 23:50:09 wedge kernel: [  366.077496] nouveau  [    VOLT][0000:01:00.0]
GPU voltage: 1130000uv
Aug 29 23:50:09 wedge kernel: [  366.101061] nouveau  [  PTHERM][0000:01:00.0]
FAN control: none / external
Aug 29 23:50:09 wedge kernel: [  366.101070] nouveau  [  PTHERM][0000:01:00.0]
fan management: automatic
Aug 29 23:50:09 wedge kernel: [  366.101074] nouveau  [  PTHERM][0000:01:00.0]
internal sensor: yes
Aug 29 23:50:09 wedge kernel: [  366.101082] nouveau  [     CLK][0000:01:00.0]
20: core 169 MHz shader 338 MHz memory 100 MHz
Aug 29 23:50:09 wedge kernel: [  366.101086] nouveau  [     CLK][0000:01:00.0]
21: core 283 MHz shader 566 MHz memory 297 MHz
Aug 29 23:50:09 wedge kernel: [  366.101090] nouveau  [     CLK][0000:01:00.0]
22: core 375 MHz shader 750 MHz memory 502 MHz
Aug 29 23:50:09 wedge kernel: [  366.101093] nouveau  [     CLK][0000:01:00.0]
23: core 470 MHz shader 940 MHz memory 635 MHz
Aug 29 23:50:09 wedge kernel: [  366.101136] nouveau  [     CLK][0000:01:00.0]
--: core 275 MHz shader 550 MHz memory 302 MHz
Aug 29 23:50:09 wedge kernel: [  366.101287] [TTM] Zone  kernel: Available
graphics memory: 2022336 kiB
Aug 29 23:50:09 wedge kernel: [  366.101289] [TTM] Initializing pool allocator
Aug 29 23:50:09 wedge kernel: [  366.101295] [TTM] Initializing DMA pool
allocator
Aug 29 23:50:09 wedge kernel: [  366.101306] nouveau  [     DRM] VRAM: 128 MiB
Aug 29 23:50:09 wedge kernel: [  366.101308] nouveau  [     DRM] GART: 1048576
MiB
Aug 29 23:50:09 wedge kernel: [  366.101312] nouveau  [     DRM] TMDS table
version 2.0
Aug 29 23:50:09 wedge kernel: [  366.101315] nouveau  [     DRM] DCB version
4.0
Aug 29 23:50:09 wedge kernel: [  366.101317] nouveau  [     DRM] DCB outp 00:
01000123 00010034
Aug 29 23:50:09 wedge kernel: [  366.101320] nouveau  [     DRM] DCB outp 01:
02011210 00000028
Aug 29 23:50:09 wedge kernel: [  366.101322] nouveau  [     DRM] DCB outp 02:
02011212 00010030
Aug 29 23:50:09 wedge kernel: [  366.101324] nouveau  [     DRM] DCB outp 03:
01011211 0080c070
Aug 29 23:50:09 wedge kernel: [  366.101327] nouveau  [     DRM] DCB conn 00:
0040
Aug 29 23:50:09 wedge kernel: [  366.101330] nouveau  [     DRM] DCB conn 01:
1120
Aug 29 23:50:09 wedge kernel: [  366.118124] nouveau W[     DRM] unknown
connector type 20
Aug 29 23:50:09 wedge kernel: [  366.118165] nouveau W[     DRM] failed to
create encoder 0/1/0: -19
Aug 29 23:50:09 wedge kernel: [  366.118168] [drm] Supports vblank timestamp
caching Rev 2 (21.10.2013).
Aug 29 23:50:09 wedge kernel: [  366.118169] [drm] No driver support for vblank
timestamp query.
Aug 29 23:50:09 wedge kernel: [  366.135710] nouveau  [     DRM] MM: using
CRYPT for buffer copies
Aug 29 23:50:09 wedge kernel: [  366.186174] nouveau  [     DRM] allocated
1440x900 fb: 0x60000, bo ffff8800368e4c00
Aug 29 23:50:09 wedge kernel: [  366.186291] fbcon: nouveaufb (fb0) is primary
device
Aug 29 23:50:11 wedge kernel: [  367.253708] Console: switching to colour frame
buffer device 180x56
Aug 29 23:50:11 wedge kernel: [  367.255103] nouveau 0000:01:00.0: fb0:
nouveaufb frame buffer device
Aug 29 23:50:11 wedge kernel: [  367.255106] nouveau 0000:01:00.0: registered
panic notifier
Aug 29 23:50:11 wedge kernel: [  367.255112] [drm] Initialized nouveau 1.1.2
20120801 for 0000:01:00.0 on minor 0

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150830/a6bebfd2/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #10 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Jeremy Huddleston from comment #9)
> BTW, copying /sys/kernel/debug/dri/0/vbios.rom to /lib/firmware when in
> BIOS-emulation mode has allowed me to get nouveau loaded when in pure EFI
> mode via:
> 
> $ sudo modprobe nouveau config=NvBios=vbios.rom
Hmmm... looking at your logs it doesn't appear to get executed. Or perhaps
nouveau printed different things with 3.13. Try doing like

config=NvBios=vbios.rom,NvForcePost=1

which should force it to exec the vbios and hopefully reset the card to a more
expected state.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150830/ca635550/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #11 from Jeremy Huddleston <jeremyhu at freedesktop.org> ---
Sweet.  Thanks for the help.  So with 'sudo modprobe nouveau
config=NvBios=vbios.rom,NvForcePost=1', I'm seeing things working great
so far.
 The kernel logging from the initialization is shown below.

So now that *I'm* up and running, what can we do to help out Joe User here? 
I'll try out a newer kernel to see if NvForcePost=1 is still required, and
if
not, maybe we'll need a quirk.  And what can we do to get the firmware for
Joe
User?

Aug 30 23:28:30 wedge kernel: [  124.139997] [drm] Initialized drm 1.1.0
20060810
Aug 30 23:28:30 wedge kernel: [  124.174617] wmi: Mapper loaded
Aug 30 23:28:30 wedge kernel: [  124.245291] checking generic (c0030000 710000)
vs hw (c0000000 10000000)
Aug 30 23:28:30 wedge kernel: [  124.245295] fb: conflicting fb hw usage
nouveaufb vs EFI VGA - removing generic driver
Aug 30 23:28:30 wedge kernel: [  124.245377] Console: switching to colour dummy
device 80x25
Aug 30 23:28:30 wedge kernel: [  124.245495] nouveau 0000:01:00.0: enabling
device (0006 -> 0007)
Aug 30 23:28:30 wedge kernel: [  124.245734] [drm] hdmi device  not found 1 0 1
Aug 30 23:28:30 wedge kernel: [  124.246032] nouveau  [  DEVICE][0000:01:00.0]
BOOT0  : 0x084700a2
Aug 30 23:28:30 wedge kernel: [  124.246035] nouveau  [  DEVICE][0000:01:00.0]
Chipset: G84 (NV84)
Aug 30 23:28:30 wedge kernel: [  124.246038] nouveau  [  DEVICE][0000:01:00.0]
Family : NV50
Aug 30 23:28:30 wedge kernel: [  124.265240] nouveau  [   VBIOS][0000:01:00.0]
image: vbios.rom
Aug 30 23:28:30 wedge kernel: [  124.265323] nouveau  [   VBIOS][0000:01:00.0]
... appears to be valid
Aug 30 23:28:30 wedge kernel: [  124.265489] nouveau  [   VBIOS][0000:01:00.0]
BIT signature found
Aug 30 23:28:30 wedge kernel: [  124.265495] nouveau  [   VBIOS][0000:01:00.0]
version 60.84.49.03.00
Aug 30 23:28:30 wedge kernel: [  124.265707] nouveau  [   VBIOS][0000:01:00.0]
running init tables
Aug 30 23:28:31 wedge kernel: [  124.326633] nouveau 0000:01:00.0: irq 48 for
MSI/MSI-X
Aug 30 23:28:31 wedge kernel: [  124.326656] nouveau  [     PMC][0000:01:00.0]
MSI interrupts enabled
Aug 30 23:28:31 wedge kernel: [  124.326708] nouveau  [     PFB][0000:01:00.0]
RAM type: GDDR3
Aug 30 23:28:31 wedge kernel: [  124.326712] nouveau  [     PFB][0000:01:00.0]
RAM size: 128 MiB
Aug 30 23:28:31 wedge kernel: [  124.326716] nouveau  [     PFB][0000:01:00.0] 
  ZCOMP: 1892 tags
Aug 30 23:28:31 wedge kernel: [  124.335737] nouveau  [    VOLT][0000:01:00.0]
GPU voltage: 1130000uv
Aug 30 23:28:31 wedge kernel: [  124.359793] nouveau  [  PTHERM][0000:01:00.0]
FAN control: none / external
Aug 30 23:28:31 wedge kernel: [  124.359802] nouveau  [  PTHERM][0000:01:00.0]
fan management: automatic
Aug 30 23:28:31 wedge kernel: [  124.359806] nouveau  [  PTHERM][0000:01:00.0]
internal sensor: yes
Aug 30 23:28:31 wedge kernel: [  124.359832] nouveau  [     CLK][0000:01:00.0]
20: core 169 MHz shader 338 MHz memory 100 MHz
Aug 30 23:28:31 wedge kernel: [  124.359836] nouveau  [     CLK][0000:01:00.0]
21: core 283 MHz shader 566 MHz memory 297 MHz
Aug 30 23:28:31 wedge kernel: [  124.359840] nouveau  [     CLK][0000:01:00.0]
22: core 375 MHz shader 750 MHz memory 502 MHz
Aug 30 23:28:31 wedge kernel: [  124.359843] nouveau  [     CLK][0000:01:00.0]
23: core 470 MHz shader 940 MHz memory 635 MHz
Aug 30 23:28:31 wedge kernel: [  124.359883] nouveau  [     CLK][0000:01:00.0]
--: core 275 MHz shader 550 MHz memory 300 MHz
Aug 30 23:28:31 wedge kernel: [  124.360073] [TTM] Zone  kernel: Available
graphics memory: 2022336 kiB
Aug 30 23:28:31 wedge kernel: [  124.360075] [TTM] Initializing pool allocator
Aug 30 23:28:31 wedge kernel: [  124.360080] [TTM] Initializing DMA pool
allocator
Aug 30 23:28:31 wedge kernel: [  124.360091] nouveau  [     DRM] VRAM: 128 MiB
Aug 30 23:28:31 wedge kernel: [  124.360093] nouveau  [     DRM] GART: 1048576
MiB
Aug 30 23:28:31 wedge kernel: [  124.360098] nouveau  [     DRM] TMDS table
version 2.0
Aug 30 23:28:31 wedge kernel: [  124.360100] nouveau  [     DRM] DCB version
4.0
Aug 30 23:28:31 wedge kernel: [  124.360103] nouveau  [     DRM] DCB outp 00:
01000123 00010034
Aug 30 23:28:31 wedge kernel: [  124.360105] nouveau  [     DRM] DCB outp 01:
02011210 00000028
Aug 30 23:28:31 wedge kernel: [  124.360107] nouveau  [     DRM] DCB outp 02:
02011212 00010030
Aug 30 23:28:31 wedge kernel: [  124.360110] nouveau  [     DRM] DCB outp 03:
01011211 0080c070
Aug 30 23:28:31 wedge kernel: [  124.360112] nouveau  [     DRM] DCB conn 00:
0040
Aug 30 23:28:31 wedge kernel: [  124.360115] nouveau  [     DRM] DCB conn 01:
1120
Aug 30 23:28:31 wedge kernel: [  124.376927] nouveau W[     DRM] unknown
connector type 20
Aug 30 23:28:31 wedge kernel: [  124.376965] nouveau W[     DRM] failed to
create encoder 0/1/0: -19
Aug 30 23:28:31 wedge kernel: [  124.376967] [drm] Supports vblank timestamp
caching Rev 2 (21.10.2013).
Aug 30 23:28:31 wedge kernel: [  124.376969] [drm] No driver support for vblank
timestamp query.
Aug 30 23:28:31 wedge kernel: [  124.394728] nouveau  [     DRM] MM: using
CRYPT for buffer copies
Aug 30 23:28:31 wedge kernel: [  124.447363] nouveau  [     DRM] allocated
1440x900 fb: 0x60000, bo ffff8800a2cb0000
Aug 30 23:28:31 wedge kernel: [  124.450045] fbcon: nouveaufb (fb0) is primary
device
Aug 30 23:28:31 wedge kernel: [  124.507258] Console: switching to colour frame
buffer device 180x56
Aug 30 23:28:31 wedge kernel: [  124.551887] nouveau 0000:01:00.0: fb0:
nouveaufb frame buffer device
Aug 30 23:28:31 wedge kernel: [  124.551890] nouveau 0000:01:00.0: registered
panic notifier
Aug 30 23:28:31 wedge kernel: [  124.551896] [drm] Initialized nouveau 1.1.2
20120801 for 0000:01:00.0 on minor 0

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150831/2934eb47/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #12 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Jeremy Huddleston Sequoia from comment #11)
> So now that *I'm* up and running, what can we do to help out Joe User
here?
> I'll try out a newer kernel to see if NvForcePost=1 is still required,
and
> if not, maybe we'll need a quirk.  And what can we do to get the
firmware
> for Joe User?
Did you have a chance to do that? Not sure what can be done for Joe User here
-- we need the vbios. No vbios = no go. VBIOS has info about what connectors
are on the board, how they're hooked up, any scripts that need to be run to
init the card (necessary on resume), scripts to run when changing modes, etc.

It's likely that the EFI bios brings the card up enough to fool nouveau into
thinking that the card is initialized (which it is), but it sets *something* up
differently and nouveau doesn't reset it properly. But the VBIOS init
routines
do. So I think Joe User will be stuck having to do the NvForcePost. [You can
look at what all vbios init does with the help of nvbios in envytools.]

Now in order to operate the screen, EFI needs the VBIOS as well. So it has it
somewhere... the usual thing to do is to stick it at the top of PRAMIN for the
OS to be able to read it down the line. Not sure if you have access to modify
something like that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151022/8ecab8fb/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #13 from Jeremy Huddleston Sequoia <jeremyhu at
freedesktop.org> ---
After upgrading to Ubuntu 16.04.1, something seems off, and I'm having
trouble
locking it down.  I'm still using the exact same kernel that I was before
the
upgrade (4.4.6), and I've got the firmware in /lib/firmware/vbios.rom with
the
following module options set in /etc/modprobe/nouveau.conf:

    options nouveau config=NvBios=vbios.rom,NvForcePost=1 debug=VBIOS=debug

When nouveau loads in pure EFI mode, it logs the following:

[    1.948618] fb: switching to nouveaufb from EFI VGA
[    1.953188] nouveau 0000:01:00.0: enabling device (0002 -> 0003)
[    1.953230] nouveau 0000:01:00.0: NVIDIA G84 (084700a2)
[    1.953353] nouveau 0000:01:00.0: Direct firmware load for vbios.rom failed
with error -2
[    1.953362] nouveau 0000:01:00.0: Falling back to user helper
[   61.952174] nouveau 0000:01:00.0: bios: vbios.rom invalid
[   61.953062] nouveau 0000:01:00.0: Invalid ROM contents
[   61.953079] nouveau 0000:01:00.0: bios: unable to locate usable image
[   61.953087] nouveau 0000:01:00.0: bios ctor failed, -22
[   61.953097] nouveau: probe of 0000:01:00.0 failed with error -22

When nouveau loads in BIOS emulation mode, it logs the following:

[    1.797074] nouveau 0000:01:00.0: NVIDIA G84 (084700a2)
[    1.797257] nouveau 0000:01:00.0: Direct firmware load for vbios.rom failed
with error -2
[    1.797342] nouveau 0000:01:00.0: Falling back to user helper
[   61.796123] nouveau 0000:01:00.0: bios: vbios.rom invalid
[   61.813299] nouveau 0000:01:00.0: bios: version 60.84.49.03.00
[   61.875766] nouveau 0000:01:00.0: fb: 128 MiB GDDR3
[   61.926834] nouveau 0000:01:00.0: DRM: VRAM: 128 MiB
[   61.926922] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
[   61.927012] nouveau 0000:01:00.0: DRM: TMDS table version 2.0
[   61.927101] nouveau 0000:01:00.0: DRM: DCB version 4.0
[   61.927189] nouveau 0000:01:00.0: DRM: DCB outp 00: 01000123 00010034
[   61.927279] nouveau 0000:01:00.0: DRM: DCB outp 01: 02011210 00000028
[   61.927369] nouveau 0000:01:00.0: DRM: DCB outp 02: 02011212 00010030
[   61.927459] nouveau 0000:01:00.0: DRM: DCB outp 03: 01011211 0080c070
[   61.927547] nouveau 0000:01:00.0: DRM: DCB conn 00: 0040
[   61.927636] nouveau 0000:01:00.0: DRM: DCB conn 01: 1120
[   61.936343] nouveau 0000:01:00.0: DRM: unknown connector type 20
[   61.936495] nouveau 0000:01:00.0: DRM: failed to create encoder 0/1/0: -19
[   61.953987] nouveau 0000:01:00.0: DRM: MM: using CRYPT for buffer copies
[   62.001097] nouveau 0000:01:00.0: DRM: allocated 1440x900 fb: 0x50000, bo
ffff880036c5a800
[   62.001309] fbcon: nouveaufb (fb0) is primary device
[   62.091280] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[   62.096133] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on
minor 0

As you can see, the loading of /lib/firmware/vbios.rom fails with ENOENT, but
it's certainly there.  I verified that /lib/firmware/vbios.rom is exactly
the
same as /sys/kernel/debug/dri/0/vbios.rom in BIOS-emulation mode.

Odd... gonna have to dig into it a bit more later, but if you have any ideas,
I'd appreciate them.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160814/d46dd2bc/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #14 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Jeremy Huddleston Sequoia from comment #13)
> As you can see, the loading of /lib/firmware/vbios.rom fails with ENOENT,
> but it's certainly there.  I verified that /lib/firmware/vbios.rom is
> exactly the same as /sys/kernel/debug/dri/0/vbios.rom in BIOS-emulation
mode.
> 
> Odd... gonna have to dig into it a bit more later, but if you have any
> ideas, I'd appreciate them.
The usual situation is that it's not there, and so ENOENT is returned. Note
that it has to be there when nouveau loads, not at some later point in time,
when, say, the real root partition is mounted. To maximize confusion, distro
kernel builds like to load modules from initrd, and if nouveau is loaded there,
you'll want to ensure that your vbios.rom is available from there as well.

If you build your own kernel and don't plan on soldering in random hardware
(esp not new disk controllers) into your laptop without first doing a rebuild,
you can stick the vbios.rom directly into the kernel and avoid this frustration
via CONFIG_EXTRA_FIRMWARE or something similar.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160814/1552a671/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

--- Comment #15 from Jeremy Huddleston Sequoia <jeremyhu at
freedesktop.org> ---
Yeah, it seems that it's getting loaded from the initial ramdisk now for
some
reason, where it wasn't in the past.  Shoving it onto the initrd solved the
issue.

Oddly, there is still documentation to the contrary, that the fb isn't
initialized until after the root filesystem is loaded, but it looks like
that's
out of date.  Oh well, problem solved.  Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160814/d4c41922/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=91779

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #16 from Martin Peres <martin.peres at free.fr> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/211.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/bd9fd3f4/attachment-0001.html>