DOC2000 + PPM-TX166 (PATCH)

[Jim Duchek <jduchek@genaero.com>]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

Hello.  I'm not subscribed to the mailing list, so please, if you could 
make sure any replies for me go to my address and not to the list, I 
would appreciate.

We saw a problem (actually, a pretty big problem) wherein when a sync() 
was done on a filesystem on the DoC we were using, it would hang and 
never come back.  The system was perfectly responsive, except trying to 
talk to the DoC wasn't going to happen again until reboot.  The problem 
would never occur if we let the fs sync itself -- that is, just wait a 
few minutes until the buffers have been cleared.

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.  The patch 
is short and appended to this message.  I believe the patch should be 
Good for all users, although I'm not sure why we don't see this problem 
on some other setups.  My best guess is that the other setups we are 
using have Geode processors, which I don't believe have a TSC, and our 
P-MMX does have one, and udelay() is totally different depending on the 
existence of a TSC.

For those curious, we are using an unpatched 2.4.22 kernel on a 
WinSystems PPM-TX166.  The DoC in question is a 48M Industrial (X) rated 
chip.  We saw the problem with both msdos and ext2 filesystems.




[-- Attachment #2: doc2000.patch --]
[-- Type: text/plain, Size: 149 bytes --]

94a95
> 		yield();
99,100d99
< 		udelay(1);
< 		cond_resched();
101a101,104
> 	
> 	DEBUG(MTD_DEBUG_LEVEL3,
> 	      "_DoC_WaitReady finished\n");
>