The previous hack, which as the comment (and __MWERKS__) implies
dates all the way back to the Be era, finally broke: int32 is "int"
on non-x86, not "long", and so this generated an undefined symbol
error on ARM.
The best solution seems to be to make StartMenuBar merely protected,
and then make a subclass where it is fully public to call it.
This is a lot less fragile (and much less ugly.)
Change-Id: I0519d0d9eeb1cc4523d0c6dd4fdfe8688ed1092c
Reviewed-on: https://review.haiku-os.org/c/1516
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The changes in this commit are large but also subtle, so
an explanation of how they came to be seems to make sense:
Earlier today I tried booting Haiku on QEMU under USB3 ... and
discovered that it didn't work, with the "Operation timed out"
message from in usb_disk upon failing a data transfer. Indeed,
turning on tracing showed no event was being posted for the
transfer. So, I downloaded QEMU's source code, turned on XHCI
debugging, and began tracing what was going on.
Eventually I determined by adding more and more printfs into QEMU's
XHCI implementation that what was occuring was that it was evaluating
a Link TRB, hitting an empty TRB, and then deciding that the TD (aka.,
the "run" of TRBs) was not ready to be consumed, and bailing.
In fact, that very condition (a link TRB leading to an empty TRB)
is precisely what _LinkDescriptorForPipe did before this commit.
We allocate only a small (8 before this commit, 16 + 1 after this
commit) TRB ring for each *endpoint*, and larger ones on a per-*transfer*
basis; and just write Link TRBs onto the Endpoint ring pointing to
the transfer TD, and then one at the end of each transfer TD leading
back to the endpoint ring.
The reason this occured inside usb_disk, and not earlier (e.g.
during descriptor fetching), is that QEMU has special logic around
determining transfer lengths of control transfers which made it
not perform the "TRB valid?" check after evaluating the Link TRB.
So, being implementation-defined behavior, I am guessing that
this same problem was also the cause of boot failures on real
hardware.
This also means that the problem was essentially a race condition,
as if we posted another transfer to the ring before it evaluated
the TRB, it would always work.
The solution of course is to put some valid TRB at the end of
every transfer on the Endpoint ring. A "no-op" would have done
the job (well, maybe not, it appears QEMU does not implement "no-op"
TRBs for some reason), but there was another feature of XHCI
that we did not take advantage of: Event Data TRBs. These provide
the "total transferred length" as well as the status, instead of
the "remaining length" of the final TRB.
This of course required refactoring the use of the CHAIN bit
and the IOC bit (namely, more or less all TRBs save the Event Data
get the CHAIN bit set, and none save Event Data get the IOC bit.)
There was also an update to the XHCI spec since I've last committed here,
so the new comments are in reference to the "XHCI 1.2" spec. (I'll
eventually find time to update the old ones.)
Fixes booting from USB3 on QEMU, and most likely also on
bare metal, where it at least got to usb_disk (it does
not seem to fix the case where usb_disk does not even start.) Whew!
Whenever using Terminal in fullscreen mode, there is a permanently on
tooltip with the shortcut to exit fullscreen mode wherever you leave
your mouse. This is super annoying and as a result I find myself rarely
using fullscreen mode.
Remove the tooltip, and instead add a button to the right of the tab bar
to exit fullscreen mode, as done in WonderBrush and WebPositive.
Change-Id: If42f038da3d644970de6214a31195882d4fc7eee
Reviewed-on: https://review.haiku-os.org/c/1507
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Remove a currently unused copy of it from HaikuDepot.
Change-Id: Idb97fae8e7190da6bc1049b3c1f1df929ea91bab
Reviewed-on: https://review.haiku-os.org/c/1506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We always want to use the shared one from the syslibs package,
never the shared one from this build.
Part of #14842: after this change, the ICU build now fails with
"cannot find libstdc++" instead of an invalid symbol.
* If Volume::Mount() failed opening the root node, the Volume would be
destroyed regardless of the fact that the block allocator was
initializing the bitmap asynchronously.
* For a proper shutdown, the block allocator needs to be uninitialized
first.
* This should fix#15015.
Change-Id: Ice520a12c5c58c785f391009327becfb1f284bce
Reviewed-on: https://review.haiku-os.org/c/1501
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It's quite annoying to install the new debug_server and test with a
crashing app everytime. So add a DebugWindow app that just shows the
debug window and returns the result.
Change-Id: I7238057a508871ce3fffc493cb73126eb852d99e
Reviewed-on: https://review.haiku-os.org/c/1460
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Use radio buttons laid out vertically so that locales with long labels
(no short word for "write core file") can still look nice. This is open
for experiment, buttons laid out vertically are another option. At least
now we have a window t work from, as BAlert doesn't cut it here.
While I'm at it, use a ladybug icon for this one, so it's visibly
different from normal application alerts.
Change-Id: I08ba9573f132901484224e107404348e7dca97f4
Reviewed-on: https://review.haiku-os.org/c/1459
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I2343a6f2db2f95e33991e16c3a9cbd5445f90790
Reviewed-on: https://review.haiku-os.org/c/1499
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* After the gcc 8 upgrade, during bootstrap sources attempt to
load limits.h from gcc before they use our limits.h override
resulting in undefined NAME_MAX, PATH_MAX, etc.
Change-Id: I9204410d0543a033e262124eaf7bcde09db26aa9
Reviewed-on: https://review.haiku-os.org/c/1498
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Now that the previous commit introduced the adaptive thread cache,
the thread cache multiplier is just a "hard limit", and often
not reached. So we can increase it a bit without adversely
affecting memory usage that much.
This synchronizes to rpmalloc upstream commit
5ffaa237989ac2c74dcd77776e4a3983a387a477.
The primary change in this batch is the "adaptive thread cache",
which was created partially from the use-case of our own Installer,
as mmlr discovered when first testing rpmalloc. Our interim solution
was to tweak the thread cache limits, which helped, but not as
much as this does:
Without patch, default cache multipliers: memory usage peaks at around 227MB.
Without patch, our reduced cache multipliers: memory usage peaks at 37MB.
With patch, default cache multipliers: memory usage peaks at 18MB (!!).
the commit.
* Partitions with negative offsets were already ignored, now also ignore
those with an invalid size of block size, too.
Change-Id: I128e38773933f8eadded0977a957f607363cccbe
Reviewed-on: https://review.haiku-os.org/c/805
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
WriterLocker::AcquireWriter(): don't fail when the other end isn't yet opened.
WriterLocker::_CheckBackgroundWrite(): don't fail when the pgrp_id differs.
ReaderLocker::AcquireReader(): fail when the other end isn't opened anymore.
ReaderLocker::AcquireReader(): check available bytes even in case of failure.
ReaderLocker::_CheckBackgroundRead(): don't fail when the pgrp_id differs.
Change-Id: Ice2bd119cbec2afc9ebd40714e4307856f540ea2
Reviewed-on: https://review.haiku-os.org/c/1418
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* it seems 36 bytes is the length of a short inquiry request, so use that.
* also remove a data_length check on SCSI_DIR_IN, a zero value is actually
allowed.
Change-Id: I6618f59626c2540d95b5a8b900d758ec65b11b24
Reviewed-on: https://review.haiku-os.org/c/1487
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
get_memory_map_etc() allows to not need an additional empty entry.
also fix a TODO
Change-Id: I1b5dc3e65267ccba2a21c7162cfc2504b16ad8f7
Reviewed-on: https://review.haiku-os.org/c/1490
Reviewed-by: Rene Gollent <rene@gollent.com>
it seems possible that a file descriptor is still opened after the device
is uninited. at least handle properly the situation.
help with #15089
Change-Id: I76fb41a8439ab7350ce4d781511aceb6496847c3
Reviewed-on: https://review.haiku-os.org/c/1486
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
