On Wed, Oct 24, 2018 at 11:09:37PM -0700, Mike Larkin wrote: > On Wed, Oct 24, 2018 at 09:13:30PM +0200, Leo Unglaub wrote: > > Hi, > > thank you very much for your reply. I did what you suggested and found out > > something interesting. The change has no effect on "zzz". However when i > > execute "ZZZ" i now get the following: > > > > The screen stays on and after around 4 minutes the laptop shuts down. When i > > boot the laptop again for the first time i get the following message: > > unhibernate detected: switching to /bsd.booted > > So far so good. > > > > > Then the laptop attempts to boot but always fails. It's just stuck at the > > That's a terrible explanation. What "fails"? > > > following screen. I took a picture of it. [https://i.imgur.com/NlYyhBv.jpg] > > > > I bet if you pressed enter here a few times it would be ok. You're looking > at the resumed kernel's old dmesg output, press enter and I bet you see a > login prompt. > > In other words, I bet it worked fine. > > > When i hard-reset the laptop and try it again the boot works fine and i get > > the previous state. When i executed the ZZZ from within an X environment > > What is "the previous state"? > > > it's not usable at first. I have to CTRL+ALT+1 to something different and > > This makes no sense, what do you mean "ZZZ from within an X environment is not > usable at first"? > > > then come back to CTRL+ALT+5 again. Then it works fine. > > So, after all this, you're saying "ZZZ works fine"? > > Then what is the error you're reporting? > > > > > I found the following error in dmesg: > > > Starting stack trace... > > > tsleep(ad44de28f91f1848,ffff8000003eda60,d,ffff8000003eda00) at > > > tsleep+0x65 > > > pckbc_enqueue_cmd(762b4fe54eae8807,2,ffff8000003ed600,3,ffff8000003ed600,1) > > > at pckbc_enqueue_cmd+0x203 > > > pms_change_state(bdcbc7cf9b5f945d,0,ffff8000003eeb00) at > > > pms_change_state+0x1ce > > > pmsactivate(ebbc33233aaf717d,ffffffff81c94790) at pmsactivate+0x3b > > > config_activate_children(f12df37a7d46060e,0) at > > > config_activate_children+0x72 > > > pckbc_isa_activate(c198ed5766f26fbb,0) at pckbc_isa_activate+0x30 > > > config_activate_children(f12df37a7da320f7,0) at > > > config_activate_children+0x72 > > > config_activate_children(f12df37a7da320f7,0) at > > > config_activate_children+0xb9 > > > config_activate_children(f12df37a7dd074db,0) at > > > config_activate_children+0xb9 > > > pciactivate(37e774f29c3deede,0) at pciactivate+0x35 > > > config_activate_children(f12df37a7da3272a,ffff800000023100) at > > > config_activate_children+0x72 > > > config_suspend_all(f7408b87c1d75ae7) at config_suspend_all+0x1b4 > > > acpi_sleep_state(6d9b9d11260f3892,ffff800000020400) at > > > acpi_sleep_state+0x1f6 > > > acpi_sleep_task(b898c8a63965f9e2,ffff800000020400) at acpi_sleep_task+0x1e > > > acpi_thread(0) at acpi_thread+0x188 > > > end trace frame: 0x0, count: 242 > > > End of stack trace. > > When did you see this in dmesg? What was before that in dmesg? > > > > > The fact that the first boot attempt fails and only the second one works is > > So you're saying "booting" fails? I thought this was a zzz/ZZZ issue you were > reporting. > > > reproducable at this laptop. I did 3 different tries on this issue. > > > > When i leave wsdisplay_suspend() in, zzz and ZZZ dont work at all. I add you > > It may be possible that wsdisplay_suspend does something strange on the > machine, > then. I don't have this machine; I suggested removing that because that lets > you see what's going on during suspend. > > And I still don't know what fails with "zzz". > > > > the dmesg from the laptop with the custom kernel i build after your > > recommendation. > > This whole bug report is baffling. > > -ml
We have a theory this is a bug in pms(4). Can you use the kernel with the commented out line that does not do a wsdisplay_suspend, and boot -c ? ukc> disable pms ukc> quit then do a zzz/ZZZ/resume? This will disable the mouse/trackpad, so you might need to use a usb mouse for this test. If this works, we can dig further. -ml
