Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

[Stephen Hurd]

Ok, the review is updated with the EBR.  If you can update your tree to
r333466 or newer, apply the patch and retest, that would be great.  It
seems to be working here.

On Thu, May 10, 2018 at 2:29 PM, Harry Schmalzbauer 
wrote:

> Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 20:07 (localtime):
> > No need to test the latest revision unless/until you get a LOR or a
> > panic (both should be possible with the revision you currently have).
> > With the recent addition of a simple EBR API, mmacy@ is working on a
> > better solution.  If possible, it would be great to have you re-test it
> > once that is up.
>
>
> Since this literally brand new _haswell_ (DH87MC) box is waiting now for
> 3 years to replace my 10 years old core2duo, I'll keep it on the tinker
> bench...
>
> I'd have some "smbios0: SMBIOS checksum failed" and
> "[drm2:pid:hangcheck_hung]...GPU hung" issues to track/report, but since
> finding Xorg's secret about "MatchIsKeyboard" took me too much time,
> this is postponed.
>
> -harry
>



-- 
[image: Limelight Networks] 
Stephen Hurd* Principal Engineer*
EXPERIENCE FIRST.
+1 616 848 0643 <+1+616+848+0643>
www.limelight.com
[image: Facebook] [image:
LinkedIn] [image:
Twitter] 
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

if_em(4) carrier loss event not recognized with i217; while 82574 does recognize

[Harry Schmalzbauer]

 Hello,

if I pull the TP connection from my i217 Clarkville, HEAD still reports
media
1000Base-T status "active".

Doing the same with the other if_em(4) NIC in that box, a hartwell,
82574LM, the status correctly changes to "no carrier".

This is not iflib related, since it's reproducable with FreeBSD
11-stable (some months old).

Shall I file a PR?

-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259

Jonathan T. Looney  changed:

   What|Removed |Added

 Status|New |In Progress

--- Comment #12 from Jonathan T. Looney  ---
See D15019 and D15021. I think we're waiting for reviewers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259

--- Comment #11 from e...@free.fr ---
Hi,

Any news on this subject, please ?

Regards

Éric Masson

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

[Harry Schmalzbauer]

Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 20:07 (localtime):
> No need to test the latest revision unless/until you get a LOR or a
> panic (both should be possible with the revision you currently have). 
> With the recent addition of a simple EBR API, mmacy@ is working on a
> better solution.  If possible, it would be great to have you re-test it
> once that is up.


Since this literally brand new _haswell_ (DH87MC) box is waiting now for
3 years to replace my 10 years old core2duo, I'll keep it on the tinker
bench...

I'd have some "smbios0: SMBIOS checksum failed" and
"[drm2:pid:hangcheck_hung]...GPU hung" issues to track/report, but since
finding Xorg's secret about "MatchIsKeyboard" took me too much time,
this is postponed.

-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

[Stephen Hurd]

No need to test the latest revision unless/until you get a LOR or a panic
(both should be possible with the revision you currently have).  With the
recent addition of a simple EBR API, mmacy@ is working on a better
solution.  If possible, it would be great to have you re-test it once that
is up.

On Thu, May 10, 2018 at 2:02 PM, Harry Schmalzbauer 
wrote:

>  Bezüglich Harry Schmalzbauer's Nachricht vom 10.05.2018 19:54 (localtime):
> …
> > Please excuse that I'm not familar with the phabricator and just did
> > "raw diff download" after briefly flying over the comments.
> > According to st_mtime this was on May 9th, 08:14:02 UTC (10:14 local
> > (CEST) time).
> > No idea what timezone phabricator reports to me, most likely respecting
> > local time.  Which means latest revision was part of my test – but I'm
>
> Oh, I missed "pm".
> Phabricator reports Wed, May 9, 9:49 PM
>  as last revision, my
> download was from 10:14 _AM_...
> But if the web site was respecting local time zone, I guess it would
> respect local time format, so not PM, but 21:49...
> So I think it's most likely any UTC+>2 time, so the revision I tested
> was probably Diff 42294 .
>
> Just tell me if it was useful for you to test the latest revision again.
>
> -harry
>



-- 
[image: Limelight Networks] 
Stephen Hurd* Principal Engineer*
EXPERIENCE FIRST.
+1 616 848 0643 <+1+616+848+0643>
www.limelight.com
[image: Facebook] [image:
LinkedIn] [image:
Twitter] 
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

[Harry Schmalzbauer]

 Bezüglich Harry Schmalzbauer's Nachricht vom 10.05.2018 19:54 (localtime):
…
> Please excuse that I'm not familar with the phabricator and just did
> "raw diff download" after briefly flying over the comments.
> According to st_mtime this was on May 9th, 08:14:02 UTC (10:14 local
> (CEST) time).
> No idea what timezone phabricator reports to me, most likely respecting
> local time.  Which means latest revision was part of my test – but I'm

Oh, I missed "pm".
Phabricator reports Wed, May 9, 9:49 PM
 as last revision, my
download was from 10:14 _AM_...
But if the web site was respecting local time zone, I guess it would
respect local time format, so not PM, but 21:49...
So I think it's most likely any UTC+>2 time, so the revision I tested
was probably Diff 42294 .

Just tell me if it was useful for you to test the latest revision again.

-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

[Harry Schmalzbauer]

Bezüglich Stephen Hurd's Nachricht vom 08.05.2018 20:58 (localtime):
> Can you test the review here: https://reviews.freebsd.org/D15355
> 
> It looks like there are two different locks protecting the same data
> everywhere but in lagg_ioctl().  This is a rough first-pass, and there may
> be some lingering recursion and performance regressions with it.
> 
…
>> Sleeping on "e1000_delay" with the following non-sleepable locks held:
>> exclusive rm if_lagg rmlock (if_lagg rmlock) r = 0 (0xf80014228c08)
>> locked @ /usr/src/sys/net/if_lagg.c:1433
>> stack backtrace:
>> #0 0x80701113 at witness_debugger+0x73
>> #1 0x807024f1 at witness_warn+0x461
>> #2 0x806a42cc at _sleep+0x6c
>> #3 0x806a4b34 at pause_sbt+0x144
>> #4 0x80440e21 at e1000_write_phy_reg_mdic+0xf1
>> #5 0x804446bf at e1000_enable_phy_wakeup_reg_access_bm+0x2f
>> #6 0x80432e0a at e1000_update_mc_addr_list_pch2lan+0x3a
>> #7 0x8041408f at em_if_multi_set+0x1bf
>> #8 0x807bc02e at iflib_if_ioctl+0xfe
>> #9 0x82111a15 at lagg_ioctl+0x115
>> #10 0x807dd348 at inm_release_task+0x218
>> #11 0x806dea29 at gtaskqueue_run_locked+0x139
>> #12 0x806de7a8 at gtaskqueue_thread_loop+0x88
>> #13 0x80659d84 at fork_exit+0x84
>> #14 0x809b767e at fork_trampoline+0xe
>> Sleeping thread (tid 100017, pid 0) owns a non-sleepable lock
>> KDB: stack backtrace of thread 100017:
>> sched_switch() at sched_switch+0x945/frame 0xfe00750dc5d0
>> mi_switch() at mi_switch+0x18c/frame 0xfe00750dc600
>> sleepq_switch() at sleepq_switch+0x10d/frame 0xfe00750dc640
>> sleepq_timedwait() at sleepq_timedwait+0x50/frame 0xfe00750dc680
>> _sleep() at _sleep+0x307/frame 0xfe00750dc730
>> pause_sbt() at pause_sbt+0x144/frame 0xfe00750dc780
>> e1000_write_phy_reg_mdic() at e1000_write_phy_reg_mdic+0xf1/frame
>> 0xfe00750dc7c0
>> e1000_enable_phy_wakeup_reg_access_bm() at
>> e1000_enable_phy_wakeup_reg_access_bm+0x2f/frame 0xfe00750dc7e0
>> e1000_update_mc_addr_list_pch2lan() at
>> e1000_update_mc_addr_list_pch2lan+0x3a/frame 0xfe00750dc820
>> em_if_multi_set() at em_if_multi_set+0x1bf/frame 0xfe00750dc870
>> iflib_if_ioctl() at iflib_if_ioctl+0xfe/frame 0xfe00750dc8e0
>> lagg_ioctl() at lagg_ioctl+0x115/frame 0xfe00750dc990
>> inm_release_task() at inm_release_task+0x218/frame 0xfe00750dc9f0
>> gtaskqueue_run_locked() at gtaskqueue_run_locked+0x139/frame
>> 0xfe00750dca40
>> gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x88/frame
>> 0xfe00750dca70
>> fork_exit() at fork_exit+0x84/frame 0xfe00750dcab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe00750dcab0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> panic: sleeping thread
>> cpuid = 3
>> time = 1525794682
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe008fe180e0
>> vpanic() at vpanic+0x1a3/frame 0xfe008fe18140
>> panic() at panic+0x43/frame 0xfe008fe181a0
>> propagate_priority() at propagate_priority+0x335/frame 0xfe008fe181e0
>> turnstile_wait() at turnstile_wait+0x38d/frame 0xfe008fe18230
>> __mtx_lock_sleep() at __mtx_lock_sleep+0x1e1/frame 0xfe008fe182b0
>> __mtx_lock_flags() at __mtx_lock_flags+0xf9/frame 0xfe008fe18300
>> _rm_rlock() at _rm_rlock+0x280/frame 0xfe008fe18330
>> _rm_rlock_debug() at _rm_rlock_debug+0x14c/frame 0xfe008fe18380
>> lagg_transmit() at lagg_transmit+0x38/frame 0xfe008fe183f0
>> ether_output_frame() at ether_output_frame+0xaa/frame 0xfe008fe18420
>> ether_output() at ether_output+0x68b/frame 0xfe008fe184c0
>> arprequest() at arprequest+0x474/frame 0xfe008fe185c0
>> arp_ifinit() at arp_ifinit+0x58/frame 0xfe008fe18600
>> ether_ioctl() at ether_ioctl+0x1d1/frame 0xfe008fe18630
>> lagg_ioctl() at lagg_ioctl+0x602/frame 0xfe008fe186e0
>> in_control() at in_control+0x8f5/frame 0xfe008fe18780
>> ifioctl() at ifioctl+0x19c6/frame 0xfe008fe18850
>> kern_ioctl() at kern_ioctl+0x2b9/frame 0xfe008fe188b0
>> sys_ioctl() at sys_ioctl+0x168/frame 0xfe008fe18980
>> amd64_syscall() at amd64_syscall+0x2cc/frame 0xfe008fe18ab0
>> fast_syscall_common() at fast_syscall_common+0x101/frame
>> 0xfe008fe18ab0
>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004820ba, rsp =
>> 0x7fffe1c8, rbp = 0x7fffe210 ---
>> KDB: enter: panic

I can confirm that the D15355 version I tested eleminates that panic.
Also no LOR with em0+em1 as laggports.

From the kawela report:
> Bezüglich Kevin Bowling's Nachricht vom 08.05.2018 11:52 (localtime):
>> On Tue, May 8, 2018 at 2:43 AM, Harry Schmalzbauer
 wrote:
> …
>>> But if the simple iflib/hw-support test with kawela+hartwell helps I'm
>>> happy to do.
>>
>> At this point it would be helpful, we think e1000 is nearing pretty
>> good shape and I need to become familiar with any outstanding bugs.
>
> Here's the results for 

Re: NETGRAPH- bridge vlans using netgraph help

[Julian Elischer]

On 9/5/18 11:24 pm, Abdullah Tariq wrote:


a picture would do wonders to understand what he wants.


 Apologies for being AWOL
 Attaching an image link: https://ibb.co/nt1s4S


Ok so, it looks like there i a problem in concepts.
FreeBSD doesn't really know about tags inside the machine..

It only has the ability to make a separate interface that multiplexes 
(on output)
and demultiplexes (on input) packets going onto a single link by 
assigning/creating

a virtual sub-interface for each active vlan on that real interface.

(well that's 100% true, but it doesn't use the tags for anything real 
internally.)


If you add the tag for a packet coming in and then remove it as it 
goes out, what

is the point in having it?
FreeBSD does not have a vlan switch internally.

That is not to say that we can not MAKE one,
but the whole aim of FreeBSD's vlan support is to allow it to send 
packets out that are

tagged for different vlans depending on which 'sub interface'
the packet was routed to, not to send unmarked packets internally 
routed via

some mythical internal vlan switch.

iface0.1][iface0]--wire
      /
iface0.2]/

packets sent out via iface0.1 will appear on the wire with vlan1 headers
packates sent out through iface0.2 will appear on the wire with vlan2 
headers


Inside the system however the vlan headers have been stripped off. 
They DO still have some vlan

information tagged on them but it is not used generally.

I still don't fully understand the aim of the exercise.


Julian






On Tue, May 1, 2018 at 8:39 PM, Julian Elischer > wrote:


On 1/5/18 11:16 pm, Freddie Cash wrote:

On Tue, May 1, 2018 at 6:08 AM, Julian Elischer
>wrote:

On 1/5/18 2:08 am, Eugene Grosbein wrote:

01.05.2018 1:03, Freddie Cash wrote:

On Mon, Apr 30, 2018 at 10:59 AM, Eugene Grosbein

>>wrote:

     > What the OP is trying to do is have PC1 send
untagged packets to igb0 on FreeBSD which is
configured for tagged vlan 5.
     > Then bridge the packets to igb1 which is
also configured for tagged vlan 5.  Then send the
packets out, untagged, to PC2.

     Why would one want to "configure igb0 for
tagged vlan 5" when igb0 supposed to receive
untagged frames?
     This does not make any sense. One should just
bridge igb0 as is, without creation vlan on it and
problem's solved.

​Yes, agree.  What the OP wants to do can't be
done.  :)​

Perhaps, you missed a message from him when he states
that configuration style does no matter for him really.
So, what he wants can be done, just using different style.


a picture would do wonders to understand what he wants
​.


​A FreeBSD system with multiple NICs, with separate vlans
internally to separate untagged traffic between PCs.​

https://forums.freebsd.org/threads/bridge-with-vlans-not-working.65592/


​​https://forums.freebsd.org/attachments/capture-png.4744/



​https://forums.freebsd.org/threads/bridge-with-vlans-not-working.65592/#lg=post-385584=0



​The "easy" solution is to just bridge together the interfaces
you want to be part of the same "virtual lan", thus allowing
traffic between those stations only.  Want PC1 and PC2 to be
part of one vlan?  Then bridge together igb0 and igb1.  Want
PC3, connected to igb2, and PC4, connected to igb3, to be part
of a separate "virtual lan"?  Then create a separate bridge
between igb2 and igb3. No vlan tags required anywhere.


ok so does he want to have those vlans terminated at his box or
just pass them through?
and if they are untagged,  why is it being called a vlan?
untagged vlan is what we call "ethernet".

if it's untagged then only the internal state of the switches
decides which "virtual network" it is on..





But, the OP (in the forum thread and here) keeps getting hung
up on "needing" vlan tags on the NICs, trying to treat the
FreeBSD box like a switch with hybrid ports and PVIDs set on
the ports.

-- 
Freddie Cash

fjwc...@gmail.com 






___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net

RE: kernel: in6_delayed_cksum: delayed m_pullup

[Dries Michiels]

> -Original Message-
> From: Dries Michiels 
> Sent: donderdag 10 mei 2018 16:58
> To: 'Andrey V. Elsukov' ; freebsd-net@freebsd.org
> Subject: RE: kernel: in6_delayed_cksum: delayed m_pullup
> 
> > -Original Message-
> > From: Andrey V. Elsukov 
> > Sent: donderdag 10 mei 2018 16:34
> > To: Dries Michiels ;
> > freebsd-net@freebsd.org
> > Subject: Re: kernel: in6_delayed_cksum: delayed m_pullup
> >
> > On 10.05.2018 17:25, Andrey V. Elsukov wrote:
> > > On 29.04.2018 21:30, Dries Michiels wrote:
> > >> Dear mailing list,
> > >>
> > >> After upgrading my FreeBSD server from source from:
> > >> FreeBSD 11.1-STABLE (VADOS) #9 r331859: Sun Apr  1 12:09:18 CEST
> > >> 2018 to FreeBSD 11.2-PRERELEASE (VADOS) #10 r333091: Sun Apr 29
> > >> 16:48:44 CEST 2018
> > >>
> > >> My /var/log/messages is getting spammed by the following
> notice/error:
> > >> Apr 29 19:51:42 vados kernel: in6_delayed_cksum: delayed m_pullup,
> > >> m->len: 48 plen 68 off 56 csum_flags=400 Apr 29
> > >> 19:55:34 vados last message repeated 11 times Apr 29 20:11:56 vados
> > >> last message repeated 10 times Apr 29 20:12:42 vados last message
> > >> repeated 4 times
> > >>
> > >> Does anyone have a clue what this indicates?
> > >> I did not have this message on my older system (r331859).
> > >
> > > Do you use pf(4) or ipsec(4)?
> 
> I use IPFW as firewall. Due to log file spamming I had disabled ipv6.
> I will enable it again and check if error message is still present.
> If so I will try the patch you provided. Thanks in advance!
> > Also, can you try this patch?
> >
> > --
> > WBR, Andrey V. Elsukov

Ok error has returned:
May 10 17:31:39 vados kernel: in6_delayed_cksum: delayed m_pullup, m->len: 48 
plen 68 off 56 csum_flags=400
May 10 17:31:53 vados last message repeated 3 times

I'll apply the patch and rebuild from source to give an update later.

Dries


in6_delayed_cksum.diff
Description: Binary data
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Unrecognized Inifiniband HCA

[Justin Clift]

On 2018-05-10 10:21, Grzegorz Junka wrote:

On 08/05/2018 23:41, Justin Clift wrote:


That's probably a ConnectX (series 1) Mellanox card.  Those can 
operate in

either Infiniband mode, or Ethernet mode.

Which mode are you wanting it to run in? :)

As a thought, the FreeBSD wiki page has a bit of info:

  https://wiki.freebsd.org/InfiniBand

For that card to be recognised at all, it'll need the mlx4 driver(s) 
to load.


I don't remember the exact one off hand (it's been a while), but some 
searching

online for mlx4 and FreeBSD should turn up the right bits.


Many thanks Justin. This is the first time I am hearing about an
Infiniband card operating in Ethernet mode. These cards come with two
CX4/SFF 8470 ports. It's not possible to connect standard Ethernet
cables that I know of (not even SFP modules). Do you mean that they
can operate in Ethernet mode over the CX4 cable?


Yep. :)

Back in the day when these cards were current tech, CX4 was an 
acceptable

connector for 10GbE.  The Infiniband switches from that era (that I had
access to) were mostly Infiniband only though.

But 10GbE CX4 switches did exist, and can still be found reasonably 
cheaply

on Ebay.  eg:

  * HP ProCurve 6 port CX4 10GBe switch
https://www.ebay.com/itm/152232294328

  * HP ProCurve 48 port 1GbE switch, with 2x 10GbE CX4 ports on the back
https://www.ebay.com/itm/281899832599

One of the good things about those HP ProCurve switches... being 
enterprise

gear they just keep working.  For Years.

From memory, HP still releases firmware security updates for them (for
free) to this day. Unlike (say) Cisco. ;)

Note - As a data point, FreeNAS (based on FreeBSD) includes the 10/40GbE 
driver

for these cards by default.  With FreeNAS they work as 10GbE "out of the
box". :D

Hopefully that helps. :)

+ Justin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 228108] if_ipsec drops all the icmp v4 error messages

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108

--- Comment #2 from bugs.freebsd@mx.zzux.com ---
And why ping is working ok?
ping -c 1 -S 192.168.233.1 192.168.233.2
PING 192.168.233.2 (192.168.233.2) from 192.168.233.1: 56 data bytes
64 bytes from 192.168.233.2: icmp_seq=0 ttl=64 time=0.410 ms

Is gif over if_ipsec the only reliable way to create encrypted ipv6 tunnel
without need of install extra software?
Pure ipv6 over if_ipsec is limited in use because of dropping 'packet_too_big'
messages.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kernel: in6_delayed_cksum: delayed m_pullup

[Alexander Zagrebin]

В Thu, 10 May 2018 16:56:38 +0200
"Dries Michiels"  пишет:

> I had updated the day after to see if it was just a regression but
> the error message was not gone: May  1 22:19:51 vados kernel:
> in6_delayed_cksum: delayed m_pullup, m->len: 48 plen 68 off 56
> csum_flags=400 May  1 22:27:57 vados last message
> repeated 29 times May  1 22:36:53 vados last message repeated 17
> times May  1 22:49:41 vados last message repeated 6 times May  1
> 23:00:09 vados last message repeated 8 times May  1 23:01:06 vados
> last message repeated 7 times May  1 23:18:05 vados last message
> repeated 12 times For this reason I had disabled IPV6 for my LAN
> clients (disabled rtadvd). My server was still ipv6 reachable and
> error messages where gone.

I've observed such messages when ipv6 packets was passed via ipv4 NAT.
After changing ipfw rule from (for example)
nat 1 ip from any to me in via re1
to
nat 1 ipv4 from any to me in via re1
this messages has gone.
 
-- 
Alexander Zagrebin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: kernel: in6_delayed_cksum: delayed m_pullup

[Dries Michiels]

> -Original Message-
> From: Andrey V. Elsukov 
> Sent: donderdag 10 mei 2018 16:34
> To: Dries Michiels ; freebsd-net@freebsd.org
> Subject: Re: kernel: in6_delayed_cksum: delayed m_pullup
> 
> On 10.05.2018 17:25, Andrey V. Elsukov wrote:
> > On 29.04.2018 21:30, Dries Michiels wrote:
> >> Dear mailing list,
> >>
> >> After upgrading my FreeBSD server from source from:
> >> FreeBSD 11.1-STABLE (VADOS) #9 r331859: Sun Apr  1 12:09:18 CEST 2018
> >> to FreeBSD 11.2-PRERELEASE (VADOS) #10 r333091: Sun Apr 29 16:48:44
> >> CEST 2018
> >>
> >> My /var/log/messages is getting spammed by the following notice/error:
> >> Apr 29 19:51:42 vados kernel: in6_delayed_cksum: delayed m_pullup,
> >> m->len: 48 plen 68 off 56 csum_flags=400 Apr 29
> >> 19:55:34 vados last message repeated 11 times Apr 29 20:11:56 vados
> >> last message repeated 10 times Apr 29 20:12:42 vados last message
> >> repeated 4 times
> >>
> >> Does anyone have a clue what this indicates?
> >> I did not have this message on my older system (r331859).
> >
> > Do you use pf(4) or ipsec(4)?

I use IPFW as firewall. Due to log file spamming I had disabled ipv6.
I will enable it again and check if error message is still present.
If so I will try the patch you provided. Thanks in advance!

> Also, can you try this patch?
> 
> --
> WBR, Andrey V. Elsukov

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: kernel: in6_delayed_cksum: delayed m_pullup

[Dries Michiels]

> -Original Message-
> From: Tom Jones 
> Sent: donderdag 10 mei 2018 15:48
> To: Dries Michiels 
> Cc: freebsd-net@freebsd.org
> Subject: Re: kernel: in6_delayed_cksum: delayed m_pullup
> 
> On Mon, Apr 30, 2018 at 09:54:48AM +0200, Dries Michiels wrote:
> >
> > Tom,
> >
> > I’m using the igb (intel I210) driver for my LAN interface and the em
> > (intel I219-V) driver for the WAN interface.  I use this FreeBSD box
> > as my home server so I wouldn’t say that it has a heavy ipv6 workload.
> >
> 
> Hi Dries,
> 
> Does this bug persist on later snapshots? Or have you stayed with the same
> one from the original question?

I had updated the day after to see if it was just a regression but the error 
message was not gone:
May  1 22:19:51 vados kernel: in6_delayed_cksum: delayed m_pullup, m->len: 48 
plen 68 off 56 csum_flags=400
May  1 22:27:57 vados last message repeated 29 times
May  1 22:36:53 vados last message repeated 17 times
May  1 22:49:41 vados last message repeated 6 times
May  1 23:00:09 vados last message repeated 8 times
May  1 23:01:06 vados last message repeated 7 times
May  1 23:18:05 vados last message repeated 12 times
For this reason I had disabled IPV6 for my LAN clients (disabled rtadvd).
My server was still ipv6 reachable and error messages where gone.

> Could you send me the ifconfig flags lines for igb0 and em0?
> 
> like this
> 
> $ ifconfig em0
> em0:
> flags=8943
> metric 0 mtu 1500
>   options=40098 AN_HWTSO>
> 
> $ ifconfig igb0
> igb0: flags=8843 metric 0
> mtu 1500
> 
> options=6403bb O_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM
> _IPV6>

ifconfig flags of my interfaces shown below.
em0: flags=8843 metric 0 mtu 1500
description: WAN

options=209b
igb0: flags=8843 metric 0 mtu 1500
description: LAN

options=6403bb

> My em interfaces don't have flags for ipv6 checksum offload, I suspect the
> issue is from the em side of your network.
> 
> I have tried moving 100GB of v6 tcp through each interface with iperf3 to see
> if I could stimulate the bug, but no luck so far. I will leave the test box 
> sitting
> exposed to my network for a while.
> 
> - [tj]

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kernel: in6_delayed_cksum: delayed m_pullup

[Andrey V. Elsukov]

On 10.05.2018 17:25, Andrey V. Elsukov wrote:
> On 29.04.2018 21:30, Dries Michiels wrote:
>> Dear mailing list,
>>
>> After upgrading my FreeBSD server from source from:
>> FreeBSD 11.1-STABLE (VADOS) #9 r331859: Sun Apr  1 12:09:18 CEST 2018 
>> to
>> FreeBSD 11.2-PRERELEASE (VADOS) #10 r333091: Sun Apr 29 16:48:44 CEST 2018
>>
>> My /var/log/messages is getting spammed by the following notice/error:
>> Apr 29 19:51:42 vados kernel: in6_delayed_cksum: delayed m_pullup, m->len: 
>> 48 plen 68 off 56 csum_flags=400
>> Apr 29 19:55:34 vados last message repeated 11 times
>> Apr 29 20:11:56 vados last message repeated 10 times
>> Apr 29 20:12:42 vados last message repeated 4 times
>>
>> Does anyone have a clue what this indicates?
>> I did not have this message on my older system (r331859).
> 
> Do you use pf(4) or ipsec(4)?

Also, can you try this patch?

-- 
WBR, Andrey V. Elsukov
Index: sys/netinet6/ip6_output.c
===
--- sys/netinet6/ip6_output.c	(revision 333456)
+++ sys/netinet6/ip6_output.c	(working copy)
@@ -199,18 +199,10 @@ in6_delayed_cksum(struct mbuf *m, uint32_t plen, u
 		csum = 0x;
 	offset += m->m_pkthdr.csum_data;	/* checksum offset */
 
-	if (offset + sizeof(u_short) > m->m_len) {
-		printf("%s: delayed m_pullup, m->len: %d plen %u off %u "
-		"csum_flags=%b\n", __func__, m->m_len, plen, offset,
-		(int)m->m_pkthdr.csum_flags, CSUM_BITS);
-		/*
-		 * XXX this should not happen, but if it does, the correct
-		 * behavior may be to insert the checksum in the appropriate
-		 * next mbuf in the chain.
-		 */
-		return;
-	}
-	*(u_short *)(m->m_data + offset) = csum;
+	if (offset + sizeof(csum) > m->m_len)
+		m_copyback(m, offset, sizeof(csum), );
+	else
+		*(u_short *)mtodo(m, offset) = csum;
 }
 
 int


signature.asc
Description: OpenPGP digital signature

Re: kernel: in6_delayed_cksum: delayed m_pullup

[Andrey V. Elsukov]

On 29.04.2018 21:30, Dries Michiels wrote:
> Dear mailing list,
> 
> After upgrading my FreeBSD server from source from:
> FreeBSD 11.1-STABLE (VADOS) #9 r331859: Sun Apr  1 12:09:18 CEST 2018 
> to
> FreeBSD 11.2-PRERELEASE (VADOS) #10 r333091: Sun Apr 29 16:48:44 CEST 2018
> 
> My /var/log/messages is getting spammed by the following notice/error:
> Apr 29 19:51:42 vados kernel: in6_delayed_cksum: delayed m_pullup, m->len: 48 
> plen 68 off 56 csum_flags=400
> Apr 29 19:55:34 vados last message repeated 11 times
> Apr 29 20:11:56 vados last message repeated 10 times
> Apr 29 20:12:42 vados last message repeated 4 times
> 
> Does anyone have a clue what this indicates?
> I did not have this message on my older system (r331859).

Do you use pf(4) or ipsec(4)?

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: kernel: in6_delayed_cksum: delayed m_pullup

[Tom Jones]

On Mon, Apr 30, 2018 at 09:54:48AM +0200, Dries Michiels wrote:
> 
> Tom,
> 
> I’m using the igb (intel I210) driver for my LAN interface and the em
> (intel I219-V) driver for the WAN interface.  I use this FreeBSD box
> as my home server so I wouldn’t say that it has a heavy ipv6 workload.
> 

Hi Dries,

Does this bug persist on later snapshots? Or have you stayed with the
same one from the original question?

Could you send me the ifconfig flags lines for igb0 and em0?

like this

$ ifconfig em0
em0: flags=8943 metric 0 mtu 
1500
options=40098

$ ifconfig igb0
igb0: flags=8843 metric 0 mtu 1500

options=6403bb
 


My em interfaces don't have flags for ipv6 checksum offload, I suspect
the issue is from the em side of your network. 

I have tried moving 100GB of v6 tcp through each interface with iperf3
to see if I could stimulate the bug, but no luck so far. I will leave
the test box sitting exposed to my network for a while.

- [tj]
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 228108] if_ipsec drops all the icmp v4 error messages

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108

Andrey V. Elsukov  changed:

   What|Removed |Added

 CC||a...@freebsd.org

--- Comment #1 from Andrey V. Elsukov  ---
This is because the ICMP/ICMPv6 input code does check that message was not
encrypted. If you apply IPsec transform to gif tunnel, I think you will get the
same result.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 228108] if_ipsec drops all the icmp v4 error messages

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Unrecognized Inifiniband HCA

[Gary Palmer]

On Thu, May 10, 2018 at 09:21:10AM +, Grzegorz Junka wrote:
> 
> On 08/05/2018 23:41, Justin Clift wrote:
> > On 2018-05-08 21:59, Grzegorz Junka wrote:
> >> Hi All,
> >>
> >> pciconf -lv
> >>
> >> gives me
> >>
> >> none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 
> >> chip=0x634015b3
> >> rev=0xa0 hdr=0x00
> >> ?? vendor = 'Mellanox Technologies'
> >> ?? device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]'
> >> ?? class?? = serial bus
> >>
> >> Does it mean that my card is unrecognized? It supposed to be 10GB x 2
> >> Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware.
> >> Currently the card doesn't show when doing ifconfig. What should I do
> >> to have the proper device name instead of none1 or for the card to
> >> appear in ifconfig?
> >>
> >> # kldstat
> >> Id Refs Address?? Size Name
> >> ??1 28 0x8020 1f67a88?? kernel
> >> ??2?? 1 0x82169000 316708 zfs.ko
> >> ??3?? 2 0x8248 cb78 opensolaris.ko
> >> ??4?? 1 0x8248d000 42c28?? mps.ko
> >> ??5?? 1 0x82621000 bdb0 if_lagg.ko
> >> ??6?? 1 0x8262d000 3650 ums.ko
> >> ??7?? 1 0x82631000 6679 nullfs.ko
> >> ??8?? 1 0x82638000 bdfe unionfs.ko
> >> ??9?? 2 0x82644000 2094f?? mlx5.ko
> >> 10?? 2 0x82665000 103e1?? linuxkpi.ko
> >> 11?? 1 0x82676000 15965?? mlx5en.ko
> >
> > That's probably a ConnectX (series 1) Mellanox card.?? Those can 
> > operate in
> > either Infiniband mode, or Ethernet mode.
> >
> > Which mode are you wanting it to run in? :)
> >
> > As a thought, the FreeBSD wiki page has a bit of info:
> >
> > ?? https://wiki.freebsd.org/InfiniBand
> >
> > For that card to be recognised at all, it'll need the mlx4 driver(s) 
> > to load.
> >
> > I don't remember the exact one off hand (it's been a while), but some 
> > searching
> > online for mlx4 and FreeBSD should turn up the right bits.
> 
> Many thanks Justin. This is the first time I am hearing about an 
> Infiniband card operating in Ethernet mode. These cards come with two 
> CX4/SFF 8470 ports. It's not possible to connect standard Ethernet 
> cables that I know of (not even SFP modules). Do you mean that they can 
> operate in Ethernet mode over the CX4 cable?

You can get CX4 to SFP+ cables, so I would assume so

Regards

Gary

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Missing mlx4, was Re: Unrecognized Inifiniband HCA

[Gary Palmer]

On Thu, May 10, 2018 at 08:36:44AM +, Grzegorz Junka wrote:
> 
> On 09/05/2018 00:39, Rodney W. Grimes wrote:
> >> On Tue, May 08, 2018 at 08:59:20PM +, Grzegorz Junka wrote:
> >>> Hi All,
> >>>
> >>> pciconf -lv
> >>>
> >>> gives me
> >>>
> >>> none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 
> >>> chip=0x634015b3
> >>> rev=0xa0 hdr=0x00
> >>>   ?? vendor = 'Mellanox Technologies'
> >>>   ?? device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]'
> >>>   ?? class?? = serial bus
> >>>
> >>> Does it mean that my card is unrecognized? It supposed to be 10GB x 2
> >>> Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware. Currently
> >>> the card doesn't show when doing ifconfig. What should I do to have the
> >>> proper device name instead of none1 or for the card to appear in ifconfig?
> >>>
> >>> # kldstat
> >>> Id Refs Address?? Size Name
> >>>   ??1 28 0x8020 1f67a88?? kernel
> >>>   ??2?? 1 0x82169000 316708 zfs.ko
> >>>   ??3?? 2 0x8248 cb78 opensolaris.ko
> >>>   ??4?? 1 0x8248d000 42c28?? mps.ko
> >>>   ??5?? 1 0x82621000 bdb0 if_lagg.ko
> >>>   ??6?? 1 0x8262d000 3650 ums.ko
> >>>   ??7?? 1 0x82631000 6679 nullfs.ko
> >>>   ??8?? 1 0x82638000 bdfe unionfs.ko
> >>>   ??9?? 2 0x82644000 2094f?? mlx5.ko
> >>> 10?? 2 0x82665000 103e1?? linuxkpi.ko
> >>> 11?? 1 0x82676000 15965?? mlx5en.ko
> >> mlx5en is for ConnectX-4.  I think that's an older card.  Try mlx4en,
> >> which supports ConnectX-2 and ConnectX-3.
> >  From a quick grep this infact should be supported by the mlx4/mlx5en
> > drivers:
> > net/mlx4/main.c:/* MT25408 "Hermon" SDR */
> > net/mlx4/main.c:/* MT25408 "Hermon" DDR */
> > net/mlx4/main.c:/* MT25408 "Hermon" QDR */
> > net/mlx4/main.c:/* MT25408 "Hermon" DDR PCIe gen2 */
> > net/mlx4/main.c:/* MT25408 "Hermon" QDR PCIe gen2 */
> > net/mlx4/main.c:/* MT25408 "Hermon" EN 10GigE */
> > net/mlx4/main.c:/* MT25408 "Hermon" EN 10GigE PCIe gen2 */
> >
> 
> Thank you Gary and Rod for your quick reply. I don't seem to have mlx4 
> in my /boot/kernel. I unloaded mlx5 and mlx5en and tried to load mlx 
> instead, but strangely, it says mlx is already loaded. How?
> 
> # kldload mlx
> kldload: can't load mlx: module already loaded or in kernel
> 
> # kldstat
> Id Refs Address?? Size Name
>  ??1 22 0x8020 1f67a88?? kernel
>  ??2?? 1 0x82169000 316708 zfs.ko
>  ??3?? 2 0x8248 cb78 opensolaris.ko
>  ??4?? 1 0x8248d000 42c28?? mps.ko
>  ??5?? 1 0x82621000 bdb0 if_lagg.ko
>  ??6?? 1 0x8262d000 3650 ums.ko
>  ??7?? 1 0x82631000 6679 nullfs.ko
>  ??8?? 1 0x82638000 bdfe unionfs.ko
> 
> # ls -l /boot/kernel/mlx
> mlx.ko*?? mlx5.ko* mlx5en.ko*
> 
> Anyways, mlx seems to be rather unrelated to this problem: 
> https://www.freebsd.org/cgi/man.cgi?query=mlx
> 
> Looks like mlx4 is available in the kernel: 
> https://github.com/freebsd/freebsd/tree/master/sys/modules/mlx4
> 
> However, it seems that it may not compile: 
> https://forums.freebsd.org/threads/mellanox-mt26448.64350/
> 
> Does it mean, that mlx4 is no longer compiled in the default kernel and 
> I would need to compile the kernel manually? Can I just compile the 
> mlx4/en/ib kernel module without having to compile the whole kernel?

You either need to put "options OFED" into your kernel and recompile
to get the mlx4 module, or go to /sys/modules/mlx4 and run
"make all install"

(more details on the wiki that someone else posted earlier)

Regards,

Gary
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Unrecognized Inifiniband HCA

[Grzegorz Junka]

On 08/05/2018 23:41, Justin Clift wrote:

On 2018-05-08 21:59, Grzegorz Junka wrote:

Hi All,

pciconf -lv

gives me

none1@pci0:3:0:0:   class=0x0c0600 card=0x000315b3 chip=0x634015b3
rev=0xa0 hdr=0x00
    vendor = 'Mellanox Technologies'
    device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]'
    class  = serial bus

Does it mean that my card is unrecognized? It supposed to be 10GB x 2
Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware.
Currently the card doesn't show when doing ifconfig. What should I do
to have the proper device name instead of none1 or for the card to
appear in ifconfig?

# kldstat
Id Refs Address    Size Name
 1   28 0x8020 1f67a88  kernel
 2    1 0x82169000 316708   zfs.ko
 3    2 0x8248 cb78 opensolaris.ko
 4    1 0x8248d000 42c28    mps.ko
 5    1 0x82621000 bdb0 if_lagg.ko
 6    1 0x8262d000 3650 ums.ko
 7    1 0x82631000 6679 nullfs.ko
 8    1 0x82638000 bdfe unionfs.ko
 9    2 0x82644000 2094f    mlx5.ko
10    2 0x82665000 103e1    linuxkpi.ko
11    1 0x82676000 15965    mlx5en.ko


That's probably a ConnectX (series 1) Mellanox card.  Those can 
operate in

either Infiniband mode, or Ethernet mode.

Which mode are you wanting it to run in? :)

As a thought, the FreeBSD wiki page has a bit of info:

  https://wiki.freebsd.org/InfiniBand

For that card to be recognised at all, it'll need the mlx4 driver(s) 
to load.


I don't remember the exact one off hand (it's been a while), but some 
searching

online for mlx4 and FreeBSD should turn up the right bits.


Many thanks Justin. This is the first time I am hearing about an 
Infiniband card operating in Ethernet mode. These cards come with two 
CX4/SFF 8470 ports. It's not possible to connect standard Ethernet 
cables that I know of (not even SFP modules). Do you mean that they can 
operate in Ethernet mode over the CX4 cable?

GrzegorzJ
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Missing mlx4, was Re: Unrecognized Inifiniband HCA

[Grzegorz Junka]

On 10/05/2018 09:06, Ben RUBSON wrote:

On 10 May 2018 10:36, Grzegorz Junka wrote:


Does it mean, that mlx4 is no longer compiled in the default kernel


It has never been, but I think modules have been added recently, I can 
remember HPS did it :)


Right, I meant that they are not being build as modules along with the 
default kernel, unlike mx5/en currently for example (which are available 
with the default FreeBSD installation) :)




Can I just compile the mlx4/en/ib kernel module without having to 
compile the whole kernel?


Yes, here are at least the instructions for FreeBSD 11.0 which could 
help you :

cd /usr/src/sys/modules/mlx4
make
make install
make clean
cd /usr/src/sys/modules/mlxen
make
make install
make clean



That looks easy, will give it a try. Thanks!
GrzegorzJ

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Missing mlx4, was Re: Unrecognized Inifiniband HCA

[Ben RUBSON]

On 10 May 2018 10:36, Grzegorz Junka wrote:


Does it mean, that mlx4 is no longer compiled in the default kernel


It has never been, but I think modules have been added recently, I can  
remember HPS did it :)


Can I just compile the mlx4/en/ib kernel module without having to compile  
the whole kernel?


Yes, here are at least the instructions for FreeBSD 11.0 which could help  
you :

cd /usr/src/sys/modules/mlx4
make
make install
make clean
cd /usr/src/sys/modules/mlxen
make
make install
make clean

Ben
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Missing mlx4, was Re: Unrecognized Inifiniband HCA

[Grzegorz Junka]

On 09/05/2018 00:39, Rodney W. Grimes wrote:

On Tue, May 08, 2018 at 08:59:20PM +, Grzegorz Junka wrote:

Hi All,

pciconf -lv

gives me

none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 chip=0x634015b3
rev=0xa0 hdr=0x00
  ?? vendor = 'Mellanox Technologies'
  ?? device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]'
  ?? class?? = serial bus

Does it mean that my card is unrecognized? It supposed to be 10GB x 2
Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware. Currently
the card doesn't show when doing ifconfig. What should I do to have the
proper device name instead of none1 or for the card to appear in ifconfig?

# kldstat
Id Refs Address?? Size Name
  ??1 28 0x8020 1f67a88?? kernel
  ??2?? 1 0x82169000 316708 zfs.ko
  ??3?? 2 0x8248 cb78 opensolaris.ko
  ??4?? 1 0x8248d000 42c28?? mps.ko
  ??5?? 1 0x82621000 bdb0 if_lagg.ko
  ??6?? 1 0x8262d000 3650 ums.ko
  ??7?? 1 0x82631000 6679 nullfs.ko
  ??8?? 1 0x82638000 bdfe unionfs.ko
  ??9?? 2 0x82644000 2094f?? mlx5.ko
10?? 2 0x82665000 103e1?? linuxkpi.ko
11?? 1 0x82676000 15965?? mlx5en.ko

mlx5en is for ConnectX-4.  I think that's an older card.  Try mlx4en,
which supports ConnectX-2 and ConnectX-3.

 From a quick grep this infact should be supported by the mlx4/mlx5en
drivers:
net/mlx4/main.c:/* MT25408 "Hermon" SDR */
net/mlx4/main.c:/* MT25408 "Hermon" DDR */
net/mlx4/main.c:/* MT25408 "Hermon" QDR */
net/mlx4/main.c:/* MT25408 "Hermon" DDR PCIe gen2 */
net/mlx4/main.c:/* MT25408 "Hermon" QDR PCIe gen2 */
net/mlx4/main.c:/* MT25408 "Hermon" EN 10GigE */
net/mlx4/main.c:/* MT25408 "Hermon" EN 10GigE PCIe gen2 */



Thank you Gary and Rod for your quick reply. I don't seem to have mlx4 
in my /boot/kernel. I unloaded mlx5 and mlx5en and tried to load mlx 
instead, but strangely, it says mlx is already loaded. How?


# kldload mlx
kldload: can't load mlx: module already loaded or in kernel

# kldstat
Id Refs Address    Size Name
 1   22 0x8020 1f67a88  kernel
 2    1 0x82169000 316708   zfs.ko
 3    2 0x8248 cb78 opensolaris.ko
 4    1 0x8248d000 42c28    mps.ko
 5    1 0x82621000 bdb0 if_lagg.ko
 6    1 0x8262d000 3650 ums.ko
 7    1 0x82631000 6679 nullfs.ko
 8    1 0x82638000 bdfe unionfs.ko

# ls -l /boot/kernel/mlx
mlx.ko*    mlx5.ko*   mlx5en.ko*

Anyways, mlx seems to be rather unrelated to this problem: 
https://www.freebsd.org/cgi/man.cgi?query=mlx


Looks like mlx4 is available in the kernel: 
https://github.com/freebsd/freebsd/tree/master/sys/modules/mlx4


However, it seems that it may not compile: 
https://forums.freebsd.org/threads/mellanox-mt26448.64350/


Does it mean, that mlx4 is no longer compiled in the default kernel and 
I would need to compile the kernel manually? Can I just compile the 
mlx4/en/ib kernel module without having to compile the whole kernel?


Thanks
GrzegorzJ

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"