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 039f93ce5e,
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.
This avoids leaking the bootloader heap memory into the kernel.
Ideally it'd be dropped automatically, but in seems in many cases
it isn't (even on EFI).
Adjust platform logic to always remove the physical allocated range,
and ignore the return code and reuse the memory anyway if we can.
Previously, there was only platform_init_heap/platform_release_heap,
which allocated a single static heap region for the heap to use,
and any subsequent heap allocations had to go through the standard
platform_allocate_region, which allocates regions visible both
to the bootloader and the kernel.
But as mentioned in previous changes, it isn't always easy to
release regions allocated that way. And besides, some bootloaders
(like EFI) use a completely separate mechanism to allocate
bootloader-local memory, which will never get "leaked" into
the kernel.
So instead, refactor all platforms to instead provide two
new methods: platform_{allocate,free}_heap_region. On EFI
this is easy to implement; on most other platforms we have
logic based more on the old platform_init_heap or allocate_region.
(On the BIOS loader in particular, we can only fully release
the memory if it's the last thing we allocated in the physical
addresses. If the "large allocation" threshhold is lowered
back to 16 KB, then we are unable to do this enough times
that we will run past the end of the 8 MB identity map and
thus fail to boot. But with the larger threshhold, we don't
leak nearly as much, and don't hit the threshhold.)
This should further reduce the amount of bootloader memory
permanently "leaked" into the kernel's used memory, though
on some platforms it may still be nonzero.
Change-Id: I5b2257fc5a425c024f298291f1401a26ea246383
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8440
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Remove unused SetTo; clear Address/Size to 0 on init.
* Free all LargeAllocations in heap_release. (This method isn't
actually called by default before kernel entry, though, so
it probably doesn't matter much.)
Change-Id: If038274adcd65adae527235d16860af659ef37b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8439
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Will be used in following commits.
Change-Id: Ica89d28cbf6980aca8dc347dfdcb200a0e637e9a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8442
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It should be OK to call this during kernel startup without using
reservations, since it's mostly used for fixed memory ranges
specified by the bootloader.
Also turn a later dprintf into a panic.
page_num_t is typedef'd to phys_addr_t, so it's 64-bits on 32-bit
platforms with PAE. In fact it's been so since the introduction
of phys_addr_t, so this comment was obsolete from the start...
If the existing allocated ranges are from physical memory ranges that
are just too small, then we'll need to start a new "allocated" range
based on the next-available physical memory range.
Should fix the "PANIC: error allocating early page!" tickets
(i.e. #14659 and friends.)
Not all platforms can properly release memory allocated via
platform_allocate_region() at present; in particular the BIOS
loader seems to (at least partially) leak it. And due to how the
kernel args ranges are handed off to the kernel, it seems
allocated physical pages that aren't virtually mapped are
leaked at present as well.
That seems like a bug that we should likely fix, and moreover
the heap shouldn't use that facility at all (but instead
request bootloader-local memory if possible; on the BIOS
loader that will ultimately go through similar logic, but
on e.g. EFI it will be entirely separate.)
But in the meantime, we can just increase the size of the
"large allocation" threshhold so that packagefs temporary buffers
(of 64 and 93 KB) stay on the main heap, and don't hit that
facility at all. The "maximum boot loader heap usage" seems
to go up by about ~200 KB with this change (e.g. 588 KB -> 797 KB),
so increase the default heap size by 256 KB to compensate.
This fixes most of the rest of #14831: memory usage after the
boot has finished is down by over 100 MB (!). The remaining
problems and leaks can be dealt with in later changes.
This reverts commit 13a5c7f91f,
and adds an inline comment explaining why this actually isn't allowed,
despite "working" in most circumstances.
Doesn't affect anything in default builds (KDEBUG_RW_LOCK_DEBUG
is not enabled under KDEBUG.)
We already started at the first-free in the block bitmap, but
after that we would just check individual bits as we went along.
Now we skip forwards to the next free block when encountering a
used block, by comparing to UINT32_MAX (all blocks used) and using
ffs() with a bitwise NOT (to find the first unused block in a chunk.)
This will benefit fragmented partitions more than non-fragmented ones.
I didn't see a significant speedup on my compile benchmark in a VM.
Fixes #18929.
X512 tested this patch and confirmed it reduces CPU usage on a
partition that he saw long times spent in AllocateBlocks on.
Change-Id: If71b5e24c585c2cc08879c8aefc80af8ae7da91f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8186
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Tested with VMWare Workstation Pro 17.6.0 with Haiku x86_64 hrev58201.
To test, had to manually open the .vmx file associated with the VM and added the line:
ethernet0.virtualDev = "vmxnet3"
Change-Id: Ic76dcc61583707345bee46624814a38f66eb4f9f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8438
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This saves 40 bytes from the size of Node (on 64-bit architectures.)
UnpackingDirectory is still at 200 bytes, while UnpackingLeafNode
is now 96 instead of 136. This saves ~5MB of memory on my system
(UnpackingLeafNodes go from 16.2MB to 11.2MB.)
The general strategy is for Directories to use their own locks, while
all other nodes read-lock their parent directory during use. There are
a few edge cases around node creation and removal in the case of
non-directory nodes; see inline comments in Volume's
_RemoveNodeAndVNode as well as packagefs_put_vnode.
Since it's now possible for a node's parent to change or be deleted
when we don't have the lock (but only a reference), we need a lock
protecting just that field to hold while we acquire a reference to
the parent. (Right now, this is just one static rw_lock for all Nodes;
this could be changed in the future if necessary, but it seems performant
enough for the moment.)
Tested with basic system functionality, installing/uninstalling packages,
uninstalling packages with files still in use, HaikuPorter builds, and
more. All still seems to work as expected.
Change-Id: I054187316c66b77ea1951c6d1ea8e5b75715c082
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7930
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The "open" button on an installed package is currently missing the
name of the application to launch.
Fixes #19147
Change-Id: I24cca3c5f1f4f11f81e99e4223042a0081c7babf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8434
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* When the page_protections array is allocated, we should clear the
protections from the area's flags, since they aren't used for
anything when the page_protections array is activated.
* When set_area_protection is called and there is a page_protections
array in use, it should be freed, and we should reset the protections
on all pages.
* Add some tests related to these behaviors.
