| Age | Commit message (Collapse) | Author |
|---|
|
the bugfixes in.
ok kettenis@
|
|
but our code assumes so. It's useful to have them, so create them if they
do not exist.
ok kettenis@
|
|
any current bug, it might catch issues in the future.
ok kettenis@
|
|
ok kettenis@
|
|
Tested by gkoehler@.
ok gkoehler@
|
|
fault because it does memory accesses outside of the regions it told us to
map. Try to mitigate this by installing a fault handler (using the
pcb_onfault mechanism) and bail out using longjmp(9) if we encounter a
page fault while executing an EFI runtime services call.
Since some firmware bugs result in us executing code that isn't mapped,
make kpageflttrap() handle execution faults as well as data faults.
ok guenther@
|
|
As pointed out by the RISC-V privileged spec. Sadly this is not enough
to solve all existing userland or kernel crashes seen on Unmatched (and
possibly other?) machines.
ok kettenis@
|
|
ok kettenis@
|
|
gets correct info from hw.version.
|
|
Only five legacy half-duplex hardware drivers require this function to
change between playing and recording:
i386: ess(4), gus(4), pas(4), sb(4)
luna88k: nec86(4)
If defined, it is always called early in audio_open(), so just move the
call from audio(4) to each hardware driver's open() handler.
SPKR_ON/OFF remain defined to leave driver-specific code unchanged.
Further cleanup (unchecked speaker_ctl() return values,
FWRITE -> AUMODE_PLAY -> SPKR_ON dances, etc.) can happen later.
Builds fine on i386.
OK ratchov
|
|
fork/vfork/__tfork haven't cared about the second return register.
So, stop setting retval[1] in kern_fork.c and stop setting the
second return register in the MD child_return() routines.
With the above, we have no multi-register return values on LP64,
so stop touching that register in the trapframe on those archs.
testing miod@ and aoyama@
ok miod@
|
|
ok phessler@
|
|
Guests may need these MSRs to determine the TSC frequency on AMD
families 17h and 19h.
GP fault reported by weerd@, observed on "AMD EPYC 3201 8-Core Processor"
(17-01-02). Same issue observed by Jesper Wallin on "AMD Ryzen PRO 3700U".
Tested by Jesper Wallin.
Link: https://marc.info/?l=openbsd-bugs&m=166721628323483&w=2
ok mlarkin@
|
|
This lets the MI clock interrupt code see the correct SPL.
The full splx() is skipped because the updating of the hardware interrupt
masks should not be needed here.
Prompted by and OK cheloha@
|
|
|
|
sys_execve() to return EJUSTRETURN.
setregs() is the MD routine used by sys_execve() to set up the
thread's trapframe and PCB such that, on 'return' to userspace, it
has the register values defined by the ABI and otherwise zero. It
had to set the syscall retval[] values previously because the normal
syscall return path overwrites a couple registers with the retval[]
values. By instead returning EJUSTRETURN that and some complexity
with program-counter handling on m88k and sparc64 goes away.
Also, give setregs() add a 'struct ps_strings *arginfo' argument
so powerpc, powerpc64, and sh can directly get argc/argv/envp
values for registers instead of copyin()ing the one in userspace.
Improvements from miod@ and millert@
Testing assistance miod@, kettenis@, and aoyama@
ok miod@ kettenis@
|
|
handle that such that we can see the firmware version in dmesg.
ok deraadt@, phessler@
|
|
Make drivers which do *not* adverise AUDIO_PROP_FULLDPLEX return ENXIO
in their open() if full-duplex mode was requested.
This way, sys/dev/audio.c:audio_open() will fail immediately rather than
later through the to-be-removed get_props() check.
These are all drivers which simply don't support full-duplex mode.
In device-tree based drivers like simpleaudio(4)/rkiis(4) and newer Apple
ones like aplaudio(4)/aplmca(4), this adds a new open() stub to the
low-level drivers which merely does the duplex check.
My Pinebook Pro keeps playing audio and recording silence with this diff
just like before (rkiis(4) is currently play-only):
simpleaudio0 at mainbus0
simpleaudio1 at mainbus0
audio0 at simpleaudio1
$ aucat -i song69.wav -o rec.wav
OK ratchov miod
|
|
ok deraadt@
|
|
The property bits of audio(9) are obsolete and ought to be removed
completely.
sys/dev/audio.c:audio_open() currently uses get_props() to bail out if
read *and* write was requested on a non-duplex driver.
Drivers that currently support playing but not recording need adjustment
before the API can be cleaned up.
Drivers that advertise themselves as full duplex, i.e. those that always
return AUDIO_PROP_FULLDUPLEX unconditionally in their get_props() currently
always succeed this check.
As this is the only property, losen audio_open()'s DIAGNOSTIC check and only
do the duplex check if the driver provides get_props().
This allows for simple removal of get_props() from full-duplex drivers
without adding any other code or without changing functionality.
This includes all audio drivers under sys/dev/pci/ (maestro(4) being the
only unfinished exception here).
Other drivers as well as the API change can then follow in smaller diffs.
This builds on amd64, arm64, i386, macppc and sparc64.
amd64 with azalia(4) still plays, records as well as plays and records
at the same time on my X230 as tested with
$ aucat -i play.wav [-o rec.wav]
alpha and hppa tests by miod
OK ratchov miod
|
|
vm_page_md, which allows this struct to shrink a bit.
|
|
used by cpu_fork()
ok miod@ kettenis@ mpi@ deraadt@
|
|
This prevents "luna88k_ext_int: cpu0 level 1 interrupt" message on
heavy load.
"This makes sense" miod@, tested by me.
|
|
either 32bit or 64bit. With the elimination of 32bit sparc bits
it was just a superfluous indirection of BIAS. Also, CCFSZ is gone.
ok miod@
|
|
|
|
Compute the TSC frequency on AMD family 17h and 19h CPUs using the
PStateDef MSRs.
Link 1: https://marc.info/?l=openbsd-tech&m=166394236029484&w=2
Link 2: https://marc.info/?l=openbsd-tech&m=166446065916283&w=2
Test list: https://marc.info/?l=openbsd-tech&m=166646389821326&w=2
Reviewed by kettenis@ using the AMD documents cited in the comments.
Maybe reviewed by mlarkin@? I can't remember. He seemed supportive
of the idea at least.
ok kettenis@
|
|
ok miod@ kettenis@
|
|
M2 Macbook Air with a newer device tree where aplaudio tries to allocate a
channel after apldma_attach() failed.
ok kettenis@
|
|
anyone. No need to also set d_flags to 0.
|
|
status information.
ok deraadt@
|
|
Both only used for printf calls.
OK gkoehler
|
|
A kernel with option SUSPEND now calls gosleep() if I run zzz(8),
press the power button (when machdep.pwraction=2), or close the lid
(when machdep.lidaction=1). Because gosleep() is an empty stub, the
macppc does not really suspend; it only suspends some devices and
immediately resumes.
The interrupt from the power button or the lid needs some thread
(other than systq) to call sleep_state(). Use taskq_create(9) to
create another thread.
Add a call to device_register_wakeup(). Without this call,
sleep_state() does nothing.
ok kettenis@ deraadt@
|
|
|
|
The old CPU in a macppc traps AltiVec instructions when they encounter
denormal or subnormal floats. Emulate most of them. They operate on
vectors of 4 single-precision floats. The emulations either use
scalar operations (so vmaddfp becomes 4 of fmadds) or a formula (like
vrsqrtefp's 1 / sqrt(b) = 1 / sqrt(b * 2**126) * 2**63).
I am forgetting to emulate some instructions (at least vrfin, vrfiz,
vrfip, vrfim). If I don't emulate it, it will still cause SIGFPE.
Mac OS never emulated these instructions, but set AltiVec's "non-Java"
NJ bit (which changes all subnormal floats to zero). FreeBSD also
sets NJ; NetBSD does SIGFPE; Linux emulates them. The POWER9 running
OpenBSD/powerpc64 does them in hardware (without trapping).
ok kettenis@ miod@
|
|
I can now use the power button to power off my macppcs running
OpenBSD. The new sysctls machdep.lidaction and machdep.pwraction act
like acpibtn(4), but we are missing code to suspend or hibernate a
macppc. Small kernels (bsd.rd) continue to ignore the power button.
adb(4) sends an environment interrupt when I unplug my PowerBook's AC
or close its lid. Rename PMU_INT_WAKEUP to PMU_INT_ENVIRONMENT like
other BSDs and Linux. Handle PMU_ENV_LID_CLOSED as a lid sensor and
PMU_ENV_AC_POWER by setting sysctl hw.power. Power buttons can either
use PMU_ENV_POWER_BUTTON or go through akbd(4); handle both kinds of
power buttons in the same way. Other models of macppc, with different
power buttons or lids, might not work yet. The lid sensor looks like,
$ sysctl hw.sensors
hw.sensors.adb0.indicator0=On (lid open)
kettenis@ warned against calling prsignal() from interrupt context,
and pointed me to task_add(9).
|
|
The powerpc64 part is under #if 0, so this change affects only macppc.
Simplify powerpc64's __syncicache (which had size_t len) and copy it
to macppc's syncicache (which had int len).
macppc was looping while ((l -= CACHELINESIZE) > 0). The loop would
be infinite if l became an unsigned type like size_t. It is simpler
to set size_t i = 0, do i += by, and loop while (i < len). It helps
that dcbst and icbi can add 2 registers, from + i.
|
|
struct names when the matching `32' flavour got removed.
Joint work with cheloha@, all bugs mine.
|
|
The Dell Precision T1600 has a UEFI 2.0 implementation where calling
GetTime() accesses memory that isn't covered by a runtime mapping.
And frankly UEFI 2.0 is so ancient that we don't really want to use it
anyway.
This also adds the check to the arm64 version even though UEFI versions
before 2.4 don't have arm64 support. But for now I want to keep amd64
and arm64 code as similar as possible.
ok kn@
|
|
This audio(9) struct will lose a member, but drivers init their struct quite
inconsistently, most pre-C99 style.
Use C99 style everywhere, to get rid of all annoying differences and allow
for easy member removals/additions:
- don't change current order of members
- no explicit NULL members
- no comments or blank lines
- trailing comma in last member line
GENERIC.MP builds fine with this on arm64, amd64, i386 and sparc64.
macppc and alpha build-tested by miod
OK ratchov miod
|
|
necsb(4/luna88k) is the only driver that "implements" it... through EIO.
Remove it so setfd can be removed from struct audio_hw_if.
Prodded by ratchov
OK aoyama
|
|
The only driver with a non-const audio(9) struct.
OK gnezdo
|
|
ok miod@, kn@
|
|
AUDIO_PROP_FULLDUPLEX is the only audio(9) in use, the other two died with
commit 1cf2860827c8ca659d8097d8da94a5ae5b888c53
Author: ratchov <ratchov@openbsd.org>
Date: Thu Jun 25 06:43:45 2015 +0000
Reimplement the audio driver in a simpler way, removing unused/unusable
functionality. Same API and ABI except for the removed bits and no
behaviour change for programs using libsndio. With help from armani@
and mpi@, thanks.
but remained defined and set in drivers.
and the following merely moved them when they were dead code already:
commit 9215aa3dfad387bca877a805534df6dcfe8722eb
Author: ratchov <ratchov@openbsd.org>
Date: Wed Aug 31 07:22:43 2016 +0000
Delete unused ioctls and associated macros. Move macros that are still
used internally by low-level drivers from sys/audioio.h to
dev/audio_if.h instead of deleting them.
None of this is used in base or ports; codesearch.debian.net only shows
AUDIO_PROP_{CAPTURE,PLAYBACK} in firefox-esr, mozjs and cubeb.
ratchov points out that audio_if.h and audioio.h are private interfaces
and the codesearch shows SunOS and NetBSD bits (#ifdef'd out on OpenBSD).
OK ratchov
|
|
provides allows bypassing the L2 cache by using a physical address alias.
ok miod@
|
|
IEEE 1275 specification. This should fix booting on machines that would
fail with something like:
OF_map_phys(3fe44000,8192,fed58000,-1) failed
no space for symbol table
Program terminated
Based on a diff provided by Harald Gutch (hgutch@netbsd). Also see
NetBSD PR#56829.
There were (and still are) some questions about whether this diff breaks
the blade1.5k. However the failure in question might have been hardware
related and subsequent testing of the equivalent kernel diff (which
was just committed) was successful. So committing this in the hope it
sticks to ease testing.
ok miod@
|
|
IEEE 1275 specification.
Based on a diff provided by Harald Gutch (hgutch@netbsd). Also see
NetBSD PR#56829.
ok miod@
|
|
in the future to implement support for things like EFI variables.
ok krw@ (a few others ok'ed earlier incarnations of this diff)
|
|
1st edition of Kernighan and Ritchie's The C Programming Language, to
that of the parameter-type-list form described in the ANSI X3.159-1989
standard.
In ISO/IEC 9899:2023 drafts, there is only one form of function definition.
"N2432 Remove support for function definitions with identifier lists".
ok kettenis@
|
|
|
|
|
