Default OS update log

[sjk]

With 1.6, it seems the first time, after a reboot \i can suspend, but all attempts after the first suspend/make cycle do not work. 

Thanks -- Scott.

[tuxor]

Hi Just received my PineBookPro yesterday, and initial impressions are good. Updated using the supplied script to 1.5 without any issues. 

My first hiccup is that suspend does not seem to be working. Hitting the power button and clicking suspend, cause it to sleep for a second, and then immediately wake up. Also closing the lid, does not seem to do anything, as I can still see the screen lit between the halves of the  clamshell. 

Thanks,
Scott.

I am experiencing this too and fiddled around with it a bit but I could only get suspend to work once per boot. I don't have the logs handy right now, but there were some problems with systemd-suspend trying to put the eMMC back so sleep because they get a wakeup call from somewhere.

This seems to be an issue with newest update. I was trying to debug it, but it only happens occasionally for me. Try to reboot and suspend - it will likely suspend just fine.
If someone could catch a dmesg or better yet UART, then this would be very useful.

I attached my full dmesg with one suspend working and the second one not. When the suspend is not working I get the error marked below:

Code:

...
[  152.419256] PM: Preparing system for sleep (freeze)
[  152.422854] Freezing user space processes ... (elapsed 0.005 seconds) done.
[  152.428746] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  152.430454] PM: Suspending system (freeze)
[  152.430462] Suspending console(s) (use no_console_suspend to debug)
[  152.430683] [BT_RFKILL]: Enter rfkill_rk_pm_prepare
[  152.430685] [BT_RFKILL]: Disable UART_RTS
[  152.430731] [BT_RFKILL]: enable irq for bt wakeup host
[  152.432881] bcmsdh_sdmmc_suspend Enter func->num=2
[  152.432886] dhdsdio_suspend Enter
[  152.482286] bcmsdh_sdmmc_suspend bcmsdh_suspend err=-16
[  152.482311] dpm_run_callback(): pm_generic_suspend+0x0/0x4c returns -16
>>>>> [  152.482323] PM: Device mmc2:0001:2 failed to suspend: error -16
>>>>> [  152.482331] PM: Some devices failed to suspend, or early wake event detected
>>>>> [  152.581766] PM: resume of devices complete after 99.410 msecs
[  152.588643] [BT_RFKILL]: Enter rfkill_rk_pm_complete
[  152.588648] [BT_RFKILL]: ** disable irq
[  152.588658] [BT_RFKILL]: Enable UART_RTS
[  152.589250] PM: Finishing wakeup.
[  152.589258] Restarting tasks ... done.
...

After a reboot suspend works as expected again (only once though until next reboot).

Don't have access to UART tools right now, otherwise I'd be glad to do some more testing.

Can you please let us know if the latest release resolves the suspend/resume issue that you're seeing? v1.6 was pushed yesterday

Just ran the updater to v1.6 and can confirm it works reliably now, that fixed it. Suspend works for me now, thank you!

edit: Im using xfce and use the GUI tools that are provided with xfce to suspend, from the CLI I use "systemctl suspend" to suspend and both ways work consistently for me so far.

[Mrfixit2001]

With 1.6, it seems the first time, after a reboot \i can suspend, but all attempts after the first suspend/make cycle do not work. 

Thanks -- Scott.

A few things... it looks like you aren't giving the system enough time to finish waking up before trying to suspend again. But I've also seen that timeout error before when usb3 / usb-c devices are connected during a suspend / restart. I'm working on an update that addresses that. I expect you shouldn't run into this issue if you suspend without usb3 or usbc devices and don't try and suspend again within 30 seconds after a resume.

[sjk]

With 1.6, it seems the first time, after a reboot \i can suspend, but all attempts after the first suspend/make cycle do not work. 

Thanks -- Scott.

A few things... it looks like you aren't giving the system enough time to finish waking up before trying to suspend again. But I've also seen that timeout error before when usb3 / usb-c devices are connected during a suspend / restart. I'm working on an update that addresses that. I expect you shouldn't run into this issue if you suspend without usb3 or usbc devices and don't try and suspend again within 30 seconds after a resume.

I just tried again. Waited 2 minutes after the first wakeup, and could not suspend again. 

I then rebooted, and could not suspend the first time after the reboot. It seems like sometimes I can get 1 suspend after a reboot,   sometimes not. Never more than 1. 

My hardware is bareboones during this experiment, just the PBP, no  card, no usb-, no usb-c. Just the laptop. 

Let me know if I can provide more debugging information.

[tuxor]

I have to take it back, suspend stopped working on my Pinebook again.

Getting the same error as before, that there's a wake up call detected.

Code:

...
[ 3150.735479] dpm_run_callback(): platform_pm_suspend+0x0/0x64 returns -110
[ 3150.735486] PM: Device xhci-hcd.3.auto failed to suspend: error -110
[ 3150.735491] PM: Some devices failed to suspend, or early wake event detected
[ 3150.878334] PM: suspend exit 2019-12-08 11:14:16.061040883 UTC
...

That flaky behavior gets quite annoying to be honest. Where's the problem?

[Luke]

V1.7 - Quite and important update:

Update 10/12/2019
* Kernel update
* Many mainline backports
* Fix for USB 3.0 suspend/ resume
* WiFi verbosity fix
* Fix for USB C suspend/ resume
* Enable USB C hubs support

[MiiCode2]

V1.7 - Quite and important update:

Update 10/12/2019
* Kernel update
* Many mainline backports
* Fix for USB 3.0 suspend/ resume
* WiFi verbosity fix
* Fix for USB C suspend/  resume
* Enable USB C hubs support

I have updated to V1.7.

I still have an issue when I connect my USB-C Startech to DVI Adapter to an older Apple Cinema display.

When I boot and connect, everything works great.  If I disconnect the USB-C connector and then try to re-connect to the display, it no longer comes on until I reboot.

I had the same behavior on V1.6.

Here is the output from dmesg.

When monitor gets plugged in initially it is working:

[   63.633838] fusb302 4-0022: CC connected in CC2 as DFP
[   63.640863] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn
[   63.925628] fusb302 4-0022: PD connected as DFP, supporting 5V
[   63.996643] usb 3-1: new full-speed USB device number 2 using xhci-hcd
[   64.014708] fusb302 4-0022: DP config successful, pin_assignment 0x4
[   64.019682] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn
[   64.186312] fusb302 4-0022: attention, dp_status 8a
[   64.186986] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Connected, not enabled. Enabling cdn
[   64.470780] usb 3-1: device descriptor read/64, error -71
[   64.606346] rockchip-vop ff8f0000.vop: [drm:vop_crtc_enable] Update mode to 1920x1200p0, type: 10
[   64.610109] cdn-dp fec00000.dp: 1620Mbps x 4lanes
[   64.799039] usb 3-1: New USB device found, idVendor=1fc9, idProduct=5002
[   64.799064] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   64.799075] usb 3-1: Product: PTN5002
[   64.799085] usb 3-1: Manufacturer: NXP
[   64.799095] usb 3-1: SerialNumber: 00000ece0595

After monitor disconnect:


[  356.394663] usb 3-1: USB disconnect, device number 2
[  356.408943] fusb302 4-0022: connection has disconnected
[  356.420012] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn

Re-connect and monitor no longer displays anything:

[  406.743792] fusb302 4-0022: CC connected in CC2 as DFP
[  406.750887] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn
[  407.039982] fusb302 4-0022: PD connected as DFP, supporting 5V
[  407.103424] usb 3-1: new full-speed USB device number 3 using xhci-hcd
[  407.129421] fusb302 4-0022: DP config successful, pin_assignment 0x4
[  407.131156] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn
[  407.296160] fusb302 4-0022: attention, dp_status 8a
[  407.300201] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Connected, not enabled. Enabling cdn
[  407.577545] usb 3-1: device descriptor read/64, error -71
[  407.905771] usb 3-1: New USB device found, idVendor=1fc9, idProduct=5002
[  407.905799] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  407.905813] usb 3-1: Product: PTN5002
[  407.905825] usb 3-1: Manufacturer: NXP
[  407.905837] usb 3-1: SerialNumber: 00000ece0595

[bbraun]

Would it be possible to have the nvme module compiled into the default kernel? Or if the default install used an initrd, that would probably be a more generic solution. This would make it much easier to root off nvme on the default install.

[sjk]

V1.7 - Quite and important update:

Update 10/12/2019
* Kernel update
* Many mainline backports
* Fix for USB 3.0 suspend/ resume
* WiFi verbosity fix
* Fix for USB C suspend/  resume
* Enable USB C hubs support

I still cannot suspend, not even after a reboot. The system suspends and immediately wakes up.

Here is the dmesg dump.

[Luke]

@sjk what happens if you press Fn+ESC?