Re: Multiple cmsghdrs in msghdr
Always fun, cmsg structures. Anyway, I'll try to find some info on
this (maybe Stevens has something to say here).
But your experiments indicate that various Unixes do not agree, so
it's probably better to avoid sending multiple cmsg structures. Or
there is a subtle error in the way you build your messages...
-Otto
On Tue, Apr 14, 2015 at 09:26:25PM -0400, William Orr wrote:
> Hey,
>
> I was debugging a few CPython test failures yesterday, and I noticed
> that attaching multiple cmsg structures causes unp_internalize to return
> EINVAL.
>
> I've looked in unix(4) and sendmsg(2), and this caveat isn't documented
> anywhere.
>
> I looked at other OSes, and Linux supports this, FreeBSD fails in
> interesting ways and OS X returns E2BIG.
>
> Is this behavior intentional, and the documentation is missing this
> failure mode? Or is the behavior unintentional? I'm happy to submit a
> patch for either, I just want to know which behavior is intended.
>
> For reference, the code that returns EINVAL follows:
>
> int
> unp_internalize(struct mbuf *control, struct proc *p)
> {
> struct filedesc *fdp = p->p_fd;
> struct cmsghdr *cm = mtod(control, struct cmsghdr *);
> struct file **rp, *fp;
> int i, error;
> int nfds, *ip, fd, neededspace;
>
> /*
>* Check for two potential msg_controllen values because
>* IETF stuck their nose in a place it does not belong.
>*/
> if (cm->cmsg_type != SCM_RIGHTS || cm->cmsg_level != SOL_SOCKET ||
> !(cm->cmsg_len == control->m_len ||
> control->m_len == CMSG_ALIGN(cm->cmsg_len)))
> return (EINVAL);
> ...
>
> My super-awful test, also follows:
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> void
> child(int sock)
> {
> struct msghdr msg;
> memset(&msg, 0, sizeof(msg));
> recvmsg(sock, &msg, 0);
>
> printf("controllen: %zu\n", msg.msg_controllen);
> printf("control: %p\n", msg.msg_control);
> }
>
> void
> parent(int sock)
> {
> int fds[] = { -1, -1 };
> struct msghdr msg;
> struct cmsghdr *cmsg;
> union {
> struct cmsghdr hdr;
> unsigned charbuf[2 * CMSG_SPACE(sizeof(int))];
> } cmsgbuf;
> char sfn[30];
>
> memset(&msg, 0, sizeof(msg));
> for (int i = 0; i < sizeof(fds); i++) {
> (void)strlcpy(sfn, "/tmp/worrtest.XX", sizeof(sfn));
> if ((fds[i] = mkstemp(sfn)) == -1) {
> err(1, "mkstemp");
> }
> }
>
> msg.msg_control = &cmsgbuf.buf;
> msg.msg_controllen = sizeof(cmsgbuf.buf);
>
> cmsg = CMSG_FIRSTHDR(&msg);
> cmsg->cmsg_len = CMSG_LEN(sizeof(int));
> cmsg->cmsg_level = SOL_SOCKET;
> cmsg->cmsg_type = SCM_RIGHTS;
> *(int *)CMSG_DATA(cmsg) = fds[0];
>
> cmsg = CMSG_NXTHDR(&msg, cmsg);
> cmsg->cmsg_len = CMSG_LEN(sizeof(int));
> cmsg->cmsg_level = SOL_SOCKET;
> cmsg->cmsg_type = SCM_RIGHTS;
> *(int *)CMSG_DATA(cmsg) = fds[1];
>
> if (sendmsg(sock, &msg, 10240) == -1)
> err(1, "sendmsg");
> }
>
> int
> main(void)
> {
> int sock[] = {-1, -1};
>
> if (socketpair(AF_UNIX, SOCK_STREAM, 0, sock) == -1)
> err(1, "socket");
>
> switch (fork()) {
> case 0:
> child(sock[0]);
> exit(0);
> case -1:
> err(1, "fork");
> default:
> parent(sock[1]);
> exit(0);
> }
> }
>
>
> Thanks,
> William Orr
>
>
>
>
>
Re: Multiple cmsghdrs in msghdr
> Date: Tue, 14 Apr 2015 21:26:25 -0400 > From: William Orr > > Hey, > > I was debugging a few CPython test failures yesterday, and I noticed > that attaching multiple cmsg structures causes unp_internalize to return > EINVAL. > > I've looked in unix(4) and sendmsg(2), and this caveat isn't documented > anywhere. > > I looked at other OSes, and Linux supports this, FreeBSD fails in > interesting ways and OS X returns E2BIG. > > Is this behavior intentional, and the documentation is missing this > failure mode? Or is the behavior unintentional? I'm happy to submit a > patch for either, I just want to know which behavior is intended. The behaviour is intentional. The additional complexity of supporting multiple cmsghdrs has caused many bugs (and associated security issues) in the past. The alignment fuckups in various OSes make it hard to use this functionality in a portable way anyway. And we only support SCM_RIGHTS, so there is no real reason to use multiple cmsghdrs in your code.
Re: Multiple cmsghdrs in msghdr
On Wed, Apr 15, 2015 at 11:32:11AM +0200, Mark Kettenis wrote: > > Date: Tue, 14 Apr 2015 21:26:25 -0400 > > From: William Orr > > > > Hey, > > > > I was debugging a few CPython test failures yesterday, and I noticed > > that attaching multiple cmsg structures causes unp_internalize to return > > EINVAL. > > > > I've looked in unix(4) and sendmsg(2), and this caveat isn't documented > > anywhere. > > > > I looked at other OSes, and Linux supports this, FreeBSD fails in > > interesting ways and OS X returns E2BIG. > > > > Is this behavior intentional, and the documentation is missing this > > failure mode? Or is the behavior unintentional? I'm happy to submit a > > patch for either, I just want to know which behavior is intended. > > The behaviour is intentional. The additional complexity of supporting > multiple cmsghdrs has caused many bugs (and associated security > issues) in the past. The alignment fuckups in various OSes make it > hard to use this functionality in a portable way anyway. And we only > support SCM_RIGHTS, so there is no real reason to use multiple > cmsghdrs in your code. Plus it *is* possible to send multiple fd's in one message. -Otto
Re: [NEW] Driver for the Araneus Alea II USB TRNG
On 14/04/15(Tue) 15:22, attila wrote:
> Martin Pieuchot writes:
> >>
> >> static const struct usb_devno ualea_devs[] = {
> >>{ USB_VENDOR_ARANEUS, USB_PRODUCT_ARANEUS_ALEA }
> >> };
> >
> > Is it possible to match your device based on the content of the device
> > descriptor instead of whitelisting IDs? Whitelisting means that if the
> > company produce a compatible device with a new ID we'll need to modify
> > the driver.
> >
>
> Sadly, I don't think it is possible... you mean by looking at
> bDeviceClass/bDeviceSubClass/bDeviceProtocol? He only gives me zeroes
> [...]
> Perhaps I am misunderstanding; is there something else in there I
> could/should match on? I've changed the attach routine in the updated
> version to check vendor/product/iface, at least.
I was thinking at bInterfaceClass and bInterfaceProtocol but when they
are both to "vendor defined" (255), matching against the ID is the right
thing to do.
> I looked and it appears that M_ZERO is used when allocating the memory
> for all of these structures, so I take it that explicit zeroing of
> things when tearing down is neither required nor desired? I removed
> this kind of thing from ualea.c because it looked like it wasn't
> necessary.
That's right.
> I'm attaching the updated driver.
>
> Thank you for the critique. I suppose I need to write a man page for
> this as well... working on it.
Perfect, I'll put it in tree together with your driver :)
>
> Pax, -A
> --
> att...@stalphonsos.com | http://trac.haqistan.net/~attila
> keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E AC29 9677 D0A6 E6CC 1EDB
>
>
> /*$OpenBSD$ */
> /*
> * Copyright (c) 2006 Alexander Yurchenko
> * Copyright (c) 2007 Marc Balmer
> * Copyright (C) 2015 attila
> *
> * Permission to use, copy, modify, and distribute this software for any
> * purpose with or without fee is hereby granted, provided that the above
> * copyright notice and this permission notice appear in all copies.
> *
> * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> */
>
> /*
> * Alea II TRNG. Produces 100kbit/sec of entropy by black magic
> *
> * Product information in English can be found here:
> * http://www.araneus.fi/products/alea2/en/
> */
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define ALEA_IFACE0
> #define ALEA_MSECS100
> #define ALEA_READ_TIMEOUT 1000
> #define ALEA_BUFSIZ ((1024/8)*100) /* 100 kbits */
>
> #define DEVNAME(_sc) ((_sc)->sc_dev.dv_xname)
>
> struct ualea_softc {
> struct device sc_dev;
> struct usbd_device *sc_udev;
> struct usbd_pipe *sc_pipe;
> struct timeout sc_timeout;
> struct usb_task sc_task;
> struct usbd_xfer *sc_xfer;
> int *sc_buf;
> };
>
> int ualea_match(struct device *, void *, void *);
> void ualea_attach(struct device *, struct device *, void *);
> int ualea_detach(struct device *, int);
> void ualea_task(void *);
> void ualea_timeout(void *);
>
> struct cfdriver ualea_cd = {
> NULL, "ualea", DV_DULL
> };
>
> const struct cfattach ualea_ca = {
> sizeof(struct ualea_softc),
> ualea_match,
> ualea_attach,
> ualea_detach
> };
>
> int
> ualea_match(struct device *parent, void *match, void *aux)
> {
> struct usb_attach_arg *uaa = aux;
>
> if (uaa->iface == NULL)
> return (UMATCH_NONE);
> if ((uaa->vendor == USB_VENDOR_ARANEUS) &&
> (uaa->product == USB_PRODUCT_ARANEUS_ALEA) &&
> (uaa->ifaceno == ALEA_IFACE))
> return (UMATCH_VENDOR_PRODUCT);
> return (UMATCH_NONE);
> }
>
> void
> ualea_attach(struct device *parent, struct device *self, void *aux)
> {
> struct ualea_softc *sc = (struct ualea_softc *)self;
> struct usb_attach_arg *uaa = aux;
> usb_interface_descriptor_t *id;
> usb_endpoint_descriptor_t *ed;
> int ep_ibulk = -1;
> usbd_status error;
> int i;
>
> sc->sc_udev = uaa->device;
> id = usbd_get_interface_descriptor(uaa->iface);
> for (i = 0; i < id->bNumEndpoints; i++) {
> ed = usbd_interface2endpoint_descriptor(uaa->iface, i);
> if (ed == NULL) {
> printf("%s: failed to get endpoint %d descriptor\n",
> DEVNAME(sc), i);
> return;
> }
> if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN &&
>
Re: autoinstall(8) tweaks
On Wed, Apr 15, 2015 at 08:20:15AM +0900, Ryan McBride wrote: > On Thu, Apr 09, 2015 at 04:27:17AM -0600, Theo de Raadt wrote: > > > But it seems people are expected to build a custom bsd.rd if they > > > want something different so I'll bow out of this conversation. > > > > No, the situation is that less than 1% of the user community > > apparently have a secret usage case, but never manage to explain it. > > > > I manage a bunch of OpenBSD proxies that I would like to be able to > build from scratch using automated tools; everything is in place > (ansible) except for the base OpenBSD install as I need a separate > /var/squid partition to prevent cache / log disasters from filling /var; > similar concerns would apply to many other data / log-heavy daemons. > > On other systems where I don't know how the data will grow, I typically > configure them with something close to the auto layout, but a smaller > /home, and leave the remaining disk empty. When I get a feel for what > the data usage is in /var/ or /home or /usr/local, I can expand > /home or create a new partition and migrate the data. The default allocation is actually easy to rework right after a fresh install, as /usr/src, /usr/obj and /home are at the end. Ssh as root, kill /usr/src, /usr/obj and /home, optionally extend /usr/local, and then repartition as you wish. As for swap and /tmp, you can move /tmp to the end, at worst you will lose 4G worth of disk space you can add to swap. And if you need more than 2x RAM swap, you have bigger problems than partitioning. > Other reasons to want non-auto partitioning like include: > - simpler dump/restore Yeah, "embrace failure" is what all the cool kids do these days. Except that this kind of non-management just sweeps problems under the rug so they can mature into propers monsters ready to gnaw at your skull at the worst possible moment. > - moving certain parts of hier(7) onto a different device > (you can do this as a post-install task if they are empty, but > it becomes a pain if it's something that's part of base) > > A place where the latter can be quite useful is on a virtualised guest, > where you can easily make one storage device persistant, and another > ephemeral across reboots. Which part of baseXX, compXX, manXX, gameXX, xbaseXX, xfontXX, xservXX or xshareXX would fall under such a case ? None. > Yes, all of this can be done manually, but basically any place I would > care to work at is moving towards complete automation of system installs > (for *hack*Cloud*spit*, Continuous Delivery, DR, or just plain old > laziness). It would be really nice if the OpenBSD installer would handle > this in a sane fashion. Do you want me to write an ansible playbook to run a handful of shell commands over ssh ? Cheers, -- Vincent Gross
Re: autoinstall(8) tweaks
On 2015-04-15 Wed 12:05 PM |, Vincent Gross wrote: > > The default allocation is actually easy to rework right after a fresh > install, as /usr/src, /usr/obj and /home are at the end. Ssh as > root, kill /usr/src, /usr/obj and /home, optionally extend /usr/local, > and then repartition as you wish. > Maybe try install.site or rc.firsttime to automate that. > As for swap and /tmp, you can move /tmp to the end, at worst you will > lose 4G worth of disk space you can add to swap. >
Re: File protection, second attempt
On 14 Apr 2015, at 18:35, Mike Belopuhov wrote:
>
> Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
Underlying uvm calls are not mp safe and not protected by KERNEL_LOCK() calls.
[ping] dump -U by default
Hi,
Here is a patch that eliminate the -U flag for dump and make usage of
DUID in /etc/dumpdates the default. It also correct old style entries so
nothing has to be done for the admin :)
Index: dump.8
===
RCS file: /cvs/src/sbin/dump/dump.8,v
retrieving revision 1.48
diff -u -p -r1.48 dump.8
--- dump.8 17 Jul 2014 19:58:05 - 1.48
+++ dump.8 7 Apr 2015 11:28:33 -
@@ -40,7 +40,7 @@
.Sh SYNOPSIS
.Nm dump
.Bk -words
-.Op Fl 0123456789acnSUuWw
+.Op Fl 0123456789acnSuWw
.Op Fl B Ar records
.Op Fl b Ar blocksize
.Op Fl d Ar density
@@ -229,13 +229,6 @@ The
flag is mutually exclusive from the
.Fl u
flag.
-.It Fl U
-Use the
-.Xr disklabel 8
-UID instead of the device name when updating
-.Pa /etc/dumpdates
-and when searching for the date of the latest
-lower-level dump.
.It Fl u
Update the file
.Pa /etc/dumpdates
@@ -244,7 +237,9 @@ The format of
.Pa /etc/dumpdates
is human readable, consisting of one
free format record per line:
-filesystem name,
+filesystem name (defaults to
+.Xr disklabel 8
+UID when possible),
increment level
and
.Xr ctime 3
Index: dump.h
===
RCS file: /cvs/src/sbin/dump/dump.h,v
retrieving revision 1.22
diff -u -p -r1.22 dump.h
--- dump.h 3 Sep 2014 02:34:34 - 1.22
+++ dump.h 7 Apr 2015 11:28:33 -
@@ -60,7 +60,6 @@ char *duid; /* duid of the disk being d
char lastlevel; /* dump level of previous dump */
char level; /* dump level of this dump */
intuflag; /* update flag */
-intUflag; /* use duids in dumpdates flag */
intdiskfd; /* disk file descriptor */
inttapefd; /* tape file descriptor */
intpipeout;/* true => output to standard output */
Index: itime.c
===
RCS file: /cvs/src/sbin/dump/itime.c,v
retrieving revision 1.19
diff -u -p -r1.19 itime.c
--- itime.c 16 Jan 2015 06:39:57 - 1.19
+++ itime.c 7 Apr 2015 11:28:33 -
@@ -125,7 +125,7 @@ getdumptime(void)
int i;
char *fname;
- fname = Uflag ? duid : disk;
+ fname = duid ? duid : disk;
#ifdef FDEBUG
msg("Looking for name %s in dumpdates = %s for level = %c\n",
fname, dumpdates, level);
@@ -139,7 +139,8 @@ getdumptime(void)
* and older date
*/
ITITERATE(i, ddp) {
- if (strncmp(fname, ddp->dd_name, sizeof(ddp->dd_name)) != 0)
+ if ((strncmp(fname, ddp->dd_name, sizeof(ddp->dd_name)) != 0) &&
+ (strncmp(disk, ddp->dd_name, sizeof(ddp->dd_name)) != 0))
continue;
if (ddp->dd_level >= level)
continue;
@@ -165,7 +166,7 @@ putdumptime(void)
quit("cannot rewrite %s: %s\n", dumpdates, strerror(errno));
fd = fileno(df);
(void) flock(fd, LOCK_EX);
- fname = Uflag ? duid : disk;
+ fname = duid ? duid : disk;
free((char *)ddatev);
ddatev = 0;
nddates = 0;
@@ -176,8 +177,10 @@ putdumptime(void)
quit("fseek: %s\n", strerror(errno));
spcl.c_ddate = 0;
ITITERATE(i, dtwalk) {
- if (strncmp(fname, dtwalk->dd_name,
- sizeof(dtwalk->dd_name)) != 0)
+ if ((strncmp(fname, dtwalk->dd_name,
+sizeof(dtwalk->dd_name)) != 0) &&
+ (strncmp(disk, dtwalk->dd_name,
+sizeof(dtwalk->dd_name)) != 0))
continue;
if (dtwalk->dd_level != level)
continue;
Index: main.c
===
RCS file: /cvs/src/sbin/dump/main.c,v
retrieving revision 1.54
diff -u -p -r1.54 main.c
--- main.c 20 Jan 2015 18:22:20 - 1.54
+++ main.c 7 Apr 2015 11:28:33 -
@@ -115,7 +115,7 @@ main(int argc, char *argv[])
usage();
obsolete(&argc, &argv);
- while ((ch = getopt(argc, argv, "0123456789aB:b:cd:f:h:ns:ST:UuWw")) !=
-1)
+ while ((ch = getopt(argc, argv, "0123456789aB:b:cd:f:h:ns:ST:uWw")) !=
-1)
switch (ch) {
/* dump level */
case '0': case '1': case '2': case '3': case '4':
@@ -183,10 +183,6 @@ main(int argc, char *argv[])
lastlevel = '?';
break;
- case 'U':
- Uflag = 1; /* use duids */
- break;
-
case 'u': /* update /etc/dumpdates */
uflag = 1;
break;
@@ -394,11 +390,9 @@ main(int argc, char *argv[])
}
if (ioctl(diskfd, DIOCGDINFO, (char *)&lab) < 0)
err(1, "ioctl (DIOCGDI
PATCH: clarifying iked.conf man
Hello, iked.conf's man page is a bit fuzzy on how local and peer ip defaults are set. This patch below attempts to fix that. Also, can you take a look at my previous nat-on-ipsec-on-iked patchset ? see http://marc.info/?l=openbsd-tech&m=142662971007779&w=2 Cheers, Index: iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.38 diff -u -p -r1.38 iked.conf.5 --- iked.conf.5 28 Feb 2015 21:51:57 - 1.38 +++ iked.conf.5 15 Apr 2015 15:02:21 - @@ -334,23 +334,21 @@ see the file .It Ic local Ar localip Ic peer Ar remote The .Ic local -parameter specifies the address or FQDN of the local endpoint. -Unless the gateway is multi-homed or uses address aliases, -this option is generally not needed. -.Pp -The +and .Ic peer -parameter specifies the address or FQDN of the remote endpoint. -For host-to-host connections where +parameters specify the address or FQDN of the local and remote +endpoints respectively. +If neither are specified, their default values are equal to +.Ar src +and .Ar dst -is identical to -.Ar remote , -this option is generally not needed as it will be set to -.Ar dst -automatically. -If it is not specified or if the keyword -.Ar any -is given, the default peer is used. +for +.Ar localip +and +.Ar remote +respectively. When only one is specified, the other +defaults to +.Ar any . .It Xo .Ic ikesa .Ic auth Ar algorithm
Re: autoinstall(8) tweaks
Am 15.04.2015 01:20 schrieb Ryan McBride: On other systems where I don't know how the data will grow, I typically configure them with something close to the auto layout, but a smaller /home, and leave the remaining disk empty. When I get a feel for what the data usage is in /var/ or /home or /usr/local, I can expand /home or create a new partition and migrate the data. Wouldnt that be just the point? Keep the auto-layout in "big" mode as it is but do not assign all remains to /home but only x/% GB and leave the remains of the disk unallocated. + default secure splitted mountpoints untouched + no need to fuzz with the installer + less burden on "post install" by shrinking/redoing /home to gather space for /var/foobar or whatever + speeds the install-time on large disks ;-) - new heuristics for xGB /home needed 2ct or less.
Re: [NEW] Driver for the Araneus Alea II USB TRNG
Martin Pieuchot writes:
> On 14/04/15(Tue) 15:22, attila wrote:
>> Martin Pieuchot writes:
>> >>
>> >> static const struct usb_devno ualea_devs[] = {
>> >> { USB_VENDOR_ARANEUS, USB_PRODUCT_ARANEUS_ALEA }
>> >> };
>> >
>> > Is it possible to match your device based on the content of the device
>> > descriptor instead of whitelisting IDs? Whitelisting means that if the
>> > company produce a compatible device with a new ID we'll need to modify
>> > the driver.
>> >
>>
>> Sadly, I don't think it is possible... you mean by looking at
>> bDeviceClass/bDeviceSubClass/bDeviceProtocol? He only gives me zeroes
>> [...]
>> Perhaps I am misunderstanding; is there something else in there I
>> could/should match on? I've changed the attach routine in the updated
>> version to check vendor/product/iface, at least.
>
> I was thinking at bInterfaceClass and bInterfaceProtocol but when they
> are both to "vendor defined" (255), matching against the ID is the right
> thing to do.
>
>> I looked and it appears that M_ZERO is used when allocating the memory
>> for all of these structures, so I take it that explicit zeroing of
>> things when tearing down is neither required nor desired? I removed
>> this kind of thing from ualea.c because it looked like it wasn't
>> necessary.
>
> That's right.
>
>> I'm attaching the updated driver.
>>
>> Thank you for the critique. I suppose I need to write a man page for
>> this as well... working on it.
>
> Perfect, I'll put it in tree together with your driver :)
>
Man page attached. I am also attaching an updated copy of the driver
(only copyright changed).
Thanks so much for your help. I look forward to contributing more.
Pax, -A
--
att...@stalphonsos.com | http://trac.haqistan.net/~attila
keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E AC29 9677 D0A6 E6CC 1EDB
.\" $OpenBSD$
.\"
.\" Copyright (c) 2007 Marc Balmer
.\" Copyright (c) 2015 attila
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.Dd $Mdocdate$
.Dt UALEA 4
.Os
.Sh NAME
.Nm ualea
.Nd Araneus Alea II USB TRNG
.Sh SYNOPSIS
.Cd "ualea* at uhub?"
.Sh DESCRIPTION
The
.Nm
driver provides support for the Araneus Alea II, a USB true random
number generator (TRNG).
It delivers 100kbit/sec of hardware-generated entropy.
.Nm
reads raw entropy from the Alea II and uses
.Xr add_true_randomness 9
to add it to the system entropy pool.
.Pp
The product documentation states that the USB interface used by the
Alea II is the same as that used by its predecessor the Alea I;
theoretically this means that the Alea I should work but this has not
been tested.
.Sh SEE ALSO
.Xr intro 4 ,
.Xr usb 4 ,
.Xr add_true_randomness 9 ,
.Sh HISTORY
The
.Nm
driver first appeared in
.Ox 5.7 .
.Sh AUTHORS
The
.Nm
driver was written by
.An attila Aq Mt att...@stalphonsos.com .
/* $OpenBSD$ */
/*
* Copyright (c) 2006 Alexander Yurchenko
* Copyright (c) 2007 Marc Balmer
* Copyright (C) 2015 Sean Levy
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/*
* Alea II TRNG. Produces 100kbit/sec of entropy by black magic
*
* Product information in English can be found here:
* http://www.araneus.fi/products/alea2/en/
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define ALEA_IFACE 0
#define ALEA_MSECS 100
#define ALEA_READ_TIMEOUT 1000
#define ALEA_BUFSIZ ((1024/8)*100) /* 100 kbits */
#define DEVNAME(_sc) ((_sc)->sc_dev.dv_xname)
struct ualea_softc {
struct device sc_dev;
struct usbd_device *sc_udev;
struct usbd_pipe *sc_pipe;
struct timeout
pkg_* new functionality: arch, version expansion
was requested by sthen@
works with pkg.conf and PKG_PATH, similar sequences as for dpb:
%a -> architecture
%c -> either snapshots or version number
%v -> always version number.
please test/comment
just tried it after rewriting:
installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/%c/packages/%a/
in pkg.conf
Index: OpenBSD/PackingElement.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm,v
retrieving revision 1.239
diff -u -p -r1.239 PackingElement.pm
--- OpenBSD/PackingElement.pm 25 Feb 2015 16:37:15 - 1.239
+++ OpenBSD/PackingElement.pm 15 Apr 2015 15:53:09 -
@@ -1750,6 +1750,15 @@ sub stringize($)
my ($machine_arch, $arch);
+sub arch
+{
+ if (!defined $arch) {
+ my $cmd = OpenBSD::Paths->uname." -m";
+ chomp($arch = `$cmd`);
+ }
+ return $arch;
+}
+
sub check
{
my ($self, $forced_arch) = @_;
@@ -1768,11 +1777,7 @@ sub check
chomp($machine_arch = `$cmd`);
}
return 1 if $ok eq $machine_arch;
- if (!defined $arch) {
- my $cmd = OpenBSD::Paths->uname." -m";
- chomp($arch = `$cmd`);
- }
- return 1 if $ok eq $arch;
+ return 1 if $ok eq arch();
}
return;
}
Index: OpenBSD/PackageRepository/Installed.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/Installed.pm,v
retrieving revision 1.29
diff -u -p -r1.29 Installed.pm
--- OpenBSD/PackageRepository/Installed.pm 15 Jun 2014 23:49:51 -
1.29
+++ OpenBSD/PackageRepository/Installed.pm 15 Apr 2015 15:53:09 -
@@ -26,6 +26,40 @@ use warnings;
package OpenBSD::PackageRepositoryBase;
+my ($version, $current);
+
+sub expand_locations
+{
+ my ($class, $string, $state) = @_;
+ if ($string eq '%a') {
+ require OpenBSD::PackingElement;
+ return OpenBSD::PackingElement::Arch::arch();
+ } else {
+ if (!defined $version) {
+ require OpenBSD::Paths;
+ open my $cmd, '-|',
+ OpenBSD::Paths->sysctl, '-n', 'kern.version';
+ my $line = <$cmd>;
+ close($cmd);
+ if ($line =~ m/^OpenBSD (\d\.\d)(\S*)\s/) {
+ $version = $1;
+ if ($2 eq '-current') {
+ $current = 'snapshots';
+ } else {
+ $current = $version;
+ }
+ } else {
+ $state->fatal("Can't figure out version");
+ }
+ }
+ if ($string eq '%c') {
+ return $current;
+ } else {
+ return $version;
+ }
+ }
+}
+
sub parse_url
{
my ($class, $r, $state) = @_;
@@ -40,6 +74,7 @@ sub parse_url
$$r = '';
}
+ $path =~ s/\%[vac]/$class->expand_locations($&, $state)/ge;
$path .= '/' unless $path =~ m/\/$/;
bless { path => $path, state => $state }, $class;
}
Re: File protection, second attempt
On 15 April 2015 at 13:29, kanonenvogel@gmail.com
wrote:
>
> On 14 Apr 2015, at 18:35, Mike Belopuhov wrote:
>>
>> Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
> Underlying uvm calls are not mp safe
True.
> and not protected by KERNEL_LOCK() calls.
>
They are, see pool_allocator_alloc.
Re: [ping] dump -U by default
On Wed, Apr 15, 2015 at 5:48 AM, Manuel Giraud wrote: > Here is a patch that eliminate the -U flag for dump and make usage of > DUID in /etc/dumpdates the default. It also correct old style entries so > nothing has to be done for the admin :) Yeah, I've started using this and it looks good so far. Just a couple corner cases to verify tonight and presuming it looks good I'll commit tonight. Philip Guenther
Re: [ping] dump -U by default
> On Wed, Apr 15, 2015 at 5:48 AM, Manuel Giraud wrote: > > Here is a patch that eliminate the -U flag for dump and make usage of > > DUID in /etc/dumpdates the default. It also correct old style entries so > > nothing has to be done for the admin :) > > Yeah, I've started using this and it looks good so far. Just a couple > corner cases to verify tonight and presuming it looks good I'll commit > tonight. Once everything supports duids, the installer can be switched to use DUID by default, without asking the question about non-DUID use. That would be mainly in support of older machines -- we want their return keys to last longer.
Re: Multiple cmsghdrs in msghdr
On 4/15/15 5:37 AM, Otto Moerbeek wrote: > On Wed, Apr 15, 2015 at 11:32:11AM +0200, Mark Kettenis wrote: > >>> Date: Tue, 14 Apr 2015 21:26:25 -0400 >>> From: William Orr >>> >>> Hey, >>> >>> I was debugging a few CPython test failures yesterday, and I noticed >>> that attaching multiple cmsg structures causes unp_internalize to return >>> EINVAL. >>> >>> I've looked in unix(4) and sendmsg(2), and this caveat isn't documented >>> anywhere. >>> >>> I looked at other OSes, and Linux supports this, FreeBSD fails in >>> interesting ways and OS X returns E2BIG. >>> >>> Is this behavior intentional, and the documentation is missing this >>> failure mode? Or is the behavior unintentional? I'm happy to submit a >>> patch for either, I just want to know which behavior is intended. >> >> The behaviour is intentional. The additional complexity of supporting >> multiple cmsghdrs has caused many bugs (and associated security >> issues) in the past. The alignment fuckups in various OSes make it >> hard to use this functionality in a portable way anyway. And we only >> support SCM_RIGHTS, so there is no real reason to use multiple >> cmsghdrs in your code. > > Plus it *is* possible to send multiple fd's in one message. > > -Otto > Yeah, I was wondering why this was allowed on some OSes in the first place, since it seems redundant. Once I'm not in an airport, I'll submit a docs patch just so that it's clear. re: CPython's test suite, I have a patch in the queue that only enables this behavior on Linux. Thanks, William Orr signature.asc Description: OpenPGP digital signature
Re: pkg_* new functionality: arch, version expansion
On 04/15/15 17:56, Marc Espie wrote:
was requested by sthen@
works with pkg.conf and PKG_PATH, similar sequences as for dpb:
%a -> architecture
%c -> either snapshots or version number
%v -> always version number.
please test/comment
just tried it after rewriting:
installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/%c/packages/%a/
in pkg.conf
Index: OpenBSD/PackingElement.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm,v
retrieving revision 1.239
diff -u -p -r1.239 PackingElement.pm
--- OpenBSD/PackingElement.pm 25 Feb 2015 16:37:15 - 1.239
+++ OpenBSD/PackingElement.pm 15 Apr 2015 15:53:09 -
@@ -1750,6 +1750,15 @@ sub stringize($)
my ($machine_arch, $arch);
+sub arch
+{
+ if (!defined $arch) {
+ my $cmd = OpenBSD::Paths->uname." -m";
+ chomp($arch = `$cmd`);
+ }
+ return $arch;
+}
+
sub check
{
my ($self, $forced_arch) = @_;
@@ -1768,11 +1777,7 @@ sub check
chomp($machine_arch = `$cmd`);
}
return 1 if $ok eq $machine_arch;
- if (!defined $arch) {
- my $cmd = OpenBSD::Paths->uname." -m";
- chomp($arch = `$cmd`);
- }
- return 1 if $ok eq $arch;
+ return 1 if $ok eq arch();
}
return;
}
Index: OpenBSD/PackageRepository/Installed.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/Installed.pm,v
retrieving revision 1.29
diff -u -p -r1.29 Installed.pm
--- OpenBSD/PackageRepository/Installed.pm 15 Jun 2014 23:49:51 -
1.29
+++ OpenBSD/PackageRepository/Installed.pm 15 Apr 2015 15:53:09 -
@@ -26,6 +26,40 @@ use warnings;
package OpenBSD::PackageRepositoryBase;
+my ($version, $current);
+
+sub expand_locations
+{
+ my ($class, $string, $state) = @_;
+ if ($string eq '%a') {
+ require OpenBSD::PackingElement;
+ return OpenBSD::PackingElement::Arch::arch();
+ } else {
+ if (!defined $version) {
+ require OpenBSD::Paths;
+ open my $cmd, '-|',
+ OpenBSD::Paths->sysctl, '-n', 'kern.version';
+ my $line = <$cmd>;
+ close($cmd);
+ if ($line =~ m/^OpenBSD (\d\.\d)(\S*)\s/) {
+ $version = $1;
+ if ($2 eq '-current') {
+ $current = 'snapshots';
I've seen at least -beta versions short before release locks. Not
sure if there are -alpha too? Those should be treated
same way as snapshots, I think.
+ } else {
+ $current = $version;
+ }
+ } else {
+ $state->fatal("Can't figure out version");
+ }
+ }
+ if ($string eq '%c') {
+ return $current;
+ } else {
+ return $version;
+ }
+ }
+}
+
sub parse_url
{
my ($class, $r, $state) = @_;
@@ -40,6 +74,7 @@ sub parse_url
$$r = '';
}
+ $path =~ s/\%[vac]/$class->expand_locations($&, $state)/ge;
$path .= '/' unless $path =~ m/\/$/;
bless { path => $path, state => $state }, $class;
}
Re: Multiple cmsghdrs in msghdr
On Wed, Apr 15, 2015 at 11:21 AM, William Orr wrote: > On 4/15/15 5:37 AM, Otto Moerbeek wrote: >> On Wed, Apr 15, 2015 at 11:32:11AM +0200, Mark Kettenis wrote: >> Date: Tue, 14 Apr 2015 21:26:25 -0400 From: William Orr ... Is this behavior intentional, and the documentation is missing this failure mode? Or is the behavior unintentional? I'm happy to submit a patch for either, I just want to know which behavior is intended. >>> >>> The behaviour is intentional. The additional complexity of supporting >>> multiple cmsghdrs has caused many bugs (and associated security >>> issues) in the past. The alignment fuckups in various OSes make it >>> hard to use this functionality in a portable way anyway. And we only >>> support SCM_RIGHTS, so there is no real reason to use multiple >>> cmsghdrs in your code. >> >> Plus it *is* possible to send multiple fd's in one message. > > Yeah, I was wondering why this was allowed on some OSes in the first > place, since it seems redundant. > > Once I'm not in an airport, I'll submit a docs patch just so that it's > clear. > > re: CPython's test suite, I have a patch in the queue that only enables > this behavior on Linux. If CPython exposes the raw C APIs, then it would be good to patch their docs too, to indicate that multiple fds should be passed in one cmsg and not as separate cmsgs... Philip Guenther
Re: Change the way we handle interface/connected networks
On Wed, Mar 18, 2015 at 05:46:34AM +0100, Claudio Jeker wrote:
> On Tue, Mar 17, 2015 at 05:35:21PM +0100, Martin Pieuchot wrote:
> > On 12/02/15(Thu) 12:35, Martin Pieuchot wrote:
> > > On 10/02/15(Tue) 03:04, Claudio Jeker wrote:
> > > > There is no need to not allow the same network to be configured more
> > > > then
> > > > once. Instead just rely on the multipath and priority handling of the
> > > > routing table to select the right route.
> > > > Additionally this removes cloned routes (arp/npd cache) when the
> > > > interface
> > > > goes down or when the any of the multipath cloning route is changed.
> > > >
> > > > With this it is possible to run 2 dhclients on wired and wireless with a
> > > > bridged network. Active TCP sessions still fail when the cable is
> > > > unplugged. To fix this more is needed.
> > > >
> > > > This changes a fundamental part of the network stack and therefor broad
> > > > testing is needed to find all the hidden dragons.
> > >
> > > Here's version of the diff rebased on top of the recent changes.
> >
> > I think it's the time to get this in, then as a second step put the
> > dhclient(8) bits.
> >
> > Claudio you have my ok.
>
> It is broken for IPv6 and I could not find the proper fix yet. I think I
> now why it goes wrong but the nd6 code is a nightmare.
>
> I will send out a new diff once I have IPv6 fixed.
>
Unsurprisingly IPv6 needs to be special and is not using rt_ifa_add or
rt_ifa_del in all cases. There are three special cases that do the same
dance but use ifa->ifa_addr as the gateway and because of this the
resulting interface routes are not catched by the nd6 code (RTF_LLINFO is
missing). When the routes are then cloned nd6 is not invoced and
everything points back to the host. Oups.
The following updated diff seems to fix this but I only minimally tested
the IPv6 part. People using IPv6 may want to give this a spin.
IMO the net/if_var.h and netinet/ip_carp.c changes could be commited
before the rest since there should be no noticeable change in how carp
works.
--
:wq Claudio
Index: net/if_var.h
===
RCS file: /cvs/src/sys/net/if_var.h,v
retrieving revision 1.24
diff -u -p -r1.24 if_var.h
--- net/if_var.h7 Apr 2015 10:46:20 - 1.24
+++ net/if_var.h12 Apr 2015 11:47:03 -
@@ -389,6 +389,7 @@ do {
\
/* default interface priorities */
#define IF_WIRED_DEFAULT_PRIORITY 0
#define IF_WIRELESS_DEFAULT_PRIORITY 4
+#define IF_CARP_DEFAULT_PRIORITY 15
/*
* Network stack input queues.
Index: net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.208
diff -u -p -r1.208 route.c
--- net/route.c 26 Mar 2015 11:02:44 - 1.208
+++ net/route.c 4 Apr 2015 08:31:34 -
@@ -554,6 +554,16 @@ rtdeletemsg(struct rtentry *rt, u_int ta
return (error);
}
+static inline int
+rtequal(struct rtentry *a, struct rtentry *b)
+{
+ if (memcmp(rt_key(a), rt_key(b), rt_key(a)->sa_len) == 0 &&
+ memcmp(rt_mask(a), rt_mask(b), rt_mask(a)->sa_len) == 0)
+ return 1;
+ else
+ return 0;
+}
+
int
rtflushclone1(struct radix_node *rn, void *arg, u_int id)
{
@@ -561,7 +571,8 @@ rtflushclone1(struct radix_node *rn, voi
rt = (struct rtentry *)rn;
parent = (struct rtentry *)arg;
- if ((rt->rt_flags & RTF_CLONED) != 0 && rt->rt_parent == parent)
+ if ((rt->rt_flags & RTF_CLONED) != 0 && (rt->rt_parent == parent ||
+ rtequal(rt->rt_parent, parent)))
rtdeletemsg(rt, id);
return 0;
}
@@ -1106,16 +1117,20 @@ rt_ifa_add(struct ifaddr *ifa, int flags
{
struct rtentry *rt, *nrt = NULL;
struct sockaddr_rtlabel sa_rl;
+ struct sockaddr_dl sa_dl = { sizeof(sa_dl), AF_LINK };
struct rt_addrinfo info;
u_short rtableid = ifa->ifa_ifp->if_rdomain;
- u_int8_t prio = RTP_CONNECTED;
+ u_int8_t prio = ifa->ifa_ifp->if_priority + RTP_STATIC;
int error;
+ sa_dl.sdl_type = ifa->ifa_ifp->if_type;
+ sa_dl.sdl_index = ifa->ifa_ifp->if_index;
+
memset(&info, 0, sizeof(info));
info.rti_ifa = ifa;
- info.rti_flags = flags;
+ info.rti_flags = flags | RTF_MPATH;
info.rti_info[RTAX_DST] = dst;
- info.rti_info[RTAX_GATEWAY] = ifa->ifa_addr;
+ info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)&sa_dl;
info.rti_info[RTAX_LABEL] =
rtlabel_id2sa(ifa->ifa_ifp->if_rtlabelid, &sa_rl);
@@ -1170,8 +1185,9 @@ rt_ifa_del(struct ifaddr *ifa, int flags
struct sockaddr *deldst;
struct rt_addrinfo info;
struct sockaddr_rtlabel sa_rl;
+ struct sockaddr_dl sa_dl
Re: pkg_* new functionality: arch, version expansion
On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: > I've seen at least -beta versions short before release locks. Not > sure if there are -alpha too? Those should be treated > same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ?
Re: File protection, second attempt
On 15 Apr 2015, at 19:45, Mike Belopuhov wrote:
> On 15 April 2015 at 13:29, kanonenvogel@gmail.com
> wrote:
>>
>> On 14 Apr 2015, at 18:35, Mike Belopuhov wrote:
>>>
>>> Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
>> Underlying uvm calls are not mp safe
>
> True.
>
>> and not protected by KERNEL_LOCK() calls.
>>
>
> They are, see pool_allocator_alloc.
Ok I see.
But pool_get() calls msleep() which is quite similar to tlseep() but lacks the
'kernel_lock is locked' assert. Except ktrace related calls those functions
look mp safe, and my system didn't crash without this assertion.
Assertion "KASSERT(timo || __mp_lock_held(&kernel_lock))" looks
here. Also system has didn't crash with unlocked tsleep()
and wakeup() calls.
getnanotime() and friends functions are mp safe too.
0001-Wrong-assertion-from-tsleep-removed.patch
Description: Binary data
0002-Pipe-locks.patch
Description: Binary data
inteldrm/radeondrm running -current
Hi folks, Earlier today, I committed a diff that includes a check that the drm ioctls return a proper error code. If you see something like: drmioctl: cmd 0xXX errno -YY in your dmesg or on your console, please let me know. Thanks, Mark
Re: inteldrm/radeondrm running -current
On Wed, Apr 15, 2015, at 11:56 PM, Mark Kettenis wrote: > Hi folks, > > Earlier today, I committed a diff that includes a check that the drm > ioctls return a proper error code. If you see something like: > > drmioctl: cmd 0xXX errno -YY > > in your dmesg or on your console, please let me know. > > Thanks, > > Mark > Hi Mark, The only intel drm messages I receive on my current snapshot (Apr 14) are (1 - see below). I see an Apr 15 snapshot on NYC*BUG though I doubt there's a way to test if your patch is included there and probably better to wait a couple of days before updating? I'm running: inteldrm0 at vga1 drm0 at inteldrm0 error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10 error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns inteldrm0: 1366x768 the shop claims the intel card is: 'Intel HD Graphics 4400' "ATI Radeon HD 8500M" rev 0x00 at pci3 dev 0 function 0 not configured 1) error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid14978:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 Regards, Adam
On github now
Well, I’ve put "/usr/src/sys" subtree from 5.7 with my patches on guthub. I would really like to get it more traction on that. https://github.com/Kanonenvogel/openbsd-sys-5.7-smp
