It has been since 2019. It seems to be added to images anyway,
probably because something else depends on it, but for correctness,
it belongs outside the REGULAR section.
If the debug_output pointer is just a kernel_args_malloc'd structure,
then it is already mapped and we should not be re-mapping it; we only
need to do that if we are using a fixed-map ring.
Eventually, EFI should get support for the debug log ring_buffer
like bios_ia32 has for transparent handoffs, but this preserves
everything except for the pre-start MMU dump, which is an improvement.
Fixes#15455.
It was removed in hrev55422 as we never had declared it in any headers.
But it seems some software came to depend on it anyway. Reinstate it,
and add a declaration for it, behind _GNU_SOURCE.
This reverts and replaces hrev53141, hrev53200~1, and hrev53888.
Two years ago (in hrev53141), I added checks to validate that Devices
were not in the process of being torn down before using them, to fix
a race condition KDL. Further logic was added in hrev53200~1 and in
hrev53888 for Pipes.
Well, upon closer inspection following the reports of #16794 et al.,
it appears upon closer inspection there were still two more race
conditions lurking in there: the first between Get and InitCheck, and
the second between InitCheck and use.
To resolve both of these, a new atomic "busy" flag is added to objects,
which is incremented before unlocking the objects array, and then
waited on before actually proceeding with teardown.
The older checks about initialization status are now superfluous
and are removed in favor of an earlier PutUSBID() invocation in Device.
While #16794 was fixed by hrev55429, some of those or related KDLs
might have been caused by these races. This also re-resolves #15115,
along with #14949 and #15710.
Change-Id: Ifcae84945a81123af5ef4683a6e33dc1eec5b23c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4421
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This array was introduced by korli in hrev44089~1 (2012). It "mapped"
ports to slots using a device's HubPort, and then used this value in
FreeDevice() to locate the xhci_device struct in question.
Well, when there are non-root hubs in use, the HubPort values can
of course collide, leading us to tear down the wrong device in many
circumstances. This appears to have been the true cause of #16794,
and probably also #16878 and #17266, and maybe even some others.
In case any one message (or, more likely, importing the bootloader's
syslog buffer) is too large for our buffer, do not discard it, but
keep as much as we can, and print <TRUNC> at the beginning of it,
to distinguish from <DROP>. (Documentation already notes <TRUNC> as
a possible thing to find in the syslog.)
If keep_debug_output_buffer is true, then we reused the syslog buffer
the bootloader allocated (and which has just been re-mapped above),
so we do not need to write the buffer in again (and moreover doing so
is incorrect, as it contains a raw ring_buffer header, and will be
larger than the buffer.)
This fixes "<DROP>" appearing at the beginning of all syslogs (or at least,
ones that began with handoffs from the bootloader) spuriously when
the whole buffer was really present anyway.
* Destroy interfaces and endpoints before deleting the default pipe,
as all of these may actually use the default pipe at any time
while they are alive.
* Remove the default pipe and then ourselves from the stack before
deleting the default pipe, as it also may be used at any time.
May help with some of the open tickets about USB stack KDLs.
This fix is for ticket #9460 to enable -Werror for ext2.
- Unused functions are removed.
- The ASSERT macro was redefining a different ASSERT macro from the included files. Now it gets undefined first.
- One comparison side was cast to ptrdiff_t because X86_gcc2 complained about signed/unsigned comparison
Change-Id: Ib0caade2f83de34c04acc0fc6aa5ed50712daec4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4453
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Instead their IDs are indexes into the stack, and are used primarily
for TRACE*() printing, so move the getter function into a "protected"
block and rename the variable appropriately.
AllocateAddress() is the pre-USB3 way of doing things;
as we never use it anywhere else and it is specific to
each BusManager, we always just got 1, which is what
the root hub will always be anyway.
Additionally, clarify the logic in _InsertEndpointForPipe
that is special-casing the root hub.
No functional change intended.
glibc's hsearch and tree functions are old and rather slow.
While these APIs do not appear to be used very often, these
changes can make a big difference: in one benchmark I was sent,
this change is nearly a 10x speedup or more in some cases.
This is a source compatibility break from BeOS, but should not
be an ABI one (I checked, the symbols are identical.)
Also use "= {}" in the definitions of the fields. We use this
in plenty of places in the kernel, so it should be OK for GCC2.
Change-Id: Ibe05b2236d46024d7b4563ae16e1cc7140fed965
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4434
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Modifications made on hrev55413 removed UsageID from array Items,
but also (bug here) broke UsagePage, needed by KeyboardHandler
in order to recognize items as Keyboard ones.
Fixes#17263.
Change-Id: I4b73c69240f31d3c8c2aacf6bab0d270f2053387
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4458
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Follow-up for Alan Shearer's change. Useful when the buffer contains the
character "%".
Change-Id: Ia6771a2d71306ca97e7c03f0e986ad3cfe100684
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4459
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
the file position corresponds to the end of the buffer.
Change-Id: Ib67dcfe1f43d959777c2f6dbf84181f25a022a7c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4447
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* I've added support to multiple min-max ranges to array reports too.
* All possible usages are stored in an array (Vector<uint32>). Perhaps, this can be squashed into an array of ranges.
* Usage array is stored in HIDReport class, so there is only one copy of it.
* HIDReportItem no longer has UsageMinimum()/UsageMaximum() as this no longer works. Instead, a Usage() member has been introduces.
* HIDReportItems of type variable, have a Usage ID assigned to them. HIDReportItems of type array have a zero usage ID as it has no sense.
* Having a variable typed HIDReportItem to store a range of usages ID doesn't seem a good idea to me because Data() method would have to return the values of all usages... or perhaps ask for a specific usage value with something like Data(0x03). This will require changes in hid stack and overcomplicate things.
* A bitmap keyboard is a worst-case scenario: Near a hundred of usages (uint32) are stored and the same quantity of HIDReportItems are created (this is already happening on Haiku). It doesn't seem a resource drama to me.
* Keyboard Handler has room for improvement, but I would like to left that for another patch series.
Change-Id: I556fa0aebfda831ef5334be5ae3a37f099ffa35d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4403
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This helps with creating a sysroot, otherwise extracted package
links refer to /system, which is outside of the sysroot.
* Should have no functional impact on Haiku, as these are already
symlinks
Change-Id: I29f719dc2c0839dd090e7f33eea0b8f98e0d6355
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4218
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Some applications may request per-page protections for an especially
large area (e.g. multiple GB), which leads to allocating a rather
large page protections area (e.g. 512KB), which we cannot allocate
without locking the kernel space to get new slabs.
We only need to avoid locking the kernel space if the area in question
is in the kernel space, as in that case, kernel space will already be
read-locked by the current thread.
Fixes#16898.
Change-Id: If52413a594da66edfc2821811d959085a2c3c78e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4436
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This codepath is only hit for especially large malloc'd areas that
do not fit into an object cache, which is a rather rare case to
have in tandem with DONT_LOCK_KERNEL_SPACE, but we need to be
prepared for it in this code anyways.
Probably this codepath would previously have caused a hang due to
attempted double lock of the kernel addres space. Unfortunately
it appears our rw_locks do not actually detect that at present,
so likely I should investigate that next...
Change-Id: I3c9059d3e3939271beeeff221ebc921bc07ddf00
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4438
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This removes the use of the destructor in the move assignment operator, as it
may rely on undefined behaviour from the compiler. Additionally, some duplicate
logic to dereference and free a shared string has been unified under
_ReleasePrivateData().
Change-Id: Ie9f51d598c734f83cd0fba49b651315c6e9c8aac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4440
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Video generated by DemoVideoProducer is now displayed correctly
Change-Id: Idaed170a355ae7ed0b50c143a5c6c33da1393551
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4401
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Most of the ClonedNode methods just forward calls as appropriate to
fNode or fClonedNode, but missed that fNode is itself always an ObjectNode.
Now we store that, and forward on the two relevant ObjectNode calls.
This fixes kernel stack trace function demangling where the symbols
contained clones (e.g. "[clone .localalias]", etc.). Before this commit,
such symbols would just appear as "()" and no more.
The "[clone...]" block will in such cases appear after the function name
and not after all the function parameters, as the two are returned
separately and there is no way to indicate how they should be printed
in the kernel's API usage of these functions.
ClonedNode was only introduced a few months ago in hrev55147,
so this has not been broken for too long.
