If a pinned thread is being run while disabling a CPU core, the thread
is properly requeued to that core, but with fCore set to NULL, causing
the scheduler to panic the next time that thread is rescheduled.
Change-Id: I9cf18c5a470517124b2573347cf3eb6fd26ab7b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6917
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* introduce new field unitType. Currently we support only
DW_UT_compile unit type.
* abbrevOffset and addressSize are shuffled around
Change-Id: I67db242240012b52e0ec59f87ffab7cb937eb212
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6981
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
For attributes with form DW_FORM_implicit_const, the attribute
specification contains a third part which is a signed LEB128
number. This value shall be used as the value of the attribute
when parsing the debug_info section.
Change-Id: I3e9aa3ba70b3aa05e6d2f570a1464966c38e4b1b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6980
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Rene Gollent <rene@gollent.com>
The 'whence' function defined in /etc/profile serves a limited purpose
with Bash as the default shell. Bash already provides
which/type/command as built-ins, which the function simply wraps.
Additionally, zsh has a built-in 'whence' command, which is masked by
the definition in /etc/profile. The function does not work under zsh,
breaking core zsh functionality as a result.
Fixes#18612
Change-Id: Ia34d95ffd58b2cb06d71145a217a9017657fa4a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6979
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* add new field for .debug_line_str section
* implement reading string and int values tagged with DW_FORM_*
* skip new fields addressSize, segmentSelectorSize in line info header
* parse directories and file names according to new syntax
* enable line-info parsing up to version 5
Change-Id: I1dd7e0d834c73f6d72b7115c7ded9f868be84a3d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6978
Reviewed-by: Rene Gollent <rene@gollent.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The structure of a logical APIC destination is made up of a 16-bit
bitfield of cluster-local IDs, as well as a 16-bit cluster ID. When
sending an ICI to multiple cores in different clusters, these cannot simply be ORed together.
Fixes#17233
Change-Id: Ifa84da51eccd85c1eff529749ffa00bc2159899e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6919
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
R_68K_JMP_SLOT should be handled similarly to R_68K_GLOB_DAT i.e.
the relocated value is symbol_value + addend. see e.g. in uclibc:
https://git.uclibc.org/uClibc/tree/ldso/ldso/m68k/elfinterp.c#n222
(also the G variable is never assigned any nonzero value?)
before this change we get jumps to 0x00000000, bus errors with
pc=0x00000030 etc.
after this change we are able to call functions!
Change-Id: Ibe135adb0dc6248a2baf5d6eca1543fdddf3a9e8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6957
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Fixes some PTE concurrent access bugs.
Change-Id: I09ec56861fae389a8a3e228b17a3921b85202c8b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6949
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Attribute is ignored for now.
It is supposed to check ABI compatiblity and reject loading incompatible images.
Haiku currently do not use multiple ABIs for RISC-V so it is safe to ignore attributes.
PT_RISCV_ATTRIBUTES program header is produced by default in GCC 13 and Clang 17.
Change-Id: I4659e9bacbf34a2a0bc16b34c2aaa37232d700fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6948
Reviewed-by: David Karoly <karolyd577@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This error only occurs when compiling a debug build. It was introduced
with commit fb885767b6
Change-Id: I80b470df3872b5bdd8690f65b3d14388158be8ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6951
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This switches the application over from using basic
authentication to using token-based authentication in
preparation for later using Open-ID based
authentication flows. The application version is also
bumped in order that the server can detect this version
at some later date in the future when it no longer
supports basic authentication itself.
Change-Id: I7addde1d57503c58d6bcd54908f22f66830c0c59
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6944
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
The comment above this block specified the correct behavior: the
button's status is already updated elsewhere, so just check IsEnabled().
But the code did not actually do that.
It appears this has been incorrect all the way back to the initial
OpenTracker import in 2001.
Fixes#13721.
In hrev51155, it was changed to be always enabled no matter what,
so that the current directory (without anything selected) could be opened.
But this means it would also be enabled for files, which is misleading.
Instead, remove the function, and adjust the logic detecting whether
to enable the button or not to take B_DIRECTORY_NODE into account.
CVS revision(s) are in first-line comments.
Requires a new firmware package (from HaikuPorts). There are some
changes in here which may fix some of the odder issues, like failures
to connect to access points. There is also support for one new PCI ID.
Tested by PulkoMandy who reports it's still working.
* Replace count_low/count_high with bigtime_t fields plus an int32.
sizeof(spinlock) is now 32 bytes with the debug option enabled.
* Adjust and clean up all spinlock code to use the new fields.
* Fold DEBUG_SPINLOCK_LATENCIES into the new code. Remove the bootloader
option and other flags for it (these were not compiled in by default.)
The new code should be much easier to understand and also more powerful.
However, the information transmitted to userland isn't as useful now;
the KDL command output will have the interesting information.
(Things could be reworked to transmit more interesting information to
userland again if desired, but as this code clearly hadn't been compiled
for many years, as it referred to global spinlocks that have been gone
for a very long time.)
Change-Id: I2cb34078bfdc7604f288a297b6cd1aa7ff9cc512
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6943
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Only the x86 and PPC implementations look like they would have worked,
while the builtin is available and will work across all architectures.
We already use it unconditionally in some parts of libroot.
Change-Id: I2dffb3b2c7cdd605092382b9d649151adb921bb4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6942
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is the loop that runs on all CPUs besides the one
actually running the kernel debugger. It's functionally
a spin-loop around a few different variables, and so it
should be safe to use cpu_pause() here, just as real
spinlocks do.
(cpu_pause() just runs a "pause" or equivalent instruction,
it doesn't use the CPU-idle modules, which indeed may be
unsafe to use in KDL.)
A glance at FreeBSD seems to indicate they also do this
when their kernel debugger is active.
Seriously improves power consumption while KDL is active:
even running in a VM with only a few cores, there would be
obvious fan spin-up when entering KDL. After this change,
there's barely any at all (while overall CPU usage % remains
basically identical.)
I looked at this code as a reference when writing similar code in another
project, and realized then that this was broken to the point where I
don't think anyone could have actually used it:
1. Writes larger than the buffer should only return the amount written
by this Write() call, not the amount flushed beforehand.
2. fDirty was only set if there were bytes remaining after the first
write to the buffer. So, if you wrote small amounts of data, they
would be silently discarded most of the time!
3. When filling the buffer, we might as well flush simultaneously.
This allows the logic to be consolidated into a loop and remove the
duplicate memcpy. In case of failure, just return the bytes-written
as the write could be retried later.
4. Flush() should always return an error or 0, not bytes written.
While at it, add some basic tests for this class.
Change-Id: I2de01d0b31e3fe22863cef21dd7b0b62ed47121b
* Remove unused/unneeded parameters to Dequeue.
* Make use of StackOrHeapArray.
* Reorder syscall-entry checks for efficiency.
* Inline the unlock-block method and unset variables in the process.
* Reorder code for clarity and to reduce indentation.
When breaking out of _RemovePackageContentRootNode() by encountering
a specified "endPackageNode", we need to unlock all directories.
This case is only possible to encounter when _AddPackageContentRootNode()
fails partway and invokes _Remove() to remove the just-added nodes.
Fixes a hang/deadlock encountered by Diver while testing some (disabled)
HaikuPorts recipes.
hrev55571 introduced several new pure virtual functions in Node,
none of which are implemented in Handle or ExecDevice any of their
descendants.
This change fixes the build after the Node/ConsoleNode refactor.
Change-Id: I098005df063160fd984e70da29ddb24a1d7a7133
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6940
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
hrev55571 introduced several new pure virtual functions in Node,
none of which are implemented in Handle or any of its descendants.
This change fixes the build after the Node/ConsoleNode refactor.
Change-Id: I825b90a114d83105f46d566e7fe1f644ba997ec5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6939
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
