Re: ix(4) need support for X553

2019-12-02 Thread Hrvoje Popovski
On 18.11.2019. 0:31, Hrvoje Popovski wrote:
> On 14.11.2019. 1:06, Stuart Henderson wrote:
>> Apart from the obvious style(9) problems, can anyone give me guidance on
>> how to approach this diff? I'm quite uneasy at the amount of changes but 
>> these
>> nics are quite important, they're all over the place on Atom C3xxx boards
>> which are pretty much the main "next step up" from APUs.
>>
>> I have an A2SDi-2C-HLN4F that I need to put in service soon (not so
>> bothered about the ix on this box, I'm using 4xSFP+ ixl, but giving it
>> a spin) - applying my merged diff (https://junkpile.org/ixgbe.diff2)
> 
> with this diff box panic while booting at starting network
> 
> ix0 at pci1 dev 0 function 0 "Intel 82599" rev 0x01: msi, address
> ix1 at pci1 dev 0 function 1 "Intel 82599" rev 0x01: msi, address
> em0 at pci7 dev 0 function 0 "Intel I350" rev 0x01: msi, address
> em1 at pci7 dev 0 function 1 "Intel I350" rev 0x01: msi, address
> 
> net.inet.ip.forwarding: 0 -> 1
> starting network
> panic: attempt to execute user address 0x0 in supervisor mode
> Stopped at  db_enter+0x10:  popq%rbp
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> *489100  47566  0 0x3  00K ifconfig
> db_enter() at db_enter+0x10
> panic(81cbe37d) at panic+0x128
> pageflttrap(8000224ebeb0,0) at pageflttrap+0x2db
> kerntrap(8000224ebeb0) at kerntrap+0x91
> alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
> 0(80078000,80078000,aa0519036f37d371,80078000,8
> 0159300,7) at 0
> ixgbe_init(80078000) at ixgbe_init+0x36
> ixgbe_ioctl(80078048,8020690c,80159300) at ixgbe_ioctl+0x15a
> in_ifinit(80078048,80159300,8000224ec2d0,1) at
> in_ifinit+0xf3
> in_ioctl_change_ifaddr(8040691a,8000224ec2c0,80078048,1) at
> in_ioctl_change_ifaddr+0x350
> in_ioctl(8040691a,8000224ec2c0,80078048,1) at in_ioctl+0x12e
> ifioctl(fd83b36cad80,8040691a,8000224ec2c0,80004ee0) at
> ifioctl+0x99e
> sys_ioctl(80004ee0,8000224ec3d0,8000224ec430) at
> sys_ioctl+0x3c2
> syscall(8000224ec4a0) at syscall+0x389
> end trace frame: 0x8000224ec520, count: 0
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> ddb{0}>

it seems that 82599 is affected by this diff, x552 and x540 are fine



Re: ix(4) need support for X553

2019-11-22 Thread Colin Hyatt Bortner
On Thu, Nov 14, 2019, at 1:06 AM, Stuart Henderson wrote:

*snip*

> 
> I have an A2SDi-2C-HLN4F that I need to put in service soon (not so
> bothered about the ix on this box, I'm using 4xSFP+ ixl, but giving it
> a spin) - applying my merged diff (https://junkpile.org/ixgbe.diff2)
> and adding PCI_PRODUCT_INTEL_X550EM_A_1G_T_L things work so far in a
> quick test.
> 
> - MACs look sane
> 
> - no problems seen in rx/tx at 1G link speed, I haven't tried other
> speeds; looking at Linux diffs it seems it may need a little change for 10M
> 
> - haven't tried jumbos yet
> 
> - seems fairly reliable so far but tx performance is a bit poor, ~500M
> max sends from tcpbench - rx speeds are fine
> 
> - NFS works
> 
> - dmesg/pcidevs below in case they're of interest
> 

*snip*

I have a Supermicro A2SDi-8C-HLN4F and my first test with the diff was also 
positive. 

I applied to 6.6-stable sources, since that's what the target machine is 
running, 
and added PCI_PRODUCT_INTEL_X550EM_A_1G_T and [...]_A_1G_T_L to if_ix.c. 

On reboot, the four onboard interfaces were picked up. Brought one interface up 
with dhclient and ssh'd in. Will do more testing in the next week or two.

My dmesg is below.


OpenBSD 6.6-stable (GENERIC.MP) #4: Fri Nov 22 17:24:44 CET 2019
coli...@x1.colinhb.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17122009088 (16328MB)
avail mem = 16590336000 (15821MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f0c3000 (35 entries)
bios0: vendor American Megatrends Inc. version "1.1c" date 06/25/2019
bios0: Supermicro A2SDi-8C-HLN4F
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT APIC BDAT HPET UEFI SSDT DMAR 
HEST BERT ERST EINJ WSMT
acpi0: wakeup devices XHC1(S4) OBL1(S4) LAN1(S4) PEX0(S4) LAN2(S4) LAN3(S4) 
PEX1(S4) PEX6(S4) PEX7(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.42 MHz, 06-5f-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 2MB 64b/line 16-way L2 cache
cpu0: cannot disable silicon debug
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 25MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.02 MHz, 06-5f-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 2MB 64b/line 16-way L2 cache
cpu1: cannot disable silicon debug
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 8 (application processor)
cpu2: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.01 MHz, 06-5f-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 2MB 64b/line 16-way L2 cache
cpu2: cannot disable silicon debug
cpu2: smt 0, core 4, package 0
cpu3 at mainbus0: apid 12 (application processor)
cpu3: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.01 MHz, 06-5f-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 2MB 64b/line 16-way L2 cache
cpu3: cannot disable silicon debug
cpu3: smt 0, core 6, package 0
cpu4 at mainbus0: apid 16 (application processor)
cpu4: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.01 MHz, 06-5f-01
cpu4: 

Re: ix(4) need support for X553

2019-11-17 Thread Hrvoje Popovski
On 14.11.2019. 1:06, Stuart Henderson wrote:
> Apart from the obvious style(9) problems, can anyone give me guidance on
> how to approach this diff? I'm quite uneasy at the amount of changes but these
> nics are quite important, they're all over the place on Atom C3xxx boards
> which are pretty much the main "next step up" from APUs.
> 
> I have an A2SDi-2C-HLN4F that I need to put in service soon (not so
> bothered about the ix on this box, I'm using 4xSFP+ ixl, but giving it
> a spin) - applying my merged diff (https://junkpile.org/ixgbe.diff2)


with this diff box panic while booting at starting network

ix0 at pci1 dev 0 function 0 "Intel 82599" rev 0x01: msi, address
ix1 at pci1 dev 0 function 1 "Intel 82599" rev 0x01: msi, address
em0 at pci7 dev 0 function 0 "Intel I350" rev 0x01: msi, address
em1 at pci7 dev 0 function 1 "Intel I350" rev 0x01: msi, address

net.inet.ip.forwarding: 0 -> 1
starting network
panic: attempt to execute user address 0x0 in supervisor mode
Stopped at  db_enter+0x10:  popq%rbp
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
*489100  47566  0 0x3  00K ifconfig
db_enter() at db_enter+0x10
panic(81cbe37d) at panic+0x128
pageflttrap(8000224ebeb0,0) at pageflttrap+0x2db
kerntrap(8000224ebeb0) at kerntrap+0x91
alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
0(80078000,80078000,aa0519036f37d371,80078000,8
0159300,7) at 0
ixgbe_init(80078000) at ixgbe_init+0x36
ixgbe_ioctl(80078048,8020690c,80159300) at ixgbe_ioctl+0x15a
in_ifinit(80078048,80159300,8000224ec2d0,1) at
in_ifinit+0xf3
in_ioctl_change_ifaddr(8040691a,8000224ec2c0,80078048,1) at
in_ioctl_change_ifaddr+0x350
in_ioctl(8040691a,8000224ec2c0,80078048,1) at in_ioctl+0x12e
ifioctl(fd83b36cad80,8040691a,8000224ec2c0,80004ee0) at
ifioctl+0x99e
sys_ioctl(80004ee0,8000224ec3d0,8000224ec430) at
sys_ioctl+0x3c2
syscall(8000224ec4a0) at syscall+0x389
end trace frame: 0x8000224ec520, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb{0}>

ddb{0}> show registers
rdi   0x81ef0a18kprintf_mutex
rsi  0x5
rbp   0x8000224ebd40
rbx   0x8000224ebdf0
rdx   0xc800121a
rcx0x286
rax  0x1
r80x8000224ebd00
r90x8015937c
r10   0x42179c57eeeb011c
r11   0xe24334526c571546
r12 0x38
r13   0x8000224ebd50
r140x100
r15   0x81cbe37dcy_pio_rec+0x3a81
rip   0x81b1a660db_enter+0x10
cs   0x8
rflags 0x282
rsp   0x8000224ebd40
ss  0x10
db_enter+0x10:  popq%rbp
ddb{0}>


dmesg
OpenBSD 6.6-current (GENERIC.MP) #5: Mon Nov 18 00:13:49 CET 2019
hrv...@r620-1.srce.hr:/sys/arch/amd64/compile/GENERIC.MP
real mem = 17115840512 (16322MB)
avail mem = 16584732672 (15816MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (99 entries)
bios0: vendor Dell Inc. version "2.8.0" date 06/26/2019
bios0: Dell Inc. PowerEdge R620
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WDAT SLIC ERST HEST
BERT EINJ T
CPA PC__ SRAT SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 4 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.46 MHz, 06-3e-04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,V
MX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLI
NE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SM
EP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 2, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 6 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.00 MHz, 06-3e-04
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,V
MX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLI
NE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SM

Re: ix(4) need support for X553

2019-11-13 Thread Stuart Henderson
Apart from the obvious style(9) problems, can anyone give me guidance on
how to approach this diff? I'm quite uneasy at the amount of changes but these
nics are quite important, they're all over the place on Atom C3xxx boards
which are pretty much the main "next step up" from APUs.

I have an A2SDi-2C-HLN4F that I need to put in service soon (not so
bothered about the ix on this box, I'm using 4xSFP+ ixl, but giving it
a spin) - applying my merged diff (https://junkpile.org/ixgbe.diff2)
and adding PCI_PRODUCT_INTEL_X550EM_A_1G_T_L things work so far in a
quick test.

- MACs look sane

- no problems seen in rx/tx at 1G link speed, I haven't tried other
speeds; looking at Linux diffs it seems it may need a little change for 10M

- haven't tried jumbos yet

- seems fairly reliable so far but tx performance is a bit poor, ~500M
max sends from tcpbench - rx speeds are fine

- NFS works

- dmesg/pcidevs below in case they're of interest


On 2019/10/30 21:43, Stuart Henderson wrote:
> On 2019/10/30 07:34, sven falempin wrote:
> > https://github.com/dohnuts/wip/blob/master/ixgbe.diff
> > 
> > Needs lots of cleaning
> > 
> > On Wed, Oct 30, 2019 at 6:59 AM Joerg Goltermann  wrote:
> > 
> > > Hello,
> > >
> > > I have a new Lanner NCA-1510A (with a Intel C3558) which has some
> > > X553 SGMII ethernet ports. Unfortunately there is no support in ix(4)
> > > for this type.
> > >
> > > Is anyone working on an update for the ix(4) to support the new
> > > hardware?
> > >
> > > I took a look at the actual ix(4) and it's a bit confusing. I'm
> > > not sure about the "version" of this driver compared to FreeBSD/
> > > Intel version.
> > >
> > > Wouldn't it be nice to have a more "stock" version of the driver. This
> > > would make it much easier to port updates from FreeBSD/Intel to OpenBSD.
> > >
> > > Any feedback is appreciated.
> > >
> > >   - Joerg
> > >
> 
> Oh I've got a machine coming soon and I have a nasty feeling it's going to
> have one of those ..
> 
> That diff is stale, I've merged conflicts at https://junkpile.org/ixgbe.diff2,
> and it builds but totally untested.
> 

$  sysctl hw
hw.machine=amd64
hw.model=Intel(R) Atom(TM) CPU C3338 @ 1.50GHz
hw.ncpu=2
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0:f232b1bd76ed931b
hw.diskcount=1
hw.sensors.cpu0.temp0=32.00 degC
hw.cpuspeed=2200
hw.setperf=199
hw.vendor=Supermicro
hw.product=Super Server
hw.version=0123456789
hw.serialno=0123456789
hw.uuid=----3cecef004fd4
hw.physmem=8530952192
hw.usermem=8530939904
hw.ncpufound=2
hw.allowpowerdown=1
hw.perfpolicy=manual
hw.smt=0
hw.ncpuonline=2


OpenBSD 6.6-current (GENERIC.MP) #1: Wed Nov 13 23:40:03 UTC 2019
sthen@xxx:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8530952192 (8135MB)
avail mem = 8260022272 (7877MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f0c3000 (32 entries)
bios0: vendor American Megatrends Inc. version "1.1c" date 06/25/2019
bios0: Supermicro Super Server
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT APIC BDAT HPET UEFI SSDT DMAR 
HEST BERT ERST EINJ WSMT
acpi0: wakeup devices XHC1(S4) OBL1(S4) LAN1(S4) PEX0(S4) LAN2(S4) LAN3(S4) 
PEX1(S4) PEX6(S4) PEX7(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 12 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3338 @ 1.50GHz, 2200.42 MHz, 06-5f-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 2MB 64b/line 16-way L2 cache
cpu0: cannot disable silicon debug
cpu0: smt 0, core 6, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 25MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
cpu1 at mainbus0: apid 24 (application processor)
cpu1: Intel(R) Atom(TM) CPU C3338 @ 1.50GHz, 2200.02 MHz, 06-5f-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 2MB 64b/line 16-way L2 cache
cpu1: cannot disable silicon debug
cpu1: smt 0, core 12, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 

Re: ix(4) need support for X553

2019-11-04 Thread Joerg Goltermann

Hello,

thank you so much, I did some tests with my X553 and the system survived
all of my tests. Running tcpbench and unplugging the cables several times,
ifconfig down & up.


I think, the performance looks good too:
cpu0 at mainbus0: apid 4 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.41 MHz, 06-5f-01
...
ix0 at pci6 dev 0 function 0 "Intel X553 SGMII" rev 0x11: msi, address 
00:90:0b:5f:80:98
ix1 at pci6 dev 0 function 1 "Intel X553 SGMII" rev 0x11: msi, address 
00:90:0b:5f:80:99
ix2 at pci7 dev 0 function 0 "Intel X553 SGMII" rev 0x11: msi, address 
00:90:0b:5f:80:9a
ix3 at pci7 dev 0 function 1 "Intel X553 SGMII" rev 0x11: msi, address 
00:90:0b:5f:80:9b


running a back to back (2 rdomains) tcpbench with pf disabled and
mtu 1500 results in about 880 Mbit/s and using mtu 9000 in 990 Mbit/s

I run the tcpbench all the weekend and did not see any problems.

Nice work! I would really love to see the update in GENERIC.

 - Joerg


On 31.10.2019 16:00, sven falempin wrote:

On Thu, Oct 31, 2019 at 9:49 AM sven falempin 
wrote:




On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson 
wrote:


On 2019/10/31 08:25, sven falempin wrote:

Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly

removed from this

The pcidevs update is no longer needed since pcidevs r1.1889.


I may have time to test it against 6.6, see if it is still working

since 6.4 (where it was

tested, also a cross test revealed
that plugin'/unplugging SFP maybe non functionnal)


I can test an already-wprking fibre ix for new problems at some point,
but I don't
think I'll have a fibre X553.



ppb7 at pci0 dev 22 function 0 "Intel C3000 PCIE" rev 0x11
"Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 0 not configured
"Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 1 not configured
ppb8 at pci0 dev 23 function 0 "Intel C3000 PCIE" rev 0x11
"Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 0 not configured
"Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 1 not configured

When I look at them , some more involved people was talking about 10gb in
OpenBSD .

Isn't there some limitations currently or can we expect the X553  to
perform at 10Gb ?




Hey looks like my diff still works

OpenBSD 6.6-stable (GENERIC.MP) #21: Thu Oct 31 10:53:41 EDT 2019
ix0 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:81
ix1 at pci8 dev 0 function 1 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:82
ix2 at pci9 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:83
ix3 at pci9 dev 0 function 1 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:84

# ifconfig ix
ix0: flags=8802 mtu 1500
 lladdr 00:30:18:0b:4a:81
 index 3 priority 0 llprio 3
 media: Ethernet autoselect
 status: no carrier
ix1: flags=8802 mtu 1500
 lladdr 00:30:18:0b:4a:82
 index 4 priority 0 llprio 3
 media: Ethernet autoselect (10GbaseSR full-duplex)
 status: active
ix2: flags=8802 mtu 1500
 lladdr 00:30:18:0b:4a:83
 index 5 priority 0 llprio 3
 media: Ethernet autoselect
 status: no carrier
ix3: flags=8802 mtu 1500
 lladdr 00:30:18:0b:4a:84
 index 6 priority 0 llprio 3
 media: Ethernet autoselect (10GbaseSR full-duplex)
 status: active

# ifconfig ix1 rdomain 1 10.0.0.1
# ifconfig ix3 rdomain 3 10.0.0.3
# ping -V 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.573 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.246 ms

# route -T 1 exec iperf -c 10.0.0.3

Client connecting to 10.0.0.3, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 10.0.0.1 port 29912 connected with 10.0.0.3 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec   871 MBytes   731 Mbits/sec

If anyone want to help run it faster, you re welcome.





Re: ix(4) need support for X553

2019-10-31 Thread sven falempin
On Thu, Oct 31, 2019 at 9:49 AM sven falempin 
wrote:

>
>
> On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson 
> wrote:
>
>> On 2019/10/31 08:25, sven falempin wrote:
>> > Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly
>> removed from this
>>
>> The pcidevs update is no longer needed since pcidevs r1.1889.
>>
>> > I may have time to test it against 6.6, see if it is still working
>> since 6.4 (where it was
>> > tested, also a cross test revealed
>> > that plugin'/unplugging SFP maybe non functionnal)
>>
>> I can test an already-wprking fibre ix for new problems at some point,
>> but I don't
>> think I'll have a fibre X553.
>>
>>
> ppb7 at pci0 dev 22 function 0 "Intel C3000 PCIE" rev 0x11
> "Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 0 not configured
> "Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 1 not configured
> ppb8 at pci0 dev 23 function 0 "Intel C3000 PCIE" rev 0x11
> "Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 0 not configured
> "Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 1 not configured
>
> When I look at them , some more involved people was talking about 10gb in
> OpenBSD .
>
> Isn't there some limitations currently or can we expect the X553  to
> perform at 10Gb ?
>
>
>
Hey looks like my diff still works

OpenBSD 6.6-stable (GENERIC.MP) #21: Thu Oct 31 10:53:41 EDT 2019
ix0 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:81
ix1 at pci8 dev 0 function 1 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:82
ix2 at pci9 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:83
ix3 at pci9 dev 0 function 1 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:84

# ifconfig ix
ix0: flags=8802 mtu 1500
lladdr 00:30:18:0b:4a:81
index 3 priority 0 llprio 3
media: Ethernet autoselect
status: no carrier
ix1: flags=8802 mtu 1500
lladdr 00:30:18:0b:4a:82
index 4 priority 0 llprio 3
media: Ethernet autoselect (10GbaseSR full-duplex)
status: active
ix2: flags=8802 mtu 1500
lladdr 00:30:18:0b:4a:83
index 5 priority 0 llprio 3
media: Ethernet autoselect
status: no carrier
ix3: flags=8802 mtu 1500
lladdr 00:30:18:0b:4a:84
index 6 priority 0 llprio 3
media: Ethernet autoselect (10GbaseSR full-duplex)
status: active

# ifconfig ix1 rdomain 1 10.0.0.1
# ifconfig ix3 rdomain 3 10.0.0.3
# ping -V 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.573 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.246 ms

# route -T 1 exec iperf -c 10.0.0.3

Client connecting to 10.0.0.3, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 10.0.0.1 port 29912 connected with 10.0.0.3 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec   871 MBytes   731 Mbits/sec

If anyone want to help run it faster, you re welcome.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do


Re: ix(4) need support for X553

2019-10-31 Thread sven falempin
On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson 
wrote:

> On 2019/10/31 08:25, sven falempin wrote:
> > Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly
> removed from this
>
> The pcidevs update is no longer needed since pcidevs r1.1889.
>
> > I may have time to test it against 6.6, see if it is still working since
> 6.4 (where it was
> > tested, also a cross test revealed
> > that plugin'/unplugging SFP maybe non functionnal)
>
> I can test an already-wprking fibre ix for new problems at some point, but
> I don't
> think I'll have a fibre X553.
>
>
ppb7 at pci0 dev 22 function 0 "Intel C3000 PCIE" rev 0x11
"Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 0 not configured
"Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 1 not configured
ppb8 at pci0 dev 23 function 0 "Intel C3000 PCIE" rev 0x11
"Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 0 not configured
"Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 1 not configured

When I look at them , some more involved people was talking about 10gb in
OpenBSD .

Isn't there some limitations currently or can we expect the X553  to
perform at 10Gb ?


-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do


Re: ix(4) need support for X553

2019-10-31 Thread Stuart Henderson
On 2019/10/31 08:25, sven falempin wrote:
> Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly removed 
> from this

The pcidevs update is no longer needed since pcidevs r1.1889.

> I may have time to test it against 6.6, see if it is still working since 6.4 
> (where it was
> tested, also a cross test revealed
> that plugin'/unplugging SFP maybe non functionnal)

I can test an already-wprking fibre ix for new problems at some point, but I 
don't
think I'll have a fibre X553.



Re: ix(4) need support for X553

2019-10-31 Thread sven falempin
On Wed, Oct 30, 2019 at 5:43 PM Stuart Henderson 
wrote:

> On 2019/10/30 07:34, sven falempin wrote:
> > https://github.com/dohnuts/wip/blob/master/ixgbe.diff
> >
> > Needs lots of cleaning
> >
> > On Wed, Oct 30, 2019 at 6:59 AM Joerg Goltermann  wrote:
> >
> > > Hello,
> > >
> > > I have a new Lanner NCA-1510A (with a Intel C3558) which has some
> > > X553 SGMII ethernet ports. Unfortunately there is no support in ix(4)
> > > for this type.
> > >
> > > Is anyone working on an update for the ix(4) to support the new
> > > hardware?
> > >
> > > I took a look at the actual ix(4) and it's a bit confusing. I'm
> > > not sure about the "version" of this driver compared to FreeBSD/
> > > Intel version.
> > >
> > > Wouldn't it be nice to have a more "stock" version of the driver. This
> > > would make it much easier to port updates from FreeBSD/Intel to
> OpenBSD.
> > >
> > > Any feedback is appreciated.
> > >
> > >   - Joerg
> > >
>
> Oh I've got a machine coming soon and I have a nasty feeling it's going to
> have one of those ..
>
> That diff is stale, I've merged conflicts at
> https://junkpile.org/ixgbe.diff2,
> and it builds but totally untested.
>
>
Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly removed
from this

I may have time to test it against 6.6, see if it is still working since
6.4 (where it was tested, also a cross test revealed
that plugin'/unplugging SFP maybe non functionnal)



-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do


Re: ix(4) need support for X553

2019-10-30 Thread Stuart Henderson
On 2019/10/30 07:34, sven falempin wrote:
> https://github.com/dohnuts/wip/blob/master/ixgbe.diff
> 
> Needs lots of cleaning
> 
> On Wed, Oct 30, 2019 at 6:59 AM Joerg Goltermann  wrote:
> 
> > Hello,
> >
> > I have a new Lanner NCA-1510A (with a Intel C3558) which has some
> > X553 SGMII ethernet ports. Unfortunately there is no support in ix(4)
> > for this type.
> >
> > Is anyone working on an update for the ix(4) to support the new
> > hardware?
> >
> > I took a look at the actual ix(4) and it's a bit confusing. I'm
> > not sure about the "version" of this driver compared to FreeBSD/
> > Intel version.
> >
> > Wouldn't it be nice to have a more "stock" version of the driver. This
> > would make it much easier to port updates from FreeBSD/Intel to OpenBSD.
> >
> > Any feedback is appreciated.
> >
> >   - Joerg
> >

Oh I've got a machine coming soon and I have a nasty feeling it's going to
have one of those ..

That diff is stale, I've merged conflicts at https://junkpile.org/ixgbe.diff2,
and it builds but totally untested.



Re: ix(4) need support for X553

2019-10-30 Thread sven falempin
https://github.com/dohnuts/wip/blob/master/ixgbe.diff

Needs lots of cleaning

On Wed, Oct 30, 2019 at 6:59 AM Joerg Goltermann  wrote:

> Hello,
>
> I have a new Lanner NCA-1510A (with a Intel C3558) which has some
> X553 SGMII ethernet ports. Unfortunately there is no support in ix(4)
> for this type.
>
> Is anyone working on an update for the ix(4) to support the new
> hardware?
>
> I took a look at the actual ix(4) and it's a bit confusing. I'm
> not sure about the "version" of this driver compared to FreeBSD/
> Intel version.
>
> Wouldn't it be nice to have a more "stock" version of the driver. This
> would make it much easier to port updates from FreeBSD/Intel to OpenBSD.
>
> Any feedback is appreciated.
>
>   - Joerg
>
> --
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do