If we've gotten to pack_irqs, it means the current CPU is idle,
so it's not totally overloaded. We then check whether the "small
task" core is less loaded than us, or whether it has a significant
load difference from us, and bail if it doesn't.
This avoids thousands of unnecessary IRQ reassignments when
using power saving mode.
Follows up #18588.
(cherry picked from commit 5ba228dfc6fbf87de734d3f08369c824bd4553a3)
Change-Id: Idc914023911f374ec70a87e13437ce388bcdbd8a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11520
Reviewed-by: waddlesplash <[email protected]>
pw_gid and pw_uid aren't pointers, so checking them for 0 just
meant we didn't change the UIDs if we were something other
than root.
(cherry picked from commit acf0e80dc0fe1ae63d89211dfd28133a254a9753)
Change-Id: Ia567d61f645356bb122dd1bce99c581369f8f19f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11498
Reviewed-by: waddlesplash <[email protected]>
As they usually are.
Also delete an unused utility function.
(cherry picked from commit 8cd127ed218340c7d293f1dd94a60ab479204c92)
Change-Id: I43ad195f24c2bd26e875715ea18a63b1222d4e52
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11496
Reviewed-by: waddlesplash <[email protected]>
On SMP systems, we may call ioapic_assign_interrupt_to_cpu from
multiple CPUs at a time, at least under low-latency mode.
May fix#18588.
Change-Id: Ie76e4127b05a8abc5f411d7719997dcfff9c2ff0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11491
Reviewed-by: waddlesplash <[email protected]>
This is a separate thread that takes care of actually freeing vnodes,
so we can avoid doing that (or doing an expensive "free unused vnodes")
from some random thread that called put_vnode.
We still (try to) free vnodes directly in unlink(), though, so that
removal writes go through.
Note that the "reenter" parameter is now load-bearing, as put()
calls that come from a filesystem are executed directly instead of
being deferred. This is necessary in the unmount case.
This should break the deadlock in #20234.
Change-Id: I458f4003b9b8014ca326d477df4782492d8db437
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11444
Reviewed-by: waddlesplash <[email protected]>
(cherry picked from commit bc46fb3e9a83dca0d684bc0d9f1518aafac945be)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11483
We do the same for mmap. This is at least a little better than
only having "pthread func" for pthreads that don't get renamed.
(cherry picked from commit fdc03c5ef9f386e84b9229c667ddba11fabed55e)
Change-Id: Iaaafc4f5393537d3c3e16da04ed12bc56adb88ff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11423
Reviewed-by: waddlesplash <[email protected]>
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.
Augustin Cavalier