If we just unblock all threads without actually releasing the lock,
then in the case where all threads have performed the atomic_add
but none have actually started waiting, we'll deadlock forever.
Fixes Mesa deadlocking when using our pthread barriers (at present
it's been using its own.)
This breaks kernel ABI on KDEBUG builds (but not non-KDEBUG builds),
but it does so in order to resolve a long-standing incompatibility
between them: until now, any kernel add-ons built against one which
made use of these lock facilities could not be run on the other;
instead you would get hangs and/or crashes.
After this change, kernel add-ons built with a KDEBUG configuration
should work on a non-KDEBUG kernel, while add-ons built with a
non-KDEBUG configuration will fail to load on a KDEBUG kernel
with unresolved symbols, preventing incorrect and broken operation.
Previously BString::HashValue() had an identical hash to the one
in StringUtils::HashValue(), but now it uses hashdjb2, so this
means Debugger will now use that also.
Tested basic Debugger functionality, seems to still work.
Change-Id: Ia341daa56249967a494df46e6e0a69a74c8b5fe2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8266
Reviewed-by: Rene Gollent <rene@gollent.com>
Otherwise the low_resource thread's run may complete before we
even start waiting, which makes things much slower as we then
have to wait all the way to the timeout.
We should only get an error return code in this method when the mutex
was destroyed, in which case waiter.thread should be NULL.
Also do some minor code cleanups.
May help with diagnosing #18983.
... before the text is loaded by checking that the text document is set.
Remove fMouseDown member and MouseUp() override.
Get mouse button down from the current window message.
Call inherited BView methods.
Fixes #19077
Change-Id: I79edb1860e3bd7864d2362d7f59fb3a583d19053
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8260
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
packagefs StringPool on my system had about 380 colliding string hashes
with the old hash_hash_string (out of ~98,000 strings). With this, it has
only 4, and they're all very odd strings (example: "p16c5x.inc" and
"p16c76.inc" collide.)
(This affects more than packagefs, though; other parts of the kernel
also make use of this routine, including the EntryCache.)
Change-Id: I3cf48a28c5c1a1fb5a457cfaf4fff80029ae146c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8243
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Standard kernel malloc() only uses the block allocator for allocations
up to size 8192, and anything past that has to do a raw allocation,
which is much slower than going through the object_cache.
libroot's readdir() uses a buffer of size 4096, but BDirectory
invokes the syscall directly and allows using arbitrary buffer sizes.
Tracker's AddPosesTask uses CachedEntryIterator which invokes the
syscall with 10 KB buffers, which thus hits this path.
Reducing the buffer size shouldn't be a problem, as applications should
continue calling GetNextDirents() until it returns 0. In case there
are buggy applications, we can simply change GetNextDirents to
call the syscall multiple times if it needs to. Tracker still seems
to behave OK, at least.
If we just use the kernel entry time, then the pre-syscall tracing
routine (with a debugger message send) will be counted in the syscall's
runtime.
Makes the output of timing in strace and strace -c much more accurate,
however it won't include the "syscall overhead" (time spent in the
syscall entry routines, etc.) But we already can't account for time
spent in the userland-to-kernel transition, so that should probably
be measured some other way if knowing it is desired.
In fact, on architectures which used the generic syscall dispatcher
(e.g. RISC-V), this is the behavior that already existed. So this just
makes x86 consistent with them.
Change-Id: I8cef6111e478ab49b0584e15575172eea77a8760
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8240
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Returns an int which is -1, 0, or 1, much like strcmp(). Implemented
as part of the work for using an AVLTree to store nodes, which won't
be merged, but this may be useful in the future anyway.
The DPLL selection registers have changed again somewhere between
Skylake and Tiger Lake. Our code was trying to read/write the Skylake
registers on hardware where they don't exist anymore.
Introduce the new Tiger Lake registers and implement enough of it to get
things working on my machine (but probably only on my machine). Also
add a bit of specialization of DisplayPort which I think was not done
correctly on previous hardware either: for DisplayPort, the link rate is
selected from a handful of allowed frequencies, instead of closely
matching the pixel clock.
Things left TODO:
- Write a proper PLL allocation system to ensure each display gets
assigned its own PLL (unless multiple displays use the same timings).
For now it is hardcoded to what I want on my machine.
- Fix the DisplayPort PLL computation to use the values from Intel
datasheets, not the ones used by my machine which are somehow
different.
- Fix the DisplayPort PLL computation to select one of the several
available frequencies, allowing resolutions higher than Full HD which
require higher clocks.
- Fix DisplayPort link training or whatever must happen after the PLL is
set up, since changing the PLL results in a non-working display and we
don't get it back.
Unfortunately this still isn't enough to bring up both displays to life
at the same time. I think it is not very far, but the secondary display
(as decided by the BIOS) remains off for now even after successfully
setting it all up.
Early testing on other machines is welcome.
Change-Id: I37209bb14f32c99944bdc8ef6eef75e2550e18ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7367
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
On my development VM, there were over 300,000 calls to malloc()
from EntryAttributeHandler::HandleAttribute() alone, which had
the most out of any AttributeHandler, but the others were still
significant (over another 10,000 at least.) On systems with more
packages and more attributes, there would be of course more calls
to malloc().
Since the Handlers are allocated and freed in a "stack"-like
configuration, we can use a simple "bump" allocation strategy
with the AttributeHandlerContext to avoid calling malloc() at all.
In my testing, the most memory that was used appeared to be around
2 KB or so (and the smallest was 216 bytes), so a single slab
should suffice for this.
AttributeHandlerContext seems to be created/destroyed around 530 times
during the boot process on my test machine; allocating and freeing the
allocator's slab page that many times should be negligible (allocations
that large still go through the block allocator.)
Performance-wise, the total time we spend with AttributeHandlerContext
objects "alive" goes from around ~172ms to ~156ms. So, not as much an
improvement as one might hope, but that just goes to show that our
kernel malloc() is pretty efficient. And this change will also keep
short-lived objects off the heap during a period when we are allocating
many long-lived objects, anyway.
Change-Id: I810888434aad788511f2af30143335009b34ee78
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8230
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
A basic bump allocator that can handle arbitrary amounts of allocations,
so long as all are allocated and freed in a "stack"-like manner.
(Actually it could be extended to support non-stack-like operation,
but that would require more logic that isn't needed at the moment.)
Change-Id: I47077146ea282600130778d312f7d86bd8c032e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8238
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Michael Lotz <mmlr@mlotz.ch>
Anyone I've moved, I didn't see any signs of code contributions
or reviews, tickets, or forum posts in the last year and a half
at least. They may still be around and reachable, but I don't think
that suffices to be a "Haiku maintainer".
I've also moved Alexander up in the list of maintainers; the "Past"
list doesn't seem to count "von" for the alphabetical sort.
There was also one mis-sort in the past list which I've fixed.
Change-Id: If6763372be6a23b24bc0f781243e198d1734a849
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8239
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We unfortunately have to define its methods in the .cpp and not fully
inline them, because otherwise GCC chokes in some places thinking
that the class can be NULL (where it can't be) and thus generating
overrun -Werrors.
This reduces the size of Node and all subclasses (like UnpackingLeafNode)
by 8 bytes. (Not 16 as with PackageNode, as it doesn't eliminate a
virtual table pointer.)
BReferenceable has a vtable, so it's aligned on sizeof(void*) and thus
has 4 bytes of padding on 64-bit systems. We also had 4 bytes of padding,
and so if we just inline an int32 and add Acquire/Release methods,
then we save 16 bytes (again on 64-bit systems) of object size.
Since this isn't so obvious, add an inline comment explaining the
situation.
This makes sizeof(PackageFile) go from 112 to 96 bytes, and so on.
We don't really need nanosecond resolution here, microseconds will do.
We can thus fit the value into bigtime_t and use the standard converters.
Reduces the size of PackageNode by another 8 bytes on 64-bit,
saving another ~2.5 MB of memory (or so) on my test VM.
Change-Id: I1232aa8aa22fbf84a6a70af0129183f297961f03
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8237
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BControl adopts parent colors on AttachedToWindow(). Use the
adopted view and high colors for BControl derivatives before
using B_CONTROL or B_PANEL colors.
Affects the following controls:
Spinners
Checkboxes
Radio buttons
Sliders
Text controls
Buttons (get control text color already, don't pass it in.)
Affects control colors in HaikuControlLook and BeControlLook,
FlatControlLook control colors derived from HaikuControlLook.
Do not remove control flag before drawing label, we get the
correct label color now. The fallback colors are only for if
you override AttachedToWindow() on your BControl subclass to
prevent adopting parent colors.
Change-Id: I9357c0287898bff48c695a7869f3b8be108c02ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8235
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We do not always use radio buttons and check boxes on panel color,
use the parent colors instead if you have them. The label is left-
center aligned.
Change-Id: Id5cbd98e8ae88d3a65fb0735d45b2ad19c4afdf9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8233
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
... instead of list view background and panel text foreground.
Document color is appropriate here, this is not a list and we
don't want panel colors. Document color yields same result
as list color using default colors: black on white.
This changes the colors of the inside of the dialog that says:
"The following additional package changes have been made:" and
"The following problems have been encountered. Please select a
solution for each:"
fixes #19068
Change-Id: I5b721ad8703c73aa2da323eb189fa22033d44e5a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8232
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
* this avoid letting the linker defaults to take precedence.
* add common/debuginfo.ld taken from ppc/kernel.ld for debug sections,
extended by me for Dwarf 4/5.
* put the __bss_start symbol in the .bss section.
* add asserts for expected empty sections on x86 or x86_64.
Change-Id: If34433a8d7d82b3f115fe6dbf5881c1f9ea42442
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8229
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Ensure that allocated queues can hold the amount of descriptors that
were previously communicated to DMAResources in virtio_block and
virtio_scsi. The queue allocations will now fail with B_BUFFER_OVERFLOW
if the requested size cannot be provided.
When requestedSizes are set to 0, no requirement is placed and the queue
is sized to its advertised maximum. The requestedSizes argument can be
NULL which implies all 0.
Change-Id: Ifb1e032d48f8c07aedfe2bf941f32783842c8c12
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8220
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
In case the queue operation failed, the entry would stay attached to the
ConditionVariable and eventually trigger an assert when re-added on the
next iteration.
Change-Id: I347b5b1c86a7cabc12a6052f85266ef1c584c415
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8187
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
This is similar to the change in virtio_block of the same name. Checking
the return value of queue_request_v and ensuring that the
ConditionVariableEntry is removed from the ConditionVariable by using a
local one.
Change-Id: I2e8e3304925cbec27a2004c8a26468946db3d46e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8182
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Queueing can fail in which case there is no point in waiting for the
transaction to complete as it will always time out. Instead check the
return value and skip waiting.
This requires the use of a local ConditionVariableEntry or an extra
ConditionVariable::NotifyAll as otherwise the entry is never removed
from the variable. As the creation of the entry is not expensive,
using a local variable seems simpler.
Change-Id: Ie697659a35442d965bc5cf2a636ca41841f9acff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8181
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
