time of the idle thread as a measure, we now compute the CPU activity on
each thread switch - the time the CPU worked is the total of user and kernel
time a thread spent during its quantum.
Unlike before, this mechanism works correctly on SMP machines. I hope this
works as expected :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16193 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added syscalls _kern_set_cpu_enabled() and _kern_cpu_enabled().
* scheduler.c::sRunQueue::tail was not maintained at all; changed sRunQueue to
be a simple thread pointer instead of a struct thread_queue.
* Turns out we're monitoring CPU activity incorrectly when we've got more
than one CPU.
* Renamed the global CPU array from "cpu" to gCPU.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16186 a95241bf-73f2-0310-859d-f6bbb57e9c96
destructor, but created everytime AttachedToWindow() was called.
* Minor cleanups.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16184 a95241bf-73f2-0310-859d-f6bbb57e9c96
break compatibility a bit too much (as this is a public class).
* Instead, we're now using the same mechanism as in Dano/Zeta, that is,
we use BControl::SetValueNoUpdate() in the inherited classes.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16183 a95241bf-73f2-0310-859d-f6bbb57e9c96
SMP machines since we're already in a call_all_cpus() function (that also
needs to run synchronously). MTRR does now work on SMP machines again; ie.
SMP machines should boot fine again now.
* Fixed warning when compiled with tracing turned on.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16181 a95241bf-73f2-0310-859d-f6bbb57e9c96
methods. Currently guarded by an "#ifdef __HAIKU__", as long as we
want to be able to build a BeOS compatible Clock.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16177 a95241bf-73f2-0310-859d-f6bbb57e9c96
SetToImage() variants for initializing the object to the resources of
the shared object file belonging to a loaded image. Should be handy for
libraries and add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16176 a95241bf-73f2-0310-859d-f6bbb57e9c96
synchronization as done in init_mtrrs() failed because of that (let the system
hang).
Unfortunately, MTRR still doesn't work on my dual PIII with SMP enabled; that
was just one reason it didn't work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16173 a95241bf-73f2-0310-859d-f6bbb57e9c96
The test application lets run a thread at the highest priority that calls
yield all the time - the system stays responsible when it runs, so it seems
to work fine :)
Changed the malloc implementation to use _kern_thread_yield() instead of
snoozing.
We should think about making this call public, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16166 a95241bf-73f2-0310-859d-f6bbb57e9c96
enqueueing a thread to the run queue.
This mechanism is now used for the thread priority boost on semaphore
release. Also, those threads are no longer made real time threads, they
now get a temporary priority of B_FIRST_REAL_TIME_PRIORITY - 1.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16165 a95241bf-73f2-0310-859d-f6bbb57e9c96
didn't bring the app signature into its canonical lower-case form when
using it as path to the MIME DB file. Thus an application signature
MIME type didn't get any attributes, not even the path to the app's
executable, which led to all kinds of problems when finding or starting
applications by signature. Among them, Clock not finding its resources
(bug #74).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16163 a95241bf-73f2-0310-859d-f6bbb57e9c96
if it doesn't make a semantical difference. I can't believe I've written
that code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16162 a95241bf-73f2-0310-859d-f6bbb57e9c96
idea for real-time threads. They could completely hog the CPU in this
case. Thanks to Marcus for investigating!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16161 a95241bf-73f2-0310-859d-f6bbb57e9c96
when the menu item under the mouse cursor has a sub-menu.
Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16160 a95241bf-73f2-0310-859d-f6bbb57e9c96
It now works fine on my P4 system as well :-)
But since the BIOS area is not identity mapped, it might work on fewer systems
than it does in BeOS R5.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16154 a95241bf-73f2-0310-859d-f6bbb57e9c96
on at least one of my systems, it only works on 3 of them...).
* Added APM safemode setting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16152 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Menu windows now use the kMenuWindowFeel feel (but still need the B_AVOID_FOCUS
flag set, as that's currently independent from the feel).
* Minor cleanup in MenuWindow.cpp
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16150 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added --dry-run option for paranoid ones like me.
* Added support for making partition devices bootable under Linux (x86, BIOS).
When specifying respective values for HAIKU_IMAGE_{DIR,NAME} ("/dev" and
e.g. "sda7") a "jam haiku-image" will now replace the contents of your
favorite partition with a fresh Haiku installation. BE WARNED: This is nothing
for the faint of heart and I don't guarantee that my implementation is bug-free
and won't mangle the contents of your hard disk even if you use it correctly.
That being said, note that you'll probably have to run the "jam haiku-image"
as root, if you want to access the partition devices, which is a bit annoying.
Furthermore, if the build_haiku_image script fails for any reason, jam tends
to remove the image file, which in this case would be a partition device node.
The mknod command will be your friend in this case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16148 a95241bf-73f2-0310-859d-f6bbb57e9c96
implement the B_GET_GEOMETRY command in a usable way. The bfs_shell is
able to play with partition devices under Linux, now.
* Fixed two warnings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16146 a95241bf-73f2-0310-859d-f6bbb57e9c96
