You are not logged in.
I know it is caused by the stupid mediatek wifi card, but I need Internet.
What is the VID:PID of the NIC?
Edit:
Also the interface type PCI/USB/something else e.t.c..
Last edited by loqs (2022-03-31 05:17:46)
Offline
lsusb gave me this:
Bus 003 Device 002: ID 0489:e0cd Foxconn / Hon Hai Wireless_Device
Offline
If you blacklist mt7921e can you then complete a boot using 5.17.1? Can you then trigger a panic by loading the module?
Offline
Yes and no. When I put
blacklist mt7921e in the /etc/modprobe.d/blacklist.conf, the restart worked without flaw, also the systemd-udevd processes seemed to had sorted out themselves a bit quicker.
But when I attempted to load it back in (simple
sudo insmod mt7921edid not work), I got only this:
> sudo insmod (find /usr -name '*mt7921e*' 2>/dev/null)
insmod: ERROR: could not insert module /usr/lib/modules/5.17.1-arch1-1/kernel/drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko.zst: Unknown symbol in moduleOffline
insmod does not handle module dependencies. Please try with modprobe instead.
Offline
Oh, ok, I didn't know that.
I successfully restarted and, as you said, caused kernel panic by manually reenabling the modprobe mt7921e.
Offline
Was the panic left on the screen so you could photograph it?
Also what if you disable power management?
modprobe mt7921e disable_aspm=1Offline
When I got kernel panic, I can tell only by a blinking capslock light, but the screen just freezes on the last frame.
But I can confirm your command did allow me to enable the wifi after reboot without causing a kernel panic.
Is there a way how I could automate this?
Offline
Is there a way how I could automate this?
If you mean the blacklisting add the option to the parameters the bootloader passes to the kernel. The details are specific to each bootloader.
Are you able to try the bisection kernels I linked in post #13?
Edit:
As you can have multiple kernels installed you would be able to keep a known good kernel alongside the one you are testing.
Last edited by loqs (2022-04-01 21:57:50)
Offline
Are you able to try the bisection kernels I linked in post #13?
Yes, that kernel worked, though the system-udevd processes were showing up for about 30s whereas with the blacklist it was just 3s after login.
If you mean the blacklisting add the option to the parameters the bootloader passes to the kernel. The details are specific to each bootloader.
I meant rather how to readd the module with powermanagement disabled to achieve the same functionality as when doing the steps manually.
Last edited by Kepis (2022-04-02 07:39:18)
Offline
how to readd the module with powermanagement disabled
sys2064
Offline
Thank you, this worked indeed. But yet I would like to ask, how is it possible, that when the module is blacklisted the system-udevd processes are running for barely 5s; but with the wifi module loaded (no matter how modified) it takes over half a minute?
Last edited by Kepis (2022-04-02 12:41:00)
Offline
With the last one being good, here is the next one to test
https://drive.google.com/file/d/1KGijrL … sp=sharing linux-5.15.r11441.g206825f50f90-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1OEvzAO … sp=sharing linux-headers-5.15.r11441.g206825f50f90-1-x86_64.pkg.tar.zst
The delay is likely due to waiting for the network to be available before user sessions can start. That is skipped when there are no NIC to configure.
Edit:
Is 5.17.1 working with power management disabled on the NIC?
Last edited by loqs (2022-04-02 15:35:22)
Offline
system-udevd processes are running for barely 5s; but with the wifi module loaded (no matter how modified) it takes over half a minute?
You can take a look what is to "blame":
$ systemd-analyze critical-chain
$ systemd-analyze blameBeside that, try installing 'haveged'. Maybe you're short of entropy.
Last edited by Maniaxx (2022-04-02 17:34:10)
sys2064
Offline
Beside that, try installing 'haveged'. Maybe you're short of entropy.
If the system was low on entropy haveged would not help https://github.com/jirka-h/haveged/comm … b82a32b4f2 / https://wiki.archlinux.org/title/Haveged
Offline
Wouldn't harm to check dmesg for 'random' nevertheless. There might be still issues on some systems.
https://github.com/jirka-h/haveged/issu … 1054795736
sys2064
Offline
Wouldn't harm to check dmesg for 'random' nevertheless. There might be still issues on some systems.
https://github.com/jirka-h/haveged/issu … 1054795736
True although if the issue was under the 5.17.1 kernel it will be difficult to fix as that has CONFIG_RANDOM_TRUST_CPU=y and the 5800H has RDRAND so the pool would be filled by RDRAND without needing any external sources.
Offline
Is 5.17.1 working with power management disabled on the NIC?
I don't really know, what do you mean by NIC.
Last edited by Kepis (2022-04-05 17:52:00)
Offline
network interface card
sys2064
Offline
The delay is likely due to waiting for the network to be available before user sessions can start.
No, it is not. Since I observe these processes in htop, which runs in my xorg session after I get logged in, so the user session is already up.
Also, when I added the NIC using a script, I saw the script be finished almost immediately after logging in, but the rest kept hanging there for a bit.
You can take a look what is to "blame":
I don't think I have found anything of particular interest as it doesn't add up to the time I see the system-udevd proccesses running, but here are the results for power management disabled and blacklist (trimmed down to the main differences):
systemd-analyze blame and critical-chain
with power management disabled:
182ms systemd-rfkill.service
79ms udisks2.service
5ms rtkit-daemon.service
graphical.target @1.478s
└─multi-user.target @1.478s
└─getty.target @626ms
└─getty@tty1.service @625ms
└─systemd-user-sessions.service @618ms +6ms
└─network.target @617ms
└─NetworkManager.service @574ms +42ms
└─dbus.service @562ms +10ms
└─basic.target @560ms
└─sockets.target @560ms
└─dbus.socket @560ms
└─sysinit.target @560ms
└─systemd-update-done.service @557ms +2ms
└─ldconfig.service @482ms +74ms
└─local-fs.target @481ms
└─boot.mount @383ms +98ms
└─systemd-fsck@dev-disk-by\x2duuid-C978\x2d3419.service @340ms +41ms
└─dev-disk-by\x2duuid-C978\x2d3419.device @340mswith mt7921e blacklisted:
9ms systemd-rfkill.service
graphical.target @1.539s
└─multi-user.target @1.539s
└─getty.target @597ms
└─getty@tty1.service @597ms
└─systemd-user-sessions.service @592ms +4ms
└─network.target @591ms
└─NetworkManager.service @560ms +30ms
└─dbus.service @548ms +10ms
└─basic.target @547ms
└─sockets.target @547ms
└─dbus.socket @547ms
└─sysinit.target @546ms
└─systemd-update-done.service @543ms +2ms
└─ldconfig.service @478ms +63ms
└─local-fs.target @469ms
└─boot.mount @383ms +85ms
└─systemd-fsck@dev-disk-by\x2duuid-C978\x2d3419.service @345ms +37ms
└─dev-disk-by\x2duuid-C978\x2d3419.device @344msLast edited by Kepis (2022-04-05 19:02:33)
Offline
With the last one being good, here is the next one to test
Nope, this kernel caused kernel panic when restarting even before reaching login. Like two seconds after starting from restart.
Offline
Try the 'systemd-analyze critical-chain' as well. Especially look out for the 'network.target'.
Just to make sure... the delay does not happen when you manually load the module with modprobe (when blacklisted)?
What's the output of:
sudo dmesg |grep -i randomLast edited by Maniaxx (2022-04-05 18:26:42)
sys2064
Offline
Try the 'systemd-analyze critical-chain' as well. Especially look out for the 'network.target'.
What's the output of:sudo dmesg |grep -i random
The critical-chain is most of the text, just the first couple of lines are the blame, because I deleted everything that was the same in both to make it easier to spot the differences.
the command result:
[ 0.066191] random: get_random_u64 called from __kmem_cache_create+0x2a/0x550 with crng_init=0
[ 0.075965] random: crng init done (trusting CPU's manufacturer)
[ 2.611388] systemd[1]: Starting Load/Save Random Seed...
[ 2.630621] systemd[1]: Finished Load/Save Random Seed.
[ 2.630669] audit: type=1130 audit(1649182990.652:5): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-random-seed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'Offline
$ systemd-analyze critical-chainis a separate command. Please run this as well.
You just need it to run on the bootsession with the delay. Only the highest entries (longest delays) are important.
Last edited by Maniaxx (2022-04-05 18:54:37)
sys2064
Offline
I don't understand, You have the output there already, when do you want me to run it?
Offline