Executable delay

[James Bates]

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;
#ifndef CONFIG_MTD_DOCPROBE_SHORT_TIMEOUTS
	unsigned long timeo = jiffies + (HZ * 10);
#else
	unsigned long timeo = jiffies + 1;
#endif

	DEBUG(MTD_DEBUG_LEVEL3,
	      "_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) {
			set_current_state(TASK_UNINTERRUPTIBLE);
			schedule_timeout(1);
		}
		else
			udelay(1);
// End of 2.4.10 code
	}

	return 0;
}


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