Date: Wed, 22 Jul 1998 10:30:33 +0200 (MEST) From: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE> To: freebsd-current@freefall.cdrom.com Subject: panic in one year old 3.0-current Message-ID: <199807220830.KAA05011@gilberto.physik.RWTH-Aachen.DE>
next in thread | raw e-mail | index | archive | help
On a NFS/NIS server that serves a number of FreeBSD workstations
a colleague who is doing backups over the net (using tar/rmt)
told me that the server is crashing when he is trying to
backup a FS over the net.
I located the twp panics we had to be in these areas:
The first one:
/var/log/messages sagt :
Jul 22 09:36:03 toots /kernel:
Jul 22 09:36:03 toots /kernel:
Jul 22 09:36:03 toots /kernel: Fatal trap 12: page fault while in kernel mode
Jul 22 09:36:03 toots /kernel: fault virtual address = 0x64a4505d
Jul 22 09:36:03 toots /kernel: fault code = supervisor write,
+page not present
Jul 22 09:36:03 toots /kernel: instruction pointer = 0x8:0xf0136e75
Jul 22 09:36:03 toots /kernel: stack pointer = 0x10:0xf4740ef4
Jul 22 09:36:03 toots /kernel: frame pointer = 0x10:0xf4740f58
Jul 22 09:36:04 toots /kernel: code segment = base 0x0, limit
+0xfffff, type 0x1b
Jul 22 09:36:04 toots /kernel: = DPL 0, pres 1, def32 1, gran
+1
Jul 22 09:36:04 toots /kernel: processor eflags = interrupt enabled, resume,
+IOPL = 0
Jul 22 09:36:04 toots /kernel: current process = 17629 (tar)
Jul 22 09:36:04 toots /kernel: interrupt mask =
Jul 22 09:36:04 toots /kernel: trap number = 12
Jul 22 09:36:04 toots /kernel: panic: page fault
kernel region:
f0136a8c T _rmdir
f0136bec T _ogetdirentries
f0136e64 T _getdirentries
<<<<<< f0136e75
f0137020 T _umask
f0137048 T _revoke
f013715c T _getvnode
f01371a0 F vfs_vnops.o
and the second one:
Jul 22 09:54:37 toots /kernel:
Jul 22 09:54:37 toots /kernel:
Jul 22 09:54:37 toots /kernel: Fatal trap 12: page fault while in kernel mode
Jul 22 09:54:37 toots /kernel: fault virtual address = 0xa0004
Jul 22 09:54:37 toots /kernel: fault code = supervisor read,
+page
not present
Jul 22 09:54:37 toots /kernel: instruction pointer = 0x8:0xf01aea28
Jul 22 09:54:37 toots /kernel: stack pointer = 0x10:0xf473ed84
Jul 22 09:54:37 toots /kernel: frame pointer = 0x10:0xf473ed98
Jul 22 09:54:37 toots /kernel: code segment = base 0x0, limit
+0xfffff, type 0x1b
Jul 22 09:54:37 toots /kernel: = DPL 0, pres 1, def32 1, gran
+1
Jul 22 09:54:37 toots /kernel: processor eflags = interrupt enabled, resume,
+IOPL = 0
Jul 22 09:54:37 toots /kernel: current process = 280 (gzip)
Jul 22 09:54:37 toots /kernel: interrupt mask = net bio
kernel region:
f01ae694 t _pmap_remove_entry
f01ae7ac t _pmap_insert_entry
f01ae82c t _pmap_remove_pte
f01ae8a8 t _pmap_remove_page
f01ae8ec T _pmap_remove
f01ae9f8 t _pmap_remove_all
<<<<<<< f01aea28
f01aeb58 T _pmap_protect
f01aed78 T _pmap_enter
f01aefc8 t _pmap_enter_quick
f01af0a0 T _pmap_object_init_pt
f01af3b0 T _pmap_prefault
f01af578 T _pmap_change_wiring
Does anyone know if this behaviour may correlate to a meanwhile
fixed bug and if it might be worth upgrading to 2.2.6-stable?
--
Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807220830.KAA05011>
