* While virtio was attaching, network connectivity
wasn't functional.
* Use usb-net for now to get things working.
* Move to a user network with dhcp for simplicity
* Forward port 5555 on the host to 22 on the guest
for debugging / testing
Change-Id: Ieac095d7272c3132c39e4eaa0ccc461a32972dd2
Configure PRRR and NMRR as follows:
- memory type 0 is Strongly-Ordered
- memory type 1 is Shareable Device
- memory type 2 is Normal, Inner/Outer Write-Through
- memory type 3 is Normal, Inner/Outer Write-Back, no Write-Allocate
This way no change is needed in B and C bits so we can keep the
existing MemoryTypeToPageTableEntryFlags() implementation.
Change-Id: Icb4b18b0082774fdbef28576cee8624fae610538
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6607
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Condition variables are now a pretty common way the kernel blocks threads.
That means the "threads" command was getting difficult to navigate, since
at any given time, a lot of threads could be blocked on "cvar".
Now we try (carefully, because it could fault!) to fetch the first 4
characters of the "type" name and display then. This suffices to
distinguish the most common object block types in the list at a glance
(e.g. "cvar:port" for port reads, the most common.)
Change-Id: I94f4b59fd78b7ebdce913944551a5e98f0ca2e33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6605
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some executables (or shared objects) may have .debug_frame or
.eh_frame section which contains the CIE(/FDE) length is 0.
The DWARF spec doesn't describe this case explicitly, but doesn't
prohibit it.
LSB says to treat this a terminator of the CIE.
https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
Previous code failed to load the entire debug info of the
executable.
New code just skip these section (don't read anymore) after the
Debugger (kit) encounter a 0-length CIE.
Fixes#18438.
Change-Id: I382d0ec409d40570b5bccd384d38fa3c29ae2e7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6538
Reviewed-by: Rene Gollent <rene@gollent.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
No longer is it required that the mutex be unlocked.
This was the case before the recent refactor, though it
wasn't noted anywhere. Now it is the case once more.
Should fix#18445.
We need to set the "to" mutex as locked+waiting before performing
the unlock of the first mutex, otherwise something in userland could
unset the "locked" flag but never call the kernel because "waiting"
had not yet been set.
In practice, the one consumer of this API (pthread_cond) could not,
at present, wind up in that situation, as far as I can tell, so this
race was entirely theoretical.
This allows to see the display in Screen preferences, and know its DPI
and physical size (as much as EDID data can be trusted). This
information could be used to compute the default font size, for example,
so it's important that all drivers provide it whenever possible.
Change-Id: Ic3d04e53cf5fcb24e22d35661d2b364a257947da
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6576
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Added a dedicated mutex type handler that can print mutex status
flags while still showing the mutex address.
Change-Id: Ie028e5c0a336063a4c03a4f9adf955ffa6911837
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6557
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Make `pthread_getschedparam` and `pthread_setschedparam` handle
scheduling policies more consistently with `sched_get_priority_min`
and `sched_get_priority_max`.
Threads running in real-time priority will appear to be under the
`SCHED_RR` policy, while normal threads will appaer to be
`SCHED_OTHER`.
This prevents POSIX code using `sched_get_priority_min` with the
calling thread's current policy returned by `pthread_getschedparam`
to adjust its priority from unwantedly promote into real-time code
and affect overall system performance.
Change-Id: I9664257dc1b98db579e55218ce352cb762524b0c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6556
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Suppose the following scenario:
1. Thread A holds a mutex.
2. Thread B goes to acquire the mutex, winds up in kernel waiting.
3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)
4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.
5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.
6. Thread A, suspended back in step 3, resumes.
Now we encounter the problem. Under the previous code, the following
would occur.
7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!
8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!
The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.
Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.
That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.
Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.
Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.
Fixes#18436.
Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The first of these assertions in the pthread code is actually possible
to trigger under some specific circumstances, which is ticket #18436.
This makes that problem more obvious when it does happen.
Change-Id: I026ea6e4c569a7c20d82b70722f752d87e57c5a1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6536
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The debugger.xmi file is the source file meant to be opened by
Umbrello. The other files are generated.
The docbook file is exported from Umbrello and the .rst file is
converted from it using Pandoc, with minor manual fixes.
Change-Id: Idc831d15c6121c21ebb170c245bc8ab97986702e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6483
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Add command "info" to show the summary and description of a package
in a a remote repository.
Change-Id: I254eff3bb6401c90a394a483cd684134ead0a9a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6516
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
pthread_barrier_wait can return errors, which on Haiku are negative
and so -1 is an error condition, it should not be reused for a magic
constant.
This breaks ABI. However, until the recent fixes, barriers were so broken
that I doubt any application was using them seriously (Mesa, for instance,
has them disabled.)
Change-Id: Ica23921de012a33e9e7aded816bb1347bd157b31
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6517
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: X512 <danger_mail@list.ru>
The previous implementation was prone to deadlocks when the next round
of threads tried to enter the barrier before the prior round exited it.
This new version takes care of that problem, and also removes some
other contention.
Basic design:
* waiter_count is now atomic, which means only the "serial" thread, or
in case of contention threads that raced, need acquire the mutex.
* mutex remains locked during threads wakeup, at which point waiter_count
is negative. It is only unlocked when count reaches 0 in the last-woken
thread. This protects against the races that lead to deadlocks.
* Remove usage of _kern_mutex_switch_lock. This was done incorrectly;
if it returned EINTR, the first lock would be unlocked but the second
would not be acquired, creating further races. Instead, we leave
the barrier lock in "LOCKED" state at all times except when we
actually want to wake threads up, when it is left "Unlocked"
(and "unlocked" by each successive exiting thread, just in case.)
Fixes#15736.
Pages should not be marked as accessed when initially mapping them.
However, there's a short interval during kernel startup when new pages
are mapped but the fault handler is not installed yet.
Therefore, we set Accessed Flag to 1 in early_map.
Once the kernel initialization has progressed enough, we start mapping
new pages with Accessed Flag set to 0.
The chicken and egg problem of initially mapping the vector page is
tackled by preallocating the vector page in the boot loader.
Change-Id: Ie3be4f81812d7a090af57e8c79420598d16182b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6450
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
- Added some utility functions to the `Context` class.
- Updated the `sockaddr` handler to retrieve the next sibling
rather than the sibling at index 2. This allows the handler to
work for syscalls where the `socklen_t` argument is not the third
one, for example, `_kern_recvfrom`.
- Added the ability to print the `flatArgs` for `_kern_exec` and
`_kern_load_image`.
Change-Id: Ia4cf0a30a5cf972274820bbf068101450db52189
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6498
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Updated old `sockaddr *` formatting code to work with current
`strace` structure.
- Add support for `AF_UNIX` family address.
Change-Id: I13f7b0a3eb913ab188bea68f8ea84e928b753154
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6497
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Unlock the current cache in `map_backing_store` before
`unmap_address_range` is called, since `unmap_address_range` may
call `delete_area` which would then also attempt to lock the same
cache if that cache has already been mapped to an area in the
conflicting address range.
Fixes#18422.
Change-Id: I6fc5301c43d11bb6df489a2e6d6bdcd6cd80d2b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6392
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
We must do this to prevent lock order inversion: when busses are
initialized, they are started by the (locked) device manager, and
then acquire the explore lock. We must do the same in Explore itself,
for when called by the explore thread, we would otherwise first acquire
the explore lock, then (when publishing new nodes) acquire the device lock.
Should fix#18421 and #18393.
If the dimensions are already larger than needed, don't add to them.
Fixes Terminal and other non-layout applications' display
following the prior change.
- Resize the `page_protections` array in `cut_area` and also shift
the bits if necessary.
- Set the correct protection array as well as the real page
protections for the second area produced by `cut_area`.
Change-Id: I62293480487e828970ebe5a3bc729cec2a14c687
BMenuField's constructor (called on line 715) used to be passed
fDirMenu. The constructor would create a new BMenuItem using fDirMenu.
TFilePanel::Init did not want this menu so it removed it with a call to
RemoveItem (located on line 721). This call, however, does not actually
free the memory. It just removes it from the menu. The refactor that I
did here fixes this by never creating the new BMenuItem in the first
place. This is done by passing NULL into BMenuField's constructor
instead of fDirMenu. It happens that the refactoring also cleans up
TFilePanel::Init slightly.
Change-Id: I05ef24f429fb309ff41806e342d275f832772b5e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6486
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Add support for retrieving the `siginfo_t` structure of a signal
event from the Debugger API.
- Add code to `strace` to display this information every time a
signal event occurs, similar to the Linux `strace` tool.
Change-Id: If4e92bbae049ee0b52efaf9fc911d66511da62f4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6393
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Remove backported function that was needed only for old OpenSSL versions
- Add compile time options to declare which version of OpenSSL API we
want to use
This should make it possible to build with OpenSSL 3 while keeping the
old APIs available. Once the migration to OpenSSL 3 is done, we can bump
the OPENSSL_API_COMPAT value to get compile time errors when using APIs
that are deprecated in OpenSSL3, and rewrite all the code that needs
changes.
Change-Id: I606633739ed12f9698a3013989025b68478352fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6484
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In the case of devices where the mass-storage interface is not the
first one, we will miss it unless we were to check all attributes
one at a time in order. Instead of doing that, just fetch the configuration
and enumerate it directly.
I saw in a KDL stack trace that this function was using over 4KB of stack.
As it is called as part of device_manager startup, where there can be
pretty deep recursion happening, that seems like a bad idea.
Additionally, it did not actually do bounds checking.
Now we dynamically allocate an array of sufficient length.
There is now an "io_lock" which must be held when performing any USB
operations. All ioctls that read basic status, size, icon, etc. information
do not need to acquire it, of course, which should improve userland
lockup occurrences on congested USB disks.
