SUMMARY: UDBL Syndrome and tmp file system full

From: Kostas Magkos <kmag_at_lab.epmhs.gr>
Date: Thu Apr 06 2006 - 14:02:45 EDT
First of all I'd to thank all the people who jumped in and shared their
thoughts.

Summarizing:

1) What is a "UDBL Syndrome 0x1c"?

For the time being this not very critical as long as it isn't occuning
too often.

Francisco clarified that the recommendation for changing the stick is 3
or more persistent errors on 24 hours.
Nitin added that since the score is 5, it is not certain that the CE is
caused by memory itself.

UDBL stands for UltraSPARC Data Buffer. "L" means the low half of the
UDB register. Still searching for "0x1c" though.

Derek, thanks for the excellent URLs. Too much info there.

2) Are the two events related (memory problem and tmp being full)?

Most responses indicated that there is no relation.

3) If not how can I trace the tmp issue?

Suggestions included using tools such as sar, prstat, top, ps and cron
to monitor swap and /tmp usage in order to identify the process causing
all the trouble.

4) What is the recommended course of action for the memory problem?

The predominant suggestion was to replace the machine (Ultra1), as a new
module would be cost inefficient. This is already scheduled (John
Stoffel: guess what, the replacement will be a E250!), I'm just trying
to keep the machine running till then.

The tmp-swap problem most probably is caused by some process chewing up
all the space in /tmp and leaving no room in the swap (good point
Casper). I used a spare slice and mounted /tmp there (Deni and Grzegor).

Thanks guys, you rock!
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Thu Apr 6 13:55:31 2006

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:57 EST