Re: Cannot rm files when ZFS is full
Try truncating some files. -Kip On Tue, Jul 28, 2009 at 8:29 PM, grarpampgrarp...@gmail.com wrote: One week old build... # df -i . Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on ram01/mnt1 239465344 239465344 0 100% 13163 0 100% /mnt1 # ls -aliT zero 20797 -rw-r--r-- 1 user user 43515904 Jul 28 23:20:57 2009 zero # rm -f zero rm: zero: No space left on device # : zero cannot create zero: File exists # cp /dev/null zero overwrite zero? (y/n [n]) y # ls -aliT zero 20797 -rw-rw-rw- 1 root wheel 0 Jul 28 23:25:17 2009 zero # rm -f zero [gone] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Open Vs Free BSD
freebsd-stable is not an advocacy list. This is very off-topic. On Mon, Jun 22, 2009 at 7:06 PM, Daniel Bolgheronim...@dbolgheroni.eng.br wrote: On Fri, 19 Jun 2009, Holger Kipp wrote: On Fri, Jun 19, 2009 at 09:47:35AM +0100, Michal wrote: For the masses: - NetBSD: Run on any hardware (including toasters) - OpenBSD: Be as secure as possible - FreeBSD: provide best system for x86-platforms It's a mistake to make this association. OpenBSD people chose security as an argument to describe what the OS is. It's true and I believe it can attract more users, but on the other side, people seem to think OpenBSD is ONLY used when you need security, like a firewall, router, etc. OpenBSD is a GENERIC OS which can be used to do _almost_ every task a computer system is able to. Teers, -- Daniel Bolgheroni m...@dbolgheroni.eng.br FEI - Faculdade de Engenharia Industrial http://www.dbolgheroni.eng.br/mykey ASCII ribbon campaign ( ) against HTML e-mail X / \ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Open Vs Free BSD
Individuals in each of the camps (Free, Open, Net) are frequently deeply invested in their platforms of choice to the point where they identify with them. In addition, many if not most of us are only familiar with one of them. Thus, it isn't really fair to ask us to compare the three. You will enjoy more success by asking each of the three projects what their respective strengths are. Cheers, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Open Vs Free BSD
I agree, this shouldn't necessarily be treated as flamebait or trolling. But shouldn't the question be redirected to the advocacy mailing list/team? Yes. This list is for targeted technical questions. It isn't realistic to expect a discussion of this nature to stay on-topic. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS user library?
I was wondering if there are plans to document and keep the ZFS user library as a reasonably stable API. You really need to ask that on the ZFS lists. Usually Solaris man pages indicate that an API is not stable (assuming) man pages exist. With a few minor exceptions, ZFS in FreeBSD just tracks ZFS in OpenSolaris. Cheers, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Let's back out LOADER_ZFS_SUPPORT from STABLE
On Sat, Jun 13, 2009 at 1:53 PM, Dan Allendanalle...@airwired.net wrote: I have now proven that the recent post June 8th version of /usr/src/sys/boot/i386/loader/Makefile causes catastrophic data loss. Then it should be disabled by default until the problem is fixed. Why on earth would this change not be immediately rolled back out of the STABLE branch? For those on the bleeding edge with CURRENT they expect to lose their entire drives, but not STABLE users. Your word choice indicates that someone has asserted otherwise, when in fact I see no indication that this is the case. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zfs related panic
show sleepchain show thread 100263 On Fri, Jun 12, 2009 at 6:56 AM, Andriy Gapona...@icyb.net.ua wrote: This is on a recent stable/7 amd64, with zpool and filesystems upgraded to the latest version. I did zfs rollback x...@yyy And then did ls on a directory in the rolled-back fs. I have the core file if it can be of any help. Sleeping thread (tid 100263, pid 2432) owns a non-sleepable lock sched_switch() at 0x8031d0ef = sched_switch+0x47d mi_switch() at 0x80302a59 = mi_switch+0x1bf sleepq_switch() at 0x8032f645 = sleepq_switch+0xd8 sleepq_catch_signals() at 0x8032f925 = sleepq_catch_signals+0x2db sleepq_wait_sig() at 0x80330219 = sleepq_wait_sig+0xc _sleep() at 0x80302eba = _sleep+0x2b5 kern_sigsuspend() at 0x802fc567 = kern_sigsuspend+0xeb sigsuspend() at 0x802fc5e9 = sigsuspend+0x34 syscall() at 0x80491d2d = syscall+0x347 Xfast_syscall() at 0x8047d00b = Xfast_syscall+0xab --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x80092ce3c, rsp = 0x7fffdee8, rbp = 0x8011e5a60 --- panic: sleeping thread cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x80192dd5 = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x80327ea7 = kdb_backtrace+0x32 panic() at 0x802fb70c = panic+0x1b0 propagate_priority() at 0x80332e92 = propagate_priority+0x122 turnstile_wait() at 0x80333e29 = turnstile_wait+0x358 _mtx_lock_sleep() at 0x802ed64a = _mtx_lock_sleep+0x117 cache_lookup() at 0x8036a52a = cache_lookup+0x632 vfs_cache_lookup() at 0x8036a69f = vfs_cache_lookup+0xab VOP_LOOKUP_APV() at 0x804c86f3 = VOP_LOOKUP_APV+0x51 lookup() at 0x80370a71 = lookup+0x5d8 namei() at 0x8037168f = namei+0x320 kern_lstat() at 0x8037f6ca = kern_lstat+0x5e lstat() at 0x8037f8c9 = lstat+0x25 syscall() at 0x80491d2d = syscall+0x347 Xfast_syscall() at 0x8047d00b = Xfast_syscall+0xab --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80095afbc, rsp = 0x7fffdde8, rbp = 0x800b50270 --- -- Andriy Gapon ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: WITHOUT_ZFS makes build world and kernel error
fixed. On Tue, May 26, 2009 at 5:05 AM, Wu, Yuevano...@gmail.com wrote: Hi, list, I have a FreeBSD 7-stable box, which has been cvsed up yesterday, even with my src.conf which has the line of WITHOUT_ZFS=yes, FreeBSD always wants to install libzfs relative stuffs when installing kernel and world, so error comes, I have to comment out this line to make the installing stage goes correctly. Is it a bug? -- Hi, Wu, Yue ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS weird device tasting loop since MFC
Must be a weird geom interaction. I don't see this with raw disk. I'll look at it eventually but UMA and performance are further up in the queue. -Kip On Fri, Jun 5, 2009 at 1:44 AM, Ulrich Spörleinu...@spoerlein.net wrote: On Tue, 02.06.2009 at 11:24:08 +0200, Ulrich Spörlein wrote: On Tue, 02.06.2009 at 11:16:10 +0200, Ulrich Spörlein wrote: Hi all, so I went ahead and updated my ~7.2 file server to the new ZFS goodness, and before running any further tests, I already discovered something weird and annoying. I'm using a mirror on GELI, where one disk is usually *not* attached as a means of poor man's backup. (I had to go that route, as send/recv of snapshots frequently deadlocked the system, whereas a mirror scrubbing did not) r...@coyote:~# zpool status pool: tank state: DEGRADED status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 12333765091756463941 REMOVED 0 0 0 was /dev/da0.eli errors: No known data errors When imported, there is a constant tasting of all devices in the system, which also makes the floppy drive go spinning constantly, which is really annoying. It did not do this with the old ZFS, are there any remedies? gstat(8) is displaying the following every other second, together with a spinning fd0 drive. dT: 1.010s w: 1.000s filter: ^...$ L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| fd0 0 8 8 1014 0.1 0 0 0.0 0.1| md0 0 32 32 4055 9.2 0 0 0.0 29.2| ad0 0 77 10 1267 7.1 63 1125 2.3 31.8| ad4 There is no activity going on, especially md0 is for /tmp, yet it constantly tries to read stuff from everywhere. I will now insert the second drive and see if ZFS shuts up then ... It does, but it also did not start resilvering the second disk: r...@coyote:~# zpool status pool: tank state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4.eli ONLINE 0 0 0 da0.eli ONLINE 0 0 16 errors: No known data errors Will now run the scrub and report back in 6-9h. Another datapoint: While the floppy-tasting has stopped, since the mirror sees all devices again, there is some other problem here: r...@coyote:/# zpool online tank da0.eli r...@coyote:/# zpool status pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Fri Jun 5 10:21:36 2009 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4.eli ONLINE 0 0 0 684K resilvered da0.eli ONLINE 0 0 0 2.20M resilvered errors: No known data errors r...@coyote:/# zpool offline tank da0.eli r...@coyote:/# zpool status pool: tank state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: resilver completed after 0h0m with 0 errors on Fri Jun 5 10:21:36 2009 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 684K resilvered da0.eli OFFLINE 0 0 0 2.20M resilvered errors: No known data errors r...@coyote:/# zpool status pool: tank state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device
Re: kmem map too small panic after updating to STABLE-7 r192996
As I mentioned in the initial e-mail, auto-tuning is only safe to rely on on amd64. -Kip On Thu, Jun 4, 2009 at 7:48 AM, Tim Chase t...@chase2k.com wrote: Hello, I decided to give the new zfs code a try and upgraded my stable-7 system and discovered a panic that I can reproduce at will. This is an i386 system with 1.5GB of RAM and a single zfs pool: appbuild# zpool status pool: backup state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM backup ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 errors: No known data errors I had previously used the following zfs tuning: vm.kmem_size=512M vm.kmem_size_max=512M vfs.zfs.arc_max=100M After getting this panic, I removed these tunables. The panic happens in either case. Reproducing the panic is easy: I keep a copy of the FreeBSD svn tree in a compressed zfs file system (compression ratio runs around 1.35x). An svn update (or the requisite svn cleanup following a system crash) in my checkout area will _always_ result in a kmem map too small panic. Here's a stack trace from my most recent panic: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc052c963 in boot (howto=260) at /root/stable-7/sys/kern/kern_shutdown.c:418 #2 0xc052cb9d in panic (fmt=Variable fmt is not available. ) at /root/stable-7/sys/kern/kern_shutdown.c:574 #3 0xc069fa2a in kmem_malloc (map=0xc105408c, size=131072, flags=2) at /root/stable-7/sys/vm/vm_kern.c:305 #4 0xc0696587 in page_alloc (zone=0x0, bytes=131072, pflag=0xe6dbcb47 \002, wait=2) at /root/stable-7/sys/vm/uma_core.c:952 #5 0xc0699000 in uma_large_malloc (size=131072, wait=2) at /root/stable-7/sys/vm/uma_core.c:2706 #6 0xc051af38 in malloc (size=131072, mtp=0xc094f060, flags=2) at /root/stable-7/sys/kern/kern_malloc.c:393 #7 0xc085db00 in zfs_kmem_alloc (size=131072, kmflags=2) at /root/stable-7/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:74 #8 0xc08d1c79 in zio_buf_alloc (size=131072) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:207 #9 0xc08bcc40 in vdev_queue_io_to_issue (vq=0xc492b334, pending_limit=Variable pending_limit is not available. ) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:227 #10 0xc08bce42 in vdev_queue_io_done (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:313 #11 0xc08d4162 in zio_vdev_io_done (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1847 #12 0xc08d2532 in zio_execute (zio=0xd420a000) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #13 0xc0862aa0 in taskq_thread (arg=0xc44a10cc) at /root/stable-7/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/os/taskq.c:854 #14 0xc0506816 in fork_exit (callout=0xc0862960 taskq_thread, arg=0xc44a10cc, frame=0xe6dbcd38) at /root/stable-7/sys/kern/kern_fork.c:811 #15 0xc06d4670 in fork_trampoline () at /root/stable-7/sys/i386/i386/exception.s:264 (kgdb) print panicstr $1 = 0xc0792320 kmem_malloc(131072): kmem_map too small: 325656576 total allocated The arc size is now auto-tuned as: kstat.zfs.misc.arcstats.c_min: 26214400 kstat.zfs.misc.arcstats.c_max: 209715200 and while monitoring kstat.zfs.misc.arcstats.size I noticed it fluctuated between around 140 and 150 million. Interestingly enough, immediately before the last panic, It (arcstats.size) had just been reduced from 150038268 to 128790020. I'm going to continue to poke around in my core dumps and see if I can figure out what's going on. Any hints as to what to look for or monitor while the system is running would be appreciated. Thanks, Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
Re: kmem map too small panic after updating to STABLE-7 r192996
On Thu, Jun 4, 2009 at 2:13 PM, Kip Macy km...@freebsd.org wrote: As I mentioned in the initial e-mail, auto-tuning is only safe to rely on on amd64. Tying ZFS in to UMA to allow zone limits to reduce memory pressure on write as well as reduce the ARC's ability to grow without bound is on my to do list. However, I haven't gotten to it yet. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS booting without partitions
Odds are that there are more changes that were made in HEAD to the loader that need to be MFC'd. -Kip On Mon, Jun 1, 2009 at 3:55 AM, Alberto Villa villa.albe...@gmail.com wrote: On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert h...@restart.be wrote: This is the file /boot/loader from 7.2-STABLE which is wrong. You can find a copy from 8.0-CURRENT and a script that I tested on a USB key) and is running for me: replacing /boot/loader with yours did the job thanks! -- Alberto Villa villa.albe...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS booting without partitions
On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall mcdou...@egr.msu.edu wrote: I'm thinking that too. I spent some time taking stabs at figuring it out yesterday but didn't get anywhere useful. I did try compiling the -current src/sys/boot tree on 7.2 after a couple header tweaks to make it compile but the loader still didn't work. The working loader is the same file size as the broken loader unless it was compiled on i386 and then it is ~30k bigger for some reason (it shrinks to the same size as the rest if I force it to use the same 32bit compilation flags as used on amd64). Just mentioning this in case it saves someone else some time. I'm real pleased it works at all. If someone has the time to track down the differences I'll MFC them. I'm not using ZFS boot at the moment so I have no way of testing. Cheers, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: buildworld fails with WITHOUT_CDDL=yes in src.conf
Same here.. The first bug is the use of a LIBZFS variable in src/sys/boot/i386/loader/Makefile, as this variable is set in share/mk/bsd.libnames.mk I just replaced LIBZFS by LIBZFSBOOT and the buildworld succeeded. The second bug is the use of LOADER_ZFS_SUPPORT without any consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) I won't comment the it won't use any memory on your system.. I'll try get it fixed by Wednesday. Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads down
Please try applying this change to your tree and let me know. Thanks, Kip http://svn.freebsd.org/viewvc/base?view=revisionrevision=193110 On Sat, May 30, 2009 at 2:11 AM, Henri Hennebert h...@restart.be wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy km...@freebsd.org wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I get a Fatal trap 12: page fault while in kernel mode at shutdown. the core.txt is http://verbier.restart.be/xfer/core.txt.61 Thanks for you work Henri Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: loader not working with GPT and LOADER_ZFS_SUPPORT
MFC'd in 192969
On Wed, May 27, 2009 at 3:31 PM, Artis Caune artis.ca...@gmail.com wrote:
2009/5/28 Lorenzo Perone lopez.on.the.li...@yellowspace.net:
Hi, I'm a bit confused:
I can't find this change (rev 185095) in the stable log, yet stable has some
other
recent changes related to the current posts (in turn commited also to
head)...
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/libi386/biosdisk.c?view=log
http://svn.freebsd.org/viewvc/base/stable/7/sys/boot/i386/libi386/biosdisk.c?view=log
maybe I'm misunderstanding how things eventually get ingto -stable,
however, which revision to use now for a peaceful world boot? :)
I'll go for the -head version for my next try..
It's not merged to stable yet. You should apply r185095 diff by hand.
Just edit sys/boot/i386/libi386/biosdisk.c and change:
--- sys/boot/i386/libi386/biosdisk.c (revision 192872)
+++ sys/boot/i386/libi386/biosdisk.c (working copy)
@@ -996,8 +996,10 @@
od-od_boff = gp-gp_start;
out:
- if (error)
+ if (error) {
free(od-od_partitions);
+ od-od_flags = ~BD_GPTOK;
+ }
return (error);
}
@@ -1088,7 +1090,7 @@
switch(rw){
case F_READ:
- DEBUG(read %d from %d to %p, blks, dblk, buf);
+ DEBUG(read %d from %lld to %p, blks, dblk, buf);
if (blks bd_read(od, dblk, blks, buf)) {
DEBUG(read error);
--
Artis Caune
Everything should be made as simple as possible, but not simpler.
--
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.
Edmund Burke
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads down
On Wed, May 27, 2009 at 11:04 AM, Artem Belevich fbsdl...@src.cx wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. --Artem Adding to rw_init looks fine, but I'd rather find out why owner isn't NULL when the calling convention expects it. Getting a backtrace from where the assert is hit would be helpful. -Kip On Wed, May 27, 2009 at 3:00 AM, Henri Hennebert h...@restart.be wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy km...@freebsd.org wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. No a real problem but maybe worth mentioning: on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 15:37:48 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 [r...@morzine ~]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 Assertion failed: (?Ąuč? ėŪ¨´), function mp-m_owner == NULL, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Abort trap: 6 and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 [r...@avoriaz ~]# zdb rpool version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 Segmentation fault: 11 By the way, to help prepare a boot/root pool does a utility to display the content of zpool.cache exist ? Henri Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: NFS on ZFS
The flags checks are too strict. File a PR. I'll fix it when I get to it. Sorrry. -Kip On Wed, May 27, 2009 at 7:24 PM, Mike Andrews mandr...@bit0.com wrote: On Tue, 26 May 2009, Mike Andrews wrote: Takahashi Yoshihiro wrote: Today's stable has a problem creating a new file via NFS on ZFS. On the NFS server, there is no problem. % cd /ZFS % mktemp hoge hoge % ls -l hoge -rw--- 1 nyan nyan 0 5 26 19:09 hoge But it's a problem on the NFS client. # mount server:/ZFS /ZFS % cd /ZFS % mktemp hoge mktemp: mkstemp failed on hoge: Input/output error % ls -l hoge -- 1 nyan wheel 0 5 26 19:09 hoge The file has a wrong permission. This problem is only on stable, current has no problem. I'm seeing this too. It seems so far to be limited to mkstemp() -- just copying files normally works. For example /usr/bin/install -S fails, without -S works, if the target is an NFS+ZFS volume. Anyone? I've verified that if the NFS server uses UFS2, mkstemp() from an NFS client to the server works fine, but if the NFS server uses ZFS, the NFS server returns EIO after creating a file with 000 permissions. In addition to breaking /usr/bin/install -S, it also breaks rsync over NFS. I don't yet know if it matters whether the on-disk format is ZFS v6 vs v13. -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads down
On Wed, May 27, 2009 at 1:18 PM, Artem Belevich fbsdl...@src.cx wrote: Did you by any chance do that from single-user mode? ZFS seems to rely on hostid being set. Try running /etc/rc.d/hostid start and then re-try your zfs commands. Yup. Your hostuuid has to match that in the pool. Cheers, Kip --Artem On Wed, May 27, 2009 at 1:06 PM, Henri Hennebert h...@restart.be wrote: Artem Belevich wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. The patch is ok for stable. now I get for the pool with my root: [r...@morzine libzpool]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 WARNING: pool 'rpool' could not be loaded as it was last accessed by another system (host: unset hostid: 0x8a08f344). See: http://www.sun.com/msg/ZFS-8000-EY zdb: can't open rpool: No such file or directory But rpool have been used for many boot now - strange ... Thanks for your patch and time Henri --Artem On Wed, May 27, 2009 at 3:00 AM, Henri Hennebert h...@restart.be wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy km...@freebsd.org wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. No a real problem but maybe worth mentioning: on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 15:37:48 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 [r...@morzine ~]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 Assertion failed: (?Ąuč? ėŪ¨´), function mp-m_owner == NULL, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Abort trap: 6 and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 [r...@avoriaz ~]# zdb rpool version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 Segmentation fault: 11 By the way, to help
Re: ZFS MFC heads down
I haven't looked at the panic yet, but adding a USB quirk (no SYNCHRONIZE_CACHE) would certainly reduce the noise in your logs. -Kip On Mon, May 25, 2009 at 4:16 AM, Henri Hennebert h...@restart.be wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy km...@freebsd.org wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I get a panic: panic: solaris assert: 0 == dmu_read(os, lr-lr_foid, off, dlen, buf), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 991 during `make -s DESTDIR=/kingston installworld` kingston is a pool on a USB stick with GPT partitions more info at : http://verbier.restart.be/xfer/core.txt.60 Thanks for your work Henri Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS hanging at kernel boot now, but didn't before... (Re: ZFS MFC heads up)
Motin is your best bet in tracking down ATA problems. Cheers, Kip On Fri, May 22, 2009 at 10:40 AM, Joe Karthauser j...@freebsd.org wrote: Hi Kip, I seriously don't understand what has happened. If I boot kernel.old I still get the same problem. Very confusing. :(. Joe on 21/05/2009 19:28 Kip Macy said the following: I have no idea what is happening. I think our best bet is having someone with insight into ATA provide us with help in adding diagnostics. Sorry for the trouble. Perhaps you can just roll back to 7.2 for now. Cheers, Kip On Thu, May 21, 2009 at 10:50 AM, Joe Karthauserj...@freebsd.org wrote: Hmm, I've had a bit of a miserable afternoon trying to fight my RELENG_7 server, which now doesn't boot. :(. So, it's a ZRAID2 pool with a ufs/gmirror root partition split over 5 disks (gmirror on 500Mb partition on each of five disks, and zraid2 over the rest of each drive). What I did was to update the userland, and then reboot. I didn't upgrade the kernel (but I've subsequently done that and have the same problem). What happens is that the kernel hangs booting just after displaying a LABEL message or ZFS pool/spool message. I _can_ get it to boot if I boot single user with acpi switched off. When I do that I can manually start zfs, and mount all the partitions. However, one of the disks is missing more on that next. The machine is running a gigabyte motherboard (domestic gamer P35 board, similar to this http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2533, although it might be a DS4 variant). I've got 5 of the 6 sata ports wired to a 5 unit SATA hot swap bay (5 drives vertially mounted into 3 5-1/4 bays kind of thing). Now, because of the gmirror I can boot the system on any disk, or combination of plugged in disks. I should be able to succeed with the kernel probe up to the attempt to mount the root filesystem irrespective of any zfs pool, etc. And, indeed, this has been working fine for about two years. But, now it hangs in the same place no matter what disk I boot on (I've tried every bay). But, without ACPI enabled it does appear to boot ok... what's going on here? Is it possible that the machine has developed a hardware fault? Ok, finally, if I boot with ACPI disabled then one of the disks is missing. If I unplug it I get a disconnect message from the ata device, and a reconnect and reinit attempt when I plug it back in, but no device appears on the bus. Usually I can do a 'atacontrol detach sata4; sleep 1; atacontrol attach sata4' and the device reappears. This happens on the other buses, but not on the last one. It's not the disk, because if I swap it into another bay, it comes up and appears on the bus. On the other hand it doesn't appear to be that controller or slow in the drive bay because if I unplug all the over disks the system will boot that disk and get as far as the hang hmm. Is this a consequence of disabling the ACPI? Does anyone have a clue what might be going on? Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads down
Please, fix 4 times repetition of all its content in stable/7/cddl/compat/opensolaris/include/libshare.h. The same: stable/7/sys/cddl/compat/opensolaris/sys/pathname.h stable/7/sys/cddl/compat/opensolaris/sys/kidmap.h stable/7/sys/cddl/compat/opensolaris/sys/file.h fixed by r192523 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads up
Looks like a (corrupted) space management bug. I'll take a closer look this weekend to see if it can be recovered from. -Kip On Thu, May 21, 2009 at 12:50 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Wed, 20 May 2009, Kip Macy wrote: KM I will be MFC'ing the newer ZFS support some time this afternoon. Both KM world and kernel will need to be re-built. Existing pools will KM continue to work without upgrade. KM KM KM If you choose to upgrade a pool to take advantage of new features you KM will no longer be able to use it with sources prior to today. 'zfs KM send/recv' is not expected to inter-operate between different pool KM versions. I updated my poor old moose to the fresh RELENG_7, and panic is still in place: r...@moose:/ar/.bad# ls -la 200807/ total 9089 drwxr-xr-x 3 rscript wheel 4 Nov 5 2008 ./ drwxr-xr-x 3 root wheel 3 Apr 12 21:33 ../ drwxr-xr-x 2 rscript wheel 36 Apr 2 22:12 daily/ -rw-r--r-- 1 rscript wheel 9207828 Aug 1 2008 total.200807 r...@moose:/ar/.bad# ls -la 200807/daily/ panic: avl_find() succeeded inside avl_add() cpuid = 1 Uptime: 1m27s Physical memory: 2039 MB Dumping 247 MB: 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete on the dump: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc05352e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05355f5 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0843b60 in avl_add (tree=Variable tree is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 #4 0xc08b0edf in zap_lockdir (os=0xc55dfa60, obj=6108, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp=0xfc755ba0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:335 #5 0xc08b13af in zap_cursor_retrieve (zc=0xfc755b9c, za=0xfc755a84) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:993 #6 0xc08d6340 in zfs_freebsd_readdir (ap=0xfc755c00) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2156 #7 0xc06de842 in VOP_READDIR_APV (vop=0xc093c560, a=0xfc755c00) at vnode_if.c:1407 #8 0xc05bf88a in kern_getdirentries (td=0xc55c0900, fd=5, buf=0x48215000 Address 0x48215000 out of bounds, count=4096, basep=0xfc755c74) at vnode_if.h:747 #9 0xc05bfab1 in getdirentries (td=0xc55c0900, uap=0xfc755cfc) at /usr/src/sys/kern/vfs_syscalls.c:3785 #10 0xc06d3588 in syscall (frame=0xfc755d38) at /usr/src/sys/i386/i386/trap.c:1090 #11 0xc06b8f40 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #12 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Any other info we need to examine this further? Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads down
I did an update on one of my less critical boxes today. I upgraded the version as well to lucky 13 :) So far so good! I am rsyncing a few hundred GB to it now. One thing I noticed, and not sure if this is normal because of the compression, the capacity shows 31%, df shows 13% Your snapshots are using two thirds of your used capacity. 'df' only knows about the mounted file system. Cheers, Kip 0[offsite]# zpool status pool: tank1 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 errors: No known data errors 0[offsite]# zpool get all tank1 NAME PROPERTY VALUE SOURCE tank1 size 5.44T - tank1 used 1.69T - tank1 available 3.75T - tank1 capacity 31% - tank1 altroot - default tank1 health ONLINE - tank1 guid 7336939736750289319 - tank1 version 13 default tank1 bootfs - default tank1 delegation on default tank1 autoreplace off default tank1 cachefile - default tank1 failmode wait default tank1 listsnapshots off default 0[offsite]# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad6s1a 2026030 406192 1457756 22% / devfs 1 1 0 100% /dev /dev/ad6s1d 2026030 112 1863836 0% /tmp /dev/ad6s1e 40622796 4937888 32435086 13% /usr /dev/ad6s1f 20844174 1258572 17918070 7% /var tank1 3399088000 457597952 2941490048 13% /tank1 ta...@20090510 3391231232 449741184 2941490048 13% /tank1/.zfs/snapshot/20090510 ta...@20090517 3391393408 449903360 2941490048 13% /tank1/.zfs/snapshot/20090517 0[offsite]# 0[offsite]# zfs get all NAME PROPERTY VALUE SOURCE tank1 type filesystem - tank1 creation Fri May 8 13:44 2009 - tank1 used 1.27T - tank1 available 2.74T - tank1 referenced 437G - tank1 compressratio 1.63x - tank1 mounted yes - tank1 quota none default tank1 reservation none default tank1 recordsize 128K default tank1 mountpoint /tank1 default tank1 sharenfs off default tank1 checksum on default tank1 compression on local tank1 atime off local tank1 devices on default tank1 exec on default tank1 setuid on default tank1 readonly off default tank1 jailed off default tank1 snapdir visible local tank1 aclmode groupmask default tank1 aclinherit restricted default tank1 canmount on default tank1 shareiscsi off default tank1 xattr off temporary tank1 copies 1 default tank1 version 1 - tank1 utf8only off - tank1 normalization none - tank1 casesensitivity sensitive - tank1 vscan off default tank1 nbmand off default tank1 sharesmb off default tank1 refquota none default tank1 refreservation none default tank1 primarycache all default tank1 secondarycache all default ta...@20090510 type snapshot - ta...@20090510 creation Sun May 10 12:37 2009 - ta...@20090510 used
ZFS MFC heads up
I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. Cheers, Kip -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads up
On Wed, May 20, 2009 at 3:11 PM, Mike Tancsa m...@sentex.net wrote: At 05:59 PM 5/20/2009, Kip Macy wrote: If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. Hi, Thanks for working on ZFS! Is there a summary of the new features somewhere ? ---Mike Primarily what was in Pawel's commit to HEAD (see below). The following changes have also been brought in: - the recurring deadlock was fixed by deferring vinactive to a dedicated thread - zfs boot for all types now works - kmem now goes up to 512GB so arc is now limited by physmem - the arc now experiences backpressure from the vm (which can be too much - but allows ZFS to work without any tunables on amd64) Revision 185029 - (view) (annotate) - [select for diffs] Modified Mon Nov 17 20:49:29 2008 UTC (6 months ago) by pjd File length: 38244 byte(s) Diff to previous 177698 Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes. This bring huge amount of changes, I'll enumerate only user-visible changes: - Delegated Administration Allows regular users to perform ZFS operations, like file system creation, snapshot creation, etc. - L2ARC Level 2 cache for ZFS - allows to use additional disks for cache. Huge performance improvements mostly for random read of mostly static content. - slog Allow to use additional disks for ZFS Intent Log to speed up operations like fsync(2). - vfs.zfs.super_owner Allows regular users to perform privileged operations on files stored on ZFS file systems owned by him. Very careful with this one. - chflags(2) Not all the flags are supported. This still needs work. - ZFSBoot Support to boot off of ZFS pool. Not finished, AFAIK. Submitted by: dfr - Snapshot properties - New failure modes Before if write requested failed, system paniced. Now one can select from one of three failure modes: - panic - panic on write error - wait - wait for disk to reappear - continue - serve read requests if possible, block write requests - Refquota, refreservation properties Just quota and reservation properties, but don't count space consumed by children file systems, clones and snapshots. - Sparse volumes ZVOLs that don't reserve space in the pool. - External attributes Compatible with extattr(2). - NFSv4-ACLs Not sure about the status, might not be complete yet. Submitted by: trasz - Creation-time properties - Regression tests for zpool(8) command. Obtained from: OpenSolaris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ZFS MFC heads down
On Wed, May 20, 2009 at 2:59 PM, Kip Macy km...@freebsd.org wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS MFC heads down
Not really a problem but a question: Is the v13 on-disk format exactly the same as that used by Solaris/Opensolaris? It is supposed to be. The sources are the same. However, I have not tested interoperability. Does this make it possible to have a ZFS-only dual boot system running FreeBSD-stable and Solaris, with a shared home directory between the two environments? It should be. Has anyone tried anything like this? Google anyone? :-) -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFT: ZFS MFC
Unfortunately not a lot but we can do the following: - Donate some hardware (Fibre Channel HBAs) to the FreeBSD project (paid from my pocket, not my employer's one); - Donate some money (paid from my employer's pocket, if I can demonstrate that this can help us to save big bucks on high-end storage systems); - Detail in a very precise way all the tests that we are doing on ZFS, using the following storage: Apple Xraid, Nexsan Sas/SATAbeast, EMC (waiting for the final configuration) as a contribution to the FreeBSD community. In a few words, please let the community know what we can do in order to make this dream come true. Contributing hardware to the cluster increases the range of platforms that FreeBSD committers can test on. I can't speak to whom or to what to contribute money - that really depends on your perceived needs. 4GB / 8GB qlogic fibre channel support is actually on its way, although I don't know the date. Cheers, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFT: ZFS MFC
Many people are happily running an old pool with the new code. I have done that in a VM and run load over it just to be certain. The tuning still applies to i386. On amd64 vm backpressure works, but may actually be too aggressive - shrinking the ARC in favor of the inactive pages queue. Cheers, Kip On Tue, May 19, 2009 at 12:54 PM, Dimitry Andric dimi...@andric.com wrote: On 2009-05-19 19:41, Pete French wrote: http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 Thanks - am going to gve this a try later. Preseumably if I leave the pool at the revision it is currently on then I can revert back easily ? I'll just repeat what Kip told us, The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. That said, zpool(1M) tells: zpool upgrade [-V version] -a | pool ... Upgrades the given pool to the latest on-disk version. Once this is done, the pool will no longer be accessible on systems running older versions of the software. and later on: -V version Upgrade to the specified version. If the -V flag is not specified, the pool is upgraded to the most recent version. This option can only be used to increase the version number, and only up to the most recent version supported by this software. E.g. you can upgrade pools to ZFS v13, but there's no way back. If you don't upgrade your pool, it should not destroy anything (but don't count on it!), but you won't be able to test any new features either... Also, is this the version which no longer requires any tuning parameters in loader.conf ? That would be extermely interesting! As far as I know, the tuning stuff still applies, especially for i386. On my i386 test VM with 1GB RAM, vm.kmem_size is about 163 MiB without any tuning, while vm.kmem_size_max is about 320 MiB, so you get the warning: ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. So please test, and let us know your findings. :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFT: ZFS MFC
I created a branch for a reason. With all the renames applying a patch is a nightmare. Either use the branch or wait until I do the MFC. Cheers, Kip On Tue, May 19, 2009 at 3:49 PM, Dimitry Andric dimi...@andric.com wrote: On 2009-05-19 23:57, Dmitry Morozovsky wrote: ... but then again, on `build all'' phase, I got === cddl/sbin/zpool (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zpool zpool_main.o zpool_vdev.o zpool_iter.o zpool_util.o -lavl -lzfs -lgeom -lbsdxml -lsbuf -lm -lnvpair -luutil -lutil zpool_main.o(.text+0x61ff): In function `zpool_do_create': : undefined reference to `zfs_allocatable_devs' *** Error code 1 FWIW, I just did a full buildworld, kernel, reboot, installworld dance, there were no errors. You may possibly have some cruft left in obj, or you could zap your src tree and start fresh? :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFT: ZFS MFC
On Tue, May 19, 2009 at 4:00 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Tue, 19 May 2009, Kip Macy wrote: KM I created a branch for a reason. With all the renames applying a patch KM is a nightmare. Either use the branch or wait until I do the MFC. Ah well, Kip, thank you for all of your support. Then, what would you offer for releng_7 users to test your changes? I'm more than happy to test, and I'm ready to be unvolved in some clashes resolved, but... Anyway, thank you for all your efforts you put there! I would recommend that you use the ZFS_MFC branch - it is the same as what will be in RELENG_7 tomorrow afternoon. Cheers, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFT: ZFS MFC
I will if you can reproduce on this branch. A lot has changed between ZFS v7 and ZFS v13. -Kip On Sun, May 17, 2009 at 3:48 AM, Dmitry Morozovsky ma...@rinet.ru wrote: Kip, On Fri, 15 May 2009, Kip Macy wrote: KM I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. KM KM http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ KM KM The standard disclaimers apply. This has only been lightly tested in a KM VM. Please do not use it with data you care about at this time. maybe you have time and ability to investigate my panic: avl_find() succeeded inside avl_add() I reported at 4 Apr? I can even provide you with serial console if it's needed. Thank you in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFT: ZFS MFC
On Sun, May 17, 2009 at 3:19 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Sun, 17 May 2009, Kip Macy wrote: KM I will if you can reproduce on this branch. A lot has changed between KM ZFS v7 and ZFS v13. So, if I understand you correctrly, you wish me to upgrade to the latest sources including RELENG_7 ZFS patches, but do *NOT* upgrade the pool to V13? Hopefully, provided ZFS snapshots work right (they did on my previous tests, and for now I moved the offending directory out of usage, and disabled cron due to daily security find) I can try this tomorrow. I don't know how well V7 will work with the latest sources. Too much has changed for me to support V7. I may create a branch with the MFC against 7.2 if you need to be on a release. Cheers, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RELENG 7.2 with v13 ZFS branch
For those of you who prefer to stay on a release I've created a 7.2 branch with v13 ZFS. http://svn.freebsd.org/base/user/kmacy/releng_7_2_zfs/ -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RFT: ZFS MFC
I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?]
I think most if not all of the gains are from increasing the maximum tcp socket buffer sizes. You might test it out with only those to confirm. -Kip On Thu, Apr 9, 2009 at 3:42 PM, Freddie Cash fjwc...@gmail.com wrote: On Wed, Apr 8, 2009 at 3:55 PM, Antony Mawer fbsd-sta...@mawer.org wrote: Freddie Cash wrote: ... We've also heavily modified /etc/sysctl.conf and upped a bunch of the network-related sysctls. Doing so increased our SSH throughput from ~30 Mbits/sec across all connections to over 90 Mbits/sec per SSH connection. Are you able to share any of these with the list? It would be useful to compare as a lot of these tunings people do individually and it would be good to allow others to test in their environments to see if they help, as well as potentially adding them to the tuning man-page. They're all taken from the HPN-SSH website and various google searches related to HPN-enabled OpenSSH. I don't know exactly what all the different, individual sysctls do, nor whether this is the most optimal setup, but here's the sysctl.conf that we use. This is on 2 systems using a quad-port gigabit NIC where the top two ports are connected via lagg(4) and the bottom two ports are connected via lagg(4), with the two laggX interfaces on separate networks. I did a bunch of scp/sftp transfers of 100 MB files filled with random data pulled from /dev/random between these two boxes tweaking the options one at a time, but didn't do too much in the way of scientific/empirical measurements and comparisons beyond the throughput data that scp/sftp shows. If there are any glaring errors, gotchas, or why would you ever do thats, let me know. :) # General network settings net.isr.direct=1 # Whether to enable Direct Dispatch for netisr # IP options net.inet.ip.forwarding=0 # Whether to enable packet forwarding for NAT/routing net.inet.ip.process_options=0 # Disable processing of IP options (nothing uses this field) net.inet.ip.random_id=1 # Randomise the IP header ID number net.inet.ip.redirect=0 # Whether to allow redirect packets #net.inet.ip.stealth=0 # Whether to appear in traceroute output # ICMP options net.inet.icmp.icmplim=200 # Limit ICMP packets to this many per second net.inet.icmp.drop_redirect=1 # Drop ICMP redirect packets net.inet.icmp.log_redirect=0 # Don't log ICMP redirect packets # TCP options net.inet.tcp.blackhole=1 # Drop packets destined to unused ports net.inet.tcp.inflight.enable=0 # Use automatic TCP window-scaling net.inet.tcp.log_in_vain=0 # Don't log the blackholed packets net.inet.tcp.path_mtu_discovery=1 # Use ICMP type 3 to find the MTU to use net.inet.tcp.recvbuf_max=16777216 # The max size of the receive buffer (16 MB) net.inet.tcp.recvspace=131072 # The initial size in bytes of the receive buffer net.inet.tcp.sack.enable=1 # Enable Selective ACKs net.inet.tcp.sendbuf_max=16777216 # The max size of the send buffer net.inet.tcp.sendspace=131072 # The initial size in bytes of the send buffer net.inet.tcp.syncookies=1 # Enable SYN cookie protection net.inet.tcp.rfc1323=1 # Enable RFC1323 extensions (TCP window scaling) # UDP options net.inet.udp.blackhole=1 # Drop packets destined to unused ports net.inet.udp.checksum=1 # Enable UDP checksums net.inet.udp.log_in_vain=0 # Don't log the blackholed packets net.inet.udp.recvspace=65536 # Size in bytes of the receive buffer # Debug options debug.minidump=1 # Disable the small kernel core dump (only mem in use) debug.mpsafevfs=1 # Enable threaded VFS subsystem # Kernel options kern.coredump=0 # Disable kernel core dumps kern.ipc.maxsockbuf=4194304 # Set the max size of the socket buffers (4 MB) kern.ipc.somaxconn=1024 # Expand the IP listen queue kern.maxvnodes=25 # Bump up the max number of vnodes # PCI bus options hw.pci.enable_msix=1 # Enable Message Signalled Interrupts - Extended hw.pci.enable_msi=1 # Enable Message Signalled Interrupts hw.pci.enable_io_modes=1 # Enable alternate I/O access modes -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke ___ freebsd-stable@freebsd.org mailing list
Re: Driver for Intel 10GbE adapter
see ixgbe(4) On Wed, Feb 11, 2009 at 2:43 PM, Greg Rivers gcr+freebsd-sta...@tharned.org wrote: I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very recent 7.1-STABLE amd64 with GENERIC kernel. I expected the ixbg(4) driver to attach, but it does not. The labels on the card show: INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER 893135 EXPX9502FXSRGP5 001B211170BE 028AD E15728-003 A verbose boot shows the card on the PCI bus, but no driver attaches: pcib11: ACPI PCI-PCI bridge at device 6.0 on pci0 pcib11: domain0 pcib11: secondary bus 23 pcib11: subordinate bus 23 pcib11: I/O decode0x6000-0x6fff pcib11: memory decode 0xfde0-0xfdff pcib11: no prefetched decode pci23: ACPI PCI bus on pcib11 pci23: domain=0, physical bus=23 found- vendor=0x8086, dev=0x10c6, revid=0x01 domain=0, bus=23, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 18 messages in map 0x1c map[10]: type Memory, range 32, base 0xfdfe, size 17, enabled pcib11: requested memory range 0xfdfe-0xfdff: good map[14]: type Memory, range 32, base 0xfdf8, size 18, enabled pcib11: requested memory range 0xfdf8-0xfdfb: good map[18]: type I/O Port, range 32, base 0x6000, size 5, enabled pcib11: requested I/O range 0x6000-0x601f: in range map[1c]: type Memory, range 32, base 0xfdf7, size 14, enabled pcib11: requested memory range 0xfdf7-0xfdf73fff: good pcib11: matched entry for 23.0.INTA pcib11: slot 0 INTA hardwired to IRQ 19 found- vendor=0x8086, dev=0x10c6, revid=0x01 domain=0, bus=23, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 18 messages in map 0x1c map[10]: type Memory, range 32, base 0xfdf4, size 17, enabled pcib11: requested memory range 0xfdf4-0xfdf5: good map[14]: type Memory, range 32, base 0xfdf0, size 18, enabled pcib11: requested memory range 0xfdf0-0xfdf3: good map[18]: type I/O Port, range 32, base 0x6020, size 5, enabled pcib11: requested I/O range 0x6020-0x603f: in range map[1c]: type Memory, range 32, base 0xfdef, size 14, enabled pcib11: requested memory range 0xfdef-0xfdef3fff: good pcib11: matched entry for 23.0.INTB pcib11: slot 0 INTB hardwired to IRQ 16 pci23: network, ethernet at device 0.0 (no driver attached) pci23: network, ethernet at device 0.1 (no driver attached) pciconf shows: no...@pci0:23:0:0: class=0x02 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet no...@pci0:23:0:1: class=0x02 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I thought perhaps it would be a simple matter of adding/updating a card ID in the driver header file, but I see that sys/dev/ixgb/ixgb_ids.h already contains an entry for 0xA15F as listed above. Does anyone have experience with this card or know how to get it to probe and attach? Thanks! -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kern.ipc.maxpipekva exceeded; see tuning(7)
I don't know off hand how you could end up with that many pipes. Nonetheless, sys_pipe.c has a good explanation of what that does and how pipe sizing works. -Kip On Thu, Nov 13, 2008 at 9:37 PM, Bruce Simpson [EMAIL PROTECTED] wrote: I just got lots and lots of this: kern.ipc.maxpipekva exceeded; see tuning(7) However, tuning(7) on my system has no information about this tunable whatsoever. anglepoise:~ % uname -a FreeBSD anglepoise.lon.incunabulum.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Tue Nov 4 15:40:44 GMT 2008 [EMAIL PROTECTED]:/home/obj/usr/src/sys/ANGLEPOISE7 amd64 anglepoise:~ % sysctl kern.ipc.maxpipekva kern.ipc.maxpipekva: 20971520 I was running a couple of copies of synergys at the time. After killing them, all seems fine, however this was causing most binaries on the system to error out with ENOMEM. Any ideas? BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is FreeBSD a suitable choice for a MacBook?
You sound as if you just got the machine and haven't given MacOS X a chance. Give MacOS X a chance. Download (if its not on your MacOS X install DVD) X Code, and Apple X11. X11 is barely usable under Leopard. Apps crash regularly and full-screen doesn't work. He may simply want to be able to boot in to FreeBSD as well. Cheers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sun4v arch
Hi Peter, There really isn't any magic to bringing up a port. You compile it, install it, and then run it until it breaks. Once it breaks you spend a lot of time instrumenting the code to track down what went wrong. Then, depending on the amount of technical insight you have in to the issue, you go through a number of iterations until it is fixed. Fixing the pmap issue is just (notice the quotes) a matter of tracking down the missing TLB shootdowns. For anyone who chooses pick this up it will be very educational. It will also be very time consuming. -Kip On Sat, Aug 23, 2008 at 9:23 PM, Peter Jeremy [EMAIL PROTECTED] wrote: On 2008-Aug-23 22:40:55 -0500, Mark Linimon [EMAIL PROTECTED] wrote: My understanding is the the port is in a pre-alpha state due to unfinished work in the kernel, so expecting there to be any userbase is premature. Except that the wiki gives a far more optimistic picture. All of our 'new' architectures which are in this state have so few non- developer users that there is hardly any reason to submit PRs. AFAICT the active developers already know what's missing :-) That makes it very difficult for someone outside that group to come up to speed. I can't find anything in the freebsd-sun4v archvies. I was hoping that there would be a list somewhere of what state various subsystems were in and what remained to be done. wiki.freebsd.org sounds like the ideal place for this. On 2008-Aug-23 20:39:29 -0700, Garrett Cooper [EMAIL PROTECTED] wrote: Maybe some time should be spent looking at stuff from NetBSD to see whether or not they've solved some already critical porting pieces that FreeBSD lacks in this architecture? I can't find anything that suggests NetBSD runs on sun4v. Their sparc64 port only covers the US-I/II families and there's no mention of sun4v. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sun4v arch
On Sat, Aug 23, 2008 at 9:34 PM, Sevan / Venture37 [EMAIL PROTECTED] wrote: I can't find anything that suggests NetBSD runs on sun4v. Their sparc64 port only covers the US-I/II families and there's no mention of sun4v. OpenBSD/sparc64 supports the sun4v architecture has done for a while. Heh. The bugs that FreeBSD exhibits on sun4v won't be hit on UP and are much less prevalent without preemption. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the future of sun4v
Well, let's see what architecture the upcoming Rock CPUs are; judging their feature list they appear to be a continuation of the Fujitsu sun4u line rather than a successor of UST1/2 :) That is not what I've heard. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
the future of sun4v
I apologise for cross-posting. I believe that there is a general expectation by freebsd users and developers that unsupported code should not be in CVS. Although sun4v is a very interesting platform for developers doing SMP work, I simply do not have the time or energy to maintain it. If someone else would like to step up and try his hand I would be supportive of his efforts. In the likely event that no one steps forward by the time that 7.1 is released I will ask that it be moved to the Attic. Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
got it On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa [EMAIL PROTECTED] wrote: At 10:24 AM 8/18/2008, John Baldwin wrote: Edit src/sys/conf/files Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_subr.c Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_syncache.c Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy Edit src/sys/netinet/tcp_syncache.h Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_usrreq.c Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy These are changes by Kip to do TCP offload (181013, 181014). Given that, I think the likeliest changes to cause this are the TCP offload changes. Note that Kip later MFC'd this change which changed ARP stuff: However, I would stary by narrowing it down to see if Kip's commits cause the change. As I dont have the skills to unwind Robert's patch, I have done the following csup with date=2008.08.01.00.00.00 which shows the problem. I then manually grabbed the prior versions of the above files 0[smtp2]% ident src/sys/conf/files src/sys/conf/files: $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb Exp $ 0[smtp2]% ident src/sys/netinet/tcp_subr.c src/sys/netinet/tcp_subr.c: $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident src/sys/netinet/tcp_syncache.c src/sys/netinet/tcp_syncache.c: $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident src/sys/netinet/tcp_syncache.h src/sys/netinet/tcp_syncache.h: $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 silby Exp $ 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c src/sys/netinet/tcp_usrreq.c: $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 11:50:00 rwatson Exp $ 0[smtp2]% All is OK. So it looks like the above introduced the bug. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
Hi Mike, Could you please check that this doesn't happen on HEAD as well? This same code has been in 8 since shortly after the branch. Thanks, Kip On Mon, Aug 18, 2008 at 10:14 AM, Mike Tancsa [EMAIL PROTECTED] wrote: At 12:55 PM 8/18/2008, Kip Macy wrote: got it Thanks. The problem manifests itself soon after boot. There is nothing special about the box, it has 2 em network interfaces doing a lot of sendmail as well as local recursive DNS for itself and a few other sendmail boxes and also talks to a cluster of spam / virus scanning machines over tcp and UDP. ---Mike On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa [EMAIL PROTECTED] wrote: At 10:24 AM 8/18/2008, John Baldwin wrote: Edit src/sys/conf/files Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_subr.c Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_syncache.c Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy Edit src/sys/netinet/tcp_syncache.h Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_usrreq.c Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy These are changes by Kip to do TCP offload (181013, 181014). Given that, I think the likeliest changes to cause this are the TCP offload changes. Note that Kip later MFC'd this change which changed ARP stuff: However, I would stary by narrowing it down to see if Kip's commits cause the change. As I dont have the skills to unwind Robert's patch, I have done the following csup with date=2008.08.01.00.00.00 which shows the problem. I then manually grabbed the prior versions of the above files 0[smtp2]% ident src/sys/conf/files src/sys/conf/files: $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb Exp $ 0[smtp2]% ident src/sys/netinet/tcp_subr.c src/sys/netinet/tcp_subr.c: $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident src/sys/netinet/tcp_syncache.c src/sys/netinet/tcp_syncache.c: $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident src/sys/netinet/tcp_syncache.h src/sys/netinet/tcp_syncache.h: $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 silby Exp $ 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c src/sys/netinet/tcp_usrreq.c: $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 11:50:00 rwatson Exp $ 0[smtp2]% All is OK. So it looks like the above introduced the bug. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
On Mon, Aug 18, 2008 at 3:42 PM, Mike Tancsa [EMAIL PROTECTED] wrote: At 06:32 PM 8/18/2008, Kip Macy wrote: Hi Mike, Could you please check that this doesn't happen on HEAD as well? This same code has been in 8 since shortly after the branch. Hi, I dont have any easy way to migrate the box to HEAD and then back. Can I just boot a kernel from HEAD ? Yes. That should work fine. A couple of utilities won't work (ps and netstat) but other than that it should be testable. I noticed on the commits prior to some of those files, (e.g. http://lists.freebsd.org/pipermail/cvs-src/2008-July/093223.html ) MFC an ABI compatible implementation of Multiple routing tables. Is it possible your commit makes some assumptions that dont jive with that? It is indeed possible. That would make the most sense. Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0 + Xen 3.1 + HVM: Success!
I'd just like to observe that due to bugs in their real-mode emulation (only required on intel) FreeBSD won't run on Xen 3.1 in HVM on Intel processors. This longstanding issue was finally fixed very recently in the 3.2 branch. -Kip On Fri, Feb 29, 2008 at 3:34 PM, Freddie Cash [EMAIL PROTECTED] wrote: Just thought I'd pass along that I have successfully installed FreeBSD 7.0 into a Xen 3.1 HVM. This one went as smooth as I expected, considering my experience with 6.3. Haven't done any benchmarking or stress testing or port installs or anything. But so far it's working nicely. Here's all the info. If you'd like to see anything else, let me know. Host hardware: Tyan h2000M motherboard 2x AMD Opteron 2200-series CPUs (dual-core) 8 GB ECC DDR2-800 SDRAM 3Ware Escalade 9650SX-12ML PCIe RAID controller 12x 400 GB SATA harddrives in RAID6 with 1 hot spare (4 TB) Host software: Ubuntu Server 7.10 64-bit version Linux kernel 2.6.22 Xen 3.1 LVM partitions for all the virtual machines Xen config file: # Enable hardware virtualisation using HVM kernel = '/usr/lib/xen-ioemu-3.1/boot/hvmloader' device_model= '/usr/lib/xen-ioemu-3.1/bin/qemu-dm' builder = 'hvm' # VM/domain name name= 'freebsd70' # Memory and CPU settings vcpus = '1' memory = '1024' # Disk settings disk= [ 'phy:/dev/xenvol0/freebsd70,ioemu:hda,w', 'file:/home/fcash/freebsd-7.0-i386-cd1.iso,hdc:cdrom,r' ] boot= 'c' # Network settings hostname= 'fbsdvm2.sd73.bc.ca' vif = [ 'type=ioemu, bridge=xenbr3, mac=00:16:3e:00:00:03' ] dhcp= '1' # Graphics settings sdl = '0' vnc = '1' vncviewer = '1' # Other settings pae = '0' # Whether to enable PAE for 32-bit VMs acpi= '0' # Whether to enable ACPI for guests localtime = '1' # Whether system clock is set to local time or UTC # Start/stop settings on_poweroff = 'destroy' on_reboot = 'destroy' on_crash= 'destroy' FreeBSD 7.0 dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Dual-Core AMD Opteron(tm) Processor 2220 (2793.13-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x40f13 Stepping = 3 Features=0x789fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x2001SSE3,CX16 AMD Features=0x28400800SYSCALL,MMX+,RDTSCP,LM AMD Features2=0x19LAHF,ExtAPIC,CR8 real memory = 1073717248 (1023 MB) avail memory = 1037139968 (989 MB) MPTable: _HVMCPU_ XEN ioapic0: Changing APIC ID to 1 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 19:59:27) cpu0 on motherboard pcib0: Host to PCI bridge pcibus 0 on motherboard pir0: PCI Interrupt Routing Table: 6 Entries on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] vgapci0: VGA-compatible display mem 0xf000-0xf1ff,0xf200-0xf2000fff at device 2.0 on pci0 pci0: unknown at device 3.0 (no driver attached) re0: RealTek 8139C+ 10/100BaseTX port 0xc200-0xc2ff mem 0xf400-0xf4ff irq 5 at device 4.0 on pci0 miibus0: MII bus on re0 rlphy0: RealTek internal media interface PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 00:16:3e:00:00:03 re0: [FILTER] pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc-0xc7fff pnpid ORM on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port
Re: another: supervisor read, page not present
What workload, if any, was running at the time?
Have you run memtest on the machine to confirm that there are no memory issues?
-Kip
2008/2/12 Mikhail T. [EMAIL PROTECTED]:
The kernel is from:
FreeBSD 6.3-STABLE #0: Thu Feb 7 ... amd64
The crash:
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xffe3ffe3e010
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x80414d98
stack pointer = 0x10:0xd62714d0
frame pointer = 0x10:0xff016e6ce9e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 10919 (kdeinit)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 19h29m22s
Dumping 4095 MB (3 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 (CTRL-C to abort)
(CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort)
1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487
1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247
1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007
991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703
687 671 655 639 623 607 591 575 559 543 527 511 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 ... ok
chunk 2: 2048MB (524288 pages) 2033 2017 2001 1985 1969 1953 1937 1921 1905
1889 1873 1857 1841 1825 1809 1793 1777 1761 1745 1729 1713 1697 1681 1665
1649 1633 1617 1601 1585 1569 1553 1537 1521 1505 1489 1473 1457 1441 1425
1409 1393 1377 1361 1345 1329 1313 1297 1281 1265 1249 1233 1217 1201 1185
1169 1153 1137 1121 1105 1089 1073 1057 1041 1025 1009 993 977 961 945 929
913 897 881 865 849 833 817 801 785 769 753 737 721 705 689 673 657 641 625
609 593 577 561 545 529 513 497 481 465 449 433 417 401 385 369 353 337 321
305 289 273 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 1
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 amd64-marcel-freebsd...
(kgdb) #0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x802ba757 in boot (howto=260)
at ../../../kern/kern_shutdown.c:409
#3 0x802badf1 in panic (
fmt=0xff013c235be0 X\223і[EMAIL PROTECTED])
at ../../../kern/kern_shutdown.c:565
#4 0x8041e31f in trap_fatal (frame=0xff013c235be0,
eva=18446742979543995224) at ../../../amd64/amd64/trap.c:669
#5 0x8041e69c in trap_pfault (frame=0xd6271420, usermode=0)
at ../../../amd64/amd64/trap.c:580
#6 0x8041e953 in trap (frame=
{tf_rdi = -1099511627776, tf_rsi = 16386, tf_rdx = -120260927488,
tf_rcx = 4503599627366400, tf_r8 = 0, tf_r9 = 5, tf_rax = -120260927472,
tf_rbx = 0, tf_rbp = -1093364028960, tf_r10 = 0, tf_r11 = 1, tf_r12 =
34365251584, tf_r13 = -1093364028960, tf_r14 = -1093237757744, tf_r15 = 5,
tf_trapno = 12, tf_addr = -120260927472, tf_flags = 0, tf_err = 0, tf_rip =
-2143203944, tf_cs = 8, tf_rflags = 66178, tf_rsp = -702081824, tf_ss = 0})
at ../../../amd64/amd64/trap.c:353
#7 0x8040456b in calltrap () at ../../../amd64/amd64/exception.S:168
#8 0x80414d98 in pmap_enter_quick_locked (pmap=0xff016e6ce9e0,
va=34365251584, m=0xff0175f3a8d0, prot=5 '\005', mpte=0x0)
at ../../../amd64/amd64/pmap.c:2298
#9 0x80414fdf in pmap_enter_object (pmap=0xff016e6ce9e0,
start=34365251584, end=18446743953448624128, m_start=0xff0175f3a8d0,
prot=5 '\005') at ../../../amd64/amd64/pmap.c:2235
#10 0x803ee67d in vm_map_pmap_enter (map=0xff016e6ce880,
addr=34365251584, prot=5 '\005', object=0xff0174b899a0,
pindex=18446742980345522304, size=18446742980472635672, flags=0)
at ../../../vm/vm_map.c:1539
#11 0x803ee9e4 in vm_map_insert (map=0xff016e6ce880,
object=0xff0174b899a0, offset=0, start=34365251584, end=34365411328,
prot=5 '\005', max=7 '\a', cow=0) at ../../../vm/vm_map.c:1069
#12 0x8027f646 in elf64_map_insert (map=0xff016e6ce880,
object=0xff0174b899a0, offset=0, start=34365251584, end=34365411328,
prot=5 '\005', cow=-1843184) at ../../../kern/imgact_elf.c:327
#13 0x8027f74f in
Re: RELENG_7_0: KVA_PAGES=375, BTX halted
Read the comment in pmap.h: /* * Size of Kernel address space. This is the number of page table pages * (4MB each) to use for the kernel. 256 pages == 1 Gigabyte. * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). */ #ifndef KVA_PAGES #ifdef PAE #define KVA_PAGES 512 #else #define KVA_PAGES 256 #endif #endif On Jan 14, 2008 1:23 PM, Boris Samorodov [EMAIL PROTECTED] wrote: Hello, can you tell me which value may be used for KVA_PAGES? If I use KVA_PAGES=360, the system boots. If I use KVA_PAGES=375, the system halts at BTX stage: ftp://ftp.ipt.ru/pub/images/btx_halted/img014.jpg The kernel is GENERIC + SCHED_ULE, some IPFWIREWALL, etc. - localhost%% uname -a FreeBSD bb.ipt.ru 7.0-RC1 FreeBSD 7.0-RC1 #7: Fri Jan 11 20:53:40 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GG i386 localhost% dmesg | head -22 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RC1 #7: Fri Jan 11 20:53:40 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BB Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2405.47-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 3489136640 (3327 MB) avail memory = 3408564224 (3250 MB) ACPI APIC Table: A_M_I_ OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 - WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: RELENG_7_0: KVA_PAGES=375, BTX halted
On Jan 14, 2008 1:42 PM, Peter Wemm [EMAIL PROTECTED] wrote: Kip, do you think a CTASSERT might be in order? Good idea. Your patch or mine? :-) -Kip On Jan 14, 2008 1:27 PM, Kip Macy [EMAIL PROTECTED] wrote: Read the comment in pmap.h: /* * Size of Kernel address space. This is the number of page table pages * (4MB each) to use for the kernel. 256 pages == 1 Gigabyte. * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). */ #ifndef KVA_PAGES #ifdef PAE #define KVA_PAGES 512 #else #define KVA_PAGES 256 #endif #endif On Jan 14, 2008 1:23 PM, Boris Samorodov [EMAIL PROTECTED] wrote: Hello, can you tell me which value may be used for KVA_PAGES? If I use KVA_PAGES=360, the system boots. If I use KVA_PAGES=375, the system halts at BTX stage: ftp://ftp.ipt.ru/pub/images/btx_halted/img014.jpg The kernel is GENERIC + SCHED_ULE, some IPFWIREWALL, etc. - localhost%% uname -a FreeBSD bb.ipt.ru 7.0-RC1 FreeBSD 7.0-RC1 #7: Fri Jan 11 20:53:40 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GG i386 localhost% dmesg | head -22 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RC1 #7: Fri Jan 11 20:53:40 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BB Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2405.47-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 3489136640 (3327 MB) avail memory = 3408564224 (3250 MB) ACPI APIC Table: A_M_I_ OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 - WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance!
Are you sure that the settitle call is disabled on FreeBSD?
On 12/20/07, Krassimir Slavchev [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have read all related threads about performance problems with multi
core systems but still have no idea what to do to make thinks better.
Below are results of testing postgresql on HP DL380G5 using sysbench.
The results are comparable to:
http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
but the same tests running on the same hardware using Linux (kernel
2.6.18-53.1.4.el5 SMP x86_64) are very different.
PostgreSQL is tuned equal.
dmesg:
...
CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz
K8-class CPU)
Origin = GenuineIntel Id = 0x10676 Stepping = 6
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xce3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,b19
AMD Features=0x2800SYSCALL,LM
AMD Features2=0x1LAHF
Cores per package: 4
usable memory = 8575655936 (8178 MB)
avail memory = 8288337920 (7904 MB)
ACPI APIC Table: HP ProLiant
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
...
test:
sysbench --num-threads=${i} --test=oltp --pgsql-user=bench
- --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0
- --oltp-read-only=on run
tuning:
kern.ipc.shmmax=2147483647
kern.ipc.shmall=524288
kern.ipc.semmsl=512
kern.ipc.semmap=256
kern.ipc.somaxconn=2048
kern.maxfiles=65536
vfs.read_max=32
kern.ipc.semmni=256
kern.ipc.semmns=2048
results:
FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE
#threads#transactions/sec user/system
1 500 7.4%,5.3%
5 199030.9%,23.4%
10 251039.9%,35.0%
20 254944.5%,43.5%
40 192129.8%,59.4%
60 158022.7%,70.6%
80 134118.9%,75.9%
100 122716.5%,79.3%
Linux
#threads#transactions/sec
1 693
5 3539
10 5789
20 5791
40 5661
60 5517
80 5401
100 5319
What can be done to improve these results?
Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHal7hxJBWvpalMpkRAsaiAJ9G3ZoTv6cUbR4yix07TEMf7PKm7gCgoroM
+xvcXkcaFjSTxYfjk5rqMko=
=Tpsq
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [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: hwpmc broken on T2300 Core
FreeBSD's HWPMC doesn't currently support post-P4 processors. -Kip On Dec 8, 2007 7:00 PM, Michael Butler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dmesg reads: Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-BETA4 #42: Sat Dec 8 10:50:45 EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TOSHI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1662.51-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6e8 Stepping = 8 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xc1a9SSE3,MON,VMX,EST,TM2,xTPR,PDCM Cores per package: 2 .. yet hwpmc fails to attach .. pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0xc0632364, 0xc0951a80) error 78 Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHW1pmQv9rrgRC1JIRAst+AKCQJu1Z+7ApXQOyvMK0X3KBC3elmACdFZT8 FpdQKws82SGjZ23FEivOiuA= =9yD4 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
On Nov 19, 2007 9:53 AM, Anish Mistry [EMAIL PROTECTED] wrote: On Wednesday 07 November 2007, Anish Mistry wrote: On Monday 05 November 2007, [LoN]Kamikaze wrote: Marc Fonvieille wrote: On Thu, Oct 18, 2007 at 05:53:47PM +0200, [LoN]Kamikaze wrote: Anish Mistry wrote: On Thursday 18 October 2007, Marc Fonvieille wrote: On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: I just updated to RELENG_7 from 6.2 and I'm running into some really annoying issues with jerky mouse movement and skipping sound. This seems to be similar to: Re: SCHED_4BSD in RELENG_7 disturbs workflow This happens both with 4BSD and ULE. I seems to happen when I'm compiling ports and a new cc/bzip2/sh process fires off (I'm just watching top), I'll get the skip/freezeup. [...] Using ULE and UP kernel (i.e. without SMP etc.) helped a bit the things but it's still very annoying to use firefox during ports build. I see this lag/freeze on all boxes I use with 7.0, but it's true that with a fast machine people can ignore the problem, it's less obvious than with a 1GHz box for example. Yeah, I'm still seeing this behavior. Does anyone have suggestions on debugging? Thanks, I did post the solution in this thread. It has nothing to do with the mouse. Does the problem persist for you? It's gone for me, even with moused. Yes, the problem seems to have been fixed. I'm back to kern.hz=1000 and removed FULL_PREEMPTION. No skipping. It looks like I spoke too soon. I've just tried to compile miro and as it was compiling the boost-python dependency I noticed the problem again. Switching kern.hz=100 seems to fix the problem. Can any of the developers in this area reproduce the issue? It's pretty easy to reproduce on my 1.33Ghz Athlon. There is an ithread priority inversion bug that might be causing this. The fix for that should be going in shortly. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hook up idmapd to build in 6-stable?
It was initially brought in by Alfred but I don't think anyone has done much work on NFSv4 on FreeBSD. It would be nice to have. -Kip On Nov 16, 2007 5:31 PM, Adam McDougall [EMAIL PROTECTED] wrote: I am beginning to dabble with NFSv4 client functionality. I noticed idmapd is not built in -stable but it has been in -current since src/sbin/Makefile v. 1.163 (13 months ago). Should it be hooked up to the build? Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: reboot after panic: vm_page_unwire: invalid wire count: 0
Unfortunately, ZERO_COPY_SOCKETs have long been a known source of problems. I think also, when a page is copied as part of COW the new page is unwired (see pmap_copy et al.), this could lead to socow_iodone unwiring after send a page that was not wired. An added issue is that parts of the VM assume that COW and wired are mutually exclusive which the socow code violates. At some point in the near future I may be adding support for doing zero copy send without COW for blocking sockets. The one down side of this approach is that if you have multiple threads in your process it widens the window during which they can stomp on data that you're sending. Nonetheless, this would be a bug in the application code. More complicated would be zero-copy non-COW send on non-blocking sockets as it would require an extension to kevent for completion notification. In the meantime, your best bet is to disable ZERO_COPY_SOCKETS. -Kip On Nov 13, 2007 1:59 PM, Vivek Khera [EMAIL PROTECTED] wrote: On Nov 13, 2007, at 4:50 PM, Vlad GALU wrote: vmio = 1 offset = Unhandled dwarf expression opcode 0x93 (kgdb) Do you happen to have ZERO_COPY_SOCKETS in your kernel config? Yes, I do. Are they known to be bad under certain loads or just in general. I don't have this issue with any other web server running the same kernel config but those are amd64 boxes mostly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: reboot after panic: vm_page_unwire: invalid wire count: 0
Various calls that downgrade permissions or virtually copy a pmap in pmap.c now remove PG_W (and did not 6 months ago). This may be the cause of the regression. It would probably be better (and faster) if the pages were held instead of wired. -Kip On Nov 13, 2007 4:49 PM, Kris Kennaway [EMAIL PROTECTED] wrote: Kip Macy wrote: Unfortunately, ZERO_COPY_SOCKETs have long been a known source of problems. I think also, when a page is copied as part of COW the new page is unwired (see pmap_copy et al.), this could lead to socow_iodone unwiring after send a page that was not wired. An added issue is that parts of the VM assume that COW and wired are mutually exclusive which the socow code violates. At some point in the near future I may be adding support for doing zero copy send without COW for blocking sockets. The one down side of this approach is that if you have multiple threads in your process it widens the window during which they can stomp on data that you're sending. Nonetheless, this would be a bug in the application code. More complicated would be zero-copy non-COW send on non-blocking sockets as it would require an extension to kevent for completion notification. In the meantime, your best bet is to disable ZERO_COPY_SOCKETS. There is a chance this was a recent regression, previously in 7.0 they were believed to work. Kris -Kip On Nov 13, 2007 1:59 PM, Vivek Khera [EMAIL PROTECTED] wrote: On Nov 13, 2007, at 4:50 PM, Vlad GALU wrote: vmio = 1 offset = Unhandled dwarf expression opcode 0x93 (kgdb) Do you happen to have ZERO_COPY_SOCKETS in your kernel config? Yes, I do. Are they known to be bad under certain loads or just in general. I don't have this issue with any other web server running the same kernel config but those are amd64 boxes mostly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: RFC: Evolution of the em driver
Jack, you should know by now that we're not Linux. All we care about is that you not break the code that we rely on. I'm still slightly embarrassed when I explain to people that I build if_em as a module because em0 doesn't come up sometimes due to a race condition on initialization, so I need to be able to re-load the driver. We're happy that you're keeping support for Intel's hardware up to date on FreeBSD. -Kip On 10/29/07, Jack Vogel [EMAIL PROTECTED] wrote: I have an important decision to make and I thought rather than just make it and spring it on you I'd present the issues and see what opinions were. Our newer hardware uses new features that, more and more, require parallel code paths in the driver. For instance, the 82575 (Zoar) uses what are called 'advanced descriptors', this means different TX path. The 7.0 em driver has this support in it, it just uses a function pointer to handle it. When I add in multiqueue/RSS support it will add even more code that functions this way. What the Linux team did was to split the newer code into a standalone driver, they call it 'igb'. I had originally resisted doing this, but with the development I have been working on the past month I am starting to wonder if it might not be best to follow them. I see 3 possibilities and I'd like feedback, which would you prefer if you have a preference and why. First, keep the driver as is and just live with multiple code paths and features, possibly #ifdef'ed as they appear. Second, split the driver as Linux has into em and igb. The added question then is how to split it, Linux made the line the use of advanced descriptors, so Zoar and after, but I could also see a case for having everything PCI-E/MSI capable being in the new driver. Third, sort of a half-way approach, split up code but not the driver, in other words offer different source files that can be compiled into the driver, so you could have the one big jumbo driver with all in there, or one that will only work with a subset of adapters. This one would probably be the most work, because its a new approach. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: All routes to freebsd are dead
The machine is down. Don't know why yet. -Kip On 10/3/07, Chris H. [EMAIL PROTECTED] wrote: Greetings, Lately I've been finding it difficult, to impossible to reach freebsd.org. (hope this message makes it) At any rate, no matter my location; all routes to freebsd.org appear to be dead. From my home base, the route to freebsd.org appears to be provided by Yahoo # traceroute www.freebsd.org ... 8 ix-6-2.core3.PDI-PaloAlto.Teleglobe.net (207.45.213.130) 101.882 ms 101.642 ms 122.385 ms 9 g-0-0-0-p150.msr2.sp1.yahoo.com (216.115.107.73) 103.554 ms g-1-0-0-p140.msr1.sp1.yahoo.com (216.115.107.53) 101.487 ms g-1-0-0-p150.msr2.sp1.yahoo.com (216.115.107.77) 103.430 ms 10 ge-1-47.bas-b2.sp1.yahoo.com (209.131.32.53) 102.561 ms ge-1-41.bas-b1.sp1.yahoo.com (209.131.32.25) 103.646 ms 102.476 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * # From my end, it seems Yahoo is doing freebsd.org a great disservice. Bouncing the routers and switches here have no (positive) affect. Nor does dumping caches, and restarting the nameservers. I noticed earlier on, someone else mentioning troubles connecting to freebsd.org. Can anyone shed any light on this? Thank you for all your time and consideration. --Chris -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: Adobe flash media server compatibility?
You're obviously going to have to modify the install scripts to recognize FreeBSD in addition to RHEL3 RHEL4. When I tried it on -CURRENT there was some symbol versioning issue so I just installed it in a CentOS VM instead (its not for me and its only being used for development). You'll probably need to grab a library or two but with linux emulation it should just work, if it does not its a bug in linux support and needs to be fixed. The only Linux app that I know of that doesn't work is the linux-jdk. -Kip On 8/14/07, Albert Wong [EMAIL PROTECTED] wrote: Is it possible to use Adobe Flash Media Server on FreeBSD? It appears as if Adobe Flash Media Server is only compatible with Red Hat, but I read somewhere that a fix was made so that it could be made compatible with Ubuntu. Is there similar fix for FreeBSD? Thanks for your thoughts. Albert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: call for ALTQ users
Expanding the net a bit. -- Forwarded message -- From: Kip Macy [EMAIL PROTECTED] Date: Jul 28, 2007 2:03 PM Subject: call for ALTQ users To: freebsd-net [EMAIL PROTECTED] I'm looking at extending ifnet to support multiple tx queues. It appears that this will inevitably interact with ALTQ. I don't know anyone using ALTQ so I need users to raise their hands to eventually test prospective changes. Thanks. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: call for ALTQ users
On 7/28/07, Alexey Karagodov [EMAIL PROTECTED] wrote: how can i help you? I'd like to understand how ALTQ is being used currently. Are there users using it on high bandwidth interfaces? As currently implemented it would force serialization, increased locking overhead, and potentially loss of locality on cards that support multiple queues (i.e. most 10GigE cards). -Kip 2007/7/29, Kip Macy [EMAIL PROTECTED]: Expanding the net a bit. -- Forwarded message -- From: Kip Macy [EMAIL PROTECTED] Date: Jul 28, 2007 2:03 PM Subject: call for ALTQ users To: freebsd-net [EMAIL PROTECTED] I'm looking at extending ifnet to support multiple tx queues. It appears that this will inevitably interact with ALTQ. I don't know anyone using ALTQ so I need users to raise their hands to eventually test prospective changes. Thanks. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@ freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cxgb mfc is missing cxgb_include.h
Oops - thanks. On 6/17/07, Mike Jakubik [EMAIL PROTECTED] wrote: mkdep -f .depend -a -nostdinc -DCONFIG_CHELSIO_T3_CORE -DDEFAULT_JUMBO -DCONFIG_DEFINED -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/cxgb/../../dev/cxgb -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -I/usr/obj/usr/src/sys/SPAMTOASTER /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_mc5.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_vsc8211.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_vsc7323.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_ael1002.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_mv88e1xxx.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_xgmac.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_t3_hw.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_lro.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_offload.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_l2t.c /usr/src/sys/modules/cxgb/../../dev/cxgb/sys/uipc_mvec.c if_cxgb.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_vsc8211.c:34:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_ael1002.c:34:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_mv88e1xxx.c:34:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_xgmac.c:35:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_t3_hw.c:35:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:76:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:62:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:178:3: #error SGE_NUM_GENBITS must be 1 or 2 /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_lro.c:53:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_offload.c:58:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_l2t.c:53:26: cxgb_include.h: No such file or directory /usr/src/sys/modules/cxgb/../../dev/cxgb/sys/uipc_mvec.c:45:26: cxgb_include.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/cxgb. *** Error code 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: cxgb mfc is missing cxgb_include.h
I don't know. I just deleted dev/cxgb and recreated it from cvs and LINT builds for me. -Kip On 6/17/07, Mike Jakubik [EMAIL PROTECTED] wrote: Kip Macy wrote: Oops - thanks. I've included the file from cvs on my box, however i now get this error while compiling. --- cc -O2 -fno-strict-aliasing -pipe -march=prescott -DCONFIG_CHELSIO_T3_CORE -g -DDEFAULT_JUMBO -DCONFIG_DEFINED -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/cxgb/../../dev/cxgb -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/SPAMTOASTER/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/SPAMTOASTER -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_mc5.c cc -O2 -fno-strict-aliasing -pipe -march=prescott -DCONFIG_CHELSIO_T3_CORE -g -DDEFAULT_JUMBO -DCONFIG_DEFINED -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/cxgb/../../dev/cxgb -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/SPAMTOASTER/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/SPAMTOASTER -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_vsc8211.c In file included from /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_include.h:10, from /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_vsc8211.c:34: /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_offload.h:83: warning: struct l2t_entry declared inside parameter list /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_offload.h:83: warning: its scope is only this definition or declaration, which is probably not what you want *** Error code 1 Stop in /usr/src/sys/modules/cxgb. --- I then noticed that the contents of that file are all commented out, so i tried uncommenting but it fails during the depend stage. --- mkdep -f .depend -a -nostdinc -DCONFIG_CHELSIO_T3_CORE -DDEFAULT_JUMBO -DCONFIG_DEFINED -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/modules/cxgb/../../dev/cxgb -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -I/usr/obj/usr/src/sys/SPAMTOASTER /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_mc5.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_vsc8211.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_vsc7323.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_ael1002.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_mv88e1xxx.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_xgmac.c /usr/src/sys/modules/cxgb/../../dev/cxgb/common/cxgb_t3_hw.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_lro.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_offload.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_l2t.c /usr/src/sys/modules/cxgb/../../dev/cxgb/sys/uipc_mvec.c if_cxgb.c /usr/src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:178:3: #error SGE_NUM_GENBITS must be 1 or 2 mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/cxgb. --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cxgb mfc is missing cxgb_include.h
On 6/17/07, Mike Jakubik [EMAIL PROTECTED] wrote: Kip Macy wrote: I don't know. I just deleted dev/cxgb and recreated it from cvs and LINT builds for me. Re-cvsupped your version from RELENG_6 and all is well now. Good to hear. Thanks. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Plan to MFC new em driver
On 6/6/07, David Christensen [EMAIL PROTECTED] wrote: I have a version of code ready to MFC, the big difference with CURRENT is that TSO is #ifdef'd off until Andre is able to get that back. Is something broken with TSO? I just added TSO support to bce on CURRENT and was planning on MFC'ing to RELENG_6 within the next week. TSO support is not present in RELENG_6. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vnode_pager_putpages errors on 6.2
On 5/29/07, steve [EMAIL PROTECTED] wrote: Howdy! I had this issue on 4.x, which is basically, I have machines that do cgi stuff for customers, and there is a local md device that is used as a tmp. When it fills the machine logs errors vnode_pager_putpages I/O error 28.. and the machine is unresponsive and needs to be power cycled. There is a previous thread on this issue http://atm.tut.fi/list-archive/freebsd-stable/msg19031.html and a subsequent patch for 4.x http://atm.tut.fi/list-archive/freebsd-stable/msg19288.html that I appled to 4.x and it solved the problem. Now that I have upgraded to 6.2, the problem has recurred, but the previous patch is no longer valid. Is there something wrong with the patch/solution given, and is there a solution for 6.2? thanx - steve All the patch does is rate limit error messages to once per second and return VM_PAGER_BAD when there is an error. Constructing a similar patch for 6.2 should be trivial. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mfs and buildworlds on the SunFire x4600
as i've mentioned in my original email, does mfs speed up I/O stuff ? there's been a lot of threads in teh past that a buildworld on mfs increases speed --- tho it might not be the appropriate test for high-end machines (speaking of w/c I just gots a T2000). buildworld on NFS or local disk on the T2000 takes about 1:10 on mfs it takes about 1:04. An improvement, but when you take into account the time taken to copy the files over its a wash. The INTR_FILTER change broke sun4v and I haven't had time to fix it. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Don't buy AMD products (was Re: Xorg and ATI card query.)
Please be very careful. The only real alternative (Intel comes and goes) is Nvidia whose driver is binary-only for i386 (no amd64 support) and has a history for being notoriously buggy. I only buy ATI because of the problems I keep seeing people have with the Nvidia driver. I have a friend who has basically abandoned his dual-head Nvidia card due to recurring issues. -Kip On 3/13/07, Nikolas Britton [EMAIL PROTECTED] wrote: We need to start hounding on AMD to publish the developer documentation for all radeon chipsets. I for one will not buy any AMD or ATI components until they decide to fix the problem. Here's the email address of AMD's president: [EMAIL PROTECTED] Give him your two cents. On 3/12/07, Daniel O'Connor [EMAIL PROTECTED] wrote: On Tuesday 13 March 2007 05:10, Yann Golanski wrote: I have an ATI Radeon X1950 Sapphire and I am trying to get X/FreeBSD working with it. My system is a clean install of FreBSD. I've managed to get VESA to work but cannot get much more than that. There is no open source support for this card (alas). It's VESA or fglrx. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: Xen Dom0, are we making progress?
I know you were working on Xen support in FreeBSD, but web about it (http://www.fsmware.com/xenofreebsd/7.0/STATUS) has one year old info (support planned in FreeBSD 6.1). So is there any progress, or Xen will not be in any near future release? Basically Xen did not mature in the fashion that I anticipated. As far as I can tell it is really only good for server consolidation for large Linux distro vendors. You need to have what amounts to a private branch. The xen developers don't appear to understand the importance of interface versioning. They broke ABI compatibility going from 3.0.2 - 3.0.3 (trivial to fix, but that is not the point). When last I worked on it, they had one branch that was in constant flux and another branch that only received minor bug fixes and was 18 months behind from a functionality standpoint (think 5.x / 4.x). There are numerous other logging / supportability issues that I think are only addressed by the major distros. As it stood 6 months ago, unless you understood the internals of various bits of the code, there was no way of diagnosing failures due to a misconfiguration. This is not to say that it isn't cool technology, but rather that isn't going to be useful for the things I wanted to use it for so my time is being directed elsewhere. If I ever have a need for EC2 I may look at it again. One of the guys who ported FreeBSD to the xbox has expressed interest - so something may yet come of it. I'm happy to provide technical support to an individual who is largely self-sustaining in working on the code. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Don't buy AMD products (was Re: Xorg and ATI card query.)
Please be very careful. The only real alternative (Intel comes and goes) is Nvidia whose driver is binary-only for i386 (no amd64 support) and has a history for being notoriously buggy. I only buy ATI because of the problems I keep seeing people have with the Nvidia driver. I have a friend who has basically abandoned his dual-head Nvidia card due to recurring issues. Hmm... I abandoned ATI GPU because of notoriously buggy issues. I have no problem with my nvidia GPUs (even in dualhead, at the time I tried it). Good data point. I'm not taking sides. What dual head card are you using? I'm ordering the parts for a shuttle box now - if Nvidia works better I'll go with it. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xen Dom0, are we making progress?
On 3/12/07, Ivan Voras [EMAIL PROTECTED] wrote: Nikolas Britton wrote: Free Solaris DVD software kits (Free shipping too): http://www.sun.com/solaris/freemedia Or NetBSD: http://www.netbsd.org/Ports/xen/ Heh, you're still confused about what list your on. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New em patch for 6.2 BETA 3
If you create a patch against -CURRENT I can test on sun4v. The timeouts with em on sun4v are so severe that I have to use the driver from June for any kind of workload. -Kip On 11/3/06, Jack Vogel [EMAIL PROTECTED] wrote: I have been hard at work trying to understand and fix the remaining issues with the em driver. What I have here is a patch that has gotten rid of any issues that I can reproduce. It solves the intermittent watchdogs that have been happening. It also fixes the problem noted with jumbo frame tx I, and re, would very much appreciate any test feedback you can give on this code. I am happy with the changes, I hope these get rid of everyone's issues. Thanks to Gleb and Scott and John for all the help! Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: em network issues
I have a Sun T2000 that I generally run with the em driver from as of July in order to avoid watchdog timeouts. One trivial scenario that reproduces the problem with 100% consistency is running the ghc configure script (a 20kloc shell script) over NFS. As the T2000 doesn't exactly represent typical PC hardware it may not be the most desirable test platform. Nonetheless, let me know if you're interested. Thanks for looking into this issue. -Kip On 10/18/06, Jack Vogel [EMAIL PROTECTED] wrote: I think there may be a few different problems going on with the em driver on 6.2 that are being lumped under the general description of network hangs. In order to solve these I need a reproducible failure, either on a system here at Intel, or someone who is willing to be a remote guinea pig :) I need detailed reports, meaning EXACT system data, if its an OEM box, what model, what addons, a pciconf list, description of the network, and anything special that is connected with the problem occurence. OH, and if you have a 'before and after' situation, then please give driver deltas that worked, and which failed. I know that there are systems out there that have management hardware that can interfere on the network, it grabs certain packets as being 'management' and doesnt pass them on to the OS. Specifically packets for port 623 and 664 get 'eaten' by this hardware. There is a fix for this, you tell the portmapper to not use ports below 665, in particular: sysctl net.inet.ip.portrange.lowlast 665 (default is 600) So, if you have IPMI or AMT hardware, you should try this change and see if it fixes hangs. There is also a hardware eeprom issue on systems with an 82573 type NIC on SOME systems. There is a utility to fix that, if you have a problem, and have that NIC email me and I can send that out to you. Lastly, our Linux crew have long believed that there are lurking issues on some AMD based systems, we have problems with these because we dont have easy access to this hardware (as you can imagine :). But we now have evidence that SOMETIMES completion on transmit descriptors is not being written back, and this causes hangs. They (the linux team) have a modified transmit cleanup algorithm that does not use the DONE bit, instead it just using the head and tail pointers. If I can get a case where someone has this kind of hardware and has hangs AND is willing to test then perhaps I can try coding something similar up. Also, remember to let everyone know if something gets fixed :) Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: em network issues
On Wed, 18 Oct 2006, Jack Vogel wrote: On 10/18/06, Kip Macy [EMAIL PROTECTED] wrote: I have a Sun T2000 that I generally run with the em driver from as of July in order to avoid watchdog timeouts. One trivial scenario that reproduces the problem with 100% consistency is running the ghc configure script (a 20kloc shell script) over NFS. As the T2000 doesn't exactly represent typical PC hardware it may not be the most desirable test platform. Nonetheless, let me know if you're interested. Thanks for looking into this issue. -Kip I'm a bit confused from the way you worded this, do you have watchdogs with em, or you use em to avoid them? I have watchdogs with the current (post vendor update) em driver, but not with an older (pre vendor update) version of it. If you have problems when running NFS then thats a clue, is it TCP or UDP based NFS? I am interested, give me details about the setup please. Its UDP: 192.168.1.100:/usr/flatstor/freebsd/7.x/sparc64 / nfs bg,intr,rw 0 0 192.168.1.100:/usr/flatstor/shared /shared nfs bg,intr,rw,nfsv3 0 0 Running ./configure --help in /shared/ghc-6.4.2/ triggers it 100% consistently. I have one of the engineers in our test organization trying to repro symptoms on a system installed with BETA2, it has shared interrupts between em and usb. Any additional stuff he could run would be helpful. Let me know what else you need. %ifconfig -a em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=18bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4 inet 192.168.1.5 netmask 0xff00 broadcast 192.168.1.255 ether 00:03:ba:d9:20:ae media: Ethernet autoselect (1000baseTX full-duplex) status: active em1: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 options=18bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4 ether 00:03:ba:d9:20:af media: Ethernet autoselect status: no carrier em2: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 options=18bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4 ether 00:03:ba:d9:20:b0 media: Ethernet autoselect status: no carrier em3: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 options=18bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4 ether 00:03:ba:d9:20:b1 media: Ethernet autoselect status: no carrier lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 %pciconf -l [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:2:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:8:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:9:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x02 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:2:0:class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:8:0:class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:9:0:class=0x060400 card=0x0040 chip=0x853210b5 rev=0xaa hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03408086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:0:2:class=0x060400 card=0x0044 chip=0x03418086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:2:0: class=0x060100 card=0x153310b9 chip=0x153310b9 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:6:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x0101ff card=0x chip=0x522910b9 rev=0xc4 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x0c0400 card=0x01001077 chip=0x23121077 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x01 card=0x30f01000 chip=0x00501000 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x02 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x105e108e chip=0x105e8086 rev=0x06 hdr=0x00 %vmstat -i interrupt total rate vec1941: em0 18533 91 Total 18533 91 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and make -j# buildworld usability
Some work is now being done so that -j can be reliably used on 'make buildkernel', but I don't think that has been completed yet. For now, my own opinion is that you're not going to save enough time with -j on buildkernel to justify the amount of time you'll lose if it does not work. That is my answer for today, but I expect -j for buildkernel will be more reliable as time goes on. Depends on the target. I've never had any problems with 'make -j6 buildkernel' when cross-compiling to sun4v from i386. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance 4.x vs. 6.x (was: e: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon)
Please do not feed the trolls. -Kip On Thu, 12 Oct 2006, Danial Thom wrote: --- Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Dan Lukes [EMAIL PROTECTED] (from Thu, 12 Oct 2006 09:43:20 +0200): [moved from security@ to [EMAIL PROTECTED] The main problem is - 6.x is still not competitive replacement for 4.x. I'm NOT speaking about old unsupported hardware - I speaked about performance in some situation and believe in it's stability. You can't be sure that a committer has the resources to setup an environment where he is able to reproduce your performance problems. You on the other hand have hands-on experience with the performance problem. If you are able to setup a -current system (because there are changes which may affect performance already, and it is the place where the nuw stuff will be developt) which exposes the bad behavior, you could make yourself familiar with the pmc framework (http://wiki.freebsd.org/PmcTools, I'm sure jkoshy@ will help if you have questions) and point out the bottlenecks on current@ and/or performance@ (something similar happened for MySQL, and now we have a webpage in the wiki about it). Without such reports, we can't handle the issue. Further discussion about this should happen in performance@ or [EMAIL PROTECTED] Bye, Alexander. Maybe its just time for the entire FreeBSD team to come out of its world of delusion and come to terms with what every real-life user of FreeBSD knows: In how ever many years of development, there is still no good reason to use anything other than FreeBSD 4.x except that 4.x doesn't support a lot of newer harder. There is no performance advantage in real world applications with multiple processors, and the performance is far worse with 1 processor. The right thing to do is to port the SATA support and new NIC support back to 4.x and support both. 4.x is far superior on a Uniprocessor system and FreeBSD-5+ may be an entire re-write away from ever being any good at MP. Come to terms with it, PLEASE, because it is the case and saying otherwise won't change it. My prediction is that a year from now we'll all be using DragonflyBSD and you guys will be looking for a new bunch of beta-test guinea pigs. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to [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: Xen under -STABLE ... ?
There are a couple of people who have expressed interest in the work, but no one is working on it currently. -Kip On 10/3/06, Marc G. Fournier [EMAIL PROTECTED] wrote: I know there is work being done on this for -HEAD, but does anyone know if it will run under -STABLE? I don't see a port for it, so I'm guessing not, but figured I'd ask ... Thx ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: panic: vm_thread_new: kstack allocation failed
I've seen this when running stress2 with a large number of incarnations. Why don't we return an error to the user? -Kip On 9/1/06, Julian Elischer [EMAIL PROTECTED] wrote: Vyacheslav Vovk wrote: can you see how many threads thre are in the system? I think you will have to extract this information frome the zone allocator. I just realised there is no effective limit on kernel threads in the system. probably one could cause this with a fork bomb appoach using forks and thread creation. Unread portion of the kernel message buffer: panic: vm_thread_new: kstack allocation failed cpuid = 3 Uptime: 7d4h30m58s ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: panic: vm_thread_new: kstack allocation failed
On closer inspection this means that we've run out of KVA. In principle it should be handled more gracefully, but the 1GB KVA limitation is really a 32-bit artifact. It might be worth wading through the kernel memory allocations to see if a subsystem has gone beserk. -Kip On 9/1/06, Kip Macy [EMAIL PROTECTED] wrote: I've seen this when running stress2 with a large number of incarnations. Why don't we return an error to the user? -Kip On 9/1/06, Julian Elischer [EMAIL PROTECTED] wrote: Vyacheslav Vovk wrote: can you see how many threads thre are in the system? I think you will have to extract this information frome the zone allocator. I just realised there is no effective limit on kernel threads in the system. probably one could cause this with a fork bomb appoach using forks and thread creation. Unread portion of the kernel message buffer: panic: vm_thread_new: kstack allocation failed cpuid = 3 Uptime: 7d4h30m58s ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: TOP shows above 100% WCPU usage
I've seen with libthr. What libraries are you using? -Kip On Tue, 22 Aug 2006, Jiawei Ye wrote: On 8/16/06, Dan Nelson [EMAIL PROTECTED] wrote: How can mysql use 160%? Is this a reporting bug in top because mysql is threaded? You have multiple CPUs, so a threaded process can theoretically reach 100*ncpus cpu usage. -- Dan Nelson [EMAIL PROTECTED] I am seeing this on a UP system too. last pid: 35355; load averages: 0.36, 0.08, 0.03up 1+12:11:39 12:20:56 205 processes: 3 running, 202 sleeping CPU states: 97.8% user, 0.0% nice, 1.5% system, 0.0% interrupt, 0.7% idle Mem: 122M Active, 52M Inact, 59M Wired, 7808K Cache, 34M Buf, 524K Free Swap: 1024M Total, 40M Used, 984M Free, 3% Inuse PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 35343 www22 40 275M 64620K accept 0:21 271.92% java 767 jabber 1 910 8836K 1284K select 7:07 0.00% perl5.8.8 875 pgsql 1 910 19880K 1748K select 0:20 0.00% postgres 840 vscan 1 40 22892K 18304K accept 0:17 0.00% clamd 4733 www27 40 17428K 3268K kqread 0:10 0.00% httpd -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: Xen / FreeBSD 6.2
I haven't been keeping the xen port up to date. There is an SoC student who is making some progress with it but he is looking more at what is required to make the installer work with it. Making 6.2 work would not be that difficult, but no one is currently working on it. -Kip On Sun, 6 Aug 2006, Nikolas Britton wrote: Will FreeBSD 6.2 support Xen dom0? I have a new Xeon system with VT and I'm chomping at the bit here, considering -CURRENT for a production server... or worse... running Linux to get my fix. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [releng_6 tinderbox] failure on sparc64/sparc64
IIRC, at NetApp -O2 was the default for all builds. I think it is safe to say that the generated code is quite stable. If -O2 allows the compiler to catch errors earlier it should be the default. -Kip On 2/4/06, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : Warner Losh [EMAIL PROTECTED] writes: : Can we not have special flags for tinderbox builds? It make : pre-commit testing a big pita. How about just -O on both head and : in RELENG_6? : : As I have repeatedly pointed out in the past, -O2 catches more bugs : because it enables optimizations which require more extensive coverage : analysis. Then it should be the default, standard flag. : The kernel make files have special magic to disable the parts of -O2 : that are known to be bad because tinderbox uses -O2, despite efforts : in the past to stop the practice. : : The kernel has special magic to disable strict aliasing checks because : certain people regularly commit kernel code which violates C aliasing : rules and refuse to fix it. The userland code does not need these : hacks because I spent a lot of time and effort fixing aliasing bugs in : e.g. libalias. The optimizations are disable because they do not work. It is really that simple. The kernel has lots and lots of these problems, it is true. : Aliasing violations are not trivial matters; they prevent the compiler : from optimizing code which (for instance) accesses structure members : through pointers to the structure. There is a lot of this in the : kernel. I agree. However, I think it is unreasonable to have one set of defaults, then another set that committers are held to. This leads to lots of problems. My bottom line is that as a committer, you are expected to not break the builds with the default flags. The tinderbox runs at a different level, thereby creating the impression that someone has done something wrong when it happens to blow up, when in fact they have not. If -O2 is so good w/o the -fno-strict-alias, then it should be the default so we catch these bugs. I'm not arguing against -O2 because it isn't useful. I'm arguing because it isn't the default. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [releng_6 tinderbox] failure on sparc64/sparc64
Actually, in my tree, 19 files don't compile. In all of the files I've looked at PCPU_SET is the offender. My guess is that the issue could be fixed by passing the type as an argument. On 2/4/06, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Matthew Jacob [EMAIL PROTECTED] writes: a) The tinderbox breakage is being treated as bad as stop ship type of bug rather than being informative as it should be. I feel I got roasted and slammed for what should have been simply a hey- Matt- come fix this please!. Not really. You were roasted and slammed for ignoring repeated tinderbox failures for seven or eight consecutive days. b) It's instantly not obvious to me (being lazy and not having kept all my committer mail in a way I can find) how *I* can do a tinderbox run myself. cd /usr/src/tools/tools/tinderbox make make install man tbmaster c) Similarily, I don't know how to build a cross-build environment. I should, and I bet if grovel around a bit I can find out how to do so. man build DES -- Dag-Erling Smørgrav - [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: who's been smoking crack in freebsd land now ?
--- Jeroen Ruigrok/asmodai [EMAIL PROTECTED] wrote: -On [20020411 15:45], Darren Reed ([EMAIL PROTECTED]) wrote: By definition, /usr/include/sys _IS_ kernel include files. Err, APIs to kernel related interfaces. The kernel uses the files in the compile/KERNEL directory, src/include and directories below src/sys. It does _NOT_ use /usr/include. Which are copied into /usr/include/sys on a worldinstall. -Kip __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: NFS hang with fxp and Network Appliance fileserver
Since you didn't mention seeing this before, is this only on the machine with the fxp driver? Is there any way I could see the logs from both ends? I don't know off hand what could be causing that except to be sitting in a directory that has been deleted out from underneath you. -Kip On Sat, 6 Apr 2002, Aditya wrote: Kip, with v3 TCP mounts I'm getting: Stale NFS file handle. complaints after a few hours of inactivity. I've verified that the filer has not rebooted. Adi On Fri, Apr 05, 2002 at 11:19:39PM -0800, Kip Macy wrote: Okay, I've forced nfs v3 and tcp like this: -3,tcp,ro,intr,nodev,nosuid,noauto and seems to work fine too...so the problem is with fragments on v2 and v3 UDP mounts (I tested both and they had the same hanging behaviour). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: hang at probing devices screen on VAIO505
Thanks to all. I will do that. I was seriously worried that I might have to install Linux. -Kip On Sun, 7 Nov 1999, Jacques Vidrine wrote: On 7 November 1999 at 11:36, Mike Smith [EMAIL PROTECTED] wrote: Turn off the 'memory stick' device in the BIOS setup screen. It appears that on those machines it either lookes like an IDE device, or at least lives in that address range, and gets our probes all in a tizz. Actually sysinstall gets confused when it tries to read its disklabel (which must fail, because there is no memory card in the slot). I think this is brain damage in the VAIO -- it is as if the memory card slot is not a removable device ... But yes, as Mike says, the work around is to disable it during the install. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kern.maxfiles and kern.maxfilesperproc
You are correct -- what one really needs is a per user limit on files -- there may already be something to that effect, although I do not know of it. On Tue, 21 Sep 1999, Bryan Talbot wrote: At 04:23 PM 9/21/99 , Kip Macy wrote: Thanks. Although having maxfiles == maxfilesperproc might make sense for special cases e.g. a machine completely dedicated to one process -- It is dangerous at best for the general case. Any malicious program can make a machine running FreeBSD non-functional. The default should be set with the average user in mind, namely protecting him from himself. -Kip But adjusting maxfilesperproc maxfiles won't protect you from a malicious process or user any more than having maxfilesperproc == maxfiles. Just fork() or run two (or more) processes that open all the file handles. Same result, right? -Bryan = IMPORTANT NOTICE: According to certain suggested versions of the Grand Unified Theory, the primary particles constituting this message may decay to nothingness within the next Four Hundred Million Years. = "I think not!" said Descartes, who promptly disappeared. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: kern.maxfiles and kern.maxfilesperproc
Obviously not from the default settings. Typically limits are in place to protect something from something. This, however, may be an exception. -Kip On Tue, 21 Sep 1999, David Schwartz wrote: Thanks. Although having maxfiles == maxfilesperproc might make sense for special cases e.g. a machine completely dedicated to one process -- It is dangerous at best for the general case. Any malicious program can make a machine running FreeBSD non-functional. The default should be set with the average user in mind, namely protecting him from himself. -Kip These settings have nothing to do with protecting anything from anything else. That's not what they're for. So your argument is interesting but irrelevant. DS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Out of mbuf clusters
You are, as is so often the case, correct. The way you phrase your responses sometimes blinds me, and evidently others, to the complete circumstances. -Kip On 21 Sep 1999, Dag-Erling Smorgrav wrote: Kip Macy [EMAIL PROTECTED] writes: This is in no way a rant against FreeBSD, but rather a rant against the attitude that one needs to know about OS internals to run a lightweight server. Calling what he did to that box "running a lightweight server" is a very very wide stretch of imagination. I haven't seen his CLONE program and therefore can't speak with 100% assurance, but I've run similar experiments against my own servers, so I think I'm entitled to make an educated guess about the behaviour of CLONE. It simulates a worst-case scenario for an IRC server: open hundreds of connections, log on, join a channel, but don't consume the data the server sends. This fills up the server's send queues and exhausts its mbuf pool. Memory consumption is a quadratic function of the number of clones (linear if you just connect without joining a channel). The worst thing about CLONE is that it's neither a realistic simulation of normal everyday IRC traffic (because real IRC clients consume data almost as soon as it is sent, and therefore do not fill up the server's send queues), nor of a typical attack against an IRC server (because a properly-configured IRC server does not allow a large number of connections from the same host, nor does it allow the send queues to fill up, and is therefore practically immune to this kind of attack). This is what mbuf usage looks like on a real-world IRC server with 1800 clients: root@irc ~# netstat -m 2859/9376 mbufs in use: 947 mbufs allocated to data 1912 mbufs allocated to packet headers 180/2466/8192 mbuf clusters in use (current/peak/max) 6104 Kbytes allocated to network (11% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Sun's StarOffice 5.1, again
With their ever-stricter licensing agreements and their ever-less competitive position in the market, it is likely to be some time before the source is released under a usable license. -Kip On Mon, 20 Sep 1999, Chad R. Larson wrote: As I recall, Mike Smith wrote: As I recall, Haobo Yu wrote: http://www.serv.net/~mcglk/staroffice-install.html. It worked for me. Do we know if this cookbook works against 2.2-STABLE? We know it definitely will not. You _may_ have some luck running WordPerfect on 2.2, since it is a much kinder app, but not StarOffice. I've got WordPerfect 8 running now. I bought two copies (one for the office, one for home) of the StarOffice CD-ROM from the Sun Web site ($9.95 each) and loaded the Windows version on a Win98 machine at home. I loaded the Solaris SPARC version on an E450 at work. I'm just shooting for universal deployment. I suppose the POSIX kernel stuff would kill me on my 2.2 machines. Anybody sign up for doing the Native FreeBSD port whenever Sun gets around to releasing the sources? -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
file table is full
I am debugging a mail sending program under 3.3-R. My program received a SIGBUS: Too many files open on system - this is odd since I did not have all that many files open and the program itself only had 128 sockets open. When I type sysctl -a after machdep.msgbuf: I get a couple hundred lines of: 3file: table is full 3file: table is full 3file: table is full 3file: table is full 3file: table is full 3file: table is full What is happening here? Thanks. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
kern.maxfiles and kern.maxfilesperproc
Is kern.maxfiles the total number of files that can be open on the system at one time? If so it seems very silly that by default it is the same number as kern.maxfilesperproc -- meaning that any process can use up the total number of files available to the system. Thanks. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: testsockbuf.c
Would raising the number of NMBCLUSTERS help? Or would it just postpone the problem? Solaris/x86 also does not have any problems with the code. -Kip On Mon, 9 Aug 1999, Marc Olzheim wrote: Isn't this a huge problem for ordinary users on a system?? I mean there aren't any user restrictions on sockets right? I imagine there will be some sort of follow up on this exploit? Well, there is a 256k limit per socket of the buffer (I O), try sysctl kern.maxsockbuf and you can limit the number of sockets with the maximum number of filedescriptors per process (ulimit -a), but that's just not safe enough. It seems that the kernel doesn't check wether the space it wants to allocate still exists or not. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
