Re: Updates to linux-firmware
Hi Ben, On Tue, Jul 16, 2024, at 9:20 AM, Ben Hutchings wrote: > On Fri, 2024-04-26 at 14:35 -0400, Mark Pearson wrote: >> Hi Didier & Ben, >> >> I hope all is well. >> I wanted to check in with you guys, as with the new 2024 platforms coming >> out there are some updates to linux-firmware - for CPU, GPU, Wifi, >> Bluetooth, etc devices >> >> I checked and it looked like firmware-nonfree and it hadn't been updated >> since last year - and I wondered if that is something I can help with? I'd >> like to make sure the Debian experience on this years platforms is good >> out-of-the-box. >> >> Let me know if that would be helpful, and any pointers on how best to >> contribute and be useful > > Hi Mark, > > Sorry for not responding to this earlier. > > I've finally uploaded an update to (nearly) the current version. This > incorporates some of Diederik's work, but I also made changes that > should reduce the amount of manual effort required for future updates. > No worries, and big thank you to both of you for all your hard work on this. Very much appreciated and I will do some testing of the latest to confirm it works. As an aside, it was useful and interesting to look into the repositories and see what was involved. I did at one point take a stab at looking what would be involved to help with updates but backed off until the current updates have gone through. With that done, I'm very happy to try and help with updates going forward. I know that for many people in the Debian community that dealing with non-free FW is not much fun or interest :) I will give it a go in the future, but do feel free to ping me if you're looking for a pair of hands to do some work on this. Hope you get to enjoy Korea :) Mark > Ben. > >> Thanks >> Mark >> >> PS - in case anyone notices, I've mothballed my old markpear...@lenovo.com >> address because the Lenovo outlook servers there became horribly unusable. I >> am using my personal domain for open source collaboration instead. >> I still have access to that address (if anybody wants to check I am who I >> say I am) and am still employed at Lenovo (if that makes any difference to >> anything) > > -- > Ben Hutchings - Debian developer, member of kernel, installer and LTS > teams > > Attachments: > * signature.asc
Bug#1072108: linux-image-amd64: Enable CONFIG_PINCTRL_METEORLAKE
On Tue, May 28, 2024, at 2:33 PM, Diederik de Haas wrote: > Control: forcemerge -1 1071551 > > On Tuesday, 28 May 2024 20:20:11 CEST Mark Pearson wrote: >> Package: src:linux >> Version: 6.8.11-1 >> Severity: important >> X-Debbugs-Cc: mpearson-len...@squebb.ca >> >> Dear Maintainer, >> >> Please enable the CONFIG_PINCTRL_METEORLAKE kernel option. This is needed to >> support Meteorlake based platforms. > > That was already requested in bug #1071551 with the following header: > > On Mon, 20 May 2024 22:19:16 -0300 Facundo Gaich wrote: >> Package: src:linux >> Version: 6.8.9-1 >> Severity: important >> X-Debbugs-Cc: mpearson-len...@squebb.ca > > ... > > The MR for it (1062) has just been merged into master. > Attachments: > * signature.asc Awesome - thanks! I did scan the bugs before submitting but missed that one. Apologies. Should I close this issue then as it's a duplicate? Mark
Bug#1072108: linux-image-amd64: Enable CONFIG_PINCTRL_METEORLAKE
Package: src:linux Version: 6.8.11-1 Severity: important X-Debbugs-Cc: mpearson-len...@squebb.ca Dear Maintainer, Please enable the CONFIG_PINCTRL_METEORLAKE kernel option. This is needed to support Meteorlake based platforms. -- Package-specific info: ** Version: Linux version 6.8.11-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.8.11-1 (2024-05-26) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.8.11-amd64 root=UUID=53f1bc6e-77b2-4354-88ed-77234d21b754 ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [ 123.271676] usb 1-1: Manufacturer: Generic [ 123.275591] hub 1-1:1.0: USB hub found [ 123.278788] hub 1-1:1.0: 4 ports detected [ 137.469932] usb 1-1: USB disconnect, device number 6 [ 143.071167] usb 1-1: new high-speed USB device number 7 using xhci_hcd [ 143.236634] usb 1-1: New USB device found, idVendor=0bda, idProduct=5411, bcdDevice= 1.18 [ 143.236646] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 143.236651] usb 1-1: Product: 4-Port USB 2.1 Hub [ 143.236654] usb 1-1: Manufacturer: Generic [ 143.238802] hub 1-1:1.0: USB hub found [ 143.240015] hub 1-1:1.0: 4 ports detected [ 529.376067] wlp0s20f3: deauthenticating from bc:df:58:fe:b8:be by local choice (Reason: 3=DEAUTH_LEAVING) [ 529.874359] PM: suspend entry (s2idle) [ 529.880533] Filesystems sync: 0.006 seconds [ 529.880730] (NULL device *): firmware: direct-loading firmware iwlwifi-ma-b0-gf-a0.pnvm [ 529.880847] (NULL device *): firmware: direct-loading firmware regulatory.db [ 529.880882] (NULL device *): firmware: direct-loading firmware regulatory.db.p7s [ 529.880926] (NULL device *): firmware: direct-loading firmware intel/ibt-0180-0041.ddc [ 529.880957] (NULL device *): firmware: direct-loading firmware intel/sof-ace-tplg/sof-hda-generic-2ch.tplg [ 529.881093] (NULL device *): firmware: direct-loading firmware iwlwifi-ma-b0-gf-a0-86.ucode [ 529.881127] (NULL device *): firmware: direct-loading firmware intel/ibt-0180-0041.sfi [ 529.881144] (NULL device *): firmware: direct-loading firmware i915/mtl_dmc.bin [ 529.883884] Freezing user space processes [ 529.914435] Freezing user space processes completed (elapsed 0.030 seconds) [ 529.914439] OOM killer disabled. [ 529.914440] Freezing remaining freezable tasks [ 529.915793] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 529.915796] printk: Suspending console(s) (use no_console_suspend to debug) [ 530.095825] ACPI: EC: interrupt blocked [ 739.865047] ACPI: EC: interrupt unblocked [ 739.943016] pci :00:08.0: Setting to D3hot [ 739.955306] pci :00:0b.0: Setting to D3hot [ 739.999154] iwlwifi :00:14.3: WRT: Invalid buffer destination [ 740.041638] nvme nvme0: Shutdown timeout set to 10 seconds [ 740.048976] nvme nvme0: 22/0/0 default/read/poll queues [ 740.154423] iwlwifi :00:14.3: Not valid error log pointer 0x0027B0C0 for RT uCode [ 740.154578] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x1f [ 740.154597] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f [ 740.154604] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x80 [ 740.154611] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0 [ 740.155001] iwlwifi :00:14.3: RFIm is deactivated, reason = 4 [ 740.262685] OOM killer enabled. [ 740.262687] Restarting tasks ... done. [ 740.264043] random: crng reseeded on system resumption [ 740.346752] PM: suspend exit [ 744.330519] wlp0s20f3: authenticate with bc:df:58:fe:b8:ba (local address=d4:e9:8a:28:29:5e) [ 744.331181] wlp0s20f3: send auth to bc:df:58:fe:b8:ba (try 1/3) [ 744.365025] wlp0s20f3: authenticated [ 744.367345] wlp0s20f3: associate with bc:df:58:fe:b8:ba (try 1/3) [ 744.379466] wlp0s20f3: RX AssocResp from bc:df:58:fe:b8:ba (capab=0x status=0 aid=2) [ 744.381167] wlp0s20f3: associated [ 744.400403] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by bc:df:58:fe:b8:ba [ 749.728812] wlp0s20f3: disconnect from AP bc:df:58:fe:b8:ba for new auth to bc:df:58:fe:b8:be [ 749.772632] wlp0s20f3: authenticate with bc:df:58:fe:b8:be (local address=d4:e9:8a:28:29:5e) [ 749.773041] wlp0s20f3: send auth to bc:df:58:fe:b8:be (try 1/3) [ 749.827021] wlp0s20f3: authenticate with bc:df:58:fe:b8:be (local address=d4:e9:8a:28:29:5e) [ 749.827587] wlp0s20f3: send auth to bc:df:58:fe:b8:be (try 1/3) [ 749.843441] wlp0s20f3: authenticated [ 749.847478] wlp0s20f3: associate with bc:df:58:fe:b8:be (try 1/3) [ 749.854108] wlp0s20f3: RX ReassocResp from bc:df:58:fe:b8:be (capab=0x status=0 aid=2) [ 749.856761] wlp0s20f3: associated [ 1055.998967] wlp0s20f3: disconnect from AP bc:df:58:fe:b8:be for new auth to bc:df:58:fe:b8:ba [ 1056.130402] wlp0s20f3: authenticate with bc:df:58:fe:b8:ba (local address=d4:e9:8a:28:29:5e) [ 1056.135259] wlp0s20f3: send auth to bc:df:58:fe:b8:ba (try 1/3) [ 1056.173137] wlp0s20f3:
Re: Updates to linux-firmware
Hi Diederik, On Tue, May 7, 2024, at 11:17 AM, Diederik de Haas wrote: > On Tuesday, 7 May 2024 15:49:45 CEST Mark Pearson wrote: >> > As I see it, the primary problem is the lack of people actively >> > contributing to the Debian kernel team's work. In general. >> >> Interesting read, and combined with my notes to Didier - is this something >> where I and some in my team could maybe help? If you think it would be >> worthwhile, does it make sense to setup a training session to walk me >> through the steps so I can attempt a first pass, and then review where the >> problems are and which bits are useful/not-useful. If the review/link >> updating/etc was all done - would it make it easier for a DM to look at it >> and go "yeah, that's solid" and release? > > *I* don't see where you/your team could help now. At least not for this > particular issue. General help with f.e. bug triaging would still be welcomed > I presume. > > At https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/ > you > can find the MRs I made to make the firmware-nonfree packages all up to date. > MR 85 is 'the BIG one' and in there I also mentioned that I also have an > update to 20240312 in my fork which I can submit as MR too. > > MR 85 is also reviewed by a DD, but while they are *allowed* to make uploads > for any package, they choose not to. And FWIW: I agree with that. > > I already mentioned that MR 85 is a BIG one (but the only one which needs to > go through NEW), which in turn means that reviewing takes more then 10 > minutes > (to put it mildly). > The update to 20230804 is also larger then average as some changes needed to > be 'postponed' due to needing a new upstream version. > > The updates after that are indicative of what I suspect/hope future updates > will look like. Unless a kernel-team member thinks that I didn't do it > correctly. While I did my best, that's surely a possibility. > > So if you want to know what's generally involved into updating the firmware- > nonfree packages, I suggest to look into my MRs. > I have a tendency to be verbose in my commit messages, which may help. > And the procedure I described earlier should match what you'll see in the > updates after 20230804. > Cool - I have taken a very quick look and kudos - amazing job. A few follow on questions: - It looks like it is stuck on someone doing the upload (guessing nobody has time to do that). Unfortunately I can't help with that bit - not a DM and nowhere near enough experience. Any recommendations on how to unblock that? It doesn't seem like testing/reviewing would help - but if you have any insight as to what would make a difference let me know. And, thinking about the comment previously about funding - is this something where somebody needs some paid time to do the exercise? It's not something I can promise (and dealing with Lenovo procurement is a special form of hell), but if that's the blocker then I am happy to go and shake some branches and see if there's a way we can help out. I don't want to cause offence and assume that's the answer though (and FWIW, I would prefer my team to contribute directly through knowledge/skills as I think it's better in the long term). - I love what you've done with the monthly cadence of updates, that seems smart to me but I appreciate it's a chunk of work every month. I also noted in one of the commits you mentioned "I don't particularly care about this package, but just wanted to do something about the (big) backlog AND make it easier to prevent a backlog from appearing again in the future (by making it easier for everyone to make an update)", so I'm assuming you'd like done with it ASAP. You noted earlier that it wasn't documented and added some useful notes. Would it be helpful to work through that process with an idiot (aka...me) to get an initial document down as a starting point? With the last MR being a few months old now, would it be reasonable for me to take a stab at doing an update and (worst-case) learning from it? I don't want to tread on any toes, and I will almost certainly need some guidance, but it seems like there is interest in helping out from other users too (based on the comment thread). If we can figure out the upload piece, it looks like the infrastructure work you've put in would pay off. - Previously you noted "Upstream now also produces a deb package per tag/release" - I had a look for those but couldn't find it. Do you have a location I can check those out? Figured it would be interesting to have a look. >> I can't highlight all patches needed for Meteorlake/Hawkpoint support - that >> would be huge. I can highlight that a 6.8 kernel is needed; and which FW >> packages are needed. > > While firmw
Re: Updates to linux-firmware
Hi Diederik, On Tue, May 7, 2024, at 5:22 AM, Diederik de Haas wrote: > On Tuesday, 7 May 2024 08:25:23 CEST Didier 'OdyX' Raboud wrote: >> What I did back then to try to help getting the firmware package in better >> shape was to dive in the (complex) packaging and try to produce "ready-to- >> merge" merge-requests for new upstream releases, fixes, etc, then pinging >> Ben at (what I considered) reasonable intervals. I see that Diederik >> (CC'ed) has started to do the same for recent versions. > > What I did was indeed my effort to get things into better shape with the hope/ > goal that it would be easier to do going forward. Which in turn hopefully > means that it would be done more regularly which would not make it a > monumental task ... which no-one is looking forward to do or has the capacity > (time/motivation/etc) to do. > >> The package is complex and a mined land of legal concerns, > > It was a HUGE amount of work, partly because I wanted to get things into what > I consider a better shape. Another part which made it *look* complex, were > inconsistencies. In one of my commits I determined in which sequence the > control fields were going to get placed and then fixed all the config files > to > conform to that sequence. I also ordered the entries alphabetically. > > I haven't documented it (yet), but I followed a different procedure > then 'the > official one', which I think makes it easier and better ... lowering > the barrier > for future contributions/MRs. > > It was basically the following: > 1) Have the upstream repo locally and checkout the next tag/release and open > that with gitk > 2) Start a new branch in your local Debian firmware-nonfree repo > 3) Go through each commit and decide what to do with it > - Upstream merge commit: ignore it > - Upstream working on their own infra: ignore it. Unless it has an effect on > (future) Debian packaging, then add it to d/changelog. And use the > secondary commit message to properly document it. > - Updated version of firmware files: if it has a(n explicit) version number, > update the version in the appropriate ``defines`` file. > - New links (documented in WHENCE): Add that entry to the ``files:`` section >of the Debian ``defines`` file. > - New files: Add an entry to the `files:` section and add a Stanza for it > with >its 'ID'/Name, description and if available the version number > - Check whether d/copyright covers any new files and if it doesn't expand the >'regex' so that it does if the license is already known. Otherwise add an >entry and the license text to d/copyright* > > With updated versions or new links or new files, add an entry to d/changelog > which is mostly or fully upstream's primary commit message, prepended by the > Debian package name. This way there's an almost 1-on-1 match between the > Debian and upstream's commit (message). This should also make reviews easier. > > I ordered the entries by Debian package name, so that if someone only has AMD > graphics firmware, it doesn't have to read the full changelog, only the part > which is about amd-graphics. Upstream's git commit log sequence is rather > random, which isn't useful or helpful to our users (IMO ofc) > > *) I did improve d/copyright too, but not fully. All the license texts have > been moved to the bottom, but I didn't fix the sequencing of all the stanzas. > >> the upstream repo needs repacking, > > Upstream now also produces a deb package per tag/release, but that's 350MB in > size ... and growing. And it includes firmware which isn't DFSG compliant and > therefor we shouldn't ship or f.e. can only be shipped as part of the kernel, > so we can't distribute them. > >> and the (upstream & debian/) repositories are split; > > I think the split is very useful, especially for our users. Some users only > need one or a few small firmware files. Not having to download >350MB for > that > for every upstream/Debian release/version is quite useful. Not everyone has > unmetered GbE internet connection ... or wants to waste 300+MB for files for > which they have no need/use. > >> I have not found this a very pleasant experience, sadly. > > I didn't find it pleasant either, but I hope/expect that with my updates and > restructuring it shouldn't be that bad either. > When things are kept up-to-date it's quite doable, but when you have to work > through months of 'backlog' the 'fun' quickly diminishes. > >> And again; no-one to blame here: there _is_ tooling to help, and immense >> work has been put towards making this manageable! I'm merely saying it's not >> a matter of running "debian/rules get-new-upstream" at all. > > The tooling is mostly great. > *I* do think that the script which imports upstream's changelog should go > though as it makes 'you' think you're quickly done. But if you want to do > things right, you should still go through all the commits to actually update > the versions and add
Re: Updates to linux-firmware
Hi Didier On Tue, May 7, 2024, at 2:25 AM, Didier 'OdyX' Raboud wrote: > Hello there Mark, > > thanks for your email, and for the followup ping; weeks are well-filled with > $job, baby and other involvements. Congrats! Exciting times (my eldest just passed her driving test last week...the time flies by far too fast...enjoy it!) > > Regarding firmware-nonfree updates, I have related my last-years' experience > on d-devel: https://lists.debian.org/msgid-search/2390124.3VsfAaAtOV@turnagra > Interesting read. I do skim the debian lists and I'd missed it. Some notes further below that I think are related to the points you raise in there. > I insist: I am absolutely not implying that Ben is doing anything wrong; I > just observed that he was mostly alone in a bottleneck position for that > package. > > What I did back then to try to help getting the firmware package in better > shape was to dive in the (complex) packaging and try to produce "ready-to- > merge" merge-requests for new upstream releases, fixes, etc, then pinging Ben > at (what I considered) reasonable intervals. I see that Diederik (CC'ed) has > started to do the same for recent versions. > > The package is complex and a mined land of legal concerns, the upstream repo > needs repacking, and the (upstream & debian/) repositories are split; I have > not found this a very pleasant experience, sadly. And again; no-one to blame > here: there _is_ tooling to help, and immense work has been put towards > making > this manageable! I'm merely saying it's not a matter of running "debian/rules > get-new-upstream" at all. > > From where I sit (that is: I only modestly contributed in the past, and > cannot > commit to much these days), there are two angles to address: > A) lift the bottleneck: there needs to be more Debian Developers confident to > comment and merge MRs, and then upload. > B) regular commitment: I feel it would be easier to get regular updates > merged, rather than doing the huge batch shortly before release; that would > also appease the tensions that many probably feel when they get new hardware > but no available package. So, this may be naive, but I think this is potentially a good place for myself and (hopefully) some of the Lenovo team to get involved and contribute - at least on (B) in the short term and maybe eventually on (A) in the longer term. I really want to support the community distros that are at the core of Linux - I think it's important. It's also, honestly, what makes me happiest. I also think that, realistically, nobody really wants to mess around with non-free FW because it's just not very interesting. But it's needed as the vendors themselves don't particularly want to get involved with packaging (I do the Debian firmware-sof-signed package for the Intel audio FW because of this). Lenovo has a big advantage in that we have the hardware available, earlier, so are able to identify what's needed and do testing. My biggest problem is how to get started. As noted above, I do the SOF firmware packaging so I'm not a complete noob, but I'm not particularly experienced either. I have the steps I need to follow, and I do that, test, sometimes fix minor issues and that's it. I should flag, I'm not a DD or DM (FWIW, I'd like to be one day, I've just not earned it yet :)) I'm open to ideas and suggestions, but (particularly for the linux-firmware pieces) I think we (Lenovo) can help here, if someone is willing to give some help to get started. I appreciate there needs to be appropriate mentoring and checking in place - but if there's something we can do to get some of the grunt work done so that MR's can be checked please let me know how to do that. > > As to how I can get involved in any of the above; I can't reasonably add this > to my plate these days (and would rather _not do_, than commit to do and > fail). > > But I wonder if some financial sponsorship (if Lenovo and others would be > open > to something like that) could help, via Freexian for example (disclaimer: not > for me to do it; I'm not a Freexian person). I'd be concerned that this would > only solve B above though. It would feel like a 1-2 hours job / week. > If $'s solve it - I'm open to suggestions. I have to caveat it with the fact the Linux project here is not making money...I don't have budget to burn. I'd rather get involved directly and contribute and enable others in my team to contribute directly too, I think that has more real value. If the answer is just money, then let me know and where I should take that discussion - I'm not averse to it, but my previous experience is that money doesn't solve the problem - the issue is more having hands to do the work (I think the Debian budget reports confirm this FWIW - money is not lacking). > I hope the above helps you navigate that question, and that it helps the > situation in general. > Thank you for all the pointers! Mark
Re: Updates to linux-firmware
Hi all, Thought I'd check in and see if my previous email was missed in inbox swamp. Please let me know what I can do to help here. Not sure if it's helpful - but I did some bugzilla tickets, as I'm guessing that's part of the process. FYI - 1070647 - firmware-misc-nonfree (graphics FW) - 1070648 - firmware-iwlwifi (wifi) - 1070650 - kernel (everything) If I can be involved and/or useful - please let me know how. Thanks! Mark On Fri, Apr 26, 2024, at 2:35 PM, Mark Pearson wrote: > Hi Didier & Ben, > > I hope all is well. > I wanted to check in with you guys, as with the new 2024 platforms > coming out there are some updates to linux-firmware - for CPU, GPU, > Wifi, Bluetooth, etc devices > > I checked and it looked like firmware-nonfree and it hadn't been > updated since last year - and I wondered if that is something I can > help with? I'd like to make sure the Debian experience on this years > platforms is good out-of-the-box. > > Let me know if that would be helpful, and any pointers on how best to > contribute and be useful > > Thanks > Mark > > PS - in case anyone notices, I've mothballed my old > markpear...@lenovo.com address because the Lenovo outlook servers there > became horribly unusable. I am using my personal domain for open source > collaboration instead. > I still have access to that address (if anybody wants to check I am who > I say I am) and am still employed at Lenovo (if that makes any > difference to anything)
Bug#1070650: linux-image-6.7.7-amd64: Updates needed for 2024 Platform support - graphics, wifi, CPU, audio
Package: src:linux Version: 6.7.7-1 Severity: important X-Debbugs-Cc: mpearson-len...@squebb.ca I realise this bug is overly broad, but testing Debian on the 2024 platforms and updated kernel is needed for a better user experience - Meteorlake support is a bit limited before 6.8. Need updated kernel for graphic, audio, power support. - Intel AX211 driver is in newer kernel. - AMD graphics drivers have seen significant improvements in 6.8 This also links to #1070647 and #1070648 where FW updates are required. Very happy to help if any tested needed. I've had users trying to run Debian on their systems and would like to be able to help them get up and runninng. Note - kernel logs below are with updated FW that I manually installed myself. Without these I don't have functional graphics of wifi :) Thanks Mark -- Package-specific info: ** Version: Linux version 6.7.7-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-16.1) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.7-1 (2024-03-02) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.7.7-amd64 root=UUID=864f906b-6c9a-49b9-bdbe-78e4b4a88d9d ro quiet ** Not tainted ** Kernel log: [5.157952] cryptd: max_cpu_qlen set to 1000 [5.164733] ACPI Warning: \_SB.PC00.XHCI.RHUB.HS10._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20230628/nsarguments-61) [5.165165] Bluetooth: hci0: DSM reset method type: 0x00 [5.165836] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6E AX211 160MHz, REV=0x441 [5.165896] thermal thermal_zone8: failed to read out thermal zone (-61) [5.169658] bluetooth hci0: firmware: direct-loading firmware intel/ibt-0180-0041.sfi [5.174253] Bluetooth: hci0: Found device firmware: intel/ibt-0180-0041.sfi [5.174303] Bluetooth: hci0: Boot Address: 0x100800 [5.174304] Bluetooth: hci0: Firmware Version: 132-8.24 [5.176650] AVX2 version of gcm_enc/dec engaged. [5.176706] AES CTR mode by8 optimization enabled [5.177586] iwlwifi :00:14.3: WRT: Invalid buffer destination [5.183424] sof-audio-pci-intel-mtl :00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380 [5.184986] sof-audio-pci-intel-mtl :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [5.185540] sof-audio-pci-intel-mtl :00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380 [5.185595] sof-audio-pci-intel-mtl :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [5.192677] sof-audio-pci-intel-mtl :00:1f.3: use msi interrupt mode [5.239977] typec port0: bound usb1-port3 (ops connector_ops [usbcore]) [5.240002] typec port0: bound usb4-port1 (ops connector_ops [usbcore]) [5.254026] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [5.254028] Bluetooth: BNEP filters: protocol multicast [5.254032] Bluetooth: BNEP socket layer initialized [5.258126] Btrfs loaded, zoned=yes, fsverity=yes [5.273296] sof-audio-pci-intel-mtl :00:1f.3: hda codecs found, mask 5 [5.273298] sof-audio-pci-intel-mtl :00:1f.3: using HDA machine driver skl_hda_dsp_generic now [5.273301] sof-audio-pci-intel-mtl :00:1f.3: DMICs detected in NHLT tables: 2 [5.274536] sof-audio-pci-intel-mtl :00:1f.3: firmware: direct-loading firmware intel/sof-ipc4/mtl/sof-mtl.ri [5.274976] sof-audio-pci-intel-mtl :00:1f.3: Loaded firmware library: ADSPFW, version: 2.8.1.1 [5.342774] iwlwifi :00:14.3: Not valid error log pointer 0x0027B0C0 for RT uCode [5.342847] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x1f [5.342866] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f [5.342873] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x80 [5.342882] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0 [5.343634] iwlwifi :00:14.3: RFIm is deactivated, reason = 4 [5.343711] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-ma-b0-gf-a0.pnvm [5.343796] iwlwifi :00:14.3: loaded PNVM version ce1a5094 [5.353058] NET: Registered PF_QIPCRTR protocol family [5.359195] iwlwifi :00:14.3: Detected RF GF, rfid=0x2010d000 [5.382188] sof-audio-pci-intel-mtl :00:1f.3: Booted firmware version: 2.8.1.1 [5.389778] sof-audio-pci-intel-mtl :00:1f.3: firmware: direct-loading firmware intel/sof-ace-tplg/sof-hda-generic-2ch.tplg [5.389812] sof-audio-pci-intel-mtl :00:1f.3: Topology: ABI 3:29:0 Kernel ABI 3:23:0 [5.389997] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not yet available, widget card binding deferred [5.413768] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker [5.413772] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [5.413773] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [5.413774] snd_hda_codec_realtek ehdaudio0D0:
Bug#1070648: firmware-iwlwifi: Update needed for Intel AX211 Wifi support
Package: firmware-iwlwifi Version: 20230625-2 Severity: important X-Debbugs-Cc: mpearson-len...@squebb.ca I've been testing Debian on the new Lenovo Meteorlake based platforms with AX211 Intel wifi, and seeing lots of problems related to out of date kernel and firmware support. This bug is being raised to specifically track getting the iwlwifi firmware packages updated Please let me know how I can help. Happy to do any testing, and I have some limited experience with packaging from maintaining the firmware-sof-signed packag> Thanks Mark -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.7.7-amd64 (SMP w/22 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.142 -- no debconf information
Bug#1070647: firmware-misc-nonfree: Update needed to support Meteorlake graphics
Package: firmware-misc-nonfree Version: 20230625-2 Severity: important X-Debbugs-Cc: mpearson-len...@squebb.ca I've been testing Debian on the new Lenovo Meteorlake based platforms and seeing lots of problems related to out of date kernel and firmware support. This bug is being raised to specifically track getting the graphics firmware packages updated - /lib/firmware/i915 Please let me know how I can help. Happy to do any testing, and I have some limited experience with packaging from maintaining the firmware-sof-signed packag> As a note - iwlwifi and kernel itself need updating too, but I will do separate bugs for those Thanks Mark -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.7.7-amd64 (SMP w/22 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-misc-nonfree depends on no packages. firmware-misc-nonfree recommends no packages. Versions of packages firmware-misc-nonfree suggests: ii initramfs-tools 0.142 -- no debconf information
Updates to linux-firmware
Hi Didier & Ben, I hope all is well. I wanted to check in with you guys, as with the new 2024 platforms coming out there are some updates to linux-firmware - for CPU, GPU, Wifi, Bluetooth, etc devices I checked and it looked like firmware-nonfree and it hadn't been updated since last year - and I wondered if that is something I can help with? I'd like to make sure the Debian experience on this years platforms is good out-of-the-box. Let me know if that would be helpful, and any pointers on how best to contribute and be useful Thanks Mark PS - in case anyone notices, I've mothballed my old markpear...@lenovo.com address because the Lenovo outlook servers there became horribly unusable. I am using my personal domain for open source collaboration instead. I still have access to that address (if anybody wants to check I am who I say I am) and am still employed at Lenovo (if that makes any difference to anything)
Bug#962134: [External] Re: Bug#962134: add Sound Open Firmware
On 6/4/2020 9:21 AM, Mark Pearson wrote: OK - I have asked the SOF folk to talk to you about this. I'll unicast you the email address so you have the correct contact details too. I know some discussions started with the SOF folk. Has there been any progress for this issue? Anything that is stuck that I can help with? Thanks Mark
Bug#962134: [External] Re: Bug#962134: add Sound Open Firmware
On 6/4/2020 4:56 AM, Paul Wise wrote: On Wed, 2020-06-03 at 21:34 -0400, Mark Pearson wrote: Hi Paul - I'm afraid it does (not something of Lenovo's choosing to my knowledge...). Interesting, is it Intel doing the restrictions on Lenovo hardware? ISTR reading on one of the bugs that some hardware doesn't have the restrictions, so it is strange that Intel restricts some hardware vendors but not others. If you are able to push back on these Intel restrictions, it would be very much appreciated. I'll see what I can find out. I know the SOF team wanted to work with Debian on this issue a few months ago - I will dig up that email and point them at this bug so they can contribute to the conversation without me muddying the waters about their decisions (I was on their mailing list but not involved in the decision making) Interesting, thanks for that. OK - I have asked the SOF folk to talk to you about this. I'll unicast you the email address so you have the correct contact details too.
Bug#962134: add Sound Open Firmware
On 6/3/2020 8:31 PM, Paul Wise wrote: > > > SOF is free software, but many devices require binaries that are signed > by Intel's keys, so the free license/source code much less useful and > the binaries going into linux-firmware are needed for most people. > > More details in the links on this page: > > https://wiki.debian.org/Firmware/Open > > Mark, do Lenovo Laptops require the Intel-signed blobs? > Hi Paul - I'm afraid it does (not something of Lenovo's choosing to my knowledge...). My understanding is the SOF team didn't want to use intel-firmware but I'm trying to find the discussion on the SOF mailing list as to why. I think it was related to there being topology files and debug files and wanting to keep everything together - and the other two files didn't belong in intel-firmware. There were also concerns about it moving outside of their control. Their solution was the sof-bin repository (https://github.com/thesofproject/sof-bin) I have to admit - I hadn't considered the freedoms issues of that. Is having a sof-firmware repository that is non-free the same way as intel-firmware? I'm guessing Debian doesn't want to increase the number of non-free packages? I know the SOF team wanted to work with Debian on this issue a few months ago - I will dig up that email and point them at this bug so they can contribute to the conversation without me muddying the waters about their decisions (I was on their mailing list but not involved in the decision making) Mark
Bug#962134: add Sound Open Firmware
Hi, Don't know if it helps but I raised #960788 on the same topic. It has a few details on how other distro's have packaged it which might be helpful. Once this is available I'm happy to do some testing. Thanks Mark
RE: [External] Difficulties with kernel package contributions
Thanks Ben > -Original Message- > From: Ben Hutchings > Sent: Sunday, May 17, 2020 11:50 AM > To: Mark Pearson > Cc: Pete Batard ; Debian kernel maintainers ker...@lists.debian.org> > Subject: [External] Difficulties with kernel package contributions > > I'm not cc'ing the BTS on this as this discussion is no longer specific > to one bug report. > > On Sun, 10 May 2020 16:46:47 + Mark Pearson > wrote: > [...] > > I'm hesitant to post to this thread as I don't agree with all of Pete's > > points, > > but this thread somewhat resonated, especially this last comment. > > As someone who is still learning and finding their way through the process > > myself - finding the preferred way of doing things and all the little > > details > > is hard - or at least that's my experience. The kernel handbook is OK, but > > it doesn't cover this detail in my opinion > > Yes, there's definitely room for improvement in the documentation. > > We also have documentation spread across debian/README.source, kernel- > handbook, the docs directory of kernel-team.git, and some wiki pages. > We (the kernel team) should clarify who they're for and what > information belongs where; and probably we should add more cross- > references. > > Oh, and I gave this talk: > > https://peertube.debian.social/videos/watch/3b1818f2-e44c-4cbd-b9a0- > c9465c53667a > https://www.decadent.org.uk/ben/talks/mdch2018-help-the-kernel-team.pdf > These are good - thank you. > and I'm not sure all of the information there is written down elsewhere... > > > It would be really nice to have an idiots/beginners guide to what the best > way > > is to make the maintainers life easy - I have been stumbling my way through, > > making plenty of mistakes and I'm sure I generate more headaches then I > mean > > to. > > I got the impression that you're not hugely familiar with git, so > having to deal with git and quilt at the same time is bound to be > difficult. > That's fair. I have used git but there has definitely been some learning of functionality (rebase) that I'd not come across before. Quilt is new to me but I'm getting more used to it > > Having a guide explaining how to backport a patch cleanly from kernel.org > > would be a really nice thing to have - down to best working practices with > > salsa, all the bits of info that have to be added to the patch(es), using > > dch, > > how to deal with patches that don't merge cleanly, git best practices etc. > > A fair amount of that is needed for Debian packages in general, so I > don't think we should be writing our own documentation about it but we > should refer to existing documentation. > Makes sense - I need to make more effort to go through those. I've tended to be kernel focused as it's the area where I'm more aware of patches upstream that impact our platforms that are (I hope) good to get into Debian sooner. > > I'm > > sure as a kernel maintainer you see the same mistake again and again and it > > must be infuriating. Recommended workflows would be amazing - I'm still > not > > sure what the *best* way to work on the Debian kernel is (I have steps I use > > but I had to figure them out myself and I suspect they could be better). > > I'm going to assume that you're talking specifically about backporting > features from upstream (either mainline or a maintainer tree). If the > target Debian branch is not far behind, that I would usually: > > 1. Export the upstream commits with git-format-patch-for-debian. This is a >wrapper for "git format-patch" that adds the extra patch headers, and it's >in the kernel-team.git repository. > 2. Depending on the number of patches, either: >- Import them individually, with something like: > quilt import -P features/all/foo.patch ~/linux/0001-foo.patch >- Move them into a subdirectory of debian/patches, e.g.: > cd debian/patches > mkdir features/all/foo > mv ~/linux/0*.patch features/all/foo/ > ls features/all/foo/*.patch >> series > 3. Apply each patch (quilt push) and fix up any conflicts. > 4. Build and test (to the extent possible). > > If the target Debian branch is further behind (e.g. 4.19 as Pete is > dealing with) then I would more likely: > > 1. Start a git branch from the upstream stable branch. > 2. For each upstream commit: >1. Cherry-pick it with "git cherry-pick -x" it. Fix up any > conflicts and note the change in the commit message. >2. Build the kernel, or at least the affected subsystem or driver. > Fix any failure, possibly by picking additional commits
Bug#950578: [External] Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4
> From: Ben Hutchings > Sent: Saturday, May 9, 2020 5:20 PM > > On Thu, 2020-05-07 at 14:23 +0100, Pete Batard wrote: > [...] > > > If Debian 11 was planning to continue to use a 4.x kernel, I could see > > some point in splitting the patch and ensuring, so that it *might* be > > easier to maintain for many years to come. But, from what I gather, > > Debian 11 will bump kernel major, so any work being done making the 4.x > > backport (which is not that complex, sorry, especially as I made sure to > > already group the code changes in a manner that makes it easier to > > handle) easier to maintain in the long run seems like a waste of time, > > even if 10.x may see long time support for a few more years... > [...] > > Debian 10 will be supported for 4 more years, in fact. During that > time this driver may well see other changes backported through the > stable process. Based on past experience, I think it will be easier to > resolve any conflicts if our patches make smaller changes. > > So please don't assume what's "easier to handle" for us. > > Ben. > I'm hesitant to post to this thread as I don't agree with all of Pete's points, but this thread somewhat resonated, especially this last comment. As someone who is still learning and finding their way through the process myself - finding the preferred way of doing things and all the little details is hard - or at least that's my experience. The kernel handbook is OK, but it doesn't cover this detail in my opinion It would be really nice to have an idiots/beginners guide to what the best way is to make the maintainers life easy - I have been stumbling my way through, making plenty of mistakes and I'm sure I generate more headaches then I mean to. Having a guide explaining how to backport a patch cleanly from kernel.org would be a really nice thing to have - down to best working practices with salsa, all the bits of info that have to be added to the patch(es), using dch, how to deal with patches that don't merge cleanly, git best practices etc. I'm sure as a kernel maintainer you see the same mistake again and again and it must be infuriating. Recommended workflows would be amazing - I'm still not sure what the *best* way to work on the Debian kernel is (I have steps I use but I had to figure them out myself and I suspect they could be better). It would also be really nice to have a way to reasonably escalate things (with a reason for the escalation) without pissing off people who are too busy to be swamped with nag-emails (I've been told those are a huge no-no with the kernel Debian community). I'd be OK with a "this is not a priority I will look at it in N weeks" but having no insight into where you are in the queue or if you have been missed is hard. From my point of view I regularly get asked "when will X be available in Debian" and I can never give an estimate. I cannot recommend to even expert Lenovo customers to use Debian on our platforms - and that is frustrating because it is a great distro. Please note - I do not mean to sound like I am complaining. I believe part of being in the community is to do things the way the community wants. I just think the path for newcomers to contribute and make Debian better is not an easy one and wanted to offer insight as to why. If you can point me at what I'm missing that would be awesome (and slightly embarrassing as I've looked for it at length) Mark
Bug#958041: linux-image-5.5.0-1-amd64: OLED brightness control not working on Lenovo P1G2 and X1 extreme
Package: src:linux Version: 5.5.13-2 Severity: normal Tags: upstream Dear Maintainer, Raising bug for tracking issue with OLED brightness control not working on some Lenovo platforms (and I believe some Dell platforms too) The patches are upstream here: https://patchwork.freedesktop.org/series/69914/ https://patchwork.freedesktop.org/series/72991/ and I'm working on a merge request to bring them into Debian: https://salsa.debian.org/kernel-team/linux/-/merge_requests/231 I was told a bug was preferred so am raising this for tracking. Let me know if any questions or concerns. Mark Pearson mpear...@lenovo.com -- Package-specific info: ** Version: Linux version 5.5.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.5.0-1-amd64 root=UUID=fa0b3088-7fd9-47a8-9306-8cd2d4c0d3a6 ro quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: LENOVO product_name: 20QUZ4QSUS product_version: ThinkPad P1 Gen 2 chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: N2OET41W (1.28 ) board_vendor: LENOVO board_name: 20QUZ4QSUS board_version: SDK0Q40104 WIN ** Loaded modules: sd_mod sg uas usb_storage scsi_mod fuse x86_pkg_temp_thermal intel_powerclamp coretemp bnep kvm_intel kvm irqbypass crct10dif_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd snd_hda_codec_hdmi glue_helper mei_wdt intel_cstate intel_rapl_msr intel_uncore intel_rapl_perf efi_pstore serio_raw intel_wmi_thunderbolt wmi_bmof snd_sof_pci snd_sof_intel_hda_common snd_sof_intel_hda efivars pcspkr snd_sof_intel_byt snd_sof_intel_ipc snd_sof iTCO_wdt snd_sof_xtensa_dsp iTCO_vendor_support watchdog snd_soc_skl iwlwifi snd_hda_codec_conexant snd_soc_hdac_hda snd_hda_codec_generic snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btusb nls_ascii btrtl snd_compress btbcm nls_cp437 btintel snd_hda_intel vfat snd_intel_dspcfg bluetooth fat uvcvideo cfg80211 videobuf2_vmalloc tpm_crb mei_me videobuf2_memops videobuf2_v4l2 mei snd_hda_codec videobuf2_common snd_hda_core videodev drbg thinkpad_acpi snd_hwdep snd_pcm nvram mc ansi_cprng processor_thermal_device snd_timer tpm_tis ledtrig_audio intel_rapl_common tpm_tis_core ucsi_acpi snd ecdh_generic ecc typec_ucsi tpm joydev rfkill soundcore intel_soc_dts_iosf intel_pch_thermal typec rng_core ac int3403_thermal int340x_thermal_zone int3400_thermal acpi_pad evdev acpi_thermal_rel parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic wacom hid_generic usbhid hid i915 rtsx_pci_sdmmc mmc_core i2c_designware_platform i2c_designware_core e1000e i2c_algo_bit psmouse crc32_pclmul drm_kms_helper crc32c_intel xhci_pci ptp xhci_hcd pps_core drm usbcore nvme thunderbolt nvme_core rtsx_pci i2c_i801 intel_lpss_pci intel_lpss idma64 usb_common mfd_core wmi battery video button ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers [8086:3ec4] (rev 0d) Subsystem: Lenovo 8th Gen Core Processor Host Bridge/DRAM Registers [17aa:22a8] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 0d) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 630 (Mobile) [8086:3e9b] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Lenovo UHD Graphics 630 (Mobile) [17aa:22a8] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0d) Subsystem: Lenovo Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [17aa:22a8] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: proc_thermal Kernel modules: processor_therma
Bug#944350: RE: Bug#944350: RE: [External] Bug#944350: systemd: screen remains off after waking up from suspend
Hi, The BIOS fix was actually just an initial workaround - the proper fix is the kernel patch (https://patchwork.freedesktop.org/patch/338599/?series=68817=4 )which went into 5.4-rc8 and has also been backported into Debian sid at the end of last year To add some context/detail in case it helps or is of interest: We found the issue and worked with Intel - in summary the wrong clock was used on resume and it meant, for OLED panels, not enough time was allowed for initialization/training to complete and this sometimes leads to a black screen (ssh etc still works). The BIOS fix was to increase the timeout (from the spec version of 200ms to 210ms I believe) but it's just a workaround. We released it as we had some customers who needed the fix quickly and we were worried it would take a long time for the patch to upstream and then to get into the distros. Releasing a new BIOS isn't a fast process and as it turned out the kernel patch went through really fast (doesn't always happen ) so we probably could have skipped the BIOS workaround, but the tweak is minor and safe so it's good to have it available for those needing to use an older kernel. Summary: If you're running a newer kernel than 5.4-rc8 and don't care about the enhancements in the update you don't need to update the BIOS for the timing fix. Let me know if any questions. Mark > -Original Message- > From: Jiri Kanicky > Sent: Sunday, January 26, 2020 11:48 PM > To: 944...@bugs.debian.org > Subject: Bug#944350: RE: Bug#944350: RE: [External] Bug#944350: systemd: > screen remains off after waking up from suspend > > FYI Lenovo also pushed a fix into a BIOS. > > CHANGES IN THIS RELEASE > Version 1.28 > > [Important updates] > Nothing > > [New functions or enhancements] > - Supported BIOS password authentication before entering into MEBx. > - Updated Regulatory Information. > > [Problem fixes] > - Fixed an issue where OLED panel might not trun on after resuming from > sleep on Linux. > > https://download.lenovo.com/pccbbs/mobiles/n2oul07w.txt > > > > > > Regards, Jiri > > > > > > On Fri, 6 Dec 2019 18:47:05 + Mark Pearson > <mailto:mpear...@lenovo.com> wrote: > > > Hi Jiri, > > > > I'm pretty sure it's not in 5.3.0-2. Are you sure? I can look again but I > recently did put in a merge request to get it pulled into sid: > https://salsa.debian.org/kernel-team/linux/merge_requests/188 > > > > Not sure if/when it will be accepted (it's only my 2nd attempt at doing > > this) > but hopefully someone looks at it and thinks it's useful) > > > > Mark > > > > > -Original Message- > > > From: Jiri Kanicky <mailto:j...@ganomi.com> > > > Sent: Saturday, November 30, 2019 6:56 AM > > > To: 944...@bugs.debian.org <mailto:944...@bugs.debian.org> > > > Subject: Bug#944350: RE: [External] Bug#944350: systemd: screen > remains > > > off after waking up from suspend > > > > > > Hi. > > > > > > It seems that Debian 5.3.0-2-amd64 includes the code in the patch > > > already and I still have the issue. > > > > > > Jiri > > > > > > On Mon, 25 Nov 2019 16:45:55 + Mark Pearson > > > <mailto:mpear...@lenovo.com> wrote: > > > > > > > Hi, > > > > > > > > I don't know if this is helpful but I recently debugged a similar > > > issue on the Lenovo P1Gen2. There the problem is only with the > > > integrated graphics and an OLED screen - we tracked it down to an issue > > > in the i915 driver where it wasn't giving enough time for eDP link > > > training. It turned out this was due to the driver using the wrong > > > clocks after a suspend and resume . > > > > > > > > Intel recently up-streamed a fix (commit 2f216a85 - it went into > > > 5.4-rc8) > > > > > > > > I'm working on doing a patch that I'm hoping to get into Debian to > > > backport - just not done yet :) The patch is pretty small (I've attached > > > it) so you might want to give it a go and see if it helps. > > > > > > > > Note - we did also test X1 extreme with OLED panel and didn't see a > > > problem therebut it's a really subtle timing issue so some units > > > might be more susceptible than others. Maybe worth a go? > > > > > > > > If it does make a difference let me know. > > > > Mark > > > > > > >
Bug#944257: [External] Bug#944257: Confirmed, possible duplicate
Hi Daniel, I'll ask internally if we have one of these - I don't have one myself. It's supposed to be a certified system so hopefully our team has one and can look at what is happening. If you're able to track down when the issue was introduced let me know. Actually - if you get a chance post something on the Lenovo linux forum too (https://forums.lenovo.com/t5/Linux-Operating-Systems/ct-p/lx_en) - it just helps it get a bit of extra visibility Thx Mark > -Original Message- > From: Daniel M. > Sent: Saturday, December 7, 2019 9:39 AM > To: 944...@bugs.debian.org > Subject: [External] Bug#944257: Confirmed, possible duplicate > > Hi, > > I have exactly the same behavior on my lenovo E460 laptop. No suspend > and shutdown working since upgrade to linux 5.x. > > I don't know how to get more attention to this. Can we raise the > severity or flag it? > > Some more info in my earlier report #939170. Maybe even duplicate? > > Cheers, > Daniel
Bug#944350: RE: [External] Bug#944350: systemd: screen remains off after waking up from suspend
Hi Jiri, I'm pretty sure it's not in 5.3.0-2. Are you sure? I can look again but I recently did put in a merge request to get it pulled into sid: https://salsa.debian.org/kernel-team/linux/merge_requests/188 Not sure if/when it will be accepted (it's only my 2nd attempt at doing this) but hopefully someone looks at it and thinks it's useful) Mark > -Original Message- > From: Jiri Kanicky > Sent: Saturday, November 30, 2019 6:56 AM > To: 944...@bugs.debian.org > Subject: Bug#944350: RE: [External] Bug#944350: systemd: screen remains > off after waking up from suspend > > Hi. > > It seems that Debian 5.3.0-2-amd64 includes the code in the patch > already and I still have the issue. > > Jiri > > On Mon, 25 Nov 2019 16:45:55 + Mark Pearson > wrote: > > > Hi, > > > > I don't know if this is helpful but I recently debugged a similar > issue on the Lenovo P1Gen2. There the problem is only with the > integrated graphics and an OLED screen - we tracked it down to an issue > in the i915 driver where it wasn't giving enough time for eDP link > training. It turned out this was due to the driver using the wrong > clocks after a suspend and resume . > > > > Intel recently up-streamed a fix (commit 2f216a85 - it went into > 5.4-rc8) > > > > I'm working on doing a patch that I'm hoping to get into Debian to > backport - just not done yet :) The patch is pretty small (I've attached > it) so you might want to give it a go and see if it helps. > > > > Note - we did also test X1 extreme with OLED panel and didn't see a > problem therebut it's a really subtle timing issue so some units > might be more susceptible than others. Maybe worth a go? > > > > If it does make a difference let me know. > > Mark > >
Bug#944350: [External] Bug#944350: systemd: screen remains off after waking up from suspend
Hi, I don't know if this is helpful but I recently debugged a similar issue on the Lenovo P1Gen2. There the problem is only with the integrated graphics and an OLED screen - we tracked it down to an issue in the i915 driver where it wasn't giving enough time for eDP link training. It turned out this was due to the driver using the wrong clocks after a suspend and resume . Intel recently up-streamed a fix (commit 2f216a85 - it went into 5.4-rc8) I'm working on doing a patch that I'm hoping to get into Debian to backport - just not done yet :) The patch is pretty small (I've attached it) so you might want to give it a go and see if it helps. Note - we did also test X1 extreme with OLED panel and didn't see a problem therebut it's a really subtle timing issue so some units might be more susceptible than others. Maybe worth a go? If it does make a difference let me know. Mark > -Original Message- > From: Jiri Kanicky > Sent: Sunday, November 24, 2019 9:13 PM > To: 944...@bugs.debian.org > Subject: [External] Bug#944350: systemd: screen remains off after waking up > from suspend > > Further to the issue, when I set BIOS to discrete graphics only, I am > experiencing the same issue when booting the system from shutdown state. > The screen stays off, but the OS is booted and working. 0001-drm-i915-update-rawclk-also-on-resume.patch Description: 0001-drm-i915-update-rawclk-also-on-resume.patch
Bug#943515: [External] Bug#943515: linux-image-5.2.0-3-amd64: Cannot resume from suspend
> On Sat, Oct 26, 2019 at 7:28 PM Ben Hutchings > wrote: > > I have the same model and can't reproduce this. > > > > Does this still happen if you remove the acpi_call module? > > Yes, I removed acpi_call module and can't resume from suspend. > > I also done clean testing installation, with only main packages and standard > system utilities, no configuration at all. > Just boot and sudo systemctl suspend, and can't resume. > > -- > Cheers, > Anton Hi Anton, We tried here at Lenovo (using the same 5.2.17 testing stream) and weren't able to reproduce either I'm afraid. Let me know if you are able to narrow it down to something in particular. We recently debugged a suspend-and-resume issue on the P1 Gen2 using hybrid graphics mode and in that case it was a link training issue in the i915 driver caused by a timeout being too short. It only happened on a system with an OLED screen and was 'introduced' 4.19.3 as that was when eDP link re-training was enabled (it is a timeout setting in the BIOS that is the problem, not the kernel code itself, but the code change triggered the issue). In that particular case on resume everything was working fine except the screen was blank (so you could ssh in to the system succesfully). We've only seen that issue on P1G2 so it's really unlikely it's the same thing your seeing - but just in case it's helpful. Thanks Mark
Guide to correct (or best) way to build and provide patches for the debian kernel
If anybody out there can help this confused newbie it would be appreciated. I have been building a buster-backports 5.2.9 kernel with some backported upstream kernel patches for the audio driver. I raised a bug to get the patches with the fix included and I've just received some guidance that providing a single patch combining all the backported commits I've used isn't the best way to do things. I was pointed at https://salsa.debian.org/kernel-team/linux/merge_requests/11 as an example to follow (which was great). So...I started again - thinking this shouldn't be a big deal. I have my 7 original upstream commits and it shouldn't be too hard to just leave them as they are instead of combining thembut following the example I needed the "debian" directory with the patches/changelog/series/configs files to do this all...(I have previously just been using unpacking /usr/src/linux-source-5.2.tar.xz and then applying my patches and doing 'make deb-pkg') Did some searching and I came across a guide that suggested doing "apt source linux" so tried that (I used 'apt source linux-source-5.2') and lo-and-behold the debian directory appeared with my kernel source. I thought this was great *but* the build just doesn't work and the errors are to me somewhat cryptic and to be honest I figured I was going off down a rathole pointlessly (as an aside the error is 'unrepresentable changes to source'). I've been looking for an authoritative guide on how I should be building a debian kernel and providing patches in such a way that the over-worked debian kernel maintainers can easily go "yep, that's all good, add it" and I just can't find that detail. I'm sure it must exist as there's a load of documentation out there. I thought the kernel handbook (https://kernel-team.pages.debian.net/kernel-handbook) would be the gospel but it doesn't cover how to provide nice clean patches that the maintainers would like (which to me seems important) Any pointers or insight would be deeply appreciated. FWIW I have two bugs (#940726, #940825) that are the root of all this and whilst my priority is to get the patches I submitted with those included anything I can learn along the way to make the process faster and more helpful to maintainers/community would be great. Thanks Mark PS - I do realise using buster-backports rather than main is a bit non-standard. Unfortunately I need to be there as I have a customer I'm supporting who needs to use 5.2.9 (or newer) and a short timeframe.
Bug#940825: linux-source-5.2: Backport of wifi driver fixes to enable wifi on whiseylake based system in 5.2.9
Package: linux-source-5.2
Version: 5.2.9-2~bpo10+1
Severity: important
Tags: patch
Dear Maintainer,
* What led up to the situation?
Wifi on the Lenovo X1 Carbon Gen7 is not functional.
Intel pointed us at the attached patch comprised of upstream fixes
* What exactly did you do (or not do) that was effective (or
ineffective)?
Applied the patch and wifi was then operational
* What was the outcome of this action?
Wifi works correctly
* What outcome did you expect instead?
NA
Please let me know any questions. I'm still new to the process.
Thanks in advance for the help - we have a customer who is waiting on these
fixes in Debian (this and the SOF driver backport).
Mark
-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.9 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-source-5.2 depends on:
ii binutils 2.31.1-16
ii xz-utils 5.2.4-1
Versions of packages linux-source-5.2 recommends:
ii bc1.07.1-2+b1
ii bison 2:3.3.2.dfsg-1
ii flex 2.6.4-6.2
ii gcc 4:8.3.0-1
ii libc6-dev [libc-dev] 2.28-10
ii linux-config-5.2 5.2.9-2~bpo10+1
ii make 4.2.1-1.2
Versions of packages linux-source-5.2 suggests:
ii libncurses-dev [ncurses-dev] 6.1+20181013-2+deb10u1
pn libqt4-dev
pn pkg-config
-- no debconf information
diff -cr linux-source-5.2/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
linux-5.2.15/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
*** linux-source-5.2/drivers/net/wireless/intel/iwlwifi/cfg/22000.c
2019-08-16 04:11:12.0 -0400
--- linux-5.2.15/drivers/net/wireless/intel/iwlwifi/cfg/22000.c 2019-09-16
02:23:24.0 -0400
***
*** 80,87
--- 80,90
#define IWL_22000_QU_B_HR_B_FW_PRE"iwlwifi-Qu-b0-hr-b0-"
#define IWL_22000_HR_B_FW_PRE "iwlwifi-QuQnj-b0-hr-b0-"
#define IWL_22000_HR_A0_FW_PRE"iwlwifi-QuQnj-a0-hr-a0-"
+ #define IWL_QU_C_HR_B_FW_PRE "iwlwifi-Qu-c0-hr-b0-"
#define IWL_QU_B_JF_B_FW_PRE "iwlwifi-Qu-b0-jf-b0-"
+ #define IWL_QU_C_JF_B_FW_PRE "iwlwifi-Qu-c0-jf-b0-"
#define IWL_QUZ_A_HR_B_FW_PRE "iwlwifi-QuZ-a0-hr-b0-"
+ #define IWL_QUZ_A_JF_B_FW_PRE "iwlwifi-QuZ-a0-jf-b0-"
#define IWL_QNJ_B_JF_B_FW_PRE "iwlwifi-QuQnj-b0-jf-b0-"
#define IWL_CC_A_FW_PRE "iwlwifi-cc-a0-"
#define IWL_22000_SO_A_JF_B_FW_PRE"iwlwifi-so-a0-jf-b0-"
***
*** 106,111
--- 109,118
IWL_22000_HR_A0_FW_PRE __stringify(api) ".ucode"
#define IWL_QUZ_A_HR_B_MODULE_FIRMWARE(api) \
IWL_QUZ_A_HR_B_FW_PRE __stringify(api) ".ucode"
+ #define IWL_QUZ_A_JF_B_MODULE_FIRMWARE(api) \
+ IWL_QUZ_A_JF_B_FW_PRE __stringify(api) ".ucode"
+ #define IWL_QU_C_HR_B_MODULE_FIRMWARE(api) \
+ IWL_QU_C_HR_B_FW_PRE __stringify(api) ".ucode"
#define IWL_QU_B_JF_B_MODULE_FIRMWARE(api) \
IWL_QU_B_JF_B_FW_PRE __stringify(api) ".ucode"
#define IWL_QNJ_B_JF_B_MODULE_FIRMWARE(api) \
***
*** 241,246
--- 248,289
.max_tx_agg_size = IEEE80211_MAX_AMPDU_BUF_HT,
};
+ const struct iwl_cfg iwl_ax201_cfg_qu_hr = {
+ .name = "Intel(R) Wi-Fi 6 AX201 160MHz",
+ .fw_name_pre = IWL_22000_QU_B_HR_B_FW_PRE,
+ IWL_DEVICE_22500,
+ /*
+* This device doesn't support receiving BlockAck with a large bitmap
+* so we need to restrict the size of transmitted aggregation to the
+* HT size; mac80211 would otherwise pick the HE max (256) by default.
+*/
+ .max_tx_agg_size = IEEE80211_MAX_AMPDU_BUF_HT,
+ };
+
+ const struct iwl_cfg iwl_ax101_cfg_qu_c0_hr_b0 = {
+ .name = "Intel(R) Wi-Fi 6 AX101",
+ .fw_name_pre = IWL_QU_C_HR_B_FW_PRE,
+ IWL_DEVICE_22500,
+ /*
+* This device doesn't support receiving BlockAck with a large bitmap
+* so we need to restrict the size of transmitted aggregation to the
+* HT size; mac80211 would otherwise pick the HE max (256) by default.
+*/
+ .max_tx_agg_size = IEEE80211_MAX_AMPDU_BUF_HT,
+ };
+
+ const struct iwl_cfg iwl_ax201_cfg_qu_c0_hr_b0 = {
+ .name = "Intel(R) Wi-Fi 6 AX201 160MHz",
+ .fw_name_pre = IWL_QU_C_HR_B_FW_PRE,
+ IWL_DEVICE_22500,
+ /*
+* This device doesn't support receiving BlockAck with a large bitmap
+* so we need to restrict the size of transmitted aggregation to the
+* HT size; mac80211 would otherwise pick the HE max (256) by default.
+*/
+ .max_tx_agg_size =
Bug#940726: linux-source-5.2: Enable SOF audio driver and back-port fixes required to 5.2 kernel
Package: linux-source-5.2
Version: 5.2.9-2~bpo10+1
Severity: important
Tags: patch
Dear Maintainer,
* What led up to the situation?
The Lenovo X1 Carbon Gen 7 laptops use the Whiskeylake CPU and when testing
with Debian we found the audio was not working.
Whiskeylake requires the new SOF audio driver to be enabled - but some fixes
also need to be backported to prevent firmware load issues seen during suspend
and resume
Note we are using the buster-backports 5.2 kernel as SOF audio driver support
is not available in the earlier kernels.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Enabled SOF audio driver kernel configs and rebuilt the kernel. Tested and
debugged the suspend/resume issue and identified the required commits from the
working 5.3 kernel.org kernel that are needed to fix the issue.
* What was the outcome of this action?
Audio is working correctly. The driver appears stable
* What outcome did you expect instead?
NA
Notes:
The patch I'm uploading is a combo of the following applied to 5.2:
https://github.com/thesofproject/linux/commit/c760776089f147c4d28875619f3a917c02d42307
https://github.com/thesofproject/linux/commit/bb1ea3b31c28a131a5f5a50dd325198645526b19
https://github.com/thesofproject/linux/commit/64632de9140e52b72781fefe542314db7cd29d8c
https://github.com/thesofproject/linux/commit/bf705eaa7ce07f9c132f8e367fc2fc46b7842528
https://github.com/thesofproject/linux/commit/38d0e9fc227c7876d09754863adc88aeca6dd205
https://github.com/thesofproject/linux/commit/f5dbba9fee801f4678a50d92c785f7f24d4ee2c6
https://github.com/thesofproject/linux/commit/7623ae793c28cc0928c5d1292542dbb92fc2e9e2
The kconfig snipped I'm also uploading is based on config settings from the SOF
team
This is my first bug raised against Debian - Lenovo are actively focussing on
getting Debian working on our systems so I'm hoping to get a lot more involved.
Please do let me know if I've made any mistakes or things I can improve on for
future bugs.
Thanks
Mrk Pearson
-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.9 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-source-5.2 depends on:
ii binutils 2.31.1-16
ii xz-utils 5.2.4-1
Versions of packages linux-source-5.2 recommends:
ii bc1.07.1-2+b1
ii bison 2:3.3.2.dfsg-1
ii flex 2.6.4-6.2
ii gcc 4:8.3.0-1
ii libc6-dev [libc-dev] 2.28-10
ii linux-config-5.2 5.2.9-2~bpo10+1
ii make 4.2.1-1.2
Versions of packages linux-source-5.2 suggests:
ii libncurses-dev [ncurses-dev] 6.1+20181013-2+deb10u1
pn libqt4-dev
pn pkg-config
-- no debconf information
diff -Naurp linux-source-5.2-orig/sound/soc/sof/control.c
linux-source-5.2/sound/soc/sof/control.c
--- linux-source-5.2-orig/sound/soc/sof/control.c 2019-08-16
04:11:12.0 -0400
+++ linux-source-5.2/sound/soc/sof/control.c2019-09-18 22:18:22.970932678
-0400
@@ -39,26 +39,8 @@ int snd_sof_volume_get(struct snd_kcontr
struct soc_mixer_control *sm =
(struct soc_mixer_control *)kcontrol->private_value;
struct snd_sof_control *scontrol = sm->dobj.private;
- struct snd_sof_dev *sdev = scontrol->sdev;
struct sof_ipc_ctrl_data *cdata = scontrol->control_data;
unsigned int i, channels = scontrol->num_channels;
- int err, ret;
-
- ret = pm_runtime_get_sync(sdev->dev);
- if (ret < 0) {
- dev_err_ratelimited(sdev->dev,
- "error: volume get failed to resume %d\n",
- ret);
- pm_runtime_put_noidle(sdev->dev);
- return ret;
- }
-
- /* get all the mixer data from DSP */
- snd_sof_ipc_set_get_comp_data(sdev->ipc, scontrol,
- SOF_IPC_COMP_GET_VALUE,
- SOF_CTRL_TYPE_VALUE_CHAN_GET,
- SOF_CTRL_CMD_VOLUME,
- false);
/* read back each channel */
for (i = 0; i < channels; i++)
@@ -66,12 +48,6 @@ int snd_sof_volume_get(struct snd_kcontr
ipc_to_mixer(cdata->chanv[i].value,
scontrol->volume_table, sm->max + 1);
- pm_runtime_mark_last_busy(sdev->dev);
- err = pm_runtime_put_autosuspend(sdev->dev);
- if (err < 0)
- dev_err_ratelimited(sdev->dev,
- "error: volume get failed to idle %d\n",
-
buster backports for 5.3 kernel
Hi, Does anybody know if and when there would be a buster backports for the now stable 5.3 kernel? If it's an exercise in progress and there is anything I can help with please let me know (I realise it was only declared stable yesterday :)). Thanks! Mark
RE: [External] Re: Lenovo and Debian
> In Debian unstable we will move to 5.3 shortly after it is released, > depending on > whether there are important regressions or integration to be resolved. > > Debian 10 "buster" will always have a 4.19-based kernel, but users can opt to > install newer kernel versions from buster-backports. > As our customer wants a 5.2.9 kernel, I believe they will be using the buster-backports package for that (I'll confirm). If we want to enable the SOF driver and it's options by default are there any pointers about how I would do that? Is it just a case of pasting the CONFIG_ settings to this email thread or is something more subtle required (defconfig snippet etc)? > > - Is there any solution available if we wanted to get the SOF fixes > > into Debian Buster sooner. The SOF team have their own kernel but I > > can track down commits where they pushed changes upstream etc. > > We're happy to take tested backports of changes that have been accepted > upstream. > > That would include both: > > * Applying the fixes from 5.4 to our 5.3-based kernel for unstable > * Adding the SOF driver to the 4.19-based kernel for buster > Got it - thanks. I managed to get the audio seemingly working in 5.2.9 with no driver changes needed (different firmware image) so I'm hoping (fingers crossed) I don't have to go this route but it's good to know it's available. Thanks for all the help - I appreciate all the pointers. Mark
