Re: patch: Intel CPU sensor readout correction

Hi, i would like to ask if everything's ok with my patch. If somethings wrong, tell me, i'll fix it. I think this patch is a nice correction of the temperature readout of Intel CPU's. I tested this patch on some CPU's and everything looks fine so far. BR Simon 2014-11-27 12:44 GMT+01:00,

tcpdump non-blocking/immediate mode patch

Hi, tcpdump feels a bit laggy or slow some times when i use it for live debugging. The following patch adds a new flag, '-b', to tcpdump. With this flag, tcpdump sets BIOCIMMEDIATE on the bpf(4) device. With BIOCIMMEDIATE set, the output is fluent. Index: usr.sbin/tcpdump/privsep.c

Re: [PATCH] bpf is now blocking again with and without timeout

Is everything right with my regression test? 2015-01-21 15:28 GMT+01:00, Simon Mages mages.si...@googlemail.com: btw. here is my regression test for bpf: Index: regress/sys/net/Makefile === RCS file: /home/cvs/src/regress/sys

Re: [PATCH] bpf is now blocking again with and without timeout

I tested the patch and its working. I have a small test program already. I create a regression test with it. I'll post the diff here. Am 06.01.2015 04:19 schrieb Philip Guenther guent...@gmail.com: [(@#*$(*# control-enter keybinding] On Mon, Jan 5, 2015 at 7:15 PM, Philip Guenther

redundant code in reboot/halt and init?

Hi there, i read the code of init.c and reboot.c and was asking myself why reboot is not just sending SIGINT to init? The whole reboot code seems to be redundant, or am i missing something here? Why not just determine if im running as halt or reboot and send the correct signal to init. Let init

[PATCH] let the mbufs use more then 4gb of memory

On a System where you use the maximum socketbuffer size of 256kbyte you can run out of memory after less then 9k open sockets. My patch adds a new uvm_constraint for the mbufs with a bigger memory area. I choose this area after reading the comments in sys/arch/amd64/include/pmap.h. This patch

Supermicro X9SCM without ipmi panics while trying to attach ipmi0

It looks like the Supermicro X9SCM BIOS lies about the presence of a BMC. This board does not have a BMC but OpenBSD 5.9 tries to attach it and fails with the following panic: ... acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB panic: ipmi0: sendcmd fails Starting stack trace... panic() at

Fwd: [PATCH] let the mbufs use more then 4gb of memory

-- From: Simon Mages <mages.si...@googlemail.com> Date: Fri, 22 Jul 2016 13:24:24 +0200 Subject: Re: [PATCH] let the mbufs use more then 4gb of memory To: David Gwynne <da...@gwynne.id.au> Hi, I think i found the problem with your diff regarding the bigger mbuf clusters. You cho

[PATCH] dont increase the size of socket buffers in low memory situations

At the moment the buffersize will be set to the default even if the current value is smaller. The following diff fixes this problem. Index: netinet/tcp_usrreq.c === RCS file: /cvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision

Re: [PATCH] dont increase the size of socket buffers in low memory situations

2016-07-05 15:36 GMT+02:00, Claudio Jeker <cje...@diehard.n-r-g.com>: > On Tue, Jul 05, 2016 at 07:22:27AM -0600, Bob Beck wrote: >> Makes sense to me. Others? >> >> >> On Tue, Jul 5, 2016 at 4:08 AM, Simon Mages <mages.si...@googlemail.com> >> wrote:

Re: bigger mbuf clusters for sosend()

Hi, this diff works for me. I tested TCP and Unix Domain Sockets. I did no performance tests though. I like this version better then the one i was working with, it really is easier to read. For completeness follows the diff i was using: Index: kern/uipc_socket.c

Re: Scheduler ping-pong with preempt()

Hi, i did my usual tests. current: req/s: 3898.20 variance: 0.84 current+diff: req/s: 3928.80 variance: 0.45 With this diff the messurements have been much more stable. The variance of the req/s messurements is now a lot smaller. Also the performance has increased. For the bandwidth/s case

Re: add support for multiple transmit queues on interfaces

I did some tests. The performance did not change. I think this is the expected behaviour. BR Simon 2017-01-23 7:35 GMT+01:00, David Gwynne : > hrvoje popovski hit a problem where the kernel would panic under load. > > i mistakenly called an interfaces qstart routine directly

[PATCH] fix mbuf leak in uicp_usrreq.c

Hi, while i was debugging dlg@'s diff regarding the bigger mbuf clusters i stumbled across a bug in the PRU_SEND case in uicp_usrreq.c. There is a call to sbappendcontrol which can fail, but there is no error handling done. If sbappendcontrol fails m will be set to NULL, which just leaks this

Re: Help me testing the netlock

Hi, i did some performace tests in current with and without your diff. There is no difference in performance. I will try to do performance tests with current on a regular base now. 2016-10-05 10:15 GMT+02:00, Martin Pieuchot : > On 10/04/16 16:44, Martin Pieuchot wrote: >> On

Re: global mbuf memory limit

It seems netstat -m is not printing the correct results with this diff. The max values is wrong. # sysctl kern.maxclusters kern.maxclusters=262144 # netstat -m 9543 mbufs in use: 8044 mbufs allocated to data 1491 mbufs allocated to packet headers 8 mbufs allocated to

Re: per-cpu caches for pools

Hi, today i did some performance messurements on OpenBSD-current, with and without your diff. I use a custom HTTP proxy. Performance in this case is requests/s and bandwidth. To messure requests/s i use requests with a very small response. To messure bandwidth i use big responses. This custom

Re: SOCKET_LOCK looking for testers

Hi, i did some performance measurements with and without your diff on OpenBSD-current. There is no performance difference. I think this is the expected outcome. BR Simon 2016-11-04 10:12 GMT+01:00, Martin Pieuchot : > On 03/11/16(Thu) 11:21, Martin Pieuchot wrote: >> Here's

[PATCH] pcidump - read and write registers

Hi, right now i use the following diff to poke around in the PCIe config space. This diff enables pcidump to read and write to a register. So far i used this mainly to play with the Advanced Error Reporting Capability some devices have. $ pcidump 4:0:0:104 4:0:0: Broadcom BCM5754

[PATCH] pcidump - Enhanced Capabilities

Hi, on some machines i saw some unknown enhanced capabilities. After looking into it i saw that on some intel chipsets there actually is a capability with id 0x0. This capability contains some registers of the Advanced Error Reporting Capability but not all of them. I guess intel choose 0x0

Re: [PATCH] pcidump - read and write registers

Ah ok, good to know. Thanks anyway. 2017-03-27 14:57 GMT+02:00, Mark Kettenis <mark.kette...@xs4all.nl>: >> From: Simon Mages <mages.si...@googlemail.com> >> Date: Mon, 27 Mar 2017 13:57:54 +0200 >> >> Hi, >> >> right now i use the following

[PATCH] pcidump - Enhanced Capabilities

Hi, right now i got the chance to play a little bit with PCIe. I read some parts of the spec and was interessted what my PCIe devices can do. I also found out that pcidump can not display the Enhanced Capabilites. This patch enables pcidump to display them. I did not find a good list of

Re: 1M routes or 1M arp entries

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 2017-08-14 16:28 GMT+02:00, Hrvoje Popovski : > On 14.8.2017. 16:03, Alexander Bluhm wrote: >> On Mon, Aug 14, 2017 at

Re: [PATCH] pcidump - Enhanced Capabilities

Yes, this is correct. I missed those two somehow ... 2017-05-17 8:11 GMT+02:00, Jonathan Gray <j...@jsg.id.au>: > On Thu, Mar 16, 2017 at 03:19:23PM +0100, Simon Mages wrote: >> Hi, >> >> right now i got the chance to play a little bit with PCIe. I rea