Maybe but if yes, then the details will need to be fed into the kernel group and they would expect some data from logs that indicates that it is a kernel driver issue.
Is there nothing in the boot log related to when the drivers are assigned to the nics or any other error messages during the boot up phase?
Where can I find this log?
/var/log/bootlog
Here are the 2 machine logs
ADL-bootlog.1.gz (15,2 Ko)
Mairie-bootlog.zip (15,3 Ko)
no change at all.
Try version 6.11 as I heard off an on for the past 6 months there has been some Kernel hardware issues, but I think what he ended up doing is getting rid of devFS after 6.10. 6.12 is supposed to be released next month to be incorporated into Mint and others.
IPFire runs on the LTS kernel branch. Currently that is 6.6 and it has an EOL for updates of Dec 2026. Using a non LTS branch means that EOL would be sooner forcing a 6.x change more often as opposed to a 6.6.x change.
The new LTS versions usually come out around the end of the year, although it is not a fixed in stone date. Likely 6.12 will be the next LTS release although it could also be 6.13
When the next LTS branch is released we will evaluate and update to it.
I extracted the log entries and post for convenience to look at.
Here are the relevant log entries for Intel:
grep e1000e Mairie-bootlog
[ 7.100668] e1000e: Intel(R) PRO/1000 Network Driver
[ 7.100670] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 7.100699] e1000e 0000:02:00.0: enabling device (0000 â 0002)
[ 7.100895] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 7.141349] e1000e 0000:02:00.0 0000:02:00.0 (uninitialized): registered PHC clock
[ 7.186456] e1000e 0000:02:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 68:05:ca:e8:49:18
[ 7.186459] e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000 Network Connection
[ 7.186478] e1000e 0000:02:00.0 eth1: MAC: 3, PHY: 8, PBA No: E46981-008
[ 7.332044] e1000e 0000:02:00.0 red0: renamed from eth1
grep e1000e ADL-bootlog.1
[ 4.817637] e1000e: Intel(R) PRO/1000 Network Driver
[ 4.817649] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 4.818192] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 5.081856] e1000e 0000:00:19.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:21:9b:39:a3:96
[ 5.081865] e1000e 0000:00:19.0 eth1: Intel(R) PRO/1000 Network Connection
[ 5.081884] e1000e 0000:00:19.0 eth1: MAC: 7, PHY: 6, PBA No: 1041FF-0FF
[ 5.218598] e1000e 0000:00:19.0 green0: renamed from eth1
And for Realtek:
grep r8169 Mairie-bootlog
[ 6.976848] r8169 0000:01:00.0: enabling device (0000 â 0003)
[ 6.976995] r8169 0000:01:00.0: canât disable ASPM; OS doesnât have ASPM control
[ 6.985438] r8169 0000:01:00.0 eth0: RTL8168h/8111h, 18:c0:4d:8b:5d:5f, XID 541, IRQ 127
[ 6.985442] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 7.318576] r8169 0000:01:00.0 green0: renamed from eth0
grep r8169 ADL-bootlog.1
[ 4.878736] r8169 0000:03:02.0 eth0: RTL8169sb/8110sb, 70:62:b8:ae:ae:68, XID 100, IRQ 18
[ 4.878747] r8169 0000:03:02.0 eth0: jumbo features [frames: 7146 bytes, tx checksumming: ok]
[ 5.205057] r8169 0000:03:02.0 red0: renamed from eth0
Hi Didier,
I did some more searching and both the e1000e and r8169 drivers report âLink is Upâ and âLink is Downâ information - some samples from searches below.
[ 18.825504] e1000e 0000:00:19.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ +3.499100] r8169 0000:05:00.0 lan: Link is Up - 100Mbps/Full - flow control off
[Aug 3 23:55] r8169 0000:05:00.0 lan: Link is Down
Since these messages are not in your âbootlogâ, can you search â/var/log/messagesâ for when the links go up?
grep e1000e /var/log/messages
and
grep r8169 /var/log/messages
And post those messages.
You may need to go to an older log to find the messages from after the boot if your log has been rotated.
And also, just to say thanks for providing information. I know Iâve been asking for a lot of it.
Thanks,
Stephen
ok, LTS isnât a bad thing to stick to, just that next time you guys should look if others are having issues. I know afew freinds that were having issues with micocode patches on distros they help maintain and its not really specific hardware, its an after effect of devFS going out of sync with udev and cause hardware to be connected but down. On usb dives they just donât mount until you reboot. But network cards, they will go into standby and the speed drops to 100. Some find that changing the speed or even waking them up temporarily fixes this. But since this OS is a router/gateway server, I would definitely tell people to hold off. Because the ipfire install doesnât have a significant attack surface to be hacked in the first place. So upgrading isnât as significant compared to a web hosting server or even home computers.
Hi,
This is for mairie
[root@firewall ~]# grep e1000e /var/log/messages
Sep 29 22:00:23 firewall kernel: e1000e 0000:02:00.0 red0: NIC Link is Down
Sep 29 22:01:29 firewall kernel: e1000e 0000:02:00.0 red0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Oct 1 13:41:13 firewall kernel: e1000e 0000:02:00.0 red0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[root@firewall ~]# grep r8169 /var/log/messages
Sep 29 22:01:24 firewall kernel: Generic FE-GE Realtek PHY r8169-0-100:00: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC)
Sep 29 22:01:24 firewall kernel: r8169 0000:01:00.0 green0: Link is Down
Sep 29 22:01:27 firewall kernel: r8169 0000:01:00.0 green0: Link is Up - 1Gbps/Full - flow control rx
Oct 1 13:41:22 firewall kernel: r8169 0000:01:00.0 green0: Link is Up - 1Gbps/Full - flow control off
Oct 1 13:41:22 firewall kernel: r8169 0000:01:00.0 green0: Link is Down
Oct 1 13:41:25 firewall kernel: r8169 0000:01:00.0 green0: Link is Up - 1Gbps/Full - flow control off
Disconnection on Sunday at 10:00 p.m. is the programmed restart of the machine.
then for ADL
[root@firewall ~]# grep e1000e /var/log/messages
Sep 29 15:41:23 firewall kernel: e1000e 0000:00:19.0 green0: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 9776 ms
Sep 29 15:41:23 firewall kernel: e1000e 0000:00:19.0 green0: Reset adapter unexpectedly
Sep 29 15:41:26 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 29 15:41:27 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 29 15:41:29 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 29 15:41:30 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 29 15:41:33 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 29 15:41:34 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 29 15:41:36 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 29 15:41:47 firewall kernel: e1000e 0000:00:19.0 green0: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 5912 ms
Sep 29 15:41:47 firewall kernel: e1000e 0000:00:19.0 green0: Reset adapter unexpectedly
Sep 29 15:41:50 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 29 15:41:51 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 29 15:41:53 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 29 15:41:54 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 29 15:41:57 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 29 15:41:58 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 29 15:42:00 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 01:47:27 firewall kernel: e1000e 0000:00:19.0 green0: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 7846 ms
Sep 30 01:47:27 firewall kernel: e1000e 0000:00:19.0 green0: Reset adapter unexpectedly
Sep 30 01:47:29 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 01:47:30 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 01:47:33 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 01:47:34 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 01:47:36 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 01:47:38 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 01:47:40 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 05:47:29 firewall kernel: e1000e 0000:00:19.0 green0: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 9524 ms
Sep 30 05:47:29 firewall kernel: e1000e 0000:00:19.0 green0: Reset adapter unexpectedly
Sep 30 05:47:31 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 05:47:33 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 05:47:35 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 05:47:36 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 05:47:39 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 05:47:40 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 05:47:42 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 05:47:52 firewall kernel: e1000e 0000:00:19.0 green0: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 6861 ms
Sep 30 05:47:52 firewall kernel: e1000e 0000:00:19.0 green0: Reset adapter unexpectedly
Sep 30 05:47:55 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 05:47:56 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 05:47:58 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 05:47:59 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 05:48:02 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 30 05:48:03 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Down
Sep 30 05:48:05 firewall kernel: e1000e 0000:00:19.0 green0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[root@firewall ~]# grep r8169 /var/log/messages.1
Sep 23 13:36:37 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:37:40 firewall kernel: RTL8211C Gigabit Ethernet r8169-0-310:00: attached PHY driver (mii_bus:phy_addr=r8169-0-310:00, irq=MAC)
Sep 23 13:37:40 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:38:06 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:38:07 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:38:43 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:38:44 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:41:04 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:41:05 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:41:16 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:41:17 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:41:27 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:41:28 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:41:47 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:41:48 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:42:27 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:42:57 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:44:05 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:44:08 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:44:28 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:44:29 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:44:31 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:44:32 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:44:59 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:45:00 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:45:08 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:45:11 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:45:13 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:45:14 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:45:19 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:45:20 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:45:41 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:45:41 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:50:56 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:51:15 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:51:43 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:51:45 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:51:47 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:51:48 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:52:02 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 23 13:52:02 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 23 13:52:29 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 24 14:19:52 firewall kernel: RTL8211C Gigabit Ethernet r8169-0-310:00: attached PHY driver (mii_bus:phy_addr=r8169-0-310:00, irq=MAC)
Sep 24 14:19:52 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 24 14:19:54 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 26 10:37:54 firewall kernel: RTL8211C Gigabit Ethernet r8169-0-310:00: attached PHY driver (mii_bus:phy_addr=r8169-0-310:00, irq=MAC)
Sep 26 10:37:54 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 26 10:37:56 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 26 14:42:07 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 26 14:43:33 firewall kernel: RTL8211C Gigabit Ethernet r8169-0-310:00: attached PHY driver (mii_bus:phy_addr=r8169-0-310:00, irq=MAC)
Sep 26 14:43:33 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 26 14:43:36 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 26 14:58:55 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 26 14:59:56 firewall kernel: RTL8211C Gigabit Ethernet r8169-0-310:00: attached PHY driver (mii_bus:phy_addr=r8169-0-310:00, irq=MAC)
Sep 26 14:59:56 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 26 14:59:59 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 26 20:42:44 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 27 07:34:33 firewall kernel: RTL8211C Gigabit Ethernet r8169-0-310:00: attached PHY driver (mii_bus:phy_addr=r8169-0-310:00, irq=MAC)
Sep 27 07:34:34 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 27 07:34:36 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 27 14:42:50 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 27 14:44:09 firewall kernel: RTL8211C Gigabit Ethernet r8169-0-310:00: attached PHY driver (mii_bus:phy_addr=r8169-0-310:00, irq=MAC)
Sep 27 14:44:09 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 27 14:44:12 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 29 00:00:31 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 29 00:01:34 firewall kernel: RTL8211C Gigabit Ethernet r8169-0-310:00: attached PHY driver (mii_bus:phy_addr=r8169-0-310:00, irq=MAC)
Sep 29 00:01:34 firewall kernel: r8169 0000:03:02.0 red0: Link is Down
Sep 29 00:01:36 firewall kernel: r8169 0000:03:02.0 red0: Link is Up - 1Gbps/Full - flow control rx/tx
The machine also restarts on Sundays at 00:00
I donât mind giving information, Iâm already the one who made the request and the least I can do is respond to requests if I can help in any way I can. 
thank you
Hi Didier,
Just to confirm a couple of thingsâŚ
On mairie, the messages around Sep 29 22:00:00 are expected and the messages around Oct 1 13:41:00 are not expected? And on mairie, you donât see the NICs bouncing up and down several times a day like on ADL?
And for ADL, the messages around Sep 29 00:00:00 are expected? I noticed on the ADL logs most of the error messages happen batches for a couple of minutes and then no errors for a time hours or days.
I think you said that these are separate sites/ISPâs. Is mairie a smaller site than ADL in terms of network workload since mairie NICs donât bounce as much?
For both firewalls, both NICs going down at the same time is pretty suspect to me and makes me think of hardware or something outside of IPFire.
How are the firewalls connected to the LAN and the ISP? Are the green0 and red0 connections going through the same switch and maybe overloading a switch backbone somewhere? Do you see any error messages in your switch logs?
Is there anything else external that you can think of that would cause both NICs to go down.
Regards,
Stephen
On mairie, the messages around Sep 29 22:00:00 are expected
Yes, the firewall reboots every Sunday at 10.00 p.m.
and the messages around Oct 1 13:41:00 are not expected?
I do âethtool -s red0 speed 1000 duplex full autoneg offâ as suggested by Dave Mikeska
I think you said that these are separate sites/ISPâs. Is mairie a smaller site than ADL in terms of network workload since mairie NICs donât bounce as much?
Yes, mairie is a Town Hall and ADL is a consultancy firm.
For both firewalls, both NICs going down at the same time is pretty suspect to me and makes me think of hardware or something outside of IPFire.
There are about 20km between the 2 sites and they donât use the same ISP
How are the firewalls connected to the LAN and the ISP? Are the green0 and red0 connections going through the same switch and maybe overloading a switch backbone somewhere? Do you see any error messages in your switch logs?
The firewalls are connected to the ISPs via fiber modem routers on the red side and to standard network switches on the green side Unfortunately I donât have any logs for the switches.
This evening Iâm going to reboot all the equipments (modem, firewall, switches, etc.) and weâll see if anything inside is causing a problem. I canât before because at the Town Hall the phone goes through the firewall and at ADL I have to tell someone on site how to do it. 
thank you
So as far as mairie is concerned, itâs all sorted, everything works. Why I donât know, but itâs working.
However, for ADL on the green card when I enter the order
ethtool -s red0 speed 1000 duplex full autoneg off
the connection falls, with
ethtool -s red0 speed 100 duplex full autoneg off
It works, but at 100mbps of course
The difference between the mairie and ADL cards is the pci slots at mairie pcie at ADL pci. I think Iâll just change ADL card, itâll be easier.
Hi Didier,
Iâm not sure what you mean by âon the green cardâ when youâre entering âethtoolâ commands for red0.
But, Iâm glad that youâve got things sorted with restarting everything.
By chance did âspeedtest-cliâ start working again for you as well?
Regards,
Stephen
The joys of copying and pasting
I had a good try
ethtool -s green0 speed 1000 duplex full autoneg off
unfortunately speedtest-cli is still not working
I have checked with an IPFire eco (Atom D525 1,8 Ghz and 4 Intel 82574L e1000e nics)
Iperf2 bidirectional through the IPFire (client in green server in red):
core187:
[ ID] Interval Transfer Bandwidth
[ 2] 0.0000-60.0878 sec 2.24 GBytes 320 Mbits/sec
[ 1] 0.0000-60.0904 sec 4.44 GBytes 634 Mbits/sec
core188:
[ ID] Interval Transfer Bandwidth
[ 2] 0.0000-60.0623 sec 6.30 GBytes 901 Mbits/sec
[ 1] 0.0000-60.0807 sec 6.44 GBytes 921 Mbits/sec
The reason for the much better result is the removal of cake which need to much cpu power.
But the card has no link problems here. Have you checked the status of aspm powersave. (this is often the reason for problems)
Same on IPFire-prime (Atom 1.6Ghz 2x Realtek rtl8168 nics)
core187:
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-60.0938 sec 3.84 GBytes 549 Mbits/sec
[ 2] 0.0000-60.0961 sec 2.66 GBytes 381 Mbits/sec
core188:
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-60.1058 sec 3.66 GBytes 522 Mbits/sec
[ 2] 0.0000-60.1048 sec 3.47 GBytes 497 Mbits/sec
Here the passive Realtek nics in conjunction with the slow Atom SoC PCIe bandwich limit the speed 500 Mbit/s bidirektional and around 800Mbit single direction.
But there is still no 100Mbit limitation.
I wonder what it reports.
For people that are having issues, run:
lspci -vv | grep ASPM
on a root ssh shell.
all of the 'LnkCtl" entries reported after the apm bus/port device should read something like this:
LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
passing pcie_aspm=off by either backing up and modifying the policy file like:
cp /sys/module/pcie_aspm/parameters/policy /sys/module/pcie_aspm/parameters/policy.old
Then edit the policy file and delete the first line and replace it with:
pcie_aspm=off
The other place you can do this is in grub (or what ever boot manager is used) on the kernel line.
But either way, you have to disable secure boot in both cases to change PCIe speeds or other parameters.
Hello, a priori aspm is already disabled
[root@firewall ~]# lspci -vv | grep ASPM
LnkCap: Port #2, Speed 2.5GT/s, Width x16, ASPM L0s, Exit Latency L0s <256ns
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <256ns
ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
thanks