Re: ix(4) need support for X553
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
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: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV
Re: ix(4) need support for X553
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 EP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP
Re: ix(4) need support for X553
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 (PCI
Re: ix(4) need support for X553
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
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
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
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
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
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
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
ix(4) need support for X553
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