Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack
Package: src:linux
Version: 6.1.90-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
Rebooting the box after kernel package upgrade
* What exactly did you do (or not do) that was effective (or
ineffective)?
Nothing
* What was the outcome of this action?
Nothing
* What outcome did you expect instead?
Rebooting without traces in the logs
-- Package-specific info:
** Version:
Linux version 6.1.0-21-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03)
** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64
root=UUID=a75e6ad5-37fc-4f69-9361-f94d6c0e5d2f ro net.ifnames=0 apparmor=0
selinux=0 noresume consoleblank=0 console=tty1
** Tainted: WOE (12800)
* kernel issued warning
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
May 7 08:10:12 cerberus kernel: [ 76.203881] [ cut here
]
May 7 08:10:12 cerberus kernel: [ 76.203895] WARNING: CPU: 3 PID: 0 at
net/bridge/br_netfilter_hooks.c:622 br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
May 7 08:10:12 cerberus kernel: [ 76.203911] Modules linked in: ctr ccm
nf_tables xt_nat xt_recent xt_geoip(OE) xt_NFQUEUE xt_mark xt_CT xt_tcpudp
xt_helper nf_nat_ftp nf_conntrack_ftp ip6table_raw ip6table_mangle ip6table_nat
xt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_LOG nf_log_syslog ipt_REJECT
nf_reject_ipv4 iptable_raw iptable_mangle xt_multiport xt_state xt_limit
xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c
ip6table_filter ip6_tables iptable_filter ip_tables x_tables ovpn_dco_v2(OE)
ip6_udp_tunnel udp_tunnel tcp_bbr nct6775 nct6775_core hwmon_vid br_netfilter
bridge stp llc nfnetlink_queue nfnetlink i915 ppdev intel_rapl_msr evdev
intel_rapl_common x86_pkg_temp_thermal intel_powerclamp drm_buddy coretemp
video rt2800usb wmi ghash_clmulni_intel drm_display_helper rt2x00usb
sha512_ssse3 sha512_generic rt2800lib rt2x00lib cec sha256_ssse3 sha1_ssse3
rc_core mac80211 aesni_intel ttm crypto_simd drm_kms_helper libarc4 cryptd
cfg80211 rapl intel_cstate drm intel_uncore rfkill parport_pc pcspkr
May 7 08:10:12 cerberus kernel: [ 76.203999] serio_raw iTCO_wdt
intel_pmc_bxt iTCO_vendor_support parport watchdog at24 button ext4 crc16
mbcache jbd2 crc32c_generic sg sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif
crct10dif_generic ahci libahci libata crct10dif_pclmul crct10dif_common
crc32_pclmul crc32c_intel psmouse scsi_mod i2c_i801 i2c_smbus ehci_pci ehci_hcd
scsi_common lpc_ich usbcore igb i2c_algo_bit usb_common dca
May 7 08:10:12 cerberus kernel: [ 76.204039] CPU: 3 PID: 0 Comm: swapper/3
Tainted: G OE 6.1.0-21-amd64 #1 Debian 6.1.90-1
May 7 08:10:12 cerberus kernel: [ 76.204044] Hardware name: Sophos UTM/To be
filled by O.E.M., BIOS 4.6.4 11/08/2011
May 7 08:10:12 cerberus kernel: [ 76.204046] RIP:
0010:br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
May 7 08:10:12 cerberus kernel: [ 76.204056] Code: df e8 4b b7 cd fa 66 83
ab b8 00 00 00 08 eb 94 be 04 00 00 00 48 89 df e8 34 b7 cd fa 66 83 ab b8 00
00 00 04 e9 7a ff ff ff <0f> 0b e9 f0 fe ff ff 0f 0b e9 dd fe ff ff 48 89 ef e8
41 67 d8 fa
May 7 08:10:12 cerberus kernel: [ 76.204059] RSP: 0018:bf5600144928
EFLAGS: 00010202
May 7 08:10:12 cerberus kernel: [ 76.204062] RAX: 0002 RBX:
9ac2862ff300 RCX:
May 7 08:10:12 cerberus kernel: [ 76.204065] RDX: bf5600144980 RSI:
9ac2862ff300 RDI:
May 7 08:10:12 cerberus kernel: [ 76.204067] RBP: 9ac2848a8100 R08:
0001 R09: 9ac2872be980
May 7 08:10:12 cerberus kernel: [ 76.204070] R10: 9ac2872be000 R11:
0002 R12: bf5600144980
May 7 08:10:12 cerberus kernel: [ 76.204072] R13: R14:
9ac282f4bac0 R15: 9ac2d027da00
May 7 08:10:12 cerberus kernel: [ 76.204074] FS: ()
GS:9ac5b018() knlGS:
May 7 08:10:12 cerberus kernel: [ 76.204077] CS: 0010 DS: ES:
CR0: 80050033
May 7 08:10:12 cerberus kernel: [ 76.204080] CR2: 5618751eb018 CR3:
2e610006 CR4: 000606e0
May 7 08:10:12 cerberus kernel: [ 76.204083] Call Trace:
May 7 08:10:12 cerberus kernel: [ 76.204087]
May 7 08:10:12 cerberus kernel: [ 76.204090] ? __warn+0x7d/0xc0
May 7 08:10:12 cerberus kernel: [ 76.204097] ? br_nf_local_in+0x1a9/0x1d0
[br_netfilter]
May 7 08:10:12 cerberus kernel: [ 76.204105] ? report_bug+0xe2/0x150
May 7 08:10:12 cerberus kernel: [ 76.204113] ? handle_bug+0x41/0x70
May 7 08:10:12 cerberus kernel: [ 76.204118] ? exc_invalid_op+0x13/0x60
May 7 08:10:12 cerberus kernel: [ 76.204122] ? asm_exc_invalid_op+0x16/0x20
May 7 08:10:12 cerberus kernel: [ 76.204128] ? br_nf_local_in+0x1a9/0x1d0
[br_netfilter]
May 7 08:10:12 cerberus k
Re: Updates to linux-firmware
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 the new links and new files. If you don't, and the temptations is IMO rather high, then you'd create another monumental task like the one I went through. And that REALLY did not make me happy or considered fun. At all. As I see it,
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 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
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. > 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 firmware package updates have lagged before, the kernel packages are normally quite up-to-date. But sometimes there are other factors which cause delays which normally aren't there. The time64 transition f.e. caused 'some' disruptions. But (my) update-to-6.8 MR has now been merged into master, so an update to the 6.8 kernel is in the works. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares
Hi, New kernel 6.1.0-21 seems to be out. Could you verify if this bus is fixed in it? I found from https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.90 that there is a commit b3686200adba26dd1f8beee3d9c1b34563db1e65 is that a fix for this? Regards, Kari From: Salvatore Bonaccorso on behalf of Salvatore Bonaccorso Date: Thursday, 18. April 2024 at 9.39 To: Kari Lempiäinen Cc: 1069...@bugs.debian.org <1069...@bugs.debian.org>, Manfred Larcher , 1069...@bugs.debian.org <1069...@bugs.debian.org> Subject: Re: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares Hi Kari, On Thu, Apr 18, 2024 at 05:31:33AM +, Kari Lempiäinen wrote: > Hi, > > I think I spoke too soon. I removed 'noserverino' options from all > my cifs mounts yesterday and u/remounted them. From last night > syslog I can still find the "directory entry name would overflow > frame end of buf" entries. > > I have options like this in my fstab: > //mercury/backups/mnt/backups cifs > credentials=/etc/smbcredentials,uid=kari,gid=kari,_netdev,dir_mode=0775,file_mode=0775,noperm,vers=3.0 > 0 0 Thanks for reporting back! So it might be possible that the noserverino just makes the issue easier visible. If I would provide you a (unsigned!) kernel-image package with a tentative patch from upstream, asking for testing, could you boot one affected machine into it to verify if the problem is solved? Regards, Salvatore
Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares
Hi, On Tue, May 07, 2024 at 03:30:58PM +, Kari Lempiäinen wrote: > Hi, > > New kernel 6.1.0-21 seems to be out. Could you verify if this bus is fixed in > it? > > I found from > https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.90 that > there is a commit b3686200adba26dd1f8beee3d9c1b34563db1e65 is that a fix for > this? I closed the bug in the changelog with it, with the testing case I had at hand. But please verify if that is the case as well in your setup. Can you then report back? Regards, Salvatore
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 firmware package updates have lagged before, the kernel packages are > normally quite up-to-date. But sometimes there are other factors which cause > delays which normally aren't there. The time64 transition f.e. caused 'som
Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares
Hi, Looks like this fixed the problem. I ran a couple of backup jobs to cifs-mounted shares and no error messages so far. Thanks! Regards, Kari From: Salvatore Bonaccorso on behalf of Salvatore Bonaccorso Date: Tuesday, 7. May 2024 at 19.01 To: Kari Lempiäinen Cc: 1069...@bugs.debian.org <1069...@bugs.debian.org>, Manfred Larcher , 1069...@bugs.debian.org <1069...@bugs.debian.org> Subject: Re: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares Hi, On Tue, May 07, 2024 at 03:30:58PM +, Kari Lempiäinen wrote: > Hi, > > New kernel 6.1.0-21 seems to be out. Could you verify if this bus is fixed in > it? > > I found from > https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.90 that > there is a commit b3686200adba26dd1f8beee3d9c1b34563db1e65 is that a fix for > this? I closed the bug in the changelog with it, with the testing case I had at hand. But please verify if that is the case as well in your setup. Can you then report back? Regards, Salvatore
Processed: Re: Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack
Processing control commands: > tags -1 + moreinfo Bug #1070685 [src:linux] linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack Added tag(s) moreinfo. -- 1070685: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070685 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack
Control: tags -1 + moreinfo
Hi Tito,
On Tue, May 07, 2024 at 10:19:44AM +0200, Tito Ragusa wrote:
> Package: src:linux
> Version: 6.1.90-1
> Severity: normal
>
> Dear Maintainer,
>
>* What led up to the situation?
>
>Rebooting the box after kernel package upgrade
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
>
>Nothing
>
>* What was the outcome of this action?
>
>Nothing
>
>* What outcome did you expect instead?
>
>Rebooting without traces in the logs
>
> -- Package-specific info:
> ** Version:
> Linux version 6.1.0-21-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian
> 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
> PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03)
>
> ** Command line:
> BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64
> root=UUID=a75e6ad5-37fc-4f69-9361-f94d6c0e5d2f ro net.ifnames=0 apparmor=0
> selinux=0 noresume consoleblank=0 console=tty1
>
> ** Tainted: WOE (12800)
> * kernel issued warning
> * externally-built ("out-of-tree") module was loaded
> * unsigned module was loaded
>
> ** Kernel log:
> May 7 08:10:12 cerberus kernel: [ 76.203881] [ cut here
> ]
> May 7 08:10:12 cerberus kernel: [ 76.203895] WARNING: CPU: 3 PID: 0 at
> net/bridge/br_netfilter_hooks.c:622 br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
> May 7 08:10:12 cerberus kernel: [ 76.203911] Modules linked in: ctr ccm
> nf_tables xt_nat xt_recent xt_geoip(OE) xt_NFQUEUE xt_mark xt_CT xt_tcpudp
> xt_helper nf_nat_ftp nf_conntrack_ftp ip6table_raw ip6table_mangle
> ip6table_nat xt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_LOG nf_log_syslog
> ipt_REJECT nf_reject_ipv4 iptable_raw iptable_mangle xt_multiport xt_state
> xt_limit xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c
> ip6table_filter ip6_tables iptable_filter ip_tables x_tables ovpn_dco_v2(OE)
> ip6_udp_tunnel udp_tunnel tcp_bbr nct6775 nct6775_core hwmon_vid br_netfilter
> bridge stp llc nfnetlink_queue nfnetlink i915 ppdev intel_rapl_msr evdev
> intel_rapl_common x86_pkg_temp_thermal intel_powerclamp drm_buddy coretemp
> video rt2800usb wmi ghash_clmulni_intel drm_display_helper rt2x00usb
> sha512_ssse3 sha512_generic rt2800lib rt2x00lib cec sha256_ssse3 sha1_ssse3
> rc_core mac80211 aesni_intel ttm crypto_simd drm_kms_helper libarc4 cryptd
> cfg80211 rapl intel_cstate drm intel_uncore rfkill parport_pc pcspkr
> May 7 08:10:12 cerberus kernel: [ 76.203999] serio_raw iTCO_wdt
> intel_pmc_bxt iTCO_vendor_support parport watchdog at24 button ext4 crc16
> mbcache jbd2 crc32c_generic sg sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif
> crct10dif_generic ahci libahci libata crct10dif_pclmul crct10dif_common
> crc32_pclmul crc32c_intel psmouse scsi_mod i2c_i801 i2c_smbus ehci_pci
> ehci_hcd scsi_common lpc_ich usbcore igb i2c_algo_bit usb_common dca
> May 7 08:10:12 cerberus kernel: [ 76.204039] CPU: 3 PID: 0 Comm: swapper/3
> Tainted: G OE 6.1.0-21-amd64 #1 Debian 6.1.90-1
> May 7 08:10:12 cerberus kernel: [ 76.204044] Hardware name: Sophos UTM/To
> be filled by O.E.M., BIOS 4.6.4 11/08/2011
> May 7 08:10:12 cerberus kernel: [ 76.204046] RIP:
> 0010:br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
> May 7 08:10:12 cerberus kernel: [ 76.204056] Code: df e8 4b b7 cd fa 66 83
> ab b8 00 00 00 08 eb 94 be 04 00 00 00 48 89 df e8 34 b7 cd fa 66 83 ab b8 00
> 00 00 04 e9 7a ff ff ff <0f> 0b e9 f0 fe ff ff 0f 0b e9 dd fe ff ff 48 89 ef
> e8 41 67 d8 fa
> May 7 08:10:12 cerberus kernel: [ 76.204059] RSP: 0018:bf5600144928
> EFLAGS: 00010202
> May 7 08:10:12 cerberus kernel: [ 76.204062] RAX: 0002 RBX:
> 9ac2862ff300 RCX:
> May 7 08:10:12 cerberus kernel: [ 76.204065] RDX: bf5600144980 RSI:
> 9ac2862ff300 RDI:
> May 7 08:10:12 cerberus kernel: [ 76.204067] RBP: 9ac2848a8100 R08:
> 0001 R09: 9ac2872be980
> May 7 08:10:12 cerberus kernel: [ 76.204070] R10: 9ac2872be000 R11:
> 0002 R12: bf5600144980
> May 7 08:10:12 cerberus kernel: [ 76.204072] R13: R14:
> 9ac282f4bac0 R15: 9ac2d027da00
> May 7 08:10:12 cerberus kernel: [ 76.204074] FS: ()
> GS:9ac5b018() knlGS:
> May 7 08:10:12 cerberus kernel: [ 76.204077] CS: 0010 DS: ES:
> CR0: 80050033
> May 7 08:10:12 cerberus kernel: [ 76.204080] CR2: 5618751eb018 CR3:
> 2e610006 CR4: 000606e0
> May 7 08:10:12 cerberus kernel: [ 76.204083] Call Trace:
> May 7 08:10:12 cerberus kernel: [ 76.204087]
> May 7 08:10:12 cerberus kernel: [ 76.204090] ? __warn+0x7d/0xc0
> May 7 08:10:12 cerberus kernel: [ 76.204097] ? br_nf_local_in+0x1a9/0x1d0
> [br_netfilter]
> May 7 08:10:12 cerberus kernel: [ 76.204105] ? report_bug+0xe2/0x150
> May 7 08:10:12 cerberus kernel: [ 76.204113] ?
Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares
Hi, On Tue, May 07, 2024 at 06:35:06PM +, Kari Lempiäinen wrote: > Hi, > > Looks like this fixed the problem. I ran a couple of backup jobs to > cifs-mounted shares and no error messages so far. Thanks! Thanks for the confirmation! Regards, Salvatore
Bug#1070717: linux-image-6.7.12-amd64: Mediatek mt7921e WiFi fails connecting after hibernation since 6.7.12
Package: src:linux Version: 6.7.12-1 Severity: normal Dear Maintainer, Since upgrading to Linux 6.7.12 from 6.6.15, connecting to WiFi after waking up from hibernation fails. The journal lists these kernel errors, I can't see any other relevant errors: Mai 07 16:53:03 kernel: mt7921e :01:00.0: Message 00020007 (seq 1) timeout Mai 07 16:53:03 kernel: mt7921e :01:00.0: PM: dpm_run_callback(): pci_pm_restore+0x0/0xe0 returns -110 Mai 07 16:53:03 kernel: mt7921e :01:00.0: PM: failed to restore async: error -110 Mai 07 16:53:03 kernel: mt7921e :01:00.0: Failed to get patch semaphore Mai 07 16:53:03 kernel: mt7921e :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xfff4ff80 flags=0x] Mai 07 16:53:03 kernel: mt7921e :01:00.0: Message 0010 (seq 14) timeout Mai 07 16:53:03 kernel: mt7921e :01:00.0: Failed to get patch semaphore Mai 07 16:53:03 kernel: mt7921e :01:00.0: Message 0010 (seq 15) timeout Mai 07 16:53:03 kernel: mt7921e :01:00.0: Failed to get patch semaphore Mai 07 16:53:03 kernel: mt7921e :01:00.0: Message 46ed (seq 1) timeout Mai 07 16:53:03 kernel: mt7921e :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xffbb9a80 flags=0x] Mai 07 16:53:03 kernel: ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume+0x0/0x1b0 [cfg80211] returns -110 Mai 07 16:53:03 kernel: ieee80211 phy0: PM: failed to restore async: error -110 Mai 07 16:53:06 kernel: mt7921e :01:00.0: Message 0010 (seq 2) timeout Mai 07 16:53:06 kernel: mt7921e :01:00.0: Failed to get patch semaphore Mai 07 16:53:09 kernel: mt7921e :01:00.0: Message 0010 (seq 3) timeout Mai 07 16:53:09 kernel: mt7921e :01:00.0: Failed to get patch semaphore Mai 07 16:53:13 kernel: mt7921e :01:00.0: Message 46ed (seq 4) timeout Mai 07 16:53:13 kernel: mt7921e :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xffd52d00 flags=0x] dmesg doesn't indicated any firmware issues when grepping for mt7921e. The firmware at hand comes directly from the April tarball on kernel.org, as the iGPU already needed much newer firmware as available from Debian repos, so I just copied over the whole archive. This wasn't an issue with 6.6.15. Also, in the last weeks before 6.7.12 was released to testing, I did compile 6.8.8 and 6.8.9 based on Debians 6.6.15 config (updates with make olddefconfig) and compiled to Debian packages, which showed a similar behavior. So this might be an upstream issue, yet I can't be sure. -- Package-specific info: ** Version: Linux version 6.7.12-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-23) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24) ** Command line: BOOT_IMAGE=/@/boot/vmlinuz-6.7.12-amd64 root=UUID=557dc1ed-2335-4fe5-806d-012051c96cbf ro rootflags=subvol=@ quiet cryptdevice=UUID=91aa7dec-7df2-4330-82c5-f5b544612416:luks-91aa7dec-7df2-4330-82c5-f5b544612416 root=/dev/mapper/luks-91aa7dec-7df2-4330-82c5-f5b544612416 splash resume=/dev/mapper/luks-4deac7d3-52a0-4f41-84bb-b913eb17f834 ** Not tainted ** Kernel log: [ 422.107842] audit: type=1400 audit(1715094289.283:515): apparmor="ALLOWED" operation="open" class="file" profile="libreoffice-soffice" name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max" pid=6388 comm=433220436F6D70696C657254687265 requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [ 422.128664] audit: type=1400 audit(1715094289.303:516): apparmor="ALLOWED" operation="open" class="file" profile="libreoffice-soffice" name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max" pid=6388 comm=433220436F6D70696C657254687265 requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [ 422.151895] audit: type=1400 audit(1715094289.327:517): apparmor="ALLOWED" operation="open" class="file" profile="libreoffice-soffice" name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max" pid=6388 comm=433220436F6D70696C657254687265 requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [ 422.172284] audit: type=1400 audit(1715094289.347:518): apparmor="ALLOWED" operation="open" class="file" profile="libreoffice-soffice" name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max" pid=6388 comm=433220436F6D70696C657254687265 requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [ 422.194409] audit: type=1400 audit(1715094289.371:519): apparmor="ALLOWED" operation="open" class="file" profile="libreoffice-soffice" name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max" pid=6388 comm=433120436F6D70696C657254687265 requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [ 435
Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack
On Tue, 7 May 2024 21:01:06 +0200
Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi Tito,
>
> On Tue, May 07, 2024 at 10:19:44AM +0200, Tito Ragusa wrote:
> > Package: src:linux
> > Version: 6.1.90-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> >* What led up to the situation?
> >
> >Rebooting the box after kernel package upgrade
> >
> >* What exactly did you do (or not do) that was effective (or
> > ineffective)?
> >
> >Nothing
> >
> >* What was the outcome of this action?
> >
> >Nothing
> >
> >* What outcome did you expect instead?
> >
> >Rebooting without traces in the logs
> >
> > -- Package-specific info:
> > ** Version:
> > Linux version 6.1.0-21-amd64 (debian-kernel@lists.debian.org) (gcc-12
> > (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
> > PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03)
> >
> > ** Command line:
> > BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64
> > root=UUID=a75e6ad5-37fc-4f69-9361-f94d6c0e5d2f ro net.ifnames=0 apparmor=0
> > selinux=0 noresume consoleblank=0 console=tty1
> >
> > ** Tainted: WOE (12800)
> > * kernel issued warning
> > * externally-built ("out-of-tree") module was loaded
> > * unsigned module was loaded
> >
> > ** Kernel log:
> > May 7 08:10:12 cerberus kernel: [ 76.203881] [ cut here
> > ]
> > May 7 08:10:12 cerberus kernel: [ 76.203895] WARNING: CPU: 3 PID: 0 at
> > net/bridge/br_netfilter_hooks.c:622 br_nf_local_in+0x1a9/0x1d0
> > [br_netfilter]
> > May 7 08:10:12 cerberus kernel: [ 76.203911] Modules linked in: ctr ccm
> > nf_tables xt_nat xt_recent xt_geoip(OE) xt_NFQUEUE xt_mark xt_CT xt_tcpudp
> > xt_helper nf_nat_ftp nf_conntrack_ftp ip6table_raw ip6table_mangle
> > ip6table_nat xt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_LOG
> > nf_log_syslog ipt_REJECT nf_reject_ipv4 iptable_raw iptable_mangle
> > xt_multiport xt_state xt_limit xt_conntrack nf_conntrack nf_defrag_ipv6
> > nf_defrag_ipv4 libcrc32c ip6table_filter ip6_tables iptable_filter
> > ip_tables x_tables ovpn_dco_v2(OE) ip6_udp_tunnel udp_tunnel tcp_bbr
> > nct6775 nct6775_core hwmon_vid br_netfilter bridge stp llc nfnetlink_queue
> > nfnetlink i915 ppdev intel_rapl_msr evdev intel_rapl_common
> > x86_pkg_temp_thermal intel_powerclamp drm_buddy coretemp video rt2800usb
> > wmi ghash_clmulni_intel drm_display_helper rt2x00usb sha512_ssse3
> > sha512_generic rt2800lib rt2x00lib cec sha256_ssse3 sha1_ssse3 rc_core
> > mac80211 aesni_intel ttm crypto_simd drm_kms_helper libarc4 cryptd cfg80211
> > rapl intel_cstate
drm intel_uncore rfkill parport_pc pcspkr
> > May 7 08:10:12 cerberus kernel: [ 76.203999] serio_raw iTCO_wdt
> > intel_pmc_bxt iTCO_vendor_support parport watchdog at24 button ext4 crc16
> > mbcache jbd2 crc32c_generic sg sd_mod t10_pi crc64_rocksoft crc64
> > crc_t10dif crct10dif_generic ahci libahci libata crct10dif_pclmul
> > crct10dif_common crc32_pclmul crc32c_intel psmouse scsi_mod i2c_i801
> > i2c_smbus ehci_pci ehci_hcd scsi_common lpc_ich usbcore igb i2c_algo_bit
> > usb_common dca
> > May 7 08:10:12 cerberus kernel: [ 76.204039] CPU: 3 PID: 0 Comm:
> > swapper/3 Tainted: G OE 6.1.0-21-amd64 #1 Debian 6.1.90-1
> > May 7 08:10:12 cerberus kernel: [ 76.204044] Hardware name: Sophos
> > UTM/To be filled by O.E.M., BIOS 4.6.4 11/08/2011
> > May 7 08:10:12 cerberus kernel: [ 76.204046] RIP:
> > 0010:br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
> > May 7 08:10:12 cerberus kernel: [ 76.204056] Code: df e8 4b b7 cd fa 66
> > 83 ab b8 00 00 00 08 eb 94 be 04 00 00 00 48 89 df e8 34 b7 cd fa 66 83 ab
> > b8 00 00 00 04 e9 7a ff ff ff <0f> 0b e9 f0 fe ff ff 0f 0b e9 dd fe ff ff
> > 48 89 ef e8 41 67 d8 fa
> > May 7 08:10:12 cerberus kernel: [ 76.204059] RSP: 0018:bf5600144928
> > EFLAGS: 00010202
> > May 7 08:10:12 cerberus kernel: [ 76.204062] RAX: 0002 RBX:
> > 9ac2862ff300 RCX:
> > May 7 08:10:12 cerberus kernel: [ 76.204065] RDX: bf5600144980 RSI:
> > 9ac2862ff300 RDI:
> > May 7 08:10:12 cerberus kernel: [ 76.204067] RBP: 9ac2848a8100 R08:
> > 0001 R09: 9ac2872be980
> > May 7 08:10:12 cerberus kernel: [ 76.204070] R10: 9ac2872be000 R11:
> > 0002 R12: bf5600144980
> > May 7 08:10:12 cerberus kernel: [ 76.204072] R13: R14:
> > 9ac282f4bac0 R15: 9ac2d027da00
> > May 7 08:10:12 cerberus kernel: [ 76.204074] FS: ()
> > GS:9ac5b018() knlGS:
> > May 7 08:10:12 cerberus kernel: [ 76.204077] CS: 0010 DS: ES:
> > CR0: 80050033
> > May 7 08:10:12 cerberus kernel: [ 76.204080] CR2: 5618751eb018 CR3:
> > 2e610006 CR4: 000606e0
> > May 7 08:10:12 cerberus kernel: [ 76.204083] Call Trace:
> > May 7 08:10:12 cerberus kernel: [ 76.204087]
> > May 7 08:10
Re: Updates to linux-firmware
Hi Mark, On Tuesday, 7 May 2024 19:30:59 CEST Mark Pearson wrote: > > 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 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. > > Cool - I have taken a very quick look and kudos - amazing job. Cheers :) > 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. As it has to go through NEW, the uploader must be a DD (not a DM). AFAIK, it's not the upload that's the blocker (that should be rather quick), but the *review* of MR 85. And those reviews are VERY important (more on that later). > And, thinking about the comment previously about funding - is this something > where somebody needs some paid time to do the exercise? IIF that's an option then I'd guess they'd contact you, most likely privately. The most likely scenario, as is the case for 99% (just a guess) of the software packaged for Debian, is that someone needs to find the time (and motivation) to do that 'work' in their FREE time. > - 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. My guess is that it'll take a couple (probably <4) of hours a 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. Debian is often described as a do-ocracy so I did what was in my power and that was making a MR which would/could fix the problem I was seeing. It wasn't the most enjoyable thing I've done, but someone needed to do the 'work', so why not me? > 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? I haven't added my procedure to a MR because I wanted to have a review first. As I've learned over time, there tends to be very good reasons why things are done (and described in README.source) a certain way. I didn't manage to find the reason why the described update procedure was as written down. It could be that 'my' procedure does something wrong or is incomplete or not the best/appropriate way, which I expect will be pointed out in the review. If the reviewer thinks my procedure is actually better, then I'll write it down and submit that as MR too. That shouldn't take much time. > 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? Generally the best way to learn something is by doing it ;-) > - 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. https://gitlab.com/kernel-firmware/linux-firmware/ is now the place where upstream changes are merged. When a release is tagged, their CI now produces a deb (and rpm) package. So on https://gitlab.com/kernel-firmware/linux-firmware/-/tags you'll see a (hopefully green) checkmark indicating the success of the pipeline run. https://gitlab.com/kernel-firmware/linux-firmware/-/pipelines/1247368343 would be the one for the 20240410 tag/release and if you click through to the 'deb- release' job and then you can download or browse through to the artifact(s), which in this case is a 347 MiB deb package with all the firmware. > >> 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. > > > > But (my) update-to-6.8 MR has now been merged into master, so an update to > > the 6.8 kernel is in the works. > > That's awesome. If you want any sanity checks run on it, let me know - When you submit a MR you are (generally) expected to have verified it works as intended. While I did build a 6.8 kernel, I tend to use the 'nodoc' profile. The review of that MR (in this case by Ben) turned out that it actually contained an error ... in building the documentation. So while using the 'nodoc' is generally fine for my use case, next time I really should also make a build with the 'doc' profile (which is the default). That's why those reviews are so important! > I have a number of platf
Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure
Package: src:linux Version: 5.10.216-1 Severity: grave Justification: renders package unusable Dear Maintainer, After upgrading to linux-image-5.10.0-29 the system fails to boot with grub 'Error 16: Inconsistent filesystem structure'. Booting into linux-image-5.10.0-28-amd64 and the system is once again bootable The console displays: Booting 'Debian GNU/Linux, kernel 5.10.0-29-amd64' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /boot/vmlinuz-5.10.0-29-amd64 root=UUID=ca38e015-f8d1-4ef0-9dc9-b56d7c8 le0f1 ro [Linux-bzImage, setup=0x3c00, size=0x6b5f40] Initrd /boot/initrd. img-5.10.0-29-amd64 Error 16: Inconsistent filesystem structure Press any key to continue...- -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: QEMU product_name: Standard PC (i440FX + PIIX, 1996) product_version: pc-i440fx-8.1 chassis_vendor: QEMU chassis_version: pc-i440fx-8.1 bios_vendor: SeaBIOS bios_version: rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:05.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio SCSI [1af4:1004] Subsystem: Red Hat, Inc. Virtio SCSI [1af4:0008] Physical Slot: 5 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: virtio-pci Kernel modules: virtio_pci 00:12.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000] Subsystem: Red Hat, Inc. Virtio network device [1af4:0001] Physical Slot: 18 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: virtio-pci Kernel modules: virtio_pci 00:13.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000] Subsystem: Red Hat, Inc. Virtio network device [1af4:0001] Physical Slot: 19 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: virtio-pci Kernel modules: virtio_pci 00:1e.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] (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: 00:1f.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] (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: ** USB devices: not available -- System Information: Debian Release: 11.9 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-28-amd64 (SMP w/6 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-5.10.0-29-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.140 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.10.0-29-amd64 recommends: ii apparmor 2.13.6-10 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.10.0-29-amd64 suggests: pn debian-kernel-handbook pn grub-pc | grub-efi-amd64 | extlinux pn linux-doc-5.10 Versions of packages linux-image-5.10.0-29-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn f
