Re: armv7/omap: introducing amdisplay(4) + nxptda(4)

> Date: Mon, 3 Apr 2017 01:33:28 -0400 > From: Ian Sutton > > This patch introduces preliminary support for the display hardware > onboard the am335x/BeagleBone Black. Included are two drivers, > amdisplay(4) and nxptda(4), which run the LCD controller and HDMI PHY > transmitter

Re: USB polling + xhci(4) fix

> Date: Thu, 9 Mar 2017 16:04:44 +0100 > From: Martin Pieuchot <m...@openbsd.org> > > On 09/03/17(Thu) 15:04, Mark Kettenis wrote: > > > Date: Thu, 9 Mar 2017 14:32:29 +0100 > > > From: Martin Pieuchot <m...@openbsd.org> > > > > > >

armv7 memory segments

For some reason u-boot on the exynos platform decides to split up the memory in banks with a maximum size of 256MB. Since my Odroid XU4 has 2GB of memory, I end up with more memory segments than the two supported by our kernel. The diff below increases the number of segments to 32, which is what

Re: sysctl machdep.fakepckbc=1

> Date: Thu, 9 Mar 2017 16:13:01 +0100 > From: Martin Pieuchot <m...@openbsd.org> > > On 09/03/17(Thu) 14:48, Mark Kettenis wrote: > > > Date: Thu, 9 Mar 2017 14:04:04 +0100 > > > From: Martin Pieuchot <m...@openbsd.org> > > > > >

Re: sysctl machdep.fakepckbc=1

> Date: Thu, 9 Mar 2017 14:04:04 +0100 > From: Martin Pieuchot > > Many of us have x86 machines with a USB keyboard that's unusable in > ddb(4). That's generally because the BIOS presents a fake pckbd(4) > to the OS: > > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 >

Re: USB polling + xhci(4) fix

> Date: Thu, 9 Mar 2017 14:32:29 +0100 > From: Martin Pieuchot > > Diff below move per HC driver polling code to the stack. I know this > code contains a use-after-free and this will be addressed in a later > diff. For the moment merge 4 copies into 1 such that I don't have

OF_getindex() API

A recurring pattern in device trees is that there is a "xxx-names" property that allows you to lookup an entry in the corresponding "xxx" property by names. Examples that we already use in our tree are "clock-names", "reset-names" and "pinctrl-names". There is duplicated code to do this for all

Empty usb vendor and product strings

The GL3521 USB 3 hub on the odroid XU4 returns empty vendor and product strings. That makes us skip the lookup in our own tables and print a "vendor 0x05e3 pruduct 0x0616" string. Not sure if that's intentional (can't think of a good reason). If it isn't, I propose the diff below. ok? Index:

Re: arm64 setjmp/longjmp once again.

> Date: Fri, 10 Mar 2017 02:14:00 -0500 > From: Dale Rahn > > Yesterday's comments about setjmp caused me to dig more deeply into the > function today. Here are several fixes. There is still one possibly > outstanding issue with fpsr. When reading thru the calling convention

Re: Add RTL8153 support to ure(4)

> Date: Sat, 11 Mar 2017 07:23:47 +1000 > From: Jonathan Matthew <jonat...@d14n.org> > > On Fri, Mar 10, 2017 at 08:54:39PM +0100, Mark Kettenis wrote: > > Fairly straightforward port of the changes made to the FreeBSD driver. > > Like re(4) this has a fairly incesti

Add RTL8153 support to ure(4)

Fairly straightforward port of the changes made to the FreeBSD driver. Like re(4) this has a fairly incestious relationship with rgephy(4) as it needs a similar hack to read the media status register. Tests, especially on RTL8152 hardware, and OKs are welcome. Index: dev/usb/if_ure.c

Re: newsyslog timestamp

> From: "Todd C. Miller" > Date: Mon, 13 Mar 2017 16:31:35 -0600 > > How about we just eliminate the "logfile turned over" message > entirely? It's kind of bogus for newsyslog to be writing to the > log files directly. I don't think that message provides any useful >

regmap: device tree reachover

misc.c --- /dev/null 1 Jan 1970 00:00:00 - +++ dev/ofw/ofw_misc.c 8 Mar 2017 21:58:30 - @@ -0,0 +1,81 @@ +/* $OpenBSD$ */ +/* + * Copyright (c) 2017 Mark Kettenis + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is here

Re: exuart(4) diff

> Date: Sun, 5 Mar 2017 13:05:24 +0100 > From: Patrick Wildt <patr...@blueri.se> > > On Sun, Mar 05, 2017 at 12:33:57PM +0100, Mark Kettenis wrote: > > Diff below makes the console on the odroid-xu4 actually work. I don't > > completely understand the current c

arm64 ampintc(4) fix

So here is the diff that brings the changes I made to the armv7 version over to arm64. I've now verified that it actually works. Even better, I've verified that it fixes my Overdrive 1000! It seems not all Overdrives are created equally. The Overdrive 3000 has 8 cores, but the Overdrive 1000

Re: amd64 struct reg

> Date: Tue, 21 Mar 2017 15:57:46 +0100 (CET) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > Date: Mon, 20 Mar 2017 12:26:28 -0400 > > From: Dale Rahn <dr...@dalerahn.com> > > > > On Mon, Mar 20, 2017 at 11:54:03AM +0100, Mark Kettenis wrote:

Re: amd64 struct reg

> Date: Mon, 20 Mar 2017 12:26:28 -0400 > From: Dale Rahn <dr...@dalerahn.com> > > On Mon, Mar 20, 2017 at 11:54:03AM +0100, Mark Kettenis wrote: > > > Date: Mon, 20 Mar 2017 13:31:32 +1100 > > > From: Jonathan Gray <j...@jsg.id.au> > > > Cc: tec

CFI directives support in binutils

This diff extends the support for CFI in binutils with a few directives emitted by clang. Most of the code is stolen from FreeBSD's GPLv2 binutils. Support for the .cfi_sections directive is incomplete; basically we just ignore it. Our binutils only support emitting frame info in the .eh_frame

Re: ./usr/include/g++/std removed from distrib/sets/lists/

> Date: Tue, 18 Apr 2017 11:28:59 +0200 > From: Sebastien Marie > > Hi, > > I saw that with the split of comp lists to gcc/clang parts, > ./usr/include/g++/std entry was removed from comp/mi, and not added > back in comp/gcc.*. > > As the entry is an empty directory, it

Make arm usable from userland

If you just include , uint32_t isn't defined. There is no real reason for this code to use uint32_t. For our ILP32/LP64 ecosystem, unsigned long is the appropriate integer type. ok? Index: arch/arm/include/atomic.h === RCS file:

Re: dvmrpctl: remove unused variable

> Date: Fri, 28 Jul 2017 12:27:15 + > From: Florian Obser > > ... pointed out by clang > > OK? ok kettenis@ > diff --git dvmrpctl/parser.c dvmrpctl/parser.c > index ffbf7c05a1e..17ec5fbb33a 100644 > --- dvmrpctl/parser.c > +++ dvmrpctl/parser.c > @@ -54,7 +54,6 @@

Re: route6d: use correct size for strlcat

> Date: Fri, 28 Jul 2017 12:34:25 + > From: Florian Obser > > clang... > > OK? ok kettenis@ > diff --git route6d/log.c route6d/log.c > index 3dd3aefe558..efaba6900e5 100644 > --- route6d/log.c > +++ route6d/log.c > @@ -93,7 +93,7 @@ vlog(int pri, const char *fmt,

Re: ripctl: remove unused variables

> Date: Fri, 28 Jul 2017 12:32:56 + > From: Florian Obser > > clang... > > OK? ok kettenis@ > diff --git ripctl/parser.c ripctl/parser.c > index e82045f0eb7..08a7e88e71a 100644 > --- ripctl/parser.c > +++ ripctl/parser.c > @@ -54,8 +54,6 @@ static const struct token

Re: nsd: prototypes for __b64_pton and __b64_ntop

> Date: Thu, 27 Jul 2017 19:50:26 + > From: Florian Obser > > ... to silence clang warnings, it kinda has a point... > > e.g.: > > /usr/src/usr.sbin/nsd/zonec.c:642:6: warning: implicit declaration of > function > '__b64_pton' is invalid in C99

efiboot boot path matching

This is apparently very hard. Caught this on arm64 where efi_device_path_depth() returned 0, which resulted in always selecting the first device. Clearly if the first path component (i = 0) matches the desired type, we should return 1, not 0. Here is the amd64 version of the diff which is

Re: sysctl machdep.lidaction=suspend

> Date: Sat, 29 Jul 2017 13:53:43 +0200 > From: Martin Natano > > Words are more descriptive than numbers. Let's use them! > > This diff removes > > sysctl machdep.lidaction=0 > sysctl machdep.lidaction=1 > sysctl machdep.lidaction=2 > > in favor of the

Raspberry Pi Ethernet MAC address

Newer device trees for the Raspberry Pi have reorganized the usb part of the tree. This makes sure we can find the MAC address in those trees as well. Hopefully we can simplify this at some point when we have phased out old firmware. ok? Index: dev/usb/if_smsc.c

rthreads futex implementation fix

The futex-based implementation of mutexes uses _atomic_lock_t for the futex. That's a bit of problem as _atomic_lock_t isn't a 32-bit integer type on sparc64 and landisk. The _atomic_lock_t really is a special type for spin locks. The futex implementation uses atomic operations from though.

Re: efiboot boot path matching

> Date: Mon, 31 Jul 2017 20:35:45 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Sun, Jul 30, 2017 at 11:01:58PM +0200, Mark Kettenis wrote: > > > Date: Sun, 30 Jul 2017 12:20:27 +1000 > > > From: Jonathan Gray <j...@jsg.id.au> > > > >

Fix libexec/ld.so/dlclose regress

Couldn't convince clang not to inline duplicateFun() into bbTest2(). Splitting things out in a seperate file avoids the issue. Fixes the regression test. ok? Index: regress/libexec/ld.so/dlclose/test1/libbb/Makefile === RCS file:

Fix libunwind on i386

So apparently Apple messed up the register numbering, or at least chose to be different: https://reviews.llvm.org/D22508 Fixes the exception handling regression tests on i386 with clang. ok? Index: lib/libunwind/include/libunwind.h

Re: clang ld.so regress failures

> From: "Ted Unangst" <t...@tedunangst.com> > Date: Wed, 02 Aug 2017 00:09:13 -0400 > > Mark Kettenis wrote: > > FAIL libexec/ld.so/dlclose/test1/prog3/prog3 > > > > This fails because clang doesn't respect ELF interposition: > > > >

Re: armv7 void x_intr() vs int x_intr()

> Date: Mon, 31 Jul 2017 16:30:07 +0300 > From: Artturi Alm > > Hi, > > i've been annoyed by this inconsistency for years, and was wondering > if someone would have the time to explain why it is the way it is, or > give me any advice towards the correct fixes. > > i'll

fix format warning

Currently clang ignores the "kprintf" format attribute. I've got a fix for that, but with that fix it complains about the code fixed in the diff below. Now our manual page says: FORMAT OPTIONS The kernel functions don't support as many formatting specifiers as their user space

Re: clang ld.so regress failures

> Date: Tue, 1 Aug 2017 16:46:17 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > FAIL libexec/ld.so/constructor/prog1/prog1 > FAIL libexec/ld.so/constructor/prog2/prog2 > FAIL libexec/ld.so/initfirst/test2/prog1/prog1 > FAIL libexec/ld.so/initfir

Re: DisplayPort MST changes from linux 4.4.79

> Date: Sun, 13 Aug 2017 22:32:47 +1000 > From: Jonathan Gray > > Bring in some DisplayPort MST changes from linux-4.4.y/4.4.79 Sure. > -- > > commit 4ca0f3730e2734f67e648b2b4f12b66673e995e1 > Author: Imre Deak > Date: Wed Jul 19 16:46:32 2017 +0300 >

arm64 setregs

Other architectures have this assignment in their setregs() implementation. I don't fully understand why though. Diff below makes arm64 consistent with the rest, but I don't think it fixes anything. Index: arch/arm64/arm64/machdep.c

Re: hme: incorrect register endian for PCI sun hme devices?

> From: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> > Date: Mon, 14 Aug 2017 19:59:55 +0100 > > On 14/08/17 14:25, Mark Kettenis wrote: > > >> Great, thanks for the information - the fact that the nsphy0 has been > >> detected correctly means that

Re: Please test: HZ bump

> Date: Mon, 14 Aug 2017 16:06:51 -0400 > From: Martin Pieuchot > > I'd like to improve the fairness of the scheduler, with the goal of > mitigating userland starvations. For that the kernel needs to have > a better understanding of the amount of executed time per task. > >

Re: amd64: remove clock warning

> Date: Fri, 11 Aug 2017 17:11:11 -0400 > From: joshua stein > > Removes this useless error that appears on some modern machines: > > RTC BIOS diagnostic error > ff Those bits have lost their meaning a

Re: csu: _dl_printf no longer needed

> Date: Fri, 11 Aug 2017 10:13:16 -0700 > From: Philip Guenther > > The _dl_printf() used to be used in libexec/ld.so/*/archdep.h if an > unexpected type of relocation was encountered in ld.so itself. Those went > away (we test ld.so before installing it; _dl_exit() is

Fix rasops rotation with RI_VCONS

There is a bit too much layering going on and the rasops_erasecols_rotated() and rasops_eraserows_rotated() functions end up calling the vcons functions creating a nice infinite loop. Simplest fix os for them to simply call rasops_putchar_rotated() directly. I don't really see a valid reason not

Re: wscons(4): set WS_KERNEL_COLATTR to WSATTR_HILIT in vt100 emulation

> Date: Sat, 12 Aug 2017 17:06:18 +0200 > From: Frederic Cambus > > Hi tech@, > > Currently, output originating from the kernel is displayed using > WSCOL_WHITE on WSCOL_BLUE, which translates to NORMAL_WHITE on > NORMAL_BLUE. > > When booting in BIOS mode, NORMAL_WHITE is

Implement __cxa_thread_atexit

The diff below implements __cxa_thread_atexit(). Calls to this function are emitted by the compiler to schedule running desctructors for thread_local objects when a thread terminates or calls exit(3). The Linux implementation prevents unloading of shared libraries that registered such destructors

counter-clockwise rasops rotation

Because I have a laptop that needs it. ok? Index: dev/rasops/rasops.c === RCS file: /cvs/src/sys/dev/rasops/rasops.c,v retrieving revision 1.46 diff -u -p -r1.46 rasops.c --- dev/rasops/rasops.c 13 Aug 2017 22:28:23 - 1.46

Re: hme: incorrect register endian for PCI sun hme devices?

> From: Mark Cave-Ayland > Date: Mon, 14 Aug 2017 06:31:34 +0100 > > On 13/08/17 16:52, Kaashif Hymabaccus wrote: > > > Hello Mark, > > > > I have a Sun Ultra 5 with the following dmesg: > > > > console is /pci@1f,0/pci@1,1/ebus@1/se@14,40:a > > Copyright

Re: /sys/dev/fdt/dwmmc.c missing char

> Date: Thu, 17 Aug 2017 13:03:58 +0300 > From: Artturi Alm > > Hi, > > > trying to clean/minimalize another diff adding things, and this is rather > irrelevant to it, so, even if harmless, i'd like to see +| there. > > thanks, in advance:) > -Artturi Fixed. Thanks!

Re: arm/sysreg.h use in C

> Date: Thu, 13 Jul 2017 15:49:03 +0300 > From: Artturi Alm > > On Sat, Jul 01, 2017 at 10:53:14AM +0300, Artturi Alm wrote: > > Hi, > > > > just in case i didn't make it clear what it is for, here's diff "fixing" > > current uses below, compile-tested. > > > > -Artturi

Re: signal info code SEGV_ACCERR

> Date: Thu, 13 Jul 2017 14:54:41 +0200 > From: Alexander Bluhm > > Hi, > > The regress test src/regress/sys/kern/siginfo-fault checks wether > the si_code is set to SEGV_ACCERR after memory access with wrong > permissions has triggert a SIGSEGV. > > Relevant commit

Re: inteldrm(4) diff needs review and testing

Could be your mail client is mangling the diff though. > On Sun, Jul 16, 2017 at 03:19:41PM +0200, Mark Kettenis wrote: > > Can somebody test the following diff on Ivy Bridge or Haswell (Intel > > HD Graphics 2500/4000/4600/4700/5000/5100/5200)? > > > > When I add

Let inteldrm(4) publish a backlight property

Diff below publishes a "Backlight" property that can be used to get and set the backlight associated with a particular output. This property can easily be exported by the X11 graphics drivers trough the RandR protocol. A future diff will let the "modesetting" driver do this and make

Re: Allowing devices to set a minimum wait time at power down/reboot

> Date: Sun, 9 Jul 2017 14:12:34 +0200 (CEST) > From: Stefan Fritsch > > Hi, > > there are some open issues that usb devices do not flush their caches fast > enough (at least on some boards). And my mail about shortening the wait > times in reboot(8) brought up that issue

Re: Let inteldrm(4) publish a backlight property

> Date: Mon, 10 Jul 2017 12:23:08 +0200 > From: Marcus MERIGHI <mcmer-open...@tor.at> > > mark.kette...@xs4all.nl (Mark Kettenis), 2017.07.09 (Sun) 23:41 (CEST): > > Diff below publishes a "Backlight" property that can be used to get > > and set the backl

Use modesetting driver on i965 and up

This diff has been in snaps for a while now. This matches what several major Linux distros do. ok? Index: xserver/hw/xfree86/common/xf86pciBus.c === RCS file: /cvs/xenocara/xserver/hw/xfree86/common/xf86pciBus.c,v retrieving

Re: armv7 small XXX fix

> Date: Mon, 10 Jul 2017 23:18:59 +0300 > From: Artturi Alm > > Hi, > > this does clutter my diffs, and the XXX comment is correct, It probably isn't. None of the other architectures have those macros in their . > currently used _C_LABEL() is nothing, and i find it's

Re: Use modesetting driver on i965 and up

> From: "Ted Unangst" <t...@tedunangst.com> > Date: Mon, 10 Jul 2017 17:36:00 -0400 > > Mark Kettenis wrote: > > This diff has been in snaps for a while now. This matches what > > several major Linux distros do. > > > > ok? > > for

Re: Reduce NET_LOCK() contention part 2

> Date: Tue, 18 Jul 2017 16:08:04 +0200 > From: Martin Pieuchot > > As long as most of the Network Stack run under the NET_LOCK() we want to > avoid grabbing the lock from different contexts. Because when multiple > threads are waiting for the lock, all of them are awaken upon

Re: SIGBUS short mmap object

> From: Theo de Raadt > Date: Mon, 17 Jul 2017 16:06:05 -0600 (MDT) > > Sorry I disagree. SIGSEGV is the right answer. It was not mapped. > That is segmentation. Actually it is mapped in the sense that uvm has created mapping entries for it. The mapping just isn't backed

Re: armv7 sunxi i2c+pmic(=shutdown -p)

> Date: Sun, 9 Jul 2017 20:34:29 +0300 > From: Artturi Alm > > Hi, > > revived the diff below, i2c tested via pmic's shutdown(), for working > "shutdown -p now" operation. > there was only two i2c's w/"status: 'okay'" in the FDT, so not all of > them do attach. > >

inteldrm(4) diff needs review and testing

Can somebody test the following diff on Ivy Bridge or Haswell (Intel HD Graphics 2500/4000/4600/4700/5000/5100/5200)? When I added support for the command parser, I took a bit of a shortcut and implemented the hash tables as a single linked list. This diff fixes that. For the hash function I

Fix for clang-provoked relocation errors

The diff below fixes the /usr/bin/ld: /tmp/BC-10602a.o: relocation R_X86_64_PC32 against `xxx' can not be used when making a shared object; recompile with -fPIC errors that we see with some ports when compiled with clang. It is essentially a diff that was carried for a while in upstream

Better ddb support for inteldrm(4)

Because of the locking changes in the inteldrm(4) update, the code that swicthes to the console framebuffer is pretty much broken. The diff below fixes the issue inteldrm(4) by introducing a new enter_ddb() "accessop" for wsdisplay(4). The implementation of this function should bypass as much of

Re: SIGBUS short mmap object

> Date: Mon, 17 Jul 2017 23:36:17 +0200 > From: Alexander Bluhm > > Hi, > > The tests regress/sys/kern/siginfo-fault accesses an mmap(2)ed file > behind its end. Then it expects an SIGBUS, but gets an SIGSEGV. As you found it, this was a bit controversial. Theo and I

Re: SIGBUS short mmap object

> Date: Thu, 20 Jul 2017 18:18:58 +0200 > From: Alexander Bluhm <alexander.bl...@gmx.net> > > On Thu, Jul 20, 2017 at 02:03:10PM +0200, Mark Kettenis wrote: > > If you can make the BUS_ADRERR -> BUS_OBJERR change (both here and in > > the regress test), this

hppa SIGBUS/SIGSEGV patch

Fixes regress/sys/kern/siginfo-fault on hppa. For some reason the old code munges EACCES into EFAULT so it never actually generated SEGV_ACCERR. ok? Index: arch/hppa/hppa/trap.c === RCS file: /cvs/src/sys/arch/hppa/hppa/trap.c,v

Re: armv7 sunxi i2c+pmic(=shutdown -p)

> Date: Wed, 19 Jul 2017 04:32:45 +0300 > From: Artturi Alm <artturi@gmail.com> > > On Sun, Jul 16, 2017 at 11:13:35PM +0200, Mark Kettenis wrote: > > > Date: Sun, 9 Jul 2017 20:34:29 +0300 > > > From: Artturi Alm <artturi@gmail.com> > >

pcxrtc(4)

=== RCS file: dev/i2c/pcf8563.c diff -N dev/i2c/pcf8563.c --- /dev/null 1 Jan 1970 00:00:00 - +++ dev/i2c/pcf8563.c 24 Jul 2017 19:20:38 - @@ -0,0 +1,286 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2005 Kimihiro Nonaka + * Copyright (c) 2016, 2017 Mark Kettenis + * All

Re: Skylake m5/m7 Xorg to black screen after Jul 10 snapshot

> Date: Mon, 24 Jul 2017 12:55:25 -0700 > From: Bryan Vyhmeister <br...@bsdjournal.net> > > On Mon, Jul 24, 2017 at 09:42:41PM +0200, Mark Kettenis wrote: > > > From: Bryan Vyhmeister <br...@bsdjournal.net> > > > > > > Running wsconsctl dis

Re: DRM pool fix

> Date: Thu, 27 Jul 2017 17:26:57 +0200 > From: Martin Pieuchot > > Fix a copy/paste, found while trying to track the possible leak I'm > seeing. > > ok? Ouch. Eh, yes. ok kettenis@ > Index: i915/i915_gem.c >

Re: printf(3) return value on ENOMEM

> From: "Theo de Raadt" > Date: Wed, 26 Jul 2017 08:07:53 -0600 > > > The current behaviour of our implementation is to return the number > > of characters printed *and* set errno = ENOMEM. > > I expect it should not set errno. As a general rule, errno should > only be set

arm64 SIGBUS/SIGSEGV fixes

This brings arm64 in line with amd64/i386. Makes the siginfo-fault regress test pass. ok? Index: arch/arm64/arm64/trap.c === RCS file: /cvs/src/sys/arch/arm64/arm64/trap.c,v retrieving revision 1.7 diff -u -p -r1.7 trap.c ---

armv7 mmap(2) SIGBUS fix

Already had the SEGV_ACCERR/SEGV_MAPERR bits right. So this just fixes the SIGBUS of access beyond the mapped object. Tried to follow amd64 since it was already close. ok? Index: arch/arm/arm/fault.c === RCS file:

Re: style.9: discourage (void)ing unused return values

> Date: Sat, 22 Jul 2017 15:29:17 +0200 > From: Ingo Schwarze > > Hi Scott, > > Scott Cheloha wrote on Fri, Jul 21, 2017 at 05:03:11PM -0500: > > > Per encouragement from deraadt@, > > Not sure what exactly he said, but i'm quite sure you misunderstood him. > > I have both

Tolerate imprecise fault address in siginfo-fault regress

This makes the tests pass on sparc64 where the hardware doesn't give us the low bits of the faulting address. ok? Index: regress/sys/kern/siginfo-fault/siginfo-fault.c === RCS file:

Re: llvm - xor return pointers

> Date: Sat, 22 Jul 2017 02:25:29 -0400 > From: Todd Mortimer > > Hello tech, > > I've been working on llvm/clang some lately, and am experimenting with > the llvm Pass infrastructure. Passes essentially let you perform > arbitrary transforms on the program at various points in

Re: CVS: cvs.openbsd.org: src

> From: Frank Groeneveld > Date: Tue, 04 Jul 2017 09:38:18 +0200 > > On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote: > > This change *STILL* breaks my $DAYJOB machine. > > > > dmesg with DRMDEBUG enabled > > Maybe you shouldn't chose Apple hardware ;-) Well.

Re: patch: fix inteldrm for Intel P4000 graphics

> Date: Tue, 4 Jul 2017 17:24:27 -0400 > From: "Joe Gidi" > > I have a machine with a Xeon E3-1225v2 CPU, which includes integrated > Intel P4000 graphics. This required a patch back in 2015 to avoid matching > on the mythical "Intel Quanta Transcode" device, which

Re: serial console and ddb

> From: Hrvoje Popovski > Date: Mon, 3 Jul 2017 21:05:01 +0200 > > Hi all, > > i'm having two firewalls fw1 and fw2 and on fw1 i'm sending console > output to com0. > > root@fw1:~ > # cat /etc/boot.conf > stty com0 115200 > set tty com0 > > root@fw1:~ > # cat /etc/ttys | grep

Re: mpsafe malloc(9)

> Date: Wed, 5 Jul 2017 09:44:19 +1000 > From: David Gwynne > > the following adds a mutex to malloc and free to protect their > internal state. this should be enough to make the api mpsafe, > assuming the way they interact with uvm is mpsafe. > > this only uses a single

Re: armv7 small bootstrap improvement/simplification

> Date: Wed, 5 Jul 2017 09:34:59 +0300 > From: Artturi Alm > > On Wed, Jul 05, 2017 at 02:27:46AM +0300, Artturi Alm wrote: > > Hi, > > > > instead of messing w/bs_tags, use the fact pmap_kernel()->pm_refs is going > > to be 0 until pmap_bootstrap() has ran. tmp_bs_tag

Re: install man8/arm64/{MAKEDEV,eeprom}.8

> Date: Wed, 26 Apr 2017 14:56:58 +0100 > From: Stuart Henderson > > ok? Sure. > Index: etc/mtree/4.4BSD.dist > === > RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v > retrieving revision 1.297 > diff -u -p

Re: ARM64: attach CPUs for identification purposes.

> From: David Gwynne <da...@gwynne.id.au> > Date: Tue, 25 Apr 2017 11:06:52 +1000 > > > On 25 Apr 2017, at 6:18 am, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > >> Date: Mon, 24 Apr 2017 16:01:39 -0400 > >> From: Dale Rahn <d

Re: ARM64: attach CPUs for identification purposes.

> Date: Mon, 24 Apr 2017 16:01:39 -0400 > From: Dale Rahn > > The below code is set up to attach and identify processors for arm64 > currently it only identifies model, not cache size, but that can be added > later. It is set up to attach secondary processors later (for when

arm quadruple bus space

On armv7 and arm64 we have this dirty hack to be able to use the com(4) driver on hardware blocks that have the registers spaced differently than the origional NS8250/16450/16550. One they I'm going to fix this properly in com(4) itself, but not today. Now on the Rockchip RK3288, the Synopsis

Make mainbus(4) recognize early attribute on arm64

Here is a diff that makes mainbus(4) behave in a similar way as simplebus(4). Needed for the Firefly-RK3399 since it attaches most devices directly on mainbus(4) and need to control the order a bit. I dropped the "no device tree" panic. We really can't get this far without having an FDT. I'll

arm64 gic-v3 driver

The firefly rk3399 board has a gic-v3, so I'd like to get Dale's driver into the tree. I did some further cleanup, renamed the driver to agintc(4) (as jsg@ felt the "new" in angintc(4) did't make sense) and fixed two bugs: * prival in setipl() was used uninitialized * apparently a dsb

Re: libform remove extra parentheses

> Date: Fri, 28 Jul 2017 20:45:10 + > From: Florian Obser > > same for libform as previous diff for mopd. > > OK? ok kettenis@ > diff --git frm_driver.c frm_driver.c > index de06cdaf8a4..0e8ca3b88a5 100644 > --- frm_driver.c > +++ frm_driver.c > @@ -1285,7 +1285,7 @@

Re: mopd: remove extra parentheses

> Date: Fri, 28 Jul 2017 20:43:06 + > From: Florian Obser > > this silences > > cc -O2 -pipe -I/usr/src/usr.sbin/mopd/mopd -I/usr/src/usr.sbin/mopd/mopd/.. > -I/usr/src/usr.sbin/mopd/mopd/../common -Werror-implicit-function-declaration > -MD -MP -c

Re: efiboot boot path matching

> Date: Sun, 30 Jul 2017 12:20:27 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Sat, Jul 29, 2017 at 09:01:35PM +0200, Patrick Wildt wrote: > > On Sat, Jul 29, 2017 at 02:59:19PM +0200, Mark Kettenis wrote: > > > This is apparently very

Re: fix arm64 format strings

> Date: Wed, 9 Aug 2017 14:01:25 +1000 > From: Jonathan Gray > > Make the kernel build on arm64 again after the recent kprintf changes > in clang. ok kettenis@ > Index: arm64/cpu.c > === > RCS file:

clang ld.so regress failures

Here is my analysis of the ld.so regress failures. None of the actually suggests that there is a bug in ld.so. Cheers, Mark FAIL libexec/ld.so/dlclose/test1/prog3/prog3 This fails because clang doesn't respect ELF interposition:

Re: fix format warning

> Date: Mon, 7 Aug 2017 11:32:55 +0200 (CEST) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > Date: Mon, 7 Aug 2017 11:04:51 +0200 (CEST) > > From: Markus Hennecke <markus-henne...@markus-hennecke.de> > > > > On Thu, 3 Aug 2017, Mark Kette

Fix clang's lgamma(3) builtin

So the regress failure is a clang bug. Already fixed upstream: https://reviews.llvm.org/D29778 ok? Index: gnu/llvm/tools/clang/include/clang/Basic/Builtins.def === RCS file:

efiboot machine exit for armv7 and amd64

This adds a "machine exit" command like we already have on amd64. Main motivation is that this would help including our bootloader in the U-Boot regression tests. This also changes the code to use RS->ResetSystem() on arm64. It seems we don't need the Cubox-i workaround there. Still doesn't do

Enable kprintf format attribute in clang

This makes clang actually do something for kprintf. This is a minimal diff that actually allows some FreeBSD-specific kprintf type specifiers. But I'd prefer to do a proper overhaul of this code upstream first and keep the diffs minimal at this point. ok? Index:

Re: fix format warning

> Date: Mon, 7 Aug 2017 11:04:51 +0200 (CEST) > From: Markus Hennecke <markus-henne...@markus-hennecke.de> > > On Thu, 3 Aug 2017, Mark Kettenis wrote: > > > Currently clang ignores the "kprintf" format attribute. I've got a > > fix for that, but with

Re: counter-clockwise rasops rotation

> Date: Thu, 17 Aug 2017 22:17:44 +0200 > From: Stefan Sperling <s...@stsp.name> > > On Thu, Aug 17, 2017 at 09:28:43PM +0200, Mark Kettenis wrote: > > > Date: Mon, 14 Aug 2017 01:38:56 +0200 (CEST) > > > From: Mark Kettenis <mark.kette...@xs4all.n

Re: partial compat checking w/OF_is_compatible() ?

> Date: Tue, 22 Aug 2017 22:12:51 +0300 > From: Artturi Alm > > Hi, > > i came across dwc2 usb node like this: > > usb@101c { > compatible = "snps,dwc2"; > reg = <0x101c 0x4>; > interrupts = <0x0 0x11

Re: partial compat checking w/OF_is_compatible() ?

> Date: Wed, 23 Aug 2017 00:17:01 +0300 > From: Artturi Alm <artturi@gmail.com> > > On Tue, Aug 22, 2017 at 09:47:27PM +0200, Mark Kettenis wrote: > > > Date: Tue, 22 Aug 2017 22:12:51 +0300 > > > From: Artturi Alm <artturi@gmail.com> > >

Re: arm64 lock: no userland progress, several procs in wchan "vp"

> Date: Wed, 3 May 2017 13:51:22 +0100 > From: Stuart Henderson <s...@spacehopper.org> > > On 2017/05/01 22:18, Mark Kettenis wrote: > > > Date: Mon, 1 May 2017 20:58:29 +0100 > > > From: Stuart Henderson <s...@spacehopper.org> > > > > &g

<    9   10   11   12   13   14   15   16   17   18   >