[patch] Check memory allocation error in usr.bin/systat/vmstat.c

2018-05-02 Thread Nan Xiao
Hi tech@, A patch for usr.bin/systat/vmstat.c, apologize if I'm wrong. Index: vmstat.c === RCS file: /cvs/src/usr.bin/systat/vmstat.c,v retrieving revision 1.82 diff -u -p -r1.82 vmstat.c --- vmstat.c18 Dec 2016 23:36:32 -

Re: SMCCC 1.1 support for psci(4)

2018-05-02 Thread Jonathan Gray
On Tue, May 01, 2018 at 11:55:00AM +0200, Mark Kettenis wrote: > So after adding a quick hack to mitigate Spectre variant 2 to ARM > Trusted Firmware (ATF), ARM actually designed a proper solution that > minimizes the performance loss and makes the presence of the > workaround detectable. This is

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

2018-05-02 Thread Theo Buehler
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_ioctl_get(), where we only > > need a read lock, similar to ifioctl() and t

splice out a knock function for alps touchpads in pms.c

2018-05-02 Thread Ryan Lennox
Hi, Elantech has elantech_knock() Synaptics has synaptics_knock() Alps should have alps_knock() I'd ask for ok, but I don't have an Alps touchpad to test it. ​Index: src/sys/dev/pckbc/pms.c === RCS file: /cvs/src/sys/dev/pckbc/pms.

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 switches

Re: libkvm requires kvm_getargv before kvm_getenv when both needed

2018-05-02 Thread Todd C. Miller
On Tue, 01 May 2018 13:35:54 -0600, "Theo de Raadt" wrote: > > b) Their working space should be independent of each other. This > > isn't hard, just splitting kd->argbuf into kd->argbuf and > > kd->envbuf. Seems a bit saner. > > > > I think (b) would be the better solution, this seems

Re: reduce hppa interrupt guts awfulness

2018-05-02 Thread Mark Kettenis
> Date: Tue, 1 May 2018 21:22:12 + > From: Miod Vallat > > B2000 and C3650 test have been done with sys/dev/ic/com.c downgraded to > 1.166 in order to avoid freezes (bug resolution ongoing and not related > to this diff). So that's why my C3000 didn't come back after a reboot... The problem

Re: Don't send icmp redirect to the same interface a forwarded packet came in on

2018-05-02 Thread Christopher Zimmermann
On 2018-05-02 Martin Pieuchot wrote: > On 02/05/18(Wed) 11:47, Christopher Zimmermann wrote: > > I just want to bring this up again. Can some network guru give me an ok > > or some feedback please? > > Can you explain with words why we shouldn't send a redirect? The > comment above your diff s

Add support note for Theobroma RK3399-Q7 module

2018-05-02 Thread Karel Gardas
Hi, Mark Kettenis confirmed on -arm mailing list support of -current for Theobroma's RK3399-Q7 module together with Haikou Q7 Dev Kit. Patch below fixes this omission on arm64 platform page. Thanks, Karel ? papers/eurobsdcon_2013_kde4/.new.img69.png Index: arm64.html ===

Re: Don't send icmp redirect to the same interface a forwarded packet came in on

2018-05-02 Thread Martin Pieuchot
On 02/05/18(Wed) 11:47, Christopher Zimmermann wrote: > I just want to bring this up again. Can some network guru give me an ok > or some feedback please? Can you explain with words why we shouldn't send a redirect? The comment above your diff states clearly: "If forwarding packet using same i

Re: Don't send icmp redirect to the same interface a forwarded packet came in on

2018-05-02 Thread Christopher Zimmermann
Hi, I just want to bring this up again. Can some network guru give me an ok or some feedback please? Christopher On 2017-12-01 Christopher Zimmermann wrote: > Hi, > > by accident I discovered this rather senseless redirect: > > $ doas tcpdump -eptni vlan2 icmp > tcpdump: listening on vlan2,

Re: 5GHz AP RSSI measurement problem

2018-05-02 Thread Paul Irofti
On Wed, May 02, 2018 at 11:52:18AM +0200, Stefan Sperling wrote: > On Wed, May 02, 2018 at 12:30:30PM +0300, Paul Irofti wrote: > > On Mon, Apr 30, 2018 at 10:55:22AM +0200, Stefan Sperling wrote: > > > + /* > > > + * During a scan on 5Ghz, prefer RSSI measured for probe > > > +

in6_ioctl(): use read lock for SIOCGIF*_IN6

2018-05-02 Thread Theo Buehler
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 switches in the function body and error out early on on

Re: 5GHz AP RSSI measurement problem

2018-05-02 Thread Stefan Sperling
On Wed, May 02, 2018 at 12:30:30PM +0300, Paul Irofti wrote: > On Mon, Apr 30, 2018 at 10:55:22AM +0200, Stefan Sperling wrote: > > + /* > > +* During a scan on 5Ghz, prefer RSSI measured for probe > > +* response frames. i.e. don't allow beacons to lower the > > +

Re: 5GHz AP RSSI measurement problem

2018-05-02 Thread Paul Irofti
On Mon, Apr 30, 2018 at 10:55:22AM +0200, Stefan Sperling wrote: > I've ran into what seems to be a fairly modern dual-band AP (issued > by a French ISP). This AP camps on channel 112. This channel requires > radar detection which may explain the behaviour described below. > > The AP sends 5GHz be

Re: 5GHz AP RSSI measurement problem

2018-05-02 Thread Peter Hessler
On 2018 Apr 30 (Mon) at 10:55:22 +0200 (+0200), Stefan Sperling wrote: :Setting aside concerns about my lack of understanding of the underlying :reason for this behaviour, the hack below is sufficient to make this AP :show up as a strong contender in the candidate list and be preferred :over 2GHz a

Re: 5GHz AP RSSI measurement problem

2018-05-02 Thread Stefan Sperling
On Tue, May 01, 2018 at 10:06:54PM -0500, Patrick Dohman wrote: > I believe you are correct to correlate RSSI & probe response. > My understanding is that 802.11 beacon is a management frame to synchronize > networks. > Essentially the beacon interval determines the multiple for the DTIM & may >