[Nouveau] [Bug 98240] Kernel module fails to load on HP Pavilion V3A33AV laptop.

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Oct 14 02:58:19 UTC 2016


--- Comment #12 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Sergey Okhapkin from comment #11)
> [ 3234.532656] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch
> - Found [Buffer], ACPI requires [Package] (20160422/nsarguments-95)
> [ 3234.532743] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type
> mismatch - Found [Buffer], ACPI requires [Package] (20160422/nsarguments-95)
> [ 3234.532849] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type
> mismatch - Found [Buffer], ACPI requires [Package] (20160422/nsarguments-95)
> [ 3234.533890] pci 0000:01:00.0: optimus capabilities: enabled, status
> dynamic power, 
> [ 3234.533897] VGA switcheroo: detected Optimus DSM method
> \_SB_.PCI0.PEG0.PEGP handle
> [ 3234.533898] nouveau: detected PR support, will not use DSM
> [ 3234.534005] nouveau 0000:01:00.0: NVIDIA GM107 (1171b0a2)
> [ 3234.538042] retrieving _ROM off: 0x0, len: 0x1000, ret: 0x1000
> [ 3234.539278] retrieving _ROM off: 0x1000, len: 0xf000, ret: 0xf000

Grrr. Well, that's the issue. It only returns 0x1000 worth of data, but claims
to return a buffer sized to 0xf000. And I think I see why:

            Name (VROM, Buffer (Local1)
                 0x00                                             /* . */

Which allocates the VROM buffer to be 0xf000 sized. At the end, that buffer is
filled with

            Mid (Local5, Local0, Local1, VROM) /*
            Return (VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */

However I suspect that Mid() doesn't actually *replace* the object. And this is
what acpi_ex_store_buffer_to_buffer() does on Linux - as long as less data is
stored, the length of the object appears untouched.

So ... given this implementation, I'm not sure how we can reliably skip the
"fast" ACPI read. Ben, thoughts?

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/20161014/0ad0027e/attachment-0001.html>

More information about the Nouveau mailing list