At a loss: Kernel 2.6.19-rt15 with ixp425

At a loss: Kernel 2.6.19-rt15 with ixp425

[Eric W Anderson]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

Hello All,

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


-- 
Eric W. Anderson                                   University of Colorado
eric.anderson@colorado.edu                      Dept. of Computer Science
phone: +1-720-984-8864                   Systems Research Lab - ECCR 1B54

                         PGP key fingerprints:
       personal: 1BD4 CFCE 8B59 8D6E EA3E  EBD5 4DC9 3E61 656C 462B
       academic: D3C5 D6FF EDED 9F1F C36D  53A3 74B7 53A6 3C74 5F12

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Sven-Thorsten Dietrich]

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
> 
> 

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

[Eric W Anderson]

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

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.

-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
> > 
> > 
> 
> 

-- 
Eric W. Anderson                                   University of Colorado
eric.anderson@colorado.edu                      Dept. of Computer Science
phone: +1-720-984-8864                   Systems Research Lab - ECCR 1B54

                         PGP key fingerprints:
       personal: 1BD4 CFCE 8B59 8D6E EA3E  EBD5 4DC9 3E61 656C 462B
       academic: D3C5 D6FF EDED 9F1F C36D  53A3 74B7 53A6 3C74 5F12

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Sven-Thorsten Dietrich]

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
> > > 
> > > 
> > 
> > 
> 

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

[Xianghua Xiao]

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

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

[Sven-Thorsten Dietrich]

On Wed, 2010-06-09 at 13:50 -0500, Xianghua Xiao wrote:

> 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

I am sure if you provided some specific code or performance data to
substantiate that regression someone here (or on LKML) would take
interest.

Regards

Sven