On Tue, 7 Jul 2015, Sudeep Holla wrote:
> Yes I tested this patch for all the combinations I had mentioned in my
> earlier email. Everything works as expected. Thanks a lot for the
> patience. Please feel free to add:
>
> Tested-by: Sudeep Holla
>
> > {
> > Index:
Hi Thomas,
On 07/07/15 08:31, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
This triggered the below crash on boot, looks like it's accessing
hrtimer->function which is null in periodic mode IIUC
Regards,
Sudeep
Gah. I have no
On Mon, 6 Jul 2015, Thomas Gleixner wrote:
> On Mon, 6 Jul 2015, Sudeep Holla wrote:
> > This triggered the below crash on boot, looks like it's accessing
> > hrtimer->function which is null in periodic mode IIUC
> >
> > Regards,
> > Sudeep
>
> Gah. I have no idea how that gets queued. /me goes
On Mon, 6 Jul 2015, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
This triggered the below crash on boot, looks like it's accessing
hrtimer-function which is null in periodic mode IIUC
Regards,
Sudeep
Gah. I have no idea how that gets queued. /me goes off to tweak
On Tue, 7 Jul 2015, Sudeep Holla wrote:
Yes I tested this patch for all the combinations I had mentioned in my
earlier email. Everything works as expected. Thanks a lot for the
patience. Please feel free to add:
Tested-by: Sudeep Holla sudeep.ho...@arm.com
{
Index:
Hi Thomas,
On 07/07/15 08:31, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
This triggered the below crash on boot, looks like it's accessing
hrtimer-function which is null in periodic mode IIUC
Regards,
Sudeep
Gah. I have no
On Mon, 6 Jul 2015, Sudeep Holla wrote:
> This triggered the below crash on boot, looks like it's accessing
> hrtimer->function which is null in periodic mode IIUC
>
> Regards,
> Sudeep
Gah. I have no idea how that gets queued. /me goes off to tweak x86 to
emulate that crap.
> --->8
>
> Bad
On 06/07/15 17:53, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 06/07/15 17:06, Thomas Gleixner wrote:
2. After boot I am seeing the below warning:
[ cut here ]
WARNING: CPU: 1 PID: 0 at kernel/time/hrtimer.c:1247
On Mon, 6 Jul 2015, Sudeep Holla wrote:
> On 06/07/15 17:06, Thomas Gleixner wrote:
> 2. After boot I am seeing the below warning:
>
> [ cut here ]
> WARNING: CPU: 1 PID: 0 at kernel/time/hrtimer.c:1247
> __hrtimer_run_queues+0x148/0x150()
> Modules linked in:
> CPU: 1
On 06/07/15 17:06, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 06/07/15 16:35, Thomas Gleixner wrote:
Well, we should figure out what happens while we are at it before
everything gets paged out again.
True. I just wanted to mention that this patch works for all the
On Mon, 6 Jul 2015, Sudeep Holla wrote:
> On 06/07/15 16:35, Thomas Gleixner wrote:
> > Well, we should figure out what happens while we are at it before
> > everything gets paged out again.
> >
>
> True. I just wanted to mention that this patch works for all the
> practical purposes.
>
> > In
On 06/07/15 16:35, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 05/07/15 21:53, Thomas Gleixner wrote:
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go
On Mon, 6 Jul 2015, Sudeep Holla wrote:
> On 05/07/15 21:53, Thomas Gleixner wrote:
> > If no broadcast device is installed and the cpu local timers stop in
> > deeper idle states, then there is currently nothing telling the idle
> > code that it should not go into deep idle states, so the timers
Hi Thomas,
On 05/07/15 21:53, Thomas Gleixner wrote:
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go into deep idle states, so the timers stop
and nothing wakes up the cpus.
On 06/07/15 17:06, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 06/07/15 16:35, Thomas Gleixner wrote:
Well, we should figure out what happens while we are at it before
everything gets paged out again.
True. I just wanted to mention that this patch works for all the
On Mon, 6 Jul 2015, Sudeep Holla wrote:
This triggered the below crash on boot, looks like it's accessing
hrtimer-function which is null in periodic mode IIUC
Regards,
Sudeep
Gah. I have no idea how that gets queued. /me goes off to tweak x86 to
emulate that crap.
---8
Bad mode in
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 06/07/15 17:06, Thomas Gleixner wrote:
2. After boot I am seeing the below warning:
[ cut here ]
WARNING: CPU: 1 PID: 0 at kernel/time/hrtimer.c:1247
__hrtimer_run_queues+0x148/0x150()
Modules linked in:
CPU: 1 PID: 0
On 06/07/15 17:53, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 06/07/15 17:06, Thomas Gleixner wrote:
2. After boot I am seeing the below warning:
[ cut here ]
WARNING: CPU: 1 PID: 0 at kernel/time/hrtimer.c:1247
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 05/07/15 21:53, Thomas Gleixner wrote:
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go into deep idle states, so the timers stop
On 06/07/15 16:35, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 05/07/15 21:53, Thomas Gleixner wrote:
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go
Hi Thomas,
On 05/07/15 21:53, Thomas Gleixner wrote:
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go into deep idle states, so the timers stop
and nothing wakes up the cpus.
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 06/07/15 16:35, Thomas Gleixner wrote:
Well, we should figure out what happens while we are at it before
everything gets paged out again.
True. I just wanted to mention that this patch works for all the
practical purposes.
In the case of
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go into deep idle states, so the timers stop
and nothing wakes up the cpus.
Make the broadcast_enter/exit() functions independent of
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go into deep idle states, so the timers stop
and nothing wakes up the cpus.
Make the broadcast_enter/exit() functions independent of
24 matches
Mail list logo
