Nouveau - Feb 2014 - [Bug 75511] New: Screen freezes during boot with an 3.13 kernel (Arch Linux)

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

          Priority: medium
            Bug ID: 75511
          Assignee: nouveau at lists.freedesktop.org
           Summary: Screen freezes during boot with an 3.13 kernel (Arch
                    Linux)
        QA Contact: xorg-team at lists.x.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: cllorenz at uni-potsdam.de
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: git
         Component: Driver/nouveau
           Product: xorg

Created attachment 94735
  --> https://bugs.freedesktop.org/attachment.cgi?id=94735&action=edit
dmesg output

During boot (with late module load of nouveau) the screen freezes at about the
time where normally a glitch occurs and the resolution is set much higher. It
will not recover from this state and the machine must be restarted/powered off
via ctrl+alt+del or the power button. The journald log shows that systemd
booted normally. I circumvented the problem by downgrading to kernel 3.12 where
everything works fine. Here are the Arch Linux package versions of the
configuration when the error occurs:

kernel - 3.13.5-1
xf86-video-nouveau - 1.0.10-2
nouveau-dri - 10.0.3-1
mesa - 10.0.3-1
xorg-server - 1.15.0-5
libdrm - 2.4.52-1


The dmesg output in the attachment was taken during a boot (as last systemd
target before gnome) with the problem described above.

-- 
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/20140225/97d8adcc/attachment.html>

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

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Am I correct that you have 2 ~identical GK107 cards in there? Unfortunately it
appears that the VBIOS for the first one is corrupt. It's being retrieved
from
PCIROM, which more often than not actually doesn't have what we want
(despite
it passing the checksum). Note that your 2nd card appears to init correctly,
and it gets its VBIOS from the PROM. Not sure where the VBIOS for your first
card lives...

I assume that the VBIOS error about the unknown opcode exists in 3.12 as well?
Except that 3.13 made that an error. Who knows, maybe it's a legitimately
unknown opcode... could you grab a copy of envytools and retrieve the VBIOSes
for both of your cards with nvagetbios? i.e.

nvagetbios -c 0 -s PROM > vbios-0.rom
nvagetbios -c 1 -s PROM > vbios-1.rom

If the first one fails, also try PRAMIN instead of PROM (I assume -c 1 will
work just fine since nouveau is able to find it without problem). If that still
fails, try to get it from the pci rom directly:

echo 1 > /sys/bus/pci/devices/0000:01:00.0/rom
cat /sys/bus/pci/devices/0000:01:00.0/rom > vbios-0.rom
echo 0 > /sys/bus/pci/devices/0000:01:00.0/rom

(all of this as root, obviously.)

-- 
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/20140225/4b99cb33/attachment.html>

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

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Screen freezes during boot  |[NVE7] Unknown opcode in
                   |with an 3.13 kernel (Arch   |VBIOS on one of 2 cards,
                   |Linux)                      |fails boot on 3.13+

-- 
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/20140225/47dca515/attachment.html>

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

--- Comment #2 from Claas Lorenz <cllorenz at uni-potsdam.de> ---
Created attachment 94736
  --> https://bugs.freedesktop.org/attachment.cgi?id=94736&action=edit
output of "cat /sys/bus/pci/devices/0000:01:00.0/rom > vbios-0.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/20140225/822bc7aa/attachment-0001.html>

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

--- Comment #3 from Claas Lorenz <cllorenz at uni-potsdam.de> ---
Created attachment 94737
  --> https://bugs.freedesktop.org/attachment.cgi?id=94737&action=edit
output of "nvagetbios -c 1 -s PROM > vbios-1.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/20140225/6d81a8dd/attachment.html>

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

--- Comment #4 from Claas Lorenz <cllorenz at uni-potsdam.de> ---
Created attachment 94738
  --> https://bugs.freedesktop.org/attachment.cgi?id=94738&action=edit
output of "nvagetbios -c 0 -s PRAMIN > vbios-0.ramin"

-- 
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/20140225/0fda7437/attachment.html>

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

--- Comment #5 from Claas Lorenz <cllorenz at uni-potsdam.de> ---
Created attachment 94739
  --> https://bugs.freedesktop.org/attachment.cgi?id=94739&action=edit
output of "nvagetbios -c 1 -s PRAMIN > vbios-1.ramin"

-- 
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/20140225/235b9627/attachment.html>

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

--- Comment #6 from Claas Lorenz <cllorenz at uni-potsdam.de> ---
Wow, that was fast. Yes, I have indeed two cards in there and yes, the kernel
message also occured in all earlier kernels I used (at least since 3.9.8 when I
got my laptop).
>From the attachments you see that I had to go the direct pci way to get the
vbios-0.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/20140225/f672e2b0/attachment.html>

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

--- Comment #7 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Well, analyzing the vbios from the second (working) card, what I see is:

Init script 0 at 0x83e0:
0x83e0: 8c                                             UNK8C
0x83e1: 7a 00 02 00 00 20 20 00 00                     ZM_REG   R[0x000200]
0x00002020
0x83ea: 33 14                                          REPEAT   0x14
0x83ec: 6e 00 00 00 00 ff ff ff ff 00 00 00 00         NV_REG   R[0x000000]
&0xffffffff |= 0x00000000
0x83f9: 36                                             END_REPEAT
0x83fa: 7a 00 02 00 00 25 21 01 40                     ZM_REG   R[0x000200]
0x40012125
0x8403: 7a c0 24 12 00 00 00 00 00                     ZM_REG   R[0x1224c0]
0x00000000
0x840c: 7a 40 26 12 00 00 00 00 00                     ZM_REG   R[0x122640]
0x00000000
0x8415: 6e 00 24 02 00 ff f7 ff ff 00 08 00 00         NV_REG   R[0x022400]
&0xfffff7ff |= 0x00000800
and so on

Looking at the pci rom of the first (non-working) card, I see:

Init script 0 at 0x83e0:
0x83e0: 42                                             ???
0x83e1: 66                                             CONFIGURE_MEM
0x83e2: ad                                             ???
0x83e3: 66                                             CONFIGURE_MEM
0x83e4: c1                                             ???
0x83e5: c8                                             ???

As you can see the bytes are all different, I'm pretty sure this is 16-bit
real
mode x86 code:

$ udcli -16 -x
42 66 ad 66 c1 c8 10 ee 66 c1 c0 08 ee 66 c1 c0 08 ee e2 ed 1f 66 61
0000000000000000 42               inc dx                  
0000000000000001 66ad             lodsd                   
0000000000000003 66c1c810         ror eax, 0x10           
0000000000000007 ee               out dx, al              
0000000000000008 66c1c008         rol eax, 0x8            
000000000000000c ee               out dx, al              
000000000000000d 66c1c008         rol eax, 0x8            
0000000000000011 ee               out dx, al              
0000000000000012 e2ed             loop 0x1                
0000000000000014 1f               pop ds                  
0000000000000015 6661             popad                   

Otherwise the bioses appear identical... at least the DCB and GPIO tables match
up. So I'd recommend simply grabbing that good vbios-1.rom, sticking it in
/lib/firmware (in the initrd if that's where nouveau is loaded from), and
adding nouveau.config=NvBios=vbios-1.rom which will use that as the vbios
instead of trying to read it from the card.

I'm not extremely happy with this solution, of course, but it's the
fastest way
to get something that works.

Can you provide any relevant details about your system? These appear to both be
mobile chips, it's pretty uncommon to have that in a single system. Would
you
also mind providing an acpidump? Perhaps the vbios for the first card is hiding
in ACPI somewhere unexpected.

-- 
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/20140225/5d74f377/attachment.html>

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

--- Comment #8 from Claas Lorenz <cllorenz at uni-potsdam.de> ---
I have a Lenovo Y500 with two GeForce GT 650M cards. I think this laptop was
intended as medium class gaming machine where two graphic cards make sense
somehow. Here is the lspci:

01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M]
(rev a1)
02:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M]
(rev a1)

Since I do not use it for gaming, I never cared about having a second card. I
put the working vbios to /lib/firmware and added the config to the kernel line,
as you suggested, and it works fine now (also with 3.13). Thank you very much
for your help!

I also attached my acpidump, I hope that helps.

-- 
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/20140226/8c75e4b3/attachment.html>

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

--- Comment #9 from Claas Lorenz <cllorenz at uni-potsdam.de> ---
Created attachment 94782
  --> https://bugs.freedesktop.org/attachment.cgi?id=94782&action=edit
output of acpidump

-- 
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/20140226/fb8151d1/attachment.html>

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

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[NVE7] Unknown opcode in    |[NVE7] Lenovo Y500 with 2x
                   |VBIOS on one of 2 cards,    |GT650M, first card gets
                   |fails boot on 3.13+         |wrong vbios, fails boot on
                   |                            |3.13+

-- 
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/20140226/02c6df25/attachment.html>

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

--- Comment #10 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Would you mind trying to edit nouveau_acpi.c:nouveau_acpi_rom_supported and
removing the check for dsm_detected and optimus_detected? (And then booting
that without the NvBios setting.) I think the situation is that those aren't
set, but we should still get the rom from ACPI for that first card.

-- 
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/20140326/20cb3423/attachment.html>

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

Ilia Mirkin <imirkin at alum.mit.edu> changed:

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

--- Comment #11 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #10)
> Would you mind trying to edit nouveau_acpi.c:nouveau_acpi_rom_supported and
> removing the check for dsm_detected and optimus_detected? (And then booting
> that without the NvBios setting.) I think the situation is that those
aren't
> set, but we should still get the rom from ACPI for that first card.
A patch to do this was merged a while back, and backported to stable kernels.
Pretty sure it will fix the issue for you (without needing the NvBios thing).
Feel free to re-open if not.

-- 
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/20140821/651ab122/attachment.html>