[SOLVED] eth0 missing after upgrading sarpi-firmware/hack of 17 feb 2021

Pigi_102 · 03-14-2021, 07:48 AM

Hello all,
trying to fix a problem with wifi not working on my RPi4, as access point, on 21 February this year I've upgraded the two packages:

Code:

sarpi4-hacks-4.0-armv7l-1_slackcurrent_17Feb21_sp1
sarpi4-boot-firmware-armv7l-1_slackcurrent_17Feb21_sp1

I haven't rebooted as it was only firmware so modprobe -r and modprobe was all I needed to get stuff working again.

Today I lost power on rpi for the first time since, but after the power comes back and rpi rebooted, I was not able to reach her from remote.
No dhcp nor other services.
I've then connected a monitor and keyboard and started to debug.
It was an easy one.... eth0 was missing

Can you help shine some light on this ?
What should I check ?

Thanks in advance

Pigi

hazel · 03-14-2021, 08:03 AM

You could try grepping dmesg for the card name and see if the kernel mentions trying to load a particular firmware file and perhaps not finding it.

teckk · 03-14-2021, 08:28 AM

eth0 has not changed to another name? (Predictable device naming)

Code:

ip a

What is the device, and is there a kernel module loaded for it?

Code:

lspci -k

Lets see, you are using slack so no systemd. How about slacks log files? Any thing in them?

Also grep dmesg like Hazel said.

Pigi_102 · 03-14-2021, 08:38 AM

That's the really strange part. I cannot find any particular error in dmesg:
The only error I see is:

Code:

dmesg | grep -i erro

[    6.231102] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2

No other occurrences.

Pigi_102 · 03-14-2021, 08:44 AM

Quote:

Originally Posted by teckk

eth0 has not changed to another name? (Predictable device naming)

Code:

ip a

What is the device, and is there a kernel module loaded for it?

Code:

lspci -k

Lets see, you are using slack so no systemd. How about slacks log files? Any thing in them?

Also grep dmesg like Hazel said.

No name change:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
4: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 100
5: tap1: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 100
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
9: veth7156b0c@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
11: veth4bc09ec@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
13: vetheac42c8@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
15: veth2648337@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
16: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000

eth1 and eth2 are two usb dongle. One is for connecting to internet ( as it was before ) the other is the one I've added to temporary fix the problem.
tap0 and tap1 are two openvpn tap interfaces.
veth* are docker interfaces.
bt0 is the bridge for the docker.

Code:

root@casa:~# lspci -k
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries Device 2711 (rev 10)
        Kernel driver in use: pcieport
01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01)
        Subsystem: VIA Technologies, Inc. VL805 USB 3.0 Host Controller
        Kernel driver in use: xhci_hcd

hazel · 03-14-2021, 09:26 AM

Quote:

Originally Posted by Pigi_102

That's the really strange part. I cannot find any particular error in dmesg:
The only error I see is:

Code:

dmesg | grep -i erro

[    6.231102] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2

No other occurrences.

Exactly! I thought it was probably something like that. You do a firmware upgrade and suddenly the kernel driver for your card can't find a file it's looking for. Evidently the card doesn't function without that file being loaded.

Check the files in /lib/firmware/brcm. And check for the name of the missing file(s) in the /var/log/packages file for that update, and in the previous version (which should be in /var/log/removed_packages). It may be that you will need to extract the missing file from the older package and copy it into place by hand.

Pigi_102 · 03-14-2021, 11:09 AM

hazel, unfortunally it does not seem to be the right one, as :

Code:

Mar 14 13:05:13 casa kernel: [   10.015264] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2
Mar 14 13:05:13 casa kernel: [   10.289651] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
Mar 14 13:05:13 casa kernel: [   10.307173] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2

so the kernel does not load the firmware with that name, but it resolve loading with brcm/brcmfmac43455-sdio ( without the "4-model-b" )

and btw there is no such file in the removed packages for that one.

Still no joy

hazel · 03-14-2021, 11:29 AM

4-model-b.txt looks like a text file. I wonder what it contains. Maybe some kind of catalogue. I'd certainly have a look if it was me if only out of curiosity.

The problem has to be somewhere in that set of files. Is there any difference at all between the old and the new packages regarding the contents of that directory?

Also I would look in the messages file for your last successful boot to see if there are any differences from this one regarding the loading of this firmware.

Pigi_102 · 03-14-2021, 12:48 PM

Last boot is out of rotation logs

It is indeed on first days of january, and the last messages.4 is from february

In the files there is quite a bunch of diffs, but it is because the previous installation was with sarpi3.

I wonder if it would not be better to revert to sarpi3 sa the kernel is from this.

Unfortunally I have installed current and not upgraded since quite a bit, so it would be a pita to upgrade to latest current.

TheTKS · 03-14-2021, 03:15 PM

Quote:

Originally Posted by Pigi_102

Hello all,
trying to fix a problem with wifi not working on my RPi4, as access point, on 21 February this year I've upgraded the two packages:

Code:

sarpi4-hacks-4.0-armv7l-1_slackcurrent_17Feb21_sp1
sarpi4-boot-firmware-armv7l-1_slackcurrent_17Feb21_sp1

I haven't rebooted as it was only firmware so modprobe -r and modprobe was all I needed to get stuff working again.

Today I lost power on rpi for the first time since, but after the power comes back and rpi rebooted, I was not able to reach her from remote.
No dhcp nor other services.
I've then connected a monitor and keyboard and started to debug.
It was an easy one.... eth0 was missing

Can you help shine some light on this ?
What should I check ?

Thanks in advance

Pigi

Quote:

Originally Posted by Pigi_102

Last boot is out of rotation logs

It is indeed on first days of january, and the last messages.4 is from february

In the files there is quite a bunch of diffs, but it is because the previous installation was with sarpi3.

I wonder if it would not be better to revert to sarpi3 sa the kernel is from this.

Unfortunally I have installed current and not upgraded since quite a bit, so it would be a pita to upgrade to latest current.

Pigi_102,

I’m puzzled about your setup, so I’d ask you to clarify a couple of things.

- You want help with a wifi problem, but then mention eth0 is missing and you seem to have found wlan0. So do you still have a problem with both wifi and eth0? If so, show your list of files in /lib/firmware/brcm. Some of us had problems with no wifi (didn’t even see wlan0) on RPi4 awhile back. My problem was fixed by deleting all files in that directory (after backing them up elsewhere) and reinstalling sarpi4-hacks. You may want to not use such a reckless, brute force solution. There are threads here where that “fix” was described. With that brute force fix, you may not get working bluetooth; if you want that, another set of threads discussed that issue.

- Do I understand correctly that you are using a Raspberry Pi 4 but had sarpi3 installed? If so, sarpi3 packages are for the RPi3, sarpi4 for the RPi4. Someone else who knows sarpi would have to comment, because I don’t know it well enough to even guess what could go wrong with that arrangement, or whether you can even get from that to a properly working setup with just a few changes. It sounds like you don’t want to do this, but you could always do a new SlackwareARM -current installation with sarpi4 packages.

I think Hazel is on the right track suspecting firmware in /lib/firmware/brcm, but if you’ve had sarpi3 packages installed on RPi4, it would not surprise me if you have to fix more than that.

TKS

Pigi_102 · 03-14-2021, 03:32 PM

Hello,
let me clarify a bit.
I have a raspberry pi4. Before this one I had a pi3 completely configured so after have bought the pi4 I just took out the SD card from the PI3, put inside the PI4 and started. No problem at all, a part from the wifi for almost an year.
PI3 and PI4 are based on same ( or at least similar ) hardware for a lot of components, so I don't think it should be a problem.

My problem with eth0 missing.

Eth0 has disappeared after I have installed packages ( firmware ) for pi4, all the other stuff are from my previous installation ( on pi3 ) and is running well.

I will try to reinstall pi3 packages ( which are only firmware packages ) and see if this will fix my problem ( and how it will behave with wifi problem again ).
Eth0 is more important than my wifi problem

Pigi_102 · 03-14-2021, 04:00 PM

No, I was wrong. The sapri fimware and boots were from sarpi4 while the other stuff were from my old installation.

BTW being that before the reboot the eth0 was well working and now it's not, how can I check if is not faulted ?
From lsusb can I see something ?

Pigi_102 · 03-14-2021, 05:29 PM

I did come test: I downloaded the raspbian and installed on a SD, then booted.
eth0 show up correctly, and in dmesg I get :

[ 1.132493] bcmgenet fd580000.ethernet: failed to get enet clock
[ 1.134953] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[ 1.137354] bcmgenet fd580000.ethernet: failed to get enet-wol clock
[ 1.139723] bcmgenet fd580000.ethernet: failed to get enet-eee clock
[ 1.142059] bcmgenet: Skipping UMAC reset
[ 1.162607] libphy: bcmgenet MII bus: probed
[ 22.037175] bcmgenet: Skipping UMAC reset
[ 22.039224] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[ 22.039491] bcmgenet fd580000.ethernet eth0: Link is Down

so ethernet is fine. ( Link was down by purpose ).

In my config.gz the driver is enabled :
root@casa:~# gzip -dc /proc/config.gz | grep -i bcmgenet
CONFIG_BCMGENET=y

I have also take note of eth0 mac address, to check if some of the docker interfaces were renamed from my ethernet but is not present in the previous list.

I can't really understand what's going on.

Any idea ?

Thanks in advance

Pigi

mralk3 · 03-14-2021, 05:34 PM

You don't need to install another OS to troubleshoot this. Read the following: https://www.linuxquestions.org/quest...nd-4175627137/

The outlined process will be similar in fixing any driver issue on Rpi in Slackware. Also, make sure your system time is synchronised.

Code:

ntpdate 0.pool.ntp.org

TheTKS · 03-14-2021, 05:41 PM

Quote:

Originally Posted by Pigi_102

BTW being that before the reboot the eth0 was well working and now it's not, how can I check if is not faulted ?
From lsusb can I see something ?

I have no other suggestions for you. Sorry I couldn't be of help.

You might find something useful in this thread to track down your eth0, using what we did in trying to figure out why we couldn't find wlan0.

https://www.linuxquestions.org/quest...an-4175689292/

TKS