Executable delay

James Bates jbates at paradise.co.uk
Mon Dec 22 20:58:22 EST 2003

Hi All,

I have had my first real poke around the kernel and it looks like I was
correct in saying that any task accessing the DOC drivers was put into an
incorrect state. The code that seemed to do the damage can be found in
drivers/mtd/devices/doc2000.c in the function _DoC_WaitReady().

The problem seems to be the call to cond_resched which is not in slightly
older kernel versions. To fix the bug I reverted this function back to the
code in version 2.4.10 of the kernel.

After making these changes it appears to work perfectly. My question now is.
Have I inadvertently broken something without knowing it.

Kind Regards,

James Bates

PS: My  _DoC_WaitReady is as follows:

/* DOC_WaitReady: Wait for RDY line to be asserted by the flash chip */
static int _DoC_WaitReady(struct DiskOnChip *doc)
	unsigned long docptr = doc->virtadr;
	unsigned long timeo = jiffies + (HZ * 10);
	unsigned long timeo = jiffies + 1;

	      "_DoC_WaitReady called for out-of-line wait\n");

	/* Out-of-line routine to wait for chip response */
	while (!(ReadDOC(docptr, CDSNControl) & CDSN_CTRL_FR_B)) {
		if (time_after(jiffies, timeo)) {
			DEBUG(MTD_DEBUG_LEVEL2, "_DoC_WaitReady timed out.\n");
			return -EIO;
// This is the "new" code from version 2.4.23
//		udelay(1);
//		cond_resched();
// Revert back to old task state management in 2.4.10
		if (current->need_resched) {
// End of 2.4.10 code

	return 0;

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-embedded mailing list