Searched +hist:1 +hist:cd8c4cc (Results 1 - 2 of 2) sorted by relevance
| /haiku/src/system/boot/loader/ | ||
| H A D | loader.cpp | diff 1f96a3cb Mon Oct 08 18:28:00 MDT 2018 Jessica Hamilton <jessica.l.hamilton@gmail.com> system/boot: Add support for multiple bootloaders diff 1cd8c4cc Fri Sep 26 18:33:20 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> Let the boot loader set the kernel image's name. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27754 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 1cd8c4cc Fri Sep 26 18:33:20 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> Let the boot loader set the kernel image's name. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27754 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9e8dc2a9 Sat Jul 14 20:10:15 MDT 2007 Ingo Weinhold <ingo_weinhold@gmx.de> [Sorry, couldn't split this one up any further.] * Images preloaded by the boot loader had to be modules to be of any use to the kernel. Extended the mechanism so that any images not accepted by the module code would later be tried to be added as drivers by the devfs. This is a little hacky ATM, since the devfs manages the drivers using a hash map keyed by the drivers inode ID, which those drivers obviously don't have. * The devfs emulates read_pages() using read(), if the device driver doesn't implement the former (all old-style drivers), thus making it possible to BFS, which uses the file cache which in turn requires read_pages(), on the device. write_pages() emulation is still missing. * Replaced the kernel_args::boot_disk structure by a KMessage, which can more flexibly be extended and deals more gracefully with arbitrarily-size data. The disk_identifier structure still exists, though. It is added as message field in cases where needed (non net boot). Moved the boot_drive_number field of the bios_ia32 platform specific args into the message. * Made the stage 1 PXE boot loader superfluous. Moved the relevant initialization code into the stage 2 loader, which can now be loaded directly via PXE. * The PXE boot loader does now download a boot tgz archive via TFTP. It does no longer use the RemoteDisk protocol (it could actually be removed from the boot loader). It also parses the DHCP options in the DHCPACK packet provided by PXE and extracts the root path to be mounted by the kernel. * Reorganized the boot volume search in the kernel (vfs_boot.cpp) and added support for network boot. In this case the net stack is initialized and the network interface the boot loader used is brought up and configured. Since NBD and RemoteDisk are our only options for net boot (and those aren't really configurable dynamically) ATM, the the boot device is found automatically by the disk device manager. Booting via PXE does work to some degree now. The most grievous problem is that loading certain drivers or kernel modules (or related activity) causes a reboot (likely a triple fault, though one wonders where our double fault handler is on vacation). Namely the keyboard and mouse input server add-ons need to be deactivated as well as the media server. A smaller problem is the net server, which apparently tries to (re-)configure the network interface we're using to boot, which obviously doesn't work out that well. So, if all this stuff is disabled Haiku does fully boot, when using the RemoteDisk protocol (not being able to use keyboard or mouse doesn't make this a particular fascinating experience, though ;-)). I had no luck with NBD -- it seemed to have protocol problems with the servers I tried. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 1cd8c4cc089ffb3623a1ff761549a100cb1b4cce Fri Sep 26 18:33:20 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> Let the boot loader set the kernel image's name. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27754 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9e8dc2a9bbbe768acdfd224a6a4af01918bb4ce0 Sat Jul 14 20:10:15 MDT 2007 Ingo Weinhold <ingo_weinhold@gmx.de> [Sorry, couldn't split this one up any further.] * Images preloaded by the boot loader had to be modules to be of any use to the kernel. Extended the mechanism so that any images not accepted by the module code would later be tried to be added as drivers by the devfs. This is a little hacky ATM, since the devfs manages the drivers using a hash map keyed by the drivers inode ID, which those drivers obviously don't have. * The devfs emulates read_pages() using read(), if the device driver doesn't implement the former (all old-style drivers), thus making it possible to BFS, which uses the file cache which in turn requires read_pages(), on the device. write_pages() emulation is still missing. * Replaced the kernel_args::boot_disk structure by a KMessage, which can more flexibly be extended and deals more gracefully with arbitrarily-size data. The disk_identifier structure still exists, though. It is added as message field in cases where needed (non net boot). Moved the boot_drive_number field of the bios_ia32 platform specific args into the message. * Made the stage 1 PXE boot loader superfluous. Moved the relevant initialization code into the stage 2 loader, which can now be loaded directly via PXE. * The PXE boot loader does now download a boot tgz archive via TFTP. It does no longer use the RemoteDisk protocol (it could actually be removed from the boot loader). It also parses the DHCP options in the DHCPACK packet provided by PXE and extracts the root path to be mounted by the kernel. * Reorganized the boot volume search in the kernel (vfs_boot.cpp) and added support for network boot. In this case the net stack is initialized and the network interface the boot loader used is brought up and configured. Since NBD and RemoteDisk are our only options for net boot (and those aren't really configurable dynamically) ATM, the the boot device is found automatically by the disk device manager. Booting via PXE does work to some degree now. The most grievous problem is that loading certain drivers or kernel modules (or related activity) causes a reboot (likely a triple fault, though one wonders where our double fault handler is on vacation). Namely the keyboard and mouse input server add-ons need to be deactivated as well as the media server. A smaller problem is the net server, which apparently tries to (re-)configure the network interface we're using to boot, which obviously doesn't work out that well. So, if all this stuff is disabled Haiku does fully boot, when using the RemoteDisk protocol (not being able to use keyboard or mouse doesn't make this a particular fascinating experience, though ;-)). I had no luck with NBD -- it seemed to have protocol problems with the servers I tried. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
| /haiku/src/system/kernel/vm/ | ||
| H A D | vm.cpp | diff c650846d Tue Mar 14 15:42:25 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> vm: Replace the VMAreas OpenHashTable with an AVLTree. Since we used a hash table with a fixed size (1024), collisions were obviously inevitable, meaning that while insertions would always be fast, lookups and deletions would take linear time to search the linked-list for the area in question. For recently-created areas, this would be fast; for less-recently-created areas, it would get slower and slower and slower. A particularly pathological case was the "mmap/24-1" test from the Open POSIX Testsuite, which creates millions of areas until it hits ENOMEM; it then simply exits, at which point it would run for minutes and minutes in the kernel team deletion routines; how long I don't know, as I rebooted before it finished. This change fixes that problem, among others, at the cost of increased area creation time, by using an AVL tree instead of a hash. For comparison, mmap'ing 2 million areas with the "24-1" test before this change took around 0m2.706s of real time, while afterwards it takes about 0m3.118s, or around a 15% increase (1.152x). On the other hand, the total test runtime for 2 million areas went from around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other words, with this new code, it is *32 times faster.* Area insertion will no longer be O(1), however, so the time increase may go up with the number of areas present on the system; but if it's only around 3 seconds to create 2 million areas, or about 1.56 us per area, vs. 1.35 us before, I don't think that's worth worrying about. My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark seems to be within the realm of "noise", anyway, with most results both before and after this change coming in around 47s real time. Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831 diff c650846d Tue Mar 14 15:42:25 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> vm: Replace the VMAreas OpenHashTable with an AVLTree. Since we used a hash table with a fixed size (1024), collisions were obviously inevitable, meaning that while insertions would always be fast, lookups and deletions would take linear time to search the linked-list for the area in question. For recently-created areas, this would be fast; for less-recently-created areas, it would get slower and slower and slower. A particularly pathological case was the "mmap/24-1" test from the Open POSIX Testsuite, which creates millions of areas until it hits ENOMEM; it then simply exits, at which point it would run for minutes and minutes in the kernel team deletion routines; how long I don't know, as I rebooted before it finished. This change fixes that problem, among others, at the cost of increased area creation time, by using an AVL tree instead of a hash. For comparison, mmap'ing 2 million areas with the "24-1" test before this change took around 0m2.706s of real time, while afterwards it takes about 0m3.118s, or around a 15% increase (1.152x). On the other hand, the total test runtime for 2 million areas went from around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other words, with this new code, it is *32 times faster.* Area insertion will no longer be O(1), however, so the time increase may go up with the number of areas present on the system; but if it's only around 3 seconds to create 2 million areas, or about 1.56 us per area, vs. 1.35 us before, I don't think that's worth worrying about. My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark seems to be within the realm of "noise", anyway, with most results both before and after this change coming in around 47s real time. Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831 diff c650846d Tue Mar 14 15:42:25 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> vm: Replace the VMAreas OpenHashTable with an AVLTree. Since we used a hash table with a fixed size (1024), collisions were obviously inevitable, meaning that while insertions would always be fast, lookups and deletions would take linear time to search the linked-list for the area in question. For recently-created areas, this would be fast; for less-recently-created areas, it would get slower and slower and slower. A particularly pathological case was the "mmap/24-1" test from the Open POSIX Testsuite, which creates millions of areas until it hits ENOMEM; it then simply exits, at which point it would run for minutes and minutes in the kernel team deletion routines; how long I don't know, as I rebooted before it finished. This change fixes that problem, among others, at the cost of increased area creation time, by using an AVL tree instead of a hash. For comparison, mmap'ing 2 million areas with the "24-1" test before this change took around 0m2.706s of real time, while afterwards it takes about 0m3.118s, or around a 15% increase (1.152x). On the other hand, the total test runtime for 2 million areas went from around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other words, with this new code, it is *32 times faster.* Area insertion will no longer be O(1), however, so the time increase may go up with the number of areas present on the system; but if it's only around 3 seconds to create 2 million areas, or about 1.56 us per area, vs. 1.35 us before, I don't think that's worth worrying about. My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark seems to be within the realm of "noise", anyway, with most results both before and after this change coming in around 47s real time. Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831 diff c25f6f53 Tue Mar 29 18:09:36 MDT 2022 Augustin Cavalier <waddlesplash@gmail.com> kernel/vm: Completely replace mlock() implementation. The old implementation used the real lock_memory(). This is problematic and does not work for a large number of reasons: 1) Various parts of the kernel assume memory is locked only very temporarily, and will often wait on locked memory to become unlocked. The transient nature of locks is further demonstrated by the fact that lock_memory acquires references to structures, like the address space, which are only released by unlock_memory 2) The VM has a hard assumption that all lock_memory calls will be exactly balanced, and maintains internal "WiredRange" structures on areas, etc. corresponding to the original lock_memory calls. Maintaining separate data structures as this code did is a recipe for even more problems when the structures are manipulated separately, leading to confusing or incorrect behavior on unlocks. 3) Areas with locked memory cannot be deleted, nor can the pages which are locked be removed from the areas/caches. This of course is most notable when destroying teams which locked memory, but the problem also occurs when just using delete_area, resize_area, mmap/munmap, etc. Because of (2) and especially (3), adding support for mlock()-like semantics to the existing memory locking system is just not a good option. A further reason is that our lock_memory is much stricter than mlock(), which only demands the pages in question must remain resident in RAM and cannot be swapped out (or, it seems, otherwise written back to disk.) Thus, this commit completely removes the old implementation (which was seriously broken and did not actually automatically unlock memory on team exit or area destruction at all, etc.) and instead adds a new feature to VMAnonymousCache to block certain pages from being written out. The syscall then just invokes this to do its work. Fixes #17674. Related to #13651. Change-Id: Id2745c51796bcf9a74ba5325fe686a95623cd521 Reviewed-on: https://review.haiku-os.org/c/haiku/+/5147 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 8ca0f03d Mon Nov 08 23:39:16 MST 2021 X512 <danger_mail@list.ru> riscv64/smp: Implement multi-processor support * Working under qemu smp 1,2+ * Working on SiFive Unmatched * x86_64 efi not broken by smp_boot_other_cpus change Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> diff 1e3d4cf7 Sat Mar 21 20:26:44 MDT 2020 X512 <danger_mail@list.ru> Kernel: remove dead code area->name is a fixed array inside struct, not pointer, so it should be never be NULL. Pointed by clang. Change-Id: Ic8930450cb8461eef158bc854f214eb47d92ce22 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2391 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> diff 023a547d Mon Aug 06 21:27:50 MDT 2018 Augustin Cavalier <waddlesplash@gmail.com> vm: Enable B_USER_CLONEABLE_AREA protection. Spotted while reading through the VM code while thinking about how to implement vfork(). When axeld disabled this in 2005 (!), Haiku's kernel was still young, BeOS drivers were still "a thing," and there was no distinction in this function from being called by the kernel / not by the kernel. Now, it's 2018, we manage all drivers ourselves, have SMAP enabled by default when available, and as axeld recently noted on the mailing lists, "there's not much reason we still use GCC2 for the kernel anyway." So we probably don't care about any BeOS drivers that may be broken by this (are there any still around?) Besides the usual fixes to get this 13-year-old chunk to work again, there are two functional changes: 1) Allow the kernel to clone whatever it likes into the user's address space. It seems that this is often done legitimately (e.g. team creation), and so attempting to distinguish those cases seems more work than it may be worth right now. The disadvantage is that drivers without proper checks may be "tricked" into cloning areas they shouldn't; but I'm guessing if that's the case, then something else is probably broken and the driver should be fixed. It seems the reverse case (cloning a userland area into the kernel) is much more common (in fact, it looks like all 4 of the 4 places where clone_area is used in kernel-space outside the kernel itself are doing this.) 2) At KDEBUG_LEVEL 2 and higher, throw a panic when attempting to clone an area that does not have the protection flag set. This should make finding any bugs exposed by this change much easier than "hardware doesn't work" / "black screen on boot" / etc., as well as any potential future bugs introduced in the process of driver development. diff 70d3bd55 Tue Oct 28 17:53:06 MDT 2014 Ingo Weinhold <ingo_weinhold@gmx.de> vm_soft_fault(): Missing DEBUG_PAGE_ACCESS_END() ... in case we'd need to unmap a page that is wired. Fixes the immediate issue of #10977. There's a problem remaining (as discussed in comment 1): If two threads want to wire the same page at the same time (which led to the assertion being triggered), they will now deadlock, waiting for each other to remove the pre-registered VMAreaWiredRange. diff 1fe24d0c Sat Dec 03 12:03:20 MST 2011 Michael Lotz <mmlr@mlotz.ch> Add heap with guard pages to detect out of bound reads/writes. This is a very simple heap implementation that allocates memory so that the end of each allocation always coincides with a page end and is followed by a guard page which is marked non-present. Out of bounds access (both read and write) therefore cause a crash (unhandled page fault). Note that this allocator is neither speed nor space efficient, indeed it wastes huge amounts of pages and address space so it is quite easy to hit limits. It is intended as a pure debug feature. diff 1d26c724 Thu Jun 10 11:30:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> vm_page_allocate_page_run(): Added parameter "limit", specifying the upper physical address limit for the page run to allocate. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37086 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 331 milliseconds