Commits
use directly AcpiReset() for acpi reboot
by korli on 2009-12-13 23:01 (3 days ago)
* All scheduler implementations: - enqueue_in_run_queue() no longer returns whether rescheduling is supposed to happen. Instead is sets cpu_ent::invoke_scheduler on the current CPU. - reschedule() does now handle cpu_ent::invoke_scheduler_if_idle(). No need to let all callers do that. * thread_unblock[_locked]() no longer return whether rescheduling is supposed to happen. * Got rid of the B_INVOKE_SCHEDULER handling. The interrupt hooks really can't know, when it makes sense to reschedule or not. * Introduced scheduler_reschedule_if_necessary[_locked]() functions for checking+invoking the scheduler. * Some semaphore functions (e.g. delete_sem()) invoke the scheduler now, if they wake up anything with greater priority. I've also tried to add scheduler invocations in the condition variable and mutex/rw_lock code, but that actually has a negative impact on performance, probably because it causes too much ping-ponging between threads when multiple locking primitives are involved.
by bonefish on 2009-12-13 21:18 (3 days ago)
Improved panic() message.
by bonefish on 2009-12-13 21:03 (3 days ago)
Fixed a stupid race condition between IORequest finishing and IORequest::Wait(). Wait() immediately returned when IsFinished() returned true, but this is the case as soon as the last IOOperation has finished. The I/O scheduler is not done with the request at this point, though, since it will still be sitting in at least one of three doubly linked lists. Since the usual procedure to issue synchronous I/O requests is to create an IORequest on the stack, pass it to the I/O scheduler, and Wait() on it, Wait() returning early might cause the IORequest object to be destroyed while it is still in use, leading to invalid memory access in the I/O scheduler, corruption of its list structures, as well as later corruption of the issuing thread's stack. Related tickets: * #4431: The request issuing thread returned and already deleted the area the request was writing to before NotifyFinished() was called. * #3048, #4883: Caused by the on stack IORequest being overwritten with other data while being handled by the I/O scheduler thread. * #4517: Hard to say, but I've seen a such a problem too, after a thread scheduling related change. An explanation would be a list structure corruption in the I/O scheduler causing an infinite loop with disabled interrupts. * #2845, #3428, #3429: The block notifier/writer is I/O heavy and as such quite likely to run into the stack corruption issue.
by bonefish on 2009-12-13 19:28 (3 days ago)
added more missing prototypes in math.h
by korli on 2009-12-13 16:35 (3 days ago)
added missing prototypes for fmin, fma, fmax functions.
by korli on 2009-12-13 16:22 (3 days ago)
added fmin, fma, fmax from glibc (ticket #5114).
by korli on 2009-12-13 14:22 (3 days ago)
gcc4 build fix
by korli on 2009-12-13 13:28 (3 days ago)
switch to use STL containers, limit to 10 cache entries, don't clear cache on findkeyframe, removed inflight list as it was not needed, report error conditions better. This makes video work again
by dlmcpaul on 2009-12-13 12:09 (3 days ago)
Use B_OP_OVER instead of B_OP_COPY on Haiku (bug #4815)
by korli on 2009-12-13 00:23 (4 days ago)