So, the system semi hung again.... ctrl + alt + F(n) only thing that was
working. :-(
On 9/4/18 6:08 PM, Eugene Grosbein wrote:
04.09.2018 23:57, Ryan Moeller wrote:
The NIC's are Intel based using igb kernel driver:
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
I see your MTU is 9000, and as described by the other thread you linked to,
there are issues with 9k jumbo cluster allocation.
Some detailed notes are here, but the quick summary is: set MTU < 4096
https://gist.github.com/freqlabs/eba9b755f17a223260246becfbb150a1
Yes MTU 9000, though it seems the 9k issues are related to FreeBSD
only?? - my other OS's (OpenBSD and Linux based) seem to be able to
handle the setting fine as I haven't experienced any issues with them.
However, their driver implementation or handling of things maybe quite
different so I cannot form a direct comparison.
Taking your advice and reading through the link I reset the MTU to 4000
after the 'hang' mentioned above, so far no issues:
24652/3428/28080 mbufs in use (current/cache/total)
0/1358/1358/1525810 mbuf clusters in use (current/cache/total/max)
0/1081 mbuf+clusters out of packet secondary zone in use (current/cache)
24648/129/24777/762905 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/226045 9k jumbo clusters in use (current/cache/total/max)
0/0/0/127150 16k jumbo clusters in use (current/cache/total/max)
104755K/4089K/108844K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 sendfile syscalls
0 sendfile syscalls completed without I/O request
0 requests for I/O initiated by sendfile
0 pages read by sendfile as part of a request
0 pages were valid at time of a sendfile request
0 pages were requested for read ahead by applications
0 pages were read ahead by sendfile
0 times sendfile encountered an already busy page
0 requests for sfbufs denied
0 requests for sfbufs delayed
Can anyone suggest anything to stop my system from completely locking up and
becoming unresponsive?
At the moment I'm not sure if switching to 'Stable' or 'Current' branches is a
good solution?
The problem has been mitigated for a while on 12-CURRENT, so that might be
worth trying. Otherwise I’ve been hoping a committer will put this fix in
11-STABLE, but in the meantime you could manually apply the patch:
https://reviews.freebsd.org/D16534 <https://reviews.freebsd.org/D16534>
Intel NIC users also should be aware of chip hardware problems while dealing
with 9k MTU, like documented here:
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/i218-i219-ethernet-connection-spec-update.pdf
In short, Intel does not recommend MTU over 8500.
That's really interesting!
The card in the system is one of these 4 port ones:
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-controller-i350-datasheet.pdf
For now I'll keep the mtu at 4000 then when 12 becomes RELEASE, I'll try
cranking it up again to see if the problem has been fixed; however, I
set up a cron job to mail me the output of 'netstat -m' so I can keep
track of the mbufs though it's probably going to be more useful at full
whack - meaning 9k then now were it seems the issue has been temporarily
alleviated....
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[email protected]"
Kaya
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[email protected]"
