PAT support (i.e. uncacheable, write-through, and write-back). Has pretty
much no effect ATM, as the MTRRs restrict the types to what is actually
requested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36583 a95241bf-73f2-0310-859d-f6bbb57e9c96
implemented for any architecture yet.
* vm_set_area_memory_type(): Call VMTranslationMap::ProtectArea() to change the
memory type for the already mapped pages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36574 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Don't set the VMArea's memory type in arch_vm_set_memory_type(), but let the
callers do that.
* vm_set_area_memory_type(): Does nothing, if the memory type doesn't change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36573 a95241bf-73f2-0310-859d-f6bbb57e9c96
of consistency.
* Moved the B_OVERCOMMITTING_AREA flag from B_KERNEL_AREA_FLAGS to
B_USER_AREA_FLAGS, since we really allow it to be passed from userland.
* Most VM syscalls check the provided protection against B_USER_AREA_FLAGS
instead of B_USER_PROTECTION, now. This way they allow for
B_OVERCOMMITTING_AREA as well.
* _user_map_file(), _user_set_memory_protection(): Check the protection like
the other syscalls do and use fix_protection() instead of doing that
manually.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36572 a95241bf-73f2-0310-859d-f6bbb57e9c96
WebPositive. Gopher URL type remains the only one to refer Firefox.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36568 a95241bf-73f2-0310-859d-f6bbb57e9c96
* InitiateDrag() now makes sure that either a number of top-level items
or a group of subitems sharing the parent is being dragged - anything
else doesn't really make sense and results in mayhem and/or crashes
* LocaleWindow now tries harder to keep the language listview sorted
* when moving around items between the two listviews, they are no longer
copied (and partly leaked), but the same items are now just moved over
* cleanup here and there
This is still somewhat of a mess - I recommend splitting the two listviews at least (as they actually behave differently) - maybe it would be better to pick the available languages from a popup-menu instead of keeping them in a listview?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36561 a95241bf-73f2-0310-859d-f6bbb57e9c96
continuing to run. This must not happen since the thread is the boot CPU's
idle thread performing the early kernel initialization (before the scheduler
is started).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36560 a95241bf-73f2-0310-859d-f6bbb57e9c96
fixes the problem that the CPU initiating the call could make the next call
and reset sCpuRendezvous2 before the other CPUs have returned from their
smp_cpu_rendezvous(). Probably virtually impossible on real hardware, but I
could almost reliably reproduce it with qemu -smp 2 (would hang the late boot
process without ability to enter KDL).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36559 a95241bf-73f2-0310-859d-f6bbb57e9c96
boot CPU wait until all other CPUs are ready to wait. This solves a
theoretical problem in main(): The boot CPU could run fully through the early
initialization and reset sCpuRendezvous2 before the other CPUs left
smp_cpu_rendezvous(). It's very unlikely on real hardware that the non-boot
CPUs are so much slower, but it might be a concern in emulation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36558 a95241bf-73f2-0310-859d-f6bbb57e9c96
for bezilla's and NetSurf's source archives, instead of defining a local
variable (as installoptionalpackage didn't like it). No functional change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36557 a95241bf-73f2-0310-859d-f6bbb57e9c96
kernel from committing memory for all read-only segments until we're done
relocating. This allows Haiku to boot on machines with less RAM and swap
disabled. At least in qemu I could boot with 100 MB and start WebPositive.
Probably fixed#5822.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36552 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Commit(): Unreserve memory when asked to shrink the commitment.
* Fault(): The whole logic is flawed, since this is always called by
vm_soft_fault(), even, if the page is finally mapped from a lower cache.
Now we do at least limit our commitment to (page_count + 1) * B_PAGE_SIZE
instead of always reserving memory for another page.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36551 a95241bf-73f2-0310-859d-f6bbb57e9c96
maps. The new cache will be created in over-committing mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36550 a95241bf-73f2-0310-859d-f6bbb57e9c96
component of a 32 bit color is below 128 and returns the special CMAP8 index
for indicating transparency.
* Changed the WriteCMAP() color conversion function to expext a 32bit RGBA
value and use IndexForRGBA32().
* Adapted B_CMAP8 target color space case of ConvertBits() to the new
semantics.
This allows transparency in bitmaps when converting B_RGBA32 bitmaps to
B_CMAP8, tested only for this case and working as expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36549 a95241bf-73f2-0310-859d-f6bbb57e9c96
SourceURL: Text <URL> lines. InstallSourceArchive commands have been added,
where source archives provided. The baseSourceURL has been updated to
http://haiku-files.org/files/releases/r1alpha2/sources
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36544 a95241bf-73f2-0310-859d-f6bbb57e9c96
window actually has a selection list to use. Certain actions can render it
possible to empty out the selection in mid drag-and-drop, which MoveSelectionInto
wasn't taking into account, leading to a crash.
Fixes ticket #5860.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36543 a95241bf-73f2-0310-859d-f6bbb57e9c96
(scsi_start_mode_sense_6(), scsi_start_mode_select_6()) also call
replace_request_data(), which does the same. Therefore the original request
data were lost. scsi_start_mode_select_6() also copied the wrong data due
to this.
* scsi_finish_mode_sense_10_6(): In case of error also call
restore_request_data() to restore the request data.
Fixes#5855 -- since the request data length was changed, unlock_memory() was
called with a different length than lock_memory(), thus triggering the
panic(). After starting CDPlayer the syslog is still spammed with failing
requests, so obviously something is still not OK.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36539 a95241bf-73f2-0310-859d-f6bbb57e9c96
shells started by remote login daemons (sshd, telnetd) also get the
environmental variables defined there. Closes#5789 and #2468.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36536 a95241bf-73f2-0310-859d-f6bbb57e9c96
