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.. Tristan > > > > Thanks > > > > Tristan > > > > Am 28.01.19 um 11:20 schrieb Jon Hunter: > > > On 28/01/2019 09:44, Tristan Bastian wrote: > > > > The following commit disabled the CPU DFLL Clock of the nyan boards to > fix suspend: > > > > ARM: tegra: Fix suspend hang on Tegra124 Chromebooks (9a0baee960a7) > > > I think you mean commit 80373d37bee5. > > > > > > > I'm not sure if suspend was working afterwards, but at least suspend > isn't working in the latest kernels. > > > It was at least until v4.15 (I don't have any testlogs after that > > > unfortunately). > > > > > > > When suspend isn't working anyway we could reenable the CPU DFLL clock > again to at least make that work. > > > I don't think that is a good idea. > > > > > > > So would it be possible to revert the commit from above or fix suspend > or maybe both? > > > If suspend is broken, then that needs to be fixed. Once that works, we > > > need to have a way to switch from the DFLL to the PLL correctly for > > > suspend before we can revert this change. > > > > > > Cheers > > > Jon > > >