Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
On 3/4/24 21:39, Alexander Motin wrote: AFAIK it is only a workaround. I saw it myself on number of different USB dongles and laptops, that USB starting experience some problems with multiple NIC queues and some other factors. IIRC the Realtek driver was much more stable once I limited it to one queue and some other hacks. IIRC if_cdce just has only one queue and other limitations, that not only makes it more stable, but also much slower. It would be good to understand what's wrong is there exactly, since IMHO it is a big problem now. Unfortunately HPS was unable to reproduce it on his laptop (that makes me wonder if is is specific to chipset(s) or thunderbolt?), so it ended nowhere so far. I have a Lenovo USB 3 dongle, so no thunderbolt. I also use USB3 dongles. But in my laptops the USB 3 ports are provided by Intel Thunderbolt controller, while in HPS' they were plain from USB3 controller. Though it may be just a coincidence. I don't think (how do I know?) I have thunderbolt in this Lenovo AMD Ryzen laptop. USB ID 0x17ef/0x7205 rgephy1: PHY 0 on miibus1 I tried using the cdce driver, it gives me < 100Mb/s, while the ure driver gets > 500Mb/s Right, I saw about the same. Just to try something else, I got another USB dongle, I does the exact same thing: ugen1.10: at usbus1 axge0 on uhub6 axge0: on usbus1 miibus1: on axge0 rgephy1: PHY 3 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow ue0: on axge0 ue0: Ethernet address: xx:xx:xx:xx:xx:xx ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: 2 link states coalesced ue0: link state changed to UP
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
Jakob Alvermark writes: > I tried using the cdce driver, it gives me < 100Mb/s, while the ure > driver gets > 500Mb/s I'll take 100 stable Mb/s over 500 unstable Mb/s any day :-) (Back in my days we had only 10 Mb/s, and everybody shared them ) But yes, I agree that it would be nice if this stuff () worked better. Poul-Henning PS: In other news: I think my main-n268442-2f4cbf459d4a kernel has managed to suspend more times with iwlwifi than I've ever seen before :-> -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
On Mar 4, 2024, at 12:39, Alexander Motin wrote: > On 04.03.2024 15:33, Jakob Alvermark wrote: >> On 3/4/24 21:13, Alexander Motin wrote: >>> On 04.03.2024 15:00, Poul-Henning Kamp wrote: >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad Thunderbolt 3 Dock MCU", but they went away after I forced it to use the if_cdce driver instead with this quirk: /* This works much better with if_cdce than if_ure */ USB_QUIRK(LENOVO, TBT3LAN, 0x, 0x, UQ_CFG_INDEX_1), >>> >>> AFAIK it is only a workaround. I saw it myself on number of different USB >>> dongles and laptops, that USB starting experience some problems with >>> multiple NIC queues and some other factors. IIRC the Realtek driver was >>> much more stable once I limited it to one queue and some other hacks. IIRC >>> if_cdce just has only one queue and other limitations, that not only makes >>> it more stable, but also much slower. It would be good to understand >>> what's wrong is there exactly, since IMHO it is a big problem now. >>> Unfortunately HPS was unable to reproduce it on his laptop (that makes me >>> wonder if is is specific to chipset(s) or thunderbolt?), so it ended >>> nowhere so far. >> I have a Lenovo USB 3 dongle, so no thunderbolt. > > I also use USB3 dongles. But in my laptops the USB 3 ports are provided by > Intel Thunderbolt controller, while in HPS' they were plain from USB3 > controller. Though it may be just a coincidence. To my knowledge, no USB4/Thunderbolt controller is present in the PRIME X670-P WIFI system that had been showing the messages and no built-in external port is an example of such. https://www.asus.com/us/motherboards-components/motherboards/prime/prime-x670-p-wifi/techspec/ lists for USB: Rear USB (Total 10 ports) 1 x USB 3.2 Gen 2x2 port (1 x USB Type-C®) 3 x USB 3.2 Gen 2 ports (3 x Type-A) 4 x USB 3.2 Gen 1 ports (4 x Type-A) 2 x USB 2.0 ports (2 x Type-A) Front USB (Total 9 ports) 1 x USB 3.2 Gen 1 connector (supports USB Type-C®) 2 x USB 3.2 Gen 1 headers support additional 4 USB 3.2 Gen 1 ports 2 x USB 2.0 headers support additional 4 USB 2.0 ports * USB Type-C® power delivery output: max. 5V/3A For Miscellaneous it lists: 1 x Thunderbolt™ (USB4®) header But, as I understand, it has to be tied to a PCie Thunderbolt card. For reference for the 7950X3D system: # pciconf -lcv | grep -B4 -A16 "subclass = USB" xhci0@pci0:11:0:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x1022 device=0x43f7 subvendor=0x1b21 subdevice=0x1142 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = '600 Series Chipset USB 3.2 Controller' class = serial bus subclass = USB cap 05[50] = MSI supports 8 messages, 64 bit cap 11[68] = MSI-X supports 8 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x2080] cap 01[78] = powerspec 3 supports D0 D3 current D0 cap 10[80] = PCI-Express 2 legacy endpoint max data 256(512) RO NS max read 512 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0018[160] = LTR 1 ahci0@pci0:12:0:0: class=0x010601 rev=0x01 hdr=0x00 vendor=0x1022 device=0x43f6 subvendor=0x1b21 subdevice=0x1062 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = '600 Series Chipset SATA Controller' class = mass storage subclass = SATA cap 05[50] = MSI supports 1 message, 64 bit enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 -- xhci1@pci0:13:0:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x1022 device=0x43f7 subvendor=0x1b21 subdevice=0x1142 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = '600 Series Chipset USB 3.2 Controller' class = serial bus subclass = USB cap 05[50] = MSI supports 8 messages, 64 bit cap 11[68] = MSI-X supports 8 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x2080] cap 01[78] = powerspec 3 supports D0 D3 current D0 cap 10[80] = PCI-Express 2 legacy endpoint max data 256(512) RO NS max read 512 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0018[160] = LTR 1 ahci1@pci0:14:0:0: class=0x010601 rev=0x01 hdr=0x00 vendor=0x1022 device=0x43f6 subvendor=0x1b21 subdevice=0x1062 vendor = 'Advanced Micro Devices, Inc. [AMD]'
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
On 04.03.2024 15:33, Jakob Alvermark wrote: On 3/4/24 21:13, Alexander Motin wrote: On 04.03.2024 15:00, Poul-Henning Kamp wrote: Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad Thunderbolt 3 Dock MCU", but they went away after I forced it to use the if_cdce driver instead with this quirk: /* This works much better with if_cdce than if_ure */ USB_QUIRK(LENOVO, TBT3LAN, 0x, 0x, UQ_CFG_INDEX_1), AFAIK it is only a workaround. I saw it myself on number of different USB dongles and laptops, that USB starting experience some problems with multiple NIC queues and some other factors. IIRC the Realtek driver was much more stable once I limited it to one queue and some other hacks. IIRC if_cdce just has only one queue and other limitations, that not only makes it more stable, but also much slower. It would be good to understand what's wrong is there exactly, since IMHO it is a big problem now. Unfortunately HPS was unable to reproduce it on his laptop (that makes me wonder if is is specific to chipset(s) or thunderbolt?), so it ended nowhere so far. I have a Lenovo USB 3 dongle, so no thunderbolt. I also use USB3 dongles. But in my laptops the USB 3 ports are provided by Intel Thunderbolt controller, while in HPS' they were plain from USB3 controller. Though it may be just a coincidence. USB ID 0x17ef/0x7205 rgephy1: PHY 0 on miibus1 I tried using the cdce driver, it gives me < 100Mb/s, while the ure driver gets > 500Mb/s Right, I saw about the same. -- Alexander Motin
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
On 3/4/24 21:13, Alexander Motin wrote: On 04.03.2024 15:00, Poul-Henning Kamp wrote: Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad Thunderbolt 3 Dock MCU", but they went away after I forced it to use the if_cdce driver instead with this quirk: /* This works much better with if_cdce than if_ure */ USB_QUIRK(LENOVO, TBT3LAN, 0x, 0x, UQ_CFG_INDEX_1), AFAIK it is only a workaround. I saw it myself on number of different USB dongles and laptops, that USB starting experience some problems with multiple NIC queues and some other factors. IIRC the Realtek driver was much more stable once I limited it to one queue and some other hacks. IIRC if_cdce just has only one queue and other limitations, that not only makes it more stable, but also much slower. It would be good to understand what's wrong is there exactly, since IMHO it is a big problem now. Unfortunately HPS was unable to reproduce it on his laptop (that makes me wonder if is is specific to chipset(s) or thunderbolt?), so it ended nowhere so far. I have a Lenovo USB 3 dongle, so no thunderbolt. USB ID 0x17ef/0x7205 rgephy1: PHY 0 on miibus1 I tried using the cdce driver, it gives me < 100Mb/s, while the ure driver gets > 500Mb/s Jakob
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
On 04.03.2024 15:00, Poul-Henning Kamp wrote: Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad Thunderbolt 3 Dock MCU", but they went away after I forced it to use the if_cdce driver instead with this quirk: /* This works much better with if_cdce than if_ure */ USB_QUIRK(LENOVO, TBT3LAN, 0x, 0x, UQ_CFG_INDEX_1), AFAIK it is only a workaround. I saw it myself on number of different USB dongles and laptops, that USB starting experience some problems with multiple NIC queues and some other factors. IIRC the Realtek driver was much more stable once I limited it to one queue and some other hacks. IIRC if_cdce just has only one queue and other limitations, that not only makes it more stable, but also much slower. It would be good to understand what's wrong is there exactly, since IMHO it is a big problem now. Unfortunately HPS was unable to reproduce it on his laptop (that makes me wonder if is is specific to chipset(s) or thunderbolt?), so it ended nowhere so far. -- Alexander Motin
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP I consistently had similar problems with my 0x17ef/0x3066 "ThinkPad Thunderbolt 3 Dock MCU", but they went away after I forced it to use the if_cdce driver instead with this quirk: /* This works much better with if_cdce than if_ure */ USB_QUIRK(LENOVO, TBT3LAN, 0x, 0x, UQ_CFG_INDEX_1), -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
On Mar 3, 2024, at 23:25, Jakob Alvermark wrote: > On 12/4/23 09:16, Mark Millard wrote: >> The following sort of thing is happening a lot: >> >> Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically >> used on occasion, sometimes for long periods . . . >> >> Example contexts for the issue have been: >> >> FreeBSD 15.0-CURRENT #126 main-n266130-d521abdff236-dirty: Tue Oct 24 >> 18:17:40 PDT 2023 >> and: >> FreeBSD 15.0-CURRENT #131 main-n266749-ed31b3f4a146-dirty: Wed Nov 29 >> 16:53:33 PST 2023 >> >> Both UFS and ZFS boot media, here part of a ed31b3f4a146 UFS example is shown >> >> Nov 29 18:26:27 7950X3D-UFS kernel: miibus0: on ure0 >> Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: > interface> PHY 0 on miibus0 >> Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: none, 10baseT, 10baseT-FDX, >> 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto >> Nov 29 18:26:27 7950X3D-UFS kernel: ue0: on ure0 >> Nov 29 18:26:27 7950X3D-UFS kernel: ue0: Ethernet address: REDACTED >> Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to DOWN >> . . . >> Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to UP >> . . . (no ue0: messages, then) . . . >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 2 link states coalesced >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:20 7950X3D-UFS dhclient[53725]: New IP Address (ue0): >> 192.168.1.157 >> Nov 30 03:23:20 7950X3D-UFS dhclient[53730]: New Subnet Mask (ue0): >> 255.255.255.0 >> Nov 30 03:23:20 7950X3D-UFS dhclient[53734]: New Broadcast Address (ue0): >> 192.168.1.255 >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 3 link states coalesced >> Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:20 7950X3D-UFS dhclient[53771]: New Routers (ue0): 192.168.1.1 >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 3 link states coalesced >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 2 link states coalesced >> Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP >> . . . (lots more) . . . >> >> Other FreeBSD system on the Ethernet are not getting such but none >> of them are currently using such a dongle. >> >> Note: The ASUS X670-P WiFi board's built in Ethernet is not >> supported. >> >> === >> Mark Millard >> marklmi at yahoo.com >> > I see the same with my Lenovo dongle: > > ugen1.12: at usbus1 > ure0 on uhub6 > ure0: on usbus1 > miibus1: on ure0 > rgephy1: PHY 0 on miibus1 > rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 I've no had the problem since somewhat after my earlier list submittal. The timing would suggest that the change was tied to my moving things around and reconnecting the ethernet cabling afterwards. === Mark Millard marklmi at yahoo.com
Re: main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
On 12/4/23 09:16, Mark Millard wrote: The following sort of thing is happening a lot: Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically used on occasion, sometimes for long periods . . . Example contexts for the issue have been: FreeBSD 15.0-CURRENT #126 main-n266130-d521abdff236-dirty: Tue Oct 24 18:17:40 PDT 2023 and: FreeBSD 15.0-CURRENT #131 main-n266749-ed31b3f4a146-dirty: Wed Nov 29 16:53:33 PST 2023 Both UFS and ZFS boot media, here part of a ed31b3f4a146 UFS example is shown Nov 29 18:26:27 7950X3D-UFS kernel: miibus0: on ure0 Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: PHY 0 on miibus0 Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto Nov 29 18:26:27 7950X3D-UFS kernel: ue0: on ure0 Nov 29 18:26:27 7950X3D-UFS kernel: ue0: Ethernet address: REDACTED Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to DOWN . . . Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to UP . . . (no ue0: messages, then) . . . Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 2 link states coalesced Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:20 7950X3D-UFS dhclient[53725]: New IP Address (ue0): 192.168.1.157 Nov 30 03:23:20 7950X3D-UFS dhclient[53730]: New Subnet Mask (ue0): 255.255.255.0 Nov 30 03:23:20 7950X3D-UFS dhclient[53734]: New Broadcast Address (ue0): 192.168.1.255 Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 3 link states coalesced Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:20 7950X3D-UFS dhclient[53771]: New Routers (ue0): 192.168.1.1 Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 3 link states coalesced Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 2 link states coalesced Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP . . . (lots more) . . . Other FreeBSD system on the Ethernet are not getting such but none of them are currently using such a dongle. Note: The ASUS X670-P WiFi board's built in Ethernet is not supported. === Mark Millard marklmi at yahoo.com I see the same with my Lenovo dongle: ugen1.12: at usbus1 ure0 on uhub6 ure0: on usbus1 miibus1: on ure0 rgephy1: PHY 0 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 Jakob
main [so: 15] context, 7950X3D and RTL8251/8153 based Ethernet dongle: loss of state, example log information
The following sort of thing is happening a lot: Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically used on occasion, sometimes for long periods . . . Example contexts for the issue have been: FreeBSD 15.0-CURRENT #126 main-n266130-d521abdff236-dirty: Tue Oct 24 18:17:40 PDT 2023 and: FreeBSD 15.0-CURRENT #131 main-n266749-ed31b3f4a146-dirty: Wed Nov 29 16:53:33 PST 2023 Both UFS and ZFS boot media, here part of a ed31b3f4a146 UFS example is shown Nov 29 18:26:27 7950X3D-UFS kernel: miibus0: on ure0 Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: PHY 0 on miibus0 Nov 29 18:26:27 7950X3D-UFS kernel: rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto Nov 29 18:26:27 7950X3D-UFS kernel: ue0: on ure0 Nov 29 18:26:27 7950X3D-UFS kernel: ue0: Ethernet address: REDACTED Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to DOWN . . . Nov 29 18:26:27 7950X3D-UFS kernel: ue0: link state changed to UP . . . (no ue0: messages, then) . . . Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:19 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 2 link states coalesced Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:20 7950X3D-UFS dhclient[53725]: New IP Address (ue0): 192.168.1.157 Nov 30 03:23:20 7950X3D-UFS dhclient[53730]: New Subnet Mask (ue0): 255.255.255.0 Nov 30 03:23:20 7950X3D-UFS dhclient[53734]: New Broadcast Address (ue0): 192.168.1.255 Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:20 7950X3D-UFS kernel: ue0: 3 link states coalesced Nov 30 03:23:20 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:20 7950X3D-UFS dhclient[53771]: New Routers (ue0): 192.168.1.1 Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to DOWN Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 3 link states coalesced Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP Nov 30 03:23:21 7950X3D-UFS kernel: ue0: 2 link states coalesced Nov 30 03:23:21 7950X3D-UFS kernel: ue0: link state changed to UP . . . (lots more) . . . Other FreeBSD system on the Ethernet are not getting such but none of them are currently using such a dongle. Note: The ASUS X670-P WiFi board's built in Ethernet is not supported. === Mark Millard marklmi at yahoo.com
