(Please tell me what information to attach and I will attach it) HP Pavilion 15 (Skylake) with Maxwell 950M fails to load the whole BIOS. The ACPI "fast" method is selected first, which partially loads the BIOS with a score of 6, which prevents the ACPI "slow" method which actually works from ever being attempted. To work around this I changed the name of the ACPI methods to "ACPIF" and "ACPIS" respectively, so that I could issue this parameter to target the slow method directly: nouveau.config=NvBios=ACPIS Kernel log from trying to load nouveau normally of kernel 4.9.0: Jan 21 17:47:33 achpee2 kernel: [ 1835.339060] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95) Jan 21 17:47:33 achpee2 kernel: [ 1835.339093] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95) Jan 21 17:47:33 achpee2 kernel: [ 1835.339132] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95) Jan 21 17:47:33 achpee2 kernel: [ 1835.339544] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, Jan 21 17:47:33 achpee2 kernel: [ 1835.339547] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle Jan 21 17:47:33 achpee2 kernel: [ 1835.339689] nouveau 0000:01:00.0: NVIDIA GM107 (1171a0a2) Jan 21 17:47:33 achpee2 kernel: [ 1835.339734] nouveau 0000:01:00.0: pci: MSI enabled Jan 21 17:47:33 achpee2 kernel: [ 1835.339736] nouveau 0000:01:00.0: bios: trying PRAMIN... Jan 21 17:47:33 achpee2 kernel: [ 1835.339748] nouveau 0000:01:00.0: bios: ... not enabled Jan 21 17:47:33 achpee2 kernel: [ 1835.339749] nouveau 0000:01:00.0: bios: trying PROM... Jan 21 17:47:33 achpee2 kernel: [ 1835.344944] nouveau 0000:01:00.0: bios: 00000000: ROM signature (0000) unknown Jan 21 17:47:33 achpee2 kernel: [ 1835.344945] nouveau 0000:01:00.0: bios: image 0 invalid Jan 21 17:47:33 achpee2 kernel: [ 1835.344950] nouveau 0000:01:00.0: bios: scored 0 Jan 21 17:47:33 achpee2 kernel: [ 1835.344951] nouveau 0000:01:00.0: bios: trying ACPI... Jan 21 17:47:33 achpee2 kernel: [ 1835.345417] nouveau 0000:01:00.0: bios: 00000000: type 00, 65536 bytes Jan 21 17:47:33 achpee2 kernel: [ 1835.345904] nouveau 0000:01:00.0: bios: 00000000: checksum failed Jan 21 17:47:33 achpee2 kernel: [ 1835.346372] nouveau 0000:01:00.0: bios: 00010000: type e0, 37376 bytes Jan 21 17:47:33 achpee2 kernel: [ 1835.346830] nouveau 0000:01:00.0: bios: 00019200: ROM signature (0000) unknown Jan 21 17:47:33 achpee2 kernel: [ 1835.346832] nouveau 0000:01:00.0: bios: image 2 invalid Jan 21 17:47:33 achpee2 kernel: [ 1835.346833] nouveau 0000:01:00.0: bios: scored 6 Jan 21 17:47:33 achpee2 kernel: [ 1835.346834] nouveau 0000:01:00.0: bios: using image from ACPI Jan 21 17:47:33 achpee2 kernel: [ 1835.346946] nouveau 0000:01:00.0: bios: BIT signature found Jan 21 17:47:33 achpee2 kernel: [ 1835.346949] nouveau 0000:01:00.0: bios: version 82.07.9b.00.d1 Jan 21 17:47:33 achpee2 kernel: [ 1835.346953] nouveau 0000:01:00.0: bios: DCB contains no useful data Jan 21 17:47:33 achpee2 kernel: [ 1835.346954] nouveau 0000:01:00.0: bios: DCB contains no useful data Jan 21 17:47:33 achpee2 kernel: [ 1835.346956] nouveau 0000:01:00.0: mxm: no VBIOS data, nothing to do Jan 21 17:47:33 achpee2 kernel: [ 1835.346970] nouveau 0000:01:00.0: bios: DCB contains no useful data
By the way, I am not proposing that my workaround is sufficient, though it is beneficial for a user to be able to directly work around via trying different module options. I think we need to fix BIOS retrieval scoring such that if there is a ROM signature and/or checksum failure, the score is heavily penalized in favor of attempting the slow retrieval.
So the *idea* is that the fast method should fail in your case, because it should require the checksum to match. Hmmm... the logic was added in Ben's tree in commit https://github.com/skeggsb/nouveau/commit/2f693ef05fc8ca4627535a85900d8563b66032e9 However I can't see that commit in the upstream kernel. That's rather odd. Either way, can you try applying that patch and seeing if that forces the fast method to error out?
Er wait, that commit is there upstream (5dc7f4aa9d84ea94b54a9bfcef095f0289f1ebda). Not sure what I was looking at locally. Either way... would be good to figure out why the require_checksum logic isn't working.
And now I notice that you're on kernel v4.9 - try v4.10-rcN and see if that improves the situation -- or at least apply 5dc7f4aa9d84ea94b54a9bfcef095f0289f1ebda to your tree.
Created attachment 129310 [details] dmesg 4.10-rc5
Indeed, it does seem to work on 4.10-rc5. But there is a weird FAULT message, in case that is of interest?
-- 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/320.
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.