https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254147
--- Comment #8 from Kevin Bowling ---
(In reply to Eric Joyner from comment #7)
Per the datasheets the 10GbaseT phy is intel in x552 and x553. Both might use
the inphy CS4227 for a SFP+ cage. IIRC the issue you hinted at was for the
CS422
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254147
--- Comment #7 from Eric Joyner ---
(In reply to Kevin Bowling from comment #5)
I don't think so, I think the thermal problem was specifically just the X552
and the external 10Gbase-T PHY.
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254147
--- Comment #6 from Yif Swery ---
Kevin, are you asking if things are overheating?
This is our system in production that has the onboard X553
$ ipmitool sensor
CPU Temp | 54.000 | degrees C | ok
System Temp | 61.000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254147
Kevin Bowling changed:
What|Removed |Added
CC||kbowl...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254147
--- Comment #4 from Yif Swery ---
Thanks for the quick reply Robert.
Will give that a run command on the interface and start looking at moving to a
different NIC card entirely.
Also seeing a bunch of online threads about the X500's runnin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254147
--- Comment #3 from robert.ayrapet...@gmail.com ---
Just to follow-up, I don't have this server anymore, but my last reply to DC
technicians after they've completely replaced the whole server was:
UPD: so the issue has happened again right
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989
--- Comment #13 from Kevin Bowling ---
(In reply to e94pasch from comment #12)
Thanks, this actually looks ok in both cases and the fact that it is on Chelsio
eliminates a lot of other concerns one might have in the data path. I am
wonderi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989
--- Comment #12 from e94pa...@yahoo.com ---
Created attachment 227385
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=227385&action=edit
top with PSH flags shaper off
--
You are receiving this mail because:
You are the assignee f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989
--- Comment #11 from e94pa...@yahoo.com ---
Created attachment 227384
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=227384&action=edit
top with PSH flags shaper on
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254147
Yif Swery changed:
What|Removed |Added
CC||yiftach...@gmail.com
--- Comment #2 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989
--- Comment #10 from Kevin Bowling ---
(In reply to Franco Fichtner from comment #7)
We all have to work together somehow. I don't particularly care about the past
or downstream project business concerns as long as everyone is doing good w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254695
--- Comment #36 from Michael Tuexen ---
See review D31648 for a step towards making the LRO contracts with regard to
net epoch handling clear.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257989
--- Comment #9 from Kevin Bowling ---
(In reply to e94pasch from comment #8)
Thanks, can you do 'top -PSH' instead? I will explain my reasoning so you can
follow along. A stream is ordered and transcends the network stack on one
core. Th
On Sun, Aug 22, 2021 at 8:30 AM alfadev via freebsd-hackers
wrote:
>
> Hi, I successfully configured VXLAN tunnel between amd64 FreeBSD 11.2 to x64
> Linux
> But in FreeBSD 12.2 with below same configuration not works.
> So What is tHe problem with FreeBSD 12.2 is it bug or any other thing?
> Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254695
--- Comment #35 from Michael Tuexen ---
We need something along the lines of your proposed fix. However, the number of
entries/exist of the epoch should be kept minimal. So we might want to have the
author of the driver to have a look.
But
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254695
--- Comment #34 from Gordon Bergling ---
I think I have found a way to enable TCP BBR and RACK on Hyper-V again with the
following patch, which adds NET_EPOCH{ENTER,EXIT} calls around
hn_chan_rollup(), in which the panic is happening.
diff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256681
Zhenlei Huang changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
17 matches
Mail list logo
