On Tue, Sep 10, 2024 at 05:36:56PM +0800, duanchenghao wrote: > S4 wakeup restores the image that was saved before the system entered > the S4 sleep state. > > S4 waking up from hibernation > ============================= > kernel initialization > | > v > freeze user task and kernel thread > | > v > load saved image > | > v > freeze the peripheral device and controller > (Check the HCD_FLAG_WAKEUP_ PENDING flag of the USB. If it is set, > return to EBUSY and do not perform the following restore image.) Why is the flag set at this point? It should not be; the device and controller should have been frozen with wakeup disabled. > | > v > restore image(task recovery) > > > However, upon detecting that the hcd is in the > > > HCD_FLAG_WAKEUP_PENDING state, > > > it will return an EBUSY status, causing the S4 suspend to fail and > > > subsequent task recovery to not proceed. > > > > What will return an EBUSY status? > > if HCD_FLAG_WAKEUP_PENDING flag is set_bit, will return EBUSY. I meant: Which function will return EBUSY status? The answer is in the log below; hcd_pci_suspend() does this. > > Why do you say that S4 suspend will fail? Aren't you talking about > > S4 > > wakeup? > > After returning EBUSY, the subsequent restore image operation will not > be executed. > > > > > Can you provide a kernel log that explains these points and shows > > what > > problem you are trying to solve? > > [ 9.009166][ 2] [ T403] PM: Image signature found, resuming > [ 9.009167][ 2] [ T403] PM: resume from hibernation > [ 9.009243][ 2] [ T403] inno-codec inno-codec.16.auto: > [inno_vpu][vpu_notifier:1540]vpu_notifier: untested action 5... > [ 9.009244][ 2] [ T403] Freezing user space processes ... (elapsed > 0.001 seconds) done. > [ 9.010355][ 2] [ T403] OOM killer disabled. > [ 9.010355][ 2] [ T403] Freezing remaining freezable tasks ... > (elapsed 0.000 seconds) done. > [ 9.012152][ 2] [ T403] PM: Basic memory bitmaps created > [ 9.073333][ 2] [ T403] PM: Using 3 thread(s) for decompression > [ 9.073334][ 2] [ T403] PM: Loading and decompressing image data > (486874 pages)... > [ 9.073335][ 2] [ T403] hibernate: Hibernated on CPU 0 [mpidr:0x0] > [ 9.095928][ 2] [ T403] PM: Image loading progress: 0% > [ 9.664803][ 2] [ T403] PM: Image loading progress: 10% > [ 9.794156][ 2] [ T403] PM: Image loading progress: 20% > [ 9.913001][ 2] [ T403] PM: Image loading progress: 30% > [ 10.034331][ 2] [ T403] PM: Image loading progress: 40% > [ 10.154070][ 2] [ T403] PM: Image loading progress: 50% > [ 10.277096][ 2] [ T403] PM: Image loading progress: 60% > [ 10.398860][ 2] [ T403] PM: Image loading progress: 70% > [ 10.533760][ 2] [ T403] PM: Image loading progress: 80% > [ 10.659874][ 2] [ T403] PM: Image loading progress: 90% > [ 10.760681][ 2] [ T403] PM: Image loading progress: 100% > [ 10.760693][ 2] [ T403] PM: Image loading done > [ 10.760718][ 2] [ T403] PM: Read 1947496 kbytes in 1.68 seconds > (1159.22 MB/s) > [ 10.761982][ 2] [ T403] PM: Image successfully loaded > [ 10.761988][ 2] [ T403] printk: Suspending console(s) (use > no_console_suspend to debug) > [ 10.864973][ 2] [ T403] innovpu_freeze:1782 > [ 10.864974][ 2] [ T403] innovpu_suspend:1759 > [ 11.168871][ 2] [ T189] PM: pci_pm_freeze(): > hcd_pci_suspend+0x0/0x38 returns -16 This should not be allowed to happen. Freezing is mandatory and not subject to wakeup requests. Is your problem related to the one discussed in this email thread? https://lore.kernel.org/linux-usb/d8600868-6e4b-45ab-b328-852b6ac8ecb5@xxxxxxxxxxxxxxxxxxx/ Would the suggestion I made there -- i.e., have the xhci-hcd interrupt handler skip calling usb_hcd_resume_root_hub() if the root hub was suspended with wakeup = 0 -- fix your problem? Alan Stern
