Fix ifstated(8) "carp?.link.unknown"
Hi, "carp?.link.unknown" doesn't work. carp(4) started using LINK_STATE_INVALID for ifi_link_state instead of LINK_STATE_INVALID(0). ifstated needs to sync this change. ok? Index: usr.sbin/ifstated/ifstated.c === RCS file: /var/cvs/openbsd/src/usr.sbin/ifstated/ifstated.c,v retrieving revision 1.61 diff -u -p -r1.61 ifstated.c --- usr.sbin/ifstated/ifstated.c30 Aug 2017 16:14:52 - 1.61 +++ usr.sbin/ifstated/ifstated.c23 Apr 2018 06:37:14 - @@ -448,7 +448,10 @@ external_evtimer_setup(struct ifsd_state } } -#defineLINK_STATE_IS_DOWN(_s) (!LINK_STATE_IS_UP((_s))) +#defineLINK_STATE_IS_UNKNOWN(_s) ((_s) == LINK_STATE_UNKNOWN || \ + (_s) == LINK_STATE_INVALID) +#defineLINK_STATE_IS_DOWN(_s) (!LINK_STATE_IS_UNKNOWN(_s) && \ + !LINK_STATE_IS_UP((_s))) int scan_ifstate_single(const char *ifname, int s, struct ifsd_state *state) @@ -468,7 +471,7 @@ scan_ifstate_single(const char *ifname, truth = (ifstate->ifstate == IFSD_LINKUNKNOWN && - s == LINK_STATE_UNKNOWN) || + LINK_STATE_IS_UNKNOWN(s)) || (ifstate->ifstate == IFSD_LINKDOWN && LINK_STATE_IS_DOWN(s)) || (ifstate->ifstate == IFSD_LINKUP &&
Re: ccp(4): quick and dirty driver for amd crypto coprocessors
> From: David Gwynne > Date: Mon, 23 Apr 2018 10:38:57 +1000 > > > On 21 Apr 2018, at 05:52, Christian Weisgerber wrote: > > > > On 2018-04-20, Mark Kettenis wrote: > > > >> At some point I tried playing with this on the APU, which has the v3 > >> engine I think. Couldn't get anything to work (but I didn't try very > >> hard). Would be interesting to see whether this actually works on > >> that machine. > > > > It attaches. How can I tell if it works? > > > > ccp0 at pci0 dev 8 function 0 "AMD Cryptographic Co-processor v3" rev 0x00 > > i added printfs in the timeout, but that's pretty invasive. how do > we tell if any rng is working? We can't tell. Our random code doesn't really care. Adding data that isn't really random to the entropy pool shouldn't make our output less random and we don't count entropy anymore.
Re: [patch] man for vgafb(4) should have list of supported architectures
On Tue, Apr 17, 2018 at 04:24:53AM +0300, IL Ka wrote: > diff --git share/man/man4/vgafb.4 share/man/man4/vgafb.4 > index d9ccfa469..6e9a9875c 100644 > --- share/man/man4/vgafb.4 > +++ share/man/man4/vgafb.4 > @@ -31,6 +31,7 @@ > .Nm vgafb > .Nd VGA frame buffer > .Sh SYNOPSIS > +.Cd # sparc64, macppc > .Cd "vgafb* at pci?" > .Cd "wsdisplay* at vgafb?" > .Sh DESCRIPTION fixed, thanks. jmc
Re: Despite the man, wsmouse(4) can't be shared between X(1) and wsmoused(8) (workaround included)
On Sun, Apr 22, 2018 at 05:45:26PM +0100, Jason McIntyre wrote: > On Sun, Apr 22, 2018 at 01:27:40AM +0300, IL Ka wrote: > > man wsmoused: > > "wsmoused will happily coexist with the X Window System, provided that the > > mouse device is supported by wsmouse(4). " > > > > I have wsmouse0 on pms0 (PS/2 controller emulation running on VirtualBox) > > > > When moused works on /dev/wsmouse, X reports > > that device /dev/wsmouse is busy and mouse does not work. > > > > To investigate it, I tried to open(2) it and perror(3) said "Device busy": > > I then stopped wsmoused, and open(2) worked. > > So, X is right: it can't share /dev/wsmouse with wsmoused. > > > > I then created custom ServerLayout for X > > with InputDevice backed by "ws" driver pointing to "/dev/wsmouse0" > > > > and it worked. > > > > So, X can access my mouse directly (via /dev/wsmouse0) but not > > via multiplex (/dev/wsmouse) > > > > I have 2 approaches to fix it: > > 1) Update wsmoused(8) man page and write that user must stop it before X > > 2) Patch "ws" to probe first N mice: it will start X with mouse even if > > wsmoused runs > > > > Which one should I take? > > > > I also suggest to move following phrase from wsmoused(8) to wsmouse(4) man: > > "/dev/wsmouse (the multiplexer device that receives all mouse events from > > all wsmouse compatible mice on the system)" > > > > This information is vital to understand how wsmouse works, and it is not > > easy to find now. > > Should I do that? > > > > > > Ilya. > > at some point, behaviour changed so that you could have one, but not > both. that was deliberate. > > i think we should probably just alter the text that says you can have > both. > > devs? > > jmc i should have attached a diff, just to be clear what i was suggesting: Index: wsmoused.8 === RCS file: /cvs/src/usr.sbin/wsmoused/wsmoused.8,v retrieving revision 1.21 diff -u -r1.21 wsmoused.8 --- wsmoused.8 14 Nov 2015 01:30:11 - 1.21 +++ wsmoused.8 23 Apr 2018 05:48:52 - @@ -49,6 +49,8 @@ .Xr wscons 4 driver. Its purpose is to provide copy/paste functionality on the console. +It does not happily coexist with the X Window System though, +so it has to be killed before starting the X Window System. .Pp By default, the left mouse button is used to select text (in the familiar click-and-drag fashion); @@ -165,16 +167,6 @@ Hitachi tablet protocol. .El .El -.Pp -.Nm -will happily coexist with the X Window System, provided that the mouse -device is supported by -.Xr wsmouse 4 . -Serial mice do not have a -.Xr wsmouse 4 -compatible driver, so -.Nm -has to be killed before starting the X Window System. .Sh EXAMPLES To start wsmoused on the .Nm wsdisplay1
Re: ccp(4): quick and dirty driver for amd crypto coprocessors
> On 21 Apr 2018, at 05:52, Christian Weisgerber wrote: > > On 2018-04-20, Mark Kettenis wrote: > >> At some point I tried playing with this on the APU, which has the v3 >> engine I think. Couldn't get anything to work (but I didn't try very >> hard). Would be interesting to see whether this actually works on >> that machine. > > It attaches. How can I tell if it works? > > ccp0 at pci0 dev 8 function 0 "AMD Cryptographic Co-processor v3" rev 0x00 i added printfs in the timeout, but that's pretty invasive. how do we tell if any rng is working? dlg
Re: Despite the man, wsmouse(4) can't be shared between X(1) and wsmoused(8) (workaround included)
On Sun, Apr 22, 2018 at 01:27:40AM +0300, IL Ka wrote: > man wsmoused: > "wsmoused will happily coexist with the X Window System, provided that the > mouse device is supported by wsmouse(4). " > > I have wsmouse0 on pms0 (PS/2 controller emulation running on VirtualBox) > > When moused works on /dev/wsmouse, X reports > that device /dev/wsmouse is busy and mouse does not work. > > To investigate it, I tried to open(2) it and perror(3) said "Device busy": > I then stopped wsmoused, and open(2) worked. > So, X is right: it can't share /dev/wsmouse with wsmoused. > > I then created custom ServerLayout for X > with InputDevice backed by "ws" driver pointing to "/dev/wsmouse0" > > and it worked. > > So, X can access my mouse directly (via /dev/wsmouse0) but not > via multiplex (/dev/wsmouse) > > I have 2 approaches to fix it: > 1) Update wsmoused(8) man page and write that user must stop it before X > 2) Patch "ws" to probe first N mice: it will start X with mouse even if > wsmoused runs > > Which one should I take? > > I also suggest to move following phrase from wsmoused(8) to wsmouse(4) man: > "/dev/wsmouse (the multiplexer device that receives all mouse events from > all wsmouse compatible mice on the system)" > > This information is vital to understand how wsmouse works, and it is not > easy to find now. > Should I do that? > > > Ilya. at some point, behaviour changed so that you could have one, but not both. that was deliberate. i think we should probably just alter the text that says you can have both. devs? jmc
new semapahore implementation using atomics and futexes
Hi,
Here is a new semaphore implementation that uses atomic operations,
where available, and futexes for locking.
The reason we need this is to make semaphores safe for asynchronous
signals.
All posixsuite tests (semaphore and sigaction) pass with this.
They do not with our current implementation. Unfortunately I can not
get our sem_timedwait regression test to work.
regress/lib/libpthread/semaphore/sem_timedwait
My investigation so far suggests that the current implementation is
flawed because it does not respect ERESTART and treats EINTR as if it
would be equivalent to EAGAIN. The POSIX standard and other
implementations disagree with that: ERESTART should restart the
semaphore waiting and EINTR should exit the call. The above regression
test relies on our current EINTR abuse and I think that is why it fails.
I added a few helpful printfs to that test in my diff.
I hope future discussions at the Nantes hackathon will clarify this
issue.
Otherwise I have been running with this implementation for a couple of
weeks. LaTeX, octave, chrome, firefox, thunderbird, vim, mutt, vlc,
mplayer etc. run just fine.
I would like to get wider testing to see if there are any defects left
in the current version.
I have also added all the changes in a fork on github.
https://github.com/bulibuta/openbsd-src/tree/sem_atomicfutex
Please test and get back to me if you see any issues.
Thank you,
Paul
diff --git lib/librthread/Makefile lib/librthread/Makefile
index 4c3e127491d..5dfb140290e 100644
--- lib/librthread/Makefile
+++ lib/librthread/Makefile
@@ -30,12 +30,19 @@ SRCS= rthread.c \
rthread_rwlock.c \
rthread_rwlockattr.c \
rthread_sched.c \
- rthread_sem.c \
rthread_sig.c \
rthread_stack.c \
rthread_spin_lock.c \
sched_prio.c
+# Architectures that implement atomics
+.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" || \
+${MACHINE_ARCH} == "mips64" || ${MACHINE_ARCH} == "mips64el"
+SRCS+= rthread_sem_atomic.c
+.else
+SRCS+= rthread_sem.c
+.endif
+
SRCDIR= ${.CURDIR}/../libpthread
.include "${SRCDIR}/man/Makefile.inc"
.include
diff --git lib/librthread/rthread_rwlock.c lib/librthread/rthread_rwlock.c
index a75e88c52e4..6fccd2fe1bd 100644
--- lib/librthread/rthread_rwlock.c
+++ lib/librthread/rthread_rwlock.c
@@ -143,8 +143,8 @@ int
pthread_rwlock_timedrdlock(pthread_rwlock_t *lockp,
const struct timespec *abstime)
{
- if (abstime == NULL || abstime->tv_sec < 0 || abstime->tv_nsec < 0 ||
- abstime->tv_nsec > 10)
+ if (abstime == NULL || abstime->tv_nsec < 0 ||
+ abstime->tv_nsec >= 10)
return (EINVAL);
return (_rthread_rwlock_rdlock(lockp, abstime, 0));
}
@@ -210,8 +210,8 @@ int
pthread_rwlock_timedwrlock(pthread_rwlock_t *lockp,
const struct timespec *abstime)
{
- if (abstime == NULL || abstime->tv_sec < 0 || abstime->tv_nsec < 0 ||
- abstime->tv_nsec > 10)
+ if (abstime == NULL || abstime->tv_nsec < 0 ||
+ abstime->tv_nsec >= 10)
return (EINVAL);
return (_rthread_rwlock_wrlock(lockp, abstime, 0));
}
diff --git lib/librthread/rthread_sem_atomic.c
lib/librthread/rthread_sem_atomic.c
new file mode 100644
index 000..f1d8eea4f88
--- /dev/null
+++ lib/librthread/rthread_sem_atomic.c
@@ -0,0 +1,434 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2004,2005,2013 Ted Unangst
+ * Copyright (c) 2018 Paul Irofti
+ * All Rights Reserved.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "rthread.h"
+#include "cancel.h"/* in libc/include */
+#include "synch.h"
+
+#define SHARED_IDENT ((void *)-1)
+
+/* SHA256_DIGEST_STRING_LENGTH includes nul */
+/* "/tmp/" + sha256 + ".sem" */
+#define SEM_PATH_SIZE (5 + SHA256_DIGEST_STRING_LENGTH + 4)
+
+/* long enough to be hard to guess */
+#define SEM_RANDOM_NAME_LEN10
+
+/*
+ * Size of memory to be mmap()'ed by named semaphores.
+ * Should be >= SEM_PATH_SIZE and page-aligned.
+ */
+#define SEM_MMAP_SIZE _thread_pagesize
+
+/*
+ * Internal imp
Re: [PATCH 7/7] em: Add magic delay for HP elitebook 820 G3
On Tue, 10 Apr 2018, Jonathan Gray wrote: > On Sat, Apr 07, 2018 at 01:35:31PM +0200, Stefan Fritsch wrote: > > On Fri, 6 Apr 2018, Jonathan Gray wrote: > > > > > On Thu, Apr 05, 2018 at 09:57:23PM +0200, Stefan Fritsch wrote: > > > > Add another magic 1ms delay that seems to help with some remaining > > > > issues on an HP elitebook 820 G3 with i219LM. A printf() at the same > > > > place helps, too. > > > > > > Could you explain what the problem here was and why this place was > > > chosen to add the delay? > > > > The problems fixed by patches 1-6 were that there were these kinds of > > errors > > > > em0: Hardware Initialization Failed > > em0: Unable to initialize the hardware > > > > either during em_attach (in this case em0 would simply not be available in > > ifconfig) or during ifconfig up. The problems only appeared if there was > > no link (or no cable plugged in) during boot or during resume. > > > > The fixes 1 to 5 made the problem appear much less often, but it still > > appeared sometimes. I had some printfs added and I have never seen the > > problem with the printf present. In the end I traced the "fix" to the > > single printf at this exact location and I replaced it with a delay. > > > > We added Patch 6 (the E1000_TARC0_CB_MULTIQ_2_REQ erratum) later, to fix > > different problems with watchdog timeouts that were only recoverable by a > > reboot, when pulling the cable or when the link was flaky. > > If you have the HP machine that triggers the problem it should be possible > to find which register write the delay is needed after? That should be possible, yes. I don't know when I will have the time for that, though. > > > > > > > > > > --- > > > > sys/dev/pci/if_em_hw.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git sys/dev/pci/if_em_hw.c sys/dev/pci/if_em_hw.c > > > > index 7709a4c5805..d122e727875 100644 > > > > --- sys/dev/pci/if_em_hw.c > > > > +++ sys/dev/pci/if_em_hw.c > > > > @@ -1493,6 +1493,8 @@ em_init_hw(struct em_hw *hw) > > > > /* Set the media type and TBI compatibility */ > > > > em_set_media_type(hw); > > > > > > > > + /* Magic delay that improves problems with i219LM on HP > > > > Elitebook */ > > > > + msec_delay(1); > > > > /* Must be called after em_set_media_type because media_type is > > > > used */ > > > > em_initialize_hardware_bits(hw); > > > > > > > > -- > > > > 2.13.0 > > > > > > > > > > >
Re: [PATCH 4/7] em: Improve access logic for software flag
Sorry for the late response.
On Tue, 10 Apr 2018, Jonathan Gray wrote:
> On Thu, Apr 05, 2018 at 09:57:20PM +0200, Stefan Fritsch wrote:
> > Some em chips have a semaphore ("software flag") to synchronize access
> > to certain registers between OS and firmware (ME/AMT).
> >
> > Make the logic to get the flag match the logic in freebsd. This includes
> > higher timeouts and waiting for a previous unlock to complete before
> > trying a lock again.
>
> Shouldn't the printfs remain as DEBUGOUT() and DEBUGOUT2() as they are
> in FreeBSD?
I am pretty sure that things will break if the SW flag cannot be aquired
and I prefer to have meaningful error messages in that case. But I am fine
either way.
> > ---
> > sys/dev/pci/if_em_hw.c | 22 +++---
> > sys/dev/pci/if_em_hw.h | 2 ++
> > 2 files changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git sys/dev/pci/if_em_hw.c sys/dev/pci/if_em_hw.c
> > index e5084252c29..5bba83cbcd4 100644
> > --- sys/dev/pci/if_em_hw.c
> > +++ sys/dev/pci/if_em_hw.c
> > @@ -9613,9 +9613,21 @@ em_get_software_flag(struct em_hw *hw)
> > if (IS_ICH8(hw->mac_type)) {
> > while (timeout) {
> > extcnf_ctrl = E1000_READ_REG(hw, EXTCNF_CTRL);
> > - extcnf_ctrl |= E1000_EXTCNF_CTRL_SWFLAG;
> > - E1000_WRITE_REG(hw, EXTCNF_CTRL, extcnf_ctrl);
> > + if (!(extcnf_ctrl & E1000_EXTCNF_CTRL_SWFLAG))
> > + break;
> > + msec_delay_irq(1);
> > + timeout--;
> > + }
> > + if (!timeout) {
> > + printf("%s: SW has already locked the resource?\n",
> > + __func__);
> > + return -E1000_ERR_CONFIG;
> > + }
> > + timeout = SW_FLAG_TIMEOUT;
> > + extcnf_ctrl |= E1000_EXTCNF_CTRL_SWFLAG;
> > + E1000_WRITE_REG(hw, EXTCNF_CTRL, extcnf_ctrl);
> >
> > + while (timeout) {
> > extcnf_ctrl = E1000_READ_REG(hw, EXTCNF_CTRL);
> > if (extcnf_ctrl & E1000_EXTCNF_CTRL_SWFLAG)
> > break;
> > @@ -9624,7 +9636,11 @@ em_get_software_flag(struct em_hw *hw)
> > }
> >
> > if (!timeout) {
> > - DEBUGOUT("FW or HW locks the resource too long.\n");
> > + printf("Failed to acquire the semaphore, FW or HW "
> > + "has it: FWSM=0x%8.8x EXTCNF_CTRL=0x%8.8x)\n",
> > + E1000_READ_REG(hw, FWSM), extcnf_ctrl);
> > + extcnf_ctrl &= ~E1000_EXTCNF_CTRL_SWFLAG;
> > + E1000_WRITE_REG(hw, EXTCNF_CTRL, extcnf_ctrl);
> > return -E1000_ERR_CONFIG;
> > }
> > }
> > diff --git sys/dev/pci/if_em_hw.h sys/dev/pci/if_em_hw.h
> > index 5e415e60a34..71dc91e5582 100644
> > --- sys/dev/pci/if_em_hw.h
> > +++ sys/dev/pci/if_em_hw.h
> > @@ -2755,6 +2755,8 @@ struct em_host_command_info {
> > #define AUTO_READ_DONE_TIMEOUT 10
> > /* Number of milliseconds we wait for PHY configuration done after MAC
> > reset */
> > #define PHY_CFG_TIMEOUT 100
> > +/* SW Semaphore flag timeout in ms */
> > +#define SW_FLAG_TIMEOUT1000
> >
> > #define E1000_TX_BUFFER_SIZE ((uint32_t)1514)
> >
> > --
> > 2.13.0
> >
>
>
amd64 EFI - kernel boots with obsolete memory map
Hi,
efi_cleanup() invokes ExitBootServices, which changes the memory map on some
EFI machines.
Since mem_pass() is called prior to efi_cleanup(), the kernel boots with an
obsolete memory map.
The problem can be fixed by calling mem_pass() after efi_cleanup().
Here's the report history with more detailed information:
https://marc.info/?l=openbsd-bugs&m=148253785924157&w=2
https://marc.info/?l=openbsd-tech&m=148653092621349&w=2
https://marc.info/?l=openbsd-bugs&m=151887483824518&w=2
This patch should correct the problem. I've been using it since 6.0 on several
machines (BIOS and EFI) without any issues.
Index: src/sys/arch/amd64/stand/libsa/exec_i386.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/exec_i386.c,v
retrieving revision 1.22
diff -u -p -u -r1.22 exec_i386.c
--- src/sys/arch/amd64/stand/libsa/exec_i386.c 18 Apr 2018 16:34:42 -
1.22
+++ src/sys/arch/amd64/stand/libsa/exec_i386.c 21 Apr 2018 05:57:48 -
@@ -78,7 +78,7 @@ run_loadfile(u_long *marks, int howto)
bios_bootsr_t bootsr;
struct sr_boot_volume *bv;
#endif
-#if defined(EFIBOOT)
+#ifdef EFIBOOT
int i;
u_long delta;
extern u_long efi_loadaddr;
@@ -86,6 +86,7 @@ run_loadfile(u_long *marks, int howto)
if ((av = alloc(ac)) == NULL)
panic("alloc for bootarg");
efi_makebootargs();
+ delta = DEFAULT_KERNEL_ADDRESS - efi_loadaddr;
#endif
if (sa_cleanup != NULL)
(*sa_cleanup)();
@@ -124,6 +125,17 @@ run_loadfile(u_long *marks, int howto)
sr_clear_keys();
#endif
+ entry = marks[MARK_ENTRY] & 0x0fff;
+#ifdef EFIBOOT
+ entry += delta;
+#endif
+
+ printf("entry point at 0x%lx\n", entry);
+
+#ifdef EFIBOOT
+ /* Sync the memory map and call ExitBootServices() */
+ efi_cleanup();
+#endif
/* Pass memory map to the kernel */
mem_pass();
@@ -137,33 +149,24 @@ run_loadfile(u_long *marks, int howto)
makebootargs(av, &ac);
#endif
- entry = marks[MARK_ENTRY] & 0x0fff;
-
- printf("entry point at 0x%lx\n", entry);
-
-#ifndef EFIBOOT
- /* stack and the gung is ok at this point, so, no need for asm setup */
- (*(startfuncp)entry)(howto, bootdev, BOOTARG_APIVER, marks[MARK_END],
- extmem, cnvmem, ac, (int)av);
-#else
+#ifdef EFIBOOT
/*
* Move the loaded kernel image to the usual place after calling
* ExitBootServices().
*/
- delta = DEFAULT_KERNEL_ADDRESS - efi_loadaddr;
- efi_cleanup();
memcpy((void *)marks[MARK_START] + delta, (void *)marks[MARK_START],
marks[MARK_END] - marks[MARK_START]);
for (i = 0; i < MARK_MAX; i++)
marks[i] += delta;
- entry += delta;
+#endif
+
#ifdef __amd64__
(*run_i386)((u_long)run_i386, entry, howto, bootdev, BOOTARG_APIVER,
marks[MARK_END], extmem, cnvmem, ac, (intptr_t)av);
#else
+ /* stack and the gung is ok at this point, so, no need for asm setup */
(*(startfuncp)entry)(howto, bootdev, BOOTARG_APIVER, marks[MARK_END],
extmem, cnvmem, ac, (int)av);
-#endif
#endif
/* not reached */
}
