Re: [ros-svn] [ion] 20554: - Fix shamefully dangerously broken Work Thread/Queue/Item implementation:

[Hartmut Birr]

[e-mail] wrote:
> Fix shamefully dangerously broken Work Thread/Queue/Item implementation:
> Do not pollute the kernel with 10 real-time threads and 5 high-priority threads in order to manage work items. Work threads are very-low priority (< 7) and should never pre-empt userthreads like they do now. 1 priority 7, 5 priority 5 and 3 priority 4 threads are now properly created.
> Implement a worker thread balance set manager. On SMP systems, it is able to determine when a new thread should be allocate to execute on a free CPU. On both UP and MP, it is also able to detect if a work queue has deadlocked, and will allocate new dynamic threads to unfreeze the queue.
> Add check for threads returning with APC disabled, and re-enable APCs if this happend. This hack is used in NT for broken drivers.
> Lots of code changes to support dynamic threads, which:
> Can terminate.
> Use a 10 minute timeout on the kernel queue.
> Add skeleton code for swapping worker thread stacks as well as worker thread shutdown (not yet implemented).
> Add WORKER_INVALID bugcheck definition.
> These changes seem to make ROS a lot more responsive.
>
> NDK:
> Make more compatible with MS IFS
> Fix EX_WORK_QUEUE definition.
> Fix ETHREAD offsets.
> Fix RtlIsNameLegalDOS8Dot3 definition.
> Move splay tree defines to IFS.
>
> Updated files:
> trunk/reactos/include/ndk/exfuncs.h
> trunk/reactos/include/ndk/extypes.h
> trunk/reactos/include/ndk/ifssupp.h
> trunk/reactos/include/ndk/iofuncs.h
> trunk/reactos/include/ndk/obfuncs.h
> trunk/reactos/include/ndk/pstypes.h
> trunk/reactos/include/ndk/rtlfuncs.h
> trunk/reactos/include/ndk/rtltypes.h
> trunk/reactos/lib/rtl/dos8dot3.c
> trunk/reactos/ntoskrnl/ex/work.c
> trunk/reactos/ntoskrnl/ntoskrnl.mc
> trunk/reactos/w32api/include/ddk/ntifs.h
>
> Ros-svn mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-svn

After applying this commit, I get a crash during compiling ros on ros
with 'make clean' on a clean tree on my smp machine:

Assertion (Thread->State == Waiting) == (Thread->WaitBlockList != NULL)
failed at ./ntoskrnl/ke/wait.c:722

I don't get a back trace. It may be a problem of the broken ASSERT
statement (DBG=1 and KDBG=0).

- Hartmut

[Alex Ionescu]

After applying this commit, I get a crash during compiling ros on ros
> with 'make clean' on a clean tree on my smp machine:
>
> Assertion (Thread->State == Waiting) == (Thread->WaitBlockList != NULL)
> failed at ./ntoskrnl/ke/wait.c:722
>
> I don't get a back trace. It may be a problem of the broken ASSERT
> statement (DBG=1 and KDBG=0).

Hi,

Can you try KDBG=1 and do a "bt" please? This should show a stack trace.
Also, is this the SMP build?
> Hartmut

Best regards,
Alex Ionescu

[Alex Ionescu]

Can you also try separating the ASSERT in two statements please?
It's really confusing in the way it's written.

Best regards,
Alex Ionescu

Alex Ionescu wrote:
> After applying this commit, I get a crash during compiling ros on ros
> > with 'make clean' on a clean tree on my smp machine:
> >
> > Assertion (Thread->State == Waiting) == (Thread->WaitBlockList != NULL)
> > failed at ./ntoskrnl/ke/wait.c:722
> >
> > I don't get a back trace. It may be a problem of the broken ASSERT
> > statement (DBG=1 and KDBG=0).
>
> Hi,
>
> Can you try KDBG=1 and do a "bt" please? This should show a stack trace.
> Also, is this the SMP build?
> > Hartmut
>
> Best regards,
> Alex Ionescu

[Hartmut Birr]

Alex Ionescu wrote:
> Hi,
>
> Can you try KDBG=1 and do a "bt" please? This should show a stack trace.
> Also, is this the SMP build?

It is a smp build. I'm not able to install a build with KDBG=1. It does
always crash at the end of the second stage setup. I've created a
backtrace by adding KeRosDumpStackFrames. It is rev 20554 with a highly
modified hal and kernel during the processor/apic initialization.

- Hartmut

(./ntoskrnl/ke/wait.c:724 CPU0) KiAbortWaitThread: 818f75e8, Status:
102, 818f7690
Frames:
<ntoskrnl.exe:95f9 (./ntoskrnl/ke/wait.c:725 (KiAbortWaitThread))>
<ntoskrnl.exe:955e (./ntoskrnl/ke/wait.c:701 (KiWaitTest))>
<ntoskrnl.exe:841e (./ntoskrnl/ke/timer.c:307 (KiHandleExpiredTimer))>
<ntoskrnl.exe:83d1 (./ntoskrnl/ke/timer.c:273 (KiExpireTimers))>
<ntoskrnl.exe:334f (./ntoskrnl/ke/dpc.c:554 (KiDispatchInterrupt))>
<80507204> hal/halx86/mp/mpsirql.c:93, HalpLowerIrql
<8050767D> hal/halx86/mp/mpsirql.c:337, HalEndSystemInterrupt
<80504419> hal/halx86/mp/apic.c:820, MpsTimerHandler
<80506F6F> hal\halx86\mp\mps.S:85, MpsTimerInterrupt
<ntoskrnl.exe:8d93f (./ntoskrnl/ps/thread.c:90 (PspSystemThreadStartup))>
Assertion (Thread->State == Waiting) == (Thread->WaitBlockList != NULL)
failed at ./ntoskrnl/ke/wait.c:727 for CPU0
KeBugCheckWithTf at ntoskrnl\ke\i386\exp.c:1242

M:\Sandbox\ros_work\reactos>svn diff ntoskrnl\ke\wait.c
Index: ntoskrnl/ke/wait.c
===================================================================
--- ntoskrnl/ke/wait.c  (Revision 20554)
+++ ntoskrnl/ke/wait.c  (Arbeitskopie)
@@ -719,6 +719,11 @@

/* If we are blocked, we must be waiting on something also */
     DPRINT("KiAbortWaitThread: %x, Status: %x, %x \n", Thread,
WaitStatus, Thread->WaitBlockList);
+    if (!((Thread->State == Waiting) == (Thread->WaitBlockList != NULL)))
+    {
+       DPRINT1("KiAbortWaitThread: %x, Status: %x, %x \n", Thread,
WaitStatus, Thread->WaitBlockList);
+       KeRosDumpStackFrames(NULL, 10);
+    }
     ASSERT((Thread->State == Waiting) == (Thread->WaitBlockList != NULL));

/* Remove the Wait Blocks from the list */

[Alex Ionescu]

Hartmut Birr wrote:
> Alex Ionescu wrote:
> > Hi,
> >
> > Can you try KDBG=1 and do a "bt" please? This should show a stack trace.
> > Also, is this the SMP build?
>
> It is a smp build. I'm not able to install a build with KDBG=1. It does
> always crash at the end of the second stage setup. I've created a
> backtrace by adding KeRosDumpStackFrames. It is rev 20554 with a highly
> modified hal and kernel during the processor/apic initialization.
> Hartmut

Hi,

Can you try the latest build please? It fixes some bugs in worker 
threads and waiting mechanisms.

Best regards,
Alex Ionescu

[Hartmut Birr]

Alex Ionescu wrote:
> >
>
> Hi,
>
> Can you try the latest build please? It fixes some bugs in worker
> threads and waiting mechanisms.

I get the same result:

(./ntoskrnl/ke/wait.c:750 CPU0) KiAbortWaitThread: 81381a18, Status:
102, 81381ac0
Frames:
<ntoskrnl.exe:9c36 (./ntoskrnl/ke/wait.c:751 (KiAbortWaitThread))>
<ntoskrnl.exe:9b98 (./ntoskrnl/ke/wait.c:726 (KiWaitTest))>
<ntoskrnl.exe:866b (./ntoskrnl/ke/timer.c:307 (KiHandleExpiredTimer))>
<ntoskrnl.exe:861e (./ntoskrnl/ke/timer.c:273 (KiExpireTimers))>
<ntoskrnl.exe:336b (./ntoskrnl/ke/dpc.c:554 (KiDispatchInterrupt))>
<804DF204>
<804DF67D>
<804DC419>
<804DEF6F>
<ntoskrnl.exe:8f0fd (./ntoskrnl/ps/thread.c:90 (PspSystemThreadStartup))>

- Hartmut

[Hartmut Birr]

2006/1/5, Hartmut Birr [e-mail]:
> I get the same result:
>
> (./ntoskrnl/ke/wait.c:750 CPU0) KiAbortWaitThread: 81381a18, Status:
> 102, 81381ac0
> Frames:
> <ntoskrnl.exe:9c36 (./ntoskrnl/ke/wait.c:751 (KiAbortWaitThread))>
> <ntoskrnl.exe:9b98 (./ntoskrnl/ke/wait.c:726 (KiWaitTest))>
> <ntoskrnl.exe:866b (./ntoskrnl/ke/timer.c:307 (KiHandleExpiredTimer))>
> <ntoskrnl.exe:861e (./ntoskrnl/ke/timer.c:273 (KiExpireTimers))>
> <ntoskrnl.exe:336b (./ntoskrnl/ke/dpc.c:554 (KiDispatchInterrupt))>
> <804DF204>
> <804DF67D>
> <804DC419>
> <804DEF6F>
> <ntoskrnl.exe:8f0fd (./ntoskrnl/ps/thread.c:90 (PspSystemThreadStartup))>

The thread state (Thread->State) is 'Ready'.

- Hartmut

[Hartmut Birr]

Alex Ionescu wrote:
> Hartmut Birr wrote:
> > It is a smp build. I'm not able to install a build with KDBG=1. It does
> > always crash at the end of the second stage setup. I've created a
> > backtrace by adding KeRosDumpStackFrames. It is rev 20554 with a highly
> > modified hal and kernel during the processor/apic initialization.
> > Hartmut
>
> Hi,
>
> Can you try the latest build please? It fixes some bugs in worker
> threads and waiting mechanisms.

Hi,

there are three places in the kernel, which does remove wait blocks.
They are in KiAbortWaitThread, KiInsertQueue and KiBlockThread. Only in
KiBlockThread, Thread->WaitBlockList is  set to NULL. Is this the problem?

- Hartmut

[Alex Ionescu]

Hartmut Birr wrote:
> Hi,
>
> there are three places in the kernel, which does remove wait blocks.
> They are in KiAbortWaitThread, KiInsertQueue and KiBlockThread. Only in
> KiBlockThread, Thread->WaitBlockList is  set to NULL. Is this the problem?
> Hartmut

Hi,

I have been reading Windows Internals II and Windows Internals 4th 
Edition and I see that the wait blocks are actually supposed to be a 
circular list... so there should never really be any "NULL". It's 
possible I based some previous code on this knowledge, which is now 
conflicting with the ROS implementation of a null-terminated list. I 
will change the wait code to use circular lists as documented and post a 
patch.

Best regards,
Alex Ionescu

[Hartmut Birr]

Alex Ionescu wrote:
> Hartmut Birr wrote:
> > Hi,
> >
> > there are three places in the kernel, which does remove wait blocks.
> > They are in KiAbortWaitThread, KiInsertQueue and KiBlockThread. Only in
> > KiBlockThread, Thread->WaitBlockList is  set to NULL. Is this the
> > problem?
> > Hartmut
>
> Hi,
>
> I have been reading Windows Internals II and Windows Internals 4th
> Edition and I see that the wait blocks are actually supposed to be a
> circular list... so there should never really be any "NULL". It's
> possible I based some previous code on this knowledge, which is now
> conflicting with the ROS implementation of a null-terminated list. I
> will change the wait code to use circular lists as documented and post
> a patch.
>
> Best regards,
> Alex Ionescu

I think, the real problem isn't if the list is NULL terminated or if the
WaitBlockList entry from thread is NULL. The real problem is,
KiAbortWaitThread is called for a thread which does not waiting.

- Hartmut

[Alex Ionescu]

Hartmut Birr wrote:
> Alex Ionescu wrote:
> > Hartmut Birr wrote:
> > > Hi,
> > >
> > > there are three places in the kernel, which does remove wait blocks.
> > > They are in KiAbortWaitThread, KiInsertQueue and KiBlockThread. Only in
> > > KiBlockThread, Thread->WaitBlockList is  set to NULL. Is this the
> > > problem?
> > > Hartmut
> >
> > Hi,
> >
> > I have been reading Windows Internals II and Windows Internals 4th
> > Edition and I see that the wait blocks are actually supposed to be a
> > circular list... so there should never really be any "NULL". It's
> > possible I based some previous code on this knowledge, which is now
> > conflicting with the ROS implementation of a null-terminated list. I
> > will change the wait code to use circular lists as documented and post
> > a patch.
> >
> > Best regards,
> > Alex Ionescu
>
> I think, the real problem isn't if the list is NULL terminated or if the
> WaitBlockList entry from thread is NULL.

Hmm perhaps not, but it's still an issue I'm going to tackle tonight 
(last time I tried it failed for mysterious reasons).
> The real problem is,
> KiAbortWaitThread is called for a thread which does not waiting.

Ok, since this happened after my worker thread patch and they use kernel 
queues, I reviewed their implementation and found a number of important 
flaws.. wether or not they cause this problem I can't tell for sure, but 
I've also added a debug print before the KeAbortWaitThread call... let 
me know if this patch fixes anything or if the dprint shoes that the 
thread isn't really waiting.
> Hartmut

Best regards,
Alex Ionescu

[Hartmut Birr]

Alex Ionescu wrote:
> Hartmut Birr wrote:
> > The real problem is,
> > KiAbortWaitThread is called for a thread which does not waiting.
>
> Ok, since this happened after my worker thread patch and they use
> kernel queues, I reviewed their implementation and found a number of
> important flaws.. wether or not they cause this problem I can't tell
> for sure, but I've also added a debug print before the
> KeAbortWaitThread call... let me know if this patch fixes anything or
> if the dprint shoes that the thread isn't really waiting.
>
> Best regards,
> Alex Ionescu

I've test your changes (r20579 with r20601,20605,20606).
KeAbortWaitThread is called for waiting threads only. But I'm running in
another problem. Compiling ros on ros (with the nice parameter '-j2')
hangs after some time. If I look to taskmgr or ctm, only the idle thread
consumes cpu power. Sometimes I can stop the compiling with Ctrl-C,
sometimes not. I wasn't able to compile ros on the smp machine. On the
up machine, one of four compile runs does finish.

- Hartmut

[James Tabor]

Hartmut Birr wrote:
> Alex Ionescu wrote:
> > Hartmut Birr wrote:
> > > The real problem is,
> > > KiAbortWaitThread is called for a thread which does not waiting.
> >
> > Ok, since this happened after my worker thread patch and they use
> > kernel queues, I reviewed their implementation and found a number of
> > important flaws.. wether or not they cause this problem I can't tell
> > for sure, but I've also added a debug print before the
> > KeAbortWaitThread call... let me know if this patch fixes anything or
> > if the dprint shoes that the thread isn't really waiting.
> >
> > Best regards,
> > Alex Ionescu
>
> I've test your changes (r20579 with r20601,20605,20606).
> KeAbortWaitThread is called for waiting threads only. But I'm running in
> another problem. Compiling ros on ros (with the nice parameter '-j2')
> hangs after some time. If I look to taskmgr or ctm, only the idle thread
> consumes cpu power. Sometimes I can stop the compiling with Ctrl-C,
> sometimes not. I wasn't able to compile ros on the smp machine. On the
> up machine, one of four compile runs does finish.
> Hartmut

Hi Hartmut,
try ps.exe and dump all the threads and processes.
Thanks,
James

[Hartmut Birr]

James Tabor wrote:
> Hartmut Birr wrote:
> > I've test your changes (r20579 with r20601,20605,20606).
> > KeAbortWaitThread is called for waiting threads only. But I'm running in
> > another problem. Compiling ros on ros (with the nice parameter '-j2')
> > hangs after some time. If I look to taskmgr or ctm, only the idle thread
> > consumes cpu power. Sometimes I can stop the compiling with Ctrl-C,
> > sometimes not. I wasn't able to compile ros on the smp machine. On the
> > up machine, one of four compile runs does finish.
> > Hartmut
>
> Hi Hartmut,
> try ps.exe and dump all the threads and processes.
> Thanks,
> James

I've attached the output from PS.  It seems, it isn't possible to
terminate AS. AS has no running threads.

- Hartmut

P     PID     PPID     KTime      UTime   NAME
t              TID     KTime      UTime   State      WaitResson
w     PID     Hwnd  WndStile        TID   WndName
P       0        0   0:07:27    0:00:00   ProcName: 
P       4        0   0:00:17    0:00:00   ProcName: System
t                8   8:44:17    0:00:00   Wait       WrQueue          
t               12   8:44:17    0:00:00   Wait       WrQueue          
t               16   8:44:17    0:00:00   Wait       WrQueue          
t               20   8:44:19    0:00:00   Wait       WrQueue          
t               24   8:44:18    0:00:00   Ready      Executive        
t               28   8:44:17    0:00:00   Wait       WrQueue          
t               32   8:44:17    0:00:00   Wait       WrQueue          
t               36   8:44:17    0:00:00   Ready      Executive        
t               40   8:44:21    0:00:00   Wait       WrQueue          
t               44   8:44:17    0:00:00   Wait       Executive        
t               48   8:44:18    0:00:00   Wait       Executive        
t               52   8:44:24    0:00:00   Wait       Executive        
t               56   8:44:17    0:00:00   Wait       Executive        
t               60   8:44:17    0:00:00   Wait       Executive        
t               64   8:44:22    0:00:00   Wait       Executive        
t               68   8:44:17    0:00:00   Wait       DelayExecution   
t               72   8:44:17    0:00:00   Wait       Executive        
t               76   8:44:18    0:00:00   Wait       Executive        
t              128   8:44:17    0:00:00   Wait       Executive        
t              132   8:44:20    0:00:00   Wait       Executive        
t              264   8:44:18    0:00:00   Wait       Executive        
P      80        4   0:00:00    0:00:00   ProcName: smss.exe
t               88   8:44:17    0:00:00   Wait       UserRequest      
t               92   8:44:17    0:00:00   Wait       UserRequest      
t               96   8:44:17    0:00:00   Wait       UserRequest      
t              100   8:44:17    0:00:00   Wait       UserRequest      
t              104   8:44:17    0:00:00   Wait       UserRequest      
t              120   8:44:17    0:00:00   Wait       UserRequest      
P     108       80   0:01:54    0:00:01   ProcName: csrss.exe
t               84   8:44:17    0:00:00   Wait       UserRequest      
t              124   8:44:18    0:00:00   Wait       UserRequest      
t              136   8:44:17    0:00:00   Wait       UserRequest      
t              140   8:44:18    0:00:00   Wait       Executive        
t              152   8:44:19    0:00:00   Wait       UserRequest      
t              156   8:44:17    0:00:00   Wait       UserRequest      
t              160   8:44:20    0:00:00   Wait       Executive        
w     108    20020  96000000        160    
t              164   8:44:18    0:00:00   Wait       Executive        
w     108    20022  86000000        164    
t              168   8:44:17    0:00:00   Wait       Executive        
w     108    20024  86000000        168    
t              180   8:44:19    0:00:00   Wait       UserRequest      
t              196   8:44:17    0:00:00   Wait       UserRequest      
t              208   8:44:17    0:00:00   Wait       UserRequest      
t              228   8:44:17    0:00:00   Wait       UserRequest      
t              252   8:44:17    0:00:00   Wait       UserRequest      
t              316   8:44:17    0:00:00   Wait       UserRequest      
t              328   8:44:18    0:00:00   Wait       UserRequest      
t              332   8:46:13    0:00:00   Wait       Executive        
w     108    200d4  04cf0000        332    
w     108    200d6  14ca0000        332   Command Prompt
w     108    200de  14ca0000        332   Command Prompt
t              340   8:44:18    0:00:00   Wait       UserRequest      
t              380   8:44:17    0:00:00   Wait       UserRequest      
t              400   8:44:17    0:00:00   Wait       UserRequest      
t              412   8:44:17    0:00:00   Wait       UserRequest      
P     144      108   0:00:00    0:00:00   ProcName: winlogon.exe
t              148   8:44:18    0:00:00   Wait       UserRequest      
w     144    20032  84000000        148   SAS
P     172      144   0:00:00    0:00:00   ProcName: services.exe
t              176   8:44:19    0:00:00   Wait       Executive        
t              184   8:44:17    0:00:00   Wait       UserRequest      
P     188      172   0:00:00    0:00:00   ProcName: eventlog.exe
t              192   8:44:19    0:00:00   Wait       UserRequest      
t              204   8:44:17    0:00:00   Wait       UserRequest      
t              200   8:44:19    0:00:00   Wait       UserRequest      
P     212      172   0:00:00    0:00:00   ProcName: umpnpmgr.exe
t              216   8:44:19    0:00:00   Wait       UserRequest      
t              224   8:44:19    0:00:00   Wait       UserRequest      
t              236   8:44:19    0:00:00   Wait       UserRequest      
t              256   8:44:19    0:00:00   Wait       UserRequest      
t              268   8:44:19    0:00:00   Wait       UserRequest      
t              272   8:44:19    0:00:00   Wait       UserRequest      
t              276   8:44:19    0:00:00   Wait       UserRequest      
t              280   8:44:19    0:00:00   Wait       UserRequest      
t              284   8:44:19    0:00:00   Wait       UserRequest      
t              288   8:44:19    0:00:00   Wait       UserRequest      
t              292   8:44:18    0:00:00   Wait       UserRequest      
t              296   8:44:19    0:00:00   Wait       UserRequest      
t              308   8:44:19    0:00:00   Wait       UserRequest      
t              312   8:44:19    0:00:00   Wait       UserRequest      
P     232      172   0:00:00    0:00:00   ProcName: dhcp.exe
t              220   8:44:18    0:00:00   Wait       DelayExecution   
t              240   8:44:17    0:00:00   Wait       Executive        
P     244      144   0:00:00    0:00:00   ProcName: userinit.exe
t              248   8:44:18    0:00:00   Wait       UserRequest      
P     300      244   0:00:01    0:00:00   ProcName: explorer.exe
t              304   8:44:22    0:00:00   Wait       Executive        
w     300    60040  84000000        304    
w     300    20042  84000000        304    
w     300    20044  84000000        304    
w     300    20046  84000000        304    
w     300    2006c  04c00000        304    
w     300    20074  94000000        304   Program Manager
w     300    20076  50010000        304   Program Manager
w     300    20078  56010340        304   Program Manager
w     300    2007c  40000002        304   Program Manager
w     300    20088  96040000        304   Program Manager
w     300    2008c  5000000b        304   Start
w     300    20090  50000045        304   Running Applications
w     300    20092  56001341        304   Running Applications
w     300    20094  84800000        304   Running Applications
w     300    20096  52000000        304   Running Applications
w     300    20098  84800003        304   Running Applications
w     300    2009a  50000000        304   Running Applications
w     300    2009c  84800003        304   Running Applications
w     300    2009e  56000b4d        304   Running Applications
w     300    200a0  84800001        304   Running Applications
w     300    200a2  5600a249        304   Running Applications
w     300    200aa  86040000        304   Start Menu
P     260      300   0:00:00    0:00:00   ProcName: cmd.exe
t              324   8:44:18    0:00:00   Wait       UserRequest      
P     344      260   0:00:04    0:00:00   ProcName: _make.EXE
t              336   8:44:31    0:00:00   Wait       UserRequest      
P     372      300   0:00:00    0:00:00   ProcName: cmd.exe
t              376   8:44:19    0:00:00   Wait       UserRequest      
P     360      344   0:00:00    0:00:00   ProcName: gcc.exe
t              404   8:44:19    0:00:00   Wait       UserRequest      
P     396      360   0:00:00    0:00:00   ProcName: as.exe

[James Tabor]

Hi!
Hartmut Birr wrote:
> t                8   8:44:17    0:00:00   Wait       WrQueue

^^^^^^^
Oh man! NOOOOO! The Kernel time is not init right so this is meaningless!
Sorry, this was a good try BTW, 8^<
James

[Alex Ionescu]

Hartmut Birr wrote:
> Alex Ionescu wrote:
> > Hartmut Birr wrote:
> > > The real problem is,
> > > KiAbortWaitThread is called for a thread which does not waiting.
> >
> > Ok, since this happened after my worker thread patch and they use
> > kernel queues, I reviewed their implementation and found a number of
> > important flaws.. wether or not they cause this problem I can't tell
> > for sure, but I've also added a debug print before the
> > KeAbortWaitThread call... let me know if this patch fixes anything or
> > if the dprint shoes that the thread isn't really waiting.
> >
> > Best regards,
> > Alex Ionescu
>
> I've test your changes (r20579 with r20601,20605,20606).
> KeAbortWaitThread is called for waiting threads only. But I'm running in
> another problem. Compiling ros on ros (with the nice parameter '-j2')
> hangs after some time. If I look to taskmgr or ctm, only the idle thread
> consumes cpu power. Sometimes I can stop the compiling with Ctrl-C,
> sometimes not. I wasn't able to compile ros on the smp machine. On the
> up machine, one of four compile runs does finish.
> Hartmut

Hi,

From what I understood from Waxdragon, my 20632 should have fixed 
this... can you try again please?

Best regards,
Alex Ionescu

[WaxDragon]

On 1/7/06, Hartmut Birr [e-mail] wrote:
> Alex Ionescu wrote:
> > Hartmut Birr wrote:
> > > The real problem is,
> > > KiAbortWaitThread is called for a thread which does not waiting.
> >
> > Ok, since this happened after my worker thread patch and they use
> > kernel queues, I reviewed their implementation and found a number of
> > important flaws.. wether or not they cause this problem I can't tell
> > for sure, but I've also added a debug print before the
> > KeAbortWaitThread call... let me know if this patch fixes anything or
> > if the dprint shoes that the thread isn't really waiting.
> >
> > Best regards,
> > Alex Ionescu
>
> I've test your changes (r20579 with r20601,20605,20606).
> KeAbortWaitThread is called for waiting threads only. But I'm running in
> another problem. Compiling ros on ros (with the nice parameter '-j2')
> hangs after some time.

When I try to selfhost with a -O2 build, I see a hang about 90% into
the build.  The hang I see is *hard*, at least under vmware, nothing
is reponding.   I don't use "-j2".
> If I look to taskmgr or ctm, only the idle thread
> consumes cpu power.

I have seen this once, I don't remember what I was doing at the time,
it may have compiling.
> Sometimes I can stop the compiling with Ctrl-C,
> sometimes not. I wasn't able to compile ros on the smp machine. On the
> up machine, one of four compile runs does finish.
> Hartmut
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

WD
--
<Alex_Ionescu> it's like saying let's rename Ke to Kernel because
people think it's Ketchup

[Hartmut Birr]

WaxDragon wrote:
> On 1/7/06, Hartmut Birr [e-mail] wrote:
> > Alex Ionescu wrote:
> > > Hartmut Birr wrote:
> > > > The real problem is,
> > > > KiAbortWaitThread is called for a thread which does not waiting.
> > >
> > > Ok, since this happened after my worker thread patch and they use
> > > kernel queues, I reviewed their implementation and found a number of
> > > important flaws.. wether or not they cause this problem I can't tell
> > > for sure, but I've also added a debug print before the
> > > KeAbortWaitThread call... let me know if this patch fixes anything or
> > > if the dprint shoes that the thread isn't really waiting.
> > >
> > > Best regards,
> > > Alex Ionescu
> >
> > I've test your changes (r20579 with r20601,20605,20606).
> > KeAbortWaitThread is called for waiting threads only. But I'm running in
> > another problem. Compiling ros on ros (with the nice parameter '-j2')
> > hangs after some time.
>
> When I try to selfhost with a -O2 build, I see a hang about 90% into
> the build.  The hang I see is *hard*, at least under vmware, nothing
> is reponding.   I don't use "-j2".
> > If I look to taskmgr or ctm, only the idle thread
> > consumes cpu power.
>
> I have seen this once, I don't remember what I was doing at the time,
> it may have compiling.
> > Sometimes I can stop the compiling with Ctrl-C,
> > sometimes not. I wasn't able to compile ros on the smp machine. On the
> > up machine, one of four compile runs does finish.
> > Hartmut

Currently I'm on r20600. After fixing some bugs (timer.c, gate.c and
wait.c), I'm able to compile ros on ros. After updating to r20601, it is
broken again. I commit the fixes if I reach the head revision.

- Hartmut

Index: ntoskrnl/ke/timer.c
===================================================================
--- ntoskrnl/ke/timer.c	(Revision 20601)
+++ ntoskrnl/ke/timer.c	(Arbeitskopie)
@@ -165,6 +165,11 @@
     return KeSetTimerEx(Timer, DueTime, 0, Dpc);
 }

+ULONG _help1;
+ULONG _help2;
+ULONG _help3;
+ULONG _help4;
+
 /*
  * @implemented
  *
@@ -247,6 +252,7 @@
     /* Query Interrupt Times */
     InterruptTime = KeQueryInterruptTime();

+    _help1 = 1;
     /* Loop through the Timer List and remove Expired Timers. Insert them into the Expired Listhead */
     LIST_FOR_EACH_SAFE(Timer, tmp, &KiTimerListHead, KTIMER, TimerListEntry)
     {
@@ -259,7 +265,9 @@
         RemoveEntryList(&Timer->TimerListEntry);
         InsertTailList(&ExpiredTimerList, &Timer->TimerListEntry);
     }
+    _help1 = 0;

+    _help2 = 1;
     /* Expire the Timers */
     while (!IsListEmpty(&ExpiredTimerList)) {

@@ -267,11 +275,13 @@

/* Get the Timer */
         Timer = CONTAINING_RECORD(CurrentEntry, KTIMER, TimerListEntry);
+        Timer->Header.Inserted = FALSE;
         DPRINT("Expiring Timer: %x\n", Timer);

/* Expire it */
         KiHandleExpiredTimer(Timer);
     }
+    _help2 = 0;

DPRINT("Timers expired\n");

@@ -301,7 +311,9 @@
     /* Set it as Signaled */
     DPRINT("Setting Timer as Signaled\n");
     Timer->Header.SignalState = TRUE;
+    _help3 = 1;
     KiWaitTest(&Timer->Header, IO_NO_INCREMENT);
+    _help3 = 0;

/* If the Timer is periodic, reinsert the timer with the new due time */
     if (Timer->Period) {
@@ -321,10 +333,11 @@
         DPRINT("Timer->Dpc %x Timer->Dpc->DeferredRoutine %x\n", Timer->Dpc, Timer->Dpc->DeferredRoutine);

/* Insert the DPC */
+        _help4 = 1;
         KeInsertQueueDpc(Timer->Dpc,
                          NULL,
                          NULL);
-
+	_help4 = 0;
         DPRINT("Finished dpc routine\n");
     }
 }
Index: ntoskrnl/ke/gate.c
===================================================================
--- ntoskrnl/ke/gate.c	(Revision 20601)
+++ ntoskrnl/ke/gate.c	(Arbeitskopie)
@@ -136,7 +136,6 @@
     /* Reschedule the Thread */
     DPRINT("Unblocking the Thread\n");
     KiUnblockThread(WaitThread, &WaitStatus, EVENT_INCREMENT);
-    return;

quit:
     /* Release the Dispatcher Database Lock */
Index: ntoskrnl/ke/wait.c
===================================================================
--- ntoskrnl/ke/wait.c	(Revision 20601)
+++ ntoskrnl/ke/wait.c	(Arbeitskopie)
@@ -152,6 +152,7 @@
         {
             /* FIXME: The timer already expired, we should find a new ready thread */
             Status = STATUS_SUCCESS;
+            CHECKPOINT1;
             break;
         }

@@ -329,6 +330,7 @@
             {
                 /* Return a timeout if we couldn't insert the timer */
                 Status = STATUS_TIMEOUT;
+                CHECKPOINT1;
                 goto DontWait;
             }
         }
@@ -560,6 +562,7 @@
             {
                 /* Return a timeout */
                 Status = STATUS_TIMEOUT;
+                CHECKPOINT1;
                 goto DontWait;
             }

@@ -808,6 +811,10 @@
     {
         KiDispatchThreadNoLock(Ready);
     }
+    else
+    {
+        KeReleaseDispatcherDatabaseLockFromDpcLevel();    
+    }

/* Lower irql back */
     KeLowerIrql(OldIrql);
Index: ntoskrnl/include/internal/ke.h
===================================================================
--- ntoskrnl/include/internal/ke.h	(Revision 20601)
+++ ntoskrnl/include/internal/ke.h	(Arbeitskopie)
@@ -62,7 +62,6 @@
 #define KeReleaseDispatcherDatabaseLockFromDpcLevel() \
     KeReleaseSpinLockFromDpcLevel(&DispatcherDatabaseLock);
 #define KeReleaseDispatcherDatabaseLock(OldIrql) \
-    KeReleaseSpinLockFromDpcLevel(&DispatcherDatabaseLock); \
     KiExitDispatcher(OldIrql);
 #endif

@@ -675,7 +674,7 @@

VOID
 NTAPI
-KeApplicationProcessorInit(VOID);
+KeApplicationProcessorInit(ULONG);

VOID
 NTAPI

[Ge van Geldorp]

> From: Hartmut Birr
>
> Currently I'm on r20600.

I was wondering "why such an old version", until I looked up the date: 6
Jan. 150 commits in 3 days, I'd say this project is alive and kicking :-)

GvG

[Magnus Olsen]

The
svn.reactos.org is up and roung again
I just update my local tree

----- Original Message ----- 
From: "Hartmut Birr" [e-mail]
To: "ReactOS Development List" [e-mail]
Sent: den 9 January 2006 16:32
Subject: Re: [ros-dev] Re: [ros-svn] [ion] 20554: - Fix shamefully
dangerouslybroken Work Thread/Queue/Item implementation:
> WaxDragon wrote:
> > On 1/7/06, Hartmut Birr [e-mail] wrote:
> > > Alex Ionescu wrote:
> > > > Hartmut Birr wrote:
> > > > > The real problem is,
> > > > > KiAbortWaitThread is called for a thread which does not waiting.
> > > >
> > > > Ok, since this happened after my worker thread patch and they use
> > > > kernel queues, I reviewed their implementation and found a number of
> > > > important flaws.. wether or not they cause this problem I can't tell
> > > > for sure, but I've also added a debug print before the
> > > > KeAbortWaitThread call... let me know if this patch fixes anything or
> > > > if the dprint shoes that the thread isn't really waiting.
> > > >
> > > > Best regards,
> > > > Alex Ionescu
> > >
> > > I've test your changes (r20579 with r20601,20605,20606).
> > > KeAbortWaitThread is called for waiting threads only. But I'm running

in
> > > another problem. Compiling ros on ros (with the nice parameter '-j2')
> > > hangs after some time.
> >
> > When I try to selfhost with a -O2 build, I see a hang about 90% into
> > the build.  The hang I see is *hard*, at least under vmware, nothing
> > is reponding.   I don't use "-j2".
> > > If I look to taskmgr or ctm, only the idle thread
> > > consumes cpu power.
> >
> > I have seen this once, I don't remember what I was doing at the time,
> > it may have compiling.
> > > Sometimes I can stop the compiling with Ctrl-C,
> > > sometimes not. I wasn't able to compile ros on the smp machine. On the
> > > up machine, one of four compile runs does finish.
> > > Hartmut
>
> Currently I'm on r20600. After fixing some bugs (timer.c, gate.c and
> wait.c), I'm able to compile ros on ros. After updating to r20601, it is
> broken again. I commit the fixes if I reach the head revision.
> Hartmut

----------------------------------------------------------------------------
----
> Index: ntoskrnl/ke/timer.c
>
> --- ntoskrnl/ke/timer.c (Revision 20601)
> +++ ntoskrnl/ke/timer.c (Arbeitskopie)
> @@ -165,6 +165,11 @@
>      return KeSetTimerEx(Timer, DueTime, 0, Dpc);
>  }
>
> +ULONG _help1;
> +ULONG _help2;
> +ULONG _help3;
> +ULONG _help4;
>
> /*
> @implemented
>
> @@ -247,6 +252,7 @@
>      /* Query Interrupt Times */
>      InterruptTime = KeQueryInterruptTime();
> _help1 = 1;
> /* Loop through the Timer List and remove Expired Timers. Insert them

into the Expired Listhead */
>  LIST_FOR_EACH_SAFE(Timer, tmp, &KiTimerListHead, KTIMER,

TimerListEntry)
>  {
>
> @@ -259,7 +265,9 @@
>          RemoveEntryList(&Timer->TimerListEntry);
>          InsertTailList(&ExpiredTimerList, &Timer->TimerListEntry);
>      }
>
> _help1 = 0;
>
> _help2 = 1;
> /* Expire the Timers */
> while (!IsListEmpty(&ExpiredTimerList)) {
>
> @@ -267,11 +275,13 @@
>      /* Get the Timer */
>      Timer = CONTAINING_RECORD(CurrentEntry, KTIMER, TimerListEntry);
>    Timer->Header.Inserted = FALSE;
>    DPRINT("Expiring Timer: %x\n", Timer);
>
>    /* Expire it */
>    KiHandleExpiredTimer(Timer);
>
> }
>
> _help2 = 0;
>
> DPRINT("Timers expired\n");
>
> @@ -301,7 +311,9 @@
>      /* Set it as Signaled */
>      DPRINT("Setting Timer as Signaled\n");
>      Timer->Header.SignalState = TRUE;
>
> _help3 = 1;
> KiWaitTest(&Timer->Header, IO_NO_INCREMENT);
>
> _help3 = 0;
>
> /* If the Timer is periodic, reinsert the timer with the new due time

*/
>  if (Timer->Period) {
>
> @@ -321,10 +333,11 @@
>          DPRINT("Timer->Dpc %x Timer->Dpc->DeferredRoutine %x\n",

Timer->Dpc, Timer->Dpc->DeferredRoutine);
>      /* Insert the DPC */
>    _help4 = 1;
>    KeInsertQueueDpc(Timer->Dpc,
>                     NULL,
>                     NULL);
> _help4 = 0;
>        DPRINT("Finished dpc routine\n");
>    }
>
> }
> Index: ntoskrnl/ke/gate.c
> ===================================================================
> --- ntoskrnl/ke/gate.c (Revision 20601)
> +++ ntoskrnl/ke/gate.c (Arbeitskopie)
> @@ -136,7 +136,6 @@
>      /* Reschedule the Thread */
>      DPRINT("Unblocking the Thread\n");
>      KiUnblockThread(WaitThread, &WaitStatus, EVENT_INCREMENT);
> return;
>
> quit:
>      /* Release the Dispatcher Database Lock */
> Index: ntoskrnl/ke/wait.c
> ===================================================================
> --- ntoskrnl/ke/wait.c (Revision 20601)
> +++ ntoskrnl/ke/wait.c (Arbeitskopie)
> @@ -152,6 +152,7 @@
>          {
>              /* FIXME: The timer already expired, we should find a new

ready thread */
>          Status = STATUS_SUCCESS;
>        CHECKPOINT1;
>        break;
>    }
>
> @@ -329,6 +330,7 @@
>              {
>                  /* Return a timeout if we couldn't insert the timer */
>                  Status = STATUS_TIMEOUT;
>            CHECKPOINT1;
>            goto DontWait;
>        }
>    }
>
> @@ -560,6 +562,7 @@
>              {
>                  /* Return a timeout */
>                  Status = STATUS_TIMEOUT;
>            CHECKPOINT1;
>            goto DontWait;
>        }
>
> @@ -808,6 +811,10 @@
>      {
>          KiDispatchThreadNoLock(Ready);
>      }
>
> else
>
> {
>    KeReleaseDispatcherDatabaseLockFromDpcLevel();
>
> }
>
> /* Lower irql back */
> KeLowerIrql(OldIrql);
> Index: ntoskrnl/include/internal/ke.h
>
> --- ntoskrnl/include/internal/ke.h (Revision 20601)
> +++ ntoskrnl/include/internal/ke.h (Arbeitskopie)
> @@ -62,7 +62,6 @@
>  #define KeReleaseDispatcherDatabaseLockFromDpcLevel() \
>      KeReleaseSpinLockFromDpcLevel(&DispatcherDatabaseLock);
>  #define KeReleaseDispatcherDatabaseLock(OldIrql) \
> KeReleaseSpinLockFromDpcLevel(&DispatcherDatabaseLock); \
> KiExitDispatcher(OldIrql);
>
> #endif
>
> @@ -675,7 +674,7 @@
>
> VOID
>  NTAPI
> -KeApplicationProcessorInit(VOID);
> +KeApplicationProcessorInit(ULONG);
>
> VOID
>  NTAPI

----------------------------------------------------------------------------
----
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev