Bug 252165 - usb network and mii bus media status race condition
Summary: usb network and mii bus media status race condition
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-26 16:14 UTC by Ali Abdallah
Modified: 2025-03-24 03:36 UTC (History)
21 users (show)

See Also:


Attachments
Workaround race in link status change (1.50 KB, patch)
2021-01-04 19:37 UTC, Ali Abdallah
no flags Details | Diff
dtrace ure usb traces (90.43 KB, text/plain)
2022-09-28 10:13 UTC, Ali Abdallah
no flags Details
Partially solves for me (1.38 KB, patch)
2024-06-29 09:45 UTC, ml
no flags Details | Diff
usb_ethernet Sync ioctl/tick media status changes (2.86 KB, patch)
2024-11-13 18:03 UTC, Ali Abdallah
no flags Details | Diff
usb_ethernet Sync ioctl/tick media status changes v2 (2.82 KB, patch)
2024-11-14 08:13 UTC, Ali Abdallah
no flags Details | Diff
usb_ethernet Sync ioctl/tick media status changes v3 (3.10 KB, patch)
2024-11-19 15:17 UTC, Ali Abdallah
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ali Abdallah 2020-12-26 16:14:32 UTC
I'm using if_ure on a USB-C dock station. I'm having the following random issue:

Dec 25 12:20:10 Fryzen495 kernel: ue0: link state changed to UP
Dec 25 12:20:10 Fryzen495 kernel: ue0: link state changed to DOWN
Dec 25 12:20:10 Fryzen495 kernel: ue0: link state changed to UP
Dec 25 12:20:58 Fryzen495 kernel: ue0: link state changed to DOWN
Dec 25 12:21:01 Fryzen495 kernel: ue0: link state changed to UP
Dec 25 12:21:07 Fryzen495 dhclient[20388]: New IP Address (ue0): 192.168.1.145
Dec 25 12:21:07 Fryzen495 dhclient[21191]: New Subnet Mask (ue0): 255.255.255.0
Dec 25 12:21:07 Fryzen495 dhclient[22099]: New Broadcast Address (ue0): 192.168.1.255
Dec 25 12:21:07 Fryzen495 dhclient[22651]: New Routers (ue0): 192.168.1.254

After digging into the code, I've discovered that the issue is caused by the following race condition:

In mii/mii.c, the function miibus_linkchg(device_t dev) reads mii->mii_media_status and sets the link state accordingly. 

static void
miibus_linkchg(device_t dev)
{
...

   if (mii->mii_media_status & IFM_AVALID) {
       if (mii->mii_media_status & IFM_ACTIVE)
           link_state = LINK_STATE_UP;
       else
           link_state = LINK_STATE_DOWN;

...
}

On the other hand, the function mii_pollstat running on another thread, polls the media status, which is using rgephy.c code in my case. (via PHY_SERVICE call)

static void
rgephy_status(struct mii_softc *sc)
{
   mii->mii_media_status = IFM_AVALID;
   mii->mii_media_active = IFM_ETHER;

   /* HERE IS THE ISSUE
     The read in miibus_linkchg is randomly seeing mii->mii_media_status as IFM_AVALID,
     but it does not yet have the IFM_ACTIVE flag set, which makes it trigger a link state change...
   */

   if (rgephy_linkup(sc) != 0)
      mii->mii_media_status |= IFM_ACTIVE;
   ...

This is an issue in all miibus modules, rgephy.c, truephy.c, mlphy.c, etc...

Please note that also in mii_pollstat, mii->mii_media_status is initialized to 0 (not sure why), and that also races with miibus_linkchg.

There are many ways to fix it, locally I'm not resetting mii->mii_media_status until rgephy_linkup(sc) returns link down.
Comment 1 Rodney W. Grimes freebsd_committer freebsd_triage 2020-12-27 10:14:11 UTC
I believe I have seen this several times in the past, mostly when I am doing diskless boots via pxe/ipxe/nfs.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2020-12-27 12:20:28 UTC
^Triage: set to net@ as this affect miibus.
Comment 3 Ali Abdallah 2021-01-04 19:37:43 UTC
Created attachment 221274 [details]
Workaround race in link status change

(In reply to Rodney W. Grimes from comment #1)
The various mii modules are "terribly" SMP broken, they all reset the media status to

mii->mii_media_status = IFM_AVALID; 

then call the hardware specific function to check the link and eventually set

mii->mii_media_status |= IFM_ACTIVE;

But during this time the call to miibus_linkchg might trigger a link change, as it randomly sees the IFM_AVALID flag only, before the IFM_ACTIVE being set.

Attached is the workaround I'm currently applying to avoid the issue on my T495 with the Thinkpad USB-C gen2 docking station (My hardware uses rgephy.c). If you think this is the way to go, I can provide a full patch for the rest of the mii bus modules.
Comment 4 Hans Petter Selasky freebsd_committer freebsd_triage 2021-01-07 14:47:42 UTC
Could you extend your patch to fix the other cases you see aswell, and create a patch at https://reviews.freebsd.org/differential/ with full context?
Comment 5 Ali Abdallah 2021-01-08 07:19:18 UTC
(In reply to Hans Petter Selasky from comment #4)

Yes I'll do that.
Comment 6 Ali Abdallah 2021-01-11 12:30:07 UTC
I had a deeper look into the issue, applying the work-around described in comment 3 is definitely not the way to go, the problem lies somewhere else.

Actually the code path that end up calling miibus_linkchg is mii_tick and mii_poll (through mii_phy_update). At the first look they seem to be running without lock, but looking at the usb ethernet specific code (if_ure.c in my case), a common lock is acquired before calling those functions.

in ure_tick the lock is already acquired beforehand, by the usb ethernet code 

static void
ure_tick(struct usb_ether *ue)
....
URE_LOCK_ASSERT(sc, MA_OWNED); 
mii_tick(mii);
....

ure_ifmedia_sts is what polls for media status, and it acquires the same lock before calling mii_pollstat.

static void
ure_ifmedia_sts(struct ifnet *ifp, struct ifmediareq *ifmr)
...
URE_LOCK(sc);
mii_pollstat(mii);
...
URE_UNLOCK(sc);

What I'm seeing is that, despite the lock, sometimes they run both in parallel, which is causing the race in the media status... I'm not sure why, and it is kind of driving me crazy.
Comment 7 Hans Petter Selasky freebsd_committer freebsd_triage 2021-01-11 12:39:13 UTC
Did you try using dtrace, or adding simple prints:

printf("%d %s:%d\n", ticks, __FILE__, __LINE__);

--HPS
Comment 8 Ali Abdallah 2021-01-11 12:43:57 UTC
Yes I did add simple printf, showing the thread id, and this is what I have

Jan  8 16:24:47 frix230 kernel: tick begin  thread 0xfffff800a2343000
Jan  8 16:24:47 frix230 kernel: tick finish thread 0xfffff800a2343000
Jan  8 16:24:48 frix230 kernel: 
Jan  8 16:24:48 frix230 kernel: poll begin  thread 0xfffff8001e67c000
Jan  8 16:24:48 frix230 kernel: poll finish thread 0xfffff8001e67c000
Jan  8 16:24:48 frix230 kernel: 
Jan  8 16:24:48 frix230 kernel: 
Jan  8 16:24:48 frix230 kernel: poll begin  thread 0xfffff8001e67c000
Jan  8 16:24:48 frix230 kernel: poll finish thread 0xfffff8001e67c000
Jan  8 16:24:48 frix230 kernel: 
Jan  8 16:24:48 frix230 kernel: tick begin  thread 0xfffff800a2343000
Jan  8 16:24:48 frix230 kernel: 
Jan  8 16:24:48 frix230 kernel: poll begin  thread 0xfffff8001e67c000 
Jan  8 16:24:48 frix230 kernel: Link down detected from thread 0xfffff800a2343000 
Jan  8 16:24:48 frix230 kernel: tick finish thread 0xfffff800a2343000
Jan  8 16:24:48 frix230 kernel: ue0: link state changed to DOWN
Jan  8 16:24:48 frix230 kernel:
Jan  8 16:24:48 frix230 kernel: Link up detected from thread 0xfffff8001e67c000
Jan  8 16:24:48 frix230 kernel: poll finish thread 0xfffff8001e67c000
Jan  8 16:24:48 frix230 kernel: ue0: link state changed to UP
Jan  8 16:24:48 frix230 kernel: 

All those print are after having acquired the lock and before releasing it. As you can see, the poll thread begins while the tick one didn't finish yet.
Comment 9 Ali Abdallah 2021-01-11 12:59:03 UTC
How can that be even possible? I've added also the following static variable in ure_tick

URE_LOCK_ASSERT(sc, MA_OWNED);                                                          
printf("\ntick begin thread %p\n", curthread);
ticking = 1;
mii_tick(mii);                                                                                                                
ticking = 0;
printf("\ntick end thread %p\n", curthread);

And in ure_ifmedia_sts

URE_LOCK(sc);
printf("poll begin %p\n", curthread);
if (!ticking)                                                                                                                 
  mii_pollstat(mii);
printf("poll end %p\n", curthread);
...
URE_UNLOCK(sc);

And it is running fine since last Friday, which proves further that the poll thread is being executed while the tick on is running, despite the fact that they use the same lock!

The only difference I personally see here, unlike mii_tick, ure_ifmedia_sts is called at the end of a syscall, not sure if this is relevant here.
Comment 10 Hans Petter Selasky freebsd_committer freebsd_triage 2021-01-11 13:24:25 UTC
Hi,

Can you print "%s" curthread->td_proc->p_comm

and

curthread->td_name

Probably two threads are racing there!

--HPS
Comment 11 Ali Abdallah 2021-01-11 13:44:09 UTC
The additional strings to print changed a bit the timing, it is no longer racing on media status, but media type (it went from 1000baseT <full-duplex> to nothing during the race below).

Jan 11 14:40:42 frix230 kernel: tick begin thread 0xfffff8027121a740 ure0 usb
Jan 11 14:40:42 frix230 kernel: 
Jan 11 14:40:42 frix230 kernel: poll begin 0xfffff801ca32f000 ifconfig ifconfig
Jan 11 14:40:42 frix230 kernel: poll finish 0xfffff801ca32f000 ifconfig ifconfig
Jan 11 14:40:42 frix230 kernel: 
Jan 11 14:40:42 frix230 kernel: poll begin 0xfffff801ca32f000 ifconfig ifconfig
Jan 11 14:40:42 frix230 kernel: poll finish 0xfffff801ca32f000 ifconfig ifconfig
Jan 11 14:40:42 frix230 kernel: 
Jan 11 14:40:42 frix230 kernel: poll begin 0xfffff801ca32f000 ifconfig ifconfig
Jan 11 14:40:42 frix230 kernel: poll finish 0xfffff801ca32f000 ifconfig ifconfig
Jan 11 14:40:42 frix230 kernel: tick end thread 0xfffff8027121a740 ure0 usb

For the test, I'm calling ifconfig continuously from a script, but any network monitoring applet will trigger the issue.
Comment 12 Ali Abdallah 2021-01-20 13:55:24 UTC
Any possible explanation of what is happening here? Thanks.
Comment 13 Ali Abdallah 2021-03-01 17:25:22 UTC
I had a better look at the code, and I think I have an explanation of what is the root cause of the issue. 

The function uether_rxflush releases the lock, causing a mess up with lock/unlock orders.

void
uether_rxflush(struct usb_ether *ue)
{
        ...       
        UE_LOCK_ASSERT(ue, MA_OWNED);
                
        n = mbufq_flush(&ue->ue_rxq);
        UE_UNLOCK(ue);
        NET_EPOCH_ENTER(et);
        ...
        NET_EPOCH_EXIT(et);
        UE_LOCK(ue);
}   

I've dtraced the calls

2  64153           ure_ifmedia_sts:return      155646206056
0  64153           ure_ifmedia_sts:return      155647214955
0  64152            ure_ifmedia_sts:entry      155647476515
2  64153           ure_ifmedia_sts:return      155648459628
2  64152            ure_ifmedia_sts:entry      155648490676
1  64220             uether_rxflush:entry      155649463422  <-
0  64153           ure_ifmedia_sts:return      155649466344  <-
1  64221            uether_rxflush:return      155649488201


When uether_rxflush:entry is called, it has the lock, but then it is releasing it and re-acquiring it later, causing the mess with ure_ifmedia_sts IMHO.
Comment 14 Ali Abdallah 2021-03-02 07:39:28 UTC
Even without UE_LOCK and UE_UNLOCK of comment 13 the issue is still occurring... 

The following dtrace is observed when the link state fictitiously changes 

2  64192               ue_tick_task:entry      242528044179
2  64175                   ure_tick:entry      242528050925
1  64152            ure_ifmedia_sts:entry      242529137165
2  64176                  ure_tick:return      242529369904
1  64152            ure_ifmedia_sts:entry      242529474008
2  64153           ure_ifmedia_sts:return      242530486029

For whatever reason... Normally the sequence should be 

2  64152            ure_ifmedia_sts:entry      243552084077
2  64153           ure_ifmedia_sts:return      243553071554
0  64192               ue_tick_task:entry      243553441743
0  64175                   ure_tick:entry      243553444178
2  64176                  ure_tick:return      243554572011
3  64152            ure_ifmedia_sts:entry      243663084286
3  64153           ure_ifmedia_sts:return      243664074467
Comment 15 Hans Petter Selasky freebsd_committer freebsd_triage 2021-03-02 10:43:15 UTC
Probably all of the chip configuration and status reads need to be serialized on a USB process callback thread.

--HPS
Comment 16 Ali Abdallah 2021-03-02 16:47:22 UTC
(In reply to Hans Petter Selasky from comment #15)

Probably, but I'm really not sure how to deal in a usb callback thread with the SIOCSIFMEDIA ioctl.

Also, I'm still not able to identify the root cause of the issue, the fact that the usb thread and the ifconfig ioctl thread use the same lock should avoid any race, but for some reason it is not happening. I would still like to understand what is going wrong.
Comment 17 Ali Abdallah 2022-04-08 13:56:42 UTC
After digging further into the code, I'm still unable to understand how the inversion described in comment 14 is even possible...

On a spare system T430 with a USB ethernet, I've compiled the kernel with 

options WITNESS
options INVARIANTS
options INVARIANT_SUPPORT
options DEBUG_LOCKS
options DIAGNOSTIC

The up/down link issue is even more frequent with the debug kernel, but all I see is 

if_delmulti_locked: detaching ifnet instance 0xfffff8001880b800
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

This issue is driving me crazy, any fbsd kernel locking expert to help here?
Comment 18 Hans Petter Selasky freebsd_committer freebsd_triage 2022-04-08 14:47:30 UTC
dtrace does not work if a function was inlined in the same C-file it was declared!

Try to compile a kernel w/o optimizations, -O0, first.

--HPS
Comment 19 Ali Abdallah 2022-04-08 16:58:43 UTC
(In reply to Hans Petter Selasky from comment #18)
Compiling the kernel with COPTFLAGS=-O0 and CFLAGS=-O0 resulted in non-working dtrace... (dtrace: invalid probe specifier... "/usr/lib/dtrace/mbuf.d", line 1: failed to copy type of 'm_data': Type information is in parent and unavailable.) But anyway the problem occurs, with no particular dmesg from witness or debug_lock.

On the other hand, on the standard generic kernel, when the issue is not occurring, the following dtrace is shown

# dtrace -n "fbt:kernel:mii_pollstat:*,fbt:uether:ue_tick_task:*,fbt:if_ure:ure_tick:*,fbt:if_ure:ure_ifmedia_sts:*,fbt:kernel:mii_tick:*"

  0  92491            ure_ifmedia_sts:entry 
  0  35254               mii_pollstat:entry 
  2  35255              mii_pollstat:return 
  2  92492           ure_ifmedia_sts:return 

  3  92425               ue_tick_task:entry 
  3  92489                   ure_tick:entry 
  3  35276                   mii_tick:entry 
  3  35277                  mii_tick:return 
  3  92490                  ure_tick:return 

Which are the two "code-path" checking for link status. Now with the same dtrace probes, when the link up/down problem occurs, I see 

  3  92425               ue_tick_task:entry 
  3  92489                   ure_tick:entry 
  3  35276                   mii_tick:entry 
  0  92491            ure_ifmedia_sts:entry  <----
  0  35254               mii_pollstat:entry  <----
  3  35277                  mii_tick:return 
  3  92490                  ure_tick:return

How that is possible? ure_ifmedia_sts should acquire the same mutex lock as ue_tick_task before calling mii_pollstat. And this is not happening apparently.
Comment 20 Hans Petter Selasky freebsd_committer freebsd_triage 2022-04-08 20:20:09 UTC
Can you make dtrace print the backtrace? Maybe it is another ethernet device?

--HPS
Comment 21 Ali Abdallah 2022-04-09 06:24:47 UTC
(In reply to Hans Petter Selasky from comment #20)
Not sure how to do that, but anyway, it is the only USB ethernet device I have that uses if_ure and mii bus, if not loaded, nothing is shown in the mentioned dtrace command.
Comment 22 vxasxfepbikrfqdruz 2022-09-19 19:15:57 UTC
I believe I am having the same issue with if_axe using a usb to ethernet adapter based on the ASIX AX88178 chipset. It works (sort of) and I can get the full speed I'm expecting but dmesg shows the interface as going UP and DOWN constantly which seems to manifest as dropped packets. If there's any information I can provide please ask.

Has there been any progress on this? (In reply to Ali Abdallah from comment #6) I know it's not a good fix but would you be willing to apply that workaround to if_axe so I could build it myself?
Comment 23 Ali Abdallah 2022-09-23 09:59:24 UTC
(In reply to vxasxfepbikrfqdruz from comment #22)

Unfortunately I had no time recently to continue debugging the issue, I'm still using the ugly workaround in my local branch
Comment 24 Ali Abdallah 2022-09-28 10:13:21 UTC
Created attachment 236901 [details]
dtrace ure usb traces

I got another machine on which I didn't apply the workaround, running 13.1, with a USB Lan adapter that uses if_ure, I used the following dtrace probes.

dtrace -n 'fbt:miibus:mii_pollstat:*,fbt:uether:ue_tick_task:*,fbt:if_ure:ure_tick:*,fbt:if_ure:ure_ifmedia_sts:*,fbt:miibus:mii_tick:*,fbt:miibus:miibus_linkchg:*, fbt:usb:* { printf("%p", curthread); }'

You can see from the attached debug log (numbered lines)

1  48573            ure_ifmedia_sts:entry fffffe00dc75c720
1  48475               mii_pollstat:entry fffffe00dc75c720

But before exit entry of re_ifmedia_sts:return of thread fffffe00dc75c720, you can see:

1052   0  48573            ure_ifmedia_sts:entry fffffe00e00271e0
1053   2  27791        usb_command_wrapper:entry fffffe0082a17ac0
1054   2  27738      usbd_callback_wrapper:entry fffffe0082a17ac0
1055   0  48475               mii_pollstat:entry fffffe00e00271e0

And that exactly when the link up/down happened.

So thread fffffe00e00271e0 managed to go ahead and call mii_pollstat, acquiring the sc mutex, despite that thread fffffe00dc75c720 didn't release it yet, you can see that the return from "polling the media state" on thread fffffe00dc75c720 comes way after the ure_ifmedia_sts:entry of thread fffffe00e00271e0

1517   3  48476              mii_pollstat:return fffffe00dc75c720
1518   3  48574           ure_ifmedia_sts:return fffffe00dc75c720

__snip if_ure__ 

ure_ifmedia_sts
{
  ...
  URE_LOCK(sc);                                                                                                                
  mii_pollstat(mii);
  ifmr->ifm_active = mii->mii_media_active;
  ifmr->ifm_status = mii->mii_media_status;
  URE_UNLOCK(sc);
}
__snip__

The mutex locked/released by URE_LOCK, is the same mutex used in if_ure, USB xfer and USB transfer, so I guess something is not playing well in the release/acquire sequence...

Will try if time permits to dig more into the USB transfer/process code, but I have to say that I'm extremely surprised that this bug didn't attract much attention, it actually renders any USB Ethernet device unusable on FreeBSD...
Comment 25 vxasxfepbikrfqdruz 2022-10-22 04:06:44 UTC
(In reply to Ali Abdallah from comment #24)
Yeah, I was pretty surprised as well that this is entirely broken despite several USB to ethernet adapters being listed as supported by FreeBSD. This also affects pfSense and opnSense which you think would generate some attention about this, but they just seem to recommend not using USB adapters at all. 

If it's any help when I was getting my USB adapters I checked with the supported devices list and the comments on amazon. There were several comments saying their adapters worked fine with freebsd with the latest one being from October 2016. That would mean this problem was probably introduced sometime between v10.4 and now.

This is kinda over my head but I would really appreciate if this were fixed and I was able to build the fixed mii module. Thank you for your efforts.



P.S. This is only sort of related but there's another issue with USB adapters if you have more than one. They get picked up at boot in a random order so which adapter is which interface will get shuffled every boot. I was able to mitigate that using the ethname package.
Comment 26 Hans Petter Selasky freebsd_committer freebsd_triage 2022-10-22 10:10:00 UTC
These issues are not forgotten. It just takes a while to find good and generic solutions. Maybe all MII bus code should be executed for the same thread?

Would remove the need for depending on locking.

--HPS
Comment 27 ml 2022-10-31 05:53:08 UTC
(In reply to vxasxfepbikrfqdruz from comment #22)

Just a me too here.
I have an AX88179A USB-C adapter.

Feel free to ask for any info.
Comment 28 ml 2022-10-31 14:16:46 UTC
(In reply to ml from comment #27)

P.S.
I tried the patch from comment #3, but it doesn't help in my case.
Comment 29 Ali Abdallah 2022-11-02 08:03:31 UTC
(In reply to ml from comment #28)

your device doesn't use mii bus rgephy code, but something else. See which part your device uses from sys/dev/mii/ and adapt the workaround accordingly.
Comment 30 Ali Abdallah 2022-11-02 08:14:35 UTC
(In reply to Hans Petter Selasky from comment #26)
> Maybe all MII bus code should be executed for the same thread?

Not sure what do you mean.

The issue is that the ioctl for media status (which invokes the mii bus) races with a currently running tick (ure_tick for example).

So the MII bus code runs in a single thread always, but one invoked by ioctl and another one by the tick callback race between each other sometimes (and it is not clear why, as both code paths use the same lock...)
Comment 31 ml 2022-11-06 10:01:37 UTC
(In reply to Ali Abdallah from comment #29)

Doh! Should have been obvious! (At least to someone more expert than me :)
Anyway, I made the same changes to ukphy and now LAN seems to work perfectly: I was able to run a full "make installworld" via NFS (which previously would have required unplugging/replugging the adapter at least 4 or 5 times).
Thanks.
Comment 32 ciaduck 2024-03-16 00:56:54 UTC
Hello. I'm an OPNsense user, and I'm having this exact issue.

What can I do to help? I have 2 different USB NICs (Anker and Ugreen), and both exhibit this behavior.

I'd really like to help solve this issue, because it impacts many and I think it would be very nice to be able to use USB NICs on my firewall PC.


Thanks!
Comment 33 kosolapiy 2024-06-28 14:40:21 UTC
(In reply to ml from comment #31)
Hi! Any chance you could share what you changed for asix ethernet adapter? (In reply to ml from comment #31)
Comment 34 ml 2024-06-29 09:45:10 UTC
(In reply to kosolapiy from comment #33)

Sure.
I'm attaching the patch I applied to CURRENT.
Notice:
a) I'm not using current, so I also applied the same to 13.3R;
b) this does not *solve*, only makes it usable (i.e. hangs and forces me to unplug/replug the adapter several times per days, instead of a few times per minute).
Comment 35 ml 2024-06-29 09:45:46 UTC
Created attachment 251770 [details]
Partially solves for me
Comment 36 Ali Abdallah 2024-11-13 18:01:05 UTC
(In reply to Hans Petter Selasky from comment #26)

The issue is that ioctl thread to get the media status, which basically started by userspace races with ue_tick_task. And I finally know why.

The usbd_do_request_flags called releases the lock and then later acquire it (see the code). So, an ioctl waiting on the same lock will be executed together with ue_tick_task (because they aren't executed from the same thread), causing the race observed here and basically breaking all usb ethernet devices.

I will shortly attach a patch to Sync ioctl/tick media status changes.
Comment 37 Ali Abdallah 2024-11-13 18:03:31 UTC
Created attachment 255142 [details]
usb_ethernet Sync ioctl/tick media status changes

This solves the issue without touching the mii code or any specific usb ethernet device code (like if_ure and others for example) I tested it and so far so good.

Please review it/test it extensively.
Comment 38 Ali Abdallah 2024-11-13 21:26:53 UTC
(In reply to Ali Abdallah from comment #37)
The patch in comment 37 could be a bit optimized, yes! 

The usb process/request code is completely broken when it comes to different threads sharing ue_lock (ioctl versus uether tick), the usb request code releases the acquired lock, making ioctl thread waiting for the same lock to be scheduled for execution, lovely!

To be more precise.

ioctly waiting for ue_lock, which is acquired by ue_tick, but then the tick code will call at some point usbd_do_request_flags, which will release the lock at the beginning (and then acquire it later), but in the meantime we have our "cute" ioctl thread waken-up only to report wrong media_status value!
Comment 39 Ali Abdallah 2024-11-14 08:13:39 UTC
Created attachment 255162 [details]
usb_ethernet Sync ioctl/tick media status changes v2

patch v2, this should be enough to sync ioctl with tick usb net threads.
Comment 40 Mikael Urankar freebsd_committer freebsd_triage 2024-11-18 08:47:15 UTC
(In reply to Ali Abdallah from comment #39)
I see UP / DOWN and network stall with v2.
I'll try with v1
Comment 41 Mikael Urankar freebsd_committer freebsd_triage 2024-11-18 08:47:58 UTC
(In reply to Mikael Urankar from comment #40)
forget my last comment, I forgot to patch my src tree :/
Comment 42 Mikael Urankar freebsd_committer freebsd_triage 2024-11-18 09:41:05 UTC
(In reply to Ali Abdallah from comment #39)
None of the patches (v1 or v2) work for me.
Comment 43 Ali Abdallah 2024-11-19 07:33:32 UTC
(In reply to Mikael Urankar from comment #42)
What do you mean by they don't work? Can you be more specific? Which usb network device you are using? 

I tested the patch (v2) on a couple of network devices I have on FreeBSD 14.1 (both use if_ure), I no longer can reproduce the issue and network is stable so far.
Comment 44 Ali Abdallah 2024-11-19 09:24:45 UTC
(In reply to Mikael Urankar from comment #42)

I can still reproduce with both patches the state down/up issue. 

The patch solves tick vs ioctl. But running 2 or ifconfig from different screens lead to the issue (ioctl thread1 vs ioctl thread2), since usbd_do_request_flags releases the lock and so one of the ioctl thread waiting for it gets executed, altering the media_state flag.

I will try to dedicate some time for it to see how this can be solved.
Comment 45 Ali Abdallah 2024-11-19 15:17:39 UTC
Created attachment 255301 [details]
usb_ethernet Sync ioctl/tick media status changes v3

Please kindly give the attach v3 patch a try.
Comment 46 Mikael Urankar freebsd_committer freebsd_triage 2024-11-20 13:54:28 UTC
(In reply to Ali Abdallah from comment #43)
It's a dell dockstation,
rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0

No packets are coming in or coming out. Same problem with v3
Comment 47 Ali Abdallah 2024-11-20 14:06:02 UTC
(In reply to Mikael Urankar from comment #46)

But does your dell dockstation work without the patch?
Comment 48 Mikael Urankar freebsd_committer freebsd_triage 2024-11-20 15:41:15 UTC
(In reply to Ali Abdallah from comment #47)
It kinda works, the interface goes up and down and I can transfer a few GB of data before any more packets pass through.
Comment 49 Ali Abdallah 2024-11-20 15:50:05 UTC
(In reply to Mikael Urankar from comment #48)

The patch doesn't touch packets transferring/receiving. It is only trying to address the up/down issue. 

Are you using dhclient? can you attach ifconfig?
Comment 50 Nick Lott 2024-12-10 07:35:44 UTC
I have applied this patch(v3) to the generic 14.2 kernel and it appears to have solved my issue. I no longer see constant up/down messages and am able to sustain 950Mbps over my DELL WD19 dock.
Comment 51 Nick Lott 2024-12-10 07:37:53 UTC
(In reply to Nick Lott from comment #50)
# dmesg | grep miibus
[18] miibus0: <MII bus> on ure0
[18] rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
Comment 52 Oleksandr Kryvulia 2024-12-10 14:56:35 UTC
I can also confirm - patch v3 solves this problem with my ThinkPad Dock on current.
Comment 53 Nick Lott 2024-12-14 20:04:02 UTC
I noticed a short bunch of regressions to previous behavior even with the patch after a few days of uptime. The USB interface starts to have issues from Dec 15 00:26:09 to  Dec 15 05:51:10. (NOTE: This still an massive improvement on the behavior prior to the patch :) )

I have a lagg interface configured as follows:

    ifconfig_lagg0="up laggproto failover laggport ue0 laggport wlan1 DHCP"

At some point proir to  Dec 15 06:44:00 ue0 dropped out of the lagg0 interace it was a part of, but when the lagg0 interfaces is destroyed and re created the ue0 interface is working well.

Here is the output of "cat /var/log/messages | grep kernel" (NOTE: ethernet MAC addresses have been redacted)

Dec 12 06:34:59 lemurBSD kernel: ---<<BOOT>>---
Dec 12 06:34:59 lemurBSD kernel: Copyright (c) 1992-2023 The FreeBSD Project.
Dec 12 06:34:59 lemurBSD kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
Dec 12 06:34:59 lemurBSD kernel: 	The Regents of the University of California. All rights reserved.
Dec 12 06:34:59 lemurBSD kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
Dec 12 06:34:59 lemurBSD kernel: FreeBSD 14.2-RELEASE #3 releng/14.2-n269506-c8918d6c7412-dirty: Sun Dec  8 22:37:34 NZDT 2024
Dec 12 06:34:59 lemurBSD kernel:     root@experiment:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
Dec 12 06:34:59 lemurBSD kernel: FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67)
Dec 12 06:34:59 lemurBSD kernel: VT(efifb): resolution 1920x1080
Dec 12 06:34:59 lemurBSD kernel: module_register: cannot register tmpfs from kernel; already loaded from tmpfs.ko
Dec 12 06:34:59 lemurBSD kernel: Module tmpfs failed to register: 17
Dec 12 06:34:59 lemurBSD kernel: CPU: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz (2100.00-MHz K8-class CPU)
Dec 12 06:34:59 lemurBSD kernel:   Origin="GenuineIntel"  Id=0x806ec  Family=0x6  Model=0x8e  Stepping=12
Dec 12 06:34:59 lemurBSD kernel:   Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Dec 12 06:34:59 lemurBSD kernel:   Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
Dec 12 06:34:59 lemurBSD kernel:   AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
Dec 12 06:34:59 lemurBSD kernel:   AMD Features2=0x121<LAHF,ABM,Prefetch>
Dec 12 06:34:59 lemurBSD kernel:   Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
Dec 12 06:34:59 lemurBSD kernel:   Structured Extended Features3=0xbc000600<MCUOPT,MD_CLEAR,IBPB,STIBP,L1DFL,ARCH_CAP,SSBD>
Dec 12 06:34:59 lemurBSD kernel:   XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
Dec 12 06:34:59 lemurBSD kernel:   IA32_ARCH_CAPS=0x2b<RDCL_NO,IBRS_ALL,SKIP_L1DFL_VME,MDS_NO>
Dec 12 06:34:59 lemurBSD kernel:   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
Dec 12 06:34:59 lemurBSD kernel:   TSC: P-state invariant, performance statistics
Dec 12 06:34:59 lemurBSD kernel: real memory  = 17179869184 (16384 MB)
Dec 12 06:34:59 lemurBSD kernel: avail memory = 16465797120 (15703 MB)
Dec 12 06:34:59 lemurBSD kernel: Event timer "LAPIC" quality 600
Dec 12 06:34:59 lemurBSD kernel: ACPI APIC Table: <COREv4 COREBOOT>
Dec 12 06:34:59 lemurBSD kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
Dec 12 06:34:59 lemurBSD kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads
Dec 12 06:34:59 lemurBSD kernel: random: registering fast source Intel Secure Key RNG
Dec 12 06:34:59 lemurBSD kernel: random: fast provider: "Intel Secure Key RNG"
Dec 12 06:34:59 lemurBSD kernel: random: unblocking device.
Dec 12 06:34:59 lemurBSD kernel: ioapic0 <Version 2.0> irqs 0-119
Dec 12 06:34:59 lemurBSD kernel: Launching APs: 1 6 5 7 4 2 3
Dec 12 06:34:59 lemurBSD kernel: random: entropy device external interface
Dec 12 06:34:59 lemurBSD kernel: kbd1 at kbdmux0
Dec 12 06:34:59 lemurBSD kernel: efirtc0: <EFI Realtime Clock>
Dec 12 06:34:59 lemurBSD kernel: efirtc0: registered as a time-of-day clock, resolution 1.000000s
Dec 12 06:34:59 lemurBSD kernel: smbios0: <System Management BIOS> at iomem 0x99a4c000-0x99a4c01e
Dec 12 06:34:59 lemurBSD kernel: smbios0: Version: 3.0
Dec 12 06:34:59 lemurBSD kernel: aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
Dec 12 06:34:59 lemurBSD kernel: acpi0: <COREv4 COREBOOT>
Dec 12 06:34:59 lemurBSD kernel: acpi0: Power Button (fixed)
Dec 12 06:34:59 lemurBSD kernel: hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Dec 12 06:34:59 lemurBSD kernel: Timecounter "HPET" frequency 24000000 Hz quality 950
Dec 12 06:34:59 lemurBSD kernel: Event timer "HPET" frequency 24000000 Hz quality 550
Dec 12 06:34:59 lemurBSD kernel: cpu0: <ACPI CPU> on acpi0
Dec 12 06:34:59 lemurBSD kernel: atrtc0: <AT realtime clock> port 0x70-0x77 on acpi0
Dec 12 06:34:59 lemurBSD kernel: atrtc0: registered as a time-of-day clock, resolution 1.000000s
Dec 12 06:34:59 lemurBSD kernel: Event timer "RTC" frequency 32768 Hz quality 0
Dec 12 06:34:59 lemurBSD kernel: attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Dec 12 06:34:59 lemurBSD kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Dec 12 06:34:59 lemurBSD kernel: Event timer "i8254" frequency 1193182 Hz quality 100
Dec 12 06:34:59 lemurBSD kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Dec 12 06:34:59 lemurBSD kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
Dec 12 06:34:59 lemurBSD kernel: acpi_ec0: <Embedded Controller: GPE 0x50> port 0x62,0x66 on acpi0
Dec 12 06:34:59 lemurBSD kernel: pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
Dec 12 06:34:59 lemurBSD kernel: pci0: <ACPI PCI bus> on pcib0
Dec 12 06:34:59 lemurBSD kernel: vgapci0: <VGA-compatible display> port 0x1000-0x103f mem 0xb0000000-0xb0ffffff,0xa0000000-0xafffffff irq 16 at device 2.0 on pci0
Dec 12 06:34:59 lemurBSD kernel: vgapci0: Boot video device
Dec 12 06:34:59 lemurBSD kernel: xhci0: <XHCI (generic) USB 3.0 controller> mem 0x9fc00000-0x9fc0ffff irq 16 at device 20.0 on pci0
Dec 12 06:34:59 lemurBSD kernel: xhci0: 32 bytes context size, 64-bit DMA
Dec 12 06:34:59 lemurBSD kernel: usbus0 on xhci0
Dec 12 06:34:59 lemurBSD kernel: usbus0: 5.0Gbps Super Speed USB v3.0
Dec 12 06:34:59 lemurBSD kernel: pci0: <memory, RAM> at device 20.2 (no driver attached)
Dec 12 06:34:59 lemurBSD kernel: pci0: <network> at device 20.3 (no driver attached)
Dec 12 06:34:59 lemurBSD kernel: pci0: <serial bus> at device 21.0 (no driver attached)
Dec 12 06:34:59 lemurBSD kernel: pci0: <serial bus> at device 25.0 (no driver attached)
Dec 12 06:34:59 lemurBSD kernel: pci0: <simple comms> at device 25.2 (no driver attached)
Dec 12 06:34:59 lemurBSD kernel: pcib1: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
Dec 12 06:34:59 lemurBSD kernel: pci1: <ACPI PCI bus> on pcib1
Dec 12 06:34:59 lemurBSD kernel: pci1: <unknown> at device 0.0 (no driver attached)
Dec 12 06:34:59 lemurBSD kernel: pcib2: <ACPI PCI-PCI bridge> irq 16 at device 29.0 on pci0
Dec 12 06:34:59 lemurBSD kernel: pci2: <ACPI PCI bus> on pcib2
Dec 12 06:34:59 lemurBSD kernel: nvme0: <Generic NVMe Device> mem 0x9f900000-0x9f903fff irq 16 at device 0.0 on pci2
Dec 12 06:34:59 lemurBSD kernel: pcib3: <ACPI PCI-PCI bridge> irq 16 at device 29.4 on pci0
Dec 12 06:34:59 lemurBSD kernel: pci3: <ACPI PCI bus> on pcib3
Dec 12 06:34:59 lemurBSD kernel: nvme1: <Generic NVMe Device> mem 0x9fa00000-0x9fa03fff irq 16 at device 0.0 on pci3
Dec 12 06:34:59 lemurBSD kernel: isab0: <PCI-ISA bridge> at device 31.0 on pci0
Dec 12 06:34:59 lemurBSD kernel: isa0: <ISA bus> on isab0
Dec 12 06:34:59 lemurBSD kernel: hdac0: <Intel Comet Lake-LP HDA Controller> mem 0x9fc1c000-0x9fc1ffff,0x9fb00000-0x9fbfffff irq 16 at device 31.3 on pci0
Dec 12 06:34:59 lemurBSD kernel: pci0: <serial bus> at device 31.5 (no driver attached)
Dec 12 06:34:59 lemurBSD kernel: acpi_acad0: <AC Adapter> on acpi0
Dec 12 06:34:59 lemurBSD kernel: battery0: <ACPI Control Method Battery> on acpi0
Dec 12 06:34:59 lemurBSD kernel: acpi_button0: <Power Button> on acpi0
Dec 12 06:34:59 lemurBSD kernel: acpi_button1: <Sleep Button> on acpi0
Dec 12 06:34:59 lemurBSD kernel: acpi_lid0: <Control Method Lid Switch> on acpi0
Dec 12 06:34:59 lemurBSD kernel: atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
Dec 12 06:34:59 lemurBSD kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0
Dec 12 06:34:59 lemurBSD kernel: kbd0 at atkbd0
Dec 12 06:34:59 lemurBSD kernel: atkbd0: [GIANT-LOCKED]
Dec 12 06:34:59 lemurBSD kernel: psm0: <PS/2 Mouse> irq 12 on atkbdc0
Dec 12 06:34:59 lemurBSD kernel: psm0: [GIANT-LOCKED]
Dec 12 06:34:59 lemurBSD kernel: WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 15.0.
Dec 12 06:34:59 lemurBSD kernel: psm0: model Elantech Touchpad, device ID 0
Dec 12 06:34:59 lemurBSD kernel: coretemp0: <CPU On-Die Thermal Sensors> on cpu0
Dec 12 06:34:59 lemurBSD kernel: hwpstate_intel0: <Intel Speed Shift> on cpu0
Dec 12 06:34:59 lemurBSD kernel: hwpstate_intel1: <Intel Speed Shift> on cpu1
Dec 12 06:34:59 lemurBSD kernel: hwpstate_intel2: <Intel Speed Shift> on cpu2
Dec 12 06:34:59 lemurBSD kernel: hwpstate_intel3: <Intel Speed Shift> on cpu3
Dec 12 06:34:59 lemurBSD kernel: hwpstate_intel4: <Intel Speed Shift> on cpu4
Dec 12 06:34:59 lemurBSD kernel: hwpstate_intel5: <Intel Speed Shift> on cpu5
Dec 12 06:34:59 lemurBSD kernel: hwpstate_intel6: <Intel Speed Shift> on cpu6
Dec 12 06:34:59 lemurBSD kernel: hwpstate_intel7: <Intel Speed Shift> on cpu7
Dec 12 06:34:59 lemurBSD kernel: module_register_init: MOD_LOAD (tmpfs, 0xffffffff80c156e0, 0xffffffff82150cb0) error 17
Dec 12 06:34:59 lemurBSD kernel: Timecounter "TSC" frequency 2112000082 Hz quality 1000
Dec 12 06:34:59 lemurBSD kernel: Timecounters tick every 1.000 msec
Dec 12 06:34:59 lemurBSD kernel: ZFS filesystem version: 5
Dec 12 06:34:59 lemurBSD kernel: ZFS storage pool version: features support (5000)
Dec 12 06:34:59 lemurBSD kernel: ugen0.1: <Intel XHCI root HUB> at usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub0 on usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub0: <Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
Dec 12 06:34:59 lemurBSD kernel: hdacc0: <Realtek ALC293 HDA CODEC> at cad 0 on hdac0
Dec 12 06:34:59 lemurBSD kernel: hdaa0: <Realtek ALC293 Audio Function Group> at nid 1 on hdacc0
Dec 12 06:34:59 lemurBSD kernel: pcm0: <Realtek ALC293 (Analog 2.0+HP/4ch)> at nid 20,21 and 18,26 on hdaa0
Dec 12 06:34:59 lemurBSD kernel: hdacc1: <Intel Kaby Lake HDA CODEC> at cad 2 on hdac0
Dec 12 06:34:59 lemurBSD kernel: hdaa1: <Intel Kaby Lake Audio Function Group> at nid 1 on hdacc1
Dec 12 06:34:59 lemurBSD kernel: pcm1: <Intel Kaby Lake (HDMI/DP 8ch)> at nid 3 on hdaa1
Dec 12 06:34:59 lemurBSD kernel: nda0 at nvme0 bus 0 scbus0 target 0 lun 1
Dec 12 06:34:59 lemurBSD kernel: nda0: <Samsung SSD 970 EVO 500GB xx >
Dec 12 06:34:59 lemurBSD kernel: nda0: Serial Number xx
Dec 12 06:34:59 lemurBSD kernel: nda0: nvme version 1.3
Dec 12 06:34:59 lemurBSD kernel: nda0: 476940MB (976773168 512 byte sectors)
Dec 12 06:34:59 lemurBSD kernel: nda1 at nvme1 bus 0 scbus1 target 0 lun 1
Dec 12 06:34:59 lemurBSD kernel: nda1: <Samsung SSD 970 EVO Plus 250GB  xx xx>
Dec 12 06:34:59 lemurBSD kernel: nda1: Serial Number xx
Dec 12 06:34:59 lemurBSD kernel: nda1: nvme version 1.3
Dec 12 06:34:59 lemurBSD kernel: nda1: 238475MB (488397168 512 byte sectors)
Dec 12 06:34:59 lemurBSD kernel: g_dev_taste: make_dev_p() failed (gp->name=gpt//, error=22)
Dec 12 06:34:59 lemurBSD kernel: sysctl_unregister_oid: failed(22) to unregister sysctl(tmpfs)
Dec 12 06:34:59 lemurBSD kernel: Trying to mount root from zfs:zroot500/ROOT/prewayland-fallback []...
Dec 12 06:34:59 lemurBSD kernel: uhub0: 18 ports with 18 removable, self powered
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.2: <Dell Inc. Dell dock> at usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub1 on uhub0
Dec 12 06:34:59 lemurBSD kernel: uhub1: <Dell Inc. Dell dock, class 9/0, rev 2.10/1.47, addr 1> on usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub1: MTT enabled
Dec 12 06:34:59 lemurBSD kernel: uhub1: 5 ports with 4 removable, self powered
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.3: <Dell Inc. Dell dock> at usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub2 on uhub1
Dec 12 06:34:59 lemurBSD kernel: uhub2: <Dell Inc. Dell dock, class 9/0, rev 2.10/1.21, addr 2> on usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub2: MTT enabled
Dec 12 06:34:59 lemurBSD kernel: uhub2: 6 ports with 6 removable, self powered
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.4: <VIA Labs, Inc. USB2.0 Hub> at usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub3 on uhub2
Dec 12 06:34:59 lemurBSD kernel: uhub3: <VIA Labs, Inc. USB2.0 Hub, class 9/0, rev 2.10/90.80, addr 3> on usbus0
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub3: 4 ports with 4 removable, self powered
Dec 12 06:34:59 lemurBSD kernel: ugen0.5: <vendor 0x1a40 USB 2.0 Hub> at usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub4 on uhub3
Dec 12 06:34:59 lemurBSD kernel: uhub4: <vendor 0x1a40 USB 2.0 Hub, class 9/0, rev 2.00/1.11, addr 4> on usbus0
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub4: 4 ports with 4 removable, self powered
Dec 12 06:34:59 lemurBSD kernel: ugen0.6: <Logitech USB Receiver> at usbus0
Dec 12 06:34:59 lemurBSD kernel: ukbd0 on uhub4
Dec 12 06:34:59 lemurBSD kernel: ukbd0: <Logitech USB Receiver, class 0/0, rev 2.00/12.10, addr 5> on usbus0
Dec 12 06:34:59 lemurBSD kernel: kbd2 at ukbd0
Dec 12 06:34:59 lemurBSD kernel: ugen0.7: <SINO WEALTH USB KEYBOARD> at usbus0
Dec 12 06:34:59 lemurBSD kernel: ukbd1 on uhub4
Dec 12 06:34:59 lemurBSD kernel: ukbd1: <SINO WEALTH USB KEYBOARD, class 0/0, rev 1.10/1.00, addr 6> on usbus0
Dec 12 06:34:59 lemurBSD kernel: kbd3 at ukbd1
Dec 12 06:34:59 lemurBSD kernel: ukbd2 on uhub4
Dec 12 06:34:59 lemurBSD kernel: ukbd2: <SINO WEALTH USB KEYBOARD, class 0/0, rev 1.10/1.00, addr 6> on usbus0
Dec 12 06:34:59 lemurBSD kernel: kbd4 at ukbd2
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.8: <Blueskin Design Ltd dmk20> at usbus0
Dec 12 06:34:59 lemurBSD kernel: ukbd3 on uhub4
Dec 12 06:34:59 lemurBSD kernel: ukbd3: <Blueskin Design Ltd dmk20, class 0/0, rev 1.10/0.01, addr 7> on usbus0
Dec 12 06:34:59 lemurBSD kernel: kbd5 at ukbd3
Dec 12 06:34:59 lemurBSD kernel: ugen0.9: <Logitech Inc. Logi USB Headset H340> at usbus0
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.10: <Generic USB Audio> at usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.11: <vendor 0x413c Dell dock> at usbus0
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.12: <vendor 0x413c Dell dock> at usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.13: <Sonix Technology Co., Ltd. Chicony USB2.0 Camera> at usbus0
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.14: <vendor 0x8087 product 0x0aaa> at usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.15: <Dell Inc. Dell dock> at usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub5 on uhub0
Dec 12 06:34:59 lemurBSD kernel: uhub5: <Dell Inc. Dell dock, class 9/0, rev 3.10/1.47, addr 14> on usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub5: 4 ports with 3 removable, self powered
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.16: <vendor 0x046d Logitech StreamCam> at usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.17: <Dell Inc. Dell dock> at usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub6 on uhub5
Dec 12 06:34:59 lemurBSD kernel: uhub6: <Dell Inc. Dell dock, class 9/0, rev 3.10/1.21, addr 16> on usbus0
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub6: 4 ports with 4 removable, self powered
Dec 12 06:34:59 lemurBSD kernel: ugen0.18: <VIA Labs, Inc. USB3.0 Hub> at usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub7 on uhub6
Dec 12 06:34:59 lemurBSD kernel: uhub7: <VIA Labs, Inc. USB3.0 Hub, class 9/0, rev 3.00/90.81, addr 17> on usbus0
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: uhub7: 4 ports with 4 removable, self powered
Dec 12 06:34:59 lemurBSD kernel: Root mount waiting for: usbus0
Dec 12 06:34:59 lemurBSD kernel: ugen0.19: <Realtek USB 10/100/1000 LAN> at usbus0
Dec 12 06:34:59 lemurBSD kernel: [16] <6>[drm] Got Intel graphics stolen memory base rx0, size 0x0
Dec 12 06:34:59 lemurBSD kernel: [16] drmn0: <drmn> on vgapci0
Dec 12 06:34:59 lemurBSD kernel: [16] vgapci0: child drmn0 requested pci_enable_io
Dec 12 06:34:59 lemurBSD kernel: [16] kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/kbl_dmc_ver1_04.bin either
Dec 12 06:34:59 lemurBSD kernel: [16] i915/kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/i915/kbl_dmc_ver1_04.bin either
Dec 12 06:34:59 lemurBSD kernel: [16] i915_kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/i915_kbl_dmc_ver1_04.bin either
Dec 12 06:34:59 lemurBSD kernel: [16] drmn0: successfully loaded firmware image 'i915/kbl_dmc_ver1_04.bin'
Dec 12 06:34:59 lemurBSD kernel: [16] drmn0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
Dec 12 06:34:59 lemurBSD kernel: [16] lkpi_iic0: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [16] iicbus0: <Philips I2C bus> on lkpi_iic0
Dec 12 06:34:59 lemurBSD kernel: [16] iic0: <I2C generic I/O> on iicbus0
Dec 12 06:34:59 lemurBSD kernel: [16] lkpi_iic1: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [16] iicbus1: <Philips I2C bus> on lkpi_iic1
Dec 12 06:34:59 lemurBSD kernel: [16] iic1: <I2C generic I/O> on iicbus1
Dec 12 06:34:59 lemurBSD kernel: [16] lkpi_iic2: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [16] iicbus2: <Philips I2C bus> on lkpi_iic2
Dec 12 06:34:59 lemurBSD kernel: [16] iic2: <I2C generic I/O> on iicbus2
Dec 12 06:34:59 lemurBSD kernel: [16] lkpi_iic3: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [16] iicbus3: <Philips I2C bus> on lkpi_iic3
Dec 12 06:34:59 lemurBSD kernel: [16] iic3: <I2C generic I/O> on iicbus3
Dec 12 06:34:59 lemurBSD kernel: [16] sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
Dec 12 06:34:59 lemurBSD kernel: [16] lkpi_iic4: <LinuxKPI I2C> on drm1
Dec 12 06:34:59 lemurBSD kernel: [16] iicbus4: <Philips I2C bus> on lkpi_iic4
Dec 12 06:34:59 lemurBSD kernel: [16] iic4: <I2C generic I/O> on iicbus4
Dec 12 06:34:59 lemurBSD kernel: [16] lkpi_iic5: <LinuxKPI I2C> on drm2
Dec 12 06:34:59 lemurBSD kernel: [16] iicbus5: <Philips I2C bus> on lkpi_iic5
Dec 12 06:34:59 lemurBSD kernel: [16] iic5: <I2C generic I/O> on iicbus5
Dec 12 06:34:59 lemurBSD kernel: [16] <6>[drm] Initialized i915 1.6.0 20201103 for drmn0 on minor 0
Dec 12 06:34:59 lemurBSD kernel: [16] VT: Replacing driver "efifb" with new "drmfb".
Dec 12 06:34:59 lemurBSD kernel: [16] fbd0 on drmn0
Dec 12 06:34:59 lemurBSD kernel: [16] device_attach: fbd0 attach returned 6
Dec 12 06:34:59 lemurBSD kernel: [16] lkpi_iic6: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [16] iicbus6: <Philips I2C bus> on lkpi_iic6
Dec 12 06:34:59 lemurBSD kernel: [16] iic6: <I2C generic I/O> on iicbus6
Dec 12 06:34:59 lemurBSD kernel: [16] fbd0 on drmn0
Dec 12 06:34:59 lemurBSD kernel: [16] device_attach: fbd0 attach returned 6
Dec 12 06:34:59 lemurBSD kernel: [16] lkpi_iic7: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [16] iicbus7: <Philips I2C bus> on lkpi_iic7
Dec 12 06:34:59 lemurBSD kernel: [16] iic7: <I2C generic I/O> on iicbus7
Dec 12 06:34:59 lemurBSD kernel: [17] start FB_INFO:
Dec 12 06:34:59 lemurBSD kernel: [17] height=1080 width=1920 depth=32
Dec 12 06:34:59 lemurBSD kernel: [17] pbase=0xa0040000 vbase=0xfffff800a0040000
Dec 12 06:34:59 lemurBSD kernel: [17] name=drmn0 id=i915drmfb flags=0x0 stride=7680
Dec 12 06:34:59 lemurBSD kernel: [17] end FB_INFO
Dec 12 06:34:59 lemurBSD kernel: [17] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:34:59 lemurBSD kernel: [18] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:34:59 lemurBSD kernel: [18] Cuse v0.1.37 @ /dev/cuse
Dec 12 06:34:59 lemurBSD kernel: [18] ure0 on uhub5
Dec 12 06:34:59 lemurBSD kernel: [18] ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 3.00/31.11, addr 18> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [18] Intel(R) Wireless WiFi based driver for FreeBSD
Dec 12 06:34:59 lemurBSD kernel: [18] miibus0: <MII bus> on ure0
Dec 12 06:34:59 lemurBSD kernel: [18] pchtherm0: <CometLake-LP Thermal Subsystem> mem 0x9fc23000-0x9fc23fff irq 16 at device 18.0 on pci0
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: <iwlwifi> mem 0x9fc18000-0x9fc1bfff irq 16 at device 20.3 on pci0
Dec 12 06:34:59 lemurBSD kernel: [18] rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: Detected crf-id 0x2816, cnv-id 0x20000302 wfpm id 0x80000000
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: PCI dev 02f0/0034, rev=0x351, rfid=0x105110
Dec 12 06:34:59 lemurBSD kernel: [18] rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
Dec 12 06:34:59 lemurBSD kernel: [18] ue0: <USB Ethernet> on ure0
Dec 12 06:34:59 lemurBSD kernel: [18] ue0: Ethernet address: xx:xx:xx:xx:xx:xx
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: successfully loaded firmware image 'iwlwifi-QuZ-a0-jf-b0-77.ucode'
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: api flags index 2 larger than supported by driver
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
Dec 12 06:34:59 lemurBSD kernel: [18] iwl-debug-yoyo.bin: could not load binary firmware /boot/firmware/iwl-debug-yoyo.bin either
Dec 12 06:34:59 lemurBSD kernel: [18] iwl-debug-yoyo_bin: could not load binary firmware /boot/firmware/iwl-debug-yoyo_bin either
Dec 12 06:34:59 lemurBSD kernel: [18] iwl_debug_yoyo_bin: could not load binary firmware /boot/firmware/iwl_debug_yoyo_bin either
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: loaded firmware version 77.206b0184.0 QuZ-a0-jf-b0-77.ucode op_mode iwlmvm
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: Detected Intel(R) Wireless-AC 9560 160MHz, REV=0x351
Dec 12 06:34:59 lemurBSD kernel: [18] drmn0: [drm] *ERROR* Link Training Unsuccessful
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: Detected RF JF, rfid=0x105110
Dec 12 06:34:59 lemurBSD kernel: [18] iwlwifi0: base HW address: xx:xx:xx:xx:xx:xx
Dec 12 06:34:59 lemurBSD kernel: [18] ig4iic0: <Intel Comet Lake-LP I2C Controller-0> mem 0x9fc25000-0x9fc25fff irq 16 at device 21.0 on pci0
Dec 12 06:34:59 lemurBSD kernel: [18] ig4iic0: Using MSI
Dec 12 06:34:59 lemurBSD kernel: [18] iicbus8: <Philips I2C bus (ACPI-hinted)> on ig4iic0
Dec 12 06:34:59 lemurBSD kernel: [18] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:34:59 lemurBSD kernel: [18] fbd0 on drmn0
Dec 12 06:34:59 lemurBSD kernel: [18] device_attach: fbd0 attach returned 6
Dec 12 06:34:59 lemurBSD kernel: [18] lkpi_iic8: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [18] iicbus9: <Philips I2C bus> on lkpi_iic8
Dec 12 06:34:59 lemurBSD kernel: [18] iic8: <I2C generic I/O> on iicbus9
Dec 12 06:34:59 lemurBSD kernel: [18] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:34:59 lemurBSD kernel: [18] fbd0 on drmn0
Dec 12 06:34:59 lemurBSD kernel: [18] device_attach: fbd0 attach returned 6
Dec 12 06:34:59 lemurBSD kernel: [18] lkpi_iic9: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [18] iicbus10: <Philips I2C bus> on lkpi_iic9
Dec 12 06:34:59 lemurBSD kernel: [18] iic9: <I2C generic I/O> on iicbus10
Dec 12 06:34:59 lemurBSD kernel: [18] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:34:59 lemurBSD kernel: [19] iicbus8: <unknown card> at addr 0x15
Dec 12 06:34:59 lemurBSD kernel: [19] iic10: <I2C generic I/O> on iicbus8
Dec 12 06:34:59 lemurBSD kernel: [19] ig4iic1: <Intel Comet Lake-LP I2C Controller-4> at device 25.0 on pci0
Dec 12 06:34:59 lemurBSD kernel: [19] ig4iic1: Using MSI
Dec 12 06:34:59 lemurBSD kernel: [19] iicbus11: <Philips I2C bus (ACPI-hinted)> on ig4iic1
Dec 12 06:34:59 lemurBSD kernel: [20] iic11: <I2C generic I/O> on iicbus11
Dec 12 06:34:59 lemurBSD kernel: [20] ichsmb0: <Intel Comet Lake SMBus controller> port 0xefa0-0xefbf mem 0x9fc28000-0x9fc280ff irq 16 at device 31.4 on pci0
Dec 12 06:34:59 lemurBSD kernel: [20] smbus0: <System Management Bus> on ichsmb0
Dec 12 06:34:59 lemurBSD kernel: [20] rtsx0: <2.1g Realtek RTS522A PCIe SD Card Reader> mem 0x9f800000-0x9f800fff irq 17 at device 0.0 on pci1
Dec 12 06:34:59 lemurBSD kernel: [20] rtsx0: No card is detected
Dec 12 06:34:59 lemurBSD kernel: [21] drmn0: [drm] *ERROR* Failed to get ACT after 3000ms, last status: 00
Dec 12 06:34:59 lemurBSD kernel: [22] wlan1: Ethernet address: xx:xx:xx:xx:xx:xx
Dec 12 06:34:59 lemurBSD kernel: [22] ue0: link state changed to UP
Dec 12 06:34:59 lemurBSD kernel: [22] lo1: changing name to 'bastille0'
Dec 12 06:34:59 lemurBSD kernel: [22] lo0: link state changed to UP
Dec 12 06:34:59 lemurBSD kernel: [22] ue0: link state changed to DOWN
Dec 12 06:34:59 lemurBSD kernel: [22] lagg0: link state changed to DOWN
Dec 12 06:34:59 lemurBSD kernel: [23] ums0 on uhub4
Dec 12 06:34:59 lemurBSD kernel: [23] ums0: <Logitech USB Receiver, class 0/0, rev 2.00/12.10, addr 5> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [23] ums0: 16 buttons and [XYZT] coordinates ID=2
Dec 12 06:34:59 lemurBSD kernel: [23] uhid0 on uhub4
Dec 12 06:34:59 lemurBSD kernel: [23] uhid0: <Logitech USB Receiver, class 0/0, rev 2.00/12.10, addr 5> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [23] ums1 on uhub4
Dec 12 06:34:59 lemurBSD kernel: [23] ums1: <Blueskin Design Ltd dmk20, class 0/0, rev 1.10/0.01, addr 7> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [23] ums1: 5 buttons and [XYZT] coordinates ID=2
Dec 12 06:34:59 lemurBSD kernel: [23] uhid1 on uhub3
Dec 12 06:34:59 lemurBSD kernel: [23] uhid1: <Logitech Inc. Logi USB Headset H340, class 0/0, rev 2.00/1.17, addr 8> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [24] uhid2 on uhub2
Dec 12 06:34:59 lemurBSD kernel: [24] uhid2: <vendor 0x413c Dell dock, class 0/0, rev 2.01/1.01, addr 10> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [24] uhid3 on uhub1
Dec 12 06:34:59 lemurBSD kernel: [24] uhid3: <vendor 0x413c Dell dock, class 0/0, rev 2.01/1.01, addr 11> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [24] uhid4 on uhub5
Dec 12 06:34:59 lemurBSD kernel: [24] uhid4: <vendor 0x046d Logitech StreamCam, class 239/2, rev 3.20/3.17, addr 15> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio0 on uhub3
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio0: <Logitech Inc. Logi USB Headset H340, class 0/0, rev 2.00/1.17, addr 8> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio0: Play[0]: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer. (selected)
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio0: Record[0]: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer. (selected)
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio0: No MIDI sequencer.
Dec 12 06:34:59 lemurBSD kernel: [24] pcm2 on uaudio0
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio0: HID volume keys found.
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio1 on uhub2
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio1: <Generic USB Audio, class 0/0, rev 2.00/0.01, addr 9> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio1: Play[0]: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x4ms buffer. (selected)
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio1: Play[1]: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x4ms buffer. (selected)
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio1: Record[0]: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x4ms buffer. (selected)
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio1: No MIDI sequencer.
Dec 12 06:34:59 lemurBSD kernel: [24] pcm3 on uaudio1
Dec 12 06:34:59 lemurBSD kernel: [24] pcm4 on uaudio1
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio1: No HID volume keys found.
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2 on uhub5
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2: <vendor 0x046d Logitech StreamCam, class 239/2, rev 3.20/3.17, addr 15> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2: No playback.
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2: Record[0]: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer. (selected)
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2: Record[0]: 32000 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer.
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2: Record[0]: 24000 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer.
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2: Record[0]: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer.
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2: No MIDI sequencer.
Dec 12 06:34:59 lemurBSD kernel: [24] pcm5 on uaudio2
Dec 12 06:34:59 lemurBSD kernel: [24] uaudio2: No HID volume keys found.
Dec 12 06:34:59 lemurBSD kernel: [24] ubt0 on uhub0
Dec 12 06:34:59 lemurBSD kernel: [24] ubt0: <vendor 0x8087 product 0x0aaa, class 224/1, rev 2.00/0.02, addr 13> on usbus0
Dec 12 06:34:59 lemurBSD kernel: [24] drmn0: [drm] *ERROR* Failed to get ACT after 3000ms, last status: 00
Dec 12 06:34:59 lemurBSD kernel: [24] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:34:59 lemurBSD kernel: [25] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:34:59 lemurBSD kernel: [25] fbd0 on drmn0
Dec 12 06:34:59 lemurBSD kernel: [25] device_attach: fbd0 attach returned 6
Dec 12 06:34:59 lemurBSD kernel: [25] lkpi_iic10: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [25] iicbus12: <Philips I2C bus> on lkpi_iic10
Dec 12 06:34:59 lemurBSD kernel: [25] iic12: <I2C generic I/O> on iicbus12
Dec 12 06:34:59 lemurBSD kernel: [25] fbd0 on drmn0
Dec 12 06:34:59 lemurBSD kernel: [25] device_attach: fbd0 attach returned 6
Dec 12 06:34:59 lemurBSD kernel: [25] lkpi_iic11: <LinuxKPI I2C> on drmn0
Dec 12 06:34:59 lemurBSD kernel: [25] iicbus13: <Philips I2C bus> on lkpi_iic11
Dec 12 06:34:59 lemurBSD kernel: [25] iic13: <I2C generic I/O> on iicbus13
Dec 12 06:34:59 lemurBSD kernel: [25] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:34:59 lemurBSD kernel: [25] wlan1: link state changed to UP
Dec 12 06:34:59 lemurBSD kernel: [25] lagg0: link state changed to UP
Dec 12 06:34:59 lemurBSD kernel: [25] iichid0: <ELAN040D:00 04F3:311D I2C HID device> at addr 0x15 irq 51 on iicbus8
Dec 12 06:34:59 lemurBSD kernel: [25] hidbus0: <HID bus> on iichid0
Dec 12 06:34:59 lemurBSD kernel: [26] hms0: <ELAN040D:00 04F3:311D Mouse> on hidbus0
Dec 12 06:34:59 lemurBSD kernel: [26] hms0: 2 buttons and [XY] coordinates ID=1
Dec 12 06:34:59 lemurBSD kernel: [26] hmt0: <ELAN040D:00 04F3:311D TouchPad> on hidbus0
Dec 12 06:34:59 lemurBSD kernel: [26] hconf0: <ELAN040D:00 04F3:311D Configuration> on hidbus0
Dec 12 06:34:59 lemurBSD kernel: [26] hmt0: Multitouch touchpad with 0 external buttons, click-pad
Dec 12 06:34:59 lemurBSD kernel: [26] hmt0: 5 contacts with [C] properties. Report range [0:0] - [3204:1945]
Dec 12 06:34:59 lemurBSD kernel: [26] pflog0: promiscuous mode enabled
Dec 12 06:34:59 lemurBSD kernel: [26] ue0: link state changed to UP
Dec 12 06:34:59 lemurBSD kernel: [27] bridge0: Ethernet address: xx:xx:xx:xx:xx:xx
Dec 12 06:34:59 lemurBSD kernel: [27] bridge0: changing name to 'vm-public'
Dec 12 06:34:59 lemurBSD kernel:  good
Dec 12 06:34:59 lemurBSD kernel: [28] tun0: link state changed to UP
Dec 12 06:34:59 lemurBSD kernel: [28] tun0: changing name to 'tailscale0'
Dec 12 06:35:02 lemurBSD kernel: [28] drmn0: [drm] *ERROR* Failed to get ACT after 3000ms, last status: 00
Dec 12 06:35:03 lemurBSD kernel: [31] drmn0: [drm] *ERROR* Failed to get ACT after 3000ms, last status: 00
Dec 12 06:35:03 lemurBSD kernel: [31] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:35:03 lemurBSD kernel: [31] fbd0 on drmn0
Dec 12 06:35:03 lemurBSD kernel: [31] device_attach: fbd0 attach returned 6
Dec 12 06:35:03 lemurBSD kernel: [31] lkpi_iic12: <LinuxKPI I2C> on drmn0
Dec 12 06:35:03 lemurBSD kernel: [31] iicbus14: <Philips I2C bus> on lkpi_iic12
Dec 12 06:35:03 lemurBSD kernel: [31] iic14: <I2C generic I/O> on iicbus14
Dec 12 06:35:03 lemurBSD kernel: [31] fbd0 on drmn0
Dec 12 06:35:03 lemurBSD kernel: [31] device_attach: fbd0 attach returned 6
Dec 12 06:35:03 lemurBSD kernel: [31] lkpi_iic13: <LinuxKPI I2C> on drmn0
Dec 12 06:35:03 lemurBSD kernel: [31] iicbus15: <Philips I2C bus> on lkpi_iic13
Dec 12 06:35:03 lemurBSD kernel: [31] iic15: <I2C generic I/O> on iicbus15
Dec 12 06:35:03 lemurBSD kernel: [31] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 06:35:07 lemurBSD kernel: .
Dec 12 06:35:07 lemurBSD kernel: .
Dec 12 06:35:07 lemurBSD kernel: [37] Security policy loaded: MAC/ntpd (mac_ntpd)
Dec 12 06:48:58 lemurBSD kernel: [859] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 07:28:44 lemurBSD kernel: [3251] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 07:40:00 lemurBSD kernel: [3925] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 08:22:56 lemurBSD kernel: [6506] ue0: link state changed to DOWN
Dec 12 08:22:56 lemurBSD kernel: [6506] ue0: link state changed to UP
Dec 12 08:37:56 lemurBSD kernel: [7406] ue0: link state changed to DOWN
Dec 12 08:37:56 lemurBSD kernel: [7406] ue0: link state changed to UP
Dec 12 12:16:17 lemurBSD kernel: [20507] ue0: link state changed to DOWN
Dec 12 12:16:17 lemurBSD kernel: [20507] ue0: link state changed to UP
Dec 12 13:23:37 lemurBSD kernel: [24547] ue0: link state changed to DOWN
Dec 12 13:23:37 lemurBSD kernel: [24547] ue0: link state changed to UP
Dec 12 16:39:37 lemurBSD kernel: [36307] ue0: link state changed to DOWN
Dec 12 16:39:37 lemurBSD kernel: [36307] ue0: link state changed to UP
Dec 12 17:54:59 lemurBSD kernel: [40823] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 18:18:21 lemurBSD kernel: [42231] pid 62670 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 12 19:03:30 lemurBSD kernel: [44938] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 21:07:47 lemurBSD kernel: [52395] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 21:10:47 lemurBSD kernel: [52571] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 21:30:48 lemurBSD kernel: [53770] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 21:51:49 lemurBSD kernel: [55038] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 12 22:14:43 lemurBSD kernel: [56413] pid 99159 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 12 22:17:28 lemurBSD kernel: [56578] pid 314 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 12 22:17:37 lemurBSD kernel: [56587] pid 492 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 12 22:19:03 lemurBSD kernel: [56673] pid 884 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 12 22:21:02 lemurBSD kernel: [56792] pid 1569 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 12 22:23:51 lemurBSD kernel: [56961] pid 2849 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 12 22:24:10 lemurBSD kernel: [56980] pid 2971 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 13 06:15:32 lemurBSD kernel: [85259] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 13 06:35:36 lemurBSD kernel: [86438] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 13 20:02:16 lemurBSD kernel: [134863] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 13 21:02:37 lemurBSD kernel: [138473] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 13 21:30:46 lemurBSD kernel: [140176] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 13 21:30:46 lemurBSD kernel: [140176] ugen0.15: <Dell Inc. Dell dock> at usbus0 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub5: at uhub0, port 14, addr 14 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] ugen0.16: <vendor 0x046d Logitech StreamCam> at usbus0 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] uaudio2: at uhub5, port 2, addr 15 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] pcm5: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] uaudio2: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] uhid4: at uhub5, port 2, addr 15 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] uhid4: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] ugen0.17: <Dell Inc. Dell dock> at usbus0 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub6: at uhub5, port 3, addr 16 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] ugen0.18: <VIA Labs, Inc. USB3.0 Hub> at usbus0 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub7: at uhub6, port 2, addr 17 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub7: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub6: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] ugen0.19: <Realtek USB 10/100/1000 LAN> at usbus0 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] ure0: at uhub5, port 4, addr 18 (disconnected)
Dec 13 21:30:46 lemurBSD kernel: [140176] wlan1: link state changed to DOWN
Dec 13 21:30:46 lemurBSD kernel: [140176] rgephy0: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] lagg0: link state changed to DOWN
Dec 13 21:30:46 lemurBSD kernel: [140176] miibus0: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] ure0: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub5: detached
Dec 13 21:30:46 lemurBSD kernel: [140176] ugen0.15: <Dell Inc. Dell dock> at usbus0
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub5 on uhub0
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub5: <Dell Inc. Dell dock, class 9/0, rev 3.10/1.47, addr 19> on usbus0
Dec 13 21:30:46 lemurBSD kernel: [140176] uhub5: 4 ports with 3 removable, self powered
Dec 13 21:30:47 lemurBSD kernel: [140177] ugen0.16: <vendor 0x046d Logitech StreamCam> at usbus0
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2 on uhub5
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2: <vendor 0x046d Logitech StreamCam, class 239/2, rev 3.20/3.17, addr 20> on usbus0
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2: No playback.
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2: Record[0]: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer. (selected)
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2: Record[0]: 32000 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer.
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2: Record[0]: 24000 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer.
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2: Record[0]: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x4ms buffer.
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2: No MIDI sequencer.
Dec 13 21:30:47 lemurBSD kernel: [140177] pcm5 on uaudio2
Dec 13 21:30:47 lemurBSD kernel: [140177] uaudio2: No HID volume keys found.
Dec 13 21:30:47 lemurBSD kernel: [140177] uhid4 on uhub5
Dec 13 21:30:47 lemurBSD kernel: [140177] uhid4: <vendor 0x046d Logitech StreamCam, class 239/2, rev 3.20/3.17, addr 20> on usbus0
Dec 13 21:30:47 lemurBSD kernel: [140177] ugen0.17: <Dell Inc. Dell dock> at usbus0
Dec 13 21:30:47 lemurBSD kernel: [140177] uhub6 on uhub5
Dec 13 21:30:47 lemurBSD kernel: [140177] uhub6: <Dell Inc. Dell dock, class 9/0, rev 3.10/1.21, addr 21> on usbus0
Dec 13 21:30:48 lemurBSD kernel: [140178] uhub6: 4 ports with 4 removable, self powered
Dec 13 21:30:48 lemurBSD kernel: [140178] ugen0.18: <VIA Labs, Inc. USB3.0 Hub> at usbus0
Dec 13 21:30:48 lemurBSD kernel: [140178] uhub7 on uhub6
Dec 13 21:30:48 lemurBSD kernel: [140178] uhub7: <VIA Labs, Inc. USB3.0 Hub, class 9/0, rev 3.00/90.81, addr 22> on usbus0
Dec 13 21:30:49 lemurBSD kernel: [140179] uhub7: 4 ports with 4 removable, self powered
Dec 13 21:30:50 lemurBSD kernel: [140180] ugen0.19: <Realtek USB 10/100/1000 LAN> at usbus0
Dec 13 21:30:50 lemurBSD kernel: [140180] ure0 on uhub5
Dec 13 21:30:50 lemurBSD kernel: [140180] ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 3.00/31.11, addr 23> on usbus0
Dec 13 21:30:50 lemurBSD kernel: [140180] miibus0: <MII bus> on ure0
Dec 13 21:30:50 lemurBSD kernel: [140180] rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
Dec 13 21:30:50 lemurBSD kernel: [140180] rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
Dec 13 21:30:50 lemurBSD kernel: [140180] ue0: <USB Ethernet> on ure0
Dec 13 21:30:50 lemurBSD kernel: [140180] ue0: Ethernet address: xx:xx:xx:xx:xx:xx
Dec 13 21:30:50 lemurBSD kernel: [140180] ue0: link state changed to DOWN
Dec 13 21:30:54 lemurBSD kernel: [140184] ue0: link state changed to UP
Dec 13 21:31:45 lemurBSD kernel: [140235] wlan1: link state changed to UP
Dec 13 21:31:45 lemurBSD kernel: [140235] lagg0: link state changed to UP
Dec 14 08:15:20 lemurBSD kernel: [178847] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 08:29:50 lemurBSD kernel: [179720] pid 72296 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 14 08:54:15 lemurBSD kernel: [181185] pid 77553 (cscope), jid 0, uid 1000: exited on signal 6 (core dumped)
Dec 14 10:04:32 lemurBSD kernel: [185400] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 11:40:57 lemurBSD kernel: [191185] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 13:19:55 lemurBSD kernel: [197123] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 14:39:09 lemurBSD kernel: [201875] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 17:37:10 lemurBSD kernel: [212555] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 18:08:42 lemurBSD kernel: [214450] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 18:08:42 lemurBSD kernel: [214450] drmn0: [drm] *ERROR* Link Training Unsuccessful
Dec 14 18:09:18 lemurBSD kernel: [214487] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 19:43:28 lemurBSD kernel: [220135] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 14 20:01:50 lemurBSD kernel: [221215] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 15 00:26:09 lemurBSD kernel: [237099] ue0: link state changed to DOWN
Dec 15 00:26:09 lemurBSD kernel: [237099] ue0: link state changed to UP
Dec 15 00:26:59 lemurBSD kernel: [237149] ue0: link state changed to DOWN
Dec 15 00:26:59 lemurBSD kernel: [237149] ue0: 3 link states coalesced
Dec 15 00:26:59 lemurBSD kernel: [237149] ue0: link state changed to UP
Dec 15 00:27:39 lemurBSD kernel: [237189] ue0: link state changed to DOWN
Dec 15 00:27:39 lemurBSD kernel: [237189] ue0: link state changed to UP
Dec 15 00:32:39 lemurBSD kernel: [237489] ue0: link state changed to DOWN
Dec 15 00:32:39 lemurBSD kernel: [237489] ue0: link state changed to UP
Dec 15 00:32:39 lemurBSD kernel: [237489] ue0: 2 link states coalesced
Dec 15 00:32:39 lemurBSD kernel: [237489] ue0: link state changed to UP
Dec 15 00:34:29 lemurBSD kernel: [237599] ue0: link state changed to DOWN
Dec 15 00:34:29 lemurBSD kernel: [237599] ue0: link state changed to UP
Dec 15 00:34:29 lemurBSD kernel: [237599] ue0: 2 link states coalesced
Dec 15 00:34:29 lemurBSD kernel: [237599] ue0: link state changed to UP
Dec 15 00:34:39 lemurBSD kernel: [237609] ue0: link state changed to DOWN
Dec 15 00:34:39 lemurBSD kernel: [237609] ue0: link state changed to UP
Dec 15 00:35:29 lemurBSD kernel: [237659] ue0: link state changed to DOWN
Dec 15 00:35:29 lemurBSD kernel: [237659] ue0: link state changed to UP
Dec 15 00:35:29 lemurBSD kernel: [237659] ue0: 2 link states coalesced
Dec 15 00:35:29 lemurBSD kernel: [237659] ue0: link state changed to UP
Dec 15 00:35:59 lemurBSD kernel: [237689] ue0: link state changed to DOWN
Dec 15 00:35:59 lemurBSD kernel: [237689] ue0: link state changed to UP
Dec 15 00:36:09 lemurBSD kernel: [237699] ue0: link state changed to DOWN
Dec 15 00:36:09 lemurBSD kernel: [237699] ue0: link state changed to UP
Dec 15 00:36:09 lemurBSD kernel: [237699] ue0: 2 link states coalesced
Dec 15 00:36:09 lemurBSD kernel: [237699] ue0: link state changed to UP
Dec 15 00:36:39 lemurBSD kernel: [237729] ue0: link state changed to DOWN
Dec 15 00:36:39 lemurBSD kernel: [237729] ue0: link state changed to UP
Dec 15 00:42:19 lemurBSD kernel: [238069] ue0: link state changed to DOWN
Dec 15 00:42:19 lemurBSD kernel: [238069] ue0: link state changed to UP
Dec 15 00:42:19 lemurBSD kernel: [238069] ue0: 2 link states coalesced
Dec 15 00:42:19 lemurBSD kernel: [238069] ue0: link state changed to UP
Dec 15 00:45:09 lemurBSD kernel: [238239] ue0: link state changed to DOWN
Dec 15 00:45:09 lemurBSD kernel: [238239] ue0: link state changed to UP
Dec 15 00:45:49 lemurBSD kernel: [238279] ue0: link state changed to DOWN
Dec 15 00:45:49 lemurBSD kernel: [238279] ue0: link state changed to UP
Dec 15 05:31:50 lemurBSD kernel: [255440] ue0: link state changed to DOWN
Dec 15 05:31:50 lemurBSD kernel: [255440] ue0: link state changed to UP
Dec 15 05:31:50 lemurBSD kernel: [255440] ue0: 2 link states coalesced
Dec 15 05:31:50 lemurBSD kernel: [255440] ue0: link state changed to UP
Dec 15 05:33:10 lemurBSD kernel: [255520] ue0: link state changed to DOWN
Dec 15 05:33:10 lemurBSD kernel: [255520] ue0: link state changed to UP
Dec 15 05:33:10 lemurBSD kernel: [255520] ue0: 2 link states coalesced
Dec 15 05:33:10 lemurBSD kernel: [255520] ue0: link state changed to UP
Dec 15 05:35:20 lemurBSD kernel: [255650] ue0: link state changed to DOWN
Dec 15 05:35:20 lemurBSD kernel: [255650] ue0: link state changed to UP
Dec 15 05:36:00 lemurBSD kernel: [255690] ue0: link state changed to DOWN
Dec 15 05:36:00 lemurBSD kernel: [255690] ue0: link state changed to UP
Dec 15 05:36:00 lemurBSD kernel: [255690] ue0: 2 link states coalesced
Dec 15 05:36:00 lemurBSD kernel: [255690] ue0: link state changed to UP
Dec 15 05:37:20 lemurBSD kernel: [255770] ue0: link state changed to DOWN
Dec 15 05:37:20 lemurBSD kernel: [255770] ue0: link state changed to UP
Dec 15 05:43:30 lemurBSD kernel: [256140] ue0: link state changed to DOWN
Dec 15 05:43:30 lemurBSD kernel: [256140] ue0: link state changed to UP
Dec 15 05:43:30 lemurBSD kernel: [256140] ue0: link state changed to DOWN
Dec 15 05:43:30 lemurBSD kernel: [256140] ue0: link state changed to UP
Dec 15 05:51:10 lemurBSD kernel: [256600] ue0: link state changed to DOWN
Dec 15 05:51:10 lemurBSD kernel: [256600] ue0: link state changed to UP
Dec 15 05:51:10 lemurBSD kernel: [256600] ue0: 2 link states coalesced
Dec 15 05:51:10 lemurBSD kernel: [256600] ue0: link state changed to UP
Dec 15 06:44:40 lemurBSD kernel: [259808] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 15 06:44:40 lemurBSD kernel: [259808] drmn0: [drm] *ERROR* Link Training Unsuccessful
Dec 15 06:48:45 lemurBSD kernel: [260055] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 15 06:50:01 lemurBSD kernel: [260131] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Dec 15 07:55:17 lemurBSD kernel: [264045] hdacc1: Unexpected unsolicited response with tag 63: ffffffff
Comment 54 ml 2024-12-22 07:00:51 UTC
(In reply to Ali Abdallah from comment #45)

I ditched the patch I was using and applied your latest patch to 14.1 and 14.2.
After brief testing, it seems to be working (better than the former), but, as this is a laptop and I'm not using USB LAN frequently, time will tell.
I'll get back if/when I encounter further problems.
Thanks a lot.
Comment 55 ml 2025-01-17 08:07:31 UTC
(In reply to ml from comment #54)

Alas, after more extensive testing, I still experience the troubles I had before (with the previous patch I had posted):
_ under moderate load, occasionally the network hangs;
_ ping shows "no buffer space available";
_ I have to unplug, replug, rerun dhcpclient.
Comment 56 Cy Schubert freebsd_committer freebsd_triage 2025-03-24 01:11:41 UTC
The patch does not resolve the issue with AX88179A connected to a Framework 13.
Comment 57 Cy Schubert freebsd_committer freebsd_triage 2025-03-24 03:36:12 UTC
The problem only occurs with axge(4), not ure(4). PR/267514 documents the axge(4) issue.