DOC2000 + PPM-TX166 (PATCH)

[Jim Duchek]

I'll take a look at getting you that backtrace -- I don't think we have 
one of our boxes with a keyboard/video on it right now, but next time I 
get the opportunity I'll get you that.  I haven't tried removing the 
udelay.  I didn't consider that the udelay might have been the problem 
until after I'd put the yield() in, and then later was discussing what 
the difference might have been and I thought of the TSC/non-TSC 
udelays.  I'll give that a shot tomorrow as well -- it really ought to 
be removed anyhow if a resched() is going to happen right after it.  We 
did try the latest CVS code (perhaps two weeks ago) and saw no 
difference, so reverted back to the 2.4.22 released version. 


Jim

David Woodhouse wrote:

>On Wed, 2003-11-05 at 11:20 -0600, Jim Duchek wrote:
>  
>
>>I traced the problem down to the cond_resched() in WaitReady in 
>>doc2000.c.  Removing cond_resched() made the problem go away (and the 
>>system unresponsive while doing any DoC access).  Replacing the 
>>udelay(1) and cond_resched() with a yield() fixes everything. 
>>    
>>
>
>Very strange. Calling yield() really isn't what we want there; we wanted
>cond_resched(). What if you leave the cond_resched() and remove the
>udelay()? What if you make the udelay() larger?
>
>When the system is locked up as you described, can you hit SysRq-T to
>see the backtrace of the stuck thread, and show me the (decoded) output.
>
>Does the same happen even with the current CVS code?
>
>  
>