* 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 13a5c7f91f356541faaec72888533fc7a156c3da,
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>
This basically reverts the changes in this function back to before
5b4d5ef89794bc57bcc0a0647af53d66ba0f6ee8.
As c686c2216cbe49683cdfe81b878748252ab9eb0e is left intact, #19047
is still fixed regardless.
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.
Otherwise, all RAM that has a more specific type than the physical range
will hit the assertion below. We also don't want to return the type
set here, so put this check before the effectiveType check.
Change-Id: I703242221771732c69accce66380b5a0efdc77e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8345
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
hrev55002 unintentionally turned a single click in the resize corner of
a window into a minimize command. Change that back and minimize only on
double-click, like with the tab and other border parts.
Fixes: #19137
Change-Id: Ic9c76c809531d718fac911eaf668770edc3e5b89
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8427
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Update size of registersArea[] to fix index out of bounds
in init_bus() and uninit_bus() caused by mismatching
between sizeof(registersArea[]) and loop counters.
Pointed out by cppcheck.
* actually use index to populate registers and registersArea arrays.
Change-Id: Iec6337c7dd475bb86f94fe8f2a7b8fed9776ee28
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8376
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Instead of traversing the list of input devices when we are not given a
mouse name, update a list of currently running ones on device start and
stop. This makes the input_server message loop independent of other
threads holding the device list lock.
Fixes: #19100
Change-Id: I2d0d55da04fa506bef88bf731e1a719a64958a17
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8359
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Don't let users format a volume with more sectors than can fit in
the 32 bits that the FAT spec provides for storing the sector count on
disk. Since dosfs_initialize() assumes 512-byte sectors, this
will truncate FAT volumes at ~2.2 TB when a user tries for format
a partition larger than that.
* Mount read-only if the sector count read from disk is lower than it
should be.
* Account for an unrelated overflow in struct device_geometry that
could theoretically occur when mounting a large FAT image file.
* Set the struct mount read-only flag earlier during mounting, to
avoid a fillinusemap error when changing to read-only inside
fat_volume_init.
* Addresses #19079.
Change-Id: I3d15940dc18f50e5c8562fefee3b1749c4b93b6f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8426
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
