Re: exp.3: remove ancient history and some markup tweaks

> Date: Mon, 30 May 2016 15:34:04 +0200 > From: Joerg Sonnenberger > > On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote: > > It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and > > log1p(x) = log(1 + x) are provided and what their historical purpose

Re: xhci(4) vs BIOS

> Date: Tue, 31 May 2016 18:43:16 +0200 > From: Martin Pieuchot > > I finally got my hands on a DELL Optiplex 3020. The BIOS on this > machines uses the xHCI controller to handle the keyboard and mouse. > > Turns out that I badly copy/pasted the ehci(4) code to take over the

Re: ptrace PT_IO write bug

> From: "Ted Unangst" > Date: Tue, 31 May 2016 13:57:04 -0400 > > Jeremie Courreges-Anglas wrote: > > >> > > >> Since PT_WRITE_I and PT_WRITE_D are documented as strictly equivalent > > >> since rev. 1.1, I doubt that such an optimization is a good idea. > > > > > > A clear

Re: kdump small timespecs

> From: "Ted Unangst" > Date: Tue, 31 May 2016 21:46:16 -0400 > > Small timespecs print funny: > > 57686 chrome CALL clock_gettime(CLOCK_MONOTONIC,0x7f7f0028) > 57686 chrome STRU struct timespec { 15411<"Dec 31 23:16:51 > 1969">.584609082 } > 57686 chrome

Re: ntfs mkdir errno value

> Date: Wed, 1 Jun 2016 10:04:12 +0200 > From: Martin Natano > > The following patch addresses an issue found by landry. mkdir on an ntfs > mountpoint returns ENOENT, while the error should be EROFS. We don't > support write access on ntfs. > > Ok? ok kettenis@ > Index:

Re: sqlite3 update

> Date: Wed, 1 Jun 2016 07:44:23 +0200 > From: Landry Breuil > > > (I don't really understand how things are working in Firefox on > > other OS, there are two different versions of sqlite in their > > tree...even in the one firefox tarball).. > > Nss is considered a

installboot(8) form armv7

Since the armv7 installer now creates an msdos filesystem for the bootloader, here's an updated installboot(8) diff. Besides FAT32 LBA partitions (created by the installer), it also recognizes FAT16 LBA and EFI System partitions. Not sure whether we actually need to support FAT16, but we'll

Re: exp.3: remove ancient history and some markup tweaks

> Date: Mon, 30 May 2016 18:55:42 +0200 > From: Theo Buehler <t...@math.ethz.ch> > > On Mon, May 30, 2016 at 06:24:55PM +0200, Mark Kettenis wrote: > > > Date: Mon, 30 May 2016 15:34:04 +0200 > > > From: Joerg Sonnenberger <jo...@bec.de> > > > &

Re: ptrace PT_IO write bug

> From: Jeremie Courreges-Anglas <j...@wxcvbn.org> > Date: Mon, 30 May 2016 19:30:27 +0200 > > Mark Kettenis <mark.kette...@xs4all.nl> writes: > > > Mathieu - schreef op 2016-05-28 13:05: > >> Martin Natano wrote: > >>> The diff read

Re: exp.3: remove ancient history and some markup tweaks

> Date: Mon, 30 May 2016 19:33:04 +0200 > From: Theo Buehler > > > Sorry. No. The use of originally still implies that these functions > > are no longer relevant for the purpose mentioned in the sentence. It > > doesn't make sense without the historic context. I'd simply

Re: ktrace.h: move KTRPOINT() into the kernel part

> Date: Fri, 17 Jun 2016 21:31:37 -0700 > From: Philip Guenther > > KTRPOINT(), with its references to struct proc and struct process members, > is only useful inside the kernel, so let's move it to the #ifdef _KERNEL > part. > > ok? Sure. > Index: sys/ktrace.h >

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

> Date: Thu, 23 Jun 2016 13:09:28 +0200 > From: Alexander Bluhm > > On Wed, Jun 22, 2016 at 10:54:27PM +1000, David Gwynne wrote: > > secondly, allocating more than 4g at a time to socket buffers is > > generally a waste of memory. in practice you should scale the amount

Stop mesa W^X violations

As reported by several people, mesa contains code that violates W^X. As a result glxgears aborts when using the swrast driver. The diff below disables the offending code. The code seems to deal the absence of W|X memory just fine. There is a fallback path that is also used on SELinux systems.

Re: less progname in r

> From: "Ted Unangst" > Date: Thu, 23 Jun 2016 21:57:00 -0400 > > These programs don't do anything interesting based on progname, > except to echo is back to the user. If the user creates a link, is > it somehow more correct to print that name? I'd argue the original > name

Re: Can not allocate memory for KERN_MSGBUF

This happens if kernel and the dmesg(8) userland program are out of sync. And yes, that can even happen for snapshots. Next snapshot should be ok again.

umb(4) attachment

As reported earlier, umb(4) currently doesn't attach to devices that implement both NCM 1.0 and MBIM, such as the Sierra Wireless EM7345 that is found in some thinkpads. The diff below fixes this. It revamps the way we look up interface descriptors quite a bit. I removed the unused code for

sdmmc voltage bits

Seems the voltage bit defenitions in sdmmcreg.h for voltages below 2V are not quite right. At least I can't find them in any of the MMC and SD card documentation I can find on the interwebs. Instead there is a single "low voltage bit" that indicates support for the 1.65-1.95V or 1.70-1.95V range

Re: acpithinkpad tablet dock/undock events

> Date: Sun, 10 Jan 2016 16:47:05 +0100 > From: Stefan Sperling > > Add events which occur when docking/undocking a tablet observed > on the Helix 2. You have a tabs vs. spaces inconsistency, but otherthan that, this is ok > Index: acpithinkpad.c >

SD Host Controller 3.0 support

The diff below adds (minimal) support for the 3.0 specification. The most important bit is support for the higher base clock and the larger divisors that this standard brings. It doesn't really add support for the new features that allow faster data transport. ok? Index: sdhc.c

Re: sdmmc voltage bits

> Date: Mon, 11 Jan 2016 00:50:23 +1100 > From: Jonathan Gray <j...@jsg.id.au> > > On Sun, Jan 10, 2016 at 12:34:56PM +0100, Mark Kettenis wrote: > > Seems the voltage bit defenitions in sdmmcreg.h for voltages below 2V > > are not quite right. At least I can

Re: ksyms uiomove() conversion

> Date: Sun, 10 Jan 2016 19:44:27 +0100 > From: Stefan Kempf > > Martin Natano wrote: > > Below the uiomove() conversion for dev/ksyms.c. 'len' is a size_t. > > And len is computed from values >= 0 and from expressions that do not > wrap around. > > ok? ok kettenis@ > >

Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)

> Date: Sun, 10 Jan 2016 21:28:31 +0100 > From: Joerg Jung > > On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote: > > Hi, > > > > I'm running -current on Apple MacBook Air 6,2. I installed using Jasper's > > instructions [1], OpenBSD is the only OS and boots via

Re: umb(4) attachment

> Date: Tue, 28 Jun 2016 07:01:09 +0200 > From: Martin Pieuchot <m...@openbsd.org> > > On 17/06/16(Fri) 22:22, Mark Kettenis wrote: > > As reported earlier, umb(4) currently doesn't attach to devices that > > implement both NCM 1.0 and MBIM, such as the Sierra Wir

Re: kill(2) and zombie processes

> From: j...@wxcvbn.org (Jeremie Courreges-Anglas) > Date: Mon, 27 Jun 2016 20:13:54 +0200 > > Some time ago someone reported a wird behavior in the shells/zsh ports. > > http://marc.info/?l=openbsd-misc=146101806918986=2 > > The latter relies on kill(zombie, 0) to succeed, instead we return

Re: use cpsw mac address and phy id from fdt

> Date: Sun, 26 Jun 2016 22:46:26 +1000 > From: Jonathan Gray > > With cpsw being a switch getting the port config isn't as > straightforward as fec. Not terribly fond of the !strcmp() idiom, but otherwise this looks ok to me. > We only handle the first port at the moment,

Re: [patch] kern/exec_script: return error when the shell name is not specified

> Date: Fri, 5 Feb 2016 13:06:56 -0500 > From: Michael McConville > > Michael McConville wrote: > > Michael McConville wrote: > > > Maxim Pugachev wrote: > > > > In a case when the shell name is not specified (i.e. just "#!" without > > > > a path), don't run the heavy logic

Re: ansify libarch/i386

> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) > Date: Mon, 01 Feb 2016 20:10:25 +0100 > > ok? ok kettenis@ > Index: lib/libarch/i386/i386_get_ioperm.c > === > RCS file:

sdmmc card detect

The Bay Trail SoC SD controller for the SD card slot doesn't use the Card Detect bit in the standard register. Instead there is a separate gpio that signals the presence of a card in the slot. The diff below introduces a function pointer in the sdhc softc that, if non-NULL, gets called instead

Re: ldapd: add -r option to specify datadir path

> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) > Date: Tue, 02 Feb 2016 19:23:25 +0100 > > j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: > > > Sebastien Marie writes: > > > >> On Sun, Jan 31, 2016 at 09:39:52AM +0100, Landry Breuil

Re: UEFI Boot Report: Screen corruption and kernel panic

> Date: Tue, 2 Feb 2016 14:14:04 -0500 > From: James Hastings <mooset...@gmail.com> Best not to drop the list. There are other developers that might want to chime in. > On 2/2/16, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > >> Date: Tue, 2 Feb 2016 02:09:08 -

Re: UEFI Boot Report: Screen corruption and kernel panic

> Date: Tue, 2 Feb 2016 21:32:13 +0100 (CET) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > Date: Tue, 2 Feb 2016 14:14:04 -0500 > > From: James Hastings <mooset...@gmail.com> > > > > Native screen size is 1366x768 > > > > Res

Re: tcpdump: decode 802.11 QoS frames correctly

> Date: Sun, 31 Jan 2016 20:57:29 +0100 > From: Stefan Sperling <s...@stsp.name> > > On Sun, Jan 31, 2016 at 03:14:46PM +0100, Mark Kettenis wrote: > > I think you should add a TCHECK somewhere at the top for the qos frame > > size otherwise this might loo

Re: Make iwn(4) pass control frames in monitor mode

> Date: Wed, 3 Feb 2016 17:03:46 +0100 > From: Stefan Sperling > > This allows tcpdump to see all control frames with iwn(4). Hmm, the code below that does look inside the frame. How do we guarantee it isn't looking at garbage or reading beyond the end of the buffer? > Index:

Re: tcpdump: show 802.11 control frames

> Date: Wed, 3 Feb 2016 13:27:50 +0100 > From: Stefan Sperling > > Currently, tcpdump displays 802.11 control frames as "type#4" and > doesn't give more information than that. > > This diff makes tcpdump show the subtype of such frames, and pretty-print > a few subtypes in

Re: tcpdump: decode 802.11 QoS frames correctly

> Date: Sun, 31 Jan 2016 13:36:17 +0100 > From: Stefan Sperling > > On Sun, Jan 31, 2016 at 12:53:09PM +0100, Stefan Sperling wrote: > > This matters for frames which arrived in A-MPDUs. > > > > Before: > > > > 12:35:07.726898 802.11: QoS data: 00:1e:52:f1:80:55 sap 00 > > >

Re: more windows versions for acpi _OSI checks

> Date: Sun, 28 Feb 2016 16:07:50 +1100 > From: Jonathan Gray > > Claim to be more versions of windows for _OSI. Mostly based on the > table in 'How to Identify the Windows Version in ACPI by Using _OSI'. > > 2001.1 SP1Windows Server 2003 SP1 > 2006.1Windows

Re: spec_vnops.c uiomove() conversion

> Date: Mon, 18 Jan 2016 19:12:01 +0100 > From: Stefan Kempf > > Martin Natano wrote: > > Below the conversion to uiomove() for kern/spec_vnops.c. This diff > > prevents truncation of uio_resid when passed to min(). > > Looks good. Basically the same reasoning as with the

Re: cd9660 uiomove() conversion

> > Diff reads good. ok? ok kettenis@ > Some thoughts (mostly for myself) inline. > > Martin Natano wrote: > > Below the uiomove conversion for isofs/cd9660/cd9660_vnops.c. > > > > cheers, > > natano > > > > Index: isofs/cd9660/cd9660_vnops.c > >

Re: 11n: fix BA timeout value in ADDBA requests/responses

> Date: Thu, 21 Jan 2016 19:06:51 +0100 > From: Stefan Sperling > > The ADDBA frames use a timeout value in units of TU (802.11 time unit). > ba->ba_timeout_val is in usec and has already been multiplied by TU > (e.h. in ieee80211_recv_addba_req()). > We need to divide by TU when

Re: Firefox, malloc(3) and threads

> From: "Peter N. M. Hansteen" <pe...@bsdly.net> > Date: Sun, 24 Jan 2016 23:10:41 +0100 > > On 01/22/16 22:46, Mark Kettenis wrote: > > Firefox makes a lot of concurrent malloc(3) calls. The locking to > > make malloc(3) thread-safe is a bit...subopt

Re: audio: expose real device name

> Date: Wed, 20 Jan 2016 09:13:53 +0100 > From: Alexandre Ratchov > > This diff makes audioctl(1) display the device name (ex. > "azalia0", "cmpci0", etc) in the "name" attribute. This way > audioctl(1) output could be correlated with dmesg output. This > seems more useful

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

> From: Noth > Date: Sat, 20 Feb 2016 07:22:56 +0100 > > On 02/20/16 06:46, Theo de Raadt wrote: > >> I'm using VAIO Z. Hibernation works, but my vaio also wakes back > >> immediately. I have a diff to avoid this wakeup. Unhibernation works > >> fine. > >> > >> The

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

> Date: Sat, 20 Feb 2016 11:32:15 -0800 > From: Mike Larkin <mlar...@azathoth.net> > > On Sat, Feb 20, 2016 at 10:04:28AM +0100, Mark Kettenis wrote: > > > From: Noth <nothingn...@citycable.ch> > > > Date: Sat, 20 Feb 2016 07:22:56 +0100 > >

Re: opendev(3) tweak

> Date: Thu, 10 Mar 2016 12:52:35 +0100 > From: Marc Espie > > Already shown to a few people, but since pledge(2) aborts on non-dev, let's > check upfront that we're of the right type. > > I don't think this requires a bump. It doesn't really change the interface, > just makes

Re: IB700 watchdog

> Date: Thu, 17 Mar 2016 14:28:04 +0900 > From: Masao Uebayashi > > This tiny driver is only meant for a backup watchdog configuration on > QEMU, whose ICH watchdog, supported by ichwdt(4), seems broken. > > ib700wdt(4) supports only 0-30 second timeouts but in practice

Re: New scheduler for OpenBSD

> From: Bob Beck > Date: Fri, 18 Mar 2016 09:20:35 -0600 > > this is cool .. but > > I would be interested in someone comparing server workloads, as > opposed to interactive GUI response, using this. > > I wouldn't be surprised that inspiriation from BFS would produce >

Re: kern_sched.c: unused functions

> Date: Wed, 16 Mar 2016 22:18:41 -0400 > From: Michael McConville > > Michal Mazurek wrote: > > On 17:19:39, 2.03.16, Martin Natano wrote: > > > On Wed, Mar 02, 2016 at 05:07:21PM +0100, Michal Mazurek wrote: > > > > kern_sched.c: > > > > - remove unused functions > > > > -

Re: Xorg stipple

> Date: Wed, 9 Mar 2016 17:09:13 -0600 > From: joshua stein > > Is anyone seriously finding video/Xorg bugs through the default X > stipple pattern anymore? Xorg changed the default to draw a black > background a while ago (with stipple enabled using the -retro flag), > but we

Cleaner way to disable acpivout(4)

Simply don'tmatch if the ws_get_param or ws_set_param callback has been set. That way we don't need the platform-specific acpi driver "enabled" variables anymore. ok? Index: acpi.c === RCS file: /cvs/src/sys/dev/acpi/acpi.c,v

Re: tidy syscall_mi.h

> Date: Thu, 7 Apr 2016 13:10:23 +0200 > From: Michal Mazurek > > Depending on the NOLOCK flag, the KERNEL_LOCK will, or will not be acquired > before calling pledge_syscall(). I therefore conclude that KERNEL_LOCK > is not needed to call pledge_syscall(). It really depends

Re: fdt: rename file to prepare for fdt bus

> Date: Thu, 7 Apr 2016 16:54:19 +0200 > From: Patrick Wildt > > Hi, > > after a bit of talking with jsg@ we have found a way forward on how to > integrate FDT into ARM. > > An aspect of this is having an MI FDT bus residing in sys/dev/ofw/, > where the fdt subroutines

Re: fdt: translate memory addresses

> Date: Tue, 5 Apr 2016 18:11:03 +0200 > From: Patrick Wildt > > Updated to include feedback. > > ok? Looks good to me; ok kettenis@ > diff --git sys/dev/ofw/fdt.c sys/dev/ofw/fdt.c > index 4cebbb4..09ddcfc 100644 > --- sys/dev/ofw/fdt.c > +++ sys/dev/ofw/fdt.c > @@ -34,6

Re: Double resched_proc() in setrunnable()

> Date: Wed, 6 Apr 2016 11:03:29 +0200 > From: Martin Pieuchot > > On 27/03/16(Sun) 12:00, Martin Pieuchot wrote: > > Diff below moves resetpriority() out of updatepri() and resched_proc() > > out of resetpriority() in order to expose a double resched_proc() call > > in

Re: Keyboard resume (zzz) diff

> Date: Sun, 10 Apr 2016 23:33:59 -0700 > From: Mike Larkin > > Please test this diff on all machines that you can successfully (today) > resume with 'zzz'. Please make sure that after resume, the keyboard > still works. > > This diff re-enables the keyboard on resume.

Re: arm/fdt: ... to prepare for fdt bus

> Date: Fri, 8 Apr 2016 14:53:35 +0200 > From: Patrick Wildt > > On Fri, Apr 08, 2016 at 03:29:05PM +0300, Artturi Alm wrote: > > On Fri, Apr 08, 2016 at 01:44:11PM +0200, Patrick Wildt wrote: > > > Hi, > > > > > > with the feedback received on the fdt bus, the fdt stuff will

Re: fdt: rename file to prepare for fdt bus

> Date: Thu, 7 Apr 2016 18:31:22 +0200 > From: Patrick Wildt <patr...@blueri.se> > > On Thu, Apr 07, 2016 at 06:00:25PM +0200, Mark Kettenis wrote: > > > > just be the enumeration mechanism for "mainbus". And I think armv7 > > should be the

Re: arm: fix cortex bus match function

> Date: Fri, 8 Apr 2016 13:44:11 +0200 > From: Patrick Wildt > > Hi, > > with the feedback received on the fdt bus, the fdt stuff will now be > replacing the mainbus. While doing that I noticed that the cortex > bus matches every time on config_found, which is because it

Re: fdt: implement helper to check and find compatible nodes

> Date: Fri, 8 Apr 2016 17:14:03 +0200 > From: Patrick Wildt > > On Fri, Apr 08, 2016 at 04:34:25PM +0200, Martin Pieuchot wrote: > > On 08/04/16(Fri) 14:46, Patrick Wildt wrote: > > > Hi, > > > > > > so that we can easily check if a node is compatible or to find nodes > > >

Re: bufcache KNF

> From: "Ted Unangst" > Date: Mon, 11 Apr 2016 09:44:26 -0400 > > Martin Pieuchot wrote: > > ok? > > > > -int chillbufs(struct > > -bufcache *cache, struct bufqueue *queue, int64_t *queuepages); > > +int chillbufs(struct bufcache *, struct bufqueue *, int64_t *); > >

Re: Spurious serial console interrupts

> Date: Tue, 12 Apr 2016 13:12:42 + > From: Visa Hankala > > On Fri, Apr 08, 2016 at 12:16:03PM +, Visa Hankala wrote: > > Every now and then I see "spurious interrupt 34" messages on octeon > > serial console. The root cause seems to be in comstart() which enables > >

Re: patch: serialize multiple threads calling pledge(2)

> Date: Sat, 9 Apr 2016 10:47:14 +0200 > From: Sebastien Marie > > Hi, > > The following diff makes the effect of multiple threads calling > pledge(2) to be serializable. > > It adds a loop (with tsleep(9)) at pledge(2) entrance if another thread > is already inside (due

Re: arm: new FDT-enabled mainbus

> Date: Sat, 9 Apr 2016 17:32:33 +0200 > From: Patrick Wildt <patr...@blueri.se> > > On Fri, Apr 08, 2016 at 09:38:25PM +0200, Mark Kettenis wrote: > > > Date: Fri, 8 Apr 2016 20:26:14 +0200 > > > From: Patrick Wildt <patr...@blueri.se> > > >

Re: arm: new FDT-enabled mainbus

> Date: Fri, 8 Apr 2016 20:26:14 +0200 > From: Patrick Wildt > > +void > +mainbus_iterate(struct device *self, struct device *match, int node) > +{ > + for (; > + node != 0; > + node = OF_peer(node)) > + { > + /* skip nodes that are already

Re: vmm: guest<->host communication via shared memory

> Date: Wed, 6 Apr 2016 20:58:16 +0200 > From: Stefan Kempf > > Stefan Kempf wrote: > > Hi, > > > > here comes a diff for vmm, and I'd like to ask people that are > > interested in our hypervisor to test this. If you are experimenting > > with vmm already, just do what you

Re: Rename the global variable ``ticks''

> Date: Thu, 17 Mar 2016 21:02:03 +0100 > From: Martin Pieuchot > > ``ticks'' is in my opinion a really badly named global variable. But we > all know that finding names is hard ;) > > Since its popularity seems to be really high lately, I'd suggest to > rename it. I chose

Re: sdhc: don't always compile the pci attachment driver

> Date: Fri, 4 Mar 2016 22:32:19 +0100 > From: Patrick Wildt > > Hi, > > if you attach sdhc, you automatically compile the pci attachment driver, > even if there's no "sdhc* at pci?" in the config. This might fail on > architectures that don't have pci compiled in. > > If

Re: Scheduler hack for multi-threaded processes

> Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > Date: Sat, 19 Mar 2016 13:53:07 +0100 > > From: Martin Pieuchot <m...@openbsd.org> > > > > Applications using multiple threads often call sched_yie

Re: Scheduler hack for multi-threaded processes

> Date: Wed, 23 Mar 2016 22:16:36 +0100 > From: Martin Pieuchot <m...@openbsd.org> > > On 23/03/16(Wed) 21:35, Mark Kettenis wrote: > > > Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET) > > > From: Mark Kettenis <mark.kette...@xs4all.nl> > > &

mpsafe aesni

Diff below makes aesni crypto "mpsafe". It adds a CRYPTOCAP_F_MPSAFE flag that makes the crypto framework dispatch to an mpsafe taskq if it is set. In order to make the aesni_process() function that does the actual crypto work mpsafe, it moves the code over to a per-session working buffer. This

Re: realpath additions

> Date: Mon, 21 Mar 2016 15:31:42 +0300 > From: Alexei Malinin > > Hello. > > I'm not sure but it seems to me that there are several missed things: > - checking path against NULL, POSIX says that we should return EINVAL in that case. > - setting errno to ENOMEM in case

Re: New scheduler for OpenBSD

> Date: Sat, 19 Mar 2016 09:06:26 +0100 > From: Alexandre Ratchov <a...@caoua.org> > > On Fri, Mar 18, 2016 at 08:00:35PM +0100, Mark Kettenis wrote: > > > From: Bob Beck <b...@openbsd.org> > > > Date: Fri, 18 Mar 2016 09:20:35 -0600 > > &

Re: vnet(4) memory leak

> Date: Sat, 19 Mar 2016 14:15:47 +0100 > From: Stefan Sperling > > A sparc64 machine of mine crashes every few weeks because the kernel > runs out of memory. > > The crash usually happens in a malloc call in the vnet(4) ioctl code path. > I have a cronjob which downs/up vnet

Re: Scheduler hack for multi-threaded processes

> Date: Sat, 19 Mar 2016 13:53:07 +0100 > From: Martin Pieuchot > > Applications using multiple threads often call sched_yield(2) to > indicate that one of the threads cannot make any progress because > it is waiting for a resource held by another one. > > One example of this

Re: mpsafe aesni

> From: Mike Belopuhov <m...@belopuhov.com> > Date: Thu, 24 Mar 2016 21:33:25 +0100 > > On 24 March 2016 at 20:53, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > Diff below makes aesni crypto "mpsafe". It adds a CRYPTOCAP_F_MPSAFE > >

Re: Scheduler hack for multi-threaded processes

> From: attila > Date: Sat, 26 Mar 2016 17:47:38 -0600 > > Jyri Hovila [Turvamies.fi] writes: > > > I can report significant usability improvement on a single core > > ThinkPad T42 and a dual core ThinkPad X60. > > I hate to crap on this

Re: Double resched_proc() in setrunnable()

> Date: Sun, 27 Mar 2016 12:00:04 +0200 > From: Martin Pieuchot > > Diff below moves resetpriority() out of updatepri() and resched_proc() > out of resetpriority() in order to expose a double resched_proc() call > in setrunnable(). > > This happens when a thread has slept for

Re: uvm: remove unused(?) amap_extend

> Date: Sat, 26 Mar 2016 23:02:52 +0100 > From: Martin Pieuchot > > On 26/03/16(Sat) 19:19, Stefan Kempf wrote: > > Stefan Kempf wrote: > > > amap_extend is called when merging two adjacent areas of virtual address > > > space. However, merging is done only for kernel > > >

acpi gpio support

/null 1 Jan 1970 00:00:00 - +++ bytgpio.c 27 Mar 2016 19:18:31 - @@ -0,0 +1,242 @@ +/* $OpenBSD$ */ +/* + * Copyright (c) 2016 Mark Kettenis + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided

Re: Fix overflow check in sys/kern/kern_time.c

> Date: Wed, 23 Mar 2016 10:58:42 -0400 > From: Michael McConville > > I'm not sure whether avoiding incrementing here is an ideal move, but > this diff definitely works toward a local optimum. Namely, that error > check is technically meaningless because signed overflow is

Re: Scheduler hack for multi-threaded processes

> From: Amit Kulkarni > Date: Sun, 20 Mar 2016 17:57:49 -0500 > > On Sat, Mar 19, 2016 at 4:35 PM, Bob wrote: > > > > > I'm also interested in hearing from more people using multi-threaded > >> applications. > >> > > > > I applied the patch to my old

Re: amd64: foo() -> foo(void)

> Date: Sun, 6 Mar 2016 23:08:11 +0100 > From: Christian Weisgerber > > Match (and fix) the function declarations. > > PS: I'll do i386 and sparc64, too. ok kettenis@ > Index: amd64/consinit.c > === > RCS

Re: fdt: move code from socppc to sys/dev/fdt/

> Date: Thu, 3 Mar 2016 00:56:34 +0100 > From: Patrick Wildt > > On Thu, Mar 03, 2016 at 09:38:25AM +1000, David Gwynne wrote: > > > > > On 2 Mar 2016, at 20:49, Patrick Wildt wrote: > > > > > > Hi, > > > > > > to allow FDT to be used on ARM I think we

Re: Remove WSDISPLAY_COMPAT_SYSCONS

> Date: Thu, 3 Mar 2016 17:30:05 +0100 > From: Christian Weisgerber > > jmc@ stumbled over this. The WSDISPLAY_COMPAT_SYSCONS option was > only ever in i386 GENERIC and it has been disabled there for 15 > years, so I think we can safely delete it, whatever it was used for >

Re: anyone using gdb "kvm proc/pcb" ?

> Date: Sat, 2 Apr 2016 20:42:15 -0700 > From: Philip Guenther > > The gdb in base, when used against a live kernel or crash dump, is > supposed to be able to backtrace individual threads via the kvm proc and > kvm pcb commands. Is anyone actually using these on 5.9 or

Re: anyone using gdb "kvm proc/pcb" ?

> Date: Sun, 3 Apr 2016 00:39:14 -0700 > From: Philip Guenther > > On Sat, 2 Apr 2016, Philip Guenther wrote: > > I ask as I see some "this can't work" logic between the kernel and gdb for > > at least i386 and possibly others and I'd like to hear what *is* working > > that

Re: fdt: translate memory addresses

> Date: Sun, 3 Apr 2016 16:57:10 +0200 > From: Patrick Wildt > > Hi, > > now we're able to get a node's memory address. Though, a device tree > may implement so called ranges. Those ranges are used to translate from > one address space to another. > > This is used on a few

Re: uvm: UVM_FLAG_AMAPPAD has no effect anymore, nuke it

> Date: Sun, 3 Apr 2016 16:11:40 +0200 > From: Stefan Kempf > > This flag caused amaps to be allocated with additional spare slots, to > make extending them cheaper. However, the kernel never extends amaps, > so allocating spare slots is pointless. Also UVM_FLAG_AMAPPAD only

Re: amd64: remove savectx() from cpu_fork()

> Date: Sun, 3 Apr 2016 12:04:47 -0700 > From: Philip Guenther > > amd64's savectx() only updates pcb_rsp and pcb_rbp, which in cpu_fork() > are promptly overwriten in the child's pcb, so do the same simplification > as on i386. > > ok? ok kettenis@ > Index: vm_machdep.c

acpi gpio interrupts

Hi Jonathan, Joshua & other interested folks, The diff below adds support for gpio interrupts for the Bay Trail GPIO controller. The acpi gpio interface gets extended with an intr_establish() method that establishes an interrupt on a specific pin. The pin is configured according to the flags

Re: gdb on landisk

> Date: Sun, 27 Mar 2016 23:06:23 + > From: Miod Vallat > > There is a fallout from the switch to binutils 2.17: the binaries > created by 2.17 aren't recognized by the in-tree gdb because it's built > with the bfd code from 2.15. > > My understanding is that the in-tree gdb

Re: handle bogus sparc64 frame buffers

> Date: Mon, 28 Mar 2016 14:21:33 + > From: Miod Vallat > > Some sparc64 pci frame buffers incorrectly have the `depth' property > spelled `depth ' with a trailing space. > > This can be found in this E450 eeprom -p output: > http://pastebin.com/P4ab4Xt4 > > Because of

Re: acpi gpio support

> Date: Sun, 27 Mar 2016 20:29:29 -0700 > From: Philip Guenther <guent...@gmail.com> > > On Sun, Mar 27, 2016 at 12:28 PM, Mark Kettenis <mark.kette...@xs4all.nl> > wrote: > > The diff below is a first stab at adding support for GPIOs as defined > > in ACP

Re: acpi gpio support

> Date: Mon, 28 Mar 2016 21:49:39 +1100 > From: Jonathan Gray <j...@jsg.id.au> > > On Sun, Mar 27, 2016 at 09:28:25PM +0200, Mark Kettenis wrote: > > The diff below is a first stab at adding support for GPIOs as defined > > in ACPI 5.0. The primary target for thi

acpi device attachment

Adding each and every new acpi device driver to acpi_foundhid() is gettingabit of the burden. And it really isn't how our autoconf framework is supposed to work for busses that can be enumerated. All the drivers already check for a matching _HID in their attach function. So we can just drop the

DMA overruns and iommu's

It is pretty clear that the DMA engine on the Davicom dc(4) hardware is broken and will read beyond the end of the buffer that we pass it. This is bad news for hardware that uses an IOMMU, as it will detect the DMA overrun and (at least on sparc64) signal an unrecoverable error. It is somewhat

Re: DMA overruns and iommu's

> Date: Sat, 2 Apr 2016 21:30:55 +0200 > From: Alexander Bluhm > > Should we clear the scratch page to prevent that the dc(4) hardware > may see sensitive information? Good point; new diff below. Index: dev/ic/dc.c

Re: libpthread: simplify syscall wrapping/invocation

> Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=openbsd.org; > dkim=pass header.d=gmail.com; dmarc=pass header.from=gmail.com > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=20120113; >

Re: libpthread: tighten various internal references

> Date: Fri, 1 Apr 2016 23:18:19 -0700 > From: Philip Guenther > > This diff tightens up internal references to exported functions, plus one > pointless syscall. > > This is done via a namespace.h and wrapper headers like the hidden/* added > in the libc source. The files

dwiic attach

The diff below makes the dwiic(4) driver's match function behave like the other acpi attach functions by matching on the _HID. This way it will continue to atach with the diff I sent out earlier today. I deliberately did not use the #define's from acpireg.h here. I intend to remove those. Just

Re: uvm: shrinking amap kmem consumption

> Date: Mon, 21 Mar 2016 20:02:28 +0100 > From: Stefan Kempf > > Recently we found that amaps consume a good deal of kernel address space. > See this thread: https://marc.info/?l=openbsd-tech=145752756005014=2. > And we found a way to reduce kernel mem pressure for some

<    4   5   6   7   8   9   10   11   12   13   >