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.
> >
> >
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.
We use the
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
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
Hi Wolfram,
Thanks for investigating this.
On Sat, Jul 4, 2015 at 12:09 AM, Wolfram Sang w...@the-dreams.de 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
Hi Geert,
On Sat, Jul 4, 2015 at 2:02 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote:
Hi Wolfram,
On Fri, Jul 3, 2015 at 4:37 PM, Wolfram Sang w...@the-dreams.de 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
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
> 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
> 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. 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:
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
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
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
> 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
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:
> 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:
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/
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
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
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
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
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
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 branch
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 is
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
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 kernel has SMP=n.
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 highres=n
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. One
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
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:
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
mult:
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
Hi Wolfram,
On Fri, Jul 3, 2015 at 4:37 PM, Wolfram Sang w...@the-dreams.de 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
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
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. It's
Hi Simon,
On Fri, Jul 3, 2015 at 4:40 AM, Simon Horman ho...@verge.net.au 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
On Fri, 3 Jul 2015, Geert Uytterhoeven wrote:
Hi Simon,
On Fri, Jul 3, 2015 at 4:40 AM, Simon Horman ho...@verge.net.au 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
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 include
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
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
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
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/
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
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
50 matches
Mail list logo
