-----Original Message----- From: ros-dev-bounces@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