Re: Interfaces errors and latency spikes with Intel 82583V
Apparently it is not: #ifconfig em0 hwfeatures em0: flags=808843 mtu 1500 hwfeatures=36 hardmtu 9216 lladdr XX:XX:XX:XX:XX:XX index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet XX:XX:XX:XX netmask 0xff00 broadcast XX:XX:XX:XX On 2020-06-11 21:57, David Gwynne wrote: Is flow control enabled? Can you try disabling rxpause and txpause? On 12 Jun 2020, at 10:36 am, Gabri Tofano wrote: Yes, this is today without resetting the interface: #netstat -ie NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls em0 1500XX:XX:XX:XX:XX:XX 5351463 1868 3016695 0 0 em0 1500 XX:XX:XX:XX XX:XX:XX:XX:XX:XX 5351463 1868 3016695 0 0 em1 1500XX:XX:XX:XX:XX:XX 2839738 0 5147702 0 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 2839738 0 5147702 0 0 em2 1500XX:XX:XX:XX:XX:XX46977 044135 0 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX46977 044135 0 0 em3*150000:e0:67:10:9d:970 00 0 0 enc0* 00 00 0 0 pflog0 331360 0 128982 0 0 On 2020-06-11 20:29, David Gwynne wrote: Is it consistently Ierrs? dlg On 11 Jun 2020, at 10:14 pm, Gabri Tofano wrote: #netstat -id NameMtu Network Address Ipkts IdropOpkts Odrop Colls em0 1500XX:XX:XX:XX:XX:XX 266894 0 202813 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 266894 0 202813 0 0 em1 1500XX:XX:XX:XX:XX:XX 170280 0 230226 1 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 170280 0 230226 1 0 em2 1500XX:XX:XX:XX:XX:XX15788 013249 2 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15788 013249 2 0 em3*1500XX:XX:XX:XX:XX:XX0 00 0 0 enc0* 00 00 0 0 pflog0 331360 029771 0 0 #netstat -ie NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls em0 1500XX:XX:XX:XX:XX:XX 26971372 205469 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 26971372 205469 0 0 em1 1500XX:XX:XX:XX:XX:XX 172137 0 232148 0 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 172137 0 232148 0 0 em2 1500XX:XX:XX:XX:XX:XX15892 013316 0 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15892 013316 0 0 em3*1500XX:XX:XX:XX:XX:XX0 00 0 0 enc0* 00 00 0 0 pflog0 331360 030174 0 0 #systat queues QUEUE BW/FL SCH PKTSBYTES DROP_P DROP_B QLEN BORROW SUSPEN P/S B/S main on em0 120M fifo000 00 defq 100M fifo 139394 215744110 00 voip10M fifo34699 49496350 00 games 10M fifo32277 24608070 00 Thank you! Gabri
Re: Interfaces errors and latency spikes with Intel 82583V
Yes, this is today without resetting the interface: #netstat -ie NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls em0 1500XX:XX:XX:XX:XX:XX 5351463 1868 3016695 0 0 em0 1500 XX:XX:XX:XX XX:XX:XX:XX:XX:XX 5351463 1868 3016695 0 0 em1 1500XX:XX:XX:XX:XX:XX 2839738 0 5147702 0 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 2839738 0 5147702 0 0 em2 1500XX:XX:XX:XX:XX:XX46977 044135 0 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX46977 044135 0 0 em3*150000:e0:67:10:9d:970 00 0 0 enc0* 00 00 0 0 pflog0 331360 0 128982 0 0 On 2020-06-11 20:29, David Gwynne wrote: Is it consistently Ierrs? dlg On 11 Jun 2020, at 10:14 pm, Gabri Tofano wrote: #netstat -id NameMtu Network Address Ipkts IdropOpkts Odrop Colls em0 1500XX:XX:XX:XX:XX:XX 266894 0 202813 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 266894 0 202813 0 0 em1 1500XX:XX:XX:XX:XX:XX 170280 0 230226 1 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 170280 0 230226 1 0 em2 1500XX:XX:XX:XX:XX:XX15788 013249 2 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15788 013249 2 0 em3*1500XX:XX:XX:XX:XX:XX0 00 0 0 enc0* 00 00 0 0 pflog0 331360 029771 0 0 #netstat -ie NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls em0 1500XX:XX:XX:XX:XX:XX 26971372 205469 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 26971372 205469 0 0 em1 1500XX:XX:XX:XX:XX:XX 172137 0 232148 0 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 172137 0 232148 0 0 em2 1500XX:XX:XX:XX:XX:XX15892 013316 0 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15892 013316 0 0 em3*1500XX:XX:XX:XX:XX:XX0 00 0 0 enc0* 00 00 0 0 pflog0 331360 030174 0 0 #systat queues QUEUE BW/FL SCH PKTSBYTES DROP_P DROP_B QLEN BORROW SUSPEN P/S B/S main on em0 120M fifo000 00 defq 100M fifo 139394 215744110 00 voip10M fifo34699 49496350 00 games 10M fifo32277 24608070 00 Thank you! Gabri
Re: Interfaces errors and latency spikes with Intel 82583V
are there any config options on the switch site relating to flow control you can try turning off? are there any counters for pause frames on the switch side too? dlg > On 12 Jun 2020, at 12:16 pm, Gabri Tofano wrote: > > Apparently it is not: > > #ifconfig em0 hwfeatures > em0: flags=808843 mtu 1500 >hwfeatures=36 hardmtu > 9216 >lladdr XX:XX:XX:XX:XX:XX >index 1 priority 0 llprio 3 >groups: egress >media: Ethernet autoselect (1000baseT full-duplex) >status: active >inet XX:XX:XX:XX netmask 0xff00 broadcast XX:XX:XX:XX > > > On 2020-06-11 21:57, David Gwynne wrote: >> Is flow control enabled? Can you try disabling rxpause and txpause? >>> On 12 Jun 2020, at 10:36 am, Gabri Tofano wrote: >>> Yes, this is today without resetting the interface: >>> #netstat -ie >>> NameMtu Network Address Ipkts IerrsOpkts Oerrs >>> Colls >>> em0 1500XX:XX:XX:XX:XX:XX 5351463 1868 3016695 0 >>> 0 >>> em0 1500 XX:XX:XX:XX XX:XX:XX:XX:XX:XX 5351463 1868 3016695 0 >>> 0 >>> em1 1500XX:XX:XX:XX:XX:XX 2839738 0 5147702 0 >>> 0 >>> em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 2839738 0 5147702 0 >>> 0 >>> em2 1500XX:XX:XX:XX:XX:XX46977 044135 0 >>> 0 >>> em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX46977 044135 0 >>> 0 >>> em3*150000:e0:67:10:9d:970 00 0 >>> 0 >>> enc0* 00 00 0 >>> 0 >>> pflog0 331360 0 128982 0 >>> 0 >>> On 2020-06-11 20:29, David Gwynne wrote: Is it consistently Ierrs? dlg > On 11 Jun 2020, at 10:14 pm, Gabri Tofano wrote: > #netstat -id > NameMtu Network Address Ipkts IdropOpkts Odrop > Colls > em0 1500XX:XX:XX:XX:XX:XX 266894 0 202813 0 > 0 > em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 266894 0 202813 0 > 0 > em1 1500XX:XX:XX:XX:XX:XX 170280 0 230226 1 > 0 > em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 170280 0 230226 1 > 0 > em2 1500XX:XX:XX:XX:XX:XX15788 013249 2 > 0 > em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15788 013249 2 > 0 > em3*1500XX:XX:XX:XX:XX:XX0 00 0 > 0 > enc0* 00 00 0 > 0 > pflog0 331360 029771 0 > 0 > #netstat -ie > NameMtu Network Address Ipkts IerrsOpkts Oerrs > Colls > em0 1500XX:XX:XX:XX:XX:XX 26971372 205469 0 > 0 > em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 26971372 205469 0 > 0 > em1 1500XX:XX:XX:XX:XX:XX 172137 0 232148 0 > 0 > em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 172137 0 232148 0 > 0 > em2 1500XX:XX:XX:XX:XX:XX15892 013316 0 > 0 > em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15892 013316 0 > 0 > em3*1500XX:XX:XX:XX:XX:XX0 00 0 > 0 > enc0* 00 00 0 > 0 > pflog0 331360 030174 0 > 0 > #systat queues > QUEUE BW/FL SCH PKTSBYTES DROP_P > DROP_B QLEN BORROW SUSPEN P/S B/S > main on em0 120M fifo000 > 00 > defq 100M fifo 139394 215744110 > 00 > voip10M fifo34699 49496350 > 00 > games 10M fifo32277 24608070 > 00 > Thank you! > Gabri
Re: Not correctly supported on OpenBSD 6.7: HPE 10/25Gb 2p 640FLR-SFP28 network adapter on HPE DL380 Gen10 servers
On Fri, Jun 12, 2020 at 12:13:42AM +0200, Mark Schneider wrote: > Hello > > > Even the 640FLR-SFP28 network adapter is listed in the "pcidump -v" output > on OpenBSD 6.7 there are no entries for it's interfaces in the output of > "ifconfig -a" > > # - > obsd67a1# grep "^ [0-9]" OBSD67-pcidump-v.txt | grep -v Intel > 1:0:0: Hewlett-Packard iLO3 Slave > 1:0:1: Matrox unknown > 1:0:2: Hewlett-Packard iLO3 Management > 1:0:4: Hewlett-Packard unknown > 2:0:0: Broadcom BCM5719 > 2:0:1: Broadcom BCM5719 > 2:0:2: Broadcom BCM5719 > 2:0:3: Broadcom BCM5719 > 18:0:0: Adaptec unknown > 177:0:0: Adaptec unknown > 178:0:0: Mellanox ConnectX-4 Lx > 178:0:1: Mellanox ConnectX-4 Lx > # - Can you try -current please? This system will likely work better with support for acpi pci host bridges, which was not enabled in 6.7.
Re: Interfaces errors and latency spikes with Intel 82583V
Is flow control enabled? Can you try disabling rxpause and txpause? > On 12 Jun 2020, at 10:36 am, Gabri Tofano wrote: > > Yes, this is today without resetting the interface: > > #netstat -ie > NameMtu Network Address Ipkts IerrsOpkts Oerrs > Colls > em0 1500XX:XX:XX:XX:XX:XX 5351463 1868 3016695 0 > 0 > em0 1500 XX:XX:XX:XX XX:XX:XX:XX:XX:XX 5351463 1868 3016695 0 > 0 > em1 1500XX:XX:XX:XX:XX:XX 2839738 0 5147702 0 > 0 > em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 2839738 0 5147702 0 > 0 > em2 1500XX:XX:XX:XX:XX:XX46977 044135 0 > 0 > em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX46977 044135 0 > 0 > em3*150000:e0:67:10:9d:970 00 0 > 0 > enc0* 00 00 0 > 0 > pflog0 331360 0 128982 0 > 0 > > > On 2020-06-11 20:29, David Gwynne wrote: >> Is it consistently Ierrs? >> dlg >>> On 11 Jun 2020, at 10:14 pm, Gabri Tofano wrote: >>> #netstat -id >>> NameMtu Network Address Ipkts IdropOpkts Odrop >>> Colls >>> em0 1500XX:XX:XX:XX:XX:XX 266894 0 202813 0 >>> 0 >>> em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 266894 0 202813 0 >>> 0 >>> em1 1500XX:XX:XX:XX:XX:XX 170280 0 230226 1 >>> 0 >>> em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 170280 0 230226 1 >>> 0 >>> em2 1500XX:XX:XX:XX:XX:XX15788 013249 2 >>> 0 >>> em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15788 013249 2 >>> 0 >>> em3*1500XX:XX:XX:XX:XX:XX0 00 0 >>> 0 >>> enc0* 00 00 0 >>> 0 >>> pflog0 331360 029771 0 >>> 0 >>> #netstat -ie >>> NameMtu Network Address Ipkts IerrsOpkts Oerrs >>> Colls >>> em0 1500XX:XX:XX:XX:XX:XX 26971372 205469 0 >>> 0 >>> em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 26971372 205469 0 >>> 0 >>> em1 1500XX:XX:XX:XX:XX:XX 172137 0 232148 0 >>> 0 >>> em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 172137 0 232148 0 >>> 0 >>> em2 1500XX:XX:XX:XX:XX:XX15892 013316 0 >>> 0 >>> em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15892 013316 0 >>> 0 >>> em3*1500XX:XX:XX:XX:XX:XX0 00 0 >>> 0 >>> enc0* 00 00 0 >>> 0 >>> pflog0 331360 030174 0 >>> 0 >>> #systat queues >>> QUEUE BW/FL SCH PKTSBYTES DROP_P >>> DROP_B QLEN BORROW SUSPEN P/S B/S >>> main on em0 120M fifo000 >>> 00 >>> defq 100M fifo 139394 215744110 >>> 00 >>> voip10M fifo34699 49496350 >>> 00 >>> games 10M fifo32277 24608070 >>> 00 >>> Thank you! >>> Gabri
Re: Interfaces errors and latency spikes with Intel 82583V
Is it consistently Ierrs? dlg > On 11 Jun 2020, at 10:14 pm, Gabri Tofano wrote: > > #netstat -id > NameMtu Network Address Ipkts IdropOpkts Odrop > Colls > em0 1500XX:XX:XX:XX:XX:XX 266894 0 202813 0 > 0 > em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 266894 0 202813 0 > 0 > em1 1500XX:XX:XX:XX:XX:XX 170280 0 230226 1 > 0 > em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 170280 0 230226 1 > 0 > em2 1500XX:XX:XX:XX:XX:XX15788 013249 2 > 0 > em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15788 013249 2 > 0 > em3*1500XX:XX:XX:XX:XX:XX0 00 0 > 0 > enc0* 00 00 0 > 0 > pflog0 331360 029771 0 > 0 > > #netstat -ie > NameMtu Network Address Ipkts IerrsOpkts Oerrs > Colls > em0 1500XX:XX:XX:XX:XX:XX 26971372 205469 0 > 0 > em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 26971372 205469 0 > 0 > em1 1500XX:XX:XX:XX:XX:XX 172137 0 232148 0 > 0 > em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 172137 0 232148 0 > 0 > em2 1500XX:XX:XX:XX:XX:XX15892 013316 0 > 0 > em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15892 013316 0 > 0 > em3*1500XX:XX:XX:XX:XX:XX0 00 0 > 0 > enc0* 00 00 0 > 0 > pflog0 331360 030174 0 > 0 > > > #systat queues > QUEUE BW/FL SCH PKTSBYTES DROP_P DROP_B > QLEN BORROW SUSPEN P/S B/S > main on em0 120M fifo0000 >0 > defq 100M fifo 139394 2157441100 > 0 > voip10M fifo34699 494963500 > 0 > games 10M fifo32277 246080700 > 0 > > Thank you! > Gabri
Re: i915_request_create+0x4b: uvm_fault
> Date: Thu, 11 Jun 2020 19:35:48 +0100 > From: Stuart Henderson > > And this, I was resizing a mupdf window at the time. Should already be fixed. See jsg's commit eralier today. > uvm_fault(0xfd87039e5890, 0x58, 0, 1) -> e > kernel: page fault trap, code=0 > Stopped at intel_partial_pages+0xf4: movq0x58,%rsi > ddb{0}> ps /o > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND > 98313 29118 10000x12 0x4001 firefox > 513012 74234 10000x12 03 i3 > 256402 98134 1000 0x2 02 xcompmgr > *495496 15497 350x12 00K Xorg > ddb{0}> tr > intel_partial_pages(81077028,80f32300) at > intel_partial_pages+0 > xf4 > ggtt_set_pages(81076e70) at ggtt_set_pages+0x5f > i915_vma_pin(81076e70,0,0,40a) at i915_vma_pin+0x406 > i915_gem_object_ggtt_pin(80f32300,80003428f9e0,0,0,a) at > i915_gem_o > bject_ggtt_pin+0xd8 > i915_gem_fault(80f32300,80003428fcf8,101925000,b5feaf63000,8000 > 3428fc00,1) at i915_gem_fault+0x3ee > drm_fault(80003428fcf8,b5feaf63000,80003428fc00,1,0,0) at > drm_fault+0x1 > 55 > uvm_fault(fd87039e5890,b5feaf63000,0,2) at uvm_fault+0x6db > pageflttrap(80003428fe70,1) at pageflttrap+0xfb > usertrap(80003428fe70) at usertrap+0x1b0 > recall_trap() at recall_trap+0x8 > end of kernel > end trace frame: 0x7f7cf710, count: -10 > ddb{0}> sh reg > rdi 0x1000__ALIGN_SIZE > rsi 0x1000__ALIGN_SIZE > rbp 0x80003428f870 > rbx0 > rdx0 > rcx 0x81102000 > rax 0x81877120 > r80x > r9 0x91 > r100x26fd86352fccbe7 > r11 0x9a94d7a63a7ccb0b > r12 0x80f32300 > r13 0x81077028 > r14 0x816e1c60 > r15 0xf5 > rip 0x818b4734intel_partial_pages+0xf4 > cs 0x8 > rflags 0x10287__ALIGN_SIZE+0xf287 > rsp 0x80003428f820 > ss 0 > intel_partial_pages+0xf4: movq0x58,%rsi > ddb{0}> mach ddbcpu 1 > Stopped at x86_ipi_db+0x12:leave > ddb{1}> tr > x86_ipi_db(800022411ff0) at x86_ipi_db+0x12 > x86_ipi_handler() at x86_ipi_handler+0x80 > Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 > _kernel_lock() at _kernel_lock+0xa2 > dofilewritev(8000349aeb18,4f,800034a8dc98,0,800034a8dd70) at > dofile > writev+0xf9 > sys_write(8000349aeb18,800034a8dd10,800034a8dd70) at > sys_write+0x51 > > syscall(800034a8dde0) at syscall+0x3b9 > Xsyscall() at Xsyscall+0x128 > end of kernel > end trace frame: 0x1e495ef0a440, count: -8 > ddb{1}> sh reg > rdi 0x800022411ff0 > rsi0 > rbp 0x800034a8da80 > rbx 0x820db068ipifunc+0x38 > rdx0 > rcx 0x7 > rax 0xff7f > r8 0 > r9 0 > r100 > r11 0x3233edf10ac64205 > r12 0x7 > r130 > r14 0x800022411ff0 > r150 > rip 0x81a79542x86_ipi_db+0x12 > cs 0x8 > rflags 0x206 > rsp 0x800034a8da70 > ss 0x10 > x86_ipi_db+0x12:leave > ddb{1}> mach ddbcpu 2 > Stopped at x86_ipi_db+0x12:leave > ddb{2}> tr > x86_ipi_db(800022422ff0) at x86_ipi_db+0x12 > x86_ipi_handler() at x86_ipi_handler+0x80 > Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 > _kernel_lock() at _kernel_lock+0xa9 > Xsyscall() at Xsyscall+0x128 > end of kernel > end trace frame: 0x7f7c3750, count: -5 > ddb{2}> sh reg > rdi 0x800022422ff0 > rsi0 > rbp 0x8000344374a0 > rbx 0x820db068ipifunc+0x38 > rdx0 > rcx 0x7 > rax 0xff7f > r8 0 > r9 0 > r100 > r11 0x3233edf10ac64205 > r12 0x7 > r130 > r14 0x800022422ff0 > r150 > rip 0x81a79542x86_ipi_db+0x12 > cs 0x8 > rflags 0x206 > rsp 0x800034437490 > ss
Re: i915_request_create+0x4b: uvm_fault
And this, I was resizing a mupdf window at the time. uvm_fault(0xfd87039e5890, 0x58, 0, 1) -> e kernel: page fault trap, code=0 Stopped at intel_partial_pages+0xf4: movq0x58,%rsi ddb{0}> ps /o TIDPIDUID PRFLAGS PFLAGS CPU COMMAND 98313 29118 10000x12 0x4001 firefox 513012 74234 10000x12 03 i3 256402 98134 1000 0x2 02 xcompmgr *495496 15497 350x12 00K Xorg ddb{0}> tr intel_partial_pages(81077028,80f32300) at intel_partial_pages+0 xf4 ggtt_set_pages(81076e70) at ggtt_set_pages+0x5f i915_vma_pin(81076e70,0,0,40a) at i915_vma_pin+0x406 i915_gem_object_ggtt_pin(80f32300,80003428f9e0,0,0,a) at i915_gem_o bject_ggtt_pin+0xd8 i915_gem_fault(80f32300,80003428fcf8,101925000,b5feaf63000,8000 3428fc00,1) at i915_gem_fault+0x3ee drm_fault(80003428fcf8,b5feaf63000,80003428fc00,1,0,0) at drm_fault+0x1 55 uvm_fault(fd87039e5890,b5feaf63000,0,2) at uvm_fault+0x6db pageflttrap(80003428fe70,1) at pageflttrap+0xfb usertrap(80003428fe70) at usertrap+0x1b0 recall_trap() at recall_trap+0x8 end of kernel end trace frame: 0x7f7cf710, count: -10 ddb{0}> sh reg rdi 0x1000__ALIGN_SIZE rsi 0x1000__ALIGN_SIZE rbp 0x80003428f870 rbx0 rdx0 rcx 0x81102000 rax 0x81877120 r80x r9 0x91 r100x26fd86352fccbe7 r11 0x9a94d7a63a7ccb0b r12 0x80f32300 r13 0x81077028 r14 0x816e1c60 r15 0xf5 rip 0x818b4734intel_partial_pages+0xf4 cs 0x8 rflags 0x10287__ALIGN_SIZE+0xf287 rsp 0x80003428f820 ss 0 intel_partial_pages+0xf4: movq0x58,%rsi ddb{0}> mach ddbcpu 1 Stopped at x86_ipi_db+0x12:leave ddb{1}> tr x86_ipi_db(800022411ff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 _kernel_lock() at _kernel_lock+0xa2 dofilewritev(8000349aeb18,4f,800034a8dc98,0,800034a8dd70) at dofile writev+0xf9 sys_write(8000349aeb18,800034a8dd10,800034a8dd70) at sys_write+0x51 syscall(800034a8dde0) at syscall+0x3b9 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x1e495ef0a440, count: -8 ddb{1}> sh reg rdi 0x800022411ff0 rsi0 rbp 0x800034a8da80 rbx 0x820db068ipifunc+0x38 rdx0 rcx 0x7 rax 0xff7f r8 0 r9 0 r100 r11 0x3233edf10ac64205 r12 0x7 r130 r14 0x800022411ff0 r150 rip 0x81a79542x86_ipi_db+0x12 cs 0x8 rflags 0x206 rsp 0x800034a8da70 ss 0x10 x86_ipi_db+0x12:leave ddb{1}> mach ddbcpu 2 Stopped at x86_ipi_db+0x12:leave ddb{2}> tr x86_ipi_db(800022422ff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 _kernel_lock() at _kernel_lock+0xa9 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7c3750, count: -5 ddb{2}> sh reg rdi 0x800022422ff0 rsi0 rbp 0x8000344374a0 rbx 0x820db068ipifunc+0x38 rdx0 rcx 0x7 rax 0xff7f r8 0 r9 0 r100 r11 0x3233edf10ac64205 r12 0x7 r130 r14 0x800022422ff0 r150 rip 0x81a79542x86_ipi_db+0x12 cs 0x8 rflags 0x206 rsp 0x800034437490 ss 0x10 x86_ipi_db+0x12:leave ddb{2}> mach ddbcpu 3 Stopped at x86_ipi_db+0x12:leave ddb{3}> tr x86_ipi_db(80002242bff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 _kernel_lock() at _kernel_lock+0xa2 sosend(fd866e5b9b28,0,8000344af6a0,0,0,80) at sosend+0x121
Re: athn0 works in 6.6, fails in 6.7
On Thu, Jun 11, 2020 at 10:14:34AM -0500, Tim Chase wrote: > On booting 6.7 I see > > - > athn0: no link > athn0: no link... got link > athn0: no link... sleeping > - > > which is not a surprise having seen the "no network" in the ifconfig > output. > > I'm not sure how to go about diagnosing what changed here. One thing you could do is adding 'debug' to your hostname.athn0 file, or running 'ifconfig athn0 debug', and then trying to connect. This should make debug messages appear in dmesg and /var/log/messages, which might contain clues. Perhaps the problem has already been fixed in -current? To verify this you could boot a -current bsd.rd kernel and check if the interface works with it (choose 'shell' at the initial prompt, then configure the interface manually with ifconfig, and run 'dhclient athn0').
Re: man double free
Hi Klemens, Klemens Nanni wrote on Thu, Jun 11, 2020 at 06:32:46PM +0200: > On Thu, Jun 11, 2020 at 06:03:20PM +0200, Ingo Schwarze wrote: >> Indeed, i came up with exactly the same diff and had already >> written this commit message, but was still testing: >> >> Fix a regression in rev. 1.238 (2019/07/26): >> Pass the right object to html_reset() or it will crash >> when rendering more than one manual page to HTML in a row. >> Bug reported by Abel Romero Perez . > Wasn't this just reshuffling the already existing html_reset() which > was introduced in r1.222? Oh right, i only looked far enough to see that the argument of html_reset() changed in that commit, but you are right that the previous argument (curp) wasn't correct either. So it seems it was even broken a few months longer. No matter, now at least it has the right argument. Thanks for having another look, Ingo
Re: man double free
Ingo Schwarze wrote: > Hi, > > Theo de Raadt wrote on Thu, Jun 11, 2020 at 10:12:47AM -0600: > > Romero Perez, Abel wrote: > > >> I suggest only to have a look into better measures of security by > >> researching optimization flags, to find an equilibrium of optimization > >> and security. > > > Romero, that is bullshit. > > However, there is something i ought to do to make such bugs less > likely: Remove the last vestigial type-unsafe pointer handling. > That was designed a decade ago with an excessive focus on flexibility > when the scope of the program was not yet clear. A typical example > of over-abstraction. When you don't know yet how general your code > might need to be, write specific code first. If it turns out > additional situations need to be handled, consider generalizing it > (and again, don't go overboard). Never invent abstractions "because > just in case". > > If we would need many dozens of different output formats, and people > would want to plug in new ones at run time or something crazy like > that, the abstraction implemented with these void pointers might > have a point. But now that we know that less than a dozen output > formats are really needed, and that they are all very stable, there > are very likely ways to improve this code, making it more robust > and less error-prone. No way Ingo, you should be carefully use the compiler -O option! It is the way to security, expert Romero has spoken!
Re: man double free
Hi, Theo de Raadt wrote on Thu, Jun 11, 2020 at 10:12:47AM -0600: > Romero Perez, Abel wrote: >> I suggest only to have a look into better measures of security by >> researching optimization flags, to find an equilibrium of optimization >> and security. > Romero, that is bullshit. However, there is something i ought to do to make such bugs less likely: Remove the last vestigial type-unsafe pointer handling. That was designed a decade ago with an excessive focus on flexibility when the scope of the program was not yet clear. A typical example of over-abstraction. When you don't know yet how general your code might need to be, write specific code first. If it turns out additional situations need to be handled, consider generalizing it (and again, don't go overboard). Never invent abstractions "because just in case". If we would need many dozens of different output formats, and people would want to plug in new ones at run time or something crazy like that, the abstraction implemented with these void pointers might have a point. But now that we know that less than a dozen output formats are really needed, and that they are all very stable, there are very likely ways to improve this code, making it more robust and less error-prone. Yours, Ingo
Re: man double free
On Thu, Jun 11, 2020 at 06:03:20PM +0200, Ingo Schwarze wrote: > Indeed, i came up with exactly the same diff and had already > written this commit message, but was still testing: > > Fix a regression in rev. 1.238 (2019/07/26): > Pass the right object to html_reset() or it will crash > when rendering more than one manual page to HTML in a row. > Bug reported by Abel Romero Perez . Wasn't this just reshuffling the already existing html_reset() which was introduced in r1.222?
Re: man double free
On Thu, Jun 11, 2020 at 05:07:17PM +0200, Otto Moerbeek wrote: > This fixes it for me, This looks like a simple mistake introduced back in main.c r1.222: date: 2019/03/03 13:01:47; author: schwarze; state: Exp; lines: +3 -1; Reset HTML formatter state, in particular the id_unique hash, after processing each manual page, such that the next page starts from a clean state and doesn't continue suffix numbering. Issue found while looking at https://github.com/Debian/debiman/issues/48 which was brought up by Orestis Ioannou . outst is on the stack and html_reset_internal() expects a struct html pointer, but this obviously mismatches and eventually free()s stack memory. 820 if (outst->had_output && outst->outtype <= OUTT_UTF8) { 821 if (outst->outdata == NULL) 822 outdata_alloc(outst, &conf->output); 823 terminal_sepline(outst->outdata); 824 } 826 if (resp->form == FORM_SRC) 827 parse(mp, fd, resp->file, outst, &conf->output); 828 else { outdata_alloc() properly allocates a struct html with html_alloc() in our case which must be reset later in parse() through html_reset(). Pretty sure your diff is correct, but won't hurt to hear from Ingo before committing. OK kn
Re: Interfaces errors and latency spikes with Intel 82583V
#netstat -id NameMtu Network Address Ipkts IdropOpkts Odrop Colls em0 1500XX:XX:XX:XX:XX:XX 266894 0 202813 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 266894 0 202813 0 0 em1 1500XX:XX:XX:XX:XX:XX 170280 0 230226 1 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 170280 0 230226 1 0 em2 1500XX:XX:XX:XX:XX:XX15788 013249 2 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15788 013249 2 0 em3*1500XX:XX:XX:XX:XX:XX0 00 0 0 enc0* 00 00 0 0 pflog0 331360 029771 0 0 #netstat -ie NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls em0 1500XX:XX:XX:XX:XX:XX 26971372 205469 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 26971372 205469 0 0 em1 1500XX:XX:XX:XX:XX:XX 172137 0 232148 0 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX 172137 0 232148 0 0 em2 1500XX:XX:XX:XX:XX:XX15892 013316 0 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX15892 013316 0 0 em3*1500XX:XX:XX:XX:XX:XX0 00 0 0 enc0* 00 00 0 0 pflog0 331360 030174 0 0 #systat queues QUEUE BW/FL SCH PKTSBYTES DROP_P DROP_B QLEN BORROW SUSPEN P/S B/S main on em0 120M fifo000 00 defq 100M fifo 139394 215744110 00 voip10M fifo34699 49496350 00 games 10M fifo32277 24608070 00 Thank you! Gabri On 2020-06-11 07:35, David Gwynne wrote: The Ifail and Ofail columns are a sum of queue drops and errors. Could you run that netstat command with -d and -e so we can see the drops and errors separately? Cheers, dlg On 11 Jun 2020, at 2:21 pm, Gabri Tofano wrote: After extensive testing the latency spikes shown up again: To the inside interface of the firewall: Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=132ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 And to the firewall's next hop (ISP ONT) at the same time: Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=242ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Interface errors are now showing up just on the output: #netstat -i NameMtu Network Address Ipkts IfailOpkts Ofail Colls em0 1500XX:XX:XX:XX:XX:XX22655 041589 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX22655 041589 0 0 em1 1500XX:XX:XX:XX:XX:XX39924 020476 1 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX39924 020476 1 0 em2 1500XX:XX:XX:XX:XX:XX 427 0 330 2 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:
Re: man double free
Romero Pérez, Abel wrote: > Yes, thank you. > > I suggest only to have a look into better measures of security by > researching optimization flags, to find an equilibrium of optimization > and security. Romero, that is bullshit.
Re: man double free
Yes, thank you. I suggest only to have a look into better measures of security by researching optimization flags, to find an equilibrium of optimization and security. But I said to forget it because it was hard to explain. On 2020-06-11 18:06, Theo de Raadt wrote: Otto Moerbeek wrote: On Thu, Jun 11, 2020 at 05:15:28PM +0200, Romero Pérez, Abel wrote: On 2020-06-11 17:07, Otto Moerbeek wrote: On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote: On 2020-06-11 16:45, Klemens Nanni wrote: On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote: This already trips the bug; man -T html -c pfctl id No need for a custom man function. No clue yet why. This is in mandoc's HTML parser, but only happens for multiple manuals in html.c:html_reset_internal(): 164 while ((tag = h->tag) != NULL) { 165 h->tag = tag->next; 166 free(tag); 167 } Note that it crashes differently depending on the optimization level: $ cd /usr/src/usr.bin/mandoc $ make DEBUG=-O0 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null ; echo $? 0 $ make DEBUG=-O1 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null Segmentation fault (core dumped) $ make DEBUG=-O2 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null mandoc(32092) in free(): bogus pointer (double free?) 0x6641bab613b Abort trap (core dumped) Need to run now, but wanted to share what seems to be the right direction. Compile with -O0 to fix temporally the bug. But, I also want to note that a binary is not need to be specified, can be a just a file... (as second man entry). This fixes it for me, -Otto Index: main.c === RCS file: /cvs/src/usr.bin/mandoc/main.c,v retrieving revision 1.247 diff -u -p -r1.247 main.c --- main.c 24 Feb 2020 21:15:05 - 1.247 +++ main.c 11 Jun 2020 15:06:43 - @@ -872,7 +872,7 @@ parse(struct mparse *mp, int fd, const c if (outst->outdata == NULL) outdata_alloc(outst, outconf); else if (outst->outtype == OUTT_HTML) - html_reset(outst); + html_reset(outst->outdata); mandoc_xr_reset(); meta = mparse_result(mp); Only one comment, don't use -O0 flag as optimization (disabled) to hunt more bugs of this kind. I have no clue what you mean by above sentence. If code has a bug, optmization level might cause the bug to be hidden or exposed; it can work both ways. The person who didn't fix the bug is giving you advice about fixing the bug.
Re: man double free
Otto Moerbeek wrote: > On Thu, Jun 11, 2020 at 05:15:28PM +0200, Romero Pérez, Abel wrote: > > > > > > > On 2020-06-11 17:07, Otto Moerbeek wrote: > > > On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote: > > > > > > > > > > > > > > > On 2020-06-11 16:45, Klemens Nanni wrote: > > > > > On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote: > > > > > > This already trips the bug; > > > > > > > > > > > > man -T html -c pfctl id > > > > > > > > > > > > No need for a custom man function. No clue yet why. > > > > > This is in mandoc's HTML parser, but only happens for multiple manuals > > > > > in html.c:html_reset_internal(): > > > > > > > > > > 164 while ((tag = h->tag) != NULL) { > > > > > 165 h->tag = tag->next; > > > > > 166 free(tag); > > > > > 167 } > > > > > > > > > > Note that it crashes differently depending on the optimization level: > > > > > > > > > > $ cd /usr/src/usr.bin/mandoc > > > > > $ make DEBUG=-O0 > > > > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null ; echo $? > > > > > 0 > > > > > > > > > > $ make DEBUG=-O1 > > > > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null > > > > > Segmentation fault (core dumped) > > > > > > > > > > $ make DEBUG=-O2 > > > > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null > > > > > mandoc(32092) in free(): bogus pointer (double free?) > > > > > 0x6641bab613b > > > > > Abort trap (core dumped) > > > > > > > > > > Need to run now, but wanted to share what seems to be the right > > > > > direction. > > > > > > > > > Compile with -O0 to fix temporally the bug. > > > > But, I also want to note that a binary is not need to be specified, can > > > > be a > > > > just a file... (as second man entry). > > > > > > > > > > This fixes it for me, > > > > > > -Otto > > > > > > Index: main.c > > > === > > > RCS file: /cvs/src/usr.bin/mandoc/main.c,v > > > retrieving revision 1.247 > > > diff -u -p -r1.247 main.c > > > --- main.c24 Feb 2020 21:15:05 - 1.247 > > > +++ main.c11 Jun 2020 15:06:43 - > > > @@ -872,7 +872,7 @@ parse(struct mparse *mp, int fd, const c > > > if (outst->outdata == NULL) > > > outdata_alloc(outst, outconf); > > > else if (outst->outtype == OUTT_HTML) > > > - html_reset(outst); > > > + html_reset(outst->outdata); > > > mandoc_xr_reset(); > > > meta = mparse_result(mp); > > > > > Only one comment, don't use -O0 flag as optimization (disabled) to hunt more > > bugs of this kind. > > I have no clue what you mean by above sentence. If code has a bug, > optmization level might cause the bug to be hidden or exposed; it can > work both ways. The person who didn't fix the bug is giving you advice about fixing the bug.
Re: man double free
Hi Otto, Otto Moerbeek wrote on Thu, Jun 11, 2020 at 05:07:17PM +0200: > This fixes it for me, Indeed, i came up with exactly the same diff and had already written this commit message, but was still testing: Fix a regression in rev. 1.238 (2019/07/26): Pass the right object to html_reset() or it will crash when rendering more than one manual page to HTML in a row. Bug reported by Abel Romero Perez . Given that you published the diff earlier, please commit, OK schwarze@. This teaches once again that having type safety is really useful and artificially circumventing it tends to invite trouble. On first sight, it seems surprising that such a blatant regression could survive almost a year. Then again, the reason probably is that .. isn't really valid HTML in the first place, so i guess few people are using -T html with more than one input file at a time, and hence the bug doesn't really bite in practically relevant use cases. Yours, Ingo > Index: main.c > === > RCS file: /cvs/src/usr.bin/mandoc/main.c,v > retrieving revision 1.247 > diff -u -p -r1.247 main.c > --- main.c24 Feb 2020 21:15:05 - 1.247 > +++ main.c11 Jun 2020 15:06:43 - > @@ -872,7 +872,7 @@ parse(struct mparse *mp, int fd, const c > if (outst->outdata == NULL) > outdata_alloc(outst, outconf); > else if (outst->outtype == OUTT_HTML) > - html_reset(outst); > + html_reset(outst->outdata); > > mandoc_xr_reset(); > meta = mparse_result(mp); >
Re: man double free
On Thu, Jun 11, 2020 at 05:15:28PM +0200, Romero Pérez, Abel wrote: > > > On 2020-06-11 17:07, Otto Moerbeek wrote: > > On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote: > > > > > > > > > > > On 2020-06-11 16:45, Klemens Nanni wrote: > > > > On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote: > > > > > This already trips the bug; > > > > > > > > > > man -T html -c pfctl id > > > > > > > > > > No need for a custom man function. No clue yet why. > > > > This is in mandoc's HTML parser, but only happens for multiple manuals > > > > in html.c:html_reset_internal(): > > > > > > > > 164 while ((tag = h->tag) != NULL) { > > > > 165 h->tag = tag->next; > > > > 166 free(tag); > > > > 167 } > > > > > > > > Note that it crashes differently depending on the optimization level: > > > > > > > > $ cd /usr/src/usr.bin/mandoc > > > > $ make DEBUG=-O0 > > > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null ; echo $? > > > > 0 > > > > > > > > $ make DEBUG=-O1 > > > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null > > > > Segmentation fault (core dumped) > > > > > > > > $ make DEBUG=-O2 > > > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null > > > > mandoc(32092) in free(): bogus pointer (double free?) > > > > 0x6641bab613b > > > > Abort trap (core dumped) > > > > > > > > Need to run now, but wanted to share what seems to be the right > > > > direction. > > > > > > > Compile with -O0 to fix temporally the bug. > > > But, I also want to note that a binary is not need to be specified, can > > > be a > > > just a file... (as second man entry). > > > > > > > This fixes it for me, > > > > -Otto > > > > Index: main.c > > === > > RCS file: /cvs/src/usr.bin/mandoc/main.c,v > > retrieving revision 1.247 > > diff -u -p -r1.247 main.c > > --- main.c 24 Feb 2020 21:15:05 - 1.247 > > +++ main.c 11 Jun 2020 15:06:43 - > > @@ -872,7 +872,7 @@ parse(struct mparse *mp, int fd, const c > > if (outst->outdata == NULL) > > outdata_alloc(outst, outconf); > > else if (outst->outtype == OUTT_HTML) > > - html_reset(outst); > > + html_reset(outst->outdata); > > mandoc_xr_reset(); > > meta = mparse_result(mp); > > > Only one comment, don't use -O0 flag as optimization (disabled) to hunt more > bugs of this kind. I have no clue what you mean by above sentence. If code has a bug, optmization level might cause the bug to be hidden or exposed; it can work both ways. -Otto > > Thanks by the patch. >
Re: man double free
On 2020-06-11 17:07, Otto Moerbeek wrote: On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote: On 2020-06-11 16:45, Klemens Nanni wrote: On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote: This already trips the bug; man -T html -c pfctl id No need for a custom man function. No clue yet why. This is in mandoc's HTML parser, but only happens for multiple manuals in html.c:html_reset_internal(): 164 while ((tag = h->tag) != NULL) { 165 h->tag = tag->next; 166 free(tag); 167 } Note that it crashes differently depending on the optimization level: $ cd /usr/src/usr.bin/mandoc $ make DEBUG=-O0 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null ; echo $? 0 $ make DEBUG=-O1 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null Segmentation fault (core dumped) $ make DEBUG=-O2 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null mandoc(32092) in free(): bogus pointer (double free?) 0x6641bab613b Abort trap (core dumped) Need to run now, but wanted to share what seems to be the right direction. Compile with -O0 to fix temporally the bug. But, I also want to note that a binary is not need to be specified, can be a just a file... (as second man entry). This fixes it for me, -Otto Index: main.c === RCS file: /cvs/src/usr.bin/mandoc/main.c,v retrieving revision 1.247 diff -u -p -r1.247 main.c --- main.c 24 Feb 2020 21:15:05 - 1.247 +++ main.c 11 Jun 2020 15:06:43 - @@ -872,7 +872,7 @@ parse(struct mparse *mp, int fd, const c if (outst->outdata == NULL) outdata_alloc(outst, outconf); else if (outst->outtype == OUTT_HTML) - html_reset(outst); + html_reset(outst->outdata); mandoc_xr_reset(); meta = mparse_result(mp); Only one comment, don't use -O0 flag as optimization (disabled) to hunt more bugs of this kind. Thanks by the patch.
Re: man double free
On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote: > > > On 2020-06-11 16:45, Klemens Nanni wrote: > > On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote: > > > This already trips the bug; > > > > > > man -T html -c pfctl id > > > > > > No need for a custom man function. No clue yet why. > > This is in mandoc's HTML parser, but only happens for multiple manuals > > in html.c:html_reset_internal(): > > > > 164 while ((tag = h->tag) != NULL) { > > 165 h->tag = tag->next; > > 166 free(tag); > > 167 } > > > > Note that it crashes differently depending on the optimization level: > > > > $ cd /usr/src/usr.bin/mandoc > > $ make DEBUG=-O0 > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null ; echo $? > > 0 > > > > $ make DEBUG=-O1 > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null > > Segmentation fault (core dumped) > > > > $ make DEBUG=-O2 > > $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null > > mandoc(32092) in free(): bogus pointer (double free?) 0x6641bab613b > > Abort trap (core dumped) > > > > Need to run now, but wanted to share what seems to be the right direction. > > > Compile with -O0 to fix temporally the bug. > But, I also want to note that a binary is not need to be specified, can be a > just a file... (as second man entry). > This fixes it for me, -Otto Index: main.c === RCS file: /cvs/src/usr.bin/mandoc/main.c,v retrieving revision 1.247 diff -u -p -r1.247 main.c --- main.c 24 Feb 2020 21:15:05 - 1.247 +++ main.c 11 Jun 2020 15:06:43 - @@ -872,7 +872,7 @@ parse(struct mparse *mp, int fd, const c if (outst->outdata == NULL) outdata_alloc(outst, outconf); else if (outst->outtype == OUTT_HTML) - html_reset(outst); + html_reset(outst->outdata); mandoc_xr_reset(); meta = mparse_result(mp);
Re: man double free
On 2020-06-11 16:45, Klemens Nanni wrote: On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote: This already trips the bug; man -T html -c pfctl id No need for a custom man function. No clue yet why. This is in mandoc's HTML parser, but only happens for multiple manuals in html.c:html_reset_internal(): 164 while ((tag = h->tag) != NULL) { 165 h->tag = tag->next; 166 free(tag); 167 } Note that it crashes differently depending on the optimization level: $ cd /usr/src/usr.bin/mandoc $ make DEBUG=-O0 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null ; echo $? 0 $ make DEBUG=-O1 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null Segmentation fault (core dumped) $ make DEBUG=-O2 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null mandoc(32092) in free(): bogus pointer (double free?) 0x6641bab613b Abort trap (core dumped) Need to run now, but wanted to share what seems to be the right direction. Compile with -O0 to fix temporally the bug. But, I also want to note that a binary is not need to be specified, can be a just a file... (as second man entry).
Re: man double free
On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote: > This already trips the bug; > > man -T html -c pfctl id > > No need for a custom man function. No clue yet why. This is in mandoc's HTML parser, but only happens for multiple manuals in html.c:html_reset_internal(): 164 while ((tag = h->tag) != NULL) { 165 h->tag = tag->next; 166 free(tag); 167 } Note that it crashes differently depending on the optimization level: $ cd /usr/src/usr.bin/mandoc $ make DEBUG=-O0 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null ; echo $? 0 $ make DEBUG=-O1 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null Segmentation fault (core dumped) $ make DEBUG=-O2 $ ./obj/mandoc -Thtml `man -w id cat` >/dev/null mandoc(32092) in free(): bogus pointer (double free?) 0x6641bab613b Abort trap (core dumped) Need to run now, but wanted to share what seems to be the right direction.
Re: man double free
On 2020-06-11 16:13, Romero Pérez, Abel wrote: On 2020-06-11 15:59, Otto Moerbeek wrote: On Thu, Jun 11, 2020 at 03:15:55PM +0200, Romero Pérez, Abel wrote: I've got a: man(13835) in free(): bogus pointer (double free?) 0x22c43c2813b To check please, add the following function to .kshrc and run . ./.kshrc: function man { set -A array "$@" tag=${array[$#-1]} PAGER="" MANPAGER="" /usr/bin/man -T html -c pfctl $@ > /tmp/man.html | lynx /tmp/man.html#$tag #PAGER="" MANPAGER="" /usr/bin/man -T html -c $@ | lynx -stdin } Then launch on prompt: man id The result if exploited is on screenshot, but on console as follows: foo$ man id Abort trap foo$ This already trips the bug; man -T html -c pfctl id No need for a custom man function. No clue yet why. -Otto Confirmed, it exploits also with your cmd-line. It seems to crash only when a binary on $PATH is specified as 2nd man entry (for example id). -Abel.
Re: man double free
On 2020-06-11 15:59, Otto Moerbeek wrote: On Thu, Jun 11, 2020 at 03:15:55PM +0200, Romero Pérez, Abel wrote: I've got a: man(13835) in free(): bogus pointer (double free?) 0x22c43c2813b To check please, add the following function to .kshrc and run . ./.kshrc: function man { set -A array "$@" tag=${array[$#-1]} PAGER="" MANPAGER="" /usr/bin/man -T html -c pfctl $@ > /tmp/man.html | lynx /tmp/man.html#$tag #PAGER="" MANPAGER="" /usr/bin/man -T html -c $@ | lynx -stdin } Then launch on prompt: man id The result if exploited is on screenshot, but on console as follows: foo$ man id Abort trap foo$ This already trips the bug; man -T html -c pfctl id No need for a custom man function. No clue yet why. -Otto Confirmed, it exploits also with your cmd-line.
Re: man double free
On Thu, Jun 11, 2020 at 03:15:55PM +0200, Romero Pérez, Abel wrote: > I've got a: man(13835) in free(): bogus pointer (double free?) 0x22c43c2813b > > To check please, add the following function to .kshrc and run . ./.kshrc: > > > function man { > set -A array "$@" > tag=${array[$#-1]} > PAGER="" MANPAGER="" /usr/bin/man -T html -c pfctl $@ > /tmp/man.html | > lynx /tmp/man.html#$tag > #PAGER="" MANPAGER="" /usr/bin/man -T html -c $@ | lynx -stdin > } > > Then launch on prompt: man id > > > The result if exploited is on screenshot, but on console as follows: > > foo$ man id > Abort trap > foo$ > This already trips the bug; man -T html -c pfctl id No need for a custom man function. No clue yet why. -Otto
i915_request_create+0x4b: uvm_fault
I came back to a machine which had died with a uvm_fault in i915_request_create. traces/sh reg/ps/disassembly of the function/dmesg below. It's not a GENERIC kernel but I'll send the information anyway because the changes don't seem especially likely to be implicated. Kernel is GENERIC.MP + options KQUEUE_DEBUG + pseudo-device dt + clock_gettime diff. uvm_fault(0xfd86dc92f000, 0x51, 0, 1) -> e kernel: page fault trap, code=0 Stopped at i915_request_create+0x4b: movq0x50(%r14),%rdi ddb{1}> ps /o TIDPIDUID PRFLAGS PFLAGS CPU COMMAND 449802 67311 10000x12 00 jq 407113 31444755 0x2 02 php-7.4 48223 655467320x200802 0x40020003 mongod *517013 31216 350x12 01K Xorg ddb{1}> tr i915_request_create(fd880f4e99d8) at i915_request_create+0x4b i915_gem_do_execbuffer(80122078,80e10800,8000340d7020,81760800,0) at i915_gem_do_execbuffer+0x2bdb i915_gem_execbuffer2_ioctl(80122078,8000340d7020,80e10800) at i915_gem_execbuffer2_ioctl+0x1ec drm_do_ioctl(80122078,100,80406469,8000340d7020) at drm_do_ioctl+0x274 drmioctl(15700,80406469,8000340d7020,7,800033cba758) at drmioctl+0xdc VOP_IOCTL(fd87242a14f0,80406469,8000340d7020,7,fd86dd920ec0,800033cba758) at VOP_IOCTL+0x55 vn_ioctl(fd872253cb58,80406469,8000340d7020,800033cba758) at vn_ioctl+0x75 sys_ioctl(800033cba758,8000340d7130,8000340d7190) at sys_ioctl+0x2df syscall(8000340d7200) at syscall+0x3b9 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7c4310, count: -10 ddb{1}> sh reg rdi 0x8000340d6790 rsi 0x1 rbp 0x8000340d6870 rbx 0x81732098 rdx0 rcx 0x1 rax 0x51 r8 0x11 r90x81ff85e0rw_ops+0x10 r10 0x3 r11 0xfa811d8f9f11700e r12 0x8068d900 r13 0x810cf068 r14 0x1 r15 0xfd880f4e99d8 rip 0x813b70abi915_request_create+0x4b cs 0x8 rflags 0x10207__ALIGN_SIZE+0xf207 rsp 0x8000340d6840 ss 0x10 i915_request_create+0x4b: movq0x50(%r14),%rdi ddb{1}> mach ddbcpu 2 Stopped at x86_ipi_db+0x12:leave ddb{2}> tr x86_ipi_db(800022422ff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 _kernel_lock() at _kernel_lock+0xa2 usertrap(8000358ecb00) at usertrap+0x1b0 recall_trap() at recall_trap+0x8 end of kernel end trace frame: 0x7f7f6370, count: -6 ddb{2}> sh reg rdi 0x800022422ff0 rsi0 rbp 0x8000358ec930 rbx 0x821080a8ipifunc+0x38 rdx0 rcx 0x7 rax 0xff7f r8 0 r9 0 r100 r11 0x81e3a26a7fed6779 r12 0x7 r130 r14 0x800022422ff0 r150 rip 0x814dbd02x86_ipi_db+0x12 cs 0x8 rflags 0x282 rsp 0x8000358ec920 ss 0 x86_ipi_db+0x12:leave ddb{2}> mach ddbcpu 3 Stopped at x86_ipi_db+0x12:leave ddb{3}> tr x86_ipi_db(80002242bff0) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23 __mp_acquire_count(8218b388,1) at __mp_acquire_count+0x8b mi_switch() at mi_switch+0x2a2 yield() at yield+0x8a coredump_write(800035cb91b0,0,5e8b95c1000,400) at coredump_write+0x60 coredump_elf(800035549af0,800035cb91b0) at coredump_elf+0x133 coredump(800035549af0) at coredump+0x394 trapsignal(800035549af0,a,4,3,5e84ad5c9c9) at trapsignal+0x123 usertrap(800035cb9380) at usertrap+0x14f recall_trap() at recall_trap+0x8 end of kernel end trace frame: 0x5e88b139250, count: -12 ddb{3}> sh reg rdi 0x80002242bff0 rsi0 rbp 0x800035cb8d70 rbx 0x821080a8ipifunc+0x38 rdx0 rcx 0x7 rax 0xff7f r8 0 r9 0 r100 r11 0x81e3a26a7fed6779 r12 0x7 r13
Some bugs.
OpenBSD 6.7 shuts down automatically after a several minutes of starting.I have upgraded my laptop to OpenBSD 6.7, but it shuts down automatically.Also, amdgpu(4) firmware not working on my AMD Radeon R4 on OpenBSD 6.7 (it worked on 6.6). dmesg (OpenBSD): > OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 3624251392 (3456MB) > avail mem = 3501789184 (3339MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xbbb52000 (44 entries) > bios0: vendor LENOVO version "8UCN09WW" date 07/27/2018 > bios0: LENOVO 81D6 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST WSMT POAT BATB SSDT IVRS > CRAT VFCT TPM2 SSDT SSDT SSDT SSDT FPDT SSDT BGRT UEFI > acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) > GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 16 (boot processor) > cpu0: AMD A6-9225 RADEON R4, 5 COMPUTE CORES 2C+3G, 2600.29 MHz, 15-70-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT > cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 17 (application processor) > cpu1: AMD A6-9225 RADEON R4, 5 COMPUTE CORES 2C+3G, 2600.00 MHz, 15-70-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT > cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: smt 1, core 0, package 0 > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped > ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (GPP0) > acpiprt2 at acpi0: bus -1 (GPP1) > acpiprt3 at acpi0: bus 1 (GPP2) > acpiprt4 at acpi0: bus 2 (GPP3) > acpiprt5 at acpi0: bus -1 (GPP4) > acpiprt6 at acpi0: bus -1 (GFX0) > acpiprt7 at acpi0: bus -1 (GFX1) > acpiprt8 at acpi0: bus -1 (GFX2) > acpiprt9 at acpi0: bus -1 (GFX3) > acpiprt10 at acpi0: bus -1 (GFX4) > acpiec0 at acpi0 > acpicpu0 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS > acpicpu1 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS > acpipwrres0 at acpi0: P0U3, resource for XHC0 > acpipwrres1 at acpi0: P3U3, resource for XHC0 > acpipwrres2 at acpi0: P0U2, resource for EHC1 > acpipwrres3 at acpi0: P3U2, resource for EHC1 > acpipwrres4 at acpi0: P0SD > acpipwrres5 at acpi0: P3SD > acpipwrres6 at acpi0: P0ST, resource for SATA > acpipwrres7 at acpi0: P3ST, resource for SATA > acpibtn0 at acpi0: PWRB > acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x > acpicmos0 at acpi0 > acpibat0 at acpi0: BAT0 model "L17L2PF1" serial 2884 type LiP oem "LGC" > "VPC2004" at acpi0 not configured > acpiac0 at acpi0: AC unit offline > acpibtn1 at acpi0: LID_ > "PNP0C14" at acpi0 not configured > amdgpio0 at acpi0: GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins > "AMD0010" at acpi0 not configured > "AUI1666" at acpi0 not configured > "MSFT0101" at acpi0 not configured > acpivideo0 at acpi0: VGA_ > acpivideo1 at acpi0: VGA_ > acpivideo2 at acpi0: VGA_ > acpivout0 at acpivideo2: LCD_ > cpu0: 2600 MHz: speeds: 2600 2400 2200 1900 1600 1300 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "AMD 15h Root Complex" rev 0x00 > "AMD 15h IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured > amdgpu0 at pci0 dev 1 function 0 "ATI Stoney Ridge" rev 0xea > drm0 at amdgpu0 > amdgpu0: msi > azalia0 at pci0 dev 1 function 1 vendor "ATI", unknown product 0x15b3 rev > 0x00: msi > azal
Re: awk: FS pattern separation issue
On Thu, 11 Jun 2020 06:09:02 -0600 Todd C. Miller wrote: > This should be fixed by the commit I just made to awk/lib.c. > The strlcpy() length parameter was incorrect. > > - todd I can confirm that with the neofetch test case, thanks a lot!
Re: awk: FS pattern separation issue
This should be fixed by the commit I just made to awk/lib.c. The strlcpy() length parameter was incorrect. - todd
Re: awk: i386 broken
On 2020/06/11 05:59, Todd C. Miller wrote: > On Thu, 11 Jun 2020 12:36:27 +0100, Stuart Henderson wrote: > > > This "fixes" it ... > > > > I think the most sensible approach for now is the backout diff > > in my previous mail. Any OKs for that? > > The strlcpy() is wrong now that inputFS is a pointer. > It should be: > > strlcpy(inputFS, *FS, len_inputFS); > > - todd > OK
Re: awk: i386 broken
On Thu, 11 Jun 2020 12:36:27 +0100, Stuart Henderson wrote: > This "fixes" it ... > > I think the most sensible approach for now is the backout diff > in my previous mail. Any OKs for that? The strlcpy() is wrong now that inputFS is a pointer. It should be: strlcpy(inputFS, *FS, len_inputFS); - todd
Re: Interfaces errors and latency spikes with Intel 82583V
The Ifail and Ofail columns are a sum of queue drops and errors. Could you run that netstat command with -d and -e so we can see the drops and errors separately? Cheers, dlg > On 11 Jun 2020, at 2:21 pm, Gabri Tofano wrote: > > After extensive testing the latency spikes shown up again: > > To the inside interface of the firewall: > > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time=132ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 > > And to the firewall's next hop (ISP ONT) at the same time: > > Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=242ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 > Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 > > Interface errors are now showing up just on the output: > > #netstat -i > NameMtu Network Address Ipkts IfailOpkts Ofail > Colls > em0 1500XX:XX:XX:XX:XX:XX22655 041589 0 > 0 > em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX22655 041589 0 > 0 > em1 1500XX:XX:XX:XX:XX:XX39924 020476 1 > 0 > em1 1500 172.16.200. XX:XX:XX:XX:XX:XX39924 020476 1 > 0 > em2 1500XX:XX:XX:XX:XX:XX 427 0 330 2 > 0 > em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX 427 0 330 2 > 0 > em3*1500XX:XX:XX:XX:XX:XX0 00 0 > 0 > enc0* 00 00 0 > 0 > pflog0 331360 0 1294 0 > 0 > > UDP real time traffic is the most affected one as very sensitive and I keep \ > having spikes meanwhile playing online. > > Thank you! > Gabri > > On 2020-06-10 22:50, Gabri Tofano wrote: >> Another user pointed out to me that in the OpenBSD 6.7 release notes >> there is a statement in regards of the em(4) drivers: "Improvements in >> the em(4) driver." and so I have gave it a try and reinstalled with >> OpenBSD 6.6. It looks like that the system is now stable and latency >> spikes/interface errors are not present at all even under heavy >> traffic loads. I am not sure what introduced the issue but maybe one >> of the devs can give it a look? >> Thank you! >> Gabri >> On 2020-06-09 13:01, Gabri Tofano wrote: >>> Hi all, >>> I'm using a "Protectli FW1" with FreeBSD 12.1 amd64 as a firewall >>> which is serving me with great performances and no issues at all. The >>> appliance has 4 Intel Gigabit 82583V Ethernet NIC ports which are >>> working very well. I have used PFsense as well prior to FreeBSD and it >>> worked without issues too. >>> I took the decision to move to OpenBSD 6.7 amd64 in order to benefit >>> of the latest pf (and other) features but unfortunately the OS is >>> giving me an issue which I guess is related to the NIC drivers; When I >>> was connected via ssh I felt some glitches meanwhile I was >>> typing/moving around with the editor, so I started to ping the inside >>> interface from a wired connected pc and found out that time to time >>> the appliance is responding with a 100+/200+ ms response (I have cut >>> some 1ms reply to make it shorter): >>> Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 >>> Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 >
Re: awk: i386 broken
On 2020/06/11 12:23, Stuart Henderson wrote: > On 2020/06/11 12:07, Stuart Henderson wrote: > > On 2020/06/11 12:05, Stuart Henderson wrote: > > > I am going to start a ports build with the January 5 version, i.e. the > > > following backout: > > > > This backout fixes neofetch (the problem found by cwen) as well. > > > > The upstream version from https://github.com/onetrueawk/awk does not > show the problem with neofetch. It doesn't like the awk script from > libgpg-error so I haven't confirmed whether it fixes libgpg-error too. > This "fixes" it ... I think the most sensible approach for now is the backout diff in my previous mail. Any OKs for that? Index: lib.c === RCS file: /cvs/src/usr.bin/awk/lib.c,v retrieving revision 1.35 diff -u -p -r1.35 lib.c --- lib.c 10 Jun 2020 21:06:09 - 1.35 +++ lib.c 11 Jun 2020 11:31:38 - @@ -124,7 +124,7 @@ void savefs(void) { size_t len; if ((len = strlen(getsval(fsloc))) < len_inputFS) { - strlcpy(inputFS, *FS, sizeof(inputFS)); /* for subsequent field splitting */ + strcpy(inputFS, *FS); /* for subsequent field splitting */ return; }
Re: awk: i386 broken
On 2020/06/11 12:07, Stuart Henderson wrote: > On 2020/06/11 12:05, Stuart Henderson wrote: > > I am going to start a ports build with the January 5 version, i.e. the > > following backout: > > This backout fixes neofetch (the problem found by cwen) as well. > The upstream version from https://github.com/onetrueawk/awk does not show the problem with neofetch. It doesn't like the awk script from libgpg-error so I haven't confirmed whether it fixes libgpg-error too.
Re: awk: FS pattern separation issue
On Thu, 11 Jun 2020 11:50:48 +0100 Stuart Henderson wrote: > On 2020/06/11 11:48, Charlene Wendling wrote: > > >Synopsis: FS pattern separation issue > > >Category: awk > > >Environment: > > System : OpenBSD 6.7 > > Details : OpenBSD 6.7-current (GENERIC.MP) #258: Wed > > Jun 10 20:46:20 MDT 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > > > In the latest awk we're proposing, FS pattern separation > > does not work properly and makes neofetch fail to properly get > > the screen resolution: > > > > $ xrandr --nograb --current | awk -F 'connected |\+|\(' '/ > > connected/ && $2 {printf $2 ", "}' > > ed primary 1920x1080+0+0 (normal left inverted right x axis y axis) > > 521mm x 293mm, > > It would be better to show the exact text fed into awk, xrandr depends > on the machine you run it on. > > For all the old versions I get this with your command: > > illegal primary in regular expression connected |+|( at |( > You're right, and i don't know why but some escapes in my command vanished. I'm attaching a shell test case that will compare with mawk and gawk if they're available. awk_testcase Description: Binary data
Re: awk: i386 broken
On 2020/06/11 12:05, Stuart Henderson wrote: > I am going to start a ports build with the January 5 version, i.e. the > following backout: This backout fixes neofetch (the problem found by cwen) as well.
awk: i386 broken
See attached test case extracted from libgpg-error, it fails on i386 but works on amd64. (ports/lang/gcc failed too, I forgot to save the build directory). TZ=GMT cvs up -D '2020/06/10 21:05:00' January 5, 2020 works as expected TZ=GMT cvs up -D '2020/06/10 21:05:10' January 31, 2020 building awk fails TZ=GMT cvs up -D '2020/06/10 21:05:50' February 28, 2020 building awk works, test case fails $ cc -E -P _mkerrcodes.h | grep GPG_ERR_ | awk -f ./mkerrcodes.awk > /dev/null awk: nonterminated character class [ input record number 2, file source line number 93 *** Error 2 in /tmp/awk-problem (Makefile:4 'all') I am going to start a ports build with the January 5 version, i.e. the following backout: Index: FIXES === RCS file: /cvs/src/usr.bin/awk/FIXES,v retrieving revision 1.33 diff -u -p -r1.33 FIXES --- FIXES 10 Jun 2020 21:06:09 - 1.33 +++ FIXES 11 Jun 2020 11:02:48 - @@ -1,4 +1,4 @@ -/* $OpenBSD: FIXES,v 1.33 2020/06/10 21:06:09 millert Exp $*/ +/* $OpenBSD: FIXES,v 1.30 2020/06/10 21:04:40 millert Exp $*/ / Copyright (C) Lucent Technologies 1997 All Rights Reserved @@ -26,60 +26,6 @@ THIS SOFTWARE. This file lists all bug fixes, changes, etc., made since the AWK book was sent to the printers in August, 1987. -June 5, 2020: - In fldbld(), make sure that inputFS is set before trying to - use it. Thanks to Steffen Nurpmeso - for the report. - -May 5, 2020: - Fix checks for compilers that can handle noreturn. Thanks to - GitHub user enh-google for pointing it out. Closes Issue #79. - -April 16, 2020: - Handle old compilers that don't support C11 (for noreturn). - Thanks to Arnold Robbins. - -April 5, 2020: - Use and noreturn instead of GCC attributes. - Thanks to GitHub user awkfan77. Closes PR #77. - -February 28, 2020: - More cleanups from Christos Zoulas: notably backslash continuation - inside strings removes the newline and a fix for RS = "^a". - Fix for address sanitizer-found problem. Thanks to GitHub user - enh-google. - -February 19, 2020: - More small cleanups from Christos Zoulas. - -February 18, 2020: - Additional cleanups from Christos Zoulas. It's no longer necessary - to use the -y flag to bison. - -February 6, 2020: - Additional small cleanups from Christos Zoulas. awk is now - a little more robust about reporting I/O errors upon exit. - -January 31, 2020: - Merge PR #70, which avoids use of variable length arrays. Thanks - to GitHub user michaelforney. Fix issue #60 ({0} in interval - expressions doesn't work). Also get all tests working again. - Thanks to Arnold Robbins. - -January 24, 2020: - A number of small cleanups from Christos Zoulas. Add the close - on exec flag to files/pipes opened for redirection; courtesy of - Arnold Robbins. - -January 19, 2020: - If POSIXLY_CORRECT is set in the environment, then sub and gsub - use POSIX rules for multiple backslashes. This fixes Issue #66, - while maintaining backwards compatibility. - -January 9, 2020: - Input/output errors on closing files are now fatal instead of - mere warnings. Thanks to Martijn Dekker . - January 5, 2020: Fix a bug in the concatentation of two string constants into one done in the grammar. Fixes GitHub issue #61. Thanks @@ -118,13 +64,13 @@ October 25, 2019: October 24, 2019: Import second round of code cleanups from NetBSD. Much thanks - to Christos Zoulas (GitHub user zoulasc). Merges PR 53. + to Christos Zoulas (Github user zoulasc). Merges PR 53. Add an optimization for string concatenation, also from Christos. October 17, 2019: Import code cleanups from NetBSD. Much thanks to Christos - Zoulas (GitHub user zoulasc). Merges PR 51. + Zoulas (Github user zoulasc). Merges PR 51. October 6, 2019: Import code from NetBSD awk that implements RS as a regular @@ -132,7 +78,7 @@ October 6, 2019: September 10, 2019: Fixes for various array / memory overruns found via gcc's - -fsanitize=unknown. Thanks to Alexander Richardson (GitHub + -fsanitize=unknown. Thanks to Alexander Richardson (Github user arichardson). Merges PRs 47 and 48. July 28, 2019: Index: README.md === RCS file: /cvs/src/usr.bin/awk/README.md,v retrieving revision 1.2 diff -u -p -r1.2 README.md --- README.md 10 Jun 2020 21:05:50 - 1.2 +++ README.md 11 Jun 2020 11:02:48 - @@ -1,4 +1,4 @@ -$OpenBSD: README.md,v 1.2 2020/06/10 21:05:50 millert Exp $ +$OpenBSD: README.md,v 1.1 2020/06/10 21:04:40 millert Exp $ # The One True Awk @@ -44,19 +44,7 @@ Thanks. ## Submitting Pull Reques
Re: drm panic
On Thu, Jun 11, 2020 at 11:07:11AM +0100, Laurence Tratt wrote: > The recent DRM update has fixed one long-ish-standing bug for me where Xorg > sometimes would get stuck while executing Xsession (I could never work out > why) which is really good! > > However I've now had the following kernel panic several times: > > kernel: page fault trap, code=0 > Stopped at intel_partial_pages+0xf4:moq 0x58,%rsi > > Unfortunately that also seems to take out my keyboard at ddb so I have no > further information beyond my dmesg :/ Try this, the code in question does sg_set_page(sg, NULL, I915_GTT_PAGE_SIZE, 0); sg_dma_address(sg) = i915_gem_object_get_dma_address(obj, src_idx); sg_dma_len(sg) = I915_GTT_PAGE_SIZE; VM_PAGE_TO_PHYS() will attempt to deref NULL. Index: sys/dev/pci/drm/include/linux/scatterlist.h === RCS file: /cvs/src/sys/dev/pci/drm/include/linux/scatterlist.h,v retrieving revision 1.2 diff -u -p -r1.2 scatterlist.h --- sys/dev/pci/drm/include/linux/scatterlist.h 8 Jun 2020 04:48:15 - 1.2 +++ sys/dev/pci/drm/include/linux/scatterlist.h 11 Jun 2020 10:54:05 - @@ -115,7 +115,8 @@ sg_set_page(struct scatterlist *sgl, str unsigned int length, unsigned int offset) { sgl->__page = page; - sgl->dma_address = VM_PAGE_TO_PHYS(page); + if (page != NULL) + sgl->dma_address = VM_PAGE_TO_PHYS(page); sgl->offset = offset; sgl->length = length; sgl->end = false;
Re: drm panic
> Date: Thu, 11 Jun 2020 11:07:11 +0100 > From: Laurence Tratt > > The recent DRM update has fixed one long-ish-standing bug for me where Xorg > sometimes would get stuck while executing Xsession (I could never work out > why) which is really good! > > However I've now had the following kernel panic several times: > > kernel: page fault trap, code=0 > Stopped at intel_partial_pages+0xf4:moq 0x58,%rsi > > Unfortunately that also seems to take out my keyboard at ddb so I have no > further information beyond my dmesg :/ That is a bit unforunate; more information would be useful... Can you put the following line in /etc/sysctl.conf: machdep.forceukbd=1 and reboot? That might help the next time you hit this. > OpenBSD 6.7-current (GENERIC.MP) #258: Wed Jun 10 20:46:20 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17028239360 (16239MB) > avail mem = 16497246208 (15733MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xc320 (89 entries) > bios0: vendor American Megatrends Inc. version "3805" date 05/16/2018 > bios0: ASUSTeK COMPUTER INC. Z170M-PLUS > acpi0 at bios0: ACPI 6.1 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT BGRT MCFG SSDT FIDT SSDT SSDT HPET SSDT > SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) > SIO1(S3) UAR1(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) > RP12(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4011.41 MHz, 06-5e-03 > 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 24MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4009.91 MHz, 06-5e-03 > 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4009.91 MHz, 06-5e-03 > 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4009.91 MHz, 06-5e-03 > 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 0, core 3, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpihpet0 at acpi0: 2399 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG0) > acpiprt2 at acpi0: bus -1 (PEG1) > acpiprt3 at acpi0: bus -1 (P
Re: awk: FS pattern separation issue
On 2020/06/11 11:48, Charlene Wendling wrote: > >Synopsis:FS pattern separation issue > >Category:awk > >Environment: > System : OpenBSD 6.7 > Details : OpenBSD 6.7-current (GENERIC.MP) #258: Wed Jun 10 > 20:46:20 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > > In the latest awk we're proposing, FS pattern separation does > not work properly and makes neofetch fail to properly get > the screen resolution: > > $ xrandr --nograb --current | awk -F 'connected |\+|\(' '/ connected/ > && $2 {printf $2 ", "}' > ed primary 1920x1080+0+0 (normal left inverted right x axis y axis) > 521mm x 293mm, It would be better to show the exact text fed into awk, xrandr depends on the machine you run it on. For all the old versions I get this with your command: illegal primary in regular expression connected |+|( at |(
drm panic
The recent DRM update has fixed one long-ish-standing bug for me where Xorg sometimes would get stuck while executing Xsession (I could never work out why) which is really good! However I've now had the following kernel panic several times: kernel: page fault trap, code=0 Stopped at intel_partial_pages+0xf4:moq 0x58,%rsi Unfortunately that also seems to take out my keyboard at ddb so I have no further information beyond my dmesg :/ Laurie OpenBSD 6.7-current (GENERIC.MP) #258: Wed Jun 10 20:46:20 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17028239360 (16239MB) avail mem = 16497246208 (15733MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xc320 (89 entries) bios0: vendor American Megatrends Inc. version "3805" date 05/16/2018 bios0: ASUSTeK COMPUTER INC. Z170M-PLUS acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT BGRT MCFG SSDT FIDT SSDT SSDT HPET SSDT SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) SIO1(S3) UAR1(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4011.41 MHz, 06-5e-03 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4009.91 MHz, 06-5e-03 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4009.91 MHz, 06-5e-03 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4009.91 MHz, 06-5e-03 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 4 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus -1 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus 3 (RP01) acpiprt10 at acpi0: bus -1 (RP02) acpiprt11 at acpi0: bus -1 (RP03) acpiprt12 at acpi0: bus -1 (RP04) acpiprt13 at acpi0: bus -1 (RP05) acpiprt14 at acpi0: bus -1 (RP06) acpiprt15 at ac
awk: FS pattern separation issue
>Synopsis: FS pattern separation issue >Category: awk >Environment: System : OpenBSD 6.7 Details : OpenBSD 6.7-current (GENERIC.MP) #258: Wed Jun 10 20:46:20 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: In the latest awk we're proposing, FS pattern separation does not work properly and makes neofetch fail to properly get the screen resolution: $ xrandr --nograb --current | awk -F 'connected |\+|\(' '/ connected/ && $2 {printf $2 ", "}' ed primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm, Using mawk or gawk, or our previous version of awk returns "primary 1920x1080," as expected. >Fix: None. Charlène.
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
Hi Gerhard, Today I added Your patches to 6.7-stable and moved back LTE modem to USB 3.0. So, just waiting for… nothing or kernel panic. I’ll let you know. > On 8 Jun 2020, at 19:13, Patrick Wildt wrote: > > On Mon, Jun 08, 2020 at 05:31:44PM +0200, Gerhard Roth wrote: >> On 2020-05-25 13:19, Martin Pieuchot wrote: >>> On 25/05/20(Mon) 12:56, Gerhard Roth wrote: On 5/22/20 9:05 PM, Mark Kettenis wrote: >> From: Łukasz Lejtkowski >> Date: Fri, 22 May 2020 20:51:57 +0200 >> >> Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) - >> too high. Should be 12,25-12,50 V. I replaced to the new one. > > That might be why the device stops responding. The fact that cleaning > up from a failed USB transaction leads to this panic is a bug though. > > And somebody just posted a very similar panic with ure(4). Something > in the network stack is holding a mutex when it shouldn't. I think that holding the mutex is ok. The bug is calling the stop routine in case of errors. This is what common foo_start() does: m_head = ifq_deq_begin(&ifp->if_snd); if (foo_encap(sc, m_head, 0)) { ifq_deq_rollback(&ifp->if_snd, m_head); ... return; } ifq_deq_commit(&ifp->if_snd, m_head); Here, ifq_deq_begin() grabs a mutex and it is held while calling foo_encap(). For USB network interfaces foo_encap() mostly does this: err = usbd_transfer(sc->sc_xfer); if (err != USBD_IN_PROGRESS) { foo_stop(sc); return EIO; } And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(), which might sleep. How to fix? We could do the foo_encap() after the ifq_deq_commit(), possibly dropping the current mbuf if encap fails (who cares for the packets after foo_stop() anyway). >>> >>> That's the approach taken by drivers using ifq_dequeue(9) instead of >>> ifq_deq_begin/commit(). >>> Or change all the drivers to follow the path that if_aue.c takes: err = usbd_transfer(c->aue_xfer); if (err != USBD_IN_PROGRESS) { ... /* Stop the interface from process context. */ usb_add_task(sc->aue_udev, &sc->aue_stop_task); return (EIO); } >>> >>> That's just trading the current problem for another one with higher >>> complexity. >>> Any ideas, what's better? Or alternative proposals? >>> >>> Using ifq_dequeue(9) would have the advantage of unifying the code base. >>> It introduces a behavior change. A simpler fix would be to call >>> foo_stop() in the error path after ifq_deq_rollback(). >>> >> >> Hi, >> >> two weeks passed any nobody objected Martin's proposal. So I thought, >> we could try to move on this way. >> >> Gerhard >> > > From what I remember from various discussions, the goal should be to > check if there's a buffer free in the ring, then dequeue and send, and > it it can't be sent out, then drop it. With USB apparently those > drivers "always" have an open buffer, so we can just dequeue and send, > like you do in this diff. And if it gets dropped, that's fine. > > That said, I think IFQ_DEQUEUE() is old compat code, and we actually > nowadays prefer: > > m_head = ifq_dequeue(&ifp->if_snd); > > If you look at the define for IFQ_DEQUEUE() you'll see it's marked > as compat code. If you look at a new driver, like ixl(4), you'll > see that it also uses ifq_dequeue(). > > Sorry to to give you some work, but with that fixed: ok patrick@ > > Patrick > >> >> Index: sys/dev/usb/if_axe.c >> === >> RCS file: /cvs/src/sys/dev/usb/if_axe.c,v >> retrieving revision 1.139 >> diff -u -p -u -p -r1.139 if_axe.c >> --- sys/dev/usb/if_axe.c 7 Jul 2019 06:40:10 - 1.139 >> +++ sys/dev/usb/if_axe.c 8 Jun 2020 15:13:25 - >> @@ -1223,6 +1223,7 @@ axe_encap(struct axe_softc *sc, struct m >> /* Transmit */ >> err = usbd_transfer(c->axe_xfer); >> if (err != USBD_IN_PROGRESS) { >> +c->axe_mbuf = NULL; >> axe_stop(sc); >> return(EIO); >> } >> @@ -1246,16 +1247,15 @@ axe_start(struct ifnet *ifp) >> if (ifq_is_oactive(&ifp->if_snd)) >> return; >> >> -m_head = ifq_deq_begin(&ifp->if_snd); >> +IFQ_DEQUEUE(&ifp->if_snd, m_head); >> if (m_head == NULL) >> return; >> >> if (axe_encap(sc, m_head, 0)) { >> -ifq_deq_rollback(&ifp->if_snd, m_head); >> +m_freem(m_head); >> ifq_set_oactive(&ifp->if_snd); >> return; >> } >> -ifq_deq_commit(&ifp->if_snd, m_head); >> >> /* >> * If there's a BPF listener, bounce a copy of this frame >> Index: sys/dev/usb/if_axen.c >> =
Re: Interfaces errors and latency spikes with Intel 82583V
After extensive testing the latency spikes shown up again: To the inside interface of the firewall: Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=132ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 And to the firewall's next hop (ISP ONT) at the same time: Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=242ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=2ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=1ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Reply from 74.215.235.1: bytes=32 time=3ms TTL=62 Interface errors are now showing up just on the output: #netstat -i NameMtu Network Address Ipkts IfailOpkts Ofail Colls em0 1500XX:XX:XX:XX:XX:XX22655 041589 0 0 em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX22655 041589 0 0 em1 1500XX:XX:XX:XX:XX:XX39924 020476 1 0 em1 1500 172.16.200. XX:XX:XX:XX:XX:XX39924 020476 1 0 em2 1500XX:XX:XX:XX:XX:XX 427 0 330 2 0 em2 1500 172.16.103/ XX:XX:XX:XX:XX:XX 427 0 330 2 0 em3*1500XX:XX:XX:XX:XX:XX0 00 0 0 enc0* 00 00 0 0 pflog0 331360 0 1294 0 0 UDP real time traffic is the most affected one as very sensitive and I keep \ having spikes meanwhile playing online. Thank you! Gabri On 2020-06-10 22:50, Gabri Tofano wrote: Another user pointed out to me that in the OpenBSD 6.7 release notes there is a statement in regards of the em(4) drivers: "Improvements in the em(4) driver." and so I have gave it a try and reinstalled with OpenBSD 6.6. It looks like that the system is now stable and latency spikes/interface errors are not present at all even under heavy traffic loads. I am not sure what introduced the issue but maybe one of the devs can give it a look? Thank you! Gabri On 2020-06-09 13:01, Gabri Tofano wrote: Hi all, I'm using a "Protectli FW1" with FreeBSD 12.1 amd64 as a firewall which is serving me with great performances and no issues at all. The appliance has 4 Intel Gigabit 82583V Ethernet NIC ports which are working very well. I have used PFsense as well prior to FreeBSD and it worked without issues too. I took the decision to move to OpenBSD 6.7 amd64 in order to benefit of the latest pf (and other) features but unfortunately the OS is giving me an issue which I guess is related to the NIC drivers; When I was connected via ssh I felt some glitches meanwhile I was typing/moving around with the editor, so I started to ping the inside interface from a wired connected pc and found out that time to time the appliance is responding with a 100+/200+ ms response (I have cut some 1ms reply to make it shorter): Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=163ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254 Reply from 172.16.200.1: bytes=32 time=2ms TTL=254 Reply from 172.16.200.1: bytes=32 time=1ms TTL=254 Reply from 172.16.200.1: bytes=32 time<1ms TTL=254