On Wed, Jul 31, 2013 at 10:49:06PM +0200, Daniel Lezcano wrote: > On 07/31/2013 12:34 AM, Sören Brinkmann wrote: > > On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote: > >> On 07/30/2013 02:03 AM, Sören Brinkmann wrote: > >>> Hi Daniel, > >>> > >>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote: > >>> (snip) > >>>> > >>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local > >>>> timer will be stopped when entering to the idle state. In this case, the > >>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a > >>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the > >>>> idle state, switching the local timer back in use. > >>> > >>> I've been thinking about this, trying to understand how this makes my > >>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag > >>> would make the timer core switch to a broadcast device even though it > >>> wouldn't be necessary. But shouldn't it still work? It sounds like we do > >>> something useless, but nothing wrong in a sense that it should result in > >>> breakage. I guess I'm missing something obvious. This timer system will > >>> always remain a mystery to me. > >>> > >>> Actually this more or less leads to the question: What is this > >>> 'broadcast timer'. I guess that is some clockevent device which is > >>> common to all cores? (that would be the cadence_ttc for Zynq). Is the > >>> hang pointing to some issue with that driver? > >> > >> If you look at the /proc/timer_list, which timer is used for broadcasting ? > > > > So, the correct run results (full output attached). > > > > The vanilla kernel uses the twd timers as local timers and the TTC as > > broadcast device: > > Tick Device: mode: 1 > > > > Broadcast device > > Clock Event Device: ttc_clockevent > > > > When I remove the offending CPUIDLE flag and add the DT fragment to > > enable the global timer, the twd timers are still used as local timers > > and the broadcast device is the global timer: > > Tick Device: mode: 1 > > > > Broadcast device > > > > Clock Event Device: arm_global_timer > > > > Again, since boot hangs in the actually broken case, I don't see way to > > obtain this information for that case. > > Can't you use the maxcpus=1 option to ensure the system to boot up ?
Right, that works. I forgot about that option after you mentioned, that it is most likely not that useful. Anyway, this are those sysfs files with an unmodified cpuidle driver and the gt enabled and having maxcpus=1 set. /proc/timer_list: Tick Device: mode: 1 Broadcast device Clock Event Device: arm_global_timer max_delta_ns: 12884902005 min_delta_ns: 1000 mult: 715827876 shift: 31 mode: 3 next_event: 108080000000 nsecs set_next_event: gt_clockevent_set_next_event set_mode: gt_clockevent_set_mode event_handler: tick_handle_oneshot_broadcast retries: 0 tick_broadcast_mask: 00000001 tick_broadcast_oneshot_mask: 00000000 Tick Device: mode: 1 Per CPU device: 0 Clock Event Device: local_timer max_delta_ns: 12884902005 min_delta_ns: 1000 mult: 715827876 shift: 31 mode: 3 next_event: 106900000000 nsecs set_next_event: twd_set_next_event set_mode: twd_set_mode event_handler: hrtimer_interrupt retries: 0 # cat /proc/interrupts CPU0 27: 252 GIC 27 gt 29: 626 GIC 29 twd 43: 0 GIC 43 ttc_clockevent 82: 410 GIC 82 xuartps IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts Err: 0 Sören -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/