Thanks to:
"Martin Mokrejs" <mmokrejs_at_natur.cuni.cz>
who suggested that we should explicitly set lockmode = 0 in
/etc/sysconfigtab. I guess when we commented the new lockmode lines out of
sysconfigtab it didn't reset it to 0 for us? Regardless, the machine has
been stable since yesterday afternoon.
Thanks!
- Jeff
Original Question:
--On Mon, Nov 23, 1998 2:34 PM -0500 "Jeff Berliner"
<jeff_at_popmail.med.nyu.edu> wrote:
> Managers:
>
> We've got a single processor AlphaServer 300 4/266. It's got DU
4.0b,
> with parts of the last patch kit installed. In the process of trying to
> help debug another problem, we set lockmode = 4 in our /etc/sysconfigtab,
> and rebooted. The machine soon crashed with the message:
>
> Nov 23 13:34:50 endeavor vmunix: lock_read: hierarchy violation
> Nov 23 13:34:50 endeavor vmunix:
> Nov 23 13:34:50 endeavor vmunix: pc of caller:
> 0xfffffc000039a3dc
> Nov 23 13:34:50 endeavor vmunix: lock address:
> 0xffffffff80273ef8
> Nov 23 13:34:50 endeavor vmunix: lock info addr:
> 0xfffffc0000ee6260
> Nov 23 13:34:50 endeavor vmunix: lock class name:
> BMT.bfAccessT.xtntMap_lk
> Nov 23 13:34:50 endeavor vmunix: class already locked:
vdT.del_list_lk
> Nov 23 13:34:50 endeavor vmunix: current spl level: 0
> Nov 23 13:34:50 endeavor vmunix:
> Nov 23 13:34:50 endeavor vmunix: panic (cpu 0): lock_read: hierarchy
> violation
>
> We've since backed out the change, but the machine crashed again
with
> the same error. It boots, runs for about 20 minutes, crashes, and
reboots.
>
>
> Is there something else we've missed in backing out the change? Did
> we hose some filesystem or something? Any help is appreciated!
>
> - Jeff
> --
> Jeff Berliner jeff_at_popmail.med.nyu.edu
> Academic Computing, Phone: (212) 263-5744
> New York University School of Medicine Fax: (212) 263-8542
>
--
Jeff Berliner jeff_at_popmail.med.nyu.edu
Academic Computing, Phone: (212) 263-5744
New York University School of Medicine Fax: (212) 263-8542
Received on Tue Nov 24 1998 - 16:36:01 NZDT