Re: At a loss: Kernel 2.6.19-rt15 with ixp425

[Xianghua Xiao <xiaoxianghua@gmail.com>]

On Wed, Jun 9, 2010 at 12:02 PM, Sven-Thorsten Dietrich
<thebigcorporation@gmail.com> 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@gmail.com):
>>
>> > 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html