Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1694735 > unrolled thread
| Started by | Martin Peres <martin.peres@linux.intel.com> |
|---|---|
| First post | 2017-07-24 15:50 +0200 |
| Last post | 2017-07-28 14:40 +0200 |
| Articles | 20 on this page of 45 — 6 participants |
Back to article view | Back to linux.kernel
Suspend-resume failure on Intel Eagle Lake Core2Duo Martin Peres <martin.peres@linux.intel.com> - 2017-07-24 15:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-24 17:30 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Martin Peres <martin.peres@linux.intel.com> - 2017-07-24 17:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-24 18:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Martin Peres <martin.peres@linux.intel.com> - 2017-07-24 18:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-25 09:10 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Martin Peres <martin.peres@linux.intel.com> - 2017-07-26 15:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-26 16:30 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-27 09:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-27 09:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-27 10:20 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-27 21:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-27 22:20 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-27 23:10 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-28 14:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-28 14:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-28 15:20 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-28 15:30 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-28 16:20 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-28 16:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-28 17:00 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-28 17:00 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-28 18:30 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-31 09:30 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-31 09:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-31 10:00 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-31 10:30 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-31 10:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-31 16:10 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-31 16:20 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-31 17:10 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Tomi Sarvela <tomi.p.sarvela@intel.com> - 2017-07-31 17:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-31 18:00 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-08-03 09:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Peter Zijlstra <peterz@infradead.org> - 2017-08-03 10:30 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Marc Zyngier <marc.zyngier@arm.com> - 2017-08-03 10:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-08-03 15:00 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Marc Zyngier <marc.zyngier@arm.com> - 2017-08-03 15:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-08-07 06:50 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Marc Zyngier <marc.zyngier@arm.com> - 2017-08-07 10:20 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-08-08 03:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Marc Zyngier <marc.zyngier@arm.com> - 2017-08-08 09:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-08-09 06:10 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Thomas Gleixner <tglx@linutronix.de> - 2017-07-31 10:40 +0200
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo Martin Peres <martin.peres@linux.intel.com> - 2017-07-28 14:40 +0200
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-28 17:00 +0200 |
| Message-ID | <u8eU9-560-5@gated-at.bofh.it> |
| In reply to | #1698857 |
On Fri, 28 Jul 2017, Tomi Sarvela wrote: > On 28/07/17 17:13, Thomas Gleixner wrote: > > On Fri, 28 Jul 2017, Tomi Sarvela wrote: > > > On 28/07/17 16:15, Thomas Gleixner wrote: > > > > Another question. Is the machine completely dead or not? > > > > > > Completely dead. Powerled is on, so host isn't shut down. > > > > So that means it does not even power the machine down. That's what I > > expected least. > > > > > Serial or network if don't give any signs of life. > > > > > Patch applies cleanly but still getting the same error: > > > > Sorry for the noise. I'm an idiot trying to do 10 things at once. This time > > it actually compiles and links. > > > > If the machine does still not powerdown with this applied, then please redo > > the 'platform' test and grab the trace for that one. > > This patch fixes the issue. Below is the dmesg from the testrun (sorry for the > spam, we're primarily testing i915 issues). Can you please retrieve the trace data from: /sys/kernel/debug/tracing/trace and provide that. The dmesg does not help much. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Tomi Sarvela <tomi.p.sarvela@intel.com> |
|---|---|
| Date | 2017-07-28 17:00 +0200 |
| Message-ID | <u8eUa-560-17@gated-at.bofh.it> |
| In reply to | #1698861 |
On 28/07/17 17:50, Thomas Gleixner wrote:
> On Fri, 28 Jul 2017, Tomi Sarvela wrote:
>> On 28/07/17 17:13, Thomas Gleixner wrote:
>>> On Fri, 28 Jul 2017, Tomi Sarvela wrote:
>>>> On 28/07/17 16:15, Thomas Gleixner wrote:
>>>>> Another question. Is the machine completely dead or not?
>>>>
>>>> Completely dead. Powerled is on, so host isn't shut down.
>>>
>>> So that means it does not even power the machine down. That's what I
>>> expected least.
>>>
>>>> Serial or network if don't give any signs of life.
>>>
>>>> Patch applies cleanly but still getting the same error:
>>>
>>> Sorry for the noise. I'm an idiot trying to do 10 things at once. This time
>>> it actually compiles and links.
>>>
>>> If the machine does still not powerdown with this applied, then please redo
>>> the 'platform' test and grab the trace for that one.
>>
>> This patch fixes the issue. Below is the dmesg from the testrun (sorry for the
>> spam, we're primarily testing i915 issues).
>
> Can you please retrieve the trace data from:
>
> /sys/kernel/debug/tracing/trace
>
> and provide that. The dmesg does not help much.
Right, here you go.
$ sudo cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
rtcwake-1332 [000] d..1 64.411098: suspend_device_irqs:
presuspend 0 state 00400600
rtcwake-1332 [000] d..1 64.411101: suspend_device_irqs:
postsuspend 0 state 00400600
rtcwake-1332 [000] d..1 64.411102: suspend_device_irqs:
presuspend 1 state 00030000
rtcwake-1332 [000] d..1 64.411103: suspend_device_irqs:
postsuspend 1 state 00030000
rtcwake-1332 [000] d..1 64.411104: suspend_device_irqs:
presuspend 2 state 00030000
rtcwake-1332 [000] d..1 64.411104: suspend_device_irqs:
postsuspend 2 state 00030000
rtcwake-1332 [000] d..1 64.411105: suspend_device_irqs:
presuspend 3 state 00030000
rtcwake-1332 [000] d..1 64.411106: suspend_device_irqs:
postsuspend 3 state 00030000
rtcwake-1332 [000] d..1 64.411107: suspend_device_irqs:
presuspend 4 state 00031000
rtcwake-1332 [000] d..1 64.411107: suspend_device_irqs:
postsuspend 4 state 00031000
rtcwake-1332 [000] d..1 64.411108: suspend_device_irqs:
presuspend 5 state 00030000
rtcwake-1332 [000] d..1 64.411108: suspend_device_irqs:
postsuspend 5 state 00030000
rtcwake-1332 [000] d..1 64.411109: suspend_device_irqs:
presuspend 6 state 00030000
rtcwake-1332 [000] d..1 64.411110: suspend_device_irqs:
postsuspend 6 state 00030000
rtcwake-1332 [000] d..1 64.411110: suspend_device_irqs:
presuspend 7 state 00030000
rtcwake-1332 [000] d..1 64.411111: suspend_device_irqs:
postsuspend 7 state 00030000
rtcwake-1332 [000] d..1 64.411112: suspend_device_irqs:
presuspend 8 state 00401200
rtcwake-1332 [000] d..1 64.411112: __irq_disable:
predisable 8 state 00401200
rtcwake-1332 [000] d..1 64.411113: __irq_disable:
postdisable 8 state 00411200
rtcwake-1332 [000] d..1 64.411114: suspend_device_irqs:
postsuspend 8 state 00411200
rtcwake-1332 [000] d..1 64.411115: suspend_device_irqs:
presuspend 9 state 00403300
rtcwake-1332 [000] d..1 64.411115: __irq_disable:
predisable 9 state 00403300
rtcwake-1332 [000] d..1 64.411116: __irq_disable:
postdisable 9 state 00413300
rtcwake-1332 [000] d..1 64.411116: suspend_device_irqs:
postsuspend 9 state 00413300
rtcwake-1332 [000] d..1 64.411117: suspend_device_irqs:
presuspend 10 state 00030000
rtcwake-1332 [000] d..1 64.411118: suspend_device_irqs:
postsuspend 10 state 00030000
rtcwake-1332 [000] d..1 64.411119: suspend_device_irqs:
presuspend 11 state 00030000
rtcwake-1332 [000] d..1 64.411119: suspend_device_irqs:
postsuspend 11 state 00030000
rtcwake-1332 [000] d..1 64.411120: suspend_device_irqs:
presuspend 12 state 00030000
rtcwake-1332 [000] d..1 64.411120: suspend_device_irqs:
postsuspend 12 state 00030000
rtcwake-1332 [000] d..1 64.411121: suspend_device_irqs:
presuspend 13 state 00030000
rtcwake-1332 [000] d..1 64.411122: suspend_device_irqs:
postsuspend 13 state 00030000
rtcwake-1332 [000] d..1 64.411122: suspend_device_irqs:
presuspend 14 state 00030000
rtcwake-1332 [000] d..1 64.411123: suspend_device_irqs:
postsuspend 14 state 00030000
rtcwake-1332 [000] d..1 64.411124: suspend_device_irqs:
presuspend 15 state 00030000
rtcwake-1332 [000] d..1 64.411124: suspend_device_irqs:
postsuspend 15 state 00030000
rtcwake-1332 [000] d..1 64.411125: suspend_device_irqs:
presuspend 16 state 00403200
rtcwake-1332 [000] d..1 64.411126: __irq_disable:
predisable 16 state 00403200
rtcwake-1332 [000] d..1 64.411126: __irq_disable:
postdisable 16 state 00413200
rtcwake-1332 [000] d..1 64.411127: suspend_device_irqs:
postsuspend 16 state 00413200
rtcwake-1332 [000] d..1 64.411128: suspend_device_irqs:
presuspend 17 state 00033000
rtcwake-1332 [000] d..1 64.411128: suspend_device_irqs:
postsuspend 17 state 00033000
rtcwake-1332 [000] d..1 64.411129: suspend_device_irqs:
presuspend 18 state 00032000
rtcwake-1332 [000] d..1 64.411130: suspend_device_irqs:
postsuspend 18 state 00032000
rtcwake-1332 [000] d..1 64.411130: suspend_device_irqs:
presuspend 19 state 00032000
rtcwake-1332 [000] d..1 64.411131: suspend_device_irqs:
postsuspend 19 state 00032000
rtcwake-1332 [000] d..1 64.411132: suspend_device_irqs:
presuspend 20 state 00403300
rtcwake-1332 [000] d..1 64.411132: __irq_disable:
predisable 20 state 00403300
rtcwake-1332 [000] d..1 64.411133: __irq_disable:
postdisable 20 state 00413300
rtcwake-1332 [000] d..1 64.411133: suspend_device_irqs:
postsuspend 20 state 00413300
rtcwake-1332 [000] d..1 64.411134: suspend_device_irqs:
presuspend 21 state 00403300
rtcwake-1332 [000] d..1 64.411134: __irq_disable:
predisable 21 state 00403300
rtcwake-1332 [000] d..1 64.411135: __irq_disable:
postdisable 21 state 00413300
rtcwake-1332 [000] d..1 64.411136: suspend_device_irqs:
postsuspend 21 state 00413300
rtcwake-1332 [000] d..1 64.411136: suspend_device_irqs:
presuspend 22 state 00403300
rtcwake-1332 [000] d..1 64.411137: __irq_disable:
predisable 22 state 00403300
rtcwake-1332 [000] d..1 64.411137: __irq_disable:
postdisable 22 state 00413300
rtcwake-1332 [000] d..1 64.411138: suspend_device_irqs:
postsuspend 22 state 00413300
rtcwake-1332 [000] d..1 64.411139: suspend_device_irqs:
presuspend 24 state 00409600
rtcwake-1332 [000] d..1 64.411139: suspend_device_irqs:
postsuspend 24 state 00409600
rtcwake-1332 [000] d..1 64.411140: suspend_device_irqs:
presuspend 25 state 00409600
rtcwake-1332 [000] d..1 64.411141: suspend_device_irqs:
postsuspend 25 state 00409600
rtcwake-1332 [000] d..1 64.411142: suspend_device_irqs:
presuspend 26 state 00038000
rtcwake-1332 [000] d..1 64.411142: suspend_device_irqs:
postsuspend 26 state 00038000
rtcwake-1332 [000] d..1 64.411143: suspend_device_irqs:
presuspend 27 state 00038000
rtcwake-1332 [000] d..1 64.411143: suspend_device_irqs:
postsuspend 27 state 00038000
rtcwake-1332 [000] d..1 64.411144: suspend_device_irqs:
presuspend 28 state 00401200
rtcwake-1332 [000] d..1 64.411145: __irq_disable:
predisable 28 state 00401200
rtcwake-1332 [000] d..1 64.411145: __irq_disable:
postdisable 28 state 00411200
rtcwake-1332 [000] d..1 64.411146: suspend_device_irqs:
postsuspend 28 state 00411200
rtcwake-1332 [001] d.H1 64.425561: mask_irq: premask 8
state 00411200
rtcwake-1332 [001] d.H1 64.425565: mask_irq: postmask 8
state 00431200
rtcwake-1332 [000] dN.1 64.436605: __irq_disable:
predisable 25 state 00409600
rtcwake-1332 [000] dN.1 64.436607: mask_irq: premask 25
state 00419600
rtcwake-1332 [000] dN.1 64.436608: mask_irq: postmask 25
state 00439600
rtcwake-1332 [000] dN.1 64.436609: __irq_disable:
postdisable 25 state 00439600
rtcwake-1332 [000] d..1 576460734.868390: __irq_disable:
predisable 24 state 00409600
rtcwake-1332 [000] d..1 576460734.868508: __irq_disable:
postdisable 24 state 00419600
rtcwake-1332 [000] d..1 576460734.868511: irq_enable:
preenable 24 state 00419600
rtcwake-1332 [000] d..1 576460734.868511: unmask_irq:
preunmask 24 state 00409600
rtcwake-1332 [000] d..1 576460734.868512: unmask_irq:
postunmask 24 state 00409600
rtcwake-1332 [000] d..1 576460734.868512: irq_enable:
postenable 24 state 00409600
rtcwake-1332 [000] dNh1 576460734.868533: mask_irq: premask 9
state 00413200
rtcwake-1332 [000] dNh1 576460734.868535: mask_irq: postmask
9 state 00433200
kworker/1:1-1039 [001] d..1 576460734.869322: irq_enable:
preenable 25 state 00039600
kworker/1:1-1039 [001] d..1 576460734.869324: unmask_irq:
preunmask 25 state 00029600
kworker/1:1-1039 [001] d..1 576460734.869325: unmask_irq:
postunmask 25 state 00009600
kworker/1:1-1039 [001] d..1 576460734.869326: irq_enable:
postenable 25 state 00009600
kworker/1:1-1039 [001] d..1 576460734.869329: __irq_disable:
predisable 25 state 00409600
kworker/1:1-1039 [001] d..1 576460734.869329: __irq_disable:
postdisable 25 state 00419600
kworker/1:1-1039 [001] d..1 576460734.869332: irq_enable:
preenable 25 state 00419600
kworker/1:1-1039 [001] d..1 576460734.869332: unmask_irq:
preunmask 25 state 00409600
kworker/1:1-1039 [001] d..1 576460734.869333: unmask_irq:
postunmask 25 state 00409600
kworker/1:1-1039 [001] d..1 576460734.869333: irq_enable:
postenable 25 state 00409600
rtcwake-1332 [000] d..1 576460734.882983: resume_irqs:
preresume 0 state 00400600
rtcwake-1332 [000] d..1 18446744056.289114: resume_irqs:
postresume 0 state 00400600
rtcwake-1332 [000] d..1 18446744056.289116: resume_irqs:
preresume 1 state 00030000
rtcwake-1332 [000] d..1 18446744056.289116: resume_irqs:
postresume 1 state 00030000
rtcwake-1332 [000] d..1 18446744056.289117: resume_irqs:
preresume 2 state 00030000
rtcwake-1332 [000] d..1 18446744056.289118: resume_irqs:
postresume 2 state 00030000
rtcwake-1332 [000] d..1 18446744056.289118: resume_irqs:
preresume 3 state 00030000
rtcwake-1332 [000] d..1 18446744056.289119: resume_irqs:
postresume 3 state 00030000
rtcwake-1332 [000] d..1 18446744056.289120: resume_irqs:
preresume 4 state 00031000
rtcwake-1332 [000] d..1 18446744056.289120: resume_irqs:
postresume 4 state 00031000
rtcwake-1332 [000] d..1 18446744056.289121: resume_irqs:
preresume 5 state 00030000
rtcwake-1332 [000] d..1 18446744056.289122: resume_irqs:
postresume 5 state 00030000
rtcwake-1332 [000] d..1 18446744056.289122: resume_irqs:
preresume 6 state 00030000
rtcwake-1332 [000] d..1 18446744056.289123: resume_irqs:
postresume 6 state 00030000
rtcwake-1332 [000] d..1 18446744056.289124: resume_irqs:
preresume 7 state 00030000
rtcwake-1332 [000] d..1 18446744056.289124: resume_irqs:
postresume 7 state 00030000
rtcwake-1332 [000] d..1 18446744056.289125: resume_irqs:
preresume 8 state 00431200
rtcwake-1332 [000] d..1 18446744056.289126: irq_enable:
preenable 8 state 00431200
rtcwake-1332 [000] d..1 18446744056.289126: unmask_irq:
preunmask 8 state 00421200
rtcwake-1332 [000] d..1 18446744056.289128: unmask_irq:
postunmask 8 state 00401200
rtcwake-1332 [000] d..1 18446744056.289128: irq_enable:
postenable 8 state 00401200
rtcwake-1332 [000] d..1 18446744056.289129: resume_irqs:
postresume 8 state 00401200
rtcwake-1332 [000] d..1 18446744056.289570: resume_irqs:
preresume 9 state 00433200
rtcwake-1332 [000] d..1 18446744056.289571: irq_enable:
preenable 9 state 00433200
rtcwake-1332 [000] d..1 18446744056.289571: unmask_irq:
preunmask 9 state 00423200
rtcwake-1332 [000] d..1 18446744056.289572: unmask_irq:
postunmask 9 state 00403200
rtcwake-1332 [000] d..1 18446744056.289572: irq_enable:
postenable 9 state 00403200
rtcwake-1332 [000] d..1 18446744056.289572: resume_irqs:
postresume 9 state 00403200
rtcwake-1332 [000] d..1 18446744056.289573: resume_irqs:
preresume 10 state 00030000
rtcwake-1332 [000] d..1 18446744056.289573: resume_irqs:
postresume 10 state 00030000
rtcwake-1332 [000] d..1 18446744056.289588: resume_irqs:
preresume 11 state 00030000
rtcwake-1332 [000] d..1 18446744056.289588: resume_irqs:
postresume 11 state 00030000
rtcwake-1332 [000] d..1 18446744056.289589: resume_irqs:
preresume 12 state 00030000
rtcwake-1332 [000] d..1 18446744056.289589: resume_irqs:
postresume 12 state 00030000
rtcwake-1332 [000] d..1 18446744056.289589: resume_irqs:
preresume 13 state 00030000
rtcwake-1332 [000] d..1 18446744056.289590: resume_irqs:
postresume 13 state 00030000
rtcwake-1332 [000] d..1 18446744056.289590: resume_irqs:
preresume 14 state 00030000
rtcwake-1332 [000] d..1 18446744056.289591: resume_irqs:
postresume 14 state 00030000
rtcwake-1332 [000] d..1 18446744056.289591: resume_irqs:
preresume 15 state 00030000
rtcwake-1332 [000] d..1 18446744056.289591: resume_irqs:
postresume 15 state 00030000
rtcwake-1332 [000] d..1 18446744056.289592: resume_irqs:
preresume 16 state 00413200
rtcwake-1332 [000] d..1 18446744056.289592: irq_enable:
preenable 16 state 00413200
rtcwake-1332 [000] d..1 18446744056.289593: unmask_irq:
preunmask 16 state 00403200
rtcwake-1332 [000] d..1 18446744056.289593: unmask_irq:
postunmask 16 state 00403200
rtcwake-1332 [000] d..1 18446744056.289594: irq_enable:
postenable 16 state 00403200
rtcwake-1332 [000] d..1 18446744056.289594: resume_irqs:
postresume 16 state 00403200
rtcwake-1332 [000] d..1 18446744056.289594: resume_irqs:
preresume 17 state 00033000
rtcwake-1332 [000] d..1 18446744056.289595: resume_irqs:
postresume 17 state 00033000
rtcwake-1332 [000] d..1 18446744056.289595: resume_irqs:
preresume 18 state 00032000
rtcwake-1332 [000] d..1 18446744056.289596: resume_irqs:
postresume 18 state 00032000
rtcwake-1332 [000] d..1 18446744056.289596: resume_irqs:
preresume 19 state 00032000
rtcwake-1332 [000] d..1 18446744056.289596: resume_irqs:
postresume 19 state 00032000
rtcwake-1332 [000] d..1 18446744056.289597: resume_irqs:
preresume 20 state 00413200
rtcwake-1332 [000] d..1 18446744056.289597: irq_enable:
preenable 20 state 00413200
rtcwake-1332 [000] d..1 18446744056.289598: unmask_irq:
preunmask 20 state 00403200
rtcwake-1332 [000] d..1 18446744056.289598: unmask_irq:
postunmask 20 state 00403200
rtcwake-1332 [000] d..1 18446744056.289598: irq_enable:
postenable 20 state 00403200
rtcwake-1332 [000] d..1 18446744056.289599: resume_irqs:
postresume 20 state 00403200
rtcwake-1332 [000] d..1 18446744056.289599: resume_irqs:
preresume 21 state 00413200
rtcwake-1332 [000] d..1 18446744056.289600: irq_enable:
preenable 21 state 00413200
rtcwake-1332 [000] d..1 18446744056.289600: unmask_irq:
preunmask 21 state 00403200
rtcwake-1332 [000] d..1 18446744056.289600: unmask_irq:
postunmask 21 state 00403200
rtcwake-1332 [000] d..1 18446744056.289601: irq_enable:
postenable 21 state 00403200
rtcwake-1332 [000] d..1 18446744056.289601: resume_irqs:
postresume 21 state 00403200
rtcwake-1332 [000] d..1 18446744056.289602: resume_irqs:
preresume 22 state 00413200
rtcwake-1332 [000] d..1 18446744056.289602: irq_enable:
preenable 22 state 00413200
rtcwake-1332 [000] d..1 18446744056.289602: unmask_irq:
preunmask 22 state 00403200
rtcwake-1332 [000] d..1 18446744056.289603: unmask_irq:
postunmask 22 state 00403200
rtcwake-1332 [000] d..1 18446744056.289603: irq_enable:
postenable 22 state 00403200
rtcwake-1332 [000] d..1 18446744056.289603: resume_irqs:
postresume 22 state 00403200
rtcwake-1332 [000] d..1 18446744056.289604: resume_irqs:
preresume 24 state 00409600
rtcwake-1332 [000] d..1 18446744056.289604: resume_irqs:
postresume 24 state 00409600
rtcwake-1332 [000] d..1 18446744056.289604: resume_irqs:
preresume 25 state 00409600
rtcwake-1332 [000] d..1 18446744056.289605: resume_irqs:
postresume 25 state 00409600
rtcwake-1332 [000] d..1 18446744056.289605: resume_irqs:
preresume 26 state 00038000
rtcwake-1332 [000] d..1 18446744056.289606: resume_irqs:
postresume 26 state 00038000
rtcwake-1332 [000] d..1 18446744056.289606: resume_irqs:
preresume 27 state 00038000
rtcwake-1332 [000] d..1 18446744056.289606: resume_irqs:
postresume 27 state 00038000
rtcwake-1332 [000] d..1 18446744056.289607: resume_irqs:
preresume 28 state 00411200
rtcwake-1332 [000] d..1 18446744056.289607: irq_enable:
preenable 28 state 00411200
rtcwake-1332 [000] d..1 18446744056.289608: unmask_irq:
preunmask 28 state 00401200
rtcwake-1332 [000] d..1 18446744056.289608: unmask_irq:
postunmask 28 state 00401200
rtcwake-1332 [000] d..1 18446744056.289608: irq_enable:
postenable 28 state 00401200
rtcwake-1332 [000] d..1 18446744056.289609: resume_irqs:
postresume 28 state 00401200
Tomi
--
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-28 18:30 +0200 |
| Message-ID | <u8gjg-65z-19@gated-at.bofh.it> |
| In reply to | #1698864 |
On Fri, 28 Jul 2017, Tomi Sarvela wrote: > On 28/07/17 17:50, Thomas Gleixner wrote: > > On Fri, 28 Jul 2017, Tomi Sarvela wrote: > > > On 28/07/17 17:13, Thomas Gleixner wrote: > > > > On Fri, 28 Jul 2017, Tomi Sarvela wrote: > > > > > On 28/07/17 16:15, Thomas Gleixner wrote: > > > > > > Another question. Is the machine completely dead or not? > > > > > > > > > > Completely dead. Powerled is on, so host isn't shut down. > > > > > > > > So that means it does not even power the machine down. That's what I > > > > expected least. > > > > > > > > > Serial or network if don't give any signs of life. > > > > > > > > > Patch applies cleanly but still getting the same error: > > > > > > > > Sorry for the noise. I'm an idiot trying to do 10 things at once. This > > > > time > > > > it actually compiles and links. > > > > > > > > If the machine does still not powerdown with this applied, then please > > > > redo > > > > the 'platform' test and grab the trace for that one. > > > > > > This patch fixes the issue. Below is the dmesg from the testrun (sorry for > > > the spam, we're primarily testing i915 issues). > > > > Can you please retrieve the trace data from: > > > > /sys/kernel/debug/tracing/trace > > > > and provide that. The dmesg does not help much. > > Right, here you go. Thanks for providing the data. Just to be sure, that data was from a real suspend, not the 'platform' test, right? If so, that does not make any sense at all. The patch merily changes the enable/resume path and adds the debug trace printks which have no influence on the disable logic. But you said that the machine does not power off in the bad case. That does not make any sense at all as the enable logic is not involved at all in the suspend path. Did you change anything else compared to the tests before ? Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Tomi Sarvela <tomi.p.sarvela@intel.com> |
|---|---|
| Date | 2017-07-31 09:30 +0200 |
| Message-ID | <u9djk-3lr-11@gated-at.bofh.it> |
| In reply to | #1698930 |
On 28/07/17 19:26, Thomas Gleixner wrote:
> On Fri, 28 Jul 2017, Tomi Sarvela wrote:
>> On 28/07/17 17:50, Thomas Gleixner wrote:
>>> On Fri, 28 Jul 2017, Tomi Sarvela wrote:
>>>> On 28/07/17 17:13, Thomas Gleixner wrote:
>>>>> On Fri, 28 Jul 2017, Tomi Sarvela wrote:
>>>>>> On 28/07/17 16:15, Thomas Gleixner wrote:
>>>>>>> Another question. Is the machine completely dead or not?
>>>>>>
>>>>>> Completely dead. Powerled is on, so host isn't shut down.
>>>>>
>>>>> So that means it does not even power the machine down. That's what I
>>>>> expected least.
>>>>>
>>>>>> Serial or network if don't give any signs of life.
>>>>>
>>>>>> Patch applies cleanly but still getting the same error:
>>>>>
>>>>> Sorry for the noise. I'm an idiot trying to do 10 things at once. This
>>>>> time
>>>>> it actually compiles and links.
>>>>>
>>>>> If the machine does still not powerdown with this applied, then please
>>>>> redo
>>>>> the 'platform' test and grab the trace for that one.
>>>>
>>>> This patch fixes the issue. Below is the dmesg from the testrun (sorry for
>>>> the spam, we're primarily testing i915 issues).
>>>
>>> Can you please retrieve the trace data from:
>>>
>>> /sys/kernel/debug/tracing/trace
>>>
>>> and provide that. The dmesg does not help much.
>>
>> Right, here you go.
>
> Thanks for providing the data. Just to be sure, that data was from a real
> suspend, not the 'platform' test, right?
>
> If so, that does not make any sense at all. The patch merily changes the
> enable/resume path and adds the debug trace printks which have no influence
> on the disable logic. But you said that the machine does not power off in
> the bad case. That does not make any sense at all as the enable logic is
> not involved at all in the suspend path.
>
> Did you change anything else compared to the tests before ?
I did check that the problem persisted in linus-HEAD before testing your
patch. The testing was done in order (reading from console logs I happen
to still have in one window):
- reboot to patched kernel
[ 0.000000] Linux version 4.13.0-rc2+ (testrunner@elk) (gcc version
6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)) #5 SMP PREEMPT Fri Jul 28
17:15:47 EEST 2017
[ 0.000000] Command line: BOOT_IMAGE=/boot/tsa.efi root=/dev/sda1
console=ttyS0,115200n8 console=tty0 intel_iommu=igfx_off drm.debug=0xe
nmi_watchdog=panic,auto panic=1 softdog.soft_panic=1
scsi_mod.use_blk_mq=0 rootwait ro 3
- "real" 15sec suspend test through IGT/piglit and rtcwake
$ ./scripts/run-tests.sh -vt igt@gem_exec_suspend@basic-s3 -x devices
- dmesg to go with suspend
[ 1189.597665] Suspended for 14.825 seconds
[ 1189.597665] Delta way too big! 18446743991837909721
ts=18446744056274518328 write stamp = 64436608607
If you just came from a suspend/resume,
please switch to the trace global clock:
echo global > /sys/kernel/debug/tracing/trace_clock
[ 1189.597665] ------------[ cut here ]------------
[ 1189.597665] WARNING: CPU: 0 PID: 1332 at
kernel/trace/ring_buffer.c:2647 rb_handle_timestamp.isra.32+0x71/0x80
[ 1189.597665] Modules linked in: snd_hda_codec_realtek i915
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core
coretemp snd_pcm e1000e lpc_ich mei_me ptp mei pps_core
[ 1189.597665] CPU: 0 PID: 1332 Comm: rtcwake Tainted: G U
4.13.0-rc2+ #5
[ 1189.597665] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT
PC/3647h, BIOS 786G7 v01.13 07/20/2011
[ 1189.597665] task: ffff88010dce9880 task.stack: ffffc900000c8000
[ 1189.597665] RIP: 0010:rb_handle_timestamp.isra.32+0x71/0x80
[ 1189.597665] RSP: 0018:ffffc900000cbab0 EFLAGS: 00010082
[ 1189.597665] RAX: 00000000000000e0 RBX: ffffc900000cbad0 RCX:
0000000000000004
[ 1189.597665] RDX: 0000000080000004 RSI: 0000000000000082 RDI:
00000000ffffffff
[ 1189.597665] RBP: ffffc900000cbac0 R08: 0000000000000000 R09:
00000000000000e0
[ 1189.597665] R10: ffffc900000cbbe0 R11: 00000000000ebc08 R12:
ffff880117008890
[ 1189.597665] R13: ffff8801170088b0 R14: 00000000000003e8 R15:
0000000000000005
[ 1189.597665] FS: 00007f93d957e700(0000) GS:ffff88011bc00000(0000)
knlGS:0000000000000000
[ 1189.597665] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1189.597665] CR2: 000000f00255b068 CR3: 00000000d9063000 CR4:
00000000000406f0
[ 1189.597665] Call Trace:
[ 1189.597665] ring_buffer_lock_reserve+0x1fa/0x350
[ 1189.597665] trace_vbprintk+0xdc/0x260
[ 1189.597665] ? __irq_disable+0x1b/0xc0
[ 1189.597665] __trace_bprintk+0x4a/0x60
[ 1189.597665] ? preempt_count_add+0x9e/0xb0
[ 1189.597665] __irq_disable+0x3f/0xc0
[ 1189.597665] irq_disable+0x17/0x20
[ 1189.597665] __disable_irq_nosync+0x59/0x70
[ 1189.597665] disable_hardirq+0x11/0x30
[ 1189.597665] hpet_msi_resume+0x85/0xd0
[ 1189.597665] clockevents_tick_resume+0x14/0x20
[ 1189.597665] tick_resume_local+0x32/0x60
[ 1189.597665] tick_resume+0x13/0x20
[ 1189.597665] timekeeping_resume+0x149/0x1a0
[ 1189.597665] syscore_resume+0x4b/0x190
[ 1189.597665] ? syscore_resume+0x4b/0x190
[ 1189.597665] suspend_devices_and_enter+0x6b9/0x810
[ 1189.597665] pm_suspend+0x367/0x540
[ 1189.597665] state_store+0x7e/0xf0
[ 1189.597665] kobj_attr_store+0xf/0x20
[ 1189.597665] sysfs_kf_write+0x37/0x40
[ 1189.597665] kernfs_fop_write+0x110/0x1a0
[ 1189.597665] __vfs_write+0x28/0x130
[ 1189.597665] ? __this_cpu_preempt_check+0x13/0x20
[ 1189.597665] ? __sb_start_write+0x55/0xe0
[ 1189.597665] vfs_write+0xb6/0x1a0
[ 1189.597665] SyS_write+0x46/0xb0
[ 1189.597665] entry_SYSCALL_64_fastpath+0x17/0x98
[ 1189.597665] RIP: 0033:0x7f93d90ac8f0
[ 1189.597665] RSP: 002b:00007ffd80a9ca88 EFLAGS: 00000246 ORIG_RAX:
0000000000000001
[ 1189.597665] RAX: ffffffffffffffda RBX: 000000f00255a050 RCX:
00007f93d90ac8f0
[ 1189.597665] RDX: 0000000000000004 RSI: 000000f00255a060 RDI:
0000000000000007
[ 1189.597665] RBP: 00007f93d9375b00 R08: 000000f002557d90 R09:
00007f93d957e700
[ 1189.597665] R10: 00007f93d9375b58 R11: 0000000000000246 R12:
00007f93d9375b58
[ 1189.597665] R13: 00007f93d9375b58 R14: 000000000000270f R15:
0000000000001010
[ 1189.597665] Code: f0 48 8b 73 08 85 c0 48 8b 13 48 c7 c0 88 9a a5 81
49 c7 c0 1a 3b a8 81 4c 0f 44 c0 48 8b 0f 48 c7 c7 10 9b a5 81 e8 c0 c8
fa ff <0f> ff eb a7 90 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 56
[ 1189.597665] ---[ end trace 7d99ac836f161565 ]---
- printing out the trace from /sys/kernel/debug/tracing/trace
Tomi
--
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-31 09:50 +0200 |
| Message-ID | <u9dCF-3sb-7@gated-at.bofh.it> |
| In reply to | #1699758 |
On Mon, 31 Jul 2017, Tomi Sarvela wrote:
> On 28/07/17 19:26, Thomas Gleixner wrote:
> > Did you change anything else compared to the tests before ?
>
> I did check that the problem persisted in linus-HEAD before testing your
> patch. The testing was done in order (reading from console logs I happen to
> still have in one window):
What I still do not understand is why this would affect the suspend path in
any way.
Can you remove the previous patch and apply the one below. If it resumes,
please provide the data from the trace buffer again.
Thanks,
tglx
8<--------------
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -459,3 +459,11 @@ static inline void irq_remove_debugfs_en
{
}
#endif /* CONFIG_GENERIC_IRQ_DEBUGFS */
+
+extern bool irq_suspend_resume;
+
+static inline void irq_trace_state(const char *what, struct irq_desc *desc)
+{
+ trace_printk("%s %d state %08x\n", what, irq_desc_get_irq(desc),
+ irqd_get(&desc->irq_data));
+}
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -14,6 +14,8 @@
#include "internals.h"
+bool irq_suspend_resume;
+
bool irq_pm_check_wakeup(struct irq_desc *desc)
{
if (irqd_is_wakeup_armed(&desc->irq_data)) {
@@ -120,6 +122,7 @@ void suspend_device_irqs(void)
struct irq_desc *desc;
int irq;
+ irq_suspend_resume = true;
for_each_irq_desc(irq, desc) {
unsigned long flags;
bool sync;
@@ -127,7 +130,9 @@ void suspend_device_irqs(void)
if (irq_settings_is_nested_thread(desc))
continue;
raw_spin_lock_irqsave(&desc->lock, flags);
+ irq_trace_state("presuspend", desc);
sync = suspend_device_irq(desc);
+ irq_trace_state("postsuspend", desc);
raw_spin_unlock_irqrestore(&desc->lock, flags);
if (sync)
@@ -150,8 +155,9 @@ static void resume_irq(struct irq_desc *
/* Pretend that it got disabled ! */
desc->depth++;
irq_state_set_disabled(desc);
- irq_state_set_masked(desc);
+
resume:
+ irq_state_set_masked(desc);
desc->istate &= ~IRQS_SUSPENDED;
__enable_irq(desc);
}
@@ -172,9 +178,14 @@ static void resume_irqs(bool want_early)
continue;
raw_spin_lock_irqsave(&desc->lock, flags);
+ irq_trace_state("preresume", desc);
resume_irq(desc);
+ irq_trace_state("postresume", desc);
raw_spin_unlock_irqrestore(&desc->lock, flags);
}
+
+ if (!want_early)
+ irq_suspend_resume = false;
}
/**
[toc] | [prev] | [next] | [standalone]
| From | Tomi Sarvela <tomi.p.sarvela@intel.com> |
|---|---|
| Date | 2017-07-31 10:00 +0200 |
| Message-ID | <u9dMl-3vs-7@gated-at.bofh.it> |
| In reply to | #1699781 |
On 31/07/17 10:45, Thomas Gleixner wrote: > On Mon, 31 Jul 2017, Tomi Sarvela wrote: >> On 28/07/17 19:26, Thomas Gleixner wrote: >>> Did you change anything else compared to the tests before ? >> >> I did check that the problem persisted in linus-HEAD before testing your >> patch. The testing was done in order (reading from console logs I happen to >> still have in one window): > > What I still do not understand is why this would affect the suspend path in > any way. > > Can you remove the previous patch and apply the one below. If it resumes, > please provide the data from the trace buffer again. No such luck. ELK hangs in the suspend-test with earlier patch removed, this added. Checked again that the power-led is on, no serial output. Tree not pulled: still testing against the previous head -rc2, not current 4.13.0-rc3 Best regards, Tomi -- Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-31 10:30 +0200 |
| Message-ID | <u9efn-3Uf-3@gated-at.bofh.it> |
| In reply to | #1699794 |
On Mon, 31 Jul 2017, Tomi Sarvela wrote: > On 31/07/17 10:45, Thomas Gleixner wrote: > > On Mon, 31 Jul 2017, Tomi Sarvela wrote: > > > On 28/07/17 19:26, Thomas Gleixner wrote: > > > > Did you change anything else compared to the tests before ? > > > > > > I did check that the problem persisted in linus-HEAD before testing your > > > patch. The testing was done in order (reading from console logs I happen > > > to > > > still have in one window): > > > > What I still do not understand is why this would affect the suspend path in > > any way. > > > > Can you remove the previous patch and apply the one below. If it resumes, > > please provide the data from the trace buffer again. > > No such luck. ELK hangs in the suspend-test with earlier patch removed, this > added. Checked again that the power-led is on, no serial output. > > Tree not pulled: still testing against the previous head -rc2, not current > 4.13.0-rc3 Shouldn't make a difference. Can you please try the following: Offline CPU1 before invoking suspend. # echo 0 >/sys/devices/system/cpus/cpu1/offline Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Tomi Sarvela <tomi.p.sarvela@intel.com> |
|---|---|
| Date | 2017-07-31 10:50 +0200 |
| Message-ID | <u9eyL-40A-39@gated-at.bofh.it> |
| In reply to | #1699807 |
On 31/07/17 11:29, Thomas Gleixner wrote: > On Mon, 31 Jul 2017, Tomi Sarvela wrote: >> On 31/07/17 10:45, Thomas Gleixner wrote: >>> On Mon, 31 Jul 2017, Tomi Sarvela wrote: >>>> On 28/07/17 19:26, Thomas Gleixner wrote: >>>>> Did you change anything else compared to the tests before ? >>>> >>>> I did check that the problem persisted in linus-HEAD before testing your >>>> patch. The testing was done in order (reading from console logs I happen >>>> to >>>> still have in one window): >>> >>> What I still do not understand is why this would affect the suspend path in >>> any way. >>> >>> Can you remove the previous patch and apply the one below. If it resumes, >>> please provide the data from the trace buffer again. >> >> No such luck. ELK hangs in the suspend-test with earlier patch removed, this >> added. Checked again that the power-led is on, no serial output. >> >> Tree not pulled: still testing against the previous head -rc2, not current >> 4.13.0-rc3 > > Shouldn't make a difference. Can you please try the following: > > Offline CPU1 before invoking suspend. > > # echo 0 >/sys/devices/system/cpus/cpu1/offline Tested with your latest patch (irq_trace_state): echo 0 >/sys/devices/system/cpu/cpu1/online ./scripts/run-tests.sh -vt igt@gem_exec_suspend@basic-s3 -x devices No change, no wakey at all. Tomi -- Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-31 16:10 +0200 |
| Message-ID | <u9jyq-7fE-15@gated-at.bofh.it> |
| In reply to | #1699826 |
On Mon, 31 Jul 2017, Tomi Sarvela wrote: > On 31/07/17 11:29, Thomas Gleixner wrote: > > On Mon, 31 Jul 2017, Tomi Sarvela wrote: > > > On 31/07/17 10:45, Thomas Gleixner wrote: > > > > On Mon, 31 Jul 2017, Tomi Sarvela wrote: > > > > > On 28/07/17 19:26, Thomas Gleixner wrote: > > > > > > Did you change anything else compared to the tests before ? > > > > > > > > > > I did check that the problem persisted in linus-HEAD before testing > > > > > your > > > > > patch. The testing was done in order (reading from console logs I > > > > > happen > > > > > to > > > > > still have in one window): > > > > > > > > What I still do not understand is why this would affect the suspend path > > > > in > > > > any way. > > > > > > > > Can you remove the previous patch and apply the one below. If it > > > > resumes, > > > > please provide the data from the trace buffer again. > > > > > > No such luck. ELK hangs in the suspend-test with earlier patch removed, > > > this > > > added. Checked again that the power-led is on, no serial output. > > > > > > Tree not pulled: still testing against the previous head -rc2, not current > > > 4.13.0-rc3 > > > > Shouldn't make a difference. Can you please try the following: > > > > Offline CPU1 before invoking suspend. > > > > # echo 0 >/sys/devices/system/cpus/cpu1/offline > > Tested with your latest patch (irq_trace_state): > > echo 0 >/sys/devices/system/cpu/cpu1/online > > ./scripts/run-tests.sh -vt igt@gem_exec_suspend@basic-s3 -x devices So this "igt@gem_exec_suspend@basic-s3" thingy is that executing anything extra aside of 'echo mem > /sys/power/state'? Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Tomi Sarvela <tomi.p.sarvela@intel.com> |
|---|---|
| Date | 2017-07-31 16:20 +0200 |
| Message-ID | <u9jI6-7iZ-23@gated-at.bofh.it> |
| In reply to | #1700075 |
On 31/07/17 17:04, Thomas Gleixner wrote: > On Mon, 31 Jul 2017, Tomi Sarvela wrote: >> On 31/07/17 11:29, Thomas Gleixner wrote: >>> On Mon, 31 Jul 2017, Tomi Sarvela wrote: >>>> On 31/07/17 10:45, Thomas Gleixner wrote: >>>>> On Mon, 31 Jul 2017, Tomi Sarvela wrote: >>>>>> On 28/07/17 19:26, Thomas Gleixner wrote: >>>>>>> Did you change anything else compared to the tests before ? >>>>>> >>>>>> I did check that the problem persisted in linus-HEAD before testing >>>>>> your >>>>>> patch. The testing was done in order (reading from console logs I >>>>>> happen >>>>>> to >>>>>> still have in one window): >>>>> >>>>> What I still do not understand is why this would affect the suspend path >>>>> in >>>>> any way. >>>>> >>>>> Can you remove the previous patch and apply the one below. If it >>>>> resumes, >>>>> please provide the data from the trace buffer again. >>>> >>>> No such luck. ELK hangs in the suspend-test with earlier patch removed, >>>> this >>>> added. Checked again that the power-led is on, no serial output. >>>> >>>> Tree not pulled: still testing against the previous head -rc2, not current >>>> 4.13.0-rc3 >>> >>> Shouldn't make a difference. Can you please try the following: >>> >>> Offline CPU1 before invoking suspend. >>> >>> # echo 0 >/sys/devices/system/cpus/cpu1/offline >> >> Tested with your latest patch (irq_trace_state): >> >> echo 0 >/sys/devices/system/cpu/cpu1/online >> >> ./scripts/run-tests.sh -vt igt@gem_exec_suspend@basic-s3 -x devices > > So this "igt@gem_exec_suspend@basic-s3" thingy is that executing anything > extra aside of 'echo mem > /sys/power/state'? It's setting wakeup with rtcwake to +15 seconds, then suspending. Complete information glanceable from sources: https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/gem_exec_suspend.c -> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/lib/igt_aux.c:void igt_system_suspend_autoresume Tomi -- Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-31 17:10 +0200 |
| Message-ID | <u9kuu-7PW-9@gated-at.bofh.it> |
| In reply to | #1699794 |
On Mon, 31 Jul 2017, Tomi Sarvela wrote: > On 31/07/17 10:45, Thomas Gleixner wrote: > > On Mon, 31 Jul 2017, Tomi Sarvela wrote: > > > On 28/07/17 19:26, Thomas Gleixner wrote: > > > > Did you change anything else compared to the tests before ? > > > > > > I did check that the problem persisted in linus-HEAD before testing your > > > patch. The testing was done in order (reading from console logs I happen > > > to > > > still have in one window): > > > > What I still do not understand is why this would affect the suspend path in > > any way. > > > > Can you remove the previous patch and apply the one below. If it resumes, > > please provide the data from the trace buffer again. > > No such luck. ELK hangs in the suspend-test with earlier patch removed, this > added. Checked again that the power-led is on, no serial output. Can you please remove the patch. And try the following: # echo N > /sys/module/printk/parameters/console_suspend # echo mem > /sys/power/state and log the output of the serial console. That way we might get a clue where it gets stuck. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Tomi Sarvela <tomi.p.sarvela@intel.com> |
|---|---|
| Date | 2017-07-31 17:50 +0200 |
| Message-ID | <u9l7b-82B-13@gated-at.bofh.it> |
| In reply to | #1700100 |
On 31/07/17 18:06, Thomas Gleixner wrote: > On Mon, 31 Jul 2017, Tomi Sarvela wrote: >> On 31/07/17 10:45, Thomas Gleixner wrote: >>> On Mon, 31 Jul 2017, Tomi Sarvela wrote: >>>> On 28/07/17 19:26, Thomas Gleixner wrote: >>>>> Did you change anything else compared to the tests before ? >>>> >>>> I did check that the problem persisted in linus-HEAD before testing your >>>> patch. The testing was done in order (reading from console logs I happen >>>> to >>>> still have in one window): >>> >>> What I still do not understand is why this would affect the suspend path in >>> any way. >>> >>> Can you remove the previous patch and apply the one below. If it resumes, >>> please provide the data from the trace buffer again. >> >> No such luck. ELK hangs in the suspend-test with earlier patch removed, this >> added. Checked again that the power-led is on, no serial output. > > Can you please remove the patch. And try the following: > > # echo N > /sys/module/printk/parameters/console_suspend > > # echo mem > /sys/power/state > > and log the output of the serial console. That way we might get a clue > where it gets stuck. I'm afraid it hangs right away. No response from SSH, no output to serial. Tomi -- Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-31 18:00 +0200 |
| Message-ID | <u9lgS-85O-21@gated-at.bofh.it> |
| In reply to | #1700138 |
On Mon, 31 Jul 2017, Tomi Sarvela wrote: > On 31/07/17 18:06, Thomas Gleixner wrote: > > Can you please remove the patch. And try the following: > > > > # echo N > /sys/module/printk/parameters/console_suspend > > > > # echo mem > /sys/power/state > > > > and log the output of the serial console. That way we might get a clue > > where it gets stuck. > > I'm afraid it hangs right away. No response from SSH, no output to serial. What means hangs right away? Is there no output at all on the serial console? Or does it just stop at some point? Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Masahiro Yamada <yamada.masahiro@socionext.com> |
|---|---|
| Date | 2017-08-03 09:40 +0200 |
| Message-ID | <uaiTE-5ar-13@gated-at.bofh.it> |
| In reply to | #1700148 |
Hi.
2017-08-01 0:55 GMT+09:00 Thomas Gleixner <tglx@linutronix.de>:
> On Mon, 31 Jul 2017, Tomi Sarvela wrote:
>> On 31/07/17 18:06, Thomas Gleixner wrote:
>> > Can you please remove the patch. And try the following:
>> >
>> > # echo N > /sys/module/printk/parameters/console_suspend
>> >
>> > # echo mem > /sys/power/state
>> >
>> > and log the output of the serial console. That way we might get a clue
>> > where it gets stuck.
>>
>> I'm afraid it hangs right away. No response from SSH, no output to serial.
>
> What means hangs right away? Is there no output at all on the serial
> console? Or does it just stop at some point?
>
> Thanks,
>
> tglx
>
Sorry for jumping in.
Finally, I found this thread.
My environment is completely different (ARM64 board),
I am also suffering from a hibernation problem
since this commit.
I get no response on the serial console
after "Restarting tasks ... done." log message.
By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
irq function calls", I can get hibernation working again.
SW info:
defconfig: arch/arm64/configs/defconfig
DT : arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
PSCI : ARM Trusted Firmware
SoC info:
CPU : Cortex-A72 * 2 + Cortex-A53 * 2
irqchip : GICv3 (drivers/irq/irq-gic-v3.c)
--
Best Regards
Masahiro Yamada
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2017-08-03 10:30 +0200 |
| Message-ID | <uajG3-5ML-41@gated-at.bofh.it> |
| In reply to | #1702729 |
On Thu, Aug 03, 2017 at 04:32:09PM +0900, Masahiro Yamada wrote:
> My environment is completely different (ARM64 board),
> I am also suffering from a hibernation problem
> since this commit.
>
>
> I get no response on the serial console
> after "Restarting tasks ... done." log message.
>
>
> By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
> irq function calls", I can get hibernation working again.
https://lkml.kernel.org/r/alpine.DEB.2.20.1707312158590.2287@nanos
Is the patch that cured the x86 issue, but maybe that gives a clue as
what to look for in your platform.
[toc] | [prev] | [next] | [standalone]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2017-08-03 10:50 +0200 |
| Message-ID | <uajZo-5W2-5@gated-at.bofh.it> |
| In reply to | #1702729 |
Hi Masahiro,
On 03/08/17 08:32, Masahiro Yamada wrote:
> Hi.
>
> 2017-08-01 0:55 GMT+09:00 Thomas Gleixner <tglx@linutronix.de>:
>> On Mon, 31 Jul 2017, Tomi Sarvela wrote:
>>> On 31/07/17 18:06, Thomas Gleixner wrote:
>>>> Can you please remove the patch. And try the following:
>>>>
>>>> # echo N > /sys/module/printk/parameters/console_suspend
>>>>
>>>> # echo mem > /sys/power/state
>>>>
>>>> and log the output of the serial console. That way we might get a clue
>>>> where it gets stuck.
>>>
>>> I'm afraid it hangs right away. No response from SSH, no output to serial.
>>
>> What means hangs right away? Is there no output at all on the serial
>> console? Or does it just stop at some point?
>>
>> Thanks,
>>
>> tglx
>>
>
> Sorry for jumping in.
> Finally, I found this thread.
>
>
> My environment is completely different (ARM64 board),
> I am also suffering from a hibernation problem
> since this commit.
>
>
> I get no response on the serial console
> after "Restarting tasks ... done." log message.
>
>
> By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
> irq function calls", I can get hibernation working again.
>
>
> SW info:
> defconfig: arch/arm64/configs/defconfig
> DT : arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
> PSCI : ARM Trusted Firmware
>
>
> SoC info:
> CPU : Cortex-A72 * 2 + Cortex-A53 * 2
> irqchip : GICv3 (drivers/irq/irq-gic-v3.c)
Let me take an educated guess: It feels like your firmware doesn't
save/restore the GIC context across suspend/resume. Is that something
you could check, assuming you have access to the firmware source code?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[toc] | [prev] | [next] | [standalone]
| From | Masahiro Yamada <yamada.masahiro@socionext.com> |
|---|---|
| Date | 2017-08-03 15:00 +0200 |
| Message-ID | <uanTk-8vF-21@gated-at.bofh.it> |
| In reply to | #1702793 |
Hi Marc,
2017-08-03 17:41 GMT+09:00 Marc Zyngier <marc.zyngier@arm.com>:
> Hi Masahiro,
>
> On 03/08/17 08:32, Masahiro Yamada wrote:
>> Hi.
>>
>> 2017-08-01 0:55 GMT+09:00 Thomas Gleixner <tglx@linutronix.de>:
>>> On Mon, 31 Jul 2017, Tomi Sarvela wrote:
>>>> On 31/07/17 18:06, Thomas Gleixner wrote:
>>>>> Can you please remove the patch. And try the following:
>>>>>
>>>>> # echo N > /sys/module/printk/parameters/console_suspend
>>>>>
>>>>> # echo mem > /sys/power/state
>>>>>
>>>>> and log the output of the serial console. That way we might get a clue
>>>>> where it gets stuck.
>>>>
>>>> I'm afraid it hangs right away. No response from SSH, no output to serial.
>>>
>>> What means hangs right away? Is there no output at all on the serial
>>> console? Or does it just stop at some point?
>>>
>>> Thanks,
>>>
>>> tglx
>>>
>>
>> Sorry for jumping in.
>> Finally, I found this thread.
>>
>>
>> My environment is completely different (ARM64 board),
>> I am also suffering from a hibernation problem
>> since this commit.
>>
>>
>> I get no response on the serial console
>> after "Restarting tasks ... done." log message.
>>
>>
>> By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
>> irq function calls", I can get hibernation working again.
>>
>>
>> SW info:
>> defconfig: arch/arm64/configs/defconfig
>> DT : arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
>> PSCI : ARM Trusted Firmware
>>
>>
>> SoC info:
>> CPU : Cortex-A72 * 2 + Cortex-A53 * 2
>> irqchip : GICv3 (drivers/irq/irq-gic-v3.c)
>
> Let me take an educated guess: It feels like your firmware doesn't
> save/restore the GIC context across suspend/resume. Is that something
> you could check, assuming you have access to the firmware source code?
Thanks for your comments.
I do not know much about the manner of preserving GICv3 context.
I can see this patch (rejected?) :
https://patchwork.kernel.org/patch/9343061/
Is it something that should be completely cared by firmware
instead of kernel?
ARM Trusted Firmware (https://github.com/ARM-software/arm-trusted-firmware)
is open source software, and I pushed my platform code to the upstream.
So, yes, I (and everybody) can have access to the firmware source code.
I am not sure how ATF saves the context during hibernation, though.
--
Best Regards
Masahiro Yamada
[toc] | [prev] | [next] | [standalone]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2017-08-03 15:40 +0200 |
| Message-ID | <uaow2-Bh-17@gated-at.bofh.it> |
| In reply to | #1703085 |
On 03/08/17 13:52, Masahiro Yamada wrote:
> Hi Marc,
>
> 2017-08-03 17:41 GMT+09:00 Marc Zyngier <marc.zyngier@arm.com>:
>> Hi Masahiro,
>>
>> On 03/08/17 08:32, Masahiro Yamada wrote:
>>> Hi.
>>>
>>> 2017-08-01 0:55 GMT+09:00 Thomas Gleixner <tglx@linutronix.de>:
>>>> On Mon, 31 Jul 2017, Tomi Sarvela wrote:
>>>>> On 31/07/17 18:06, Thomas Gleixner wrote:
>>>>>> Can you please remove the patch. And try the following:
>>>>>>
>>>>>> # echo N > /sys/module/printk/parameters/console_suspend
>>>>>>
>>>>>> # echo mem > /sys/power/state
>>>>>>
>>>>>> and log the output of the serial console. That way we might get a clue
>>>>>> where it gets stuck.
>>>>>
>>>>> I'm afraid it hangs right away. No response from SSH, no output to serial.
>>>>
>>>> What means hangs right away? Is there no output at all on the serial
>>>> console? Or does it just stop at some point?
>>>>
>>>> Thanks,
>>>>
>>>> tglx
>>>>
>>>
>>> Sorry for jumping in.
>>> Finally, I found this thread.
>>>
>>>
>>> My environment is completely different (ARM64 board),
>>> I am also suffering from a hibernation problem
>>> since this commit.
>>>
>>>
>>> I get no response on the serial console
>>> after "Restarting tasks ... done." log message.
>>>
>>>
>>> By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
>>> irq function calls", I can get hibernation working again.
>>>
>>>
>>> SW info:
>>> defconfig: arch/arm64/configs/defconfig
>>> DT : arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
>>> PSCI : ARM Trusted Firmware
>>>
>>>
>>> SoC info:
>>> CPU : Cortex-A72 * 2 + Cortex-A53 * 2
>>> irqchip : GICv3 (drivers/irq/irq-gic-v3.c)
>>
>> Let me take an educated guess: It feels like your firmware doesn't
>> save/restore the GIC context across suspend/resume. Is that something
>> you could check, assuming you have access to the firmware source code?
>
> Thanks for your comments.
>
>
> I do not know much about the manner of preserving GICv3 context.
>
> I can see this patch (rejected?) :
> https://patchwork.kernel.org/patch/9343061/
>
>
> Is it something that should be completely cared by firmware
> instead of kernel?
That was definitely the intention, but it looks like something that ATF
has only started supporting very recently:
https://github.com/ARM-software/arm-trusted-firmware/pull/1047
> ARM Trusted Firmware (https://github.com/ARM-software/arm-trusted-firmware)
> is open source software, and I pushed my platform code to the upstream.
>
> So, yes, I (and everybody) can have access to the firmware source code.
>
>
> I am not sure how ATF saves the context during hibernation, though.
See the above link. Is there any chance of you trying this into your
firmware?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[toc] | [prev] | [next] | [standalone]
| From | Masahiro Yamada <yamada.masahiro@socionext.com> |
|---|---|
| Date | 2017-08-07 06:50 +0200 |
| Message-ID | <ubI9j-3zf-5@gated-at.bofh.it> |
| In reply to | #1703119 |
Hi Marc,
2017-08-03 22:30 GMT+09:00 Marc Zyngier <marc.zyngier@arm.com>:
> On 03/08/17 13:52, Masahiro Yamada wrote:
>> Hi Marc,
>>
>> 2017-08-03 17:41 GMT+09:00 Marc Zyngier <marc.zyngier@arm.com>:
>>> Hi Masahiro,
>>>
>>> On 03/08/17 08:32, Masahiro Yamada wrote:
>>>> Hi.
>>>>
>>>> 2017-08-01 0:55 GMT+09:00 Thomas Gleixner <tglx@linutronix.de>:
>>>>> On Mon, 31 Jul 2017, Tomi Sarvela wrote:
>>>>>> On 31/07/17 18:06, Thomas Gleixner wrote:
>>>>>>> Can you please remove the patch. And try the following:
>>>>>>>
>>>>>>> # echo N > /sys/module/printk/parameters/console_suspend
>>>>>>>
>>>>>>> # echo mem > /sys/power/state
>>>>>>>
>>>>>>> and log the output of the serial console. That way we might get a clue
>>>>>>> where it gets stuck.
>>>>>>
>>>>>> I'm afraid it hangs right away. No response from SSH, no output to serial.
>>>>>
>>>>> What means hangs right away? Is there no output at all on the serial
>>>>> console? Or does it just stop at some point?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> tglx
>>>>>
>>>>
>>>> Sorry for jumping in.
>>>> Finally, I found this thread.
>>>>
>>>>
>>>> My environment is completely different (ARM64 board),
>>>> I am also suffering from a hibernation problem
>>>> since this commit.
>>>>
>>>>
>>>> I get no response on the serial console
>>>> after "Restarting tasks ... done." log message.
>>>>
>>>>
>>>> By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
>>>> irq function calls", I can get hibernation working again.
>>>>
>>>>
>>>> SW info:
>>>> defconfig: arch/arm64/configs/defconfig
>>>> DT : arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
>>>> PSCI : ARM Trusted Firmware
>>>>
>>>>
>>>> SoC info:
>>>> CPU : Cortex-A72 * 2 + Cortex-A53 * 2
>>>> irqchip : GICv3 (drivers/irq/irq-gic-v3.c)
>>>
>>> Let me take an educated guess: It feels like your firmware doesn't
>>> save/restore the GIC context across suspend/resume. Is that something
>>> you could check, assuming you have access to the firmware source code?
>>
>> Thanks for your comments.
>>
>>
>> I do not know much about the manner of preserving GICv3 context.
>>
>> I can see this patch (rejected?) :
>> https://patchwork.kernel.org/patch/9343061/
>>
>>
>> Is it something that should be completely cared by firmware
>> instead of kernel?
>
> That was definitely the intention, but it looks like something that ATF
> has only started supporting very recently:
>
> https://github.com/ARM-software/arm-trusted-firmware/pull/1047
>
>> ARM Trusted Firmware (https://github.com/ARM-software/arm-trusted-firmware)
>> is open source software, and I pushed my platform code to the upstream.
>>
>> So, yes, I (and everybody) can have access to the firmware source code.
>>
>>
>> I am not sure how ATF saves the context during hibernation, though.
>
> See the above link. Is there any chance of you trying this into your
> firmware?
>
> Thanks,
Thanks for the pointer.
Yes. I will try that once GIC-v3 context save/restore is supported in ATF.
I think that will basically work for suspend-to-ram
because all contexts including both non-secure and secure worlds will
be retained in the main memory.
However, I still do not understand how the context is preserved during
the hibernation (suspend-to-disk).
If my understanding is correct, hibernation on Linux works like follows:
[1] Freeze all tasks
[2] CPU_OFF for non-boot CPUs
[3] Create a hibernation image
[4] CPU_ON for non-boot CPUs
[5] Write the hibernation image to the disk (=swap area)
[6] SYSTEM_OFF
IIUC, [5] only writes the context Linux takes care of (only non-secure).
If so, where and how does the firmware write the GIC-v3 context
to the disk?
--
Best Regards
Masahiro Yamada
[toc] | [prev] | [next] | [standalone]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2017-08-07 10:20 +0200 |
| Message-ID | <ubLqA-5J4-39@gated-at.bofh.it> |
| In reply to | #1705090 |
On 07/08/17 05:45, Masahiro Yamada wrote:
> Hi Marc,
>
>
> 2017-08-03 22:30 GMT+09:00 Marc Zyngier <marc.zyngier@arm.com>:
>> On 03/08/17 13:52, Masahiro Yamada wrote:
>>> Hi Marc,
>>>
>>> 2017-08-03 17:41 GMT+09:00 Marc Zyngier <marc.zyngier@arm.com>:
>>>> Hi Masahiro,
>>>>
>>>> On 03/08/17 08:32, Masahiro Yamada wrote:
>>>>> Hi.
>>>>>
>>>>> 2017-08-01 0:55 GMT+09:00 Thomas Gleixner <tglx@linutronix.de>:
>>>>>> On Mon, 31 Jul 2017, Tomi Sarvela wrote:
>>>>>>> On 31/07/17 18:06, Thomas Gleixner wrote:
>>>>>>>> Can you please remove the patch. And try the following:
>>>>>>>>
>>>>>>>> # echo N > /sys/module/printk/parameters/console_suspend
>>>>>>>>
>>>>>>>> # echo mem > /sys/power/state
>>>>>>>>
>>>>>>>> and log the output of the serial console. That way we might get a clue
>>>>>>>> where it gets stuck.
>>>>>>>
>>>>>>> I'm afraid it hangs right away. No response from SSH, no output to serial.
>>>>>>
>>>>>> What means hangs right away? Is there no output at all on the serial
>>>>>> console? Or does it just stop at some point?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> tglx
>>>>>>
>>>>>
>>>>> Sorry for jumping in.
>>>>> Finally, I found this thread.
>>>>>
>>>>>
>>>>> My environment is completely different (ARM64 board),
>>>>> I am also suffering from a hibernation problem
>>>>> since this commit.
>>>>>
>>>>>
>>>>> I get no response on the serial console
>>>>> after "Restarting tasks ... done." log message.
>>>>>
>>>>>
>>>>> By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
>>>>> irq function calls", I can get hibernation working again.
>>>>>
>>>>>
>>>>> SW info:
>>>>> defconfig: arch/arm64/configs/defconfig
>>>>> DT : arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
>>>>> PSCI : ARM Trusted Firmware
>>>>>
>>>>>
>>>>> SoC info:
>>>>> CPU : Cortex-A72 * 2 + Cortex-A53 * 2
>>>>> irqchip : GICv3 (drivers/irq/irq-gic-v3.c)
>>>>
>>>> Let me take an educated guess: It feels like your firmware doesn't
>>>> save/restore the GIC context across suspend/resume. Is that something
>>>> you could check, assuming you have access to the firmware source code?
>>>
>>> Thanks for your comments.
>>>
>>>
>>> I do not know much about the manner of preserving GICv3 context.
>>>
>>> I can see this patch (rejected?) :
>>> https://patchwork.kernel.org/patch/9343061/
>>>
>>>
>>> Is it something that should be completely cared by firmware
>>> instead of kernel?
>>
>> That was definitely the intention, but it looks like something that ATF
>> has only started supporting very recently:
>>
>> https://github.com/ARM-software/arm-trusted-firmware/pull/1047
>>
>>> ARM Trusted Firmware (https://github.com/ARM-software/arm-trusted-firmware)
>>> is open source software, and I pushed my platform code to the upstream.
>>>
>>> So, yes, I (and everybody) can have access to the firmware source code.
>>>
>>>
>>> I am not sure how ATF saves the context during hibernation, though.
>>
>> See the above link. Is there any chance of you trying this into your
>> firmware?
>>
>> Thanks,
>
> Thanks for the pointer.
>
>
> Yes. I will try that once GIC-v3 context save/restore is supported in ATF.
>
> I think that will basically work for suspend-to-ram
> because all contexts including both non-secure and secure worlds will
> be retained in the main memory.
>
> However, I still do not understand how the context is preserved during
> the hibernation (suspend-to-disk).
>
>
> If my understanding is correct, hibernation on Linux works like follows:
>
> [1] Freeze all tasks
> [2] CPU_OFF for non-boot CPUs
> [3] Create a hibernation image
> [4] CPU_ON for non-boot CPUs
> [5] Write the hibernation image to the disk (=swap area)
> [6] SYSTEM_OFF
>
>
> IIUC, [5] only writes the context Linux takes care of (only non-secure).
>
> If so, where and how does the firmware write the GIC-v3 context
> to the disk?
Gah, I completely missed the fact that you were talking about suspend to
disk, sorry about that.
It is likely that some driver doesn't restore its state properly. Is
there any chance that you could pinpoint which device creates the issue?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web