Bug 99372

Summary: Nvidia 640M devinit fails
Product: xorg Reporter: ralala <me>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: NEW --- QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
vbios.rom
none
dmesg.log
none
acpidump
none
dmesg.log none

Description ralala 2017-01-11 23:43:21 UTC
Created attachment 128904 [details]
vbios.rom

I have a VAIO SVS1511C5E laptop and the nouveau driver is not working in kernel versions > 3.16 . (3.19 does not work for me)

From my understanding the ACPI loading of the bios rom fails. I tried other methods as suggested in many other threads (PROM, PRAMIN), but they also fail.
ACPI loading worked in kernel 3.16.

I attach the vbios.rom copied from a booted 3.16 kernel from /sys/kernel/debug/dri/1/vbios.rom and a dmesg log showing the error from kernel 4.10rc3.

As a workaround I am able to load nouveau manually in all kernels by providing the copied vbios.rom as a parameter to the nouveau module.
Comment 1 ralala 2017-01-11 23:45:29 UTC
Created attachment 128905 [details]
dmesg.log

4.10rc3
Comment 2 Ilia Mirkin 2017-01-11 23:46:04 UTC
Please include an acpidump of your system.
Comment 3 Ilia Mirkin 2017-01-11 23:48:01 UTC
Oh, and separately, please include the dmesg of a boot of 4.10-rcN with nouveau.debug=debug when not specifying the "fixed" vbios.rom explicitly.
Comment 4 ralala 2017-01-11 23:59:52 UTC
Created attachment 128906 [details]
acpidump
Comment 5 ralala 2017-01-12 00:00:57 UTC
Created attachment 128907 [details]
dmesg.log

4.10rc3
Comment 6 Ilia Mirkin 2017-01-12 00:20:24 UTC
OK, so ... similar issue as before - it creates a temporary buffer sized to the incoming argument's size, and THEN truncates the size argument. Great.... so we just get the first 4K back with the "fast acpi" method. However at that point, the checksum really oughtn't match. But I don't see the "checksum failed" message. So it does match? Or somehow the second bogus image increases the score to 4? Not sure...

Method (_ROM, 2, NotSerialized)  // _ROM: Read-Only Memory
{
    Local0 = Arg0
    Local1 = Arg1
    Name (VROM, Buffer (Local1)
    {
         0x00                                             /* . */
    })
    If (Local1 > 0x1000)
    {
        Local1 = 0x1000
    }

    If (Arg0 > RVBS)
    {
        Return (VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
    }

    Local2 = (Arg0 + Arg1)
    If (Local2 > RVBS)
    {
        Local1 = (RVBS - Local0)
    }

    If (Local0 < 0x8000)
    {
        Mid (VBS1, Local0, Local1, VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
    }
    Else
    {
        Local0 -= 0x8000
        If (Local0 < 0x8000)
        {
            Mid (VBS2, Local0, Local1, VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
        }
        Else
        {
            Local0 -= 0x8000
            If (Local0 < 0x8000)
            {
                Mid (VBS3, Local0, Local1, VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
            }
            Else
            {
                Local0 -= 0x8000
                If (Local0 < 0x8000)
                {
                    Mid (VBS4, Local0, Local1, VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
                }
            }
        }
    }

    Return (VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
}
Comment 7 Ilia Mirkin 2017-01-12 00:42:59 UTC
Looking through the code, the checksum must be passing. This is surprising.

(a) The returned data is not all 0's, e.g. the bios version is there, etc. [All 0's *would* pass the checksum test.]
(b) The checksum fails for the first 0x1000 bytes being returned.

Something even more nefarious must be going on...

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.