As mentioned it probably would be good to upgrade the release version of fedora.
With the release of Fedora 40 this week it seems f38 will be going EOL within about 30 days and no further updates of any kind will be seen after that happens.
This is a kernel bug that is being worked on.
https://bugzilla.kernel.org/show_bug.cgi?id=218740
1 Like
Thanks a lot !!! This is really a good news to me. Now I can relax and wait for fixed kernel. And also, when the fix is incorporated, upgrading to F39 or F40 will be much easier. In the mean time, I will look for a way to upgrade Intel ME.
I wonder why noboxy else in Fedora is complaining. Is e1000 already outdated ?
Kernel 6.8.7 is out, but may still be in testing for F38. I had it on my f39 workstation before upgrading to f40.
The bug is still in 6.8.7
I did report this the other day ( 2276325 – Lenovo M910Q hardware boot fails with "Bug: scheduling while atomic" when ethernet connected ).
Since it’s an upstream issue there’s probably not much the Fedora maintainers could do before it gets fixed there.
I’m also surprised that this bug is not more widely noticed. Perhaps it only effects some hardware implementations of the e1000 (or not many people are still using Ethernet 
Ah, Me Bad. I should have searched in bugzilla, not only in “Ask Fedora”.
Since it’s an upstream issue there’s probably not much the Fedora maintainers could do before it gets fixed there.
And the patch seems to be still under review as of 2024-04-24, we need to wait for a few more days.
I’m also surprised that this bug is not more widely noticed. Perhaps it only effects some hardware implementations of the e1000 (or not many people are still using Ethernet
Indeed. Just FYI,
[takemura@mocha ~]$ sudo lspci -s 00:1f.6 -vvv
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10)
DeviceName: Onboard - Ethernet
Subsystem: ASUSTeK Computer Inc. Device 8672
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 134
Region 0: Memory at a1100000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee002f8 Data: 0000
Kernel driver in use: e1000e
Kernel modules: e1000e
1 Like
Kernel 6.8.8 is out but the patch did not make it into this release…
Unfortunately, it is still under review…
https://lkml.org/lkml/2024/4/28/97
Good news. The patch entered into net-dev tree.
https://lkml.org/lkml/2024/4/29/1047
6.8.9-300.fc40 is in the fedora 40 testing repo now.
Unfortunately this doesn’t fix the problem for me.
I wonder if the fix made it into that release …
I don’t see the fix commit (387f295cb2150ed164905b648d76dfcbd3621778) in the change log.
The patch was included on May 1, but looks like we have to wait for 6.8.10, as the kernel package maintainer says in the bugzilla page you created
2276325 – Lenovo M910Q hardware boot fails with “Bug: scheduling while atomic” when ethernet connected.
I found several people also reported the problem in the page. My machine is a desktop one and so I never thougt of pulling out ether cable.
On the machine I have problem with it also occurs on boot (if the Ethernet cable is attached).
6.9.0 is out in rawhide (for 41).
I installed this kernel on F40 and it fixes the problem for me.
I’m not sure when the build for F40 will be created (maybe in a day or so).
https://koji.fedoraproject.org/koji/buildinfo?buildID=2451284
2 Likes
6.8.10-300.fc40.x86_64 is in koji now and it also fixes the problem. (perhaps 6.9 will not be packaged for F40).
F38 reached EOL and this bug remains unfixed there forever. So I just updated to F39, which installed kernel-6.8.10-200.fc39 as a default, and verified that it fixes this problem. Thank you vk2bea for the solution.
On reboot after update, firewalld stopped working with
internal:0:0-0: Error: Could not process rules: device or resource busy
(Not exactly, the log is in Japanese). I could not figure out what is wrong, and searched the net for an hour or so without solution. Finally, I just
systemctl restart firewalld.service
and it seems to be working fine as in F38. Strange, but this is another problem.
As for Interl ME update, I have not figrured out how to do, but from the link [Update Intel Me using Linux] which gnwiii kindly provided, it seems to me that making a Windows-PE bootable USB memory stick with Interl-ME and Interl-MEI drivers installed and contains ME updater leads to the solution. I have no knowledge or experience with virtual machine and very little experience on Windows so it will take me long time but I will continue to figure out.
Thank you everyone for giving me advice, suggestions, and a solution.
1 Like
Probably because the firewald service was changed by the update so needed a restart, this would be normal for a changed running service of systemd.
Well, when you upgrade a daemon package on a running system. it can happen. Usually the packager takes care of this through postscripts and administrators do not have to mannually restart the daemon, though. But on system upgrade, this cannot happen.
I used dnf system-upgrade. I downloaded upgrade packages (in F38)
sudo dnf system-upgrade download --releasever=39
and then restarted (into F38) to upgrade
sudo dnf system-upgrade reboot.
After upgrade is completed,, the system automatically reboots into fresh F39. The running (old F38) firewalld must be killed and F39 firewalld must be started in a fresh F39 environment during this automatical reboot. Do I miss something?
By the way the system is warning about irrelevant replies and suggests to open a new topic. Should I? It is mysterious to me but harmless as not reproduced in the following boots.
Not sure, it depends on if you feel like it. If not, just bring it up in a new topic in the future if/when you need to. Also this topic has a marked solution.
No it appears not, I was really just making a suggestion as to what may be the reason. Something (one particular task) from an update failing with no outwardly apparent error until the service fails could happen.
When doing such a reboot any configs from f38 would automatically be stopped and only the new service in f39 would be started. Manual changes should not normally be required as long as the user has not been using a non-standard firewall config and needs to update the settings with the new OS version.
Yes, unless your follow on post is directly related to the original thread, once a thread has a marked solution you should open your own thread with specific details about your problem to avoid confusion and ensure that your problem gets appropriate attention.
In general, users are discouraged fromme too posts unless they can contribute to the solution for the original poster.