* Not able to use HIGH_RES_TIMERS on ARM @ 2012-03-19 13:01 Ajeet Yadav 2012-03-19 13:04 ` Russell King - ARM Linux 0 siblings, 1 reply; 21+ messages in thread From: Ajeet Yadav @ 2012-03-19 13:01 UTC (permalink / raw) To: Russell King - ARM Linux, John Stultz, linux-kernel, Steven Rostedt Hi John, refering to you patch: ARM: remove 'select GENERIC_TIME' GENERIC_TIME is now enabled by default, so 'select GENERIC_TIME' is redundant. Remove them. The following config's are not selectable: config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config PREEMPT_TRACER As far as I know, ARM now uses GENERIC_TIME via the arch_getoffset() infrastructure, i.e ARCH_USES_GETTIMEOFFSET=y diff -Naurp -X linux-3.0.20/Documentation/dontdiff linux-3.0.20/kernel/time/Kconfig linux-3.0.20-dirty/kernel/time/Kconfig --- linux-3.0.20/kernel/time/Kconfig 2012-02-06 23:01:45.000000000 +0530 +++ linux-3.0.20-dirty/kernel/time/Kconfig 2012-03-19 18:22:32.000000000 +0530 @@ -6,7 +6,7 @@ config TICK_ONESHOT config NO_HZ bool "Tickless System (Dynamic Ticks)" - depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS + depends on GENERIC_CLOCKEVENTS select TICK_ONESHOT help This option enables a tickless system: timer interrupts will @@ -15,7 +15,7 @@ config NO_HZ config HIGH_RES_TIMERS bool "High Resolution Timer Support" - depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS + depends on GENERIC_CLOCKEVENTS select TICK_ONESHOT help This option enables high resolution timer support. If your diff -Naurp -X linux-3.0.20/Documentation/dontdiff linux-3.0.20/kernel/trace/Kconfig linux-3.0.20-dirty/kernel/trace/Kconfig --- linux-3.0.20/kernel/trace/Kconfig 2012-02-06 23:01:45.000000000 +0530 +++ linux-3.0.20-dirty/kernel/trace/Kconfig 2012-03-19 18:21:41.000000000 +0530 @@ -173,7 +173,6 @@ config IRQSOFF_TRACER bool "Interrupts-off Latency Tracer" default n depends on TRACE_IRQFLAGS_SUPPORT - depends on !ARCH_USES_GETTIMEOFFSET select TRACE_IRQFLAGS select GENERIC_TRACER select TRACER_MAX_TRACE @@ -195,7 +194,6 @@ config IRQSOFF_TRACER config PREEMPT_TRACER bool "Preemption-off Latency Tracer" default n - depends on !ARCH_USES_GETTIMEOFFSET depends on PREEMPT select GENERIC_TRACER select TRACER_MAX_TRACE ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-19 13:01 Not able to use HIGH_RES_TIMERS on ARM Ajeet Yadav @ 2012-03-19 13:04 ` Russell King - ARM Linux 2012-03-19 13:19 ` Ajeet Yadav 0 siblings, 1 reply; 21+ messages in thread From: Russell King - ARM Linux @ 2012-03-19 13:04 UTC (permalink / raw) To: Ajeet Yadav; +Cc: John Stultz, linux-kernel, Steven Rostedt On Mon, Mar 19, 2012 at 06:31:44PM +0530, Ajeet Yadav wrote: > Hi John, refering to you patch: > > ARM: remove 'select GENERIC_TIME' > GENERIC_TIME is now enabled by default, so 'select GENERIC_TIME' is > redundant. Remove them. > > The following config's are not selectable: > config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config > PREEMPT_TRACER > > As far as I know, ARM now uses GENERIC_TIME via the arch_getoffset() > infrastructure, i.e ARCH_USES_GETTIMEOFFSET=y No. It is possible to select these options, but only if your platform uses the clockevent and clocksource infrastructure. If you're using that, then you must _not_ select ARCH_USES_GETTIMEOFFSET. ARCH_USES_GETTIMEOFFSET is for compatibility with old unconverted platforms, which are _not_ possible to use the above features. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-19 13:04 ` Russell King - ARM Linux @ 2012-03-19 13:19 ` Ajeet Yadav 2012-03-19 13:26 ` Russell King - ARM Linux 0 siblings, 1 reply; 21+ messages in thread From: Ajeet Yadav @ 2012-03-19 13:19 UTC (permalink / raw) To: Russell King - ARM Linux; +Cc: John Stultz, linux-kernel, Steven Rostedt On Mon, Mar 19, 2012 at 6:34 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Mar 19, 2012 at 06:31:44PM +0530, Ajeet Yadav wrote: >> Hi John, refering to you patch: >> >> ARM: remove 'select GENERIC_TIME' >> GENERIC_TIME is now enabled by default, so 'select GENERIC_TIME' is >> redundant. Remove them. >> >> The following config's are not selectable: >> config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config >> PREEMPT_TRACER >> >> As far as I know, ARM now uses GENERIC_TIME via the arch_getoffset() >> infrastructure, i.e ARCH_USES_GETTIMEOFFSET=y > > No. It is possible to select these options, but only if your platform > uses the clockevent and clocksource infrastructure. If you're using that, > then you must _not_ select ARCH_USES_GETTIMEOFFSET. > > ARCH_USES_GETTIMEOFFSET is for compatibility with old unconverted > platforms, which are _not_ possible to use the above features. Just before the patch "time: Kill off CONFIG_GENERIC_TIME" Generic time was selectable option, Therefore our target configuration with 2.6 kernel was GENERIC_CLOCKEVENTS=y, ARCH_USES_GETTIMEOFFSET=y, I conclude that GENERIC_CLOCKEVENTS is supported, hence I must set ARCH_USES_GETTIMEOFFSET=n, in order to use NO_HZ, HIGH_RES_TIMERS, IRQSOFF_TRACER, PREEMPT_TRACER ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-19 13:19 ` Ajeet Yadav @ 2012-03-19 13:26 ` Russell King - ARM Linux 2012-03-21 4:58 ` John Stultz 0 siblings, 1 reply; 21+ messages in thread From: Russell King - ARM Linux @ 2012-03-19 13:26 UTC (permalink / raw) To: Ajeet Yadav; +Cc: John Stultz, linux-kernel, Steven Rostedt On Mon, Mar 19, 2012 at 06:49:34PM +0530, Ajeet Yadav wrote: > On Mon, Mar 19, 2012 at 6:34 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Mar 19, 2012 at 06:31:44PM +0530, Ajeet Yadav wrote: > >> Hi John, refering to you patch: > >> > >> ARM: remove 'select GENERIC_TIME' > >> GENERIC_TIME is now enabled by default, so 'select GENERIC_TIME' is > >> redundant. Remove them. > >> > >> The following config's are not selectable: > >> config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config > >> PREEMPT_TRACER > >> > >> As far as I know, ARM now uses GENERIC_TIME via the arch_getoffset() > >> infrastructure, i.e ARCH_USES_GETTIMEOFFSET=y > > > > No. It is possible to select these options, but only if your platform > > uses the clockevent and clocksource infrastructure. If you're using that, > > then you must _not_ select ARCH_USES_GETTIMEOFFSET. > > > > ARCH_USES_GETTIMEOFFSET is for compatibility with old unconverted > > platforms, which are _not_ possible to use the above features. > > Just before the patch "time: Kill off CONFIG_GENERIC_TIME" Generic > time was selectable option, CONFIG_GENERIC_TIME was always set to 'y' on ARM (and everything else) before that commit. As the option is always set, there's no point it existing. So it was removed, and all the code paths associated with it became unconditional. Yes, there are places where GENERIC_TIME was subsituted with !ARCH_USES_GETTIMEOFFSET. (John will know the details.) > Therefore our target configuration with 2.6 kernel was > GENERIC_CLOCKEVENTS=y, ARCH_USES_GETTIMEOFFSET=y, It's absolutely absurd to have a platform converted to use clockevents and clocksources, and then select ARCH_USES_GETTIMEOFFSET. That's saying "I provide the new infrastructure, but I want the dodgy old compatibility which doesn't work properly with a set of other features as well". > I conclude that GENERIC_CLOCKEVENTS is supported, hence I must set > ARCH_USES_GETTIMEOFFSET=n, in order to use NO_HZ, HIGH_RES_TIMERS, > IRQSOFF_TRACER, PREEMPT_TRACER Correct. If you're using clockevents and clocksources, you should not select ARCH_USES_GETTIMEOFFSET. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-19 13:26 ` Russell King - ARM Linux @ 2012-03-21 4:58 ` John Stultz 2012-03-21 10:16 ` Ajeet Yadav 0 siblings, 1 reply; 21+ messages in thread From: John Stultz @ 2012-03-21 4:58 UTC (permalink / raw) To: Russell King - ARM Linux; +Cc: Ajeet Yadav, linux-kernel, Steven Rostedt On 03/19/2012 06:26 AM, Russell King - ARM Linux wrote: > On Mon, Mar 19, 2012 at 06:49:34PM +0530, Ajeet Yadav wrote: >> Therefore our target configuration with 2.6 kernel was >> GENERIC_CLOCKEVENTS=y, ARCH_USES_GETTIMEOFFSET=y, > It's absolutely absurd to have a platform converted to use clockevents > and clocksources, and then select ARCH_USES_GETTIMEOFFSET. That's saying > "I provide the new infrastructure, but I want the dodgy old compatibility > which doesn't work properly with a set of other features as well". > >> I conclude that GENERIC_CLOCKEVENTS is supported, hence I must set >> ARCH_USES_GETTIMEOFFSET=n, in order to use NO_HZ, HIGH_RES_TIMERS, >> IRQSOFF_TRACER, PREEMPT_TRACER > Correct. If you're using clockevents and clocksources, you should not > select ARCH_USES_GETTIMEOFFSET. > Hey Ajeet, As Russell pointed out, it looks like you're confused as to the use of ARCH_USES_GETTIMEOFFSET. That option is only for legacy systems that don't provide continuous clocksources that can be used for timekeeping. In the past, time was incremented by one tick every timer interrupt. Some systems could use the timer hardware (usually PIT style decrementer) to calculate inter-tick times. Its only for this style of hardware, that either wraps or resets each tick, that GETTIMEOFFSET is needed. If you have a continuous counter that doesn't wrap for a reasonable number of ticks, you want to use the clocksource abstraction to represent that hardware. That has the benefits of allowing high res timers and nohz, since we don't need to keep a constant tick-beat to keep time (and also avoids lost-ticks and a host of problems that tick based timekeeping can run into). So I suspect you probably want to verify your hardware supports a clocksource and disable ARCH_USES_GETTIMEOFFSET. Sorry for any confusion! thanks -john ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-21 4:58 ` John Stultz @ 2012-03-21 10:16 ` Ajeet Yadav 2012-03-22 9:16 ` Ajeet Yadav 0 siblings, 1 reply; 21+ messages in thread From: Ajeet Yadav @ 2012-03-21 10:16 UTC (permalink / raw) To: John Stultz; +Cc: Russell King - ARM Linux, linux-kernel, Steven Rostedt Hi John, Thank for clearing the confusion. On Wed, Mar 21, 2012 at 10:28 AM, John Stultz <john.stultz@linaro.org> wrote: > On 03/19/2012 06:26 AM, Russell King - ARM Linux wrote: >> >> On Mon, Mar 19, 2012 at 06:49:34PM +0530, Ajeet Yadav wrote: >>> >>> Therefore our target configuration with 2.6 kernel was >>> GENERIC_CLOCKEVENTS=y, ARCH_USES_GETTIMEOFFSET=y, >> >> It's absolutely absurd to have a platform converted to use clockevents >> and clocksources, and then select ARCH_USES_GETTIMEOFFSET. That's saying >> "I provide the new infrastructure, but I want the dodgy old compatibility >> which doesn't work properly with a set of other features as well". >> >>> I conclude that GENERIC_CLOCKEVENTS is supported, hence I must set >>> ARCH_USES_GETTIMEOFFSET=n, in order to use NO_HZ, HIGH_RES_TIMERS, >>> IRQSOFF_TRACER, PREEMPT_TRACER >> >> Correct. If you're using clockevents and clocksources, you should not >> select ARCH_USES_GETTIMEOFFSET. >> > > Hey Ajeet, > As Russell pointed out, it looks like you're confused as to the use of > ARCH_USES_GETTIMEOFFSET. That option is only for legacy systems that don't > provide continuous clocksources that can be used for timekeeping. > > In the past, time was incremented by one tick every timer interrupt. Some > systems could use the timer hardware (usually PIT style decrementer) to > calculate inter-tick times. Its only for this style of hardware, that either > wraps or resets each tick, that GETTIMEOFFSET is needed. If you have a > continuous counter that doesn't wrap for a reasonable number of ticks, you > want to use the clocksource abstraction to represent that hardware. That has > the benefits of allowing high res timers and nohz, since we don't need to > keep a constant tick-beat to keep time (and also avoids lost-ticks and a > host of problems that tick based timekeeping can run into). > > So I suspect you probably want to verify your hardware supports a > clocksource and disable ARCH_USES_GETTIMEOFFSET. > > Sorry for any confusion! > > thanks > -john > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-21 10:16 ` Ajeet Yadav @ 2012-03-22 9:16 ` Ajeet Yadav 2012-03-22 10:02 ` Russell King - ARM Linux 0 siblings, 1 reply; 21+ messages in thread From: Ajeet Yadav @ 2012-03-22 9:16 UTC (permalink / raw) To: John Stultz; +Cc: Russell King - ARM Linux, linux-kernel, Steven Rostedt Hi John, On our target ARCH_USES_GETTIMEOFFSET=y, can you please help me how can I useIRQSOFF_TRACER, PREEMPT_TRACER ? On Wed, Mar 21, 2012 at 3:46 PM, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote: > Hi John, > Thank for clearing the confusion. > > On Wed, Mar 21, 2012 at 10:28 AM, John Stultz <john.stultz@linaro.org> wrote: >> On 03/19/2012 06:26 AM, Russell King - ARM Linux wrote: >>> >>> On Mon, Mar 19, 2012 at 06:49:34PM +0530, Ajeet Yadav wrote: >>>> >>>> Therefore our target configuration with 2.6 kernel was >>>> GENERIC_CLOCKEVENTS=y, ARCH_USES_GETTIMEOFFSET=y, >>> >>> It's absolutely absurd to have a platform converted to use clockevents >>> and clocksources, and then select ARCH_USES_GETTIMEOFFSET. That's saying >>> "I provide the new infrastructure, but I want the dodgy old compatibility >>> which doesn't work properly with a set of other features as well". >>> >>>> I conclude that GENERIC_CLOCKEVENTS is supported, hence I must set >>>> ARCH_USES_GETTIMEOFFSET=n, in order to use NO_HZ, HIGH_RES_TIMERS, >>>> IRQSOFF_TRACER, PREEMPT_TRACER >>> >>> Correct. If you're using clockevents and clocksources, you should not >>> select ARCH_USES_GETTIMEOFFSET. >>> >> >> Hey Ajeet, >> As Russell pointed out, it looks like you're confused as to the use of >> ARCH_USES_GETTIMEOFFSET. That option is only for legacy systems that don't >> provide continuous clocksources that can be used for timekeeping. >> >> In the past, time was incremented by one tick every timer interrupt. Some >> systems could use the timer hardware (usually PIT style decrementer) to >> calculate inter-tick times. Its only for this style of hardware, that either >> wraps or resets each tick, that GETTIMEOFFSET is needed. If you have a >> continuous counter that doesn't wrap for a reasonable number of ticks, you >> want to use the clocksource abstraction to represent that hardware. That has >> the benefits of allowing high res timers and nohz, since we don't need to >> keep a constant tick-beat to keep time (and also avoids lost-ticks and a >> host of problems that tick based timekeeping can run into). >> >> So I suspect you probably want to verify your hardware supports a >> clocksource and disable ARCH_USES_GETTIMEOFFSET. >> >> Sorry for any confusion! >> >> thanks >> -john >> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-22 9:16 ` Ajeet Yadav @ 2012-03-22 10:02 ` Russell King - ARM Linux 2012-03-22 10:25 ` Ajeet Yadav 0 siblings, 1 reply; 21+ messages in thread From: Russell King - ARM Linux @ 2012-03-22 10:02 UTC (permalink / raw) To: Ajeet Yadav; +Cc: John Stultz, linux-kernel, Steven Rostedt On Thu, Mar 22, 2012 at 02:46:31PM +0530, Ajeet Yadav wrote: > Hi John, > On our target ARCH_USES_GETTIMEOFFSET=y, can you please help me how > can I useIRQSOFF_TRACER, PREEMPT_TRACER ? If you have ARCH_USES_GETTIMEOFFSET=y, the simple answer is: you can't. Your solution is to update your platform to use clock sources and clock events and disable the obsolete ARCH_USES_GETTIMEOFFSET option. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-22 10:02 ` Russell King - ARM Linux @ 2012-03-22 10:25 ` Ajeet Yadav 2012-03-23 3:23 ` John Stultz 2012-03-23 3:28 ` John Stultz 0 siblings, 2 replies; 21+ messages in thread From: Ajeet Yadav @ 2012-03-22 10:25 UTC (permalink / raw) To: Russell King - ARM Linux; +Cc: John Stultz, linux-kernel, Steven Rostedt I understand your point, Our target (2.6) always had ARCH_USES_GETTIMEOFFSET=y , but still we were able to use the TRACER in past until the patch "kill GENERIC_TIMER" published, anyone will ask me remove this patch and use TRACER, becaue it was working before. :) If I set ARCH_USES_GETTIMEOFFSET=n to use this feature, my target fail to boot. (reason I well understand from our past discussions) but if do below, everything work find target as well as tracer. --- linux-3.0.20/kernel/time/Kconfig 2012-02-06 23:01:45.000000000 +0530 +++ linux-3.0.20-dirty/kernel/time/Kconfig 2012-03-19 18:22:32.000000000 +0530 @@ -6,7 +6,7 @@ config TICK_ONESHOT config NO_HZ bool "Tickless System (Dynamic Ticks)" - depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS + depends on GENERIC_CLOCKEVENTS select TICK_ONESHOT help This option enables a tickless system: timer interrupts will @@ -15,7 +15,7 @@ config NO_HZ config HIGH_RES_TIMERS bool "High Resolution Timer Support" - depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS + depends on GENERIC_CLOCKEVENTS select TICK_ONESHOT help This option enables high resolution timer support. If your On Thu, Mar 22, 2012 at 3:32 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Thu, Mar 22, 2012 at 02:46:31PM +0530, Ajeet Yadav wrote: >> Hi John, >> On our target ARCH_USES_GETTIMEOFFSET=y, can you please help me how >> can I useIRQSOFF_TRACER, PREEMPT_TRACER ? > > If you have ARCH_USES_GETTIMEOFFSET=y, the simple answer is: you can't. > > Your solution is to update your platform to use clock sources and clock > events and disable the obsolete ARCH_USES_GETTIMEOFFSET option. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-22 10:25 ` Ajeet Yadav @ 2012-03-23 3:23 ` John Stultz 2012-03-23 4:59 ` Ajeet Yadav 2012-03-23 9:10 ` Ajeet Yadav 2012-03-23 3:28 ` John Stultz 1 sibling, 2 replies; 21+ messages in thread From: John Stultz @ 2012-03-23 3:23 UTC (permalink / raw) To: Ajeet Yadav; +Cc: Russell King - ARM Linux, linux-kernel, Steven Rostedt On 03/22/2012 03:25 AM, Ajeet Yadav wrote: > I understand your point, > Our target (2.6) always had ARCH_USES_GETTIMEOFFSET=y , but still we > were able to use the TRACER in past until the patch "kill > GENERIC_TIMER" published, anyone will ask me remove this patch and use > TRACER, becaue it was working before. :) Ajeet, Sorry, by TRACER, do you mean PREEMPT_TRACER or something else? And what specific 2.6.X kernel were you using? Steven, I'm seeing: config PREEMPT_TRACER bool "Preemption-off Latency Tracer" default n depends on !ARCH_USES_GETTIMEOFFSET Do you have any context as to why is !ARCH_USES_GETTIMEOFFSET flagged here? thanks -john ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 3:23 ` John Stultz @ 2012-03-23 4:59 ` Ajeet Yadav 2012-03-23 9:10 ` Ajeet Yadav 1 sibling, 0 replies; 21+ messages in thread From: Ajeet Yadav @ 2012-03-23 4:59 UTC (permalink / raw) To: John Stultz; +Cc: Russell King - ARM Linux, linux-kernel, Steven Rostedt On Fri, Mar 23, 2012 at 8:53 AM, John Stultz <john.stultz@linaro.org> wrote: > On 03/22/2012 03:25 AM, Ajeet Yadav wrote: >> >> I understand your point, >> Our target (2.6) always had ARCH_USES_GETTIMEOFFSET=y , but still we >> were able to use the TRACER in past until the patch "kill >> GENERIC_TIMER" published, anyone will ask me remove this patch and use >> TRACER, becaue it was working before. :) > > > Ajeet, > Sorry, by TRACER, do you mean PREEMPT_TRACER or something else? And what > specific 2.6.X kernel were you using? IRQSOFF_TRACER and PREEMPT_TRACER, our old kernel was 2.6.35. > > Steven, I'm seeing: > > config PREEMPT_TRACER > bool "Preemption-off Latency Tracer" > default n > depends on !ARCH_USES_GETTIMEOFFSET > > Do you have any context as to why is !ARCH_USES_GETTIMEOFFSET flagged here? > > thanks > -john > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 3:23 ` John Stultz 2012-03-23 4:59 ` Ajeet Yadav @ 2012-03-23 9:10 ` Ajeet Yadav 2012-03-23 14:28 ` Steven Rostedt 1 sibling, 1 reply; 21+ messages in thread From: Ajeet Yadav @ 2012-03-23 9:10 UTC (permalink / raw) To: John Stultz; +Cc: Russell King - ARM Linux, linux-kernel, Steven Rostedt On Fri, Mar 23, 2012 at 8:53 AM, John Stultz <john.stultz@linaro.org> wrote: > On 03/22/2012 03:25 AM, Ajeet Yadav wrote: >> >> I understand your point, >> Our target (2.6) always had ARCH_USES_GETTIMEOFFSET=y , but still we >> were able to use the TRACER in past until the patch "kill >> GENERIC_TIMER" published, anyone will ask me remove this patch and use >> TRACER, becaue it was working before. :) > > > Ajeet, > Sorry, by TRACER, do you mean PREEMPT_TRACER or something else? And what > specific 2.6.X kernel were you using? > > Steven, I'm seeing: > > config PREEMPT_TRACER > bool "Preemption-off Latency Tracer" > default n > depends on !ARCH_USES_GETTIMEOFFSET > > Do you have any context as to why is !ARCH_USES_GETTIMEOFFSET flagged here? Since boot problem is now fixed, I removed "depends on !ARCH_USES_GETTIMEOFFSET" from config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config PREEMPT_TRACER, to continue my work. Ref: time: Kill off CONFIG_GENERIC_TIME http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=592913ecb87a9e06f98ddb55b298f1a66bf94c6b diff -Naurp -X linux-3.0.20/Documentation/dontdiff linux-3.0.20/kernel/time/Kconfig linux-3.0.20-dirty/kernel/time/Kconfig --- linux-3.0.20/kernel/time/Kconfig 2012-02-06 23:01:45.000000000 +0530 +++ linux-3.0.20-dirty/kernel/time/Kconfig 2012-03-19 18:22:32.000000000 +0530 @@ -6,7 +6,7 @@ config TICK_ONESHOT config NO_HZ bool "Tickless System (Dynamic Ticks)" - depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS + depends on GENERIC_CLOCKEVENTS select TICK_ONESHOT help This option enables a tickless system: timer interrupts will @@ -15,7 +15,7 @@ config NO_HZ config HIGH_RES_TIMERS bool "High Resolution Timer Support" - depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS + depends on GENERIC_CLOCKEVENTS select TICK_ONESHOT help This option enables high resolution timer support. If your diff -Naurp -X linux-3.0.20/Documentation/dontdiff linux-3.0.20/kernel/trace/Kconfig linux-3.0.20-dirty/kernel/trace/Kconfig --- linux-3.0.20/kernel/trace/Kconfig 2012-02-06 23:01:45.000000000 +0530 +++ linux-3.0.20-dirty/kernel/trace/Kconfig 2012-03-19 18:21:41.000000000 +0530 @@ -173,7 +173,6 @@ config IRQSOFF_TRACER bool "Interrupts-off Latency Tracer" default n depends on TRACE_IRQFLAGS_SUPPORT - depends on !ARCH_USES_GETTIMEOFFSET select TRACE_IRQFLAGS select GENERIC_TRACER select TRACER_MAX_TRACE @@ -195,7 +194,6 @@ config IRQSOFF_TRACER config PREEMPT_TRACER bool "Preemption-off Latency Tracer" default n - depends on !ARCH_USES_GETTIMEOFFSET depends on PREEMPT select GENERIC_TRACER select TRACER_MAX_TRACE > > thanks > -john > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 9:10 ` Ajeet Yadav @ 2012-03-23 14:28 ` Steven Rostedt 2012-03-24 7:06 ` Ajeet Yadav 0 siblings, 1 reply; 21+ messages in thread From: Steven Rostedt @ 2012-03-23 14:28 UTC (permalink / raw) To: Ajeet Yadav; +Cc: John Stultz, Russell King - ARM Linux, linux-kernel On Fri, 2012-03-23 at 14:40 +0530, Ajeet Yadav wrote: > linux-3.0.20/kernel/trace/Kconfig > linux-3.0.20-dirty/kernel/trace/Kconfig > --- linux-3.0.20/kernel/trace/Kconfig 2012-02-06 23:01:45.000000000 +0530 > +++ linux-3.0.20-dirty/kernel/trace/Kconfig 2012-03-19 > 18:21:41.000000000 +0530 > @@ -173,7 +173,6 @@ config IRQSOFF_TRACER > bool "Interrupts-off Latency Tracer" > default n > depends on TRACE_IRQFLAGS_SUPPORT > - depends on !ARCH_USES_GETTIMEOFFSET > select TRACE_IRQFLAGS > select GENERIC_TRACER > select TRACER_MAX_TRACE > @@ -195,7 +194,6 @@ config IRQSOFF_TRACER > config PREEMPT_TRACER > bool "Preemption-off Latency Tracer" > default n > - depends on !ARCH_USES_GETTIMEOFFSET > depends on PREEMPT > select GENERIC_TRACER > select TRACER_MAX_TRACE A little history here. When I converted the irqsoff/preemptoff latency tracers from the original -rt patch (written by Ingo), these options originally had "depends on GENERIC_TIME". I just checked, and this goes at least back to 2.6.22.1-rt9 (long before ftrace). When I ported these to ftrace, I kept the dependencies. They probably are not needed and are only there for historical reasons. If this patch works fine for you, and that you are my only test case for this patch. I'd just say: Acked-by: Steven Rostedt <rostedt@goodmis.org> -- Steve ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 14:28 ` Steven Rostedt @ 2012-03-24 7:06 ` Ajeet Yadav 2012-03-26 16:47 ` Steven Rostedt 0 siblings, 1 reply; 21+ messages in thread From: Ajeet Yadav @ 2012-03-24 7:06 UTC (permalink / raw) To: Steven Rostedt; +Cc: John Stultz, Russell King - ARM Linux, linux-kernel On Fri, Mar 23, 2012 at 7:58 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > On Fri, 2012-03-23 at 14:40 +0530, Ajeet Yadav wrote: > >> linux-3.0.20/kernel/trace/Kconfig >> linux-3.0.20-dirty/kernel/trace/Kconfig >> --- linux-3.0.20/kernel/trace/Kconfig 2012-02-06 23:01:45.000000000 +0530 >> +++ linux-3.0.20-dirty/kernel/trace/Kconfig 2012-03-19 >> 18:21:41.000000000 +0530 >> @@ -173,7 +173,6 @@ config IRQSOFF_TRACER >> bool "Interrupts-off Latency Tracer" >> default n >> depends on TRACE_IRQFLAGS_SUPPORT >> - depends on !ARCH_USES_GETTIMEOFFSET >> select TRACE_IRQFLAGS >> select GENERIC_TRACER >> select TRACER_MAX_TRACE >> @@ -195,7 +194,6 @@ config IRQSOFF_TRACER >> config PREEMPT_TRACER >> bool "Preemption-off Latency Tracer" >> default n >> - depends on !ARCH_USES_GETTIMEOFFSET >> depends on PREEMPT >> select GENERIC_TRACER >> select TRACER_MAX_TRACE > > A little history here. > > When I converted the irqsoff/preemptoff latency tracers from the > original -rt patch (written by Ingo), these options originally had > "depends on GENERIC_TIME". I just checked, and this goes at least back > to 2.6.22.1-rt9 (long before ftrace). > > When I ported these to ftrace, I kept the dependencies. They probably > are not needed and are only there for historical reasons. > > If this patch works fine for you, and that you are my only test case for > this patch. I'd just say: > > Acked-by: Steven Rostedt <rostedt@goodmis.org> > > -- Steve Hi Steve thanks for review, is their anything more I can do or shall I consider this change as already submitted, thanks everyone for helping me. > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-24 7:06 ` Ajeet Yadav @ 2012-03-26 16:47 ` Steven Rostedt 0 siblings, 0 replies; 21+ messages in thread From: Steven Rostedt @ 2012-03-26 16:47 UTC (permalink / raw) To: Ajeet Yadav; +Cc: John Stultz, Russell King - ARM Linux, linux-kernel On Sat, 2012-03-24 at 12:36 +0530, Ajeet Yadav wrote: > Hi Steve thanks for review, is their anything more I can do or shall I > consider this change as already submitted, thanks everyone for helping > me. > > > > I can pull this in. Do they need to go into 3.4? Or can you wait till 3.5? -- Steve ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-22 10:25 ` Ajeet Yadav 2012-03-23 3:23 ` John Stultz @ 2012-03-23 3:28 ` John Stultz 2012-03-23 5:52 ` Ajeet Yadav 1 sibling, 1 reply; 21+ messages in thread From: John Stultz @ 2012-03-23 3:28 UTC (permalink / raw) To: Ajeet Yadav; +Cc: Russell King - ARM Linux, linux-kernel, Steven Rostedt On 03/22/2012 03:25 AM, Ajeet Yadav wrote: > If I set ARCH_USES_GETTIMEOFFSET=n to use this feature, my target > fail to boot. (reason I well understand from our past discussions) And this point I'm not sure I'm following. Why exactly does disabling ARCH_USES_GETTIMEOFFSET cause boot failures? Could you expand on the details here? You should just end up using the jiffies clocksource, which would give you low-res HZ granular timestamps, but shouldn't get in the way of booting. thanks -john ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 3:28 ` John Stultz @ 2012-03-23 5:52 ` Ajeet Yadav 2012-03-23 6:17 ` Rabin Vincent 2012-03-23 16:14 ` Greg KH 0 siblings, 2 replies; 21+ messages in thread From: Ajeet Yadav @ 2012-03-23 5:52 UTC (permalink / raw) To: Russell King - ARM Linux, John Stultz Cc: linux-kernel, Steven Rostedt, stable CCing to stable@vger.kernel.org On Fri, Mar 23, 2012 at 8:58 AM, John Stultz <john.stultz@linaro.org> wrote: > On 03/22/2012 03:25 AM, Ajeet Yadav wrote: >> >> If I set ARCH_USES_GETTIMEOFFSET=n to use this feature, my target >> fail to boot. (reason I well understand from our past discussions) > > And this point I'm not sure I'm following. Why exactly does disabling > ARCH_USES_GETTIMEOFFSET cause boot failures? Could you expand on the details > here? We did some dissection to narrow down the patch, our latest kernel is stable 3.0.X , however we backported patch " ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR" from 3.0.25 stable tree, this patch causes kernel hang during boot (IRQSOFF_TRACER=y and PREEMPT_TRACER=y) with 100% probability , if we remove this patch or disable the given CONFIG's then boot is success. > > You should just end up using the jiffies clocksource, which would give you > low-res HZ granular timestamps, but shouldn't get in the way of booting. > > thanks > -john > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 5:52 ` Ajeet Yadav @ 2012-03-23 6:17 ` Rabin Vincent 2012-03-23 8:58 ` Ajeet Yadav 2012-03-23 16:14 ` Greg KH 1 sibling, 1 reply; 21+ messages in thread From: Rabin Vincent @ 2012-03-23 6:17 UTC (permalink / raw) To: Ajeet Yadav Cc: Russell King - ARM Linux, John Stultz, linux-kernel, Steven Rostedt, stable On Fri, Mar 23, 2012 at 11:22, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote: > We did some dissection to narrow down the patch, our latest kernel is > stable 3.0.X , however we backported patch " ARM: 7321/1: cache-v7: > Disable preemption when reading CCSIDR" from 3.0.25 stable tree, this > patch causes kernel hang during boot (IRQSOFF_TRACER=y and > PREEMPT_TRACER=y) with 100% probability , if we remove this patch or > disable the given CONFIG's then boot is success. 8e43a905dd574f54c5715d9783 ("ARM: 7325/1: fix v7 boot with lockdep enabled") fixes 7321/1's boot problems. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 6:17 ` Rabin Vincent @ 2012-03-23 8:58 ` Ajeet Yadav 0 siblings, 0 replies; 21+ messages in thread From: Ajeet Yadav @ 2012-03-23 8:58 UTC (permalink / raw) To: Rabin Vincent Cc: Russell King - ARM Linux, John Stultz, linux-kernel, Steven Rostedt, stable On Fri, Mar 23, 2012 at 11:47 AM, Rabin Vincent <rabin@rab.in> wrote: > On Fri, Mar 23, 2012 at 11:22, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote: >> We did some dissection to narrow down the patch, our latest kernel is >> stable 3.0.X , however we backported patch " ARM: 7321/1: cache-v7: >> Disable preemption when reading CCSIDR" from 3.0.25 stable tree, this >> patch causes kernel hang during boot (IRQSOFF_TRACER=y and >> PREEMPT_TRACER=y) with 100% probability , if we remove this patch or >> disable the given CONFIG's then boot is success. > > 8e43a905dd574f54c5715d9783 ("ARM: 7325/1: fix v7 boot with lockdep > enabled") fixes 7321/1's boot problems. Hi Rabin, Thanks for fixing the boot problem, we have tested it, fixed. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 5:52 ` Ajeet Yadav 2012-03-23 6:17 ` Rabin Vincent @ 2012-03-23 16:14 ` Greg KH 2012-03-24 7:05 ` Ajeet Yadav 1 sibling, 1 reply; 21+ messages in thread From: Greg KH @ 2012-03-23 16:14 UTC (permalink / raw) To: Ajeet Yadav Cc: Russell King - ARM Linux, John Stultz, linux-kernel, Steven Rostedt, stable On Fri, Mar 23, 2012 at 11:22:46AM +0530, Ajeet Yadav wrote: > CCing to stable@vger.kernel.org Why? What am I supposed to do here? confused, greg k-h ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Not able to use HIGH_RES_TIMERS on ARM 2012-03-23 16:14 ` Greg KH @ 2012-03-24 7:05 ` Ajeet Yadav 0 siblings, 0 replies; 21+ messages in thread From: Ajeet Yadav @ 2012-03-24 7:05 UTC (permalink / raw) To: Greg KH Cc: Russell King - ARM Linux, John Stultz, linux-kernel, Steven Rostedt, stable I send earlier reply using my andriod gmail application, and it was rejected by stable/ linux-kernel (not in plain text), so sending again using PC. On Fri, Mar 23, 2012 at 9:44 PM, Greg KH <greg@kroah.com> wrote: > On Fri, Mar 23, 2012 at 11:22:46AM +0530, Ajeet Yadav wrote: >> CCing to stable@vger.kernel.org > > Why? What am I supposed to do here? > > confused, > > greg k-h I initially thought that problem is in 3.0.x stable, but I was wrong. Solution patch suggested by Rabin is already there in stable. Summary: " ARM: 7321/1: cache-v7: > Disable preemption when reading CCSIDR" introduce hang on boot, that is resolved by commit "ARM: 7325/1: fix v7 boot with lockdep enabled" fortunately both are in 3.0.x so no problem, but i do not know about other stable versions. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-03-26 16:47 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-19 13:01 Not able to use HIGH_RES_TIMERS on ARM Ajeet Yadav 2012-03-19 13:04 ` Russell King - ARM Linux 2012-03-19 13:19 ` Ajeet Yadav 2012-03-19 13:26 ` Russell King - ARM Linux 2012-03-21 4:58 ` John Stultz 2012-03-21 10:16 ` Ajeet Yadav 2012-03-22 9:16 ` Ajeet Yadav 2012-03-22 10:02 ` Russell King - ARM Linux 2012-03-22 10:25 ` Ajeet Yadav 2012-03-23 3:23 ` John Stultz 2012-03-23 4:59 ` Ajeet Yadav 2012-03-23 9:10 ` Ajeet Yadav 2012-03-23 14:28 ` Steven Rostedt 2012-03-24 7:06 ` Ajeet Yadav 2012-03-26 16:47 ` Steven Rostedt 2012-03-23 3:28 ` John Stultz 2012-03-23 5:52 ` Ajeet Yadav 2012-03-23 6:17 ` Rabin Vincent 2012-03-23 8:58 ` Ajeet Yadav 2012-03-23 16:14 ` Greg KH 2012-03-24 7:05 ` Ajeet Yadav
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.