| Summary: | [NV110] HP Pavilion 15 with Maxwell 950M fails to read BIOS (fix included) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Ryan Underwood <nemesis> | ||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | major | ||||||
| Priority: | medium | ||||||
| Version: | unspecified | ||||||
| Hardware: | x86-64 (AMD64) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Ryan Underwood
2017-01-22 04:28:45 UTC
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.