Re: Say no to LARVAL

On 10/05/18(Thu) 22:49, Philip Guenther wrote: > On Wed, May 9, 2018 at 3:31 AM, Martin Pieuchot wrote: > > > On 08/05/18(Tue) 14:12, Philip Guenther wrote: > > > On Tue, 8 May 2018, Martin Pieuchot wrote: > > > > The way our kernel allocates and populates new 'struct file *'

hppa.html broken link, fix

Now that hppa is mentioned every day... Index: hppa.html === RCS file: /cvs/www/hppa.html,v retrieving revision 1.274 diff -u -p -u -r1.274 hppa.html --- hppa.html 2 Apr 2018 02:48:19 - 1.274 +++ hppa.html 21 May 2018

Re: acpithinkpad(4): port-replicator hkey event

On Sun, May 06, 2018 at 11:43:43PM +0200, Tobias Tschinkowitz wrote: > On Sun, May 06, 2018 at 09:31:55AM -0700, Mike Larkin wrote: > > On Fri, May 04, 2018 at 08:28:04PM +0200, Tobias Tschinkowitz wrote: > > > Hi @tech, > > > > > > i thought it would be a good idea to delegate the

Re: cosmetic sdio diff

On Mon, May 21, 2018 at 01:35:31PM +0200, Mark Kettenis wrote: > This diff improves the way we printf "not configured" sdio devices. > > Before: > > (manufacturer 0x2d0, product 0x4334)at sdmmc1 function 2 not configured > > After: > > manufacturer 0x02d0, product 0x4334 at sdmmc1 function 2

Re: acpithinkpad(4): port-replicator hkey event

On Mon, May 21, 2018 at 11:35:54AM +0200, Tobias Tschinkowitz wrote: > As the last diff still had formatting issues i fixed that. OK by me. Nitpick: There are overlong lines here (please stay <= 80 columns). > + sc->sc_sens[THINKPAD_SENSOR_PORTREPL].status = > SENSOR_S_OK;

doaccept() & NET_LOCK() recursion

FILE_SET_MATURE() shouldn't be called while holding the NET_LOCK(). Because if it releases the last reference of a file it will call soclose() and try to grab the lock again. I posted a regression test in the following thread: https://marc.info/?l=openbsd-tech=152637351632752=2 Diff

dwiic(4) fix

The diff below fixes I2C_OP_WRITE_WITH_STOP operations. Currently we run the read completion code for those operations, but since there is no data to read, this fails. Instead, this waits until a stop is detected. That doesn't seem to work for I2C_F_POLL operations though, so in that case we

Re: doaccept() & NET_LOCK() recursion

On 21/05/18(Mon) 14:18, Alexander Bluhm wrote: > On Mon, May 21, 2018 at 01:41:45PM +0200, Martin Pieuchot wrote: > > Diff below fixes that, ok? > > This part modifies the struct socket. It would run without > netlock in your diff. Indeed, updated diff. Index: kern/uipc_syscalls.c

Re: doaccept() & NET_LOCK() recursion

On Mon, May 21, 2018 at 03:14:45PM +0200, Martin Pieuchot wrote: > On 21/05/18(Mon) 14:18, Alexander Bluhm wrote: > > On Mon, May 21, 2018 at 01:41:45PM +0200, Martin Pieuchot wrote: > > > Diff below fixes that, ok? > > > > This part modifies the struct socket. It would run without > > netlock

Re: Wake the acpi thread up for gpio events

On 20/05/18(Sun) 11:28, Mark Kettenis wrote: > > Date: Sun, 20 May 2018 10:44:49 +0200 > > From: Martin Pieuchot > > > > On 19/05/18(Sat) 21:39, Mark Kettenis wrote: > > > Without the wakeup, the event doesn't get scheduled until some other > > > event wakes up the acpi thread.

cosmetic sdio diff

This diff improves the way we printf "not configured" sdio devices. Before: (manufacturer 0x2d0, product 0x4334)at sdmmc1 function 2 not configured After: manufacturer 0x02d0, product 0x4334 at sdmmc1 function 2 not configured This is somewhat similar to how we print "unknown" pci devices,

Re: doaccept() & NET_LOCK() recursion

On Mon, May 21, 2018 at 01:41:45PM +0200, Martin Pieuchot wrote: > Diff below fixes that, ok? This part modifies the struct socket. It would run without netlock in your diff. if (nflag & FNONBLOCK) so->so_state |= SS_NBIO; else

Re: errors in usage.c - libusbhid

On 18/05/18(Fri) 10:01, David Bern wrote: > Hello! > > Have been using libusbhid and discovered a couple of discrepancies in > the man-page (libusbhid.3) and the source of usage.c > > Some are just factual misses, but I also got (what I think is) 2 errors. > I will try to explain them; > > 1.

Re: acpithinkpad(4): port-replicator hkey event

On Mon, May 21, 2018 at 11:56:37AM +0200, Stefan Sperling wrote: > On Mon, May 21, 2018 at 11:35:54AM +0200, Tobias Tschinkowitz wrote: > > As the last diff still had formatting issues i fixed that. > > OK by me. > > Nitpick: There are overlong lines here (please stay <= 80 columns). > > > +

cdce0 troubles on RPi3, few ways to fix, which one to choose?

Hi, I do have 2 USB ethernet adapters based on Realtek 8153: TP-Link UE 300 Lenovo Thinkpad USB 3.0 Gigabit Adapter both adapters work well with 6.3-current on amd64 platform. If however I try to use them on RPi3 with 6.3-current, both lead to system freeze. As I see it now, there may be two

Re: unbuffered fread does not set error/EOF flags

#if 0 2018-05-05 22:17 GMT+03:00 Vadim Zhukov : > 2018-05-05 22:12 GMT+03:00 Vadim Zhukov : >> Hi all! >> >> Recently I was working on a program that uses stdio functions heavily. >> While hunting for a bug, I've temporarily disabled buffering (via >>

Re: acpithinkpad(4): port-replicator hkey event

On Mon, May 21, 2018 at 12:55:13PM +0200, Tobias Tschinkowitz wrote: > On Mon, May 21, 2018 at 11:56:37AM +0200, Stefan Sperling wrote: > > On Mon, May 21, 2018 at 11:35:54AM +0200, Tobias Tschinkowitz wrote: > > > As the last diff still had formatting issues i fixed that. > > > > OK by me. > >

Re: errors in usage.c - libusbhid

First diff "solves" point 1 & 2. Second diff is on the parts of the manual that does not match the usbhid.h Index: usage.c === RCS file: /cvs/src/lib/libusbhid/usage.c,v retrieving revision 1.16 diff -u -p -r1.16 usage.c --- usage.c

INT33F4 device information needed

Hi Folks, For a driver that I'm working on I need a variety of acpidump output to get a better understanding of how the hardware behaves. If you have a machine that has the following line in its dmesg: "INT33F4" at iic0 addr 0x34 not configured please send me: 1. A tar file with all the

Re: Drop memory barriers from _aromic_lock() on armv7 and arm64

On Mon, May 14, 2018 at 11:36 AM, Mark Kettenis wrote: > Since the callers now add the barriers we can drop them here. > > ok? > ok guenther@

Re: dwiic(4) fix

On Mon, May 21, 2018 at 12:44:47PM +0200, Mark Kettenis wrote: > The diff below fixes I2C_OP_WRITE_WITH_STOP operations. Currently we > run the read completion code for those operations, but since there is > no data to read, this fails. Instead, this waits until a stop is > detected. That