head -r334018 powerpc64 PowerMac G5 pmac_thermal: which sleep sometimes gets hung up vs. which ones have not (so far)

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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"