Messages in this thread | | | Date | Mon, 26 May 2008 12:50:49 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: hrtimer_get_res() problem (pcsp does not work) |
| |
On Fri, 23 May 2008, Stas Sergeev wrote: > Magosányi Árpád wrote: > > code: > > hrtimer_get_res(CLOCK_MONOTONIC, &tp); > > + printk(KERN_INFO "PCSP: sec=%li, nsec=%linS\n",tp.tv_sec, tp.tv_nsec); > > > > output: > > [ 22.882520] PCSP: sec=0, nsec=1nS > > after an rmmod and modprobe: > > [ 476.300571] PCSP: sec=0, nsec=1nS > > after an rmmod, changing clocksource to tsc, and insmod: > > [ 669.124557] PCSP: sec=0, nsec=1nS > OK, thanks you. > In this case I suspect this is not an > snd-pcsp bug, but a hrtimer bug. Adding > more people to CC. > > So what we have: > --- > I have a PIIX4 chipset, the full dmesg is attached. > Note that it is an old 400Mhz pentium, and there is some problem with > the timer source I use: > [ 0.822740] * Found PM-Timer Bug on the chipset. Due to workarounds > for a bug, > [ 0.822750] * this clock source is slow. Consider trying other clock > sources > --- > and (presumably) because of that PM-Timer > Bug, snd-pcsp produces only the noice. > dmesg said that the clock source is slow, > yet the hrtimer_get_res() claims the > resolution is 1nS. I think this is wrong, > hrtimer_get_res() might be broken. > Can someone please comment on that? > Is hrtimer_get_res() known to return 1nS > regardless of the real clock resolution?
It's not an hrtimer bug. The kernel internal time has nsec units.
The internal resolution of hrtimers is HZ when high resolution timers are disabled or 1nsec when high resolution timers are available and active.
We can not expose an exact resolution in this interface as this depends on too many factors and it would be a horrible hackery to take the theroetical resolution which results from the available clock source and the resolution of the device which generates the timer events into account in the hrtimer code. Even if we would expose an interface which lets you know the exact resulting resolution there is no guarantee that a timer meets its expiry time exactly.
The pmtimer bug is not causing the problems you have. It just slows down the access to the pmtimer (instead of reading it straight we need to read twice and do a sanity check).
Thanks, tglx | |