Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jul 1998 15:39:30 +0200
From:      Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE>
To:        Matthew Thyer <thyerm@camtech.net.au>, Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE>
Cc:        freebsd-current@freefall.cdrom.com
Subject:   Re: panic in one year old 3.0-current
Message-ID:  <19980722153930.A6043@gil.physik.rwth-aachen.de>
In-Reply-To: <35B5D5AE.4801C673@camtech.net.au>; from Matthew Thyer on Wed, Jul 22, 1998 at 09:36:06PM %2B0930
References:  <199807220830.KAA05011@gilberto.physik.RWTH-Aachen.DE> <35B5D5AE.4801C673@camtech.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 22, 1998 at 09:36:06PM +0930, Matthew Thyer wrote:
> NFS had lots of problems until quite recently.

Sigh. Tell this a person to whom you always argued "I'm using FreeBSD
over Linux for it's stability what networking is concerned" :-)
Maybe things are even worse under Linux.

NFS was indeed involved in my case alse (see below).

> 
> I was restricting my NFS use to the version 2 protocol until very
> recently.
> 
> Now it seems to work very well with version 3 on recent current.
> 
> e.g. I spent the other day building the world on a Pentium 100
> with 32MB RAM running X (Netscape, fvwm2-95 and xterms) whilst
> at the same time I was installing various ports AND [here's the
> best bit]:  Random playing 2 Gig worth of MPEG 1 layer 3 audio
> files with mpg123 version 0.59o from an NFS3 mounted directory
> (from a Solaris 2.5.1 system) without a hitch.  I was not using
> any buffering with mpg123 but I did have to run it a a real time
> process to stop the sound breaking up.  (rtprio 31 mpg123 .... )
> 
> I did this for 5 or 6 hours or so without a problem.
> 
> Of course make world took a lot longer as mpg123 was using ~35%
> of the CPU most of the time.
> 
> Paging didn't seem to be a problem as I was using about 50% of my
> 130 MB swap the whole time.
> 
> The load average was usually between 3 and 4 most of the day.
> 
> Needless to say I was very impressed as was the rest of the office.
> (Even the HP-UX lover had to be impressed as HP-UX 10.20 is really
> unstable with NFS3).
> 
> Now thats thrashing the poor P100!
> 
> Of course this is only a test of NFS3 client.
> 
> 
> Christoph Kukulies wrote:
> > 
> > On a NFS/NIS  server that serves a number of FreeBSD workstations
> > a colleague who is doing backups over the net (using tar/rmt)


I was errounously assuming that it was tar/rmt but it was
tar with destination to a file on an NFS mounted Dec Alpha (OSF/1).

> > 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
> 
> -- 
> /=====================================================================\
> |Work: Matthew.Thyer@dsto.defence.gov.au | Home: thyerm@camtech.net.au|
> \=====================================================================/
> "If it is true that our Universe has a zero net value for all conserved
> quantities, then it may simply be a fluctuation of the vacuum of some
> larger space in which our Universe is imbedded. In answer to the
> question of why it happened, I offer the modest proposal that our
> Universe is simply one of those things which happen from time to time."
>  E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973

-- 
--Chris 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?19980722153930.A6043>