size: improve column alignment
size(1) output is not padded and uses a single tab between each column
which often looks ugly:
$ size bsd /usr/lib/libc.so.96.4 `which echo cc`
textdatabss dec hex
896234 31208 54664 982106 efc5a /usr/lib/libc.so.96.4
106152 11200 12640 129992 1fbc8 /bin/echo
8439822141416 343049 8478268650dae5e /usr/bin/cc
The GNU implementation looks less off:
# pkg_add binutils
binutils-2.39: ok
$ gsize bsd /usr/lib/libc.so.96.4 `which echo cc`
textdata bss dec hex filename
896234 31208 54664 982106 efc5a /usr/lib/libc.so.96.4
106152 11200 12640 129992 1fbc8 /bin/echo
84398221 41416 343049 8478268650dae5e /usr/bin/cc
I haven't checked their code, but padding fields to seven chars and
delimiting with a tab yields their format (modulo "filename" printing):
$ obj/size bsd /usr/lib/libc.so.96.4 `which echo cc`
textdata bss dec hex
896234 31208 54664 982106 efc5a /usr/lib/libc.so.96.4
106152 11200 12640 129992 1fbc8 /bin/echo
84398221 41416 343049 8478268650dae5e /usr/bin/cc
Big files are still off, but at least fields are now aligned.
Another alternative could be to pad fields to eight chars and delimit
with a space, causing both small and big files to align nicely whilst
staying under 80 chars total width with reasonable file names
(which I left delimited with a tab... coulde be space for consistency):
$ grep %8 nm.c
printf("%8s %8s %8s %8s %8s\n",
printf("%8lu %8lu %8lu %8lu %8lx",
$ obj/size bsd /usr/lib/libc.so.96.4 `which echo cc`
text data bss dec hex
8962343120854664 982106efc5a/usr/lib/libc.so.96.4
1061521120012640 1299921fbc8/bin/echo
8439822141416 343049 84782686 50dae5e/usr/bin/cc
What do others think?
Diff below switches to the GNU format, keeping tabs in outputs.
One possible concern is scripts parsing size(1) output with anything but
awk(1), but at least base does not seem to contain Makefiles that depend
on the exact current format.
Index: nm.c
===
RCS file: /cvs/src/usr.bin/nm/nm.c,v
retrieving revision 1.54
diff -u -p -r1.54 nm.c
--- nm.c3 Mar 2019 16:07:39 - 1.54
+++ nm.c30 Oct 2022 20:54:05 -
@@ -682,11 +682,12 @@ show_file(int count, int warn_fmt, const
if (first) {
first = 0;
- printf("text\tdata\tbss\tdec\thex\n");
+ printf("%7s\t%7s\t%7s\t%7s\t%7s\n",
+ "text", "data", "bss", "dec", "hex");
}
total = text + data + bss;
- printf("%lu\t%lu\t%lu\t%lu\t%lx",
+ printf("%7lu\t%7lu\t%7lu\t%7lu\t%7lx",
text, data, bss, total, total);
if (count > 1)
(void)printf("\t%s", name);
mbufs growing in 7.2
My router has become unstable since upgrading from 7.1-stable to 7.2. After several days of uptime the machine gets into a state where some applications (unbound & dhcpd) report ENOBUFS (No buffer space available). At that time the machine is pingable over all the interfaces, but only the upstream interface seems functional (igc0). The networks downstream of the router can't get much data across. I don't have a good characterization of this. At first I suspected this had something to do with the igc checksum offloading commit, so I am now running 7.2 with this reverted: "Implement and enable IPv4, TCP, and UDP checksum offloading for igc." I also started monitoring some counters that appeared relevant with this trivial loop: $ while : ; do date; netstat -s | grep err; netstat -m; netstat -ni | grep '^[Ni]'; sleep 300; done | tee err-log I have some 38 hours worth of counters as of now. I observe an upward trend in "mbuf 2112" and "mbufs in use", I extracted the values with $ perl -ne 'print "$x,$1\n" if m/^(\d+).*mbuf 2112/; $x=$1 if /^(\d+)\smbufs in use/;' err-log It starts out 610,410-ish and ends at 717,513. I have a picture for those visually inclined: https://photos.app.goo.gl/DZGCrJnJDohPrVyZ8 I have dmesg at the end and I shared the hostname files with mbuhl@. There's nothing special there AFAICT. The pf ruleset is also a pretty trivial NAT setup with DNS rdr-to to local unbound. I'll keep monitoring these numbers and am happy to share the full file with people who care to look at raw data. If there's more data to collect, please suggest what it is. If the symptoms happen again I may have to go back to 7.1 to avoid my family revolting. This will give me a baseline of the same measurements if nothing else. Thanks Greg OpenBSD 7.2 (GENERIC.MP) #0: Fri Oct 28 19:14:33 PDT 2022 greg@local:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4093276160 (3903MB) avail mem = 3951816704 (3768MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xeae90 (57 entries) bios0: vendor American Megatrends Inc. version "5.13" date 01/06/2022 bios0: Default string Default string acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG SSDT DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT SSDT SSDT SSDT SSDT TPM2 DMAR WDAT WSMT acpi0: wakeup devices SIO1(S3) HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) J4125 CPU @ 2.00GHz, 1994.48 MHz, 06-7a-08 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) J4125 CPU @ 2.00GHz, 1994.48 MHz, 06-7a-08 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) J4125 CPU @ 2.00GHz, 1994.48 MHz, 06-7a-08 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (appli
thethering on Mudita Pure
I wonder would it be possible to support Mudita Pure phone
(https://mudita.com/products/) Internet thethering.
After enabling USB thethering, the phone it identifies itself as
vendor 0x2c7c and product 0x0125, so Quectel EG25-G.
The umb driver fails to attach:
umb0 at uhub0 port 1 "Quectel EG25-G" rev 2.00/3.18 addr 2
umb0: switching to config #1
umb0: missing MBIM descriptor
Disabling umb makes umsm to match it, but not attach:
umsm0 at uhub0 port 1 configuration 1 interface 0 "Quectel EG25-G" rev
2.00/3.18 addr 2
umsm0: missing endpoint
umsm1 at uhub0 port 1 configuration 1 interface 2 "Quectel EG25-G" rev
2.00/3.18 addr 2
ucom0 at umsm1
umsm2 at uhub0 port 1 configuration 1 interface 3 "Quectel EG25-G" rev
2.00/3.18 addr 2
ucom1 at umsm2
umsm3 at uhub0 port 1 configuration 1 interface 4 "Quectel EG25-G" rev
2.00/3.18 addr 2
ucom2 at umsm3
umsm4 at uhub0 port 1 configuration 1 interface 5 "Quectel EG25-G" rev
2.00/3.18 addr 2
ucom3 at umsm4
The device is supported on macOS via a third party urndis driver.
On OpenBSD I was able to use it with this diff and after
disabling both umsm and umb in kernel config:
Index: dev/usb/if_urndis.c
===
RCS file: /cvs/src/sys/dev/usb/if_urndis.c,v
retrieving revision 1.73
diff -u -p -r1.73 if_urndis.c
--- dev/usb/if_urndis.c 5 Nov 2021 11:38:52 - 1.73
+++ dev/usb/if_urndis.c 26 Oct 2022 20:28:21 -
@@ -129,6 +129,7 @@ const struct urndis_class {
const char *typestr;
} urndis_class[] = {
{ UICLASS_CDC, UISUBCLASS_ABSTRACT_CONTROL_MODEL, 0xff, "Vendor" },
+ { UICLASS_CDC_DATA, UISUBCLASS_DATA, UIPROTO_DATA_VENDOR, "Vendor" },
{ UICLASS_WIRELESS, UISUBCLASS_RF, UIPROTO_RNDIS, "RNDIS" },
{ UICLASS_MISC, UISUBCLASS_SYNC, UIPROTO_ACTIVESYNC, "Activesync" }
};
fix libz regress on gcc archs
Makefile bits adapted from regress/lib/libssl/interop/botan/Makefile.
required for stderr
required for exit(3)
required for memcmp(3)
g++-8.4.0p12 on sparc64 prints coloured warnings/errors, but that is
enother issue.
On sparc64, `make CXX=clang++' without patch works as well.
A follow-up commit could skip only google chromium's unit tests as the only
C++ code, this way the other tests are always run.
Feedback? OK?
---
regress/lib/libz/Makefile | 15 +++
regress/lib/libz/utils_unittest.cc | 3 +++
2 files changed, 18 insertions(+)
diff --git a/regress/lib/libz/Makefile b/regress/lib/libz/Makefile
index 73e7871294d..ac760edd2af 100644
--- a/regress/lib/libz/Makefile
+++ b/regress/lib/libz/Makefile
@@ -6,6 +6,19 @@
# google chromium has special test for libz bugs
#
https://chromium.googlesource.com/chromium/src/third_party/+/refs/heads/main/zlib/contrib/tests/utils_unittest.cc
+.include
+
+.if (${COMPILER_VERSION:L} != "clang" && ! exists(/usr/local/bin/eg++))
+regress:
+ @echo 'Run "pkg_add g++" to run unittests on GCC architectures'
+ @echo SKIPPED
+.else
+
+.if ${COMPILER_VERSION:L} != "clang" && ${CXX} == "c++"
+# C++11
+CXX = /usr/local/bin/eg++
+.endif
+
PROGS= example infcover minigzip utils_unittest
SRCS_utils_unittest = utils_unittest.cc
LDADD= -lz
@@ -43,4 +56,6 @@ run-utils_unittest-${tst}: utils_unittest
.endfor
+.endif # (${COMPILER_VERSION:L} != "clang" && ! exists(/usr/local/bin/eg++))
+
.include
diff --git a/regress/lib/libz/utils_unittest.cc
b/regress/lib/libz/utils_unittest.cc
index edb6a91b960..0c1228ba5af 100644
--- a/regress/lib/libz/utils_unittest.cc
+++ b/regress/lib/libz/utils_unittest.cc
@@ -33,6 +33,9 @@
#include
#include
+#include
+#include
+#include
#include
#define TEST(a, b) void b(void)
--
2.38.1
Re: Towards unlocking mmap(2) & munmap(2)
On Fri, Oct 28, 2022 at 11:08:55AM +0200, Martin Pieuchot wrote: > On 20/10/22(Thu) 16:17, Martin Pieuchot wrote: > > On 11/09/22(Sun) 12:26, Martin Pieuchot wrote: > > > Diff below adds a minimalist set of assertions to ensure proper locks > > > are held in uvm_mapanon() and uvm_unmap_remove() which are the guts of > > > mmap(2) for anons and munmap(2). > > > > > > Please test it with WITNESS enabled and report back. > > > > New version of the diff that includes a lock/unlock dance in > > uvm_map_teardown(). While grabbing this lock should not be strictly > > necessary because no other reference to the map should exist when the > > reaper is holding it, it helps make progress with asserts. Grabbing > > the lock is easy and it can also save us a lot of time if there is any > > reference counting bugs (like we've discovered w/ vnode and swapping). > > Here's an updated version that adds a lock/unlock dance in > uvm_map_deallocate() to satisfy the assert in uvm_unmap_remove(). > Thanks to tb@ from pointing this out. > > I received many positive feedback and test reports, I'm now asking for > oks. In principal, this is what I did a few months back, with less asserts and less "Must be called with map [un]locked" comment additions for functions that gained assertions. I went through the tree to manually verify that each function you added an assert to is called with[out] the map lock held: this looks good. GENERIC.MP+uvm (your diff) with mmap(2) as and munmap(2) unlocked has been working fine on my daily x230 driver with browsing, compiling, etc. i386 kernels build fine using GENERIC.MP+uvm and i386 regress runs fine using GENERIC.MP+uvm+WITNESS. sparc64 kernels build fine using GENERIC.MP+uvm and sparc64 regress runs fine using GENERIC.MP+uvm (WITNESS doesn't boot). Please keep an eye on syzkaller after this gets committed. Last time I committed something like this syzcaller was broken. This was reported off-list. OK kn
Re: Towards unlocking mmap(2) & munmap(2)
On Sun, Oct 30, 2022 at 01:58:40PM +0100, Martin Pieuchot wrote: > On 30/10/22(Sun) 12:45, Klemens Nanni wrote: > > On Sun, Oct 30, 2022 at 12:40:02PM +, Klemens Nanni wrote: > > > regress on i386/GENERIC.MP+WITNESS with this diff shows > > > > Another one; This machine has three read-only NFS mounts, but none of > > them are used during builds or regress. > > It's the same. See archives of bugs@ for discussion about this lock > order reversal and a potential fix from visa@. Great, thanks!
Re: Towards unlocking mmap(2) & munmap(2)
On 30/10/22(Sun) 12:45, Klemens Nanni wrote: > On Sun, Oct 30, 2022 at 12:40:02PM +, Klemens Nanni wrote: > > regress on i386/GENERIC.MP+WITNESS with this diff shows > > Another one; This machine has three read-only NFS mounts, but none of > them are used during builds or regress. It's the same. See archives of bugs@ for discussion about this lock order reversal and a potential fix from visa@. > > This one is most certainly from the NFS regress tests themselves: > 127.0.0.1:/mnt/regress-nfs-server 3548 2088 1284 > 62%/mnt/regress-nfs-client > > witness: lock order reversal: > 1st 0xd6381eb8 vmmaplk (&map->lock) > 2nd 0xf5c98d24 nfsnode (&np->n_lock) > lock order data w2 -> w1 missing > lock order "&map->lock"(rwlock) -> "&np->n_lock"(rrwlock) first seen at: > #0 rw_enter+0x57 > #1 rrw_enter+0x3d > #2 nfs_lock+0x27 > #3 VOP_LOCK+0x50 > #4 vn_lock+0x91 > #5 vn_rdwr+0x64 > #6 vndstrategy+0x2bd > #7 physio+0x18f > #8 vndwrite+0x1a > #9 spec_write+0x74 > #10 VOP_WRITE+0x3f > #11 vn_write+0xde > #12 dofilewritev+0xbb > #13 sys_pwrite+0x55 > #14 syscall+0x2ec > #15 Xsyscall_untramp+0xa9 >
Re: Towards unlocking mmap(2) & munmap(2)
On 30/10/22(Sun) 12:40, Klemens Nanni wrote: > On Fri, Oct 28, 2022 at 11:08:55AM +0200, Martin Pieuchot wrote: > > On 20/10/22(Thu) 16:17, Martin Pieuchot wrote: > > > On 11/09/22(Sun) 12:26, Martin Pieuchot wrote: > > > > Diff below adds a minimalist set of assertions to ensure proper locks > > > > are held in uvm_mapanon() and uvm_unmap_remove() which are the guts of > > > > mmap(2) for anons and munmap(2). > > > > > > > > Please test it with WITNESS enabled and report back. > > > > > > New version of the diff that includes a lock/unlock dance in > > > uvm_map_teardown(). While grabbing this lock should not be strictly > > > necessary because no other reference to the map should exist when the > > > reaper is holding it, it helps make progress with asserts. Grabbing > > > the lock is easy and it can also save us a lot of time if there is any > > > reference counting bugs (like we've discovered w/ vnode and swapping). > > > > Here's an updated version that adds a lock/unlock dance in > > uvm_map_deallocate() to satisfy the assert in uvm_unmap_remove(). > > Thanks to tb@ from pointing this out. > > > > I received many positive feedback and test reports, I'm now asking for > > oks. > > regress on i386/GENERIC.MP+WITNESS with this diff shows This isn't related to this diff.
Re: Towards unlocking mmap(2) & munmap(2)
On Sun, Oct 30, 2022 at 12:40:02PM +, Klemens Nanni wrote: > regress on i386/GENERIC.MP+WITNESS with this diff shows Another one; This machine has three read-only NFS mounts, but none of them are used during builds or regress. This one is most certainly from the NFS regress tests themselves: 127.0.0.1:/mnt/regress-nfs-server 3548 2088 1284 62%/mnt/regress-nfs-client witness: lock order reversal: 1st 0xd6381eb8 vmmaplk (&map->lock) 2nd 0xf5c98d24 nfsnode (&np->n_lock) lock order data w2 -> w1 missing lock order "&map->lock"(rwlock) -> "&np->n_lock"(rrwlock) first seen at: #0 rw_enter+0x57 #1 rrw_enter+0x3d #2 nfs_lock+0x27 #3 VOP_LOCK+0x50 #4 vn_lock+0x91 #5 vn_rdwr+0x64 #6 vndstrategy+0x2bd #7 physio+0x18f #8 vndwrite+0x1a #9 spec_write+0x74 #10 VOP_WRITE+0x3f #11 vn_write+0xde #12 dofilewritev+0xbb #13 sys_pwrite+0x55 #14 syscall+0x2ec #15 Xsyscall_untramp+0xa9
Re: Towards unlocking mmap(2) & munmap(2)
On Fri, Oct 28, 2022 at 11:08:55AM +0200, Martin Pieuchot wrote: > On 20/10/22(Thu) 16:17, Martin Pieuchot wrote: > > On 11/09/22(Sun) 12:26, Martin Pieuchot wrote: > > > Diff below adds a minimalist set of assertions to ensure proper locks > > > are held in uvm_mapanon() and uvm_unmap_remove() which are the guts of > > > mmap(2) for anons and munmap(2). > > > > > > Please test it with WITNESS enabled and report back. > > > > New version of the diff that includes a lock/unlock dance in > > uvm_map_teardown(). While grabbing this lock should not be strictly > > necessary because no other reference to the map should exist when the > > reaper is holding it, it helps make progress with asserts. Grabbing > > the lock is easy and it can also save us a lot of time if there is any > > reference counting bugs (like we've discovered w/ vnode and swapping). > > Here's an updated version that adds a lock/unlock dance in > uvm_map_deallocate() to satisfy the assert in uvm_unmap_remove(). > Thanks to tb@ from pointing this out. > > I received many positive feedback and test reports, I'm now asking for > oks. regress on i386/GENERIC.MP+WITNESS with this diff shows witness: lock order reversal: 1st 0xd6381aa8 vmmaplk (&map->lock) 2nd 0xd76a9790 inode (&ip->i_lock) lock order "&ip->i_lock"(rrwlock) -> "&map->lock"(rwlock) first seen at: #0 rw_enter_read+0x32 #1 vm_map_lock_read_ln+0x15 #2 uvmfault_lookup+0x60 #3 uvm_fault_check+0x14 #4 uvm_fault+0xe4 #5 kpageflttrap+0xe5 #6 trap+0x260 #7 calltrap+0xc #8 copyout+0x42 #9 uiomove+0x135 #10 ffs_read+0x27b #11 VOP_READ+0x3c #12 vn_rdwr+0x85 #13 vmcmd_map_readvn+0x7e #14 exec_process_vmcmds+0x5e #15 sys_execve+0x69e #16 start_init+0x241 #17 proc_trampoline+0x12 lock order "&map->lock"(rwlock) -> "&ip->i_lock"(rrwlock) first seen at: #0 rw_enter+0x57 #1 rrw_enter+0x3d #2 ufs_lock+0x27 #3 VOP_LOCK+0x50 #4 vn_lock+0x91 #5 vn_rdwr+0x64 #6 vndstrategy+0x2bd #7 physio+0x18f #8 vndwrite+0x1a #9 spec_write+0x74 #10 VOP_WRITE+0x3f #11 vn_write+0xde #12 dofilewritev+0xbb #13 sys_pwrite+0x55 #14 syscall+0x2ec #15 Xsyscall_untramp+0xa9
Re: Towards unlocking mmap(2) & munmap(2)
On Fri, Oct 28, 2022 at 11:08:55AM +0200, Martin Pieuchot wrote: > On 20/10/22(Thu) 16:17, Martin Pieuchot wrote: > > On 11/09/22(Sun) 12:26, Martin Pieuchot wrote: > > > Diff below adds a minimalist set of assertions to ensure proper locks > > > are held in uvm_mapanon() and uvm_unmap_remove() which are the guts of > > > mmap(2) for anons and munmap(2). > > > > > > Please test it with WITNESS enabled and report back. > > > > New version of the diff that includes a lock/unlock dance in > > uvm_map_teardown(). While grabbing this lock should not be strictly > > necessary because no other reference to the map should exist when the > > reaper is holding it, it helps make progress with asserts. Grabbing > > the lock is easy and it can also save us a lot of time if there is any > > reference counting bugs (like we've discovered w/ vnode and swapping). > > Here's an updated version that adds a lock/unlock dance in > uvm_map_deallocate() to satisfy the assert in uvm_unmap_remove(). > Thanks to tb@ from pointing this out. > > I received many positive feedback and test reports, I'm now asking for > oks. ok tb
Remove audio(9) speaker_ctl(), let open() handle speakers where needed
Only five legacy half-duplex hardware drivers require this function to
change between playing and recording:
i386: ess(4), gus(4), pas(4), sb(4)
luna88k: nec86(4)
If defined, it is always called early in audio_open(), so just move the
call from audio(4) to each hardware driver's open() handler.
SPKR_ON/OFF remain defined to leave driver-specific code unchanged.
Further cleanup (unchecked speaker_ctl() return values,
FWRITE -> AUMODE_PLAY -> SPKR_ON dances, etc.) can happen later.
i386/GENERIC.MP builds fine.
Feedback? Objection? OK?
---
share/man/man9/audio.9 | 10 --
sys/arch/luna88k/cbus/nec86.c | 1 -
sys/arch/luna88k/cbus/nec86hw.c | 2 ++
sys/dev/audio.c | 8
sys/dev/audio_if.h | 1 -
sys/dev/isa/ess.c | 4 ++--
sys/dev/isa/gus.c | 13 +++--
sys/dev/isa/gusvar.h| 1 -
sys/dev/isa/pas.c | 1 -
sys/dev/isa/sb.c| 1 -
sys/dev/isa/sbdsp.c | 2 ++
11 files changed, 9 insertions(+), 35 deletions(-)
diff --git a/share/man/man9/audio.9 b/share/man/man9/audio.9
index f03bd74c8b8..50cf1197fa9 100644
--- a/share/man/man9/audio.9
+++ b/share/man/man9/audio.9
@@ -60,10 +60,6 @@ struct audio_hw_if {
int (*halt_output)(void *);
int (*halt_input)(void *);
- int (*speaker_ctl)(void *, int);
-#define SPKR_ON 1
-#define SPKR_OFF 0
-
int (*set_port)(void *, struct mixer_ctrl *);
int (*get_port)(void *, struct mixer_ctrl *);
@@ -275,12 +271,6 @@ This function is called to abort the input transfer
(started by
.Fn start_input )
in progress.
This function returns 0 on success, otherwise an error code.
-.It Ft int Fn (*speaker_ctl) "void *hdl" "int on"
-This function is optional.
-If supplied, it is called when a half duplex device changes between
-playing and recording.
-It can, e.g., be used to turn the speaker on and off.
-This function returns 0 on success, otherwise an error code.
.It Ft int Fn (*set_port) "void *hdl" "struct mixer_ctrl *mc"
This function is called when the
.Dv AUDIO_MIXER_WRITE
diff --git a/sys/arch/luna88k/cbus/nec86.c b/sys/arch/luna88k/cbus/nec86.c
index 49e31c52d46..36d34fa50bf 100644
--- a/sys/arch/luna88k/cbus/nec86.c
+++ b/sys/arch/luna88k/cbus/nec86.c
@@ -79,7 +79,6 @@ const struct audio_hw_if nec86_hw_if = {
.start_input= nec86hw_pdma_input,
.halt_output= nec86hw_halt_pdma,
.halt_input = nec86hw_halt_pdma,
- .speaker_ctl= nec86hw_speaker_ctl,
.set_port = nec86hw_mixer_set_port,
.get_port = nec86hw_mixer_get_port,
.query_devinfo = nec86hw_mixer_query_devinfo,
diff --git a/sys/arch/luna88k/cbus/nec86hw.c b/sys/arch/luna88k/cbus/nec86hw.c
index 070c7f57344..7a4740f781c 100644
--- a/sys/arch/luna88k/cbus/nec86hw.c
+++ b/sys/arch/luna88k/cbus/nec86hw.c
@@ -176,6 +176,8 @@ nec86hw_open(void *arg, int flags)
if (sc->sc_open != 0 || nec86hw_reset(sc) != 0)
return ENXIO;
+ nec86hw_speaker_ctl(sc, (flags & FWRITE) ? SPKR_ON : SPKR_OFF);
+
sc->sc_open = 1;
sc->sc_intr = NULL;
sc->sc_arg = NULL;
diff --git a/sys/dev/audio.c b/sys/dev/audio.c
index d57a743460a..06ddb17de32 100644
--- a/sys/dev/audio.c
+++ b/sys/dev/audio.c
@@ -1492,14 +1492,6 @@ audio_open(struct audio_softc *sc, int flags)
if (flags & FREAD)
sc->mode |= AUMODE_RECORD;
- if (sc->ops->speaker_ctl) {
- /*
-* XXX: what is this used for?
-*/
- sc->ops->speaker_ctl(sc->arg,
- (sc->mode & AUMODE_PLAY) ? SPKR_ON : SPKR_OFF);
- }
-
error = audio_setpar(sc);
if (error)
goto bad;
diff --git a/sys/dev/audio_if.h b/sys/dev/audio_if.h
index 564139271bb..a3c1e6f307b 100644
--- a/sys/dev/audio_if.h
+++ b/sys/dev/audio_if.h
@@ -99,7 +99,6 @@ struct audio_hw_if {
int (*halt_output)(void *);
int (*halt_input)(void *);
- int (*speaker_ctl)(void *, int);
#define SPKR_ON1
#define SPKR_OFF 0
diff --git a/sys/dev/isa/ess.c b/sys/dev/isa/ess.c
index c195a1749d3..90c48be7d6a 100644
--- a/sys/dev/isa/ess.c
+++ b/sys/dev/isa/ess.c
@@ -204,7 +204,6 @@ const struct audio_hw_if ess_1788_hw_if = {
.round_blocksize = ess_round_blocksize,
.halt_output = ess_audio1_halt,
.halt_input = ess_audio1_halt,
- .speaker_ctl = ess_speaker_ctl,
.set_port = ess_set_port,
.get_port = ess_get_port,
.query_devinfo = ess_query_devinfo,
@@ -222,7 +221,6 @@ const struct audio_hw_if ess_1888_hw_if = {
.round_blocksize = ess_round_blocksize,
.halt_output = ess_audio2_halt,
.halt_input = ess_audio1_halt,
- .speaker_ctl = ess_speaker_ctl,
.set_port = ess_set_port,
.get_port = ess_get_port,
.query_devinf
