Previously this code iterated over children, but only ever looked
at the parent team's thread times.
It seems this has been broken since the code was originally
introduced in 2004.
On my darp10-b it ends up way above 4GiB. Fix is to add 64-bit entries to
32-bit GDT. Then we use this temporary GDT in order to enter 64-bit mode
and then reload correct gdt once we're in 64-bit mode
Change-Id: I69ec32904bbbb23adbe695de0538dc2100f40b48
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9004
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Otherwise the ownership isn't clear: if the exception is thrown
after the item partially initializes, the message might get
deleted by a destructor already. This way, the ownership is clear.
Otherwise, BMessage allocations and frees don't really get
checked by the debug heaps, which isn't helpful. Use a
public debug heap function with a weak definition to detect this.
While at it, drop the full MIT license from the header and use
the common shorthand.
Should help with diagnosing #18905.
I was experimenting with forcing the CheckVisitor to always rebuild all
indices, when I got a KDL from a Tracker process that I had running
a query in the background. The fault address was invalid (0x7b4493418),
and the stack trace was bfs_read_query -> GetNextMatching ->
TreeIterator::Traverse. That method read-locks inodes, and it looks
like query references to inodes are managed correctly.
This seems like the most plausible culprit for missing locks. I didn't
manage to reproduce the KDL, unfortunately, but hopefully this resolves
it nonetheless.
The ring buffer is now mostly atomic, with only a lock needed on the
write end, not the read end (removing this wouldn't be possible without
switching to allocating chunks of the ring non-linearly, and probably
isn't worth it.)
The big "request lock" is now broken up into 2 spinlocks and a R/W lock,
all of which stay unlocked or read-locked only except for short periods.
"stress-ng --pipe 1" (with "--timeout 5s --metrics") goes from ~230 MB/s
to ~2.5 GB/s in my VMware setup with this change (it concurrently reads
and writes 4KB buffers). This is still a ways off from the ~7 GB/s that
Linux gets on this same setup, but a significant improvement nonetheless.
Compile performance seems about the same; there might be an 0.2-0.8s
improvement (both with and without -pipe) out of ~24s in a rebuild of
libroot (with 4 cores), or that could be just noise.
Change-Id: I9d911f82bb36ed3149e759b94632294a0aa33a41
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9058
Reviewed-by: waddlesplash <[email protected]>
Fill/StrokeBezier always have 4 points so passing point count is not
needed. Point count is not passed to BView drawing API and not stored in
BPicture data.
Change-Id: Iddb32bd493143d4450acfb76bdc56fc02136448e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8560
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Includes an optimization to use memcpy where possible, and protection
against aliasing undefined behavior.
Also clean up the Jamrules for the kernel's usage of musl methods.
This is still used in various places, so we should be clear about how it
is supposed to be done. It should avoid people learning from repeating errors
that others have already made.
Change-Id: I2468e51e62658bfad499c22294dd8a34c8aa8c90
When userlandfs_server is set to something other than multiple
launch then it becomes impossible to mount userland filesystems
of different types at the same time.
Change-Id: I1e41ddb938af8813f76409f0911c577571936450
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9053
Reviewed-by: waddlesplash <[email protected]>
In some situations an app launching in the background will steal our
status as the active application which causes HideCursor() to fail when
the screensaver resumes. This is particularly noticeable when the
screen lock is used early in the boot and things like Tracker and
Deskbar are still launching.
Change-Id: I37c432d277ce30716b9c98ad6a500c9313cbea92
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9045
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
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.
Augustin Cavalier