You are not logged in.
While the attempt to provide further troubleshooting information for this thread is appreciated, note that we only support Arch here.
Offline
Indeed. Closed, Dust binned.
You will need to ask on the Manjaro boards about how they have configured things.
Never mind -- I missed this is an ongoing thread
Last edited by ewaller (2018-02-07 20:58:02)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
I have identical hardware MacBook Pro (13-inch, Mid 2009) aka model MacBookPro5,5 and suffer the same symptoms. I'm still in the process of setting up a new system and therefore it's pretty barebones at this point - just nvidia-340xx and broadcom-wl-dkms installed. Also, I use NetworkManager as the network manager.
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.
Last edited by verbbis (2018-05-06 09:54:40)
Offline
Glad to find this thread -- same situation.
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]
Last edited by n8henrie (2018-07-25 13:44:24)
Offline
Hello, I had the same issue and, after a long search, I ended up with the following solution:
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`
Offline
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
Last edited by seth (2023-01-30 07:29:16)
Offline
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?
Offline
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?
Last edited by seth (2023-01-30 14:50:24)
Offline
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.
Offline
And that is why I linked you how to do that w/o having to manually re-load the module w/ the parameters…
Offline