It seems this is the type of the innermost source cache, not the
topmost cache (which well may be "RAM" if this is an anonymous cache
on top of a Vnode cache.)
Originally VMArea::cache_type was introduced 15 years ago
(commit 0c12332715, 2007)
merely to mirror the underlying cache's type. Somewhere along the way,
it acquired different values. As the VM has changed a lot since then,
perhaps its overall purpose should be re-evaluated?
Fixes#17556.
If these methods are called while the interface in question
is receiving data via a receive thread, we can hit a deadlock
where a receive thread is holding the receive lock and then
tries to call get_interface_address_for_link (due, e.g., to ipv4
checking is_local_link_address), which tries to acquire the interfaces
lock, while at the same time we are trying to acquire the receive lock
due to CreateDomainDatalinkIfNeeded invoking a module's datalink_init
which calls register_device_handler, so we deadlock. (Whew!)
As far as I can tell, we do not need to set Busy() here despite unlocking
the interfaces lock, as the Interface acquires its own lock in
CreateDomainDatalinkIfNeeded.
Observed in VMware when the DHCP client spins for a long time,
and the deadlock occurs upon opening Network preferences.
Instead add a second level to the loop and a small temporary array.
Makes the code slightly simpler (and safer, as there is no risk
of races now.)
Also add a missing "firstCPU +" in the current_frequency calculation.
It seems that has been broken since the frequency value was introduced...
In addition to being slightly more efficient, this also allows one
to see precisely how many vnodes are currently "alive" across all
mounts via the "slabs" KDL command.
Part of the point of published variables is to make them "shareable",
and not require external synchronization. Requiring the callers
to ensure unpublishing does not occur is thus unreasonable, as e.g.
a variable could be unpublished immediately after being notified.
That is the case for some usages of these variables in the FreeBSD
compatibility layer, which under heavy usage, can and did trigger
use-after-unpublishes and then KDLs, at least in local testing.
Instead, only unlock the hash after we have locked the variable.
This is already done in some other functions, so it's safe to do
it here, too. This way, the variable won't be unpublished
while Notify() is running.
This resolves a TODO, and allows B_KERNEL_RESOURCE_ADDRESS_SPACE
to be a bit more useful, as fragmentation will now turn in
to a low-resource notification.
We never included obprintf in the build, and the real obstack.h
exists in the "extensions" folder. Unfortunately, it seems the
BeOS R5 libroot had an obstack.h in the public POSIX headers
directory and exported the functions, so we cannot remove it
completely just yet.
Seems none of the applications I tested yesterday actually used poll(),
because it was completely broken by this.
The previous code assigned this variable inside a malloc() call, though,
which wasn't all that obvious either.
Reset the value of IsFirstClick to true whenever a new game is
started. Without this fix the board gets confused if there is
a card flipped when a game is restarted.
I can't reproduce any of the other oddities in the ticket but
this fixes the egregious repro case mentioned.
Fixes#6932
Change-Id: Ie5cedd7fc2ca411db722d3c24f68fe9aa48f7b5f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5038
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some improvements to allow setting 8, 15, 16 and 32bit modes, and detect
the correct mode number after patching the BIOS automatically, instead
of hardcoding it.
Also move the patching code to a separate file.
Fixes#10570.
Change-Id: I920f448b59ad7373cb8595d92ce3fa52324be67e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4629
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This uses atombios headers to find where in the BIOS the video mode
tables is located. Then, we can replace entries in the table (in a RAM
copy of the BIOS, of course) and inject any video mode we need. To make
the table easy to find, the Atombios headers from the radeon_hd are
reused, but no atombios code execution takes place here.
Change-Id: If1981b1574822d4ce1e072dd6437a727192ce7cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4628
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Get the OEM string from the VESA info block (and also get the memory
size from there while we are at it). If the string is empty, use the
BIOS type (identified in other ways) to still report something.
Change-Id: I8cbd75d19f624a43db05e82d1e1b2a536cc418b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4625
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The VESA standard does not define any way for software to set a custom
video mode, which means normally we would be constrained to whichever
modes the video card manufacturer decided to provide. However, since we
run the BIOS in an emulated environment, it is possible (and even quite
easy) to patch it and inject any video mode we want, provided we know
the format to use and where to put the info in.
This approach was used in the NewOS VESA driver, as well as in
915resolution (a tool that predates the availability of native drivers
for Linux for Intel videocards). Later on it was also used in Chameleon
and Clover, bootloaders that are used for hackintoshes (running MacOS on
unsupported hardware).
This commit implements full support for Intel cards only, AMD and NVidia
will be added later (but there is preliminary code to detect them)
Change-Id: I2c528ba18b3863f486da694860a10761efcbfb3f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4624
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
MSI was never implemented in this driver and only used for a log during
initialization. Remove it for now.
This makes it easier to use the driver on non-x86 systems where there is
no MSI.
Change-Id: I39ccbb82b78ea98c0d045ef07ee9bb28c775e292
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4847
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* move common SMP initialization code to x86/arch_smp.cpp
* factor out arch-specific SMP initialization to
arch_smp_32.cpp resp arch_smp_64.cpp
* implement smp_trampoline for x86 32-bit EFI loader
* rename SMP trampoline for x86_64 to long_smp_trampoline
* add new argument virtKernelArgs to arch_smp_boot_other_cpus
as the kernel args are not identity mapped on 32-bit architectures
Change-Id: I30d0bb1fa9bfb08f6784a2af34eb83d6b64afa57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4869
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
In the Terminal settings window, the pop-up help text for
"Tab title:" had two entries for "%% - The character '%'.".
Removed one of the entries.
Fixed the spelling of some constants: kTooTip* vs kToolTip*
Changing the window title and tab title directly will now
show the same tool-tips as the Terminal settings window.
Change-Id: Ic36cc1f8af0305b757105a229203115efee870c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4989
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Máximo Castañeda <antiswen@yahoo.es>
The options "Refuse in/output format changes" were meant to prevent
format changes of connections on the fly, without tearing down and
establishing a new connection.
The mixer does not support such format changes for input.
With this patch input format changes are refused - the former
default setting.
Output format changes are at least mostly implemented, so we are
allowing format changes here.
Both options get removed from the Audio mixer setup panel of the
Media preferences. The code those settings themselves is kept.
Thanks Máximo Castañeda for the investigation, see
https://www.freelists.org/post/haiku-development/Explain-the-Audio-Mixer-Setup-options-of-Media-preferences,26
Change-Id: Idb2d0674a4701014249bc5252a7e4ccedc4f532f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4934
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Use the User Read-only Thread ID Register aka TPIDRURO to store
TLS pointer.
The User Read-only Thread ID Register is read-only in User mode,
and read/write in privileged modes.
see: ARMv7 Architecture Reference Manual,
section B3.12.46 CP15 c13 Software Thread ID registers
Change-Id: I7bff2fd66f41d7bf1a8a247151bcd02b32733c1b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4994
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
