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

[Marin Mitov <mitov@issp.bas.bg>]

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.

Best regards.

Marin Mitov