This works similarly on the 32-bit and 64-bit ARM port.
Other architectures call reserve_io_interrupt_vectors() when
initializing the interrupt controller (e.g. PIC, APIC etc.)
so let's do the same on ARM.
Change-Id: If5a360cf23fd01d97d2f20702785bc5da0190052
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5566
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
GICv2 can use interrupt numbers up to 1019:
* 0-15 are SGIs aka ICIs
* 16-31 are PPIs
* 32-1019 are SPIs
Change-Id: I1c19be77105683da3f6988a5607b14dc10a899db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5565
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Better testing of the riscv64 arch by providing
more supported hardware
* Partially based on x512's research in the forums
* Example usage:
../src/tests/qemu-boot-test riscv64 \
kernel:.../u-boot.bin haiku-mmc.image
Change-Id: I9fe9d3c63bd7683818fc28fad2de64545bcd4804
Not all things that accept locale_t can accept LC_GLOBAL_LOCALE,
specifically nl_langinfo_l does not (the specification indicates
that passing it is undefined behavior; indeed, no C library I glanced
at seems to support that.)
So, return a static locale_t pointing to the global values instead.
Fixes#17875 and #17876.
Now that we have locale_t, we can use the musl versions of these functions.
This also fixes a licensing issue: the strptime implementation had an
advertising clause (although in upstream *BSD it was removed, so we
likely could have managed to remove it anyway.)
All filesystems have open_dir calls in their vnode hooks,
but there are some vnode hooks that do not, like FIFOs.
Thus we need to check the hook actually exists.
Fixes#17870.
Creates, opens, tries to open as directory, then unlinks.
The attempt to open as a directory triggers an assertion
in the kernel at present (this is #17870.) The next commit
will fix that.
* adjust format string for thread id
* fix variable name loop vs looper
Change-Id: I3d1924d6ab98981b4b2a3f56689872e35e5bea77
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5562
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Icc4ab0c3f7258914d798267e08c47977c0987c97
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5547
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: David Karoly <karolyd577@gmail.com>
These two recieve integer values from userland (termios).
Cast them accordingly.
Should fix#17861. Tested on 32 and 64 bits.
Change-Id: Ic5eb53d2732354f86a82f59aab4917ad1851cfc5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5545
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It can be enabled by putting "bios_patching true" in the VESA settings
file.
This patching does not work yet on modern hardware, but the detection
code to decide if we should try patching still says it found the
modetables. In this situation we can crash the BIOS or other weird
things can happen.
To avoid these problems, and because VESA is supposed to be the failsafe
option, disable this code by default, and let people who want to
experiment with it first enable it in the settings file.
Should fix#17633.
Change-Id: I4d89ff6dfeb7d02e39cd3da7b22ddd5411b10822
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5499
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
compiler generates a warning regarding using offsetof() function on a non - POD type class
disabling Werror will not break build due to this warning
Change-Id: Ic72210f92a257e80ad8de9327892cfca7454076e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5538
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
sscanf() requires 1024 bytes for url[] at line 96 and 97,
but url[] size is 256 bytes.
Pointed out by LGTM.
Change-Id: Ia94661b8d7f08874395f8912b48774dba3b9ece2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5534
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* conditional compile for dump_fdt() with #ifdef
* rename functions according to coding standard
* use dprintf() for printing
Change-Id: Ie486739d87f1cb9a005188a46a43f470b6000319
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5536
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
... and B_WORKSPACES_CHANGED too.
hrev50148 propagated B_SCREEN_CHANGED messages to
children allowing them to respond to screen changes
fixing #8035 back in 2016.
This does the same thing for workspace messages only
I spelled propagate correctly this time.
Add private _PropagateMessageToChildViews() convinience
method to BWindow to do this work.
Call PostMessage() instead of calling MessageReceived()
directly which can work better in certain circumstances.
Change-Id: I5978c3fe674bbe75d9eafb7afb654a49ee3e0c11
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5516
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
and dns_resolver_repair() succeeds.
reply allocated at line 178, not freed on continue.
Change-Id: I8fc9d02512ab741d34b0f6bd4710bb1bd29ddaae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5532
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
as it extends the provided protection with the kernel protection.
fix hrev55016
Change-Id: I9fa9349c15b4ef896a9dadd1b1b7a4165cc03b39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5531
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
'reply' is allocated in Serialize() at line 120, but is not freed.
Pointed out by Clang Static Analyzer.
Change-Id: I9f7e0c5c2dcb976f11230ad8a5ba38d653b23d6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5530
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
should help with #17664
register change from Tahiti for #17377
Change-Id: I52b9691cd6a04b58b70e905bc29e803f06936789
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5526
Reviewed-by: John Scipione <jscipione@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Normally the heap's priority will suffice to check if we need to reschedule.
However, in cases where the CPU in question is currently in the middle of
rescheduling already, and it is about to change its priority to "idle",
we can race with it and not notice that we need to send it an ICI.
Previously this meant we would just lose some performance, but after
recent fixes to not reschedule only as necessary, this race led to hangs.
Now we report whether the runqueue we added the thread to was empty
in ThreadData::Enqueue(), and if it was, we then always trigger a
scheduler invocation on the target CPU.
In my testing, this fixes#17847; and at least in my unscientific
benchmarks, improves compile performance by as much as 10% (I saw
~55s -> ~50s in some tests.)
This will allow it to be invoked outside scheduler_cpu.cpp,
and GCC should automatically inline this function within that file
anyway.
No functional change intended.
No commits since 2016 or so. Are you guys still around?
Change-Id: I07ca59f537c7e47859c02128023eeebb4d452e33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5525
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Instead of 8096 maximum entries, now there will be about 130k.
As there are around ~32k files in the Haiku git tree, this has a
serious impact on "git status" performance: in my testing it sped up
from around 0.95s to 0.39s, or less than half with a "hot" cache
(in a VM backed by an NVMe SSD, may be more dramatic on spinning system.)
Compile performance does not seem very much improved, however.
We are trying to add the enty to the current generation, so we
need to use the current generation's next_index, not the previous.
This was apparently broken since this code was imported. The "miss"
here meant we always acquired the write-lock and then ran the more
expensive add operation, which performs this same check (correctly).
Slight performance improvement seen in basic testing, but nothing
too drastic.
