remove cpuset dead code

Unused under /sys, survived a kernel build without problems. Index: kern/kern_sched.c === RCS file: /cvs/src/sys/kern/kern_sched.c,v retrieving revision 1.44 diff -u -p -u -p -r1.44 kern_sched.c --- kern/kern_sched.c 21 Jan 2017

Re: Help with the NET_LOCK()

boot to console: /etc/hostname.re0: inet n.n.n.n 0xff00 /etc/hostname.ral0: nwid xyz wpakey "" mode 11g dhcp dmesg: OpenBSD 6.0-current (GENERIC.MP) #4: Tue Jan 31 19:42:25 EST 2017 r...@cq58-b.test:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem =

Re: Help with the NET_LOCK()

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 to m. > > The different policy who has

Re: Help with the NET_LOCK()

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 to m. The different policy who has to free the mbuf with if (op == PRCO_SETOPT)

httpd: HTTP pipelining

Hi, the following diff adds support for HTTP pipelining. With pipelining, the client sends multiple requests before receiving the responses in the same order. It was long dead and disabled in most browsers before Apple decided to turn it on in iOS Safari. btw. There is no need to enable

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

athn: rate scaling tweak

The athn driver disables multi-rate retries if RTS is used. This is done because of a hardware limitation (see comment in ar5008_tx()). So all attemps to send the frame will use the same data rate. If RTS is not used, the driver will configure the hardware to switch to a lower rate after 2 failed

Re: Help with the NET_LOCK()

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() functions? > > Changing the signature

Re: uvm: free sizes diff

David Hill wrote: > Hello - > > The following diff adds free sizes to free() calls in uvm/. Only one > remaining in uvm/. ok stefan@ > Index: uvm/uvm_amap.c > === > RCS file: /cvs/src/sys/uvm/uvm_amap.c,v > retrieving revision

Re: per cpu counters for icmp

Jonathan Matthew writes: > This is much like the other per cpu counter conversions, except the counter > enum has gaps in it to match the arrays in struct icmpstat. I missed this mail and implemented basically the same diff. :-/ So your diff looks fine to me, the difference

rtwn: amrr support

This diff adds AMRR support to rtwn(4) (not urtwn(4) yet! PCI devices only). This improves Tx performance with 8188CE hardware a lot. The firmware's builtin rate scaling rarely selects rates above 1Mbit/s in my environment. With this diff and tcpbench I've seen the driver crank it up to 54mbit/s.

tcpstat percpu counters (and kernel size growth)

Maybe I'm comparing apples and oranges, but I got curious and compared the size of various kernels on amd64: * -current GENERIC: textdatabss dec hex 9197408 269192 684032 101506329ae2e8 * percpu tcpstat, not inlined, GENERIC: textdatabss dec hex

Re: [wscons] User-space access to terminal emulation data

Hello to everyone. First of all, thank you again for your attention, and to who read this message. I am unsubscribing from the list now, to manage easily my mailbox. Still, I am interested in hearing your opinions and comments. So feel free to contact me directly. Thank you again, Enrico

Re: sys/dev/uaudio.c: Fix broken links

Michael Reed writes: I'm not sure how, but the patch got corrupted (it didn't apply with just ''patch < uaudio.diff'', there are missing newlines). Anyway, committed. Thanks, -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: ip6stat percpu counters

Updated diff that addresses Martin's points: - kill IPv6 mbuf stats; don't change the ip6stat structure yet - there are already other fields that are useless - add ip6stat_add() Keep the M_COUNTERS change separate for now, I can send an updated diff later if needed. Additionally, - stop

Re: Add quirks to support M-Audio FastTrack Pro (uaudio)

Hi, below you find an updated diff. OK? On 2017-01-29 Martin Pieuchot wrote: > On 29/01/17(Sun) 19:33, Christopher Zimmermann wrote: > > [...] > > @@ -444,6 +447,11 @@ uaudio_match(struct device *parent, void > > if (uaa->iface == NULL || uaa->device == NULL) > >

Re: counters api: always use M_COUNTERS

On Tue, Jan 31, 2017 at 01:18:05PM +0100, Jeremie Courreges-Anglas wrote: > > As proposed by mpi@ in > > http://marc.info/?l=openbsd-tech=148585429014645=2 > > I think that choosing a "proper" type doesn't bring much information, > and having one parameter less makes things simpler. mbuf

Re: counters api: always use M_COUNTERS

Jeremie Courreges-Anglas writes: > As proposed by mpi@ in > > http://marc.info/?l=openbsd-tech=148585429014645=2 > > I think that choosing a "proper" type doesn't bring much information, > and having one parameter less makes things simpler. mbuf counters move > from M_DEVBUF

Re: ip6stat percpu counters

On 31/01/17(Tue) 12:16, Jeremie Courreges-Anglas wrote: > Martin Pieuchot writes: > [...] > Yes, but I don't know which threshold warrants introducing a new > function. So far those are the first cases for counters_dec(); that > includes wip rip6stat, icmp6stat, icmpstat and

Re: ip6stat percpu counters

Martin Pieuchot writes: > On 30/01/17(Mon) 22:14, Jeremie Courreges-Anglas wrote: >> Very lightly tested. I used the existing percpu counters as examples. > > I like it. > >> I don't like the hardcoding of "32" in ip6_input() but I am not sure how >> to solve it nicely; the

Re: iwm(4): Update struct iwm_scan_results_notif. Remove a few old defines.

On Mon, Jan 30, 2017 at 12:07:46PM +0100, Imre Vadász wrote: > Thanks, this patch was trying to remove the struct iwm_scan_complete_notif > definition that was already removed in one of the previous diffs. > fixed patch: Committed. Thank you!

rtwn: fix hardware admission control config

In my latest commit I enabled "hardware AC queue management" in rtwn. Upon closer investigation, this register works differently. It needs to reflect "ACM" (admission control mandatory) flags which the AP sends to clients in EDCA parameters. There is one such flag per traffic class, and the

Re: Help with the NET_LOCK()

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() functions? Changing the signature would ensure we do not miss a call. This would also simplify the SETOPT case. >

Re: [wscons] User-space access to terminal emulation data

Hello Enrico, On 26/01/17(Thu) 14:41, Enrico Mioso wrote: > Hello to everyone reading this message, and thank you. Welcome to OpenBSD hacking! > I am a blind user, using a braille display to read the output of my > computer. Each braille display has it's own protocol, so there is the need > of

11n hostap: send correct edca params to clients

In hostap mode, when copying EDCA parameters into frames we send to clients, we copy EDCA parameters from the "QOS AP" table (ieee80211_qap_edca_table). But values in these frames tell clients what parameters to use themselves. So copy parameters from the "QOS client" table (ieee80211_edca_table)

Re: ip6stat percpu counters

On 30/01/17(Mon) 22:14, Jeremie Courreges-Anglas wrote: > Very lightly tested. I used the existing percpu counters as examples. I like it. > I don't like the hardcoding of "32" in ip6_input() but I am not sure how > to solve it nicely; the easiest way would be to just kill those > ipv6-specific