Created attachment 285197 [details] otcpl-dell-p5510-xeon-2_mem_psmouse.html The psmouse on the Dell p5510 xeon 2 occasionally takes almost a second to suspend. This bug will monitor other systems for this issue as well.
Created attachment 285199 [details] issue.def monitor all psmouse devices that take longer than 50 ms to suspend
On most machines, this issue only occurs on the first suspend (mem or freeze) and goes away for the rest. e.g. Kernel Machine mode-count Issue Test # 5.3.0+ otcpl-dell-p5510-xeon-2 mem-x570 1 5.3.0+ otcpl-dell-p5510-xeon-2 freeze-x1093 1 5.3.0+ otcpl-dell-9380-cfl mem-x2053 1 5.3.0+ otcpl-dell-p5510-xeon-1 mem-x2209 1 5.3.0+ otcpl-dell-7390-cmlu mem-x2386 1 5.3.0+ otcpl-dell-p5510-xeon-1 freeze-x2431 1 5.3.0+ otcpl-dell-9380-cfl freeze-x2441 1 5.3.0+ otcpl-dell-7390-cmlu freeze-x2618 1 5.3.0+ otcpl-dell-9360-kbl mem-x2821 1 5.3.0+ otcpl-dell-9360-kbl freeze-x2859 1
Created attachment 285341 [details] dell-9360-kbl_mem_#1_with_issue.html
Created attachment 285343 [details] dell-9360-kbl_mem_#2_without_issue.html
On my Dell 9300, the 1st suspend after reboot always gets this: psmouse serio1: Failed to disable mouse on isa0060/serio1 and the device delays the suspend flow by 800 ms.
Created attachment 289013 [details] sleepgraph showing failure in Linux-5.7-rc4 In the attached sleepgraph output, you can hover over the schedule_timeout and udelay boxes in the psmouse1 section. ps2_do_sendbyte() 201ms i8042_waitwrite() 184ms ps2_do_sendbyte() 203ms ps2_do_sendbyte() 203ms ps2_do_sendbyte() 203ms All of these delays are synchronous and delay the entire machine's suspend progress, as we don't have enough work to run in parallel with these long delays.
Created attachment 289015 [details] sleepgraph showing SUCCES in Linux-5.7-rc4 on Dell 9300 Here is a successful sleepgraph result for a subsequent suspend cycle on the same machine. It was successful, in that serio1 did not add a measurable delay. Indeed, you zoom in all the way, you can observe a very small block just before serio0, and it is serio1, which took only 0.001 msec! All subsequent tests will be fast like this one. But the problem will be reproduced every time on the 1st suspend after a reboot.
Created attachment 289073 [details] issue.def -- for recording known suspend/resume stress test issues