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

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

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)

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

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

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

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

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

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

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

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

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

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()

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()

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

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

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

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

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)

; 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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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)

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

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

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()

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

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

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

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()

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

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

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

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

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

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

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

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

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

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

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

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

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

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()

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

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()

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()

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()

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)

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

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()

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()

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()

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()

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()

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()

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()

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()

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()

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"

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"

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)

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!

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

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()

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()

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

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

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

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

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

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

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

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

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

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

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

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

Re: MSI-X support

On 4.5.2016. 16:32, Mark Kettenis wrote: >>> This is great, thanks for doing this! I'm a bit surprised that >>> we don't need to the same suspend/resume dance in ppb(4) as with >>> MSI. >>> >> >> That is an excellent point I overlooked. Kettenis, do we? > > Almost certainly. I committed the

Re: bigger mbuf clusters for sosend()

On 22.8.2016. 8:20, David Gwynne wrote: > >> On 22 Aug 2016, at 03:36, Hrvoje Popovski <hrv...@srce.hr> wrote: >> >> On 13.8.2016. 10:59, Claudio Jeker wrote: >>> This diff refactors the uio to mbuf code to make use of bigger buffers (up >>> to 64k) an

Re: bigger mbuf clusters for sosend()

On 13.8.2016. 10:59, Claudio Jeker wrote: > This diff refactors the uio to mbuf code to make use of bigger buffers (up > to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in > the same function. I see no point in not waiting for a cluster and instead > chain lots of mbufs

Re: MSI-X support

On 4.5.2016. 8:50, Mark Kettenis wrote: >> Date: Tue, 3 May 2016 15:23:07 -0700 >> From: Mike Larkin >> >> On Tue, May 03, 2016 at 09:40:28PM +0200, Mark Kettenis wrote: >>> Today mpi@ reminded me that I had written support for MSI-X some time >>> ago. Since he is

Re: Moving away from softnet interrupts

On 18.4.2016. 15:31, Hrvoje Popovski wrote: > On 18.4.2016. 10:50, Martin Pieuchot wrote: >> The current goal of the Network SMP effort is to have a single CPU >> process the IP forwarding path in a process context without holding >> the KERNEL_LOCK(). To achieve this goa

Re: Moving away from softnet interrupts

On 18.4.2016. 10:50, Martin Pieuchot wrote: > The current goal of the Network SMP effort is to have a single CPU > process the IP forwarding path in a process context without holding > the KERNEL_LOCK(). To achieve this goal we're progressively moving > code from the softnet interrupt context to

Re: ix(4): enable checksum offload

On 9.9.2013. 22:07, Mike Belopuhov wrote: > On 9 September 2013 21:48, Brad Smith wrote: >> Here is a diff to enable the checksum offload support for ix(4). >> >> Looking for any testing. >> > > last time i checked this broke ospf traffic. please make sure at least > ip/tcp,

Re: New scheduler for OpenBSD

On 18.3.2016. 20:00, Mark Kettenis wrote: > One other important case to test is network packet forwarding. Some > of our network stack is now running inside a kernel thread. And any > changes in the scheduling behaviour have the potential of having a > significant impact there. I've done some

renesas unknown product on dell r630

hi, this patch adds renesas product on dell r630 dmesg on dell r630 without patch: pci6 at ppb5 bus 6 ppb6 at pci6 dev 0 function 0 vendor "Renesas", unknown product 0x001d rev 0x00 pci7 at ppb6 bus 7 ppb7 at pci7 dev 0 function 0 vendor "Renesas", unknown product 0x001d rev 0x00 pci8 at ppb7

snapshot from 26-Jan-2016 - pfsync panic

Hi all, i have pf,carp,pfsync and dhcpd setup with 2 Dell R610. today i updated my secondary firewall with latest snapshot from http://ftp2.eu.openbsd.org/ install59.iso 26-Jan-2016 04:00 and after update secondary firewall panic http://kosjenka.srce.hr/~hrvoje/crash2.jpg i couldn't type

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

On 23.1.2016. 23:29, Adam McDougall wrote: > Hello, > > I have a few Dell servers which I've installed OpenBSD for testing > but ran into a problem with keystroke loss on the console when used > through the Dell iDRAC remote graphical console. Surprisingly it > operates perfectly fine in the

<    1   2   3   4   >