Re: page fault degaradation performance
On 11/6/07, binto [EMAIL PROTECTED] wrote: I just wanna know, how to reduce the number of page faults to upgrade program or OS performance? is there any parameters that i must set if i reduce the number of page fault? Don't forget that some amount of page faults are normal consequences of using a machine with virtual memory. Page faults alone are not an indicator that you're out of memory or suffering in any way, they just mean that something was requested in vm that wasn't actually in ram, and needed to be loaded. Ask 'swapinfo' or 'top' to see if you might possibly benefit from more ram by reducing paging. --Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault degaradation performance
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: how to reduce the number of page faults to upgrade program or OS performance? Install more memory. I can cause paging on my hugely overendowed RELENG_6 system (8GB, ~2GB active) just by reading some big files and churning through cache. It's nice seeing syslogd go into pfault while there's 5G of inactive memory and 300MB cache just waiting to be recycled. There would seem to be some room for tuning on at least some systems. -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.2 Crash
Hi all FreeBSD Hackers! :) My FreeBSD auto reboot itself and I got this report by kgdb, but actually I'm not a programmer. I don't know how to debug this error. Could someone helps with fixing? Thanx in advanced! FreeBSD .com 6.2-RELEASE-p8 FreeBSD 6.2-RELEASE-p8 #0: Tue Oct 30 22:54:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/THURISAZ i386 kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc0489471 esp = 0xd568af78 ebp = 0xd568b094 panic: double fault Uptime: 1d2h58m25s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc06abe26 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06ac0bc in panic (fmt=0xc095387e double fault) at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc08c2bb2 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:866 #4 0x in ?? () (kgdb) up 0 #0 doadump () at pcpu.h:165 165 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc06abe26 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06ac0bc in panic (fmt=0xc095387e double fault) at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc08c2bb2 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:866 #4 0x in ?? () (kgdb) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_add doesn't keep dependent pkgs
On Tue, Nov 06, 2007 at 12:27:13PM -0800, Maslan wrote: Package dependencies may change, depending on the user settings and port maintainers configuration for the port (i.e. Makefiles). The same sort of applies to packages as well. Or were you referring to just packages instead of ports based package metadata :)? Or maybe a better question is: what are you trying to accomplish? -Garrett The problem is that i always try FreeBSD snapshots, and each time i did a fresh install, i found my self in need to install xorg gnome. so when i use pkg_add -rK xorg or pkg_add -rK gnome, it just keeps the package itself only without its dependencies, it would be better for me to keep the packages i use rather than downloading them every time. The ports has no problem with that, since it leaves all the port dependencies in /usr/ports/distfiles but i prefer packages than recompiling every time i install a fresh system something like gnome would eat my day compiling it. You could always use pkg_fetch -fR (from portupgrade) to fetch them all first, and then pkg_add them after. Of course, I think fixing pkg_add to keep the dependencies also is a better solution. -- WXS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2 Crash
Atanas Gendov wrote: Hi all FreeBSD Hackers! :) My FreeBSD auto reboot itself and I got this report by kgdb, but actually I'm not a programmer. I don't know how to debug this error. Could someone helps with fixing? Thanx in advanced! FreeBSD .com 6.2-RELEASE-p8 FreeBSD 6.2-RELEASE-p8 #0: Tue Oct 30 22:54:18 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/THURISAZ i386 kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc0489471 esp = 0xd568af78 ebp = 0xd568b094 panic: double fault Do you use the nve driver? It has a known bug that causes a double fault. Unfortunately kgdb doesn't know how to properly decode double fault backtraces, so there isn't any more information about the cause. If you are not using nve, can you try to reproduce and then see what DDB says about the backtrace? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
where did the peak mbuf stat go ?
FreeBSD 4.x, netstat -m: 70/4336/26624 mbufs in use (current/peak/max) Never any doubt - if peak=max, I hit the limit. Super useful. Furthermore, by watching the peak I can see when I am getting close, rather than waiting for denied requests to pile up after the fact. FreeBSD 6.x, netstat -m: 524/826/1350 mbufs in use (current/cache/total) So ... how do I see peak mbufs in FreeBSD 6.x ? Thanks. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
A TrustedBSD voluntary sandbox policy.
I'm considering developing a policy/module for TrustedBSD loosely based on the systrace concept - A process loads a policy and then executes another program in a sandbox with fine grained control over what that program can do. I'm aiming for a much simpler implementation, however. No interaction. No privilege elevation (only restriction). No system call rewriting, only access control. The interface will look something like this: (cat EOF deny all allow file_open /etc/passwd allow file_open /dev/tty allow sock_connect 127.0.0.1 80 allow sock_connect 208.77.188.166 80 rlimit core 0 rlimit cpu 20 rlimit nofile 10 EOF ) | sandbox /bin/ls -alF /bin Please note that the 'policy' given on the command line is purely for the sake of example, no syntax or semantics have been decided upon. The implementation appears to be simple, as far as I'm aware. I'm sure there will be thorns and problems - that's what I'm here to find out. The 'sandbox' process compiles the policy text into a binary structure in userland, loads the binary structure into the kernel module via a system call implemented with mac_syscall(), sets various rlimits and then runs /bin/ls with execve(). When the process exits, the memory for the binary structure is freed. I would like, at this stage, to know if the above model is seriously incompatible with the way the MAC framework works, it's not entirely clear either way having read other policies such as mac_biba, mac_stub etc. For example - how to know when a process has exited? Policy for an executed process would be kept in a small hash table, indexed by process id. The policy will be enabled when the process sucessfully calls execve() for the first time and will be destroyed when the process exits. If we're not notified when a process has exited, we can't remove policy from the table. Also, what should be done when a process decides to fork() or execve()? It'd be rather unfortunate if the process could break out of the sandbox just by executing another process but blocking all attempts to fork() or execve() would make classes of programs unusable. Comments, flames, etc, appreciated. (cc'd to trustedbsd-discuss@ regardless of whether or not anybody actually reads it). -- dc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
