Because apparently msi=0 msix=0 is relevant?
Yes, that is the point.
I don't know if you read all the thread, people speak about DHCP issue (I also thought the same thing), but seems not related with the CPU stuck.
After some tests I figured out the responsible driver and how to load it without CPU stuck: using the parameters I wrote.
The next time I will explain better, I hope my solution will help someone else.
]]>Why are you saying is not related?
solution in 2023 is not necessarily related to whatever was a problem in 2018
[Edit: stress the important tokens]
Why are you linking a generic modprobe doc page?
I found the solution that works: loading the driver with these specific parameter
Because it will spare you the module reloading dance? Because apparently msi=0 msix=0 is relevant?
]]>https://wiki.archlinux.org/title/Kernel … odprobe.d/
Edit: please also don't necrobump - your solution in 2023 isn't necessarily related to whatever was a problem in 2018
It is absolutely related, I saved this topic years ago because I have the same issue with the same MacBook 2009 version, I tried all the solutions the other users suggested, but nothing was working.
So now, that I'm still using the same MacBook 2009 with archlinux, I found the solution that works: loading the driver with these specific parameter, not a random driver, the driver for ethernet.
Why are you saying is not related? Why are you linking a generic modprobe doc page?
]]>Edit: please also don't necrobump - your solution in 2023 isn't necessarily related to whatever was a problem in 2018
]]>1. start your MacBook without ethernet plugged in
2. unload `forcedeth` driver via `sudo modprobe -r forcedeth`
3. load `forcedeth` driver via `sudo modprobe forcedeth msi=0 msix=0`
Mid 2009 MBP, have been using Arch on it for about a year with no trouble, but recently started having full system lockups as soon as I connect an ethernet cable.
When I plug in the ethernet cable with `journalctl -xf` running, the last thing I see is: `kernel: forcedeth 0000:00:0a.0 enp0s10: link up`, then a few messages about watchdog and CPU soft lockup.
$ systemctl list-unit-files --state=enabled
UNIT FILE STATE
autovt@.service enabled
avahi-daemon.service enabled
cpupower.service enabled
crashplan.service enabled
dbus-org.freedesktop.Avahi.service enabled
dbus-org.freedesktop.thermald.service enabled
dhcpcd.service enabled
dms.service enabled
getty@.service enabled
mbpfan.service enabled
minidlna.service enabled
powertop.service enabled
sshd.service enabled
systemd-timesyncd.service enabled
thermald.service enabled
avahi-daemon.socket enabled
remote-fs.target enabled
movie_list.timer enabled
rclone.timer enabled
restic.timer enabled
20 unit files listed.
EDIT: If I
sudo systemctl stop dhcpcd.service
, then plug in ethernet, I get immediate shutdown instead of the watchdog messages.
EDIT2: Nevermind, my MBP is now crashing within seconds of booting irrespective of ethernet connection, perhaps an unrelated hardware failure.
EDIT3: Figured out the other crash, but the ethernet-related lockup possibly pertinent to this thread persists. It may also be a hardware issue though, since I just booted from USB and tested, and even from USB I get the same lockup as soon as I plug in the ethernet cable:
watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [ksoftirqd/1:20]
If I enable NetworkManager to start automatically at boot (cable connected), I start getting these soft lockup messages and consequently cannot even log in at the console. However, if I start NetworkManager manually after logging in, there is no problem. I can even disconnect and reconnect the cable just fine from thereon.
]]>Never mind -- I missed this is an ongoing thread
]]>[412904.895658] NMI watchdog: Watchdog detected hard LOCKUP on cpu 16dModules linked in:c vhost_netc vhostc macvtapc macvlanc tunc devlinkc w83795c w83627ehfc hwmon_vidc jc42c mgag200c ttmc intel_powerclampc drm_kms_helperc coretempc drmc kvm_intelc kvmc syscopyareac sysfillrectc sysimgbltc ipmi_ssifc irqbypassc fb_sys_fopsc input_ledsc led_classc joydevc igbc mousedevc intel_cstatec bridgec psmousec ptpc iTCO_wdtc pps_corec evdevc pcspkrc mac_hidc iTCO_vendor_supportc i2c_algo_bitc gpio_ichc ipmi_sic fjesc stpc llcc ipmi_msghandlerc buttonc ioatdmac i7core_edacc acpi_cpufreqc edac_corec shpchpc lpc_ichc i5500_tempc i2c_i801c dcac tpm_tisc i2c_smbusc tpm_tis_corec tpmc sch_fq_codelc ip_tablesc x_tablesc ext4c crc16c jbd2c fscryptoc mbcachec sd_modc hid_genericc usbhidc hidc uhci_hcdc ehci_pcic ata_genericc serio_rawc pata_acpic mpt3sasc raid_classc atkbdc ata_piixc ehci_hcdc libps2c libatac scsi_transport_
[412904.908938] CPU: 16 PID: 0 Comm: swapper/16 Tainted: G L 4.9.78-1-lts #1
[412904.908939] Hardware name: Supermicro X8DTH-i/6/iF/6F/X8DTH, BIOS 2.0a 09/29/2010
[412904.908939] task: ffff880331b80d00 task.stack: ffffc90003208000
[412904.908940] RIP: 0010:[<ffffffff81604bbc>] c [<ffffffff81604bbc>] intel_idle+0x9c/0x110
[412904.908941] RSP: 0018:ffffc9000320be48 EFLAGS: 00000046
[412904.908941] RAX: 0000000000000020 RBX: 0000000000000008 RCX: 0000000000000001
[412904.908942] RDX: 0000000000000000 RSI: ffffffff81aa4da0 RDI: 0000000000000010
[412904.908943] RBP: ffffc9000320be68 R08: cccccccccccccccd R09: 000000000000afa3
[412904.908943] R10: 0000000000000018 R11: 000000000000aa1c R12: 0000000000000003
[412904.908944] R13: 0000000000000004 R14: 0000000000000020 R15: 0000000000000000
[412904.908944] FS: 0000000000000000(0000) GS:ffff880333c80000(0000) knlGS:0000000000000000
[412904.908945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[412904.908946] CR2: 00007fd5e0420000 CR3: 0000000001a08000 CR4: 0000000000022670
[412904.908946] Stack:
[412904.908947] ffffffff81aa4da0c ffff880333c9fc00c 0000000000000004c ffffffff81aa4f38c
[412904.908948] ffffc9000320beb8c ffffffff814b8934c ffff880333c9fc00c 7735940000038345c
[412904.908948] 000177868fa79e2dc 0000000000000010c ffffffff81b08850c ffffffff8192b0d6c
[412904.908949] Call Trace:
[412904.908949] [<ffffffff814b8934>] cpuidle_enter_state+0x74/0x2d0
[412904.908950] [<ffffffff814b8bc7>] cpuidle_enter+0x17/0x20
[412904.908950] [<ffffffff810c2bd3>] call_cpuidle+0x23/0x40
[412904.908951] [<ffffffff810c2e4f>] cpu_startup_entry+0x15f/0x240
[412904.908952] [<ffffffff8105032f>] start_secondary+0x16f/0x1b0
[412904.908953] Code: c00 c00 c0f cae c38 c0f cae cf0 c31 cd2 c65 c48 c8b c04 c25 c00 cfb c00 c00 c48 c89 cd1 c0f c01 cc8 c48 c8b c00 ca8 c08 c75 c0b cb9 c01 c00 c00 c00 c4c c89 cf0 c0f c01 cc9 c<65> c48 c8b c04 c25 c00 cfb c00 c00 cf0 c80 c60 c02 cdf c0f cae cf0 c48 c8b c00 ca8 c
systemctl list-unit-files --state=enabled
UNIT FILE STATE
autovt@.service enabled
dbus-org.freedesktop.network1.service enabled
getty@.service enabled
libvirt-guests.service enabled
libvirtd.service enabled
lm_sensors.service enabled
systemd-networkd-wait-online.service enabled
systemd-networkd.service enabled
sshd.socket enabled
systemd-networkd.socket enabled
virtlockd.socket enabled
virtlogd.socket enabled
remote-fs.target enabled
In the vanilla kernel, in case of the dhcpcd service being disabled, the thing that seems to determine, whether the lock up occurs is the shell, from where I start dhcpcd. If it's from inside X via a terminal emulator, there is no problem, but if it's from the login shell, then it'll lock up.
On the Arch iso I didn't run into any problems, though I belief there is a dhcpcd service running as well.
As for the backtrace: Yes, I was expecting those as well, but I haven't been able to get my system to print one. It always only shows the soft and hard lockup messages directly on screen, and for some reason, nothing is being written to the journal.
]]>