Hello Alfred, hello everybody,

On Sat, May 19, 2001 at 10:08:25PM -0400, Alfred Perlstein wrote:
> * Alfred Perlstein <[EMAIL PROTECTED]> [010519 21:57] wrote:
> > * Szilveszter Adam <[EMAIL PROTECTED]> [010519 16:53] wrote:
> > > Hello everybody,
> > > 
> > > I guess I was just being too happy so it had to get me this time:-) I was
> > > building Mozilla when it struck. Today's -CURRENT, kernel & world in sync,
> > > no softupdates.
> > > 
> > > panic: mutex vm not owned at ../../vm/vm_page.h:328
> > > Debugger("panic")
> ...
> > 
> > Thanks for the traceback, can you apply this patch then try
> > to get your machine to swap?
> Oh, yeah, thanks for being brave, I've got a lot of other developers
> telling me they're not upgrading past the vm mutex patch point which
> is pretty stupid as it's doing to more harm then good without a
> thorough workout. :(

I'm afraid I don' understand this one exactly. Did other developers oppose
that you give this patch to me? Why? If they have not yet upgraded, that's
fine. I was not asking to solve this problem here and now (although a
solution is great:-) I was trying to help narrow it down since appearently
I am the one with this problem right now. There is no hurry, this machine
is play-box, which normally does nothing important, just a surf terminal.
Being able to use X would be nice however, but more on that later:-)

So, anyways,
thanks for trying to help, I applied the patch nevertheless. I have since
discovered a sure-fire method to cause a freeze and reboot, however, and
maybe this may shed some light. Unfortunately, the method involves starting
X, which makes debugging difficult. As soon as I attempt to start it, the
screen enters SVGA mode and turns dark but the X server is never actually
started it seems or at least never comes but the whole machine hangs for a
couple of secs and then reboots itself. Unfortunately, while in this wedged
state, it doesn't seem to be interested in me:-( Note that this effect is
not dependent on the patch, but only appeared with yesterday's build,
earlier X always worked fine. What effect, if any, the
patch will have will show hopefully during the course of the day.

Another interesting nit:

- It seems that if I power-cycle the machine and start up clean, it can do
  approx 1-1,5 hours of compiling at which point it will panic like posted.

This time the trace was:


and it did not even attempt to dump, just froze at "synching disks" I had
to reset it.

- However, if after this I bring it up in single-user, do a manual fsck,
  and continue in multi-user, than it could do compiles and more (eg I
  restarted the Mozilla build after my initial report and hit the hay, and 
  by morning the machine was still up, the compile finished successfully
  and even the periodic script runs caused apperently no problem.)

So this seems rather interesting of a locking issue... however, some other
info I did not give: this is an UP system, which may be important.

As usual, I am more than happy to provide info, test, etc.

BTW this appears to be recent and possibly related to the problem:

---------<snip from kernel build log>.-----------
cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs
ct-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
at-extensions -ansi -g -nostdinc -I-  -I. -I../.. -I../../dev
 -I../../contrib/dev/acpica/Subsystem/Include  -D_KERNEL -include
opt_global.h -
elf  -mpreferred-stack-boundary=2  ../../ddb/db_watch.c
In file included from ../../ddb/db_watch.c:41:
../../vm/vm_map.h: In function `_vm_map_lock_upgrade':
../../vm/vm_map.h:265: warning: implicit declaration of function `mtx_lock'


cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs
ct-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
at-extensions -ansi -g -nostdinc -I-  -I. -I../.. -I../../dev
 -I../../contrib/dev/acpica/Subsystem/Include  -D_KERNEL -include
opt_global.h -
elf  -mpreferred-stack-boundary=2  ../../kern/link_elf.c
In file included from ../../kern/link_elf.c:52:
../../vm/vm_map.h: In function `_vm_map_lock_upgrade':
../../vm/vm_map.h:265: warning: implicit declaration of function `mtx_lock'
-------------<end of snippet>------------

it also happens in the ibcs2 and fpu modules. Of course this may be pure
BS, I am not a kernel hacker, just speculate.

Szilveszter ADAM
Szeged University
Szeged Hungary

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to