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>
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>
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>
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>
This can be used to replace mutex_trylock/mutex_unlock pairs. Once the
locker has been created, the success of the locking attempt needs to be
checked via locker.IsLocked().
Change-Id: Iba4b4ce21cac5059a3577a84a6eebe28d2cc4058
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8179
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
So that it has the same naming as DoublyLinkedList.
No functional change. It seems there aren't any users
of this API in the default build at the moment.
* This is the closest thing ARM has the semantics of write-combining
MTR on x86.
Change-Id: I12a1582e0af871e2ab729262e90695ffe928c85b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8223
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Implemented using __builtin_clz where available, otherwise using
an algorithm derived from "Bit Twiddling Hacks" which is similar
to the one ramfs uses. GCC and Clang seem to unroll the loop on
x86 at least (but it doesn't matter there as the builtin exists,
implemented using the "bsr" instruction.)
These are architecture-specific routines, so they deserve proper
architecture-specific naming. The user memory access routines are
already under arch_cpu (arch_cpu_user_memcpy, etc.), and the methods
usually change a CPU flag, so it makes sense to put these there too.
RISC-V had get_ac but nothing else defined or used it, so it's removed.
No functional change intended.
Change-Id: Id4715214e32f73d4a93bc7ba8249411a0878d174
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8106
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
So we need to check that it didn't when creating areas.
Change-Id: I4342463113046b543722faa7a51ca269ed67e8bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8137
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Enhance the warning message and return a more relevant error code.
Fixes #19017.
Change-Id: I13d01ce206a27e5c9a35debc8081219422bfb10a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8136
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
gcc2 complains otherwise when using -ansi -pedantic-errors that
"text afer `#endif' violates ANSI standard" because it doesn't
recognize C++ comments in C mode.
Change-Id: Icb091d15a4324625ce305aa89391c44a94f4a38e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8094
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
- This key code is inherited from BeOS, where it was used for the power
key on Apple ADB keyboards
- Since then, we have introduced a new system for "multimedia" keys,
that uses HID key codes directly instead of defining our own mappings
- The PS2 driver was using the HID keycode, but the USB driver was still
using the BeOS defined one
- Japanese keyboards, which have a few more keys than US and European
ones, reused the same keycode for something else
Since the power key does not need to be mapped by the keymap, move it
out of the way by using the HID keycode (key codes larger than 0x7f
cannot be mapped to UTF8 symbols). Remove all mentions of the use of
0x6b as a keycode for the power key, but add a note in the documentation
that BeOS did this.
To avoid further confusions, complete the documentation of extra
keycodes, and remove some definitions from keyboard_mouse_driver.h that
should have been in InterfaceDefs.h.
While researching this, I also found that some keys specific to Korean
keyboards were declared in the wrong place, as mapped codes instead of
unmapped ones (checked that by looking at the HID driver, which emits
these raw keycodes, and confirming that the mapped ones are not used in
any keymaps. Also added a note about the mapping of the extra modifier
keys in Japanese keyboards, which I think may be a problem since these
map to invalid UTF-8 byte sequences, but this is what the existing
keymap does, so leaving it as is for now until we can determine if this
can be changed or if we have to keep it that way.
Change-Id: I6a198a0840cba7739bdc78e0c65e5d8fd23956c9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8047
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
According to the ARMv7 Reference Manual, "Wait for Interrupt" is supported only through the WFI instruction on ARMv7.
The currently used ARMv6 equivalent may not work on ARMv7 and newer CPUs.
Fixes #18520
Change-Id: I69a136870654be33c0c789004e08bf610db3dd97
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8044
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
ramfs needs to create caches that are both temporary and unmergeable,
so add another flag to make this state possible.
Otherwise, mmap'ed files from ramfs might wind up in VMCache
trying to merge the caches when the last one is closed, which
we don't want.
The IORequest internally likes to deal with transferEndOffset
not transferredBytes because of sub-requests potentially being
prepared all at once (in some paths in the I/O scheduler),
thus fTransferSize can get incremented in Advance() before we have
actually executed that transfer.
But external consumers much prefer just knowing transferredBytes
not transferEndOffset. And many of them actually named their
variables that (or "bytesTransferred") and just passed the
transferEndOffset through to variables with that name! That's
obviously wrong, and it's surprising it wasn't discovered before now.
The problem was uncovered by repeated KDLs in PrecacheIO.
That method used the "bytesTransferred" value as a count of
pages transferred, which would then run past the end of the array
if the transfer start offset was not 0 (which the majority
of the time it would be, since this method gets called on
the first mmap() of a file, probably before any pages are read in.)
Most other consumers of this API did not check the value, it seems,
or otherwise had some mitigating factor that prevented it from
causing more problems. An exception is the page code, which
may have spuriously considered writes as successful when they
really weren't.
May fix some of the "invalid concurrent access to page" KDLs.
We can't allow applications to reference/unreference cursors,
this is a safety/security violation, and it being done improperly
lead to the reference counts becoming incorrect on the app_server
side.
Change AS_REFERENCE_CURSOR to AS_CLONE_CURSOR and adjust the Cursor
code appropriately. (In the future, copying BCursor without Clone'ing
the data in the case of custom cursors could be accomplished with
client-side reference counting.)
Then rework CursorManager to remove cursors at once on team deletion,
and otherwise clean up cursor reference management to let the
reference counting handle things.
This paves the way for a variety of more interesting interactions
between drivers and the stack which are currently not possible
(e.g. checksum offload, #18744). The main advantage for the moment
is that we will save a memcpy of the buffer on each send/receive.
Adapt the virtio_net driver so that at least one driver is using
the new interface. Network still seems to work OK with it.
Change-Id: Ic5832e4865e3e1bed7462583ca1ffd16418d7cab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7912
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Does not actually break ABI since net_buffer had 3 bytes of padding
remaining unused.
Add the first two constants for this field: L3/L4_CHECKSUM_VALID.
These will indicate when the checksum of the packet is known to be
valid (good/correct).
Change-Id: I155b3ea51d1093e229677cb788a007560ddbd428
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7916
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It contains only the MSG_* flags, not any other kind of flags.
Change-Id: Ia4590d87a1638fcdb848ef2b816b047b72ca2836
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7915
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>
Convert users of those and other parameters to the new API.
Fix mouse preferences "Default" button not changing button map.
Change-Id: I9184011fd3067fd0b229e1db6376c1b41f06dab9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7878
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Remove compatibility with legacy settings format.
The preferences app doesn't need to read and save the settings file:
devices are enumerated and their properties retrieved from the
input_server. When something changes, the input_server updates the data.
Change-Id: Id1ea6f2532a1c8a173e9ba9818dd911fd6f4aa10
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7877
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Every time a page is mapped into an area on fault, we have to
allocate a mapping object for it. While the object_cache
does have per-CPU depots, these depots only store a limited
number of items, and once they run out the object_cache's lock
must be acquired.
So, to reduce lock contention on SMP systems, create a number
of object caches corresponding to the nearest power of 2
that is equal or smaller than the count of CPUs. (We already
allocate dozens of object caches for the block allocator
no matter how many CPUs there are, so a few more depending
on CPU count shouldn't impact memory use too much. Besides,
the object_caches are wired into the low_resource system.)
This significantly reduces lock contention on SMP systems.
Same benchmark setup as yesterday (compile mime_db and relink
HaikuDepot, VMware, -j4), before:
real 0m16.981s
user 0m14.357s
sys 0m6.060s
after:
real 0m14.522s
user 0m14.194s
sys 0m4.337s
And the page_mappings object_cache locks went from having 200,000+ waits
and ~14 seconds waiting time (across all threads) down to ~900 (yes,
that's not a typo) and ~0.05s wait time (though these numbers were captured
in conjunction with the following commit.)
This is an alternative to DT_HASH (SystemV/SVR4 hash tables.) Notably,
it uses a Bloom filter to allow an entire image to be skipped
at once rather than searching the actual symbol hash.
We don't currently build anything with DT_GNU_HASH support.
You can test this by adding -Wl,--hash-style=both to HAIKU_LINKFLAGS.
(It seems to increase image sizes by not too much: libroot goes
from 1347139 to 1367691 bytes (20.55 KB) in my build.)
Change-Id: I4a91276490fcd136db175833ee48b36e06ceed47
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7855
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Put close/free at the beginning since all FDs must implement that.
(Most of the function declarations inline were already in this order.)
* Add readv/writev hooks. Not used yet, but this will allow for
more than just files to implement them. All declarations updated
to have NULL for the hooks for the moment.
It allows introducing new file descriptor types without editing enumeration every time. Anonymous FDs will be needed for Mesa
OpenGL/Vulkan drivers to reference GPU memory buffers and other driver objects that can be referenced as FDs from userland.
This change breaks private VFS API compatibility.
No behavior changes intended.
Change-Id: Iac109aad420b0b6aae704b38619436e01dcf4969
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7838
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
