Re: Sndio with >16 audio channels
On Sun, Jul 28, 2019 at 11:52:52AM +0200, Alexandre Ratchov wrote: > On Sat, Jul 27, 2019 at 08:47:58PM -0600, Samuel Larkin wrote: > > I verified that cranking the max number of channels can't cause > regressions and just committed the change. I tested the changes and it is working. I wasn't able to test channels 9:17 as they are the ADAT channels on the interface and I don't have any hardware with an ADAT out. The other channels are working for both recording and playback. If I end up comming across something with ADAT out I will test the higher channels
Re: filt_bpfrdetach uvm_fault after vmd vm was shutdown
On Wed, Jul 31, 2019 at 08:22:55PM +0200, Alexandr Nedvedicky wrote: > Looks like it can be related to my commit from May: > > > https://github.com/openbsd/src/commit/b50d0c1cf040666aed872208cd6f6ba609197b11#diff-7922ad1d2f6422aa72d4bacd1bf41909 > > I'll try to take a look. The steps to reproduce would be handy. > > as the first aid I would give a try to apply a reverse patch > to commit above. The reverse patch is below. Wait, the cause is not understood yet. It looks that the crash happened because of a NULL pointer dereference in the loop in SLIST_REMOVE(), the element kn was not on the list, or the memory was corrupted. The system should detach event filters before the object is destroyed. That should not need reference counting on the level of the object.
Re: umount usb drive after using openrsync
On Wed, Jul 31, 2019 at 10:12:02AM -0500, myportslist20190...@nym.hush.com wrote: > Synopsis: umount says device busy after having used openrsync I have seen this behavior in combination with unveil(2) and chroot(2). Could you test if the same diff helps for your problem? bluhm Index: kern/kern_unveil.c === RCS file: /data/mirror/openbsd/cvs/src/sys/kern/kern_unveil.c,v retrieving revision 1.29 diff -u -p -r1.29 kern_unveil.c --- kern/kern_unveil.c 29 Jul 2019 23:14:06 - 1.29 +++ kern/kern_unveil.c 30 Jul 2019 12:18:52 - @@ -309,8 +309,7 @@ unveil_find_cover(struct vnode *dp, stru break; } - if (parent != vp) - vrele(vp); + vrele(vp); (void) unveil_lookup(parent, p, ); vput(parent);
Re: filt_bpfrdetach uvm_fault after vmd vm was shutdown
Looks like it can be related to my commit from May:
https://github.com/openbsd/src/commit/b50d0c1cf040666aed872208cd6f6ba609197b11#diff-7922ad1d2f6422aa72d4bacd1bf41909
I'll try to take a look. The steps to reproduce would be handy.
as the first aid I would give a try to apply a reverse patch
to commit above. The reverse patch is below.
hope it helps
regards
sashan
8<---8<---8<---8<---8<8<
diff --git b/sys/net/bpf.c a/sys/net/bpf.c
index 5f2a20d593e..6d9554ec502 100644
--- b/sys/net/bpf.c
+++ a/sys/net/bpf.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: bpf.c,v 1.175 2019/05/18 12:59:32 sashan Exp $*/
+/* $OpenBSD: bpf.c,v 1.174 2019/04/25 18:24:39 anton Exp $ */
/* $NetBSD: bpf.c,v 1.33 1997/02/21 23:59:35 thorpej Exp $ */
/*
@@ -126,6 +126,13 @@ void bpf_resetd(struct bpf_d *);
void bpf_prog_smr(void *);
void bpf_d_smr(void *);
+/*
+ * Reference count access to descriptor buffers
+ */
+void bpf_get(struct bpf_d *);
+void bpf_put(struct bpf_d *);
+
+
struct rwlock bpf_sysctl_lk = RWLOCK_INITIALIZER("bpfsz");
int
@@ -320,11 +327,13 @@ bpf_detachd(struct bpf_d *d)
d->bd_promisc = 0;
+ bpf_get(d);
mtx_leave(>bd_mtx);
NET_LOCK();
error = ifpromisc(bp->bif_ifp, 0);
NET_UNLOCK();
mtx_enter(>bd_mtx);
+ bpf_put(d);
if (error && !(error == EINVAL || error == ENODEV ||
error == ENXIO))
@@ -373,6 +382,7 @@ bpfopen(dev_t dev, int flag, int mode, struct proc *p)
if (flag & FNONBLOCK)
bd->bd_rtout = -1;
+ bpf_get(bd);
LIST_INSERT_HEAD(_d_list, bd, bd_list);
return (0);
@@ -393,13 +403,7 @@ bpfclose(dev_t dev, int flag, int mode, struct proc *p)
bpf_wakeup(d);
LIST_REMOVE(d, bd_list);
mtx_leave(>bd_mtx);
-
- /*
-* Wait for the task to finish here, before proceeding to garbage
-* collection.
-*/
- taskq_barrier(systq);
- smr_call(>bd_smr, bpf_d_smr, d);
+ bpf_put(d);
return (0);
}
@@ -433,6 +437,7 @@ bpfread(dev_t dev, struct uio *uio, int ioflag)
if (d->bd_bif == NULL)
return (ENXIO);
+ bpf_get(d);
mtx_enter(>bd_mtx);
/*
@@ -538,6 +543,7 @@ bpfread(dev_t dev, struct uio *uio, int ioflag)
d->bd_in_uiomove = 0;
out:
mtx_leave(>bd_mtx);
+ bpf_put(d);
return (error);
}
@@ -556,7 +562,9 @@ bpf_wakeup(struct bpf_d *d)
* by the KERNEL_LOCK() we have to delay the wakeup to
* another context to keep the hot path KERNEL_LOCK()-free.
*/
- task_add(systq, >bd_wake_task);
+ bpf_get(d);
+ if (!task_add(systq, >bd_wake_task))
+ bpf_put(d);
}
void
@@ -571,6 +579,7 @@ bpf_wakeup_cb(void *xd)
csignal(d->bd_pgid, d->bd_sig, d->bd_siguid, d->bd_sigeuid);
selwakeup(>bd_sel);
+ bpf_put(d);
}
int
@@ -588,6 +597,7 @@ bpfwrite(dev_t dev, struct uio *uio, int ioflag)
if (d->bd_bif == NULL)
return (ENXIO);
+ bpf_get(d);
ifp = d->bd_bif->bif_ifp;
if (ifp == NULL || (ifp->if_flags & IFF_UP) == 0) {
@@ -621,6 +631,7 @@ bpfwrite(dev_t dev, struct uio *uio, int ioflag)
NET_UNLOCK();
out:
+ bpf_put(d);
return (error);
}
@@ -696,6 +707,8 @@ bpfioctl(dev_t dev, u_long cmd, caddr_t addr, int flag,
struct proc *p)
}
}
+ bpf_get(d);
+
switch (cmd) {
default:
error = EINVAL;
@@ -993,6 +1006,7 @@ bpfioctl(dev_t dev, u_long cmd, caddr_t addr, int flag,
struct proc *p)
break;
}
+ bpf_put(d);
return (error);
}
@@ -1180,6 +1194,7 @@ bpfkqfilter(dev_t dev, struct knote *kn)
return (EINVAL);
}
+ bpf_get(d);
kn->kn_hook = d;
SLIST_INSERT_HEAD(klist, kn, kn_selnext);
@@ -1199,6 +1214,7 @@ filt_bpfrdetach(struct knote *kn)
KERNEL_ASSERT_LOCKED();
SLIST_REMOVE(>bd_sel.si_note, kn, knote, kn_selnext);
+ bpf_put(d);
}
int
@@ -1591,6 +1607,25 @@ bpf_d_smr(void *smr)
free(bd, M_DEVBUF, sizeof(*bd));
}
+void
+bpf_get(struct bpf_d *bd)
+{
+ atomic_inc_int(>bd_ref);
+}
+
+/*
+ * Free buffers currently in use by a descriptor
+ * when the reference count drops to zero.
+ */
+void
+bpf_put(struct bpf_d *bd)
+{
+ if (atomic_dec_int_nv(>bd_ref) > 0)
+ return;
+
+ smr_call(>bd_smr, bpf_d_smr, bd);
+}
+
void *
bpfsattach(caddr_t *bpfp, const char *name, u_int dlt, u_int hdrlen)
{
diff --git b/sys/net/bpfdesc.h a/sys/net/bpfdesc.h
index 130b91c1d9f..de8f6f3e440 100644
--- b/sys/net/bpfdesc.h
+++ a/sys/net/bpfdesc.h
@@ -1,4 +1,4 @@
-/* $OpenBSD: bpfdesc.h,v 1.38 2019/05/18 12:59:32 sashan Exp $ */
+/* $OpenBSD:
filt_bpfrdetach uvm_fault after vmd vm was shutdown
July 29 amd64 snap. I had just tested something in a vm (not very
common for me) and did "halt -p" in the guest. Immediately afterwards
I hit this:
uvm_fault(0xfd84031d4ef0, 0x8, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at filt_bpfrdetach+0x43: movq0x8(%rax),%rax
>From ps /o it seems lldpd was involved - this would be using bpfs.
was running at startup. The bridge was created and vmd was started later after
boot (while lldpd was already running, if that matters).
If a step-by-step reproducer or more details are needed I'll try to figure
something out when I'm on a machine that is less annoying to fsck.
vm.conf like this,
: switch "uplink" {
: interface bridge0
: }
:
: vm "open" {
: disable
: owner sthen
: memory 1G
: interface { switch "uplink" }
: disk "/data/vmm/open.img"
: }
and lldpd just running with defaults (pkg_add lldpd, rcctl enable lldpd)
[...]
Guest EPTP = 0x50c8201e
vmm_alloc_vpid: allocated VPID/ASID 1
vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported
vmx_handle_cr: mov to cr0 @ 100149e, data=0x80010031
vmx_handle_wrmsr: wrmsr exit, msr=0x277, discarding data written from
guest=0x70106:0x70106
vmm_handle_cpuid: unsupported rax=0x4100
vmx_handle_wrmsr: wrmsr exit, msr=0x8b, discarding data written from
guest=0x0:0x0
vmx_handle_rdmsr: rdmsr exit, msr=0x8b, data returned to guest=0x0:0x0
vmx_handle_rdmsr: rdmsr exit, msr=0x17, data returned to guest=0x0:0x0
vmm_handle_cpuid: function 0x06 (thermal/power mgt) not supported
vmm_handle_cpuid: invalid cpuid input leaf 0x15, guest rip=0x816d3021 -
resetting to 0xd
vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported
vmm_free_vpid: freed VPID/ASID 1
uvm_fault(0xfd84031d4ef0, 0x8, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at filt_bpfrdetach+0x43: movq0x8(%rax),%rax
ddb{2}> tr
filt_bpfrdetach(fd8053d82028) at filt_bpfrdetach+0x43
knote_fdclose(8000332231c0,a) at knote_fdclose+0x71
fdrelease(8000332231c0,a) at fdrelease+0x88
syscall(800033308d90) at syscall+0x389
Xsyscall(0,6,11651b1f0400,6,11653c5c3140,1164c835f640) at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7e8f20, count: -5
ddb{2}> ps /o
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
241085 82884 55 0x3 03 c++
*299783 859427200x10 02K lldpd
207781 34043 0 0x14000 0x2001 softnet
ddb{2}> sh reg
rdi 0xfd8053d82028
rsi 0xa
rbp 0x800033308bf0
rbx 0xa
rdx 0x5ebff6ec
rcx 0x2
rax0
r80x812e3a50uvm_map_inentry_pc
r9 0x16
r100
r11 0x5849881d09945a01
r12 0xfd8053d82028
r13 0xfd83a0bfee38
r14 0xfd8053d82028
r150
rip 0x818b9d13filt_bpfrdetach+0x43
cs 0x8
rflags 0x10217__ALIGN_SIZE+0xf217
rsp 0x800033308bc0
ss 0x10
filt_bpfrdetach+0x43: movq0x8(%rax),%rax
ddb{2}> sh witness
No such command
ddb{2}> mach ddbcpu 1
Stopped at x86_ipi_db+0x12:leave
ddb{1}> tr
x86_ipi_db(800022009ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi(9,800022009ff0,800022290278,0,0,800022290350) at X
resume_lapic_ipi+0x23
_kernel_lock() at _kernel_lock+0xa9
timeout_del_barrier(800022290350) at timeout_del_barrier+0xa2
msleep(80028040,80028060,20,81ad080d,0) at msleep+0xf5
taskq_next_work(80028040,8000222b6fe0) at taskq_next_work+0x38
taskq_thread(80028040) at taskq_thread+0x6f
end trace frame: 0x0, count: -8
ddb{1}> sh reg
rdi 0x800022009ff0
rsi0
rbp 0x8000222b6d60
rbx 0x81d18768ipifunc+0x38
rdx0
rcx 0x7
rax 0xff7f
r8 0
r9 0
r100
r11 0x8e93433a56188026
r12 0x7
r130
r14 0x800022009ff0
r150
rip 0x81669b42x86_ipi_db+0x12
cs 0x8
rflags 0x282
rsp 0x8000222b6d50
ss 0x10
x86_ipi_db+0x12:leave
ddb{1}> bo r
rebooting...
OpenBSD 6.5-current (GENERIC.MP) #156: Mon Jul 29 12:00:48 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real
umount usb drive after using openrsync
Synopsis: umount says device busy after having used openrsync Category: user Environment: System : OpenBSD 6.5 Details : OpenBSD 6.5-current (GENERIC.MP) #158: Tue Jul 30 15:25:51 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: After using openrsync to sync files from a mounted USB drive to a local directory, I then always see a device busy error when trying to unmount the USB drive. This has been happening on several machines on amd64 for the last few snapshots (maybe a month or so.) Sometimes fuser will show nothing; other times it shows lots of processes including 1, so a reboot is necessary in order to unmount. This happens for me with any USB drive I try and from three different OpenBSD machines with different hardware running snapshots. I've checked ps, fstat -v, fuser, pstat -s, looked for symbolic links, exited all programs and terminals, logged and and back in, but only a reboot helps. I'm running cwm and haven't tried when booting to console instead of enabling xenodm. I'm definitely not in /mnt from any terminal when trying to umount. /sbin/umount -f does work. I haven't had this problem on 6.5-release. How-To-Repeat: mount a USB drive, use openrsync to sync files to a local directory, then try to unmount the USB drive. I'm including a script below. It shows that unmounting works before running openrsync, but fails after syncing. (The syncing itself is great though -- I thank everyone who worked on it and of course all of OpenBSD!!!) Script started on Wed Jul 31 09:25:35 2019 root@joe$ /sbin/mount /dev/sd3a on / type ffs (local) /dev/sd3d on /tmp type ffs (local, nodev, nosuid) /dev/sd3f on /usr type ffs (local, nodev) /dev/sd3g on /usr/X11R6 type ffs (local, nodev) /dev/sd3h on /usr/local type ffs (local, nodev, wxallowed) /dev/sd3k on /usr/obj type ffs (local, nodev, nosuid) /dev/sd3j on /usr/src type ffs (local, nodev, nosuid) /dev/sd3e on /var type ffs (local, nodev, nosuid) /dev/sd3l on /home type ffs (local, nodev, nosuid) /dev/sd4a on /mnt type ffs (local) root@joe$ /sbin/umount /mnt root@joe$ /sbin/mount /dev/sd4a /mnt root@joe$ /bin/ls /mnt root@joe$ /sbin/umount /mnt root@joe$ /sbin/mount /dev/sd4a /mnt root@joe$ /usr/bin/touch /mnt/a /mnt/b /mnt/c root@joe$ /bin/mkdir /tmp/testbak root@joe$ cd /mnt root@joe$ /usr/bin/openrsync --rsync-path=/usr/bin/openrsync -vvv -r -t. /tmp/testbak/ /usr/src/usr.bin/rsync/main.c:466: exec[0] = /usr/bin/openrsync /usr/src/usr.bin/rsync/main.c:466: exec[1] = --server /usr/src/usr.bin/rsync/main.c:466: exec[2] = -r /usr/src/usr.bin/rsync/main.c:466: exec[3] = -t /usr/src/usr.bin/rsync/main.c:466: exec[4] = -v /usr/src/usr.bin/rsync/main.c:466: exec[5] = -v /usr/src/usr.bin/rsync/main.c:466: exec[6] = -v /usr/src/usr.bin/rsync/main.c:466: exec[7] = . /usr/src/usr.bin/rsync/main.c:466: exec[8] = /tmp/testbak/ /usr/src/usr.bin/rsync/client.c:71: client detected client version 27, server version 27, seed -2038779841 /usr/src/usr.bin/rsync/server.c:99: server detected client version 27, server version 27, seed -2038779841 /usr/src/usr.bin/rsync/client.c:82: client starting sender: (local) /usr/src/usr.bin/rsync/server.c:128: server starting receiver /usr/src/usr.bin/rsync/flist.c:1002: generated 4 filenames: . /usr/src/usr.bin/rsync/flist.c:1028: recursively generated 4 filenames /usr/src/usr.bin/rsync/flist.c:268: sending file metadata list: 4 /usr/src/usr.bin/rsync/flist.c:305: .: sending file metadata: size 512, mtime 1564583177, mode 40755 /usr/src/usr.bin/rsync/flist.c:305: ./a: sending file metadata: size 0, mtime 1564583177, mode 100644 /usr/src/usr.bin/rsync/flist.c:305: ./b: sending file metadata: size 0, mtime 1564583177, mode 100644 /usr/src/usr.bin/rsync/flist.c:305: ./c: sending file metadata: size 0, mtime 1564583177, mode 100644 /usr/src/usr.bin/rsync/flist.c:739: .: received file metadata: size 512, mtime 1564583177, mode 40755, rdev (0, 0) Transfer starting: 4 files /usr/src/usr.bin/rsync/flist.c:739: ./a: received file metadata: size 0, mtime 1564583177, mode 100644, rdev (0, 0) /usr/src/usr.bin/rsync/flist.c:739: ./b: received file metadata: size 0, mtime 1564583177, mode 100644, rdev (0, 0) /usr/src/usr.bin/rsync/flist.c:739: ./c: received file metadata: size 0, mtime 1564583177, mode 100644, rdev (0, 0) /usr/src/usr.bin/rsync/flist.c:765: received file metadata list: 4 /usr/src/usr.bin/rsync/receiver.c:233: /tmp/testbak/: receiver destination /usr/src/usr.bin/rsync/receiver.c:329: /tmp/testbak/: ready for phase 1 data /usr/src/usr.bin/rsync/uploader.c:544: .: updating directory /usr/src/usr.bin/rsync/uploader.c:952: ./a: not mapped /usr/src/usr.bin/rsync/uploader.c:952: ./b: not mapped /usr/src/usr.bin/rsync/uploader.c:952: ./c: not mapped /usr/src/usr.bin/rsync/blocks.c:392: ./a: read block prologue: 0 blocks of 32768 B,
Re: USB mouse not working in 6.5 - "uhidev1: no report descriptor"
It turns out this is not as consistently reproducible as I thought. The issue happened for at least three consecutive reboots (including one complete power-off) before I sent this bug, but when I later went to test if unplugging/reconnecting the USB device after boot made any difference, I discovered it had actually initialized correctly on that boot, and it has worked properly ever since then, including after the latest syspatch. So... no idea what's going on, but without being reproducible, it's hard to debug this any further, and at least it's working now! On Thu, May 2, 2019 at 4:12 PM wrote: > > >Synopsis: KVM switch USB mouse not working after 6.5 upgrade - > >"uhidev1: no report descriptor" > >Category: kernel > >Environment: > System : OpenBSD 6.5 > Details : OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT > 2019 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > The server is connected to a KVM switch, which has a single USB > connection for both keyboard and mouse. Both devices previously worked (in > 6.4 and earlier), but now only the keyboard works. > > Not sure if relevant, but this machine has *only* USB 3.0 ports, no > USB > 2.0 at all, so the keyboard and mouse are connected to an xhci port. > > In 6.4, the keyboard and mouse were detected like this: > uhidev0 at uhub0 port 2 configuration 1 interface 0 "Avocent APC AP5631" rev > 1.10/1.00 addr 2 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes, country code 33 > wskbd0 at ukbd0 mux 1 > wskbd0: connecting to wsdisplay0 > uhidev1 at uhub0 port 2 configuration 1 interface 1 "Avocent APC AP5631" rev > 1.10/1.00 addr 2 > uhidev1: iclass 3/1, 3 report ids > ums0 at uhidev1 reportid 1: 5 buttons, Z dir > wsmouse0 at ums0 mux 0 > uhid0 at uhidev1 reportid 2: input=2, output=0, feature=0 > uhid1 at uhidev1 reportid 3: input=1, output=0, feature=0 > > >How-To-Repeat: > Connect a (composite?) device like this to a system running 6.5: > addr 02: 0624:0706 Avocent, APC AP5631 > low speed, power 100 mA, config 1, rev 1.00 > driver: uhidev0 > driver: uhidev1 > >Fix: > Unknown. A "normal" USB mouse connected directly to the machine does > work. > > > dmesg: [snip] > uhidev0 at uhub0 port 2 configuration 1 interface 0 "Avocent APC AP5631" rev > 1.10/1.00 addr 2 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes, country code 33 > wskbd0 at ukbd0 mux 1 > wskbd0: connecting to wsdisplay0 > uhidev1 at uhub0 port 2 configuration 1 interface 1 "Avocent APC AP5631" rev > 1.10/1.00 addr 2 > uhidev1: no report descriptor > usbdevs: > Controller /dev/usb0: > addr 01: 8086: Intel, xHCI root hub > super speed, self powered, config 1, rev 1.00 > driver: uhub0 > addr 02: 0624:0706 Avocent, APC AP5631 > low speed, power 100 mA, config 1, rev 1.00 > driver: uhidev0 > driver: uhidev1 > addr 03: 413c:a001 no manufacturer, Gadget USB HUB > high speed, self powered, config 1, rev 0.00, iSerial 0123456789 > driver: uhub1
