Hello All,

I am getting memory corruption issue during suspend resume cycle.
Basically I am getting issues like linux crash during wake up process, Kernel page fault, bag page map, squash fs error due to lzo decompression issue, segfaults etc issues when my device is waking up from suspend. The occurrence of the issues are rare but consistent.

I was trying to do few experiments and based on analysis, it looks like those issues are happening due to memory corruption. To confirm that I added 300 msec delay after sys_sync operation in suspend.c before device goes for suspend. On testing, scenario really improved, means I don't see those issues any more.

But here I cant use hard delays due to process utilization constraints. So my query is , is there any way to track sys_sync completion which can be implemented during suspend process?
because sys_sync returns before it actually finished syncing. So there will be possibility of devices are suspending before sync completes. Hence sue to unsuccessful sync, memory corruption might happen when the device wakes up.

Please suggest any way to track sys_sync completion during suspend.

Thanks,
Diptendu

Looking at your previous threads it seems you have an unusually constrained environment that you are not inclined to talk about. If you really think the sync is returning before the data are hardened, raise a bug against the kernel. My understanding is this shouldn't happen on current Linux kernels. Be prepared to have good evidence, and you will have to define the environment in detail.

I don't understand this.Your organization is prepared to accept outages, but not institute a fix you says resolves (avoids) the issue. Strange place.
As to your question, you can trace the entry and exit to sync, but what would be the point if as you allege it is returning too early. Do you have accurate commit timing from the device itself ?. So many questions - how many levels of abstraction exist between the kernel and the "device" where the suspend writes to ?.