Re: is minimum udelay() not respected in preemptible SMP kernel-2.6.23?

Andrew Morton
2007-11-07T20:31:42Z

> On Wed, 7 Nov 2007 19:21:52 +0200 Marin Mitov <mitov@issp.bas.bg> wrote:
> Hi all,
>
> I have written a linux device driver for a frame grabber I use in my
> every day experimental work.
>
> In my device driver I have to write to a MMIO register, wait for a while
> (using udelay(65)) for data being written to an internal register (i2c?)
> and test a flag (in another MMIO register) if the operation has completed.
> (The hardware guarantees that the operation has completed in less than
> 65 usec). If the flag is not reset I write a message via printk.
> After switching to the kernel-2.6.23 (compiled as PREEMPTIBLE SMP i686)
> (AMD dual core) I see this message in dmesg output sometime.
>
> Testing with rdtscll() before and after udelay(65) shows the expected
> delay of 65 usec (after dividing by CPU frequency) when all is OK, but
> gives a big value (in the tenths msec range) when the error message
> shows itself in dmesg.
>
> Bracketing udelay(65) by:
>
> local_irq_disable();
> udelay(65);
> local_irq_enable();
>
> as well as by
>
> preempt_disable();
> udelay(65);
> preempt_enable();
>
> leads to message disappearing.
>
> I believe the hardware is working correctly, so if the flag is not reset
> I think udelay(65) returns prematurely (the flag clears some time latter)
> And it does not matter if I use udelay(65) or udelay(100).
>
> What could be the reason for such a behavior?
> Is this a bug in udelay() due to preemption?
> (udelay() being preempted and migrated to another processor)
>
> All my previous kernels used were SMP (but not PREEMPTIBLE)
>
> My kernel is compiled with:
> CONFIG_PREEMPT=y
> CONFIG_IRQBALANCE=y
> CONFIG_HPET_TIMER=y
>
> And I have this line in dmesg:
> Time: acpi_pm clocksource has been installed.
> Switched to high resolution mode on CPU 0
> Switched to high resolution mode on CPU 1
>
> The south bridge is: VIA VT8237 (Asus A8V Delux)
>
> Thank you in advance for your help in understanding where
> the problem is coming from.
>

Ow. Yes, from my reading delay_tsc() can return early (or after
heat-death-of-the-universe) if the TSCs are offset and if preemption
migrates the calling task between CPUs.

I suppose a lameo fix would be to disable preemption in delay_tsc().