This cleans up a lot of subtle or hidden inconsistencies:
* Drop the "exactAddress" parameter. It was added in hrev15708 (2005),
but all callers in all bootloaders passed "false" to it until 2022,
when one codepath in the ARM32 EFI loader started using it.
* Adjust EFI's platform_allocate_lomem to platform_allocate_region_below,
and add a platform_assign_kernel_address_for_region(). This allows the
aforementioned ARM EFI codepath to continue to do what it wants,
which is to get an identity-mapped trampoline page, without having
functions with confusingly different semantics ("allocate_lomem"
assigned the virtual addresses as identity-mapped unconditionally,
but it didn't insert these into the virtual allocated ranges.)
This also paves the way for other EFI loaders to use this method
to allocate memory below whatever default the boot services
would give us.
* Drop fixed virtual address allocation for all arches on EFI, with the
exception of fixed addresses inside KERNEL_LOAD_BASE, same as on
other boot platforms. Anything which wants fixed virtual addresses
outside that region can use the new "assign kernel address" method.
* Validate kernel base and size against kMaxKernelSize, instead of
assuming it fits. This matches behavior of other boot platforms.
Ideally we would have some more generic routine for mapping the
kernel, but this suffices for now.
Tested with x86_64 and ARM; both still boot (well, ARM boots as
far as it did before this commit, anyway.)
Change-Id: Ieb4fba752994101191a2335cb5395eb2b726fcbb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9024
Reviewed-by: waddlesplash <[email protected]>
On my darp10-b EFI works and leaves APIC configured in x2apic mode. While
we can switch it back to xapic, it's better to support x2apic properly.
Change-Id: Ia00c69ccffc508497f45217462cdb6868c4629f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9005
Reviewed-by: waddlesplash <[email protected]>
Some newer hardware does not have COM1 at all. It seems this isn't
easy to detect, and so the best solution is just to use a maximum
spins timeout. This is in fact what FreeBSD does already, and the
"timeout" value of 256K unsuccessful spins is the same one they use
(see "COMC_TXWAIT" definition).
If the timeout happens once, then just disable serial or mark it
as timing out and don't try again (unless we eventually load
a settings file that specifies a new serial port.)
Tested on a custom build of QEMU hacked to reply to all reads
to the serial ports with zeroes (by just adding "return 0" to
"serial_ioport_read".)
Fixes#18561. May fix#19425.
No functional change. I had been testing a minimum time before
showing the password window while still keeping the screen locked.
We can simplify the check for now though.
Change-Id: Id67c1ea07bb04ae477cd2f021fb15725c0144dbe
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9022
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
AFAIK this has always been this way, however, the confusion seems to
be that pose->CalcRect() takes false for minimal rect while pose->Draw()
takes true for full-draw so they are opposites of each other.
This means we draw all columns on Invalidate(), not just the first one.
Change-Id: I40ddf5fa75b46d6da987fd5d5f83cdc4782fa851
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9019
Reviewed-by: waddlesplash <[email protected]>
See inline comment: this can happen in the case of fork() pretty easily.
If it happens more often than that, something may be wrong; so for now,
at least, add a syslog print (under KDEBUG only) indicating that a full
recompute of the area commitment is being done.
Fixes#19337.
Do not _Uninstall() whenever we _Hide() in BMenu again.
Fixes menus in Terminal and elsewhere.
Change-Id: Ic89ee2e4b0a94cc11c7a4091d9ce01e6ff6bb915
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9018
Reviewed-by: waddlesplash <[email protected]>
The buffers are large, and we will pretty much always hold the block
cache lock anyway while allocating them, so a depot is just a waste.
Also slight code cleanup to the cache notifications declarations.
Failing here with ENOMEM means SIGSEGV sent to the process, which will
likely result in it getting killed.
All needed memory for mapping should be reserved upfront, or we should
at least fail earlier when trying to reserve pages for mapping. So
failure here indicates a problem with kernel memory accounting, and
shouldn't result in processes crashing, ideally.
And not just their flags. This method is only used in the boot process
as part of vm_free_unused_boot_loader_range() as far as I can tell.
All the other unmapping routines already clear table entries.
Closes#14673.
_Uninstall() before _Hide() in BMenu because the window must
be available when we _Uninstall() especially for shortcuts.
Remove #define and always assume USE_CACHED_MENUWINDOW.
_Uninstall() whenever we _Hide() in BMenu.
Change-Id: I5dae85f6edf1f0b4ccf67a6d9d77470576671cee
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9012
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* Remove the unused width param from TextWidget::Draw(), we don't need it.
* Simplify UpdateIcon() with new _ListIconRect() and _IconRect() methods.
* Remove bad drawView->SetDrawingMode(B_OP_OVER) from TextWidget:Draw().
* Set cut and dragged item text based on high color instead of low color
initially, then switch to low color when drawing text widget since the
low color has been set.
* Restore cut item and dragged item high color after drawing outline.
* Fix regression in list view drawing dragged item label.
* Use correct CurrentPoseList() in list mode and icon mode.
* Always break when encountering NULL pose, don't bother to continue.
* Invalidate instead of redrawing on Select all.
* Split Extent() into ListModeExtent() and IconModeExtent().
* Init fListElemHeight and fListOffset in the initilizer list
* Init sFontHeight in earlier in InitCommon().
* Rename resultingIndex to resultIndex to make it fit on one line.
* Update pose and text widget CalcRect() to position everything
(it basically already was but this standardizes ceilf and floorf).
* (use / 2.f to avoid trunction, just in case)
Change-Id: Idc8ccffdbe000bb126ab195e9739e7e5b9392bb3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8971
Reviewed-by: John Scipione <[email protected]>
This can be used when you want a keyboard shortcut to immediately lock
the screen or to lock the screen at boot time.
Change-Id: I12192fd3db9ae7a05046dee8e6d878c7fb3095a9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9011
Reviewed-by: waddlesplash <[email protected]>
There doesn't seem to be a need for multiple launches of screen_blanker
and it can cause some problems when screen_blanker is being launched
manually(e.g. via keyboard shortcut)
Change-Id: Ib2ac49a5539dbc668725bdf2126ea92646c878d9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9010
Reviewed-by: waddlesplash <[email protected]>
This replaces the non-functioning "Network password" option that was
never implemented.
Change-Id: I9b7362f4e05d7f1a4be321e1a9aade62559794d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9009
Reviewed-by: waddlesplash <[email protected]>
Having a cache larger than its area is harmless, but resizing the
cache too early could lead to not having enough memory available
if we hit errors and need to resize it back later on, which would
be bad. So put the Resize() that shrinks the first area's cache
at the end, to avoid such a potential problem.
This makes cutting larger caches much less likely to fail.
In the case of overcommit or resizePriority == -1, we already use
similar logic at the end of this method.
This can happen if cut_area() in the kernel fails to reserve memory
for the cut caches. If it happens, just re-add the chunk to the free
maps and return a success status.
There was one case in the old logic where we would double-release
references: if the secondCache->Resize() failed (or the Adopt(),
but this is much less likely to fail.)
Just reset the cacheChainLocker after we unlock all except the top cache.
It will unlock and release the reference as applicable.
Any that do occur in this state will be errors, but the page fault
handlers try to reserve pages to handle the fault even before checking
if the fault can be handled, so we could hit deadlocks or double-locks
before getting to the panic() without this.
Would have helped with diagnosing #12772.
This is relatively harmless in all cases except where the lower 32 bits
are all zeroes, as in that case we would never get a timer interrupt.
In all other cases we would just time out too soon, and the timer
interrupt handler would reschedule.
We need to add clock divisor selection to this module so that we can
be sure that at least reasonably-sized timeouts (a few seconds, e.g.)
will not overflow 32 bits, though.
Change-Id: I62c829aa740bbd611aab788854d722cfa659a0d8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9001
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
We use the TSC to measure the APIC frequency, but the TSC frequency
is only fully initialized in the kernel (where it's read from CPUID
on recent hardware).
Furthermore, on some more recent systems, it seems there may only be
X2APIC and no MMIO APIC timer at all, and the bootloader does not
handle that case.
The method in the kernel uses spin() instead of a fixed instruction
count as well as system_time_nsecs() and a double for (hopefully)
more accurate calibration.
At least on VMware, this method seems more accurate: the APIC frequency
read from the hypervisor CPUID leaf is 66,000,000; the old method in
in the bootloader yielded values like "65,801,075" and "65,106,382",
while the new one yields values like "65,963,920" and "65,962,580"
(those pairs of values are from two consecutive boots.)
The difference was sometimes similar (but smaller as a percentage) in
QEMU with software emulation: e.g. "993,218,085" vs. "992,965,761". But
sometimes it wasn't: e.g "991,619,585" vs. "993,689,669". (QEMU in
software mode doesn't report a frequency via hypervisor CPUID leaf.)
Change-Id: I4fb8535d1d984f13867e2f84e7dfad1ceed42c13
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8999
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* If WAITING is not set, we don't need to call unblock().
* When exiting wait() and there are no more waiters, zero out
the lock entirely.
Helps with #18216 a bit.
This way we are less likely to encounter "Failed to acquire ... for
a long time", especially when onscreen debug output is enabled.
In the pending repeats checker, we wait at most 100ms to acquire the lock,
since this is run on the "kernel daemon" thread which we don't want
to block for too long.
In the device driver architecture documentation there is a
TODO for adding an image representation of the device node
tree in Haiku.
This patch adds a .svg image for the same, removing the TODO
line.
Change-Id: If5d1e3ee5abe7d6e84245c837b5cb2f1f0cb670a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8983
Tested-by: Commit checker robot <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: nephele nephele <[email protected]>
Autocomitter