Fix AMD CPU selection in generic_x86 kernel add-on

* The AMD-part of the add-on is supposed to reject some very old
models. However, a bug in the selection code caused it to reject
anything with

Fix AMD CPU selection in generic_x86 kernel add-on

* The AMD-part of the add-on is supposed to reject some very old
models. However, a bug in the selection code caused it to reject
anything with model-number smaller 9 regardless of model-family.
This caused MTRR setup to not happen on many AMD CPUs and Haiku
being very slow on these machines.

* Fixes #10571

show more ...

Merge branch 'scheduler'

Conflicts:
build/jam/packages/Haiku
headers/os/kernel/OS.h
headers/os/opengl/GLRenderer.h
headers/private/shared/cpu_type.h
src/add-ons/kernel/drivers/power/acpi_batter

Merge branch 'scheduler'

Conflicts:
build/jam/packages/Haiku
headers/os/kernel/OS.h
headers/os/opengl/GLRenderer.h
headers/private/shared/cpu_type.h
src/add-ons/kernel/drivers/power/acpi_battery/acpi_battery.h
src/bin/sysinfo.cpp
src/bin/top.c
src/system/kernel/arch/x86/arch_system_info.cpp
src/system/kernel/port.cpp

show more ...

kernel/cpu: Do not use get_system_info() to identify CPU

* 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

* 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

show more ...

* Added a set_mtrrs() hook to x86_cpu_module_info, which is supposed to set
all MTRRs at once.
* Added a respective x86_set_mtrrs() kernel function.
* x86 CPU module:
- Implemented the new hook.

* Added a set_mtrrs() hook to x86_cpu_module_info, which is supposed to set
all MTRRs at once.
* Added a respective x86_set_mtrrs() kernel function.
* x86 CPU module:
- Implemented the new hook.
- Prefixed most debug output with the CPU index. Otherwise it gets quite
confusing with multiple CPUs.
- generic_init_mtrrs(): No longer clear all MTRRs, if they are already
enabled. This lets us benefit from the BIOS's setup until we install our
own -- otherwise with caching disabled things are *really* slow.
* arch_vm.cpp: Completely rewrote the MTRR handling as the old one was not
only slow (O(2^n)), but also broken (resulting in incorrect setups (e.g.
with cachable ranges larger than requested)), and not working by design for
certain cases (subtractive setups intersecting ranges added later).
Now we maintain an array with the successfully set ranges. When a new range
is added, we recompute the complete MTRR setup as we need to. The new
algorithm analyzing the ranges has linear complexity and also handles range
base addresses with an alignment not matching the range size (e.g. a range
at address 0x1000 with size 0x2000) and joining of adjacent/overlapping
ranges of the same type.

This fixes the slow graphics on my 4 GB machine (though unfortunately the
8 MTRRs aren't enough to fully cover the complete frame buffer (about 35
pixel lines remain uncachable), but that can't be helped without rounding up
the frame buffer size, for which we don't have enough information). It might
also fix #1823.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34197 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

MTRR is no longer set on anything below AMD K6-2 model 9. This should fix bug #624.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17572 a95241bf-73f2-0310-859d-f6bbb57e9c96

Refactored MTRR code a bit: there is now a generic base that is used by
all CPU specific implementations as much as possible.
AMD and Intel are now separated again, even though they are currently
equ

Refactored MTRR code a bit: there is now a generic base that is used by
all CPU specific implementations as much as possible.
AMD and Intel are now separated again, even though they are currently
equivalent besides the CPU vendor detection.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15567 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...

Added generic x86 CPU module.
Contains (emtpy) modules for Intel/AMD/VIA models.
Might be separated later, though, depending on how large they will get.


git-svn-id: file:///srv/svn/repos/haiku/haik

Added generic x86 CPU module.
Contains (emtpy) modules for Intel/AMD/VIA models.
Might be separated later, though, depending on how large they will get.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15522 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...