Re: timekeep: fixing large skews on amd64 with RDTSCP

2020-08-23 Thread Hrvoje Popovski
On 23.8.2020. 16:50, Claudio Jeker wrote: > On Sun, Aug 23, 2020 at 04:06:01PM +0200, Christian Weisgerber wrote: >> Scott Cheloha: >> >>> This "it might slow down the network stack" thing keeps coming up, and >>> yet nobody can point to (a) who expressed this concern or (b) what the >>> penalty

Re: kstats for em(4)

2020-07-07 Thread Hrvoje Popovski
On 7.7.2020. 10:51, David Gwynne wrote: > unfortunately em(4) covers a lot of chips of different vintages, so if > anyone has a super old one they can try this diff on with kstat enabled > in their kernel config, that would be appreciated. Hi, don't know if 82576 is old or super old but here

Re: fix races in if_clone_create()

2020-06-29 Thread Hrvoje Popovski
On 29.6.2020. 10:59, Vitaliy Makkoveev wrote: > I reworked tool for reproduce. Now I avoided fork()/exec() route and it > takes couple of minutes to take panic on 4 cores. Also some screenshots > attached. > > I hope anyone else will try it. Hi, i'm getting panic quite fast :) i will leave box

Re: vlan and bridge panic with latest snapshot

2020-06-22 Thread Hrvoje Popovski
On 22.6.2020. 11:11, Claudio Jeker wrote: > On Sun, Jun 21, 2020 at 08:51:53PM +0200, Hrvoje Popovski wrote: >> Hi all, >> >> with today's snapshot from 21-Jun-2020 09:34 >> OpenBSD 6.7-current (GENERIC.MP) #286: Sun Jun 21 08:51:29 MDT 2020 >> dera...@amd64.op

vlan and bridge panic with latest snapshot

2020-06-21 Thread Hrvoje Popovski
Hi all, with today's snapshot from 21-Jun-2020 09:34 OpenBSD 6.7-current (GENERIC.MP) #286: Sun Jun 21 08:51:29 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP if i do "ifconfig vlan" i'm getting assert x3550m4# ifconfig vlan vlan100: flags=8splassert:

Re: multiple rings and cpus for ix(4)

2020-06-17 Thread Hrvoje Popovski
On 17.6.2020. 13:13, Jonathan Matthew wrote: > On Wed, Jun 17, 2020 at 12:50:46PM +0200, Hrvoje Popovski wrote: >> On 17.6.2020. 12:45, Hrvoje Popovski wrote: >>> On 17.6.2020. 11:27, Hrvoje Popovski wrote: >>>> On 17.6.2020. 10:36, David Gwynne wrote: >>>

Re: multiple rings and cpus for ix(4)

2020-06-17 Thread Hrvoje Popovski
On 17.6.2020. 12:45, Hrvoje Popovski wrote: > On 17.6.2020. 11:27, Hrvoje Popovski wrote: >> On 17.6.2020. 10:36, David Gwynne wrote: >>> this is an updated version of a diff from christiano haesbaert by way of >>> mpi@ to enable the use of multiple tx and rx rings w

Re: multiple rings and cpus for ix(4)

2020-06-17 Thread Hrvoje Popovski
On 17.6.2020. 11:27, Hrvoje Popovski wrote: > On 17.6.2020. 10:36, David Gwynne wrote: >> this is an updated version of a diff from christiano haesbaert by way of >> mpi@ to enable the use of multiple tx and rx rings with msi-x. >> >> the high level description is tha

Re: multiple rings and cpus for ix(4)

2020-06-17 Thread Hrvoje Popovski
On 17.6.2020. 10:36, David Gwynne wrote: > this is an updated version of a diff from christiano haesbaert by way of > mpi@ to enable the use of multiple tx and rx rings with msi-x. > > the high level description is that that driver checks to see if msix is > available, and if so how many vectors

Re: em(4) hw setup vs queues

2020-03-03 Thread Hrvoje Popovski
On 3.3.2020. 11:37, Martin Pieuchot wrote: > Currently em_hw_init() uses some hardcorded values to configure TX > rings. Diff below convert it to use the value of the first queue. > This is currently a no-op. It makes the code consistent with the > rest of the driver and reduce the size of

Re: em(4) towards multiqueues

2020-02-16 Thread Hrvoje Popovski
On 14.2.2020. 18:28, Martin Pieuchot wrote: > I'm running this on: > > em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi > em0 at pci0 dev 20 function 0 "Intel I354 SGMII" rev 0x03: msi > > More tests are always welcome ;) em0 at pci0 dev 25 function 0 "Intel 82579LM" rev

Re: bnxt(4), myx(4), vr(4): refill timeouts: timeout_add(..., 0) -> timeout_add(..., 1)

2020-01-20 Thread Hrvoje Popovski
On 20.1.2020. 17:40, Scott Cheloha wrote: > Appreciate the testing. np, i like testing network stuff :) > Given what dlg@ has said in the past I think there should only be a > performance change in a livelock situation. yeah, that could be problem with this testing ... kern.netlivelocks=6

Re: em(4) diff to test

2020-01-20 Thread Hrvoje Popovski
On 20.1.2020. 16:42, Martin Pieuchot wrote: > Diff below is a refactoring of the actual em(4) code and defines that > will allows me to present a shorter diff to interrupt multiple CPUs and > make use of multiple queues. > > It contains the following items: > > - Abstract the

Re: bnxt(4), myx(4), vr(4): refill timeouts: timeout_add(..., 0) -> timeout_add(..., 1)

2020-01-20 Thread Hrvoje Popovski
On 16.1.2020. 18:45, Scott Cheloha wrote: > Here's a first batch of conversions: rx refill timeouts for bnxt(4), > myx(4), and vr(4). All of these can run during a softclock(). Will > changing these to one tick break these drivers? Hi all, i tried this diff with myx and performance are the

acpicpu log in dmesg

2020-01-13 Thread Hrvoje Popovski
Hi all, with today's snapshot i'm seeing acpipci log below in dmesg. is this ok? do i need to report it ? acpipci0 at acpi0 PC00: 0x 0x0011 0x0001 extent `acpipci0 pcibus' (0x0 - 0xff), flags=0 0x40 - 0xff extent `acpipci0 pciio' (0x0 - 0x), flags=0 0x3b0 -

pcidevs and usbdevs in Dell r7515

2020-01-08 Thread Hrvoje Popovski
Hi all, in attachment you can find diff with some new AMD devices found in Dell R7515. pcidevs are from https://raw.githubusercontent.com/pciutils/pciids/master/pci.ids and usbdevs are from https://usb-ids.gowdy.us/read/UD/1604/10c0 https://certification.ubuntu.com/catalog/component/1604:10c0

Re: Dell PowerEdge R7515

2019-12-22 Thread Hrvoje Popovski
On 20.12.2019. 16:45, Hrvoje Popovski wrote: > Hi, > > installation went very well but i can't reboot or halt box, it stops at > syncing disks... done and i need to power off .. > cpu on that box is 32/64 cores, when HT is enabled i'm seeing this log Dec 22 19:53:46 r7515 /bsd

Re: ix(4) need support for X553

2019-12-02 Thread Hrvoje Popovski
On 18.11.2019. 0:31, Hrvoje Popovski wrote: > On 14.11.2019. 1:06, Stuart Henderson wrote: >> Apart from the obvious style(9) problems, can anyone give me guidance on >> how to approach this diff? I'm quite uneasy at the amount of changes but >> these >> nics are quite

Re: ix(4) need support for X553

2019-11-17 Thread Hrvoje Popovski
On 14.11.2019. 1:06, Stuart Henderson wrote: > Apart from the obvious style(9) problems, can anyone give me guidance on > how to approach this diff? I'm quite uneasy at the amount of changes but these > nics are quite important, they're all over the place on Atom C3xxx boards > which are pretty

Re: TSC synchronization on MP machines

2019-08-07 Thread Hrvoje Popovski
On 6.8.2019. 22:29, Paul Irofti wrote: > Hi, > > Here is a fourth diff addressing all the issues so far, that have been > mainly pointed out by kettenis@, thanks! > > Changes: > - stop resetting the observed drift as it does not affect tsc > re-initialization on resume, thus

Re: move to interface rx queue backpressure for if_rxr livelock detection

2019-07-04 Thread Hrvoje Popovski
On 1.7.2019. 3:16, David Gwynne wrote: > interface rx queue processing includes detection of when the stack > becomes too busy to process packets. > > there's three stages to this mechanism. firstly, everything is fine > and the packets are simply queued for processing. the second is the >

tcpdump: send_fd: sendmsg(3): Broken pipe

2019-06-05 Thread Hrvoje Popovski
Hi all, when closing tcpdump while sending high rate traffic over box i'm getting log below: x3550m4# tcpdump -ni ix1 ^C x3550m4# tcpdump: send_fd: sendmsg(3): Broken pipe tcpdump: send_fd: sendmsg: expected sent 1 got -1 OpenBSD 6.5-current (GENERIC.MP) #6: Tue Jun 4 15:05:10 MDT 2019

Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

2019-06-04 Thread Hrvoje Popovski
On 2.6.2019. 21:41, Martin Pieuchot wrote: > On 01/06/19(Sat) 18:55, Martin Pieuchot wrote: >> Diff below exists mainly for documentation and test purposes. If >> you're not interested about how to break the scheduler internals in >> pieces, don't read further and go straight to testing! >

Re: stack trace / free(0) in isascan()

2019-05-09 Thread Hrvoje Popovski
On 9.5.2019. 11:14, Sebastien Marie wrote: > On Thu, May 09, 2019 at 10:55:44AM +0200, Hrvoje Popovski wrote: >> >> with this diff i'm getting new traces > > it is (somehow) expected. > > the commit that starts showing traces do the following: > - when there is

Re: stack trace / free(0) in isascan()

2019-05-09 Thread Hrvoje Popovski
On 9.5.2019. 10:35, Sebastien Marie wrote: > On Thu, May 09, 2019 at 10:12:49AM +0200, Hrvoje Popovski wrote: >> Hi all, >> >> i update kernel from cvs few minutes ago and i'm seeing this stack trace >> in dmesg. i'm just reporting it. > > The principe of the g

stack trace

2019-05-09 Thread Hrvoje Popovski
Hi all, i update kernel from cvs few minutes ago and i'm seeing this stack trace in dmesg. i'm just reporting it. free with zero size: (2) Starting stack trace... free(80074100,2,0,80074100,1d5a05b47900fbf4,81d287e8) at free+0xd8

Re: sfp module info and diagnostics

2019-04-09 Thread Hrvoje Popovski
On 8.4.2019. 22:13, Stuart Henderson wrote: > On 2019/04/08 19:55, Hrvoje Popovski wrote: >> On 8.4.2019. 11:33, David Gwynne wrote: >>> this updates the ifconfig part of the diff >> This is great feature... thank you .. >> it would be great if dBm could be exp

Re: sfp module info and diagnostics

2019-04-09 Thread Hrvoje Popovski
On 8.4.2019. 19:55, Hrvoje Popovski wrote: > On 8.4.2019. 11:33, David Gwynne wrote: >> this updates the ifconfig part of the diff > > This is great feature... thank you .. maybe to put laser wavelength in sff output? ix0 - 1000BASE-LX x3550m4# ifconfig ix0 sff ix0: ide

Re: sfp module info and diagnostics

2019-04-08 Thread Hrvoje Popovski
On 8.4.2019. 11:33, David Gwynne wrote: > this updates the ifconfig part of the diff This is great feature... thank you .. it would be great if dBm could be exported via snmp :) switch - Dell S4810 ix0 - sfp+ 10GBASE-SR optics ix1 - sfp 1000BASE-SX optics ixl0 - 10G passive DAC cables

Re: bypass interface input queues for vlan(4)

2019-03-22 Thread Hrvoje Popovski
; input. part of what if input does is count the packets. because vlan >>>>> already has per cpu counters for bypassing queues on output, we can use >>>>> them again for input from any cpu. if i ever get round to making a >>>>> driver handle multiple rx ring

carp demote counter

2018-10-18 Thread Hrvoje Popovski
hi all, while playing around with carp, pfsync, pflow and doing ifconfig pfsync0 destroy && sh netstart in loop i noticed that carp demote counter becomes really high r710-2# ifconfig -g carp carp: carp demote count 4321 don't know is this normal or not but problem is that i can't lower that

Re: acpi panic on dell r640 and r740xd

2018-10-17 Thread Hrvoje Popovski
On 17.10.2018. 9:47, Luthing wrote: > Did you find something for making this work? > > Regards could you try install snapshot or wait for few day when 6.4 will be stable ?

Re: pfsync: avoid a recursion on PF_LOCK

2018-09-28 Thread Hrvoje Popovski
On 27.9.2018. 23:37, Alexandr Nedvedicky wrote: > On Thu, Sep 27, 2018 at 11:30:09PM +0200, Hrvoje Popovski wrote: >> On 27.9.2018. 18:34, Alexandr Nedvedicky wrote: >>> Mentioning parallelism: there is yet another change you need to perform >>> in order to get more

Re: ix0/1/2/3 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:xxxxxxx

2018-09-18 Thread Hrvoje Popovski
On 18.9.2018. 18:18, sven falempin wrote: > On Tue, Sep 18, 2018 at 4:39 AM Hrvoje Popovski wrote: > >> On 17.9.2018. 22:32, sven falempin wrote: >>> Dear Tech reader, >>> >>> I am recently working on Intel(R) Atom(TM) CPU C3758 intel devices. >>&g

Re: ix0/1/2/3 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:xxxxxxx

2018-09-18 Thread Hrvoje Popovski
On 17.9.2018. 22:32, sven falempin wrote: > Dear Tech reader, > > I am recently working on Intel(R) Atom(TM) CPU C3758 intel devices. > SFP Intel card are not working in 6.3/current openBSD base > > I did patch intel driver reading netbsd, freebsd and intel code of ixgbe > driver. > > I am

witness log

2018-06-05 Thread Hrvoje Popovski
Hi, i'm sorry if this witness log is noise. this box is samba and nfs server and transmission client. i can drop to ddb if needed lock order reversal: 1st 0xff020bf5e730 vmmaplk (>lock) @ /usr/src/sys/uvm/uvm_map.c:4433 2nd 0xff01ed655d68 inode (>i_lock) @

Re: Unlock 16 network-related syscalls

2018-05-25 Thread Hrvoje Popovski
On 25.5.2018. 10:35, Martin Pieuchot wrote: > Updated diff that should prevent reported hangs, as analyzed by tb@ and > visa@. with this diff i can't reproduce lockup .. tnx ..

Re: Unlock 16 network-related syscalls

2018-05-24 Thread Hrvoje Popovski
On 23.5.2018. 15:29, Theo Buehler wrote: > On Wed, May 23, 2018 at 02:39:20PM +0200, Martin Pieuchot wrote: >> On 23/05/18(Wed) 11:14, Hrvoje Popovski wrote: >>> On 22.5.2018. 17:03, Theo Buehler wrote: >>>> I applied the diff, made syscalls, then built a

Re: Unlock 16 network-related syscalls

2018-05-23 Thread Hrvoje Popovski
On 22.5.2018. 17:03, Theo Buehler wrote: > I applied the diff, made syscalls, then built and installed a new > kernel. With that, I ran into a reliable complete lockup on my x230 by > starting in an xterm > > # make -j 3 build 2>&1 | tee -a /home/theo/buildlog > > and then navigating firefox to

Dell PowerEdge R7425

2018-05-17 Thread Hrvoje Popovski
i'm sending this mail for archive. CPU: 2 x AMD EPYC 7551 booting stops without any log: http://kosjenka.srce.hr/~hrvoje/zaprocvat/r7425_01.jpg if i want to disable acpicpu entering boot config stops right away http://kosjenka.srce.hr/~hrvoje/zaprocvat/r7425_02.jpg collected acpidump, lshw,

Dell PowerEdge R6415

2018-05-17 Thread Hrvoje Popovski
i'm sending this mail for archive. CPU: 1 x AMD EPYC 7551P booting stops with this panic: http://kosjenka.srce.hr/~hrvoje/zaprocvat/r6415_01.jpg collected acpidump, lshw, lspci, lsusb, cpuinfo from linux: http://kosjenka.srce.hr/~hrvoje/zaprocvat/R6415.tar if there's anything else that i can

Re: in6_ioctl(): use read lock for SIOCGIF*_IN6

2018-05-03 Thread Hrvoje Popovski
On 3.5.2018. 1:53, Theo Buehler wrote: > On Wed, May 02, 2018 at 04:25:20PM +0200, Hrvoje Popovski wrote: >> On 2.5.2018. 12:16, Theo Buehler wrote: >>> Here's a further refactoring of in6_ioctl() that splits out the >>> SIOCGIF*_IN6 cases into the new function in6

Re: in6_ioctl(): use read lock for SIOCGIF*_IN6

2018-05-02 Thread Hrvoje Popovski
On 2.5.2018. 12:16, Theo Buehler wrote: > Here's a further refactoring of in6_ioctl() that splits out the > SIOCGIF*_IN6 cases into the new function in6_ioctl_get(), where we only > need a read lock, similar to ifioctl() and the pending patch for > in_ioctl(). We get rid of one of the four

Re: interface queue transmit mitigation (again)

2018-04-28 Thread Hrvoje Popovski
On 28.3.2018. 11:42, Hrvoje Popovski wrote: > On 28.3.2018. 3:28, David Gwynne wrote: >> On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote: >>> On 14/03/18(Wed) 13:00, David Gwynne wrote: >>>> this adds transmit mitigation back to the tree. >>&

Re: interface queue transmit mitigation (again)

2018-04-01 Thread Hrvoje Popovski
On 28.3.2018. 11:42, Hrvoje Popovski wrote: > Hi all, > > with this diff i'm getting 1.43Mpps on > 12 x Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2400.01 MHz > > with plain kernel i'm getting 1.12Mpps and with older diff's i was > getting 1.31Mpps ... On box with 6 x In

Re: interface queue transmit mitigation (again)

2018-03-28 Thread Hrvoje Popovski
On 28.3.2018. 3:28, David Gwynne wrote: > On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote: >> On 14/03/18(Wed) 13:00, David Gwynne wrote: >>> this adds transmit mitigation back to the tree. >>> >>> it is basically the same diff as last time. the big difference this >>> time is that

acpi panic on dell r640 and r740xd

2018-03-25 Thread Hrvoje Popovski
Hi all, i'm sending diagnostics from dell r640 and dell r740xd here just for archive. i collected acpidump,lspci,lsusb,cpuinfo from linux and dmesg from bsd.rd. http://kosjenka.srce.hr/~hrvoje/zaprocvat/dell_r640.tar http://kosjenka.srce.hr/~hrvoje/zaprocvat/dell_r740xd.tar this is follow-up on

Re: interface tx mitigation, with NET LOCK fixes

2018-01-08 Thread Hrvoje Popovski
On 8.1.2018. 2:13, David Gwynne wrote: > this is tx mitigation again, ie, defer calling an interfaces start > routine until at least 4 packets are queued, or a task fires. > > the task firing is a problem for things like gif or vxlan that encap > a packet in ip and send it through the ip stack

Re: mp-safe carp_iamatch6()

2017-11-22 Thread Hrvoje Popovski
On 22.11.2017. 15:48, Martin Pieuchot wrote: > Hrvoje Popovski reported the following panic when testing my diff to > unlock protocol inputs function: > > panic() at panic+0x128 > __assert(814d1114,800022755d80,809ce000,800022755e20) > carp_ourethe

Re: multiple interface input queues

2017-11-13 Thread Hrvoje Popovski
On 14.11.2017. 5:42, David Gwynne wrote: > this replaces the single mbuf_queue and task in struct ifnet with > a new ifiqueue structure modelled on ifqueues. i've tested this diff with ix, myx, em and bge with down/up interfaces and everything is working fine ...

Re: try to bundle multiple packets on an ifq before sending

2017-11-10 Thread Hrvoje Popovski
On 10.11.2017. 1:58, David Gwynne wrote: > this makes ifq_start try to wait for 4 packets before calling > if->if_qstart. > > this is based on work sephe did in dragonflybsd, and described in > a comment in their sys/net/if.c. there's a link to it here: >

Re: sysctl_int(), sysctl_struct() & MP work

2017-09-12 Thread Hrvoje Popovski
On 12.9.2017. 15:53, Martin Pieuchot wrote: > Diff below reduces the scope of the NET_LOCK(), this time in sysctl > path. It is interesting for multiple reasons: > > - It reduces the contention on the NET_LOCK(), which should improve > the overall latency on the system when counters are

Re: refactoring of pf_find_or_create_ruleset()

2017-09-02 Thread Hrvoje Popovski
On 1.9.2017. 22:57, Alexandr Nedvedicky wrote: > as you can see the kernel sets ruleset.anchor to NULL (see pfattach() and then > do also a 'grep -n kludge pf_ioctl.c'), while userland links it to > pf_main_anchor. > > I've remember to changing 'parent != NULL' to 'parent != _main_anchor' in >

Re: 1M routes or 1M arp entries

2017-08-14 Thread Hrvoje Popovski
On 14.8.2017. 16:48, Simon Mages wrote: > Hi, > > you may want to take a look into /etc/login.conf > login.conf(5), cap_mkdb(1) > > In this file you can fiddle with you limit maxima > for login classes. > > BR > Simon > Thank you, i will do that ...

Re: 1M routes or 1M arp entries

2017-08-14 Thread Hrvoje Popovski
On 14.8.2017. 16:03, Alexander Bluhm wrote: > On Mon, Aug 14, 2017 at 03:52:56PM +0200, Hrvoje Popovski wrote: >> # netstat -rnf inet >> netstat: Cannot allocate memory > > Have you tried to increase ulimit -d ? it seems that i can decrease it but not increase it, or i

1M routes or 1M arp entries

2017-08-14 Thread Hrvoje Popovski
Hi all, when openbsd imports cca 1M routes or more and if i want to see them with "netstat -rn" i'm getting "Cannot allocate memory". bgpd can see all routes. i don't think that this is real problem but full bgp table is cca 700K routes. # bgpctl show ip bgp mem RDE memory statistics 1245184

Re: NET_LOCK() w/o argument

2017-08-11 Thread Hrvoje Popovski
On 11.8.2017. 19:56, Martin Pieuchot wrote: > Two weeks ago I remove the splsoftnet()/splx() dance inside the > NET_LOCK(). Turns out we found a single bug, a missing splx() > in net/if_spppsubr.c. > > I believe it's time to move forward and completely remove the > argument. This will allow us

Re: Reducing NET_LOCK() contention

2017-08-02 Thread Hrvoje Popovski
On 2.8.2017. 11:00, Alexandr Nedvedicky wrote: > Hello, > > On Wed, Aug 02, 2017 at 10:10:51AM +0200, Martin Pieuchot wrote: >> On 18/07/17(Tue) 15:55, Martin Pieuchot wrote: >>> When forwarding a lot of traffic with 10G interfaces contention on the >>> NET_LOCK() is "visible". Each time you

Re: Reducing NET_LOCK() contention

2017-08-02 Thread Hrvoje Popovski
On 2.8.2017. 10:10, Martin Pieuchot wrote: > On 18/07/17(Tue) 15:55, Martin Pieuchot wrote: >> When forwarding a lot of traffic with 10G interfaces contention on the >> NET_LOCK() is "visible". Each time you type "ifconfig" you can go grab >> a coffee... >> >> The problem has a name:

Re: /etc/rc: kernel relinking failed

2017-07-18 Thread Hrvoje Popovski
On 18.7.2017. 22:59, Theo Buehler wrote: > On Tue, Jul 18, 2017 at 10:55:59PM +0200, Hrvoje Popovski wrote: >> Hi all, >> >> i have checkout cvs tree few minutes ago and i'm seeing this log. >> >> Jul 18 22:47:36 x3550m4 /etc/rc: kernel relinking failed; see

/etc/rc: kernel relinking failed

2017-07-18 Thread Hrvoje Popovski
Hi all, i have checkout cvs tree few minutes ago and i'm seeing this log. Jul 18 22:47:36 x3550m4 /etc/rc: kernel relinking failed; see /usr/share/compile/GENERIC.MP/relink.log here it is: http://kosjenka.srce.hr/~hrvoje/zaprocvat/relink.log OpenBSD 6.1-current (GENERIC.MP) #8: Tue Jul 18

Re: serial console and ddb

2017-07-03 Thread Hrvoje Popovski
On 3.7.2017. 23:42, Stuart Henderson wrote: > The phrase "break sequence" is often used, but it's a bit of a misnomer. > When a serial port is connected but not actively transmitting data the tx > line is usually held high. A "break" is when that line is low for more > than a frame duration (the

serial console and ddb

2017-07-03 Thread Hrvoje Popovski
Hi all, i'm having two firewalls fw1 and fw2 and on fw1 i'm sending console output to com0. root@fw1:~ # cat /etc/boot.conf stty com0 115200 set tty com0 root@fw1:~ # cat /etc/ttys | grep tty00 tty00 "/usr/libexec/getty std.115200" vt220 on secure on fw2 i'm using "cu -s 115200" to play

Re: pfsync and option WITH_PF_LOCK

2017-06-11 Thread Hrvoje Popovski
On 9.6.2017. 16:31, Alexandr Nedvedicky wrote: >> Hi all, >> >> with this diff i don't see any traces as before. >> > > thanks a lot for quick testing. > > regards > sasha > Hi, i'm running latest snapshot with WITH_PF_LOCK in production and for now everything is fine .. will see tomorrow

Re: pfsync and option WITH_PF_LOCK

2017-06-09 Thread Hrvoje Popovski
On 9.6.2017. 14:55, Alexandr Nedvedicky wrote: > Hello, > > > On Fri, Jun 09, 2017 at 01:11:01PM +0200, Alexander Bluhm wrote: >> On Fri, Jun 09, 2017 at 10:55:46AM +0200, Alexandr Nedvedicky wrote: >>> would it make sense to commit a poor man's solution below, before pfsync(4) >>> will get to

pfsync and option WITH_PF_LOCK

2017-06-06 Thread Hrvoje Popovski
Hi all, i'm getting these traces with "option WITH_PF_LOCK" enaled. Setup is quite standard, trunk, vlan, carp, pfsync splassert: pf_state_insert: want 1 have 0 splassert: pf_remove_state: want 1 have 0 with kern.splassert=2 splassert: pf_state_insert: want 1 have 0 Starting stack

Re: routing sockets vs KERNEL_LOCK()

2017-06-06 Thread Hrvoje Popovski
LOCK() in >> rt_{set,put}gwroute(). Theses can now be called without KERNEL_LOCK() >> when inserting an ARP entry. > Hrvoje Popovski found the hard way that rtrequest(RTM_RESOLVE...) still > need the KERNEL_LOCK() for malloc(9)/free(9). Hi, with this patch i can't trigger panic as before. Thank you.

Re: Unlock IP forwarding paths

2017-05-30 Thread Hrvoje Popovski
is the bridge of this layer. A bad player. Since IPsec isn't >> ready to run without KERNEL_LOCK(), the softnet thread will grab the >> KERNEL_LOCK() as soon as ``ipsec_in_use'' is set. >> >> I tried to document as much as possible the current design in my >> commit mes

Re: Test wanted: IPv4 forwarding w/o KERNEL_LOCK()

2017-05-28 Thread Hrvoje Popovski
On 28.5.2017. 21:25, Alexander Bluhm wrote: > On Sun, May 28, 2017 at 07:41:23PM +0200, Hrvoje Popovski wrote: >> it seems that with >> $OpenBSD: ip_ipip.c,v 1.81 2017/05/28 13:59:05 bluhm Exp $ >> i can't compile this diff anymore ... with 1.80 everything is fine ... >>

Re: Test wanted: IPv4 forwarding w/o KERNEL_LOCK()

2017-05-28 Thread Hrvoje Popovski
On 28.5.2017. 15:07, Alexander Bluhm wrote: > On Fri, May 26, 2017 at 03:07:51PM +0200, Martin Pieuchot wrote: >> This diff get rids of the ipintrq for forwarding. The queue is now used >> for packets delivered locally which still need the KERNEL_LOCK(). > After committing some cleanup mpi@'s

Re: Test wanted: IPv4 forwarding w/o KERNEL_LOCK()

2017-05-28 Thread Hrvoje Popovski
On 28.5.2017. 15:07, Alexander Bluhm wrote: > After committing some cleanup mpi@'s diff looks like this now. > > bluhm Hi all, with cvs tree fetched few minutes ago and with this diff i'm getting traces in attchment. setup: carp on vlan on trunk (lacp) on 2 x ix there are so many net diffs,

Re: DDB causing lost keystrokes on Dell iDRAC console (not inside ddb)

2017-05-17 Thread Hrvoje Popovski
only differ entering ddb(4) once a matching control sequenece has been typed. This prevent loosing inputs when a USB console keyboard is "too fast". Fix a problem reported by matthieu@, Adam McDougall and Hrvoje Popovski. ok stsp@, dlg@

Re: Fix for USB keyboards eating keys, a DDB story

2017-05-10 Thread Hrvoje Popovski
On 10.5.2017. 15:22, Martin Pieuchot wrote: > This big hammer of delaying every input via a timeout introduced a nasty > side effect. Since only one element can be queued, we can lose inputs > if the keyboard is too fast. > > Here are some bug reports: > >

Re: Test wanted: IPv4 forwarding w/o KERNEL_LOCK()

2017-02-23 Thread Hrvoje Popovski
On 23.2.2017. 13:24, Alexander Bluhm wrote: > On Wed, Feb 22, 2017 at 06:22:56PM +0100, Martin Pieuchot wrote: >> I'd appreciate if you could test this diff and report regressions. > > I did run the regression tests with it. Everything worked fine. > >> This cannot be tested if you're using

Re: Test wanted: IPv4 forwarding w/o KERNEL_LOCK()

2017-02-23 Thread Hrvoje Popovski
On 23.2.2017. 13:24, Alexander Bluhm wrote: > On Wed, Feb 22, 2017 at 06:22:56PM +0100, Martin Pieuchot wrote: >> I'd appreciate if you could test this diff and report regressions. > > I did run the regression tests with it. Everything worked fine. > >> This cannot be tested if you're using

Re: Help with the NET_LOCK()

2017-02-03 Thread Hrvoje Popovski
On 25.1.2017. 7:32, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to the NET_LOCK() > just

Re: Help with the NET_LOCK()

2017-02-01 Thread Hrvoje Popovski
On 31.1.2017. 21:35, David Hill wrote: > On Tue, Jan 31, 2017 at 09:11:37PM +0100, Alexander Bluhm wrote: >> On Tue, Jan 31, 2017 at 12:14:35PM -0500, David Hill wrote: >>> with mpi@'s suggestion to pass a struct mbuf * >> We call mbuf variables m and mbuf pointer mp. So you should rename >> *mp

Re: Help with the NET_LOCK()

2017-01-31 Thread Hrvoje Popovski
On 31.1.2017. 18:14, David Hill wrote: > On Tue, Jan 31, 2017 at 10:43:26AM +0100, Martin Pieuchot wrote: >> On 27/01/17(Fri) 14:33, David Hill wrote: >>> [...] >>> Forgot a file... Try this: >> Is it now possible to pass a 'struct mbuf *' instead of a 'struct mbuf **' >> to the pr_ctloutput()

Re: Help with the NET_LOCK()

2017-01-30 Thread Hrvoje Popovski
On 25.1.2017. 7:32, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to the NET_LOCK() > just

Re: Help with the NET_LOCK()

2017-01-27 Thread Hrvoje Popovski
On 27.1.2017. 20:33, David Hill wrote: > On Fri, Jan 27, 2017 at 08:09:36PM +0100, Hrvoje Popovski wrote: >> On 27.1.2017. 19:14, David Hill wrote: >>>> splassert: yield: want 0 have 1 >>>> Starting stack trace... >>>> yield() at yield+0xac >>&g

Re: Help with the NET_LOCK()

2017-01-27 Thread Hrvoje Popovski
On 27.1.2017. 19:14, David Hill wrote: >> splassert: yield: want 0 have 1 >> Starting stack trace... >> yield() at yield+0xac >> pool_get() at pool_get+0x1ca >> m_get() at m_get+0x28 >> ip_ctloutput() at ip_ctloutput+0x4bf >> sogetopt() at sogetopt+0x7e >> sys_getsockopt() at sys_getsockopt+0xbf

Re: Help with the NET_LOCK()

2017-01-25 Thread Hrvoje Popovski
On 25.1.2017. 7:32, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to the NET_LOCK() > just

Re: tcpdump(63969): syscall 54 "tty"

2017-01-24 Thread Hrvoje Popovski
On 24.1.2017. 19:03, Sebastien Marie wrote: > On Tue, Jan 24, 2017 at 03:32:25PM +0100, Hrvoje Popovski wrote: >> Hi all, >> >> every time when quitting tcpdump with ^C i see that log on console. >> Source is fetched few minutes ago ... >> >> Don't know is

tcpdump(63969): syscall 54 "tty"

2017-01-24 Thread Hrvoje Popovski
Hi all, every time when quitting tcpdump with ^C i see that log on console. Source is fetched few minutes ago ... Don't know is this good or bad so i'm sending it here .. OpenBSD 6.0-current (GENERIC.MP) #15: Tue Jan 24 15:09:53 CET 2017

Re: NET_LOCK() for bpf(4)

2017-01-24 Thread Hrvoje Popovski
On 24.1.2017. 10:59, Martin Pieuchot wrote: > ok? > > Index: net/bpf.c > === > RCS file: /cvs/src/sys/net/bpf.c,v > retrieving revision 1.158 > diff -u -p -r1.158 bpf.c > --- net/bpf.c 9 Jan 2017 19:15:01 - 1.158 > +++

Re: NET_LOCK() take 2, tests wanted!

2017-01-20 Thread Hrvoje Popovski
On 20.1.2017. 3:04, Martin Pieuchot wrote: > Diff below enables the NET_LOCK(), again. > > What's new? > > - The lock ordering problem with fdplock() should now be fixed. It is >also documented, fdplock() should be taken first if both locks are >needed. > > - Page faults involving

Re: NET_LOCK() pr_sysctl

2017-01-16 Thread Hrvoje Popovski
On 16.1.2017. 23:53, Alexander Bluhm wrote: > Hrvoje Popovski has tested the diff and found some ugly > pmap_unwire: wiring for pmap 0xff00075f5210 va 0x7f7d5000 didn't > change! > kernel printfs. The happens when sysctl(8) writes a value. > > If oldp and newp are i

Re: pfkey vs splsoftnet()

2017-01-13 Thread Hrvoje Popovski
On 12.1.2017. 18:27, Hrvoje Popovski wrote: > On 12.1.2017. 16:20, Martin Pieuchot wrote: >> On 10/01/17(Tue) 10:37, Martin Pieuchot wrote: >>> In pfkey_sendup() we call sorwakeup() which asserts for NET_LOCK(), so >>> we are already at IPL_SOFTNET. >>&

Re: pfkey vs splsoftnet()

2017-01-12 Thread Hrvoje Popovski
On 12.1.2017. 16:20, Martin Pieuchot wrote: > On 10/01/17(Tue) 10:37, Martin Pieuchot wrote: >> In pfkey_sendup() we call sorwakeup() which asserts for NET_LOCK(), so >> we are already at IPL_SOFTNET. >> >> pfkeyv2_send() is called via pfkey_output() which is also called with >> the NET_LOCK()

Re: BFD: route get and route monitor

2017-01-12 Thread Hrvoje Popovski
On 23.12.2016. 16:57, Hrvoje Popovski wrote: > On 21.12.2016. 23:15, Sebastian Benoit wrote: >>> Hi, >>> >>> it seems that bfd is working with Force10 S4810 and Extreme Networks >>> x460 switches. I can test it with cisco c6k5 if you want? >> >&g

Re: BFD: route get and route monitor

2016-12-23 Thread Hrvoje Popovski
On 21.12.2016. 23:15, Sebastian Benoit wrote: >> Hi, >> >> it seems that bfd is working with Force10 S4810 and Extreme Networks >> x460 switches. I can test it with cisco c6k5 if you want? > > Hei, > > i'm sure phessler (who might not read this for a couple of days) is happy > about any test you

Re: BFD: route get and route monitor

2016-12-21 Thread Hrvoje Popovski
On 17.12.2016. 14:05, Peter Hessler wrote: > Updated output, requested by Theo. A normal get will show just the bfd > state, use "-bfd" to get all of the information. > > OK? > > $ route -n get 203.0.113.9 >route to: 203.0.113.9 > destination: 203.0.113.9 >mask: 255.255.255.255 >

E5v4 pciids

2016-12-15 Thread Hrvoje Popovski
Hi all, patch in attachment adds some E5v4 pciids that i'm seeing in supermicro 1018R-WR box with E5-1650 v4. before patch: vendor "Intel", unknown product 0x6f20 (class system subclass miscellaneous, rev 0x01) at pci0 dev 4 function 0 not configured vendor "Intel", unknown product 0x6f21

Re: Xeon-D R2PCIe Agent pcidevs

2016-12-11 Thread Hrvoje Popovski
On 8.12.2016. 14:32, Hrvoje Popovski wrote: > Hi all, > > i have this supermicro box: > https://www.supermicro.nl/products/motherboard/Xeon/D/X10SDV-TP8F.cfm > > dmesg without this patch shows : > vendor "Intel", unknown product 0x6f34 (class DASP subclass

Xeon-D R2PCIe Agent pcidevs

2016-12-08 Thread Hrvoje Popovski
Hi all, i have this supermicro box: https://www.supermicro.nl/products/motherboard/Xeon/D/X10SDV-TP8F.cfm dmesg without this patch shows : vendor "Intel", unknown product 0x6f34 (class DASP subclass Time and Frequency, rev 0x03) at pci12 dev 16 function 1 not configured with this patch: "Intel

Re: Intel 10GbE (ix) driver update - Looking for tests

2016-11-17 Thread Hrvoje Popovski
On 16.11.2016. 23:04, Mike Belopuhov wrote: > Hi, > > I've done a massive update of our ix(4) driver that brings > support for X550 family of controllers including those > integrated into new Xeon chips as well as QSFP support for > X520 (82599) but this needs thorough testing. If you're > using

Re: request for test: mfii

2016-10-28 Thread Hrvoje Popovski
On 26.10.2016. 5:50, YASUOKA Masahiko wrote: > On Wed, 26 Oct 2016 10:26:19 +1100 > Jonathan Gray wrote: >> On Tue, Oct 25, 2016 at 05:29:55PM +0900, YASUOKA Masahiko wrote: >>> I'm working on making mfii(4) bio(4) capable. >>> >>> If you have a machine which has mfii(4), I'd like

Re: network performance fun

2016-10-24 Thread Hrvoje Popovski
On 25.10.2016. 0:22, Hrvoje Popovski wrote: > On 24.10.2016. 23:36, Mike Belopuhov wrote: >> On Mon, Oct 24, 2016 at 19:04 +0200, Hrvoje Popovski wrote: >>> Hi all, >>> >>> OpenBSD box acts as transit router for /8 networks without pf and with &g

Re: network performance fun

2016-10-24 Thread Hrvoje Popovski
On 24.10.2016. 23:36, Mike Belopuhov wrote: > On Mon, Oct 24, 2016 at 19:04 +0200, Hrvoje Popovski wrote: >> Hi all, >> >> OpenBSD box acts as transit router for /8 networks without pf and with >> this sysctls >> >> ddb.console=1 >>

network performance fun

2016-10-24 Thread Hrvoje Popovski
Hi all, OpenBSD box acts as transit router for /8 networks without pf and with this sysctls ddb.console=1 kern.pool_debug=0 net.inet.ip.forwarding=1 net.inet.ip.ifq.maxlen=8192 netstat 11/8 192.168.11.2 UGS0 114466419 - 8 ix0 12/8 192.168.12.2

  1   2   >