Booting Threadripper 2950x with -current
Hi @tech, I just got through building a new desktop machine and thought I'd install OpenBSD -current on it. The install kernel booted quite fast, but now that I have the real kernel there, it takes approximately 5 minutes to boot. The vast majority of the time is spent at the very beginning where the "spinning text graphic" sits there until it kicks out a number and then does the next one (not sure what to call that). How could I provide appropriate info to help debug this and get a fix in? I'm guessing that not too many people are running on this CPU. By the way, all 32 cores show up on it! Thanks.
unveil hotplugd
Hi,
Now that I'm finally on my new home and tree is opened again...
hotplugd(8) needs to open(2) `device' with read permissions, /dev/hotplug by
default but can be changed via arguments. Then it needs read/execute on both
_PATH_ETC_HOTPLUG_{ATTACH,DETACH} to access(2) and execl(3) them.
Tested successfully attaching/dettaching (mount/umount) an USB pen. Comments?
OK?
Index: hotplugd.c
===
RCS file: /cvs/src/usr.sbin/hotplugd/hotplugd.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 hotplugd.c
--- hotplugd.c 31 Jul 2016 20:13:12 - 1.14
+++ hotplugd.c 22 Apr 2019 23:02:50 -
@@ -61,9 +61,6 @@ main(int argc, char *argv[])
struct sigaction sact;
struct hotplug_event he;
- if (pledge("stdio rpath proc exec", NULL) == -1)
- err(1, "pledge");
-
while ((ch = getopt(argc, argv, "d:")) != -1)
switch (ch) {
case 'd':
@@ -79,6 +76,15 @@ main(int argc, char *argv[])
argv += optind;
if (argc > 0)
usage();
+
+ if (unveil(device, "r") == -1)
+ err(1, "unveil");
+ if (unveil(_PATH_ETC_HOTPLUG_ATTACH, "rx") == -1)
+ err(1, "unveil");
+ if (unveil(_PATH_ETC_HOTPLUG_DETACH, "rx") == -1)
+ err(1, "unveil");
+ if (pledge("stdio rpath proc exec", NULL) == -1)
+ err(1, "pledge");
if ((devfd = open(device, O_RDONLY | O_CLOEXEC)) == -1)
err(1, "%s", device);
Re: libevent: Protect integer multiplications (min_heap)
On Sun, Apr 21, 2019 at 08:53:11PM +0200, Alexander Bluhm wrote:
> I wonder whether SIZE_T_MAX would be better than -1. But they seem
> to be equivalent.
I prefer SIZE_T_MAX as well.
> > Index: min_heap.h
> > ===
> > RCS file: /cvs/src/lib/libevent/min_heap.h,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 min_heap.h
> > --- min_heap.h 20 Apr 2019 23:22:28 - 1.5
> > +++ min_heap.h 20 Apr 2019 23:28:09 -
> > @@ -33,7 +33,7 @@
> >
> > typedef struct min_heap {
> > struct event **p;
> > - unsigned n, a;
> > + size_t n, a;
> > } min_heap_t;
Changing n means that at least timeout_correct in event.c must be
adjusted as well, because it is used as an unsigned:
static void
timeout_correct(struct event_base *base, struct timeval *tv)
{
unsigned int size;
...
size = base->timeheap.n;
for (; size-- > 0; ++pev) {
struct timeval *ev_tv = &(**pev).ev_timeout;
timersub(ev_tv, , ev_tv);
}
...
}
Looking only at min_heap.h it is okay, but takes a bit polishing to be
applicable for all files in libevent.
Tobias
Re: fix link id for p2p interfaces router lsa type 3 link
Remi Locherer(remi.loche...@relo.ch) on 2019.04.22 11:07:18 +0200:
> Hi,
>
> when ospfd originates LSAs for p2p interfaces it puts the interface
> address into the link id field where it should use the network address.
>
> The issue was reported by Mitchell Krome on tech@ and one part of the
> problem was fixed in rde_spf.c revision 1.77.
> --> https://marc.info/?t=15539264081=1=2
>
> This diff fixes the LSAs ospfd sends out.
>
> OK?
ok
> Remi
>
>
> Index: ospfe.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
> retrieving revision 1.103
> diff -u -p -r1.103 ospfe.c
> --- ospfe.c 27 Sep 2018 12:34:06 - 1.103
> +++ ospfe.c 22 Apr 2019 08:47:36 -
> @@ -908,7 +908,8 @@ orig_rtr_lsa(struct area *area)
> rtr_link.id = nbr->addr.s_addr;
> rtr_link.data = 0x;
> } else {
> - rtr_link.id = iface->addr.s_addr;
> + rtr_link.id = iface->addr.s_addr &
> + iface->mask.s_addr;
> rtr_link.data = iface->mask.s_addr;
> }
> rtr_link.type = LINK_TYPE_STUB_NET;
>
Re: Booting Threadripper 2950x with -current
On Mon, Apr 22, 2019 at 10:06:44PM +, Bryan Everly wrote: > Hi @tech, > > I just got through building a new desktop machine and thought I'd > install OpenBSD -current on it. The install kernel booted quite fast, > but now that I have the real kernel there, it takes approximately 5 > minutes to boot. The vast majority of the time is spent at the very > beginning where the "spinning text graphic" sits there until it kicks > out a number and then does the next one (not sure what to call that). That sounds like the part where it's loading the kernel from the disk, which is using BIOS/UEFI functions. Not sure if there's much all that can be done about that. :) > How could I provide appropriate info to help debug this and get a fix > in? I'm guessing that not too many people are running on this CPU. By > the way, all 32 cores show up on it! > 16 cores, half of them are threads. You can disable SMT in the BIOS. ;-) > Thanks. > >
unveil relayd
Hi,
I had a patch with pledge(2) for quite a while ago, but my setup is too simple
and cannot test it enough so at least we can have restricted read access to the
fs in relayd(8)'s main process through unveil(2).
Comments? OK?
Index: relayd.c
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.c,v
retrieving revision 1.174
diff -u -p -u -r1.174 relayd.c
--- relayd.c9 Sep 2018 21:06:51 - 1.174
+++ relayd.c22 Apr 2019 23:36:43 -
@@ -222,6 +222,11 @@ main(int argc, char *argv[])
if (ps->ps_noaction == 0)
log_info("startup");
+ if (unveil("/", "r") == -1)
+ err(1, "unveil");
+ if (unveil(NULL, NULL) == -1)
+ err(1, "unveil");
+
event_init();
signal_set(>ps_evsigint, SIGINT, parent_sig_handler, ps);
Re: iked: fix retransmission bug after simultaneous rekeying
On Thu, Apr 11, 2019 at 04:32:28PM +0200, Tobias Heider wrote:
> Hi,
>
> this patch fixes a bug that appears after simultaneous
> rekeying of the ikesa. Currently the initiator does not set it's
> IKED_REQ_INFORMATIONAL flag when sending the delete request and thus rejects
> the response to the DELETE INFORMATIONAL request in ikev2_recv.
> The request is not removed from the initiators request queue and is
> retransmitted over and over.
>
> The bug can best be reproduced by configuring two iked peers with a short
> ikelifetime (e.g. 10) and looking for INFORMATIONAL receives on the
> responder side.
>
>
> Index: sbin/iked//ikev2.c
> ===
> RCS file: /mount/openbsd/cvs/src/sbin/iked/ikev2.c,v
> retrieving revision 1.168
> diff -u -p -u -r1.168 ikev2.c
> --- sbin/iked//ikev2.c27 Feb 2019 06:33:56 - 1.168
> +++ sbin/iked//ikev2.c11 Apr 2019 14:09:35 -
> @@ -3539,6 +3539,9 @@ ikev2_ikesa_delete(struct iked *env, str
> struct ikev2_delete *del;
>
> if (initiator) {
> + /* XXX: Can not have simultaneous INFORMATIONAL exchanges */
> + if (sa->sa_stateflags & IKED_REQ_INF)
> + goto done;
> /* Send PAYLOAD_DELETE */
> if ((buf = ibuf_static()) == NULL)
> goto done;
> @@ -3550,6 +3553,7 @@ ikev2_ikesa_delete(struct iked *env, str
> if (ikev2_send_ike_e(env, sa, buf, IKEV2_PAYLOAD_DELETE,
> IKEV2_EXCHANGE_INFORMATIONAL, 0) == -1)
> goto done;
> + sa->sa_stateflags |= IKED_REQ_INF;
> log_debug("%s: sent delete, closing SA", __func__);
> done:
> ibuf_release(buf);
>
This makes my iked connections much more stable.
- David
fix link id for p2p interfaces router lsa type 3 link
Hi,
when ospfd originates LSAs for p2p interfaces it puts the interface
address into the link id field where it should use the network address.
The issue was reported by Mitchell Krome on tech@ and one part of the
problem was fixed in rde_spf.c revision 1.77.
--> https://marc.info/?t=15539264081=1=2
This diff fixes the LSAs ospfd sends out.
OK?
Remi
Index: ospfe.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
retrieving revision 1.103
diff -u -p -r1.103 ospfe.c
--- ospfe.c 27 Sep 2018 12:34:06 - 1.103
+++ ospfe.c 22 Apr 2019 08:47:36 -
@@ -908,7 +908,8 @@ orig_rtr_lsa(struct area *area)
rtr_link.id = nbr->addr.s_addr;
rtr_link.data = 0x;
} else {
- rtr_link.id = iface->addr.s_addr;
+ rtr_link.id = iface->addr.s_addr &
+ iface->mask.s_addr;
rtr_link.data = iface->mask.s_addr;
}
rtr_link.type = LINK_TYPE_STUB_NET;
Re: iwn: extend passive dwell time
> Date: Mon, 22 Apr 2019 12:12:18 +0200 > From: Stefan Sperling > > This should make scans on iwn(4) more reliable. > > At present the calculation of 'passive' in iwn_get_passive_dwell_time() > serves no purpose because iwn_limit_dwell() ignores its second parameter. > This looks like an accident. > > Effectively, this diff extends channel dwell time during passive scans > by 20ms on 2Ghz and by 10ms on 5GHz, on top of the default dwell time > of 100ms. Given that most APs use a beacon interval of 100ms, these > small extensions could make the difference between catching a beacon > and not catching it. > > In if_iwnreg.h there's even a comment which says: > * For the most reliable scan, set > AP beacon interval (typically 100msec). > > ok? ok kettenis@ > diff 1afff35ce04b6804bc4ca370e3ec3962d8a5f38a /usr/src > blob - c7bc1ddd8dc8f2637094971d01a3c2915c4ab628 > file + sys/dev/pci/if_iwn.c > --- sys/dev/pci/if_iwn.c > +++ sys/dev/pci/if_iwn.c > @@ -4703,7 +4703,7 @@ iwn_limit_dwell(struct iwn_softc *sc, uint16_t dwell_t > return (MIN(IWN_PASSIVE_DWELL_BASE, ((bintval * 85) / 100))); > > /* No association context? Default */ > - return (IWN_PASSIVE_DWELL_BASE); > + return dwell_time; > } > > uint16_t > >
iwn: extend passive dwell time
This should make scans on iwn(4) more reliable. At present the calculation of 'passive' in iwn_get_passive_dwell_time() serves no purpose because iwn_limit_dwell() ignores its second parameter. This looks like an accident. Effectively, this diff extends channel dwell time during passive scans by 20ms on 2Ghz and by 10ms on 5GHz, on top of the default dwell time of 100ms. Given that most APs use a beacon interval of 100ms, these small extensions could make the difference between catching a beacon and not catching it. In if_iwnreg.h there's even a comment which says: * For the most reliable scan, set > AP beacon interval (typically 100msec). ok? diff 1afff35ce04b6804bc4ca370e3ec3962d8a5f38a /usr/src blob - c7bc1ddd8dc8f2637094971d01a3c2915c4ab628 file + sys/dev/pci/if_iwn.c --- sys/dev/pci/if_iwn.c +++ sys/dev/pci/if_iwn.c @@ -4703,7 +4703,7 @@ iwn_limit_dwell(struct iwn_softc *sc, uint16_t dwell_t return (MIN(IWN_PASSIVE_DWELL_BASE, ((bintval * 85) / 100))); /* No association context? Default */ - return (IWN_PASSIVE_DWELL_BASE); + return dwell_time; } uint16_t
man4/openprom.4 is missing on Octeon
Here is the lost manpage. Index: Makefile === RCS file: /cvs/src/share/man/man4/man4.octeon/Makefile,v retrieving revision 1.13 diff -u -p -r1.13 Makefile --- Makefile12 Jan 2019 17:07:16 - 1.13 +++ Makefile22 Apr 2019 17:59:11 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.13 2019/01/12 17:07:16 visa Exp $ MAN= amdcf.4 cnmac.4 octcib.4 octcit.4 octciu.4 octcrypto.4 octgpio.4 \ - octmmc.4 octrng.4 octrtc.4 octsctl.4 octuctl.4 octxctl.4 + octmmc.4 octrng.4 octrtc.4 octsctl.4 octuctl.4 octxctl.4 openprom.4 MANSUBDIR=octeon .include Index: openprom.4 === RCS file: openprom.4 diff -N openprom.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ openprom.4 22 Apr 2019 17:59:11 - @@ -0,0 +1,150 @@ +.\" Copyright (c) 1992, 1993 +.\"The Regents of the University of California. All rights reserved. +.\" +.\" This software was developed by the Computer Systems Engineering group +.\" at Lawrence Berkeley Laboratory under DARPA contract BG 91-66 and +.\" contributed to Berkeley. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\"notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\"notice, this list of conditions and the following disclaimer in the +.\"documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of the University nor the names of its contributors +.\"may be used to endorse or promote products derived from this software +.\"without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" from: @(#)openprom.4 8.1 (Berkeley) 6/5/93 +.\" +.Dd $Mdocdate: April 22 2019 $ +.Dt OPENPROM 4 octeon +.Os +.Sh NAME +.Nm openprom +.Nd OPENPROM interface +.Sh SYNOPSIS +.In machine/openpromio.h +.Sh DESCRIPTION +The file +.Pa /dev/openprom +is an interface to the Octeon OPENPROM. +This interface is highly stylized; +ioctls are used for all operations. +These ioctls refer to +.Dq nodes , +which are simply +.Dq magic +integer values describing data areas. +Occasionally the number 0 may be used or returned instead, +as described below. +.Pp +The calls that take and/or return a node +use a pointer to an +.Li int +variable for this purpose; +others use a pointer to a +.Li struct opiocdesc +descriptor, +which contains a node and two counted strings. +The first string is comprised of the fields +.Li op_namelen +(an +.Li int ) +and +.Li op_name +(a +.Li "char *" ) , +giving the name of a field. +The second string is comprised of the fields +.Li op_buflen +and +.Li op_buf , +used analogously. +These two counted strings work in a +.Dq value-result +fashion. +At entry to the ioctl, +the counts are expected to reflect the buffer size; +on return, +the counts are updated to reflect the buffer contents. +.Pp +The following ioctls are supported: +.Bl -tag -width OPIOCGETOPTNODE +.It Dv OPIOCGETOPTNODE +Takes nothing, and fills in the options node number. +.It Dv OPIOCGETNEXT +Takes a node number and returns the number of the following node. +The node following the last node is number 0; +the node following number 0 is the first node. +.It Dv OPIOCGETCHILD +Takes a node number and returns the number of the first +.Dq child +of that node. +This child may have siblings; these can be discovered by using +.Dv OPIOCGETNEXT . +.It Dv OPIOCGET +Fills in the value of the named property for the given node. +If no such property is associated with that node, +the value length is set to -1. +If the named property exists but has no value, +the value length is set to 0. +.Dv EINVAL +is returned. +.It Dv OPIOCNEXTPROP +Finds the property whose name follows the given name +in OPENPROM internal order. +The resulting name is returned in the value field. +If the named property is the last, the +.Dq next +name is the empty string. +As with +.Dv OPIOCGETNEXT , +the next name
Re: libevent: Protect integer multiplications (min_heap)
On Mon, Apr 22, 2019 at 01:24:13PM -0400, Ted Unangst wrote:
> ah, good catch. I don't think it's wrong (until it overflows) but needs to be
> fixed. Needs some more review then. Thanks.
I have added following changes:
- converted 0u to 0 as bluhm pointed out
- converted -1 to SIZE_MAX whereever it was used as "illegal index"
as bluhm mentioned as well
- converted timemap's size usages in event.c from (u)int to size_t
Passes regress tests.
I'll discuss this with libevent maintainers to get these changes into
upstream as well.
Index: event.c
===
RCS file: /cvs/src/lib/libevent/event.c,v
retrieving revision 1.38
diff -u -p -u -p -r1.38 event.c
--- event.c 6 Jan 2015 23:11:23 - 1.38
+++ event.c 22 Apr 2019 17:44:17 -
@@ -163,7 +163,8 @@ event_base_new(void)
void
event_base_free(struct event_base *base)
{
- int i, n_deleted=0;
+ int i;
+ size_t n_deleted=0;
struct event *ev;
if (base == NULL && current_base)
@@ -199,7 +200,7 @@ event_base_free(struct event_base *base)
}
if (n_deleted)
- event_debug(("%s: %d events were still set in base",
+ event_debug(("%s: %z events were still set in base",
__func__, n_deleted));
if (base->evsel->dealloc != NULL)
@@ -846,7 +847,7 @@ static void
timeout_correct(struct event_base *base, struct timeval *tv)
{
struct event **pev;
- unsigned int size;
+ size_t size;
struct timeval off;
if (use_monotonic)
Index: event.h
===
RCS file: /cvs/src/lib/libevent/event.h,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 event.h
--- event.h 5 Jan 2015 23:14:36 - 1.30
+++ event.h 22 Apr 2019 17:44:17 -
@@ -196,7 +196,7 @@ struct event {
TAILQ_ENTRY (event) ev_next;
TAILQ_ENTRY (event) ev_active_next;
TAILQ_ENTRY (event) ev_signal_next;
- unsigned int min_heap_idx; /* for managing timeouts */
+ size_t min_heap_idx;/* for managing timeouts */
struct event_base *ev_base;
Index: min_heap.h
===
RCS file: /cvs/src/lib/libevent/min_heap.h,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 min_heap.h
--- min_heap.h 20 Apr 2019 23:22:28 - 1.5
+++ min_heap.h 22 Apr 2019 17:44:17 -
@@ -33,7 +33,7 @@
typedef struct min_heap {
struct event **p;
- unsigned n, a;
+ size_t n, a;
} min_heap_t;
static inline void min_heap_ctor(min_heap_t * s);
@@ -41,14 +41,14 @@ static inline void min_heap_dtor(min_hea
static inline void min_heap_elem_init(struct event * e);
static inline int min_heap_elem_greater(struct event * a, struct event * b);
static inline int min_heap_empty(min_heap_t * s);
-static inline unsigned min_heap_size(min_heap_t * s);
+static inline size_t min_heap_size(min_heap_t * s);
static inline struct event *min_heap_top(min_heap_t * s);
-static inline int min_heap_reserve(min_heap_t * s, unsigned n);
+static inline int min_heap_reserve(min_heap_t * s, size_t n);
static inline int min_heap_push(min_heap_t * s, struct event * e);
static inline struct event *min_heap_pop(min_heap_t * s);
static inline int min_heap_erase(min_heap_t * s, struct event * e);
-static inline void min_heap_shift_up_(min_heap_t * s, unsigned hole_index,
struct event * e);
-static inline void min_heap_shift_down_(min_heap_t * s, unsigned hole_index,
struct event * e);
+static inline void min_heap_shift_up_(min_heap_t * s, size_t hole_index,
struct event * e);
+static inline void min_heap_shift_down_(min_heap_t * s, size_t hole_index,
struct event * e);
int
min_heap_elem_greater(struct event * a, struct event * b)
@@ -70,14 +70,14 @@ void min_heap_dtor(min_heap_t * s) {
void
min_heap_elem_init(struct event * e)
{
- e->min_heap_idx = -1;
+ e->min_heap_idx = SIZE_MAX;
}
int
min_heap_empty(min_heap_t * s)
{
- return 0u == s->n;
+ return 0 == s->n;
}
-unsigned
+size_t
min_heap_size(min_heap_t * s)
{
return s->n;
@@ -102,8 +102,8 @@ min_heap_pop(min_heap_t * s)
{
if (s->n) {
struct event *e = *s->p;
- min_heap_shift_down_(s, 0u, s->p[--s->n]);
- e->min_heap_idx = -1;
+ min_heap_shift_down_(s, 0, s->p[--s->n]);
+ e->min_heap_idx = SIZE_MAX;
return e;
}
return 0;
@@ -112,9 +112,9 @@ min_heap_pop(min_heap_t * s)
int
min_heap_erase(min_heap_t * s, struct event * e)
{
- if (((unsigned int)-1) != e->min_heap_idx) {
+ if (e->min_heap_idx != SIZE_MAX) {
struct event *last = s->p[--s->n];
- unsigned parent = (e->min_heap_idx - 1) / 2;
+ size_t parent = (e->min_heap_idx - 1) / 2;
/*
* we
Re: libevent: Protect integer multiplications (min_heap)
Tobias Stoeckmann wrote: > Changing n means that at least timeout_correct in event.c must be > adjusted as well, because it is used as an unsigned: ah, good catch. I don't think it's wrong (until it overflows) but needs to be fixed. Needs some more review then. Thanks.
Removing old video drivers
Hi, In xenocara, we still build a number of video drivers for very old hardware, that is mostly useless. For AGP, I don't have a working motherboard to test the cards I still have. I also still have a few PCI cards for some of them, but most of them are dead, or don't work as primary display with modern BIOSes. And most important, none of these old cards has enough RAM to run any kind of modern 16 or 32 bpp X at a decent resolution. (And the xserver version 1.20 has dropped support for 24 bits per pixel modes). So rather that try to blindly fix the issues with these drivers I'd rather remove them. This is the list of candidates for removing. If you're still using a machine with a graphics card supported by one of these, please speak up, otherwise they are going to be removed: xf86-video-ark xf86-video-chips xf86-video-glint xf86-video-i128 xf86-video-i740 xf86-video-neomagic xf86-video-rendition xf86-video-s3 xf86-video-s3virge xf86-video-savage xf86-video-sis xf86-video-tdfx xf86-video-trident xf86-video-tseng xf86-video-voodoo For now, we would keep the following non drm/kms drivers: xf86-video-ast xf86-video-cirrus xf86-video-dummy xf86-video-mach64 xf86-video-mga xf86-video-nv xf86-video-openchrome xf86-video-r128 xf86-video-siliconmotion xf86-video-vesa xf86-video-vmware xf86-video-wsfb xf86-video-wsudl and on i386 only: xf86-video-geode -- Matthieu Herrb
Re: libevent: Protect integer multiplications (min_heap)
On Sun, Apr 21, 2019 at 08:53:11PM +0200, Alexander Bluhm wrote:
> I wonder whether SIZE_T_MAX would be better than -1. But they seem
> to be equivalent.
I prefer SIZE_T_MAX as well.
> > Index: min_heap.h
> > ===
> > RCS file: /cvs/src/lib/libevent/min_heap.h,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 min_heap.h
> > --- min_heap.h 20 Apr 2019 23:22:28 - 1.5
> > +++ min_heap.h 20 Apr 2019 23:28:09 -
> > @@ -33,7 +33,7 @@
> >
> > typedef struct min_heap {
> > struct event **p;
> > - unsigned n, a;
> > + size_t n, a;
> > } min_heap_t;
Changing n means that at least timeout_correct in event.c must be
adjusted as well, because it is used as an unsigned:
static void
timeout_correct(struct event_base *base, struct timeval *tv)
{
unsigned int size;
...
size = base->timeheap.n;
for (; size-- > 0; ++pev) {
struct timeval *ev_tv = &(**pev).ev_timeout;
timersub(ev_tv, , ev_tv);
}
...
}
Looking only at min_heap.h it is okay, but takes a bit polishing to be
applicable for all files in libevent.
I haven't inspected all occurrences, so no updated patch yet.
Tobias
Re: xenocara: unlink libFS from the build
On Thu, Mar 14, 2019 at 09:31:59PM +0100, Matthieu Herrb wrote:
> Hi,
>
> all tools dealing with X font server have been already removed, and
> don't seem to be missed since no one asked to re-add them in ports.
>
> Now, libFS, the font server client library can be removed.
> I've checked in sqlports and with a bulk build on amd64 that nothing
> in ports in depending on it either.
>
> ok ?
Ping ?
>
> Index: lib/Makefile
> ===
> RCS file: /cvs/OpenBSD/xenocara/lib/Makefile,v
> retrieving revision 1.41
> diff -u -p -u -r1.41 Makefile
> --- lib/Makefile 11 Sep 2018 19:34:56 - 1.41
> +++ lib/Makefile 14 Mar 2019 20:25:08 -
> @@ -37,7 +37,7 @@ XCB_LIBS= \
>
> SUBDIR= freetype fontconfig libxtrans libXau libXdmcp ${XCB_LIBS}\
> libX11 libXext libXrender libXft libdmx libfontenc \
> - libFS libICE libSM libXt \
> + libICE libSM libXt \
> libXmu libXpm libXaw libXfixes libXcomposite \
> libXdamage libXcursor libXfont2 \
> libXi libXinerama libxkbfile libxkbui \
> Index: distrib/sets/lists/xbase/mi
> ===
> RCS file: /cvs/OpenBSD/xenocara/distrib/sets/lists/xbase/mi,v
> retrieving revision 1.118
> diff -u -p -u -r1.118 mi
> --- distrib/sets/lists/xbase/mi 19 Jan 2019 13:38:38 - 1.118
> +++ distrib/sets/lists/xbase/mi 14 Mar 2019 20:25:09 -
> @@ -206,9 +206,6 @@
> ./usr/X11R6/lib/X11/fvwm/system.fvwm2rc-sample-1
> ./usr/X11R6/lib/X11/fvwm/system.fvwm2rc-sample-2
> ./usr/X11R6/lib/X11/xman.help
> -./usr/X11R6/lib/libFS.a
> -./usr/X11R6/lib/libFS.la
> -./usr/X11R6/lib/libFS.so.10.0
> ./usr/X11R6/lib/libICE.a
> ./usr/X11R6/lib/libICE.la
> ./usr/X11R6/lib/libICE.so.10.0
> Index: distrib/sets/lists/xshare/mi
> ===
> RCS file: /cvs/OpenBSD/xenocara/distrib/sets/lists/xshare/mi,v
> retrieving revision 1.154
> diff -u -p -u -r1.154 mi
> --- distrib/sets/lists/xshare/mi 10 Feb 2019 23:08:36 - 1.154
> +++ distrib/sets/lists/xshare/mi 14 Mar 2019 20:25:09 -
> @@ -423,7 +423,6 @@
> ./usr/X11R6/include/X11/extensions/xtestproto.h
> ./usr/X11R6/include/X11/fonts
> ./usr/X11R6/include/X11/fonts/FS.h
> -./usr/X11R6/include/X11/fonts/FSlib.h
> ./usr/X11R6/include/X11/fonts/FSproto.h
> ./usr/X11R6/include/X11/fonts/font.h
> ./usr/X11R6/include/X11/fonts/fontenc.h
> @@ -713,7 +712,6 @@
> ./usr/X11R6/lib/pkgconfig/ice.pc
> ./usr/X11R6/lib/pkgconfig/inputproto.pc
> ./usr/X11R6/lib/pkgconfig/kbproto.pc
> -./usr/X11R6/lib/pkgconfig/libfs.pc
> ./usr/X11R6/lib/pkgconfig/pciaccess.pc
> ./usr/X11R6/lib/pkgconfig/randrproto.pc
> ./usr/X11R6/lib/pkgconfig/recordproto.pc
> @@ -3798,8 +3796,6 @@
> ./usr/X11R6/share/doc/kbproto/ch15.xml
> ./usr/X11R6/share/doc/kbproto/ch16.xml
> ./usr/X11R6/share/doc/kbproto/xkbproto.xml
> -./usr/X11R6/share/doc/libFS
> -./usr/X11R6/share/doc/libFS/FSlib.txt
> ./usr/X11R6/share/doc/libICE
> ./usr/X11R6/share/doc/libICE/ICElib.xml
> ./usr/X11R6/share/doc/libICE/ice.xml
>
> --
> Matthieu Herrb
--
Matthieu Herrb
Re: Removing old video drivers
(sorry this isn't coming with In-Reply-To/References headers as I read Matthieu's post on marc.info via Mastodon) > So rather that try to blindly fix the issues with these drivers I'd > rather remove them. This is the list of candidates for removing. > > If you're still using a machine with a graphics card supported by > one of these, please speak up, otherwise they are going to be > removed: > > xf86-video-s3 > xf86-video-s3virge I still have one i386 OpenBSD machine with an S3 card (running 6.4, usually tracking releases, so it'll get upgraded to 6.5 here shortly). I'm not positive if this is one of the two S3 drivers on the chopping block, but I at least wanted to wave a "yes, I'm still using an S3 card, albeit lightly" from the back row. $ dmesg | grep vga vga1 at pci1 dev 0 function 0 "S3 Twister" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) $ grep -i s3 /var/log/Xorg.0.log [ 164.119] (II) SAVAGE: driver (version 2.3.9) for S3 Savage chipsets: Savage4, [ 164.279] (II) SAVAGE(0): VESA VBE OEM: S3 Incorporated. Twister BIOS [ 164.279] (II) SAVAGE(0): VESA VBE OEM Vendor: S3 Incorporated. [ 165.680] (II) SAVAGE(0): VESA VBE OEM: S3 Incorporated. Twister BIOS [ 165.680] (II) SAVAGE(0): VESA VBE OEM Vendor: S3 Incorporated. Please let me know if you need any further information. And push come to shove, I can retire the GUI on this machine, as I use it largely out of nostalgia as it was my first 100% OpenBSD machine. Thanks, -Tim
