Re: hrtimer_get_res() problem (pcsp does not work)

[Thomas Gleixner <tglx@linutronix.de>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2172 bytes --]

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