On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
> Andrew Lunn ?????????? 12.04.2015 17:58:
> >>Okay, got it.
> >>I'll file a bug about this issue to the the bugzilla. However
> >>something
> >>tells me it might not be cpuidle, but D-link. This one's sounds nasty
> >>and it has been around since 3.16.x. How could it go unnoticed?
> >>Unfortunately I have no other armada-370 hardware to test it.
> >
> >Hi Andrew
> >
> >A few of us here do have hardware to test with. Please give a detailed
> >description of how you reproduce the issue, and your kernel
> >configuration, if different from mvebu_v7_defconfig, or
> >multi_v7_defconfig.
> >
> > Thanks
> > Andrew
>
>
> arch/arm/configs/mvebu_v7_defconfig has CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
> so it should be sufficient to reproduce the issue. I first encountered
> this issue using that very config and observed it on 2 DNS-327L boxes I
> own.
>
> All I have to do to trigger the bug - enable cpuidle driver and let
> the box
> sit for some 4-12 hours, till it hard-freezes. If wdt is enabled -
> wdt reboot
> will happen.
That simple! Well i've got a 370RD which has been sat mostly idle for
weeks, using the mvebu_v7_defconfig, with a few addition things turned
on for testing the Ethernet switch on the board. I've not had that
lockup.
One thing you can try to narrow it down is the disable the second idle
mode. Take a look at armada370_idle_driver. Keep the
ARM_CPUIDLE_WFI_STATE but disable the "Deep Idle" state.
Andrew
--
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
