Messages in this thread | | | From | Harini Katakam <> | Date | Tue, 27 Nov 2018 11:55:47 +0530 | Subject | Re: [PATCH v2 4/4] net: macb: Add support for suspend/resume with full power down |
| |
Hi Claudiu,
On Mon, Nov 26, 2018 at 8:16 PM <Claudiu.Beznea@microchip.com> wrote: > > > > On 26.11.2018 09:07, Harini Katakam wrote: <snip> > > In the previous version you said you encountered some crashes while > stressing this part if macb_open()/macb_close() was used in here. Could you > share the tests so that I can debug it on my side?
Sure, my tests include doing a series of suspend/resume -- it is done as part of a random regression script. On ZynqMP, it includes the following to do an FPD off suspend and then use either UART or WOL as a wake source and repeat the same, sometimes pinging in between:
echo pm_request_wakeup 8 1 0 1 > /sys/kernel/debug/zynqmp-firmware/pm echo pm_force_powerdown 6 > /sys/kernel/debug/zynqmp-firmware/pm echo enabled > /sys/devices/platform/amba/ff000000.serial/tty/ttyPS0/power/wakeup echo enabled > /sys/devices/platform/amba/ff0e0000.ethernet/net/eth0/power/wakeup echo mem > /sys/power/state
ping does not work sometimes and after a few iterations (sometimes 20), a crash can be observed tracing from "kfree_skb_list" to "macb_free_consistent". From the flow, the only explanation I could come up with was that there was an attempt to free buffers that may not have been allocated. Also, this was time consuming in the suspend/resume path.
<snip> > > + } else { > > + macb_writel(bp, NCR, MACB_BIT(MPE)); > > Just asking... shouldn't other registers be restored here after SoC power > is cut off? Ideally yes. But in this series, I'm just attempting to re-initialize to a working state. I can try context save/restore later.
Regards, Harini
| |