Hi! Hartmut Birr wrote:
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
oh okay, mp = SMP
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
Okay.
FYI, you have to let ros run for over ~12 hours to get it to fail. After dividing the KernelTime clock that would be approx 11.85 hours until it froze. Oh, this was tested w/o the explorer running just the straight cmd console after boot up.
I will start with the current cvs tree at this time and restart the run.
I'll post some more information next time. 8^(
Thanks, James