Re: PCI / PM: Crashes in PME scan during system suspend

[Rafael J. Wysocki]

On Friday, April 14, 2017 10:22:49 AM Lukas Wunner wrote:
> On Tue, Feb 14, 2017 at 12:26:01PM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, February 14, 2017 10:31:38 AM Geert Uytterhoeven wrote:
> > > Laurent Pinchart reported that r8a7790/Lager crashes during suspend tests.
> > > 
> > > I managed to reproduce the issue on r8a7791/koelsch:
> > >   - It only happens during suspend tests, after writing either "platform"
> > > or "processors" to /sys/power/pm_test,
> > >   - It does not (or is less likely) to happen during full system suspend
> > > ("core" or "none").
> > > 
> > > More investigation shows this happens when the PME scan runs, once per
> > > second.  During PME scan, the PCI host bridge (rcar-pci) registers are
> > > accessed while the host bridge's module clock has already been disabled,
> > > leading to a crash.
> > 
> > OK, so clearly PME scans should be suspended before the host bridge
> > registers become inaccessible.
> > 
> > Another question, though, is whether or not PME scans are actually necessary
> > on the affected platforms at all.
> 
> I'm not seeing a fix for this in linux-next, am I missing something?
> Has anyone looked into it or is the issue still open?

It is still open AFAICS.

> Below is a tentative patch which moves PME polling to a freezable
> workqueue, so it is frozen before the host bridge is suspended.
> Geert, Laurent, could you test this?
> 
> The patch may be problematic in that pci_pme_list_scan() acquires
> pci_pme_list_mutex, which is also acquired by pci_pme_active(),
> which gets called when devices are suspended -- *after* the worker
> has been frozen.  I'm not really familiar with the freezer, can it
> happen that the worker is frozen while holding the mutex?  If so
> this would deadlock.  Rafael?

That depends on the worker, precisely on where it calls try_to_freeze().

That said I think it won't do that while holding any locks. :-)

Thanks,
Rafael

[PATCH 2/3] ARM: dts: sk-rzg1m: add SCIF0 pins

[Sergei Shtylyov]

Add the (previously omitted) SCIF0 pin data to the SK-RZG1M board's
device tree.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7743-sk-rzg1m.dts |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -1,7 +1,7 @@
 /*
  * Device Tree Source for the SK-RZG1M board
  *
- * Copyright (C) 2016 Cogent Embedded, Inc.
+ * Copyright (C) 2016-2017 Cogent Embedded, Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2. This program is licensed "as is" without any warranty of any
@@ -39,7 +39,17 @@
clock-frequency = <2000>;
 };
 
+ {
+   scif0_pins: scif0 {
+   groups = "scif0_data";
+   function = "scif0";
+   };
+};
+
  {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
status = "okay";
 };
 

[PATCH 1/3] ARM: dts: r8a7743: add PFC support

[Sergei Shtylyov]

Define the generic R8A7743 part of the PFC device node.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7743.dtsi |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -1,7 +1,7 @@
 /*
  * Device Tree Source for the r8a7743 SoC
  *
- * Copyright (C) 2016 Cogent Embedded Inc.
+ * Copyright (C) 2016-2017 Cogent Embedded Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2. This program is licensed "as is" without any warranty of any
@@ -123,6 +123,11 @@
#power-domain-cells = <1>;
};
 
+   pfc: pin-controller@e606 {
+   compatible = "renesas,pfc-r8a7743";
+   reg = <0 0xe606 0 0x250>;
+   };
+
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a7743",
 "renesas,rcar-dmac";

[PATCH 3/3] ARM: dts: sk-rzg1m: add Ether pins

[Sergei Shtylyov]

Add the (previously omitted) Ether/PHY pin data to the SK-RZG1M board's
device tree.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7743-sk-rzg1m.dts |   13 +
 1 file changed, 13 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -44,6 +44,16 @@
groups = "scif0_data";
function = "scif0";
};
+
+   ether_pins: ether {
+   groups = "eth_link", "eth_mdio", "eth_rmii";
+   function = "eth";
+   };
+
+   phy1_pins: phy1 {
+   groups = "intc_irq0";
+   function = "intc";
+   };
 };
 
  {
@@ -54,6 +64,9 @@
 };
 
  {
+   pinctrl-0 = <_pins _pins>;
+   pinctrl-names = "default";
+
phy-handle = <>;
renesas,ether-link-active-low;
status = "okay";

Greetings.

[Sarah JOHNSON]

Good Day Dearest.

My name is Sarah JOHNSON I am 18 years old, the only daughter of late Mr. 
Raymond JOHNSON from Burkina Faso, I am contacting you to help me relocate to 
your country to continue my university education in  your country, before my 
father died he gave me a deposit slip document of ($7,000,000 USD) and made me 
understand that it was because of his position in the government that his 
government associates planed and poisoned him on a business trip with them to 
France and he advised me to look for a faithful and reliable foreigner who will 
help me to transfer this money to his country and help me to relocate over 
there to continue my studies.

I hope you will help me with the good faith and trust I have in you, after you 
have secured the money and settle my education, I will give you 30% of the 
money for your good and kind assistance to me. Please Contact me 
e-Mail:sarah.johnson197...@yahoo.com 

I am waiting on your reply

Regards,

Sarah.

Re: PCI / PM: Crashes in PME scan during system suspend

[Lukas Wunner]

On Tue, Feb 14, 2017 at 12:26:01PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, February 14, 2017 10:31:38 AM Geert Uytterhoeven wrote:
> > Laurent Pinchart reported that r8a7790/Lager crashes during suspend tests.
> > 
> > I managed to reproduce the issue on r8a7791/koelsch:
> >   - It only happens during suspend tests, after writing either "platform"
> > or "processors" to /sys/power/pm_test,
> >   - It does not (or is less likely) to happen during full system suspend
> > ("core" or "none").
> > 
> > More investigation shows this happens when the PME scan runs, once per
> > second.  During PME scan, the PCI host bridge (rcar-pci) registers are
> > accessed while the host bridge's module clock has already been disabled,
> > leading to a crash.
> 
> OK, so clearly PME scans should be suspended before the host bridge
> registers become inaccessible.
> 
> Another question, though, is whether or not PME scans are actually necessary
> on the affected platforms at all.

I'm not seeing a fix for this in linux-next, am I missing something?
Has anyone looked into it or is the issue still open?

Below is a tentative patch which moves PME polling to a freezable
workqueue, so it is frozen before the host bridge is suspended.
Geert, Laurent, could you test this?

The patch may be problematic in that pci_pme_list_scan() acquires
pci_pme_list_mutex, which is also acquired by pci_pme_active(),
which gets called when devices are suspended -- *after* the worker
has been frozen.  I'm not really familiar with the freezer, can it
happen that the worker is frozen while holding the mutex?  If so
this would deadlock.  Rafael?

Alternative approaches would be to
(a) skip devices in pci_pme_list_scan() if their is_prepared or
is_suspended flags are set, or
(b) disable PME polling via a PM notifier.

The latter seems preferable performance-wise.  (To avoid checking
these flags once per second.)

Best regards,

Lukas

-- >8 --

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7904d02..d35c016 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1782,8 +1782,8 @@ static void pci_pme_list_scan(struct work_struct *work)
}
}
if (!list_empty(_pme_list))
-   schedule_delayed_work(_pme_work,
- msecs_to_jiffies(PME_TIMEOUT));
+   queue_delayed_work(system_freezable_wq, _pme_work,
+  msecs_to_jiffies(PME_TIMEOUT));
mutex_unlock(_pme_list_mutex);
 }
 
@@ -1848,8 +1848,9 @@ void pci_pme_active(struct pci_dev *dev, bool enable)
mutex_lock(_pme_list_mutex);
list_add(_dev->list, _pme_list);
if (list_is_singular(_pme_list))
-   schedule_delayed_work(_pme_work,
- 
msecs_to_jiffies(PME_TIMEOUT));
+   queue_delayed_work(system_freezable_wq,
+  _pme_work,
+  
msecs_to_jiffies(PME_TIMEOUT));
mutex_unlock(_pme_list_mutex);
} else {
mutex_lock(_pme_list_mutex);