Memory corruption after fork, only on AMD CPUs
Hi all,
There appears to be a memory corruption bug that only happens on AMD
CPUs running NetBSD (or OpenBSD). The same code doesn't fail on Intel.
This affects Go and they've made some bug reports investigating it[1][2].
People have narrowed it down to this simple Go reproducer
(install lang/go117 to run it).
#!/bin/sh
cat << EOF > test.go
package main
import (
"os/exec"
)
func main() {
sem := make(chan struct{}, 100)
for {
sem <- struct{}{}
go func() {
err := exec.Command("/usr/bin/true").Run()
if err != nil {
panic(err)
}
<-sem
}()
}
}
EOF
go117 run test.go
After some time, I get crashes, example output:
http://coypu.sdf.org/go-stack-trace-AMD.log
http://coypu.sdf.org/go-stack-trace-AMD2.log
http://coypu.sdf.org/go-stack-trace-AMD3.log
Upstream Go has stated about one of the *OpenBSD* stack traces:
That looks very much like a forked child process is changing the
memory seen by the parent process. Which should of course be
impossible.
I suspect this is a missing AMD Ryzen errata or a UVM bug specific to
an AMD feature.
Does anyone have any suggestions for what may be the cause of this bug?
I can reproduce this bug, happy to test out prospective diffs.
My machine: Ryzen 3600, runs NetBSD 9.99.92.
Thanks.
[1] https://github.com/golang/go/issues/49209
[2] https://github.com/golang/go/issues/34988 (says OpenBSD,
same is true for NetBSD)
Re: [PATCH] Move DRM-driver firmware from base to its own set, gpufw
On Thu, Sep 23, 2021 at 02:43:23PM +, coypu wrote: > Might be an issue for not obsoleting directories on non-DRM archs. So it wasn't, they are created unconditionally, so I need this additional change: --- Squash - directories are created unconditionally. Put back in base/mi --- distrib/sets/lists/base/mi | 4 distrib/sets/lists/gpufw/mi | 3 --- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/distrib/sets/lists/base/mi b/distrib/sets/lists/base/mi index 167969606ea6..d409096cef1c 100644 --- a/distrib/sets/lists/base/mi +++ b/distrib/sets/lists/base/mi @@ -265,6 +265,9 @@ ./libdata/firmware/if_wpi/README.iwlwifi-3945-ucodebase-firmware-root firmware ./libdata/firmware/if_wpi/ipw3945.ucodebase-obsolete obsolete,firmware ./libdata/firmware/if_wpi/iwlwifi-3945.ucode base-firmware-root firmware +./libdata/firmware/nouveau base-firmware-usr +./libdata/firmware/nouveau/nvidia base-firmware-usr +./libdata/firmware/nouveau/nvidia/gm206 base-firmware-usr ./libdata/firmware/nvidia base-firmware-root ./libdata/firmware/nvidia/tegra124 base-firmware-root ./libdata/firmware/nvidia/tegra124/LICENCE.nvidia base-firmware-root tegrafirmware @@ -282,6 +285,7 @@ ./libdata/firmware/qat/qat_c62x_mmp.binbase-firmware-root firmware ./libdata/firmware/qat/qat_d15xx.bin base-firmware-root firmware ./libdata/firmware/qat/qat_d15xx_mmp.bin base-firmware-root firmware +./libdata/firmware/radeon base-firmware-usr ./libdata/firmware/ral base-firmware-root ./libdata/firmware/ral/ral-license base-firmware-root firmware ./libdata/firmware/ral/ral-rt2561 base-firmware-root firmware diff --git a/distrib/sets/lists/gpufw/mi b/distrib/sets/lists/gpufw/mi index 6d14ba5dae86..856eff5b7d45 100644 --- a/distrib/sets/lists/gpufw/mi +++ b/distrib/sets/lists/gpufw/mi @@ -3,15 +3,12 @@ # Note: don't delete entries from here - mark them as "obsolete" instead. # ./etc/mtree/set.gpufw base-gpufw -./libdata/firmware/nouveau base-gpufw -./libdata/firmware/nouveau/nvidia base-gpufw ./libdata/firmware/nouveau/nvidia/LICENCE.nvidiabase-gpufw gpufirmware ./libdata/firmware/nouveau/nvidia/gm206 base-gpufw ./libdata/firmware/nouveau/nvidia/gm206/fecs_data.bin base-gpufw gpufirmware ./libdata/firmware/nouveau/nvidia/gm206/fecs_inst.bin base-gpufw gpufirmware ./libdata/firmware/nouveau/nvidia/gm206/gpccs_data.bin base-gpufw gpufirmware ./libdata/firmware/nouveau/nvidia/gm206/gpccs_inst.bin base-gpufw gpufirmware -./libdata/firmware/radeon base-gpufw ./libdata/firmware/radeon/ARUBA_me.bin base-gpufw gpufirmware ./libdata/firmware/radeon/ARUBA_pfp.binbase-gpufw gpufirmware ./libdata/firmware/radeon/ARUBA_rlc.binbase-gpufw gpufirmware -- 2.28.0
[PATCH] Move DRM-driver firmware from base to its own set, gpufw
This set is only installed on amd64,i386,evbarm.
This set is installed on minimal installs and on install media, in
case someone needs it for basic driver functionality.
Comments:
Switched to a single MK tunable for it - that is probably unneeded.
Might be an issue for not obsoleting directories on non-DRM archs.
An upcoming DRM update will include even fatter firmware, and we'd
like to minimize the impact of it.
---
distrib/amd64/cdroms/Makefile.cdrom | 2 +-
distrib/common/bootimage/Makefile.bootimage | 6 +-
.../common/bootimage/Makefile.installimage| 3 +
distrib/i386/cdroms/Makefile.cdrom| 2 +-
distrib/notes/amd64/contents | 3 +
distrib/notes/evbarm/contents | 3 +
distrib/notes/i386/contents | 3 +
distrib/sets/README | 2 +
distrib/sets/lists/base/mi| 167 -
distrib/sets/lists/gpufw/mi | 328 ++
distrib/sets/maketars | 2 +-
distrib/sets/regpkgset| 2 +-
distrib/sets/sets.subr| 7 +-
distrib/utils/embedded/mkimage| 2 +-
etc/Makefile | 3 +
external/nvidia-firmware/Makefile | 2 +-
share/mk/bsd.README | 8 +-
share/mk/bsd.own.mk | 16 +-
sys/dev/microcode/radeon/Makefile | 2 +-
usr.sbin/sysinst/Makefile.inc | 4 +
usr.sbin/sysinst/arch/amd64/md.h | 2 +-
usr.sbin/sysinst/arch/evbarm/md.h | 2 +-
usr.sbin/sysinst/arch/i386/md.h | 2 +-
usr.sbin/sysinst/defs.h | 11 +-
usr.sbin/sysinst/msg.mi.de| 3 +
usr.sbin/sysinst/msg.mi.en| 3 +
usr.sbin/sysinst/msg.mi.es| 3 +
usr.sbin/sysinst/msg.mi.fr| 3 +
usr.sbin/sysinst/msg.mi.pl| 3 +
usr.sbin/sysinst/util.c | 3 +
30 files changed, 405 insertions(+), 197 deletions(-)
create mode 100644 distrib/sets/lists/gpufw/mi
diff --git a/distrib/amd64/cdroms/Makefile.cdrom
b/distrib/amd64/cdroms/Makefile.cdrom
index 5021aed04814..c8f6ec632250 100644
--- a/distrib/amd64/cdroms/Makefile.cdrom
+++ b/distrib/amd64/cdroms/Makefile.cdrom
@@ -17,7 +17,7 @@ CDMAKEFSOPTIONS=
bootimage=i386;bootxx.${MACHINE},no-emul-boot,allow-multidot,bo
CDINSTKERNEL= ../../instkernel
CDKERNELS= netbsd-GENERIC.gz netbsd
CDRELEASE_NOISOS= true
-CD_SETS= base etc
+CD_SETS= base etc gpufw
.if ${MKKMOD} != "no"
CD_SETS+= modules
.endif
diff --git a/distrib/common/bootimage/Makefile.bootimage
b/distrib/common/bootimage/Makefile.bootimage
index 8e4875cb0c7f..744ca216922e 100644
--- a/distrib/common/bootimage/Makefile.bootimage
+++ b/distrib/common/bootimage/Makefile.bootimage
@@ -71,8 +71,8 @@
# (default: kern-GENERIC)
# SETS
# binary sets that should be extracted into image
-# (default: modules base etc comp games man misc rescue tests
-#text xbase xcomp xetc xfont xserver)
+# (default: modules base etc comp games gpufw man misc
+#rescue tests text xbase xcomp xetc xfont xserver)
# SETS_DIR
# directory path where binary sets are stored
# (default: ${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/sets)
@@ -234,7 +234,7 @@ SWAPDISK_UUID=`${TOOL_GPT} ${GPT_TIMESSTAMP} ${WORKMBR}
show -i 3 | ${TOOL_AWK}
#
# definitions to create root fs
#
-SETS_DEFAULT= modules base etc comp games man misc rescue tests text
+SETS_DEFAULT= modules base etc comp games gpufw man misc rescue tests text
.if ${MKX11} != "no"
SETS_DEFAULT+= xbase xcomp xetc xfont xserver
.endif
diff --git a/distrib/common/bootimage/Makefile.installimage
b/distrib/common/bootimage/Makefile.installimage
index 32bd54dab6cc..5d275c83acc4 100644
--- a/distrib/common/bootimage/Makefile.installimage
+++ b/distrib/common/bootimage/Makefile.installimage
@@ -33,6 +33,9 @@ SWAPMB= 0 # no swap
KERN_SET?= kern-GENERIC
SETS?= modules base etc
+.if ${MKGPUFIRMWARE:Uno} != "no"
+SETS+= gpufw
+.endif
FSTAB_IN?= ${NETBSDSRCDIR}/distrib/common/bootimage/fstab.install.in
diff --git a/distrib/i386/cdroms/Makefile.cdrom
b/distrib/i386/cdroms/Makefile.cdrom
index bec0ea3b9341..4a01c8e2ea79 100644
--- a/distrib/i386/cdroms/Makefile.cdrom
+++ b/distrib/i386/cdroms/Makefile.cdrom
@@ -10,7 +10,7 @@ CDMAKEFSOPTIONS=
bootimage=i386;bootxx.${MACHINE},no-emul-boot,allow-multidot
CDINSTKERNEL= ../../instkernel
CDKERNELS= netbsd-GENERIC.gz netbsd
CDRELEASE_NOISOS= true
-CD_SETS= base etc
+CD_SETS= base etc gpufw
.if ${MKKMOD} != "no"
CD_SETS+= modules
.endif
diff
Re: [PATCH] Move DRM-driver firmware from base to its own set, gpufw
Hi David, On Thu, Sep 23, 2021 at 05:41:45PM +0100, David Brownlee wrote: > If gpu firmware is somewhat special, is there any sense in moving it > to /usr/libdata/firmware/gpu/... ? It's not particularly special, but only some platforms have DRM drivers and it is about to get fat with the addition of amdgpu firmware.
Re: Bounties for xhci features: scatter-gather, suspend/resume
On Thu, Mar 25, 2021 at 08:36:25PM +, co...@sdf.org wrote:
> Hi all,
>
> I'd like to offer bounties for the following.
> I am also utilizing the wiki to make it easy for others to add their own
> bounties: http://wiki.netbsd.org/projects/funded/
>
>
>
> xHCI resume support
>
> xhci is everywhere, and for many machines, it's the only remaining step
> for a flawless suspend/resume experiences.
> xhci_{suspend,resume} are unimplemented, and devices do not work after
> resume.
>
> (Contact nia in http://gnats.netbsd.org/56050 for actual hardware testing)
>
> I can offer a bounty of $200 for this.
> Offer valid until 1/July/2021.
Done with:
https://mail-index.netbsd.org/source-changes/2021/05/23/msg129705.html
Bounty for fixing PR 56086: Resume hangs when tpm(4) is enabled
Hi all, I'd normally not be offering bounties again for a while, but nia reported having the same problem that I spent weeks blindly debugging. "This one is personal". Story at bottom. I can offer $500 to a fix for PR 56086: "Resume hangs when tpm(4) is enabled" Hint: I suspect that the OpenBSD tpm driver does not have this problem. (Offer expires 1/January/2023) -- I have a Dell XPS 9550 and really wanted to fix suspend (after porting bwfm@pci for wifi, and updating drm for graphics!), but this laptop is cursed. And the specific curse is that it has a TPM and the tunable to disable it likely doesn't work. Things I've tried to blindly debug its resume issue: - Suspend/resume with many premutations of less drivers enabled, and BIOS settings. - Test every OS to see which ones suspend - Dig through the suspend code of all the ones that successfully suspended (Linux, OpenBSD) - Surgically transplant the OpenBSD resume trampoline into NetBSD (suspends on one machine, but not on the XPS) - Try to move the memory allocations because OpenBSD decided to shift them to workaround a BIOS bug - Read the ACPI docs, and any docs about resume security modes repeatedly. - Attempt to transplant the entire OpenBSD tpm driver into NetBSD - Get excited when I hear there are custom USB devices for debugging laptops, but fail to find ones that are expected to work for my laptop. - Ask anyone I possibly can for a lead to follow. And gradually becoming convinced that my laptop is stuck in some TPM pre-resume check failing. It's hard to tell how common this problem is. But I am told TPMs are kinda common. Certainly my work laptop has one. Thanks.
Bounties for xhci features: scatter-gather, suspend/resume
Hi all,
I'd like to offer bounties for the following.
I am also utilizing the wiki to make it easy for others to add their own
bounties: http://wiki.netbsd.org/projects/funded/
xHCI resume support
xhci is everywhere, and for many machines, it's the only remaining step
for a flawless suspend/resume experiences.
xhci_{suspend,resume} are unimplemented, and devices do not work after
resume.
(Contact nia in http://gnats.netbsd.org/56050 for actual hardware testing)
I can offer a bounty of $200 for this.
Offer valid until 1/July/2021.
xHCI scatter-gather support
The infamous "failed to create xfers". xhci wants contiguous
allocations. With too much memory fragmentation, they're hard to do.
This shows up as USB drivers randomly failing on machines that have been
Up for a while.
(chuq attempted to handle this UVM-side recently).
Adding support for xhci scatter-gather means requiring less contiguous
memory, and fewer surprises at high uptime.
I can offer a bounty of $400 for this.
Offer valid until 1/July/2021.
Thanks.
Re: bounty for virtio 1.0 (now with instructions!)
On Tue, Nov 03, 2020 at 10:42:27PM +0100, Martin Husemann wrote: > On Tue, Nov 03, 2020 at 10:23:30PM +0100, Reinoud Zandijk wrote: > > To be clear, do we want to (keep) supporting legacy devices? Its not > > required > > in 1.0 and could clean up the code a lot! > > Yes, we need that still, as not all hosts offer the newer ones. The QEMU people mentioned that even if "legacy virtio" IDs are used, there's a bit to show that it's compatible with newer virtio. Things that claim old virtio probably do both old & new.
Re: bounty for virtio 1.0 (now with instructions!)
On Tue, Sep 01, 2020 at 01:28:44PM +, co...@sdf.org wrote: > Hi all, > > I'd like to offer a bounty for anyone who is interested in working on > VirtIO 1.0 support. It's a well-documented, simple interface. > > I can offer $750 for anyone to send a patch, or in the case of a > developer with commit access, commit it, for the following: > - 1af4:1044 VirtIO 1.0 random number generator > - 1af4:1042 VirtIO 1.0 block device > - 1af4:1041 VirtIO 1.0 network device > > Offer valid until 1 January 2021. If you would like to emulate this, I have a quick command line (that works with the pkgsrc qemu on netbsd). touch myfile qemu-system-x86_64 \ -device virtio-net-pci,disable-legacy=on \ -device virtio-rng,disable-legacy=on \ -drive id=mydrive,file=./myfile,if=none \ -device virtio-blk-pci,drive=mydrive,disable-legacy=on \ -cdrom mynetbsd.iso This will enable all these devices.
Re: make COMPAT_LINUX match SYSV binaries
On Wed, Oct 21, 2020 at 04:02:41PM +, Eduardo Horvath wrote: > On Wed, 21 Oct 2020, co...@sdf.org wrote: > > > In the event someone adds support for another OS with this problem (say, > > modern Solaris), I don't expect this compat to be enabled by default, > > for security reasons. So the problem will only occur if a user enables > > both forms of compat at the same time. > > But Solaris *IS* SYSV. > > Eduardo Solaris has a separate tag, but I'm not sure how consistently it's used. The SmartOS binaries do say: bin/dmenu: ELF 64-bit LSB executable, x86-64, version 1 (Solaris), dynamically linked, interpreter /usr/lib/amd64/ld.so.1, not stripped Bug Go-generated binaries say: main: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/amd64/ld.so.1, Go BuildID=OGLnPmMB8X-FwRbuu90n/GZ0Uvc8LQrh2V9P9rvDk/mRaPYobahbBw4F7aYitg/K58SIG6bmmaibHLZehP8, not stripped
Re: make COMPAT_LINUX match SYSV binaries
On Tue, Oct 20, 2020 at 07:11:05PM +, co...@sdf.org wrote: > hello, > > As a background, some Linux binaries don't claim to be targeting the > Linux OS, but instead are "SYSV". > > We have used some heuristics to still identify those binaries as being > Linux binaries, like looking into the symbols defined by the binary. > > it looks like we no longer have other forms of compat expected to use > SYSV ELF binaries. Perhaps we should drop this elaborate detection logic > in favour of detecting SYSV == Linux? > > As an added bonus, it allows detecting binaries built with a musl > toolchain as being Linux binaries. > I feel compelled to explain further: any OS that doesn't rely on this tag is prone to spitting out binaries with the wrong tag. For example, Go spits out Solaris binaries with SYSV as well. Our current solution to it is the kernel reading through the binary, checking if it contains certain known symbols that are common on Linux. We support the following forms of compat: ultrix not ELF sunos not ELF (we support only oold stuff) freebsd always correctly tagged, because the native OS checks this, like we do. linux ELF, not always correctly tagged So, currently, we only support one OS that has this problem, which is linux. I am proposing we take advantage of it. In the event someone adds support for another OS with this problem (say, modern Solaris), I don't expect this compat to be enabled by default, for security reasons. So the problem will only occur if a user enables both forms of compat at the same time. Users already have to opt in to have Linux compat support. I think it is a lot to ask to have them tag every binary.
make COMPAT_LINUX match SYSV binaries
hello, As a background, some Linux binaries don't claim to be targeting the Linux OS, but instead are "SYSV". We have used some heuristics to still identify those binaries as being Linux binaries, like looking into the symbols defined by the binary. it looks like we no longer have other forms of compat expected to use SYSV ELF binaries. Perhaps we should drop this elaborate detection logic in favour of detecting SYSV == Linux? As an added bonus, it allows detecting binaries built with a musl toolchain as being Linux binaries. Index: linux/common/linux_exec_elf32.c === RCS file: /cvsroot/src/sys/compat/linux/common/linux_exec_elf32.c,v retrieving revision 1.100 diff -u -r1.100 linux_exec_elf32.c --- linux/common/linux_exec_elf32.c 12 Jan 2020 18:30:58 - 1.100 +++ linux/common/linux_exec_elf32.c 19 Oct 2020 17:47:40 - @@ -370,6 +281,9 @@ memcmp(>e_ident[EI_ABIVERSION], linux, sizeof(linux)) == 0) return 0; + if (eh->e_ident[EI_OSABI] == ELFOSABI_SYSV) + return 0; + phsize = eh->e_phnum * sizeof(Elf_Phdr); ph = (Elf_Phdr *)malloc(phsize, M_TEMP, M_WAITOK); error = exec_read(l, epp->ep_vp, eh->e_phoff, ph, phsize,
bounty for virtio 1.0
Hi all, I'd like to offer a bounty for anyone who is interested in working on VirtIO 1.0 support. It's a well-documented, simple interface. I can offer $750 for anyone to send a patch, or in the case of a developer with commit access, commit it, for the following: - 1af4:1044 VirtIO 1.0 random number generator - 1af4:1042 VirtIO 1.0 block device - 1af4:1041 VirtIO 1.0 network device Offer valid until 1 January 2021. Thanks.
Re: Firefox dysfunctional, need help with sys/kern/uipc_sem.c
Disaster averted thanks to how macOS this limitation :) I have a patch (thanks to nia) that avoids the need for process-shared semaphores, so we aren't in a bad shape. Will commit soon.
Firefox dysfunctional, need help with sys/kern/uipc_sem.c
Hi all,
I'd like to call attention to a bug we have:
http://gnats.netbsd.org/55386
At some point Firefox added support for running on multiple OS
processes. To do this, it uses a process-shared semaphores.
We used to not support them properly (rather: lied about supporting
them, but failed to implement in practice). This caused a different set
of issues in the past.
In NetBSD 9.x, thorpej implemented process-shared semaphores, but the
implementation is a bit weird to avoid breaking compatibility with the
struct choices done in the previous implementation.
It has one caveat remaining: it doesn't allow destroying a semaphore
from another process. This causes firefox to violently leak fds, and
eventually show corrupt output.
sys__ksem_destroy
...
/* Cannot destroy if we did't create it. */
KASSERT(fd == -1);
KASSERT(ks->ks_pshared_proc != NULL);
if (ks->ks_pshared_proc != curproc) {
error = EINVAL;
goto out;
}
Most of the web is usable with bumping sysctl kern.maxfiles, but it
doesn't seem to bump RLIMIT_NOFILE, so a few websites still fail.
It might be worthwhile to bump MAXFILES anyway, it's somewhat long
overdue.
It would be nice if more people looked at this problem, because it is
getting very hard to work-around this issue in Firefox. Our previous
workaround (entirely disable multiprocess firefox) can't display
google.com(!).
Thanks.
Proposal: removing uyap(4), USB YAP phone firmware loader
For some background, I believe this is the device in question:
https://www.ebay.com/itm/Yap-USB-Phone-Software-Yap-Time-Your-Alternative-Phone-/264056870659
It was added in 2001, and I believe it's unlikely to be in use today.
It's pretty easy for a USB device to impersonate another USB device, so
it's one more device to audit and fix. In this case, it's unlikely
anyone will notice breakage to the driver because it's so esoteric.
I will remove this driver and associated code in 2 weeks if nobody
objects to it, that is:
sys/dev/usb/{ezload.c, ezload.h, uyap.c, uyap_firmware.h}
Proposal: removing uyurex(4)
Hi tech-kern, I'd like to propose removing uyurex(4) This is a driver for a machine created as an elaborate joke in 2008. http://pinktentacle.com/2008/12/yurex-restless-leg-monitor-by-maywa-denki/ It is disabled by default right now, but still: - appearing as results when searching for similar buffer overflows and thus came up in a discussion following maxv's security auditing - is on the list of devices to USB MP-ify - needs to be touched on refactors I'd like to remove it. The joke is probably over by now, now it just shows up in random searches for bugs :-) If not objected, I'll remove it in 2 weeks.
Proposal: removing urio(4), Rio 500 MP3 player (1999), and Rio-related packages
Hi folks, urio(4) is a driver for Rio 500, an MP3 player released in 1999. It recently received some discussion due to problems detected during maxv's USB-fuzzing. Since I expect there are very few functional devices left, I am proposing to delete this driver from NetBSD. I'd also like to propose removing some of the Rio-related pkgsrc packages: audio/rio500 last intentional commit seems to be in the year 2000 audio/rio for an even older model, last commit that seemed to have used the package is in 2000 audio/rioutil updated in 2007, a blind update saying "I don't own such devices any more". Please respond if you use this device or see a purpose in keeping the driver or packages. otherwise I will remove these packages and the driver in a month.
Re: /dev/random is hot garbage
On Sun, Jul 21, 2019 at 04:53:08PM +, Taylor R Campbell wrote: > It has become popular to redefine the traditional semantics of > /dev/random or /dev/urandom so that one or both will block once at > boot until the OS thinks the entropy pool may have been seeded, and > then never block again. > > I don't want to do this because code paths that may block but only > in extreme circumstances, like early at boot on an embedded system, > are likely never to be exercised even during what might otherwise be > extensive testing, and as noted blocking when not expected can have > severe consequences. It currently blocks for literally hours/days. We can't have the OS not function due to this purity.
Re: /dev/random is hot garbage
I'm just pissed off with the current status quo that we tolerate everything being broken. AMD CPUs do not provide hardware RNG. NVMe isn't used as an RNG source because it would slow it down too much. netbsd/xen never heard about RNG. Or monotonic time. Why are we using this to build packages?! We allow userland to deplete the entropy pool and then have /dev/random reads block until more randomness is acquired. Which is never, if you use some modern hardware, or old hardware, or embedded hardware, or VMs. Rust reads a byte from /dev/random before deciding it's OK to read /dev/urandom. We are told this is the correct behaviour and that we shouldn't upstream "just use /dev/urandom/sysctl equivalent". Nothing builds, we don't supply binary packages, and nobody cares. "Just get a 128GB RAM 32 core machine like me, and then you can use netbsd"
/dev/random is hot garbage
hi, since netbsd won't stop using broken setups like xen (which don't provide randomness) to build packages, why don't we give up on /dev/random entirely?
Re: sys/malloc.h
On Tue, Jul 02, 2019 at 07:18:31AM -0700, Jason Thorpe wrote: > There is a lot of code still using the old names, but using #define is the > wrong way to provide it. > > I would suggest changing it to a static inline __unused function instead. > > -- thorpej > Sent from my iPhone. > > > On Jul 2, 2019, at 5:03 AM, co...@sdf.org wrote: > > > > This was confusing for a bit, but apparently is due to sys/malloc.h: > > > > #definefree(addr, type)kern_free(addr) > > > > This feels like a recipe for subtle bugs. > > What's our plan for this code? > I run into serious issues with needing to provide the malloc types from this.
sys/malloc.h
Hi folks, I'm working on an import of a giant pile of code, and ran into the following build error: drm_gem.c:987:23: error: macro "free" requires 2 arguments, but only 1 given obj->funcs->free(obj); ^ This was confusing for a bit, but apparently is due to sys/malloc.h: #define free(addr, type)kern_free(addr) This feels like a recipe for subtle bugs. What's our plan for this code?
Re: EVFILT_USER?
On Mon, Feb 18, 2019 at 01:03:03AM +0100, Christoph Badura wrote: > On Sun, Feb 17, 2019 at 01:48:52PM -0800, Jason Thorpe wrote: > > > On Feb 17, 2019, at 1:32 PM, co...@sdf.org wrote: > > > the linux equivalent code seems to be using futex_wait/wake. > > > > I’m working on integrating a new Linux-compatible futex > > implementation written by Taylor (that led me down the rabbit hole of > > needing to fix issues with fetch(9) / store(9) first). Thanks. looking forward to use it. > That's nice. But it doesn't help porting ziplang to our releases. I don't expect anyone to be negatively affected from the absence of Zig support in existing releases.
EVFILT_USER?
Hi folks, Do we have anything that resembles EVFILT_USER? Apparently, it makes it possible for userland to send events around. This came up in a programming language port. https://github.com/ziglang/zig/blob/master/std/event/loop.zig I assume (based on a superficial reading) that I would like to have a thread sleep on something, then have another thread wake it up, in userland. the linux equivalent code seems to be using futex_wait/wake. thanks.
Re: Audio device mmap and kevents
On Sat, Jan 26, 2019 at 12:38:09PM +0900, Tetsuya Isaki wrote: > At Wed, 23 Jan 2019 16:32:01 +, > co...@sdf.org wrote: > > > the latency issue doesn't matter; > > Using an AMD Ryzen 7 2700X (or: this machine isn't weak): > > > > > mpv --no-video "https://www.youtube.com...; > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND > > 4908 fly 250 299M 41M CPU/0 2:32 98.83% 98.78% mpv > > > > (kern/53028) > > Would you split the PR into "hdaudio default latency too high" > and "mpv spins at 100% CPU playing audio" ? These are completely > different problems. > > For first one (latency problem), I was doubtful about displayed > value at boot time. Anyway, it's too large in either case. I am > rewriting it now. > > For second one (mpv spins at 100% cpu), I could reproduce and > I found src/lib/libossaudio/ossaudio.c rev 1.33 is the cause. > The calculation of GETOSPACE is obviously wrong and rev 1.32 > is correct. > > I think the scenario where mpv was spinning is as follows: > 1) mpv calls ioctl(SNDCTL_DSP_GETOSPACE) to ask how much free >space on write buffer. > 2) Due to this mis-calculation, GETOSPACE may return 0 (means >no writeable space) even writeable. > 3) Then mpv will poll(2) to wait to become writeable. > 4) However poll(2) will return immediately because it's writeable. > 5) goto 1! > > I could run "mpv -ao=oss some.mp3" at 0~1% CPU with rev 1.32 > on netbsd-8. > > May I commit(revert) it? > > According to PR kern/51999, this commit made mplayer work again. > But I doubt it. Unfortunately I don't have environment to play > mplayer now. Can someone confirm this? > > Thanks. > --- > Tetsuya Isaki I can confirm that pulse+mplayer still works with 1.33 reverted, and that the 100% cpu usage is gone. Thanks!
Re: Audio device mmap and kevents
> the latency issue doesn't matter; Using an AMD Ryzen 7 2700X (or: this machine isn't weak): > mpv --no-video "https://www.youtube.com...; PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 4908 fly 250 299M 41M CPU/0 2:32 98.83% 98.78% mpv (kern/53028)
Re: pckbc_cd
Thanks. I'm not sure if it is a sufficient explanation though, there's a CFATTACH_DECL_NEW(pckbc_acpi, ... but no CFATTACH_DCEL_NEW(pckbc, .. Or does that work somehow?
pckbc_cd
Hi folks, looking at port-i386/43331 I came across pckbc_cd. It doens't appear to be defined anywhere or initialized, though there's an extern in sys/arch/i386/pnpbios/pckbc_pnpbios.c How does this work? how does it compile?! :-)
process-shared mutexes
Hi, Is named semaphores the only way to have locking shared across processes? Thinking of: 1. Implementing shared process lock using named semaphores 2. Using this to implement locked atomics for machines with insufficient atomic instructions
Re: Things not referenced in kernel configs, but mentioned in files.*
> there's always the Attic
I'm currently using a custom kernel with a driver from netbsd-8
(nouveau), it was surprisingly painless to put the old version in.
(in case anyone is curious, copy sys/external/bsd/{common,drm2}. Of
course, I should attempt to fix it, but I like to be able to run
-current until we figure it out).
Re: Things not referenced in kernel configs, but mentioned in files.*
On Mon, Nov 12, 2018 at 10:23:26AM -0500, Greg Troxel wrote:
>
> co...@sdf.org writes:
>
> > This is an automatically generated list with some hand touchups, feel
> > free to do whatever with it. I only generated the output.
> >
> > ac100ic
> > acemidi
> > acpipmtr
> > [snip]
>
> I wonder if these are candidates to add to an ALL kernel, and if it will
> turn out that they are mostly not x86 things.
>
> I see we only have ALL for i386/amd64. I wonder if it makes sense to
> have one in evbarm.
The actual search was roughly (and I didn't re-test these commands)
find src/sys -name 'files.*' | xargs grep 'attach' | awk '{print $2}' > drivers
for i in `cat drivers`; do echo $i; grep "^$i[^a-z]" src/sys/arch/*/conf/*;
done |grep -v ALL > appearances-in-configs
grep -B 1 '[^0-9]0$' appearances-in-configs > no-appearance-in-configs
And some manual removal of things that are obviously not drivers,
removing duplicates, sorting...
So, I am excluding things that appear in ALL, and I am not checking if
they appear as modules.
So far I had complaints about the appearance of 'lm' which cannot be
safely included in a default kernel, for example.
Things not referenced in kernel configs, but mentioned in files.*
This is an automatically generated list with some hand touchups, feel free to do whatever with it. I only generated the output. ac100ic acemidi acpipmtr acpismbus act8846pm addcom altmem am2315temp applesmc aps aria atppc auvitek axp809pm az azalia because boca btvmei btvmeii cec cir clcd cms cs80bus cxgb cxgbc ddc dmc dmf dmz ds1672rtc e1000phy ega em3027rtc emdtv ena finsio glxt gpib gpioirq gpiopps gpiorfkill gtp hpacel hythygtemp ibmcd ibmhawk igma igmafb il imt ioat ips irmce isv itesio kse lm lmenv maxrtc mcd mcp23s17gpio mcp3kadc mcp48x1dac mcp980x moscom moxa mpl115a nca plip pps qd rsu rt rtfps rtii satlink sdtemp sf2r sf4r sfbp si70xxtemp siosixteen slurm smsc smscmon soekrisgpio swide tcom tea5767radio tsllux ualea uark uatp udsir ugenif uhmodem uipad umb umcs unichromefb uyurex vac vboxdrm vme_slv w83795g wbsio wt
filedesc(9) rewrite, please review
hi, attached is the generated output of a filedesc(9) rewrite. The source to generate it is less important, but also available here: http://coypu.sdf.org/filedesc.9 Most of the changes were rewriting the functions to describe the new API names and signatures. I tried to add some more functions for completeness, but it is still not all. Please review. FILEDESC(9)Kernel Developer's Manual FILEDESC(9) NAME filedesc, fd_alloc, fd_checkstd, fd_clone, fd_closeexec, fd_copy, fd_dup, fd_dup2, fd_dupopen, fd_free, fd_init, fd_getfile, fd_share, fd_tryexpand, file descriptor tables and operations SYNOPSIS #include #include int fd_alloc(proc_t *p, int want, int *result); int fd_checkstd(void); int fd_clone(file_t *fp, int fd, int flag, const struct fileops *fops, void *data); filedesc_t * fd_copy(void); void fd_closeexec(void); int fd_dup(file_t *fp, int minfd, int *newp, bool exclose); int fd_dup2(file_t *fp, unsigned newfd, int flags); int fd_dupopen(int old, int *newp, int error); void fd_free(void); filedesc_t * fd_init(filedesc_t *fdp); file_t * fd_getfile(unsigned fd); void fd_share(proc_t *p); void fd_tryexpand(proc_t *p); DESCRIPTION For user processes, all I/O is done through file descriptors. These file descriptors represent underlying objects supported by the kernel and are created by system calls specific to the type of object. In NetBSD, six types of objects can be represented by file descriptors: data files, pipes, sockets, event queues, crypto, and miscellaneous. The kernel maintains a descriptor table for each process which is used to translate the external representation of a file descriptor into an internal representation. The file descriptor is merely an index into this table. The file descriptor table maintains the following information: the number of descriptors allocated in the file descriptor table; approximate next free descriptor; a reference count on the file descriptor table; and an array of open file entries. On creation of the file descriptor table, a fixed number of file entries are created. It is the responsibility of the file descriptor operations to expand the available number of entries if more are required. Each file entry in the descriptor table contains the information necessary to access the underlying object and to maintain common information. See file(9) for details of operations on the file entries. New file descriptors are generally allocated by fd_alloc() and freed by fd_free(). File entries are extracted from the file descriptor table by fd_getfile(). Most of the remaining functions in the interface are purpose specific and perform lower-level file descriptor operations. FUNCTIONS The following functions are high-level interface routines to access the file descriptor table for a process and its file entries. fd_alloc(p, want, *result) Create a new open file entry and allocate a file descriptor for the process p. This operation is performed by invoking fd_alloc() to allocate the new file descriptor. The credential on the file entry are inherited from process p. The caller to the fd_alloc() function is responsible for expanding the file descriptor table when necessary. The index of the file entry is returned in *result. The fd_alloc() function returns zero on success, otherwise an appropriate error is returned. fd_getfile(fd) Get the file entry for file descriptor fd The file entry is returned if it is valid and usable, otherwise NULL is returned. fd_dup(fp, minfd, *newp, exclose) Duplicate file descriptor fp for the current process. The fd picked will be at least minfd. The resulting descriptor is given in newp. fd_dup2(fp, newfd, flags) Duplicate file descriptor fp in fd number newfd. If there is already an open file, close it (See dup2(2)). fd_dupopen(old, *newp, error) Duplicate file descriptor specified in old for the current lwp. The following functions operate on the file descriptor table for a process. fd_alloc(p, want, *result) Allocate a file descriptor want for process p. The resultant file descriptor is returned in *result. The fd_alloc() function returns zero on success, otherwise an appropriate error is returned. fd_clone(fp, fd, flag, fops, data) This function is meant to be used by devices which allocate a file entry
fd_putvnode
Hi folks, I've been requested to rewrite filedesc(9) (the manual page, not the API) as it describes the old API. I noticed we have fd_putvnode with these two matches in src/sys: kern/kern_descrip.c 140:__strong_alias(fd_putvnode,fd_putfile) sys/filedesc.h 205:void fd_putvnode(unsigned); What's the point to have a strong alias like this for something under #ifdef _KERNEL? Can I delete this in the next kernel ABI bump someone has planned? Thanks.
Re: Debugging DRM on a laptop?
On Mon, Aug 06, 2018 at 11:02:45AM +1000, matthew green wrote:
> co...@sdf.org writes:
> > Hi folks,
> >
> > we're working on a drmkms update.
> > I'm testing it on a Dell XPS 9550. It's a laptop with a Skylake CPU.
> > It has a power button. The power button powers off, not reboot.
> > This means the dmesg buffer gets wiped.
> > No serial console as far as I know.
> >
> > Now it reaches a point where the screen changes, but my DDB_COMMANDENTER
> > containing "reboot" won't do the expected thing. It's possible it's
> > hanging. I can't seem to blindly enter ddb.
> >
> > Any suggestions to make debugging less painful?
> > Something like arm a watchdog to panic after some time.
> >
> > I'm gonna experiment with sprinkling panic("XXX"); and see if this works
> > out.
>
> if you have ddb.onpanic=0 then it will write a crash dump and
> reboot. that should give you something useful.
It's not reaching a panic. And I'm not sure it's reliable about where it
hangs (if at all).
This is after cndetach so maybe that explains why my keyboard doesn't
work to blindly enter ddb.
I'm gonna try to add a watchdog driver, ichlpcib doesn't work out of the
box on the "Sunrise Point-H LPC controller" or "HM170 chipset LPC" but
it has 1771 pages worth of documents so maybe I can get it to work.
Debugging DRM on a laptop?
Hi folks,
we're working on a drmkms update.
I'm testing it on a Dell XPS 9550. It's a laptop with a Skylake CPU.
It has a power button. The power button powers off, not reboot.
This means the dmesg buffer gets wiped.
No serial console as far as I know.
Now it reaches a point where the screen changes, but my DDB_COMMANDENTER
containing "reboot" won't do the expected thing. It's possible it's
hanging. I can't seem to blindly enter ddb.
Any suggestions to make debugging less painful?
Something like arm a watchdog to panic after some time.
I'm gonna experiment with sprinkling panic("XXX"); and see if this works
out.
Re: hashtables
On Tue, Jul 24, 2018 at 05:46:16PM -0400, Thor Lancelot Simon wrote: > On Tue, Jul 24, 2018 at 07:01:36PM +, co...@sdf.org wrote: > > hi netbsd, > > > > if I were to state I totally need hashtables, what already existing API > > would you tell me to use instead? > > The kernel has lots of hash tables in it. If a hash table is the right > datastructure for your purpose, why do something else? > > Thor I have nearly zero background in CS, GPUs or hardware drivers. It's pretty hard to make sense of things. I'm trying my best though. I need this driver. I don't have any opinions about hashtables - I just know that implementing one would take me really long and would probably still be buggy in the end, and I didn't find a similar API that claims to be a hashtable. Is there some code I could use? I'm totally OK with not a hashtable too.
hashtables
hi netbsd, if I were to state I totally need hashtables, what already existing API would you tell me to use instead? I am porting code: https://github.com/torvalds/linux/blob/605dc7761d2701f73c17183649de0e3044609817/drivers/gpu/drm/i915/i915_cmd_parser.c#L842-L852
Re: pserialize_switchpoint() question
im probably not qualified to give an explanation but: as i understand it, rcu is supposed to be a synchronization mechanism that produces less contention/locks. suppose we store our objects in a linked list: [A] -> [myobj] -> [C] In order to write, we can change the linked list to look like [myobj] [A] -> [C] this is safe to do without atomics. now we wait for a message that all other cores have completed the kernel execution they were doing. once this is done then we know there is no one who might read [myobj] while we modify it. now we can modify it. when done we put it back on the list. this way, reading doesn't need any lock at all. pserialize was implemented differently as the rcu patent did not expire then. i think we use higher spl when reading, higher than can be used to answer the xcall. but i am not sure.
hid.h fallout in third party code
hi folks, in https://github.com/NetBSD/src/commit/a9e749a2e2d0044b947401ce80790a5788fad76e#diff-9353912fc541114002b043446f11751e bouyer had moved many definitions out of usbhid.h. This is a user-visible header and appears in third party packages, which now need even more ifdefs, and those need to be versioned too, which is extra ugly. example of third party code using it: https://sourceforge.net/p/vice-emu/code/HEAD/tree/tags/v3.2/vice/src/arch/unix/joy_usb.c#l72 How about this following diff, to retain the same visiblity for the definitions? I needed HUP_GENERIC_DESKTOP. Index: dev/usb/usbhid.h === RCS file: /cvsroot/src/sys/dev/usb/usbhid.h,v retrieving revision 1.17 diff -u -r1.17 usbhid.h --- dev/usb/usbhid.h10 Dec 2017 17:03:07 - 1.17 +++ dev/usb/usbhid.h14 Jul 2018 15:35:39 - @@ -35,6 +35,8 @@ #ifndef _DEV_USB_USBHID_H_ #define _DEV_USB_USBHID_H_ +#include + #define UR_GET_HID_DESCRIPTOR 0x06 #define UDESC_HID 0x21 #define UDESC_REPORT 0x22
Re: Removing bitrotted sys/dev/pci/n8 (NetOctave NSP2000)
Thanks for confirming! :-) I'll still hold my original promise of waiting a month to do so.
Removing bitrotted sys/dev/pci/n8 (NetOctave NSP2000)
Hi, The code in sys/dev/pci/n8 has bitrotted - it still makes references to LKM_ system things, so it is unlikely it builds. This has been the case since netbsd-6. I am interested in removing this because while playing with a text-processing tool to look for bugs, I came across this and spent some time looking at something that looked like a bug before realizing the code doesn't build. Thoughts? objections? If no one objects in a month, I will remove all the files in sys/dev/pci/n8 and all related references.
Removing viadrm
Hi folks,
we have two ports of linux drm code. old drm, which exists because not
all devices/drivers work with the newer, also non-x86 architectures use
this.
new drm ("drm2") which hopefully we'll transition to.
there are two via drivers:
viadrmums (drm2)
viadrm (old drm)
according to PR port-i386/53364, viadrm doesn't work any more.
viadrmums does, and uses the newer drm code.
viadrmums shouldn't be significantly different in terms of support (the
driver was almost abandoned upstream until recently).
I don't know of any non-x86 via graphics possible users.
If nobody objects, I will delete viadrm in 1-2 weeks.
workaround intel apollo lake errata
Hi,
Currently Apollo Lake CPUs fail to boot with SMP enabled.[1]
This is because we use MONITOR/MWAIT with interrupts disabled for
waiting for secondary CPUs to hatch.
Errata means the wakeup doesn't happen.[2]
I've written the attached patch, and tested it by matching my existing
CPU which doesn't have this problem. I see monitor is disabled early
enough.
Due to the first patch failing I know this means that ACPI C FFH won't
be used[3][4]. I suspect this use is safer because it is with interrupts
enabled.
(I'm not sure how to name the MISC_ENABLES register value thing)
Is this diff acceptable?
[1]
https://mail-index.netbsd.org/netbsd-users/2018/06/25/msg021006.html
[2]
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-j-series-datasheet-spec-update.pdf
APL30 A Store Instruction May Not Wake up MWAIT
Problem :
One use of the MONITOR/MWAIT instruction pair is to allow a logical
processor to wait in a sleep state until a store to the armed address
range occurs. Due to this erratum,
stores to the armed address range may not trigger MWAIT to resume execution.
Implication :
The logical processor that executed the MWAIT instruction may not resume
execution
until it receives an interrupt. Software that does not rely on stores to
the armed address range to wake a logical processor from an MWAIT sleep state is
not affected
by this erratum.
Workaround :
Software needs to use interrupts to wake processors from MWAIT-induced
sleep states.
[3] https://nxr.netbsd.org/xref/src/sys/arch/x86/acpi/acpi_cpu_md.c#404
[4] https://nxr.netbsd.org/xref/src/sys/arch/x86/acpi/acpi_cpu_md.c#157
Index: x86/include/specialreg.h
===
RCS file: /cvsroot/src/sys/arch/x86/include/specialreg.h,v
retrieving revision 1.126
diff -u -r1.126 specialreg.h
--- x86/include/specialreg.h31 May 2018 03:29:01 - 1.126
+++ x86/include/specialreg.h1 Jul 2018 08:20:47 -
@@ -683,6 +683,7 @@
#define MSR_THERM_STATUS 0x19c
#define MSR_THERM2_CTL 0x19d /* Pentium M */
#define MSR_MISC_ENABLE0x1a0
+#defineIA32_MISC_MWAIT_EN 0x4
#define MSR_TEMPERATURE_TARGET 0x1a2
#define MSR_DEBUGCTLMSR0x1d9
#define MSR_LASTBRANCHFROMIP 0x1db
Index: x86/x86/identcpu.c
===
RCS file: /cvsroot/src/sys/arch/x86/x86/identcpu.c,v
retrieving revision 1.77
diff -u -r1.77 identcpu.c
--- x86/x86/identcpu.c 23 Jun 2018 10:30:22 - 1.77
+++ x86/x86/identcpu.c 1 Jul 2018 08:20:47 -
@@ -190,6 +190,23 @@
}
static void
+cpu_probe_intel_errata(struct cpu_info *ci)
+{
+u_int family, model, stepping;
+
+family = CPUID_TO_FAMILY(ci->ci_signature);
+model = CPUID_TO_MODEL(ci->ci_signature);
+stepping = CPUID_TO_STEPPING(ci->ci_signature);
+
+ if (family == 0x6 && model == 0xC && stepping == 0x9) {
+ /* APL30 - A Store Instruction May Not Wake up MWAIT */
+ wrmsr(MSR_MISC_ENABLE, rdmsr(MSR_MISC_ENABLE) &
~IA32_MISC_MWAIT_EN);
+ cpu_feature[1] &= ~CPUID2_MONITOR;
+ ci->ci_feat_val[1] &= ~CPUID2_MONITOR;
+ }
+}
+
+static void
cpu_probe_intel(struct cpu_info *ci)
{
@@ -197,6 +214,7 @@
return;
cpu_probe_intel_cache(ci);
+ cpu_probe_intel_errata(ci);
}
static void
bwfm(4) PCI support
Hi folks.
I'm new to network driver code. I've managed to get a working bwfm with
the mentioned patches, though I haven't done a full release build yet.
I've only tested an open network due to not having other choices, but I
will soon test WPA.
It seems to work for fetching files & pinging stuff.
I'm omitting the actual firmware from the diff because it's big and
binary.
Let me know what you think. I will commit this in a few days if nobody
objects.
>From 4df83365c365371a15d2f6d837bd906add23bee0 Mon Sep 17 00:00:00 2001
From: coypu <co...@sdf.org>
Date: Fri, 4 May 2018 02:41:00 +0300
Subject: [PATCH 1/4] sync with openbsd bwfm
adds a txcheck.
set chip active/passive for more kinds of chips and add wrapper around
detect chip RAM
make bwfm_rx take an mbuf
---
sys/dev/ic/bwfm.c| 333 ++-
sys/dev/ic/bwfmreg.h | 107 ++-
sys/dev/ic/bwfmvar.h | 17 +-
sys/dev/sdmmc/if_bwfm_sdio.c | 11 ++
sys/dev/usb/if_bwfm_usb.c| 50 +-
5 files changed, 466 insertions(+), 52 deletions(-)
diff --git a/sys/dev/ic/bwfm.c b/sys/dev/ic/bwfm.c
index 82bac1d2a4..8da9214833 100644
--- a/sys/dev/ic/bwfm.c
+++ b/sys/dev/ic/bwfm.c
@@ -21,7 +21,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -85,9 +84,16 @@ void bwfm_chip_ai_reset(struct bwfm_softc *, struct
bwfm_core *,
voidbwfm_chip_dmp_erom_scan(struct bwfm_softc *);
int bwfm_chip_dmp_get_regaddr(struct bwfm_softc *, uint32_t *,
uint32_t *, uint32_t *);
+int bwfm_chip_cr4_set_active(struct bwfm_softc *, const uint32_t);
voidbwfm_chip_cr4_set_passive(struct bwfm_softc *);
+int bwfm_chip_ca7_set_active(struct bwfm_softc *, const uint32_t);
voidbwfm_chip_ca7_set_passive(struct bwfm_softc *);
+int bwfm_chip_cm3_set_active(struct bwfm_softc *);
voidbwfm_chip_cm3_set_passive(struct bwfm_softc *);
+voidbwfm_chip_socram_ramsize(struct bwfm_softc *, struct bwfm_core *);
+voidbwfm_chip_sysmem_ramsize(struct bwfm_softc *, struct bwfm_core *);
+voidbwfm_chip_tcm_ramsize(struct bwfm_softc *, struct bwfm_core *);
+voidbwfm_chip_tcm_rambase(struct bwfm_softc *);
int bwfm_proto_bcdc_query_dcmd(struct bwfm_softc *, int,
int, char *, size_t *);
@@ -107,7 +113,7 @@ struct ieee80211_channel *bwfm_bss2chan(struct bwfm_softc
*, struct bwfm_bss_inf
voidbwfm_scan(struct bwfm_softc *);
voidbwfm_connect(struct bwfm_softc *);
-voidbwfm_rx(struct bwfm_softc *, char *, size_t);
+voidbwfm_rx(struct bwfm_softc *, struct mbuf *);
voidbwfm_rx_event(struct bwfm_softc *, char *, size_t);
voidbwfm_scan_node(struct bwfm_softc *, struct bwfm_bss_info *, size_t);
@@ -133,7 +139,7 @@ bwfm_attach(struct bwfm_softc *sc)
char fw_version[BWFM_DCMD_SMLEN];
uint32_t bandlist[3];
uint32_t tmp;
- int i, error;
+ int i, j, error;
error = workqueue_create(>sc_taskq, DEVNAME(sc),
bwfm_task, sc, PRI_NONE, IPL_NET, 0);
@@ -203,8 +209,8 @@ bwfm_attach(struct bwfm_softc *sc)
ic->ic_sup_rates[IEEE80211_MODE_11B] =
ieee80211_std_rateset_11b;
ic->ic_sup_rates[IEEE80211_MODE_11G] =
ieee80211_std_rateset_11g;
- for (i = 0; i < __arraycount(bwfm_2ghz_channels); i++) {
- uint8_t chan = bwfm_2ghz_channels[i];
+ for (j = 0; j < __arraycount(bwfm_2ghz_channels); j++) {
+ uint8_t chan = bwfm_2ghz_channels[j];
ic->ic_channels[chan].ic_freq =
ieee80211_ieee2mhz(chan,
IEEE80211_CHAN_2GHZ);
ic->ic_channels[chan].ic_flags =
@@ -215,8 +221,8 @@ bwfm_attach(struct bwfm_softc *sc)
case BWFM_BAND_5G:
ic->ic_sup_rates[IEEE80211_MODE_11A] =
ieee80211_std_rateset_11a;
- for (i = 0; i < __arraycount(bwfm_5ghz_channels); i++) {
- uint8_t chan = bwfm_5ghz_channels[i];
+ for (j = 0; j < __arraycount(bwfm_5ghz_channels); j++) {
+ uint8_t chan = bwfm_5ghz_channels[j];
ic->ic_channels[chan].ic_freq =
ieee80211_ieee2mhz(chan,
IEEE80211_CHAN_5GHZ);
ic->ic_channels[chan].ic_flags =
@@ -307,6 +313,12 @@ bwfm_start(struct ifnet *ifp)
continue;
}
+ if (sc->sc_bus_ops->bs_txcheck(sc)) {
+ IF_PREPEND(>if_snd, m);
+ ifp->if_flags |= IFF_OACTIVE;
+ break;
+ }
+
IFQ_DEQUEUE(>if_snd, m);
if (m == NULL)
break;
@@ -848,24 +860,22 @@
gc private 802.11 rateset declarations
OK to commit this? I don't have any of the devices unfortunately.
G/C custom rateset definitions.
use standard where applicable.
Built tested only.
Index: dev/ic/atw.c
===
RCS file: /cvsroot/src/sys/dev/ic/atw.c,v
retrieving revision 1.162
diff -u -r1.162 atw.c
--- dev/ic/atw.c23 Oct 2017 09:25:31 - 1.162
+++ dev/ic/atw.c29 Apr 2018 20:48:13 -
@@ -514,7 +514,7 @@
};
struct ieee80211com *ic = >sc_ic;
struct ifnet *ifp = >sc_if;
- int country_code, error, i, nrate, srom_major;
+ int country_code, error, i, srom_major;
u_int32_t reg;
static const char *type_strings[] = {"Intersil (not supported)",
"RFMD", "Marvel (not supported)"};
@@ -781,12 +781,7 @@
ic->ic_caps = IEEE80211_C_PMGT | IEEE80211_C_IBSS |
IEEE80211_C_HOSTAP | IEEE80211_C_MONITOR;
- nrate = 0;
- ic->ic_sup_rates[IEEE80211_MODE_11B].rs_rates[nrate++] = 2;
- ic->ic_sup_rates[IEEE80211_MODE_11B].rs_rates[nrate++] = 4;
- ic->ic_sup_rates[IEEE80211_MODE_11B].rs_rates[nrate++] = 11;
- ic->ic_sup_rates[IEEE80211_MODE_11B].rs_rates[nrate++] = 22;
- ic->ic_sup_rates[IEEE80211_MODE_11B].rs_nrates = nrate;
+ ic->ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
/*
* Call MI attach routines.
Index: dev/ic/rt2560.c
===
RCS file: /cvsroot/src/sys/dev/ic/rt2560.c,v
retrieving revision 1.32
diff -u -r1.32 rt2560.c
--- dev/ic/rt2560.c 8 Feb 2018 09:05:19 - 1.32
+++ dev/ic/rt2560.c 29 Apr 2018 20:48:14 -
@@ -143,18 +143,6 @@
static voidrt2560_softintr(void *);
/*
- * Supported rates for 802.11a/b/g modes (in 500Kbps unit).
- */
-static const struct ieee80211_rateset rt2560_rateset_11a =
- { 8, { 12, 18, 24, 36, 48, 72, 96, 108 } };
-
-static const struct ieee80211_rateset rt2560_rateset_11b =
- { 4, { 2, 4, 11, 22 } };
-
-static const struct ieee80211_rateset rt2560_rateset_11g =
- { 12, { 2, 4, 11, 22, 12, 18, 24, 36, 48, 72, 96, 108 } };
-
-/*
* Default values for MAC registers; values taken from the reference driver.
*/
static const struct {
@@ -420,7 +408,7 @@
if (sc->rf_rev == RT2560_RF_5222) {
/* set supported .11a rates */
- ic->ic_sup_rates[IEEE80211_MODE_11A] = rt2560_rateset_11a;
+ ic->ic_sup_rates[IEEE80211_MODE_11A] =
ieee80211_std_rateset_11a;
/* set supported .11a channels */
for (i = 36; i <= 64; i += 4) {
@@ -441,8 +429,8 @@
}
/* set supported .11b and .11g rates */
- ic->ic_sup_rates[IEEE80211_MODE_11B] = rt2560_rateset_11b;
- ic->ic_sup_rates[IEEE80211_MODE_11G] = rt2560_rateset_11g;
+ ic->ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
+ ic->ic_sup_rates[IEEE80211_MODE_11G] = ieee80211_std_rateset_11g;
/* set supported .11b and .11g channels (1 through 14) */
for (i = 1; i <= 14; i++) {
Index: dev/ic/rt2661.c
===
RCS file: /cvsroot/src/sys/dev/ic/rt2661.c,v
retrieving revision 1.36
diff -u -r1.36 rt2661.c
--- dev/ic/rt2661.c 23 Oct 2017 09:31:17 - 1.36
+++ dev/ic/rt2661.c 29 Apr 2018 20:48:14 -
@@ -167,18 +167,6 @@
static int rt2661_get_rssi(struct rt2661_softc *, uint8_t);
static voidrt2661_softintr(void *);
-/*
- * Supported rates for 802.11a/b/g modes (in 500Kbps unit).
- */
-static const struct ieee80211_rateset rt2661_rateset_11a =
- { 8, { 12, 18, 24, 36, 48, 72, 96, 108 } };
-
-static const struct ieee80211_rateset rt2661_rateset_11b =
- { 4, { 2, 4, 11, 22 } };
-
-static const struct ieee80211_rateset rt2661_rateset_11g =
- { 12, { 2, 4, 11, 22, 12, 18, 24, 36, 48, 72, 96, 108 } };
-
static const struct {
uint32_treg;
uint32_tval;
@@ -309,7 +297,7 @@
if (sc->rf_rev == RT2661_RF_5225 || sc->rf_rev == RT2661_RF_5325) {
/* set supported .11a rates */
- ic->ic_sup_rates[IEEE80211_MODE_11A] = rt2661_rateset_11a;
+ ic->ic_sup_rates[IEEE80211_MODE_11A] =
ieee80211_std_rateset_11a;
/* set supported .11a channels */
for (i = 36; i <= 64; i += 4) {
@@ -330,8 +318,8 @@
}
/* set supported .11b and .11g rates */
- ic->ic_sup_rates[IEEE80211_MODE_11B] = rt2661_rateset_11b;
- ic->ic_sup_rates[IEEE80211_MODE_11G] = rt2661_rateset_11g;
+ ic->ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
+ ic->ic_sup_rates[IEEE80211_MODE_11G] = ieee80211_std_rateset_11g;
/* set supported .11b and .11g channels (1 through 14) */
for (i = 1; i <= 14; i++) {
@@ -2180,7 +2168,7 @@
* Find h/w rate index. We know it exists
rtsx(4) adding RTS525A
This is in a Dell XPS 15 9550.
it seems to work. it detects card inserted and ejected, I can mount
stuff, write stuff, remount, read the same contents again.
I don't see a LED light for it on my machine.
(Needs a pcidevs entry too.)
I don't really know what I'm doing, mostly adapted to have the same
code as RTSX_IS_RTS5227... etc.
In openbsd, that is handled with an 'else' case. they don't seem to
have the RT84xxx stuff we have. I can also do this with 'else' if
that's better.
Shuffled the flags definitions to maintain order.
Thoughts? OKs?
>From 935f6a2f88b99fda00e499b3aa0c751c72f9814b Mon Sep 17 00:00:00 2001
From: coypu <co...@sdf.org>
Date: Tue, 24 Apr 2018 19:54:27 +0300
Subject: [PATCH 1/1] add RTS525A support. From openbsd.
---
sys/dev/ic/rtsx.c | 26 ---
sys/dev/ic/rtsxreg.h | 8 ++
sys/dev/ic/rtsxvar.h | 10 ---
sys/dev/pci/rtsx_pci.c | 59 +++---
4 files changed, 69 insertions(+), 34 deletions(-)
diff --git a/sys/dev/ic/rtsx.c b/sys/dev/ic/rtsx.c
index 380ff8c78..d10b04404 100644
--- a/sys/dev/ic/rtsx.c
+++ b/sys/dev/ic/rtsx.c
@@ -560,7 +560,9 @@ rtsx_bus_power_off(struct rtsx_softc *sc)
disable3 = RTSX_PULL_CTL_DISABLE3;
if (RTSX_IS_RTS5209(sc))
RTSX_SET(sc, RTSX_PWR_GATE_CTRL, RTSX_LDO3318_OFF);
- else if (RTSX_IS_RTS5227(sc) || RTSX_IS_RTS5229(sc)) {
+ else if (RTSX_IS_RTS5227(sc)
+ || RTSX_IS_RTS5229(sc)
+ || RTSX_IS_RTS525A(sc)) {
RTSX_CLR(sc, RTSX_PWR_GATE_CTRL, RTSX_LDO3318_VCC1 |
RTSX_LDO3318_VCC2);
if (RTSX_IS_RTS5229_TYPE_C(sc))
@@ -578,7 +580,10 @@ rtsx_bus_power_off(struct rtsx_softc *sc)
RTSX_CLR(sc, RTSX_CARD_PWR_CTL, RTSX_PMOS_STRG_800mA);
/* Disable pull control. */
- if (RTSX_IS_RTS5209(sc) || RTSX_IS_RTS5227(sc) || RTSX_IS_RTS5229(sc)) {
+ if (RTSX_IS_RTS5209(sc)
+ || RTSX_IS_RTS5227(sc)
+ || RTSX_IS_RTS5229(sc)
+ || RTSX_IS_RTS525A(sc)) {
RTSX_WRITE(sc, RTSX_CARD_PULL_CTL1, RTSX_PULL_CTL_DISABLE12);
RTSX_WRITE(sc, RTSX_CARD_PULL_CTL2, RTSX_PULL_CTL_DISABLE12);
RTSX_WRITE(sc, RTSX_CARD_PULL_CTL3, disable3);
@@ -612,13 +617,23 @@ rtsx_bus_power_on(struct rtsx_softc *sc)
{
uint8_t enable3;
+ if (RTSX_IS_RTS525A(sc)) {
+ int err = rtsx_write(sc, RTSX_LDO_VCC_CFG1,
RTSX_LDO_VCC_TUNE_MASK,
+ RTSX_LDO_VCC_3V3);
+ if (err)
+ return err;
+ }
+
/* Select SD card. */
RTSX_WRITE(sc, RTSX_CARD_SELECT, RTSX_SD_MOD_SEL);
RTSX_WRITE(sc, RTSX_CARD_SHARE_MODE, RTSX_CARD_SHARE_48_SD);
RTSX_SET(sc, RTSX_CARD_CLK_EN, RTSX_SD_CLK_EN);
/* Enable pull control. */
- if (RTSX_IS_RTS5209(sc) || RTSX_IS_RTS5227(sc) || RTSX_IS_RTS5229(sc)) {
+ if (RTSX_IS_RTS5209(sc)
+ || RTSX_IS_RTS5227(sc)
+ || RTSX_IS_RTS5229(sc)
+ || RTSX_IS_RTS525A(sc)) {
RTSX_WRITE(sc, RTSX_CARD_PULL_CTL1, RTSX_PULL_CTL_ENABLE12);
RTSX_WRITE(sc, RTSX_CARD_PULL_CTL2, RTSX_PULL_CTL_ENABLE12);
if (RTSX_IS_RTS5229_TYPE_C(sc))
@@ -653,7 +668,10 @@ rtsx_bus_power_on(struct rtsx_softc *sc)
* delay in between.
*/
- if (RTSX_IS_RTS5209(sc) || RTSX_IS_RTS5227(sc) || RTSX_IS_RTS5229(sc)) {
+ if (RTSX_IS_RTS5209(sc)
+ || RTSX_IS_RTS5227(sc)
+ || RTSX_IS_RTS5229(sc)
+ || RTSX_IS_RTS525A(sc)) {
/* Partial power. */
RTSX_SET(sc, RTSX_CARD_PWR_CTL, RTSX_SD_PARTIAL_PWR_ON);
if (RTSX_IS_RTS5209(sc))
diff --git a/sys/dev/ic/rtsxreg.h b/sys/dev/ic/rtsxreg.h
index 3f00da885..90489b09a 100644
--- a/sys/dev/ic/rtsxreg.h
+++ b/sys/dev/ic/rtsxreg.h
@@ -544,6 +544,14 @@
#defineRTSX_DUMMY_REG 0xFE90
+#defineRTSX_LDO_VCC_CFG1 0xFF73
+#defineRTSX_LDO_VCC_REF_TUNE_MASK 0x30
+#defineRTSX_LDO_VCC_REF_1V20x20
+#defineRTSX_LDO_VCC_TUNE_MASK 0x07
+#defineRTSX_LDO_VCC_1V80x04
+#defineRTSX_LDO_VCC_3V30x07
+#defineRTSX_LDO_VCC_LMT_EN 0x08
+
#defineRTSX_SG_INT 0x04
#defineRTSX_SG_END 0x02
#defineRTSX_SG_VALID 0x01
diff --git a/sys/dev/ic/rtsxvar.h b/sys/dev/ic/rtsxvar.h
index 13f0d5242..98ea4236f 100644
--- a/sys/dev/ic/rtsxvar.h
+++ b/sys/dev/ic/rtsxvar.h
@@ -57,10 +57,11 @@ struct rtsx_softc {
#defineRTSX_F_5227 __BIT(3)
#defineRTSX_F_5229 __BIT(4)
#defineRTSX_F_5229_TYPE_C __BIT(5)
-#defineRTSX_F_8402 __BIT(6)
-#defineRTSX_F_8411 __BIT(7)
-#defineRTSX_F_8411B__BIT(8)
-#defineRTSX_F_8411B_QFN48
vfs question
Hi I am looking at code related to PR 53096 (really important please look at it too), I came across this code, in vfs_vnode.c vrelel: 732 mutex_exit(vp->v_interlock); 733 error = vn_lock(vp, 734 LK_EXCLUSIVE | LK_RETRY | (force ? 0 : LK_NOWAIT)); 735 defer = (error != 0); 736 mutex_enter(vp->v_interlock); Is this pattern of code legal? it looks like we are dropping all locks, then making a reference to vp again (even dereferencing it), and it might have been nuked from low orbit (freed) since we last had guarantees about it. Am I missing something?
ehci_sync_hc timeout on loongson
Hi folks. I've been trying to use a lemote yeeloong. it has internal usb wifi and usb is on pci. wifi occasionally works fine, and sometimes it will say 'ehci_sync_hc timeout' and fail to work until I reboot. I'm wondering what it could be, but don't know what to look for. some low power mode for USB/PCI? Any idea?
Spectre
Hi folks. Spectre is also a vulnerability. It's been discussed in the context of web browsers, but it does have repercussions for kernel. The gist of it seems to be, if you have code that looks like this: Variant 1: if (malicious offset is safe) value = array[malicious_offset]; value2 = (value & 1) value3 = array2[value2] You can read arbitrary memory, as cached memory will be faster. repeat this bit by bit. Variant 2: relies on poisoning the branch predictor if_transmit = mydriver_transmit; .. regular code if_transmit(); /* indirect call */ .. malicious_ptr: value = array[malicious_offset]; value2 = (value & 1) value3 = array2[value2] Now, we poison the branch target buffer, to predict that if_transmit = malicious_ptr. It does not even appear like a possible code path, but it is. This means that code being loaded is enough to pose a risk, even if there is no easy path to it. Some things that help this: - Rather than look for a gadget like this, they went for eBPF, which is like dtrace. It also has a JIT. You can load bytecode and it will verify and execute it. So you can make your own speculation-gadget. - Some archs do not allow fine-grained cache control like x86 clflush, but this isn't necessary for abuse. just fill the cache before going. they have done similar from JavaScript. Some that harm it: - Even speculative execution obeys access restrictions, so SMEP, SMAP, marking memory NX will prevent execution. - Instructions like 'lfence' stop speculative execution. - Intel and AMD have pushed microcode updates that introduce instructions, for Intel they are 'IBPB' and 'IBRS'. - ARM has 'BPIALL' to invalidate the branch target to stop branch predictor poisoning - Retpoline, stuff_RSB etc. to modify jumps to be less likely to jump into user-controlled code. People seemed to occasionally mentioned that 'as many as 100 instructions will be executed speculatively', so that is how far we are talking. Own thoughts: - Variant 1 seems possible to avoid with low cost. It will likely result in an error somewhere along the line, which is detectable. Flushing the entire cache on userret will make it hard to exploit. Do all bound checks failing result in an easily noticed error? - Variant 2 however is harder without custom instructions. Those may rely on a CPU being new enough to receive microcode updates, and them being applied. - I'm not sure how easy it is to find a good enough gadget without something like eBPF, but the mere presence of the code in memory was a risk. - Linux could've marked eBPF non-executable when it is unused, so its presence in memory does not pose risk. Discuss.
/dev/ksyms permissions
This leaks information that unprivileged user probably has no reason to own: > cat /dev/ksyms > ksyms > readelf -a ksyms |wc -l 47594 Any strong reason not to apply the following? Presumably it will have benefits for GENERIC_KASLR, or people with Intel CPUs :-) Index: MAKEDEV.tmpl === RCS file: /cvsroot/src/etc/MAKEDEV.tmpl,v retrieving revision 1.189 diff -u -r1.189 MAKEDEV.tmpl --- MAKEDEV.tmpl9 Jan 2018 03:31:14 - 1.189 +++ MAKEDEV.tmpl17 Jan 2018 15:19:04 - @@ -933,7 +933,7 @@ mkdev fullc %mem_chr% 11 666 mkdev zeroc %mem_chr% 12 666 mkdev klogc %log_chr% 0 600 - mkdev ksyms c %ksyms_chr% 0 444 + mkdev ksyms c %ksyms_chr% 0 400 mkdev random c %rnd_chr% 0 444 mkdev urandom c %rnd_chr% 1 644 if ! $fdesc_mounted; then
uvm page coloring for cache aliasing
Hi folks,
as I understand, a reason to have page coloring is extra broken MIPS
hardware which has cache aliasing issues unless a large page size
is used. picking the same color avoids aliasing.
now, looking at uvm_pagealloc_pgfl:
do {
/* trying to find pages in color.. */
/* goto success */
color = (color + 1) & uvmexp.colormask;
} while (color != trycolor);
which means that if we fail to find a page in the requested color, we'll
try another color. I think this might end up inducing cache aliasing
issues, and we should instead fail for this case.
thoughts?
Re: parallel (free) pagequeue
Summarising our IRC discussion: "someone" (aka joerg): hashing on paddrs is probably subpar, it's as much work but without balancing. the free pagequeue is a good first goal, and contention on it leads to contention on the non-free pagequeue too. frustrated we have per-CPU and global free page queues, but a global lock. we are lacking a stealing mechanism for real per-CPU. current: global and per-CPU free lists. global lock. idea #1: small local unlocked array, large local locked array, no global. when grabbing a free page: try local unlocked -> if failed, refill from local locked, retry -> if failed, refill (both locals, unlocked and locked) from non-local locked, retry when putting: Put in local unlocked -> local unlocked filled up, put some of our local unlocked in local locked. maybe written a bit weird but this is because the code is written with 'retry' now. - need to continue handling page colors. - need to pin to cpu to avoid being migrated halfway. - benchmark values selected (maybe use high/lo water marks, how many to steal / put) - Need to think more about VM_NFREELIST > 1 and uvm physseg idea #2: one local storage, xcall to steal pages (probably more expensive but it came up). Existing users of uvm_fpageqlock: - uvm_pagealloc_strat: get - uvm_pagefree: put ?? - uvm_pglistalloc_contig: get - uvm_pglistalloc_simple: get - uvm_pglistfree: put Alternate users which must be adapted once it's not one lock: - mtsleep for uvm_pagedaemon, pageout sleepers - uvm_pageout_start: synchronizes access to uvmexp.paging - uvm_pageidlezero: start with local (do others?) - uvm_page_recolor: called from some MD code at CPU spinup to distribute different colors, seems almost immediate to switch this to use local lock though it touches the global list for some reason. riastradh: vmobjlock is heavily contended (for e.g. libc.so), and uvm_pagelookup can be made into a pserialized radix tree. background: this is a flame graph** during very heavy build.sh, with minimal other activity: http://coypu.sdf.org/buildsh.svg ** https://github.com/brendangregg/FlameGraph
parallel pagequeue
hi folks. I wonder why we are not using a hashed lock for uvm_pageqlock. (lock only some of the pages for most accesses). but someone called it a 'brute force' method. I can't think of a more sophisticated or clever thing to do. ideas?
Removing an entry from struct emul
Hi, COMPAT_IRIX needed e_fault, an alternative implementation of uvm_fault. But it's been removed. can I remove e_fault from the struct, or would this break compat too hard? Its sole use is a check in mips/trap.c. I would like to remove this, too.
Re: ext2fs superblock updates
On Thu, Nov 16, 2017 at 09:54:44AM -0500, Mouse wrote: > They are generated by _newfs_ and left untouched thereafter. Interesting, thanks. what's so useful about the superblock at newfs time? is that for disaster recovery when half my drive is gone and I might be able to salvage something from a cylinder?
ext2fs superblock updates
Hi folks.
>From the looks of it, the ext2fs code only updates the primary
superblock:
/*
* Write a superblock and associated information back to disk.
*/
int
ext2fs_sbupdate(struct ufsmount *mp, int waitfor)
{
struct m_ext2fs *fs = mp->um_e2fs;
struct buf *bp;
int error = 0;
bp = getblk(mp->um_devvp, SBLOCK, SBSIZE, 0, 0);
e2fs_sbsave(>e2fs, (struct ext2fs*)bp->b_data);
if (waitfor == MNT_WAIT)
error = bwrite(bp);
else
bawrite(bp);
return error;
}
I'm under the impression that the secondary ones exist as
backups and are meant to be usable.
Is this wrong or am I misunderstanding things?
Thanks.
Re: intel sgx support
I'm not sure if the licensing is needed also to use it on netbsd, or just for windows usage where intel also functions as a certificate authority.
max open files
Hi, this number is way too easy to hit just linking things in pkgsrc. can we raise it? things fail hard when it is hit. ive seen people say 'when your build dies, restart it with MAKE_JOBS=1 so it doesn't link in parallel'.
callout_stop; callout_destroy
Hi, callout(9) says: callout_destroy() destroys the callout, preventing further use. ... The callout should be stopped before callout_destroy() is called by calling callout_halt(). Note that callout_stop() shouldn't be used for this purpose. Some users use callout_stop: ./dev/usb/if_run.c Also, some code does this: ./netbt/hci_link.c: callout_stop(>hl_expire); ./netbt/hci_link.c- if (callout_invoking(>hl_expire)) ./netbt/hci_link.c- return; ./netbt/hci_link.c- ./netbt/hci_link.c- callout_destroy(>hl_expire); I am not sure this is wrong. Other code seems odd, e.g. agr does: agrtimer_stop(sc); (callout_stop) (*sc->sc_iftop->iftop_dtor)(sc); carp: 887 if_detach(ifp); (carpdetach -> callout_stop) 888 callout_destroy(>sc_ad_tmo); So, this is common and non-obvious. (Maybe not a big deal with few things being MPSAFE?) - Can I blindly change run(4) to callout_halt? - If it's a big deal, maybe add a flag CALLOUT_UNHALTED* remove on _halt, and assert it's removed on _destroy? * with better name
Re: how to tell if a process is 64-bit
At the risk of making people angry, this answer works for linux and netbsd: $ file -L /proc/self/exe /proc/self/exe: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 8.99.2, not stripped
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 06:02:57PM +, Taylor R Campbell wrote: > % cd www/opera && bmake package > ERROR: This package has set PKG_FAIL_REASON: > ERROR: opera-12.16 has an unacceptable license condition: > ERROR: opera-1200-license > ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding > ERROR: ACCEPTABLE_LICENSES+= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding > ERROR: ACCEPTABLE_LICENSES= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. > ERROR: The following command will show you the license text: > ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license Fair enough, I set SKIP_LICENSE_CHECK=yes always for vim.
rwlock
Hi, does rwlock RW_WRITER prevent new readers? thanks
Re: kpreempt_disable and lwp migration
On Sun, Jun 18, 2017 at 11:19:59AM +0200, Martin Husemann wrote: > Isn't the idea of blocking with preemption enabled bogus? > > So instead of disallowing migration with preemption disabled, KASSERT > in all blocking primitives that preemption is enabled and fix the fallout > at the call sites? Is it now safe to use blocking functions under kpreempt_disable()? What about the single processor case?
kpreempt_disable and lwp migration
Hello tech-kern,
It seems that kpreempt_disable() does not prevent a lwp from
migrating. The assumption that it does is in some places in
NetBSD.
This came up as I am using a non-MPSAFE filesystem (LFS), and had
panics in x86 pmap's pmap_extract, which states it makes this assumption
in a comment:
kpreempt_disable();
ci = l->l_cpu;
if (__predict_true(!ci->ci_want_pmapload && ci->ci_pmap == pmap) ||
pmap == pmap_kernel()) {
/*
* no need to lock, because it's pmap_kernel() or our
* own pmap and is active. if a user pmap, the caller
* will hold the vm_map write/read locked and so prevent
* entries from disappearing while we are here. ptps
* can disappear via pmap_remove() and pmap_protect(),
* but they are called with the vm_map write locked.
My personal opinion is that allowing lwp migration with preemption
explicitly disabled is a headache for reasoning about races and
that we should consider disallowing this.
Most notably, using curcpu() is a headache.
I'm not sure how this affects other archs which don't allow kernel
preemption.
I think the following diff will do it, thoughts?
Thanks.
Index: kern_cpu.c
===
RCS file: /cvsroot/src/sys/kern/kern_cpu.c,v
retrieving revision 1.71
diff -u -r1.71 kern_cpu.c
--- kern_cpu.c 29 Aug 2015 12:24:00 - 1.71
+++ kern_cpu.c 17 Jun 2017 18:15:18 -
@@ -374,7 +374,8 @@
struct cpu_info *mci;
lwp_lock(l);
- if (l->l_cpu != ci || (l->l_pflag & (LP_BOUND | LP_INTR))) {
+ if (l->l_cpu != ci || (l->l_pflag & (LP_BOUND | LP_INTR)) ||
+ l->l_nopreempt) {
lwp_unlock(l);
continue;
}
Re: ddb extra lacking on mips
Martin mentioned it's probably because the kernel is loaded by PMON (firmware bootloader which speaks ELF) which might be passing the symbols differently or not at all. Adding makeoptions COPY_SYMTAB=1 # size for embedded symbol table seemed to do the trick, I can even use 'bt' now! :)
Re: New diagnostic routine - mutex_ownable()
On Sun, Apr 30, 2017 at 08:49:04AM +0800, Paul Goyette wrote:
> While working on getting the localcount(9) stuff whipped into shape, I ran
> across a situation where it is desirable to ensure that the current
> process/lwp does not already own a mutex.
>
> We cannot use !mutex_owned() since that doesn't return the desired result
> for a spin mutex, so I'm proposing to add a new routine called
> mutex_ownable(). This does nothing in normal kernels, but for LOCKDEBUG
> kernels it does a mutex_enter() followed immediately by mutex_exit(). If the
> current process already owns the mutex, the system will panic with a
> "locking against myself" error; otherwise mutex_ownable() just returns 1,
> enabling its use as
>
> KASSERT(mutex_ownable(mtx));
>
> Diffs are attached (including man-page and sets-list updates).
>
> Comments? Any reason why this cannot be committed?
I have an alternate proposal for the same purpose, but not much of a
suggestion for yours.
I find it weird to have two names which kinda mean the same thing but
also don't, and it's not immediate what the difference is, but not sure
if I can come up with better names.
I feel like we mostly care about adaptive mutexes, how about this
alternate suggestion?
mutex_adaptive_owned(kmutex_t * mtx)
{
if (mtx == NULL)
return 0;
KASSERT(MUTEX_ADAPTIVE_P(mtx));
return MUTEX_OWNER(mtx->mtx_owner) == (uintptr_t)curlwp;
}
Re: Power-cycle a usb port
On Mon, Apr 17, 2017 at 12:40:58AM +, Emmanuel Dreyfus wrote: > On Mon, Apr 17, 2017 at 12:01:38AM +0300, Jukka Marin wrote: > > I know that there exists hardware that can not control the USB port power > > supply. At least in the non-laptop world. > > In the meantime, I found this that claims to work from userland > https://github.com/codazoda/hub-ctrl.c > pkgsrc/devel/libusb :-)
Kernel party trick
Have YOU ever wanted to quickly analyze locking on a long function? well, wait no longer! I have this function as a script: $ cat ~/bin/fun #!/bin/sh awk "/^$@/,/^}/" * Example usage: $ fun lfs_truncate |grep -e mutex -e PUTPAGES mutex_enter(ovp->v_interlock); VOP_PUTPAGES(ovp, mutex_enter(_lock); mutex_exit(_lock); mutex_enter(ovp->v_interlock); error = VOP_PUTPAGES(ovp, round_page(length), mutex_enter(_lock); mutex_exit(_lock); Pretty quick sanity check for a 412 line function!
Workqueues on filesystems
Hi, I'd like to tackle LFS issues. I've been running it as my root filesystem to get some real world testing, and it often wedges, and this with heavy use of KERNEL_LOCK (it's not marked MPSAFE). I'm still getting to know it, and not there yet. I don't feel comfortable with how it has its own implementation of serialization etc, and would like to change it to use existing APIs where they fit. Playing with networking I used workqueue(9) which I think is perfect for e.g. LFS writer daemon, but its use is currently limited to networking code deferring work from interrupt handlers, that was the original intention of it. Is there a reason I shouldn't use it for LFS? Thanks.
Re: PAX mprotect and JIT
On Sun, Feb 26, 2017 at 03:27:05PM +0100, Kamil Rytarowski wrote: > On 26.02.2017 15:05, co...@sdf.org wrote: > > On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: > >> Can we have something like MAP_NOMPROTECT? Something like it would be > >> used to mmap(2) RWX region: > >> > >> void *mapping = mmap(NULL, rounded_size, PROT_READ | PROT_WRITE | > >> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_NOMPROTECT, -1, 0); > >> > >> Are doubled mappings more secure than this? > >> > > > > what pax mprotect does is silently turn RWX mapping to RW. > > > > What's the [security] difference between fooling and disabling mprotect > for a memory region? > > Is there a room to add this nomprotect allocator in libutil(3) to make > it convenient to reuse out of libffi? > Just disable it if you want RWX mappings. I don't see the problem.
Re: PAX mprotect and JIT
On Sat, Feb 25, 2017 at 10:35:27PM +0100, Joerg Sonnenberger wrote: > the answer can't be > "disable PAX mprotect on bin/python*" We could theoretically have python-wx-2.7, infra-wise it's not too hard, just terrible.
Re: PAX mprotect and JIT
On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: > Can we have something like MAP_NOMPROTECT? Something like it would be > used to mmap(2) RWX region: > > void *mapping = mmap(NULL, rounded_size, PROT_READ | PROT_WRITE | > PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_NOMPROTECT, -1, 0); > > Are doubled mappings more secure than this? > what pax mprotect does is silently turn RWX mapping to RW.
removing npx man page
I've been told to post it here. please cc me for replies. thanks. npx(4) referred to 387 support for x86 at some point. it's not really a driver any more. we don't attach npx at acpi, etc. moreover, all of the code related to it was renamed, so you will be hard-pressed to find any references to 'npx' anywhere. This patch removes it and all references to it: http://coypu.sdf.org/npx4-remove I intend to commit it in a few days, unless anyone objects.
Re: UVM and the NULL page
On Tue, Dec 27, 2016 at 03:26:04PM +, David Holland wrote: > Userspace memory shouldn't have supervisor execute permission anyway, > although I suppose x86 can't represent that. > Not all x86, but newer CPUs have SMEP/SMAP which do that.
Re: UVM and the NULL page
This wine argument is mostly hypothetical. It can run plenty of programs with the disable in place. I know because I've used it since the change. See the following: http://web.archive.org/web/20150324113601/http://wiki.winehq.org/PreloaderPageZeroProblem On Mon, Dec 26, 2016 at 09:22:29PM +, David Laight wrote: > ISTR that wine is actually mapping 'everywhere' in order to ensure > the addresses it needs later can be made available by unmapping > specific ranges.
D_MPSAFE drivers
Hi! Poking around I noticed KERNEL_LOCK is occasionally grabbed by cdev_* for noticeable periods of time. Looking at the code, it grabs DEV_LOCK which is effectively KERNEL_LOCK if the driver is not declared MPSAFE. It appears that many "big name" drivers (wd, nvme) do not have d_flags D_MPSAFE, unless I am reading things wrong.
Re: Audio - In kernel audio mixing
On Fri, Nov 25, 2016 at 08:30:51AM +1100, Nathanial Sloss wrote: > What is your underlying audio driver, AFAICT it works with hdaudio, uaudio > and Raspberry Pi vcaudio. > I've got multiple possible outputs, but only using one. one from a graphics card (for HDMI), and some creative labs with too many output ports (that don't work - I didn't make the best purchase decisions :-)). both are hdaudio. perhaps that plays a role. selecting only one output port for the creative labs thing did not help, though. > Yes this is known ethier the sum of the streams would be louder whch may lead > to clipping or the streams volume would have to be divided by the number or > streams so that the resultant sum is no greater than the set master volume. > Another way to work around this problem is to have custom addition that saturates to the max values, I haven't tried it though. > Is this with flash player or html5 multimedia content. For me multiple > instances of flash player work. > It's HTML5 - I guess it may be a firefox oddity. It does run mostly one process now. > > - audioctl -a seems to still say play.rate=8000 > > In the diff for audioctl you would have to supply -p to audioctl to > obtain the settings for a particular stream i.e audioctl -p -a. > > audioctl -a would otherwize open a new stream and give parameters on that > stream. audioctl -d /dev/sound is the exception where by you'll get changed > parameters as of the last process or audioctl on /dev/sound. > .. > Could audioctl be killed or did you require a restart? > It could not be killed. I was using old audioctl and just updated kernel. I think I can reproduce it with running `while true; do audioctl -a; done` while playing two streams. Thanks for working on this, I look forward to it! :)
Re: Audio - In kernel audio mixing
To clarify, I don't consider most of these to be problems. The only things that are problematic are the underruns and audioctl hanging.
Re: Audio - In kernel audio mixing
On Wed, Nov 23, 2016 at 12:22:05PM +1100, Nathanial Sloss wrote: > Hi, > > I've made changes to in kernel audio mixing and made them available at > ftp.NetBSD.org/pub/NetBSD/misc/nat/nextaudio5-kern.gz > > This patch includes only changes to audio the synthesized spkr device will be > in a follow up email. > > New in this version a new audio ioctl to select your audio channel based on > process id of it's controlling process, changes to audioctl(1) to demonstrate > this. > > /dev/sound keeps setting of the last process that changed parameters and it > is > possible to use audioctl(1) on /dev/sound to set parameters before opening > /dev/sound. > > Simultaneous recording channels with independent volume / recording paraeter > control. > > Also a sysctl to set the common format use full for when hw available > precision and or channels are greater than 2ch 16 bit 44100 Hz. > > Please take a look, if there are no objections I would like to commit this in > two weeks. > > Best regards, > > Nat I've mostly tried to use it, not review the code.. Please include the definition of D_MCLOSE in the diff, otherwise it does not compile. I've tried to use it with firefox (PKG_DEFAULT_OPTIONS="-pulseaudio oss") and mpv. Both seem to have problems: - audio seems to be underrunning maybe? even when playing a single stream. It's periodically broken. I've tried to adjust buffer size but to no avail. - playing multiple streams lowers volume - firefox is unable to play audio from multiple tabs, I don't know what is wrong with it. changing to output to /dev/sound did not help. If you'd like to poke around, note it's easier to delete work/.build_done to retry. - audioctl -a seems to still say play.rate=8000 - I ended up with `audioctl -a` hanging, with this trace: sleepq_block() at sleepq_block+0x97 cv_wait_sig() at cv_wait_sig+0xfe audio_drain() at audio_drain+0xfc audio_close() at audio_close+0x26b audioclose() at audioclose+0xe7 spec_close() at spec_close+0x11a VOP_CLOSE() at VOP_CLOSE+0x33 vn_close() at vn_close+0x36 closef() at closef+0x54 fd_free() at fd_free+0xcb exit1() at exit1+0x11d sys_exit() at sys_exit+0x3d syscall() at syscall+0x15b --- syscall (number 1) --- 734e91139efa:
Re: netbsd32 syscalls sy_flags
On Fri, Oct 28, 2016 at 11:48:19PM +, Christos Zoulas wrote: > > cvs update, I fixed it. > > christos Hurray, it works! I can continue building Firefox, which has hand-written o32 code. Thanks.
netbsd32 syscalls sy_flags
Hi, I've been trying to run code meant for MIPS o32 ABI on MIPS n32. Background: Both of them run under netbsd32 compat (when running mips64). MIPS o32 ABI calling convention says there are 4 registers meant for passing arguments, the rest go onto the stack. Also, o32 has 32bit registers. So a syscall with 64bit parameters has to be split up to using two arguments/stack slots. The code within sys/arch/mips/mips/syscall.c expects to know which arguments are 64bit through callp->sy_flags for its own logic. However, when making an lseek call, it seems to have sy_flags=0, so it treats all the arguments as being 32bit, and grabs the upper half of the offset as "whence" (usually zero), which is broken. (The relevant code is in lines 205 onwards... It tells a given argument is 64bit using: 213 unsigned int arg64mask = SYCALL_ARG_64_MASK(callp); Where: 154 #define SYCALL_ARG_64_MASK(sy) (((sy)->sy_flags >> 17) & 0xff) (From sys/sys/systm.h) >From trying to put dummy code in lib/libc/sys/lseek.c, GCC seems to think that the call does have a 64bit argument in it, and splits it up. But the flags are still zero, and most calls in sys/compat/netbsd32/netbsd32_syscalls.c doesn't seem to have flags specified for it. Is this a case of the flags being wrong, or GCC being misled somehow?
hw.acpi.sleep.vbios
This value cannot stay 1. It should be either 0 (drmkms) or 2. I find it extremely hard to imagine there's any machine that can suspend & resume properly with the value of 1 (feel free to tell me about your 15 year old hardware, though). Pick one, commit. attached diff for 0. diff --git a/sys/arch/x86/acpi/acpi_wakeup.c b/sys/arch/x86/acpi/acpi_wakeup.c index 191c079..7b124dc 100644 --- a/sys/arch/x86/acpi/acpi_wakeup.c +++ b/sys/arch/x86/acpi/acpi_wakeup.c @@ -111,7 +111,7 @@ __KERNEL_RCSID(0, "$NetBSD: acpi_wakeup.c,v 1.41 2016/07/27 13:04:28 maxv Exp $" static paddr_t acpi_wakeup_paddr = 3 * PAGE_SIZE; static vaddr_t acpi_wakeup_vaddr; -int acpi_md_vbios_reset = 1; /* Referenced by dev/pci/vga_pci.c */ +int acpi_md_vbios_reset = 0; /* Referenced by dev/pci/vga_pci.c */ int acpi_md_vesa_modenum = 0; /* Referenced by arch/x86/x86/genfb_machdep.c */ static int acpi_md_beep_on_reset = 0;
Re: Generic crc32c support in kernel?
On Sat, Aug 13, 2016 at 05:17:17PM -0400, Thor Lancelot Simon wrote: > On Fri, Aug 12, 2016 at 07:37:50PM +, paul_kon...@dell.com wrote: > > > > It seems sensible. It could be done by a common CRC routine that takes a > > table pointer argument, then the two specific routines are just wrappers. > > > > It would be really nice to not pay the function call overhead on modern > Intel CPUs where this is a single instruction. Not sure this is possible > in a generic kernel without resorting to binary patch, but we do that in > other places... > > Thor Not just Intel, but also ARMv8, optionally.
Re: gpio and suspend on amd64
jakllsch disabled gpio at ichlpcib by default with r1.51 of sys/arch/x86/pci/ichlpcib.c it is probably the best idea - users typically have no business messing with it normally, and you can re-enable it by jumping through a few hoops. thanks!
gpio and suspend on amd64
I have been trying to get suspend working well on my laptop (a very
plain Dell Inspiron n4030), and gpio(4) is the only thing standing in
my way :-)
it's currently enabled by default for GENERIC on amd64:
gpio0 at ichlpcib0: 64 pins
the behaviour is that on first resume, it'll work fine, but second one
crashes (just powers down).
currently, on resume, we restore the previous gpio values.
by disabling this (with the attached diff), I am able to suspend/resume
repeatedly, or by disabling gpio with userconf.
apparently, in amd64 systems, it's probably bound to random undocumented
system things, and messing with it is a bad idea.
I haven't played with many embedded systems, but I wouldn't be surprised
if some non-amd64 machines do the same.
could we do something about this problem?
thanks.
Index: gpio/gpio.c
===
RCS file: /cvsroot/src/sys/dev/gpio/gpio.c,v
retrieving revision 1.58
diff -u -r1.58 gpio.c
--- gpio/gpio.c 11 May 2016 18:33:40 - 1.58
+++ gpio/gpio.c 5 Aug 2016 18:13:45 -
@@ -136,13 +136,14 @@
static bool
gpio_resume(device_t self, const pmf_qual_t *qual)
{
+#if 0
struct gpio_softc *sc = device_private(self);
int pin;
-
for (pin = 0; pin < sc->sc_npins; pin++) {
gpiobus_pin_ctl(sc->sc_gc, pin, sc->sc_pins[pin].pin_flags);
gpiobus_pin_write(sc->sc_gc, pin, sc->sc_pins[pin].pin_state);
}
+#endif
return true;
}
Weird case in vfs_bio.c bwrite
Hi, I've been reading the vfs code for no reason. in vfs_bio.c:802 we have: vp = bp->b_vp; then we have a test if it's NULL, but strangely, we do not leave the function, we continue with it. there is even a call in vfs_bio.c:873 VOP_STRATEGY(vp, bp); which will still happen for the vp=NULL case, if it is possible. what is this case? Thanks.
Re: lfs_lock
On Thu, Jul 14, 2016 at 08:51:45PM +, Michael van Elst wrote: > dholland-t...@netbsd.org (David Holland) writes: > > >Is there any reason lfs is using a global (rather than per-volume) > >lock? ad@ seems to have introduced it but as usual there's little in > >the way of reasoning or explanation. > > After changing lfs to use the new locking primitives it was utterly > broken. So don't try to interpret much into the global lock. It's > just a slightly more local version of the big kernel lock. > Hmm, some users of KERNEL_LOCK still remain. I think using both may be causing problems. KERNEL_LOCK forces lfs_lock, but not all KERNEL_LOCK users check for lfs_lock. The one that does (lfs_cluster_aiodone), does it within KERNEL_LOCK, not outside.
Re: Debugging an early kernel problem (more MIPS trouble)
I've resorted to taking advantage of the fact I'm running an emulator and made it print a message to stderr every time it changes the interrupt level. Which, conveniently, didn't boot as well (although it got stuck a lot later). However, the problem was found: Seems like all the interrupt code is fine, except that the initial value in STATUS is wrong for MIPS1, as is the check - it fits MIPS3 or later. Thanks for the help!
Re: Debugging an early kernel problem (more MIPS trouble)
On Tue, Jul 05, 2016 at 03:52:21AM +, David Holland wrote: > On Tue, Jul 05, 2016 at 02:00:35AM +, co...@sdf.org wrote: > > After failing to fix enough broken things with the interrupt code by > > reading it, I wanted to try adding some code to let me know when the > > interrupt level was changed. > > > > I've attempted to add a couple of PRINTFs from , but it > > mostly fails to boot with the addition of this code. > > Where have you put it? (Early in kernel startup, for example, there > are many things you can't do yet.) > > > gxemul gives these warnings: > > [ warning: LOW reference: vaddr=0x, exception TLBL, pc=0x > <(no symbol)> ] > > [ warning: LOW reference: vaddr=0x, 00 <(no symbol)> ] > > [ warning: LOW reference: vaddr=0x, exception TLBL, pc=0x > <(no symbol)> ] > > [ warning: LOW reference: vaddr=0x, exception TLBL, pc=0x > <(no symbol)> ] > > > > I'm guessing it jumped somewhere it shouldn't have. > > Yeah, jumped to null. I suspect if you patch gxemul to also print the > value of $ra (register 31) it will be somewhat more enlightening. > > -- > David A. Holland > dholl...@netbsd.org Just putting one in splraise in spl.S will do it, many of the places where I'd want to print a message are problematic. Even attempting to do things the hard way and trying to save to an arbitrary point in memory is not working out, it won't boot. What does work? Thanks.
Re: Debugging an early kernel problem (more MIPS trouble)
I was under the impression I am seeing init being forked by the kernel (which I was told is lwp0), but that is not the case. This is also not the first fork1 call. So I am back to looking at machine-dependent code disabling interrupts and not enabling them back.
Debugging an early kernel problem (more MIPS trouble)
Hi, I've been trying to understand why with DIAGNOSTIC, a pmax kernel panics at init, with the following: init path (default /sbin/init): init: copying out path `/sbin/init' 11 pid 1(init): ABI set to O32 (e_flags=0x1007) panic: kernel diagnostic assertion "pcb2->pcb_context.val[_L_SR] & MIPS_SR_INT_IE" failed: file "/usr/cvs-src/src/sys/arch/mips/mips/vm_machdep.c", line 150 2.1 0x80034 cpu0: Begin traceback... pid -1020797712 not found cpu0: End traceback... kernel: breakpoint trap Stopped in pid 2.1 (sh) at netbsd:cpu_Debugger+0x4:jr ra bdslot: nop db> bt 0xc327dd18: cpu_Debugger+4 (0,0,0,804e2f00) ra 80314c70 sz 0 0xc327dd18: vpanic+1a4 (0,0,0,804e2f00) ra 80413be0 sz 48 0xc327dd48: kern_assert+40 (0,8043b04c,8043fd7c,8043fdac) ra 800527e8 sz 32 0xc327dd68: cpu_lwp_fork+218 (0,8043b04c,8043fd7c,8043fdac) ra 802837b0 sz 64 0xc327dda8: uvm_lwp_fork+28 (0,8043b04c,8043fd7c,8043fdac) ra 802c78d4 sz 32 0xc327ddc8: lwp_create+2d8 (0,8043b04c,8043fd7c,8043fdac) ra 802bef5c sz 64 0xc327de08: fork1+44c (0,8043b04c,14,8043fdac) ra 802bf6ac sz 144 0xc327de98: sys_fork+2c (0,8043b04c,c327df68,8043fdac) ra 8004ec80 sz 48 0xc327dec8: syscall+260 (0,8043b04c,c327df68,8043fdac) ra 800415b8 sz 128 0xc327df48: mips1_systemcall+ec (0,8043b04c,c327df68,8043fdac) ra 7de726e0 sz 0 PC 0x7de726e0: not in kernel space 0xc327df48: 0+7de726e0 (0,8043b04c,c327df68,8043fdac) ra 0 sz 0 User-level: pid 2.1 The assert is testing if the STATUS register in the newly forked pcb2 has interrupts enabled (first bit is 1). I've also attempted to check the parent of this process, and it also triggers the assert. if I check in init_start, lwp0 has interrupts enabled and everything is nicely initialized. So my trouble is: why does init's PCB seem to differ from that of lwp0? what is lwp0? (I thought it's init?) Any other suggestions for debugging? Thanks.
Re: Patch to make PCI_CONF_MODE work (it might not?)
Feel free to ignore, it does work as is! Sorry for the noise
Re: SOSEND_LOAN problems in MIPS
Replying to myself on tech-kern for the sake of completeness, in case anyone has similar issues. For the failure of `cat hugefile.gz | gunzip -` I must use both PIPE_SOCKETPAIR and SOSEND_LOAN (default on) I've built a kernel with UVMHIST and DEBUG (and fixed/hacked some of the fallout) and ran tests which reliably trigger a panic. Attached is the output. extra messages originate in GXemul, the emulator I am using. MIPS panic with DEBUG and UVMHIST (without options SOSEND_NO_LOAN or PIPE_SOCKETPAIR) running `gxemul -e 3max -d ~/test2.img` # cd /usr/tests/dev/raidframe/ # atf-run Content-Type: application/X-atf-tps; version="3" info: atf.version, Automated Testing Framework 0.20 (atf-0.20) info: tests.root, /usr/tests/dev/raidframe info: time.start, Tue Jun 21 00:08:16 UTC 2016 info: uname.sysname, NetBSD info: uname.nodename, info: uname.release, 7.99.31 info: uname.version, NetBSD 7.99.31 (GENERIC) #0: Tue Jun 21 00:39:23 IDT 2016 f...@net.home:/usr/obj.pmax/sys/arch/pmax/compile/GENERIC info: uname.machine, pmax info: env, ENV=/root/.shrc info: env, BLOCKSIZE=1k info: env, PWD=/usr/tests/dev/raidframe info: env, HOME=/root info: env, PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/pkg/sbin:/usr/pkg/bin:/usr/X11R7/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin info: env, HOST= info: env, TERM=vt220 info: env, OLDPWD=/root info: env, USER=root info: env, LOGNAME=root info: env, SHELL=/bin/sh tps-count: 1 tp-start: 1466467701.417968, t_raid, 6 tc-start: 1466467701.417968, raid1_comp0fail [ WARNING! SPECIAL3 opcode used, but the R3000 processor does not implement such instructions. Only printing this warning once. ] tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev -lrumpdev_disk -lrumpdev_raidframe -d key=/disk0,hostpath=disk0.img,size=32m -d key=/disk1,hostpath=disk1.img,size=32m unix://sock ] tc-so:Executing command [ rump.raidctl -C raid.conf raid0 ] tc-so:Executing command [ rump.raidctl -I 12345 raid0 ] tc-so:Executing command [ rump.raidctl -iv raid0 ] DIV by zero tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev -lrumpdev_disk -lrumpdev_raidframe -d key=/disk0,hostpath=disk0.img,size=32m -d key=/disk1,hostpath=disk1.img,size=32m unix://sock ] tc-so:Executing command [ rump.raidctl -c raid.conf raid0 ] tc-end: 1466467719.488281, raid1_comp0fail, passed tc-start: 1466467719.535156, raid1_compfail tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev -lrumpdev_disk -lrumpdev_raidframe -d key=/disk0,hostpath=disk0.img,size=32m -d key=/disk1,hostpath=disk1.img,size=32m unix://sock ] tc-so:Executing command [ rump.raidctl -C raid.conf raid0 ] tc-so:Executing command [ rump.raidctl -I 12345 raid0 ] tc-so:Executing command [ rump.raidctl -iv raid0 ] DIV by zero tc-so:Executing command [ dd if=/usr/tests/dev/raidframe/t_raid of=testfile count=4 ] tc-so:Executing command [ /bin/sh -c dd if=testfile | rump.dd of=/dev/rraid0c conv=sync ] tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev -lrumpdev_disk -lrumpdev_raidframe -d key=/disk0,hostpath=disk0.img,size=32m -d key=/disk1,hostpath=disk1.img,size=32m unix://sock ] tc-so:Executing command [ rump.raidctl -c raid.conf raid0 ] tc-so:Executing command [ rump.dd if=/dev/rraid0c count=4 ] tc-end: 1466467737.785156, raid1_compfail, passed tc-start: 1466467737.828125, raid1_normal tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev -lrumpdev_disk -lrumpdev_raidframe -d key=/disk0,hostpath=disk0.img,size=32m -d key=/disk1,hostpath=disk1.img,size=32m unix://sock ] tc-so:Executing command [ rump.raidctl -C raid.conf raid0 ] tc-so:Executing command [ rump.raidctl -I 12345 raid0 ] tc-so:Executing command [ rump.raidctl -iv raid0 ] DIV by zero tc-so:Executing command [ dd if=/usr/tests/dev/raidframe/t_raid of=testfile count=4 ] tc-so:Executing command [ /bin/sh -c dd if=testfile | rump.dd of=/dev/rraid0c conv=sync ] tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev -lrumpdev_disk -lrumpdev_raidframe -d key=/disk0,hostpath=disk0.img,size=32m -d key=/disk1,hostpath=disk1.img,size=32m unix://sock ] tc-so:Executing command [ rump.raidctl -c raid.conf raid0 ] tc-so:Executing command [ rump.dd if=/dev/rraid0c count=4 ] tc-end: 1466467753.109375, raid1_normal, passed tc-start: 1466467753.187500, raid5_compfail tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev -lrumpdev_disk -lrumpdev_raidframe -d key=/disk0,hostpath=disk0.img,size=32m -d key=/disk1,hostpath=disk1.img,size=32m -d key=/disk2,hostpath=disk2.img,size=32m unix://sock ] tc-so:Executing command [ rump.raidctl -C raid.conf raid0 ] tc-so:Executing command [ rump.raidctl -I 12345 raid0 ] tc-so:Executing command [ rump.raidctl -iv raid0 ] DIV by zero panic: kernel debugging assertion "asid == curcpu()->ci_pmap_asid_cur" failed: file "/usr/src/sys/arch/mips/mips/pmap_tlb.c", line 1047 tlb_hi (0xc32cb000) asid (0) != current asid (0x23) kernel: breakpoint trap Stopped in pid 1047.28 (rump_server) at netbsd:cpu_Debugger+0x4:
Re: SOSEND_LOAN problems in MIPS
On Sun, Jun 19, 2016 at 04:25:20PM +0100, Robert Swindells wrote: > > You can find what the option does using grep(1). Use the search button > on the mailing list archives to see if anyone else has had a similar > problem. > > It looks to me as if the only place that it is used is in > sys/kern/uipc_socket.c. > > The behaviour that is enabled by the option is also enabled if > MULTIPROCESSOR is true so I would guess that this code path is > followed on most NetBSD systems in use today. > > The mailing list archives suggest that some ports have had pmap bugs > in the past that were triggered if the SOSEND_NO_LOAN option wasn't > enabled. > > It could also be that as the kernel size has grown over time the > amount of free memory on a PMAX isn't large enough. How have you > configured gxemul ? > > It would probably also help to know where the file that you read > using cat was stored, was it read over NFS ? Local storage, tar x.. file works, cat file | tar x... does not. Boundary where it stops working is with file over 4K. number may be dependent on machine, so 'huge file' is suggested. It was evident when unpacking tarballs manually worked, but sysinst did not - it pipes to show progress. This is a known issue with many MIPS CPUs, including some in production. the CI20 config also has this option, likely because it was broken too. I'm pretty glad to have this failure in emulation because I can look at the emulator code. I was hoping for some help figuring out what the actual problem is, so it can be fixed, not just hacked away with a kernel option, which does work, with this option enabled I am able to install normally, run tests, etc. my recently completed atf run shows: Summary for 644 test programs: 3975 passed test cases. 201 failed test cases. 35 expected failed test cases. 102 skipped test cases. (could be a lot worse :-)) Some stuff I've been told off-list: SGI machines do not have this problem at all (tested on SGI O2, and none of the SGI machines have it enabled in their configs), so not everything is as broken (phew). Some stuff I don't yet fully understand but sharing anyway: SOSEND_LOAN prevents copying of memory contents and 'loans' it instead. We end up with: Two virtual addresses for the same physical address in TLB? Kernel virtual address mapping of same physical address does not match the rest of the virtual addresses it has? CPU notices this, throws an exception (maybe T_VCED) which we're hoping would go away if we just tell it the pages are uncached, but apparently some MIPS CPUs do not like uncached mappings. So, we must have a behaviour that the CPU is happy with, maybe take advantage of the exception received. Thanks for the responses.
SOSEND_LOAN trouble in MIPS
Hi, in emulating pmax with gxemul I ran into an issue that: cat somefile | command does not work if somefile is bigger than 4096 bytes (but does for smaller, or if I use 'command somefile' instead). using 'options SOSEND_NO_LOAN' in the kernel config 'fixes' it. what will be a good way to figure out what is wrong? also, many MIPS configs have it, would it make sense to just enable it for all the ones that don't? thanks
Re: Panic in tmpfs
On Thu, Jun 09, 2016 at 08:07:57PM -0700, Michael Plass wrote: > Does this ring a bell with anybody? The only similar panic on gnats that I > was able to > find was closed in 2011. But I've had trouble finding things in gnats before. > PR/50381 http://gnats.netbsd.org/50381 Sometimes, I use Google search with site:mail-index.netbsd.org, for better queries. This one I remembered frmo 7.0.1 release notes. Thanks!
Re: Unused functions in kernels
On Sat, Jun 04, 2016 at 01:35:16PM -0400, D'Arcy J.M. Cain wrote: > In fact, cleaning out the source seems like a more beneficial > improvement than reducing the binary. Save human resources (viewing > source) over computer resources. I can personally attest to wasting time looking at some of the functions on this list today :-)
Re: WAPBL not locking enough?
How about this change instead?
Still going over the rest of the function calls of wapbl_flush.
>From d51a64a5e9a15169949b8f1442c79060c157536d Mon Sep 17 00:00:00 2001
From: coypu <co...@sdf.org>
Date: Wed, 11 May 2016 13:08:06 +0300
Subject: [PATCH 1/2] assert wl_mtx held in wapbl_transaction_len
---
sys/kern/vfs_wapbl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sys/kern/vfs_wapbl.c b/sys/kern/vfs_wapbl.c
index e63f228..e317daf 100644
--- a/sys/kern/vfs_wapbl.c
+++ b/sys/kern/vfs_wapbl.c
@@ -2098,6 +2098,9 @@ wapbl_transaction_len(struct wapbl *wl)
sizeof(((struct wapbl_wc_blocklist *)0)->wc_blocks[0]);
KASSERT(bph > 0);
+#ifdef WAPBL_DEBUG /* XXX: get rid of this eventually */
+ KASSERT(mutex_owned(>wl_mtx));
+#endif
len = wl->wl_bcount;
len += howmany(wl->wl_bufcount, bph) * blocklen;
--
2.8.1
>From fa8f55b0373747697f81c4fedc36deb93ad2e51d Mon Sep 17 00:00:00 2001
From: coypu <co...@sdf.org>
Date: Wed, 11 May 2016 14:27:46 +0300
Subject: [PATCH 2/2] hold wl_mtx for wapbl_truncate and wl_bufcount
---
sys/kern/vfs_wapbl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/sys/kern/vfs_wapbl.c b/sys/kern/vfs_wapbl.c
index e317daf..3d2fd4c 100644
--- a/sys/kern/vfs_wapbl.c
+++ b/sys/kern/vfs_wapbl.c
@@ -1592,6 +1592,9 @@ wapbl_flush(struct wapbl *wl, int waitfor)
* file system didn't produce any blocks as a consequence of
* it, but the same does not seem to be so of wl_inohashcnt.
*/
+
+ mutex_enter(>wl_mtx); /* protect bufcount, truncate call */
+
if (wl->wl_bufcount == 0) {
goto wait_out;
}
@@ -1624,6 +1627,9 @@ wapbl_flush(struct wapbl *wl, int waitfor)
}
error = wapbl_truncate(wl, flushsize);
+
+ mutex_exit(>wl_mtx);
+
if (error)
goto out;
@@ -1753,6 +1759,7 @@ wapbl_flush(struct wapbl *wl, int waitfor)
error = wapbl_truncate(wl, wl->wl_circ_size -
wl->wl_reserved_bytes);
}
+ mutex_exit(>wl_mtx);
out:
if (error) {
--
2.8.1
