Re: armv7/stand/efiboot: working BOOTAA64.EFI payload

> I don't see the point in adding a directory without a pmap or toolchain, > but if/when it is added it should probably be arm64. That's an excellent point, history has taught us this: If there is no pmap, there is no need to mkdir.

Re: relayd: sync proc.c and fix startup fd exhaustion

Reyk Floeter writes: > Hi, > > relayd suffers from the same issue that has been fixed in httpd: > > The new fork+exec mode uses too many fds in the parent process on > startup, for a short time, so we needed a rlimit hack in relayd.c. > rzalamena@ has fixed proc.c and I added

Re: armv7/stand/efiboot: working BOOTAA64.EFI payload

On Wed, Nov 23, 2016 at 08:50:56PM -0500, Ian Sutton wrote: > On Wed, Nov 23, 2016 at 05:48:27PM -0700, Theo de Raadt wrote: > > > I am assuming that arch/aarch64 > > > > There should be no such thing. > > > > This game of calling things 5 names has to stop. > > I'm equally irritated and would

Re: armv7/stand/efiboot: working BOOTAA64.EFI payload

On Wed, Nov 23, 2016 at 05:48:27PM -0700, Theo de Raadt wrote: > > I am assuming that arch/aarch64 > > There should be no such thing. > > This game of calling things 5 names has to stop. I'm equally irritated and would like to reach a consensus on a single, final name. I see three candidates:

Re: armv7/stand/efiboot: working BOOTAA64.EFI payload

On Wed, Nov 23, 2016 at 08:49:44PM +0100, Patrick Wildt wrote: > > $ MACHINE=armv8 armmake64-aarch64 -f Makefile.arm64 > > Please call it arm64. We should distinquish between 32 and 64-bit ARMs > now. Yes, the other one is called armv7, but that's just how it is. > > Typically the ports are

[PATCH] List Sierra Wireless EM7455 as supported umb(4) device

I forgot about adding the newly supported Sierra Wireless EM7455 to the umb(4) man page. Bryan Index: share/man/man4/umb.4 === RCS file: /cvs/src/share/man/man4/umb.4,v retrieving revision 1.5 diff -u -p -r1.5 umb.4 ---

Re: bpf_mtap(9) w/o KERNEL_LOCK

On Tue, Nov 22, 2016 at 11:54:47AM +0100, Martin Pieuchot wrote: > Next extract diff that tweaks bpf_detachd(). > > The goal here is to remove ``d'' from the list and NULLify ``d->bd_bif'' > before calling ifpromisc(). > > The reason is that ifpromisc() can sleep. Think USB ;) So we'll have to

Re: vio(4): fixup crash on up/down

On Wed, Nov 23, 2016 at 09:10:44PM +0100, Stefan Fritsch wrote: > On Wed, 23 Nov 2016, Rafael Zalamena wrote: > > > > Maybe something like this is enough already (untested): > > > > I tried your diff without Mike's if_vio diff and it doesn't panic anymore, > > however it doesn't work. > > > >

Re: Relocate some of the vio(4) (re)init code into vio_init

On Wed, 23 Nov 2016, Mike Belopuhov wrote: > This moves code that is supposed to be in init, but is in stop > right now. Tested on qemu. OK? The current code has some symmetry insofar that stop leaves the device in the same state as it is after attach. With your diff, the first vio_init()

Re: Fixup tsleeps in vio(4) and make them interruptable

On Wed, 23 Nov 2016, Mike Belopuhov wrote: > This fixes up tsleep priorities in vio(4) and makes sleeps > interruptable so that ifconfig can be killed with ^C. Tested > on qemu with a previous diff that makes vio(4) hang there. > > OK? I think the tsleep stuff is ok, but the vio_iff() changes

Re: vio(4): fixup crash on up/down

On Wed, 23 Nov 2016, Rafael Zalamena wrote: > > Maybe something like this is enough already (untested): > > I tried your diff without Mike's if_vio diff and it doesn't panic anymore, > however it doesn't work. > > vioX can send packets to host, host receives them and reply, but vioX > doesn't

List Ericsson N5321gw as supported umb(4) device

Hi, the "Lenovo N5321gw" is working for me with umb(4) (https://marc.info/?l=openbsd-misc=147992993614369=2). So mention it as a supported device in umb.4? (Lenovo seems to call it Ericsson N5321gw on its support sites, so I'll use this wording.) OK? Best regards, Ingo Index: umb.4

Re: armv7/stand/efiboot: working BOOTAA64.EFI payload

On Tue, Nov 22, 2016 at 11:02:55PM -0500, Ian Sutton wrote: > Hi, > > Patch adds armv8/aarch64 EFI payload image build support. With > patrick@'s aarch64-none-elf- toolchain referenced in my last mail on > this list, you can build it via... Great! > > $ MACHINE=armv8 armmake64-aarch64 -f

Re: ip6_input() refactoring

On Tue, Nov 22, 2016 at 03:31:05PM +0100, Martin Pieuchot wrote: > This diff merges two "#ifdef MROUTING" blocks. It's one more step > towards splitting ip6_input() in two. Which is a requirement to > unlock the forwarding path without messing with the receiving path. > > ok? The only

Re: UEFI install fails on Hetzner EX51

On 23.11.2016 15:05, Leo Unglaub wrote: > Hey, > > On 11/23/16 14:50, Jiri B wrote: >> So probably something like this? >> >> efibootmgr --create --disk /dev/$disk --part 1 --label "OpenBSD >> (${disk})" --load "\\EFI\\openbsd\\BOOTX64.EFI" > > yeah, i think something like this would work. But i

Re: pf af-to forward

On Mon, Nov 21, 2016 at 07:15:31PM +0100, Mike Belopuhov wrote: > I'm surprised this works as I'm pretty sure it didn't way back when... At least it does work with my regression tests. There I test forwarding, path MTU discovery and tracroute over a router with pf af-to. Protocols are ping,

Re: Unnecessary goto in ip_output()

On Wed, Nov 23, 2016 at 11:02:49AM +0100, Martin Pieuchot wrote: > On 23/11/16(Wed) 06:00, Claudio Jeker wrote: > > On Tue, Nov 22, 2016 at 04:55:17PM +0100, Martin Pieuchot wrote: > > > After the last IPSEC-related refactoring this goto no longer make sense. > > > > > > ok? > > > > Are you

Re: vio(4): fixup crash on up/down

On Wed, Nov 23, 2016 at 09:03:46AM +0100, Stefan Fritsch wrote: > On Wed, 23 Nov 2016, Mike Belopuhov wrote: > > > I guess we could do that. But then we cannot free the mbufs on DOWN > > > until the device has used them. > > > > Diff to this effect is below. Works on vmd and qemu (original > >

Re: reloading pf through ansible easy hook

On Wed, Nov 23, 2016 at 09:40:48AM -0500, sven falempin wrote: > On Mon, Nov 21, 2016 at 5:48 PM, Antoine Jacoutot > wrote: > > > > On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote: > > > Ansible is already managing pkg and service of openBSD , cool > > > > >

Re: reloading pf through ansible easy hook

On Mon, Nov 21, 2016 at 5:48 PM, Antoine Jacoutot wrote: > > On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote: > > Ansible is already managing pkg and service of openBSD , cool > > > > If one want to manage pf with it, and push or modify a few files, > > on

Re: UEFI install fails on Hetzner EX51

Hey, On 11/23/16 15:17, Mark Kettenis wrote: Right, something like that would work if you copy the OpenBSD EFI bootloader into /EFI/OpenBSD/BOOTX64.EFI on the EFI system partition first. why do i have to copy the EFI file first? Does the order matter? If yes, the correct workflow would be

Re: UEFI install fails on Hetzner EX51

> Date: Wed, 23 Nov 2016 08:50:25 -0500 > From: Jiri B > > On Wed, Nov 23, 2016 at 01:55:59PM +0100, Leo Unglaub wrote: > > Hey, > > > > On 11/23/16 13:27, Mark Kettenis wrote: > > >>> Booting the UEFI version of the install.fs works fine and also the > > >>> install works but i

Re: UEFI install fails on Hetzner EX51

Hey, On 11/23/16 14:50, Jiri B wrote: So probably something like this? efibootmgr --create --disk /dev/$disk --part 1 --label "OpenBSD (${disk})" --load "\\EFI\\openbsd\\BOOTX64.EFI" yeah, i think something like this would work. But i am not sure about the --load flag. I would think it

Re: UEFI install fails on Hetzner EX51

On Wed, Nov 23, 2016 at 01:55:59PM +0100, Leo Unglaub wrote: > Hey, > > On 11/23/16 13:27, Mark Kettenis wrote: > >>> Booting the UEFI version of the install.fs works fine and also the > >>> install works but i am unable to boot the server. According the the > >>> datacenter this happens because

Re: UEFI install fails on Hetzner EX51

Hey, On 11/23/16 13:27, Mark Kettenis wrote: > Booting the UEFI version of the install.fs works fine and also the > install works but i am unable to boot the server. According the the > datacenter this happens because OpenBSD does not write an entry in the > mainboards firmware UEFI bootlist

Re: UEFI install fails on Hetzner EX51

> From: Leo Unglaub > Date: Wed, 23 Nov 2016 12:20:24 +0100 > > Hey friends, > first of all i am sorry if this is not for tech@ and more for bugs@ but > to me it seams like a tech@ issue. > > I am trying to install OpenBSD on a Hetzner EX51 server. The specs can > be

Re: vio(4): fixup crash on up/down

On Wed, 23 Nov 2016, Mike Belopuhov wrote: > > I am not convinced. Doing a reset allows to recover from all kinds of > > problems with DOWN/UP. That was useful when we had bugs in the event_idx > > implementation. > > > > I don't think this justifies it since bugs need to be fixed regardless.

UEFI install fails on Hetzner EX51

Hey friends, first of all i am sorry if this is not for tech@ and more for bugs@ but to me it seams like a tech@ issue. I am trying to install OpenBSD on a Hetzner EX51 server. The specs can be found here: https://www.hetzner.de/us/hosting/produkte_rootserver/ex51 In order to use the entire

Re: Unnecessary goto in ip_output()

On 23/11/16(Wed) 06:00, Claudio Jeker wrote: > On Tue, Nov 22, 2016 at 04:55:17PM +0100, Martin Pieuchot wrote: > > After the last IPSEC-related refactoring this goto no longer make sense. > > > > ok? > > Are you shure? I'm not convinced that for an INADDR_BROADCAST destination > the code would

Re: vio(4): fixup crash on up/down

On Wed, Nov 23, 2016 at 09:03 +0100, Stefan Fritsch wrote: > On Wed, 23 Nov 2016, Mike Belopuhov wrote: > > > I guess we could do that. But then we cannot free the mbufs on DOWN > > > until the device has used them. > > > > Diff to this effect is below. Works on vmd and qemu (original > > one

Re: use DRM_IOCTL_GET_PCIINFO in libdrm

> Date: Wed, 23 Nov 2016 11:50:49 +1100 > From: Jonathan Gray > > On Tue, Nov 22, 2016 at 09:29:03PM +0100, Mark Kettenis wrote: > > > Date: Sat, 19 Nov 2016 19:31:18 +1100 > > > From: Jonathan Gray > > > > > > Support libdrm functions required for Mesa versions

Re: add a new DRM_IOCTL_GET_PCIINFO ioctl

> Date: Wed, 23 Nov 2016 11:46:41 +1100 > From: Jonathan Gray > > On Tue, Nov 22, 2016 at 09:26:21PM +0100, Mark Kettenis wrote: > > > Date: Sat, 19 Nov 2016 19:27:25 +1100 > > > From: Jonathan Gray > > > > > > To pull pci information from the kernel for drm

Re: vio(4): fixup crash on up/down

On Wed, 23 Nov 2016, Mike Belopuhov wrote: > > I guess we could do that. But then we cannot free the mbufs on DOWN > > until the device has used them. > > Diff to this effect is below. Works on vmd and qemu (original > one didn't because I kept the virtio_reset). > > > That sounds like an