On Wed, Jun 9, 2010 at 12:02 PM, Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx> wrote: > On Tue, 2010-06-08 at 13:32 -0600, Eric W Anderson wrote: >> Hi Sven, >> >> The device manufacturer has made some kernel modifications to support their >> board, and those are specific to 2.6.19. (In fact, they're specific to >> 2.6.19.2 OpenWRT patches). There's also a large driver which is appropriate >> for an old kernel but would need some re-engineering to deal with API changes >> in 2.6.20 or 2.6.21, I believe. >> >> So, if getting high-resolution timing with this kernel is going to be a >> nightmare, I can try taking on a newer kernel. But it'll be an ordeal. >> > > Don't know really what to say. > > With the device manufacturer not pushing / maintaining code upstream, > that sounds like a non-starter already. > > The ixp425 is supported by folks like MontaVista, maybe Wind River iirc. > > The former has had some sort of HRT support for a long time, it might > get you the functionality you need. > > But in any case, I'd try and walk the drivers forward, rather than try > to back-port HRT. > > You're unlikely to get much support for such an old Kernel if you run > into other issues, so the more up to date you can get, the better. > > Good luck. > > Sven > >> -Eric >> >> >> Thus spake Sven-Thorsten Dietrich (thebigcorporation@xxxxxxxxx): >> >> > On Tue, 2010-06-08 at 12:17 -0600, Eric W Anderson wrote: >> > > Hello All, >> > >> > Hi Eric, >> > >> > 2.6.19 is very very old. >> > >> > What is preventing you from a Kernel upgrade? >> > >> > Sven >> > >> > >> > > >> > > I can't figure out (or haven't figured out) how to get actual high-resolution >> > > timers on the above platform. I'm kind of stuck with 2.6.19, unfortunately. >> > > I've applied the -rt patch to stock 2.6.19, merged in some random patches to >> > > support my hardware, and gotten it to boot. But, here's what confuses me: I >> > > have the hrtimer API, but my actual clock resolution is still shown as 10ms. >> > > >> > > root@patty:/# cat /proc/timer_list >> > > Timer List Version: v0.1 >> > > HRTIMER_MAX_CLOCK_BASES: 2 >> > > now at 2766685920305 nsecs >> > > >> > > cpu: 0 >> > > clock 0: >> > > .index: 0 >> > > .resolution: 10000000 nsecs >> > > .get_time: ktime_get_real >> > > active timers: >> > > clock 1: >> > > .index: 1 >> > > .resolution: 10000000 nsecs >> > > .get_time: ktime_get >> > > active timers: >> > > #0: <c4615ec8>, hrtimer_wakeup >> > > # expires at 2766802147358 nsecs [in 116227053 nsecs] >> > > #1: <c4615ec8>, it_real_fn >> > > # expires at 2767494816966 nsecs [in 808896661 nsecs] >> > > #2: <c4615ec8>, it_real_fn >> > > # expires at 3642163204498 nsecs [in 875477284193 nsecs] >> > > #3: <c4615ec8>, it_real_fn >> > > # expires at 3643403169278 nsecs [in 876717248973 nsecs] >> > > >> > > Additionally, I don't see CONFIG_HIGH_RES_TIMERS anywhere in my kernel >> > > menuconfig. I've added a patch from Kevin Hilman and Milan Svoboda >> > > (http://lkml.indiana.edu/hypermail/linux/kernel/0607.1/2343.html) which >> > > purports to enable a high-resolution clock event source for this board, but >> > > that doesn't seem to change anything. >> > > >> > > I think I don't properly understand the preempt_rt / hrtimers / >> > > board-specific-bits ecosystem here. What are the bits and pieces I need in >> > > order to have high-resolution timers on this platform? >> > > >> > > Many, many thanks, >> > > Eric Anderson >> > > >> > > >> > >> > >> > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > while upgrading to newer kernel sounds great, which I just did(from 2.6.18rt to 2.6.33rt), the newer kernel sometimes does not perform as well as older ones(plus it's also bloated), esp in embedded products. In my case, we got a slower product with the newer kernel, the 'worse' performance happened immediately when CFS was added. Even after a long time debugging and tweaking, it's still there. xianghua -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
