On Mon, Feb 11, 2019 at 09:02:17AM +0000, Tristan Bastian wrote: > Thierry Reding – Mon, 11. February 2019 9:54 > > On Sun, Feb 10, 2019 at 09:20:01PM +0100, Tristan Bastian wrote: > > > Hi John, > > > > > > So I'm running with CPU DFLL Clock enabled and it is working fine.. > > > > > > Since I don't know how to debug the not working suspend, I attached my dmesg > > > output when running pm-suspend: > > > > > > [ 548.312095] PM: suspend entry (deep) > > > [ 548.312106] PM: Syncing filesystems ... done. > > > [ 548.711143] rfkill: input handler enabled > > > [ 548.773693] Freezing user space processes ... (elapsed 0.004 seconds) > > > done. > > > [ 548.778001] OOM killer disabled. > > > [ 548.778007] Freezing remaining freezable tasks ... (elapsed 0.001 > > > seconds) done. > > > [ 548.779912] printk: Suspending console(s) (use no_console_suspend to > > > debug) > > > [ 548.784432] mwifiex_sdio mmc1:0001:1: info: successfully disconnected > > > from 44:4e:6d:6f:a5:0d: reason code 3 > > > [ 548.791657] mwifiex_sdio mmc1:0001:1: None of the WOWLAN triggers enabled > > > [ 553.843794] Bluetooth: Host sleep enable command failed > > > [ 553.843800] Bluetooth: HS not activated, suspend failed! > > > [ 553.843813] dpm_run_callback(): pm_generic_suspend+0x0/0x48 returns -16 > > > [ 553.843826] PM: Device mmc1:0001:2 failed to suspend async: error -16 > > > [ 553.843916] PM: Some devices failed to suspend, or early wake event > > > detected > > > [ 554.103601] tegra-sor 54540000.sor: failed to attach SOR: -110 > > > [ 554.292068] OOM killer enabled. > > > [ 554.292074] Restarting tasks ... > > > [ 554.293913] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 554.295802] done. > > > [ 554.301180] PM: suspend exit > > > [ 554.321490] rfkill: input handler disabled > > > [ 554.393944] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 554.393955] mwifiex_sdio mmc1:0001:1: scan failed: -1 > > > [ 554.564316] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 554.564415] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 554.664897] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 554.664914] mwifiex_sdio mmc1:0001:1: scan failed: -1 > > > [ 555.666327] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 555.666335] mwifiex_sdio mmc1:0001:1: scan failed: -1 > > > [ 556.668738] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 556.668779] mwifiex_sdio mmc1:0001:1: scan failed: -1 > > > [ 557.672858] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 557.672915] mwifiex_sdio mmc1:0001:1: scan failed: -1 > > > [ 558.676060] mwifiex_sdio mmc1:0001:1: PREP_CMD: device in suspended state > > > [ 558.676070] mwifiex_sdio mmc1:0001:1: scan failed: -1 > > > > > > So it looks like this is failing because of bluetooth? > > > > So when you're saying that suspend is failing, it's actually never > > entering suspend? Or is it suspending but not resuming properly? > > > > If the former I wouldn't consider that a critical bug, but if we > > actually manage to suspend and then can't resume properly, that's fairly > > critical. > > > > Thierry > > I'm trying this on ubuntu and if I run systemctl suspend I'm ending at a blank screen with no backlight on. > And I'm not able to resume the system. > > If I run the pm-suspend command from above, the system goes to the same black screen, but leaves after a short while. > > I'm not sure if pm-suspend should end in a suspend mode or not.. So suspend can always be aborted if any driver fails to suspend. The kernel will then make sure to resume drivers that have already been suspended. However, it seems like the SOR fails to properly resume at that point: [ 554.103601] tegra-sor 54540000.sor: failed to attach SOR: -110 I vaguely remember fixing that at some point in the past. What version of the kernel are you running? Thierry
Attachment:
signature.asc
Description: PGP signature
