Re: any real documentation of the boot2 prompt?
Jo Rhett wrote: So I've been searching for hours now, and it appears that short of reading the C code, there's no documentation of the boot2 menu prompt. Sure, it says drive:driver(unit,slice,part) But no combination of those three that I can find actually works. There's two LUNs: drive 0: single 2TB slice drive 1: 264GB, with root, swap, etc How do I tell boot2 to find the loader on disk1? 1:da(1,a) 1:da(1,1,a) 1:da(0,1,a) 1:da(0,a) 0:da(1,a) 0:da(0,a) ...etc none of them work. Take a look at boot(8). I think you need to specify the file to load: 1:da(1,a)/boot/loader -- Suleiman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue LOR
Kostik Belousov wrote: On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: Hi, the attached lor.txt contains LOR I got this yesterday. It is FreeBSD 6.1 with relatively recent kernel, from last week or so. -- VH +lock order reversal: + 1st 0xc537f300 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1547 + 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ /usr/src/sys/ufs/ufs/ufs_vnops.c:138 +KDB: stack backtrace: +kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at kdb_backtrace+0x2f +witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at witness_checkorder+0x5fe +_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at _mtx_lock_flags+0x32 +ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at ufs_itimes+0x6c +ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at ufs_getattr+0x20 +VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at VOP_GETATTR_APV+0x3a +filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 +knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 +VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at VOP_WRITE_APV+0x148 +vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at vn_write+0x201 +dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,,...) at dofilewrite+0x84 +kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 +write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f +syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 +Xint0x80_syscall() at Xint0x80_syscall+0x1f +--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = 0xbfbfea1c, ebp = 0xbfbfea48 --- Thank you for the report. The LOR is caused by my commit into sys/ufs/ufs/ufs_vnops.c, rev. 1.280. Is the mount lock really required, if all we're doing is a single read of a single word (mnt_kern_flags) (v_mount should be read-only for the whole lifetime of the vnode, I believe)? After all, reads of a single word are atomic on all our supported architectures. The only situation I see where there MIGHT be problems are forced unmounts, but I think there are bigger issues with those. Sorry for noticing this email only now. -- Suleiman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue LOR
Attilio Rao wrote: 2006/12/12, Kostik Belousov [EMAIL PROTECTED]: On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote: Kostik Belousov wrote: On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote: Hi, the attached lor.txt contains LOR I got this yesterday. It is FreeBSD 6.1 with relatively recent kernel, from last week or so. -- VH +lock order reversal: + 1st 0xc537f300 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1547 + 2nd 0xc45c22dc struct mount mtx (struct mount mtx) @ /usr/src/sys/ufs/ufs/ufs_vnops.c:138 +KDB: stack backtrace: +kdb_backtrace(c07f9879,c45c22dc,c07fd31c,c07fd31c,c080c7b2,...) at kdb_backtrace+0x2f +witness_checkorder(c45c22dc,9,c080c7b2,8a,c07fc6bd,...) at witness_checkorder+0x5fe +_mtx_lock_flags(c45c22dc,0,c080c7b2,8a,e790ba20,...) at _mtx_lock_flags+0x32 +ufs_itimes(c47a0dd0,c47a0e90,e790ba78,c060e1cc,c47a0dd0,...) at ufs_itimes+0x6c +ufs_getattr(e790ba54,e790baec,c0622af6,c0896f40,e790ba54,...) at ufs_getattr+0x20 +VOP_GETATTR_APV(c0896f40,e790ba54,c08a5760,c47a0dd0,e790ba74,...) at VOP_GETATTR_APV+0x3a +filt_vfsread(c4cf261c,6,c07f445e,60b,0,...) at filt_vfsread+0x75 +knote(c4f57114,6,1,1f30c2af,1f30c2af,...) at knote+0x75 +VOP_WRITE_APV(c0896f40,e790bbec,c47a0dd0,227,e790bcb4,...) at VOP_WRITE_APV+0x148 +vn_write(c45d5120,e790bcb4,c5802a00,0,c4b73a80,...) at vn_write+0x201 +dofilewrite(c4b73a80,1b,c45d5120,e790bcb4,,...) at dofilewrite+0x84 +kern_writev(c4b73a80,1b,e790bcb4,8220c71,0,...) at kern_writev+0x65 +write(c4b73a80,e790bd04,c,c07d899c,3,...) at write+0x4f +syscall(3b,3b,bfbf003b,0,bfbfeae4,...) at syscall+0x295 +Xint0x80_syscall() at Xint0x80_syscall+0x1f +--- syscall (4, FreeBSD ELF32, write), eip = 0x2831d727, esp = 0xbfbfea1c, ebp = 0xbfbfea48 --- Thank you for the report. The LOR is caused by my commit into sys/ufs/ufs/ufs_vnops.c, rev. 1.280. Is the mount lock really required, if all we're doing is a single read of a single word (mnt_kern_flags) (v_mount should be read-only for the whole lifetime of the vnode, I believe)? After all, reads of a single word are atomic on all our supported architectures. The only situation I see where there MIGHT be problems are forced unmounts, but I think there are bigger issues with those. Sorry for noticing this email only now. The problem is real with snapshotting. Ignoring MNTK_SUSPEND/MNTK_SUSPENDED flags (in particular, reading stale value of mnt_kern_flag) while setting IN_MODIFIED caused deadlock at ufs vnode inactivation time. This was the big trouble with nfsd and snapshots. As such, I think that precise value of mmnt_kern_flag is critical there, and mount interlock is needed. This can be avoided using a memory barrier when setting flags. Even if memory barriers usage is not encouraged, some critical code should really use them replacing a mutex semantic (if that worths it). Why is memory barrier usage not encouraged? As you said, they can be used to reduce the number of atomic (LOCKed) operations, in some cases. FWIW, Linux has rmb() (load mem barrier), wmb() (store mem barrier), mb() (load/store mem barrier), smp_rmb(), smp_wmb(), smp_mb() (mem barriers only needed on SMP), and barrier() (GCC barrier (__asm __volatile (:::memory)) macros that I've personally found very useful. Admittedly, they are harder to use than atomic operations, but it might still worth having something similar. -- Suleiman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pagezero again
Ivan Voras wrote: Some time ago I reported that pagezero kernel thread sometime takes (what seems to me) a too large chunk of available CPU (30%) on a very busy web server. There were no replies :( Since then, I've reconfigured apache to use PHP as a fastcgi module and the problem seems to have gotten worse - now it *always* takes ~25-30% CPU, and my System time stat shows it (its almost always ~30%). From what I can understand, pagezero thread fills kernel's pool of zeroed pages. This looks non-threteaning, but what would cause such high demand of zeroed pages on my system? The number of processes is almost constant, there are no frequent process spawnings or forks (top shows last pid to be almost constant). FastCGI processes communicate over UNIX sockets. Also, pagezero thread is (should be) executing at idle priority - does this mean it won't interfere much with machine's performance? Even if 0% idle is not uncommon state? (This is FreeBSD 6.1-R, 2CPU SMP). Can you give the output of top(1)? Until this is fixed, you can disable pagezero with sysctl vm.idlezero_enable=0. -- Suleiman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS2 partition with negative used space
Hi, On Jun 9, 2005, at 11:50 PM, Xin LI wrote: Hi, Suleiman, 2005-06-09 23:35 -0400Suleiman Souhlal Hi, [...] It used to be recomputed by the kernel at mount time if the filesystem was dirty, but delphij changed it so that background fsck recomputes it instead. For some reason, in this case, this wasn't enough to synchronize the superblock's cg summary with the actual summary stored in the cgs. I'll have to investigate some more. Will setting vfs.ffs.compute_summary_at_mount=1 before mounting the volume help the situation? Unfortunately, we didn't try that (well, we actually did, but I forgot to tell Jean-Yves to make sure his volume was dirty before mounting it). -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS2 partition with negative used space
Hi, On Jun 9, 2005, at 10:22 PM, Jean-Yves Lefort wrote: Hi, Filesystem SizeUsed Avail Capacity Mounted on /dev/ad0s1e989M-46M956M -5%/var/tmp Any hints? During a private discussion I had with Jean-Yves, we have determined that the problem was due to the cylinder group summary being stale. It used to be recomputed by the kernel at mount time if the filesystem was dirty, but delphij changed it so that background fsck recomputes it instead. For some reason, in this case, this wasn't enough to synchronize the superblock's cg summary with the actual summary stored in the cgs. I'll have to investigate some more. In the meantime, a fsck -y is enough to fix it. Bye. -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Hi, On May 10, 2005, at 1:24 AM, Daniel Eischen wrote: No, libc_r wraps execve() and a lot of other syscalls that libpthread or libthr don't need to. Take a look at libc_r/uthread/ uthread_execve.c and you will see it sets the signal mask before exec()ing. Couldn't we do the same thing in libpthread, in the not-threaded case? I apologize if I'm asking stupid questions.. :) -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Hello, On May 9, 2005, at 1:31 PM, Pete French wrote: 5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? I just ran a test here with SMP turned of on 5.4-RC4 (GENERIC) I got the following result: 67.52 real41.13 user26.16 sys 7034 involuntary context switches i.e. it still has system time a a huge proportion of the total compared to the 4.11 kernel. Interesingly, after reading Holger Kipp's results I tried it on a genuine multi-processor box with SMP enabled running 5.3. He got a very small percentage of the time in sys (3.51 out of 81.90) but I got: 255.30 real 160.20 user88.50 sys Once again a far higher proprtion of the time spent in sys than you would expect. I ran ktrace(1) on it, and it appears that python keeps calling sigprocmask() continually: 673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c) 673 python 0.05 RET sigprocmask 0 673 python 0.09 CALL sigprocmask(0x1,0,0x8113d1c) 673 python 0.05 RET sigprocmask 0 etc.. This explains why it's using so much system time. Now the question is why is python doing this? -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Hello, On May 9, 2005, at 3:54 PM, Daniel Eischen wrote: On Tue, 10 May 2005, Peter Jeremy wrote: On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote: I have what I think is a serious performance issue with fbsd 5.3 release. I've read about threading issues, and it seems to me that that is what I'm looking at, but I'm not confident enough to rule out that it might be a hardware issue, a kernel configuration issue, or something to do with the python port. There does appear to be a problem in FreeBSD. Python is built with threading enabled by default, the threading libraries play with the signal mask and there have been extensive changes there. My The threading libraries don't play with the signal mask. In fact, libpthread has userland versions of sigprocmask() et. al. and won't even make the syscall() unless the threads are system scope. There is a special thread in libpthread that handles signals which does use the system sigprocmask(), but unless the application is making heavy use of signals in general, it shouldn't matter. I think I've found the problem: Python uses setjmp/longjmp to protect against SIGFPU every time it does floating point operations. The python script does not actually use threads, and libpthread assumes non-threaded processes are system scope. So, it would end up using the sigprocmask syscall, even though it doesn't really need to. The diff at http://people.freebsd.org/~ssouhlal/testing/ thr_sigmask-20050509.diff fixes this, by making sure the process is threaded, before using the syscall. -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Hello, On May 9, 2005, at 7:21 PM, Daniel Eischen wrote: I don't think that patch is correct. You need the signal mask in the kernel to match in case of an exec() after a fork() for instance. If the application fork()'s, then changes the signal mask in the child (which is now single threaded), then the child exec()s, the mask is wrong. If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). Processes linked with libc_r NEVER call the syscall, once they have started (after rtld-elf): zZzZ:~/py% LD_LIBMAP=libpthread.so.1=libc_r.so.5 ktrace -t c python heapsort.py 1 /dev/null kdump -T | grep sigprocmask 2991 python 1115698354.240301 CALL sigprocmask (0x1,0x2810a820,0xbfbfea60) 2991 python 1115698354.240304 RET sigprocmask 0 2991 python 1115698354.240307 CALL sigprocmask(0x3,0x2810a830,0) 2991 python 1115698354.240308 RET sigprocmask 0 zZzZ:~/py% compare with libpthread: zZzZ:~/py% ktrace -t c python heapsort.py 1 /dev/null kdump - T | grep -c sigprocmask 92114 zZzZ:~/py% Is this a bug in libc_r? -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issues in 5.3-RELEASE.
Hi, On Thu, 2004-11-18 at 03:46, Ronald Klop wrote: For what I have seen everybody uses snd_emu10k1. Since I use my onboard soundcard (snd_ess* (not MPSAFE)) I have less problems with my sound under disk load. None of the sound drivers are actually MPSAFE.. The reason people that use snd_emu10k1 are more affected by this is because it has a smaller default buffer size (4096) than the other drivers. -- Suleiman Souhlal| [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
