Hi Thomas,
On Fri, Jul 03, 2015 at 04:53:49PM +0200, Thomas Gleixner wrote:
> On Fri, 3 Jul 2015, Wolfram Sang wrote:
> > > So this is a single core machine and uses the em_sti timer w/o the
> > > broadcast nonsense. In Simons case it looks like em_sti is used as
> > > broadcast device.
> >
> > W
Hi Geert,
On Sat, Jul 4, 2015 at 2:02 AM, Geert Uytterhoeven wrote:
> Hi Wolfram,
>
> On Fri, Jul 3, 2015 at 4:37 PM, Wolfram Sang wrote:
>>> So this is a single core machine and uses the em_sti timer w/o the
>>> broadcast nonsense. In Simons case it looks like em_sti is used as
>>> broadcast de
Hi Wolfram,
Thanks for investigating this.
On Sat, Jul 4, 2015 at 12:09 AM, Wolfram Sang wrote:
>
>> Ok. So it's unrelated to deep idle states. Any chance of poking with
>> JTAG at the frozen box? If not, are there GPIOs which you could use to
>> monitor certain state?
>
> No JTAGger here at the
Hi Wolfram,
On Fri, Jul 3, 2015 at 4:37 PM, Wolfram Sang wrote:
>> So this is a single core machine and uses the em_sti timer w/o the
>> broadcast nonsense. In Simons case it looks like em_sti is used as
>> broadcast device.
>
> We use the same board. Just my kernel has SMP=n.
Unlike our other m
> Can you try the patch below, whether it makes a difference?
It doesn't. Board locks again.
> - clockevents_config_and_register(ced, 1, 2, 0x);
> + clockevents_config_and_register(ced, 1, 100, 0x);
signature.asc
Description: Digital signature
On Fri, 3 Jul 2015, Wolfram Sang wrote:
> > Ok. One more check please. Does nohz=off on the command line fix/hide
> > the issue as well?
>
> Yes, it does. It boots to the prompt then.
So something is fishy with this timer. In your UP setting we don't
have any interaction with the broadcast stuff.
> Ok. One more check please. Does nohz=off on the command line fix/hide
> the issue as well?
Yes, it does. It boots to the prompt then.
signature.asc
Description: Digital signature
On Fri, 3 Jul 2015, Wolfram Sang wrote:
> > Ok. So it's unrelated to deep idle states. Any chance of poking with
> > JTAG at the frozen box? If not, are there GPIOs which you could use to
> > monitor certain state?
>
> No JTAGger here at the moment. And no manual/schematics for this board
> :(
Ok
> Ok. So it's unrelated to deep idle states. Any chance of poking with
> JTAG at the frozen box? If not, are there GPIOs which you could use to
> monitor certain state?
No JTAGger here at the moment. And no manual/schematics for this board
:(
I'll ask around...
signature.asc
Description: Digi
On 03/07/15 15:54, Thomas Gleixner wrote:
On Fri, 3 Jul 2015, Sudeep Holla wrote:
On 03/07/15 15:37, Wolfram Sang wrote:
So this is a single core machine and uses the em_sti timer w/o the
broadcast nonsense. In Simons case it looks like em_sti is used as
broadcast device.
We use the same
On Fri, 3 Jul 2015, Sudeep Holla wrote:
> On 03/07/15 15:37, Wolfram Sang wrote:
> >
> > > So this is a single core machine and uses the em_sti timer w/o the
> > > broadcast nonsense. In Simons case it looks like em_sti is used as
> > > broadcast device.
> >
> > We use the same board. Just my ker
On Fri, 3 Jul 2015, Wolfram Sang wrote:
> > So this is a single core machine and uses the em_sti timer w/o the
> > broadcast nonsense. In Simons case it looks like em_sti is used as
> > broadcast device.
>
> We use the same board. Just my kernel has SMP=n.
>
> > Though the issues you see in the h
On 03/07/15 15:37, Wolfram Sang wrote:
So this is a single core machine and uses the em_sti timer w/o the
broadcast nonsense. In Simons case it looks like em_sti is used as
broadcast device.
We use the same board. Just my kernel has SMP=n.
If it's UP build, then GENERIC_CLOCKEVENTS_BROAD
> So this is a single core machine and uses the em_sti timer w/o the
> broadcast nonsense. In Simons case it looks like em_sti is used as
> broadcast device.
We use the same board. Just my kernel has SMP=n.
> Though the issues you see in the highres=n case might be the same as
> the ones Simon i
On Fri, 3 Jul 2015, Wolfram Sang wrote:
>
> > So with high res timers it boots. Can you please provide the output of
> > /proc/timer_list for that case?
> Tick Device: mode: 1
> Per CPU device: 0
> Clock Event Device: e018.timer
> max_delta_ns: 131071523464982
> min_delta_ns: 61035
> So with high res timers it boots. Can you please provide the output of
> /proc/timer_list for that case?
Sure:
Timer List Version: v0.7
HRTIMER_MAX_CLOCK_BASES: 4
now at 40752899169 nsecs
cpu: 0
clock 0:
.base: c03aa990
.index: 0
.resolution: 1 nsecs
.get_time: ktime_get
On Fri, 3 Jul 2015, Wolfram Sang wrote:
> Hi Simon,
>
> > I have observed what appears to be a regression while testing next-20150702
> > which seems to be caused by 2951d5c031a3 ("tick: broadcast: Prevent
> > livelock from event handler").
>
> Does reverting help? I see a similar case with your
On Fri, Jul 03, 2015 at 12:13:58PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 03, 2015 at 01:07:31PM +0200, Wolfram Sang wrote:
> > > Please share your .config file for this case. Thanks.
> >
> > Here it goes...
>
> Please try:
>
> sed -i s/IRQSOFF_TRACER/TRACE_IRQFLAGS/ arch/arm/kern
On Fri, Jul 03, 2015 at 01:07:31PM +0200, Wolfram Sang wrote:
> > Please share your .config file for this case. Thanks.
>
> Here it goes...
Please try:
sed -i s/IRQSOFF_TRACER/TRACE_IRQFLAGS/ arch/arm/kernel/entry-armv.S
Thanks.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down
> Please share your .config file for this case. Thanks.
Here it goes...
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.1.0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPO
On Fri, Jul 03, 2015 at 12:54:41PM +0200, Wolfram Sang wrote:
> Enabling all lockdep features doesn't show anything for the non-working
> case. However, I get warning for the working case:
Please share your .config file for this case. Thanks.
--
FTTC broadband for 0.8mile line: currently at 10.
Hi Simon,
> I have observed what appears to be a regression while testing next-20150702
> which seems to be caused by 2951d5c031a3 ("tick: broadcast: Prevent
> livelock from event handler").
Does reverting help? I see a similar case with your branch
renesas-devel-20150629-v4.1 which does not incl
On Fri, 3 Jul 2015, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Fri, Jul 3, 2015 at 4:40 AM, Simon Horman wrote:
> > I have observed what appears to be a regression while testing next-20150702
> > which seems to be caused by 2951d5c031a3 ("tick: broadcast: Prevent
> > livelock from event handler
Hi Simon,
On Fri, Jul 3, 2015 at 4:40 AM, Simon Horman wrote:
> I have observed what appears to be a regression while testing next-20150702
> which seems to be caused by 2951d5c031a3 ("tick: broadcast: Prevent
> livelock from event handler").
>
> The problem manifests on the emev2/kzm9d board as
Hi Thomas,
I have observed what appears to be a regression while testing next-20150702
which seems to be caused by 2951d5c031a3 ("tick: broadcast: Prevent
livelock from event handler").
The problem manifests on the emev2/kzm9d board as per the boot log below.
The problem manifests when booting u
25 matches
Mail list logo
