[SOLVED] mdelay erratic behavior

I'm attempting to debug a driver on a code base I've inherited.
One of the drivers which my system reads is causing my entire firmware to hang when the driver reads from a device.

The code goes something like this.

ioctl call to read driver value()
{

Loop 25 times
{

If the is hardware working/readable

read the driver value
break;

If the hardware is not working/readable

mdelay(100);

}

If the hardware wasn't ever working/readable in the last loop
{

printf("Driver Failed\n");
return failure;

}
return success;

}

From the looks of this if the driver isn't readable it should retry for 2.5 seconds then return a failure. I'm seeing that this happens correctly right after I flash and boot the chip. Then I hard power the whole system and let it all boot up again. Now the behavior changes. The system hangs in the ioctl call for ~350 seconds. The odd part is that it prints the Driver Failed message at the beginning of the hang.

One would think that if the Driver Failed message was shown the function would return right away! This is not the case. I've done some timing tests and the hang is directly related to (number of loop retries * mdelay milliseconds).

I was thinking of coding a workaround by creating my own delay function using f_time but before doing that I wanted to see if anyone had a better idea of what is going on first.

The location may be different in your environment, but in my situation the file that describes the rationale behind the choice amongst mdelay(), udelay(), ndelay(), msleep(), or usleep() is:

/usr/src/linux/Documentation/timers/timers-howto.txt

You might wish to consult the corresponding file in your environment.

Also, if you are doing some sort of processor sharing, the timing might be off because certain situations may effectively rely on virtualized timing.

Then too, you might want to consider how closely the exact source code matches the pseudo-code you've provided, and whether or not there is some need to break out a separate test.

For example, is it possible to have a separate test to see if the device is "working", as opposed to whether or not the device is readable at a given instant. After all, when you reboot the machine, in principle, an "init pulse" so to speak, is sent to the hardware devices, which should reset things to a stable state. Whereas during operation, if there is any problem with the device, or driver, the exact state of the physical device may not be known. If I'm understanding you correctly, one or more such factors might provide for the seemingly erratic behavior.

calling a blocking delay in a driver is a bad idea. It prevents everything else from updating including timers since it is a system level priority.