Bug 10789
Summary: | hrtimer_get_res() problem (pcsp does not work) | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | Magosányi Árpád (m4gw4s) |
Component: | i386 | Assignee: | john stultz (john.stultz) |
Status: | REJECTED DOCUMENTED | ||
Severity: | normal | CC: | mingo, platform_i386, stsp2, tglx |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.26-rc3 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Magosányi Árpád
2008-05-24 23:08:46 UTC
I'll reassign this to platform_i386@kernel-bugs.osdl.org. > > [ 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.
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
|