Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

freebsd-hackers Digest, Vol 366, Issue 7

1 view
Skip to first unread message

freebsd-hac...@freebsd.org

unread,
Apr 4, 2010, 8:00:22 AM4/4/10
to freebsd...@freebsd.org
Send freebsd-hackers mailing list submissions to
freebsd...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org

You can reach the person managing the list at
freebsd-ha...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."


Today's Topics:

1. Re: random FreeBSD panics (Masoom Shaikh)
2. Re: random FreeBSD panics (Gary Jennejohn)
3. Re: leak of the vnodes (Petr Salinger)
4. Re: leak of the vnodes (Kostik Belousov)


----------------------------------------------------------------------

Message: 1
Date: Sat, 3 Apr 2010 12:51:46 +0000
From: Masoom Shaikh <masoom...@gmail.com>
Subject: Re: random FreeBSD panics
To: Ivan Voras <ivo...@freebsd.org>
Cc: freebsd...@freebsd.org, freebsd...@freebsd.org,
freebsd-...@freebsd.org
Message-ID:
<q2ib10011eb1004030551yf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras <ivo...@freebsd.org> wrote:
> On 28 March 2010 16:42, Masoom Shaikh <masoom...@gmail.com> wrote:
>
>> lets assume if this is h/w problem, then how can other OSes overcome
>> this ? is there a way to make FreeBSD ignore this as well, let it
>> result in reasonable performance penalty.
>
> Very probably, if only we could detect where the problem is.
> Try adding "options     PRINTF_BUFR_SIZE=128" to the kernel
> configuration file if you can, to see if you can get a less mangled
> log outout.
>

ok, after few days of silence I am back with more questions
this time system feels little better, it is able to sustain for more
time that what 7.3-RELEASE could

FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1
01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64

I am using KDE4, and when OS freezes, well it freezes, means I cannot
change to tty0 and see the panic text, if any it might possibly have
spit. the stuck frozen GUI keeps staring there. So the question is how
to I capture that panic text ? unfortunately I am not getting core
files too, so there is nothing I can pick up hints

is there some option (KDB, DDB), so that on panic system drop to debugger ?

Masoom Shaikh


------------------------------

Message: 2
Date: Sat, 3 Apr 2010 16:35:23 +0200
From: Gary Jennejohn <gary.je...@freenet.de>
Subject: Re: random FreeBSD panics
To: Masoom Shaikh <masoom...@gmail.com>
Cc: freebsd...@freebsd.org, freebsd...@freebsd.org
Message-ID: <20100403163...@ernst.jennejohn.org>
Content-Type: text/plain; charset=US-ASCII

On Sat, 3 Apr 2010 12:51:46 +0000
Masoom Shaikh <masoom...@gmail.com> wrote:

> On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras <ivo...@freebsd.org> wrote:
> > On 28 March 2010 16:42, Masoom Shaikh <masoom...@gmail.com> wrote:
> >
> >> lets assume if this is h/w problem, then how can other OSes overcome
> >> this ? is there a way to make FreeBSD ignore this as well, let it
> >> result in reasonable performance penalty.
> >
> > Very probably, if only we could detect where the problem is.
> > Try adding "options __ __ PRINTF_BUFR_SIZE=128" to the kernel
> > configuration file if you can, to see if you can get a less mangled
> > log outout.
> >
>
> ok, after few days of silence I am back with more questions
> this time system feels little better, it is able to sustain for more
> time that what 7.3-RELEASE could
>
> FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1
> 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64
>
> I am using KDE4, and when OS freezes, well it freezes, means I cannot
> change to tty0 and see the panic text, if any it might possibly have
> spit. the stuck frozen GUI keeps staring there. So the question is how
> to I capture that panic text ? unfortunately I am not getting core
> files too, so there is nothing I can pick up hints
>
> is there some option (KDB, DDB), so that on panic system drop to debugger ?
>

[trimmed Cc - no need to send this to 3 MLs]

There's no code in the kernel to switch back out of graphics mode (i.e.
what X uses) when a panic happens.

You probably can switch to v0, but you won't be able to see it.

The only sure-fire way is to hook up a screen (terminal, laptop or
another computer) to a serial port.

--
Gary Jennejohn


------------------------------

Message: 3
Date: Sat, 3 Apr 2010 09:16:54 +0200 (CEST)
From: Petr Salinger <Petr.S...@seznam.cz>
Subject: Re: leak of the vnodes
To: freebsd...@freebsd.org
Message-ID: <Pine.LNX.4.62.10...@sci.felk.cvut.cz>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

>> Another possible workaround, if you do not need path resolutions in /proc
>> or lsof(1), is to set sysctl vfs.vlru_allow_cache_src=1.
>
> I will test this.

Does not help.

kern.maxvnodes: 100000
kern.minvnodes: 25000
vfs.vlru_allow_cache_src: 1
vfs.freevnodes: 199
vfs.wantfreevnodes: 25000
vfs.numvnodes: 100038
debug.vnlru_nowhere: 647

Petr


------------------------------

Message: 4
Date: Sat, 3 Apr 2010 19:52:38 +0300
From: Kostik Belousov <kost...@gmail.com>
Subject: Re: leak of the vnodes
To: Petr Salinger <Petr.S...@seznam.cz>
Cc: freebsd...@freebsd.org
Message-ID: <2010040316...@deviant.kiev.zoral.com.ua>
Content-Type: text/plain; charset="us-ascii"

On Sat, Apr 03, 2010 at 09:16:54AM +0200, Petr Salinger wrote:
> >>Another possible workaround, if you do not need path resolutions in /proc
> >>or lsof(1), is to set sysctl vfs.vlru_allow_cache_src=1.
> >
> >I will test this.
>
> Does not help.
>
> kern.maxvnodes: 100000
> kern.minvnodes: 25000
> vfs.vlru_allow_cache_src: 1
> vfs.freevnodes: 199
> vfs.wantfreevnodes: 25000
> vfs.numvnodes: 100038
> debug.vnlru_nowhere: 647

Can you go into single-user mode, and then start unmounting filesystems
one by one, looking at the vfs.numvnodes ? The goal is to determine
which fs caused exhaustion of the vnodes limit.

Then, after you determined the problematic mp, reboot the machine,
redo the procedure causing leak. From ddb prompt, you can do "show mount",
find the mp, then do "show mount <mp address>". The later command shall
produce really large output, listing all mp vnodes, so serial console
or firewire can be useful. Put output somewhere.

Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100403/b95968a6/attachment-0001.pgp

------------------------------


End of freebsd-hackers Digest, Vol 366, Issue 7
***********************************************

0 new messages