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 > > 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 > >
Attachment:
signature.asc
Description: PGP signature
