Searched +hist:8 +hist:a0c9d52 (Results 1 - 22 of 22) sorted by relevance
| /haiku/src/add-ons/kernel/drivers/graphics/intel_810/ | ||
| H A D | driver.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/3dfx/ | ||
| H A D | driver.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/et6x00/ | ||
| H A D | driver.c | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/s3/ | ||
| H A D | driver.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/ati/ | ||
| H A D | driver.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/file_systems/userlandfs/private/ | ||
| H A D | RequestAllocator.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/system/kernel/messaging/ | ||
| H A D | MessagingService.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/radeon/ | ||
| H A D | PCI_GART.c | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| H A D | init.c | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/skeleton/ | ||
| H A D | driver.c | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/headers/private/system/ | ||
| H A D | vm_defs.h | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/neomagic/ | ||
| H A D | driver.c | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/via/ | ||
| H A D | driver.c | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/matrox/ | ||
| H A D | driver.c | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/vesa/ | ||
| H A D | vesa.cpp | diff 015b4086 Wed Oct 20 10:13:56 MDT 2021 Adrien Destugues <pulkomandy@pulkomandy.tk> vesa: live mode patching, nvidia version. 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> diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff bb693d77 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77643c7bc4b2b10847007a94af5e84b953 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77643c7bc4b2b10847007a94af5e84b953 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77643c7bc4b2b10847007a94af5e84b953 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
| /haiku/src/system/kernel/debug/ | ||
| H A D | frame_buffer_console.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff bb693d77 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff ebf6c5de Fri Oct 31 04:39:50 MDT 2008 Axel Dörfler <axeld@pinc-software.de> * 15 and 16 bit KDL consoles now have nice colors, too. * For 8 bit, the palette is pretty messed up during the boot process (thanks to the boot loader image), so that we might want to change how the colors are set then. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28393 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 51a3c450 Tue Dec 13 09:34:29 MST 2005 Axel Dörfler <axeld@pinc-software.de> The short story: we now have MTRR support on Intel and AMD CPUs (the latter has not yet been tested, though - I'll do this after this commit): * Removed the arch_memory_type stuff from vm_area; since there are only 8 memory ranges on x86, it's simply overkill. The MTRR code now remembers the area ID and finds the MTRR that way (it could also iterate over the existing MTRRs). * Introduced some post_modules() init functions. * If the other x86 CPUs out there don't differ a lot, MTRR functionality might be put back into the kernel. * x86_write_msr() was broken, it wrote the 64 bit number with the 32 bit words switched - it took me some time (and lots of #GPs) to figure that one out. * Removed the macro read_ebp() and introduced a function x86_read_ebp() (it's not really a time critical call). * Followed the Intel docs on how to change MTRRs (symmetrically on all CPUs with caches turned off). * Asking for memory types will automatically change the requested length to a power of two - note that BeOS seems to behave in the same, although that's not really very clean. * fixed MTRRs are ignored for now - we should make sure at least, though, that they are identical on all CPUs (or turn them off, even though I'd prefer the BIOS stuff to be uncacheable, which we don't enforce yet, though). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15528 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77643c7bc4b2b10847007a94af5e84b953 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77643c7bc4b2b10847007a94af5e84b953 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bb693d77643c7bc4b2b10847007a94af5e84b953 Fri Aug 14 03:49:28 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Added VESA capabilities field to the kernel args. * The vesa driver no longer uses VGA programming if the chip does not support VGA compatibility. * The VESA driver now tries to set the DAC to 8 bits per color gun. * In VESA modes, the driver no longer tries to use VGA programming; introduced the new vesa_set_indexed_colors() that is now used for palette programming. This should fix wrong colors of 8 bit BWindowScreen users with VESA on real hardware (emulators usually didn't mind either way). * Note that the app_server needs to maintain a palette per 8 bit screen, as right now, the colors are garbled after a workspace switch. Stefano, are you looking into that already? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
| /haiku/headers/os/drivers/ | ||
| H A D | KernelExport.h | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) |
| /haiku/src/add-ons/kernel/drivers/graphics/radeon_hd/ | ||
| H A D | radeon_hd.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8bb67907 Fri Apr 16 09:29:30 MDT 2010 Clemens Zeidler <clemens.zeidler@googlemail.com> Set the write combine flag for the framebuffer area. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36330 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8bb679076df2971e1943b04f94c2d7d24efe1951 Fri Apr 16 09:29:30 MDT 2010 Clemens Zeidler <clemens.zeidler@googlemail.com> Set the write combine flag for the framebuffer area. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36330 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
| /haiku/src/add-ons/kernel/drivers/graphics/intel_extreme/ | ||
| H A D | intel_extreme.cpp | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff c2d37953 Sat Jul 28 14:52:37 MDT 2018 Adrien Destugues <pulkomandy@pulkomandy.tk> Rework PLL calculations for Iron Lake The limits were wrong in several places. Checked the sandy bridge, ivy brige and haswell docs, they all say mostly the same. - The value of p2 is either 7, 14, 5 or 10 depending on 1 bit in the config register and on the display type. We can guess which values are right according to the global P limit (5-80 when using 5/10, 28-something when using 14/7). The values are different because CRT need a precise, but rather low pixel clock, while modern display interface can accomodate being faster than required by a few MHz, but need a much higher speed (the bits are transferred serially, so they need to be at least 8 times faster than a DAC). - The limits for N were obviously wrong, as the register is written with N-2, so values less than 2 make no sense. Use 3-8 as specified in the datasheet. - The reference frequency (set by the driver) was wrong, too. It is 120MHz, not 96. It is 100MHz in some cases (FDI, etc), we should see when this happens and switch to the right reference for PLL computations. - There was an attempt to minimize the value of N (a powersaving effort, I guess?), but it would basically force the loop to stop at the first value of N tested, resulting in way off timings in some cases. - To ease testing and stop sending patches and syslogs back and forth with vidrep, extract the "test mode" from pll.cpp into a proper test executable, making it a little easier to experiment with the code and fix the problems. This should fix #13669 and possibly other cases of "out of range", black screen, bad timings, etc. Change-Id: Ic4c1c159701f352b7c1ef15a647f023c82ac26c Reviewed-on: https://review.haiku-os.org/360 Reviewed-by: Axel Dörfler <axeld@pinc-software.de> Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff c2d37953 Sat Jul 28 14:52:37 MDT 2018 Adrien Destugues <pulkomandy@pulkomandy.tk> Rework PLL calculations for Iron Lake The limits were wrong in several places. Checked the sandy bridge, ivy brige and haswell docs, they all say mostly the same. - The value of p2 is either 7, 14, 5 or 10 depending on 1 bit in the config register and on the display type. We can guess which values are right according to the global P limit (5-80 when using 5/10, 28-something when using 14/7). The values are different because CRT need a precise, but rather low pixel clock, while modern display interface can accomodate being faster than required by a few MHz, but need a much higher speed (the bits are transferred serially, so they need to be at least 8 times faster than a DAC). - The limits for N were obviously wrong, as the register is written with N-2, so values less than 2 make no sense. Use 3-8 as specified in the datasheet. - The reference frequency (set by the driver) was wrong, too. It is 120MHz, not 96. It is 100MHz in some cases (FDI, etc), we should see when this happens and switch to the right reference for PLL computations. - There was an attempt to minimize the value of N (a powersaving effort, I guess?), but it would basically force the loop to stop at the first value of N tested, resulting in way off timings in some cases. - To ease testing and stop sending patches and syslogs back and forth with vidrep, extract the "test mode" from pll.cpp into a proper test executable, making it a little easier to experiment with the code and fix the problems. This should fix #13669 and possibly other cases of "out of range", black screen, bad timings, etc. Change-Id: Ic4c1c159701f352b7c1ef15a647f023c82ac26c Reviewed-on: https://review.haiku-os.org/360 Reviewed-by: Axel Dörfler <axeld@pinc-software.de> Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 8a3177ff Sat Aug 27 01:03:56 MDT 2016 Adrien Destugues <pulkomandy@pulkomandy.tk> intel_extreme: enable Werror and fix warnings. diff 8dd9b6f0 Sat Aug 27 00:34:02 MDT 2016 Adrien Destugues <pulkomandy@pulkomandy.tk> intel_extreme: style fixes and clarifications Thanks to Axel for review. diff 7902c46c Wed May 17 11:30:23 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * Added i830 as supported chipset - doesn't work perfectly, though. But Kyan reports that at least 8 bit modes seems to work (but overlay only partially) * Added "hardware_cursor" option to the settings file - when set to "false", you should have a cursor in the second output now as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17498 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 82bca02b Sat May 13 13:48:17 MDT 2006 Axel Dörfler <axeld@pinc-software.de> You can now specify how much memory the chip can use for graphics memory via a settings file. However, you cannot specify less than the amount taken by the BIOS (ie. your settings will be ignored if you do). Just put something like the following into a "intel_extreme" settings file: graphics_memory_size 16 To allocate 16 MB in total. Note, whatever value you specify will be rounded up to the next power of two, ie. if you specify 6 MB, 8 will be taken. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17444 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff ccb666bc Sat May 13 03:19:56 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * Prepared having hardware cursor support; got quite complicated because there is no good (or reliable) way to retrieve the physical address of "stolen" (by the BIOS) graphics memory. * Implemented allocation of additional graphics memory in case the BIOS was a bit too cheap. We now guarantee 8 MB of memory available to the graphics chip - would be nicer to only allocate that on demand, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17433 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 7902c46c3e03133bc17b23822b95bf3e8e84c9a2 Wed May 17 11:30:23 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * Added i830 as supported chipset - doesn't work perfectly, though. But Kyan reports that at least 8 bit modes seems to work (but overlay only partially) * Added "hardware_cursor" option to the settings file - when set to "false", you should have a cursor in the second output now as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17498 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
| /haiku/src/add-ons/kernel/drivers/graphics/nvidia/ | ||
| H A D | driver.c | diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 9e751160 Thu Jan 17 01:15:50 MST 2008 Axel Dörfler <axeld@pinc-software.de> * Deactivated the IDs for the 8xxx chips - they are not supported. * Removed ID 0x0141 for the FX 6600 as well until it's fixed, see ticket #1530 for details. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23579 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 1f482508 Tue Oct 09 14:05:43 MDT 2007 Rudolf Cornelissen <rudolf.cornelissen@gmail.com> updated naming for some previous unknown cards, added 24 new cards for support/recognition in the kernel driver, being GF 6xxx, 7xxx and 8xxx types. Also two more nforce 6100 4x0 cards recognized now. NOTE: accelerant update will come at a later date (soon I hope), needs more investigation first. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22497 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8bde8143 Sat Jan 21 07:49:39 MST 2006 Rudolf Cornelissen <rudolf.cornelissen@gmail.com> driver now enforces correct order of use of INIT_ACCELERANT and CLONE_ACCELERANT: bailing out with B_NOT_ALLOWED if incorrect use is detected. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16020 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8d87804e Thu May 26 03:30:20 MDT 2005 Rudolf Cornelissen <rudolf.cornelissen@gmail.com> added creation of 1Mb DMA command buffer in main mem. Hopefully this will further speedup DMA acceleration when finished in accelerant. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12833 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9e7511601a3812ea495415b0688604b9ef2a957b Thu Jan 17 01:15:50 MST 2008 Axel Dörfler <axeld@pinc-software.de> * Deactivated the IDs for the 8xxx chips - they are not supported. * Removed ID 0x0141 for the FX 6600 as well until it's fixed, see ticket #1530 for details. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23579 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 1f4825089031cd29b5bcc18f534595845bfec180 Tue Oct 09 14:05:43 MDT 2007 Rudolf Cornelissen <rudolf.cornelissen@gmail.com> updated naming for some previous unknown cards, added 24 new cards for support/recognition in the kernel driver, being GF 6xxx, 7xxx and 8xxx types. Also two more nforce 6100 4x0 cards recognized now. NOTE: accelerant update will come at a later date (soon I hope), needs more investigation first. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22497 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8bde8143ebfe127c5631e4688cb4d44b99ebf7ad Sat Jan 21 07:49:39 MST 2006 Rudolf Cornelissen <rudolf.cornelissen@gmail.com> driver now enforces correct order of use of INIT_ACCELERANT and CLONE_ACCELERANT: bailing out with B_NOT_ALLOWED if incorrect use is detected. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16020 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8d87804ed640b9b107c22371c46f68fea6004590 Thu May 26 03:30:20 MDT 2005 Rudolf Cornelissen <rudolf.cornelissen@gmail.com> added creation of 1Mb DMA command buffer in main mem. Hopefully this will further speedup DMA acceleration when finished in accelerant. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12833 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
| /haiku/headers/os/kernel/ | ||
| H A D | OS.h | diff 8af7b72d Mon Apr 25 15:25:55 MDT 2022 Augustin Cavalier <waddlesplash@gmail.com> OS.h: Remove set_timezone function from header, place behind _BEOS_R5_COMPATIBLE_. Long ago deprecated, not used in the tree. diff 68d37cfb Wed Dec 30 06:42:48 MST 2020 Adrien Destugues <pulkomandy@pulkomandy.tk> Fix definition of PAGESIZE and B_PAGE_SIZE On sparc, the minimal page size we can use is 8K. Since B_PAGE_SIZE and PAGESIZE defines were hardcoded to 4K, this resulted in a lot of confusion in all code trying to manipulate pages. - Remove cpu.h from headers/private/kernel/arch/*. It dates back from NewOS and was not used anymore since our kernel uses B_PAGE_SIZE (PAGE_SIZE was the only thing defined in this header). - Add posix/arch/*/limits.h with the arch specific page size and include it from the main limits.h. - Adjust bios_ia32/debug.cpp which was the only place using the PAGE_SIZE constant from the deleted headers. - Change OS.h to define B_PAGE_SIZE to be the same as POSIX PAGESIZE. - Define PAGESIZE in the build header if the host OS doesn't. Change-Id: I8c3732cf952ea3c2f088aa16d216678fbf198b96 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3558 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8fe70e82 Fri Oct 25 19:11:15 MDT 2002 lillo <lillo@nowhere.fake> beos compatibility fixes: exit_thread now issues a signal; wait_for_thread returns B_INTERRUPTED if target thread gets killed git-svn-id: file:///srv/svn/repos/haiku/trunk/current@1674 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8fe70e8212d0de7e9d252885d37d81fbf1787db4 Fri Oct 25 19:11:15 MDT 2002 lillo <lillo@nowhere.fake> beos compatibility fixes: exit_thread now issues a signal; wait_for_thread returns B_INTERRUPTED if target thread gets killed git-svn-id: file:///srv/svn/repos/haiku/trunk/current@1674 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
| /haiku/src/system/kernel/vm/ | ||
| H A D | vm.cpp | 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 8e74e307 Fri May 29 07:23:49 MDT 2020 Michael Lotz <mmlr@mlotz.ch> kernel/vm: Add discard_address_range that discards pages. Pages in the given range are unmapped and freed without getting written back anywhere. It can be used whenever a caller does not care about the data in the given range anymore and wants to reduce page pressure. Change-Id: I8bcce68fab278efef710d3714677e1d463504a56 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2843 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a0c9d52 Sat Aug 10 13:51:41 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.) diff 8a1709b3 Tue Dec 11 11:37:39 MST 2018 Augustin Cavalier <waddlesplash@gmail.com> vm: Allow W|X before kernel startup ends. The altcodepatch mechanism needs to overwrite parts of the kernel image. This can't be done by setting it to RW-only and not RWX, as we are already running within the kernel when this occurs, and so instruction fetches can and will occur between the points of +W and -W. As gKernelStartup is turned off before the scheduler is started, this is not much of a lifted restriction, as no modules are loaded, no secondary threads started, etc. Fixes #14751. diff 8ef857d8 Tue Oct 28 19:34:56 MDT 2014 Ingo Weinhold <ingo_weinhold@gmx.de> vm_soft_fault(): Avoid inconsistent state when seeing wired page When we encounter a wired page that we'd have to unmap to map our newly allocated one, we need to get rid of the latter before unlocking everything and waiting for the wired page. Otherwise we'd leave things in an inconsistent state (a page from an upper cache shadowing a mapped page from a lower cache). diff c3f0fd28 Thu Jul 12 04:29:33 MDT 2012 Alex Smith <alex@alex-smith.me.uk> Fixed formatting of output in some debugger commands. Currently all debugger commands assume 32-bit pointers when formatting their output. This means that on x86_64 the output is incorrectly formatted. Fixed this by adding a B_PRINTF_POINTER_WIDTH definition (16 on 64-bit, 8 on 32-bit), and using this to correctly format the output. Not all commands have been fixed yet, but all VM, slab, VFS, team, thread and image commands should be correct. diff dac21d8b Thu Feb 18 06:52:43 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * map_physical_memory() does now always set a memory type. If none is given (it needs to be or'ed to the address specification), "uncached" is assumed. * Set the memory type for the "BIOS" and "DMA" areas to write-back. Not sure, if that's correct, but that's what was effectively used on my machines before. * Changed x86_set_mtrrs() and the CPU module hook to also set the default memory type. * Rewrote the MTRR computation once more: - Now we know all used memory ranges, so we are free to extend used ranges into unused ones in order to simplify them for MTRR setup. - Leverage the subtractive properties of uncached and write-through ranges to simplify ranges of any other respectively write-back type. - Set the default memory type to write-back, so we don't need MTRRs for the RAM ranges. - If a new range intersects with an existing one, we no longer just fail. Instead we use the strictest requirements implied by the ranges. This fixes #5383. Overall the new algorithm should be sufficient with far less MTRRs than before (on my desktop machine 4 are used at maximum, while 8 didn't quite suffice before). A drawback of the current implementation is that it doesn't deal with the case of running out of MTRRs at all, which might result in some ranges having weaker caching/memory ordering properties than requested. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35515 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8d1316fd Fri Jan 22 14:19:23 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Replaced CACHE_DONT_SLEEP by two new flags CACHE_DONT_WAIT_FOR_MEMORY and CACHE_DONT_LOCK_KERNEL_SPACE. If the former is given, the slab memory manager does not wait when reserving memory or pages. The latter prevents area operations. The new flags add a bit of flexibility. E.g. when allocating page mapping objects for userland areas CACHE_DONT_WAIT_FOR_MEMORY is sufficient, i.e. the allocation will succeed as long as pages are available. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35246 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8a65066a Fri Jan 22 12:58:04 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> vm_soft_fault(): map_page() can fail for B_NO_LOCK areas, since it needs to allocate a page mapping. In that case we do at least have to mark the page not busy again. Furthermore we enforce the minimum page mappings object cache reserve, so we'll have more luck on the next fault. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35241 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 1020 milliseconds