Re: 7.3.1-rc2 does not recognize network interface

> On 06/07/2024 12:30 BST KP.Kirchdoerfer <[email protected]> wrote:
> 
>  
> Am Mittwoch, 3. Juli 2024, 18:30:29 CEST schrieb David Brooke:
> > Hi,
> > 
> > > On 04/06/2024 14:20 BST KP.Kirchdoerfer <[email protected]> wrote:
> > > 
> > > 
> > > Hi;
> > > 
> > > Am Dienstag, 4. Juni 2024, 08:59:39 CEST schrieb Dirk Gfrörer:
> > > > Hello,
> > > > 
> > > > tried to update one of our apu4 PC Engines boxes to 7.3.1-rc2 using the
> > > > Bering-uClibc_7.3.1-rc2_x86_64_syslinux_serial115200.tar.gz image.
> > > > 
> > > > This failed since the network interfaces were no longer recognized.
> > > > Reverting back to rc1 made the network interfaces appear again. Have not
> > > > yet understood on what goes wrong, but maybe someone else is also having
> > > > this issue.
> > > 
> > > It does work here with APU2 and igb network driver (automatically
> > > detected).
> > > 
> > > If you're issue persists I'll look again next week.
> > > 
> > > kp
> > 
> > I am seeing the same issue today with 7.3.1_x86_64 on an APU2.
> > 
> > Seems to be intermittent / inconsistent though:
> > * Reboot and it says can't find eth0/1/2
> > * Reboot again and it *can* find those but *not* e.g. ppp0
> > * Reboot again and it's back to not finding eth0/1/2
> > 
> > I wonder if it's right on the limit of a timeout for module loading???
> > (Is it the 3-second usb_wait, set in syslinux/syslinux.cfg, for this?)
> > 
> 
> Odd; I'm running it successfully on an APU4 and also tested the image with 
> qemu.

Odd indeed! :-) When it works, everything is fine - and I've been running
7.3.1 successfully for a few days now (without rebooting). But then I do a
reboot and it fails to find the network interfaces. When I reboot a second
time - *with the **exact** same configuration* - it works fine again.

(Changing usb_wait didn't help; I've had that set to 4 when it failed, and 
2 when it works.)

> What does dmesg show when you are booting? (see below how it looks here)

I've now got the dmesg output captured for a 'good' and a 'bad' boot.
These are identical until after the 'u32 classifier' lines - which I
believe are the result of loading cls_u32, specified near the end of
/etc/modules. Is that a clue? Looking at repo/init.d/root.loadmodules
there's an attempt to unmount the squashfs as soon as /etc/modules
has been processed.

dmesg output from a 'good' boot:

...
[   17.801213] 8021q: 802.1Q VLAN Support v1.8
[   17.866368] u32 classifier
[   17.866384]     Performance counters on
[   17.866387]     input device check on
[   17.866390]     Actions configured
[   17.941866] igb: loading out-of-tree module taints kernel.
[   17.956580] igb: Intel(R) Gigabit Ethernet Linux Driver - version 5.15.6
[   17.956588] igb: Copyright(c) 2007 - 2023 Intel Corporation.
...  (Many more igb lines, omitted)
[   18.100447] igb 0000:03:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)
[   19.117966] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[   19.118339] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address
[   19.118510] sp5100-tco sp5100-tco: initialized. heartbeat=60 sec (nowayout=0)
[   19.139035] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0
[   19.139055] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus port selection
[   19.139329] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20
[   19.263714] EDAC amd64: MCT channel count: 1
[   19.264013] EDAC MC0: Giving out device to module amd64_edac controller F16h_M30h: DEV 0000:00:18.3 (INTERRUPT)
[   19.264054] EDAC amd64: F16h_M30h detected (node 0).
[   19.264059] EDAC MC: DCT0 chip selects:
[   19.264063] EDAC amd64: MC: 0:  4096MB 1:     0MB
[   19.264070] EDAC amd64: MC: 2:     0MB 3:     0MB
[   19.264076] EDAC amd64: MC: 4:     0MB 5:     0MB
[   19.264081] EDAC amd64: MC: 6:     0MB 7:     0MB
[   19.264086] EDAC MC: DCT1 chip selects:
[   19.264089] EDAC amd64: MC: 0:     0MB 1:     0MB
[   19.264094] EDAC amd64: MC: 2:     0MB 3:     0MB
[   19.264098] EDAC amd64: MC: 4:     0MB 5:     0MB
[   19.264103] EDAC amd64: MC: 6:     0MB 7:     0MB
[   19.264107] EDAC amd64: using x4 syndromes.
[   19.264144] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED)                          
[   19.264183] AMD64 EDAC driver v3.5.0
[   19.630869] acpi_cpufreq: overriding BIOS provided _PSD data
[   23.910792] EXT4-fs (sda3): unmounting filesystem.
[   23.919071] Adding 104444k swap on /dev/zram0.  Priority:100 extents:1 across:104444k SS


dmesg output from a 'bad' boot:

...
[   17.803206] 8021q: 802.1Q VLAN Support v1.8
[   17.868978] u32 classifier
[   17.869023]     Performance counters on
[   17.869026]     input device check on
[   17.869028]     Actions configured
[   17.899170] EXT4-fs (sda3): unmounting filesystem.
[   17.908144] Adding 104444k swap on /dev/zram0.  Priority:100 extents:1 across:104444k SS

So it's not only the igb modules that are missing; some others fail to load too.
It's as if the module auto-loading just stops too soon.

The text on the serial console is the same in both cases:

LOADMODULES: identified device /dev/sda3
LOADMODULES: Mounting squashes with modules...
LOADMODULES: found modules.sqfs on /mnt1
[   16.399684] /dev/loop0: Can't open blockdev
LOADMODULES: loading modules from /etc/modules
LOADMODULES: Unmounting /mnt1
LOADMODULES: Removing /mnt1

(I always get that /dev/loop0 'blockdev' message, which seems to just be a
warning.)

> Maybe it's worth testing the kernel module for igb, we are suing the out-of-
> tree from Intel and/or a kernel version without UEFI support (which has been 
> added in 7.3.1-rc2.

I don't think that will help, since the issue isn't specific to the igb module.

Having reviewed the root.loadmodules script, my hunch is that the unmount
of the squashfs is happening before the auto-loading has finished. Maybe the
loop with a 'sleep 3' gets (un)lucky sometimes? I note there's a VERBOSE2
variable which will create more output; I'll give that a try when I get chance.

> If you can't build a kernel and modules sqfs any more because of a missing 
> build environment, I'll provide both.

I do have a build environment for 7.3.1 - I was unable to get FreeRadius
working for my 802.1X WiFi Authentication use-case so I've been doing some
updates to that, which I will share once I'm happy they are working OK.

dMb

> kp
>


------------------------------------------------------------------------
leaf-user mailing list: [email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/