Date: Tue, 26 Feb 2019 19:01:02 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: head -r334018 powerpc64 PowerMac G5 pmac_thermal: which sleep sometimes gets hung up vs. which ones have not (so far) Message-ID: <4BDD3946-C7E8-4333-847E-3374864A105E@yahoo.com>
index | next in thread | raw e-mail
fan_management_proc uses:
pause("pmac_therm", hz);
which leads to (via my replacing what KTR_PROC tracing
reports):
sleepq_set_timeout_sbt: sbt=fffffed8 pr=0 flags=100 td_sleeptimo=... prec=fffffed flags=501
(the figures are all hexadecimal)
So far all pmac_thermal stuck-sleeps have been based on this
timeout happening but failing the comparison to sbinuptime()
in the sleepq_timeout callout (instead of the original --but
unaccessible "now"). But the comparison does not always fail
--and so the pause does not always get stuck.
Note: (timeo/hz) seconds is used (approximately),
here (hz/hz) seconds approximately 1 second.
smu_run_cmd uses:
error = tsleep(cmd, 0, "smu", 800 * hz / 1000);
. . .
which leads to:
sleepq_set_timeout_sbt: sbt=cccccbe0 pr=0 flags=100 td_sleeptimo=... prec=cccccbe flags=501
Note: (timeo/hz) seconds is used, here approximately 0.8 seconds.
kiic_transfer uses:
timo = 100;
. . .
mtx_sleep(dev, &sc->sc_mutex, 0, "kiic", timo);
. . .
err = mtx_sleep(dev, &sc->sc_mutex, 0, "kiic", timo);
which leads to:
sleepq_set_timeout_sbt: sbt=653332be30 pr=0 flags=100 td_sleeptimo=... prec=653332be3 flags=501
Note: (100/hz) seconds is used here.
smuiic_transfer uses:
mtx_sleep(sc, &sc->sc_mtx, 0, "smuiic", 100);
. . .
mtx_sleep(sc, &sc->sc_mtx, 0, "smuiic", 10);
which leads to:
sleepq_set_timeout_sbt: sbt=28f5c26 pr=0 flags=100 td_sleeptimo=... prec=28f5c2 flags=501
Note: (100/hz) seconds is used and (10/hz) seconds is used.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BDD3946-C7E8-4333-847E-3374864A105E>