This reverts a small portion of f5842905e3.
I added these asserts instead of the deletions to hedge against
the Team/Thread reaching this point with timers still active.
But it seems that doesn't happen, while if thread init fails
due to OOM, we have the default timers still present, which need
to be deleted.
Fixes#20154 and #20148.
* Retrieve info from the stored configuration in GetScreenMode &
GetScreenFrame if needed.
* Use the stored configurations in _SetCurrentWorkspaceConfiguration.
The last part seems to fix#20136.
Otherwise we could block forever if the data size is
larger than the buffer size. Partial writes are an
expected behavior of stream sockets, so this should
not cause any other problems.
Fixes#20163.
We were passing our own fs_vnode, not the underlying filesystem's.
I guess this was just never tested, because it would've always crashed?
Fixes#20156.
* Don't unlock in ContainerWindow's constructor; instead leave
the BWindow locked, as the BWindow constructor itself does.
* Call Run() at the end of TFilePanel's constructor. This way,
the TFilePanel will be in the state existing applications expect
it to be after the constructor runs (i.e. running and not locked),
while also performing all necessary initialization before actually
doing that, to avoid races.
* Drop TFilePanel::Show as it's not needed now.
* Revert changes to BFilePanel::Show as they're now not neede.
I retested #19499 with this change, and couldn't get it to reproduce
(while it reproduced easily with Run() called at the top of TFilePanel()
followed by the Lock/Unlock scheme.)
This should be a much simpler solution that hopefully will cause no
regressions in any of #19499, #20125, #20128, #20131, #20144.
A comment in the header says the cursor handling functions "do their
own Read/Write locking", but they didn't actually lock the framebuffer.
Should fix#20141 and #2539.
* Ensure memory is locked before doing virtual->physical translation.
* Make sure get_memory_map_etc actually returned an entry.
I didn't see either of these trip in some basic testing though.
* Properly handle copy-on-write in the case of consumers, same as
set_area_protection. This seems to fix most of the remaining problems
in boehm-gc's mprotect-VDB.
* Do not call set_area_protection if the whole range is covered,
as it tries to acquire address space locks, which can lead to
deadlocks: that was the cause of #20138. Instead, handle changing
the protection of all pages in here.
* Don't unmap pages of lower caches; just don't allow writing to
those pages. This allows us to avoid unlocking the translation map,
and also should mean a lot fewer page faults, hopefully improving
performance.
Fixes#20138.
Untested as I don't have hardware with supported brightness control,
but the changes are relatively straightforward.
Should fix#20134.
Change-Id: I45b78bc8006a54cc5ba4f65a026df99401c621b5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11083
Reviewed-by: waddlesplash <[email protected]>
Otherwise, the host won't be able to modify the guest FPU (and we could
clobber the state, too.)
This doesn't seem to fix the general problems seen so far, however.
The bootloader is now only responsible for setting up Protected Mode
and Paging. It otherwise preserves the existing CR0, and leaves setup
to the kernel.
The kernel now sets CR0 for each CPU in preboot_init_percpu().
Some redundant sets are removed from x86_init_fpu, which now
panic()s in the case where we don't have a FPU, and avoids
unnecessary prints.
This fixes a massive oversight where CR0 was never reset on x86
systems booted using the EFI loader, except on the boot CPU! That
meant that NUMERIC_ERROR and possibly even WRITE_PROTECT were
simply not set on non-boot CPUs, unless the EFI BIOS had set them up
already. (On the BIOS loader, smp_start_kernel() ran on all CPUs.)
Fixes NVMM initialization on non-boot CPUs on Intel hardware.
At present, it can boot TinyCore Linux to a GUI, but a Haiku
image reaches the rocket before crashing with an NVMM error,
when tested under nested virtualization in VMware. (It seems
my Intel device is a few generations too old and doesn't have
all required features, so I wasn't able to test there.) So,
some more work is still required, it seems.
* VMUserAddressSpace & VMTranslationMap64Bit will need to be inherited from.
* vm_soft_fault & vm_unmap_address_range will need to be invoked directly.
* map_backing_store will need to be invoked directly. The whole concept
of "backing stores" is long merged into VMCache anyway, so at the
same time, just rename the method to "vm_map_cache".
Methods added to the internal vm_priv.h; they should not be needed
except in special circumstances.
* Drop screen_configuration::is_current. This just caused significant
confusion and problems, because values could get out of sync between
the Stored and Current screen configuration storage.
* Try to match by monitor_info always, not just ID.
* Add the current vs. stored Configurations distinction to VirtualScreen.
This will populate the CurrentScreenConfiguration object during
initial configuration of screens.
Fixes app_server not properly reverting to the original resolution after
apps that change the resolution quitting, which was seen in #20042.
Change-Id: I61c9ee4c5b7e755cbb207170d2eddb1d31fd0ea8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11024
Reviewed-by: waddlesplash <[email protected]>
This reverts dbc6b2061e.
Hopefully after the various fixes to APIC timer setup, the
problems that this was causing will be gone. (The users who
reported issues with it did so only on the forums and never
opened tickets, it seems.)
We should just be zeroing any unknown bits, not trying to preserve them.
If the BIOS or other mechanisms left the timer in some other mode
besides "one-shot" like we need, then we might incorrectly preserve
those bits.
This also has the advantage of avoiding config reads in set_hardware_timer.
Even on a single-core software-emulation QEMU VM, we acquire more
than 10k spinlocks per second (sometimes even over 100k.) That makes
sense, as every syscall entry, mutex acquisition (even uncontended,
for KDEBUG kernels), etc. acquires a spinlock. So, reasonably, this
list will always be too small to detect much of anything at this point.
If we need a similar debugging facility, we should store addresses
or thread IDs in the lock structure. That will require a more significant
refactor to locking code, however, and it doesn't seem necessary at this
time, so I haven't implemented that (yet).
* Get rid of the global sUserTimerLock. This was added in 2013
to prepare for the removal of the global scheduler lock, which
is what all these routines previously used. The locking design
was never redesigned since then to accomodate for the changes,
it appears.
* Make CPU timers always locked by time_lock, and the system-time
timers locked by a local lock.
* Make fScheduled load-bearing as to whether the timer is presently
in the team/thread lists or not.
* Don't re-fetch the team/thread every wait cycle. This allows us
to avoid a lock/unlock dance that would otherwise complicate
the scheduling logic significantly.
Tested using the old version of the Open POSIX Testsuite (which
indeed caught some bugs in earlier versions of this patch.) All
12 timer_create tests still pass, including the ones that depend on
timers firing within the right timeframe.
Fixes#20090.
Change-Id: I54dd9a49e72f51711baa0fbf18e5c35a7fafec8f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11007
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
They have been in BeBuild.h since BeOS days, but as this file
is included everywhere in the base system headers, it causes
a bunch of unnecessary POSIX namespace pollution. So, instead,
put them in a config header, and include it from SupportDefs.h,
which should only ever be included by Be/Haiku API headers.
It's a non-standard header we inherited from BeOS. According to the
POSIX specification, size_t should be declared from including stddef.h
and/or sys/types.h, and ssize_t from sys/types.h.
It comes with AVX, so enable it if we've enabled AVX.
This also adjusts altcodepatch_replace to explicitly set NOPs
for the remainder of the patch area.
Change-Id: Ia07549851d86836ff5428635b580c751b4e5b2a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10867
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Enabled by default, but can be disabled via a new settings window
option (which is saved and remembered across runs.)
Change-Id: Ifd49cd734dcf5e4a5e5b3625d23bc2778fa1fa55
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10850
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Putting all the per-CPU messages in one array means they'll all
be on the same cache lines. The cpu_ent structure is cache-line-aligned,
so this means they'll be on separate cache lines.
TCPEndpoint::_NotifyReader() calls notify(READ, _AvailableData()),
which after a close will be negative, so this will set DISCONNECTED
in that case.
Drop the unnecessary duplication from TCPEndpoint::_HandleReset:
the net_socket layer sends READ|WRITE notifications in this case.
Fixes#19969.
Change-Id: I0e10c0280f3c84276b486b0375000153a117246d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10581
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* Implement the TODO about needing to place stubs in executable
memory. This fixes basic ltrace operations.
* Place traces behind a TRACE ifdef.
* Get rid of the "patched table" and find the PatchEntry
using fixed offsets, to improve efficiency.
* Add a "bool trace" to PatchEntry. This paves the way for
tracing only specific methods.
Using LD_PRELOAD_ADDONS=...ltrace_stub.so, trace entries are now
printed on x86_64. However, it seems that the trace stub is clobbering
something, as BWindows don't work correctly when traced.
On a 64-bit nightly, it appears we're already using 16 out of the 20
slots for kernel_args ranges. On a 32-bit bootstrap build with symbols
enabled, we exhaust them (due to the network drivers that the bootstrap
build adds to the boot set).
The kernel_args are later freed by the kernel, so this shouldn't "leak"
any memory unnecessarily. With this size, we only need one chunk with
symbol loading disabled.
We never send it to the kernel but always free it. The kernel_args
allocator is very simple and can't handle frees besides the most recent
data, so this avoids "leaking" some kernel_args memory (it should all
be freed by the kernel later, though, so that only matters for
the bootloader itself.)
Nothing uses it (not even DEBUG_PAGE_QUEUE, it appears),
and it will need to be managed a different way for the
multiple ModifiedPageQueues, if we really do need it.
Use strchrnul instead of strchr, and increment at the end of the loop.
This avoids needing to call _ParseExportVariable in two separate places.
The invocation of line.Append(chunk, bytesRead) was also incorrect,
as bytesRead would be past the end of chunk if chunk had been
incremented. But this wasn't really a problem because BString
does strnlen() on the passed arguments.
Inspired by a change seen in a fork of the Haiku repository on
GitHub.
Also drop the long-double files from architectures where long-double
support is (currently) disabled in glibc config.h.
Should fix#19589 and other long-double related problems on
RISC-V and ARM64.
Change-Id: Ia33ce2791d812eb143b719fb61e69dbf8b70ce79
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10815
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Sam Roberts <[email protected]>
Otherwise we just spends lots of CPU time sending silence.
This also paves the way for stopping the output when all
outputs disconnect, but that's not implemented just yet.
Since this forces a wait inside the mixer for the destination
to actually start, it may help with problems like #19074.
At least in testing, without that block, I got similar symptoms
and crashes, due to the initial 0 value being used to compute
the performance times, and winding up with very incorrect times.
Note that this changes the MultiAudioNode to not really start its
timesource when it gets a TIMESOURCE_START message. Instead it waits
until it gets a regular B_START (via StartNode) message to do that.
Change-Id: I1716e347537c88dcc76163a515e7fbb8c5ccdecb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10643
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Augustin Cavalier