There's no reason to reject them; they should just result in
a zero-byte output.
Should fix#20222.
(cherry picked from commit 4b6aad38968f9fe91712e742aff9166fec6e67a1)
Change-Id: Ifdbe17618d74eca0b873a6808ec0b14a7d38189a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11402
Reviewed-by: waddlesplash <[email protected]>
Instead of elsewhere. Fixes another missed Put(), in VMUserAddressSpace's
_InsertAreaIntoReservedRegion(), and guards against such problems
happening in the future.
Change-Id: If6d87d36225907e281e2341e8b53c461e6954f22
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11381
Reviewed-by: waddlesplash <[email protected]>
They were passed to TranslationMap::Query() directly, assuming that the
TranslationMap would just round down to the nearest page address. This
actually isn't guaranteed in the case of X86VMTranslationMap64Bit and
the physical map area, which uses hugepages, and so adds the offset
to the page address itself.
So, here the logic is rewritten to always pass page-aligned addresses
to Query(), and then re-add the offset for the first page only. We then
increment virtualAddress instead of an offset, making the next Query
naturally page-aligned.
This was the cause of #20142: when the BFS I/O hook was disabled,
virtual addresses in the physical map region were passed down to
the disk I/O routines, which were then mistranslated by this function,
resulting in corruption of adjacent pages by DMA, and incorrect
data in the pages where it was supposed to be read into.
Fixes#20142.
Change-Id: Ibacd00b7f5ce23a7b41c620224ddf8d338b6de4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11377
Reviewed-by: waddlesplash <[email protected]>
The cache may not have all pages needed to be fully locked. Therefore
we have to use B_LAZY_LOCK if it doesn't.
Fixes some KDLs I was seeing when using NVMM against a raw disk device.
(cherry picked from commit 0ea1a0a835e8093355c5ea4fbe08dc9be93e3eb5)
Change-Id: I403eaf2f14677101cdd327d4b99c12318815c116
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11332
Reviewed-by: waddlesplash <[email protected]>
Discovered by compiling with UBSan (it triggered as a compile-time
warning; I don't know if this actually causes any problems at runtime.)
(cherry picked from commit 6b28f736c09757156abadd560e69b8e090e60f25)
Change-Id: I91f6930fd4b9e870ecc1bad357aae2722f252cd1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11329
Reviewed-by: waddlesplash <[email protected]>
off_t is a signed 64-bit type, but size_t isn't signed or 64-bit
on 32-bit platforms. That meant adding a sign bit caused strange
things to happen there.
Fixes incorrect free-memory computations on 32-bit.
(cherry picked from commit cc565c81afd2dfba34de6ced607199d757080a8d)
Change-Id: I294f92ac1279a6311347b5e25341542d8c862013
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11326
Reviewed-by: waddlesplash <[email protected]>
We allocate/free ranges with the write lock held, so the depot is
just a waste, and actually in low-memory conditions hurts (if we
need a Range and there's none in the cache but there were in the
depots, a scenario I saw when trying to boot with a DEBUG=1 kernel
on my laptop.)
(cherry picked from commit ad189ca258d42e68f493c22bb3ce5f904e1589bc)
Change-Id: Id4af983a8b1337f8e90640218fe63402543355f8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11322
Reviewed-by: waddlesplash <[email protected]>
It was a complete no-op before. Now, when enabled, BIOS calls
won't be done past the bootloader, and the Framebuffer driver
will be used instead of VESA.
(cherry picked from commit 7f12208162a5fc676f7a03e050f7671919f4fb12)
Change-Id: Id7670cc060ab5273411222e27467a6dfdbbb9e7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11313
Reviewed-by: waddlesplash <[email protected]>
No functional change. Reasonably we should have architecture-specific
headers for some of these, but that can wait.
(cherry picked from commit 450728b4b717b3ea09fb2145daf2e6a24874c6de)
Change-Id: I887d37a54b44e127e4d1fe46675bf57bc2a392dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11312
Reviewed-by: waddlesplash <[email protected]>
We publish devices in the driver register hook, and if we try
to unpublish them from the device removed hook, not the driver
removed hook, we'll confuse the device_manager and cause it
to do use-after-frees on list iteration.
The two are called in quick succession of each other, so this
shouldn't cause problems.
Fixes a KDL reported by OscarL when unplugging a USB card reader
(which I reproduced with another USB card reader.) It seems the problem
would happen with any USB disk device that published more than
one LUN.
(cherry picked from commit a688b173e7c1e903845b6cac78baa7bd2ea23c31)
Change-Id: Ia9fae3428a45e199cb2c903acfe9c689dfa9bed4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11305
Reviewed-by: waddlesplash <[email protected]>
Avoids the media checker retrying uselessly after devices have been
removed.
(cherry picked from commit a88cbfae4fcaf80d8786d144fccbeb349c3bd91b)
Change-Id: I3fefcbe515bf46bb84b6a6476e9cef7dcbbb48eb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11304
Reviewed-by: waddlesplash <[email protected]>
We want the DriverData not the device_node.
Discovered while working on usb_disk. I wonder if anyone ever actually
used this method for hot-unplug before...? Looking at the source code
of other modules, only a select few try to do anything with the cookie,
and most of those likely don't use hot-unplug.
(cherry picked from commit 5fec48b27d7b4c1c831b93db3d4abc1cfaee4982)
Change-Id: Iaf8973b8212758ba2148ad88832f9f96aa5158f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11303
Reviewed-by: waddlesplash <[email protected]>
This way, we can use it even after the "early" boot phase is over
but before PCI is initialized, and also add the locking necessary
once there are multiple threads.
Should fix#20196.
Change-Id: Ie96daf44cc7c82050d0aa686d0d395228ffa4f20
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11285
Reviewed-by: waddlesplash <[email protected]>
(cherry picked from commit 4e8abe02f6384e6c35895785557b1eeaed85a607)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11287
EFI doesn't have a boot keys mechanism so we just disable the
routine that enables it entirely. Also disable it in early kernel
output before the settings file has been read.
This solves an old TODO, that the page writer could potentially cause
deadlocks when writing pages of different devices back at once. It's
also necessary after the previous change, as otherwise simultaneous
writes to disks with different write speeds would cause the quota
computations to be fluctuating and inconsistent.
Change-Id: I1c485f66625ea9013f17ab4fee007d7d58afd2ea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8619
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Otherwise, if we're marking pages modified faster than we can
write them out, the number of modified pages will just grow
unboundedly. This can lead (e.g.) to `sync` taking multiple
minutes after copying a lot of data to a slow disk. So, instead,
we now have a quota of no more than 3 seconds for all pages
to be written back.
Also drop a TODO comment from the page_writer thread. Since
we only start writing pages if there's at least 256 to be written,
or if someone wakes us up deliberately (which the page daemon
does, if it schedules pages to be written out), we shouldn't
need to wait shorter.
This should fix#5777 and related tickets.
Change-Id: I4d419d149ea780677b462f5fa46cfe4d65044b2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10811
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
It doesn't mean "write to this memory", but rather "this is for
a write IORequest" (i.e. if true, the memory will be read from
only.)
No functional change, but clarifies things around #20173.
The documentation comment just above explains its purpose correctly:
> requests that the range must be wired writable ("read from device
> into memory").
The Be Book confirms, and there are numerous examples in the Haiku
source which are written with this behavior in mind. It appears the
original implementation of this function got it right, but then
it was broken in 550376ffb8 (which,
coincidentally, is the same commit that added the documentation
comment quoted above...)
Primary fix for #20173.
Apple Darwin also extends kqueue to support other object types,
like Mach ports, so we might as well do the same for Haiku (Be)
object types.
Fixes#19974.
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]>
Augustin Cavalier