On 20/09/13 15:55, Christopher Covington wrote: > On 09/20/2013 04:17 AM, Marc Zyngier wrote: >> On 20/09/13 05:57, Yuvaraj Kumar wrote: >>> Resending it as it bounced from kernel mailing group >>> >>> On Wed, Sep 18, 2013 at 3:53 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: >>>> [adding lakml] >>>> >>>> On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote: >>>>> Without the "clock-frequency" property in arch timer node, could able >>>>> to see the below crash dump. >>>> >>>> Why does this cause the below crash specifically? What is CNTFRQ reading >>>> as? >>> Return value of arch_timer_get_cntfrq() is 0 >>>> >>>> Your firmware or bootloader should set CNTFRQ -- setting the >>>> clock-frequency is a work-around for buggy firmware/bootloaders that >>>> should be avoided as far as possible. >>> Why kernel should depend on bootloader/firmware to set CNTFRQ? Any >>> specific reasons? >> >> Because the kernel can't set it if running non-secure. Only secure mode >> can do this (see the ARM ARM for details). > > What software outside the kernel actually reads the CNTFRQ and why? Your favourite virtual machine does, for the same reason the host kernel does. And as you can't guess the frequency from userspace, you cannot specify it in the guest's DT, getting whatever random number sits in CNTFRQ. As you would expect, things don't go smoothly when that happens. M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
