This facility is used by the kernel to notify the low_resource manager
that it failed to allocate something. But if we are in (e.g.) CRITICAL
low-resource state and this method is used to notify that a large
allocation failed, we would previously revert to NOTE state, while
we should stay at CRITICAL.
* Add kDeleteSelection command alias in Commands.h, keep kDelete.
* Add kMoveSelectionToTrash and use it in place of kMoveToTrash.
- kMoveToTrash in kept in tracker_private.h for use outside.
* Create a new constant kRestoreSelectionFromTrash for Tracker.
- Move kRestoreFromTrash to tracker_private.h
Change-Id: I3cdefe97e8359fb53bacfc3319b046b051c6f7db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8225
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
They were ignored and unused; and in fact can't be made to work
properly since the block_cache always operates on exactly block-sized
buffers, and doesn't have contiguous buffers of multiple blocks
to hand out at all.
No functional change intended.
This mostly reverts commit 19141f2110472c0b9b5227e5411f7e1b9f98fe8b,
thus restoring most of the changes from 8b813adf6df7c4ec2c988888a5b6ef2e398aa103.
However, we keep these ranges inside the kernel args ranges for now,
as they're used in the 32-bit non-PAE case at least.
Change-Id: I966d3269414dd02713cdda9852f5a4a212d85be5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8463
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way, on systems with lots of RAM (> 100 GB) where the page array
will wind up taking > 1 GB, we don't consume all the available memory
below 4GB before even getting out of the early boot process.
When we run out of memory above 4GB, the "expand upwards" loop will
try expanding the previous ranges, and then the "expand downwards" loop
will expand the range starting at 4GB downwards if there's memory below.
So if the memory before 4GB is needed, we'll still allocate it.
Fixes #19117.
Change-Id: Ic20934ccf8ea7f6b1d4bff1af4a09cf1688147d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8448
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
1. Only do low battery processing if the battery being queried is the
"virtual aggregate battery" (ID -1), this fixes the issue of spurious
and duplicated low battery warnings whenever the extended info panel is
open (and therefore multiple batteries are being individually queried).
2. Calculate the time remaining separately after adding up all the
individual battery values, this works around batteries which are not
currently in use returning -1 time_left which caused the aggregate to be
incorrect if the values from the driver interface are simply added as-is.
An example situation to illustrate item 2:
Battery 0 capacity: 20,000mWh
Battery 0 draw: 0mW
Battery 0 state: Unused
Battery 0 time_left: -1 (since it currently has zero draw on it, it has
"infinite time left" if looked at in isolation)
Battery 1 capacity: 20,000mWh
Battery 1 draw: 10,000mW
Battery 1 state: Discharging
Battery 1 time_left: 2 hours
If the time_lefts are added together (even if battery 0 is ignored for that
calculation), it'll show 2 hours left despite there being 40,000mWh of total
capacity for a 10,000mW draw. We now treat all batteries together as one large
one instead, calculating the draw/capacity on the totals which gives an
accurate number.
This fixes issues 2 and 3 in bug #19167.
Change-Id: I1b9a0c3dd47f917da86becfcfebed7b35b3422d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8462
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
All other uses of this definition was removed many years ago...
In addition, I'm certain this aspect of POSIX support is complete now.
Change-Id: I309779d8e895efeb6b2b7c107bf2ef038d0a6612
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8458
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Another regression from hrev58236: the code assigned start then size
previously, but there was another temporary that made things work
properly that was removed in that commit.
Fixes #18140.
1. fOnline made sense when APM was the dominant power interface
("online" is "charging" in APM-speak) but it's confusing now that
ACPI is the primary system and specifies more granular status.
Eliminate fOnline and check specifically for charging or discharging as
needed instead.
2. In multi-battery setups batteries that were neither charging nor
discharging were shown with the lightning-bolt charging icon due to the
lack of granularity in fOnline, now shows a paused icon instead.
This solves the first point in #19167.
Change-Id: If723b6b9a4695427d09075680a8ef435b3c1ac54
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8456
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 8b813adf6df7c4ec2c988888a5b6ef2e398aa103.
This does not properly handle the case of 32-bit page tables that
the kernel will continue using (i.e. non-64-bit, non-PAE). So,
some other solution will need to be found to not leak these
and the bootloader heap.
* Minor tweaks to POSIX sys/param.h for style.
* Don't redefine alignment macros in BSD sys/param.h even conditionally.
And add a few more macros from the real BSD sys/param.h, for convenience.
(Most of these are also declared in musl and glibc's sys/param.h)
This reverts commit b6554e72fc67652007c4d06317144af6427f0681
which added the --with-python flag. Using environment variables
to specify host and cross tools is how the rest of this script
behaves, so let's be consistent.
Fix different order of arguments between definition and declaration
of TTracker::SelectChildInParentSoon() and
TTracker::SelectChildInParent().
Pointed out by cppcheck.
Change-Id: Ie78089c80d77f8f687fb9e63883f0ce7b2e2785c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8379
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Fix different order of arguments between definition and declaration
of BAlert::_Init().
Pointed out by cppcheck.
Change-Id: I59af49f8d8789bc96df8ad6da6bc499d322771d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8378
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Some systems may be using wget2 symlinked to wget (Fedora,
currently), which doesn't support --retry-on-host-error.
Change-Id: I9fac080e7ac1cc4c39a03f6c27e9c42f8697ecff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8336
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
on a fresh Haiku install, Printers window title is hidden
due to the window position. Also use a better filename
for the window position settings.
Change-Id: Iee6a8fd0d992c5265f07082e5df99c577433b21d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8420
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
In testing, the allocation sizes I was seeing were all multiples
of the page size anyway, but of course there's no requirement
that they are, so we need to round here.
Pointed out by mmlr.
Just start the kernel allocations after the end of the identity map
(i.e. the first 8 MB of RAM.) This way, we can avoid putting the
bootloader heap and page table memory into the kernel ranges
at all, which avoids leaking it.
Technically reverts 039f93ce5eeef9ff027f71ad6b69c9bc78c2b0fc,
but just moves the call elsewhere.
Should fix #19164.
Change-Id: I3f240d4a28a4ec522382440944a3c80a74bbaa0e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8445
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The most likely case is that the last range is the one we actually
want to try expanding, so this should be a slight efficiency gain.
But it also will help in avoiding allocating "low" memory when
it isn't necessary.
This way, the Pipe won't be seen as "idle" when there are still
transfers in flight with references to it.
May help with diagnosing or even outright fix #17549, #18768, #17799
and #17348.
