iSCSI issues after upgrading to 11.2 x64 RELEASE

[Kaya Saman]

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....


>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"


Kaya