Re: TSTILE lockups on disk dump/backups

> On Dec 21, 2024, at 9:21 AM, Martin Husemann <[email protected]> =
wrote:
>=20
> On Sat, Dec 21, 2024 at 02:20:23AM -0600, Don Lee wrote:
>> Any thought about how I should deal with this? My kernel debugging
>> skills are weak. Is there anything I can do to produce useful debug
>> information next time this happens?
>=20
> A tstile just means the process/kernel thread is blocked for a longer
> time waiting for "something". In this context that would typically be
> either a disk buffer ("buf") read from disk (the source you are =
backing
> up) or a network buffer ("mbuf") handed to the network device output
> queue.
>=20
> This would point to a bug in the disk driver or the network driver.

Wherever it is, I didn=E2=80=99t see it on NetBSD 8.2. That may mean =
that it=E2=80=99s a new bug, or it might be that something in the timing =
of 8.2 just didn=E2=80=99t trigger it.

It=E2=80=99s a macppc system with 1 GB of memory. I wonder if NetBSD 9.4 =
needs more memory...

> The other option would be your system runing out of kernel address =
space,
> so it can not allocate either type of buffer. This would show up in=20
> the output of vmstat -s (or you are running against limits for either
> type of buffer, but I would expect that to fail differently).

> Can you start new processes in the state when it hangs? Like the =
vmstat -s=20
> mentioned above, or "crash" to look at kernel state? I am not sure =
"crash"
> would work on macppc and 9.x good enough.

> Martin

 I should be able to do a vmstat -s next time it hangs. It seems that =
most processes run OK while the system's stuck, as long as I don=E2=80=99t=
 touch the the filesystem(s) the wrong way. If I don=E2=80=99t notice =
the hang, the dump processes =E2=80=9Cpile up=E2=80=9D as they get =
launched by cron. Eventually, I can=E2=80=99t log in, but early in the =
process, I can log in and do stuff.

Many thanks,

-dgl-