Hello,
Again sorry for the late summary: It looks as if my ST32550N Barracuda
used as the system disk was just slowly dying (even though it was
properly cooled with a separate fan). I've temporarily replaced this disk
now with an IBM DPES-31080 and the system is up for more than one week
(knock on wood). I'm currently about the get a warranty replacement
of the ST32550N and hope that the next one will do better.
Thanks to Steve Thompson <smt_at_NICS1.CORNING.COM>
Lucien HERCAUD <Lucien_HERCAUD_at_paribas.com>
Karen Byrd <BYRD_at_mscf.med.upenn.edu>
"Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com>
Christophe DIARRA <diarra_at_ipno.in2p3.fr>
soma_c_at_decus.fr (Claude SOMA - CNTS)
And again special thanks to Dr. Tom Blinn with whom I had a really
extensive mail exchange about that. Thanks Tom.
Tom
This is my original posting:
------------------------------------------------------------------------------
Hi,
I had two crashes of my EB64+ running DU4.0a today. After both, I found
the activity LED of the root scsi disk constantly lit. I don't know
if the system was writing the crash dump or if there was another reason
for that. The first time, I've just reset the system (during the LED
was on) and rebooted without problems.
The second time, though, I got the same boot failure as I've already
described in a previous message:
panic (cpu0): ftx_bfmeta_rec_redo: got bmt page N1 instead of N2
N1=954, N2=59.
The numbers were different, though. The root file system (which is
AdvFS) was trashed after that. In contrast to the crash on sunday,
though, the usr filesystem was still intact so I had the box going
again in about 15 minutes after rebooting from my emergency disk
and re-creating root_domain and reloading from the backup.
But: This is unacceptable. Did anyone experiance something like
that before.
What could cause that? I have no indication for the reason of the
crash.
Maybe the reason is totally different and the system just overwrites
my root domain when it tries to write its crash dump? This is the
disklabel for the disk:
disklabel -r rz3
# size offset fstype [fsize bsize cpg]
a: 187111 0 AdvFS # (Cyl. 0 -156*)
b: 493020 187111 swap # (Cyl. 156*-567*)
c: 4194058 0 unused 1024 8192 # (Cyl. 0 -3497*)
d: 0 0 unused 0 0 # (Cyl. 0 - -1)
e: 0 0 unused 0 0 # (Cyl. 0 - -1)
f: 0 0 unused 0 0 # (Cyl. 0 - -1)
g: 3513927 680131 AdvFS # (Cyl. 567*-3497*)
h: 0 0 unused 0 0 # (Cyl. 0 - -1)
Any other ideas anyone?
--------------------------------------------------------------------------
T o m L e i t n e r Dept. of Communications
Graz University of Technology,
e-mail : tom_at_finwds01.tu-graz.ac.at Inffeldgasse 12
Phone : +43-316-873-7455 A-8010 Graz / Austria / Europe
Fax : +43-316-463-697
Home page :
http://wiis.tu-graz.ac.at/people/tom.html
PGP public key on :
ftp://wiis.tu-graz.ac.at/pgp-keys/tom.asc or send
mail with subject "get Thomas Leitner" to pgp-public-keys_at_keys.pgp.net
--------------------------------------------------------------------------
Received on Mon Feb 10 1997 - 21:04:44 NZDT