https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281452
--- Comment #4 from Zhenlei Huang ---
@Mithun
It seems this has been fixed by Kristof via commit 43387b4e5740 (if: guard
against if_ioctl being NULL). The commit has been MFCed to stable/14 with
commit 9a8a26aefb36.
May you please have a
> On Sep 13, 2024, at 10:54 PM, Sad Clouds wrote:
>
> On Fri, 13 Sep 2024 08:08:02 -0400
> Mark Saad wrote:
>
>> Sad
>> Can you go back a bit you mentioned there is a RPi in the mix ? Some of
>> the raspberries have their nic usb attached under the covers . Which will
>> kill the total s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281452
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--- Comment #3 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281460
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--- Comment #2 fro
On Fri, 13 Sep 2024 08:08:02 -0400
Mark Saad wrote:
> Sad
>Can you go back a bit you mentioned there is a RPi in the mix ? Some of
> the raspberries have their nic usb attached under the covers . Which will
> kill the total speed of things.
>
> Can you cobble together a diagram of what y
On Fri, 13 Sep 2024 13:40:55 +
Mike Belanger wrote:
> Thank you for the response and for sharing your scenario.
>
> We’ve also hacked up the cgem and the ffec driver to support a shared
> mdio. That was not too difficult, but we have a new scenario where
> the mdio is now being shared betwee
Thank you for the response and for sharing your scenario.
We’ve also hacked up the cgem and the ffec driver to support a shared mdio.
That was not too difficult, but we have a new scenario where the mdio is now
being shared between two different devices that use different drivers (ffec and
eqos)
>
> On Sep 13, 2024, at 5:09 AM, Sad Clouds wrote:
>
> Tried both, kernel built with "options RSS" and the following
> in /boot/loader.conf
>
> net.isr.maxthreads=-1
> net.isr.bindthreads=1
> net.isr.dispatch=deferred
>
> Not sure if there are race conditions with these implementations, bu
Tried both, kernel built with "options RSS" and the following
in /boot/loader.conf
net.isr.maxthreads=-1
net.isr.bindthreads=1
net.isr.dispatch=deferred
Not sure if there are race conditions with these implementations, but
after a few short tests, the epair_task_0 got stuck 100% on CPU and
stayed
On Fri, 6 Sep 2024 18:03:39 +
Mike Belanger wrote:
> The following device tree specifies a shared mdio.
> The ffec driver uses miibus.
> When there is a shared mdio, one of the device instances will not be
> able to properly configure the PHY, as it needs to use the other
> devices resource t
I built new kernel with "options RSS" however TCP throughput performance
now decreased from 128 MiB/sec to 106 MiB/sec.
Looks like the problem has shifted from epair to netisr
PID USERNAMEPRI NICE SIZERES STATEC TIMEWCPU COMMAND
12 root-56- 0B 272K CPU3
11 matches
Mail list logo
