On 2019-05-28, Paco Esteban <p...@onna.be> wrote: > Hi Stuart, > > On Tue, 28 May 2019, Stuart Henderson wrote: > >> Some things to try: >> >> Does it seem to be in ddb? Try typing "call cpu_reset" blindly and see >> if it reboots. > > I'll take a look at the manpages to see how that works. Never used the > kerned debugger.
This is just a command which is likely to trigger a reboot (on amd64) without getting into other problems that might hang. Basically to identify whether it's in ddb without having changed the screen, or whether it's hard locked. (There's some new non-arch-dependent command to do this but I forgot what it's called and it didn't get added to the ddb manual). >> Does it start responding again if you wait? > > No, at least in a "short time period" (5 minutes more or less). I'll try > to wait longer next time to test this. I'd give it a little bit more than this, though probably doesn't need much more. I've had systems recover from hangs after 5-10ish minutes (I don't know if it's likely to be similar or completely different to what you're seeing, so just throwing out a few things to try to get more information and possibly help..). >> What does "sysctl kern.timecounter.hardware" say? If it's tsc, try one >> of the other names shown in "sysctl kern.timecounter.choice", probably >> acpihpet0 if available. >> >> Is it any better with the intel driver rathef than modesetting? Try this >> in xorg.conf: >> >> Section "Device" >> Identifier "Intel Graphics" >> Driver "intel" >> EndSection > > I'll try them all one change at a time and try to make a table > (work/crash) for it. > > It can take some time as the problem manifests randomly. > > Thanks for the suggestions. >
