[Linux] Shutdown hangs

[blueskull]

I recently ran into a problem with shutting down my system on a new laptop.

The symptom is that it fails to power off when I click power off in Gnome desktop.

It is not an ACPI issue as I can power it off using poweroff command or shutdown -P command.

However, normally I believe shutdown -h can also put it into power off mode (so halt is treated as poweroff in modern Linux OSes), but in my case it only halts the system not shutting it down.

Journal shows the system has reached completely halt, with everything cleanly unmounted and cleaned up after.

So, I guess the question is, how can I force systemd-halt.service to power off the computer?

[PKTKS]

Dug through journalctl -b -1, found that interestingly enough, the OS stuck after "reached target: power off", rather than "reached target: halt".

So the kernel was told to power off by gnome, but for whatever reason it got stuck, while if I explicitly tell it to power off, it will. This is weird.

Anyway, I reverted from 5.11-rc6 (mainline, compiled myself) to stable 5.10 release (linux-oem-20.04-edge), and it all went normal.

There is a short answer (here)  and a loooooong proper answer
posted after the short one.

The short answer is that these "generic" fit all - suited for casual - kernels
do the things the possible worst way..

Vast majority of kernel modules are compiled in_kernel thus resulting
in a kernel image 50 times bigger than a proper hand crafted one.

 ACPI specification is mostly implemented in modules and since
these modules will attach IRQ handlers to the kernel.. the order
in which these  handlers and the proper BUS (ACPI uses mostly I2C and SMB)
will interact on a target system.

That said ... potterix systemd like things - which just "load that shit all parallel"
all built in kernel...  have a great chance to improperly assign  IRQs..

It happens not only in ACPI but USB as well devices will wrongly claim
IRQs due to wrong IRQ priority.

It may be solved by crafted kernels..  but the obvious solution
is to load the modules orderly and assign strictly required IRQs.

It is not going to happen on the potterix systemd things..

Paul

[PKTKS]

The LOOOONG answer...

ACPI was meant to replace BIOS INT15H APM services.

Obviously by removing power controllers from a specific matched
hardware via  BIOS..  to a combination of software/firmware on ACPI tables..
we now rely into the fact that the OS will be able not only to identify
the whole plethora of components on the system.. but also be able
to map each and every system out there...

For that old folks will remember that PC-AT  PSUs received things like
PS_ON , PG and other lines...  resulting in ATX form factors.

Chips like HY510N or TPS5510 and others became part of ATX PSUs.

On the MOBO side.. the SUPER I/O chipset was overloaded with LPC bus
crammed with I2C, SMB the real BIOS and several other things..

Laptops are now a source of complicated problems because what was
once a simple BIOS matter... became a complicated problem of "matching"
the Super I/O with a proper firmware from a proper model manufacturer..

ENE/ ITE are now mostly requiring specific programmable Super I/O
to handle ACPI and several parts of hardware.. 

Desktops are not requiring these complicated Super I/O versions but
nevertheless we are required to compile a proper kernel that will match
the devices in which ACPI is expected to handle...

That shit is growing by dozens..

A proper kernel ... properly compiled just need to care loading the BUS
modules first ... I2C and SMB... and when properly attached..
the strictly required ACPI modules should be orderly loaded to claim
strictly the needed IRQs

This way we do not risk the chance to have races or dead locks in IRQ handlers..

Obviously a SYTEMV  rc.d  proper matched loader is required..

And more obviously .. the required "halt  or "shutdown"  should
be handled by dedicated systems counter part of INIT.

It never fails when properly done.
It required different  AMD /INTEL and VIA kernels and modules..

That  FIT ALL LOAD ALL things may work.. but chances are that it fails
some point in between

Attached an expected  proper device class dependency tree.
Note the IRQ subsystem where ACPI tables play their roll

Paul

[GodIsRealUnless DefinedInt]

I recently ran into a problem with shutting down my system on a new laptop.

UEFI? Been known to hang shutdowns on some implementations.

Simple to test, add noefi as a kernel option on boot and see if it has any impact. Worth a toss.

[GodIsRealUnless DefinedInt]

That's how they fix them, firmware updates in the kernel. Used to be a big problem with Lenovo laptops with EUFI Linux shutdown hangs until the FW update arrived.

[Monkeh]

Either your kernel wasn't configured right, or there's a bug. Try building 5.10 with the same config. If it works, great, bisect.

[Monkeh]

Either your kernel wasn't configured right, or there's a bug. Try building 5.10 with the same config. If it works, great, bisect.

I copied my 5.10 config to 5.11 and ran yes '' | make oldconfig. Yet the new kernel fails to shut down.

The more interesting part is the new kernel can power off just fine with poweroff or shutdown -P now, but refuses to power off using halt or shutdown -h now.

So the new kernel must have treated halt and shutdown differently, while the old one powers off regardless receiving halt or shutdown command.

My 2 cents lie in somewhere between the kernel, systemd and gnome-shell. I'll wait till the Ubuntu team patches the user land components to fit the new kernel.

Well, technically you're describing correct behaviour. 'halt' should not power down, although it sometimes does seem to. Again, a bisect would be informative if only the kernel has changed.