-----Original Message-----
From: ros-dev-bounces(a)reactos.com
[mailto:ros-dev-bounces@reactos.com] On Behalf Of James Tabor
Sent: Thursday, November 04, 2004 7:55 AM
To: ReactOS Development List
Subject: [ros-dev] Race Condition?
Hi,
I believe with the new cvs changes by Hartmut caused the
illusive lockups I'm
having to pop up more often now. Two today and yesterday.
This print out looks good, but I've had debug messages
overlapping each other
at the beginning of the building process.
Debug output before lockup, there seems to be a double print
out, before just one
every KernelTime, and the KernelTime looks like it had stopped,
Hi,
I can not reproduce your problem. I'm using a nearly clean cvs tree from
yesterday. I've add some little modifications that I can compile ros with
gcc-3.4.1 and the latest w32api. I use also modified inf files for the
installation. My test system is a scsi only mp machine. I assume that you
spoke about the up system. I'm using cmd.exe as login shell. I can compile
ros on ros. I think that the changes to the hal and the irq handling are not
the problem. I've add some changes for the sequence how threads acquire the
PiThreadLock and the DispatcherDatabaseLock. Currently the locking sequence
is only a problem for mp systems, not for up systems. The problem on mp
systems is that the first thread have acquire one lock and the second thread
the other. After this, the threads try to acquire the other lock. This is
currently not a problem of the up system, because after a thread has acquire
one lock the system runs on DISPATCH_LEVEL and no thread switching is
possible, no other thread can acquire the second lock. Currently there exist
more problems of the locking sequence for mp machines. You have reported the
KernelTime problem. In one of Filip's changes was a little mistake, which
has called KeUpdateSystemTime with the wrong irql. The time was always
reported to the interrupt time. I've fixed this, but didn't add a comment.
- Hartmut