You are not logged in.
linux-firmware 20170217.12987ca-1 now includes some new i915 firmware libraries. I had previously installed these manually as outlined in the XPS 9360 wiki.
/usr/lib/firmware/i915/kbl_guc_ver9_14.bin
/usr/lib/firmware/i915/kbl_huc_ver02_00_1810.bin
With kernel 4.9.11 and the files from linux-firmware, the guc firmware is failing to load. The graphics in this system is the HD620.
[ 18.488576] Setting dangerous option semaphores - tainting kernel
[ 18.488579] Setting dangerous option enable_fbc - tainting kernel
[ 18.488580] Setting dangerous option enable_guc_loading - tainting kernel
[ 18.488581] Setting dangerous option enable_guc_submission - tainting kernel
...
[ 18.537528] [drm] Missing firmware components
[ 18.537529] [drm] Failed to fetch valid GuC firmware from i915/kbl_guc_ver9_14.bin (error 0)
[ 18.538222] [drm] GuC firmware load failed: -5
[ 18.538223] [drm] Falling back from GuC submission to execlist mode
I manually re-downloaded the firmware files from Intel's website, and diff reports a binary difference for only kbl_guc_ver9_14.bin.
When I boot using the manually downloaded one, the GuC firmware loads fine with kernel 4.9.11.
When I revert to the one from linux-firmware, the error persists. Is anyone else able to load the guc firmware from this latest release?
Edit: Seems a byte is missing on the linux-firmware version. I deleted the package from the cache and reinstalled with pacman, and the size remained one byte short, so I don't think this was a one-off local file corruption issue.
Edit2: Tested a few different package servers as well, and they are all short one byte.
Downloaded file
-rw-r--r-- 1 root root 142656 Feb 20 16:01 kbl_guc_ver9_14.bin
linux-firmware file
-rw-r--r-- 1 root root 142655 Feb 19 06:08 kbl_guc_ver9_14.bin
Edit3: This seems like an upstream issue, as the file at kernel.org is also a byte smaller than the version on Intel's website.
Last edited by blahhumbug (2017-02-22 03:24:02)
Offline
I'm having an issue with amdgpu on linux-firmware-20170217. (It's a GPU hang bug when launching X.) Doesn't seem to have been a great package update in general - there's a bug report open of other people having AMDGPU issues on the tracker.
https://bugs.archlinux.org/task/53042?o … us%5B0%5D=
Last edited by GourdCaptain (2017-02-22 16:32:35)
Avatar by Ditey: https://twitter.com/phrobitey
Offline
@blahhumbug,
Did you report an upstream bug?
@GourdCaptain,
Please fix your bugreport link, you appear to have mistakenly posted the version that will trick anyone who clicks on it into inadvertently voting for the bug on your behalf.
...
In general, this is the kind of issue that makes me think "we need more people to run [testing] and catch these things early", note that as a reward for using the testing repos you can get an archweb login and signoff powers.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Whoops, fixed the link. Sorry about that. I'd love to help our more with testing stuff, but the machine in question I kind of need for my job so running Arch already is a bit risky at times, let alone testing.
Avatar by Ditey: https://twitter.com/phrobitey
Offline
@Eschwartz I contacted the upstream contributor to the kernel firmware tree and got back this response.
"The firmware on 01.org is different from linux-firmware.git because of the install script. The firmware on 01.org has an install script that generates the initrd and hence the firmware is ready by the time the kernel is loaded. But the one on linux-firmware.git has no such install script. This fw is meant for OSV's. They package suitably in their distributions. For individual users, 01.org is the place to get the fw from."
This is an area of the kernel and distribution responsibilities that I know nothing about, but it seems that upstream believes this is a downstream problem.
Offline
Although, I never ran any install script from the Intel site download. I just hand copied the .bin and reran mkinitcpio (although I wasn't sure if that was necessary).
Offline
Although, I never ran any install script from the Intel site download. I just hand copied the .bin and reran mkinitcpio (although I wasn't sure if that was necessary).
Probably depends on whether or not you're adding the i915 module to your initramfs for early KMS, and if so, you certainly need to do it since it embeds the firmware. Not a bad idea either way, though.
Avatar by Ditey: https://twitter.com/phrobitey
Offline
That makes sense. I am not doing early KMS as I ran into some stability issues when it was enabled, although that was many kernel versions ago. So I am questioning whether this upstream reply makes any sense and is valid.
But I do know that the .bin in linux-firmware will not load for me. :-)
Last edited by blahhumbug (2017-02-22 22:58:11)
Offline
So I am questioning whether this upstream reply makes any sense and is valid.
Would suggest opening a bug report on the arch bugtracker and attaching the correspondence from upstream to that as well as the earlier details on the issue.
Offline
Whoops, fixed the link. Sorry about that. I'd love to help our more with testing stuff, but the machine in question I kind of need for my job so running Arch already is a bit risky at times, let alone testing.
An eminently reasonable attitude to take. Not everyone can run testing, but I figured people should be prodded into considering whether it is something they are interested in, since I think Arch could really use more testers.
@Eschwartz I contacted the upstream contributor to the kernel firmware tree and got back this response.
"The firmware on 01.org is different from linux-firmware.git because of the install script. The firmware on 01.org has an install script that generates the initrd and hence the firmware is ready by the time the kernel is loaded. But the one on linux-firmware.git has no such install script. This fw is meant for OSV's. They package suitably in their distributions. For individual users, 01.org is the place to get the fw from."
This is an area of the kernel and distribution responsibilities that I know nothing about, but it seems that upstream believes this is a downstream problem.
So what is going on? Does linux-firmware.git ship something and then expect downstream distro packagers to modify it in some manner? (Really weird, and kind of impractical... but as long as they clearly document that the file needs to be modified with X, I guess they are entitled to make strange decisions.)
Didn't you say the downloaded firmware is different on the 01.org site than in linux-firmware.git ... does linux-firmware have the pre-install-script version, or the post-install-script version?
(Also, why on earth would 01.org use an install script that modifies the file in some predictable way, rather than simply shipping it that way in the first place???)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I believe the upstream reply is incorrect, but I do admit to being a bit out of my knowledge zone here. I am fairly convinced that the committed file to linux-firmware.git is corrupted, with one byte at offset 56D3 missing in the repo version.
I have sent this info to the upstream committer, and am awaiting a 2nd reply.
cmp -l linux-firmware.git/kbl_guc_ver9_14.bin 01.org/kbl_guc_ver9_14.bin | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
000056D3 0A 0D
000056D4 C3 0A
000056D5 0A C3
000056D6 C2 0A
000056D7 88 C2
000056D8 47 88
...
As can be seen from this cmp result, the data up to 56D3 is identical, then a byte of 0xD is missing in the linux-firmware.git version. All of the data after this point is still identical until the end of the file, although shifted up a row, due to the missing byte.
Last edited by blahhumbug (2017-02-24 03:24:18)
Offline
Upstream has confirmed that the firmware blob is corrupted and further reviews identified that a similar one-byte corruption has occurred with the Broxton GuC firmware as well. Will mark this thread solved, once the fixes are committed upstream.
Offline