I'm experiencing a delay or hang in powering off my computer after `halt
-d -f -i -p' and I've bisected it to this commit in the mainline tree:

commit 6d25be5782e482eb93e3de0c94d0a517879377d0
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Mar 13 17:55:48 2019 +0100

    sched/core, workqueues: Distangle worker accounting from rq lock

The delays have varied in length from ~20 seconds to seeminingly
indefinitely long (the longest I've waited before pressing the start
button on the machine is 6 minutes).  With kernels prior to this commit,
my machine powers off within 4 seconds after the halt invocation.

I first noticed this problem with the stable kernel 5.5.9 that I built
with Linux From Scratch (LFS).  My previous LFS system had stable kernel
4.20.12 and there was no such delay.  I also tried stable kernel 5.6.4
and the delay/hang also happens with it.  After consulting with LFS
developers I cloned the mainline kernel repository and determined that
problem happens with commit with v5.2 (0ecfebd2) but not with v5.1
(e93c9c99), then ran the bisection with those boundaries.

With mainline kernels (I only tried with v.5.3 and then commits between
v5.1 and v5.2 during the bisection) there are no kernel messages during
the delay/hang, but with 5.5.9 and 5.6.4, when the delay is longer than
two minutes, a message like the following is displayed:

  sr 5:0:0:0: tag#21 timing out command, waited 120s

repeating every 2 minutes with a different tag#.  This made me think the
problem was due to the cdrom device in the machine, but when I compiled
5.3.0 without /dev/cdrom (by not setting CONFIG_BLK_DEV_SR, which also
left CONFIG_CDROM unset), the delay/hang still happened.

The length of the delay seems to depend not only on the kernel but also
the number or kind of programs used.  The 20 second delay has happened
only went I invoke `shutdown -h now' (which runs `halt -d -f -i -p' in
LFS) immediately after booting.  When I ran `more' in one tty and
`shutdown -h now' in another, the machine powered off in less than two
minutes.  But after running emacs in a tty (and then killing it), the
delay was seemingly indefinite, as it is with my usual workflow with X,
emacs, firefox, etc. running (but I always kill them before invoking
`shutdown -h now' from a tty).  During the bisection I tested each
kernel build by running startx, emacs, firefox, killing these, then
`shutdown -h now'.  I've attached the git log of the bisection augmented
with power-off timing notes.  (FWIW, when I reboot the machine with
`shutdown -r now' there is no delay with the problematic kernels.)

One piece of advice I got from the LFS mailing list was to try and
revert the above commit pinpointed by the bisection in a recent mainline
or stable kernel.  But it fails to revert cleanly (using `patch -R') in
such kernels and I am too unfamiliar with the code to try and revert it
manually.

Another pointer I got was to the recent commit 62849a96, which fixes a
bug due to the commit that causes my problem.  I applied 62849a96 to
5.6.4, but it did not prevent the delay/hang.

I've found nothing on the web about this problem, so it seems to be
rare.  That's why I'm seeking your help (on the advice of LFS
developers).  In addition to the bisection log I've also attached the
kernel 5.1.0 config file (I used that during the bisection, accepting
all defaults of later options, as with the configs of 5.5.9 and 5.6.4)
and the contents of /proc/cpuinfo.  Please let me know if there's any
other information I can provide or anything else I can do to help with
debugging this issue.  I hope you can fix it.

Thanks,
Steve Berman