NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: how to turn off devices that monitor sensors



As you both predicted, disabling those drivers at boot didn't solve
the problem; the machine still freezes at "acpi0: entering state S5".
At least now I know the problem lies elsewhere.  Thank you.

I went through the BIOS settings, and I cannot see anything which
would be forcing the system to stay on.  Wake-on-lan is disabled.  I
even tried disabling TPM and BIOS security features.

Any other ideas?  The machine, an HP Pavilion Notebook 15-au123cl,
seems so ordinary.  I will not be able to use it as I had hoped,
because I cannot power it down remotely.  Very sad.

Thank you all again.

Henry

2022年6月12日(日) 19:39 Robert Elz <kre%munnari.oz.au@localhost>:

>
>     Date:        Sun, 12 Jun 2022 18:18:26 +0900
>     From:        Henry <nbsd4ever%gmail.com@localhost>
>     Message-ID:  <CAKP-rwGEAAOGDPHOcPagwyM9mzAS+kiaZ1VYQcDK0fOUkhU6dQ%mail.gmail.com@localhost>
>
>   | The machine freezes with the last messages to the console:
>   | acpi0: entering state S5
>
> S5 is "off" (more or less), the system should be doing nothing except
> waiting for someone (or something) to request that it be turned on again.
>
> It looks as if your system is one of those which NetBSD doesn't know how
> to really shut down, or the BIOS has bugs which are preventing that from
> happening.   Do you have any "Wake on" type events configured in the BIOS?
> If so, you might want to try disabling those and see if that might make
> a difference - the BIOS might be keeping the system more alive that you
> want so that wake on lan, or wake on usb keyboard, or something can work.
>
>   | acpitz0: workqueue busy: updates stopped
>   | coretemp0: workqueue busy: updates stopped
>   | coretemp1: workqueue busy: updates stopped
>
> As Martin said, that's just noise, because the BIOS hasn't reset enough to
> stop that stuff from interrupting, and is apparently keeping enough power
> enabled to the ram (or at least caches) that enough of NetBSD is still
> around to report that stuff, I agree with Martin, those are almost certainly
> not related to your issue (they're a symptom caused by it, not causing it).
> [I also would agree that there's potentially a driver bug, once the system
> is off (or supposed to be off) nothing should be being processed at all.]
>
> kre
>
> ps: this might, or might not, make it direct from me to gmail, so I hope
> you're subscribed to netbsd-users so you can get the reply that way.  gmail
> doesn't like me, and tends to bounce mail I send.
>
>


Home | Main Index | Thread Index | Old Index