Back to back mtdchar reads causing massive kernel latencies?

[Christian Melki]

Hi.

I have a powerpc 8347 attached to a nor-flash.
On the device sits a hardware watchdog with non changeable
watchdog timeout at minimum 1600ms (likely almost 3 seconds,
depending on external temperature).
The kernel has timers to kick the watchdog once every second.
This has never been a problem, not even at 100% userspace load.
But when I do back to back reads using mtdchar with eraseblock
sizes, the watchdog times out.
This does not happen in any other situation and I can reliably
reproduce it with dd to any of my mtdchar devices.
Also, it does not happen if I use mtdblock instead which seem to
have a schedule()inside it's worker loop.
But I can't figure out why this would ever happen to the
mtdchar device?
Switching between userland and kernelspace with the data would
cause a scheduling point for the kernel anyway, right?
Is someone packing the back-to-back reads into something very
large that does not return in time?
Strace tells me that the reads are still 128k large.
A timed normal read on 128k eraseblock takes approx. 70ms.

I can see that the cmdset for the flash has schedule points at
erase and some other xip stuff, but not in the read path.
I have tried HZ at 100 and 1000, with and without preemption and
with and without NO_HZ. Same result.

Clues as to what's happening anyone?

Regards,
Christian