The patched errata are only the AMD ones FreeBSD patches
(it seems there are no Intel errata that can be patched
this way, they are all in microcode updates ... or can't
be patched in the CPU at all.)
This also seems to be roughly the point in the boot that
FreeBSD patches these, too, despite how "critical" some
of them seem.
Change-Id: I9065f8d025332418a21c2cdf39afd7d29405edcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1740
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Sparcv9 runs Openboot in 64 bit mode, which means the cell size is
64bit. Use intptr_t where appropriate to make the open firmware calls
work.
Beware, some values are still 32bit, this matters for example for
of_getprop, if you get 32bits into a 64bit variables it will be in the
MSB of it (big endian only weakness...) and confuse things. See for
example in console.cpp, where the input and output handles are retrieved
as 32bit values. It seems wise to check the expected size when using
of_getprop in these cases, instead of just checking for errors.
Change-Id: Ie72ebc4afe7c6d7602a47478f0bfb6b8247004b8
Reviewed-on: https://review.haiku-os.org/c/1369
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Before this commit, *all* ConditionVariable operations (yes, all;
even Wait, Notify, etc.) went through a single spinlock, that also
protected the sConditionVariableHash. This obviously does not scale
so well with core count, to say the least!
With this commit, we add spinlocks to each Variable and Entry.
This makes locking somewhat more complicated (and nuanced; see
inline comment), but the trade-off seems completely worth it:
(compile HaikuDepot in VMware, 2 cores)
before
real 1m20.219s
user 1m5.619s
sys 0m40.724s
after
real 1m12.667s
user 0m57.684s
sys 0m37.251s
The more cores there are, the more of an optimization this will
likely prove to be. But 10%-across-the-board is not bad to say
the least.
Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a
Even on 64bit CPUs it's a 32bit register.
Change-Id: I9a4de6eec225de19a90d70fae1382b662e530629
Reviewed-on: https://review.haiku-os.org/c/1625
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
B_OS_NAME_LENGTH is 32, char* is 8 (on x64), and this structure
has quite a lot of pointers in it so it is not like we really
needed to save those 24 bytes. Hitting malloc() in here is not
so great, especially because we usually have B_DONT_LOCK_KERNEL_SPACE
turned on, so just inline and avoid it.
Change-Id: I5c94955324cfda08972895826b61748c3b69096a
This was (following the packagefs changes) the number-one (by call
count) consumer of malloc() during the boot -- 52866 calls, and 100%
of them either 1024 or 1025 bytes!
Virtually all of these are ephemeral (indeed, the object_cache
stats after a boot with this patch shows there is only a single slab
of 64 buffers allocated, and most of them unused), so this is
probably a significant performance boost.
Change-Id: I659f5707510cbfeafa735d35eea7b92732ead666
If the buildbots were working, I would have been informed of this
about an hour after I committed it last night. But it seems they aren't.
Maybe kallisti5 will have some more incentive to work on that?
Cleans up some lock/get/unlock sequences, and makes it possible
for external consumers to get team structs (which will be necessary
for permissions checks.)
* Now matches the rest of the architectures.
Change-Id: I6699e0c8f729923770f136f2c9599185a685336a
Reviewed-on: https://review.haiku-os.org/c/1527
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
* mutex_destroy() only checked wether or not there were waiters,
not if the lock itself was presently held by another thread.
Now we do, which should make #15015 panic much earlier instead
of trying to use freed memory.
* mutex_transfer_lock() and recursive_lock_transfer_lock() did
not check that the calling thread actually owned the lock.
Now it does, which should trigger asserts if anyone tries
to do this.
Copied from PPC with the hooks for Apple hardware removed.
To be completed with the actual PCI bus implementation for Sun machines.
This is where we start doing machine specific stuff, apparently.
Change-Id: I06af4de9621e9d40593d153642478d928083e49a
Reviewed-on: https://review.haiku-os.org/c/1364
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Kernel is 64 bit, and we won't need a 32bit load base.
Change-Id: I729bab01c8f71083002db061e153b0e5052b9a1c
Reviewed-on: https://review.haiku-os.org/c/1326
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Add a platform cleanup hook before starting the kernel. The openfirmware
and PXE loaders clean up their network stack there, while the other
loaders currently do nothing.
This closes ticket #6166
Change-Id: I34765892dfd9b2310c6af97c9ff7d414afae49e5
Reviewed-on: https://review.haiku-os.org/c/50
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Add empty implementation of timer, elf, vm, debugger support, to let the
kernel link.
Also add the kernel linker script.
Change-Id: If0795fa6554aea3df1ee544c25cc4832634ffd78
Reviewed-on: https://review.haiku-os.org/c/1108
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previous commit adding these was merged very quickly, so here's one
more...
Change-Id: I23c424db7631db1f0ec48e2d0ae47c8409ae6af2
Reviewed-on: https://review.haiku-os.org/c/1088
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There was no synchronization of the check of the done flag and the
waiting thread suspending to wait for it. It was therefore possible that
the new team both set the flag and triggered the wakeup of the waiting
thread in that time window, causing it to miss both the set flag and the
thread resumption.
Use a condition variable instead.
Fixes#13081.
Change-Id: I93c45db8dd773fe42b45c4b67153bcd39e200d3b
Reviewed-on: https://review.haiku-os.org/803
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This file is included, directly or indirectly, by most of the
kernel-space C++ code, and so importing the entirety of "std"
seriously pollutes the global namespace.
So instead, just import "std::nothrow", which is the only thing
we really want in the global namespace. Tested on both GCC2
and GCC7 and seems to work just fine.
While I'm here, also update the include guards and copyright
header to match the standard format used elsewhere.
* Consolidate all fdt code into fdt bus_manager
* Build boot and kernel static libraries
Change-Id: I2a69cd7e1f1276999a80734ff12918fd49b599e5
Reviewed-on: https://review.haiku-os.org/440
Reviewed-by: Alexander von Gluck IV <kallisti5@unixzen.com>
memset uses rep stosb on x86 during boot, with memory
not set to write-combining, which makes it slow.
Instead we do aligned writes of 2 x four bytes at once.
Only clear the minimum of size and width * height * 4
UEFI framebuffer size can be huge, upto 512MB here,
and rep stosb seems to be around 25-30MB/s
This is written as generic as possible to work on
old compilers and different platforms, without
expecting boot memset to be optimized.
This makes it almost unnoticable compared to not
clearing.
It seems not all of the kernel includes this, but some use new/delete
anyway. Further, operator delete[] was not implemented at all.
Possibly fixes the ARM build.
Writes to videomem is slow without memory remapping
Can't do the mapping without leaving UEFI, so skipping
the clear. Afaict it should always be cleared by UEFI
This saves ~10 seconds of booting on my machine
(1920*1080*4 bytes)
EFI video mode (should have been it's own commit)
* Only do strcmp if there are enough params
* break when found
This reverts commit c558f9c8fe.
This reverts commit 44f24718b1.
This reverts commit a69cb33030.
This reverts commit 951182620e.
There have been multiple reports that these changes break mounting NTFS partitions
(on all systems, see #14204), and shutting down (on certain systems, see #12405.)
Until they can be fixed, they are being backed out.
* define compat_thread_info, compat_rlim_t, compat_rlimit and
compat_thread_creation_attributes to be used when applicable in compatibility
mode.
* handle 32-bit types in _user_spawn_thread(), _user_get_thread_info(),
_user_get_next_thread_info(), _user_getrlimit(), _user_setrlimit(),
other syscalls are compatible as is.
* init TLS for compatibility mode threads.
Change-Id: I483ba95e6198ddac9d240671bcb56fcd2ad831d2
* in load_image_internal(), elf32_load_user_image checks whether the binary
format requires the compatibility mode.
* we then set up the flag THREAD_FLAGS_COMPAT_MODE and the address space size.
* the compatibility mode runtime_loader is hardcoded with x86/runtime_loader.
* if needed, the 64-bit flat_args structure is converted in-place to its 32-bit
layout.
* a 32-bit flat_args isn't handled yet (a 32-bit team execs a 64-bit binary).
Change-Id: Ia6a066bde8d1774d85de29b48dc500e27ae9668f
* define compat_area_info to be used when applicable in
compatibility mode.
* handle 32-bit types in _user_reserve_address_range(), _user_get_area_info(),
_user_get_next_area_info(), _user_transfer_area(), _user_clone_area(),
_user_create_area(), _user_map_file(), other syscalls are compatible as is.
* _get_next_area_info() doesn't work well with a 32-bit address cookie (address
could be in 64-bit range). Instead use _compat_get_next_area_info() which uses
the area id as cookie, though the areas are not ordered by address any more.
Change-Id: Ic7519ca8824aa2d534b0f03ea75a1bf6ae321535
