Messages in this thread | | | Date | Wed, 7 Nov 2007 12:30:45 -0800 | From | Andrew Morton <> | Subject | Re: is minimum udelay() not respected in preemptible SMP kernel-2.6.23? |
| |
> 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(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |