NetBSD Problem Report #55822

From kiers@shell.boppelans.net  Tue Nov 24 16:13:36 2020
Return-Path: <kiers@shell.boppelans.net>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 0BE2D1A921F
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 24 Nov 2020 16:13:36 +0000 (UTC)
Message-Id: <20201124161535.B0FCAD3855@shell.boppelans.net>
Date: Tue, 24 Nov 2020 17:15:35 +0100 (CET)
From: kiers@original.xs4all.nl
Reply-To: kiers@original.xs4all.nl
To: gnats-bugs@NetBSD.org
Subject: kernel panic in iavf0 attach
X-Send-Pr-Version: 3.95

>Number:         55822
>Category:       kern
>Synopsis:       iavf0 attach: panic: kernel diagnostic assertion "!(pg->flags & PG_FREE)" failed: file "/home/kiers/git/NetBSD-current/src/sys/uvm/uvm_page.c", line 1449
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yamaguchi
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 24 16:15:00 +0000 2020
>Last-Modified:  Wed Dec 02 13:25:01 +0000 2020
>Originator:     kiers@original.xs4all.nl
>Release:        NetBSD 9.99.75 (GENERIC) #0: Mon Nov 23 18:10:03 CET 2020
>Organization:

>Environment:
Host is Freebsd 12.2 with X710 and X722 NICS, NetBSD-current in Bhyve


System: NetBSD 9.99.75 (GENERIC) #0: Mon Nov 23 18:10:03 CET 2020 kiers@esmeralda5:/tmp/obj/obj10592/sys/arch/amd64/compile/GENERIC
Architecture: x86_64
Machine: amd64
>Description:
	I have a FreeBSD 12.2 host with X710 and X722 NICs.  I try to pass one of them trough
	to a NetBSD 9.99.75 guest.  The kernel panics during iavf0 probing:

[   1.0342967] iavf0 at pci0 dev 2 function 0:unable to get VF interface version
[   1.0342967] panic: kernel diagnostic assertion "!(pg->flags & PG_FREE)" failed: file "/home/kiers/git/NetBSD-current/src/sys/uvm/uvm_page.c", line 1449 
[   1.0342967] cpu0: Begin traceback...
[   1.0342967] vpanic() at netbsd:vpanic+0x156
[   1.0342967] __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax
[   1.0342967] uvm_pagefree() at netbsd:uvm_pagefree+0x657
[   1.0342967] uvm_pglistfree() at netbsd:uvm_pglistfree+0x6b
[   1.0342967] _bus_dmamem_free.isra.0() at netbsd:_bus_dmamem_free.isra.0+0x8d
[   1.0342967] iavf_aqb_free() at netbsd:iavf_aqb_free+0x3b
[   1.0342967] iavf_attach() at netbsd:iavf_attach+0x3b1
[   1.0342967] config_attach_loc() at netbsd:config_attach_loc+0x182
[   1.0342967] pci_probe_device() at netbsd:pci_probe_device+0x585

...a lot more lines...

cpu_configure() at netbsd:cpu_configure+0x38
main() at netbsd:main+0x32c
ds          3840
es          37f0
fs          3830
gs          10
rdi         8
rsi         3f8
rbp         ffffffff81c23830
rbx         107e3c000
rdx         1
rcx         8
rax         1
r8          107e3c000
r9          53bb7
r10         1
r11         fffffffe
r12         104
r13         ffffffff813451f8    ostype+0xa88
r14         ffffffff81c23878
r15         ffffab9f3e512000
rip         ffffffff80221a25    breakpoint+0x5
cs          8
rflags      202
rsp         ffffffff81c23830
ss          10
netbsd:breakpoint+0x5:  leave
db{0}> bt
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x156
__x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax
uvm_pagefree() at netbsd:uvm_pagefree+0x657
uvm_pglistfree() at netbsd:uvm_pglistfree+0x6b
_bus_dmamem_free.isra.0() at netbsd:_bus_dmamem_free.isra.0+0x8d
iavf_aqb_free() at netbsd:iavf_aqb_free+0x3b
iavf_attach() at netbsd:iavf_attach+0x3b1
config_attach_loc() at netbsd:config_attach_loc+0x182
pci_probe_device() at netbsd:pci_probe_device+0x585
pci_enumerate_bus() at netbsd:pci_enumerate_bus+0x1b5
pcirescan() at netbsd:pcirescan+0x4e
pciattach() at netbsd:pciattach+0x186
config_attach_loc() at netbsd:config_attach_loc+0x182
mp_pci_scan() at netbsd:mp_pci_scan+0x9e
amd64_mainbus_attach() at netbsd:amd64_mainbus_attach+0x236
mainbus_attach() at netbsd:mainbus_attach+0x84
config_attach_loc() at netbsd:config_attach_loc+0x182
cpu_configure() at netbsd:cpu_configure+0x38
main() at netbsd:main+0x32c
db{0}> 


>How-To-Repeat:
	Probably just as simple as booting NetBSD-current in this configuration.

	FreeBSD guests run fine on this host.

	I have another host with FreeBSD 12.1 and different X540-AT2 NIC
	and that runs NetBSD 9.0 fine.  But that uses ixv(4) in the guest.

>Fix:


>Release-Note:

>Audit-Trail:
From: Bert Kiers <kiers@original.xs4all.nl>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/55822: kernel panic in iavf0 attach
Date: Tue, 24 Nov 2020 18:18:06 +0100

 On Tue, Nov 24, 2020 at 04:15:01PM +0000, kiers@original.xs4all.nl wrote:
 > >Number:         55822
 > >Category:       kern
 > >Synopsis:       iavf0 attach: panic: kernel diagnostic assertion "!(pg->flags & PG_FREE)" failed: file "/home/kiers/git/NetBSD-current/src/sys/uvm/uvm_page.c", line 1449


 A little more info:

 NetBSD-current without the NIC passthrough works fine.

 It does not matter if I passthrough a port of the X710 or a port of the X722.

 On the FreeBSD side they probe as

 ixl1: <Intel(R) Ethernet Connection X722 for 10GBASE-T - 2.3.0-k> mem 0xc3000000-0xc3ffffff,0xc5000000-0xc5007fff irq 36 at device 0.1 numa-domain 0 on pci8
 ixl1: fw 3.1.49755 api 1.5 nvm 3.1d etid 80000827 oem 1.262.0
 ixl1: PF-ID[1]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 768, MDIO shared
 ixl1: Using 1024 TX descriptors and 1024 RX descriptors
 ixl1: Using 8 RX queues 8 TX queues
 ixl1: Using MSI-X interrupts with 9 vectors
 ixl1: Ethernet address: ac:1f:6b:4e:2a:2f
 ixl1: Allocating 8 queues for PF LAN VSI; 8 queues active
 ixl1: SR-IOV ready
 ixl1: netmap queues/slots: TX 8/1024, RX 8/1024
 ixl1: Link is up, 1 Gbps Full Duplex, Requested FEC: None, Negotiated FEC: None, Autoneg: True, Flow Control: None
 ixl1: link state changed to UP

 and

 ixl2: <Intel(R) Ethernet Controller X710 for 10GbE SFP+ - 2.3.0-k> mem 0xfb000000-0xfb7fffff,0xfb818000-0xfb81ffff irq 48 at device 0.0 numa-domain 0 on pci11
 ixl2: fw 8.13.63341 api 1.12 nvm 8.15 etid 80009616 oem 1.267.0
 ixl2: The driver for the device detected a newer version of the NVM image than expected.
 ixl2: Please install the most recent version of the network driver.
 ixl2: PF-ID[0]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, I2C
 ixl2: Using 1024 TX descriptors and 1024 RX descriptors
 ixl2: Using 8 RX queues 8 TX queues
 ixl2: Using MSI-X interrupts with 9 vectors
 ixl2: Ethernet address: 68:05:ca:2f:7c:50
 ixl2: Allocating 8 queues for PF LAN VSI; 8 queues active
 ixl2: PCI Express Bus: Speed 8.0GT/s Width x8
 ixl2: SR-IOV ready
 ixl2: netmap queues/slots: TX 8/1024, RX 8/1024
 ixl2: Link is up, 10 Gbps Full Duplex, Requested FEC: None, Negotiated FEC: None, Autoneg: False, Flow Control: None
 ixl2: link state changed to UP

 Both ports are connected to a Cisco ME-4924-10GE running IOS 15.0(2)SG9 (ENTSERVICESK9)

Responsible-Changed-From-To: kern-bug-people->yamaguchi
Responsible-Changed-By: yamaguchi@NetBSD.org
Responsible-Changed-When: Fri, 27 Nov 2020 09:16:33 +0000
Responsible-Changed-Why:
mine


From: "Shoichi YAMAGUCHI" <yamaguchi@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/55822 CVS commit: src/sys/dev/pci
Date: Tue, 1 Dec 2020 04:39:03 +0000

 Module Name:	src
 Committed By:	yamaguchi
 Date:		Tue Dec  1 04:39:03 UTC 2020

 Modified Files:
 	src/sys/dev/pci: if_iavf.c

 Log Message:
 Dequeue aqb from sc_atq_live even when the last command is failed

 iavf(4) didn't dequeue aqb from sc_atq_live that is a list for
 buffer in use when a command is failed by ETIMEDOUT.

 This causes a panic in the following sequence:

  1. enqueue an aqb to sc_atq_live at iavf_aqb_post()
  2. the last command is failed by ETIMEDOUT
  3. enqueue the aqb used in the failed command to sc_atq_idle
     at an error handling in iavf_attach()
  4. dequeue the same aqb from sc_atq_live and enqueue sc_atq_idle
     again at iavf_cleanup_admin_queue()
    - sc_atq_idle is broken at that time
  5. free the aqb in sc_atq_idle more than once

 Fix PR/55822

 reviewed by knakahara@n.o.


 To generate a diff of this commit:
 cvs rdiff -u -r1.6 -r1.7 src/sys/dev/pci/if_iavf.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Bert Kiers <kiers@original.xs4all.nl>
To: gnats-bugs@netbsd.org
Cc: yamaguchi@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	kiers@original.xs4all.nl
Subject: Re: PR/55822 CVS commit: src/sys/dev/pci
Date: Tue, 1 Dec 2020 14:24:49 +0100

 On Tue, Dec 01, 2020 at 04:40:01AM +0000, Shoichi YAMAGUCHI wrote:
 > The following reply was made to PR kern/55822; it has been noted by GNATS.
 > 
 > From: "Shoichi YAMAGUCHI" <yamaguchi@netbsd.org>
 > To: gnats-bugs@gnats.NetBSD.org
 > Cc: 
 > Subject: PR/55822 CVS commit: src/sys/dev/pci
 > Date: Tue, 1 Dec 2020 04:39:03 +0000
 > 
 >  Module Name:	src
 >  Committed By:	yamaguchi
 >  Date:		Tue Dec  1 04:39:03 UTC 2020
 >  
 >  Modified Files:
 >  	src/sys/dev/pci: if_iavf.c
 >  
 >  Log Message:
 >  Dequeue aqb from sc_atq_live even when the last command is failed
 >  
 >  iavf(4) didn't dequeue aqb from sc_atq_live that is a list for
 >  buffer in use when a command is failed by ETIMEDOUT.
 >  
 >  This causes a panic in the following sequence:
 >  
 >   1. enqueue an aqb to sc_atq_live at iavf_aqb_post()
 >   2. the last command is failed by ETIMEDOUT
 >   3. enqueue the aqb used in the failed command to sc_atq_idle
 >      at an error handling in iavf_attach()
 >   4. dequeue the same aqb from sc_atq_live and enqueue sc_atq_idle
 >      again at iavf_cleanup_admin_queue()
 >     - sc_atq_idle is broken at that time
 >   5. free the aqb in sc_atq_idle more than once
 >  
 >  Fix PR/55822

 This fixed the panic, but now I get

 iavf0 at pci0 dev 2 function 0autoconfiguration error: :unable to get VF interface version

 with both the 

 000:02:0: Intel X722 10GbE VF (ethernet network, revision 0x09)

 and the

 000:02:0: Intel XL710 Ethernet Virtual Function (ethernet network, revision 0x01)

 Grtnx,
 --
 Bert

From: s ymgch <s.ymgch228@gmail.com>
To: gnats-bugs@netbsd.org, kiers@original.xs4all.nl
Cc: Shoichi Yamaguchi <yamaguchi@netbsd.org>, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: PR/55822 CVS commit: src/sys/dev/pci
Date: Wed, 2 Dec 2020 10:45:40 +0900

 Hi,

 >  This fixed the panic, but now I get
 >
 >  iavf0 at pci0 dev 2 function 0autoconfiguration error: :unable to get VF interface version

 The reason why iavf(4) did not work on bhyve may be the combination between
 bhyve and NetBSD, because it didn't appear on ESXi and Linux as far as I know.

 Can you let me know about the environment of the VM?

 1. Which version of bhyve did you use?
 2. Which driver version of ixl did the bhyve use?
    - This is not the FW version shown in a probe message.
 3. Can other network devices using PCI passthrough, for example ixl, ixg and ixv
    work well on the same VM (not NetBSD-9 host)

 And can you tell me the message when iavf(4) is loaded with -i
 debug_level=3 option?
 You may already know, but just in case, the usage of the debug option
 is following:

 1. build and install kernel not containing iavf(4)
 2. build and install modules
 3. run the kernel and do "modload -i debug_level=3 if_iavf" command

 Regards,
 -- yamaguchi



 On Tue, Dec 1, 2020 at 10:35 PM Bert Kiers <kiers@original.xs4all.nl> wrote:
 >
 > The following reply was made to PR kern/55822; it has been noted by GNATS.
 >
 > From: Bert Kiers <kiers@original.xs4all.nl>
 > To: gnats-bugs@netbsd.org
 > Cc: yamaguchi@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
 >         kiers@original.xs4all.nl
 > Subject: Re: PR/55822 CVS commit: src/sys/dev/pci
 > Date: Tue, 1 Dec 2020 14:24:49 +0100
 >
 >  On Tue, Dec 01, 2020 at 04:40:01AM +0000, Shoichi YAMAGUCHI wrote:
 >  > The following reply was made to PR kern/55822; it has been noted by GNATS.
 >  >
 >  > From: "Shoichi YAMAGUCHI" <yamaguchi@netbsd.org>
 >  > To: gnats-bugs@gnats.NetBSD.org
 >  > Cc:
 >  > Subject: PR/55822 CVS commit: src/sys/dev/pci
 >  > Date: Tue, 1 Dec 2020 04:39:03 +0000
 >  >
 >  >  Module Name:        src
 >  >  Committed By:       yamaguchi
 >  >  Date:               Tue Dec  1 04:39:03 UTC 2020
 >  >
 >  >  Modified Files:
 >  >      src/sys/dev/pci: if_iavf.c
 >  >
 >  >  Log Message:
 >  >  Dequeue aqb from sc_atq_live even when the last command is failed
 >  >
 >  >  iavf(4) didn't dequeue aqb from sc_atq_live that is a list for
 >  >  buffer in use when a command is failed by ETIMEDOUT.
 >  >
 >  >  This causes a panic in the following sequence:
 >  >
 >  >   1. enqueue an aqb to sc_atq_live at iavf_aqb_post()
 >  >   2. the last command is failed by ETIMEDOUT
 >  >   3. enqueue the aqb used in the failed command to sc_atq_idle
 >  >      at an error handling in iavf_attach()
 >  >   4. dequeue the same aqb from sc_atq_live and enqueue sc_atq_idle
 >  >      again at iavf_cleanup_admin_queue()
 >  >     - sc_atq_idle is broken at that time
 >  >   5. free the aqb in sc_atq_idle more than once
 >  >
 >  >  Fix PR/55822
 >
 >  This fixed the panic, but now I get
 >
 >  iavf0 at pci0 dev 2 function 0autoconfiguration error: :unable to get VF interface version
 >
 >  with both the
 >
 >  000:02:0: Intel X722 10GbE VF (ethernet network, revision 0x09)
 >
 >  and the
 >
 >  000:02:0: Intel XL710 Ethernet Virtual Function (ethernet network, revision 0x01)
 >
 >  Grtnx,
 >  --
 >  Bert
 >

From: Bert Kiers <kiers@original.xs4all.nl>
To: s ymgch <s.ymgch228@gmail.com>
Cc: gnats-bugs@netbsd.org, kiers@original.xs4all.nl,
	Shoichi Yamaguchi <yamaguchi@netbsd.org>, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: PR/55822 CVS commit: src/sys/dev/pci
Date: Wed, 2 Dec 2020 13:10:11 +0100

 On Wed, Dec 02, 2020 at 10:45:40AM +0900, s ymgch wrote:
 > Hi,

 Hi,

 > The reason why iavf(4) did not work on bhyve may be the combination between
 > bhyve and NetBSD, because it didn't appear on ESXi and Linux as far as I know.
 > 
 > Can you let me know about the environment of the VM?
 > 
 > 1. Which version of bhyve did you use?

 The one that comes with FreeBSD 12.2-RELEASE r366954.
 bhyve nor bhyvectl have an option that shows the version, afaik.

 > 2. Which driver version of ixl did the bhyve use?
 >    - This is not the FW version shown in a probe message.

 I see

 ixl0: <Intel(R) Ethernet Connection X722 for 10GBASE-T - 2.3.0-k> mem 0xc4000000-0xc4ffffff,0xc5008000-0xc500ffff irq 36 at device 0.0 numa-domain 0 on pci8

 so 2.3.0-k

 On

 https://downloadcenter.intel.com/download/25160/Intel-Network-Adapter-Driver-for-PCIe-40-Gigabit-Ethernet-Network-Connection-under-FreeBSD-

 I see version 1.12.3.  I'll go try that.  But I do not understand how
 2.3.0-k relates to 1.12.3 yet.

 > 3. Can other network devices using PCI passthrough, for example ixl, ixg and ixv
 >    work well on the same VM (not NetBSD-9 host)

 I just have ixl NICs on this machine.  So I don't know.

 (In an other server I have a X540 NIC, that is ix on the FreeBSD side
 and ixv in the NetBSD guest.  That works stable and fast, but just for
 *one* guest, I documented that story on
 https://netbsd.itsx.net/freebsd+bhyve+sriov.html, which is work in 
 progress).

 On this machine with ixl, multiple FreeBSD and Linux guests work.


 > And can you tell me the message when iavf(4) is loaded with -i
 > debug_level=3 option?
 > You may already know, but just in case, the usage of the debug option
 > is following:
 > 
 > 1. build and install kernel not containing iavf(4)
 > 2. build and install modules
 > 3. run the kernel and do "modload -i debug_level=3 if_iavf" command

 Boot messages:

 [     1.033888] Intel XL710 Ethernet Virtual Function (ethernet network, revision 0x01) at pci0 dev 2 function 0 not configured
 [     1.033888] Intel X722 10GbE VF (ethernet network, revision 0x09) at pci0 dev 3 function 0 not configured

 and then

 # modload -i debug_level=3 if_iavf
 [  61.5983006] iavf: debug level=3
 [  61.6083181] iavf0 at pci0 dev 2 function 0iavf0: post
 [  61.6283146] iavf0: flags 0x3400<SI,BUF,DB> opcode 0801
 [  61.6283146] iavf0: datalen 8 retval 0
 [  61.6283146] iavf0: vc-opcode 1 (GET_VERSION)
 [  61.6381634] iavf0: vc-retval 0
 [  61.6381634] iavf0: cookie 0000000000000001
 [  61.6381634] iavf0: 00000000 00000000 00000001 07fd0000
 [  61.9183239] iavf0: atq timedout
 :unable to get VF interface version
 [  61.9379397] iavf1 at pci0 dev 3 function 0iavf1: post
 [  61.9483230] iavf1: flags 0x3400<SI,BUF,DB> opcode 0801
 [  61.9483230] iavf1: datalen 8 retval 0
 [  61.9483230] iavf1: vc-opcode 1 (GET_VERSION)
 [  61.9483230] iavf1: vc-retval 0
 [  61.9582973] iavf1: cookie 0000000000000001
 [  61.9582973] iavf1: 00000000 00000000 00000001 080d5000
 [  62.2182973] iavf1: atq timedout
 :unable to get VF interface version


 I'll put complete dmesg and things on
 https://netbsd.itsx.net/PR55822/ soon.

 Grtnx,
 --
 Bert

From: Bert Kiers <kiers@original.xs4all.nl>
To: Bert Kiers <kiers@original.xs4all.nl>
Cc: s ymgch <s.ymgch228@gmail.com>, gnats-bugs@netbsd.org,
	Shoichi Yamaguchi <yamaguchi@netbsd.org>, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: PR/55822 CVS commit: src/sys/dev/pci
Date: Wed, 2 Dec 2020 14:03:15 +0100

 On Wed, Dec 02, 2020 at 01:10:11PM +0100, Bert Kiers wrote:
 > On Wed, Dec 02, 2020 at 10:45:40AM +0900, s ymgch wrote:

 > > 2. Which driver version of ixl did the bhyve use?
 > >    - This is not the FW version shown in a probe message.
 > 
 > I see
 > 
 > ixl0: <Intel(R) Ethernet Connection X722 for 10GBASE-T - 2.3.0-k> mem 0xc4000000-0xc4ffffff,0xc5008000-0xc500ffff irq 36 at device 0.0 numa-domain 0 on pci8
 > 
 > so 2.3.0-k
 > 
 > On
 > 
 > https://downloadcenter.intel.com/download/25160/Intel-Network-Adapter-Driver-for-PCIe-40-Gigabit-Ethernet-Network-Connection-under-FreeBSD-
 > 
 > I see version 1.12.3.  I'll go try that.  But I do not understand how
 > 2.3.0-k relates to 1.12.3 yet.

 This needs the patch from
 https://forums.freebsd.org/threads/intel-ix-driver-no-longer-compile-correcty-in-12-2.77603/

 On the FreeBSD host now:

 ixl0: <Intel(R) Ethernet Connection 700 Series PF Driver, Version - 1.12.3> mem 0xc4000000-0xc4ffffff,0xc5008000-0xc500ffff irq 36 at device 0.0 numa-domain 0 on pci8

 In the NetBSD VM, nothing changed.

 Grtnx,
 -- 
 Bert

From: Bert Kiers <kiers@original.xs4all.nl>
To: Bert Kiers <kiers@original.xs4all.nl>
Cc: s ymgch <s.ymgch228@gmail.com>, gnats-bugs@netbsd.org,
	Shoichi Yamaguchi <yamaguchi@netbsd.org>, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: PR/55822 CVS commit: src/sys/dev/pci
Date: Wed, 2 Dec 2020 14:22:07 +0100

 On Wed, Dec 02, 2020 at 02:03:15PM +0100, Bert Kiers wrote:
 > On Wed, Dec 02, 2020 at 01:10:11PM +0100, Bert Kiers wrote:
 > > On Wed, Dec 02, 2020 at 10:45:40AM +0900, s ymgch wrote:
 > 
 > > > 2. Which driver version of ixl did the bhyve use?
 > > >    - This is not the FW version shown in a probe message.
 > > 
 > > I see
 > > 
 > > ixl0: <Intel(R) Ethernet Connection X722 for 10GBASE-T - 2.3.0-k> mem 0xc4000000-0xc4ffffff,0xc5008000-0xc500ffff irq 36 at device 0.0 numa-domain 0 on pci8
 > > 
 > > so 2.3.0-k
 > > 
 > > On
 > > 
 > > https://downloadcenter.intel.com/download/25160/Intel-Network-Adapter-Driver-for-PCIe-40-Gigabit-Ethernet-Network-Connection-under-FreeBSD-
 > > 
 > > I see version 1.12.3.  I'll go try that.  But I do not understand how
 > > 2.3.0-k relates to 1.12.3 yet.
 > 
 > This needs the patch from
 > https://forums.freebsd.org/threads/intel-ix-driver-no-longer-compile-correcty-in-12-2.77603/
 > 
 > On the FreeBSD host now:
 > 
 > ixl0: <Intel(R) Ethernet Connection 700 Series PF Driver, Version - 1.12.3> mem 0xc4000000-0xc4ffffff,0xc5008000-0xc500ffff irq 36 at device 0.0 numa-domain 0 on pci8

 *and*

 the warning
 ```
 ixl2: The driver for the device detected a newer version of the NVM image than expected.
 ixl2: Please install the most recent version of the network driver.
 ```
 is gone.  So 1.12.3 is newer than 2.3.0 somehow.

 > 
 > In the NetBSD VM, nothing changed.

 Grtnx,
 -- 
 Bert

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.