From doconnor at gsoft.com.au Mon Jun 1 00:10:38 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Jun 1 00:10:46 2009 Subject: buildworld fails with "WITHOUT_CDDL=yes" in src.conf In-Reply-To: <20090531191456.M33035@onet.com.ua> References: <20090531191456.M33035@onet.com.ua> Message-ID: <200906010940.26300.doconnor@gsoft.com.au> On Mon, 1 Jun 2009, Pavel Greenberg wrote: > Hello everybody! > After today's source update I have a problem when doing make > buildworld: > > cc -O2 -fno-strict-aliasing -pipe -march=pentium4 > -DLOADER_NFS_SUPPORT - DBOOT_FORTH > -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/ > i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT > -DLOADER_GPT_SUPPORT -I/usr/ src/sys/boot/i386/loader/../../common > -I. -Wall -I/usr/src/sys/boot/i386/ loader/.. > -I/usr/src/sys/boot/i386/loader/../btx/lib -ffreestanding - > mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno- sse3 -c > /usr/src/sys/boot/i386/loader/../../common/interp_forth.c make: don't > know how to make /usr/obj/usr/src/tmp/usr/lib/libzfs.a. Stop *** > Error code 2 > > Stop in /usr/src/sys/boot/i386. > *** Error code 1 > > Stop in /usr/src/sys/boot. > *** Error code 1 > > Stop in /usr/src/sys. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > In my src.conf I have options > WITHOUT_CDDL= true > WITHOUT_ZFS= true > because I don't use ZFS, my desktop haven't enought resources for it > and I want not to build it. When I updated my OS some weeks ago with > the same src.conf process ended OK. While the above IS a bug it should be pointed out that unless you actually load the ZFS kld it won't use any memory on your system. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090601/696fd64a/attachment.pgp From uqs at spoerlein.net Mon Jun 1 05:45:12 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Mon Jun 1 05:45:19 2009 Subject: ZFS on top of GELI / Intel Atom 330 system In-Reply-To: References: <20090531160533.GF18676@acme.spoerlein.net> Message-ID: <20090601054510.GH18676@acme.spoerlein.net> On Sun, 31.05.2009 at 19:28:51 +0300, Dan Naumov wrote: > Hi > > Since you are suggesting 2 x 8GB USB for a root partition, what is > your experience with read/write speed and lifetime expectation of > modern USB sticks under FreeBSD and why 2 of them, GEOM mirror? Well, my current setup is using an old 2GB CF card, so read/write speeds suck (14 and 7 MB/s, respectively, IIRC), but then again, there are not many actual read/writes on / or /usr for my setup anyway. The 2x 8GB USB sticks I would of course use to gmirror the setup, although I have been told that this is rather excessive. Modern flash media should cope with enough write cycles to get you through a decade. With /var being on GELI+ZFS this point is mood even more, IMHO. A recent 8GB Sandisk U3 stick of mine manages to read/write ~25MB/s (working from memory here), so this is pretty much the maximum USB 2.0 is giving you. Cheers, Ulrich Sp?rlein -- http://www.dubistterrorist.de/ From villa.alberto at gmail.com Mon Jun 1 09:57:49 2009 From: villa.alberto at gmail.com (Alberto Villa) Date: Mon Jun 1 09:57:55 2009 Subject: ZFS booting without partitions (was: ZFS boot on zfs mirror) In-Reply-To: References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> Message-ID: On Thu, May 28, 2009 at 3:58 PM, Lorenzo Perone wrote: > the result is, when choosing the disk with the zfs boot > sectors in it (in my case F5, which goes to ad6), the kernel > is not found. the console shows: > > forth not found > definitions not found > only not found > (the above repeated several times) > > can't load 'kernel' > > and I get thrown to the loader prompt. > lsdev does not show any ZFS devices. same here on 7-stable (csupped yesterday) i've followed the same steps, but i've used gpt as explained in the first mail. the same exact steps worked perfectly on 8-current in virtualbox -- Alberto Villa From hlh at restart.be Mon Jun 1 10:06:24 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Jun 1 10:06:32 2009 Subject: ZFS booting without partitions In-Reply-To: References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> Message-ID: <4A23A81A.5050600@restart.be> Lorenzo Perone wrote: > Hi, > > I tried hard... but without success ;( > > the result is, when choosing the disk with the zfs boot > sectors in it (in my case F5, which goes to ad6), the kernel > is not found. the console shows: > > forth not found > definitions not found > only not found > (the above repeated several times) 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: http://verbier.restart.be/xfer/boot-zfs/ Put this directory somewhere, eg /tmp/boot-zfs and run the script eg: `cd /tmp/boot-zfs && sh -x make_usb_key.sh da6 kingston` good luck Henri > > can't load 'kernel' > > and I get thrown to the loader prompt. > lsdev does not show any ZFS devices. > > Strange thing: if I boot from the other disk, F1, which is my > ad4 containing the normal ufs system I used to make up the other > one, and escape to the loader prompt, lsdev actually sees the > zpool which is on the other disk, and shows: > zfs0: tank > > I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, > but there I get the panic: free: guard1 fail message. > (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) > > Sure I'm doing something wrong, but what...? Is it a problem that > the pool is made out of the second disk only (ad6)? > > Here are my details (note: latest stable and biosdisk.c merged > with changes shown in r185095. no problems in buildworld/kernel): > > > > Machine: p4 4GHz 4 GB RAM (i386) > > Note: the pool has actually a different name (heidi > instead of tank, if this can be of any relevance...), > just using tank here as it's one of the conventions... > > mount (just to show my starting situation) > > /dev/mirror/gm0s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) > /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) > /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) > > gmirror status > Name Status Components > mirror/gm0 DEGRADED ad4 > (ad6 used to be the second disk...) > > echo 'LOADER_ZFS_SUPPORT=yes' >> /etc/make.conf > > cd /usr/src > make buildworld && make buildkernel KERNCONF=HEIDI > make installkernel KERNCONF=HEIDI > mergemaster > make installworld > shutdown -r now > > dd if=/dev/zero of=/dev/ad6 bs=512 count=32 > > zpool create tank ad6 > zfs create tank/usr > zfs create tank/var > zfs create -V 4gb tank/swap > zfs set org.freebsd:swap=on tank/swap > zpool set bootfs=tank tank > > rsync -avx / /tank > rsync -avx /usr/ /tank/usr > rsync -avx /var/ /tank/var > cd /usr/src > make installkernel KERNCONF=HEIDI DESTDIR=/tank > > zpool export tank > > dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 > dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 > > zpool import tank > > zfs set mountpoint=legacy tank > zfs set mountpoint=/usr tank/usr > zfs set mountpoint=/var tank/var > > shutdown -r now ... > > at the 'mbr prompt' I pressed F5 (the second disk, ad6) > .. as written above, loader gets loaded (at this stage > I suppose it's the stuff dd't after block 1024?), > but kernel not found. > > /usr/src/sys/i386/conf/HEIDI: > (among other things...): > options KVA_PAGES=512 > > (/tank)/boot/loader.conf: > vm.kmem_size="1024M" > vm.kmem_size_max="1024M" > vfs.zfs.arc_max="128M" > vfs.zfs.vdev.cache.size="8M" > vfs.root.mountfrom="zfs:tank" > > (/tank)/etc/fstab: > # Device Mountpoint FStype Options Dump Pass# > tank / zfs rw 0 0 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > > > > any help is welcome... don't know where to go from here right now. > > BTW: I can't stop thanking the team for the incredible > pace at which bugs are fixed these days! > > > Regards, > > Lorenzo > > > > On 26.05.2009, at 18:42, George Hartzell wrote: > >> Andriy Gapon writes: >>> on 26/05/2009 19:21 George Hartzell said the following: >>>> Dmitry Morozovsky writes: >>>>> On Tue, 26 May 2009, Mickael MAILLOT wrote: >>>>> >>>>> MM> Hi, >>>>> MM> >>>>> MM> i prefere use zfsboot boot sector, an example is better than a >>>>> long talk: >>>>> MM> >>>>> MM> $ zpool create tank mirror ad4 ad6 >>>>> MM> $ zpool export tank >>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 >>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 >>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 >>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 >>>>> >>>>> s/skeep/skip/ ? ;-) >>>> >>>> What is the reason for copying zfsboot one bit at a time, as opposed >>>> to >>>> >>>> dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 >>> >>> seek=1024 for the second part? and no 'count=1' for it? :-) >>> >>> [Just guessing] Apparently the first block of zfsboot is some form of >>> MBR and the >>> rest is zfs-specific code that goes to magical sector 1024. >> >> Ok, I managed to read the argument to seek as "one block", apparently >> my coffee hasn't hit yet. >> >> I'm still confused about the two parts of zfsboot and what's magical >> about seeking to 1024. >> >> g. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From hlh at restart.be Mon Jun 1 10:22:46 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Jun 1 10:22:58 2009 Subject: /boot/loader can't load kernel if too many pool/devices Message-ID: <4A23ABF2.3070601@restart.be> Hello, During my tests (succesful) to directly boot from ZFS (with zfsboot and gptzfsboot) I encounter the error "can't boot 'kernel'" if too many devices/pools are connected to the machine. In my case: 2 SAS disks with 2 pools 2 SATA disks with 2 pools 1 USB key with one pool `heap` command: Active Allocations: 171/173 536576 bytes reserved 527800 bytes allocated `ls` command: open '/' failed: too many open files If I reboot without the USB key all is OK. If I reboot from the USB key after disconnecting 2 disks all is OK. By the way, the /boot/loader in 7.2-STABLE don't work, complains about forth not found. The previous tests were made with 7.2-STABLE (May 31) with /boot/loader from 8.0-CURRENT. Henri From hlh at restart.be Mon Jun 1 10:27:14 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Jun 1 10:27:22 2009 Subject: ZFS booting without partitions In-Reply-To: <4A23A81A.5050600@restart.be> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> Message-ID: <4A23ACFD.102@restart.be> Henri Hennebert wrote: > Lorenzo Perone wrote: >> Hi, >> >> I tried hard... but without success ;( >> >> the result is, when choosing the disk with the zfs boot >> sectors in it (in my case F5, which goes to ad6), the kernel >> is not found. the console shows: >> >> forth not found >> definitions not found >> only not found >> (the above repeated several times) > > 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: > > http://verbier.restart.be/xfer/boot-zfs/ > > Put this directory somewhere, eg /tmp/boot-zfs > > and run the script eg: > `cd /tmp/boot-zfs && sh -x make_usb_key.sh da6 kingston` > > good luck CAVEAT: The script put tuning in '/boot/loader.conf' wich imply "options KVA_PAGES=384" in my i386 kernel. Henri > > Henri >> >> can't load 'kernel' >> >> and I get thrown to the loader prompt. >> lsdev does not show any ZFS devices. >> >> Strange thing: if I boot from the other disk, F1, which is my >> ad4 containing the normal ufs system I used to make up the other >> one, and escape to the loader prompt, lsdev actually sees the >> zpool which is on the other disk, and shows: >> zfs0: tank >> >> I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, >> but there I get the panic: free: guard1 fail message. >> (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) >> >> Sure I'm doing something wrong, but what...? Is it a problem that >> the pool is made out of the second disk only (ad6)? >> >> Here are my details (note: latest stable and biosdisk.c merged >> with changes shown in r185095. no problems in buildworld/kernel): >> >> >> >> Machine: p4 4GHz 4 GB RAM (i386) >> >> Note: the pool has actually a different name (heidi >> instead of tank, if this can be of any relevance...), >> just using tank here as it's one of the conventions... >> >> mount (just to show my starting situation) >> >> /dev/mirror/gm0s1a on / (ufs, local) >> devfs on /dev (devfs, local) >> /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) >> /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) >> /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) >> >> gmirror status >> Name Status Components >> mirror/gm0 DEGRADED ad4 >> (ad6 used to be the second disk...) >> >> echo 'LOADER_ZFS_SUPPORT=yes' >> /etc/make.conf >> >> cd /usr/src >> make buildworld && make buildkernel KERNCONF=HEIDI >> make installkernel KERNCONF=HEIDI >> mergemaster >> make installworld >> shutdown -r now >> >> dd if=/dev/zero of=/dev/ad6 bs=512 count=32 >> >> zpool create tank ad6 >> zfs create tank/usr >> zfs create tank/var >> zfs create -V 4gb tank/swap >> zfs set org.freebsd:swap=on tank/swap >> zpool set bootfs=tank tank >> >> rsync -avx / /tank >> rsync -avx /usr/ /tank/usr >> rsync -avx /var/ /tank/var >> cd /usr/src >> make installkernel KERNCONF=HEIDI DESTDIR=/tank >> >> zpool export tank >> >> dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 >> dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 >> >> zpool import tank >> >> zfs set mountpoint=legacy tank >> zfs set mountpoint=/usr tank/usr >> zfs set mountpoint=/var tank/var >> >> shutdown -r now ... >> >> at the 'mbr prompt' I pressed F5 (the second disk, ad6) >> .. as written above, loader gets loaded (at this stage >> I suppose it's the stuff dd't after block 1024?), >> but kernel not found. >> >> /usr/src/sys/i386/conf/HEIDI: >> (among other things...): >> options KVA_PAGES=512 >> >> (/tank)/boot/loader.conf: >> vm.kmem_size="1024M" >> vm.kmem_size_max="1024M" >> vfs.zfs.arc_max="128M" >> vfs.zfs.vdev.cache.size="8M" >> vfs.root.mountfrom="zfs:tank" >> >> (/tank)/etc/fstab: >> # Device Mountpoint FStype Options Dump Pass# >> tank / zfs rw 0 0 >> /dev/acd0 /cdrom cd9660 ro,noauto 0 0 >> >> >> >> any help is welcome... don't know where to go from here right now. >> >> BTW: I can't stop thanking the team for the incredible >> pace at which bugs are fixed these days! >> >> >> Regards, >> >> Lorenzo >> >> >> >> On 26.05.2009, at 18:42, George Hartzell wrote: >> >>> Andriy Gapon writes: >>>> on 26/05/2009 19:21 George Hartzell said the following: >>>>> Dmitry Morozovsky writes: >>>>>> On Tue, 26 May 2009, Mickael MAILLOT wrote: >>>>>> >>>>>> MM> Hi, >>>>>> MM> >>>>>> MM> i prefere use zfsboot boot sector, an example is better than a >>>>>> long talk: >>>>>> MM> >>>>>> MM> $ zpool create tank mirror ad4 ad6 >>>>>> MM> $ zpool export tank >>>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 >>>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 >>>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 >>>>>> MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 >>>>>> >>>>>> s/skeep/skip/ ? ;-) >>>>> >>>>> What is the reason for copying zfsboot one bit at a time, as opposed >>>>> to >>>>> >>>>> dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 >>>> >>>> seek=1024 for the second part? and no 'count=1' for it? :-) >>>> >>>> [Just guessing] Apparently the first block of zfsboot is some form >>>> of MBR and the >>>> rest is zfs-specific code that goes to magical sector 1024. >>> >>> Ok, I managed to read the argument to seek as "one block", apparently >>> my coffee hasn't hit yet. >>> >>> I'm still confused about the two parts of zfsboot and what's magical >>> about seeking to 1024. >>> >>> g. >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From villa.alberto at gmail.com Mon Jun 1 10:55:26 2009 From: villa.alberto at gmail.com (Alberto Villa) Date: Mon Jun 1 10:55:33 2009 Subject: ZFS booting without partitions In-Reply-To: <4A23A81A.5050600@restart.be> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> Message-ID: On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert 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 From kmacy at freebsd.org Mon Jun 1 13:08:36 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon Jun 1 13:17:46 2009 Subject: ZFS booting without partitions In-Reply-To: References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> Message-ID: <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> 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 wrote: > On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert 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 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@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 From avg at freebsd.org Mon Jun 1 15:07:56 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon Jun 1 15:08:04 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A1FD687.5070502@freebsd.org> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> Message-ID: <4A23EEC8.2040208@freebsd.org> on 29/05/2009 15:35 Andriy Gapon said the following: > So anyone else feels that this is a bug? > > on 28/05/2009 16:55 Andriy Gapon said the following: >> on 28/05/2009 16:26 Henri Hennebert said the following: >>> (gdb) bt >>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >> I find the above part interesting. >> Could this be because of the following discrepancy: >> >> 1) >> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >> extern void __assert(const char *, const char *, int); >> 2) >> lib/libc/gen/assert.c: >> void >> __assert(func, file, line, failedexpr) >> const char *func, *file; >> int line; >> const char *failedexpr; >> >>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1 I propose the following patch for this issue. It fixes mismatch between __assert extern declaration in zfs code and actual signature in libc code. I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that those checks are not needed with compilers that can be used to compile FreeBSD. Besides, both branches of __STDC_VERSION__ check were exactly the same. Henri, if you still experience that crash of zpool command, could you please try the patch and see if you have a nicer assert message and stacktrace now? Sorry, that this is still not a fix for the real issue. diff --git a/cddl/contrib/opensolaris/head/assert.h b/cddl/contrib/opensolaris/head/assert.h index 394820a..c2a4936 100644 --- a/cddl/contrib/opensolaris/head/assert.h +++ b/cddl/contrib/opensolaris/head/assert.h @@ -37,15 +37,7 @@ extern "C" { #endif -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -extern void __assert(const char *, const char *, int); -#else -extern void __assert(const char *, const char *, int); -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -extern void _assert(); -#endif +extern void __assert(const char *, const char *, int, const char *); #ifdef __cplusplus } @@ -68,14 +60,6 @@ extern void _assert(); #else -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #endif /* NDEBUG */ diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h index 7ae7f9d..631e302 100644 --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); #define fm_panic panic /* This definition is copied from assert.h. */ -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ - +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #define VERIFY verify #define ASSERT assert -extern void __assert(const char *, const char *, int); +extern void __assert(const char *, const char *, int, const char *); #ifdef lint #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ #LEFT, #OP, #RIGHT, \ (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ - __assert(__buf, __FILE__, __LINE__); \ + __assert(__func__, __FILE__, __LINE__, __buf); \ } \ _NOTE(CONSTCOND) } while (0) /* END CSTYLED */ -- Andriy Gapon From dudu at dudu.ro Mon Jun 1 15:34:04 2009 From: dudu at dudu.ro (Vlad Galu) Date: Mon Jun 1 15:34:12 2009 Subject: Unnamed POSIX shared semaphores Message-ID: Hello, According to sem_init(3), we can't have shared unnamed semaphores. However, the following code snippet seems to work just fine: -- cut here -- sem_t semaphore; if (sem_init(&semaphore, 1, 10) < 0) std::cout << "Couldn't init semaphore: " << strerror(errno) << std::endl; if (sem_wait(&semaphore) < 0) std::cout << "Couldn't decrement semaphore: " << strerror(errno) << std::endl; int val; sem_getvalue(&semaphore, &val); std::cout << "Value is " << val << std::endl; -- and here -- Is this a case where sem_init() silently reports success, or should be the man page get an update? Thanks, Vlad From cpghost at cordula.ws Mon Jun 1 15:58:18 2009 From: cpghost at cordula.ws (cpghost) Date: Mon Jun 1 15:58:24 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: References: Message-ID: <20090601154807.GB6065@phenom.cordula.ws> On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote: > Hello, > > According to sem_init(3), we can't have shared unnamed semaphores. > However, the following code snippet seems to work just fine: > > -- cut here -- > sem_t semaphore; > if (sem_init(&semaphore, 1, 10) < 0) > std::cout << "Couldn't init semaphore: " << > strerror(errno) << std::endl; > if (sem_wait(&semaphore) < 0) > std::cout << "Couldn't decrement semaphore: " << > strerror(errno) << std::endl; > int val; > sem_getvalue(&semaphore, &val); > std::cout << "Value is " << val << std::endl; > -- and here -- > > Is this a case where sem_init() silently reports success, or should be > the man page get an update? You may want to read the comments in /usr/src/lib/libc/gen/sem.c regarding sem_init(). But yes, the man page is somewhat unclear and I'm not sure the last paragraph is still totally accurate. > Thanks, > Vlad -cpghost. -- Cordula's Web. http://www.cordula.ws/ From hlh at restart.be Mon Jun 1 16:12:30 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Jun 1 16:12:45 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A23EEC8.2040208@freebsd.org> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> Message-ID: <4A23FDE5.1040101@restart.be> Andriy Gapon wrote: > on 29/05/2009 15:35 Andriy Gapon said the following: >> So anyone else feels that this is a bug? >> >> on 28/05/2009 16:55 Andriy Gapon said the following: >>> on 28/05/2009 16:26 Henri Hennebert said the following: >>>> (gdb) bt >>>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >>> I find the above part interesting. >>> Could this be because of the following discrepancy: >>> >>> 1) >>> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >>> extern void __assert(const char *, const char *, int); >>> 2) >>> lib/libc/gen/assert.c: >>> void >>> __assert(func, file, line, failedexpr) >>> const char *func, *file; >>> int line; >>> const char *failedexpr; >>> >>>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1 > > I propose the following patch for this issue. > It fixes mismatch between __assert extern declaration in zfs code and actual > signature in libc code. > I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that > those checks are not needed with compilers that can be used to compile FreeBSD. > Besides, both branches of __STDC_VERSION__ check were exactly the same. > > Henri, > > if you still experience that crash of zpool command, could you please try the > patch and see if you have a nicer assert message and stacktrace now? > Sorry, that this is still not a fix for the real issue. > > diff --git a/cddl/contrib/opensolaris/head/assert.h > b/cddl/contrib/opensolaris/head/assert.h > index 394820a..c2a4936 100644 > --- a/cddl/contrib/opensolaris/head/assert.h > +++ b/cddl/contrib/opensolaris/head/assert.h > @@ -37,15 +37,7 @@ > extern "C" { > #endif > > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -extern void __assert(const char *, const char *, int); > -#else > -extern void __assert(const char *, const char *, int); > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -extern void _assert(); > -#endif > +extern void __assert(const char *, const char *, int, const char *); > > #ifdef __cplusplus > } > @@ -68,14 +60,6 @@ extern void _assert(); > > #else > > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#else > -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) > -#endif /* __STDC__ */ > +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) > > #endif /* NDEBUG */ > diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > index 7ae7f9d..631e302 100644 > --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); > #define fm_panic panic > > /* This definition is copied from assert.h. */ > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#else > -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) > -#endif /* __STDC__ */ > - > +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) > > #define VERIFY verify > #define ASSERT assert > > -extern void __assert(const char *, const char *, int); > +extern void __assert(const char *, const char *, int, const char *); > > #ifdef lint > #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) > @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); > (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ > #LEFT, #OP, #RIGHT, \ > (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ > - __assert(__buf, __FILE__, __LINE__); \ > + __assert(__func__, __FILE__, __LINE__, __buf); \ > } \ > _NOTE(CONSTCOND) } while (0) > /* END CSTYLED */ > > Here is the new bt after the patch [root@avoriaz libzpool]# gdb zdb 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"...(no debugging symbols found)... (gdb) r pool1 Starting program: /usr/sbin/zdb pool1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100178] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100178)] [New Thread 0x801802240 (LWP 100345)] version=13 name='pool1' state=0 txg=4 pool_guid=9156958376606789 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=9156958376606789 children[0] type='raidz' id=0 guid=8214939615613279020 nparity=1 metaslab_array=23 metaslab_shift=32 ashift=9 asize=500108886016 is_log=0 children[0] type='disk' id=0 guid=7001907692988243779 path='/dev/ad8p2' whole_disk=0 children[1] type='disk' id=1 guid=1909032920962573263 path='/dev/ad10p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100346)] [New Thread 0x801802560 (LWP 100347)] [New Thread 0x8018026f0 (LWP 100348)] [New Thread 0x801802880 (LWP 100349)] [New Thread 0x801802a10 (LWP 100350)] [New Thread 0x801802ba0 (LWP 100351)] [New Thread 0x801802d30 (LWP 100352)] [New Thread 0x801802ec0 (LWP 100353)] [New Thread 0x801803050 (LWP 100354)] [New Thread 0x8018031e0 (LWP 100355)] [New Thread 0x801803370 (LWP 100356)] [New Thread 0x801803500 (LWP 100357)] [New Thread 0x801803690 (LWP 100358)] [New Thread 0x801803820 (LWP 100359)] [New Thread 0x8018039b0 (LWP 100360)] [New Thread 0x801803b40 (LWP 100361)] [New Thread 0x801803cd0 (LWP 100362)] [New Thread 0x801803e60 (LWP 100363)] [New Thread 0x801803ff0 (LWP 100364)] [New Thread 0x801804180 (LWP 100365)] [New Thread 0x801804310 (LWP 100366)] [New Thread 0x8018044a0 (LWP 100367)] [New Thread 0x801804630 (LWP 100368)] [New Thread 0x8018047c0 (LWP 100369)] [New Thread 0x801804950 (LWP 100370)] [New Thread 0x801804ae0 (LWP 100371)] Assertion failed: (mp->m_owner == NULL), function zmutex_destroy, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Program received signal SIGABRT, Aborted. [Switching to Thread 0x8018020b0 (LWP 100178)] 0x000000080121fadc in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000000080121fadc in thr_kill () from /lib/libc.so.7 #1 0x00000008012af06b in abort () from /lib/libc.so.7 #2 0x0000000801296fe5 in __assert () from /lib/libc.so.7 #3 0x0000000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c:112 #4 0x0000000801030287 in dsl_dataset_evict (db=Variable "db" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:266 #5 0x0000000801048b61 in dbuf_evict_user (db=0x8018ca960) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:215 #6 0x000000080104a8c3 in dbuf_rele (db=0x8018ca960, tag=Variable "tag" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1739 #7 0x0000000801029276 in dsl_pool_open (spa=0x8018a2000, txg=Variable "txg" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:139 #8 0x000000080101d503 in spa_load (spa=0x8018a2000, config=Variable "config" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1134 #9 0x000000080101e060 in spa_open_common (pool=0x7fffffffed6e "pool1", spapp=0x7fffffffeb08, tag=0x40b790, config=0x0) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1474 #10 0x0000000000408b41 in ?? () #11 0x00000000004036de in ?? () #12 0x0000000800534000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000002 in ?? () #15 0x00007fffffffed60 in ?? () #16 0x00007fffffffed6e in ?? () #17 0x0000000000000000 in ?? () #18 0x00007fffffffed74 in ?? () #19 0x00007fffffffed8a in ?? () #20 0x00007fffffffed95 in ?? () #21 0x00007fffffffedaf in ?? () #22 0x00007fffffffedda in ?? () #23 0x00007fffffffedf7 in ?? () #24 0x00007fffffffee0a in ?? () #25 0x00007fffffffee14 in ?? () #26 0x00007fffffffee1f in ?? () #27 0x00007fffffffee2b in ?? () #28 0x00007fffffffee40 in ?? () #29 0x00007fffffffee54 in ?? () #30 0x00007fffffffeeae in ?? () #31 0x00007fffffffeebd in ?? () #32 0x00007fffffffeec9 in ?? () #33 0x00007fffffffeee8 in ?? () #34 0x00007fffffffeef5 in ?? () #35 0x00007fffffffef0a in ?? () #36 0x00007fffffffef1c in ?? () #37 0x00007fffffffef25 in ?? () #38 0x00007fffffffef35 in ?? () #39 0x00007fffffffef3d in ?? () #40 0x00007fffffffef66 in ?? () #41 0x00007fffffffef73 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000003 in ?? () #44 0x0000000000400040 in ?? () #45 0x0000000000000004 in ?? () #46 0x0000000000000038 in ?? () #47 0x0000000000000005 in ?? () #48 0x0000000000000007 in ?? () #49 0x0000000000000006 in ?? () #50 0x0000000000001000 in ?? () #51 0x0000000000000008 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000009 in ?? () #54 0x0000000000403650 in ?? () #55 0x0000000000000007 in ?? () #56 0x000000080050c000 in ?? () #57 0x0000000000000000 in ?? () ---Type to continue, or q to quit---q Quit (gdb) q The program is running. Exit anyway? (y or n) yes [root@avoriaz libzpool]# Henri From jilles at stack.nl Mon Jun 1 16:19:20 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Mon Jun 1 16:19:27 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: References: Message-ID: <20090601161903.GA40377@stack.nl> On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote: > According to sem_init(3), we can't have shared unnamed semaphores. > However, the following code snippet seems to work just fine: > -- cut here -- > sem_t semaphore; > if (sem_init(&semaphore, 1, 10) < 0) > std::cout << "Couldn't init semaphore: " << > strerror(errno) << std::endl; > if (sem_wait(&semaphore) < 0) > std::cout << "Couldn't decrement semaphore: " << > strerror(errno) << std::endl; > int val; > sem_getvalue(&semaphore, &val); > std::cout << "Value is " << val << std::endl; > -- and here -- > Is this a case where sem_init() silently reports success, or should be > the man page get an update? Reading the code, it seems like this should work, but only between related processes where the parent process creates the semaphore before forking and no exec is done. This is because a sem_t is a pointer to a structure containing the kernel level semid_t (and a mutex, condvar and the like for process-private semaphores). sem_init() will allocate this structure using malloc(3). Changing sem_t to be a structure would be the obvious way to fix this, but I think this cannot be versioned properly. For example, if someone puts in the public header file of their .so: struct my_struct { int foo; sem_t bar; int quux; }; Changing the size of sem_t will break this. Also, assuming symbol versioning were to be used, if you compile the .so for FreeBSD 7 and the app for FreeBSD 8, the FreeBSD 8 sem_* functions will get FreeBSD 7 style sem_t's. If process-shared semaphores really work, then the above structure is not a pathological case. Effectively, sem_t is carved in stone. So process-private semaphores should continue to have most of their stuff in a separately allocated structure, to preserve flexibility. Perhaps a better method is to set bit 0 of the sem_t to 1 and use the other bits to store the semid_t. -- Jilles Tjoelker From avg at freebsd.org Mon Jun 1 16:23:04 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon Jun 1 16:23:27 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A23FDE5.1040101@restart.be> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> Message-ID: <4A240063.207@freebsd.org> on 01/06/2009 19:12 Henri Hennebert said the following: > Andriy Gapon wrote: >> I propose the following patch for this issue. >> It fixes mismatch between __assert extern declaration in zfs code and >> actual >> signature in libc code. >> I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. >> I think that >> those checks are not needed with compilers that can be used to compile >> FreeBSD. >> Besides, both branches of __STDC_VERSION__ check were exactly the same. >> >> Henri, >> >> if you still experience that crash of zpool command, could you please >> try the >> patch and see if you have a nicer assert message and stacktrace now? >> Sorry, that this is still not a fix for the real issue. >> > Here is the new bt after the patch Henri, thank you very much for testing! It look like the patch did its job. P.S. hopefully someone is looking into the cause of the assertion. > Assertion failed: (mp->m_owner == NULL), function zmutex_destroy, file > /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, > line 112. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x8018020b0 (LWP 100178)] > 0x000000080121fadc in thr_kill () from /lib/libc.so.7 > (gdb) bt > #0 0x000000080121fadc in thr_kill () from /lib/libc.so.7 > #1 0x00000008012af06b in abort () from /lib/libc.so.7 > #2 0x0000000801296fe5 in __assert () from /lib/libc.so.7 > #3 0x0000000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at -- Andriy Gapon From lopez.on.the.lists at yellowspace.net Mon Jun 1 17:10:01 2009 From: lopez.on.the.lists at yellowspace.net (Lorenzo Perone) Date: Mon Jun 1 17:10:09 2009 Subject: ZFS booting without partitions (was: ZFS boot on zfs mirror) In-Reply-To: <20090531071759.GA35763@egr.msu.edu> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <63548432-B73D-4A08-BA99-FEF5BCC1028A@yellowspace.net> <20090531071759.GA35763@egr.msu.edu> Message-ID: On 31.05.2009, at 09:18, Adam McDougall wrote: > I encountered the same symptoms today on both a 32bit and 64bit > brand new install using gptzfsboot. It works for me when I use > a copy of loader from an 8-current box with zfs support compiled in. > I haven't looked into it much yet but it might help you. If you > want, you can try the loader I am using from: > http://www.egr.msu.edu/~mcdouga9/loader Hi, thanx a lot for this hint. Meanwhile, I was almost giving up, and had a try with ZFS on Root with GPT partitioning, using gptzfsboot as the bootloader, a UFS root partition as boot partition (gmirrored to both disks), and the rest (inclusive of a zvol for swap!) on ZFS. This worked perfectly on the first try. (if anyone is interested, I can post my commented command series for that, but it's just a mix of the available tutorials on the web..). I'll be glad do give the zfs-only solution a new try. Had the same impression, that the loader was involved in the problem, but had no env at hand to build a -CURRENT right away... (I did, in fact, repeat the dd-steps a zfsboot bootloader from a recent 8- snapshot iso... with the results being the same as before...). Sidenote: I encountered a few panics when using rsync with the HAX flags enabled (rsync -avxHAX from UFS to ZFS). I'll try to figure out which one of the flags caused it... (Hard links, ACLs, or eXtended attributes..). Never had even the slightest problem with rsync -avx. Thanx for posting me your loader, I'll try with this tomorrow night! (any hint, btw, on why the one in -STABLE seems to be broken, or whether it has actually been fixed by now?) Regards, Lorenzo > (...) > >> 2009/5/28 Lorenzo Perone: >>> Hi, >>> >>> I tried hard... but without success ;( >>> >>> the result is, when choosing the disk with the zfs boot >>> sectors in it (in my case F5, which goes to ad6), the kernel >>> is not found. the console shows: >>> >>> forth not found >>> definitions not found >>> only not found >>> (the above repeated several times) >>> >>> can't load 'kernel' >>> >>> and I get thrown to the loader prompt. >>> lsdev does not show any ZFS devices. >>> >>> (...) From mcdouga9 at egr.msu.edu Mon Jun 1 17:21:29 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Mon Jun 1 17:21:36 2009 Subject: ZFS booting without partitions In-Reply-To: <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> Message-ID: <4A240E17.30907@egr.msu.edu> 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. Kip Macy wrote: > 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 wrote: > >> On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert 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 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > > > From clbuisson at orange.fr Mon Jun 1 17:33:55 2009 From: clbuisson at orange.fr (Claude Buisson) Date: Mon Jun 1 17:34:02 2009 Subject: buildworld fails with "WITHOUT_CDDL=yes" in src.conf In-Reply-To: <200906010940.26300.doconnor@gsoft.com.au> References: <20090531191456.M33035@onet.com.ua> <200906010940.26300.doconnor@gsoft.com.au> Message-ID: <4A2404E5.7010104@orange.fr> Daniel O'Connor wrote: > On Mon, 1 Jun 2009, Pavel Greenberg wrote: >> Hello everybody! >> After today's source update I have a problem when doing make >> buildworld: >> >> cc -O2 -fno-strict-aliasing -pipe -march=pentium4 >> -DLOADER_NFS_SUPPORT - DBOOT_FORTH >> -I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/ >> i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT >> -DLOADER_GPT_SUPPORT -I/usr/ src/sys/boot/i386/loader/../../common >> -I. -Wall -I/usr/src/sys/boot/i386/ loader/.. >> -I/usr/src/sys/boot/i386/loader/../btx/lib -ffreestanding - >> mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >> -mno- sse3 -c >> /usr/src/sys/boot/i386/loader/../../common/interp_forth.c make: don't >> know how to make /usr/obj/usr/src/tmp/usr/lib/libzfs.a. Stop *** >> Error code 2 >> >> Stop in /usr/src/sys/boot/i386. >> *** Error code 1 >> >> Stop in /usr/src/sys/boot. >> *** Error code 1 >> >> Stop in /usr/src/sys. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> >> In my src.conf I have options >> WITHOUT_CDDL= true >> WITHOUT_ZFS= true >> because I don't use ZFS, my desktop haven't enought resources for it >> and I want not to build it. When I updated my OS some weeks ago with >> the same src.conf process ended OK. > > While the above IS a bug it should be pointed out that unless you > actually load the ZFS kld it won't use any memory on your system. > 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".. Claude Buisson From enricom at teppisti.it Mon Jun 1 17:48:59 2009 From: enricom at teppisti.it (Enrico M.) Date: Mon Jun 1 17:49:11 2009 Subject: ZFS booting without partitions In-Reply-To: <4A23A81A.5050600@restart.be> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A23A81A.5050600@restart.be> Message-ID: <200906011948.58095.enricom@teppisti.it> On Monday 01 June 2009 12:06:18 Henri Hennebert wrote: > Lorenzo Perone wrote: > > Hi, > > > > I tried hard... but without success ;( > > > > the result is, when choosing the disk with the zfs boot > > sectors in it (in my case F5, which goes to ad6), the kernel > > is not found. the console shows: > > > > forth not found > > definitions not found > > only not found > > (the above repeated several times) > > 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: > > http://verbier.restart.be/xfer/boot-zfs/ Thanks! I replaced /boot/loader with the file from your link. Now the system boot. From bms at FreeBSD.org Mon Jun 1 21:17:51 2009 From: bms at FreeBSD.org (Bruce Simpson) Date: Mon Jun 1 21:17:58 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: <20090601161903.GA40377@stack.nl> References: <20090601161903.GA40377@stack.nl> Message-ID: <4A24457C.6060100@FreeBSD.org> Jilles Tjoelker wrote: > If process-shared semaphores really work, then the above structure is > not a pathological case. Effectively, sem_t is carved in stone. So > process-private semaphores should continue to have most of their stuff > in a separately allocated structure, to preserve flexibility. > There was an inadvertent race in FreeBSD's POSIX semaphores which I fixed in HEAD and STABLE about 6 weeks before 7.2 was released. I believe process-shared POSIX semaphores now work -- the Python 'multiprocessing' regression test now runs to completion with no errors on both HEAD and STABLE. cheers, BMS From deischen at freebsd.org Mon Jun 1 21:44:29 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Mon Jun 1 21:44:37 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: <4A24457C.6060100@FreeBSD.org> References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> Message-ID: On Mon, 1 Jun 2009, Bruce Simpson wrote: > Jilles Tjoelker wrote: >> If process-shared semaphores really work, then the above structure is >> not a pathological case. Effectively, sem_t is carved in stone. So >> process-private semaphores should continue to have most of their stuff >> in a separately allocated structure, to preserve flexibility. >> > > There was an inadvertent race in FreeBSD's POSIX semaphores which I fixed in > HEAD and STABLE about 6 weeks before 7.2 was released. > > I believe process-shared POSIX semaphores now work -- the Python > 'multiprocessing' regression test now runs to completion with no errors on > both HEAD and STABLE. Process-shared semaphores, mutexes, etc, will never work until their public types are structs, not pointers to structs (i.e. allocated by our library functions). The intrinsic *kernel* semaphore functions (ksem) supposedly do support process-shared semantics, but our POSIX functions' use of them cannot be shared across processes. -- DE From kmacy at freebsd.org Mon Jun 1 22:15:41 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon Jun 1 22:15:47 2009 Subject: ZFS booting without partitions In-Reply-To: <4A240E17.30907@egr.msu.edu> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> <4A240E17.30907@egr.msu.edu> Message-ID: <3c1674c90906011515r5f706fdfl570e17a3c90f169f@mail.gmail.com> On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall 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 From kmacy at freebsd.org Mon Jun 1 22:19:01 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon Jun 1 22:19:07 2009 Subject: buildworld fails with "WITHOUT_CDDL=yes" in src.conf In-Reply-To: <4A2404E5.7010104@orange.fr> References: <20090531191456.M33035@onet.com.ua> <200906010940.26300.doconnor@gsoft.com.au> <4A2404E5.7010104@orange.fr> Message-ID: <3c1674c90906011518k6d680125hf4b4d7608c92de44@mail.gmail.com> > 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 From joe at freebsd.org Tue Jun 2 06:28:11 2009 From: joe at freebsd.org (Joe Karthauser) Date: Tue Jun 2 06:28:19 2009 Subject: Sudden wierd SATA problem on RELENG_7 (Re: ZFS hanging at kernel boot now, but didn't before... (Re: ZFS MFC heads up)) In-Reply-To: <4A177AED.8080600@FreeBSD.org> References: <3c1674c90905201459k19776d53n309b2abeab0f8d0a@mail.gmail.com> <200905202209.n4KM9Bcg094853@lava.sentex.ca> <3c1674c90905201541n65f997e6jaa20d93bf566fb98@mail.gmail.com> <68BDAD74-021A-4169-B003-21A2BCF2AD5C@transsys.com> <4A156AD7.8000003@icyb.net.ua> <4A159482.9080903@freebsd.org> <3c1674c90905211128n45814519o903ee2b6eb3cf195@mail.gmail.com> <4A16E37C.2030005@freebsd.org> <3c1674c90905221139i6f335062k74d641b7c91c188c@mail.gmail.com> <4A16FF93.2020504@freebsd.org> <4A171AB6.8040607@freebsd.org> <4A177AED.8080600@FreeBSD.org> Message-ID: <4A24C673.5090408@freebsd.org> on 23/05/2009 05:26 Alexander Motin said the following: > Hi. > > Joe Karthauser wrote: >> I spoke too soon. It must have just randomly booted, because it is now >> hanging again. No amount of jiggling cables has made any difference. > > Can you provide verbose boot messages of your system from the beginning > up to the problem? Especially, all related to the ATA. > Attached. > > Do you have AHCI mode enabled in BIOS, or you using legacy ATA emulation? > It's set up as AHCI in the bios. What is strange is that it has now started working again. I can't make any sense of it. The machine boots up fine. It was definitely hanging at the ata probes though, just after the ZFS messages are output. Joe -------------- next part -------------- Copyright (c) 1992-2009 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.2-STABLE #7: Fri May 22 23:10:15 BST 2009 root@athenaeum.tao.org.uk:/usr/obj/usr/src/sys/ATHENAEUM Preloaded elf kernel "/boot/kernel/kernel" at 0x80b47000. Preloaded elf module "/boot/kernel/zfs.ko" at 0x80b4719c. Preloaded elf module "/boot/kernel/opensolaris.ko" at 0x80b47244. Preloaded elf module "/boot/kernel/geom_eli.ko" at 0x80b472f4. Preloaded elf module "/boot/kernel/crypto.ko" at 0x80b473a4. Preloaded elf module "/boot/kernel/zlib.ko" at 0x80b47450. Preloaded elf module "/boot/kernel/geom_label.ko" at 0x80b474fc. Preloaded elf module "/boot/kernel/geom_mirror.ko" at 0x80b475ac. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x80b4765c. Preloaded elf module "/boot/kernel/acpi.ko" at 0x80b476b4. module_register: module g_label already exists! Module g_label failed to register: 17 Calibrating clock(s) ... i8254 clock: 1192003 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2402413236 Hz CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2402.41-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 4096 kbytes, 16-way associative, 64 bytes/line real memory = 3756916736 (3582 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x00000000dbf7ffff, 3677728768 bytes (897883 pages) avail memory = 3673681920 (3503 MB) Table 'FACP' at 0xdfee30c0 Table 'HPET' at 0xdfee7e00 Table 'MCFG' at 0xdfee7e80 Table 'APIC' at 0xdfee7d00 MADT: Found table at 0xdfee7d00 MP Configuration Table version 1.4 found at 0x800f0d00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 3 ACPI ID 1: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target 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 bios32: Found BIOS32 Service Directory header at 0x800fad30 bios32: Entry = 0xfb3f0 (800fb3f0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb420 pnpbios: Found PnP BIOS data at 0x800fbf90 pnpbios: Entry = f0000:bfc0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ULE: setup cpu group 2 ULE: setup cpu 2 ULE: adding cpu 2 to group 2: cpus 1 mask 0x4 ULE: setup cpu group 3 ULE: setup cpu 3 ULE: adding cpu 3 to group 3: cpus 1 mask 0x8 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ACPI: RSDP @ 0x0xf6c30/0x0014 (v 0 GBT ) ACPI: RSDT @ 0x0xdfee3040/0x0034 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: FACP @ 0x0xdfee30c0/0x0074 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: DSDT @ 0x0xdfee3180/0x4B32 (v 1 GBT GBTUACPI 0x00001000 MSFT 0x0100000C) ACPI: FACS @ 0x0xdfee0000/0x0040 ACPI: HPET @ 0x0xdfee7e00/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x00000098) ACPI: MCFG @ 0x0xdfee7e80/0x003C (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: APIC @ 0x0xdfee7d00/0x0084 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 nfslock: pseudo-device mem: Pentium Pro MTRR support enabled crypto: null: kbd: new array size 4 kbd1 at kbdmux0 io: random: npx0: INT 16 interface cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0x86862000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=29c08086) pcibios: BIOS version 3.00 AcpiOsDerivePciId: \\_SB_.PCI0.PX40.PIRQ -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.PX40.PIR2 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dfde0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 14 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x29c0, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x29c1, revid=0x02 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2937, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2938, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=3 map[20]: type I/O Port, range 32, base 0xe100, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2939, revid=0x02 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xe500, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293c, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb105000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293e, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfb100000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2940, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2946, revid=0x02 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2948, revid=0x02 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2934, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0xe200, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2935, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0xe300, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2936, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xe400, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293a, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb104000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x92 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2918, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2923, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xe600, size 3, enabled map[14]: type I/O Port, range 32, base 0xe700, size 2, enabled map[18]: type I/O Port, range 32, base 0xe800, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe900, size 2, enabled map[20]: type I/O Port, range 32, base 0xea00, size 5, enabled map[24]: type Memory, range 32, base 0xfb106000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2930, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[10]: type Memory, range 64, base 0xfb107000, size 8, enabled map[20]: type I/O Port, range 32, base 0x500, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xa000-0xafff pcib1: memory decode 0xf4000000-0xf6ffffff pcib1: prefetched decode 0xe0000000-0xefffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10de, dev=0x0392, revid=0xa1 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf4000000, size 24, enabled pcib1: requested memory range 0xf4000000-0xf4ffffff: good map[14]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib1: requested memory range 0xe0000000-0xefffffff: good map[1c]: type Memory, range 64, base 0xf5000000, size 24, enabled pcib1: requested memory range 0xf5000000-0xf5ffffff: good map[24]: type I/O Port, range 32, base 0xa000, size 7, enabled pcib1: requested I/O range 0xa000-0xa07f: in range pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 vgapci0: port 0xa000-0xa07f mem 0xf4000000-0xf4ffffff,0xe0000000-0xefffffff,0xf5000000-0xf5ffffff irq 16 at device 0.0 on pci1 uhci0: port 0xe000-0xe01f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe000 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe100-0xe11f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe100 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe500-0xe51f irq 18 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe500 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfb105000-0xfb1053ff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfb105000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x9000-0x9fff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: irq 19 at device 28.3 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xb000-0xbfff pcib3: memory decode 0xfb000000-0xfb0fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x197b, dev=0x2363, revid=0x02 domain=0, bus=3, slot=0, func=0 class=01-06-01, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[24]: type Memory, range 32, base 0xfb000000, size 13, enabled pcib3: requested memory range 0xfb000000-0xfb001fff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x197b, dev=0x2363, revid=0x02 domain=0, bus=3, slot=0, func=1 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled pcib3: requested I/O range 0xb000-0xb007: in range map[14]: type I/O Port, range 32, base 0xb100, size 2, enabled pcib3: requested I/O range 0xb100-0xb103: in range map[18]: type I/O Port, range 32, base 0xb200, size 3, enabled pcib3: requested I/O range 0xb200-0xb207: in range map[1c]: type I/O Port, range 32, base 0xb300, size 2, enabled pcib3: requested I/O range 0xb300-0xb303: in range map[20]: type I/O Port, range 32, base 0xb400, size 4, enabled pcib3: requested I/O range 0xb400-0xb40f: in range pcib3: matched entry for 3.0.INTB pcib3: slot 0 INTB hardwired to IRQ 16 atapci0: mem 0xfb000000-0xfb001fff irq 19 at device 0.0 on pci3 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 52 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xfb000000 atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: SATA connect time=0ms ata2: SIGNATURE: 00000101 ata2: ahci_reset devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect status=00000000 ata3: ahci_reset devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] atapci1: port 0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f irq 16 at device 0.1 on pci3 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb400 atapci1: [MPSAFE] atapci1: [ITHREAD] ata4: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xb000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xb100 ata4: reset tp1 mask=03 ostat0=00 ostat1=00 ata4: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata4: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=00 stat1=00 devices=0x4 ata4: [MPSAFE] ata4: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xf7000000-0xf8ffffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x10ec, dev=0x8168, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib4: requested I/O range 0xc000-0xc0ff: in range map[18]: type Memory, range 64, base 0xf8000000, size 12, enabled pcib4: requested memory range 0xf8000000-0xf8000fff: good pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 re0: port 0xc000-0xc0ff mem 0xf8000000-0xf8000fff irq 16 at device 0.0 on pci4 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xf8000000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) msi: routing MSI IRQ 256 to vector 54 re0: using IRQ 256 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:1a:4d:4a:1d:b1 re0: [MPSAFE] re0: [FILTER] uhci3: port 0xe200-0xe21f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe200 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 53 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe300-0xe31f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe300 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe400-0xe41f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe400 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfb104000-0xfb1043ff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfb104000 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xd000-0xdfff pcib5: memory decode 0xf9000000-0xfaffffff pcib5: no prefetched decode pcib5: Subtractively decoded bridge. pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x1186, dev=0x4300, revid=0x10 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd000, size 8, enabled pcib5: requested I/O range 0xd000-0xd0ff: in range map[14]: type Memory, range 32, base 0xfa000000, size 8, enabled pcib5: requested memory range 0xfa000000-0xfa0000ff: good pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 20 found-> vendor=0x1186, dev=0x4300, revid=0x10 domain=0, bus=5, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xd100, size 8, enabled pcib5: requested I/O range 0xd100-0xd1ff: in range map[14]: type Memory, range 32, base 0xfa001000, size 8, enabled pcib5: requested memory range 0xfa001000-0xfa0010ff: good pcib5: matched entry for 5.1.INTA pcib5: slot 1 INTA hardwired to IRQ 19 found-> vendor=0x9004, dev=0x6178, revid=0x01 domain=0, bus=5, slot=2, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0x04 (1000 ns) intpin=a, irq=15 map[10]: type I/O Port, range 32, base 0xd200, size 8, enabled pcib5: requested I/O range 0xd200-0xd2ff: in range map[14]: type Memory, range 32, base 0xfa002000, size 12, enabled pcib5: requested memory range 0xfa002000-0xfa002fff: good pcib5: matched entry for 5.2.INTA pcib5: slot 2 INTA hardwired to IRQ 18 re1: port 0xd000-0xd0ff mem 0xfa000000-0xfa0000ff irq 20 at device 0.0 on pci5 re1: Reserved 0x100 bytes for rid 0x14 type 3 at 0xfa000000 re1: Chip rev. 0x10000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: bpf attached re1: Ethernet address: 00:1c:f0:6e:c7:d2 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 55 re1: [MPSAFE] re1: [FILTER] re2: port 0xd100-0xd1ff mem 0xfa001000-0xfa0010ff irq 19 at device 1.0 on pci5 re2: Reserved 0x100 bytes for rid 0x14 type 3 at 0xfa001000 re2: Chip rev. 0x10000000 re2: MAC rev. 0x00000000 miibus2: on re2 rgephy2: PHY 1 on miibus2 rgephy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re2: bpf attached re2: Ethernet address: 00:1c:f0:ba:be:ed re2: [MPSAFE] re2: [FILTER] ahc0: port 0xd200-0xd2ff mem 0xfa002000-0xfa002fff irq 18 at device 2.0 on pci5 ahc0: Defaulting to MEMIO off ahc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd200 ahc0: Reading SEEPROM...done. ahc0: Low byte termination Enabled ahc0: Downloading Sequencer Program... 460 instructions downloaded ahc0: Features 0x10101, Bugs 0x35, Flags 0x20481540 ahc0: [MPSAFE] ahc0: [ITHREAD] aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xfb106000-0xfb1067ff irq 19 at device 31.2 on pci0 atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xea00 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfb106000 atapci2: AHCI called from vendor specific driver atapci2: AHCI Version 01.20 controller with 4 ports detected ata5: on atapci2 ata5: SATA connect time=0ms ata5: SIGNATURE: 00000101 ata5: ahci_reset devices=0x1 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci2 ata6: SATA connect time=0ms ata6: SIGNATURE: 00000101 ata6: ahci_reset devices=0x1 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci2 ata7: port not implemented ata7: [MPSAFE] ata7: [ITHREAD] ata8: on atapci2 ata8: port not implemented ata8: [MPSAFE] ata8: [ITHREAD] ata9: on atapci2 ata9: SATA connect time=0ms ata9: SIGNATURE: 00000101 ata9: ahci_reset devices=0x1 ata9: [MPSAFE] ata9: [ITHREAD] ata10: on atapci2 ata10: SATA connect time=0ms ata10: SIGNATURE: 00000101 ata10: ahci_reset devices=0x1 ata10: [MPSAFE] ata10: [ITHREAD] pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 56 fdc0: [FILTER] sio0: irq maps: 0xdc29 0xdc39 0xdc29 0xdc29 sio0: irq maps: 0xdc29 0xdc39 0xdc29 0xdc29 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 cpu0: switching to generic Cx mode est0: enabling SpeedStep est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 920092006000620 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 920092006000620 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 920092006000620 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 920092006000620 device_attach: est3 attach returned 6 p4tcc3: on cpu3 atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd1fff,0xd2000-0xd4fff,0xd5000-0xd57ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 14 (ISA IRQ 14) to vector 59 ata0: [MPSAFE] ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 60 ata1: [MPSAFE] ata1: [ITHREAD] bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 61 ppbus0: [MPSAFE] ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xdc29 0xdc29 0xdc29 0xdc29 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 230866 -> 100000 procfs registered WARNING: ZFS is considered to be an experimental feature in FreeBSD. lapic: Divisor 2, Frequency 133467407 hz Timecounter "TSC" frequency 2402413236 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached Waiting 5 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. The GEOM class LABEL is already loaded. ZFS filesystem version 13 ZFS storage pool version 13 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 476938MB at ata2-master SATA300 ad4: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire acd0: DVDR drive at ata4 as master acd0: read 8269KB/s (8269KB/s) write 8269KB/s (8269KB/s), 2048KB buffer, UDMA66 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 476938MB at ata5-master SATA300 ad10: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad12: 476938MB at ata6-master SATA300 ad12: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue ata9-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad18: 476938MB at ata9-master SATA300 ad18: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue ata10-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad20: 476938MB at ata10-master SATA300 ad20: 976771055 sectors [969018C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM_LABEL: Label for provider ad4 is label/sata5. GEOM: new disk ad10 GEOM: new disk ad12 GEOM: new disk ad18 GEOM: new disk ad20 GEOM_LABEL: Label for provider ad4s1a is ufsid/477454d17d3bf4f7. GEOM_LABEL: Label for provider ad4s1c is ufsid/4774549e7d9d0f30. GEOM_LABEL: Label for provider ad10 is label/sata1. GEOM_LABEL: Label for provider ad12 is label/sata2. GEOM_LABEL: Label for provider ad18 is label/sata3. GEOM_LABEL: Label for provider ad20 is label/sata4. GEOM_LABEL: Label ufsid/4774549e7d9d0f30 removed. GEOM_LABEL: Label ufsid/477454d17d3bf4f7 removed. GEOM_MIRROR: Device mirror/boot0 launched (5/5). ahc0: Selection Timeout on A:0. 0 SCBs aborted ahc0: Selection Timeout on A:1. 0 SCBs aborted ahc0: Selection Timeout on A:3. 0 SCBs aborted ahc0: Selection Timeout on A:4. 0 SCBs aborted ahc0: Selection Timeout on A:5. 0 SCBs aborted ahc0: Selection Timeout on A:6. 0 SCBs aborted ahc0: Selection Timeout on A:2. 0 SCBs aborted SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 2 ioapic0: Assigning ISA IRQ 7 to local APIC 3 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning ISA IRQ 15 to local APIC 2 ioapic0: Assigning PCI IRQ 16 to local APIC 3 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 20 to local APIC 2 ioapic0: Assigning PCI IRQ 21 to local APIC 3 ioapic0: Assigning PCI IRQ 23 to local APIC 0 msi: Assigning MSI IRQ 256 to local APIC 1 Trying to mount root from zfs:storage/rootfs start_init: trying /sbin/init GEOM_LABEL: Label for provider mirror/boot0 is ufsid/4774549e7d9d0f30. GEOM_LABEL: Label for provider mirror/boot0a is ufsid/477454d17d3bf4f7. GEOM_LABEL: Label ufsid/4774549e7d9d0f30 removed. GEOM_LABEL: Label ufsid/477454d17d3bf4f7 removed. ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled re0: link state changed to UP From gerrit at pmp.uni-hannover.de Tue Jun 2 07:52:32 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Tue Jun 2 07:52:44 2009 Subject: ZFS NAS configuration question In-Reply-To: References: Message-ID: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> On Sat, 30 May 2009 21:41:36 +0300 Dan Naumov wrote about ZFS NAS configuration question: DN> So, this leaves me with 1 SATA port used for a FreeBSD disk and 4 SATA DN> ports available for tinketing with ZFS. Do you have a USB port available to boot from? A conventional USB stick (I use 4 GB or 8GB these days, but smaller ones would certainly also do) is enough to hold the base system on UFS, and you can give the whole of your disks to ZFS without having to bother with booting from them. cu Gerrit From dfr at rabson.org Tue Jun 2 08:24:25 2009 From: dfr at rabson.org (Doug Rabson) Date: Tue Jun 2 08:24:31 2009 Subject: /boot/loader can't load kernel if too many pool/devices In-Reply-To: <4A23ABF2.3070601@restart.be> References: <4A23ABF2.3070601@restart.be> Message-ID: On 1 Jun 2009, at 11:22, Henri Hennebert wrote: > Hello, > > During my tests (succesful) to directly boot from ZFS (with zfsboot > and gptzfsboot) I encounter the error "can't boot 'kernel'" if too > many devices/pools are connected to the machine. In my case: > > 2 SAS disks with 2 pools > 2 SATA disks with 2 pools > 1 USB key with one pool > > `heap` command: > > Active Allocations: 171/173 > 536576 bytes reserved 527800 bytes allocated > > `ls` command: > > open '/' failed: too many open files > > If I reboot without the USB key all is OK. > > If I reboot from the USB key after disconnecting 2 disks all is OK. > > By the way, the /boot/loader in 7.2-STABLE don't work, complains > about forth not found. > > The previous tests were made with 7.2-STABLE (May 31) with /boot/ > loader from 8.0-CURRENT. I recently increased the number of file descriptors available for / boot/loader. Could you rebuild and try again please. Make sure you rebuild libstand.a as well as /boot/loader. From dudu at dudu.ro Tue Jun 2 08:35:00 2009 From: dudu at dudu.ro (Vlad Galu) Date: Tue Jun 2 08:35:10 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> Message-ID: On Tue, Jun 2, 2009 at 12:30 AM, Daniel Eischen wrote: [...] Thank you all for your swift replies. It seems to indeed work for forked processes. The app at $work (written on and for Linux) transported an unnamed semaphore over a POSIX shared memory object. I'll probably make it a named semaphore and only send its name over the shared memory space. Regards, Vlad From dan.naumov at gmail.com Tue Jun 2 08:46:43 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Tue Jun 2 08:46:51 2009 Subject: ZFS NAS configuration question In-Reply-To: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> References: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> Message-ID: USB root partition for booting off UFS is something I have considered. I have looked around and it seems that all the "install FreeBSD onto USB stick" guides seem to involve a lot of manual work from a fixit environment, does sysinstall not recognise USB drives as a valid disk device to parition/label/install FreeBSD on? If I do go with an USB boot/root, what things I should absolutely keep on it and which are "safe" to move to a ZFS pool? The idea is that in case my ZFS configuration goes bonkers for some reason, I still have a fully workable singleuser configuration to boot from for recovery. I haven't really used USB flash for many years, but I remember when they first started appearing on the shelves, they got well known for their horrible reliability (stick would die within a year of use, etc). Have they improved to the point of being good enough to host a root partition on, without having to setup some crazy GEOM mirror setup using 2 of them? - Dan Naumov 2009/6/2 Gerrit K?hn > On Sat, 30 May 2009 21:41:36 +0300 Dan Naumov wrote > about ZFS NAS configuration question: > > DN> So, this leaves me with 1 SATA port used for a FreeBSD disk and 4 SATA > DN> ports available for tinketing with ZFS. > > Do you have a USB port available to boot from? A conventional USB stick (I > use 4 GB or 8GB these days, but smaller ones would certainly also do) is > enough to hold the base system on UFS, and you can give the whole of your > disks to ZFS without having to bother with booting from them. > > > cu > Gerrit > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From doconnor at gsoft.com.au Tue Jun 2 09:15:41 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Jun 2 09:15:49 2009 Subject: ZFS NAS configuration question In-Reply-To: References: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> Message-ID: <200906021845.33739.doconnor@gsoft.com.au> On Tue, 2 Jun 2009, Dan Naumov wrote: > USB root partition for booting off UFS is something I have > considered. I have looked around and it seems that all the "install > FreeBSD onto USB stick" guides seem to involve a lot of manual work > from a fixit environment, does sysinstall not recognise USB drives as > a valid disk device to parition/label/install FreeBSD on? If I do go > with an USB boot/root, what things I should absolutely keep on it and > which are "safe" to move to a ZFS pool? The idea is that in case my > ZFS configuration goes bonkers for some reason, I still have a fully > workable singleuser configuration to boot from for recovery. It should see them as SCSI disks, note that if you plug them in after the installer boots you will need to go into Options and tell it to rescan the devices. > I haven't really used USB flash for many years, but I remember when > they first started appearing on the shelves, they got well known for > their horrible reliability (stick would die within a year of use, > etc). Have they improved to the point of being good enough to host a > root partition on, without having to setup some crazy GEOM mirror > setup using 2 of them? I would expect one to last a long time if you only use it for /boot and use ZFS for the rest (or even just moving /var onto ZFS would save heaps of writes). Also, you could setup 2 USB sticks (install on one then dd onto the other) so you have a cold spare. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090602/5b468317/attachment.pgp From uqs at spoerlein.net Tue Jun 2 09:16:13 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Tue Jun 2 09:16:20 2009 Subject: ZFS weird device tasting loop since MFC Message-ID: <20090602091610.GE93344@acme.spoerlein.net> 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) root@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 ... Cheers, Ulrich Sp?rlein -- http://www.dubistterrorist.de/ From uqs at spoerlein.net Tue Jun 2 09:24:12 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Tue Jun 2 09:24:20 2009 Subject: ZFS weird device tasting loop since MFC In-Reply-To: <20090602091610.GE93344@acme.spoerlein.net> References: <20090602091610.GE93344@acme.spoerlein.net> Message-ID: <20090602092408.GF93344@acme.spoerlein.net> 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) > > root@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: root@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. Cheers, Ulrich Sp?rlein -- http://www.dubistterrorist.de/ From 000.fbsd at quip.cz Tue Jun 2 10:12:10 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Jun 2 10:12:18 2009 Subject: ZFS NAS configuration question In-Reply-To: <200906021845.33739.doconnor@gsoft.com.au> References: <20090602095228.8ff3654c.gerrit@pmp.uni-hannover.de> <200906021845.33739.doconnor@gsoft.com.au> Message-ID: <4A24FAF0.2020603@quip.cz> Daniel O'Connor wrote: > On Tue, 2 Jun 2009, Dan Naumov wrote: > >>USB root partition for booting off UFS is something I have >>considered. I have looked around and it seems that all the "install >>FreeBSD onto USB stick" guides seem to involve a lot of manual work >>from a fixit environment, does sysinstall not recognise USB drives as >>a valid disk device to parition/label/install FreeBSD on? If I do go >>with an USB boot/root, what things I should absolutely keep on it and >>which are "safe" to move to a ZFS pool? The idea is that in case my >>ZFS configuration goes bonkers for some reason, I still have a fully >>workable singleuser configuration to boot from for recovery. > > > It should see them as SCSI disks, note that if you plug them in after > the installer boots you will need to go into Options and tell it to > rescan the devices. > > >>I haven't really used USB flash for many years, but I remember when >>they first started appearing on the shelves, they got well known for >>their horrible reliability (stick would die within a year of use, >>etc). Have they improved to the point of being good enough to host a >>root partition on, without having to setup some crazy GEOM mirror >>setup using 2 of them? > > > I would expect one to last a long time if you only use it for /boot and > use ZFS for the rest (or even just moving /var onto ZFS would save > heaps of writes). I am using this setup (booting from USB with UFS) in our backup storage server with FreeBSD 7.2 + ZFS. 2GB USB flash disk contains normal installation of the whole system, but is set to read only in fstab. ZFS is used for /tmp /var /usr/ports /usr/src /usr/obj and storage. root filesystem is remounted read write only for some configuration changes, then remounted back to read only. Miroslav Lachman # df -h Filesystem Size Used Avail Capacity Mounted on /dev/ufs/2gLive 1.6G 863M 642M 57% / devfs 1.0K 1.0K 0B 100% /dev tank 1.1T 128K 1.1T 0% /tank tank/system 1.1T 128K 1.1T 0% /tank/system tank/system/usr 1.1T 128K 1.1T 0% /tank/system/usr tank/system/tmp 1.1T 128K 1.1T 0% /tmp tank/system/usr/obj 1.1T 128K 1.1T 0% /usr/obj tank/system/usr/ports 1.1T 218M 1.1T 0% /usr/ports tank/system/usr/ports/distfiles 1.1T 108M 1.1T 0% /usr/ports/distfiles tank/system/usr/ports/packages 1.1T 125M 1.1T 0% /usr/ports/packages tank/system/usr/src 1.1T 171M 1.1T 0% /usr/src tank/system/var 1.1T 256K 1.1T 0% /var tank/system/var/db 1.1T 716M 1.1T 0% /var/db tank/system/var/db/pkg 1.1T 384K 1.1T 0% /var/db/pkg tank/system/var/log 1.1T 45M 1.1T 0% /var/log tank/system/var/run 1.1T 128K 1.1T 0% /var/run tank/vol0 2.6T 1.5T 1.1T 57% /vol0 tank/vol0/mon 1.1T 128K 1.1T 0% /vol0/mon (some filesystems are using compression, that's why ports and var are splitted in to more filesystems) From hlh at restart.be Tue Jun 2 10:31:14 2009 From: hlh at restart.be (Henri Hennebert) Date: Tue Jun 2 10:31:29 2009 Subject: /boot/loader can't load kernel if too many pool/devices In-Reply-To: References: <4A23ABF2.3070601@restart.be> Message-ID: <4A24FF6E.7020209@restart.be> Doug Rabson wrote: > > On 1 Jun 2009, at 11:22, Henri Hennebert wrote: > >> Hello, >> >> During my tests (succesful) to directly boot from ZFS (with zfsboot >> and gptzfsboot) I encounter the error "can't boot 'kernel'" if too >> many devices/pools are connected to the machine. In my case: >> >> 2 SAS disks with 2 pools >> 2 SATA disks with 2 pools >> 1 USB key with one pool >> >> `heap` command: >> >> Active Allocations: 171/173 >> 536576 bytes reserved 527800 bytes allocated >> >> `ls` command: >> >> open '/' failed: too many open files >> >> If I reboot without the USB key all is OK. >> >> If I reboot from the USB key after disconnecting 2 disks all is OK. >> >> By the way, the /boot/loader in 7.2-STABLE don't work, complains about >> forth not found. >> >> The previous tests were made with 7.2-STABLE (May 31) with >> /boot/loader from 8.0-CURRENT. > > I recently increased the number of file descriptors available for > /boot/loader. Could you rebuild and try again please. Make sure you > rebuild libstand.a as well as /boot/loader. > OK - I can boot with the USB key and 4 disks Thanks Henri From sthaug at nethelp.no Tue Jun 2 11:04:12 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Tue Jun 2 11:04:19 2009 Subject: ZFS NAS configuration question In-Reply-To: <4A24FAF0.2020603@quip.cz> References: <200906021845.33739.doconnor@gsoft.com.au> <4A24FAF0.2020603@quip.cz> Message-ID: <20090602.123730.41694829.sthaug@nethelp.no> > root filesystem is remounted read write only for some configuration > changes, then remounted back to read only. Does this work reliably for you? I tried doing the remounting trick, both for root and /usr, back in the 4.x time frame. And could never get it to work - would always end up with inconsistent file systems. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From davidn04 at gmail.com Tue Jun 2 11:49:26 2009 From: davidn04 at gmail.com (David N) Date: Tue Jun 2 11:49:33 2009 Subject: Crash with GJournal switcher Message-ID: <4d7dd86f0906020449m43d03311jf7fcae2fbb5339c1@mail.gmail.com> FreeBSD 7.2-RELEASE GPT + gmirror + gjournal May 31 10:15:48 netserv1 kernel: Fatal trap 9: general protection fault while in kernel mode May 31 10:15:48 netserv1 kernel: cpuid = 0; apic id = 00 May 31 10:15:48 netserv1 kernel: instruction pointer = 0x8:0xffffffff8059f667 May 31 10:15:48 netserv1 kernel: stack pointer = 0x10:0xfffffffe801e0a60 May 31 10:15:48 netserv1 kernel: frame pointer = 0x10:0xfffffffe801e0a90 May 31 10:15:48 netserv1 kernel: code segment = base 0x0, limit 0xfffff, type 0x1b May 31 10:15:48 netserv1 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May 31 10:15:48 netserv1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 May 31 10:15:48 netserv1 kernel: current process = 39 (g_journal switcher) This caused one of my mirrors to become stale upon reboot. There wasn't any crash dumps. I've got WITNESS compiled at the moment, hopefully a crash/lockup will show something. Would the gjournal fail if one of the gmirror disks was faulty? Regards David N From davidn04 at gmail.com Tue Jun 2 12:01:12 2009 From: davidn04 at gmail.com (David N) Date: Tue Jun 2 12:01:23 2009 Subject: Crash with GJournal switcher In-Reply-To: <4d7dd86f0906020449m43d03311jf7fcae2fbb5339c1@mail.gmail.com> References: <4d7dd86f0906020449m43d03311jf7fcae2fbb5339c1@mail.gmail.com> Message-ID: <4d7dd86f0906020501h1439eb92g15ae886f72f4d226@mail.gmail.com> 2009/6/2 David N : > FreeBSD 7.2-RELEASE > GPT + gmirror + gjournal > > May 31 10:15:48 netserv1 kernel: Fatal trap 9: general protection > fault while in kernel mode > May 31 10:15:48 netserv1 kernel: cpuid = 0; apic id = 00 > May 31 10:15:48 netserv1 kernel: instruction pointer ? ?= 0x8:0xffffffff8059f667 > May 31 10:15:48 netserv1 kernel: stack pointer ? ? ? ? ?= > 0x10:0xfffffffe801e0a60 > May 31 10:15:48 netserv1 kernel: frame pointer ? ? ? ? ?= > 0x10:0xfffffffe801e0a90 > May 31 10:15:48 netserv1 kernel: code segment ? ? ? ? ? = base 0x0, > limit 0xfffff, type 0x1b > May 31 10:15:48 netserv1 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > May 31 10:15:48 netserv1 kernel: processor eflags ? ? ? = interrupt > enabled, resume, IOPL = 0 > May 31 10:15:48 netserv1 kernel: current process ? ? ? ? ? ? ? ?= 39 > (g_journal switcher) > > > This caused one of my mirrors to become stale upon reboot. There > wasn't any crash dumps. > > I've got WITNESS compiled at the moment, hopefully a crash/lockup will > show something. Would the gjournal fail if one of the gmirror disks > was faulty? > > Regards > David N > lock order reversal: 1st 0xffffffff80b184c0 sleepq chain (sleepq chain) @ /usr/src/sys/kern/kern_sig.c:2291 2nd 0xffffffff80afb5b0 scrlock (scrlock) @ /usr/src/sys/dev/syscons/syscons.c:2519 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x565 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d sc_puts() at sc_puts+0x93 sc_cnputc() at sc_cnputc+0x5a cnputc() at cnputc+0x49 putchar() at putchar+0x6b kvprintf() at kvprintf+0x72 printf() at printf+0xa4 witness_checkorder() at witness_checkorder+0x44c _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d wakeup() at wakeup+0x11 tdsignal() at tdsignal+0x526 realitexpire() at realitexpire+0x3e softclock() at softclock+0x270 ithread_loop() at ithread_loop+0xe7 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe8001cd30, rbp = 0 --- acquiring duplicate lock of same type: "sleepq chain" 1st sleepq chain @ /usr/src/sys/kern/kern_sig.c:2291 2nd sleepq chain @ /usr/src/sys/kern/subr_sleepqueue.c:232 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x565 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d wakeup() at wakeup+0x11 tdsignal() at tdsignal+0x526 realitexpire() at realitexpire+0x3e softclock() at softclock+0x270 ithread_loop() at ithread_loop+0xe7 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe8001cd30, rbp = 0 --- From jhb at freebsd.org Tue Jun 2 12:43:03 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 2 12:43:22 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: <4A24457C.6060100@FreeBSD.org> References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> Message-ID: <200906020842.42330.jhb@freebsd.org> On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote: > Jilles Tjoelker wrote: > > If process-shared semaphores really work, then the above structure is > > not a pathological case. Effectively, sem_t is carved in stone. So > > process-private semaphores should continue to have most of their stuff > > in a separately allocated structure, to preserve flexibility. > > > > There was an inadvertent race in FreeBSD's POSIX semaphores which I > fixed in HEAD and STABLE about 6 weeks before 7.2 was released. > > I believe process-shared POSIX semaphores now work -- the Python > 'multiprocessing' regression test now runs to completion with no errors > on both HEAD and STABLE. The semaphores in recent 7 and 8 are definitely not process-shared (at least not intentionally). They may work across a fork accidentally, but you can't store it in an mmap() region and share it with an arbitrary process. -- John Baldwin From nvass9573 at gmx.com Tue Jun 2 13:45:57 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Tue Jun 2 13:46:04 2009 Subject: ZFS NAS configuration question In-Reply-To: <20090602.123730.41694829.sthaug@nethelp.no> References: <200906021845.33739.doconnor@gsoft.com.au> <4A24FAF0.2020603@quip.cz> <20090602.123730.41694829.sthaug@nethelp.no> Message-ID: <4A252CC5.1030900@gmx.com> sthaug@nethelp.no wrote: >> root filesystem is remounted read write only for some configuration >> changes, then remounted back to read only. > > Does this work reliably for you? I tried doing the remounting trick, > both for root and /usr, back in the 4.x time frame. And could never > get it to work - would always end up with inconsistent file systems. There were many fixes in this area lately. The case where a file system with softdeps would fail to update to read-only is fixed in -CURRENT and these changes are merged to -STABLE. It is believed to work correctly. http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046001.html Remounting with soft updates enabled used to be too fragile to be useful. Now it seems very solid. Nikos From avg at freebsd.org Tue Jun 2 14:06:24 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Jun 2 14:06:31 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A240063.207@freebsd.org> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> <4A240063.207@freebsd.org> Message-ID: <4A2531DA.2070608@freebsd.org> on 01/06/2009 19:22 Andriy Gapon said the following: > Henri, > > thank you very much for testing! > It look like the patch did its job. > > P.S. hopefully someone is looking into the cause of the assertion. I think I cracked it. This is where ds->ds_lock.m_owner gets corrupted: (gdb) c Continuing. Watchpoint 8: *(void **) 34385649856 Old value = (void *) 0x0 New value = (void *) 0x8018f7ce0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 (gdb) bt #0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 #1 0x0000000800a733ca in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #2 0x0000000800a736ab in pthread_mutex_isowned_np () from /lib/libthr.so.3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 ... (gdb) fr 3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 264 if (mutex_owned(&ds->ds_lock)) (gdb) list 259 if (ds->ds_dir) 260 dsl_dir_close(ds->ds_dir, ds); 261 262 ASSERT(!list_link_active(&ds->ds_synced_link)); 263 264 if (mutex_owned(&ds->ds_lock)) 265 mutex_exit(&ds->ds_lock); mutex_owned is defined: cddl/contrib/opensolaris/head/thread.h #define mutex_owned(l) pthread_mutex_isowned_np(l) So we pass kmutex_t* parameter to pthread_mutex_isowned_np call where in fact we should be passing pthread_mutex_t* parameter. So I am quite sure that mutex_owned should be defined as follows: #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Or it should be called on m_lock member of kmutex_t. Thanks to Henri for all the debugging info! -- Andriy Gapon From avg at freebsd.org Tue Jun 2 14:14:21 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Jun 2 14:14:29 2009 Subject: libzpool assert vs libc assert In-Reply-To: <4A2531DA.2070608@freebsd.org> References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> <4A240063.207@freebsd.org> <4A2531DA.2070608@freebsd.org> Message-ID: <4A2533B8.8040007@freebsd.org> on 02/06/2009 17:06 Andriy Gapon said the following: > So I am quite sure that mutex_owned should be defined as follows: > #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Actually: #define mutex_owned(l) pthread_mutex_isowned_np(&(l)->m_lock) And on dangers of ignored compiler warnings: /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type This is during libzpool compilation. -- Andriy Gapon From talon at lpthe.jussieu.fr Tue Jun 2 17:13:29 2009 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Tue Jun 2 17:13:47 2009 Subject: FreeBSD-7.2 works excellent Message-ID: <20090602163841.GA15567@lpthe.jussieu.fr> Hello, just a word to say that the upgrade from FreeBSD-7.1 to 7.2 has solved all problems i had on my desktop (very slow windowing, etc.) without changing anything to the installed ports. Now everything works excellent in accordance with the FreeBSD tradition. Thanks for the good work of the developers -- Michel TALON From zbeeble at gmail.com Tue Jun 2 18:47:44 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Tue Jun 2 18:47:52 2009 Subject: ZFS NAS configuration question In-Reply-To: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> Message-ID: <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> On Sun, May 31, 2009 at 4:43 AM, Aristedes Maniatis wrote: > > On 31/05/2009, at 4:41 AM, Dan Naumov wrote: > > To top that >> off, even when/if you do it right, not your entire disk goes to ZFS >> anyway, because you still do need a swap and a /boot to be non-ZFS, so >> you will have to install ZFS onto a slice and not the entire disk and >> even SUN discourages to do that. >> > > ZFS on root is still pretty new to FreeBSD, and until it gets ironed out > and all the sysinstall tools support it nicely, it isn't hard to use a small > UFS slice to get things going during boot. And there is nothing wrong with > putting ZFS onto a slice rather than the entire disk: that is a very common > approach. > It's worth noting that there are a few sensible appliance designs... (although as a ZFS server, you might want 4, 8 or 16G in your "appliance"). You could, for instance, boot from flash. If your true purpose is an appliance, this is very reasonable. It means that your appliance "boots" when no "disks" are attached. Useful to instruct the appliance user how to attache disks and do diagnostics, for instance. My own ZFS is 5x 1.5TB disks running on a few week old 8-CURRENT. I gave up waiting for v13 in 7.x. Maybe I should have waited. But I've avoided most of the most recent foo-for-ah by not tracking current incessantly. If I was installing new, I'd probably stick with 7.x for a server... for now. I must admit, however, that the system seems happy with 8-CURRENT. The system boots from a pair of drives in a gmirror. Mot because you can't boot from ZFS, but because it's just so darn stable (and it predates the use of ZFS). Really there are two camps here --- booting from ZFS is the use of ZFS as the machine's own filesystem. This is one goal of ZFS that is somewhat imperfect on FreeBSD at the momment. ZFS file servers are another goal where booting from ZFS is not really required and only marginally beneficial. From 000.fbsd at quip.cz Tue Jun 2 19:16:07 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Jun 2 19:16:19 2009 Subject: ZFS NAS configuration question In-Reply-To: <20090602.123730.41694829.sthaug@nethelp.no> References: <200906021845.33739.doconnor@gsoft.com.au> <4A24FAF0.2020603@quip.cz> <20090602.123730.41694829.sthaug@nethelp.no> Message-ID: <4A257A70.2020905@quip.cz> sthaug@nethelp.no wrote: >>root filesystem is remounted read write only for some configuration >>changes, then remounted back to read only. > > > Does this work reliably for you? I tried doing the remounting trick, > both for root and /usr, back in the 4.x time frame. And could never > get it to work - would always end up with inconsistent file systems. The system is in production from October 2008 and never paniced in remounting. In this time frame, we got only two deadlocks caused by earlier versions of ZFS. At this time, files on ZFS are using 28151719 inodes, storage is for daily rsync backups of dozen webservers and mailserver. I am using mount -u -o current,rw / [do some configuration work] sync; sync; sync; mount -u -o current,ro / The sync command is maybe useless, but I feel safer with it ;o) (root filesystem is not using soft-updates) Miroslav Lachman From dougb at FreeBSD.org Tue Jun 2 19:20:43 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 2 19:20:58 2009 Subject: Do you use a value other than AUTO for network_interfaces? Message-ID: <4A257B82.1000701@FreeBSD.org> Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Thanks, Doug From dan.naumov at gmail.com Tue Jun 2 19:39:19 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Tue Jun 2 19:39:26 2009 Subject: ZFS NAS configuration question In-Reply-To: <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> Message-ID: This reminds me. I was reading the release and upgrade notes of OpenSolaris 2009.6 and noted one thing about upgrading from a previous version to the new one:: When you pick the "upgrade OS" option in the OpenSolaris installer, it will check if you are using a ZFS root partition and if you do, it intelligently suggests to take a current snapshot of the root filesystem. After you finish the upgrade and do a reboot, the boot menu offers you the option of booting the new upgraded version of the OS or alternatively _booting from the snapshot taken by the upgrade installation procedure_. Reading that made me pause for a second and made me go "WOW", this is how UNIX system upgrades should be done. Any hope of us lowly users ever seeing something like this implemented in FreeBSD? :) - Dan Naumov On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox wrote: > > > The system boots from a pair of drives in a gmirror. Mot because you can't > boot from ZFS, but because it's just so darn stable (and it predates the use > of ZFS). > > Really there are two camps here --- booting from ZFS is the use of ZFS as > the machine's own filesystem. This is one goal of ZFS that is somewhat > imperfect on FreeBSD at the momment. ZFS file servers are another goal > where booting from ZFS is not really required and only marginally > beneficial. > > > From dan.naumov at gmail.com Tue Jun 2 19:55:45 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Tue Jun 2 19:55:52 2009 Subject: ZFS NAS configuration question In-Reply-To: References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> Message-ID: A little more info for the (perhaps) curious: Managing Multiple Boot Environments: http://dlc.sun.com/osol/docs/content/2009.06/getstart/bootenv.html#bootenvmgr Introduction to Boot Environments: http://dlc.sun.com/osol/docs/content/2009.06/snapupgrade/index.html - Dan Naumov On Tue, Jun 2, 2009 at 10:39 PM, Dan Naumov wrote: > > This reminds me. I was reading the release and upgrade notes of OpenSolaris 2009.6 and noted one thing about upgrading from a previous version to the new one:: > > When you pick the "upgrade OS" option in the OpenSolaris installer, it will check if you are using a ZFS root partition and if you do, it intelligently suggests to take a current snapshot of the root filesystem. After you finish the upgrade and do a reboot, the boot menu offers you the option of booting the new upgraded version of the OS or alternatively _booting from the snapshot taken by the upgrade installation procedure_. > > Reading that made me pause for a second and made me go "WOW", this is how UNIX system upgrades should be done. Any hope of us lowly users ever seeing something like this implemented in FreeBSD? :) > > - Dan Naumov > > > > > > On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox wrote: >> >> >> The system boots from a pair of drives in a gmirror.? Mot because you can't boot from ZFS, but because it's just so darn stable (and it predates the use of ZFS). >> >> Really there are two camps here --- booting from ZFS is the use of ZFS as the machine's own filesystem.? This is one goal of ZFS that is somewhat imperfect on FreeBSD at the momment.? ZFS file servers are another goal where booting from ZFS is not really required and only marginally beneficial. >> >> > From ruben at verweg.com Tue Jun 2 20:30:52 2009 From: ruben at verweg.com (Ruben van Staveren) Date: Tue Jun 2 20:30:59 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <4A257B82.1000701@FreeBSD.org> References: <4A257B82.1000701@FreeBSD.org> Message-ID: On 2 Jun 2009, at 21:20, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I removed > that warning in HEAD Sunday, and there is no a discussion about > whether or not it should be put back, and whether or not there is any > need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a ipv6_ifconfig_bge1="down" and nail network_interfaces to bge0 bge1 lo0 only I'll get autoconfiguration of v6 where I don't want it to be. Being a bit of my own devils advocate here, network_interfaces="AUTO" is already true for ipv6. with network_interfaces="bge0 lo0" network.subr nevertheless sees bge1, and no configuration and takes the responsibility of starting ipv6 autoconfiguration for it. > If you use a value of network_interfaces other than AUTO please speak > up so that we can make an intelligent decision about this issue. you want to have a system where one still can control which interfaces are explicitly configured or skipped, with no side effects of default actions > > > Thanks, > > Doug > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > Regards, Ruben From dougb at FreeBSD.org Tue Jun 2 20:49:07 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 2 20:49:19 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> Message-ID: <4A259039.8040001@FreeBSD.org> Ruben van Staveren wrote: > Being a bit of my own devils advocate here, network_interfaces="AUTO" is > already true for ipv6. FYI, ipv6_network_interfaces exists for this purpose. Thanks for your post, it's good information to add to the pile. Doug From dkelly at hiwaay.net Tue Jun 2 21:19:28 2009 From: dkelly at hiwaay.net (David Kelly) Date: Tue Jun 2 21:19:42 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> Message-ID: <20090602205125.GA75470@Grumpy.DynDNS.org> On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > > >Up till Sunday in 8-current, and for a long time in general > >network.subr (part of the rc.d system) has emitted a warning that > >values of network_interfaces other than AUTO are deprecated. I > >removed that warning in HEAD Sunday, and there is no a discussion > >about whether or not it should be put back, and whether or not there > >is any need for the user to specify the list of network interfaces at > >all. > > Well, I do. > > I only want to configure only the interfaces that are connected and > that I know about. especially in combination with IPv6 there is a nit > that you'll get autoconfiguration for all interfaces unless they are > all explicitly configured. And while I'm not currently using anything other than AUTO I would think there is a security ramification if someone were to plug in to a supposedly unused port, then reboot the machine to prompt AUTO to configure their interface. Its not just a security thing, its an "idiot-proof" thing. If someone is moving machines around I don't want them to come up and partially work if the wires are plugged into the wrong holes. Would rather it be completely broken. I think its good that there is an AUTO *option*. Is also OK that it be the default. I don't think mandatory AUTO is good, if I want a port disabled then I want it to stay disabled. A quick glance of my 7.2-STABLE machine only found network_interfaces used in /etc/defaults/rc.conf. ipv6_network_interfaces is used in many places. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From brooks at freebsd.org Tue Jun 2 22:06:14 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 2 22:06:23 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <20090602205125.GA75470@Grumpy.DynDNS.org> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> Message-ID: <20090602220624.GD15552@lor.one-eyed-alien.net> On Tue, Jun 02, 2009 at 03:51:25PM -0500, David Kelly wrote: > On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > > > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > > > > >Up till Sunday in 8-current, and for a long time in general > > >network.subr (part of the rc.d system) has emitted a warning that > > >values of network_interfaces other than AUTO are deprecated. I > > >removed that warning in HEAD Sunday, and there is no a discussion > > >about whether or not it should be put back, and whether or not there > > >is any need for the user to specify the list of network interfaces at > > >all. > > > > Well, I do. > > > > I only want to configure only the interfaces that are connected and > > that I know about. especially in combination with IPv6 there is a nit > > that you'll get autoconfiguration for all interfaces unless they are > > all explicitly configured. > > And while I'm not currently using anything other than AUTO I would think > there is a security ramification if someone were to plug in to a > supposedly unused port, then reboot the machine to prompt AUTO to > configure their interface. > > Its not just a security thing, its an "idiot-proof" thing. If someone is > moving machines around I don't want them to come up and partially work > if the wires are plugged into the wrong holes. Would rather it be > completely broken. > > I think its good that there is an AUTO *option*. Is also OK that it be > the default. I don't think mandatory AUTO is good, if I want a port > disabled then I want it to stay disabled. To repeat what I wrote earlier today on another list there's no need to worry about hot plugged or newly added interfaces getting magically configured to do dhcp or anything else[0]. For the system to do something with an interface the following must be true: - It makes it in to the list of interfaces somehow (either by adding it to network_interfaces or leaving network_interfaces alone) - It actually exists or is create early in the process via cloned_interfaces, gif_interfaces, etc - The ifconfig_ variable is set (I think i can be "", but "up" is always a good choice if you just want a stub. - The ifconfig_ variable must not contain the NOAUTO keyword. If all of those things are true, the interface will be configured at startup or on insert. Otherwise, it won't be. -- Brooks [0] This is at least true in the IPv4 case, the IPv6 case really needs work. I thought someone had patches to bring the IPv6 support up to par with the IPv4 case, but they haven't been committed yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090602/98afd370/attachment.pgp From brooks at freebsd.org Tue Jun 2 22:09:23 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 2 22:09:36 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> Message-ID: <20090602220933.GE15552@lor.one-eyed-alien.net> On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > >> Up till Sunday in 8-current, and for a long time in general >> network.subr (part of the rc.d system) has emitted a warning that >> values of network_interfaces other than AUTO are deprecated. I removed >> that warning in HEAD Sunday, and there is no a discussion about >> whether or not it should be put back, and whether or not there is any >> need for the user to specify the list of network interfaces at all. > > Well, I do. > > I only want to configure only the interfaces that are connected and that I > know about. especially in combination with IPv6 there is a nit that you'll > get autoconfiguration for all interfaces unless they are all explicitly > configured. See my other post on why this is a needless worry for the IPv4 case. > e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a > ipv6_ifconfig_bge1="down" and nail network_interfaces to bge0 bge1 lo0 only > I'll get autoconfiguration of v6 where I don't want it to be. > > > Being a bit of my own devils advocate here, network_interfaces="AUTO" is > already true for ipv6. with network_interfaces="bge0 lo0" network.subr > nevertheless sees bge1, and no configuration and takes the responsibility > of starting ipv6 autoconfiguration for it. The IPv6 case is clearly a bug. We should really consolidate the two cases and I think there are patches to do so if someone wants to setup up and help get them in. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090602/6b4126db/attachment.pgp From randy at psg.com Tue Jun 2 22:20:59 2009 From: randy at psg.com (Randy Bush) Date: Tue Jun 2 22:21:14 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> Message-ID: > I only want to configure only the interfaces that are connected and > that I know about. especially in combination with IPv6 there is a nit > that you'll get autoconfiguration for all interfaces unless they are > all explicitly configured. bingo! From randy at psg.com Tue Jun 2 22:22:35 2009 From: randy at psg.com (Randy Bush) Date: Tue Jun 2 22:22:57 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <20090602220624.GD15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> <20090602220624.GD15552@lor.one-eyed-alien.net> Message-ID: > To repeat what I wrote earlier today on another list there's no need > to worry about hot plugged or newly added interfaces getting magically > configured to do dhcp or anything else[0]. such as detected by services such as bind/unbound? randy From roberthuff at rcn.com Tue Jun 2 22:29:21 2009 From: roberthuff at rcn.com (Robert Huff) Date: Tue Jun 2 22:29:29 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: Message-ID: <18981.41237.246524.796@jerusalem.litteratus.org> Ruben van Staveren writes: > > Up till Sunday in 8-current, and for a long time in general > > network.subr (part of the rc.d system) has emitted a warning that > > values of network_interfaces other than AUTO are deprecated. I removed > > that warning in HEAD Sunday, and there is no a discussion about > > whether or not it should be put back, and whether or not there is any > > need for the user to specify the list of network interfaces at all. > > Well, I do. > > I only want to configure only the interfaces that are connected and > that I know about. What he said. In my case complicated by the fact the interfaces in question do some wierd-ass initialization (which is legacy from like sometime in 5.x and might be unnecessary ... but it took a long time to get working and isn't broke). Robert Huff From mcdouga9 at egr.msu.edu Tue Jun 2 22:32:52 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Tue Jun 2 22:33:00 2009 Subject: ZFS NAS configuration question In-Reply-To: References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> Message-ID: <4A25A892.80903@egr.msu.edu> I have a proof of concept system doing this. I started with a 7.2 install on zfs root, compiled world and kernel from 8, took a snapshot and made a clone for the 7.2 install, and proceeded to upgrade the current fs to 8.0. After updating the loader.conf in the 7.2 zfs to point to its own cloned fs, I can pick which one to boot with a simple "zpool set bootfs=z/ROOT/7.2" or "zpool set bootfs=z/ROOT/8.0" before rebooting. I also tried rsyncing from a FFS based system into a new ZFS in that same zpool, used DESTDIR with installkernel and installworld to update the imported OS to support zfs, setup its boot loader and misc config files, and was able to boot from it using zpool to set it as the bootfs. Somewhat like shifting around OS images in a virtualization environment except its easy to reach inside the "image" to upgrade/modify it, copy them between systems, and no execution overhead while running one since its still on bare metal (but only one running OS per server of course). This makes it very easy to swap an OS onto another server if you need better/lesser hardware or just want to test. Dan Naumov wrote: > This reminds me. I was reading the release and upgrade notes of OpenSolaris > 2009.6 and noted one thing about upgrading from a previous version to the > new one:: > > When you pick the "upgrade OS" option in the OpenSolaris installer, it will > check if you are using a ZFS root partition and if you do, it intelligently > suggests to take a current snapshot of the root filesystem. After you finish > the upgrade and do a reboot, the boot menu offers you the option of booting > the new upgraded version of the OS or alternatively _booting from the > snapshot taken by the upgrade installation procedure_. > > Reading that made me pause for a second and made me go "WOW", this is how > UNIX system upgrades should be done. Any hope of us lowly users ever seeing > something like this implemented in FreeBSD? :) > > - Dan Naumov > > > > > > On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox wrote: > > >> The system boots from a pair of drives in a gmirror. Mot because you can't >> boot from ZFS, but because it's just so darn stable (and it predates the use >> of ZFS). >> >> Really there are two camps here --- booting from ZFS is the use of ZFS as >> the machine's own filesystem. This is one goal of ZFS that is somewhat >> imperfect on FreeBSD at the momment. ZFS file servers are another goal >> where booting from ZFS is not really required and only marginally >> beneficial. >> >> >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From brooks at freebsd.org Tue Jun 2 22:48:42 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 2 22:48:55 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> <20090602220624.GD15552@lor.one-eyed-alien.net> Message-ID: <20090602224852.GF15552@lor.one-eyed-alien.net> On Wed, Jun 03, 2009 at 07:22:34AM +0900, Randy Bush wrote: > > To repeat what I wrote earlier today on another list there's no need > > to worry about hot plugged or newly added interfaces getting magically > > configured to do dhcp or anything else[0]. > > such as detected by services such as bind/unbound? The rc system will do nothing with interfaces that don't pass the tests I enumerated so if you don't have an ifconfig_ interface there won't be any difference no matter how you set network_interfaces. I'd be rather supprised if bind did anything with interaces that weren't configured with an address (or even up in the case of correctly funtioning drivers). -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090602/6187a5e1/attachment.pgp From freebsd-lists-erik at erikosterholm.org Tue Jun 2 23:26:36 2009 From: freebsd-lists-erik at erikosterholm.org (Erik Osterholm) Date: Tue Jun 2 23:26:43 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <4A257B82.1000701@FreeBSD.org> References: <4A257B82.1000701@FreeBSD.org> Message-ID: <20090602230648.GB88740@barragry.com> On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I > removed that warning in HEAD Sunday, and there is no a discussion > about whether or not it should be put back, and whether or not there > is any need for the user to specify the list of network interfaces > at all. > > If you use a value of network_interfaces other than AUTO please > speak up so that we can make an intelligent decision about this > issue. > > Thanks, > > Doug I'll have to preface this by disclosing that I have not been running -current, nor following any changes to the RC system. In 7.1, if you compile a custom kernel and comment out an interface (such that it is compiled as a module), one way to ensure that the module is loaded is to explicitly list it in network_interfaces. If -current works the same way, then users will be required to modify /boot/loader.conf in order to load the module. Could there could be possible side-effects to this change, since the loading of the module happens at a different time? At best, users doing things the 'network_interfaces' way may be in for a surprise when the update (remotely), and this may be worthy of a note in UPDATING. If this has changed in 7.2 or -current, then I apologize for the noise! Erik From dudu at dudu.ro Wed Jun 3 12:15:56 2009 From: dudu at dudu.ro (Vlad Galu) Date: Wed Jun 3 12:16:04 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP Message-ID: Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? Thanks, Vlad -------------- next part -------------- A non-text attachment was scrubbed... Name: poll.cpp Type: application/octet-stream Size: 1737 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090603/3d24343e/poll.obj From dudu at dudu.ro Wed Jun 3 12:25:37 2009 From: dudu at dudu.ro (Vlad Galu) Date: Wed Jun 3 12:25:44 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP In-Reply-To: References: Message-ID: Hm, according to the code at http://www.greenend.org.uk/rjk/2001/06/poll.html, it seems to work as expected (returning both POLLIN and POLLHUP), when closing the write end of the pipe from within the same process. On Wed, Jun 3, 2009 at 3:15 PM, Vlad Galu wrote: > Hello, > > Please take a look at the attached code. Shouldn't poll() get a > POLLHUP event when the child process exits, closing the write end of > the pipe? > > Thanks, > Vlad > From kostikbel at gmail.com Wed Jun 3 12:32:14 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jun 3 12:32:21 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP In-Reply-To: References: Message-ID: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: > Hello, > > Please take a look at the attached code. Shouldn't poll() get a > POLLHUP event when the child process exits, closing the write end of > the pipe? It seems that you code forgot to close the write end of the pipe in parent. Thus, pipe is referenced by another file descriptor from the parent process, and you do not get close event. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090603/d6f14751/attachment.pgp From dudu at dudu.ro Wed Jun 3 12:36:17 2009 From: dudu at dudu.ro (Vlad Galu) Date: Wed Jun 3 12:36:24 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP In-Reply-To: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> Message-ID: On Wed, Jun 3, 2009 at 3:32 PM, Kostik Belousov wrote: > On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: >> Hello, >> >> Please take a look at the attached code. Shouldn't poll() get a >> POLLHUP event when the child process exits, closing the write end of >> the pipe? > > It seems that you code forgot to close the write end of the pipe in > parent. Thus, pipe is referenced by another file descriptor from > the parent process, and you do not get close event. > Aaarhg! You're right! Sorry for the noise! From dudu at dudu.ro Wed Jun 3 13:10:56 2009 From: dudu at dudu.ro (Vlad Galu) Date: Wed Jun 3 13:11:07 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP In-Reply-To: References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> Message-ID: On Wed, Jun 3, 2009 at 3:35 PM, Vlad Galu wrote: > On Wed, Jun 3, 2009 at 3:32 PM, Kostik Belousov wrote: >> On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: >>> Hello, >>> >>> Please take a look at the attached code. Shouldn't poll() get a >>> POLLHUP event when the child process exits, closing the write end of >>> the pipe? >> >> It seems that you code forgot to close the write end of the pipe in >> parent. Thus, pipe is referenced by another file descriptor from >> the parent process, and you do not get close event. >> > > Aaarhg! You're right! Sorry for the noise! > Hm, I was having an issue with an internal piece of software, but never checked what kind of pipe caused the problem. Turns out it was a FIFO, and I got bitten by the same bug described here: http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html The problem is that the reader process isn't notified when the writer process exits or closes the FIFO fd... From lopez.on.the.lists at yellowspace.net Wed Jun 3 13:42:17 2009 From: lopez.on.the.lists at yellowspace.net (Lorenzo Perone) Date: Wed Jun 3 13:42:24 2009 Subject: ZFS booting without partitions In-Reply-To: References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <4A1B0B4F.1020106@h3q.com> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <63548432-B73D-4A08-BA99-FEF5BCC1028A@yellowspace.net> <20090531071759.GA35763@egr.msu.edu> Message-ID: <4CB9BD6A-EB09-4FF0-AC34-74CF36837381@yellowspace.net> OK, so I've got my next little adventure here to share :-) ... after reading Your posts I was very eager to give the whole boot-zfs-without-partitions thing a new try. My starting situation was a ZFS mirror made up, as I wrote, of two GPT partitions, so my pool looked like: phaedrus# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ad6p4 ONLINE 0 0 0 ad4p4 ONLINE 0 0 0 it was root-mounted and everything was seemingly working fine, with the machine surviving several bonnie++'s, sysbenches, and supersmacks concurrently for many hours (cool!). So to give it another try my plan was to detach one partition, clear the gmirror on the UFS boot partition, make a new pool made out of the free disk and start the experiment over. it looked almost like this: zpool offline tank ad4p4 zpool detach tank ad4p4 gmirror stop gmboot (made out of ad6p2 and ad4p2) gmirror remove gmboot ad4p2 then I had to reboot cause it wouldn't give up on the swap partition on the zpool. That's where the first problem began: it wouldn't boot anymore... just because I removed a device? In this case I was stuck at the mountroot: stage. It wouldn't find the root filesystem on zfs. (this happened also when physically detaching ad4). So I booted off a recent 8-CURRENT iso DVD, and although the mounroot stage is, iirc, at a later stage than the loader, I smelled it could have something to do with it and downloaded Adam's CURRENT/ZFS loader, put it in the appropriate place on my UFS boot partition... note: From the CD, I had to import the pool with zpool import -o altroot=/somewhere tank to avoid having problems with the datasets being mounted on top of the 8-fixit environment's /usr ... Ok, rebooted, and whoops it would boot again in the previous environment. So... from there I started over with the creation of a ZFS-bootonly situation on ad4 (with the intention of zpool-attaching ad6 later on) dd if=/dev/zero bs=1m of=/dev/ad4 count=200 (just to be safe, some 'whitespace'..) zpool create esso da4 zfs snapshot -r tank@night zfs send -R tank@night | zfs recv -d -F esso (it did what it had to do - cool new v13 feature BTW!) zpool export esso dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 dd if=/boot/zfsboot of=/dev/ad4 bs=512 skip=1 seek=1024 zpool import esso zpool set bootfs=esso esso the mountpoints (legacy on the poolfs, esso, and the corresponding ones) had been correctly copied by the send -R. Just shortly mounted esso somewhere else, edited loader.conf and fstab, and put it back to legacy. shutdown -r now. Upon boot, it would wait a while, not present any F1/F5, and booted into the old environment (ad6p2 boot partition and then mounted tank as root). From there, a zfs list or zpool status just showed the root pool (tank), but the new one (esso) was not present. A zpool import showed: heidegger# zpool import pool: esso id: 865609520845688328 state: UNAVAIL status: One or more devices are missing from the system. action: The pool cannot be imported. Attach the missing devices and try again. see: http://www.sun.com/msg/ZFS-8000-3C config: esso UNAVAIL insufficient replicas ad4 UNAVAIL cannot open zpool import -f esso did not succeed, instead, looking on the console, I found ZFS: WARNING: could not open ad4 for writing I repeated the steps above two more times, making sure I had wiped everyhing off ad4 before trying... but it would always come up with that message. The disk is OK, the cables too, I triple-checked it. Besides, writing to the disk with other means (such as dd or creating a new pool) succeeded... (albeit after the usual sysctl kern.geom.debugflags=16 ...) well for now I think I'll stick to the GPT + UFS Root + ZFS Root solution (I'm so happy this works seemlessly, so this is a big THANX and not a complaint!), but I thought I'd share the latest hickups... I won't be getting to that machine for a few days before restoring to the gpt-ufs-based mirror, so if someone would like me to provide other info I'll be happy to contribute it. Big Regards! Lorenzo On 01.06.2009, at 19:09, Lorenzo Perone wrote: > On 31.05.2009, at 09:18, Adam McDougall wrote: > >> I encountered the same symptoms today on both a 32bit and 64bit >> brand new install using gptzfsboot. It works for me when I use >> a copy of loader from an 8-current box with zfs support compiled in. >> I haven't looked into it much yet but it might help you. If you >> want, you can try the loader I am using from: >> http://www.egr.msu.edu/~mcdouga9/loader > > Thanx for posting me your loader, I'll try with this tomorrow night! > (any hint, btw, on why the one in -STABLE seems to be > broken, or whether it has actually been fixed by now?) From brooks at freebsd.org Wed Jun 3 14:13:13 2009 From: brooks at freebsd.org (Brooks Davis) Date: Wed Jun 3 14:13:26 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <20090602230648.GB88740@barragry.com> References: <4A257B82.1000701@FreeBSD.org> <20090602230648.GB88740@barragry.com> Message-ID: <20090603141321.GC28486@lor.one-eyed-alien.net> On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > Up till Sunday in 8-current, and for a long time in general > > network.subr (part of the rc.d system) has emitted a warning that > > values of network_interfaces other than AUTO are deprecated. I > > removed that warning in HEAD Sunday, and there is no a discussion > > about whether or not it should be put back, and whether or not there > > is any need for the user to specify the list of network interfaces > > at all. > > > > If you use a value of network_interfaces other than AUTO please > > speak up so that we can make an intelligent decision about this > > issue. > > > > Thanks, > > > > Doug > > I'll have to preface this by disclosing that I have not been running > -current, nor following any changes to the RC system. > > In 7.1, if you compile a custom kernel and comment out an interface > (such that it is compiled as a module), one way to ensure that the > module is loaded is to explicitly list it in network_interfaces. If > -current works the same way, then users will be required to modify > /boot/loader.conf in order to load the module. Could there could be > possible side-effects to this change, since the loading of the module > happens at a different time? Do you actually do this? > At best, users doing things the 'network_interfaces' way may be in for > a surprise when the update (remotely), and this may be worthy of a > note in UPDATING. > > If this has changed in 7.2 or -current, then I apologize for the > noise! The deprecation is a change relative to 7.0, but was in 7.1. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090603/ff4e3648/attachment.pgp From kostikbel at gmail.com Wed Jun 3 14:30:57 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jun 3 14:31:04 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP In-Reply-To: References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> Message-ID: <20090603143051.GM1927@deviant.kiev.zoral.com.ua> On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote: > Hm, I was having an issue with an internal piece of software, but > never checked what kind of pipe caused the problem. Turns out it was a > FIFO, and I got bitten by the same bug described here: > http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html > > The problem is that the reader process isn't notified when the writer > process exits or closes the FIFO fd... So you did found the relevant PR with long audit trail and patches attached. You obviously should contact the author of the patches, Oliver Fromme, who is FreeBSD committer for some time (CCed). I agree that the thing shall be fixed finally. Skimming over the patches in kern/94772, I have some doubts about removal of POLLINIGNEOF flag. The reason is that we are generally do not remove exposed user interfaces. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090603/8adf0343/attachment.pgp From cryx-freebsd at h3q.com Wed Jun 3 14:42:53 2009 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Wed Jun 3 14:43:04 2009 Subject: ZFS NAS configuration question In-Reply-To: References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> Message-ID: <4A268BEA.5040706@h3q.com> Dan Naumov wrote: > > Reading that made me pause for a second and made me go "WOW", this is how > UNIX system upgrades should be done. Any hope of us lowly users ever seeing > something like this implemented in FreeBSD? :) I wrote a script implementing the most useful features of the solaris live upgrade, the only thing missing is selecting a boot-environment from the loader and freebsd-update support as I write the script on a system running current. I use this on all my freebsd-zfs boxes and it is extremely useful! http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE greetings, philipp From ruben at verweg.com Wed Jun 3 14:48:28 2009 From: ruben at verweg.com (Ruben van Staveren) Date: Wed Jun 3 14:48:41 2009 Subject: On the topic of network_interfaces, optional full automatic renaming of interfaces Message-ID: Hi lists, Now the topic of network_interfaces has been mentioned, and the freeze for 8-stable is near I wonder if there is enough interest in the following feature to be included: http://ruben.is.verweg.com/stuff/freebsd/ifrename/ There is some dust there in that directory (It works, but is nowhere finished yet), but basically this early rc.d script takes the functionality of ifconfig_XXX_name a step further and enables optional automatic renaming of all ethernet capable interfaces, and enumerate them in the order probed by the kernel. A possible usage scenario is where you do massive imaging of a freebsd installation in where you don't know beforehand it will end up on hardware that has Broadcom or Intel NICs but it is for certain the cable will be connected to the first interface available and the same interface name can be referenced throughout all configuration files that need it (pf.conf, rc.conf(.local), /etc/rc.conf.d/network ) An other application usage is nailing down interface names using ethernet address, either because of correcting "mistakes" in the hardware (e.g. some Dell PowerEdges have the port labelled first to be probed as second and vice versa) or the necessity to only allow that interface to exist if it's MAC is the one that was configured (because of switch port ACL's) Regards, Ruben From dan.naumov at gmail.com Wed Jun 3 14:56:08 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Wed Jun 3 14:56:14 2009 Subject: ZFS NAS configuration question In-Reply-To: <4A268BEA.5040706@h3q.com> References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> <4A268BEA.5040706@h3q.com> Message-ID: Anyone else think that this combined with freebsd-update integration and a simplistic menu GUI for choosing the preferred boot environment would make an _awesome_ addition to the base system? :) - Dan Naumov On Wed, Jun 3, 2009 at 5:42 PM, Philipp Wuensche wrote: > I wrote a script implementing the most useful features of the solaris > live upgrade, the only thing missing is selecting a boot-environment > from the loader and freebsd-update support as I write the script on a > system running current. I use this on all my freebsd-zfs boxes and it is > extremely useful! > > http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE > > greetings, > philipp From kostikbel at gmail.com Wed Jun 3 15:07:15 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jun 3 15:07:22 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP In-Reply-To: <20090603143051.GM1927@deviant.kiev.zoral.com.ua> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> <20090603143051.GM1927@deviant.kiev.zoral.com.ua> Message-ID: <20090603150710.GN1927@deviant.kiev.zoral.com.ua> On Wed, Jun 03, 2009 at 05:30:51PM +0300, Kostik Belousov wrote: > On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote: > > Hm, I was having an issue with an internal piece of software, but > > never checked what kind of pipe caused the problem. Turns out it was a > > FIFO, and I got bitten by the same bug described here: > > http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html > > > > The problem is that the reader process isn't notified when the writer > > process exits or closes the FIFO fd... > > So you did found the relevant PR with long audit trail and patches > attached. You obviously should contact the author of the patches, > Oliver Fromme, who is FreeBSD committer for some time (CCed). > > I agree that the thing shall be fixed finally. Skimming over the > patches in kern/94772, I have some doubts about removal of > POLLINIGNEOF flag. The reason is that we are generally do not > remove exposed user interfaces. I forward-ported Bruce' patch to the CURRENT. It passes the tests from tools/regression/fifo and a test from kern/94772. For my liking, I did not removed POLLINIGNEOF. diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c index 66963bc..7e279ca 100644 --- a/sys/fs/fifofs/fifo_vnops.c +++ b/sys/fs/fifofs/fifo_vnops.c @@ -226,11 +226,47 @@ fail1: if (ap->a_mode & FREAD) { fip->fi_readers++; if (fip->fi_readers == 1) { + SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); + if (fip->fi_writers > 0) + fip->fi_readsock->so_rcv.sb_state |= + SBS_COULDRCV; + else + /* + * Sloppy? Might be necessary to clear it + * in all the places where fi_readers is + * decremented to 0. I think only writers + * polling for input could be confused by + * having it not set, and there is a problem + * with these anyway now that we have + * reversed the sense of the flag -- they + * now block (?), but shouldn't. + */ + fip->fi_readsock->so_rcv.sb_state &= + ~SBS_COULDRCV; + SOCKBUF_UNLOCK(&fip->fi_readsock->so_rcv); SOCKBUF_LOCK(&fip->fi_writesock->so_snd); fip->fi_writesock->so_snd.sb_state &= ~SBS_CANTSENDMORE; SOCKBUF_UNLOCK(&fip->fi_writesock->so_snd); if (fip->fi_writers > 0) { wakeup(&fip->fi_writers); + SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); + if (fip->fi_writers > 0) + fip->fi_readsock->so_rcv.sb_state |= + SBS_COULDRCV; + else + /* + * Sloppy? Might be necessary to clear it + * in all the places where fi_readers is + * decremented to 0. I think only writers + * polling for input could be confused by + * having it not set, and there is a problem + * with these anyway now that we have + * reversed the sense of the flag -- they + * now block (?), but shouldn't. + */ + fip->fi_readsock->so_rcv.sb_state &= + ~SBS_COULDRCV; + SOCKBUF_UNLOCK(&fip->fi_readsock->so_rcv); sowwakeup(fip->fi_writesock); } } @@ -244,6 +280,7 @@ fail1: if (fip->fi_writers == 1) { SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); fip->fi_readsock->so_rcv.sb_state &= ~SBS_CANTRCVMORE; + fip->fi_readsock->so_rcv.sb_state |= SBS_COULDRCV; SOCKBUF_UNLOCK(&fip->fi_readsock->so_rcv); if (fip->fi_readers > 0) { wakeup(&fip->fi_readers); @@ -672,28 +709,10 @@ fifo_poll_f(struct file *fp, int events, struct ucred *cred, struct thread *td) levents = events & (POLLIN | POLLINIGNEOF | POLLPRI | POLLRDNORM | POLLRDBAND); if ((fp->f_flag & FREAD) && levents) { - /* - * If POLLIN or POLLRDNORM is requested and POLLINIGNEOF is - * not, then convert the first two to the last one. This - * tells the socket poll function to ignore EOF so that we - * block if there is no writer (and no data). Callers can - * set POLLINIGNEOF to get non-blocking behavior. - */ - if (levents & (POLLIN | POLLRDNORM) && - !(levents & POLLINIGNEOF)) { - levents &= ~(POLLIN | POLLRDNORM); - levents |= POLLINIGNEOF; - } - filetmp.f_data = fip->fi_readsock; filetmp.f_cred = cred; - revents |= soo_poll(&filetmp, levents, cred, td); - - /* Reverse the above conversion. */ - if ((revents & POLLINIGNEOF) && !(events & POLLINIGNEOF)) { - revents |= (events & (POLLIN | POLLRDNORM)); - revents &= ~POLLINIGNEOF; - } + revents |= soo_poll(&filetmp, levents | (events & POLLPOLL), + cred, td); } levents = events & (POLLOUT | POLLWRNORM | POLLWRBAND); if ((fp->f_flag & FWRITE) && levents) { diff --git a/sys/kern/sys_generic.c b/sys/kern/sys_generic.c index 616c5b7..98ccc9e 100644 --- a/sys/kern/sys_generic.c +++ b/sys/kern/sys_generic.c @@ -1226,8 +1226,8 @@ pollscan(td, fds, nfd) * POLLERR if appropriate. */ selfdalloc(td, fds); - fds->revents = fo_poll(fp, fds->events, - td->td_ucred, td); + fds->revents = fo_poll(fp, + fds->events | POLLPOLL, td->td_ucred, td); if (fds->revents != 0) n++; } diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c index 7341d3f..a13d648 100644 --- a/sys/kern/uipc_socket.c +++ b/sys/kern/uipc_socket.c @@ -2706,6 +2706,42 @@ sopoll_generic(struct socket *so, int events, struct ucred *active_cred, if (sowriteable(so)) revents |= events & (POLLOUT | POLLWRNORM); + /* + * SBS_CANTRCVMORE (which is checked by soreadable()) normally + * implies EOF (and thus readable) and hung up, but for + * compatibility with other systems and to obtain behavior that + * is otherwise unavailable we make the case of poll() on a fifo + * that has never had any writers during the lifetime of any + * current reader special: then we pretend that the fifo is + * unreadable unless it contains non-null data, and that it is + * not hung up. The POLLPOLL flag is set by poll() to identify + * poll() here, and the SBS_COULDRCV flag is set by the fifo + * layer to indicate a fifo that is not in the special state. + */ + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { + if (!(events & POLLPOLL) || so->so_rcv.sb_state & SBS_COULDRCV) + revents |= POLLHUP; /* finish settings */ + else if (!(so->so_rcv.sb_cc >= so->so_rcv.sb_lowat || + !TAILQ_EMPTY(&so->so_comp) || so->so_error)) + revents &= ~(POLLIN | POLLRDNORM); /* undo settings */ + } + + /* + * Testing of hangup for writers could be optimized by combining + * it with testing for writeability, but we keep the test separate + * and with the same organization as the test for readers for + * clarity. Note that writeable implies not hung up, so if POLLHUP + * is set here then (POLLOUT | POLLWRNORM) is not set above, as + * standards require. Less obviously, if POLLHUP was set above for + * a reader, then the output flags cannot have been set above for + * a writer. Even less obviously, we cannot end up with both + * POLLHUP output flags set in revents after ORing the revents for + * the read and write socket in fifo_poll(). + */ + if (so->so_snd.sb_state & SBS_CANTSENDMORE) + revents |= POLLHUP; + + if (events & (POLLPRI | POLLRDBAND)) if (so->so_oobmark || (so->so_rcv.sb_state & SBS_RCVATMARK)) revents |= events & (POLLPRI | POLLRDBAND); diff --git a/sys/sys/poll.h b/sys/sys/poll.h index c955f32..cfd5f01 100644 --- a/sys/sys/poll.h +++ b/sys/sys/poll.h @@ -71,6 +71,10 @@ struct pollfd { #define POLLINIGNEOF 0x2000 /* like POLLIN, except ignore EOF */ #endif +#ifdef _KERNEL +#define POLLPOLL 0x8000 /* system call is actually poll() */ +#endif + /* * These events are set if they occur regardless of whether they were * requested. diff --git a/sys/sys/sockbuf.h b/sys/sys/sockbuf.h index b8e6699..0da4fa1 100644 --- a/sys/sys/sockbuf.h +++ b/sys/sys/sockbuf.h @@ -56,6 +56,7 @@ #define SBS_CANTSENDMORE 0x0010 /* can't send more data to peer */ #define SBS_CANTRCVMORE 0x0020 /* can't receive more data from peer */ #define SBS_RCVATMARK 0x0040 /* at mark on input */ +#define SBS_COULDRCV 0x0080 /* could receive previously (or now) */ struct mbuf; struct sockaddr; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090603/3036444f/attachment.pgp From aturetta at commit.it Wed Jun 3 16:36:56 2009 From: aturetta at commit.it (Angelo Turetta) Date: Wed Jun 3 16:37:04 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <4A257B82.1000701@FreeBSD.org> References: <4A257B82.1000701@FreeBSD.org> Message-ID: <4A26A239.5050608@commit.it> Doug Barton wrote: > If you use a value of network_interfaces other than AUTO please speak > up so that we can make an intelligent decision about this issue. Maybe I am wrong, setting network_interfaces is the way I found I had to use to be able to rename cloned interfaces. eg: network_interfaces="lo0 em0 dmz" ifconfig_em0="up" cloned_interfaces="vlan0" ifconfig_vlan0_name="dmz" ifconfig_dmz="192.168.34.129/24 vlan 2 vlandev em0" I seem to remember I had to put that 'dmz' in network_interfaces, to make everything happy at boot. I can do more tests if needed. Ciao, Angelo. From brooks at freebsd.org Wed Jun 3 20:05:10 2009 From: brooks at freebsd.org (Brooks Davis) Date: Wed Jun 3 20:05:16 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <4A26A239.5050608@commit.it> References: <4A257B82.1000701@FreeBSD.org> <4A26A239.5050608@commit.it> Message-ID: <20090603200459.GG28486@lor.one-eyed-alien.net> On Wed, Jun 03, 2009 at 06:18:01PM +0200, Angelo Turetta wrote: > Doug Barton wrote: >> If you use a value of network_interfaces other than AUTO please speak >> up so that we can make an intelligent decision about this issue. > > Maybe I am wrong, setting network_interfaces is the way I found I had to > use to be able to rename cloned interfaces. > > eg: > > network_interfaces="lo0 em0 dmz" > ifconfig_em0="up" > cloned_interfaces="vlan0" > > ifconfig_vlan0_name="dmz" > ifconfig_dmz="192.168.34.129/24 vlan 2 vlandev em0" > > I seem to remember I had to put that 'dmz' in network_interfaces, to make > everything happy at boot. I can do more tests if needed. Hmm, there might be a bug related to cloned interfaces and renaming. That should be easy to fix. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090603/bf0204c3/attachment.pgp From freebsd-lists-erik at erikosterholm.org Wed Jun 3 20:37:37 2009 From: freebsd-lists-erik at erikosterholm.org (Erik Osterholm) Date: Wed Jun 3 20:37:44 2009 Subject: Do you use a value other than AUTO for network_interfaces? In-Reply-To: <20090603141321.GC28486@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602230648.GB88740@barragry.com> <20090603141321.GC28486@lor.one-eyed-alien.net> Message-ID: <20090603203736.GA23840@barragry.com> On Wed, Jun 03, 2009 at 09:13:21AM -0500, Brooks Davis wrote: > On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > > Up till Sunday in 8-current, and for a long time in general > > > network.subr (part of the rc.d system) has emitted a warning > > > that values of network_interfaces other than AUTO are > > > deprecated. I removed that warning in HEAD Sunday, and there is > > > no a discussion about whether or not it should be put back, and > > > whether or not there is any need for the user to specify the > > > list of network interfaces at all. > > > > > > If you use a value of network_interfaces other than AUTO please > > > speak up so that we can make an intelligent decision about this > > > issue. > > > > > > Thanks, > > > > > > Doug > > > > I'll have to preface this by disclosing that I have not been > > running -current, nor following any changes to the RC system. > > > > In 7.1, if you compile a custom kernel and comment out an > > interface (such that it is compiled as a module), one way to > > ensure that the module is loaded is to explicitly list it in > > network_interfaces. If -current works the same way, then users > > will be required to modify /boot/loader.conf in order to load the > > module. Could there could be possible side-effects to this > > change, since the loading of the module happens at a different > > time? > > Do you actually do this? We do use modules for a number of machines instead of leaving the NIC driver compiled into the kernel. I think that the impetus for doing this involved a driver bug back in 6.1 which crashed the machine if it passed too much traffic. The thinking was that for future bugs, it would be easier and faster to ship off the kernel module, unload the old one, load the new one, and reconfigure the interface than to ship over a whole new kernel and reboot. We also used to have a couple of machines for which the vendor supplied NIC kernel modules, but I don't think that they're in use anymore. And yes, the machines use network_interfaces to load the modules, though I'm not arrogant enough to assume that this is the best way. Maybe it is worth considering changing ifconfig_$DRIVER to load the driver? Erik From brde at optusnet.com.au Wed Jun 3 20:42:33 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Jun 3 20:42:41 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP In-Reply-To: <20090603150710.GN1927@deviant.kiev.zoral.com.ua> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> <20090603143051.GM1927@deviant.kiev.zoral.com.ua> <20090603150710.GN1927@deviant.kiev.zoral.com.ua> Message-ID: <20090604030724.V1181@besplex.bde.org> On Wed, 3 Jun 2009, Kostik Belousov wrote: > On Wed, Jun 03, 2009 at 05:30:51PM +0300, Kostik Belousov wrote: >> On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote: >>> Hm, I was having an issue with an internal piece of software, but >>> never checked what kind of pipe caused the problem. Turns out it was a >>> FIFO, and I got bitten by the same bug described here: >>> http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html >>> >>> The problem is that the reader process isn't notified when the writer G>>> process exits or closes the FIFO fd... >> >> So you did found the relevant PR with long audit trail and patches >> attached. You obviously should contact the author of the patches, >> Oliver Fromme, who is FreeBSD committer for some time (CCed). >> >> I agree that the thing shall be fixed finally. Skimming over the >> patches in kern/94772, I have some doubts about removal of >> POLLINIGNEOF flag. The reason is that we are generally do not >> remove exposed user interfaces. Maybe, but this flag was not a documented interface, and too much ugliness might be required to preserve its behaviour bug-for-bug compatibly (the old buggy behaviour would probably be more wanted for compatibility than the strange behaviour given by this flag! > I forward-ported Bruce' patch to the CURRENT. It passes the tests > from tools/regression/fifo and a test from kern/94772. Thanks. I won't be committing it any time soon, so you should. I rewrote the test programs extensively (enclosed at the end) in Oct 2007 and updated the kernel patches to match. Please run the new tests to see if you are missing anything important in the kernel part. If so, I will search for the kernel patches later (actually, now -- enclosed in the middle). I just ran them under RELENG_7 and unpatched -current and found no differences with the Oct 2007 version for RELENG_7 in the old test output. The old test output is in the following subdirectories: 4: FreeBSD-4 7: FreeBSD-7 l: Linux-2.6.10 m: my version of FreeBSD-5.2 including patches for this problem. AFAIR, the FreeBSD output in "m" is the same as the Linux output in all except a couple of cases where Linux select is inconsistent with itself and/or with Linux poll. However, the differences in the saved output are that the Linux output is mysteriously missing results for tests 5-8. The tests attempt to test certain race possibilities in a non-racy way. This is not easy and the differences might be due to some races/states not occurring under Linux. POSIX finally specified the behaviour strictly enough for it to be possible to test it a couple of years ago. I didn't follow all the developments and forget the details, but it was close to the Linux behaviour. > For my liking, I did not removed POLLINIGNEOF. > > diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c > index 66963bc..7e279ca 100644 > --- a/sys/fs/fifofs/fifo_vnops.c > +++ b/sys/fs/fifofs/fifo_vnops.c > @@ -226,11 +226,47 @@ fail1: > if (ap->a_mode & FREAD) { > fip->fi_readers++; > if (fip->fi_readers == 1) { > + SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); > + if (fip->fi_writers > 0) > + fip->fi_readsock->so_rcv.sb_state |= > + SBS_COULDRCV; My current version is in fact completely different. It doesn't have SBS_COULDRCV, but uses a generation count. IIRC, this is the same method as is used in Linux, and is needed for the same reasons (something to do with keeping new "connections" separate from old ones). So I will try to enclose the components of the patch in the order of your diff (might miss some). First one: % Index: fifo_vnops.c % =================================================================== % RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v % retrieving revision 1.100 % diff -u -2 -r1.100 fifo_vnops.c % --- fifo_vnops.c 23 Jun 2004 00:35:50 -0000 1.100 % +++ fifo_vnops.c 17 Oct 2007 11:36:23 -0000 % @@ -36,4 +36,5 @@ % #include % #include % +#include % #include % #include % @@ -61,4 +62,5 @@ % long fi_readers; % long fi_writers; % + int fi_wgen; % }; % % @@ -182,8 +184,11 @@ % struct ucred *a_cred; % struct thread *a_td; % + int a_fdidx; % } */ *ap; % { % struct vnode *vp = ap->a_vp; % struct fifoinfo *fip; % + struct file *fp; % + struct filedesc *fdp; % struct thread *td = ap->a_td; % struct ucred *cred = ap->a_cred; % @@ -240,4 +245,10 @@ % } % } % + fdp = td->td_proc->p_fd; % + FILEDESC_LOCK(fdp); % + fp = fget_locked(fdp, ap->a_fdidx); % + /* Abuse f_msgcount as a generation count. */ % + fp->f_msgcount = fip->fi_wgen - fip->fi_writers; % + FILEDESC_UNLOCK(fdp); % } % if (ap->a_mode & FWRITE) { % @@ -248,10 +259,10 @@ % fip->fi_writers++; % if (fip->fi_writers == 1) { % - SOCKBUF_LOCK(&fip->fi_writesock->so_rcv); % + SOCKBUF_LOCK(&fip->fi_readsock->so_rcv); % fip->fi_readsock->so_rcv.sb_state &= ~SBS_CANTRCVMORE; % - SOCKBUF_UNLOCK(&fip->fi_writesock->so_rcv); % + SOCKBUF_UNLOCK(&fip->fi_readsock->so_rcv); % if (fip->fi_readers > 0) { % wakeup(&fip->fi_readers); % - sorwakeup(fip->fi_writesock); % + sorwakeup(fip->fi_readsock); % } % } % @@ -588,6 +599,8 @@ % if (ap->a_fflag & FWRITE) { % fip->fi_writers--; % - if (fip->fi_writers == 0) % + if (fip->fi_writers == 0) { % socantrcvmore(fip->fi_readsock); % + fip->fi_wgen++; % + } % } % fifo_cleanup(vp); % @@ -669,2 +682,28 @@ % return (ap->a_flags & F_FLOCK ? EOPNOTSUPP : EINVAL); % } % + % +fo_poll_t fifo_poll_f; % +int % +fifo_poll_f(struct file *fp, int events, struct ucred *cred, struct thread *td) % +{ % + struct file filetmp; % + struct fifoinfo *fip; % + int levents, revents = 0; % + % + fip = fp->f_vnode->v_fifoinfo; % + levents = events & (POLLIN | POLLPRI | POLLRDNORM | POLLRDBAND); % + if (levents) { % + filetmp.f_data = fip->fi_readsock; % + filetmp.f_cred = fp->f_cred; % + if (fp->f_msgcount == fip->fi_wgen) % + levents |= POLLINIGNEOF; % + revents |= soo_poll(&filetmp, levents, cred, td); % + } % + levents = events & (POLLOUT | POLLWRNORM | POLLWRBAND); % + if (levents) { % + filetmp.f_data = fip->fi_writesock; % + filetmp.f_cred = fp->f_cred; % + revents |= soo_poll(&filetmp, levents, cred, td); % + } + return (revents); +} Large parts of this (the existence of fifo_poll_f()...) are already in -current -- I copied them from -current to fix a critical bug. The above version of fifo_poll_f() is essentially much simpler. It still uses POLLINIGNEOF but sets it better using the generation counts. I don't remember why f_msgcount is abused as a generation count instead of adding a second generation count; probably it needs to go in `struct file' and I didn't want to edit file.h and/or bloat `struct file'. > diff --git a/sys/kern/sys_generic.c b/sys/kern/sys_generic.c > index 616c5b7..98ccc9e 100644 > --- a/sys/kern/sys_generic.c > +++ b/sys/kern/sys_generic.c > @@ -1226,8 +1226,8 @@ pollscan(td, fds, nfd) > * POLLERR if appropriate. > */ > selfdalloc(td, fds); > - fds->revents = fo_poll(fp, fds->events, > - td->td_ucred, td); > + fds->revents = fo_poll(fp, > + fds->events | POLLPOLL, td->td_ucred, td); > if (fds->revents != 0) > n++; > } I now seem to have only style fixes in pollscan() and selscan(). I don't need POLLPOLL. IIRC, the more intelligent/state-dependent setting of POLLINIGNEOF handles this for fifos, while different treatments work better for nameless pipes and sockets. The following is for nameless pipes: % Index: sys_pipe.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v % retrieving revision 1.171 % diff -u -2 -r1.171 sys_pipe.c % --- sys_pipe.c 27 Mar 2004 19:50:22 -0000 1.171 % +++ sys_pipe.c 16 Oct 2007 07:18:55 -0000 % @@ -1296,6 +1295,5 @@ % if (events & (POLLIN | POLLRDNORM)) % if ((rpipe->pipe_state & PIPE_DIRECTW) || % - (rpipe->pipe_buffer.cnt > 0) || % - (rpipe->pipe_state & PIPE_EOF)) % + (rpipe->pipe_buffer.cnt > 0)) % revents |= events & (POLLIN | POLLRDNORM); % POLLHUP will be set a little later if PIPE_EOF, and it is at best confusing for PIPE_EOF to imply POLLIN and POLLRDNORM (especially, "normal input"). I now vaguely remember that the differences with Linux are in this area. IIRC, the above makes nameless pipes behave like fifos in Linux (and now in FreeBSD), while nameless pipes behave differently from fifos in Linux. The tests assert that POLLIN and POLLHUP are set when there is EOF and (previously buffered) data to read, and that POLLIN becomes clear on reading the data. This is also be related to the longstanding bug in gdb -- "echo 'print 0' | gdb" exits before reading any input because it sees POLLIN | POLLHUP and thinks that POLLHUP implies no more input. poll() is hard to use unless it clears POLLIN once the input is read, and gdb-6.1 still doesn't understand how to use poll() whether or not poll() does the wrong thing here. gdb used to work OK using select(): With select(), there is nothing like POLLHUP and select() returns the equivalent of POLLIN for EOF with no data; then the reader must try a read() and hope that a read() of 0 means EOF. With broken poll(), readers must try a read similarly since they can't trust POLLIN if POLLHUP is also set. With non-broken poll(), they can trust POLLIN and not quit until poll() returns only POLLHUP. The tests describe this with different details. > diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c > index 7341d3f..a13d648 100644 > --- a/sys/kern/uipc_socket.c > +++ b/sys/kern/uipc_socket.c > @@ -2706,6 +2706,42 @@ sopoll_generic(struct socket *so, int events, struct ucred *active_cred, > if (sowriteable(so)) > revents |= events & (POLLOUT | POLLWRNORM); > > + /* > + * SBS_CANTRCVMORE (which is checked by soreadable()) normally > + * implies EOF (and thus readable) and hung up, but for > + * compatibility with other systems and to obtain behavior that > + * is otherwise unavailable we make the case of poll() on a fifo > + * that has never had any writers during the lifetime of any > + * current reader special: then we pretend that the fifo is > + * unreadable unless it contains non-null data, and that it is > + * not hung up. The POLLPOLL flag is set by poll() to identify > + * poll() here, and the SBS_COULDRCV flag is set by the fifo > + * layer to indicate a fifo that is not in the special state. > + */ > + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { > + if (!(events & POLLPOLL) || so->so_rcv.sb_state & SBS_COULDRCV) > + revents |= POLLHUP; /* finish settings */ > + else if (!(so->so_rcv.sb_cc >= so->so_rcv.sb_lowat || > + !TAILQ_EMPTY(&so->so_comp) || so->so_error)) > + revents &= ~(POLLIN | POLLRDNORM); /* undo settings */ > + } > + > + /* > + * Testing of hangup for writers could be optimized by combining > + * it with testing for writeability, but we keep the test separate > + * and with the same organization as the test for readers for > + * clarity. Note that writeable implies not hung up, so if POLLHUP > + * is set here then (POLLOUT | POLLWRNORM) is not set above, as > + * standards require. Less obviously, if POLLHUP was set above for > + * a reader, then the output flags cannot have been set above for > + * a writer. Even less obviously, we cannot end up with both > + * POLLHUP output flags set in revents after ORing the revents for > + * the read and write socket in fifo_poll(). > + */ > + if (so->so_snd.sb_state & SBS_CANTSENDMORE) > + revents |= POLLHUP; > + > + > if (events & (POLLPRI | POLLRDBAND)) > if (so->so_oobmark || (so->so_rcv.sb_state & SBS_RCVATMARK)) > revents |= events & (POLLPRI | POLLRDBAND); My version is only subtly different from the above (except it doesn't add any comments -- not sure why). It uses a soreadable1() macro instead of getting tangled up trying to use soreadable(): % Index: uipc_socket.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v % retrieving revision 1.189 % diff -u -2 -r1.189 uipc_socket.c % --- uipc_socket.c 24 Jun 2004 04:28:30 -0000 1.189 % +++ uipc_socket.c 17 Oct 2007 10:44:50 -0000 % @@ -1862,4 +1860,8 @@ % } % % +#define soreadable1(so) \ % + ((so)->so_rcv.sb_cc >= (so)->so_rcv.sb_lowat || \ % + !TAILQ_EMPTY(&(so)->so_comp) || (so)->so_error) % + % int % sopoll(struct socket *so, int events, struct ucred *active_cred, % @@ -1869,12 +1871,7 @@ % % if (events & (POLLIN | POLLRDNORM)) % - if (soreadable(so)) % + if (soreadable1(so)) % revents |= events & (POLLIN | POLLRDNORM); % % - if (events & POLLINIGNEOF) % - if (so->so_rcv.sb_cc >= so->so_rcv.sb_lowat || % - !TAILQ_EMPTY(&so->so_comp) || so->so_error) % - revents |= POLLINIGNEOF; % - % if (events & (POLLOUT | POLLWRNORM)) % if (sowriteable(so)) % @@ -1885,8 +1882,12 @@ % revents |= events & (POLLPRI | POLLRDBAND); % % + if ((events & POLLINIGNEOF) == 0) % + if (so->so_rcv.sb_state & SBS_CANTRCVMORE) % + revents |= POLLHUP; % + if (so->so_rcv.sb_state & SBS_CANTSENDMORE) % + revents |= POLLHUP; % + % if (revents == 0) { % - if (events & % - (POLLIN | POLLINIGNEOF | POLLPRI | POLLRDNORM | % - POLLRDBAND)) { % + if (events & (POLLIN | POLLPRI | POLLRDNORM | POLLRDBAND)) { % SOCKBUF_LOCK(&so->so_rcv); % selrecord(td, &so->so_rcv.sb_sel); > diff --git a/sys/sys/poll.h b/sys/sys/poll.h > index c955f32..cfd5f01 100644 > --- a/sys/sys/poll.h > +++ b/sys/sys/poll.h > @@ -71,6 +71,10 @@ struct pollfd { > #define POLLINIGNEOF 0x2000 /* like POLLIN, except ignore EOF */ > #endif > > +#ifdef _KERNEL > +#define POLLPOLL 0x8000 /* system call is actually poll() */ > +#endif > + > /* > * These events are set if they occur regardless of whether they were > * requested. I don't have any changes here (still have POLLINIGNEOF). > diff --git a/sys/sys/sockbuf.h b/sys/sys/sockbuf.h > index b8e6699..0da4fa1 100644 > --- a/sys/sys/sockbuf.h > +++ b/sys/sys/sockbuf.h > @@ -56,6 +56,7 @@ > #define SBS_CANTSENDMORE 0x0010 /* can't send more data to peer */ > #define SBS_CANTRCVMORE 0x0020 /* can't receive more data from peer */ > #define SBS_RCVATMARK 0x0040 /* at mark on input */ > +#define SBS_COULDRCV 0x0080 /* could receive previously (or now) */ > > struct mbuf; > struct sockaddr; > I still had this patch, but no references to SBS_COULDRCV. Now I don't have it :-). Now for the test programs: #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh './4/pipeselect.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected clear; got clear Xok 2 Pipe state 5: expected set; got set Xok 3 Pipe state 6: expected set; got set Xok 4 Pipe state 6a: expected set; got set Xok 5 Sock state 4: expected clear; got clear Xok 6 Sock state 5: expected set; got set Xok 7 Sock state 6: expected set; got set Xok 8 Sock state 6a: expected set; got set Xnot ok 9 FIFO state 0: expected clear; got set Xok 10 FIFO state 1: expected clear; got clear Xok 11 FIFO state 2: expected set; got set Xok 12 FIFO state 2a: expected clear; got clear Xok 13 FIFO state 3: expected set; got set Xok 14 FIFO state 4: expected clear; got clear Xok 15 FIFO state 5: expected set; got set Xok 16 FIFO state 6: expected set; got set Xok 17 FIFO state 6a: expected set; got set Xnot ok 18 FIFO state 6b: expected clear; got set Xok 19 FIFO state 6c: expected set; got set Xok 20 FIFO state 6d: expected set; got set END_OF_FILE if test 957 -ne `wc -c <'./4/pipeselect.out'`; then echo shar: \"'./4/pipeselect.out'\" unpacked with wrong size! fi # end of './4/pipeselect.out' fi if test -f './4/pipepoll.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./4/pipepoll.out'\" else echo shar: Extracting \"'./4/pipepoll.out'\" \(1049 characters\) sed "s/^X//" >'./4/pipepoll.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected 0; got 0 Xok 2 Pipe state 5: expected POLLIN; got POLLIN Xok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xnot ok 4 Pipe state 6a: expected POLLHUP; got POLLIN | POLLHUP Xok 5 Sock state 4: expected 0; got 0 Xok 6 Sock state 5: expected POLLIN; got POLLIN Xnot ok 7 Sock state 6: expected POLLIN | POLLHUP; got POLLIN Xnot ok 8 Sock state 6a: expected POLLHUP; got POLLIN Xnot ok 9 FIFO state 0: expected 0; got POLLIN Xok 10 FIFO state 1: expected 0; got 0 Xok 11 FIFO state 2: expected POLLIN; got POLLIN Xok 12 FIFO state 2a: expected 0; got 0 Xnot ok 13 FIFO state 3: expected POLLHUP; got POLLIN Xok 14 FIFO state 4: expected 0; got 0 Xok 15 FIFO state 5: expected POLLIN; got POLLIN Xnot ok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN Xnot ok 17 FIFO state 6a: expected POLLHUP; got POLLIN Xnot ok 18 FIFO state 6b: expected 0; got POLLIN Xnot ok 19 FIFO state 6c: expected POLLHUP; got POLLIN Xnot ok 20 FIFO state 6d: expected POLLHUP; got POLLIN END_OF_FILE if test 1049 -ne `wc -c <'./4/pipepoll.out'`; then echo shar: \"'./4/pipepoll.out'\" unpacked with wrong size! fi # end of './4/pipepoll.out' fi if test -f './pipepoll.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./pipepoll.c'\" else echo shar: Extracting \"'./pipepoll.c'\" \(5929 characters\) sed "s/^X//" >'./pipepoll.c' <<'END_OF_FILE' X#include X#include X#include X X#include X#include X#include X#include X#include X#include X X#define FIFONAME "fifo.tmp" X#define FT_END 3 X#define FT_FIFO 2 X#define FT_PIPE 0 X#define FT_SOCKETPAIR 1 X Xstatic int filetype; X Xstatic const char * Xdecode_events(int events) X{ X char *ncresult; X const char *result; X X switch (events) { X case POLLIN: X result = "POLLIN"; X break; X case POLLHUP: X result = "POLLHUP"; X break; X case POLLIN | POLLHUP: X result = "POLLIN | POLLHUP"; X break; X default: X asprintf(&ncresult, "%#x", events); X result = ncresult; X break; X } X return (result); X} X Xstatic void Xreport(int num, const char *state, int expected, int got) X{ X if (expected == got) X printf("ok %-2d ", num); X else X printf("not ok %-2d", num); X printf(" %s state %s: expected %s; got %s\n", X filetype == FT_PIPE ? "Pipe" : X filetype == FT_SOCKETPAIR ? "Sock" : "FIFO", X state, decode_events(expected), decode_events(got)); X fflush(stdout); X} X Xstatic pid_t cpid; Xstatic pid_t ppid; Xstatic volatile sig_atomic_t state; X Xstatic void Xcatch(int sig) X{ X state++; X} X Xstatic void Xchild(int fd, int num) X{ X struct pollfd pfd; X int fd2; X char buf[256]; X X if (filetype == FT_FIFO) { X fd = open(FIFONAME, O_RDONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for read"); X } X pfd.fd = fd; X pfd.events = POLLIN; X X if (filetype == FT_FIFO) { X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "0", 0, pfd.revents); X } X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 1) X ; X if (filetype != FT_FIFO) { X /* X * The connection cannot be restablished. Use the code that X * delays the read until after the writer disconnects since X * that case is more interesting. X */ X state = 4; X goto state4; X } X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "1", 0, pfd.revents); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 2) X ; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "2", POLLIN, pfd.revents); X if (read(fd, buf, sizeof buf) != 1) X err(1, "read"); X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "2a", 0, pfd.revents); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 3) X ; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "3", POLLHUP, pfd.revents); X kill(ppid, SIGUSR1); X X /* X * Now we expect a new writer, and a new connection too since X * we read all the data. The only new point is that we didn't X * start quite from scratch since the read fd is not new. Check X * startup state as above, but don't do the read as above. X */ X usleep(1); X while (state != 4) X ; Xstate4: X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "4", 0, pfd.revents); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 5) X ; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "5", POLLIN, pfd.revents); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 6) X ; X /* X * Now we have no writer, but should still have data from the old X * writer. Check that we have both a data condition and a hangup X * condition, and that the data can read the data in the usual way. X * Since Linux does this, programs must not quit reading when they X * see POLLHUP; they must see POLLHUP without POLLIN (or another X * input condition) before they decide that there is EOF. gdb-6.1.1 X * is an example of a broken program that quits on POLLHUP only -- X * see its event-loop.c. X */ X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6", POLLIN | POLLHUP, pfd.revents); X if (read(fd, buf, sizeof buf) != 1) X err(1, "read"); X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6a", POLLHUP, pfd.revents); X if (filetype == FT_FIFO) { X /* X * Check that POLLHUP is not seen by new readers but is X * still seen by old readers. X */ X fd2 = open(FIFONAME, O_RDONLY | O_NONBLOCK); X if (fd2 < 0) X err(1, "open for read"); X pfd.fd = fd2; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6b", 0, pfd.revents); X pfd.fd = fd; X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6c", POLLHUP, pfd.revents); X close(fd2); X if (poll(&pfd, 1, 0) < 0) X err(1, "poll"); X report(num++, "6d", POLLHUP, pfd.revents); X } X close(fd); X kill(ppid, SIGUSR1); X X exit(0); X} X Xstatic void Xparent(int fd) X{ X usleep(1); X while (state != 1) X ; X if (filetype == FT_FIFO) { X fd = open(FIFONAME, O_WRONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for write"); X } X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 2) X ; X if (write(fd, "", 1) != 1) X err(1, "write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 3) X ; X if (close(fd) != 0) X err(1, "close for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 4) X ; X if (filetype != FT_FIFO) X return; X fd = open(FIFONAME, O_WRONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 5) X ; X if (write(fd, "", 1) != 1) X err(1, "write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 6) X ; X if (close(fd) != 0) X err(1, "close for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 7) X ; X} X Xint Xmain(void) X{ X int fd[2], num; X X num = 1; X printf("1..20\n"); X fflush(stdout); X signal(SIGUSR1, catch); X ppid = getpid(); X for (filetype = 0; filetype < FT_END; filetype++) { X switch (filetype) { X case FT_FIFO: X if (mkfifo(FIFONAME, 0666) != 0) X err(1, "mkfifo"); X fd[0] = -1; X fd[1] = -1; X break; X case FT_SOCKETPAIR: X if (socketpair(AF_UNIX, SOCK_STREAM, AF_UNSPEC, X fd) != 0) X err(1, "socketpair"); X break; X case FT_PIPE: X if (pipe(fd) != 0) X err(1, "pipe"); X break; X } X state = 0; X switch (cpid = fork()) { X case -1: X err(1, "fork"); X case 0: X (void)close(fd[1]); X child(fd[0], num); X break; X default: X (void)close(fd[0]); X parent(fd[1]); X break; X } X num += filetype == FT_FIFO ? 12 : 4; X } X (void)unlink(FIFONAME); X return (0); X} END_OF_FILE if test 5929 -ne `wc -c <'./pipepoll.c'`; then echo shar: \"'./pipepoll.c'\" unpacked with wrong size! fi # end of './pipepoll.c' fi if test -f './pipeselect.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./pipeselect.c'\" else echo shar: Extracting \"'./pipeselect.c'\" \(6476 characters\) sed "s/^X//" >'./pipeselect.c' <<'END_OF_FILE' X#include X#include X#include X X#include X#include X#include X#include X#include X#include X X#define FIFONAME "fifo.tmp" X#define FT_END 3 X#define FT_FIFO 2 X#define FT_PIPE 0 X#define FT_SOCKETPAIR 1 X X#define SETUP(fd, rfds, tv) do { \ X FD_ZERO(&(rfds)); \ X FD_SET((fd), &(rfds)); \ X (tv).tv_sec = 0; \ X (tv).tv_usec = 0; \ X} while (0) X Xstatic int filetype; X Xstatic const char * Xdecode_events(int events) X{ X return (events ? "set" : "clear"); X} X Xstatic void Xreport(int num, const char *state, int expected, int got) X{ X if (!expected == !got) X printf("ok %-2d ", num); X else X printf("not ok %-2d", num); X printf(" %s state %s: expected %s; got %s\n", X filetype == FT_PIPE ? "Pipe" : X filetype == FT_SOCKETPAIR ? "Sock" : "FIFO", X state, decode_events(expected), decode_events(got)); X fflush(stdout); X} X Xstatic pid_t cpid; Xstatic pid_t ppid; Xstatic volatile sig_atomic_t state; X Xstatic void Xcatch(int sig) X{ X state++; X} X Xstatic void Xchild(int fd, int num) X{ X fd_set rfds; X struct timeval tv; X int fd1, fd2; X char buf[256]; X X if (filetype == FT_FIFO) { X fd = open(FIFONAME, O_RDONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for read"); X } X if (fd >= FD_SETSIZE) X errx(1, "fd = %d too large for select()", fd); X X if (filetype == FT_FIFO) { X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "0", 0, FD_ISSET(fd, &rfds)); X } X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 1) X ; X if (filetype != FT_FIFO) { X /* X * The connection cannot be restablished. Use the code that X * delays the read until after the writer disconnects since X * that case is more interesting. X */ X state = 4; X goto state4; X } X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "1", 0, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 2) X ; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "2", 1, FD_ISSET(fd, &rfds)); X if (read(fd, buf, sizeof buf) != 1) X err(1, "read"); X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "2a", 0, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 3) X ; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "3", 1, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X /* X * Now we expect a new writer, and a new connection too since X * we read all the data. The only new point is that we didn't X * start quite from scratch since the read fd is not new. Check X * startup state as above, but don't do the read as above. X */ X usleep(1); X while (state != 4) X ; Xstate4: X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "4", 0, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 5) X ; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "5", 1, FD_ISSET(fd, &rfds)); X kill(ppid, SIGUSR1); X X usleep(1); X while (state != 6) X ; X /* X * Now we have no writer, but should still have data from the old X * writer. Check that we have both a data condition and a hangup X * condition, and that the data can read the data in the usual way. X * Since Linux does this, programs must not quit reading when they X * see POLLHUP; they must see POLLHUP without POLLIN (or another X * input condition) before they decide that there is EOF. gdb-6.1.1 X * is an example of a broken program that quits on POLLHUP only -- X * see its event-loop.c. X */ X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6", 1, FD_ISSET(fd, &rfds)); X if (read(fd, buf, sizeof buf) != 1) X err(1, "read"); X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6a", 1, FD_ISSET(fd, &rfds)); X if (filetype == FT_FIFO) { X /* X * Check that POLLHUP is not seen by new readers but is X * still seen by old readers. X */ X fd2 = open(FIFONAME, O_RDONLY | O_NONBLOCK); X if (fd2 < 0) X err(1, "open for read"); X fd1 = fd; X fd = fd2; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6b", 0, FD_ISSET(fd, &rfds)); X fd = fd1; X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6c", 1, FD_ISSET(fd, &rfds)); X close(fd2); X SETUP(fd, rfds, tv); X if (select(fd + 1, &rfds, NULL, NULL, &tv) < 0) X err(1, "select"); X report(num++, "6d", 1, FD_ISSET(fd, &rfds)); X } X close(fd); X kill(ppid, SIGUSR1); X X exit(0); X} X Xstatic void Xparent(int fd) X{ X usleep(1); X while (state != 1) X ; X if (filetype == FT_FIFO) { X fd = open(FIFONAME, O_WRONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for write"); X } X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 2) X ; X if (write(fd, "", 1) != 1) X err(1, "write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 3) X ; X if (close(fd) != 0) X err(1, "close for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 4) X ; X if (filetype != FT_FIFO) X return; X fd = open(FIFONAME, O_WRONLY | O_NONBLOCK); X if (fd < 0) X err(1, "open for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 5) X ; X if (write(fd, "", 1) != 1) X err(1, "write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 6) X ; X if (close(fd) != 0) X err(1, "close for write"); X kill(cpid, SIGUSR1); X X usleep(1); X while (state != 7) X ; X} X Xint Xmain(void) X{ X int fd[2], num; X X num = 1; X printf("1..20\n"); X fflush(stdout); X signal(SIGUSR1, catch); X ppid = getpid(); X for (filetype = 0; filetype < FT_END; filetype++) { X switch (filetype) { X case FT_FIFO: X if (mkfifo(FIFONAME, 0666) != 0) X err(1, "mkfifo"); X fd[0] = -1; X fd[1] = -1; X break; X case FT_SOCKETPAIR: X if (socketpair(AF_UNIX, SOCK_STREAM, AF_UNSPEC, X fd) != 0) X err(1, "socketpair"); X break; X case FT_PIPE: X if (pipe(fd) != 0) X err(1, "pipe"); X break; X } X state = 0; X switch (cpid = fork()) { X case -1: X err(1, "fork"); X case 0: X (void)close(fd[1]); X child(fd[0], num); X break; X default: X (void)close(fd[0]); X parent(fd[1]); X break; X } X num += filetype == FT_FIFO ? 12 : 4; X } X (void)unlink(FIFONAME); X return (0); X} END_OF_FILE if test 6476 -ne `wc -c <'./pipeselect.c'`; then echo shar: \"'./pipeselect.c'\" unpacked with wrong size! fi # end of './pipeselect.c' fi if test -f './m/pipeselect.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./m/pipeselect.out'\" else echo shar: Extracting \"'./m/pipeselect.out'\" \(961 characters\) sed "s/^X//" >'./m/pipeselect.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected clear; got clear Xok 2 Pipe state 5: expected set; got set Xok 3 Pipe state 6: expected set; got set Xok 4 Pipe state 6a: expected set; got set Xok 5 Sock state 4: expected clear; got clear Xok 6 Sock state 5: expected set; got set Xok 7 Sock state 6: expected set; got set Xok 8 Sock state 6a: expected set; got set Xok 9 FIFO state 0: expected clear; got clear Xok 10 FIFO state 1: expected clear; got clear Xok 11 FIFO state 2: expected set; got set Xok 12 FIFO state 2a: expected clear; got clear Xok 13 FIFO state 3: expected set; got set Xok 14 FIFO state 4: expected clear; got clear Xok 15 FIFO state 5: expected set; got set Xok 16 FIFO state 6: expected set; got set Xok 17 FIFO state 6a: expected set; got set Xok 18 FIFO state 6b: expected clear; got clear Xok 19 FIFO state 6c: expected set; got set Xok 20 FIFO state 6d: expected set; got set END_OF_FILE if test 961 -ne `wc -c <'./m/pipeselect.out'`; then echo shar: \"'./m/pipeselect.out'\" unpacked with wrong size! fi # end of './m/pipeselect.out' fi if test -f './m/pipepoll.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./m/pipepoll.out'\" else echo shar: Extracting \"'./m/pipepoll.out'\" \(1055 characters\) sed "s/^X//" >'./m/pipepoll.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected 0; got 0 Xok 2 Pipe state 5: expected POLLIN; got POLLIN Xok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 4 Pipe state 6a: expected POLLHUP; got POLLHUP Xok 5 Sock state 4: expected 0; got 0 Xok 6 Sock state 5: expected POLLIN; got POLLIN Xok 7 Sock state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 8 Sock state 6a: expected POLLHUP; got POLLHUP Xok 9 FIFO state 0: expected 0; got 0 Xok 10 FIFO state 1: expected 0; got 0 Xok 11 FIFO state 2: expected POLLIN; got POLLIN Xok 12 FIFO state 2a: expected 0; got 0 Xok 13 FIFO state 3: expected POLLHUP; got POLLHUP Xok 14 FIFO state 4: expected 0; got 0 Xok 15 FIFO state 5: expected POLLIN; got POLLIN Xok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 17 FIFO state 6a: expected POLLHUP; got POLLHUP Xok 18 FIFO state 6b: expected 0; got 0 Xok 19 FIFO state 6c: expected POLLHUP; got POLLHUP Xok 20 FIFO state 6d: expected POLLHUP; got POLLHUP END_OF_FILE if test 1055 -ne `wc -c <'./m/pipepoll.out'`; then echo shar: \"'./m/pipepoll.out'\" unpacked with wrong size! fi # end of './m/pipepoll.out' fi if test -f './7/pipeselect.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./7/pipeselect.out'\" else echo shar: Extracting \"'./7/pipeselect.out'\" \(969 characters\) sed "s/^X//" >'./7/pipeselect.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected clear; got clear Xok 2 Pipe state 5: expected set; got set Xok 3 Pipe state 6: expected set; got set Xok 4 Pipe state 6a: expected set; got set Xok 5 Sock state 4: expected clear; got clear Xok 6 Sock state 5: expected set; got set Xok 7 Sock state 6: expected set; got set Xok 8 Sock state 6a: expected set; got set Xok 9 FIFO state 0: expected clear; got clear Xok 10 FIFO state 1: expected clear; got clear Xok 11 FIFO state 2: expected set; got set Xok 12 FIFO state 2a: expected clear; got clear Xnot ok 13 FIFO state 3: expected set; got clear Xok 14 FIFO state 4: expected clear; got clear Xok 15 FIFO state 5: expected set; got set Xok 16 FIFO state 6: expected set; got set Xnot ok 17 FIFO state 6a: expected set; got clear Xok 18 FIFO state 6b: expected clear; got clear Xnot ok 19 FIFO state 6c: expected set; got clear Xnot ok 20 FIFO state 6d: expected set; got clear END_OF_FILE if test 969 -ne `wc -c <'./7/pipeselect.out'`; then echo shar: \"'./7/pipeselect.out'\" unpacked with wrong size! fi # end of './7/pipeselect.out' fi if test -f './7/pipepoll.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./7/pipepoll.out'\" else echo shar: Extracting \"'./7/pipepoll.out'\" \(1019 characters\) sed "s/^X//" >'./7/pipepoll.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected 0; got 0 Xok 2 Pipe state 5: expected POLLIN; got POLLIN Xok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xnot ok 4 Pipe state 6a: expected POLLHUP; got POLLIN | POLLHUP Xok 5 Sock state 4: expected 0; got 0 Xok 6 Sock state 5: expected POLLIN; got POLLIN Xnot ok 7 Sock state 6: expected POLLIN | POLLHUP; got POLLIN Xnot ok 8 Sock state 6a: expected POLLHUP; got POLLIN Xok 9 FIFO state 0: expected 0; got 0 Xok 10 FIFO state 1: expected 0; got 0 Xok 11 FIFO state 2: expected POLLIN; got POLLIN Xok 12 FIFO state 2a: expected 0; got 0 Xnot ok 13 FIFO state 3: expected POLLHUP; got 0 Xok 14 FIFO state 4: expected 0; got 0 Xok 15 FIFO state 5: expected POLLIN; got POLLIN Xnot ok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN Xnot ok 17 FIFO state 6a: expected POLLHUP; got 0 Xok 18 FIFO state 6b: expected 0; got 0 Xnot ok 19 FIFO state 6c: expected POLLHUP; got 0 Xnot ok 20 FIFO state 6d: expected POLLHUP; got 0 END_OF_FILE if test 1019 -ne `wc -c <'./7/pipepoll.out'`; then echo shar: \"'./7/pipepoll.out'\" unpacked with wrong size! fi # end of './7/pipepoll.out' fi if test -f './Makefile' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./Makefile'\" else echo shar: Extracting \"'./Makefile'\" \(494 characters\) sed "s/^X//" >'./Makefile' <<'END_OF_FILE' X# This makefile has been uglified for portability. X# Nothing yet works with gmake for the path to the sources. X.PATH: .. X XPROG= pipepoll pipeselect XCFLAGS+= -Werror -Wall X Xall: ${PROG} Xpipepoll: pipepoll.c Xpipeselect: pipeselect.c X Xpipepoll pipeselect: X ${CC} ${CFLAGS} ${LDFLAGS} -o $@ $@.c X Xtest: all X -for prog in ${PROG}; do \ X ./$${prog} > $${prog}.out.new; \ X diff -u1 $${prog}.out $${prog}.out.new; \ X done X Xclean: X for prog in ${PROG}; do \ X rm -f $${prog} $${prog}.out.new; \ X done END_OF_FILE if test 494 -ne `wc -c <'./Makefile'`; then echo shar: \"'./Makefile'\" unpacked with wrong size! fi # end of './Makefile' fi if test -f './l/pipepoll.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./l/pipepoll.out'\" else echo shar: Extracting \"'./l/pipepoll.out'\" \(834 characters\) sed "s/^X//" >'./l/pipepoll.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected 0; got 0 Xok 2 Pipe state 5: expected POLLIN; got POLLIN Xok 3 Pipe state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 4 Pipe state 6a: expected POLLHUP; got POLLHUP Xok 9 FIFO state 0: expected 0; got 0 Xok 10 FIFO state 1: expected 0; got 0 Xok 11 FIFO state 2: expected POLLIN; got POLLIN Xok 12 FIFO state 2a: expected 0; got 0 Xok 13 FIFO state 3: expected POLLHUP; got POLLHUP Xok 14 FIFO state 4: expected 0; got 0 Xok 15 FIFO state 5: expected POLLIN; got POLLIN Xok 16 FIFO state 6: expected POLLIN | POLLHUP; got POLLIN | POLLHUP Xok 17 FIFO state 6a: expected POLLHUP; got POLLHUP Xok 18 FIFO state 6b: expected 0; got 0 Xok 19 FIFO state 6c: expected POLLHUP; got POLLHUP Xok 20 FIFO state 6d: expected POLLHUP; got POLLHUP END_OF_FILE if test 834 -ne `wc -c <'./l/pipepoll.out'`; then echo shar: \"'./l/pipepoll.out'\" unpacked with wrong size! fi # end of './l/pipepoll.out' fi if test -f './l/pipeselect.out' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'./l/pipeselect.out'\" else echo shar: Extracting \"'./l/pipeselect.out'\" \(772 characters\) sed "s/^X//" >'./l/pipeselect.out' <<'END_OF_FILE' X1..20 Xok 1 Pipe state 4: expected clear; got clear Xok 2 Pipe state 5: expected set; got set Xok 3 Pipe state 6: expected set; got set Xok 4 Pipe state 6a: expected set; got set Xok 9 FIFO state 0: expected clear; got clear Xok 10 FIFO state 1: expected clear; got clear Xok 11 FIFO state 2: expected set; got set Xok 12 FIFO state 2a: expected clear; got clear Xok 13 FIFO state 3: expected set; got set Xok 14 FIFO state 4: expected clear; got clear Xok 15 FIFO state 5: expected set; got set Xok 16 FIFO state 6: expected set; got set Xok 17 FIFO state 6a: expected set; got set Xok 18 FIFO state 6b: expected clear; got clear Xok 19 FIFO state 6c: expected set; got set Xok 20 FIFO state 6d: expected set; got set END_OF_FILE if test 772 -ne `wc -c <'./l/pipeselect.out'`; then echo shar: \"'./l/pipeselect.out'\" unpacked with wrong size! fi # end of './l/pipeselect.out' fi echo shar: End of shell archive. exit 0 Bruce From delphij at delphij.net Wed Jun 3 22:56:27 2009 From: delphij at delphij.net (Xin LI) Date: Wed Jun 3 22:56:35 2009 Subject: mini-HEADSUP bce owners: please test Message-ID: <4A26FF44.3040609@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, David and I have committed some fixes to 7-STABLE tree, and I think all important bce(4) fixes has been merged now. If you have bce(4) interfaces PLEASE help us to test them, the simplest way of doing this is to sync your code with RELENG_7 and rebuild kernel. [1] For those who can't test this under 7-STABLE environment, I have extracted corresponding files here: http://people.freebsd.org/~delphij/misc/193358.tar.bz2 Once can extract the tarball over /usr/src/ in order to overwrite your files, this should be applicable for a 7.2-RELEASE system. Known issues that this should have resolved: - "PHY write timeout!" when you can find "ukphy" in your dmesg output, some blade servers [Dell T610?] may have this, in particular; - incorrect input traffic accounting. (netstat 1 would show larger input traffic); - under heavy load there might be some data corruption; Please let us know if these changes would bring any regressions, thanks a lot! [1] Please note that, because bce(4) is part of GENERIC kernel so you may need to do a full "make kernel" instead of just rebuilding/installing corresponding kernel module. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkom/0QACgkQi+vbBBjt66DPzwCfSpPZ+nCJcyjcrFwfZuWSCcyl anIAoKQN/jpn45pjS/jG2jR6dsjIWbhs =Eng2 -----END PGP SIGNATURE----- From petefrench at ticketswitch.com Wed Jun 3 23:04:06 2009 From: petefrench at ticketswitch.com (Pete French) Date: Wed Jun 3 23:04:15 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: <4A26FF44.3040609@delphij.net> Message-ID: > David and I have committed some fixes to 7-STABLE tree, and I think all > important bce(4) fixes has been merged now. If you have bce(4) > interfaces PLEASE help us to test them, the simplest way of doing this > is to sync your code with RELENG_7 and rebuild kernel. [1] I won't have timer to try this until friday at the earliest, but one question... is this likely to fix my infamous lagg/lacp issue ? I notice it isn't in the list of known issues. I will test anyway, but if you happen to be in that bit of code.... *does best winning smile* :-) -pete. From delphij at delphij.net Wed Jun 3 23:19:16 2009 From: delphij at delphij.net (Xin LI) Date: Wed Jun 3 23:19:23 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: References: Message-ID: <4A27049E.8040102@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pete French wrote: >> David and I have committed some fixes to 7-STABLE tree, and I think all >> important bce(4) fixes has been merged now. If you have bce(4) >> interfaces PLEASE help us to test them, the simplest way of doing this >> is to sync your code with RELENG_7 and rebuild kernel. [1] > > I won't have timer to try this until friday at the earliest, but one > question... is this likely to fix my infamous lagg/lacp issue ? I > notice it isn't in the list of known issues. I will test anyway, but s/known issue/known and fixed issue/ ... > if you happen to be in that bit of code.... *does best winning smile* :-) I am not quite sure about the lagg/lacp issue, perhaps we need more clue like tcpdump compare between old code and new code, as I don't have a switch capable for lacp setup at hand at this moment :( Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkonBJ4ACgkQi+vbBBjt66DXLwCdGAw0UFfrVYmNDTlwpbCnfMsm clMAoLrv0APr2//LiWCbTuS31qbzpsBz =Om0W -----END PGP SIGNATURE----- From davidch at broadcom.com Thu Jun 4 00:46:34 2009 From: davidch at broadcom.com (David Christensen) Date: Thu Jun 4 00:46:43 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: References: <4A26FF44.3040609@delphij.net> Message-ID: <5D267A3F22FD854F8F48B3D2B523819339DFEA2BC0@IRVEXCHCCR01.corp.ad.broadcom.com> > > David and I have committed some fixes to 7-STABLE tree, and I think > > all important bce(4) fixes has been merged now. If you have bce(4) > > interfaces PLEASE help us to test them, the simplest way of > doing this > > is to sync your code with RELENG_7 and rebuild kernel. [1] > > I won't have timer to try this until friday at the earliest, > but one question... is this likely to fix my infamous > lagg/lacp issue ? I notice it isn't in the list of known > issues. I will test anyway, but if you happen to be in that > bit of code.... *does best winning smile* :-) That should be the packet length fix at line 5973 of if_bce.c. I did not test the teaming fix myself but another user provided a similar packet length fix which he claimed did fix the issue so I'm hopeful that this should work for you too. Dave From reply at moneybookers.com Thu Jun 4 00:53:04 2009 From: reply at moneybookers.com (www.moneybookers.com) Date: Thu Jun 4 00:53:21 2009 Subject: Update Account. Message-ID: <20090604003428.2E5722EB1874@h1603454.stratoserver.net> ********************************************************************** ******************** THIS IS AN AUTOMATED EMAIL - . ********************************************************************** ******************** Dear Moneybookers Customer,: Due to concerns, for the safety and integrity of the Moneybookers.com account we have issued this warning message. It has come to our attention that your Moneybookers.com account information needs to be updated as part of our continuing commitment to protect your account and to reduce the instance of fraud on our website. If you could please take 5-10 minutes out of your online experience and update your personal records you will not run into any future problems with the online service. Once you have updated your account records your Moneybookers.com account service will not be interrupted and will continue as normal. To update your Moneybookers.com records click on the following link: [1]http://Moneybookers.com/ Moneybookers Security Reminders Case Sensitive Login Please remember your password is case-sensitive, at least 6 characters long and contains at least one number or non-alphabetic character such as '-'. ******************************* Moneybookers Ltd., London, Registered in England and Wales no 4260907. Registered office: Welken House, 10-11 Charterhouse Square, London, EC1M 6EH, United Kingdom. Authorised and regulated by the Financial Services Authority of the United Kingdom (FSA). References 1. http://www.protocolinfogate.com/moneybookers/directory.php?app=login.pl From allnetgroup at yahoo.com Thu Jun 4 03:51:11 2009 From: allnetgroup at yahoo.com (AES) Date: Thu Jun 4 05:03:48 2009 Subject: latest stable version of FreeBSD? Message-ID: <647359.51078.qm@web34304.mail.mud.yahoo.com> Where can I download the latest stable version of FreeBSD? From glen.j.barber at gmail.com Thu Jun 4 05:49:07 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Thu Jun 4 05:49:13 2009 Subject: latest stable version of FreeBSD? In-Reply-To: <647359.51078.qm@web34304.mail.mud.yahoo.com> References: <647359.51078.qm@web34304.mail.mud.yahoo.com> Message-ID: <4ad871310906032249v1a88e71frd535b45a998f7633@mail.gmail.com> On Wed, Jun 3, 2009 at 11:24 PM, AES wrote: > Where can I download the latest stable version of FreeBSD? http://www.freebsd.org/where.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ -- Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber From petefrench at ticketswitch.com Thu Jun 4 09:50:55 2009 From: petefrench at ticketswitch.com (Pete French) Date: Thu Jun 4 09:52:11 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819339DFEA2BC0@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: > That should be the packet length fix at line 5973 of if_bce.c. I did That's the patch whcih was sent to the PR, yes ? I've tried that and it doesn't fix it at all for me unfortunately. > not test the teaming fix myself but another user provided a similar > packet length fix which he claimed did fix the issue so I'm hopeful > that this should work for you too. I'll tgive this new lot of code a test tomorrow (am in London all day today unfortunately) and let you knwo the results. cheers, -pete. From petefrench at ticketswitch.com Thu Jun 4 10:33:50 2009 From: petefrench at ticketswitch.com (Pete French) Date: Thu Jun 4 10:33:57 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819339DFEA2BC0@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: Well, I found time to test this today after all - and it does actually fix the issue - my bce devices now work properly with lagg and lacp. thankyou! -pete. From cryx-freebsd at h3q.com Thu Jun 4 11:39:04 2009 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Thu Jun 4 11:39:12 2009 Subject: manageBE and ZFS boot-environments WAS [Re: ZFS NAS configuration question] In-Reply-To: References: <8B50CE3F-FCC5-42D6-8FFE-591178F3DFB6@ish.com.au> <5f67a8c40906021147h48bc1c36y5de42fdc0d18677e@mail.gmail.com> <4A268BEA.5040706@h3q.com> Message-ID: <4A27B255.8010500@h3q.com> Dan Naumov wrote: > Anyone else think that this combined with freebsd-update integration > and a simplistic menu GUI for choosing the preferred boot environment > would make an _awesome_ addition to the base system? :) I guess freebsd-update is not a problem, should be "freebsd-update -b ". But I can't test this, because I can't update STABLE with freebsd-update. ;-) I wrote a small step-by-step example to show how stuff works: http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/example.txt greetings, philipp From davidch at broadcom.com Thu Jun 4 15:00:25 2009 From: davidch at broadcom.com (David Christensen) Date: Thu Jun 4 15:00:36 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: References: <5D267A3F22FD854F8F48B3D2B523819339DFEA2BC0@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <5D267A3F22FD854F8F48B3D2B523819339DFF5F3D4@IRVEXCHCCR01.corp.ad.broadcom.com> > Well, I found time to test this today after all - and it does > actually fix the issue - my bce devices now work properly > with lagg and lacp. Thanks for the confirmation. Dave From tim at chase2k.com Thu Jun 4 15:05:39 2009 From: tim at chase2k.com (Tim Chase) Date: Thu Jun 4 15:05:47 2009 Subject: kmem map too small panic after updating to STABLE-7 r192996 Message-ID: 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 , 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 From aturetta at commit.it Thu Jun 4 15:25:20 2009 From: aturetta at commit.it (Angelo Turetta) Date: Thu Jun 4 15:25:28 2009 Subject: floppy unusable in VMWare guest? Message-ID: <4A27E757.1040104@commit.it> I'm trying to use a virtual floppy from FreeBSD 7 (both 7-STABLE and 7_2_RELEASE) in a VMWare test installation. Both running fdformat on a fresh floppy image and trying to mount a preformatted one, I get errors like: g_vfs_done():fd0[READ(offset=0, length=8192)]error = 6 Of course, after booting the same VM with a DOS live CD, the floppy is perfectly functional. I found a reference in a vmware forum post (some three years old), does anybody know if this is supposed to work? http://communities.vmware.com/thread/51022 Thanks, Angelo From aturetta at commit.it Thu Jun 4 18:28:46 2009 From: aturetta at commit.it (Angelo Turetta) Date: Thu Jun 4 18:29:28 2009 Subject: kmem map too small panic after updating to STABLE-7 r192996 In-Reply-To: References: Message-ID: <4A281250.5050306@commit.it> Tim Chase 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. I just had the same problem, and it turned out I was not diligent when I first set my zfs pool up :) To use vm.kmem_size="512M" you need to put options KVA_PAGES=512 in your kernel. I remember trying the loader.conf settings on a GENERIC kernel, found it worked and forgot to add KVA_PAGES. It seems that recently the memory allocated by a ZFS kernel on startup has become larger than the default KVA_PAGES in GENERIC. Hope this helps, Angelo Turetta From ben at wanderview.com Thu Jun 4 19:15:16 2009 From: ben at wanderview.com (Ben Kelly) Date: Thu Jun 4 19:15:22 2009 Subject: kmem map too small panic after updating to STABLE-7 r192996 In-Reply-To: References: Message-ID: <3B36D8F8-7325-49A3-9F1F-42326C661E6D@wanderview.com> On Jun 4, 2009, at 10:48 AM, Tim Chase wrote: > vm.kmem_size="512M" > vm.kmem_size_max="512M" > vfs.zfs.arc_max="100M" > $1 = 0xc0792320 "kmem_malloc(131072): kmem_map too small: 325656576 > total allocated" It looks like you are suffering from fragmentation of your kmem address space. I've done some investigation of this on -current: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=909067+0+archive/2009/freebsd-current/20090503.freebsd-current The patch linked from that mail allows me to run with an untuned ARC size with kmem of 512 MB. It does this, however, by more aggressively limiting how the ARC grows so it doesn't need to trigger its aggressive memory reclamation algorithm. I haven't tested this patch against -stable or with Kip's more recent changes so I don't know if it will apply cleanly for you. I've had some luck avoiding the fragmentation by changing ZFS to use a separate memory pool with a 128KB slab allocator, but this isn't really ready for general usage. Unfortunately I've been quite busy at work lately and haven't had time to work on it in a few weeks. I think with the current code base your only options are to increase your kmem maximum or limit your ARC even further. I hope that helps. - Ben From kmacy at freebsd.org Thu Jun 4 21:13:45 2009 From: kmacy at freebsd.org (Kip Macy) Date: Thu Jun 4 21:13:52 2009 Subject: kmem map too small panic after updating to STABLE-7 r192996 In-Reply-To: References: Message-ID: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> 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 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 , > 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-unsubscribe@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 From delphij at delphij.net Thu Jun 4 21:22:06 2009 From: delphij at delphij.net (Xin LI) Date: Thu Jun 4 21:22:13 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: References: Message-ID: <4A283A91.6050304@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Pete, Pete French wrote: > Well, I found time to test this today after all - and it does actually > fix the issue - my bce devices now work properly with lagg and lacp. So can we claim that the problem has been solved? Could you please give us a copy of output from 'ident /sys/dev/bce/* /sys/dev/mii/miidev /sys/dev/mii/brgphy*'? Thanks a lot! Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkooOpAACgkQi+vbBBjt66AfmACgiBt6eFHw8FKb5ePxrHemUgQh PUoAoJGN/rDDoROe6s7mW3PRWNHtOOzr =ukF3 -----END PGP SIGNATURE----- From petefrench at ticketswitch.com Thu Jun 4 21:48:41 2009 From: petefrench at ticketswitch.com (Pete French) Date: Thu Jun 4 21:48:48 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: <4A283A91.6050304@delphij.net> Message-ID: > So can we claim that the problem has been solved? Could you please give > us a copy of output from 'ident /sys/dev/bce/* /sys/dev/mii/miidev > /sys/dev/mii/brgphy*'? Yes, it looks very much that way. I've no idea what changed to fix it, but it is certainly working now on my test machine. I will try a rollout to my other machines over the next few days. Here is the ident output: [webadmin@florentine ~]$ ident /sys/dev/bce/* /sys/dev/mii/miidevs /sys/dev/mii/brgphy* /sys/dev/bce/if_bce.c: $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.34.2.9 2009/06/01 10:49:08 delphij Exp $ /sys/dev/bce/if_bcefw.h: $FreeBSD: src/sys/dev/bce/if_bcefw.h,v 1.4.2.2 2009/03/31 01:01:01 delphij Exp $ /sys/dev/bce/if_bcereg.h: $FreeBSD: src/sys/dev/bce/if_bcereg.h,v 1.16.2.3 2009/05/20 21:13:49 delphij Exp $ /sys/dev/mii/miidevs: $FreeBSD: src/sys/dev/mii/miidevs,v 1.46.2.11 2009/06/02 23:30:02 davidch Exp $ $NetBSD: miidevs,v 1.6 1999/05/14 11:37:30 drochner Exp $ /sys/dev/mii/brgphy.c: $FreeBSD: src/sys/dev/mii/brgphy.c,v 1.70.2.6 2009/06/02 23:30:02 davidch Exp $ /sys/dev/mii/brgphyreg.h: $FreeBSD: src/sys/dev/mii/brgphyreg.h,v 1.10.2.1 2008/06/27 03:24:54 jhb Exp $ cheers, -pete. From kmacy at freebsd.org Thu Jun 4 21:58:16 2009 From: kmacy at freebsd.org (Kip Macy) Date: Thu Jun 4 21:58:26 2009 Subject: kmem map too small panic after updating to STABLE-7 r192996 In-Reply-To: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> References: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> Message-ID: <3c1674c90906041458i19fd589fs2f03b3e7064209ca@mail.gmail.com> On Thu, Jun 4, 2009 at 2:13 PM, Kip Macy 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 From tim at chase2k.com Thu Jun 4 22:14:44 2009 From: tim at chase2k.com (Tim Chase) Date: Thu Jun 4 22:14:55 2009 Subject: kmem map too small panic after updating to STABLE-7 r192996 In-Reply-To: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> References: <3c1674c90906041413n15e2ce88q9f279818641515e7@mail.gmail.com> Message-ID: On Thu, 4 Jun 2009, Kip Macy wrote: > As I mentioned in the initial e-mail, auto-tuning is only safe to rely > on on amd64. OK, that wasn't clear to me with the latest zfs code. I'll try it with a proper 512M setting as I was using before (along with setting KVA_PAGES). - Tim From tim at chase2k.com Thu Jun 4 22:46:41 2009 From: tim at chase2k.com (Tim Chase) Date: Thu Jun 4 22:46:47 2009 Subject: kmem map too small panic after updating to STABLE-7 r192996 In-Reply-To: <4A281250.5050306@commit.it> References: <4A281250.5050306@commit.it> Message-ID: On Thu, 4 Jun 2009, Angelo Turetta wrote: > Tim Chase 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. > > I just had the same problem, and it turned out I was not diligent when I > first set my zfs pool up :) > > To use vm.kmem_size="512M" you need to put > > options KVA_PAGES=512 >... Thanks for the reminder. I had forgotten about this one, too. With my kmem size @ 512M now and with KVA_PAGES at 512, my svn test case works just fine. I guess I should have paid closer attention to the actual panic message. - Tim From lynx.ripe at gmail.com Fri Jun 5 00:37:02 2009 From: lynx.ripe at gmail.com (Dmitry Pryanishnikov) Date: Fri Jun 5 00:37:09 2009 Subject: Inconsistent checkout results for RELENG_7 at exact date Message-ID: <754a9c140906041705x6719afd4nd672ffa15975d2ac@mail.gmail.com> Hello! I'm trying to check out the FreeBSD source tree with the tag=RELENG_7 in the same state that it had at the exact date/time, e.g. 2009-05-04 18:00 UTC. So I'm using the following supfile: *default host=cvsup.ua.freebsd.org *default base=/root/sup/base *default delete use-rel-suffix compress *default release=cvs *default prefix=/usr/ftp/RELENG_7 tag=RELENG_7 date=2009.05.04.18.00.00 src-all I am starting with empty /usr/ftp/RELENG_7/src. However I am consistently (with both csup and cvsup) getting files that weren't in RELENG_7 at the specified time, e.g. src/cddl/usr.bin/zinject/Makefile (it was MFCed only 2009-05-20!). What am I doing wrong? -- Sincerely, Dmitry nic-hdl: LYNX-RIPE From uqs at spoerlein.net Fri Jun 5 08:44:26 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Fri Jun 5 08:44:34 2009 Subject: ZFS weird device tasting loop since MFC In-Reply-To: <20090602092408.GF93344@acme.spoerlein.net> References: <20090602091610.GE93344@acme.spoerlein.net> <20090602092408.GF93344@acme.spoerlein.net> Message-ID: <20090605084423.GA1609@acme.spoerlein.net> 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) > > > > root@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: > > root@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: root@coyote:/# zpool online tank da0.eli root@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 root@coyote:/# zpool offline tank da0.eli root@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 root@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 with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P 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 339 0 2.20M resilvered errors: No known data errors root@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 So I ran 'zpool status' thrice after the offline, and the second one reports write errors on the OFFLINE device (WTF?). Running zpool status in a loop, this will constantly show up and then vanish again. I also get constant write requests to the remaining device, even though no applications are accessing it. What the hell is ZFS trying to do here? root@coyote:/# zpool iostat 1 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- tank 883G 48.4G 8 246 56.8K 1.53M tank 883G 48.4G 8 249 55.9K 1.55M tank 883G 48.4G 8 250 55.0K 1.54M tank 883G 48.4G 8 252 54.1K 1.56M tank 883G 48.4G 8 254 53.3K 1.57M tank 883G 48.4G 8 253 52.5K 1.56M tank 883G 48.4G 7 255 51.7K 1.57M ^C Again, WTF? Can someone please enlighten me here? Cheers, Ulrich Sp?rlein -- http://www.dubistterrorist.de/ From kmacy at freebsd.org Fri Jun 5 11:28:40 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri Jun 5 11:28:48 2009 Subject: ZFS weird device tasting loop since MFC In-Reply-To: <20090605084423.GA1609@acme.spoerlein.net> References: <20090602091610.GE93344@acme.spoerlein.net> <20090602092408.GF93344@acme.spoerlein.net> <20090605084423.GA1609@acme.spoerlein.net> Message-ID: <3c1674c90906050428mafb5760gc706e879193345e0@mail.gmail.com> 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?rlein 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) >> > >> > root@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: >> >> root@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: > > root@coyote:/# zpool online tank da0.eli > root@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 > root@coyote:/# zpool offline tank da0.eli > root@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 > root@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 with 'zpool replace'. > ? see: http://www.sun.com/msg/ZFS-8000-9P > ?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 ? 339 ? ? 0 ?2.20M resilvered > > errors: No known data errors > root@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 > > > So I ran 'zpool status' thrice after the offline, and the second one reports > write errors on the OFFLINE device (WTF?). Running zpool status in a loop, this > will constantly show up and then vanish again. > > I also get constant write requests to the remaining device, even though no > applications are accessing it. What the hell is ZFS trying to do here? > > root@coyote:/# zpool iostat 1 > ? ? ? ? ? ? ? capacity ? ? operations ? ?bandwidth > pool ? ? ? ? used ?avail ? read ?write ? read ?write > ---------- ?----- ?----- ?----- ?----- ?----- ?----- > tank ? ? ? ? 883G ?48.4G ? ? ?8 ? ?246 ?56.8K ?1.53M > tank ? ? ? ? 883G ?48.4G ? ? ?8 ? ?249 ?55.9K ?1.55M > tank ? ? ? ? 883G ?48.4G ? ? ?8 ? ?250 ?55.0K ?1.54M > tank ? ? ? ? 883G ?48.4G ? ? ?8 ? ?252 ?54.1K ?1.56M > tank ? ? ? ? 883G ?48.4G ? ? ?8 ? ?254 ?53.3K ?1.57M > tank ? ? ? ? 883G ?48.4G ? ? ?8 ? ?253 ?52.5K ?1.56M > tank ? ? ? ? 883G ?48.4G ? ? ?7 ? ?255 ?51.7K ?1.57M > ^C > > Again, WTF? Can someone please enlighten me here? > > Cheers, > Ulrich Sp?rlein > -- > http://www.dubistterrorist.de/ > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From dan.naumov at gmail.com Fri Jun 5 11:40:14 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Fri Jun 5 11:40:21 2009 Subject: sponsoring ZFS development on FreeBSD Message-ID: Hello Kip, since your name comes up wherever I look about ZFS development on FreeBSD, I thought to send this mail to you directly as well. My question is concerning sponsoring the FreeBSD project and ZFS development in particular. I know I am just a relatively poor person so I can't contribute much (maybe on the order of 20-30 euro a month), but I keep seeing FreeBSD core team members keep mentioning "we value donations of all sizes", so what the hell :) Anyways, in the past I have directed my donations to The FreeBSD Foundation, if I want to ensure that as much of my money as possible goes directly to benefit the development of ZFS support on FreeBSD, should I continue donating to the foundation or should I be sending donations directly to specific developers? Thank you - Dan Naumov From wjw at withagen.nl Fri Jun 5 11:44:43 2009 From: wjw at withagen.nl (Willem Jan Withagen) Date: Fri Jun 5 11:44:55 2009 Subject: ZFS isntall requirements Message-ID: <4A29011B.9040803@withagen.nl> Hi, I'm trying to get my world to 7.2-stable(amd64),but run into: install -o root -g wheel -m 444 kgzldr.o /usr/lib ===> sys/boot/i386/libi386 (install) ===> sys/boot/i386/libfirewire (install) ===> sys/boot/i386/loader (install) make: don't know how to make /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop But the requirement below is NOT in /etc/{make,src}.conf. Even stronger /etc/src.conf has: WITHOUT_ZFS = yes # Put LOADER_ZFS_SUPPORT=yes in /etc/make.conf for ZFS support .if defined(LOADER_ZFS_SUPPORT) CFLAGS+= -DLOADER_ZFS_SUPPORT LIBZFS= ${.OBJDIR}/../../zfs/libzfsboot.a .endif So is this a problem on my side or is there some wrong logic somewhere? --WjW From kirk at strauser.com Fri Jun 5 14:47:06 2009 From: kirk at strauser.com (Kirk Strauser) Date: Fri Jun 5 14:47:12 2009 Subject: ZFS isntall requirements In-Reply-To: <4A29011B.9040803@withagen.nl> References: <4A29011B.9040803@withagen.nl> Message-ID: <200906050946.59547.kirk@strauser.com> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: > Hi, > > I'm trying to get my world to 7.2-stable(amd64),but run into: > install -o root -g wheel -m 444 kgzldr.o /usr/lib > ===> sys/boot/i386/libi386 (install) > ===> sys/boot/i386/libfirewire (install) > ===> sys/boot/i386/loader (install) > make: don't know how to make > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop ISTR that the build was temporarily broken several days ago. Have you csup'ed your src very recently? -- Kirk Strauser From ml at my.gd Fri Jun 5 15:29:29 2009 From: ml at my.gd (FLEURIOT Damien) Date: Fri Jun 5 15:29:37 2009 Subject: make installworld and securelevel Message-ID: <20090605154544.GA1855@sd-13813.dedibox.fr> Hello list, I apologize if this issue has been raised already but I couldn't find it anywhere. Find below a snip from my installworld: -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) ===> lib (install) ===> lib/csu/i386-elf (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/lib ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib install -C -o root -g wheel -m 444 libc_p.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib ^C My concern is with the last line which installs libc.so.7 and chflags it. I was running with securelevel 1 and got denied. I had to revert to the old kernel, change my securelevel, reinstall the new 7.2 kernel, then run my installworld. This hasn't caused me any other issue, but what will happen the day the libc.a or libc_p.a which are installed in the early steps of installworld become incompatible with the old kernel (if this is at all possible) ? I wouldn't have been able to boot anymore (this is a remote host). The server has a rescue system, but I think a lot of trouble could be saved by interrupting "make installworld" if we're running above securelevel 0. What do you think list ? Regards, Damien From delphij at delphij.net Fri Jun 5 19:24:32 2009 From: delphij at delphij.net (Xin LI) Date: Fri Jun 5 19:24:40 2009 Subject: Broadcom NetXtreme II BCM5709 Gigabit Ethernet Dell 610 and Dell In-Reply-To: <7758B5F61AA742B1B52EB2682F090282@PCdeEricDHEM> References: <7758B5F61AA742B1B52EB2682F090282@PCdeEricDHEM> Message-ID: <4A29709D.6070304@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Redirected from freebsd-drivers] Eric wrote: > Hi, > > Does any one find solution to this problem as we have same, try a proposed patch but still have problem? Could you please try the new version of driver? http://people.freebsd.org/~delphij/misc/193358.tar.bz2 Extract the tarball over your /usr/src This included mii (brgphy) and bce bits and should help. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkopcJwACgkQi+vbBBjt66DZUwCeI7mTWRv/cTij2lB+U74xeGOB sCcAn21UxO/oqjB67N/bF4DfO7blpJ2b =vUC+ -----END PGP SIGNATURE----- From hlh at restart.be Fri Jun 5 19:34:12 2009 From: hlh at restart.be (Henri Hennebert) Date: Fri Jun 5 19:34:19 2009 Subject: ZFS booting without partitions In-Reply-To: <3c1674c90906011515r5f706fdfl570e17a3c90f169f@mail.gmail.com> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> <4A240E17.30907@egr.msu.edu> <3c1674c90906011515r5f706fdfl570e17a3c90f169f@mail.gmail.com> Message-ID: <4A29732E.6090103@restart.be> Kip Macy wrote: > On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall 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. > At last I get this F.....G diff!!! The problem was in libstand.a. By the way , the patch also take into account the update of Doug Rabson to answer my problem with too many devices / pools. Happy to help on this one. > Cheers, > Kip -------------- next part -------------- --- lib/libstand/stand.h.orig 2007-01-09 02:02:04.000000000 +0100 +++ lib/libstand/stand.h 2009-06-03 17:24:42.627552341 +0200 @@ -167,7 +167,7 @@ #define SOPEN_RASIZE 512 }; -#define SOPEN_MAX 8 +#define SOPEN_MAX 64 extern struct open_file files[]; /* f_flags values */ --- lib/libstand/nfs.c.orig 2004-01-21 21:12:23.000000000 +0100 +++ lib/libstand/nfs.c 2009-06-05 20:36:26.001368421 +0200 @@ -29,7 +29,7 @@ */ #include -__FBSDID("$FreeBSD: src/lib/libstand/nfs.c,v 1.12 2004/01/21 20:12:23 jhb Exp $"); +__FBSDID("$FreeBSD: src/lib/libstand/nfs.c,v 1.14 2008/11/21 09:14:29 luigi Exp $"); #include #include @@ -405,16 +405,23 @@ #ifdef NFS_DEBUG if (debug) - printf("nfs_open: %s (rootpath=%s)\n", path, rootpath); + printf("nfs_open: %s (rootpath=%s)\n", upath, rootpath); #endif if (!rootpath[0]) { printf("no rootpath, no nfs\n"); return (ENXIO); } + /* + * This is silly - we should look at dv_type but that value is + * arch dependant and we can't use it here. + */ #ifndef __i386__ if (strcmp(f->f_dev->dv_name, "net") != 0) return(EINVAL); +#else + if (strcmp(f->f_dev->dv_name, "pxe") != 0) + return(EINVAL); #endif if (!(desc = socktodesc(*(int *)(f->f_devdata)))) From mcdouga9 at egr.msu.edu Fri Jun 5 21:53:02 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Fri Jun 5 21:53:09 2009 Subject: ZFS booting without partitions In-Reply-To: <4A29732E.6090103@restart.be> References: <29579856-69F7-4CDC-A52A-B414A40180ED@yellowspace.net> <18972.5870.795005.186542@already.dhcp.gene.com> <4A1C18CC.7080902@icyb.net.ua> <18972.7173.216763.407615@already.dhcp.gene.com> <4A23A81A.5050600@restart.be> <3c1674c90906010608te5fdf82r8349fcb9332485d@mail.gmail.com> <4A240E17.30907@egr.msu.edu> <3c1674c90906011515r5f706fdfl570e17a3c90f169f@mail.gmail.com> <4A29732E.6090103@restart.be> Message-ID: <4A2993BD.7030600@egr.msu.edu> Henri Hennebert wrote: > Kip Macy wrote: >> On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall >> 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. >> > At last I get this F.....G diff!!! > > The problem was in libstand.a. By the way , the patch also take into > account the update of Doug Rabson to answer my problem with too many > devices / pools. > > Happy to help on this one. > I can confirm that this fixes my loader when I patch, compile, install libstand then compile and install the loader. Thanks for finding it! From bruce at cran.org.uk Fri Jun 5 22:35:12 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Jun 5 22:35:19 2009 Subject: make installworld and securelevel In-Reply-To: <20090605154544.GA1855@sd-13813.dedibox.fr> References: <20090605154544.GA1855@sd-13813.dedibox.fr> Message-ID: <20090605233507.42ee1c96@gluon.draftnet> On Fri, 5 Jun 2009 17:45:50 +0200 FLEURIOT Damien wrote: > > Hello list, > > > I apologize if this issue has been raised already but I couldn't > find it anywhere. > > > Find below a snip from my installworld: > > -------------------------------------------------------------- > >>> Installing everything > -------------------------------------------------------------- > cd /usr/src; make -f Makefile.inc1 install > ===> share/info (install) > ===> lib (install) > ===> lib/csu/i386-elf (install) > install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o > /usr/lib > ===> lib/libc (install) > install -C -o root -g wheel -m 444 libc.a /usr/lib > install -C -o root -g wheel -m 444 libc_p.a /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > ^C > > > My concern is with the last line which installs libc.so.7 and > chflags it. > > I was running with securelevel 1 and got denied. > I had to revert to the old kernel, change my securelevel, reinstall > the new 7.2 kernel, then run my installworld. > > This hasn't caused me any other issue, but what will happen the day > the libc.a or libc_p.a which are installed in the early steps of > installworld become incompatible with the old kernel (if this is at > all possible) ? > > I wouldn't have been able to boot anymore (this is a remote host). > The server has a rescue system, but I think a lot of trouble could > be saved by interrupting "make installworld" if we're running above > securelevel 0. Although it's often safe to run installworld in multi user mode, it's recommended to run it in single user mode to avoid issues like this. From /usr/src/UPDATING: make buildworld make kernel KERNCONF=YOUR_KERNEL_HERE [1] [3] mergemaster -p [5] make installworld make delete-old mergemaster [4] -- Bruce Cran From freebsd-stable-local at be-well.ilk.org Fri Jun 5 23:08:03 2009 From: freebsd-stable-local at be-well.ilk.org (Lowell Gilbert) Date: Fri Jun 5 23:08:10 2009 Subject: make installworld and securelevel In-Reply-To: <20090605233507.42ee1c96@gluon.draftnet> (Bruce Cran's message of "Fri\, 5 Jun 2009 23\:35\:07 +0100") References: <20090605154544.GA1855@sd-13813.dedibox.fr> <20090605233507.42ee1c96@gluon.draftnet> Message-ID: <44prdimhh2.fsf@lowell-desk.lan> Bruce Cran writes: > On Fri, 5 Jun 2009 17:45:50 +0200 > FLEURIOT Damien wrote: > >> >> Hello list, >> >> >> I apologize if this issue has been raised already but I couldn't >> find it anywhere. >> >> >> Find below a snip from my installworld: >> >> -------------------------------------------------------------- >> >>> Installing everything >> -------------------------------------------------------------- >> cd /usr/src; make -f Makefile.inc1 install >> ===> share/info (install) >> ===> lib (install) >> ===> lib/csu/i386-elf (install) >> install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o >> /usr/lib >> ===> lib/libc (install) >> install -C -o root -g wheel -m 444 libc.a /usr/lib >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >> ^C >> >> >> My concern is with the last line which installs libc.so.7 and >> chflags it. >> >> I was running with securelevel 1 and got denied. >> I had to revert to the old kernel, change my securelevel, reinstall >> the new 7.2 kernel, then run my installworld. >> >> This hasn't caused me any other issue, but what will happen the day >> the libc.a or libc_p.a which are installed in the early steps of >> installworld become incompatible with the old kernel (if this is at >> all possible) ? >> >> I wouldn't have been able to boot anymore (this is a remote host). >> The server has a rescue system, but I think a lot of trouble could >> be saved by interrupting "make installworld" if we're running above >> securelevel 0. > > Although it's often safe to run installworld in multi user mode, it's > recommended to run it in single user mode to avoid issues like this. > From /usr/src/UPDATING: > > > make buildworld > make kernel KERNCONF=YOUR_KERNEL_HERE > [1] > [3] > mergemaster -p [5] > make installworld > make delete-old > mergemaster [4] > Still, I don't really see any obvious downsides to the suggestion. Maybe it could cause problems with jail updates? That's the only issue I've been able to think of... From ml at my.gd Fri Jun 5 23:39:11 2009 From: ml at my.gd (FLEURIOT Damien) Date: Fri Jun 5 23:39:18 2009 Subject: make installworld and securelevel In-Reply-To: <44prdimhh2.fsf@lowell-desk.lan> References: <20090605154544.GA1855@sd-13813.dedibox.fr> <20090605233507.42ee1c96@gluon.draftnet> <44prdimhh2.fsf@lowell-desk.lan> Message-ID: <20090605233903.GA8984@sd-13813.dedibox.fr> On Fri, Jun 05, 2009 at 06:41:13PM -0400 or thereabouts, Lowell Gilbert wrote: > Bruce Cran writes: > > > On Fri, 5 Jun 2009 17:45:50 +0200 > > FLEURIOT Damien wrote: > > > >> > >> Hello list, > >> > >> > >> I apologize if this issue has been raised already but I couldn't > >> find it anywhere. > >> > >> > >> Find below a snip from my installworld: > >> > >> -------------------------------------------------------------- > >> >>> Installing everything > >> -------------------------------------------------------------- > >> cd /usr/src; make -f Makefile.inc1 install > >> ===> share/info (install) > >> ===> lib (install) > >> ===> lib/csu/i386-elf (install) > >> install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o > >> /usr/lib > >> ===> lib/libc (install) > >> install -C -o root -g wheel -m 444 libc.a /usr/lib > >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib > >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > >> ^C > >> > >> > >> My concern is with the last line which installs libc.so.7 and > >> chflags it. > >> > >> I was running with securelevel 1 and got denied. > >> I had to revert to the old kernel, change my securelevel, reinstall > >> the new 7.2 kernel, then run my installworld. > >> > >> This hasn't caused me any other issue, but what will happen the day > >> the libc.a or libc_p.a which are installed in the early steps of > >> installworld become incompatible with the old kernel (if this is at > >> all possible) ? > >> > >> I wouldn't have been able to boot anymore (this is a remote host). > >> The server has a rescue system, but I think a lot of trouble could > >> be saved by interrupting "make installworld" if we're running above > >> securelevel 0. > > > > Although it's often safe to run installworld in multi user mode, it's > > recommended to run it in single user mode to avoid issues like this. > > From /usr/src/UPDATING: > > > > > > make buildworld > > make kernel KERNCONF=YOUR_KERNEL_HERE > > [1] > > [3] > > mergemaster -p [5] > > make installworld > > make delete-old > > mergemaster [4] > > > > Still, I don't really see any obvious downsides to the suggestion. > Maybe it could cause problems with jail updates? That's the only > issue I've been able to think of... Well, I'm afraid running single user isn't an option for me, hosted server. I've always skipped the single user boot, I just go multi-user and follow the other steps. Never done "make delete-old" though, it's not in the Handbook. Is it really important ? It might be worth adding to the Handbook. Regarding jails, seeing the securelevel can't be lowered, just disable chflag'ing during installworld within one ? -- Damien From bruce at cran.org.uk Sat Jun 6 00:01:03 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Sat Jun 6 00:01:11 2009 Subject: make installworld and securelevel In-Reply-To: <44prdimhh2.fsf@lowell-desk.lan> References: <20090605154544.GA1855@sd-13813.dedibox.fr> <20090605233507.42ee1c96@gluon.draftnet> <44prdimhh2.fsf@lowell-desk.lan> Message-ID: <20090606010058.2bd884b0@gluon.draftnet> On Fri, 05 Jun 2009 18:41:13 -0400 Lowell Gilbert wrote: > Bruce Cran writes: > > > On Fri, 5 Jun 2009 17:45:50 +0200 > > FLEURIOT Damien wrote: > > > >> > >> Hello list, > >> > >> > >> I apologize if this issue has been raised already but I couldn't > >> find it anywhere. > >> > >> > >> Find below a snip from my installworld: > >> > >> -------------------------------------------------------------- > >> >>> Installing everything > >> -------------------------------------------------------------- > >> cd /usr/src; make -f Makefile.inc1 install > >> ===> share/info (install) > >> ===> lib (install) > >> ===> lib/csu/i386-elf (install) > >> install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o > >> /usr/lib > >> ===> lib/libc (install) > >> install -C -o root -g wheel -m 444 libc.a /usr/lib > >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib > >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib > >> ^C > >> > >> > >> My concern is with the last line which installs libc.so.7 and > >> chflags it. > >> > >> I was running with securelevel 1 and got denied. > >> I had to revert to the old kernel, change my securelevel, reinstall > >> the new 7.2 kernel, then run my installworld. > >> > >> This hasn't caused me any other issue, but what will happen the day > >> the libc.a or libc_p.a which are installed in the early steps of > >> installworld become incompatible with the old kernel (if this is at > >> all possible) ? > >> > >> I wouldn't have been able to boot anymore (this is a remote host). > >> The server has a rescue system, but I think a lot of trouble could > >> be saved by interrupting "make installworld" if we're running above > >> securelevel 0. > > > > Although it's often safe to run installworld in multi user mode, > > it's recommended to run it in single user mode to avoid issues like > > this. From /usr/src/UPDATING: > > > > > > make buildworld > > make kernel KERNCONF=YOUR_KERNEL_HERE > > [1] > > [3] > > mergemaster -p [5] > > make installworld > > make delete-old > > mergemaster [4] > > > > Still, I don't really see any obvious downsides to the suggestion. > Maybe it could cause problems with jail updates? That's the only > issue I've been able to think of... > If you do both the installkernel and installworld at the same time and the new kernel doesn't boot, then you may not be able to boot with the old kernel because the new userland may be incompatible. -- Bruce Cran From glen.j.barber at gmail.com Sat Jun 6 13:16:13 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Sat Jun 6 13:16:20 2009 Subject: Kernel Debugging Options Message-ID: <4ad871310906060616u7f162f26h8a3149fbe7e4c273@mail.gmail.com> Hello everyone I have a two-part question: I have a minimally customized GENERIC kernel, with the only changes being: options KDB options KDB_UNATTENDED options DDB and 'sysctl debug.debugger_on_panic' shows: debug.debugger_on_panic: 0 However, after a panic loading the vboxdrv.ko module, the machine did not reboot automatically after reboot. Here are my questions: 1) Would enabling DDB in the kernel prevent an automatic reboot after a panic? 2) Does the debugger wait for XX seconds of console inactivity before rebooting? I was under the impression from the handbook that the machine would instantly reboot and after dumping the crash to vmcore0. Is this assumption incorrect? Thanks in advance for any input. -- Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber From glen.j.barber at gmail.com Sat Jun 6 13:20:59 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Sat Jun 6 13:21:05 2009 Subject: Kernel Debugging Options In-Reply-To: <4ad871310906060616u7f162f26h8a3149fbe7e4c273@mail.gmail.com> References: <4ad871310906060616u7f162f26h8a3149fbe7e4c273@mail.gmail.com> Message-ID: <4ad871310906060620l4ac34881g1ff4946a9bea569@mail.gmail.com> On Sat, Jun 6, 2009 at 9:16 AM, Glen Barber wrote: > Hello everyone > > I have a two-part question: > > I have a minimally customized GENERIC kernel, with the only changes being: > options ? ? ? ? KDB > options ? ? ? ? KDB_UNATTENDED > options ? ? ? ? DDB > > and 'sysctl debug.debugger_on_panic' shows: > debug.debugger_on_panic: 0 > > However, after a panic loading the vboxdrv.ko module, the machine did > not reboot automatically after reboot. I meant "automatically after panic". It's early, and I am apparently unable to type a coherent thought... > > Here are my questions: > 1) ?Would enabling DDB in the kernel prevent an automatic reboot after a panic? > > 2) ?Does the debugger wait for XX seconds of console inactivity before > rebooting? ?I was under the impression from the handbook that the > machine would instantly reboot and after dumping the crash to vmcore0. > ?Is this assumption incorrect? > > Thanks in advance for any input. > Also, if this is helpful, the userland / kernel are from two days ago, r193481: FreeBSD orion 7.2-STABLE FreeBSD 7.2-STABLE #0 r193481: Fri Jun 5 01:55:06 EDT 2009 root@orion:/usr/obj/usr/src/sys/ORION i386 -- Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber From nakaji at jp.freebsd.org Sat Jun 6 14:33:36 2009 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Sat Jun 6 14:33:43 2009 Subject: Big problem still remains with 7.2-STABLE locking up Message-ID: <86d49h300c.fsf@ra333.heimat.gr.jp> Hi, I noticed, some months ago, frequent lockups on my RELENG_6 server with ECS PM800-M2, Celeron 2.6GHz (UP), 2GB ram, ATA HDDs and 3Com NIC(xl0), and then I gave up this old server. Last month, I replaced this 'unstable' server to the new one with 7.2-RELEASE which worked very well until I setup it as 'a server'. The problem began just after it started 'the services'. My story is very similar to Pete's. http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047487.html I followed some instructions in the list thread. But unfortunately, the big problem still remains. 7.2-STABLE server locks up frequently. Help! :-( The server is NEC Express5800 S70/SD. o CPU: Intel(R) Celeron(R) CPU 440 @ 2.00GHz (2280.25-MHz K8-class CPU) o 6GB RAM o ACPI APIC Table: o 80GB and 250GB SATA HDDs o http://www.heimat.gr.jp/~nakaji/localhost/dmesg.boot The kernel configuration is: include GENERIC ident HEIMAT options MSGBUF_SIZE=81920 makeoptions DEBUG=-g options KDB options DDB options BREAK_TO_DEBUGGER options QUOTA options DEVICE_POLLING options HZ=1000 options SW_WATCHDOG options DEBUG_VFS_LOCKS options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options LOCK_PROFILING This server runs as web server, nfs server, dhcp server, ntp server, mail server with spam checks, ML server, usenet server and so on. From /etc/rc.conf*, there are some "_enable" lines as shown below. o ntpdate o ntpd o nfs_server o sshd o inetd o named o sendmail o rtadvd o watchdogd o dhcpd o snmpd o apache22 o samba o zope29 o zope210 o amavisd o amavisd_milter o cvsupd o ntop o compat6x o munin_node o spamd o spamass_milter o smartd o mailman o sshblock o innd o skkserv >From munin's graphs, the 'resets' value in netstat is increasing while on other 'desktops' it remains zero. Though I did not find if there is a threshold of 'resets', when it reaches to 0.8 - 1.2 the server gets "lockup". No ping response, no messages on cosole, no keyboard response, and, of cource, Ctrl-Alt-Esc does not function, when it locks up. I wonder why netstat's reset is increasing. I had learned a workaround from other Japanese guys, that is, enabling ichwd and running watchdogd can reboot the box when it locks up if the box has ICH. Exactly, after about 4 hours, the box rebooted while I was in bed last night. Watchdogd functions very well. Advice? Thanks. -- NAKAJI Hiroyuki From traveling08 at cox.net Sat Jun 6 14:43:08 2009 From: traveling08 at cox.net (Robert) Date: Sat Jun 6 14:43:16 2009 Subject: Panic resource_list_alloc 7.2 stable Message-ID: <20090606071431.092609ce@vaio> Greetings This problem seems the same as this one from May of this year http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html This happens on an older HP laptop. It was running on 7.1 prerelease fine and then I updated to 7.2 Stable yesterday. FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT 2009 root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386 The bits from pciconf atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' class = mass storage subclass = ATA The date of ata-chipset.c -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c The chipset is found in the above file ata_intel_ident(device_t dev) { struct ata_pci_controller *ctlr = device_get_softc(dev); static struct ata_chip_id ids[] = {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, ^^^^^^^ { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, I can include the dump if needed but I am not at this time to shorten the email. But here is the panic. Dump header from device /dev/ad0s1b Architecture: i386 Architecture Version: 2 Dump Length: 68939776B (65 MB) Blocksize: 512 Dumptime: Sat Jun 6 05:40:52 2009 Hostname: hp.shasta204.local Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT 2009 root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA Panic String: resource_list_alloc: resource entry is busy Dump Parity: 3285399556 Bounds: 1 Dump Status: good Any help would be greatly appreciated. Robert From attilio at freebsd.org Sat Jun 6 14:49:57 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Jun 6 14:50:03 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: <86d49h300c.fsf@ra333.heimat.gr.jp> References: <86d49h300c.fsf@ra333.heimat.gr.jp> Message-ID: <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> 2009/6/6 NAKAJI Hiroyuki : > Hi, > > I noticed, some months ago, frequent lockups on my RELENG_6 server with > ECS PM800-M2, Celeron 2.6GHz (UP), 2GB ram, ATA HDDs and 3Com NIC(xl0), > and then I gave up this old server. > > Last month, I replaced this 'unstable' server to the new one with > 7.2-RELEASE which worked very well until I setup it as 'a server'. The > problem began just after it started 'the services'. > > My story is very similar to Pete's. > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047487.html > > I followed some instructions in the list thread. But unfortunately, the > big problem still remains. 7.2-STABLE server locks up frequently. > > Help! :-( > > The server is NEC Express5800 S70/SD. > > o CPU: Intel(R) Celeron(R) CPU 440 @ 2.00GHz (2280.25-MHz K8-class CPU) > o 6GB RAM > o ACPI APIC Table: > o 80GB and 250GB SATA HDDs > o http://www.heimat.gr.jp/~nakaji/localhost/dmesg.boot > > The kernel configuration is: > > include GENERIC > ident ? HEIMAT > options MSGBUF_SIZE=81920 > makeoptions ? ? DEBUG=-g > options KDB > options DDB > options BREAK_TO_DEBUGGER > options QUOTA Were you unmounting any of the QUOTA'ed filesystems? I'm aware of a possible deadlock between quota and unmount path which is very difficult to trigger though. Anyways, the only one way we have to debug this is getting some help by the user. 1) Drop the option WITNESS_SPIKSPIN (as we would like to debug spinlocks too) and LOCK_PROFILING (in order to create higher contention and kill some barriers) 2) Once you get the deadlock break in the DDB debugger 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads Note that this is a lot of printout so you won't be able of collecting all these informations if not with a serial connection. 4) Dump the content so that we can further look at locks structure states once we identify something useful (ideally, keeping the machine up in DDB for that would be very useful, but often not viable) Let me know. Attilio -- Peace can only be achieved by understanding - A. Einstein From petefrench at ticketswitch.com Sat Jun 6 14:51:58 2009 From: petefrench at ticketswitch.com (Pete French) Date: Sat Jun 6 14:52:04 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: <86d49h300c.fsf@ra333.heimat.gr.jp> Message-ID: > My story is very similar to Pete's. > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047487.html My problem, which you link to there, tturrned out to be due to ICMP redirects, and is most definitely fixed in 7.2. So, your problem is not the same as mine, but some of the tips given there may help you ddebug it. > I followed some instructions in the list thread. But unfortunately, the > big problem still remains. 7.2-STABLE server locks up frequently. Are you using the latest STABLE ? I am rolling out the one from a few days ago with the bce fixes, and that works fine. > The kernel configuration is: ... > options BREAK_TO_DEBUGGER When the box locks up, can you actyually break to the debugger ? This is how we eventually tracked down my problem. -pete. From freebsd-stable-local at be-well.ilk.org Sat Jun 6 15:42:16 2009 From: freebsd-stable-local at be-well.ilk.org (Lowell Gilbert) Date: Sat Jun 6 15:42:23 2009 Subject: make installworld and securelevel In-Reply-To: <20090606010058.2bd884b0@gluon.draftnet> (Bruce Cran's message of "Sat\, 6 Jun 2009 01\:00\:58 +0100") References: <20090605154544.GA1855@sd-13813.dedibox.fr> <20090605233507.42ee1c96@gluon.draftnet> <44prdimhh2.fsf@lowell-desk.lan> <20090606010058.2bd884b0@gluon.draftnet> Message-ID: <44d49hbc8g.fsf@lowell-desk.lan> Bruce Cran writes: > On Fri, 05 Jun 2009 18:41:13 -0400 > Lowell Gilbert wrote: > >> Bruce Cran writes: >> >> > On Fri, 5 Jun 2009 17:45:50 +0200 >> > FLEURIOT Damien wrote: >> > >> >> >> >> Hello list, >> >> >> >> >> >> I apologize if this issue has been raised already but I couldn't >> >> find it anywhere. >> >> >> >> >> >> Find below a snip from my installworld: >> >> >> >> -------------------------------------------------------------- >> >> >>> Installing everything >> >> -------------------------------------------------------------- >> >> cd /usr/src; make -f Makefile.inc1 install >> >> ===> share/info (install) >> >> ===> lib (install) >> >> ===> lib/csu/i386-elf (install) >> >> install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o >> >> /usr/lib >> >> ===> lib/libc (install) >> >> install -C -o root -g wheel -m 444 libc.a /usr/lib >> >> install -C -o root -g wheel -m 444 libc_p.a /usr/lib >> >> install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib >> >> ^C >> >> >> >> >> >> My concern is with the last line which installs libc.so.7 and >> >> chflags it. >> >> >> >> I was running with securelevel 1 and got denied. >> >> I had to revert to the old kernel, change my securelevel, reinstall >> >> the new 7.2 kernel, then run my installworld. >> >> >> >> This hasn't caused me any other issue, but what will happen the day >> >> the libc.a or libc_p.a which are installed in the early steps of >> >> installworld become incompatible with the old kernel (if this is at >> >> all possible) ? >> >> >> >> I wouldn't have been able to boot anymore (this is a remote host). >> >> The server has a rescue system, but I think a lot of trouble could >> >> be saved by interrupting "make installworld" if we're running above >> >> securelevel 0. >> > >> > Although it's often safe to run installworld in multi user mode, >> > it's recommended to run it in single user mode to avoid issues like >> > this. From /usr/src/UPDATING: >> > >> > >> > make buildworld >> > make kernel KERNCONF=YOUR_KERNEL_HERE >> > [1] >> > [3] >> > mergemaster -p [5] >> > make installworld >> > make delete-old >> > mergemaster [4] >> > >> >> Still, I don't really see any obvious downsides to the suggestion. >> Maybe it could cause problems with jail updates? That's the only >> issue I've been able to think of... >> > > If you do both the installkernel and installworld at the same time and > the new kernel doesn't boot, then you may not be able to boot with the > old kernel because the new userland may be incompatible. The original suggestion wasn't to skip the reboot, but rather to stop the user from doing an installworld under a raised securelevel. I don't consider it important, because the recommended upgrade path is to do the installworld in single-user mode, but by the same token I don't see any real harm. From hlh at restart.be Sat Jun 6 15:53:51 2009 From: hlh at restart.be (Henri Hennebert) Date: Sat Jun 6 15:53:58 2009 Subject: Stable from May 31 - zfs list locked Message-ID: <4A2A910A.5060900@restart.be> Hello, I encounter this problem for the second time. The system is working perfectly well but suddenly the command `zfs list' don't work and can't be killed. Here is a procstat of the culprit: [root@morzine ~]# procstat -k 91766 PID TID COMM TDNAME KSTACK 91766 100490 zfs - mi_switch sleepq_switch sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir zap_lookup_norm zap_lookup dsl_prop_get_dd dsl_dataset_get_ref dsl_dataset_hold dmu_objset_open zfs_ioc_objset_stats zfsdev_ioctl devfs_ioctl_f kern_ioctl same thing happen if I try to run `zpool list' un another terminal. Henri From nakaji at jp.freebsd.org Sat Jun 6 16:11:58 2009 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Sat Jun 6 16:12:06 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: (Pete French's message of "Sat, 06 Jun 2009 15:51:49 +0100") References: Message-ID: <868wk52vgb.fsf@ra333.heimat.gr.jp> >>>>> In >>>>> Pete French wrote: > > I followed some instructions in the list thread. But unfortunately, the > > big problem still remains. 7.2-STABLE server locks up frequently. > Are you using the latest STABLE ? I am rolling out the one from a few > days ago with the bce fixes, and that works fine. Yes, the kernel was compiled at Sat Jun 6 17:59:50 JST 2009. I did not check the source changes but I need watching how it works. Yesterday's kernel can easily lock up, and ichwd+watchdogd can restart (reset?) the box. > > The kernel configuration is: > ... > > options BREAK_TO_DEBUGGER > When the box locks up, can you actyually break to the debugger ? This is how > we eventually tracked down my problem. No. I have never seen the debugger, Ctrl+Alt+Esc cannot break. And because this box does not have serial port, debugging seems difficult. -- NAKAJI Hiroyuki From nakaji at jp.freebsd.org Sat Jun 6 16:29:00 2009 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Sat Jun 6 16:29:07 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> (Attilio Rao's message of "Sat, 6 Jun 2009 16:49:54 +0200") References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> Message-ID: <864out2uny.fsf@ra333.heimat.gr.jp> >>>>> In <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> >>>>> Attilio Rao wrote: > > The kernel configuration is: > > > > include GENERIC > > ident ? HEIMAT > > options MSGBUF_SIZE=81920 > > makeoptions ? ? DEBUG=-g > > options KDB > > options DDB > > options BREAK_TO_DEBUGGER > > options QUOTA > Were you unmounting any of the QUOTA'ed filesystems? No. Quota'ed file system is /home which is not easily unmounted. > Anyways, the only one way we have to debug this is getting some help > by the user. > 1) Drop the option WITNESS_SPIKSPIN (as we would like to debug > spinlocks too) and LOCK_PROFILING (in order to create higher > contention and kill some barriers) Removed two lines from KERNCONF. > 2) Once you get the deadlock break in the DDB debugger Hmm. It is the most difficult: the box cannot break in the DDB debugger for now. > 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads > Note that this is a lot of printout so you won't be able of collecting > all these informations if not with a serial connection. The box does not have any serial port. Is there any other way? Is it possible to use dcons(4) for that purpose, if I add firewire PCI board? > 4) Dump the content so that we can further look at locks structure > states once we identify something useful (ideally, keeping the machine > up in DDB for that would be very useful, but often not viable) Thank you for instruction. I'll try. -- NAKAJI Hiroyuki From danny at cs.huji.ac.il Sat Jun 6 16:35:45 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Jun 6 16:35:53 2009 Subject: Stable from May 31 - zfs list locked In-Reply-To: <4A2A910A.5060900@restart.be> References: <4A2A910A.5060900@restart.be> Message-ID: > Hello, > > I encounter this problem for the second time. The system is working > perfectly well but suddenly the command `zfs list' don't work and can't > be killed. > > Here is a procstat of the culprit: > > [root@morzine ~]# procstat -k 91766 > PID TID COMM TDNAME KSTACK > > 91766 100490 zfs - mi_switch sleepq_switch > sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir > zap_lookup_norm zap_lookup dsl_prop_get_dd dsl_dataset_get_ref > dsl_dataset_hold dmu_objset_open zfs_ioc_objset_stats zfsdev_ioctl > devfs_ioctl_f kern_ioctl > > same thing happen if I try to run `zpool list' un another terminal. > > Henri same here, but with a twist: it used to happen on a 7.1, then after an unpgrade, sometime in April, to 7.2-PRERELEASE, things were ok till today! I was about to blame a resent upgrade of the PERC firmware(a very long shot :-), but now I don't know if upgradeing to 7.2-stable will help. This is a production host, with 12TB serving many nfs clients. danny From marck at rinet.ru Sat Jun 6 18:46:35 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sat Jun 6 18:46:43 2009 Subject: ZFS isntall requirements In-Reply-To: <200906050946.59547.kirk@strauser.com> References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> Message-ID: On Fri, 5 Jun 2009, Kirk Strauser wrote: KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: KS> > Hi, KS> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib KS> > ===> sys/boot/i386/libi386 (install) KS> > ===> sys/boot/i386/libfirewire (install) KS> > ===> sys/boot/i386/loader (install) KS> > make: don't know how to make KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop KS> KS> ISTR that the build was temporarily broken several days ago. Well, according to http://tinderbox.freebsd.org/ it does not ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From bazerka at beardz.net Sat Jun 6 18:58:16 2009 From: bazerka at beardz.net (Jase Thew) Date: Sat Jun 6 18:58:23 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: <864out2uny.fsf@ra333.heimat.gr.jp> References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> <864out2uny.fsf@ra333.heimat.gr.jp> Message-ID: <4A2AB80F.1050207@beardz.net> NAKAJI Hiroyuki wrote: >> Note that this is a lot of printout so you won't be able of collecting >> all these informations if not with a serial connection. > > The box does not have any serial port. Is there any other way? Is it > possible to use dcons(4) for that purpose, if I add firewire PCI board? > http://wiki.freebsd.org/DebugWithDcons may be of use to you. Regards, Jase Thew. From hlh at restart.be Sat Jun 6 19:54:04 2009 From: hlh at restart.be (Henri Hennebert) Date: Sat Jun 6 19:54:10 2009 Subject: Stable from May 31 - zfs list locked In-Reply-To: <4A2A910A.5060900@restart.be> References: <4A2A910A.5060900@restart.be> Message-ID: <4A2AC955.1010902@restart.be> Henri Hennebert wrote: > Hello, > > I encounter this problem for the second time. The system is working > perfectly well but suddenly the command `zfs list' don't work and can't > be killed. > > Here is a procstat of the culprit: > > [root@morzine ~]# procstat -k 91766 > PID TID COMM TDNAME KSTACK > 91766 100490 zfs - mi_switch sleepq_switch > sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir > zap_lookup_norm zap_lookup dsl_prop_get_dd dsl_dataset_get_ref > dsl_dataset_hold dmu_objset_open zfs_ioc_objset_stats zfsdev_ioctl > devfs_ioctl_f kern_ioctl > > same thing happen if I try to run `zpool list' un another terminal. Stangely, zfs snapsot and zfs destroy seems working properly ... I reboot to check this > > Henri > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From glen.j.barber at gmail.com Sat Jun 6 22:20:32 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Sat Jun 6 22:20:39 2009 Subject: Kernel Debugging Options In-Reply-To: <4ad871310906060620l4ac34881g1ff4946a9bea569@mail.gmail.com> References: <4ad871310906060616u7f162f26h8a3149fbe7e4c273@mail.gmail.com> <4ad871310906060620l4ac34881g1ff4946a9bea569@mail.gmail.com> Message-ID: <4ad871310906061520u11b0dcddt7984c2cd1d41acf0@mail.gmail.com> On Sat, Jun 6, 2009 at 9:20 AM, Glen Barber wrote: >> Hello everyone >> >> I have a two-part question: >> >> I have a minimally customized GENERIC kernel, with the only changes being: >> options ? ? ? ? KDB >> options ? ? ? ? KDB_UNATTENDED >> options ? ? ? ? DDB >> >> and 'sysctl debug.debugger_on_panic' shows: >> debug.debugger_on_panic: 0 >> >> However, after a panic loading the vboxdrv.ko module, the machine did >> not reboot automatically after reboot. > > I meant "automatically after panic". ?It's early, and I am apparently > unable to type a coherent thought... > >> >> Here are my questions: >> 1) ?Would enabling DDB in the kernel prevent an automatic reboot after a panic? >> >> 2) ?Does the debugger wait for XX seconds of console inactivity before >> rebooting? ?I was under the impression from the handbook that the >> machine would instantly reboot and after dumping the crash to vmcore0. >> ?Is this assumption incorrect? >> >> Thanks in advance for any input. >> > > Also, if this is helpful, the userland / kernel are from two days ago, r193481: > > FreeBSD orion 7.2-STABLE FreeBSD 7.2-STABLE #0 r193481: Fri Jun ?5 > 01:55:06 EDT 2009 ? ? root@orion:/usr/obj/usr/src/sys/ORION ?i386 > Sorry for the noise... Disabling DDB from the kernel corrected the reboot issue. Unless I am misunderstanding how it is worded, it is unclear from the HTML docs that DDB overrides KDB_UNATTENDED. If I am misunderstanding, I apologize, but I'm more curious if I am experiencing unusual behavior with DDB enabled. -- Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber From exemys at exemys.com Sun Jun 7 09:54:01 2009 From: exemys at exemys.com (Exemys) Date: Sun Jun 7 09:54:09 2009 Subject: Modbus I/O Module - Cost Effective Message-ID: <111abbfc08141ad9348f67a4523f8272@www.hostmailing.com> This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From tinderbox at freebsd.org Sun Jun 7 12:48:01 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Jun 7 12:48:44 2009 Subject: [releng_7 tinderbox] failure on i386/pc98 Message-ID: <20090607124756.DB3BE1B5060@freebsd-stable.sentex.ca> TB --- 2009-06-07 11:26:01 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-07 11:26:01 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-06-07 11:26:01 - cleaning the object tree TB --- 2009-06-07 11:26:26 - cvsupping the source tree TB --- 2009-06-07 11:26:26 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-06-07 11:26:37 - building world TB --- 2009-06-07 11:26:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 11:26:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 11:26:37 - TARGET=pc98 TB --- 2009-06-07 11:26:37 - TARGET_ARCH=i386 TB --- 2009-06-07 11:26:37 - TZ=UTC TB --- 2009-06-07 11:26:37 - __MAKE_CONF=/dev/null TB --- 2009-06-07 11:26:37 - cd /src TB --- 2009-06-07 11:26:37 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 11:26:39 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jun 7 12:33:51 UTC 2009 TB --- 2009-06-07 12:33:51 - generating LINT kernel config TB --- 2009-06-07 12:33:51 - cd /src/sys/pc98/conf TB --- 2009-06-07 12:33:51 - /usr/bin/make -B LINT TB --- 2009-06-07 12:33:51 - building LINT kernel TB --- 2009-06-07 12:33:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 12:33:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 12:33:51 - TARGET=pc98 TB --- 2009-06-07 12:33:51 - TARGET_ARCH=i386 TB --- 2009-06-07 12:33:51 - TZ=UTC TB --- 2009-06-07 12:33:51 - __MAKE_CONF=/dev/null TB --- 2009-06-07 12:33:51 - cd /src TB --- 2009-06-07 12:33:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 12:33:51 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue vers.c linking kernel hwpmc_intel.o(.text+0x1c6): In function `pmc_intel_initialize': : undefined reference to `pmc_core_initialize' hwpmc_intel.o(.text+0x49): In function `pmc_intel_finalize': : undefined reference to `pmc_core_finalize' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 12:47:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 12:47:56 - ERROR: failed to build lint kernel TB --- 2009-06-07 12:47:56 - 3963.74 user 410.00 system 4914.68 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From tinderbox at freebsd.org Sun Jun 7 13:44:02 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Jun 7 13:44:20 2009 Subject: [releng_7 tinderbox] failure on ia64/ia64 Message-ID: <20090607134359.63FCE1B5060@freebsd-stable.sentex.ca> TB --- 2009-06-07 12:08:02 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-07 12:08:02 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2009-06-07 12:08:02 - cleaning the object tree TB --- 2009-06-07 12:08:22 - cvsupping the source tree TB --- 2009-06-07 12:08:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2009-06-07 12:08:35 - building world TB --- 2009-06-07 12:08:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 12:08:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 12:08:35 - TARGET=ia64 TB --- 2009-06-07 12:08:35 - TARGET_ARCH=ia64 TB --- 2009-06-07 12:08:35 - TZ=UTC TB --- 2009-06-07 12:08:35 - __MAKE_CONF=/dev/null TB --- 2009-06-07 12:08:35 - cd /src TB --- 2009-06-07 12:08:35 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 12:08:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jun 7 13:37:38 UTC 2009 TB --- 2009-06-07 13:37:38 - generating LINT kernel config TB --- 2009-06-07 13:37:38 - cd /src/sys/ia64/conf TB --- 2009-06-07 13:37:38 - /usr/bin/make -B LINT TB --- 2009-06-07 13:37:38 - building LINT kernel TB --- 2009-06-07 13:37:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 13:37:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 13:37:38 - TARGET=ia64 TB --- 2009-06-07 13:37:38 - TARGET_ARCH=ia64 TB --- 2009-06-07 13:37:38 - TZ=UTC TB --- 2009-06-07 13:37:38 - __MAKE_CONF=/dev/null TB --- 2009-06-07 13:37:38 - cd /src TB --- 2009-06-07 13:37:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 13:37:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/hme/if_hme.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/hme/if_hme_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_logging.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_mod.c cc1: warnings being treated as errors /src/sys/dev/hwpmc/hwpmc_mod.c: In function 'pmc_process_interrupt': /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: implicit declaration of function 'PMC_TRAPFRAME_TO_PC' /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: nested extern declaration of 'PMC_TRAPFRAME_TO_PC' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 13:43:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 13:43:58 - ERROR: failed to build lint kernel TB --- 2009-06-07 13:43:58 - 4851.80 user 386.43 system 5756.63 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From tinderbox at freebsd.org Sun Jun 7 14:01:44 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Jun 7 14:02:01 2009 Subject: [releng_7 tinderbox] failure on powerpc/powerpc Message-ID: <20090607140140.6D2C81B5060@freebsd-stable.sentex.ca> TB --- 2009-06-07 12:47:57 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-07 12:47:57 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-06-07 12:47:57 - cleaning the object tree TB --- 2009-06-07 12:48:24 - cvsupping the source tree TB --- 2009-06-07 12:48:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-06-07 12:48:35 - building world TB --- 2009-06-07 12:48:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 12:48:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 12:48:35 - TARGET=powerpc TB --- 2009-06-07 12:48:35 - TARGET_ARCH=powerpc TB --- 2009-06-07 12:48:35 - TZ=UTC TB --- 2009-06-07 12:48:35 - __MAKE_CONF=/dev/null TB --- 2009-06-07 12:48:35 - cd /src TB --- 2009-06-07 12:48:35 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 12:48:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jun 7 13:57:26 UTC 2009 TB --- 2009-06-07 13:57:26 - generating LINT kernel config TB --- 2009-06-07 13:57:26 - cd /src/sys/powerpc/conf TB --- 2009-06-07 13:57:26 - /usr/bin/make -B LINT TB --- 2009-06-07 13:57:26 - building LINT kernel TB --- 2009-06-07 13:57:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 13:57:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 13:57:26 - TARGET=powerpc TB --- 2009-06-07 13:57:26 - TARGET_ARCH=powerpc TB --- 2009-06-07 13:57:26 - TZ=UTC TB --- 2009-06-07 13:57:26 - __MAKE_CONF=/dev/null TB --- 2009-06-07 13:57:26 - cd /src TB --- 2009-06-07 13:57:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 13:57:26 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/dev/hme/if_hme.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/dev/hme/if_hme_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_logging.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_mod.c cc1: warnings being treated as errors /src/sys/dev/hwpmc/hwpmc_mod.c: In function 'pmc_process_interrupt': /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: implicit declaration of function 'PMC_TRAPFRAME_TO_PC' /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: nested extern declaration of 'PMC_TRAPFRAME_TO_PC' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 14:01:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 14:01:40 - ERROR: failed to build lint kernel TB --- 2009-06-07 14:01:40 - 3591.21 user 361.16 system 4423.28 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From tinderbox at freebsd.org Sun Jun 7 14:49:31 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Jun 7 14:49:40 2009 Subject: [releng_7 tinderbox] failure on sparc64/sparc64 Message-ID: <20090607144928.8656A1B5060@freebsd-stable.sentex.ca> TB --- 2009-06-07 13:43:59 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-07 13:43:59 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2009-06-07 13:43:59 - cleaning the object tree TB --- 2009-06-07 13:44:22 - cvsupping the source tree TB --- 2009-06-07 13:44:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2009-06-07 13:44:33 - building world TB --- 2009-06-07 13:44:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 13:44:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 13:44:33 - TARGET=sparc64 TB --- 2009-06-07 13:44:33 - TARGET_ARCH=sparc64 TB --- 2009-06-07 13:44:33 - TZ=UTC TB --- 2009-06-07 13:44:33 - __MAKE_CONF=/dev/null TB --- 2009-06-07 13:44:33 - cd /src TB --- 2009-06-07 13:44:33 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 13:44:34 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jun 7 14:45:00 UTC 2009 TB --- 2009-06-07 14:45:00 - generating LINT kernel config TB --- 2009-06-07 14:45:00 - cd /src/sys/sparc64/conf TB --- 2009-06-07 14:45:00 - /usr/bin/make -B LINT TB --- 2009-06-07 14:45:00 - building LINT kernel TB --- 2009-06-07 14:45:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 14:45:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 14:45:00 - TARGET=sparc64 TB --- 2009-06-07 14:45:00 - TARGET_ARCH=sparc64 TB --- 2009-06-07 14:45:00 - TZ=UTC TB --- 2009-06-07 14:45:00 - __MAKE_CONF=/dev/null TB --- 2009-06-07 14:45:00 - cd /src TB --- 2009-06-07 14:45:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 14:45:00 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/hme/if_hme_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/hme/if_hme_sbus.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_logging.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_mod.c cc1: warnings being treated as errors /src/sys/dev/hwpmc/hwpmc_mod.c: In function 'pmc_process_interrupt': /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: implicit declaration of function 'PMC_TRAPFRAME_TO_PC' /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: nested extern declaration of 'PMC_TRAPFRAME_TO_PC' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 14:49:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 14:49:28 - ERROR: failed to build lint kernel TB --- 2009-06-07 14:49:28 - 3361.62 user 355.89 system 3928.90 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From wjw at withagen.nl Sun Jun 7 17:04:44 2009 From: wjw at withagen.nl (Willem Jan Withagen) Date: Sun Jun 7 17:04:51 2009 Subject: ZFS isntall requirements In-Reply-To: References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> Message-ID: <4A2BEF7D.5070808@withagen.nl> Dmitry Morozovsky wrote: > On Fri, 5 Jun 2009, Kirk Strauser wrote: > > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: > KS> > Hi, > KS> > > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib > KS> > ===> sys/boot/i386/libi386 (install) > KS> > ===> sys/boot/i386/libfirewire (install) > KS> > ===> sys/boot/i386/loader (install) > KS> > make: don't know how to make > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop > KS> > KS> ISTR that the build was temporarily broken several days ago. > > > Well, according to http://tinderbox.freebsd.org/ it does not ;) I'm not at all familiar with the intrinsics of the tinderbox setup. But am I free to assume that it is not tested with 'WITHOUT_ZFS=yes'??? Because that is required to have the trouble surface. --WjW From allnetgroup at yahoo.com Sun Jun 7 17:30:02 2009 From: allnetgroup at yahoo.com (AES) Date: Sun Jun 7 17:30:09 2009 Subject: I need to add commands that starts every time at system boot. Message-ID: <143776.42704.qm@web34307.mail.mud.yahoo.com> I need to add commands that starts every time?at system boot. ? which script is the one that starts first and where can I find it? From kometen at gmail.com Sun Jun 7 18:13:18 2009 From: kometen at gmail.com (Claus Guttesen) Date: Sun Jun 7 18:13:28 2009 Subject: I need to add commands that starts every time at system boot. In-Reply-To: <143776.42704.qm@web34307.mail.mud.yahoo.com> References: <143776.42704.qm@web34307.mail.mud.yahoo.com> Message-ID: > I need to add commands that starts every time?at system boot. > which script is the one that starts first and where can I find it? You can also try to add something like this to root's crontab: @reboot /sbin/mount -a -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From cliftonr at lava.net Sun Jun 7 18:30:39 2009 From: cliftonr at lava.net (Clifton Royston) Date: Sun Jun 7 18:30:48 2009 Subject: I need to add commands that starts every time at system boot. In-Reply-To: <143776.42704.qm@web34307.mail.mud.yahoo.com> References: <143776.42704.qm@web34307.mail.mud.yahoo.com> Message-ID: <20090607183035.GA22240@lava.net> On Sun, Jun 07, 2009 at 10:29:57AM -0700, AES wrote: > I need to add commands that starts every time?at system boot. > ? > which script is the one that starts first and where can I find it? You should add a script of your own to the directory /usr/local/etc/rc.d, and have it check the first parameter to see under what circumstances it is being invoked. If the first parameter is "start", then the system is being started, or at least you are requesting that your script be run as if it were starting. I strongly recommend against adding anything to the /etc/rc script itself. If you feel you just *can't* do it via a script in /usr/local/etc/rc.d, which is the better way, add a script called /etc/rc.local and that will be run after all the other start-up steps. "man rc" for more information, man "rcorder" if you need to control the order in which your script runs relative to other startup scripts. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From claudiu.vasadi at gmail.com Sun Jun 7 18:54:00 2009 From: claudiu.vasadi at gmail.com (claudiu vasadi) Date: Sun Jun 7 18:54:08 2009 Subject: IBM TSM server Message-ID: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> Hello again. About a week ago I cryed on your shoulders but since no one is answering I am crying again. This time with more accurate data. My sistem is a P4 2.66 Mhz (sk 478) Intel P4 processor with 1 GB DDR1 ram, mobo Asus p4p800-x with 2 HDD's. One of them (ad2 ) is a Samsing SpinPoint of 80GB ATA and is the one used by the actual OS. The second one (ad6) is a WD 250 GB S-ATA2 and has some data on it. The server acts as a web server, ftp server, NAS, samba svr, a p2p server (verlihub) and just about every normal app a mental deranged person can have running :P (those kind that dnt have money to buy the ultra ultimate bullshit in hardware or more than two 2 pc's. Leaving this asside here is my situation. Ups, almost forgot. I have a FreeBSD-7.0-STABLE. I have a Windows machine with vmware and solaris on it. In solaris there is a IBM TSM (Tape Storage Management) Server. The server can use disks over tapes to build pools. So I added the local windows disks, and have some 30 G of free space on freebsd, so I thought, I would add them to the storage pool. There's my mistake ... thinking :P Every time I try to add that space to the storage pool the system crashes with a kernel panic. Here is the /var/log/messages file Jun 7 21:03:45 da1 fsck: /dev/ad6s1d: INCORRECT BLOCK COUNT I=5652481 (0 should be 4) (CORRECTED) Jun 7 21:03:45 da1 fsck: /dev/ad6s1d: 16137 files, 45577224 used, 15357050 free (2210 frags, 1919355 blocks, 0.0% fragmentation) Jun 7 21:10:47 da1 syslogd: kernel boot file is /boot/kernel/kernel Jun 7 21:10:47 da1 kernel: ad6: FAILURE - device detached Jun 7 21:10:47 da1 kernel: subdisk6: detached Jun 7 21:10:47 da1 kernel: ad6: detached Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, length=16384)]error = 6 Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, length=16384)]error = 6 Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, length=16384)]error = 6 [...] [...] [...] Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=46438858752, length=16384)]error = 6 Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=46252277760, length=16384)]error = 6 Jun 7 21:10:47 da1 kernel: panic: vinvalbuf: dirty bufs Jun 7 21:10:47 da1 kernel: cpuid = 0 Jun 7 21:10:47 da1 kernel: Uptime: 21m50s Jun 7 21:10:47 da1 kernel: Physical memory: 1011 MB So I'm guesing the script that adds the space to the pool is doing some crap. I tryed using both HDD's but the result is the same -> sistem crash. I have no kernel dump file defined yet (dnt ask why, I've setted up long ago but for some reason this time it didn't write to it) . REPRODUCE: The only way to reproduce the problem is by telling tsm server to add the available 30G off free space. What the tsm server doesm, is it creates a file of a given size, in this case 25G out of the total of 30G, and then populates the file with whatever data it is given as backup data. I really have no ideea if this is the right mailing list for this matter. If it is not, please advise in this matter. From wojtek at wojtek.tensor.gdynia.pl Sun Jun 7 19:38:15 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Sun Jun 7 19:38:28 2009 Subject: IBM TSM server In-Reply-To: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> Message-ID: > Jun 7 21:10:47 da1 kernel: ad6: detached > Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, > length=16384)]error = 6 > Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, > length=16384)]error = 6 > Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, > length=16384)]error = 6 isn;t it trying to read past the end of disk? From claudiu.vasadi at gmail.com Sun Jun 7 20:06:20 2009 From: claudiu.vasadi at gmail.com (claudiu vasadi) Date: Sun Jun 7 20:06:29 2009 Subject: IBM TSM server In-Reply-To: References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> Message-ID: <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> On Sun, Jun 7, 2009 at 9:38 PM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote: > Jun 7 21:10:47 da1 kernel: ad6: detached >> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, >> length=16384)]error = 6 >> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, >> length=16384)]error = 6 >> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, >> length=16384)]error = 6 >> > > > isn;t it trying to read past the end of disk? > Hmm.. I guess you are correct. The question is why is it doing this ? And on both drives ? Feels to me a problem for the developers. HDD's didn't give me one problem since the day the got installed. I'm not saing that they are very good HDD's (in fact they are quite cheap ones) but fail all of a sudden ? And leaving this asside, they dnt give one error on masive transfers and still have very good transfer speed. What I'm saing is that hdd failure could be a posibility of course, but a unlikely one at this point. My problem is that I do not know what tehnik TSM server uses for creating those files because at some point it fails. Strainge thing is that it goes over 1G. First it creates the file and then it populates the file up until the given limit (25G in this case). I will try something tomorow. I will again start the tsm server to add the space (the 25G free space) to the pool and will monitor the file size up until the OS crashes. I'm very curious what's the size of the file when the OS crashes. From utisoft at googlemail.com Sun Jun 7 20:06:38 2009 From: utisoft at googlemail.com (Chris Rees) Date: Sun Jun 7 20:06:44 2009 Subject: I need to add commands that starts every time at system boot. In-Reply-To: <20090607183035.GA22240@lava.net> References: <143776.42704.qm@web34307.mail.mud.yahoo.com> <20090607183035.GA22240@lava.net> Message-ID: 2009/6/7 Clifton Royston : >?If you feel you just *can't* do it via a script in > /usr/local/etc/rc.d, which is the better way, add a script called > /etc/rc.local and that will be run after all the other start-up steps. What's wrong with rc.local? Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? From sullrich at gmail.com Sun Jun 7 20:44:43 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Sun Jun 7 20:44:50 2009 Subject: I need to add commands that starts every time at system boot. In-Reply-To: References: <143776.42704.qm@web34307.mail.mud.yahoo.com> <20090607183035.GA22240@lava.net> Message-ID: On Sun, Jun 7, 2009 at 3:36 PM, Chris Rees wrote: > 2009/6/7 Clifton Royston : > >>?If you feel you just *can't* do it via a script in >> /usr/local/etc/rc.d, which is the better way, add a script called >> /etc/rc.local and that will be run after all the other start-up steps. > > What's wrong with rc.local? Probably stems from this discussion: http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/035996.html Cheers Scott From 000.fbsd at quip.cz Sun Jun 7 21:26:17 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Sun Jun 7 21:26:33 2009 Subject: IBM TSM server In-Reply-To: <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> Message-ID: <4A2C3073.3020700@quip.cz> claudiu vasadi wrote: > On Sun, Jun 7, 2009 at 9:38 PM, Wojciech Puchar < > wojtek@wojtek.tensor.gdynia.pl> wrote: > > >>Jun 7 21:10:47 da1 kernel: ad6: detached >> >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, >>>length=16384)]error = 6 >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, >>>length=16384)]error = 6 >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, >>>length=16384)]error = 6 >>> >> >> >>isn;t it trying to read past the end of disk? >> > > > Hmm.. I guess you are correct. The question is why is it doing this ? It can be caused by wrong disk label (partitioning). Some partition made bigger then real media [disk]. You can see the label by command disklabel ad6s1 and then compare size & offset values with `diskinfo -v ad6` > And on both drives ? > > > Feels to me a problem for the developers. HDD's didn't give me one problem > since the day the got installed. I'm not saing that they are very good HDD's > (in fact they are quite cheap ones) but fail all of a sudden ? And leaving > this asside, they dnt give one error on masive transfers and still have very > good transfer speed. What I'm saing is that hdd failure could be a > posibility of course, but a unlikely one at this point. > > My problem is that I do not know what tehnik TSM server uses for creating > those files because at some point it fails. Strainge thing is that it goes > over 1G. First it creates the file and then it populates the file up until > the given limit (25G in this case). > > I will try something tomorow. I will again start the tsm server to add the > space (the 25G free space) to the pool and will monitor the file size up > until the OS crashes. I'm very curious what's the size of the file when the > OS crashes. From cliftonr at lava.net Sun Jun 7 22:21:13 2009 From: cliftonr at lava.net (Clifton Royston) Date: Sun Jun 7 22:21:20 2009 Subject: I need to add commands that starts every time at system boot. In-Reply-To: References: <143776.42704.qm@web34307.mail.mud.yahoo.com> <20090607183035.GA22240@lava.net> Message-ID: <20090607222110.GA18662@lava.net> On Sun, Jun 07, 2009 at 04:12:41PM -0400, Scott Ullrich wrote: > On Sun, Jun 7, 2009 at 3:36 PM, Chris Rees wrote: > > 2009/6/7 Clifton Royston : > > > >>?If you feel you just *can't* do it via a script in > >> /usr/local/etc/rc.d, which is the better way, add a script called > >> /etc/rc.local and that will be run after all the other start-up steps. > > > > What's wrong with rc.local? > > Probably stems from this discussion: > http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/035996.html No, I hadn't actually seen that discussion before. I used to work on BSD/OS, which had only the rc.local mechanism, and when I first switched over to FreeBSD it was what I used. Eventually I got my head around the /etc/rc.d and /usr/local/etc/rc.d mechanism and found it distinctly superior, so now I use it almost exclusively. Major highlights as to why are: * You can readily implement whatever additional operations your service should support, such as restart/shutdown/whatever; * you can add or remove different services as discrete entities, without having to merge their change or removal into a single text file; * the startup/shutdown script can therefore readily be packaged for removal/installation together with any other software for the service in question; * you can get your service or operation run in a specific order relative to other services; * you can use the same script to start, shutdown, or restart the service at another time if appropriate or necessary It used to be a little harder to write them than a few lines in rc.local, but now sourcing rc_subr provides shell functions which make it trivial. These days I only use rc.local if I need to do some kind of non-critical quick hack, e.g. for troubleshooting a problem. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From marck at rinet.ru Sun Jun 7 22:34:50 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Jun 7 22:34:58 2009 Subject: ZFS isntall requirements In-Reply-To: <4A2BEF7D.5070808@withagen.nl> References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> <4A2BEF7D.5070808@withagen.nl> Message-ID: On Sun, 7 Jun 2009, Willem Jan Withagen wrote: WJW> > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: WJW> > KS> > Hi, WJW> > KS> > WJW> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: WJW> > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib WJW> > KS> > ===> sys/boot/i386/libi386 (install) WJW> > KS> > ===> sys/boot/i386/libfirewire (install) WJW> > KS> > ===> sys/boot/i386/loader (install) WJW> > KS> > make: don't know how to make WJW> > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop WJW> > KS> KS> ISTR that the build was temporarily broken several days ago. WJW> > WJW> > WJW> > Well, according to http://tinderbox.freebsd.org/ it does not ;) WJW> WJW> I'm not at all familiar with the intrinsics of the tinderbox setup. WJW> But am I free to assume that it is not tested with 'WITHOUT_ZFS=yes'??? WJW> WJW> Because that is required to have the trouble surface. Ah well, you're possibly right. In the interim, you can safely comment this line out, as there's nothing (except small amount of disk space) you lose when you compile ZFS but do not use it. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From gaijin.k at gmail.com Mon Jun 8 00:27:03 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Mon Jun 8 00:27:10 2009 Subject: kmem map too small panic after updating to STABLE-7 r192996 In-Reply-To: <4A281250.5050306@commit.it> References: <4A281250.5050306@commit.it> Message-ID: <1244418866.1276.6.camel@RabbitsDen> On Thu, 2009-06-04 at 20:28 +0200, Angelo Turetta wrote: > Tim Chase 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. > > I just had the same problem, and it turned out I was not diligent when I > first set my zfs pool up :) > > To use vm.kmem_size="512M" you need to put > > options KVA_PAGES=512 Are you sure this is the case? RabbitsDen# uname -a FreeBSD RabbitsDen.RabbitsLawn.verizon.net 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Jun 7 12:25:08 EDT 2009 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 RabbitsDen# grep KVA_PAGES /sys/i386/conf/TPX60 options KVA_PAGES=256 <========= RabbitsDen# grep kmem /boot/loader.conf vm.kmem_size_max="512M" vm.kmem_size="512M" RabbitsDen# sysctl vm.kmem_size_max vm.kmem_size_max: 536870912 <========= RabbitsDen# sysctl vm.kmem_size vm.kmem_size: 536870912 RabbitsDen# grep arc /boot/loader.conf vfs.zfs.arc_min="128M" vfs.zfs.arc_max="256M" -- Alexandre Kovalenko (????????? ?????????) From claudiu.vasadi at gmail.com Mon Jun 8 05:59:10 2009 From: claudiu.vasadi at gmail.com (claudiu vasadi) Date: Mon Jun 8 05:59:16 2009 Subject: IBM TSM server In-Reply-To: <4A2C3073.3020700@quip.cz> References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> <4A2C3073.3020700@quip.cz> Message-ID: <4f760c6a0906072259j6d2d2c6ese55769f58e58e11a@mail.gmail.com> On Sun, Jun 7, 2009 at 11:26 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > claudiu vasadi wrote: > >> On Sun, Jun 7, 2009 at 9:38 PM, Wojciech Puchar < >> wojtek@wojtek.tensor.gdynia.pl> wrote: >> >> >> Jun 7 21:10:47 da1 kernel: ad6: detached >>> >>> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, >>>> length=16384)]error = 6 >>>> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, >>>> length=16384)]error = 6 >>>> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, >>>> length=16384)]error = 6 >>>> >>>> >>> >>> isn;t it trying to read past the end of disk? >>> >>> >> >> Hmm.. I guess you are correct. The question is why is it doing this ? >> > > It can be caused by wrong disk label (partitioning). Some partition made > bigger then real media [disk]. > You can see the label by command disklabel ad6s1 and then compare size & > offset values with `diskinfo -v ad6` Here is the ad2: [da1@da1.ro /home/da1]# disklabel ad2s1 # /dev/ad2s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 0 4.2BSD 2048 16384 8 b: 4125328 1048576 swap c: 41929587 0 unused 0 0 # "raw" part, don't edit d: 4159488 5173904 4.2BSD 2048 16384 28552 e: 1048576 9333392 4.2BSD 2048 16384 8 f: 31547619 10381968 4.2BSD 2048 16384 28552 [da1@da1.ro /home/da1]# diskinfo -v ad2 ad2 512 # sectorsize 80060424192 # mediasize in bytes (75G) 156368016 # mediasize in sectors 155127 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:S00JJ30X533937 # Disk ident. And the ad6: [da1@da1.ro /home/da1]# disklabel ad6s1 # /dev/ad6s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 490223412 0 unused 0 0 # "raw" part, don't edit d: 251658240 0 4.2BSD 0 0 0 e: 167772160 251658240 4.2BSD 0 0 0 f: 70793012 419430400 4.2BSD 0 0 0 [da1@da1.ro /home/da1]# diskinfo -v ad6 ad6 512 # sectorsize 251000193024 # mediasize in bytes (234G) 490234752 # mediasize in sectors 486344 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:WD-WCANY2281832 # Disk ident. [da1@da1.ro /home/da1]# From wojtek at wojtek.tensor.gdynia.pl Mon Jun 8 07:13:47 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Mon Jun 8 07:13:54 2009 Subject: IBM TSM server In-Reply-To: <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> Message-ID: > > isn;t it trying to read past the end of disk? > > > Hmm.. I guess you are correct. The question is why is it doing this ? because partition/slice table is wrong? From claudiu.vasadi at gmail.com Mon Jun 8 07:55:53 2009 From: claudiu.vasadi at gmail.com (claudiu vasadi) Date: Mon Jun 8 07:55:59 2009 Subject: IBM TSM server In-Reply-To: References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> <4A2C3073.3020700@quip.cz> <4f760c6a0906072259j6d2d2c6ese55769f58e58e11a@mail.gmail.com> Message-ID: <4f760c6a0906080055p481cb61dm94c7a6ca9e267e0a@mail.gmail.com> On Mon, Jun 8, 2009 at 9:16 AM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote: > > the type fdisk /dev/da1 and then compare the sectors values with what dmesg > says > > fdisk /dev/ad2 : ******* Working on device /dev/ad2 ******* parameters extracted from in-core disklabel are: cylinders=155127 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=155127 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 41929587 (20473 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 41929650, size 114430995 (55874 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 dmesg doesn't say anything usefull. only: ad2: 76351MB at ata1-master UDMA100 I'm not pretty good at this but it seams ok. the disk has been 99% full before and no problems. The slices were created a long time ago and ran some random test that all came out ok. From utisoft at googlemail.com Mon Jun 8 08:50:05 2009 From: utisoft at googlemail.com (Chris Rees) Date: Mon Jun 8 08:50:12 2009 Subject: I need to add commands that starts every time at system boot. In-Reply-To: <20090607222110.GA18662@lava.net> References: <143776.42704.qm@web34307.mail.mud.yahoo.com> <20090607183035.GA22240@lava.net> <20090607222110.GA18662@lava.net> Message-ID: 2009/6/7 Clifton Royston : > On Sun, Jun 07, 2009 at 04:12:41PM -0400, Scott Ullrich wrote: >> On Sun, Jun 7, 2009 at 3:36 PM, Chris Rees wrote: >> > 2009/6/7 Clifton Royston : >> > >> >>?If you feel you just *can't* do it via a script in >> >> /usr/local/etc/rc.d, which is the better way, add a script called >> >> /etc/rc.local and that will be run after all the other start-up steps. >> > >> > What's wrong with rc.local? >> >> Probably stems from this discussion: >> http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/035996.html > > ?No, I hadn't actually seen that discussion before. > > ?I used to work on BSD/OS, which had only the rc.local mechanism, and > when I first switched over to FreeBSD it was what I used. ?Eventually I > got my head around the /etc/rc.d and /usr/local/etc/rc.d mechanism and > found it distinctly superior, so now I use it almost exclusively. > > ?Major highlights as to why are: > > ?* You can readily implement whatever additional operations your service > ? should support, such as restart/shutdown/whatever; > ?* you can add or remove different services as discrete entities, > ? without having to merge their change or removal into a single text > ? file; > ?* the startup/shutdown script can therefore readily be packaged for > ? removal/installation together with any other software for the > ? service in question; > ?* you can get your service or operation run in a specific order > ? relative to other services; > ?* you can use the same script to start, shutdown, or restart the > ? service at another time if appropriate or necessary > > ?It used to be a little harder to write them than a few lines in > rc.local, but now sourcing rc_subr provides shell functions which make > it trivial. > > ?These days I only use rc.local if I need to do some kind of > non-critical quick hack, e.g. for troubleshooting a problem. > ?-- Clifton > > -- > ? ?Clifton Royston ?-- ?cliftonr@iandicomputing.com / cliftonr@lava.net > ? ? ? President ?- I and I Computing * http://www.iandicomputing.com/ > ?Custom programming, network design, systems and network consulting services > Nice, thanks a lot, didn't know about rc_subr. Thanks Scott too. Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? From wjw at digiware.nl Mon Jun 8 10:59:44 2009 From: wjw at digiware.nl (Willem Jan Withagen) Date: Mon Jun 8 10:59:51 2009 Subject: ZFS isntall requirements In-Reply-To: References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> <4A2BEF7D.5070808@withagen.nl> Message-ID: <4A2CEA86.9040509@digiware.nl> Dmitry Morozovsky wrote: > On Sun, 7 Jun 2009, Willem Jan Withagen wrote: > > WJW> > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: > WJW> > KS> > Hi, > WJW> > KS> > > WJW> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: > WJW> > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib > WJW> > KS> > ===> sys/boot/i386/libi386 (install) > WJW> > KS> > ===> sys/boot/i386/libfirewire (install) > WJW> > KS> > ===> sys/boot/i386/loader (install) > WJW> > KS> > make: don't know how to make > WJW> > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop > WJW> > KS> KS> ISTR that the build was temporarily broken several days ago. > WJW> > > WJW> > > WJW> > Well, according to http://tinderbox.freebsd.org/ it does not ;) > WJW> > WJW> I'm not at all familiar with the intrinsics of the tinderbox setup. > WJW> But am I free to assume that it is not tested with 'WITHOUT_ZFS=yes'??? > WJW> > WJW> Because that is required to have the trouble surface. > > Ah well, you're possibly right. In the interim, you can safely comment this > line out, as there's nothing (except small amount of disk space) you lose when > you compile ZFS but do not use it. I was trying to figure out if it was pilot error, or a bug. But now I conclude it is a bug. Should I log a PR? --WjW From clbuisson at orange.fr Mon Jun 8 11:28:32 2009 From: clbuisson at orange.fr (Claude Buisson) Date: Mon Jun 8 11:28:41 2009 Subject: ZFS isntall requirements In-Reply-To: <4A2CEA86.9040509@digiware.nl> References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> <4A2BEF7D.5070808@withagen.nl> <4A2CEA86.9040509@digiware.nl> Message-ID: <4A2CF5DC.8020102@orange.fr> Willem Jan Withagen wrote: > > Dmitry Morozovsky wrote: >> On Sun, 7 Jun 2009, Willem Jan Withagen wrote: >> >> WJW> > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: >> WJW> > KS> > Hi, >> WJW> > KS> > >> WJW> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run >> into: >> WJW> > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib >> WJW> > KS> > ===> sys/boot/i386/libi386 (install) >> WJW> > KS> > ===> sys/boot/i386/libfirewire (install) >> WJW> > KS> > ===> sys/boot/i386/loader (install) >> WJW> > KS> > make: don't know how to make >> WJW> > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop >> WJW> > KS> KS> ISTR that the build was temporarily broken several days >> ago. >> WJW> > WJW> > WJW> > Well, according to http://tinderbox.freebsd.org/ >> it does not ;) >> WJW> WJW> I'm not at all familiar with the intrinsics of the tinderbox >> setup. >> WJW> But am I free to assume that it is not tested with >> 'WITHOUT_ZFS=yes'??? >> WJW> WJW> Because that is required to have the trouble surface. >> >> Ah well, you're possibly right. In the interim, you can safely >> comment this line out, as there's nothing (except small amount of disk >> space) you lose when you compile ZFS but do not use it. > > I was trying to figure out if it was pilot error, or a bug. > But now I conclude it is a bug. > > Should I log a PR? > > --WjW > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freeb, which is invalisd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > This bug exists from some time and has already be discussed on this list. The bug stems from the use of the LIBZFS variable in sys/boot/i386/loader/Makefile: it is not defined in this Makefile if LOADER_ZFS_SUPPORT is not defined, so its value is taken from share/mk/bsd.libnames.mk which is invalid in the WITHOUT_CDDL/WITHOUT_ZFS case. Kip Macy said he would try to fix it by (last) Wednesday. He made a patch, then reverted it (see the svn history). You may use the attached simple patch. Hope it helps, Claude Buisson -------------- next part -------------- --- sys/boot/i386/loader/Makefile.orig 2009-05-24 18:32:41.000000000 +0200 +++ sys/boot/i386/loader/Makefile 2009-06-01 15:18:57.000000000 +0200 @@ -18,7 +18,7 @@ # Put LOADER_ZFS_SUPPORT=yes in /etc/make.conf for ZFS support .if defined(LOADER_ZFS_SUPPORT) CFLAGS+= -DLOADER_ZFS_SUPPORT -LIBZFS= ${.OBJDIR}/../../zfs/libzfsboot.a +LIBZFSBOOT= ${.OBJDIR}/../../zfs/libzfsboot.a .endif # Enable PXE TFTP or NFS support, not both. @@ -105,8 +105,8 @@ # XXX crt0.o needs to be first for pxeboot(8) to work OBJS= ${BTXCRT} -DPADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFS} ${LIBI386} ${LIBSTAND} -LDADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFS} ${LIBI386} -lstand +DPADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFSBOOT} ${LIBI386} ${LIBSTAND} +LDADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFSBOOT} ${LIBI386} -lstand .include From ivoras at freebsd.org Mon Jun 8 12:56:58 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Jun 8 12:57:12 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: <200906020842.42330.jhb@freebsd.org> References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> <200906020842.42330.jhb@freebsd.org> Message-ID: John Baldwin wrote: > On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote: >> Jilles Tjoelker wrote: >>> If process-shared semaphores really work, then the above structure is >>> not a pathological case. Effectively, sem_t is carved in stone. So >>> process-private semaphores should continue to have most of their stuff >>> in a separately allocated structure, to preserve flexibility. >>> >> There was an inadvertent race in FreeBSD's POSIX semaphores which I >> fixed in HEAD and STABLE about 6 weeks before 7.2 was released. >> >> I believe process-shared POSIX semaphores now work -- the Python >> 'multiprocessing' regression test now runs to completion with no errors >> on both HEAD and STABLE. > > The semaphores in recent 7 and 8 are definitely not process-shared (at least > not intentionally). They may work across a fork accidentally, but you can't > store it in an mmap() region and share it with an arbitrary process. > On a completely unrelated subject I was reading about PHP APC cache where they have the same need - cross-process locking with locks embedded in data structures and they have adopted userland spinlock code from PostgreSQL: http://www.scribd.com/doc/3288293/brian-shireapc-facebook (spin)locks are not the same as sempahores but maybe it will help the OP or anyone else trying to implement this feature: http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.h?revision=3.4&view=markup http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.c?revision=3.3&view=markup From fabien.thomas at netasq.com Mon Jun 8 13:01:15 2009 From: fabien.thomas at netasq.com (Fabien Thomas) Date: Mon Jun 8 13:01:22 2009 Subject: Announcement: PmcTools merged to RELENG_7 Message-ID: Hello, The PmcTools is merged to RELENG_7. You can now enjoy the same level of features / hw supported as in head: - Callchain in capture - Core 2 support - Core i7 support - pmcannotate: source code annotation using pmc capture - bug fixes ... Tell me if you find any problems with it. Fabien From richardtector at thekeelecentre.com Mon Jun 8 13:23:00 2009 From: richardtector at thekeelecentre.com (Richard Tector) Date: Mon Jun 8 13:23:08 2009 Subject: buildworld fails with "WITHOUT_CDDL=yes" in src.conf In-Reply-To: <3c1674c90906011518k6d680125hf4b4d7608c92de44@mail.gmail.com> References: <20090531191456.M33035@onet.com.ua> <200906010940.26300.doconnor@gsoft.com.au> <4A2404E5.7010104@orange.fr> <3c1674c90906011518k6d680125hf4b4d7608c92de44@mail.gmail.com> Message-ID: <4A2D10AB.3040007@thekeelecentre.com> Kip Macy wrote: >> The second bug is the use of LOADER_ZFS_SUPPORT without any >> consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) > I'll try get it fixed by Wednesday. Kip, I noticed a fix went in with revision 193494 but was then backed out straight away with no reason. Will this be fixed soon? It is still not possible to build RELENG_7 sources WITHOUT_CDDL. Regards, Richard From adamk at voicenet.com Mon Jun 8 14:32:16 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Mon Jun 8 14:32:23 2009 Subject: Problems with PATA disk Message-ID: <20090608101837.79c3b7d7@voicenet.com> My old workstation finally died and replaced by a Dell Vostro 420. Since the hard drives on the old machine were fine, I decided to throw them into the new machine. The new machine only had SATA onboard, so I added a Promise controller to the mix: atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020 vendor = 'Promise Technology Inc' device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' class = mass storage It has two SATA connectors and a single PATA connector. I had two PATA drives, so that worked out fine, and I hooked them up. The master was the master in the old machine and the slave was the slave in the old machine. No need to change anything around. At first everything was fine. I booted up (using GENERIC, as I nearly always do) and ran for a while. The machine locked up and I decided to bring the machine up in single user mode and run an fsck. It ran just fine on / /tmp /var and /usr (all on the master drive, ad14). I then ran the fsck on ad15s1a (/home). Unfortunately, I almost immediately started receiving 'WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout' messages (along with various other SETFEATURES messages). They were proceeded by both ad14 and ad15 (though, as I said, ad14 fsck'ed fine). This continued for 30 minutes before I gave up and rebooted. When the machine came back up, ad15 had no partition table or disklabel. And fdisk refused to create a partition. Assuming that the drive had gone bad, I swapped it out with another drive. Created a new partition, and labelled it. Restored /home from backups. It ran for about a week, but locked up on me today (as before, when doing something 3D, so I do not believe the backups are related to disk activity), and I decided to manually run a fsck on the system. Unfortunately, I received the same SETFEATURES messages as before when fsck'ing /home. Instead of letting it run for 30 minutes, I stopped after the messages flashed by the screen. I rebooted. The partition table is hosed and there is no disklabel. When I go to create a new partition (per the directions in /usr/share/doc/handbook/disks-adding.html, which is what I used without any problems when I threw the new drive into the system), this is what I happens: [ root@memory - ~ ]: dd if=/dev/zero of=/dev/ad15 bs=1k count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000118 secs (8676702 bytes/sec) [ root@memory - ~ ]: fdisk -BI ad15 ******* Working on device /dev/ad15 ******* fdisk: invalid fdisk partition table found fdisk: Geom not found: "ad15" [ root@memory - ~ ]: bsdlabel -B -w ad15s1 auto bsdlabel: /dev/ad15s1: No such file or directory And, indeed, there is still only /dev/ad15. So I have a few questions... Why do I keep losing my data? How can I partition and label either one of these drives? Some system information: [ root@memory - ~ ]: uname -a FreeBSD memory.visualtech.com 7.2-STABLE FreeBSD 7.2-STABLE #5: Fri May 8 14:02:01 EDT 2009 root@memory.visualtech.com:/usr/obj/usr/src/sys/GENERIC i386 [ root@memory - ~ ]: pciconf -vl hostb0@pci0:0:0:0: class=0x060000 card=0x02821028 chip=0x2e208086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x02821028 chip=0x2e218086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI uhci0@pci0:0:26:0: class=0x0c0300 card=0x02821028 chip=0x3a378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci1@pci0:0:26:1: class=0x0c0300 card=0x02821028 chip=0x3a388086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci2@pci0:0:26:2: class=0x0c0300 card=0x02821028 chip=0x3a398086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB ehci0@pci0:0:26:7: class=0x0c0320 card=0x02821028 chip=0x3a3c8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib2@pci0:0:28:0: class=0x060400 card=0x02821028 chip=0x3a408086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x02821028 chip=0x3a428086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x02821028 chip=0x3a448086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI uhci3@pci0:0:29:0: class=0x0c0300 card=0x02821028 chip=0x3a348086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci4@pci0:0:29:1: class=0x0c0300 card=0x02821028 chip=0x3a358086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci5@pci0:0:29:2: class=0x0c0300 card=0x02821028 chip=0x3a368086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x02821028 chip=0x3a3a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib5@pci0:0:30:0: class=0x060401 card=0x02821028 chip=0x244e8086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x02821028 chip=0x3a168086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA atapci2@pci0:0:31:2: class=0x010601 card=0x02821028 chip=0x3a228086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = mass storage subclass = SATA none0@pci0:0:31:3: class=0x0c0500 card=0x02821028 chip=0x3a308086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x030000 card=0x30001002 chip=0x5b631002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X550 Series' class = display subclass = VGA vgapci1@pci0:1:0:1: class=0x038000 card=0x30011002 chip=0x5b731002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X550 Series - Secondary' class = display atapci0@pci0:3:0:0: class=0x010185 card=0x02821028 chip=0x2363197b rev=0x03 hdr=0x00 vendor = 'JMicron Technology Corp' device = 'JMB36X PCIe-to-SATA-300/IDE RAID Controller' class = mass storage subclass = ATA re0@pci0:4:0:0: class=0x020000 card=0x02821028 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet fxp0@pci0:5:0:0: class=0x020000 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet emu10kx0@pci0:5:1:0: class=0x040100 card=0x80641102 chip=0x00021102 rev=0x0a hdr=0x00 vendor = 'Creative Technology LTD.' device = 't4780010004541 Sound Blaster Live! (Also Live! 5.1) - OEM from DELL - CT4780' class = multimedia subclass = audio none1@pci0:5:1:1: class=0x098000 card=0x00201102 chip=0x70021102 rev=0x0a hdr=0x00 vendor = 'Creative Technology LTD.' device = 'EMU10000 Game Port' class = input device atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' class = mass storage [ root@memory - ~ ]: vmstat procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad14 ad15 in sy cs us sy id 0 0 0 194M 2916M 110 0 1 0 91 0 0 0 119 2024 952 0 0 100 Thanks :-) Adam From dan.naumov at gmail.com Mon Jun 8 14:45:27 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Mon Jun 8 14:46:24 2009 Subject: gptzfsboot and RELENG_7 Message-ID: Hello list Any ideas if gptzfsboot is going to be MFC'ed into RELENG_7 anytime soon? I am going to be building a NAS soon and I would like to have a "full ZFS" system without having to resort to running 8-CURRENT :) Sincerely, - Dan Naumov From adamk at voicenet.com Mon Jun 8 14:57:16 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Mon Jun 8 14:57:22 2009 Subject: Problems with PATA disk In-Reply-To: <20090608101837.79c3b7d7@voicenet.com> References: <20090608101837.79c3b7d7@voicenet.com> Message-ID: <20090608104334.59a4718c@voicenet.com> On Mon, 8 Jun 2009 10:18:37 -0400 Adam K Kirchhoff wrote: > > My old workstation finally died and replaced by a Dell Vostro 420. > Since the hard drives on the old machine were fine, I decided to throw > them into the new machine. The new machine only had SATA onboard, so I added a Promise controller to the mix: > > atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020 > vendor = 'Promise Technology Inc' > device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' > class = mass storage > > It has two SATA connectors and a single PATA connector. I had two PATA > drives, so that worked out fine, and I hooked them up. The master was > the master in the old machine and the slave was the slave in the old > machine. No need to change anything around. > > At first everything was fine. I booted up (using GENERIC, as I nearly > always do) and ran for a while. The machine locked up and I decided to > bring the machine up in single user mode and run an fsck. It ran just > fine on / /tmp /var and /usr (all on the master drive, ad14). I then > ran the fsck on ad15s1a (/home). Unfortunately, I almost immediately > started receiving 'WARNING - SETFEATURES SET TRANSFER MODE taskqueue > timeout' messages (along with various other SETFEATURES messages). > They were proceeded by both ad14 and ad15 (though, as I said, ad14 > fsck'ed fine). > > This continued for 30 minutes before I gave up and rebooted. When the > machine came back up, ad15 had no partition table or disklabel. And > fdisk refused to create a partition. > > Assuming that the drive had gone bad, I swapped it out with another > drive. Created a new partition, and labelled it. Restored /home from > backups. It ran for about a week, but locked up on me today (as > before, when doing something 3D, so I do not believe the backups are > related to disk activity), and I decided to manually run a fsck on the > system. Unfortunately, I received the same SETFEATURES messages as > before when fsck'ing /home. Instead of letting it run for 30 minutes, I > stopped after the messages flashed by the screen. I rebooted. The > partition table is hosed and there is no disklabel. > > When I go to create a new partition (per the directions > in /usr/share/doc/handbook/disks-adding.html, which is what I used > without any problems when I threw the new drive into the system), this > is what I happens: > > [ root@memory - ~ ]: dd if=/dev/zero of=/dev/ad15 bs=1k count=1 > 1+0 records in > 1+0 records out > 1024 bytes transferred in 0.000118 secs (8676702 bytes/sec) > [ root@memory - ~ ]: fdisk -BI ad15 > ******* Working on device /dev/ad15 ******* > fdisk: invalid fdisk partition table found > fdisk: Geom not found: "ad15" > [ root@memory - ~ ]: bsdlabel -B -w ad15s1 auto > bsdlabel: /dev/ad15s1: No such file or directory > > And, indeed, there is still only /dev/ad15. > > So I have a few questions... > > Why do I keep losing my data? > How can I partition and label either one of these drives? > > Some system information: > > [ root@memory - ~ ]: uname -a > FreeBSD memory.visualtech.com 7.2-STABLE FreeBSD 7.2-STABLE #5: Fri May 8 14:02:01 EDT 2009 root@memory.visualtech.com:/usr/obj/usr/src/sys/GENERIC i386 > [ root@memory - ~ ]: pciconf -vl > hostb0@pci0:0:0:0: class=0x060000 card=0x02821028 chip=0x2e208086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0x02821028 chip=0x2e218086 rev=0x03 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > uhci0@pci0:0:26:0: class=0x0c0300 card=0x02821028 chip=0x3a378086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci1@pci0:0:26:1: class=0x0c0300 card=0x02821028 chip=0x3a388086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci2@pci0:0:26:2: class=0x0c0300 card=0x02821028 chip=0x3a398086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > ehci0@pci0:0:26:7: class=0x0c0320 card=0x02821028 chip=0x3a3c8086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > pcib2@pci0:0:28:0: class=0x060400 card=0x02821028 chip=0x3a408086 rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:28:1: class=0x060400 card=0x02821028 chip=0x3a428086 rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:28:2: class=0x060400 card=0x02821028 chip=0x3a448086 rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > uhci3@pci0:0:29:0: class=0x0c0300 card=0x02821028 chip=0x3a348086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci4@pci0:0:29:1: class=0x0c0300 card=0x02821028 chip=0x3a358086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci5@pci0:0:29:2: class=0x0c0300 card=0x02821028 chip=0x3a368086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > ehci1@pci0:0:29:7: class=0x0c0320 card=0x02821028 chip=0x3a3a8086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > pcib5@pci0:0:30:0: class=0x060401 card=0x02821028 chip=0x244e8086 rev=0x90 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0x02821028 chip=0x3a168086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-ISA > atapci2@pci0:0:31:2: class=0x010601 card=0x02821028 chip=0x3a228086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = mass storage > subclass = SATA > none0@pci0:0:31:3: class=0x0c0500 card=0x02821028 chip=0x3a308086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = SMBus > vgapci0@pci0:1:0:0: class=0x030000 card=0x30001002 chip=0x5b631002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon X550 Series' > class = display > subclass = VGA > vgapci1@pci0:1:0:1: class=0x038000 card=0x30011002 chip=0x5b731002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon X550 Series - Secondary' > class = display > atapci0@pci0:3:0:0: class=0x010185 card=0x02821028 chip=0x2363197b rev=0x03 hdr=0x00 > vendor = 'JMicron Technology Corp' > device = 'JMB36X PCIe-to-SATA-300/IDE RAID Controller' > class = mass storage > subclass = ATA > re0@pci0:4:0:0: class=0x020000 card=0x02821028 chip=0x816810ec rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > fxp0@pci0:5:0:0: class=0x020000 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 > vendor = 'Intel Corporation' > device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' > class = network > subclass = ethernet > emu10kx0@pci0:5:1:0: class=0x040100 card=0x80641102 chip=0x00021102 rev=0x0a hdr=0x00 > vendor = 'Creative Technology LTD.' > device = 't4780010004541 Sound Blaster Live! (Also Live! 5.1) - OEM from DELL - CT4780' > class = multimedia > subclass = audio > none1@pci0:5:1:1: class=0x098000 card=0x00201102 chip=0x70021102 rev=0x0a hdr=0x00 > vendor = 'Creative Technology LTD.' > device = 'EMU10000 Game Port' > class = input device > atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x02 hdr=0x00 > vendor = 'Promise Technology Inc' > device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' > class = mass storage > [ root@memory - ~ ]: vmstat > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr ad14 ad15 in sy cs us sy id > 0 0 0 194M 2916M 110 0 1 0 91 0 0 0 119 2024 952 0 0 100 > My apologies for replying to my first e-mail. I'm not sure why this didn't occur to me the first time this happened, but I completely powered off my machine, and then powered it back on. It could see the partition table and disklabel on ad15 again. I attempted an fsck, and I received the same errors as before, but this time I hit a kernel panic, too: GEOM_LABEL: Label ufsid/4a296b573007b5f2 removed. Jun 8 14:35:42 memory last message repeated 7 times ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request directly ad14: WARNING - SET_MULTI taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad15: WARNING - SET_MULTI taskqueue timeout - completing request directly ad15: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=470440143 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07d4d94 stack pointer = 0x28:0xc62f9c00 frame pointer = 0x28:0xc62f9c18 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 23 (swi6: task queue) trap number = 12 panic: page fault cpuid = 0 Uptime: 1m56s Physical memory: 3058 MB Dumping 113 MB: 98 82 66 50 34 18 2 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs Unfortunately, nothing showed up in /var/crash, which I think is odd. I'll update my -STABLE, rebuild my kernel with debugging, and hope to catch something next time. In the mean time, I'd appreciate any help I could get on resolving this problem. Adam From jhb at freebsd.org Mon Jun 8 15:33:52 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 8 15:34:16 2009 Subject: Panic resource_list_alloc 7.2 stable In-Reply-To: <20090606071431.092609ce@vaio> References: <20090606071431.092609ce@vaio> Message-ID: <200906081045.39497.jhb@freebsd.org> On Saturday 06 June 2009 10:14:31 am Robert wrote: > Greetings > > This problem seems the same as this one from May of this year > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > This happens on an older HP laptop. It was running on 7.1 prerelease > fine and then I updated to 7.2 Stable yesterday. > > FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri Jun 5 > 11:47:29 PDT 2009 > root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386 > > The bits from pciconf > > atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 chip=0x71118086 > rev=0x01 hdr=0x00 vendor = 'Intel Corporation' > device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' > class = mass storage > subclass = ATA > > The date of ata-chipset.c > > -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c > > The chipset is found in the above file > > ata_intel_ident(device_t dev) > { > struct ata_pci_controller *ctlr = device_get_softc(dev); > static struct ata_chip_id ids[] = > {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, > { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, > { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > ^^^^^^^ > { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > I can include the dump if needed but I am not at this time to shorten > the email. But here is the panic. > > Dump header from device /dev/ad0s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 68939776B (65 MB) > Blocksize: 512 > Dumptime: Sat Jun 6 05:40:52 2009 > Hostname: hp.shasta204.local > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT 2009 > root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA > Panic String: resource_list_alloc: resource entry is busy > Dump Parity: 3285399556 > Bounds: 1 > Dump Status: good > > > Any help would be greatly appreciated. The last screen of the dmesg output would be helpful. -- John Baldwin From dan.naumov at gmail.com Mon Jun 8 15:44:41 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Mon Jun 8 15:44:49 2009 Subject: gptzfsboot and RELENG_7 In-Reply-To: <4A2D26D8.8030008@egr.msu.edu> References: <4A2D26D8.8030008@egr.msu.edu> Message-ID: Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 indicated that even after that MFC, you still needed gptzfsboot from 8-CURRENT to be able to boot from a full ZFS system. Is this not the case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot in my /boot, only gptboot. I didn't make any changes to the stock Makefiles and used GENERIC kernel config. Do I need to adjust some options for gptzfsboot to get built? - Dan Naumov >> > > 5/25/09 - last month > From villa.alberto at gmail.com Mon Jun 8 16:49:50 2009 From: villa.alberto at gmail.com (Alberto Villa) Date: Mon Jun 8 16:50:07 2009 Subject: gptzfsboot and RELENG_7 In-Reply-To: References: <4A2D26D8.8030008@egr.msu.edu> Message-ID: <200906081849.45373.villa.alberto@gmail.com> On Monday 08 June 2009 17:44:40 Dan Naumov wrote: > Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 > indicated that even after that MFC, you still needed gptzfsboot from > 8-CURRENT to be able to boot from a full ZFS system. Is this not the > case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot > in my /boot, only gptboot. I didn't make any changes to the stock > Makefiles and used GENERIC kernel config. Do I need to adjust some > options for gptzfsboot to get built? no, it's /boot/loader from 8-current which is needed (the one shared on this list works perfectly for me) to build your system with zfs boot support just add LOADER_ZFS_SUPPORT=yes to /etc/make.conf -- Alberto Villa From dan.naumov at gmail.com Mon Jun 8 17:05:31 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Mon Jun 8 17:06:03 2009 Subject: /boot/loader and RELENG_7 (WAS: gptzfsboot and RELENG_7) Message-ID: Ah, so there is still a (small) piece of 8-CURRENT needed to have a working 7-STABLE zfs boot configuration? I am getting really confused now, if I add LOADER_ZFS_SUPPORT=yes to my /etc/make.conf, the RELENG_7 system will be built with zfs boot support, but I still need the actual /boot/loader from 8-CURRENT? Is that getting MFC'ed into into RELENG_7 anytime soon? Where are all make.conf options documented by the way? Neither /usr/share/examples/etc/make.conf nor "man make.conf" make any reference to the LOADER_ZFS_SUPPORT option. - Dan Naumov On Mon, Jun 8, 2009 at 7:49 PM, Alberto Villa wrote: > On Monday 08 June 2009 17:44:40 Dan Naumov wrote: >> Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 >> indicated that even after that MFC, you still needed gptzfsboot from >> 8-CURRENT to be able to boot from a full ZFS system. Is this not the >> case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot >> in my /boot, only gptboot. I didn't make any changes to the stock >> Makefiles and used GENERIC kernel config. Do I need to adjust some >> options for gptzfsboot to get built? > > no, it's /boot/loader from 8-current which is needed (the one shared on this > list works perfectly for me) > to build your system with zfs boot support just add LOADER_ZFS_SUPPORT=yes > to /etc/make.conf > -- > Alberto Villa From to.my.trociny at gmail.com Mon Jun 8 17:50:20 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Mon Jun 8 17:50:55 2009 Subject: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 Message-ID: <86d49eocwx.fsf@kopusha.onet> After recent upgrade (on June 3) of my 7-stable host (WITNESS is enabled, the previous build was Apr 26), I have been experienced panics when starting some our home made application: Architecture: i386 Architecture Version: 2 Dump Length: 73797632B (70 MB) Blocksize: 512 Dumptime: Mon Jun 8 15:29:14 2009 Hostname: zhuzha.ua1 Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.2-STABLE #18: Wed Jun 3 14:28:49 EEST 2009 root@zhuzha.ua1:/usr/obj/usr/src/sys/DEBUG Panic String: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 Dump Parity: 1277108796 Bounds: 18 Narrowing down the problem I have written a simple test program (in attaches) that models in simplified way the behaviour or our application and reproduces the crash. There are two threads. One of the threads is doing vfork/exec to start child process while the other is monitoring the status of the child calling wait4(). At the moment of the crash the parent vfork thread is sleeping on wchan=0xc4d17ae0 (td->td_proc) with lock=0xc4d178b8 waiting for the child to exec. The parent wait4 thread with lock=0xc4d17b70 and the same wchan calls sleepq_lookup(wchan) to check if the wait channel already have a sleep queue associated with it, finds the queue of the vfork thread, tries to insert the current thread into this sleep queue and fails on assertion lock==sq->sq_lock. wait4 treead: (kgdb) thr 128 [Switching to thread 128 (Thread 100164)]#0 doadump () at pcpu.h:196 196 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0496509 in db_fncall (dummy1=-1061924641, dummy2=0, dummy3=-1, dummy4=0xe69a089c "") at /usr/src/sys/ddb/db_command.c:516 #2 0xc0496abf in db_command (last_cmdp=0xc0c9ab54, cmd_table=0x0, dopager=0) at /usr/src/sys/ddb/db_command.c:413 #3 0xc0496b34 in db_command_script (command=0xc0c9baa4 "call doadump") at /usr/src/sys/ddb/db_command.c:484 #4 0xc049a3a0 in db_script_exec (scriptname=0xe69a09a8 "kdb.enter.panic", warnifnotfound=Variable "warnifnotfound" is not available. ) at /usr/src/sys/ddb/db_script.c:302 #5 0xc049a47d in db_script_kdbenter (eventname=0xc0b8fa85 "panic") at /usr/src/sys/ddb/db_script.c:324 #6 0xc0498388 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:227 #7 0xc0810d36 in kdb_trap (type=3, code=0, tf=0xe69a0ae0) at /usr/src/sys/kern/subr_kdb.c:524 #8 0xc0add6ab in trap (frame=0xe69a0ae0) at /usr/src/sys/i386/i386/trap.c:688 #9 0xc0ac159b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #10 0xc0810eba in kdb_enter_why (why=0xc0b8fa85 "panic", msg=0xc0b8fa85 "panic") at cpufunc.h:60 #11 0xc07e4216 in panic (fmt=0xc0b5ecd3 "Assertion %s failed at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:557 #12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70, wmesg=0xc0b959c1 "wait", flags=256, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327 #13 0xc07ec94b in _sleep (ident=0xc4d17ae0, lock=Variable "lock" is not available. ) at /usr/src/sys/kern/kern_synch.c:203 #14 0xc07bd8e6 in kern_wait (td=0xc41e8480, pid=-1, status=0xe69a0c2c, options=Variable "options" is not available. ) at /usr/src/sys/kern/kern_exit.c:902 #15 0xc07bd95b in wait4 (td=0xc41e8480, uap=0xe69a0cfc) at /usr/src/sys/kern/kern_exit.c:688 #16 0xc0adce23 in syscall (frame=0xe69a0d38) at /usr/src/sys/i386/i386/trap.c:1090 #17 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 12 #12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70, wmesg=0xc0b959c1 "wait", flags=256, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327 327 MPASS(lock == sq->sq_lock); (kgdb) p lock $1 = (struct lock_object *) 0xc4d17b70 (kgdb) p sq->sq_lock $2 = (struct lock_object *) 0xc4d178b8 (kgdb) p *lock $3 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process lock", lo_flags = 21168128, lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness = 0xc0ce4840}} (kgdb) p *sq->sq_lock $4 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process lock", lo_flags = 21168128, lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness = 0xc0ce4840}} vfork thread of the parent process: (kgdb) thr 127 [Switching to thread 127 (Thread 100162)]#0 sched_switch (td=0xc41e86c0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xc41e86c0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xc07ec4c3 in mi_switch (flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_synch.c:444 #2 0xc0818bd2 in sleepq_switch (wchan=0xc4d17ae0) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xc0819800 in sleepq_wait (wchan=0xc4d17ae0) at /usr/src/sys/kern/subr_sleepqueue.c:580 #4 0xc07eca69 in _sleep (ident=0xc4d17ae0, lock=0xc4d178b8, priority=92, wmesg=0xc0b8bacb "ppwait", timo=0) at /usr/src/sys/kern/kern_synch.c:230 #5 0xc07c0631 in fork1 (td=0xc41e86c0, flags=-2147483596, pages=0, procp=0xe699ac78) at /usr/src/sys/kern/kern_fork.c:747 #6 0xc07c07c9 in vfork (td=0xc41e86c0, uap=0xe699acfc) at /usr/src/sys/kern/kern_fork.c:124 #7 0xc0adce23 in syscall (frame=0xe699ad38) at /usr/src/sys/i386/i386/trap.c:1090 #8 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #9 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) And here is the child process: (kgdb) thr 129 [Switching to thread 129 (Thread 100163)]#0 sched_switch (td=0xc4d1d900, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xc4d1d900, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xc07ec4c3 in mi_switch (flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_synch.c:444 #2 0xc0818bd2 in sleepq_switch (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xc0818e6f in sleepq_catch_signals (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:417 #4 0xc0819647 in sleepq_timedwait_sig (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:631 #5 0xc07eca31 in _sleep (ident=0xc0ccdac4, lock=0x0, priority=348, wmesg=0xc0b90bcd "nanslp", timo=2) at /usr/src/sys/kern/kern_synch.c:224 #6 0xc07f3f51 in kern_nanosleep (td=0xc4d1d900, rqt=0xe699dc64, rmt=0xe699dc6c) at /usr/src/sys/kern/kern_time.c:373 #7 0xc07f594f in nanosleep (td=0xc4d1d900, uap=0xe699dcfc) at /usr/src/sys/kern/kern_time.c:415 #8 0xc0adce23 in syscall (frame=0xe699dd38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) p &td->td_proc.p_mtx $5 = (struct mtx *) 0xc4d178b8 Actually, I am not sure that the problem is observed only on the recent STABLE. It might have not been triggered by our application before the upgrade. Currently I don't have the system with some old STABLE to check this running the test program. -- Mikolaj Golub From mcdouga9 at egr.msu.edu Mon Jun 8 18:12:21 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Mon Jun 8 18:12:29 2009 Subject: /boot/loader and RELENG_7 (WAS: gptzfsboot and RELENG_7) In-Reply-To: References: Message-ID: <4A2D5483.2080004@egr.msu.edu> Dan Naumov wrote: > Ah, so there is still a (small) piece of 8-CURRENT needed to have a > working 7-STABLE zfs boot configuration? I am getting really confused > now, if I add LOADER_ZFS_SUPPORT=yes to my /etc/make.conf, the > RELENG_7 system will be built with zfs boot support, but I still need > the actual /boot/loader from 8-CURRENT? Is that getting MFC'ed into > into RELENG_7 anytime soon? > > Where are all make.conf options documented by the way? Neither > /usr/share/examples/etc/make.conf nor "man make.conf" make any > reference to the LOADER_ZFS_SUPPORT option. > > - Dan Naumov > > > ZFS booting without partitions > See the last emails in the thread "ZFS booting without partitions", it has a patch which makes the -stable loader work (some changes that didn't get merged to -stable). I think only the change from 8 to 64 is all thats needed but I applied the whole patch when I tested it. Also, yes LOADER_ZFS_SUPPORT causes gptzfsboot to be compiled as well as add ZFS support to loader (and other stuff). It may not have been documented (I didn't check). From kostikbel at gmail.com Mon Jun 8 18:17:40 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Jun 8 18:17:47 2009 Subject: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 In-Reply-To: <86d49eocwx.fsf@kopusha.onet> References: <86d49eocwx.fsf@kopusha.onet> Message-ID: <20090608181728.GU1927@deviant.kiev.zoral.com.ua> On Mon, Jun 08, 2009 at 08:25:50PM +0300, Mikolaj Golub wrote: > After recent upgrade (on June 3) of my 7-stable host (WITNESS is enabled, the > previous build was Apr 26), I have been experienced panics when starting some > our home made application: > > Architecture: i386 > Architecture Version: 2 > Dump Length: 73797632B (70 MB) > Blocksize: 512 > Dumptime: Mon Jun 8 15:29:14 2009 > Hostname: zhuzha.ua1 > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 7.2-STABLE #18: Wed Jun 3 14:28:49 EEST 2009 > root@zhuzha.ua1:/usr/obj/usr/src/sys/DEBUG > Panic String: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 > Dump Parity: 1277108796 > Bounds: 18 > > Narrowing down the problem I have written a simple test program (in attaches) > that models in simplified way the behaviour or our application and reproduces > the crash. There are two threads. One of the threads is doing vfork/exec to > start child process while the other is monitoring the status of the child > calling wait4(). > > At the moment of the crash the parent vfork thread is sleeping on > wchan=0xc4d17ae0 (td->td_proc) with lock=0xc4d178b8 waiting for the child to > exec. The parent wait4 thread with lock=0xc4d17b70 and the same wchan calls > sleepq_lookup(wchan) to check if the wait channel already have a sleep queue > associated with it, finds the queue of the vfork thread, tries to insert the > current thread into this sleep queue and fails on assertion lock==sq->sq_lock. > > wait4 treead: > > (kgdb) thr 128 > [Switching to thread 128 (Thread 100164)]#0 doadump () at pcpu.h:196 > 196 in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc0496509 in db_fncall (dummy1=-1061924641, dummy2=0, dummy3=-1, dummy4=0xe69a089c "") > at /usr/src/sys/ddb/db_command.c:516 > #2 0xc0496abf in db_command (last_cmdp=0xc0c9ab54, cmd_table=0x0, dopager=0) > at /usr/src/sys/ddb/db_command.c:413 > #3 0xc0496b34 in db_command_script (command=0xc0c9baa4 "call doadump") > at /usr/src/sys/ddb/db_command.c:484 > #4 0xc049a3a0 in db_script_exec (scriptname=0xe69a09a8 "kdb.enter.panic", warnifnotfound=Variable "warnifnotfound" is not available. > ) > at /usr/src/sys/ddb/db_script.c:302 > #5 0xc049a47d in db_script_kdbenter (eventname=0xc0b8fa85 "panic") at /usr/src/sys/ddb/db_script.c:324 > #6 0xc0498388 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:227 > #7 0xc0810d36 in kdb_trap (type=3, code=0, tf=0xe69a0ae0) at /usr/src/sys/kern/subr_kdb.c:524 > #8 0xc0add6ab in trap (frame=0xe69a0ae0) at /usr/src/sys/i386/i386/trap.c:688 > #9 0xc0ac159b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 > #10 0xc0810eba in kdb_enter_why (why=0xc0b8fa85 "panic", msg=0xc0b8fa85 "panic") at cpufunc.h:60 > #11 0xc07e4216 in panic (fmt=0xc0b5ecd3 "Assertion %s failed at %s:%d") > at /usr/src/sys/kern/kern_shutdown.c:557 > #12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70, wmesg=0xc0b959c1 "wait", flags=256, > queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327 > #13 0xc07ec94b in _sleep (ident=0xc4d17ae0, lock=Variable "lock" is not available. > ) at /usr/src/sys/kern/kern_synch.c:203 > #14 0xc07bd8e6 in kern_wait (td=0xc41e8480, pid=-1, status=0xe69a0c2c, options=Variable "options" is not available. > ) > at /usr/src/sys/kern/kern_exit.c:902 > #15 0xc07bd95b in wait4 (td=0xc41e8480, uap=0xe69a0cfc) at /usr/src/sys/kern/kern_exit.c:688 > #16 0xc0adce23 in syscall (frame=0xe69a0d38) at /usr/src/sys/i386/i386/trap.c:1090 > #17 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 > #18 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) fr 12 > #12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70, wmesg=0xc0b959c1 "wait", flags=256, > queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327 > 327 MPASS(lock == sq->sq_lock); > (kgdb) p lock > $1 = (struct lock_object *) 0xc4d17b70 > (kgdb) p sq->sq_lock > $2 = (struct lock_object *) 0xc4d178b8 > (kgdb) p *lock > $3 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process lock", lo_flags = 21168128, > lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness = 0xc0ce4840}} > (kgdb) p *sq->sq_lock > $4 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process lock", lo_flags = 21168128, > lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness = 0xc0ce4840}} > > vfork thread of the parent process: > > (kgdb) thr 127 > [Switching to thread 127 (Thread 100162)]#0 sched_switch (td=0xc41e86c0, newtd=Variable "newtd" is not available. > ) > at /usr/src/sys/kern/sched_ule.c:1944 > 1944 cpuid = PCPU_GET(cpuid); > (kgdb) bt > #0 sched_switch (td=0xc41e86c0, newtd=Variable "newtd" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1944 > #1 0xc07ec4c3 in mi_switch (flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc0818bd2 in sleepq_switch (wchan=0xc4d17ae0) at /usr/src/sys/kern/subr_sleepqueue.c:497 > #3 0xc0819800 in sleepq_wait (wchan=0xc4d17ae0) at /usr/src/sys/kern/subr_sleepqueue.c:580 > #4 0xc07eca69 in _sleep (ident=0xc4d17ae0, lock=0xc4d178b8, priority=92, wmesg=0xc0b8bacb "ppwait", > timo=0) at /usr/src/sys/kern/kern_synch.c:230 > #5 0xc07c0631 in fork1 (td=0xc41e86c0, flags=-2147483596, pages=0, procp=0xe699ac78) > at /usr/src/sys/kern/kern_fork.c:747 > #6 0xc07c07c9 in vfork (td=0xc41e86c0, uap=0xe699acfc) at /usr/src/sys/kern/kern_fork.c:124 > #7 0xc0adce23 in syscall (frame=0xe699ad38) at /usr/src/sys/i386/i386/trap.c:1090 > #8 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 > #9 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > And here is the child process: > > (kgdb) thr 129 > [Switching to thread 129 (Thread 100163)]#0 sched_switch (td=0xc4d1d900, newtd=Variable "newtd" is not available. > ) > at /usr/src/sys/kern/sched_ule.c:1944 > 1944 cpuid = PCPU_GET(cpuid); > (kgdb) bt > #0 sched_switch (td=0xc4d1d900, newtd=Variable "newtd" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1944 > #1 0xc07ec4c3 in mi_switch (flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc0818bd2 in sleepq_switch (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:497 > #3 0xc0818e6f in sleepq_catch_signals (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:417 > #4 0xc0819647 in sleepq_timedwait_sig (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:631 > #5 0xc07eca31 in _sleep (ident=0xc0ccdac4, lock=0x0, priority=348, wmesg=0xc0b90bcd "nanslp", timo=2) > at /usr/src/sys/kern/kern_synch.c:224 > #6 0xc07f3f51 in kern_nanosleep (td=0xc4d1d900, rqt=0xe699dc64, rmt=0xe699dc6c) > at /usr/src/sys/kern/kern_time.c:373 > #7 0xc07f594f in nanosleep (td=0xc4d1d900, uap=0xe699dcfc) at /usr/src/sys/kern/kern_time.c:415 > #8 0xc0adce23 in syscall (frame=0xe699dd38) at /usr/src/sys/i386/i386/trap.c:1090 > #9 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 > #10 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) p &td->td_proc.p_mtx > $5 = (struct mtx *) 0xc4d178b8 > > Actually, I am not sure that the problem is observed only on the recent > STABLE. It might have not been triggered by our application before the > upgrade. Currently I don't have the system with some old STABLE to check this > running the test program. This is fixed in HEAD by r185647. I did not merged it to 7, because I do not believe that somebody runs stable with INVARIANTS on :). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090608/942fab5c/attachment.pgp From bjb at darco.dk Mon Jun 8 19:42:02 2009 From: bjb at darco.dk (Bjarne) Date: Mon Jun 8 19:42:10 2009 Subject: flooded with "ath0: stuck beacon; resetting (bmiss count 4)" after upgrade to 7.2-stable Message-ID: <4A2D64D4.9060106@darco.dk> After upgrading from FreeBSD 7.1-RELEASE to FreeBSD 7.2-STABLE I Get a gazillion of these : kernel: ath0: stuck beacon; resetting (bmiss count 4) in /var/log/messages Mostly when all workstations are turned off. The messagestorm slows down after the first workstation has connected, but there are still a LOT of messages The Hardware is exactly the same as before the upgrade. No change whatsoever. I am uing the atheros card as a host AP and I have tried different settings with ifconfig like -bgscan to no avail. So please : how to stop these emssages ? v8 # ifconfig ath0 ath0: flags=8943 metric 0 mtu 2290 ether 00:18:4d:ec:7d:07 inet 192.168.1.103 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid XXXXXX channel 1 (2412 Mhz 11g) bssid 00:18:4d:ec:7d:07 authmode WPA1+WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 1000 protmode CTS burst hidessid dtimperiod 1 Current dmesg from 7.2 stable : ================================================= Copyright (c) 1992-2009 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.2-STABLE #2: Sun Jun 7 17:14:11 CEST 2009 toor@v8.YYYYY.dk:/usr/obj/usr/src/sys/V8 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1600+ (1401.72-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc0480800 real memory = 805240832 (767 MB) avail memory = 773959680 (738 MB) kbd1 at kbdmux0 acpi0: <761686 AWRDACPI> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc400-0xc40f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xc800-0xc81f irq 5 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcc00-0xcc1f irq 5 at device 7.3 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) vgapci0: mem 0xf0000000-0xf0003fff,0xf1000000-0xf17fffff irq 5 at device 11.0 on pci0 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xd000-0xd03f irq 12 at device 15.0 on pci0 miibus0: on xl0 nsphy0: PHY 24 on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:57:5a:bf xl0: [ITHREAD] ath0: mem 0xf3000000-0xf300ffff irq 10 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:18:4d:ec:7d:07 ath0: mac 7.9 phy 4.5 radio 5.6 atapci1: port 0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07,0xe000-0xe003,0xe400-0xe4ff irq 11 at device 19.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_throttle0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1401715949 Hz quality 800 Timecounters tick every 1.000 msec ad0: 152627MB at ata0-master UDMA100 acd0: DVDROM at ata1-master UDMA66 ad4: 152627MB at ata2-master UDMA100 ad6: 152627MB at ata3-master UDMA100 GEOM_MIRROR: Device mirror/gm0s1 launched (1/1). GEOM_MIRROR: Device gm0s1: provider ad6s1 marked as inactive, skipping. GEOM_LABEL: Label for provider ad4s1a is ufsid/43764dd0e4c68fd0. GEOM_LABEL: Label for provider ad4s1d is ufsid/43764dd570a98422. GEOM_LABEL: Label for provider ad4s1e is ufsid/43764dd8ec27faff. GEOM_LABEL: Label for provider ad4s1f is ufsid/43764ddc8f945f3f. Trying to mount root from ufs:/dev/mirror/gm0s1a bridge0: Ethernet address: 42:87:0c:b1:1e:f6 ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ============================== dmesg from 7.1-release : (same hardware - with no problems) ============================== Copyright (c) 1992-2009 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.1-RELEASE-p4 #0: Sun Apr 5 20:22:16 CEST 2009 toor@v8.YYYYY.dk:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1600+ (1401.72-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc0480800 real memory = 805240832 (767 MB) avail memory = 773980160 (738 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: <761686 AWRDACPI> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc400-0xc40f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xc800-0xc81f irq 5 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcc00-0xcc1f irq 5 at device 7.3 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) vgapci0: mem 0xf0000000-0xf0003fff,0xf1000000-0xf17fffff irq 5 at device 11.0 on pci0 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xd000-0xd03f irq 12 at device 15.0 on pci0 miibus0: on xl0 nsphy0: PHY 24 on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:57:5a:bf xl0: [ITHREAD] ath0: mem 0xf3000000-0xf300ffff irq 10 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:18:4d:ec:7d:07 ath0: mac 7.9 phy 4.5 radio 5.6 atapci1: port 0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07,0xe000-0xe003,0xe400-0xe4ff irq 11 at device 19.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_throttle0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1401715696 Hz quality 800 Timecounters tick every 1.000 msec ad0: 152627MB at ata0-master UDMA100 acd0: DVDROM at ata1-master UDMA66 ad4: 152627MB at ata2-master UDMA100 ad6: 152627MB at ata3-master UDMA100 GEOM_MIRROR: Device gm0s1: provider ad4s1 marked as inactive, skipping. Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR GEOM_MIRROR: Force device gm0s1 start due to timeout. GEOM_MIRROR: Device mirror/gm0s1 launched (2/3). Trying to mount root from ufs:/dev/mirror/gm0s1a bridge0: Ethernet address: 9e:0e:a9:07:08:01 ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 From tinderbox at freebsd.org Mon Jun 8 22:42:27 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 22:42:40 2009 Subject: [releng_7 tinderbox] failure on i386/i386 Message-ID: <20090608224221.42C7C1B5060@freebsd-stable.sentex.ca> TB --- 2009-06-08 21:28:33 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 21:28:33 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-06-08 21:28:33 - cleaning the object tree TB --- 2009-06-08 21:28:56 - cvsupping the source tree TB --- 2009-06-08 21:28:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-06-08 21:29:10 - building world TB --- 2009-06-08 21:29:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 21:29:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 21:29:10 - TARGET=i386 TB --- 2009-06-08 21:29:10 - TARGET_ARCH=i386 TB --- 2009-06-08 21:29:10 - TZ=UTC TB --- 2009-06-08 21:29:10 - __MAKE_CONF=/dev/null TB --- 2009-06-08 21:29:10 - cd /src TB --- 2009-06-08 21:29:10 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 21:29:11 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 8 22:36:06 UTC 2009 TB --- 2009-06-08 22:36:06 - generating LINT kernel config TB --- 2009-06-08 22:36:06 - cd /src/sys/i386/conf TB --- 2009-06-08 22:36:06 - /usr/bin/make -B LINT TB --- 2009-06-08 22:36:06 - building LINT kernel TB --- 2009-06-08 22:36:06 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:36:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:36:06 - TARGET=i386 TB --- 2009-06-08 22:36:06 - TARGET_ARCH=i386 TB --- 2009-06-08 22:36:06 - TZ=UTC TB --- 2009-06-08 22:36:06 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:36:06 - cd /src TB --- 2009-06-08 22:36:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 8 22:36:06 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 22:42:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 22:42:21 - ERROR: failed to build lint kernel TB --- 2009-06-08 22:42:21 - 3545.02 user 387.44 system 4427.29 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From nakaji at jp.freebsd.org Mon Jun 8 22:50:30 2009 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Mon Jun 8 22:50:37 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> (Attilio Rao's message of "Sat, 6 Jun 2009 16:49:54 +0200") References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> Message-ID: <863aaagx20.fsf@ra333.heimat.gr.jp> I got a lockup at 3 a.m. JST, but because I'm not ready for dcons I cannot show you guys the whole ddb session. I put a 'bt' output of kgdb. http://www.heimat.gr.jp/localhost/kgdbbtvmcore.0 Kernel config: include GENERIC ident HEIMAT options MSGBUF_SIZE=81920 makeoptions DEBUG=-g options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options BREAK_TO_DEBUGGER options QUOTA options DEVICE_POLLING options HZ=1000 options SW_WATCHDOG options DEBUG_VFS_LOCKS options INVARIANTS options INVARIANT_SUPPORT options WITNESS Thanks. P.S. "allthreads" was not a usable command in my RELENG_7's ddb. >>>>> In <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> >>>>> Attilio Rao wrote: > Anyways, the only one way we have to debug this is getting some help > by the user. > 1) Drop the option WITNESS_SPIKSPIN (as we would like to debug > spinlocks too) and LOCK_PROFILING (in order to create higher > contention and kill some barriers) > 2) Once you get the deadlock break in the DDB debugger > 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads > Note that this is a lot of printout so you won't be able of collecting > all these informations if not with a serial connection. > 4) Dump the content so that we can further look at locks structure > states once we identify something useful (ideally, keeping the machine > up in DDB for that would be very useful, but often not viable) > Let me know. > Attilio -- NAKAJI Hiroyuki From tinderbox at freebsd.org Mon Jun 8 23:55:36 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 8 23:55:55 2009 Subject: [releng_7 tinderbox] failure on i386/pc98 Message-ID: <20090608235530.6B3561B5060@freebsd-stable.sentex.ca> TB --- 2009-06-08 22:42:21 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 22:42:21 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-06-08 22:42:21 - cleaning the object tree TB --- 2009-06-08 22:42:52 - cvsupping the source tree TB --- 2009-06-08 22:42:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-06-08 22:43:04 - building world TB --- 2009-06-08 22:43:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:43:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:43:04 - TARGET=pc98 TB --- 2009-06-08 22:43:04 - TARGET_ARCH=i386 TB --- 2009-06-08 22:43:04 - TZ=UTC TB --- 2009-06-08 22:43:04 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:43:04 - cd /src TB --- 2009-06-08 22:43:04 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 22:43:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 8 23:50:39 UTC 2009 TB --- 2009-06-08 23:50:39 - generating LINT kernel config TB --- 2009-06-08 23:50:39 - cd /src/sys/pc98/conf TB --- 2009-06-08 23:50:39 - /usr/bin/make -B LINT TB --- 2009-06-08 23:50:39 - building LINT kernel TB --- 2009-06-08 23:50:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 23:50:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 23:50:39 - TARGET=pc98 TB --- 2009-06-08 23:50:39 - TARGET_ARCH=i386 TB --- 2009-06-08 23:50:39 - TZ=UTC TB --- 2009-06-08 23:50:39 - __MAKE_CONF=/dev/null TB --- 2009-06-08 23:50:39 - cd /src TB --- 2009-06-08 23:50:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 8 23:50:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 23:55:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 23:55:30 - ERROR: failed to build lint kernel TB --- 2009-06-08 23:55:30 - 3445.74 user 392.66 system 4388.88 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From tinderbox at freebsd.org Tue Jun 9 00:18:45 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 9 00:18:57 2009 Subject: [releng_7 tinderbox] failure on ia64/ia64 Message-ID: <20090609001839.AB5B41B5060@freebsd-stable.sentex.ca> TB --- 2009-06-08 22:42:38 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 22:42:38 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2009-06-08 22:42:39 - cleaning the object tree TB --- 2009-06-08 22:43:09 - cvsupping the source tree TB --- 2009-06-08 22:43:09 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2009-06-08 22:43:20 - building world TB --- 2009-06-08 22:43:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:43:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:43:20 - TARGET=ia64 TB --- 2009-06-08 22:43:20 - TARGET_ARCH=ia64 TB --- 2009-06-08 22:43:20 - TZ=UTC TB --- 2009-06-08 22:43:20 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:43:20 - cd /src TB --- 2009-06-08 22:43:20 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 22:43:22 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 00:12:39 UTC 2009 TB --- 2009-06-09 00:12:39 - generating LINT kernel config TB --- 2009-06-09 00:12:39 - cd /src/sys/ia64/conf TB --- 2009-06-09 00:12:39 - /usr/bin/make -B LINT TB --- 2009-06-09 00:12:39 - building LINT kernel TB --- 2009-06-09 00:12:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 00:12:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 00:12:39 - TARGET=ia64 TB --- 2009-06-09 00:12:39 - TARGET_ARCH=ia64 TB --- 2009-06-09 00:12:39 - TZ=UTC TB --- 2009-06-09 00:12:39 - __MAKE_CONF=/dev/null TB --- 2009-06-09 00:12:39 - cd /src TB --- 2009-06-09 00:12:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 00:12:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 00:18:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 00:18:39 - ERROR: failed to build lint kernel TB --- 2009-06-09 00:18:39 - 4806.28 user 390.27 system 5760.57 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From tinderbox at freebsd.org Tue Jun 9 01:08:50 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 9 01:08:57 2009 Subject: [releng_7 tinderbox] failure on powerpc/powerpc Message-ID: <20090609010845.48F961B5060@freebsd-stable.sentex.ca> TB --- 2009-06-08 23:55:30 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 23:55:30 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-06-08 23:55:30 - cleaning the object tree TB --- 2009-06-08 23:55:50 - cvsupping the source tree TB --- 2009-06-08 23:55:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-06-08 23:56:02 - building world TB --- 2009-06-08 23:56:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 23:56:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 23:56:02 - TARGET=powerpc TB --- 2009-06-08 23:56:02 - TARGET_ARCH=powerpc TB --- 2009-06-08 23:56:02 - TZ=UTC TB --- 2009-06-08 23:56:02 - __MAKE_CONF=/dev/null TB --- 2009-06-08 23:56:02 - cd /src TB --- 2009-06-08 23:56:02 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 23:56:03 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 01:04:55 UTC 2009 TB --- 2009-06-09 01:04:55 - generating LINT kernel config TB --- 2009-06-09 01:04:55 - cd /src/sys/powerpc/conf TB --- 2009-06-09 01:04:55 - /usr/bin/make -B LINT TB --- 2009-06-09 01:04:55 - building LINT kernel TB --- 2009-06-09 01:04:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 01:04:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 01:04:55 - TARGET=powerpc TB --- 2009-06-09 01:04:55 - TARGET_ARCH=powerpc TB --- 2009-06-09 01:04:55 - TZ=UTC TB --- 2009-06-09 01:04:55 - __MAKE_CONF=/dev/null TB --- 2009-06-09 01:04:55 - cd /src TB --- 2009-06-09 01:04:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 01:04:55 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 01:08:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 01:08:45 - ERROR: failed to build lint kernel TB --- 2009-06-09 01:08:45 - 3564.34 user 363.25 system 4394.38 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From tinderbox at freebsd.org Tue Jun 9 01:27:22 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 9 01:29:04 2009 Subject: [releng_7 tinderbox] failure on sparc64/sparc64 Message-ID: <20090609012718.BAEB01B5060@freebsd-stable.sentex.ca> TB --- 2009-06-09 00:18:40 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 00:18:40 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2009-06-09 00:18:40 - cleaning the object tree TB --- 2009-06-09 00:19:03 - cvsupping the source tree TB --- 2009-06-09 00:19:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2009-06-09 00:19:15 - building world TB --- 2009-06-09 00:19:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 00:19:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 00:19:15 - TARGET=sparc64 TB --- 2009-06-09 00:19:15 - TARGET_ARCH=sparc64 TB --- 2009-06-09 00:19:15 - TZ=UTC TB --- 2009-06-09 00:19:15 - __MAKE_CONF=/dev/null TB --- 2009-06-09 00:19:15 - cd /src TB --- 2009-06-09 00:19:15 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 00:19:17 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 01:23:22 UTC 2009 TB --- 2009-06-09 01:23:22 - generating LINT kernel config TB --- 2009-06-09 01:23:22 - cd /src/sys/sparc64/conf TB --- 2009-06-09 01:23:22 - /usr/bin/make -B LINT TB --- 2009-06-09 01:23:22 - building LINT kernel TB --- 2009-06-09 01:23:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 01:23:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 01:23:22 - TARGET=sparc64 TB --- 2009-06-09 01:23:22 - TARGET_ARCH=sparc64 TB --- 2009-06-09 01:23:22 - TZ=UTC TB --- 2009-06-09 01:23:22 - __MAKE_CONF=/dev/null TB --- 2009-06-09 01:23:22 - cd /src TB --- 2009-06-09 01:23:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 01:23:22 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 01:27:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 01:27:18 - ERROR: failed to build lint kernel TB --- 2009-06-09 01:27:18 - 3339.84 user 359.49 system 4118.37 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From pete at altadena.net Tue Jun 9 02:16:04 2009 From: pete at altadena.net (Pete Carah) Date: Tue Jun 9 02:16:11 2009 Subject: Bug between DRM, MSI, or somewhere, re7-stable amd64 Message-ID: <4A2DC056.8090500@altadena.net> I updated my recently acquired core-2 duo laptop to 7-stable amd64 (I had been running 7-stable i386 with few problems) and have acquired an apparent irq problem. Fortunately in debugging a linux shared-interrupt problem about a month ago I learned that the X server will happily accept mouse motion as if it was a display interrupt, so at least with some inconvenience I can read the screen... (the keyboard isn't so obliging) Ours does this too... /usr/src was picked up via svn on last Saturday morning EDT, ports via csup about the same time. I have no idea if this bug is in the intel driver, drm, or the core msi code... There are 2 peripherals that dmesg says uses msi - re0 (which doesn't get a kernel thread indicated in ps for either the stated irq (257) or re0) and drm0/vgapci0 (which indicates irq256 in systat and ps). As I said, this worked properly with earlier source (about a week) in i386 mode. I've used both G45 and re controllers in (f10) linux msi mode with no problems in both 32 and 64-bit. Fortunately this laptop now has enough disk to triple-boot so at least something works... I am using svn instead of csup because I am trying (haven't gotten time yet either :-) to port Sam's ath 92xx code to -stable and handling code porting is much easier that way. -- Pete From dudu at dudu.ro Tue Jun 9 06:37:04 2009 From: dudu at dudu.ro (Vlad Galu) Date: Tue Jun 9 06:37:12 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> <200906020842.42330.jhb@freebsd.org> Message-ID: On Mon, Jun 8, 2009 at 3:57 PM, Ivan Voras wrote: > On a completely unrelated subject I was reading about PHP APC cache > where they have the same need - cross-process locking with locks > embedded in data structures and they have adopted userland spinlock code > from PostgreSQL: > > http://www.scribd.com/doc/3288293/brian-shireapc-facebook > > (spin)locks are not the same as sempahores but maybe it will help the OP > or anyone else trying to implement this feature: > > http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.h?revision=3.4&view=markup > > http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.c?revision=3.3&view=markup Thanks, Ivan. I'll take a better look at this after our first release, which is due in a couple of weeks. Right now the team efforts aren't focused on portability, so it's a low priority issue, but something we'd definitely like to have in the future. From bms at incunabulum.net Tue Jun 9 07:26:26 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Jun 9 07:26:34 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> <200906020842.42330.jhb@freebsd.org> Message-ID: <4A2E0E9F.8050708@incunabulum.net> Vlad Galu wrote: > ... > Thanks, Ivan. I'll take a better look at this after our first release, > which is due in a couple of weeks. Right now the team efforts aren't > focused on portability, so it's a low priority issue, but something > we'd definitely like to have in the future. > I stand corrected. Having read around this, I don't see how process-shared sems could work at all, although I haven't actually tried running process-shared sem code. POSIX semaphores were however horribly broken in kernel prior to 7.2. The fix was essentially one liner. We got a very good test case from a chap in a GNATS PR. cheers BMS From admin at kkip.pl Tue Jun 9 08:35:00 2009 From: admin at kkip.pl (Bartosz Stec) Date: Tue Jun 9 08:35:49 2009 Subject: Problems with PATA disk In-Reply-To: <20090608104334.59a4718c@voicenet.com> References: <20090608101837.79c3b7d7@voicenet.com> <20090608104334.59a4718c@voicenet.com> Message-ID: <4A2E167A.3000902@kkip.pl> Adam K Kirchhoff wrote: >> atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020 >> vendor = 'Promise Technology Inc' >> device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' >> class = mass storage >> This happens frequently with Promise TX2/TX4 (less frequently in RELENG-7 than RELENG-6) and issue is probably related to controller driver. > > GEOM_LABEL: Label ufsid/4a296b573007b5f2 removed. > Jun 8 14:35:42 memory last message repeated 7 times > ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad14: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > ad14: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request directly > ad14: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad15: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > ad15: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > ad15: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad15: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=470440143 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x188 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07d4d94 > stack pointer = 0x28:0xc62f9c00 > frame pointer = 0x28:0xc62f9c18 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 23 (swi6: task queue) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1m56s > Physical memory: 3058 MB > Dumping 113 MB: 98 82 66 50 34 18 2 > Dump complete > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > cpu_reset: Stopping other CPUs > > Unfortunately, nothing showed up in /var/crash, which I think is odd. > I'll update my -STABLE, rebuild my kernel with debugging, and hope to > catch something next time. > > In this case controller probably loose whole drive (disconnected and dissapear from 'atacontrol list'), that's why you see no core dropped, and powering machine off and on let it recognize the drive again. I have this issue from time to time with TX4, but fortunately i have 2 disks in gmirror, so when one drive disconnect I force rebuilding mirro by just powering machine off and on. You're using 7.2-stable, so it seems that OS upgrade won't help you (after upgrade from FreeBSD 6 to 7 issue has been seen 80% less frequently for me), so my one and only suggestion for you is using different PATA controller if you can. -- Bartosz Stec From jkoshy at FreeBSD.org Tue Jun 9 11:20:04 2009 From: jkoshy at FreeBSD.org (Joseph Koshy) Date: Tue Jun 9 11:20:36 2009 Subject: Announcement: PmcTools merged to RELENG_7 In-Reply-To: References: Message-ID: <86prdd65xb.wl%koshy@unixconsulting.co.in> > Hello, > > The PmcTools is merged to RELENG_7. > > You can now enjoy the same level of features / hw supported as in head: > - Callchain in capture > - Core 2 support > - Core i7 support > - pmcannotate: source code annotation using pmc capture > - bug fixes > ... > > Tell me if you find any problems with it. Thank you, Fabien. Great job! Koshy From bra at fsn.hu Tue Jun 9 12:12:04 2009 From: bra at fsn.hu (Attila Nagy) Date: Tue Jun 9 12:12:12 2009 Subject: NFS on ZFS In-Reply-To: <3c1674c90905280025i17039257l573838d33d8493fd@mail.gmail.com> References: <20090526.192217.94910518.nyan@jp.FreeBSD.org> <4A1C3DA8.5050300@bit0.com> <3c1674c90905280025i17039257l573838d33d8493fd@mail.gmail.com> Message-ID: <4A2E4D2D.7040007@fsn.hu> Hello, I've also ran into it, it's a pretty "killer" feature. :-O Any chance for us on the fix? Thanks, Kip Macy wrote: > 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 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. >> >> >> > > > > From rnoland at FreeBSD.org Tue Jun 9 13:51:43 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Jun 9 13:51:49 2009 Subject: Bug between DRM, MSI, or somewhere, re7-stable amd64 In-Reply-To: <4A2DC056.8090500@altadena.net> References: <4A2DC056.8090500@altadena.net> Message-ID: <1244553854.60347.1487.camel@balrog.2hip.net> On Mon, 2009-06-08 at 21:52 -0400, Pete Carah wrote: > I updated my recently acquired core-2 duo laptop to 7-stable amd64 (I > had been running 7-stable i386 with few problems) and have acquired an > apparent irq problem. > > Fortunately in debugging a linux shared-interrupt problem about a month > ago I learned that the X server will happily accept mouse motion as if > it was a display interrupt, so at least with some inconvenience I can > read the screen... (the keyboard isn't so obliging) > Ours does this too... > > /usr/src was picked up via svn on last Saturday morning EDT, ports via > csup about the same time. I have no idea if this bug is in the intel > driver, drm, or the core msi code... There are 2 peripherals that dmesg > says uses msi - re0 (which doesn't get a kernel thread indicated in ps > for either the stated irq (257) or re0) and drm0/vgapci0 (which > indicates irq256 in systat and ps). As I said, this worked properly > with earlier source (about a week) in i386 mode. I've used both G45 and > re controllers in (f10) linux msi mode with no problems in both 32 and > 64-bit. Fortunately this laptop now has enough disk to triple-boot so > at least something works... Yes, Intel still has issues. I do have a patch that reworks the interrupt handling and gets Intel chips working. It isn't safe to commit yet though. It works correctly on my G45, but I have had reports that GM45 is still broken somehow. As a workaround you can disable MSI for just drm using loader tuneable hw.drm.msi=0. robert. > I am using svn instead of csup because I am trying (haven't gotten time > yet either :-) to port Sam's ath 92xx code to -stable and handling code > porting is much easier that way. > > -- Pete > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090609/776d670e/attachment.pgp From lopez.on.the.lists at yellowspace.net Tue Jun 9 13:54:20 2009 From: lopez.on.the.lists at yellowspace.net (Lorenzo Perone) Date: Tue Jun 9 13:54:29 2009 Subject: ZFS list -t snapshot USAGE column Message-ID: Hi there, just wondering, since the ZFS v13 update (to be precise, 7.2-STABLE FreeBSD 7.2-STABLE #11: Wed Jun 3 23:11:29 CEST 2009) why the USAGE column in a zfs list -t snapshot is not showing anymore the space used by the snapshot? I made those snapshots with zfs snapshot -r. They're almost all showing a USAGE of 0K, albeit there have been changes to the dataset since that snapshot. Regards, Lorenzo From tinderbox at freebsd.org Tue Jun 9 14:24:38 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 9 14:24:56 2009 Subject: [releng_7 tinderbox] failure on amd64/amd64 Message-ID: <20090609142435.7E1EC1B5060@freebsd-stable.sentex.ca> TB --- 2009-06-09 12:44:20 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 12:44:20 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-06-09 12:44:20 - cleaning the object tree TB --- 2009-06-09 12:44:55 - cvsupping the source tree TB --- 2009-06-09 12:44:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-06-09 12:45:05 - building world TB --- 2009-06-09 12:45:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 12:45:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 12:45:05 - TARGET=amd64 TB --- 2009-06-09 12:45:05 - TARGET_ARCH=amd64 TB --- 2009-06-09 12:45:05 - TZ=UTC TB --- 2009-06-09 12:45:05 - __MAKE_CONF=/dev/null TB --- 2009-06-09 12:45:05 - cd /src TB --- 2009-06-09 12:45:05 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 12:45:07 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jun 9 14:18:53 UTC 2009 TB --- 2009-06-09 14:18:53 - generating LINT kernel config TB --- 2009-06-09 14:18:53 - cd /src/sys/amd64/conf TB --- 2009-06-09 14:18:53 - /usr/bin/make -B LINT TB --- 2009-06-09 14:18:53 - building LINT kernel TB --- 2009-06-09 14:18:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 14:18:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 14:18:53 - TARGET=amd64 TB --- 2009-06-09 14:18:53 - TARGET_ARCH=amd64 TB --- 2009-06-09 14:18:53 - TZ=UTC TB --- 2009-06-09 14:18:53 - __MAKE_CONF=/dev/null TB --- 2009-06-09 14:18:53 - cd /src TB --- 2009-06-09 14:18:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 14:18:53 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 14:24:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 14:24:35 - ERROR: failed to build lint kernel TB --- 2009-06-09 14:24:35 - 4792.32 user 553.73 system 6015.15 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full From tinderbox at freebsd.org Tue Jun 9 15:06:55 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 9 15:07:12 2009 Subject: [releng_7 tinderbox] failure on i386/i386 Message-ID: <20090609150651.B25C21B5060@freebsd-stable.sentex.ca> TB --- 2009-06-09 13:52:38 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 13:52:38 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-06-09 13:52:38 - cleaning the object tree TB --- 2009-06-09 13:52:50 - cvsupping the source tree TB --- 2009-06-09 13:52:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-06-09 13:52:59 - building world TB --- 2009-06-09 13:52:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 13:52:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 13:52:59 - TARGET=i386 TB --- 2009-06-09 13:52:59 - TARGET_ARCH=i386 TB --- 2009-06-09 13:52:59 - TZ=UTC TB --- 2009-06-09 13:52:59 - __MAKE_CONF=/dev/null TB --- 2009-06-09 13:52:59 - cd /src TB --- 2009-06-09 13:52:59 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 13:53:01 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 15:00:46 UTC 2009 TB --- 2009-06-09 15:00:46 - generating LINT kernel config TB --- 2009-06-09 15:00:46 - cd /src/sys/i386/conf TB --- 2009-06-09 15:00:46 - /usr/bin/make -B LINT TB --- 2009-06-09 15:00:46 - building LINT kernel TB --- 2009-06-09 15:00:46 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 15:00:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 15:00:46 - TARGET=i386 TB --- 2009-06-09 15:00:46 - TARGET_ARCH=i386 TB --- 2009-06-09 15:00:46 - TZ=UTC TB --- 2009-06-09 15:00:46 - __MAKE_CONF=/dev/null TB --- 2009-06-09 15:00:46 - cd /src TB --- 2009-06-09 15:00:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 15:00:46 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 15:06:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 15:06:51 - ERROR: failed to build lint kernel TB --- 2009-06-09 15:06:51 - 3549.24 user 389.72 system 4453.23 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From tinderbox at freebsd.org Tue Jun 9 15:37:05 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 9 15:37:23 2009 Subject: [releng_7 tinderbox] failure on i386/pc98 Message-ID: <20090609153658.99C201B5060@freebsd-stable.sentex.ca> TB --- 2009-06-09 14:24:35 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 14:24:35 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-06-09 14:24:35 - cleaning the object tree TB --- 2009-06-09 14:24:56 - cvsupping the source tree TB --- 2009-06-09 14:24:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-06-09 14:25:05 - building world TB --- 2009-06-09 14:25:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 14:25:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 14:25:05 - TARGET=pc98 TB --- 2009-06-09 14:25:05 - TARGET_ARCH=i386 TB --- 2009-06-09 14:25:05 - TZ=UTC TB --- 2009-06-09 14:25:05 - __MAKE_CONF=/dev/null TB --- 2009-06-09 14:25:05 - cd /src TB --- 2009-06-09 14:25:05 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 14:25:08 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 15:32:12 UTC 2009 TB --- 2009-06-09 15:32:12 - generating LINT kernel config TB --- 2009-06-09 15:32:12 - cd /src/sys/pc98/conf TB --- 2009-06-09 15:32:12 - /usr/bin/make -B LINT TB --- 2009-06-09 15:32:12 - building LINT kernel TB --- 2009-06-09 15:32:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 15:32:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 15:32:12 - TARGET=pc98 TB --- 2009-06-09 15:32:12 - TARGET_ARCH=i386 TB --- 2009-06-09 15:32:12 - TZ=UTC TB --- 2009-06-09 15:32:12 - __MAKE_CONF=/dev/null TB --- 2009-06-09 15:32:12 - cd /src TB --- 2009-06-09 15:32:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 15:32:12 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 15:36:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 15:36:58 - ERROR: failed to build lint kernel TB --- 2009-06-09 15:36:58 - 3452.06 user 388.35 system 4342.84 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From tinderbox at freebsd.org Tue Jun 9 16:42:21 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 9 16:42:42 2009 Subject: [releng_7 tinderbox] failure on ia64/ia64 Message-ID: <20090609164218.0A74B1B5060@freebsd-stable.sentex.ca> TB --- 2009-06-09 15:06:51 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 15:06:51 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2009-06-09 15:06:51 - cleaning the object tree TB --- 2009-06-09 15:07:07 - cvsupping the source tree TB --- 2009-06-09 15:07:07 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2009-06-09 15:07:17 - building world TB --- 2009-06-09 15:07:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 15:07:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 15:07:17 - TARGET=ia64 TB --- 2009-06-09 15:07:17 - TARGET_ARCH=ia64 TB --- 2009-06-09 15:07:17 - TZ=UTC TB --- 2009-06-09 15:07:17 - __MAKE_CONF=/dev/null TB --- 2009-06-09 15:07:17 - cd /src TB --- 2009-06-09 15:07:17 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 15:07:18 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 16:36:37 UTC 2009 TB --- 2009-06-09 16:36:37 - generating LINT kernel config TB --- 2009-06-09 16:36:37 - cd /src/sys/ia64/conf TB --- 2009-06-09 16:36:37 - /usr/bin/make -B LINT TB --- 2009-06-09 16:36:37 - building LINT kernel TB --- 2009-06-09 16:36:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 16:36:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 16:36:37 - TARGET=ia64 TB --- 2009-06-09 16:36:37 - TARGET_ARCH=ia64 TB --- 2009-06-09 16:36:37 - TZ=UTC TB --- 2009-06-09 16:36:37 - __MAKE_CONF=/dev/null TB --- 2009-06-09 16:36:37 - cd /src TB --- 2009-06-09 16:36:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 16:36:37 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 16:42:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 16:42:17 - ERROR: failed to build lint kernel TB --- 2009-06-09 16:42:17 - 4804.94 user 387.17 system 5725.96 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From dougb at FreeBSD.org Tue Jun 9 18:08:57 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 9 18:09:04 2009 Subject: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 In-Reply-To: <20090608181728.GU1927@deviant.kiev.zoral.com.ua> References: <86d49eocwx.fsf@kopusha.onet> <20090608181728.GU1927@deviant.kiev.zoral.com.ua> Message-ID: <4A2EA533.1040405@FreeBSD.org> Kostik Belousov wrote: > This is fixed in HEAD by r185647. I did not merged it to 7, because I > do not believe that somebody runs stable with INVARIANTS on :). I would imagine that people doing kernel module development for use in -stable systems do that with regularity. Doug -- This .signature sanitized for your protection From eugen at kuzbass.ru Tue Jun 9 18:55:34 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Jun 9 18:55:42 2009 Subject: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 In-Reply-To: <4A2EA533.1040405@FreeBSD.org> References: <86d49eocwx.fsf@kopusha.onet> <20090608181728.GU1927@deviant.kiev.zoral.com.ua> <4A2EA533.1040405@FreeBSD.org> Message-ID: <20090609181723.GA59598@svzserv.kemerovo.su> On Tue, Jun 09, 2009 at 11:08:51AM -0700, Doug Barton wrote: > Kostik Belousov wrote: > > This is fixed in HEAD by r185647. I did not merged it to 7, because I > > do not believe that somebody runs stable with INVARIANTS on :). > > I would imagine that people doing kernel module development for use in > -stable systems do that with regularity. I generally run STABLE with INVARIANTS and lots of other debug options while trying to debug a panic or hang in STABLE. And I expect it won't add another panic. Eugene Grosbein From dougb at FreeBSD.org Tue Jun 9 18:58:26 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 9 18:58:33 2009 Subject: I need to add commands that starts every time at system boot. In-Reply-To: <143776.42704.qm@web34307.mail.mud.yahoo.com> References: <143776.42704.qm@web34307.mail.mud.yahoo.com> Message-ID: <4A2EB0C6.6040705@FreeBSD.org> AES wrote: > I need to add commands that starts every time at system boot. > > which script is the one that starts first and where can I find it? If you're Ok with running your commands late in the boot process then /etc/rc.local is your best bet. If what you're doing needs to happen in a certain order relative to the rest of the boot system then you'll want to write your own rc.d-style script and put it in /usr/local/etc/rc.d/. There are several articles in the Handbook that will help you in writing your own script. hth, Doug -- This .signature sanitized for your protection From mark at lomag.net Tue Jun 9 21:02:34 2009 From: mark at lomag.net (Mark Skurzynski) Date: Tue Jun 9 21:02:42 2009 Subject: Buildworld Failure with MODULES_WITH_WORLD=true Message-ID: <7F95EEF369A54B4E924DE08FCA4600CD@ws01> Hello, Our recent buildworlds on both i386 and amd64, as of a couple days ago, are failing with the below error. We use MODULES_WITH_WORLD=true. ===> sys/modules/dtrace/dtmalloc (depend) @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/compat/opensolaris -I/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/contrib/opensolaris/uts/common -I/usr/src/sys/modules/dtrace/dtmalloc/../../.. -I. -I@ -I@/contrib/altq/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/dev/dtmalloc/dtmalloc.c===> sys/modules/dtrace/dtrace (depend)@ -> /usr/src/sysmachine -> /usr/src/sys/amd64/includeawk -f @/tools/makeobjops.awk @/kern/bus_if.m -hawk -f @/tools/makeobjops.awk @/kern/device_if.m -hawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -pawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -qawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h:> opt_compat.h:> opt_kstack_pages.h:> opt_nfs.hcc -c -O2 -fno-strict-aliasing -pipe -DDIS_MEM -DSMP -DDEBUG -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/compat/opensolaris -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64 -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensol aris/uts/common -I/usr/src/sys/modules/dtrace/dtrace/../../.. -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --paramlarge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas@/amd64/amd64/genassym.c@/amd64/amd64/genassym.c:39:29: error: opt_hwpmc_hooks.h: No suchfile or directory*** Error code 1Stop in /usr/src/sys/modules/dtrace/dtrace.*** Error code 1Stop in /usr/src/sys/modules/dtrace.*** Error code 1Stop in /usr/src/sys/modules.*** Error code 1Stop in /usr/src/sys.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.Any ideas on how to resolve this?Thank you,Mark--******************* ********************************* Mark Skurzynski * Lomag Internet Services, LLC mark@lomag.net * http://www.lomag.net Edison, NJ USA * 908-754-0221**************************************************** From mark at lomag.net Tue Jun 9 21:05:30 2009 From: mark at lomag.net (Mark Skurzynski) Date: Tue Jun 9 21:05:38 2009 Subject: Buildworld Failure with MODULES_WITH_WORLD=true Message-ID: Hello, Our recent buildworlds on both i386 and amd64, as of a couple days ago, are failing with the below error. We use MODULES_WITH_WORLD=true. ===> sys/modules/dtrace/dtmalloc (depend) @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/compat/opensolaris -I/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/contrib/opensolaris/uts/common -I/usr/src/sys/modules/dtrace/dtmalloc/../../.. -I. -I@ -I@/contrib/altq/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/dev/dtmalloc/dtmalloc.c===> sys/modules/dtrace/dtrace (depend)@ -> /usr/src/sysmachine -> /usr/src/sys/amd64/includeawk -f @/tools/makeobjops.awk @/kern/bus_if.m -hawk -f @/tools/makeobjops.awk @/kern/device_if.m -hawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -pawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -qawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h:> opt_compat.h:> opt_kstack_pages.h:> opt_nfs.hcc -c -O2 -fno-strict-aliasing -pipe -DDIS_MEM -DSMP -DDEBUG -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/compat/opensolaris -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64 -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensol aris/uts/common -I/usr/src/sys/modules/dtrace/dtrace/../../.. -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --paramlarge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas@/amd64/amd64/genassym.c@/amd64/amd64/genassym.c:39:29: error: opt_hwpmc_hooks.h: No suchfile or directory*** Error code 1Stop in /usr/src/sys/modules/dtrace/dtrace.*** Error code 1Stop in /usr/src/sys/modules/dtrace.*** Error code 1Stop in /usr/src/sys/modules.*** Error code 1Stop in /usr/src/sys.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.Any ideas on how to resolve this?Thank you,Mark--******************* ********************************* Mark Skurzynski * Lomag Internet Services, LLC mark@lomag.net * http://www.lomag.net Edison, NJ USA * 908-754-0221**************************************************** From mandrews at bit0.com Tue Jun 9 21:50:36 2009 From: mandrews at bit0.com (Mike Andrews) Date: Tue Jun 9 21:50:44 2009 Subject: NFS on ZFS In-Reply-To: <4A2E4D2D.7040007@fsn.hu> References: <20090526.192217.94910518.nyan@jp.FreeBSD.org> <4A1C3DA8.5050300@bit0.com> <3c1674c90905280025i17039257l573838d33d8493fd@mail.gmail.com> <4A2E4D2D.7040007@fsn.hu> Message-ID: On Tue, 9 Jun 2009, Attila Nagy wrote: > Hello, > > I've also ran into it, it's a pretty "killer" feature. :-O > > Any chance for us on the fix? It's kern/135039, fyi. From dan.naumov at gmail.com Tue Jun 9 22:28:56 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Tue Jun 9 22:29:03 2009 Subject: trouble building a "make release" snapshot of 7.2-STABLE Message-ID: So first I cvsupped the entire cvs repository (sans ports) using the following supfile: =========================================== *default host=ftp13.FreeBSD.org *default base=/var/db *default prefix=/backup/ncvs *default release=cvs *default delete use-rel-suffix compress src-all doc-all cvsroot-all =========================================== Then I cd /usr/src/release and do: =========================================== make release RELEASETAG=RELENG_7 TARGET_ARCH=amd64 TARGET=amd64 BUILDNAME=7.2-STABLE CHROOTDIR=/backup/releng CVSROOT=/backup/ncvs NODOC=yes NOPORTS=yes NOPORTREADMES=yes MAKE_ISOS=yes NO_FLOPPIES=yes LOCAL_PATCHES=/root/zfs-libstand-loader-patch =========================================== However, the process bombs out on me within 5 seconds with the following: =========================================== -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) install -o root -g wheel -m 444 dir-tmpl /backup/releng/usr/share/info/dir install:No such file or directory *** Error code 1 Stop in /usr/src/share/info. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src/release. =========================================== And... =========================================== agathon# which install /usr/bin/install =========================================== Any ideas? - Dan Naumov From nakaji at jp.freebsd.org Wed Jun 10 00:29:19 2009 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Wed Jun 10 00:29:31 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> (Attilio Rao's message of "Sat, 6 Jun 2009 16:49:54 +0200") References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> Message-ID: <86hbyprkxd.fsf@ra333.heimat.gr.jp> Thanks Attilio, I set up dcons target/host pair. Target is 7.2-STABLE and host is 6.4-STABLE. Dcons session was recorded with script. http://www.heimat.gr.jp/localhost/dcons.log >>>>> In <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> >>>>> Attilio Rao wrote: > 2) Once you get the deadlock break in the DDB debugger KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a vfs_badlock() at vfs_badlock+0x95 assert_vop_elocked() at assert_vop_elocked+0x64 VOP_WRITE_APV() at VOP_WRITE_APV+0x155 vn_write() at vn_write+0x1ce dofilewrite() at dofilewrite+0x85 kern_pwritev() at kern_pwritev+0x66 pwrite() at pwrite+0x58 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (476, FreeBSD ELF64, pwrite), rip = 0x80074d17c, rsp = 0x7fffffffda98, rbp = 0xb4000 --- VOP_WRITE: 0xffffff004a26c000 is not exclusive locked but should be KDB: enter: lock violation [thread pid 29756 tid 100177 ] Stopped at kdb_enter_why+0x3d: movq $0,0x626418(%rip) > 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads > Note that this is a lot of printout so you won't be able of collecting > all these informations if not with a serial connection. db> show allpcpu Current CPU: 0 cpuid = 0 curthread = 0xffffff0114476ab0: pid 29756 "expireover" curpcb = 0xffffff80a3f7ed40 fpcurthread = none idlethread = 0xffffff0001589720: pid 11 "idle: cpu0" spin locks held: db> show alllocks Process 29784 (spamc) thread 0xffffff004afac720 (100170) exclusive sx so_rcv_sx r = 0 (0xffffff0065383c40) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 29413 (perl) thread 0xffffff004afb0720 (100162) exclusive sx so_rcv_sx r = 0 (0xffffff00656163d0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 29409 (perl) thread 0xffffff01144ea390 (100175) exclusive sx so_rcv_sx r = 0 (0xffffff004a210970) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 29406 (perl) thread 0xffffff0065899000 (100196) exclusive sx so_rcv_sx r = 0 (0xffffff00655cbc40) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1497 (perl5.8.9) thread 0xffffff0013dedab0 (100113) exclusive sx so_rcv_sx r = 0 (0xffffff004a0b9970) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1496 (ninpaths) thread 0xffffff001333a720 (100082) exclusive sx so_rcv_sx r = 0 (0xffffff004a33d100) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1494 (perl5.8.9) thread 0xffffff0013dcf720 (100107) exclusive sx so_rcv_sx r = 0 (0xffffff004a33d6a0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1397 (python2.5) thread 0xffffff0013dd1ab0 (100098) exclusive sx so_rcv_sx r = 0 (0xffffff00655cc3d0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 db> show lockedvnods Locked vnodes 0xffffff004a26c000: tag ufs, type VREG usecount 5, writecount 2, refcount 587 mountedhere 0 flags (VI_OBJDIRTY) v_object 0xffffff004a1fad80 ref 3 pages 4604 lock type ufs: SHARED (count 1) ino 3157042, on dev ad4s1f db> ps pid ppid pgrp uid state wmesg wchan cmd 29803 1443 1406 8 S nanslp 0xffffffff80b58688 sleep 29797 1534 1534 0 S connec 0xffffff00654815fe sendmail 29785 1499 1499 110 S lockf 0xffffff0065a19000 perl [snip] db> allthreads No such command db> panic panic: from debugger cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 db_panic() at db_panic+0x17 db_command() at db_command+0x1ef db_command_loop() at db_command_loop+0x50 db_trap() at db_trap+0x89 kdb_trap() at kdb_trap+0x95 trap() at trap+0x295 calltrap() at calltrap+0x8 --- trap 0x3, rip = 0xffffffff8054694d, rsp = 0xffffff80a3f7e850, rbp = 0xffffff80a3f7e870 --- kdb_enter_why() at kdb_enter_why+0x3d assert_vop_elocked() at assert_vop_elocked+0x64 VOP_WRITE_APV() at VOP_WRITE_APV+0x155 vn_write() at vn_write+0x1ce dofilewrite() at dofilewrite+0x85 kern_pwritev() at kern_pwritev+0x66 pwrite() at pwrite+0x58 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (476, FreeBSD ELF64, pwrite), rip = 0x80074d17c, rsp = 0x7fffffffda98, rbp = 0xb4000 --- Uptime: 3h20m7s Physical memory: 6121 MB Dumping 1730 MB: (CTRL-C to abort) ... Dump complete Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... And, here is a backtrace. (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xffffffff80517e73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xffffffff805182fc in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xffffffff801c6817 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:446 #4 0xffffffff801c710f in db_command (last_cmdp=0xffffffff80b21088, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413 #5 0xffffffff801c7320 in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #6 0xffffffff801c8c59 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:228 #7 0xffffffff80546775 in kdb_trap (type=3, code=0, tf=0xffffff80a3f7e7a0) at /usr/src/sys/kern/subr_kdb.c:524 #8 0xffffffff807d6925 in trap (frame=0xffffff80a3f7e7a0) at /usr/src/sys/amd64/amd64/trap.c:531 #9 0xffffffff807ba53e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #10 0xffffffff8054694d in kdb_enter_why (why=0xffffffff808caa99 "vfslock", msg=0xa
) at cpufunc.h:63 #11 0xffffffff8059d804 in assert_vop_elocked (vp=0xffffff004a26c000, str=0xffffffff80907391 "VOP_WRITE") at /usr/src/sys/kern/vfs_subr.c:3679 #12 0xffffffff8081da55 in VOP_WRITE_APV (vop=Variable "vop" is not available. ) at vnode_if.c:702 #13 0xffffffff805aad6e in vn_write (fp=0xffffff0003a13d80, uio=0xffffff80a3f7eb00, active_cred=Variable "active_cred" is not available. ) at vnode_if.h:373 ---Type to continue, or q to quit--- #14 0xffffffff80559215 in dofilewrite (td=0xffffff0114476ab0, fd=15, fp=0xffffff0003a13d80, auio=0xffffff80a3f7eb00, offset=Variable "offset" is not available. ) at file.h:257 #15 0xffffffff80559386 in kern_pwritev (td=0xffffff0114476ab0, fd=15, auio=0xffffff80a3f7eb00, offset=770655) at /usr/src/sys/kern/sys_generic.c:450 #16 0xffffffff80559418 in pwrite (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:351 #17 0xffffffff807d61de in syscall (frame=0xffffff80a3f7ec80) at /usr/src/sys/amd64/amd64/trap.c:900 #18 0xffffffff807ba74b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #19 0x000000080074d17c in ?? () Previous frame inner to this frame (corrupt stack?) > 4) Dump the content so that we can further look at locks structure > states once we identify something useful (ideally, keeping the machine > up in DDB for that would be very useful, but often not viable) The target machine is my SMTP server and it's hard to keep it in DDB. > Let me know. I hope this helps debugging. Thanks. -- NAKAJI Hiroyuki From attilio at freebsd.org Wed Jun 10 00:57:18 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Jun 10 00:57:25 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: <86hbyprkxd.fsf@ra333.heimat.gr.jp> References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> <86hbyprkxd.fsf@ra333.heimat.gr.jp> Message-ID: <3bbf2fe10906091757w35ffd5cfr6f091fc718bc80c7@mail.gmail.com> 2009/6/10 NAKAJI Hiroyuki : > Thanks Attilio, > > I set up dcons target/host pair. Target is 7.2-STABLE and host is > 6.4-STABLE. > > Dcons session was recorded with script. > http://www.heimat.gr.jp/localhost/dcons.log I'm following up privately with the user, news to come hopefully. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From kmacy at freebsd.org Wed Jun 10 01:27:19 2009 From: kmacy at freebsd.org (Kip Macy) Date: Wed Jun 10 01:27:26 2009 Subject: buildworld fails with "WITHOUT_CDDL=yes" in src.conf In-Reply-To: <4A2D10AB.3040007@thekeelecentre.com> References: <20090531191456.M33035@onet.com.ua> <200906010940.26300.doconnor@gsoft.com.au> <4A2404E5.7010104@orange.fr> <3c1674c90906011518k6d680125hf4b4d7608c92de44@mail.gmail.com> <4A2D10AB.3040007@thekeelecentre.com> Message-ID: <3c1674c90906091827u8de6f1eq438db01aaa4b3090@mail.gmail.com> On Mon, Jun 8, 2009 at 6:22 AM, Richard Tector wrote: > Kip Macy wrote: >>> >>> The second bug is the use of LOADER_ZFS_SUPPORT without any >>> consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) > >> I'll try get it fixed by Wednesday. > > > Kip, I noticed a fix went in with revision 193494 but was then backed out > straight away with no reason. > > Will this be fixed soon? It is still not possible to build RELENG_7 sources > WITHOUT_CDDL. This should be fixed now. Sorry for the delay. Thanks, Kip From kmacy at freebsd.org Wed Jun 10 01:28:52 2009 From: kmacy at freebsd.org (Kip Macy) Date: Wed Jun 10 01:28:59 2009 Subject: WITHOUT_ZFS makes build world and kernel error In-Reply-To: <20090526120510.GA1785@fbsd.hasee.cpu> References: <20090526120510.GA1785@fbsd.hasee.cpu> Message-ID: <3c1674c90906091828h43cc8a34vaeafbcacd95ebd88@mail.gmail.com> fixed. On Tue, May 26, 2009 at 5:05 AM, Wu, Yue 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-unsubscribe@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 From nakaji at jp.freebsd.org Wed Jun 10 01:32:25 2009 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Wed Jun 10 01:32:32 2009 Subject: Big problem still remains with 7.2-STABLE locking up In-Reply-To: <3bbf2fe10906091757w35ffd5cfr6f091fc718bc80c7@mail.gmail.com> (Attilio Rao's message of "Wed, 10 Jun 2009 02:57:14 +0200") References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> <86hbyprkxd.fsf@ra333.heimat.gr.jp> <3bbf2fe10906091757w35ffd5cfr6f091fc718bc80c7@mail.gmail.com> Message-ID: <87fxe8g9v0.fsf@roddy.4407.kankyo-u.ac.jp> >>>>> In <3bbf2fe10906091757w35ffd5cfr6f091fc718bc80c7@mail.gmail.com> >>>>> Attilio Rao wrote: > > Dcons session was recorded with script. > > http://www.heimat.gr.jp/localhost/dcons.log Just fix my typo. http://www.heimat.gr.jp/~nakaji/localhost/dcons.log ^^^^^^^ > I'm following up privately with the user, news to come hopefully. Thanks. I'll try. -- NAKAJI Hiroyuki From tinderbox at freebsd.org Wed Jun 10 06:35:40 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jun 10 06:35:48 2009 Subject: [releng_7 tinderbox] failure on amd64/amd64 Message-ID: <20090610063537.85FE61B5060@freebsd-stable.sentex.ca> TB --- 2009-06-10 05:36:19 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-10 05:36:19 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-06-10 05:36:19 - cleaning the object tree TB --- 2009-06-10 05:36:41 - cvsupping the source tree TB --- 2009-06-10 05:36:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-06-10 05:36:53 - building world TB --- 2009-06-10 05:36:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-10 05:36:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-10 05:36:53 - TARGET=amd64 TB --- 2009-06-10 05:36:53 - TARGET_ARCH=amd64 TB --- 2009-06-10 05:36:53 - TZ=UTC TB --- 2009-06-10 05:36:53 - __MAKE_CONF=/dev/null TB --- 2009-06-10 05:36:53 - cd /src TB --- 2009-06-10 05:36:53 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 10 05:36:54 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/load_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/load_elf64_obj.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/reloc_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/bcache.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/isapnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/pnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/interp_forth.c make: don't know how to make /obj/amd64/src/sys/boot/i386/loader/../../zfs/libzfsboot.a. Stop *** Error code 2 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-10 06:35:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-10 06:35:37 - ERROR: failed to build world TB --- 2009-06-10 06:35:37 - 2875.98 user 317.82 system 3558.16 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full From danny at cs.huji.ac.il Wed Jun 10 07:20:42 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Jun 10 07:20:51 2009 Subject: unionfs & unlocking unheld lock Message-ID: hi, sporadically, I see this: lockmgr: thread 0xffffff0004a8b390 unlocking unheld lock KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _lockmgr() at _lockmgr+0x6ae VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 unionfs_unlock() at unionfs_unlock+0x22f VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 vn_read() at vn_read+0x264 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x8017545bc, rsp = 0x7fffffffaf98, rbp = 0x7fffffffb025 --- sf-02> zgrep 'unlocking unheld lock' /var/log/messages* /var/log/messages:May 25 03:03:37 sf-02 kernel: lockmgr: thread 0xffffff0004ed0720 unlocking unheld lock /var/log/messages:May 31 03:03:10 sf-02 kernel: lockmgr: thread 0xffffff0004ed6ab0 unlocking unheld lock /var/log/messages:Jun 10 03:03:19 sf-02 kernel: lockmgr: thread 0xffffff0004a8b390 unlocking unheld lock it happens around 3 am, so I guess it must be some daily script that trips this. danny From tinderbox at freebsd.org Wed Jun 10 07:40:08 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jun 10 07:40:21 2009 Subject: [releng_7 tinderbox] failure on i386/i386 Message-ID: <20090610074004.EABC81B5060@freebsd-stable.sentex.ca> TB --- 2009-06-10 06:35:37 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-10 06:35:37 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-06-10 06:35:37 - cleaning the object tree TB --- 2009-06-10 06:35:52 - cvsupping the source tree TB --- 2009-06-10 06:35:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-06-10 06:36:03 - building world TB --- 2009-06-10 06:36:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-10 06:36:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-10 06:36:03 - TARGET=i386 TB --- 2009-06-10 06:36:03 - TARGET_ARCH=i386 TB --- 2009-06-10 06:36:03 - TZ=UTC TB --- 2009-06-10 06:36:03 - __MAKE_CONF=/dev/null TB --- 2009-06-10 06:36:03 - cd /src TB --- 2009-06-10 06:36:03 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 10 06:36:04 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/load_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/load_elf64_obj.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/reloc_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/bcache.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/isapnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/pnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/interp_forth.c make: don't know how to make /obj/src/sys/boot/i386/loader/../../zfs/libzfsboot.a. Stop *** Error code 2 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-10 07:40:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-10 07:40:04 - ERROR: failed to build world TB --- 2009-06-10 07:40:04 - 2861.66 user 306.05 system 3866.99 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From andre at freebsd.org Wed Jun 10 12:46:37 2009 From: andre at freebsd.org (Andre Oppermann) Date: Wed Jun 10 12:46:44 2009 Subject: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step Message-ID: <4A2FA4EF.5060603@freebsd.org> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config From here on it hangs and repeats the last message with some sort of exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock does. Hard reset is required to reboot. Booting the old 6.4 kernel works and the system comes up again with full access to the RAID array. Any help appreciated. -- Andre From traveling08 at cox.net Wed Jun 10 13:19:30 2009 From: traveling08 at cox.net (Robert) Date: Wed Jun 10 13:19:36 2009 Subject: Panic resource_list_alloc 7.2 stable In-Reply-To: <200906081045.39497.jhb@freebsd.org> References: <20090606071431.092609ce@vaio> <200906081045.39497.jhb@freebsd.org> Message-ID: <20090610061913.04a97b6c@vaio> On Mon, 8 Jun 2009 10:45:39 -0400 John Baldwin wrote: > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > Greetings > > > > This problem seems the same as this one from May of this year > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > This happens on an older HP laptop. It was running on 7.1 prerelease > > fine and then I updated to 7.2 Stable yesterday. > > > > FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri > > Jun 5 11:47:29 PDT 2009 > > root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386 > > > > The bits from pciconf > > > > atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 > > chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' > > device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' > > class = mass storage > > subclass = ATA > > > > The date of ata-chipset.c > > > > -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c > > > > The chipset is found in the above file > > > > ata_intel_ident(device_t dev) > > { > > struct ata_pci_controller *ctlr = device_get_softc(dev); > > static struct ata_chip_id ids[] = > > {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, > > { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, > > { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > ^^^^^^^ > > { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > > > I can include the dump if needed but I am not at this time to > > shorten the email. But here is the panic. > > > > Dump header from device /dev/ad0s1b > > Architecture: i386 > > Architecture Version: 2 > > Dump Length: 68939776B (65 MB) > > Blocksize: 512 > > Dumptime: Sat Jun 6 05:40:52 2009 > > Hostname: hp.shasta204.local > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT > > 2009 root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA > > Panic String: resource_list_alloc: resource entry is busy > > Dump Parity: 3285399556 > > Bounds: 1 > > Dump Status: good > > > > > > Any help would be greatly appreciated. > > The last screen of the dmesg output would be helpful. > I have installed 7.2 on the laptop because it would panic whenever going into multiuser. I would prefer to be on stable. Here is dmesg.boot. I hope that is what you wanted. Thank you Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.boot Type: application/octet-stream Size: 6753 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090610/087f196d/dmesg.obj From mike at sentex.net Wed Jun 10 13:23:31 2009 From: mike at sentex.net (Mike Tancsa) Date: Wed Jun 10 13:23:38 2009 Subject: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step In-Reply-To: <4A2FA4EF.5060603@freebsd.org> References: <4A2FA4EF.5060603@freebsd.org> Message-ID: <200906101321.n5ADLbds031697@lava.sentex.ca> At 08:19 AM 6/10/2009, Andre Oppermann wrote: >Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big >nasty surprise with the Areca RAID controller: > >arcmsr0: > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >arcmsr0: [ITHREAD] >... >(probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config Not sure if its a firmware issue or not, but I am running an AMD64 RELENG_7 kernel from Apr 23 and its works fine. The DV1 error seems "normal" in that I get it as well. I dont boot off the controller, so not sure if thats part of the issue or not. arcmsr0: mem 0xea600000-0xea600fff irq 18 at device 14.0 on pci3 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 arcmsr0: [ITHREAD] (probe48:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da1 at arcmsr0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da1: Command Queueing Enabled da1: 76293MB (156249600 512 byte sectors: 255H 63S/T 9726C) da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 66747MB (136697856 512 byte sectors: 255H 63S/T 8509C) da2 at arcmsr0 bus 0 target 0 lun 1 da2: Fixed Direct Access SCSI-5 device da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da2: Command Queueing Enabled da2: 2784728MB (5703123456 512 byte sectors: 255H 63S/T 355003C) From andre at freebsd.org Wed Jun 10 14:40:33 2009 From: andre at freebsd.org (Andre Oppermann) Date: Wed Jun 10 14:40:40 2009 Subject: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step In-Reply-To: <200906101321.n5ADLbds031697@lava.sentex.ca> References: <4A2FA4EF.5060603@freebsd.org> <200906101321.n5ADLbds031697@lava.sentex.ca> Message-ID: <4A2FC5E4.3000909@freebsd.org> Mike Tancsa wrote: > At 08:19 AM 6/10/2009, Andre Oppermann wrote: >> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got >> a big >> nasty surprise with the Areca RAID controller: >> >> arcmsr0: > > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >> arcmsr0: [ITHREAD] >> ... >> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > > Not sure if its a firmware issue or not, but I am running an AMD64 > RELENG_7 kernel from Apr 23 and its works fine. The DV1 error seems > "normal" in that I get it as well. I dont boot off the controller, so > not sure if thats part of the issue or not. I did an firmware update after I encountered the issue the first time. Before it was V1.43. Exactly the same behavior. And yes, I do have to boot off the RAID. After the run_interrupt_driven_hooks everything hangs and no daX drives are ever detected. You don't seem to get this particular error. -- Andre > arcmsr0: > mem 0xea600000-0xea600fff irq 18 at device 14.0 on pci3 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 > arcmsr0: [ITHREAD] > > (probe48:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > da1 at arcmsr0 bus 0 target 0 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da1: Command Queueing Enabled > da1: 76293MB (156249600 512 byte sectors: 255H 63S/T 9726C) > da0 at twa0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 100.000MB/s transfers > da0: 66747MB (136697856 512 byte sectors: 255H 63S/T 8509C) > da2 at arcmsr0 bus 0 target 0 lun 1 > da2: Fixed Direct Access SCSI-5 device > da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da2: Command Queueing Enabled > da2: 2784728MB (5703123456 512 byte sectors: 255H 63S/T 355003C) From dan at dburkland.com Wed Jun 10 14:41:46 2009 From: dan at dburkland.com (Daniel Burkland) Date: Wed Jun 10 14:41:52 2009 Subject: buildworld fails with "WITHOUT_CDDL=yes" in src.conf Message-ID: <9BF0E9EFFF8AD245AAB6AAB1542D95967CF97561@mail> Thanks Kip I greatly appreciate the fix! From richardtector at thekeelecentre.com Wed Jun 10 14:58:06 2009 From: richardtector at thekeelecentre.com (Richard Tector) Date: Wed Jun 10 14:58:13 2009 Subject: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step In-Reply-To: <200906101321.n5ADLbds031697@lava.sentex.ca> References: <4A2FA4EF.5060603@freebsd.org> <200906101321.n5ADLbds031697@lava.sentex.ca> Message-ID: <4A2FC9F0.3060804@thekeelecentre.com> Mike Tancsa wrote: > At 08:19 AM 6/10/2009, Andre Oppermann wrote: >> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got >> a big >> nasty surprise with the Areca RAID controller: >> >> arcmsr0: > > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >> arcmsr0: [ITHREAD] >> ... >> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config As a further datapoint, I see no problems with amd64 RELENG_7 from May 20th, though I am running an older firmware version. I also don't appear to receive the probe error the two of you are seeing. arcmsr0: mem 0xf4500000-0xf4500fff,0xf4000000-0xf43fffff irq 18 at device 14.0 on pci7 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: Command Queueing Enabled da0: 1831054MB (3749999616 512 byte sectors: 255H 63S/T 233426C) From scrappy at hub.org Wed Jun 10 15:04:52 2009 From: scrappy at hub.org (Marc G. Fournier) Date: Wed Jun 10 15:04:59 2009 Subject: Server lock up: kern.maxswzone relate ... Message-ID: <20090610115351.V56412@hub.org> I'm running a couple of brand new servers ... 32G of RAM, very little load on it right now, and this morning it locked up with that 'kern.maxswzone' error on the console ... The server is running a reasonably current 7.2-STABLE: FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 14:48:04 ADT And top right now, with everything running, shows no swappping, 19G of Free memory, 9G of Inact memory ... no reason to do any serious amount of swapping. last pid: 32159; load averages: 0.12, 0.21, 0.47 up 0+10:57:56 11:53:39 573 processes: 1 running, 571 sleeping, 1 zombie CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free Swap: 32G Total, 32G Free In fact, my other server (same config), has been up 9 days (they were put online 9 days ago), and tops shows it doing a little bit of swapping, but, again, huge amounts of Inact memory: last pid: 26307; load averages: 0.36, 0.35, 0.36 up 9+17:03:48 11:57:54 680 processes: 2 running, 657 sleeping, 21 zombie CPU: 0.7% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.9% idle Mem: 2915M Active, 25G Inact, 778M Wired, 13M Cache, 399M Buf, 1771M Free Swap: 32G Total, 1044K Used, 32G Free So these servers right now are definitely not feeling any pain ... And, based on experiences with another server, I have my /boot/loader.conf set to: kern.maxswzone=67108864 So, the question is ... what am I missing? Is there some magical formula for calculating maxswzone that 7.2 is missing? Some nagios plug-in I shuld be using to monitor ... what? Help? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From scottl at samsco.org Wed Jun 10 15:09:26 2009 From: scottl at samsco.org (Scott Long) Date: Wed Jun 10 15:09:33 2009 Subject: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step In-Reply-To: <4A2FA4EF.5060603@freebsd.org> References: <4A2FA4EF.5060603@freebsd.org> Message-ID: <4A2FC858.5050800@samsco.org> Andre Oppermann wrote: > Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big > nasty surprise with the Areca RAID controller: > > arcmsr0: > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 > arcmsr0: [ITHREAD] > ... > (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > From here on it hangs and repeats the last message with some sort of > exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock > does. Hard reset is required to reboot. > > Booting the old 6.4 kernel works and the system comes up again with full > access to the RAID array. > > Any help appreciated. > I'll try to reproduce this locally. There have been sporadic reports of the "fails comparison" problem, but none as fatal as this. Is it possible to compile your kernel with CAMDEBUG and CAM_DEBUG_FLAGS=CAM_DEBUG_INFO? Scott From nkalev at gmail.com Wed Jun 10 13:51:11 2009 From: nkalev at gmail.com (Nikolay Kalev) Date: Wed Jun 10 15:24:02 2009 Subject: Dell R710 4GB PERC 6/i crashing on high I/O Message-ID: <136a340a0906100621n48400e57r1fc6fbedc3e3178d@mail.gmail.com> Hello all, I wanted to ask if anyone had issues with Dell R710 4GB with PERC 6/i on heavy I/O. I cannot for sure determine that the issue is indeed with the PERC 6/i controller or hardware problem. I got the following output after some hammering with creating localy files 1-10GB with dd and doing rsync via the network interface. I've attached the pictures from the KVM. First one is with the box before upgrade to BIOS 1.1.4 and firmware of PERC 6/i to 6.2.0.0.13 Second one is after the upgrade. Any ideas ? From jhb at freebsd.org Wed Jun 10 15:37:03 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jun 10 15:37:10 2009 Subject: Panic resource_list_alloc 7.2 stable In-Reply-To: <20090610061913.04a97b6c@vaio> References: <20090606071431.092609ce@vaio> <200906081045.39497.jhb@freebsd.org> <20090610061913.04a97b6c@vaio> Message-ID: <200906101038.37028.jhb@freebsd.org> On Wednesday 10 June 2009 9:19:13 am Robert wrote: > On Mon, 8 Jun 2009 10:45:39 -0400 > John Baldwin wrote: > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > > Greetings > > > > > > This problem seems the same as this one from May of this year > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > > > This happens on an older HP laptop. It was running on 7.1 prerelease > > > fine and then I updated to 7.2 Stable yesterday. > > > > > > FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri > > > Jun 5 11:47:29 PDT 2009 > > > root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386 > > > > > > The bits from pciconf > > > > > > atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 > > > chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' > > > device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' > > > class = mass storage > > > subclass = ATA > > > > > > The date of ata-chipset.c > > > > > > -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c > > > > > > The chipset is found in the above file > > > > > > ata_intel_ident(device_t dev) > > > { > > > struct ata_pci_controller *ctlr = device_get_softc(dev); > > > static struct ata_chip_id ids[] = > > > {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, > > > { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, > > > { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > > ^^^^^^^ > > > { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > > > > > I can include the dump if needed but I am not at this time to > > > shorten the email. But here is the panic. > > > > > > Dump header from device /dev/ad0s1b > > > Architecture: i386 > > > Architecture Version: 2 > > > Dump Length: 68939776B (65 MB) > > > Blocksize: 512 > > > Dumptime: Sat Jun 6 05:40:52 2009 > > > Hostname: hp.shasta204.local > > > Magic: FreeBSD Kernel Dump > > > Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT > > > 2009 root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA > > > Panic String: resource_list_alloc: resource entry is busy > > > Dump Parity: 3285399556 > > > Bounds: 1 > > > Dump Status: good > > > > > > > > > Any help would be greatly appreciated. > > > > The last screen of the dmesg output would be helpful. > > > I have installed 7.2 on the laptop because it would panic whenever > going into multiuser. I would prefer to be on stable. > > Here is dmesg.boot. I hope that is what you wanted. Hmm, can you get the stack trace from the dump that you have? I'm curious which device driver is triggering the panic. -- John Baldwin From ben at altesco.nl Wed Jun 10 15:37:43 2009 From: ben at altesco.nl (Ben Stuyts) Date: Wed Jun 10 15:37:51 2009 Subject: Xorg keyboard and mouse hung Message-ID: <660A86EE-A365-42C3-A1DF-15AC7B03C813@altesco.nl> Hi, I've upgrade two FreeBSD 7-stable workstations to the latest kernel/ world of today, and now the mouse and keyboard don't react anymore in the Xorg / KDE login window. Mouse doesn't move, keyboard characters don't appear in the login prompt. I can still switch back with ctl-alt- F1 to a console login, and there both the keyboard and mouse still work. I have attached dmesg.boot and Xorg.0.log. I'm not using a xorg.conf as the default settings used to work fine. Any ideas? Thanks, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.boot Type: application/octet-stream Size: 8507 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090610/238d3f1f/dmesg-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: application/octet-stream Size: 48813 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090610/238d3f1f/Xorg.0-0001.obj From traveling08 at cox.net Wed Jun 10 16:45:09 2009 From: traveling08 at cox.net (Robert) Date: Wed Jun 10 16:45:16 2009 Subject: Panic resource_list_alloc 7.2 stable In-Reply-To: <200906101038.37028.jhb@freebsd.org> References: <20090606071431.092609ce@vaio> <200906081045.39497.jhb@freebsd.org> <20090610061913.04a97b6c@vaio> <200906101038.37028.jhb@freebsd.org> Message-ID: <20090610094503.104ffbb7@vaio> On Wed, 10 Jun 2009 10:38:36 -0400 John Baldwin wrote: > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > > On Mon, 8 Jun 2009 10:45:39 -0400 > > John Baldwin wrote: > > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > > > Greetings > > > > > > > > This problem seems the same as this one from May of this year > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > > > > > > I have installed 7.2 on the laptop because it would panic whenever > > going into multiuser. I would prefer to be on stable. > > > > Here is dmesg.boot. I hope that is what you wanted. > > Hmm, can you get the stack trace from the dump that you have? I'm > curious which device driver is triggering the panic. > (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e4b47 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, callbacks=0xd528a9e4, argp=0xc2a65000) at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 #9 0xc0affad2 in VOP_OPEN_APV (vop=0xc0c4f840, a=0xd528aa88) at vnode_if.c:371 #10 0xc0873329 in vn_open_cred (ndp=0xd528ab7c, flagp=0xd528ac78, cmode=1, cred=0xc2ab3d00, fp=0xc2a4be40) at vnode_if.h:199 #11 0xc0873473 in vn_open (ndp=0xd528ab7c, flagp=0xd528ac78, cmode=1, fp=0xc2a4be40) at /usr/src/sys/kern/vfs_vnops.c:94 #12 0xc0870b7d in kern_open (td=0xc2a91d80, path=0xbfbfef32
, pathseg=UIO_USERSPACE, flags=1, mode=1) at /usr/src/sys/kern/vfs_syscalls.c:1042 #13 0xc08710f0 in open (td=0xc2a91d80, uap=0xd528acfc) at /usr/src/sys/kern/vfs_syscalls.c:1009 #14 0xc0ae9405 in syscall (frame=0xd528ad38) at /usr/src/sys/i386/i386/trap.c:1090 #15 0xc0ace1e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #16 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Thanks again Robert From andre at freebsd.org Wed Jun 10 17:03:29 2009 From: andre at freebsd.org (Andre Oppermann) Date: Wed Jun 10 17:03:36 2009 Subject: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step In-Reply-To: <4A2FC858.5050800@samsco.org> References: <4A2FA4EF.5060603@freebsd.org> <4A2FC858.5050800@samsco.org> Message-ID: <4A2FE765.9000803@freebsd.org> Scott Long wrote: > Andre Oppermann wrote: >> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got >> a big >> nasty surprise with the Areca RAID controller: >> >> arcmsr0: > > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >> arcmsr0: [ITHREAD] >> ... >> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config >> >> From here on it hangs and repeats the last message with some sort of >> exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock >> does. Hard reset is required to reboot. >> >> Booting the old 6.4 kernel works and the system comes up again with full >> access to the RAID array. >> >> Any help appreciated. >> > > I'll try to reproduce this locally. There have been sporadic reports of > the "fails comparison" problem, but none as fatal as this. Is it > possible to compile your kernel with CAMDEBUG and > CAM_DEBUG_FLAGS=CAM_DEBUG_INFO? CAMDEBUG doesn't give any output. As it turns out the hang seems to be related to an interrupt routing problem somehow. I did an BIOS upgrade and BIOS settings factory reset. The mainboard is an ASUS M2N32 WS Professional with an Athlon64 X2 4800+. Enabling all on-board devices including ATA and various SATA controllers together with "PnP OS" set to yes fixed the hand and allowed FreeBSD 7 to boot sucessfully. Why 6.4 doesn't stumble I don't know. The "(probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step" line is still there. Fortunately the boot process simply continues from there without further trouble. If there are any other CAM debug options or patches you want me to try I can do that. The system is only in partial production and I'm allowed to reboot it during workhours. -- Andre From pschmehl_lists at tx.rr.com Wed Jun 10 17:09:06 2009 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Wed Jun 10 17:09:14 2009 Subject: Xorg keyboard and mouse hung In-Reply-To: <660A86EE-A365-42C3-A1DF-15AC7B03C813@altesco.nl> References: <660A86EE-A365-42C3-A1DF-15AC7B03C813@altesco.nl> Message-ID: --On Wednesday, June 10, 2009 10:02:39 -0500 Ben Stuyts wrote: > > Hi, > > I've upgrade two FreeBSD 7-stable workstations to the latest kernel/ > world of today, and now the mouse and keyboard don't react anymore in > the Xorg / KDE login window. Mouse doesn't move, keyboard characters > don't appear in the login prompt. I can still switch back with ctl-alt- > F1 to a console login, and there both the keyboard and mouse still work. > > I have attached dmesg.boot and Xorg.0.log. I'm not using a xorg.conf > as the default settings used to work fine. > > Any ideas? > Sure. In your Xorg.0.log file: "(==) ModulePath set to "/usr/local/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput" add dbus_enable="YES" and hald_enable="YES" to /etc/rc.conf. Then start them both manually (/usr/local/etc/rc.d/hald start and /usr/local/etc/rc.d/dbus start). Then restart X (Ctrl-Alt-Bkspc) -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* Check the headers before clicking on Reply. From jhb at freebsd.org Wed Jun 10 17:09:15 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jun 10 17:09:26 2009 Subject: Panic resource_list_alloc 7.2 stable In-Reply-To: <20090610094503.104ffbb7@vaio> References: <20090606071431.092609ce@vaio> <200906101038.37028.jhb@freebsd.org> <20090610094503.104ffbb7@vaio> Message-ID: <200906101307.37181.jhb@freebsd.org> On Wednesday 10 June 2009 12:45:03 pm Robert wrote: > On Wed, 10 Jun 2009 10:38:36 -0400 > John Baldwin wrote: > > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > > > On Mon, 8 Jun 2009 10:45:39 -0400 > > > John Baldwin wrote: > > > > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > > > > Greetings > > > > > > > > > > This problem seems the same as this one from May of this year > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > > > > > > > > > > > > I have installed 7.2 on the laptop because it would panic whenever > > > going into multiuser. I would prefer to be on stable. > > > > > > Here is dmesg.boot. I hope that is what you wanted. > > > > Hmm, can you get the stack trace from the dump that you have? I'm > > curious which device driver is triggering the panic. > > > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc07e4b47 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic > (fmt=Variable "fmt" is not available. ) > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, > callbacks=0xd528a9e4, argp=0xc2a65000) > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 Hmmm, ok. So the problem appears to be that the cardbus code that parses the CIS wants to allocate a resource belonging to a cardbus card device that has already been allocated by that device's driver. Warner, what is the best way to handle this do you think? Does the bus_alloc_resource() method for a cardbus bus need to proxy resource requests to the CIS resource perhaps? -- John Baldwin From imp at bsdimp.com Wed Jun 10 17:16:34 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jun 10 17:16:40 2009 Subject: Panic resource_list_alloc 7.2 stable In-Reply-To: <200906101307.37181.jhb@freebsd.org> References: <200906101038.37028.jhb@freebsd.org> <20090610094503.104ffbb7@vaio> <200906101307.37181.jhb@freebsd.org> Message-ID: <20090610.111516.1756928424.imp@bsdimp.com> In message: <200906101307.37181.jhb@freebsd.org> John Baldwin writes: : On Wednesday 10 June 2009 12:45:03 pm Robert wrote: : > On Wed, 10 Jun 2009 10:38:36 -0400 : > John Baldwin wrote: : > : > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: : > > > On Mon, 8 Jun 2009 10:45:39 -0400 : > > > John Baldwin wrote: : > > > : > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: : > > > > > Greetings : > > > > > : > > > > > This problem seems the same as this one from May of this year : > > > > > : > > > > > : http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html : > > > > > : > : > : > : > > > > : > > > I have installed 7.2 on the laptop because it would panic whenever : > > > going into multiuser. I would prefer to be on stable. : > > > : > > > Here is dmesg.boot. I hope that is what you wanted. : > > : > > Hmm, can you get the stack trace from the dump that you have? I'm : > > curious which device driver is triggering the panic. : > > : > : > (kgdb) bt : > #0 doadump () at pcpu.h:196 : > #1 0xc07e4b47 in boot (howto=260) : > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic : > (fmt=Variable "fmt" is not available. ) : > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in : > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, : > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) : > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in : > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, : > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) : > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource : > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, : > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in : > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, : > callbacks=0xd528a9e4, argp=0xc2a65000) : > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in : > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) : > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in : > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 : : Hmmm, ok. So the problem appears to be that the cardbus code that parses the : CIS wants to allocate a resource belonging to a cardbus card device that has : already been allocated by that device's driver. Warner, what is the best way : to handle this do you think? Does the bus_alloc_resource() method for a : cardbus bus need to proxy resource requests to the CIS resource perhaps? I thought I already fixed this. We snag the cardbus CIS now on attach rather than at open time. We just need to MFC it. The problem isn't that we're allocating a resource that the device owns, so much, as that there are technical hurdles to accessing the CIS after the initial parsing.... Warner From ben at altesco.nl Wed Jun 10 17:24:32 2009 From: ben at altesco.nl (Ben Stuyts) Date: Wed Jun 10 17:24:39 2009 Subject: Xorg keyboard and mouse hung In-Reply-To: References: <660A86EE-A365-42C3-A1DF-15AC7B03C813@altesco.nl> Message-ID: <56C52C1B-1CC1-407B-BB51-4EF1EF75F484@altesco.nl> On 10 jun 2009, at 18:58, Paul Schmehl wrote: > --On Wednesday, June 10, 2009 10:02:39 -0500 Ben Stuyts > wrote: > >> I've upgrade two FreeBSD 7-stable workstations to the latest kernel/ >> world of today, and now the mouse and keyboard don't react anymore in >> the Xorg / KDE login window. Mouse doesn't move, keyboard characters >> don't appear in the login prompt. I can still switch back with ctl- >> alt- >> F1 to a console login, and there both the keyboard and mouse still >> work. >> >> I have attached dmesg.boot and Xorg.0.log. I'm not using a xorg.conf >> as the default settings used to work fine. >> >> Any ideas? > > Sure. In your Xorg.0.log file: > > "(==) ModulePath set to "/usr/local/lib/xorg/modules" > (II) Cannot locate a core pointer device. > (II) Cannot locate a core keyboard device. > (II) The server relies on HAL to provide the list of input devices. > If no devices become available, reconfigure HAL or disable > AllowEmptyInput" > > add dbus_enable="YES" and hald_enable="YES" to /etc/rc.conf. Then > start them both manually (/usr/local/etc/rc.d/hald start and /usr/ > local/etc/rc.d/dbus start). Then restart X (Ctrl-Alt-Bkspc) I missed that somehow in UPDATING. Thanks! Kind regards, Ben From jhb at freebsd.org Wed Jun 10 17:45:15 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jun 10 17:45:27 2009 Subject: Panic resource_list_alloc 7.2 stable In-Reply-To: <20090610.111516.1756928424.imp@bsdimp.com> References: <200906101038.37028.jhb@freebsd.org> <200906101307.37181.jhb@freebsd.org> <20090610.111516.1756928424.imp@bsdimp.com> Message-ID: <200906101344.04754.jhb@freebsd.org> On Wednesday 10 June 2009 1:15:16 pm M. Warner Losh wrote: > In message: <200906101307.37181.jhb@freebsd.org> > John Baldwin writes: > : On Wednesday 10 June 2009 12:45:03 pm Robert wrote: > : > On Wed, 10 Jun 2009 10:38:36 -0400 > : > John Baldwin wrote: > : > > : > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > : > > > On Mon, 8 Jun 2009 10:45:39 -0400 > : > > > John Baldwin wrote: > : > > > > : > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > : > > > > > Greetings > : > > > > > > : > > > > > This problem seems the same as this one from May of this year > : > > > > > > : > > > > > > : http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > : > > > > > > : > > : > > : > > : > > > > > : > > > I have installed 7.2 on the laptop because it would panic whenever > : > > > going into multiuser. I would prefer to be on stable. > : > > > > : > > > Here is dmesg.boot. I hope that is what you wanted. > : > > > : > > Hmm, can you get the stack trace from the dump that you have? I'm > : > > curious which device driver is triggering the panic. > : > > > : > > : > (kgdb) bt > : > #0 doadump () at pcpu.h:196 > : > #1 0xc07e4b47 in boot (howto=260) > : > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic > : > (fmt=Variable "fmt" is not available. ) > : > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in > : > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, > : > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > : > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in > : > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, > : > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > : > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource > : > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, > : > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in > : > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, > : > callbacks=0xd528a9e4, argp=0xc2a65000) > : > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in > : > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) > : > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in > : > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 > : > : Hmmm, ok. So the problem appears to be that the cardbus code that parses the > : CIS wants to allocate a resource belonging to a cardbus card device that has > : already been allocated by that device's driver. Warner, what is the best way > : to handle this do you think? Does the bus_alloc_resource() method for a > : cardbus bus need to proxy resource requests to the CIS resource perhaps? > > I thought I already fixed this. We snag the cardbus CIS now on attach > rather than at open time. We just need to MFC it. Oh, ok, that would make sense. Is it easy to merge to 7? > The problem isn't that we're allocating a resource that the device > owns, so much, as that there are technical hurdles to accessing the > CIS after the initial parsing.... *nod* -- John Baldwin From jhb at freebsd.org Wed Jun 10 18:14:43 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jun 10 18:14:50 2009 Subject: Server lock up: kern.maxswzone relate ... In-Reply-To: <20090610115351.V56412@hub.org> References: <20090610115351.V56412@hub.org> Message-ID: <200906101412.35353.jhb@freebsd.org> On Wednesday 10 June 2009 11:04:48 am Marc G. Fournier wrote: > > I'm running a couple of brand new servers ... 32G of RAM, very little load > on it right now, and this morning it locked up with that 'kern.maxswzone' > error on the console ... > > The server is running a reasonably current 7.2-STABLE: > > FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 > 14:48:04 ADT > > And top right now, with everything running, shows no swappping, 19G of > Free memory, 9G of Inact memory ... no reason to do any serious amount of > swapping. > > last pid: 32159; load averages: 0.12, 0.21, 0.47 up 0+10:57:56 11:53:39 > 573 processes: 1 running, 571 sleeping, 1 zombie > CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle > Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free > Swap: 32G Total, 32G Free > > In fact, my other server (same config), has been up 9 days (they were put > online 9 days ago), and tops shows it doing a little bit of swapping, but, > again, huge amounts of Inact memory: > > last pid: 26307; load averages: 0.36, 0.35, 0.36 up 9+17:03:48 > 11:57:54 > 680 processes: 2 running, 657 sleeping, 21 zombie > CPU: 0.7% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.9% idle > Mem: 2915M Active, 25G Inact, 778M Wired, 13M Cache, 399M Buf, 1771M Free > Swap: 32G Total, 1044K Used, 32G Free > > So these servers right now are definitely not feeling any pain ... > > And, based on experiences with another server, I have my /boot/loader.conf > set to: > > kern.maxswzone=67108864 > > So, the question is ... what am I missing? Is there some magical formula > for calculating maxswzone that 7.2 is missing? Some nagios plug-in I > shuld be using to monitor ... what? > > Help? There are changes in 8 that you can ask kib@ to MFC perhaps that help some. They make the kernel kill a process when maxswzone is empty similar to what happens when you run out of swap space. If you break into the debugger and get a crashdump, you can verify 1) that you were swapping, and 2) you can calculate a better value for maxswzone. The problem with making maxswzone really big is that it uses up wired memory that can't be reused for anything else, so you don't just want to blindly use the maximum amount for the swap you have. -- John Baldwin From marck at rinet.ru Wed Jun 10 20:23:30 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Jun 10 20:23:39 2009 Subject: Server lock up: kern.maxswzone relate ... In-Reply-To: <20090610115351.V56412@hub.org> References: <20090610115351.V56412@hub.org> Message-ID: On Wed, 10 Jun 2009, Marc G. Fournier wrote: MGF> MGF> I'm running a couple of brand new servers ... 32G of RAM, very little load MGF> on it right now, and this morning it locked up with that 'kern.maxswzone' MGF> error on the console ... MGF> MGF> The server is running a reasonably current 7.2-STABLE: MGF> MGF> FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 14:48:04 MGF> ADT MGF> MGF> And top right now, with everything running, shows no swappping, 19G of Free MGF> memory, 9G of Inact memory ... no reason to do any serious amount of MGF> swapping. MGF> MGF> last pid: 32159; load averages: 0.12, 0.21, 0.47 up 0+10:57:56 MGF> 11:53:39 MGF> 573 processes: 1 running, 571 sleeping, 1 zombie MGF> CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle MGF> Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free MGF> Swap: 32G Total, 32G Free As a workaround, if your machine is usually not going to swap, you can decrease swap space significally, and use otherwise unused partition for crashdumps. For RELENG_7/amd64 with 8G RAM and 16G of swap, on stress tests with tmpfs to avoid such locks I had to tune kern.maxswzone up to 192M, which seems to be kinda overkill... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From yanefbsd at gmail.com Thu Jun 11 02:56:41 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jun 11 02:56:48 2009 Subject: Issues with gjournal (heaaaaaaaaaaalp!) In-Reply-To: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> References: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> Message-ID: <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrote: > Hi Pawel, ATA, and Stable folks, > > ? ?This time when I did a reinstall I took the bullet and tried to > use gjournaling instead of softupdates. The unfortunate thing is that > I can't seem to get it to work. > > Here's the procedure that I'm trying to follow (based off of [1]): > - sysinstall from scratch with a minimal distribution. This creates > /usr // /dev/ad6s1d as UFS2 with softupdates disabled. > - Pull latest stable sources. Rebuild kernel (with `options > GEOM_JOURNAL'), world, install kernel, then world after reboot. > - gjournal label -f ad6s1d ad6s2d > - mount /dev/ad6s1d /usr # That works (I think...), but prints out the > error message below: > > GEOM_JOURNAL: [flush] Error while writing data (error=1) > ad6s2d[WRITE(offset=512, length=6656)] > > gjournal status says: > ? ? ? ? ? ?Name ? Status ? Components > ad6s1d.journal ? ? ? N/A ? ad6s1d > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ad6s2d > > Some issues I noticed: > > - GJOURNAL ROOT (something) loops infinitely if the device can't be > found; this should probably time out and panic / exit if a device > becomes unavailable (depends on fstab values in the final 2 fields no > doubt). I did this by accident when I forgot to add iir statically to > the kernel. > - The LiveCD doesn't fully support gjournal (userland's there, kernel > support isn't). Kind of annoying and counterproductive... > - Existing journal partitions disappeared when I upgraded by accident > from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from > my server with label=.). That was weird... > - When I use gjournal label with an existing filesystem I _must_ use -f. > > Any help with this endeavor would be more than appreciated, as I want > to enable this functionality before I move on to installing X11, as > nvidia-driver frequently hardlocks the desktop (or has in the past). > > Thanks, > -Garrett > > [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html And to answer another potential question, I've tried mounting both with -o rw,async and with -o rw. Thanks! -Garrett From yanefbsd at gmail.com Thu Jun 11 03:04:56 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jun 11 03:05:03 2009 Subject: Issues with gjournal (heaaaaaaaaaaalp!) Message-ID: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> Hi Pawel, ATA, and Stable folks, This time when I did a reinstall I took the bullet and tried to use gjournaling instead of softupdates. The unfortunate thing is that I can't seem to get it to work. Here's the procedure that I'm trying to follow (based off of [1]): - sysinstall from scratch with a minimal distribution. This creates /usr // /dev/ad6s1d as UFS2 with softupdates disabled. - Pull latest stable sources. Rebuild kernel (with `options GEOM_JOURNAL'), world, install kernel, then world after reboot. - gjournal label -f ad6s1d ad6s2d - mount /dev/ad6s1d /usr # That works (I think...), but prints out the error message below: GEOM_JOURNAL: [flush] Error while writing data (error=1) ad6s2d[WRITE(offset=512, length=6656)] gjournal status says: Name Status Components ad6s1d.journal N/A ad6s1d ad6s2d Some issues I noticed: - GJOURNAL ROOT (something) loops infinitely if the device can't be found; this should probably time out and panic / exit if a device becomes unavailable (depends on fstab values in the final 2 fields no doubt). I did this by accident when I forgot to add iir statically to the kernel. - The LiveCD doesn't fully support gjournal (userland's there, kernel support isn't). Kind of annoying and counterproductive... - Existing journal partitions disappeared when I upgraded by accident from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from my server with label=.). That was weird... - When I use gjournal label with an existing filesystem I _must_ use -f. Any help with this endeavor would be more than appreciated, as I want to enable this functionality before I move on to installing X11, as nvidia-driver frequently hardlocks the desktop (or has in the past). Thanks, -Garrett [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html From dan.naumov at gmail.com Thu Jun 11 05:58:41 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Thu Jun 11 05:58:48 2009 Subject: Issues with gjournal (heaaaaaaaaaaalp!) In-Reply-To: <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> References: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> Message-ID: You need to mount your /dev/ad6s1d.journal as /usr and not /dev/ad6s1d, because this is the new device provided to you by GEOM. - Dan Naumov On Thu, Jun 11, 2009 at 5:50 AM, Garrett Cooper wrote: > On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrote: >> Hi Pawel, ATA, and Stable folks, >> >> ? ?This time when I did a reinstall I took the bullet and tried to >> use gjournaling instead of softupdates. The unfortunate thing is that >> I can't seem to get it to work. >> >> Here's the procedure that I'm trying to follow (based off of [1]): >> - sysinstall from scratch with a minimal distribution. This creates >> /usr // /dev/ad6s1d as UFS2 with softupdates disabled. >> - Pull latest stable sources. Rebuild kernel (with `options >> GEOM_JOURNAL'), world, install kernel, then world after reboot. >> - gjournal label -f ad6s1d ad6s2d >> - mount /dev/ad6s1d /usr # That works (I think...), but prints out the >> error message below: >> >> GEOM_JOURNAL: [flush] Error while writing data (error=1) >> ad6s2d[WRITE(offset=512, length=6656)] >> >> gjournal status says: >> ? ? ? ? ? ?Name ? Status ? Components >> ad6s1d.journal ? ? ? N/A ? ad6s1d >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ad6s2d >> >> Some issues I noticed: >> >> - GJOURNAL ROOT (something) loops infinitely if the device can't be >> found; this should probably time out and panic / exit if a device >> becomes unavailable (depends on fstab values in the final 2 fields no >> doubt). I did this by accident when I forgot to add iir statically to >> the kernel. >> - The LiveCD doesn't fully support gjournal (userland's there, kernel >> support isn't). Kind of annoying and counterproductive... >> - Existing journal partitions disappeared when I upgraded by accident >> from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from >> my server with label=.). That was weird... >> - When I use gjournal label with an existing filesystem I _must_ use -f. >> >> Any help with this endeavor would be more than appreciated, as I want >> to enable this functionality before I move on to installing X11, as >> nvidia-driver frequently hardlocks the desktop (or has in the past). >> >> Thanks, >> -Garrett >> >> [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html > > And to answer another potential question, I've tried mounting both > with -o rw,async and with -o rw. > Thanks! > -Garrett > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From yanefbsd at gmail.com Thu Jun 11 06:24:51 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jun 11 06:24:58 2009 Subject: Issues with gjournal (heaaaaaaaaaaalp!) In-Reply-To: References: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> Message-ID: <7d6fde3d0906102324i7c296d40pdf5a5e853c359bc3@mail.gmail.com> On Wed, Jun 10, 2009 at 10:58 PM, Dan Naumov wrote: > You need to mount your /dev/ad6s1d.journal as /usr and not > /dev/ad6s1d, because this is the new device provided to you by GEOM. > > - Dan Naumov > > > > On Thu, Jun 11, 2009 at 5:50 AM, Garrett Cooper wrote: >> On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrote: >>> Hi Pawel, ATA, and Stable folks, >>> >>> ? ?This time when I did a reinstall I took the bullet and tried to >>> use gjournaling instead of softupdates. The unfortunate thing is that >>> I can't seem to get it to work. >>> >>> Here's the procedure that I'm trying to follow (based off of [1]): >>> - sysinstall from scratch with a minimal distribution. This creates >>> /usr // /dev/ad6s1d as UFS2 with softupdates disabled. >>> - Pull latest stable sources. Rebuild kernel (with `options >>> GEOM_JOURNAL'), world, install kernel, then world after reboot. >>> - gjournal label -f ad6s1d ad6s2d >>> - mount /dev/ad6s1d /usr # That works (I think...), but prints out the >>> error message below: >>> >>> GEOM_JOURNAL: [flush] Error while writing data (error=1) >>> ad6s2d[WRITE(offset=512, length=6656)] >>> >>> gjournal status says: >>> ? ? ? ? ? ?Name ? Status ? Components >>> ad6s1d.journal ? ? ? N/A ? ad6s1d >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ad6s2d >>> >>> Some issues I noticed: >>> >>> - GJOURNAL ROOT (something) loops infinitely if the device can't be >>> found; this should probably time out and panic / exit if a device >>> becomes unavailable (depends on fstab values in the final 2 fields no >>> doubt). I did this by accident when I forgot to add iir statically to >>> the kernel. >>> - The LiveCD doesn't fully support gjournal (userland's there, kernel >>> support isn't). Kind of annoying and counterproductive... >>> - Existing journal partitions disappeared when I upgraded by accident >>> from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from >>> my server with label=.). That was weird... >>> - When I use gjournal label with an existing filesystem I _must_ use -f. >>> >>> Any help with this endeavor would be more than appreciated, as I want >>> to enable this functionality before I move on to installing X11, as >>> nvidia-driver frequently hardlocks the desktop (or has in the past). >>> >>> Thanks, >>> -Garrett >>> >>> [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html >> >> And to answer another potential question, I've tried mounting both >> with -o rw,async and with -o rw. >> Thanks! >> -Garrett Hi Dan, I'm doing that right now =\... orangebox# mount /dev/ad6s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad6s1d.journal on /usr (ufs, asynchronous, local) /dev/ad6s1e on /usr/home (ufs, local) /dev/ad6s1f on /var (ufs, local) Thanks! -Garrett From dudu at dudu.ro Thu Jun 11 08:41:18 2009 From: dudu at dudu.ro (Vlad Galu) Date: Thu Jun 11 08:41:26 2009 Subject: poll()-ing a pipe descriptor, watching for POLLHUP In-Reply-To: <20090604030724.V1181@besplex.bde.org> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> <20090603143051.GM1927@deviant.kiev.zoral.com.ua> <20090603150710.GN1927@deviant.kiev.zoral.com.ua> <20090604030724.V1181@besplex.bde.org> Message-ID: On Wed, Jun 3, 2009 at 9:42 PM, Bruce Evans wrote: [...] Hello Bruce, Kostik, Oliver. Was any consensus reached on how to tackle this issue? The RELENG_7 code looks slightly different so I haven't (yet) tried adapting the provided patches. As for the interface behavior, I think the nicest way would be to signal EOF by POLLHUP alone, without POLLIN. Regards, Vlad From vilmos.gyorgy at gmail.com Thu Jun 11 12:13:29 2009 From: vilmos.gyorgy at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Vilmos?=) Date: Thu Jun 11 12:13:36 2009 Subject: .zfs snapshot dir disappears and a crash later on, while umounting Message-ID: Hi All! (please keep me on cc) FreeBSD 7/amd64 stable compiled with GENERIC on May 23 22:22:00 CEST 2009 (csuped sources around that time) on an IBM xSomething. I have a single disk zfs pool for backup purposes, the fs is compressed and the stuff goes onto it every night and then snapshotted once. I have a nullfs mount from that to a UFS partition, like this: bkp on /bkp (zfs, local) bkp@20090607 on /bkp/.zfs/snapshot/20090607 (zfs, local, noatime, read- only) bkp@20090610 on /bkp/.zfs/snapshot/20090610 (zfs, local, noatime, read- only) bkp@20090609 on /bkp/.zfs/snapshot/20090609 (zfs, local, noatime, read- only) bkp@20090608 on /bkp/.zfs/snapshot/20090608 (zfs, local, noatime, read- only) /bkp/hosting on /data/jail/hosting/bkp (nullfs, local) The strange thing is that while did the above, I lost .zfs, so an ls wrote this: ls /bkp/.zfs/snapshot ls: /bkp/.zfs/snapshot: Bad file descriptor df also didn't show the snapshot dirs after it, but I could do snapshots and zfs list -t snapshot showed them, I just couldn't access them. Today, I've tried to umount the nullfs mount and the zfs pool to see whether it helps the situation, but it didn't, I was awarded with a crashdump. What I did is: umount /data/jail/hosting/bkp (went fine, I haven't got back the .zfs snapshot dir) then: zfs export bkp (crash) The crashdump says: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc0 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff80517925 stack pointer = 0x10:0xffffff80780249d0 frame pointer = 0x10:0xffffff8078024a50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 35021 (zpool) trap number = 12 panic: page fault cpuid = 1 Uptime: 14d22h20m56s Physical memory: 4082 MB bt says: (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff8050ff29 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:418 #3 0xffffffff80510332 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff807d5a33 in trap_fatal (frame=0xffffff0020214390, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0xffffffff807d5e05 in trap_pfault (frame=0xffffff8078024920, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #6 0xffffffff807d6744 in trap (frame=0xffffff8078024920) at /usr/src/ sys/amd64/amd64/trap.c:444 #7 0xffffffff807ba96e in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:209 #8 0xffffffff80517925 in _sx_xlock (sx=0xa0, opts=0, file=0xffffffff80f045e8 "/usr/src/sys/modules/zfs/../../cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_ctldir.c", line=1288) at atomic.h:143 #9 0xffffffff80e97e55 in zfsctl_umount_snapshots (vfsp=Variable "vfsp" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ common/fs/zfs/zfs_ctldir.c:1288 #10 0xffffffff80ea3560 in zfs_umount (vfsp=0xffffff00048b7380, fflag=0, td=Variable "td" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ common/fs/zfs/zfs_vfsops.c:1003 #11 0xffffffff8058e1a7 in dounmount (mp=0xffffff00048b7380, flags=0, td=0xffffff0020214390) at /usr/src/sys/kern/vfs_mount.c:1290 #12 0xffffffff8058e975 in unmount (td=0xffffff0020214390, uap=0xffffff8078024bf0) at /usr/src/sys/kern/vfs_mount.c:1186 #13 0xffffffff807d6087 in syscall (frame=0xffffff8078024c80) at /usr/ src/sys/amd64/amd64/trap.c:900 #14 0xffffffff807bab7b in Xfast_syscall () at /usr/src/sys/amd64/amd64/ exception.S:330 #15 0x000000080102e5cc in ?? () Previous frame inner to this frame (corrupt stack?) I have the dump, if any further info could help. Thank you in advance. From lists at reiteration.net Thu Jun 11 13:47:32 2009 From: lists at reiteration.net (John) Date: Thu Jun 11 13:47:39 2009 Subject: malo wireless driver - is this capable of wpa2-personal (WPA2-PSK) Message-ID: <4A30F7A1.1080301@reiteration.net> Hello list, uname -prs FreeBSD 7.2-RELEASE-p1 amd64 Question as subject, really. Is the malo driver capable of WPA2 under FreeBSD? ? If so, how would it be set? I've tried various wireless options via ifconfig, can't seem to get it to work, so am wondering if it is capable of it. I know support for it appeared in HEAD on OpenBSD around the middle of April, and this driver is derived from that. thanks -- John From scottl at samsco.org Thu Jun 11 15:35:40 2009 From: scottl at samsco.org (Scott Long) Date: Thu Jun 11 15:35:48 2009 Subject: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step In-Reply-To: <4A2FE765.9000803@freebsd.org> References: <4A2FA4EF.5060603@freebsd.org> <4A2FC858.5050800@samsco.org> <4A2FE765.9000803@freebsd.org> Message-ID: <4A312448.1060009@samsco.org> Andre Oppermann wrote: > Scott Long wrote: >> Andre Oppermann wrote: >>> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got >>> a big >>> nasty surprise with the Areca RAID controller: >>> >>> arcmsr0: >> > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >>> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >>> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >>> arcmsr0: [ITHREAD] >>> ... >>> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >>> run_interrupt_driven_hooks: still waiting after 60 seconds for >>> xpt_config >>> >>> From here on it hangs and repeats the last message with some sort of >>> exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock >>> does. Hard reset is required to reboot. >>> >>> Booting the old 6.4 kernel works and the system comes up again with full >>> access to the RAID array. >>> >>> Any help appreciated. >>> >> >> I'll try to reproduce this locally. There have been sporadic reports of >> the "fails comparison" problem, but none as fatal as this. Is it >> possible to compile your kernel with CAMDEBUG and >> CAM_DEBUG_FLAGS=CAM_DEBUG_INFO? > > CAMDEBUG doesn't give any output. > > As it turns out the hang seems to be related to an interrupt routing > problem somehow. I did an BIOS upgrade and BIOS settings factory reset. > The mainboard is an ASUS M2N32 WS Professional with an Athlon64 X2 4800+. > Enabling all on-board devices including ATA and various SATA controllers > together with "PnP OS" set to yes fixed the hand and allowed FreeBSD 7 to > boot sucessfully. Why 6.4 doesn't stumble I don't know. > > The "(probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step" > line is still there. Fortunately the boot process simply continues from > there without further trouble. > > If there are any other CAM debug options or patches you want me to try I > can do that. The system is only in partial production and I'm allowed to > reboot it during workhours. > You enabled both CAMDEBUG and CAM_DEBUG_FLAGS=CAM_DEBUG_INFO in your kernel? Scott From sam at freebsd.org Thu Jun 11 15:47:24 2009 From: sam at freebsd.org (Sam Leffler) Date: Thu Jun 11 15:47:32 2009 Subject: malo wireless driver - is this capable of wpa2-personal (WPA2-PSK) In-Reply-To: <4A30F7A1.1080301@reiteration.net> References: <4A30F7A1.1080301@reiteration.net> Message-ID: <4A31201F.8060300@freebsd.org> John wrote: > Hello list, > > uname -prs > FreeBSD 7.2-RELEASE-p1 amd64 > > Question as subject, really. Is the malo driver capable of WPA2 under > FreeBSD? ? If so, how would it be set? I've tried various wireless > options via ifconfig, can't seem to get it to work, so am wondering if > it is capable of it. I know support for it appeared in HEAD on OpenBSD > around the middle of April, and this driver is derived from that. > > thanks > malo is derived from the mwl driver. it supports wpa. Sam From onemda at gmail.com Thu Jun 11 16:32:06 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Jun 11 16:32:12 2009 Subject: malo wireless driver - is this capable of wpa2-personal (WPA2-PSK) In-Reply-To: <4A30F7A1.1080301@reiteration.net> References: <4A30F7A1.1080301@reiteration.net> Message-ID: <3a142e750906110932naca99bam8d0e0735ddec2797@mail.gmail.com> On 6/11/09, John wrote: > Hello list, > > uname -prs > FreeBSD 7.2-RELEASE-p1 amd64 > > Question as subject, really. Is the malo driver capable of WPA2 under > FreeBSD? ? If so, how would it be set? I've tried various wireless via wpa_supplicant(8) > options via ifconfig, can't seem to get it to work, so am wondering if > it is capable of it. I know support for it appeared in HEAD on OpenBSD > around the middle of April, and this driver is derived from that. > > thanks > -- > John > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Paul From danallen46 at airwired.net Thu Jun 11 21:25:33 2009 From: danallen46 at airwired.net (Dan Allen) Date: Thu Jun 11 21:25:39 2009 Subject: Something since June 8th clobbers my disk... Message-ID: I sync with 7-STABLE almost every day. I build everything on a Toshiba U205 Satellite. Things are fine for months on end. I did this on June 8th. Everything was fine. I did this on June 10th. The machine no longer booted. The entire root partition got clobbered. I reinstalled a snapshot of 7-STABLE from May 28th that I had put on a DVD. Everything was once again fine. I then sync'd again this morning June 11th with 7-STABLE, did a full build, and reproducibly, BOOM - the entire root partition got clobbered. Gone. Again. After the reboot it just comes up with: BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 and stops. Nothing else is printed. There is no choice of how to boot. There is no files for me to send, no log files to inspect, no remnants. I unfortunately did not see where in the build this happened. My build does the canonical steps exactly as outlined in / usr/src/Makefile and then does a reboot. It builds userland and the kernel. When I inspect it from the bootable DVD the partition that my root filesystem was in has no association with it having the root any more. The partition is listed, but it looks like it had been freshly partitioned. Something is very, very wrong. Ideas? Dan Allen From onemda at gmail.com Thu Jun 11 21:40:39 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Jun 11 21:40:46 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: References: Message-ID: <3a142e750906111440s26405c53v82fa82917145b930@mail.gmail.com> On 6/11/09, Dan Allen wrote: > I sync with 7-STABLE almost every day. I build everything on a > Toshiba U205 Satellite. Things are fine for months on end. > > I did this on June 8th. Everything was fine. > > I did this on June 10th. The machine no longer booted. The entire > root partition got clobbered. I reinstalled a snapshot of 7-STABLE > from May 28th that I had put on a DVD. Everything was once again fine. > > I then sync'd again this morning June 11th with 7-STABLE, did a full > build, and reproducibly, BOOM - the entire root partition got > clobbered. Gone. Again. After the reboot it just comes up with: > > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive A: is disk0 > BIOS drive C: is disk1 > > and stops. Nothing else is printed. There is no choice of how to > boot. There is no files for me to send, no log files to inspect, no > remnants. I unfortunately did not see where in the build this > happened. My build does the canonical steps exactly as outlined in / > usr/src/Makefile and then does a reboot. It builds userland and the > kernel. > > When I inspect it from the bootable DVD the partition that my root > filesystem was in has no association with it having the root any > more. The partition is listed, but it looks like it had been freshly > partitioned. > > Something is very, very wrong. > > Ideas? Are you using ZFS on root partition? -- Paul From danallen46 at airwired.net Thu Jun 11 21:44:25 2009 From: danallen46 at airwired.net (Dan Allen) Date: Thu Jun 11 21:44:32 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <3a142e750906111440s26405c53v82fa82917145b930@mail.gmail.com> References: <3a142e750906111440s26405c53v82fa82917145b930@mail.gmail.com> Message-ID: <7747D41F-0F3E-4D4A-AA20-552F308D8D2E@airwired.net> On 11 Jun 2009, at 3:40 PM, Paul B. Mahol wrote: > Are you using ZFS on root partition? No. The disk is the default (UFS2 I believe). So I just reinstalled BSD again and this time I did not reinitialize the file system and after a brief disk integrity check it reinstalled and files I had added were still there! So apparently the file system did not get munged as much as the main disk partition map got nailed. So, what has changed recently that could mess with the disk partition map? I have Windows on the first disk partition and it has not been harmed with these problems. Dan From danallen46 at airwired.net Thu Jun 11 22:40:59 2009 From: danallen46 at airwired.net (Dan Allen) Date: Thu Jun 11 22:41:06 2009 Subject: Something since June 8th clobbers my disk... Message-ID: <68F716C4-212C-449E-AEB7-AA14720C0D69@airwired.net> In trying to figure this out, I rebuilt a GENERIC kernel after sync'ing to today's RELENG_7 sources. I then installed it, held my breath, and rebooted. It works! So I am now looking at userland (make buildworld && make installworld) to see if it is the culprit. Another possibility is my custom kernel build. Stay tuned... Dan From danallen46 at airwired.net Thu Jun 11 23:36:48 2009 From: danallen46 at airwired.net (Dan Allen) Date: Thu Jun 11 23:36:54 2009 Subject: Something since June 8th clobbers my disk... Message-ID: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> Okay. I did a make buildkernel && installkernel and rebooted, no problems. I then did a make buildworld and rebooted, no problems. I then did a make installworld which completed normally, rebooted, and BINGO - my disk partition table has been zapped. The problem appears to be something that runs during this 'make installworld'! There are no problems with the build itself that I can tell, but some program is munging the disk partition table. In a zany sort of way this is progress. Of course now I have to reinstall the OS, again... Dan Allen From onemda at gmail.com Thu Jun 11 23:41:29 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Jun 11 23:41:38 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> Message-ID: <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> On 6/11/09, Dan Allen wrote: > Okay. I did a > > make buildkernel && installkernel > > and rebooted, no problems. > > I then did a > > make buildworld > > and rebooted, no problems. > > I then did a > > make installworld > > which completed normally, rebooted, and > > BINGO - my disk partition table has been zapped. > > The problem appears to be something that runs during this 'make > installworld'! > > There are no problems with the build itself that I can tell, but some > program is munging the disk partition table. > > In a zany sort of way this is progress. Of course now I have to > reinstall the OS, again... Looks like boot(8) is problematic. Anything in /etc/src.conf or /etc/make.conf? -- Paul From crapsh at monkeybrains.net Fri Jun 12 01:10:22 2009 From: crapsh at monkeybrains.net (Rudy Rucker) Date: Fri Jun 12 01:10:28 2009 Subject: ZFS jumps from slice to partition on upgrade (???) Message-ID: <4A31A596.6090707@monkeybrains.net> I just bumped from: FreeBSD 7.2-PRERELEASE #1: Wed Mar 18 00:55:27 PDT 2009 to: FreeBSD 7.2-STABLE #2: Wed Jun 10 18:27:30 PDT 2009 I rebooted and my zpool was WHACK'd. I was getting these errors in /var/log/messages: Jun 11 16:54:55 crepe3 root: ZFS: vdev I/O failure, zpool=tank path=/dev/ad6s2c offset=481721292800 size=1024 error=5 Jun 11 16:54:55 crepe3 root: ZFS: vdev I/O failure, zpool=tank path=/dev/ad6s2c offset=481721293824 size=1024 error=5 I had ad0s2 and ad6s2 in my zpool mirror, but after the upgrade zfs read the devices as: ad0s2 and ad6s2c. So I dropped the 'c' parition and reattached the slice: # zpool detach tank ad6s2c # zpool attach tank ad0s2 ad6s2 and now my 'zpool status' shows it resilvering... pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h22m, 21.91% done, 1h21m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad0s2 ONLINE 0 0 0 82.2M resilvered ad6s2 ONLINE 0 0 0 19.0G resilvered QUESTION: Why the heck would ZFS latch onto ad6s2c partition instead of the ad6s2 slice? I've rebooted many times before without issue... it seems the upgrade bonk'd things. Hopefully when this is all done, I can run zfs upgrade... anyone have trouble with "zfs upgrade"? Rudy From crapsh at monkeybrains.net Fri Jun 12 01:30:09 2009 From: crapsh at monkeybrains.net (Rudy) Date: Fri Jun 12 01:30:16 2009 Subject: ZFS jumps from slice to partition on upgrade (???) In-Reply-To: <4A31A596.6090707@monkeybrains.net> References: <4A31A596.6090707@monkeybrains.net> Message-ID: <4A31AFA1.304@monkeybrains.net> History for 'tank': 2008-01-17.23:07:08 zpool create tank mirror ad0s2 ad8s2 2008-01-17.23:40:35 zfs create -o quota=100g tank/test.monkeybrains.net ... many more creates/deletes ... then the zfs freakout ... 2009-06-11.16:43:33 zpool clear tank 2009-06-11.16:43:59 zpool scrub tank 2009-06-11.16:48:58 zpool scrub -s tank 2009-06-11.16:54:56 zpool detach tank ad6s2c 2009-06-11.16:55:57 zpool attach tank ad0s2 ad6s2 Maybe having the device jump from ad8s2 to ad6s2 freaked out zfs? Any thoughts, or will the Internet tube swallow this post silently? Rudy From danallen46 at airwired.net Fri Jun 12 01:33:28 2009 From: danallen46 at airwired.net (Dan Allen) Date: Fri Jun 12 01:33:37 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> Message-ID: On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > Looks like boot(8) is problematic. > Anything in /etc/src.conf or /etc/make.conf? I have never touched or created a src.conf. If there was one there, it has been unmodified by me. I HAVE modified make.conf. Here is its contents: --- /etc/make.conf --- BATCH=yes NO_PROFILE=yes KERNCONF=DKA USE_FORTRAN=yes WITH_JADETEX=no PERL_VERSION=5.8.9 --- My custom kernel named DKA has only three modifications from GENERIC: I commented out the following three lines: #cpu I486_CPU #cpu I586_CPU #makeoptions DEBUG="-g" I have run with such a kernel on many machines for many years now. However, my experiments have shown that the kernel build is not to blame. Isn't boot part of the kernel build? Why would installing the kernel not cause this problem? It is by installing the world via make installworld that my drive gets munged. I obviously am missing something, but boot(8) sounds like it is in the neighborhood of where the problem is. There were changes to /usr/src/sys/boot/i386/libi386/biosdisk.c and biospnp.c that really look suspect to me. Dan From tinderbox at freebsd.org Fri Jun 12 05:03:52 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Jun 12 05:04:10 2009 Subject: [releng_6 tinderbox] failure on amd64/amd64 Message-ID: <20090612050347.EA98D241BA@freebsd-legacy.sentex.ca> TB --- 2009-06-12 05:03:27 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2009-06-12 05:03:27 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2009-06-12 05:03:27 - cleaning the object tree TB --- 2009-06-12 05:03:47 - WARNING: /obj/amd64/src/sys/LINT/modules/src/sys/modules/sound/driver/spicds: Directory not empty TB --- 2009-06-12 05:03:47 - ERROR: unable to remove old object directory TB --- 2009-06-12 05:03:47 - 0.55 user 2.09 system 20.02 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full From danny at cs.huji.ac.il Fri Jun 12 07:57:44 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Jun 12 07:57:51 2009 Subject: (no subject) Message-ID: latest -stable (June 11) is causing problems: MB is intel SE7320VP21, msk0: Ethernet address: 00:0e:0c:6a:85:a8 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering ... cheers, danny From pyunyh at gmail.com Fri Jun 12 08:42:38 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jun 12 08:42:45 2009 Subject: your mail In-Reply-To: References: Message-ID: <20090612082212.GE72855@michelle.cdnetworks.co.kr> On Fri, Jun 12, 2009 at 10:57:42AM +0300, Danny Braniss wrote: > latest -stable (June 11) is causing problems: > MB is intel SE7320VP21, > > msk0: Ethernet address: 00:0e:0c:6a:85:a8 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > ... > I think there was not much msk(4) changes in stable. msk(4) in CURRENT has a lot changes to support newer controllers. Does msk(4) in CURRENT make any difference? Also please show me dmesg output(msk(4) related one) to know which controller you have. Btw, are you using MSI? > cheers, > danny > > From danny at cs.huji.ac.il Fri Jun 12 08:59:30 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Jun 12 08:59:36 2009 Subject: msk/stable In-Reply-To: <20090612082212.GE72855@michelle.cdnetworks.co.kr> References: <20090612082212.GE72855@michelle.cdnetworks.co.kr> Message-ID: > On Fri, Jun 12, 2009 at 10:57:42AM +0300, Danny Braniss wrote: > > latest -stable (June 11) is causing problems: > > MB is intel SE7320VP21, > > > > msk0: Ethernet address: 00:0e:0c:6a:85:a8 > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > ... > > > > I think there was not much msk(4) changes in stable. msk(4) in > CURRENT has a lot changes to support newer controllers. Does msk(4) > in CURRENT make any difference? > Also please show me dmesg output(msk(4) related one) to know which > controller you have. hrumph, missed some lines: mskc0: port 0xb800-0xb8ff mem 0xdeefc000-0xdeefffff irq 16 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:0e:0c:6a:85:a8 miibus0: on msk0 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0: [FILTER] > > Btw, are you using MSI? yes, but it was (so it seemed) working ok. i'll try again soon without msi. in the meantime, Im running an older kernel, trying to finish a very long process (svn/svk), which when done, I will be able to compile current. thanks, danny From jhb at freebsd.org Fri Jun 12 12:59:22 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Jun 12 12:59:28 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> Message-ID: <200906120832.51098.jhb@freebsd.org> On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > Isn't boot part of the kernel build? Why would installing the kernel > not cause this problem? No, sys/boot is built during world. Likely some change in /boot/loader is causing your problem. Can you narrow it down to a specific change under sys/boot? -- John Baldwin From avg at icyb.net.ua Fri Jun 12 13:56:51 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Jun 12 13:56:59 2009 Subject: zfs related panic Message-ID: <4A325E9F.2080802@icyb.net.ua> This is on a recent stable/7 amd64, with zpool and filesystems upgraded to the latest version. I did zfs rollback xxx@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 0xffffffff8031d0ef = sched_switch+0x47d mi_switch() at 0xffffffff80302a59 = mi_switch+0x1bf sleepq_switch() at 0xffffffff8032f645 = sleepq_switch+0xd8 sleepq_catch_signals() at 0xffffffff8032f925 = sleepq_catch_signals+0x2db sleepq_wait_sig() at 0xffffffff80330219 = sleepq_wait_sig+0xc _sleep() at 0xffffffff80302eba = _sleep+0x2b5 kern_sigsuspend() at 0xffffffff802fc567 = kern_sigsuspend+0xeb sigsuspend() at 0xffffffff802fc5e9 = sigsuspend+0x34 syscall() at 0xffffffff80491d2d = syscall+0x347 Xfast_syscall() at 0xffffffff8047d00b = Xfast_syscall+0xab --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x80092ce3c, rsp = 0x7fffffffdee8, rbp = 0x8011e5a60 --- panic: sleeping thread cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80192dd5 = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff80327ea7 = kdb_backtrace+0x32 panic() at 0xffffffff802fb70c = panic+0x1b0 propagate_priority() at 0xffffffff80332e92 = propagate_priority+0x122 turnstile_wait() at 0xffffffff80333e29 = turnstile_wait+0x358 _mtx_lock_sleep() at 0xffffffff802ed64a = _mtx_lock_sleep+0x117 cache_lookup() at 0xffffffff8036a52a = cache_lookup+0x632 vfs_cache_lookup() at 0xffffffff8036a69f = vfs_cache_lookup+0xab VOP_LOOKUP_APV() at 0xffffffff804c86f3 = VOP_LOOKUP_APV+0x51 lookup() at 0xffffffff80370a71 = lookup+0x5d8 namei() at 0xffffffff8037168f = namei+0x320 kern_lstat() at 0xffffffff8037f6ca = kern_lstat+0x5e lstat() at 0xffffffff8037f8c9 = lstat+0x25 syscall() at 0xffffffff80491d2d = syscall+0x347 Xfast_syscall() at 0xffffffff8047d00b = Xfast_syscall+0xab --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80095afbc, rsp = 0x7fffffffdde8, rbp = 0x800b50270 --- -- Andriy Gapon From jfvogel at gmail.com Fri Jun 12 17:03:39 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Jun 12 17:03:50 2009 Subject: Intel ESB2 problems and their solution Message-ID: <2a41acea0906121003n4e2c8a54k6ac41cc934c6d7d0@mail.gmail.com> I wanted to circulate a document from our technical marketing group that details a problem with the family of adapters called ES2LAN. These are most commonly seen as LOMs (on motherboard) in SuperMicro and other servers, the most common device ID is 0x1096 but also may be 0x1098, 0x10BA, or 0x10BB. They are a device driven by the 'em' driver. This document has some Windows symptoms that will be of no value here, but the problem does occur on FreeBSD, most often it is seen as a failure to load, due to a "Shared Code Initialization" failure. There is driver changes in 7.2 that address this problem, however the driver alone is only part of the complete solution, you MUST have firmware updates to resolve the problem, and this document provides pointers for particular systems. If you have a system that has seen this issue please obtain and apply the relevant firmware. I hope this helps resolve any of these issues customers are still seeing. Cheers everyone, Jack Vogel Intel Lan Access Division freebsd@intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ESB2_problems.pdf Type: application/pdf Size: 29539 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090612/21c541b5/ESB2_problems.pdf From phk at phk.freebsd.dk Fri Jun 12 17:41:25 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jun 12 17:41:32 2009 Subject: Stable7 buildoption effects: updated table Message-ID: <48090.1244827340@critter.freebsd.dk> I have just completed a run of /src/tools/tools/build_option_survey and have uploaded the result here: http://phk.freebsd.dk/misc/stable7_build_options/ Those of you building embedded systems on FreeBSD 7.x may find this useful. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From kmacy at freebsd.org Fri Jun 12 20:54:43 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri Jun 12 20:54:55 2009 Subject: zfs related panic In-Reply-To: <4A325E9F.2080802@icyb.net.ua> References: <4A325E9F.2080802@icyb.net.ua> Message-ID: <3c1674c90906121354s6d6ae7ben5082708b1586e94f@mail.gmail.com> show sleepchain show thread 100263 On Fri, Jun 12, 2009 at 6:56 AM, Andriy Gapon wrote: > > This is on a recent stable/7 amd64, with zpool and filesystems upgraded to the > latest version. > I did zfs rollback xxx@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 0xffffffff8031d0ef = sched_switch+0x47d > mi_switch() at 0xffffffff80302a59 = mi_switch+0x1bf > sleepq_switch() at 0xffffffff8032f645 = sleepq_switch+0xd8 > sleepq_catch_signals() at 0xffffffff8032f925 = sleepq_catch_signals+0x2db > sleepq_wait_sig() at 0xffffffff80330219 = sleepq_wait_sig+0xc > _sleep() at 0xffffffff80302eba = _sleep+0x2b5 > kern_sigsuspend() at 0xffffffff802fc567 = kern_sigsuspend+0xeb > sigsuspend() at 0xffffffff802fc5e9 = sigsuspend+0x34 > syscall() at 0xffffffff80491d2d = syscall+0x347 > Xfast_syscall() at 0xffffffff8047d00b = Xfast_syscall+0xab > --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x80092ce3c, rsp = > 0x7fffffffdee8, rbp = 0x8011e5a60 --- > panic: sleeping thread > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff80192dd5 = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff80327ea7 = kdb_backtrace+0x32 > panic() at 0xffffffff802fb70c = panic+0x1b0 > propagate_priority() at 0xffffffff80332e92 = propagate_priority+0x122 > turnstile_wait() at 0xffffffff80333e29 = turnstile_wait+0x358 > _mtx_lock_sleep() at 0xffffffff802ed64a = _mtx_lock_sleep+0x117 > cache_lookup() at 0xffffffff8036a52a = cache_lookup+0x632 > vfs_cache_lookup() at 0xffffffff8036a69f = vfs_cache_lookup+0xab > VOP_LOOKUP_APV() at 0xffffffff804c86f3 = VOP_LOOKUP_APV+0x51 > lookup() at 0xffffffff80370a71 = lookup+0x5d8 > namei() at 0xffffffff8037168f = namei+0x320 > kern_lstat() at 0xffffffff8037f6ca = kern_lstat+0x5e > lstat() at 0xffffffff8037f8c9 = lstat+0x25 > syscall() at 0xffffffff80491d2d = syscall+0x347 > Xfast_syscall() at 0xffffffff8047d00b = Xfast_syscall+0xab > --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80095afbc, rsp = 0x7fffffffdde8, > rbp = 0x800b50270 --- > > -- > Andriy Gapon > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@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 From kstewart at owt.com Sat Jun 13 02:30:54 2009 From: kstewart at owt.com (Kent Stewart) Date: Sat Jun 13 02:31:01 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> Message-ID: <200906121916.46729.kstewart@owt.com> On Thursday 11 June 2009 06:33:24 pm Dan Allen wrote: > On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > > Looks like boot(8) is problematic. > > Anything in /etc/src.conf or /etc/make.conf? > > I have never touched or created a src.conf. If there was one there, > it has been unmodified by me. > > I HAVE modified make.conf. Here is its contents: > > --- /etc/make.conf --- > > BATCH=yes > NO_PROFILE=yes > KERNCONF=DKA > USE_FORTRAN=yes > WITH_JADETEX=no > PERL_VERSION=5.8.9 > > --- > > My custom kernel named DKA has only three modifications from GENERIC: > > I commented out the following three lines: > > #cpu I486_CPU > #cpu I586_CPU > #makeoptions DEBUG="-g" > > I have run with such a kernel on many machines for many years now. > > However, my experiments have shown that the kernel build is not to > blame. > > Isn't boot part of the kernel build? Why would installing the kernel > not cause this problem? > > It is by installing the world via make installworld that my drive gets > munged. > > I obviously am missing something, but boot(8) sounds like it is in the > neighborhood of where the problem is. > > There were changes to /usr/src/sys/boot/i386/libi386/biosdisk.c and > biospnp.c that really look suspect to me. The order of your builds in previous messages had the kernel built on an old world. You are supposed to do the buildworld first and then, build and install the kernel. The classic way at this point is to boot into single user mode and do the installworld. Kent > > Dan > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From danallen46 at airwired.net Sat Jun 13 02:45:12 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sat Jun 13 02:45:19 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <200906120832.51098.jhb@freebsd.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> Message-ID: <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: >> Isn't boot part of the kernel build? Why would installing the kernel >> not cause this problem? > > No, sys/boot is built during world. Likely some change in /boot/ > loader is > causing your problem. Can you narrow it down to a specific change > under > sys/boot? Ok. I updated just the one file since it appeared like one of the few changed files /usr/src/sys/boot/i386/libi386/biosdisk.c and rebuilt things with cd /usr/src/sys/boot; make cleandir obj depend all install and it was okay. No problems. Then I did sync'd all of the changed files for /usr/src/sys/boot and my machine is hung again at boot, so we have narrowed it down to somewhere in /usr/src/sys/boot/. Time to reinstall from a DVD and try it with finer granularity. This will take some time. There appears to be only four files that have changed in /usr/src/sys/ boot from June 8th (all working fine) to June 11th (dead in the water). They are: /usr/src/sys/boot/Makefile /usr/src/sys/boot/i386/Makefile /usr/src/sys/boot/i386/libi386/biosdisk.c /usr/src/sys/boot/i386/loader/Makefile I have ruled out bisodisk.c, as stated above. That means that the Makefiles are building new stuff that previously was not built, namely zfsboot gptzfsboot I believe it has to do with that. More help is needed! I am tired of reinstalling the OS, but I am much more paranoid about updating my other machine in any way now, as it could erase that whole machine. I can't believe I am the only one seeing this... Dan From kline at thought.org Sat Jun 13 03:38:23 2009 From: kline at thought.org (Gary Kline) Date: Sat Jun 13 03:38:31 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> Message-ID: <20090613032442.GA24933@thought.org> On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > >>Isn't boot part of the kernel build? Why would installing the kernel > >>not cause this problem? > > > >No, sys/boot is built during world. Likely some change in /boot/ > >loader is > >causing your problem. Can you narrow it down to a specific change > >under > >sys/boot? > > Ok. I updated just the one file since it appeared like one of the few > changed files > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > and rebuilt things with > > cd /usr/src/sys/boot; make cleandir obj depend all install > > and it was okay. No problems. > > Then I did sync'd all of the changed files for /usr/src/sys/boot and > my machine is hung again at boot, so we have narrowed it down to > somewhere in /usr/src/sys/boot/. > > Time to reinstall from a DVD and try it with finer granularity. This > will take some time. > > There appears to be only four files that have changed in /usr/src/sys/ > boot from June 8th (all working fine) to June 11th (dead in the > water). They are: > > /usr/src/sys/boot/Makefile > /usr/src/sys/boot/i386/Makefile > /usr/src/sys/boot/i386/libi386/biosdisk.c > /usr/src/sys/boot/i386/loader/Makefile > > I have ruled out bisodisk.c, as stated above. > > That means that the Makefiles are building new stuff that previously > was not built, namely > > zfsboot gptzfsboot > > I believe it has to do with that. More help is needed! I am tired of > reinstalling the OS, but I am much more paranoid about updating my > other machine in any way now, as it could erase that whole machine. I > can't believe I am the only one seeing this... > > Dan > Whew!! i'm giving thanks to every saint, god and daemon known. i rebuilt my kernel in very recent days (7.2) on my ancient 500MHz kayak, but did not go further. So still runing on the 7.0 kernel. Will someone send up a flare when it's *safe*? gary -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org For FBSD list: http://transfinite.thought.org/slicejourney.php The 4.98a release of Jottings: http://jottings.thought.org/index.php From yuri.pankov at gmail.com Sat Jun 13 04:18:38 2009 From: yuri.pankov at gmail.com (Yuri Pankov) Date: Sat Jun 13 04:18:46 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <20090613032442.GA24933@thought.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <20090613032442.GA24933@thought.org> Message-ID: <20090613035023.GB1227@darklight.homeunix.org> On Fri, Jun 12, 2009 at 08:24:42PM -0700, Gary Kline wrote: > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > >>Isn't boot part of the kernel build? Why would installing the kernel > > >>not cause this problem? > > > > > >No, sys/boot is built during world. Likely some change in /boot/ > > >loader is > > >causing your problem. Can you narrow it down to a specific change > > >under > > >sys/boot? > > > > Ok. I updated just the one file since it appeared like one of the few > > changed files > > > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > > > and rebuilt things with > > > > cd /usr/src/sys/boot; make cleandir obj depend all install > > > > and it was okay. No problems. > > > > Then I did sync'd all of the changed files for /usr/src/sys/boot and > > my machine is hung again at boot, so we have narrowed it down to > > somewhere in /usr/src/sys/boot/. > > > > Time to reinstall from a DVD and try it with finer granularity. This > > will take some time. > > > > There appears to be only four files that have changed in /usr/src/sys/ > > boot from June 8th (all working fine) to June 11th (dead in the > > water). They are: > > > > /usr/src/sys/boot/Makefile > > /usr/src/sys/boot/i386/Makefile > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > /usr/src/sys/boot/i386/loader/Makefile > > > > I have ruled out bisodisk.c, as stated above. > > > > That means that the Makefiles are building new stuff that previously > > was not built, namely > > > > zfsboot gptzfsboot > > > > I believe it has to do with that. More help is needed! I am tired of > > reinstalling the OS, but I am much more paranoid about updating my > > other machine in any way now, as it could erase that whole machine. I > > can't believe I am the only one seeing this... > > > > Dan > > > > Whew!! i'm giving thanks to every saint, god and daemon known. i > rebuilt my kernel in very recent days (7.2) on my ancient > 500MHz kayak, but did not go further. So still runing on the 7.0 > kernel. > > Will someone send up a flare when it's *safe*? > > gary > > > > -- > Gary Kline kline@thought.org http://www.thought.org Public Service Unix > http://jottings.thought.org http://transfinite.thought.org > For FBSD list: http://transfinite.thought.org/slicejourney.php > The 4.98a release of Jottings: http://jottings.thought.org/index.php How do you know it isn't safe? Noone hasn't provided any useful info (debug, revisions where it works and where it doesn't). Yuri From kstewart at owt.com Sat Jun 13 06:24:13 2009 From: kstewart at owt.com (Kent Stewart) Date: Sat Jun 13 06:24:20 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <20090613032442.GA24933@thought.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <20090613032442.GA24933@thought.org> Message-ID: <200906122324.08061.kstewart@owt.com> On Friday 12 June 2009 08:24:42 pm Gary Kline wrote: > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > Whew!! i'm giving thanks to every saint, god and daemon known. i > rebuilt my kernel in very recent days (7.2) on my ancient > 500MHz kayak, but did not go further. So still runing on the 7.0 > kernel. > > Will someone send up a flare when it's *safe*? > > gary Gary, it isn't affecting everyone. FreeBSD ruby.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #4: Wed Jun 10 14:07:14 PDT 2009 root@ruby.owt.com:/usr/obj/usr/src/sys/FREEBSD2 i386 FreeBSD kstewart2.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 10 15:03:03 PDT 2009 root@kstewart2.owt.com:/usr/obj/usr/src/sys/FREEBSD1 i386 Ruby is an Intel core duo and the other has dual Xeon's. They were all installed the canonical way. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From kline at thought.org Sat Jun 13 07:08:23 2009 From: kline at thought.org (Gary Kline) Date: Sat Jun 13 07:08:31 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <200906122324.08061.kstewart@owt.com> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <20090613032442.GA24933@thought.org> <200906122324.08061.kstewart@owt.com> Message-ID: <20090613070817.GA25592@thought.org> On Fri, Jun 12, 2009 at 11:24:07PM -0700, Kent Stewart wrote: > On Friday 12 June 2009 08:24:42 pm Gary Kline wrote: > > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > > > Whew!! i'm giving thanks to every saint, god and daemon known. i > > rebuilt my kernel in very recent days (7.2) on my ancient > > 500MHz kayak, but did not go further. So still runing on the 7.0 > > kernel. > > > > Will someone send up a flare when it's *safe*? > > > > gary > > Gary, it isn't affecting everyone. > > FreeBSD ruby.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #4: Wed Jun 10 14:07:14 PDT > 2009 root@ruby.owt.com:/usr/obj/usr/src/sys/FREEBSD2 i386 > > FreeBSD kstewart2.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 10 > 15:03:03 PDT 2009 root@kstewart2.owt.com:/usr/obj/usr/src/sys/FREEBSD1 > i386 > > Ruby is an Intel core duo and the other has dual Xeon's. They were all > installed the canonical way. > Thanks for the insight, Kent. I'll go ahead and install 7.2 on the P3, then. Should be done this weekend. gary > Kent > -- > Kent Stewart > Richland, WA > > http://users.owt.com/kstewart/index.html > -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org For FBSD list: http://transfinite.thought.org/slicejourney.php The 4.98a release of Jottings: http://jottings.thought.org/index.php From kstewart at owt.com Sat Jun 13 08:08:35 2009 From: kstewart at owt.com (Kent Stewart) Date: Sat Jun 13 08:09:10 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <20090613070817.GA25592@thought.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <200906122324.08061.kstewart@owt.com> <20090613070817.GA25592@thought.org> Message-ID: <200906130108.33076.kstewart@owt.com> On Saturday 13 June 2009 12:08:17 am Gary Kline wrote: > On Fri, Jun 12, 2009 at 11:24:07PM -0700, Kent Stewart wrote: > > On Friday 12 June 2009 08:24:42 pm Gary Kline wrote: > > > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > > > > > Whew!! i'm giving thanks to every saint, god and daemon known. i > > > rebuilt my kernel in very recent days (7.2) on my ancient > > > 500MHz kayak, but did not go further. So still runing on the 7.0 > > > kernel. > > > > > > Will someone send up a flare when it's *safe*? > > > > > > gary > > > > Gary, it isn't affecting everyone. > > > > FreeBSD ruby.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #4: Wed Jun 10 > > 14:07:14 PDT 2009 root@ruby.owt.com:/usr/obj/usr/src/sys/FREEBSD2 > > i386 > > > > FreeBSD kstewart2.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 10 > > 15:03:03 PDT 2009 > > root@kstewart2.owt.com:/usr/obj/usr/src/sys/FREEBSD1 i386 > > > > Ruby is an Intel core duo and the other has dual Xeon's. They were all > > installed the canonical way. > > Thanks for the insight, Kent. I'll go ahead and install 7.2 on the > P3, then. Should be done this weekend. > Coming from the diagnostic side in the days of our Cray, I believe that one broken machine means more than 100 without problems. There just seems to be more to this than is normal. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From exemys at exemys.com Sat Jun 13 14:00:45 2009 From: exemys at exemys.com (Exemys) Date: Sat Jun 13 14:01:00 2009 Subject: I/O Serial Tunnel over Ethernet - Cellular - WiFi Message-ID: <4ee8822e7b83696737a9daf622ec6f95@www.hostmailing.com> This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From petefrench at ticketswitch.com Sat Jun 13 16:45:53 2009 From: petefrench at ticketswitch.com (Pete French) Date: Sat Jun 13 16:46:01 2009 Subject: reecommendations for an 'appliance" platform ? Message-ID: I am looking to deploy a couple of hundered system, which are supposed to attach to a network and be plug-in-and-go. I am thinking of doing this with a FreeBSD installation, duplicated onto flash cards, and dumped into some off-the-sheelt hardware. The questions I, what hardware ? I've done some research, and come up with boxes like this: http://www.icp-epia.co.uk/index.php?act=viewProd&productId=434 But I was wondering if anyone knew of any alternatives, preferably featuring a processor which can run amd64. The rest of thats pec is fine, and I dont need wifi. Any suggestions, or words of wisdom from anyone who has done someething similar themselevs in the past ? cheers, -pete. From danallen46 at airwired.net Sat Jun 13 16:57:00 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sat Jun 13 16:57:09 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <20090613035023.GB1227@darklight.homeunix.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <20090613032442.GA24933@thought.org> <20090613035023.GB1227@darklight.homeunix.org> Message-ID: On 12 Jun 2009, at 9:50 PM, Yuri Pankov wrote: > On Fri, Jun 12, 2009 at 08:24:42PM -0700, Gary Kline wrote: >> Whew!! i'm giving thanks to every saint, god and daemon known. i >> rebuilt my kernel in very recent days (7.2) on my ancient >> 500MHz kayak, but did not go further. So still runing on the 7.0 >> kernel. >> >> Will someone send up a flare when it's *safe*? >> > > How do you know it isn't safe? Noone hasn't provided any useful info > (debug, revisions where it works and where it doesn't). Well, I do not think it is safe at all either. I must have some strange configuration that others do not have or there would be plenty of people with their drives getting wiped out. I tried removing the zfsboot and gptzfsboot items from /usr/src/sys/ boot/i386/Makefile and then rebuild the boot area but it once again killed things. My hunch is that the boot loader is getting stuck on something strange about my system. Here is my drive config, and perhaps this will cause a light bulb to go on for someone: Toshiba U205, Intel 1.83GHz Core Duo, 1GB RAM, 1 120GB hard drive with two partitions. The first partition is 92161 MB for Windows XP Pro. I rarely use it. The second partition is 22309 MB for FreeBSD. It has 3 slices: The first slice /dev/ad0s2a is the main 22 GB file system. It has the / root mount point and has soft updates turned on. The second slice /dev/ad0s2b is a 1GB SWAP partition. The third slice /dev/ad0s2c is unused. I will continue to test. I am TRYING to narrow it down, it just takes forever. Dan From danallen46 at airwired.net Sat Jun 13 18:41:57 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sat Jun 13 18:42:03 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> Message-ID: On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > Looks like boot(8) is problematic. Okay, here is the June 13th noon update to this problem. I once again installed a May 28th build. Rebuilt world and kernel from source. Everything works great. No custom kernel, just GENERIC. I then merged in just /usr/src/sys/boot/i386/libi386 changes to June 10th. Rebuilt in /usr/src/sys/boot and installed it, no problem. Then I merged in the latest from /usr/src/sys/boot/i386/loader, rebuilt, installed, and BOOM. DEATH TO DRIVE. Disk label GONE again. Hangs after "BIOS drive C: is disk1" at boot. Does not get to memory check, let alone to the "Welcome to FreeBSD and choose a boot option" screen. CULPRIT REVEALED: So, there is only one file change in /usr/src/sys/boot/i386/loader from June 8th to June 10th, which kills my machine very repeatably, and that is the Makefile. Something in /usr/src/sys/boot/i386/loader/Makefile is killing my drive. What do I try next? Thanks for the help. Dan From onemda at gmail.com Sat Jun 13 18:50:33 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Jun 13 18:50:40 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> Message-ID: <3a142e750906131150p6e960400o8a42ab4973aa26e@mail.gmail.com> On 6/13/09, Dan Allen wrote: > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > >> On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: >>> Isn't boot part of the kernel build? Why would installing the kernel >>> not cause this problem? >> >> No, sys/boot is built during world. Likely some change in /boot/ >> loader is >> causing your problem. Can you narrow it down to a specific change >> under >> sys/boot? > > Ok. I updated just the one file since it appeared like one of the few > changed files > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > and rebuilt things with > > cd /usr/src/sys/boot; make cleandir obj depend all install > > and it was okay. No problems. > > Then I did sync'd all of the changed files for /usr/src/sys/boot and > my machine is hung again at boot, so we have narrowed it down to > somewhere in /usr/src/sys/boot/. > > Time to reinstall from a DVD and try it with finer granularity. This > will take some time. > > There appears to be only four files that have changed in /usr/src/sys/ > boot from June 8th (all working fine) to June 11th (dead in the > water). They are: > > /usr/src/sys/boot/Makefile > /usr/src/sys/boot/i386/Makefile > /usr/src/sys/boot/i386/libi386/biosdisk.c I doubt it is loader fault, from your description it appears that loader is never started. Could you try to remove -DLOADER_ZFS_SUPPORT from Makefile? > /usr/src/sys/boot/i386/loader/Makefile > > I have ruled out bisodisk.c, as stated above. > > That means that the Makefiles are building new stuff that previously > was not built, namely > > zfsboot gptzfsboot > > I believe it has to do with that. More help is needed! I am tired of > reinstalling the OS, but I am much more paranoid about updating my > other machine in any way now, as it could erase that whole machine. I > can't believe I am the only one seeing this... > > Dan > > -- Paul From cliftonr at lava.net Sat Jun 13 19:54:54 2009 From: cliftonr at lava.net (Clifton Royston) Date: Sat Jun 13 19:55:01 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: References: Message-ID: <20090613195451.GA15509@lava.net> On Sat, Jun 13, 2009 at 05:45:49PM +0100, Pete French wrote: > I am looking to deploy a couple of hundered system, which are supposed > to attach to a network and be plug-in-and-go. I am thinking of doing > this with a FreeBSD installation, duplicated onto flash cards, and > dumped into some off-the-sheelt hardware. The questions I, what hardware ? > > I've done some research, and come up with boxes like this: > > http://www.icp-epia.co.uk/index.php?act=viewProd&productId=434 > > But I was wondering if anyone knew of any alternatives, preferably > featuring a processor which can run amd64. The rest of thats pec > is fine, and I dont need wifi. I'm not 100% sure, but fairly sure that you'll have a hard time finding something that combines the low-power standalone type spec with a 64-bit capable processor. Once you get the higher-end processor, that draws higher power, and so demands active cooling, a motherboard chipset which also draws higher power, a bigger power supply which becomes a more likely failure point, and so on. Can you elaborate a bit more on which parts of that system spec you really need - do you need the GigE? Two ethernets? The external SATA? > Any suggestions, or words of wisdom from anyone who has done someething > similar themselevs in the past ? Not specifically this, though I've done other embedded work in the past. Several years ago I did research some appliance type setups for a possible spam-filtering appliance based on the VIA Nehemiah CPU; I won't bother you with that info because nowadays the Atom or AMD Geode seem to win in that niche. Besides the frequently mentioned Soekris these guys seem to make some pretty nice low-power systems: http://www.compulab.co.il/all-products/html/products.htm I bought one of these from them last year: http://www.fit-pc.com/new/fit-pc-1-0-specifications.html due to the two Ethernet ports and low power consumption, and put the pfSense package on it (FreeBSD 7.1-based) for a firewall; it runs a packet filtering bridge with DHCP service, Squid, etc. This particular model is out of production now, but the site implies they could do a new run of them for 100 or more units, and there's a newer upgraded model here: http://www.fit-pc.com/new/fit-pc-1-0-specifications.html Note these are both passively cooled and draw around 5w; I think they also come in at about half the price of what you were looking at, if they'll do. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From cliftonr at lava.net Sat Jun 13 19:59:24 2009 From: cliftonr at lava.net (Clifton Royston) Date: Sat Jun 13 19:59:31 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <20090613195451.GA15509@lava.net> References: <20090613195451.GA15509@lava.net> Message-ID: <20090613195922.GB15509@lava.net> Sorry for the self-followup; correcting an incorrect URL. On Sat, Jun 13, 2009 at 09:54:52AM -1000, Clifton Royston wrote: ... > due to the two Ethernet ports and low power consumption, and put the > pfSense package on it (FreeBSD 7.1-based) for a firewall; it runs a > packet filtering bridge with DHCP service, Squid, etc. This particular > model is out of production now, but the site implies they could do a > new run of them for 100 or more units, and there's a newer upgraded > model here: > > http://www.fit-pc.com/new/fit-pc-1-0-specifications.html Should have gone here: http://www.fit-pc.com/new/whats-new.html No business relationship with them, just had a good experience with the (earlier) hardware. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From petefrench at ticketswitch.com Sat Jun 13 20:13:38 2009 From: petefrench at ticketswitch.com (Pete French) Date: Sat Jun 13 20:13:46 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <20090613195451.GA15509@lava.net> Message-ID: > I'm not 100% sure, but fairly sure that you'll have a hard time > finding something that combines the low-power standalone type spec with > a 64-bit capable processor. Once you get the higher-end processor, That was my experiense when shopping around yes - annoying as I don't need anything particularly low power (it ain't going to be my leccy bill :-). > becomes a more likely failure point, and so on. Can you elaborate a > bit more on which parts of that system spec you really need - do you > need the GigE? Two ethernets? The external SATA? It needs to be: 1) Complete as purchased - I dont want to build a machine 2) Capable of having a simple boot device (e.g. CF card) dropped in 3) At least one ether port. 100 meg will do. 4) Small enough to be posted to the end user 5) Cheap - under 400 euros, preferably 300 I do not really care about processor speed, or memory, or power consumption. It needs to run FreeBSD, and I would prefer amd64 as we havent written or used any of our code on 32 bit in a long time, and I would feel uneasy that there might be laten bugs in it if we simply recompiled it for 32 bit. > I bought one of these from them last year: > http://www.fit-pc.com/new/fit-pc-1-0-specifications.html Thanks for the links - thats pretty interesting! I notice the newer ones are also Atom based, so similarly spec'd to what I was looking at, but they may be more suitable. cheers, -pete. From danallen46 at airwired.net Sat Jun 13 20:41:35 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sat Jun 13 20:41:41 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: <3a142e750906131150p6e960400o8a42ab4973aa26e@mail.gmail.com> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <3a142e750906131150p6e960400o8a42ab4973aa26e@mail.gmail.com> Message-ID: On 13 Jun 2009, at 12:50 PM, Paul B. Mahol wrote: > I doubt it is loader fault, from your description it appears that > loader is never started. > > Could you try to remove -DLOADER_ZFS_SUPPORT from Makefile? > >> /usr/src/sys/boot/i386/loader/Makefile BINGO! LOADER_ZFS_SUPPORT is the culprit. I rebuilt the good world, and brought in the loader changes which have caused previously caused death to my drive, then deleted the ZFS_SUPPORT path in /usr/src/sys/boot/i386/loader/Makefile as you recommended, and rebuilt things and everything works fine. Now what do we do? Dan From danallen46 at airwired.net Sat Jun 13 20:53:45 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sat Jun 13 20:53:51 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE Message-ID: I have now proven that the recent post June 8th version of /usr/src/sys/boot/i386/loader/Makefile causes catastrophic data loss. 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. We need to remove -DLOADER_ZFS_SUPPORT from /usr/src/sys/boot/i386/ loader/Makefile immediately. Dan From danallen46 at airwired.net Sat Jun 13 21:03:10 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sat Jun 13 21:04:33 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <3a142e750906131150p6e960400o8a42ab4973aa26e@mail.gmail.com> Message-ID: <4F4C9D30-9B89-469B-A62E-184AA3361813@airwired.net> On 13 Jun 2009, at 2:41 PM, Dan Allen wrote: > > On 13 Jun 2009, at 12:50 PM, Paul B. Mahol wrote: > >> I doubt it is loader fault, from your description it appears that >> loader is never started. >> >> Could you try to remove -DLOADER_ZFS_SUPPORT from Makefile? >> >>> /usr/src/sys/boot/i386/loader/Makefile > > BINGO! LOADER_ZFS_SUPPORT is the culprit. > > I rebuilt the good world, and brought in the loader changes which > have caused previously caused death to my drive, then deleted the > ZFS_SUPPORT path in /usr/src/sys/boot/i386/loader/Makefile as you > recommended, and rebuilt things and everything works fine. My wording may not have been clear: I simply replaced the errant June 10th version of /usr/src/sys/boot/i386/loader/Makefile with the June 8th version of the same file which simply defaults to no LOADER_ZFS_SUPPORT. Dan From rizzo at iet.unipi.it Sat Jun 13 21:50:27 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Jun 13 21:50:35 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: References: <20090613195451.GA15509@lava.net> Message-ID: <20090613213806.GA98400@onelab2.iet.unipi.it> On Sat, Jun 13, 2009 at 09:13:34PM +0100, Pete French wrote: > > I'm not 100% sure, but fairly sure that you'll have a hard time > > finding something that combines the low-power standalone type spec with > > a 64-bit capable processor. Once you get the higher-end processor, > > That was my experiense when shopping around yes - annoying as I > don't need anything particularly low power (it ain't going to > be my leccy bill :-). > > > becomes a more likely failure point, and so on. Can you elaborate a > > bit more on which parts of that system spec you really need - do you > > need the GigE? Two ethernets? The external SATA? > > It needs to be: > > 1) Complete as purchased - I dont want to build a machine > 2) Capable of having a simple boot device (e.g. CF card) dropped in > 3) At least one ether port. 100 meg will do. > 4) Small enough to be posted to the end user > 5) Cheap - under 400 euros, preferably 300 the Asus EEEBox might fit the description. cheers luigi From kmacy at freebsd.org Sat Jun 13 21:50:53 2009 From: kmacy at freebsd.org (Kip Macy) Date: Sat Jun 13 21:51:00 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: Message-ID: <3c1674c90906131450o572cef72tae8e891cf56268ec@mail.gmail.com> On Sat, Jun 13, 2009 at 1:53 PM, Dan Allen 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 From aragon at phat.za.net Sat Jun 13 22:11:14 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Sat Jun 13 22:11:22 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: References: Message-ID: <4A342067.1000603@phat.za.net> Hi, Pete French wrote: >> I'm not 100% sure, but fairly sure that you'll have a hard time >> finding something that combines the low-power standalone type spec with >> a 64-bit capable processor. Once you get the higher-end processor, > > That was my experiense when shopping around yes - annoying as I > don't need anything particularly low power (it ain't going to > be my leccy bill :-). The Atom 230 and 330 are supposed to be 64-bit capable: http://ark.intel.com/Compare.aspx?ids=36331,35635,35641, but I have not personally tested either with an AMD64 FreeBSD install. > It needs to be: > > 1) Complete as purchased - I dont want to build a machine > 2) Capable of having a simple boot device (e.g. CF card) dropped in > 3) At least one ether port. 100 meg will do. > 4) Small enough to be posted to the end user > 5) Cheap - under 400 euros, preferably 300 You might consider something like this: http://www.tranquilpc-shop.co.uk/acatalog/T7-330_Barebones.html Or this which is rack mountable: http://www.tranquilpc-shop.co.uk/acatalog/T2e_300atom_nocd.html Both Atom 330 based and prebuilt. No affiliation with them, but I almost ordered one and found their support to be responsive and helpful. :) Regards, Aragon From kline at thought.org Sat Jun 13 22:34:26 2009 From: kline at thought.org (Gary Kline) Date: Sat Jun 13 22:34:33 2009 Subject: Something since June 8th clobbers my disk... In-Reply-To: References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> Message-ID: <20090613223414.GA28195@thought.org> On Sat, Jun 13, 2009 at 12:41:55PM -0600, Dan Allen wrote: > > On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > > >Looks like boot(8) is problematic. > > Okay, here is the June 13th noon update to this problem. > > I once again installed a May 28th build. Rebuilt world and kernel > from source. Everything works great. No custom kernel, just GENERIC. > > I then merged in just /usr/src/sys/boot/i386/libi386 changes to June > 10th. Rebuilt in /usr/src/sys/boot and installed it, no problem. > > Then I merged in the latest from /usr/src/sys/boot/i386/loader, > rebuilt, installed, and BOOM. DEATH TO DRIVE. Disk label GONE > again. Hangs after "BIOS drive C: is disk1" at boot. Does not get to > memory check, let alone to the "Welcome to FreeBSD and choose a boot > option" screen. > > CULPRIT REVEALED: > So, there is only one file change in /usr/src/sys/boot/i386/loader > from June 8th to June 10th, which kills my machine very repeatably, > and that is the Makefile. > > Something in /usr/src/sys/boot/i386/loader/Makefile is killing my drive. > > What do I try next? > > Thanks for the help. > > Dan I just checked the timestamped on my ....i386/loader/Makefile. The CVS/RCS v that may show you something is from 07jun09: 1.85.2.4 and if you find what changed between your working build on 28may and failing build, that might isolate it. just my dime's worth :-) gary > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org For FBSD list: http://transfinite.thought.org/slicejourney.php The 4.98a release of Jottings: http://jottings.thought.org/index.php From petefrench at ticketswitch.com Sat Jun 13 22:34:50 2009 From: petefrench at ticketswitch.com (Pete French) Date: Sat Jun 13 22:34:57 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <4A342067.1000603@phat.za.net> Message-ID: > http://www.tranquilpc-shop.co.uk/acatalog/T7-330_Barebones.html Now *that* is very much what I am thinking of - OK, I will need to drop in a CF->SATA along with the card, but thats not much hassle. 64 bit and I can add in more RAM than on the other. Thanks, I hadn't realised the new ATonms did 64 bit. -pete. From aragon at phat.za.net Sat Jun 13 22:45:02 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Sat Jun 13 22:45:09 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: References: Message-ID: <4A342BEB.1030300@phat.za.net> Pete French wrote: >> http://www.tranquilpc-shop.co.uk/acatalog/T7-330_Barebones.html > > Now *that* is very much what I am thinking of - OK, I will need to drop > in a CF->SATA along with the card, but thats not much hassle. 64 bit > and I can add in more RAM than on the other. Thanks, I hadn't realised > the new ATonms did 64 bit. No, I don't think you will need a CF->SATA adapter. A simple CF->ATA adapter should do. Those systems just have an Intel GCLF2 board in them, which has both SATA and ATA: http://www.intel.com/products/desktop/motherboards/D945GCLF2-D945GCLF2D/D945GCLF2-D945GCLF2D-overview.htm Best you mail them to confirm though... They're also fanless. :) Regards, Aragon From onemda at gmail.com Sat Jun 13 23:42:20 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Jun 13 23:42:27 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: Message-ID: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> On 6/13/09, Dan Allen wrote: > I have now proven that the recent post June 8th version of > > /usr/src/sys/boot/i386/loader/Makefile > > causes catastrophic data loss. > > 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. I hardly doubt that such change cause loss of data on entire drive. There is always old loader to pick up. > We need to remove -DLOADER_ZFS_SUPPORT from /usr/src/sys/boot/i386/ > loader/Makefile immediately. I don't understand why LOADER_ZFS_SUPPORT is not defined by default on CURRENT. -- Paul From danallen46 at airwired.net Sat Jun 13 23:56:51 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sat Jun 13 23:58:02 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> Message-ID: On 13 Jun 2009, at 5:42 PM, Paul B. Mahol wrote: > On 6/13/09, Dan Allen wrote: >> I have now proven that the recent post June 8th version of >> >> /usr/src/sys/boot/i386/loader/Makefile >> >> causes catastrophic data loss. >> > > I hardly doubt that such change cause loss of data on entire drive. > There is always old loader to pick up. How do I get to the old loader when the machine boots and immediately stops? There is no ability at this point in the boot process to try and get to the old loader that I know of. Is there a hidden magic key combination that allows this? You are correct that the bulk of the file system is not touched, but the key file partitioning headers get cleared and when you boot off of a DVD -- the only way to get to the system that I know of -- and inspect the file partitioning via whatever means you try, it shows that the root partition is gone. What was your main file system is gone. I learned after many installs that I could NOT do a newfs(8) and the setup program would re-mark things and and files ended up re- appearing. My machine was well backed up so no great loss of data in the end, but it has cost me lots of time to get this figured out. For me the real questions are these: * Why is my system the only one that this happens on? * What makes my machine setup different? * What is the bug in the bootable ZFS loader that munges the partition map? Dan From mandrews at bit0.com Sat Jun 13 23:57:55 2009 From: mandrews at bit0.com (Mike Andrews) Date: Sat Jun 13 23:59:30 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <4A342067.1000603@phat.za.net> References: <4A342067.1000603@phat.za.net> Message-ID: On Sat, 13 Jun 2009, Aragon Gouveia wrote: > Hi, > > Pete French wrote: >>> I'm not 100% sure, but fairly sure that you'll have a hard time >>> finding something that combines the low-power standalone type spec with >>> a 64-bit capable processor. Once you get the higher-end processor, >> >> That was my experiense when shopping around yes - annoying as I >> don't need anything particularly low power (it ain't going to >> be my leccy bill :-). > > The Atom 230 and 330 are supposed to be 64-bit capable: > > http://ark.intel.com/Compare.aspx?ids=36331,35635,35641, > > but I have not personally tested either with an AMD64 FreeBSD install. I have a Supermicro 5015A-H on the way, which is a 1U rackmount Atom 330 box, and am planning to run 7.2-STABLE amd64 on it. We'll see how it goes. No flash card slots, so you'd need adapters -- I was just going to use a pair of leftover 2.5" disks I had on the shelf. From danny at cs.huji.ac.il Sun Jun 14 05:53:43 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sun Jun 14 05:53:51 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: References: Message-ID: > > I'm not 100% sure, but fairly sure that you'll have a hard time > > finding something that combines the low-power standalone type spec with > > a 64-bit capable processor. Once you get the higher-end processor, > > That was my experiense when shopping around yes - annoying as I > don't need anything particularly low power (it ain't going to > be my leccy bill :-). > > > becomes a more likely failure point, and so on. Can you elaborate a > > bit more on which parts of that system spec you really need - do you > > need the GigE? Two ethernets? The external SATA? > > It needs to be: > > 1) Complete as purchased - I dont want to build a machine > 2) Capable of having a simple boot device (e.g. CF card) dropped in > 3) At least one ether port. 100 meg will do. > 4) Small enough to be posted to the end user > 5) Cheap - under 400 euros, preferably 300 > > I do not really care about processor speed, or memory, or power > consumption. It needs to run FreeBSD, and I would prefer amd64 > as we havent written or used any of our code on 32 bit in a long > time, and I would feel uneasy that there might be laten bugs in > it if we simply recompiled it for 32 bit. > > > I bought one of these from them last year: > > http://www.fit-pc.com/new/fit-pc-1-0-specifications.html > > Thanks for the links - thats pretty interesting! I notice the newer > ones are also Atom based, so similarly spec'd to what I was > looking at, but they may be more suitable. > > cheers, > > -pete. I've had very good experience with: http://www.pcengines.ch/ danny danny From peterjeremy at optushome.com.au Sun Jun 14 06:19:59 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Jun 14 06:20:06 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> Message-ID: <20090614041615.GA26443@server.vk2pj.dyndns.org> On 2009-Jun-13 17:56:49 -0600, Dan Allen wrote: >How do I get to the old loader when the machine boots and immediately >stops? There is no ability at this point in the boot process to try >and get to the old loader that I know of. Is there a hidden magic key >combination that allows this? See boot(8): There should be a -\|/ spinner for a second at the start of the boot. Hit the "Any" key and you will get a prompt that lets you specify a loader(8) replacement. Assuming you are booting off ad0s1, the magic incantation is 0:ad(0,a)/boot/loader.old -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090614/5c84bffa/attachment.pgp From deischen at freebsd.org Sun Jun 14 07:27:53 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Sun Jun 14 07:28:03 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> Message-ID: On Sat, 13 Jun 2009, Dan Allen wrote: > How do I get to the old loader when the machine boots and immediately stops? > There is no ability at this point in the boot process to try and get to the > old loader that I know of. Is there a hidden magic key combination that > allows this? > > You are correct that the bulk of the file system is not touched, but the key > file partitioning headers get cleared and when you boot off of a DVD -- the > only way to get to the system that I know of -- and inspect the file > partitioning via whatever means you try, it shows that the root partition is > gone. What was your main file system is gone. I learned after many installs > that I could NOT do a newfs(8) and the setup program would re-mark things and > and files ended up re-appearing. > > My machine was well backed up so no great loss of data in the end, but it has > cost me lots of time to get this figured out. > > For me the real questions are these: > > * Why is my system the only one that this happens on? > * What makes my machine setup different? > * What is the bug in the bootable ZFS loader that munges the partition map? >From one of your older emails, you mention you are using ad0s2a as / and ad0s2b as swap, and then say that ad0s2c is unused (I may have the ad0s2 part wrong). But ad0s2c should be the entire slice (or partition depending on the wording you are used to). How about posting a relevent fdisk and disklabel (or gpart show) so we can see what your slices and partitions look like (fdisk /dev/ad0, disklabel /dev/ad0s2). -- DE From bms at incunabulum.net Sun Jun 14 07:59:18 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sun Jun 14 07:59:25 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: References: Message-ID: <4A34ADD1.10406@incunabulum.net> Pete French wrote: > Any suggestions, or words of wisdom from anyone who has done someething > similar themselevs in the past ? > The ASUS EeePC 701 is cheap as chips and can easily be mass-flashed with NanoBSD images from a USB dongle. I wrote a reflash script but didn't release it -- it just takes the USB dongle image and dumps it on the internal SSD with the appropriate fixups. cheers, BMS From RoKlein at roklein.de Sun Jun 14 10:48:12 2009 From: RoKlein at roklein.de (Robert Klein) Date: Sun Jun 14 10:48:20 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <4A34ADD1.10406@incunabulum.net> References: <4A34ADD1.10406@incunabulum.net> Message-ID: Bruce Simpson wrote: > Pete French wrote: >> Any suggestions, or words of wisdom from anyone who has done someething >> similar themselevs in the past ? > > The ASUS EeePC 701 is cheap as chips and can easily be mass-flashed with > NanoBSD images from a USB dongle. However, the EeePC 701's CPU (Celeron M ULV 353) has no AMD64. Same for the Atom N-series (N270, N280) and Z-series (Z5xx). The only AMD64-Atoms are the 230, the 330. The Eee-Box mentioned elsewhere inthe thread uses the N270 CPU as has the Epia in your original post. However, if you like the rest of the hardware you might ook at other nettops, e.g. the Acer Aspire Revo (Atom 230, 2GB Ram, 160 GB hdd) for around 300 euros (including, unfortunately, a windows vista license). Dunno if the system can boot from USB or SD card.... Anyway, check if the ethernet hw works with freebsd. I had no fun with some of the Atom netbooks. Cheers Robert From tj at tjvarghese.com Sun Jun 14 11:19:05 2009 From: tj at tjvarghese.com (TJ Varghese) Date: Sun Jun 14 11:19:13 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <4A342BEB.1030300@phat.za.net> References: <4A342BEB.1030300@phat.za.net> Message-ID: <4A34DB62.40404@tjvarghese.com> Aragon Gouveia wrote: > > No, I don't think you will need a CF->SATA adapter. A simple CF->ATA > adapter should do. Those systems just have an Intel GCLF2 board in > them, which has both SATA and ATA: > > http://www.intel.com/products/desktop/motherboards/D945GCLF2-D945GCLF2D/D945GCLF2-D945GCLF2D-overview.htm > > > Best you mail them to confirm though... > > They're also fanless. :) > Chipset has a fan, however the processor itself is fanless. I've read somewhere that the fan is a weakpoint. Can't personally confirm that since I haven't used it long enough. The GCLF2D is a new revision, slightly cheaper but minus the SVideo-out (iirc), which was found on the earlier GCLF2. SVideo is an unnecessary expense for an appliance anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090614/ac61e47e/smime.bin From aragon at phat.za.net Sun Jun 14 11:27:39 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Sun Jun 14 11:27:46 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <4A34DB62.40404@tjvarghese.com> References: <4A342BEB.1030300@phat.za.net> <4A34DB62.40404@tjvarghese.com> Message-ID: <4A34DEA9.8010509@phat.za.net> TJ Varghese wrote: >> They're also fanless. :) >> > Chipset has a fan, however the processor itself is fanless. I've read You are correct about the Intel GCLF2, however I was talking specifically about the tranquil system. They build their systems to be fanless, so I assume they remove the stock heatsinks/fans. The systems are quite heavy if you look at the specs, so the casing is probably a big heatsink. Regards, Aragon From tj at tjvarghese.com Sun Jun 14 11:38:16 2009 From: tj at tjvarghese.com (TJ Varghese) Date: Sun Jun 14 11:38:24 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <4A342067.1000603@phat.za.net> References: <4A342067.1000603@phat.za.net> Message-ID: <4A34DA2D.1070104@tjvarghese.com> Aragon Gouveia wrote: > Hi, > > Pete French wrote: >>> I'm not 100% sure, but fairly sure that you'll have a hard time >>> finding something that combines the low-power standalone type spec with >>> a 64-bit capable processor. Once you get the higher-end processor, >> >> That was my experiense when shopping around yes - annoying as I >> don't need anything particularly low power (it ain't going to >> be my leccy bill :-). > > The Atom 230 and 330 are supposed to be 64-bit capable: > > http://ark.intel.com/Compare.aspx?ids=36331,35635,35641, > > but I have not personally tested either with an AMD64 FreeBSD install. I've tried the Atom330 (D945GCLF2). It works fine with amd64...however it's rather wasted for 64bit considering it maxes out at 2gb. But I suppose if you wanted to standardize on amd64 installs, this is good. Gigabit - ok, re0. You'll need 7.2 at least. USB - ok SATA - 2 ports tested only with gmirror, ok. Xorg- not tested audio - not tested -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090614/725e6d1d/smime.bin From djv at iki.fi Sun Jun 14 12:04:48 2009 From: djv at iki.fi (Tuomo Latto) Date: Sun Jun 14 12:05:09 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <4A34DEA9.8010509@phat.za.net> References: <4A342BEB.1030300@phat.za.net> <4A34DB62.40404@tjvarghese.com> <4A34DEA9.8010509@phat.za.net> Message-ID: <4A34E4C5.3090604@iki.fi> Aragon Gouveia wrote: > TJ Varghese wrote: >>> They're also fanless. :) >>> >> Chipset has a fan, however the processor itself is fanless. I've read > > You are correct about the Intel GCLF2, however I was talking > specifically about the tranquil system. They build their systems to be > fanless, so I assume they remove the stock heatsinks/fans. The systems > are quite heavy if you look at the specs, so the casing is probably a > big heatsink. Tom's Hardware had an interesting article last year: http://www.tomshardware.com/reviews/Atom-Athlon-Efficient,1997.html I'd like to see what current processors can achieve. -- Tuomo ... The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry. -- Henry Petroski From petefrench at ticketswitch.com Sun Jun 14 12:06:05 2009 From: petefrench at ticketswitch.com (Pete French) Date: Sun Jun 14 12:06:12 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: <4A34DA2D.1070104@tjvarghese.com> Message-ID: > I've tried the Atom330 (D945GCLF2). It works fine with amd64...however > it's rather wasted for 64bit considering it maxes out at 2gb. But I > suppose if you wanted to standardize on amd64 installs, this is good. Size of memory doesnt bother me really - I made the move to amd64 because of the extra performance due to the extra registers (about 8% on my application, I realise that not everyone gets a speedup). Given the fact I am also moving to ZFS, and that works a lot better on amd64, then I am not keen to go back ;-) > Gigabit - ok, re0. You'll need 7.2 at least. > USB - ok > SATA - 2 ports tested only with gmirror, ok. Those three are very good to know work - the box will be headless, so I just need ether and booting to work fine. Am always wary of re0 ethernets as have been bitten in the past. Thanks for all the advice from eeryone in this thread - I have narrowed the choice down to either the Tranquil PC unit, or the Shuttle X27D, which is also Atom 330 based. Given the price I may simply buy one of each and evaluate which is better. Will report back if so. cheers, -pete. From mgass at unix.csbsju.edu Sun Jun 14 12:48:25 2009 From: mgass at unix.csbsju.edu (Michael Gass) Date: Sun Jun 14 12:48:32 2009 Subject: Why old files in /etc ? Message-ID: <20090614123323.GA1085@unix.csbsju.edu> Just installed 7.2-release in an old Pavilion 4455 (PII, 256M) and it runs great. Csuped src and ports and rebuilt world and generic kernel for 7.2-stable and that went well. My question is why are the files in /etc in 7.2-stable older versions (generally) than in 7.2-release? I do not just mean older by date, but older versions of the files - like many of the config files for sendmail or the net. Why is stable using older versions of these files than release? Mostly I did not let mergemaster install the files from the build because they were so much older than the original release versions. Again, why are the files for stable so much older? Thanks, Mike Gass From sonic2000gr at gmail.com Sun Jun 14 13:14:58 2009 From: sonic2000gr at gmail.com (Manolis Kiagias) Date: Sun Jun 14 13:15:05 2009 Subject: reecommendations for an 'appliance" platform ? In-Reply-To: References: Message-ID: <4A34F271.1000000@gmail.com> Pete French wrote: >> I've tried the Atom330 (D945GCLF2). It works fine with amd64...however >> it's rather wasted for 64bit considering it maxes out at 2gb. But I >> suppose if you wanted to standardize on amd64 installs, this is good. >> > > Size of memory doesnt bother me really - I made the move to amd64 because > of the extra performance due to the extra registers (about 8% on my > application, I realise that not everyone gets a speedup). Given the > fact I am also moving to ZFS, and that works a lot better on amd64, then > I am not keen to go back ;-) > > >> Gigabit - ok, re0. You'll need 7.2 at least. >> USB - ok >> SATA - 2 ports tested only with gmirror, ok. >> > > Those three are very good to know work - the box will be headless, so I > just need ether and booting to work fine. Am always wary of re0 ethernets > as have been bitten in the past. > > Thanks for all the advice from eeryone in this thread - I have narrowed > the choice down to either the Tranquil PC unit, or the Shuttle X27D, > which is also Atom 330 based. Given the price I may simply buy one of each > and evaluate which is better. Will report back if so. > > I own the X27D, in fact I am typing this from it. It works reasonably well with FreeBSD (I am using 7.2/i386). The ethernet card (100Mbit), USB , SATA, audio, Xorg all work fine. You will only need this in sysctl.conf: hw.acpi.thermal.polling_rate=0 otherwise you will be flooded with messages about weird temperatures. There is a single 40mm fan in the chipset, and in my system it failed about after a week of continuous operation. As it wasn't noisy it took a couple of hours until I realized it. You may wish to replace it with a better quality fan. This will probably work ok with AMD64 too, though with 2G of RAM I had no real reason to try. From jilles at stack.nl Sun Jun 14 14:07:03 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sun Jun 14 14:07:10 2009 Subject: Why old files in /etc ? In-Reply-To: <20090614123323.GA1085@unix.csbsju.edu> References: <20090614123323.GA1085@unix.csbsju.edu> Message-ID: <20090614140631.GA50127@stack.nl> On Sun, Jun 14, 2009 at 07:33:23AM -0500, Michael Gass wrote: > Just installed 7.2-release in an old Pavilion 4455 (PII, 256M) > and it runs great. Csuped src and ports and rebuilt world and > generic kernel for 7.2-stable and that went well. > My question is why are the files in /etc in 7.2-stable older > versions (generally) than in 7.2-release? I do not just mean > older by date, but older versions of the files - like many of > the config files for sendmail or the net. Why is stable using > older versions of these files than release? > Mostly I did not let mergemaster install the files from the build > because they were so much older than the original release versions. > Again, why are the files for stable so much older? This is because of a weakness in the svn-to-cvs exporter. Formerly, only CVS was used and tagging a release did not require a commit. So right after a release, both the release and -stable would have the same revision numbers. With Subversion, tagging a release requires a commit. The CVS exporter keeps this commit, so all files will have a changed CVS Id. This looks newer, until/unless the file is changed on -stable again. To cope with this, it's best to use mergemaster's -F or -U options. This question has been asked before. -- Jilles Tjoelker From wblock at wonkity.com Sun Jun 14 14:36:59 2009 From: wblock at wonkity.com (Warren Block) Date: Sun Jun 14 14:37:06 2009 Subject: Why old files in /etc ? In-Reply-To: <20090614123323.GA1085@unix.csbsju.edu> References: <20090614123323.GA1085@unix.csbsju.edu> Message-ID: On Sun, 14 Jun 2009, Michael Gass wrote: > Just installed 7.2-release in an old Pavilion 4455 (PII, 256M) > and it runs great. Csuped src and ports and rebuilt world and > generic kernel for 7.2-stable and that went well. > > My question is why are the files in /etc in 7.2-stable older > versions (generally) than in 7.2-release? I do not just mean > older by date, but older versions of the files - like many of > the config files for sendmail or the net. Why is stable using > older versions of these files than release? > > Mostly I did not let mergemaster install the files from the build > because they were so much older than the original release versions. > Again, why are the files for stable so much older? Here's part of a thread we had earlier this year: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=253390+0+archive/2009/freebsd-stable/20090301.freebsd-stable -Warren Block * Rapid City, South Dakota USA From dan.naumov at gmail.com Sun Jun 14 16:17:58 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Sun Jun 14 16:18:06 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: Hello list. I just wanted to have an extra pair (or a dozen) of eyes look this configuration over before I commit to it (tested it in VMWare just in case, it works, so I am considering doing this on real hardware soon). I drew a nice diagram: http://www.pastebin.ca/1460089 Since it doesnt show on the diagram, let me clarify that the geom mirror consumers as well as the vdevz for ZFS RAIDZ are going to be partitions (raw disk => full disk slice => swap partition | mirror provider partition | zfs vdev partition | unused. Is there any actual downside to having a 5-way mirror vs a 2-way or a 3-way one? - Sincerely, Dan Naumov From cmdlnkid at gmail.com Sun Jun 14 17:11:02 2009 From: cmdlnkid at gmail.com (CmdLnKid) Date: Sun Jun 14 17:11:10 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> Message-ID: On Sat, 13 Jun 2009 19:56 -0000, danallen46 wrote: > > On 13 Jun 2009, at 5:42 PM, Paul B. Mahol wrote: > >> On 6/13/09, Dan Allen wrote: >>> I have now proven that the recent post June 8th version of >>> >>> /usr/src/sys/boot/i386/loader/Makefile >>> >>> causes catastrophic data loss. >>> >> >> I hardly doubt that such change cause loss of data on entire drive. >> There is always old loader to pick up. > > How do I get to the old loader when the machine boots and immediately stops? > There is no ability at this point in the boot process to try and get to the > old loader that I know of. Is there a hidden magic key combination that > allows this? > > You are correct that the bulk of the file system is not touched, but the key > file partitioning headers get cleared and when you boot off of a DVD -- the > only way to get to the system that I know of -- and inspect the file > partitioning via whatever means you try, it shows that the root partition is > gone. What was your main file system is gone. I learned after many installs > that I could NOT do a newfs(8) and the setup program would re-mark things and > and files ended up re-appearing. > > My machine was well backed up so no great loss of data in the end, but it has > cost me lots of time to get this figured out. > > For me the real questions are these: > > * Why is my system the only one that this happens on? > * What makes my machine setup different? > * What is the bug in the bootable ZFS loader that munges the partition map? > > Dan > Is it possible that you have most likely been playing around with ZFS before this and left some of the configurations of ZFS embedded in your drive and the loader is picking that up. -- Sincerely, -- Jason H. ;; Networked Systems Engineering. The Command Line Kid. ;; Multi-user Systems Advocate. mailto:gmail.com!cmdlnkid ;; 1(616)403-XXXX / BSD Group. - (2^(N-1)) From danallen46 at airwired.net Sun Jun 14 19:01:33 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sun Jun 14 19:01:39 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> Message-ID: <2306D409-3B82-404E-AE46-AA9CD761D78F@airwired.net> On 14 Jun 2009, at 10:38 AM, CmdLnKid wrote: > Is it possible that you have most likely been playing around with ZFS > before this and left some of the configurations of ZFS embedded in > your > drive and the loader is picking that up. No, I have never used ZFS. The drive is partitioned and the first partition has Windows XP Pro on it, so I assume that this may be the problem. Dan From alson+ml at alm.flutnet.org Sun Jun 14 22:07:50 2009 From: alson+ml at alm.flutnet.org (Alson van der Meulen) Date: Sun Jun 14 22:07:57 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: <20090614215142.GA32937@tafi.alm.flutnet.org> * Dan Naumov [2009-06-14 18:17]: > I just wanted to have an extra pair (or a dozen) of eyes look this > configuration over before I commit to it (tested it in VMWare just in > case, it works, so I am considering doing this on real hardware soon). > I drew a nice diagram: http://www.pastebin.ca/1460089 Looks fine to me. Note that your swap doesn't have any redundancy, so if you lose a disk, the kernel will likely panic as soon as it hits any swap (the swap space is striped across the disks), this is something you can easily test in a VM. The kernel will only use four swap devices by default. I would put the swap on gmirror. Swap performance is rarely critical (if you're hitting swap often you should buy more RAM), and if you have 2TB disks, a few extra gigabytes less is not an issue (I usually make swap slightly larger than RAM for crash dumps, sometimes twice that if I plan to add RAM later). > Is there any actual downside to having a 5-way mirror vs a 2-way or a 3-way one? Write performance is slightly slower than a single disk (you have to wait for all five disks to finish), but these partitions are rarely performance-critical. Depending on your workload, it may be an issue for /var (databases, logs, mail), but you could always move that data to a ZFS filesystem. It should be fine for a file server. Any other solution would just add more complexity. Alson From danallen46 at airwired.net Sun Jun 14 22:27:37 2009 From: danallen46 at airwired.net (Dan Allen) Date: Sun Jun 14 22:27:44 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> Message-ID: <1407C6EC-873D-49AB-9F8C-6A4A6FFA9DC3@airwired.net> On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote: > From one of your older emails, you mention you are using > ad0s2a as / and ad0s2b as swap, and then say that ad0s2c > is unused (I may have the ad0s2 part wrong). But ad0s2c > should be the entire slice (or partition depending on > the wording you are used to). > > How about posting a relevent fdisk and disklabel (or > gpart show) so we can see what your slices and partitions > look like (fdisk /dev/ad0, disklabel /dev/ad0s2). ad0s2c is the entire slice as you thought it should be. Here is fdisk and bsdlabel /dev/ad0s2: ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 188747622 (92161 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 10/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 188747685, size 45688860 (22309 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 14/ sector 63 The data for partition 3 is: The data for partition 4 is: # /dev/ad0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 43591708 2097152 4.2BSD 0 0 0 b: 2097152 0 swap c: 45688860 0 unused 0 0 # "raw" part, don't edit From deischen at freebsd.org Sun Jun 14 23:08:57 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Sun Jun 14 23:09:04 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: <1407C6EC-873D-49AB-9F8C-6A4A6FFA9DC3@airwired.net> References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> <1407C6EC-873D-49AB-9F8C-6A4A6FFA9DC3@airwired.net> Message-ID: On Sun, 14 Jun 2009, Dan Allen wrote: > > On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote: > >> From one of your older emails, you mention you are using >> ad0s2a as / and ad0s2b as swap, and then say that ad0s2c >> is unused (I may have the ad0s2 part wrong). But ad0s2c >> should be the entire slice (or partition depending on >> the wording you are used to). >> >> How about posting a relevent fdisk and disklabel (or >> gpart show) so we can see what your slices and partitions >> look like (fdisk /dev/ad0, disklabel /dev/ad0s2). > > ad0s2c is the entire slice as you thought it should be. > > Here is fdisk and bsdlabel /dev/ad0s2: > > ******* Working on device /dev/ad0 ******* > parameters extracted from in-core disklabel are: > cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) > > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) > start 63, size 188747622 (92161 Meg), flag 0 > beg: cyl 0/ head 1/ sector 1; > end: cyl 1023/ head 10/ sector 63 > The data for partition 2 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 188747685, size 45688860 (22309 Meg), flag 80 (active) > beg: cyl 1023/ head 255/ sector 63; > end: cyl 1023/ head 14/ sector 63 > The data for partition 3 is: > > The data for partition 4 is: > > > > > # /dev/ad0s2: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 43591708 2097152 4.2BSD 0 0 0 > b: 2097152 0 swap > c: 45688860 0 unused 0 0 # "raw" part, don't > edit Seems weird to see swap at offset 0 and partition a after swap. I wonder if that is screwing things up. And shouldn't the offset for your first slice start at offset 188747685 (from fdisk)? This is from my system: $ fdisk /dev/ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 6 (0x06),(Primary DOS, 16 bit FAT (>= 32MB)) start 63, size 20964762 (10236 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 20964825, size 135331560 (66079 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: The data for partition 4 is: $ disklabel /dev/ad0s2 # /dev/ad0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 20964825 4.2BSD 2048 16384 28552 b: 4194304 23061977 swap c: 135331560 20964825 unused 0 0 d: 4194304 27256281 4.2BSD 2048 16384 28552 e: 4194304 31450585 4.2BSD 2048 16384 28552 f: 16777216 35644889 4.2BSD 2048 16384 28552 g: 103874280 52422105 4.2BSD 2048 16384 28536 -- DE From danallen46 at airwired.net Mon Jun 15 02:08:13 2009 From: danallen46 at airwired.net (Dan Allen) Date: Mon Jun 15 02:08:21 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> <1407C6EC-873D-49AB-9F8C-6A4A6FFA9DC3@airwired.net> Message-ID: On 14 Jun 2009, at 5:08 PM, Daniel Eischen wrote: > On Sun, 14 Jun 2009, Dan Allen wrote: > >> # /dev/ad0s2: >> 8 partitions: >> # size offset fstype [fsize bsize bps/cpg] >> a: 43591708 2097152 4.2BSD 0 0 0 >> b: 2097152 0 swap >> c: 45688860 0 unused 0 0 # "raw" part, >> don't edit > > Seems weird to see swap at offset 0 and partition a after swap. > I wonder if that is screwing things up. And shouldn't the offset > for your first slice start at offset 188747685 (from fdisk)? Interesting insights. I forgot to mention that there may be some discrepancies that are a remnant of reinstalling the OS many times. (Now I know I could have used the loader.old trick...) Anyway, while doing this a dozen times in a couple of days I learned that I could speed things by not doing newfs(8) each time, so the fsize and bsize fields are definitely messed up. Yet things seem to work fine. Weird. My next experiment is to redo the disk entirely. Dan From fjwcash at gmail.com Mon Jun 15 02:16:58 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Mon Jun 15 02:17:05 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: On Sun, Jun 14, 2009 at 9:17 AM, Dan Naumov wrote: > I just wanted to have an extra pair (or a dozen) of eyes look this > configuration over before I commit to it (tested it in VMWare just in > case, it works, so I am considering doing this on real hardware soon). > I drew a nice diagram: http://www.pastebin.ca/1460089 Since it doesnt > show on the diagram, let me clarify that the geom mirror consumers as > well as the vdevz for ZFS RAIDZ are going to be partitions (raw disk > => full disk slice => swap partition | mirror provider partition | zfs > vdev partition | unused. I don't know for sure if it's the same on FreeBSD, but on Solaris, ZFS will disable the onboard disk cache if the vdevs are not whole disks. IOW, if you use slices, partitions, or files, the onboard disk cache is disabled. This can lead to poor write performance. Unless you can use one of the ZFS-on-root facilities, I'd look into getting a couple of CompactFlash or USB sticks to use for the gmirror for / and /usr (put the rest on ZFS). Then you can dedicate the entirety of all 5 drives to ZFS. -- Freddie Cash fjwcash@gmail.com From emikulic at gmail.com Mon Jun 15 04:41:58 2009 From: emikulic at gmail.com (Emil Mikulic) Date: Mon Jun 15 04:42:05 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: <20090615041359.GA45187@dmr.ath.cx> On Sun, Jun 14, 2009 at 07:16:52PM -0700, Freddie Cash wrote: > I don't know for sure if it's the same on FreeBSD, but on Solaris, ZFS will > disable the onboard disk cache if the vdevs are not whole disks. pjd@ has stated in the past that this doesn't apply to FreeBSD: http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042734.html From fjwcash at gmail.com Mon Jun 15 05:00:01 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Mon Jun 15 05:00:08 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: <20090615041359.GA45187@dmr.ath.cx> References: <20090615041359.GA45187@dmr.ath.cx> Message-ID: On Sun, Jun 14, 2009 at 9:13 PM, Emil Mikulic wrote: > On Sun, Jun 14, 2009 at 07:16:52PM -0700, Freddie Cash wrote: > > I don't know for sure if it's the same on FreeBSD, but on Solaris, ZFS > will > > disable the onboard disk cache if the vdevs are not whole disks. > > pjd@ has stated in the past that this doesn't apply to FreeBSD: > http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042734.html > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Nice. Thanks for that. -- Freddie Cash fjwcash@gmail.com From dan.naumov at gmail.com Mon Jun 15 06:31:55 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Mon Jun 15 06:32:01 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: The main reason for NOT using zfs directly on raw disks is the fact that you cannot replace a vdev in a pool with a smaller one, only with one of equal size or bigger. This leads to a problem: if you are a regular Joe User (and not a company buying certified hardware from a specific vendor) and want to replace one of the disks in your pool. The new 2tb disk you buy can very often be actually a few sectors smaller then the disk you are trying to replace, this in turn will lead to zfs not accepting the new disk as a replacement, because it's smaller (no matter how small). Using zfs on partitions instead and keeping a few gb unused on each disk leaves us with some room to play and be able to avoid this issue. - Dan Naumov On Mon, Jun 15, 2009 at 5:16 AM, Freddie Cash wrote: > I don't know for sure if it's the same on FreeBSD, but on Solaris, ZFS will > disable the onboard disk cache if the vdevs are not whole disks. ?IOW, if > you use slices, partitions, or files, the onboard disk cache is disabled. > This can lead to poor write performance. From petefrench at ticketswitch.com Mon Jun 15 07:48:06 2009 From: petefrench at ticketswitch.com (Pete French) Date: Mon Jun 15 07:48:14 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: Message-ID: > The new 2tb disk you buy can very often be actually a few sectors > smaller then the disk you are trying to replace, this in turn will > lead to zfs not accepting the new disk as a replacement, because it's > smaller (no matter how small). Heh - you are in for a pleasent surprise my friend! ;-) If you actually try this in practice you will find ZFS *does* accept a smaller drive as a replacement. Preseumably to cope with the natural variability in sector size that you describe. Surprised me too the first time I saw it... -pete. From dan.naumov at gmail.com Mon Jun 15 08:02:57 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Mon Jun 15 08:03:05 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: If this is true, some magic has been done to the FreeBSD port of ZFS, because according to SUN documentation is is definitely not supposed to be possible. - Dan Naumov On Mon, Jun 15, 2009 at 10:48 AM, Pete French wrote: >> The new 2tb disk you buy can very often be actually a few sectors >> smaller then the disk you are trying to replace, this in turn will >> lead to zfs not accepting the new disk as a replacement, because it's >> smaller (no matter how small). > > Heh - you are in for a pleasent surprise my friend! ;-) If you actually > try this in practice you will find ZFS *does* accept a smaller drive as > a replacement. Preseumably to cope with the natural variability in sector > size that you describe. > > Surprised me too the first time I saw it... > > -pete. > From petefrench at ticketswitch.com Mon Jun 15 08:35:22 2009 From: petefrench at ticketswitch.com (Pete French) Date: Mon Jun 15 08:35:29 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: Message-ID: > If this is true, some magic has been done to the FreeBSD port of ZFS, > because according to SUN documentation is is definitely not supposed > to be possible. I just tried it again to make sure I wasn't imagining things - you can give it a shot yourself using mdconfig to create some drives. It will let me drop in a replacement up to about 64k smaller than the original with no problems. Below that and it refuses saying the drive is too small. -pete. From dan.naumov at gmail.com Mon Jun 15 08:39:42 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Mon Jun 15 08:39:49 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: Haven't had time to test (stuck at work), but I will trust your word :) Well, this sounds nice and sensible. I am curious though if there have been any numbers regarding how much do "actual" drive sizes vary in the real world when it comes to disks of same manufacturer/model/size. I guess this probably varies from manufacturer to manufacturer, but some average estimates would be nice, just so that one could evaluate whether this 64k barrier is enough. - Dan Naumov On Mon, Jun 15, 2009 at 11:35 AM, Pete French wrote: >> If this is true, some magic has been done to the FreeBSD port of ZFS, >> because according to SUN documentation is is definitely not supposed >> to be possible. > > I just tried it again to make sure I wasn't imagining things - you > can give it a shot yourself using mdconfig to create some drives. It > will let me drop in a replacement up to about 64k smaller than the original > with no problems. Below that and it refuses saying the drive is too > small. > > -pete. > From pluknet at gmail.com Mon Jun 15 08:49:08 2009 From: pluknet at gmail.com (pluknet) Date: Mon Jun 15 08:49:15 2009 Subject: lockup on 6.4 while bce in MGETHDR Message-ID: Hi. This is on 6.4-S as of April with uptime about 2 months. Machine could not be accessed via network, didn't reply on ping. Looking at backtrace it's here: if_bce.c::bce_get_buf(): /* This is a new mbuf allocation. */ MGETHDR(m_new, M_DONTWAIT, MT_DATA); >From brk-seq: db> bt Tracing pid 31 tid 100034 td 0xc833ad00 kdb_enter(c097ef95) at kdb_enter+0x2b siointr1(c83a3c00) at siointr1+0xce siointr(c83a3c00) at siointr+0x5e intr_execute_handlers(c80ee4c8,e8963abc,4,e8963b0c,c08cba63,...) at intr_execute_handlers+0xe1 lapic_handle_intr(38) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc06a393e, esp = 0xe8963b00, ebp = 0xe8963b0c --- _mtx_lock_sleep(c0a655c0,c833ad00,0,0,0) at _mtx_lock_sleep+0xb6 kmem_malloc(c14680c0,1000,101,e8963b8c,c082cadd,...) at kmem_malloc+0x328 page_alloc(c1456000,1000,e8963b7f,101,c8b10016,...) at page_alloc+0x1a slab_zalloc(c1456000,101,0,d278ca90,c915aa3c,...) at slab_zalloc+0xdd uma_zone_slab(c1456000,1) at uma_zone_slab+0xf0 uma_zalloc_bucket(c1456000,1) at uma_zalloc_bucket+0x15c uma_zalloc_arg(c1456000,d0729e00,1) at uma_zalloc_arg+0x292 bce_get_buf(c8363000,0,e8963c7c,e8963c7e,e8963c80) at bce_get_buf+0xef bce_fill_rx_chain(c8363000,7047,d0729000,cbd86000,59375b37,...) at bce_fill_rx_chain+0x48 bce_rx_intr(c8363000) at bce_rx_intr+0x301 bce_intr(c8363000) at bce_intr+0xf4 ithread_execute_handlers(c8337c90,c8230a80) at ithread_execute_handlers+0x125 ithread_loop(c835f860,e8963d38) at ithread_loop+0x55 fork_exit(c0694a38,c835f860,e8963d38) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe8963d6c, ebp = 0 --- db> ps pid ppid pgrp uid state wmesg wchan cmd 17102 17100 15549 0 L *vm page 0xcce93480 awk 17101 17100 15549 0 L *Giant 0xc8737480 grep 17100 17098 15549 0 S wait 0xc8726a78 sh 17098 15570 15549 0 S wait 0xc98c2a78 sh 16935 30771 30771 8382 RL httpd 16656 16349 16349 10346 S biord 0xdc389368 php 16564 16460 16460 18332 SL vmpfw 0xc365da98 lynx 16563 16351 16351 18332 LL *vm page 0xcce93480 lynx 16460 16451 16460 18332 Ss wait 0xc8ebb218 bash 16451 11589 11589 18332 S piperd 0xd264a198 crond 16360 16345 16345 37174 SL vnread 0xdc14e7f0 php 16351 16343 16351 18332 Ss wait 0xc9236c90 bash 16349 16340 16349 10346 Ss wait 0xce3f3218 bash 16345 16337 16345 37174 Ss wait 0xcf6b1860 bash 16343 11589 11589 18332 S piperd 0xca389990 crond 16340 11589 11589 10346 S piperd 0xcce447f8 crond 16337 11589 11589 37174 S piperd 0xcc6fb198 crond 15996 37504 37504 27220 S select 0xc0a56dc4 httpd 15611 15608 15561 0 S piperd 0xd222f4c8 awk -- wbr, pluknet From petefrench at ticketswitch.com Mon Jun 15 08:57:42 2009 From: petefrench at ticketswitch.com (Pete French) Date: Mon Jun 15 08:57:50 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: Message-ID: > Haven't had time to test (stuck at work), but I will trust your word > :) Well, this sounds nice and sensible. I am curious though if there It's good isn't it ? I just did another test, replacing both drives wuth smaller ones, and you can't then recursively add an even smaller one in :-) If you were wondering why I tried that, I just wanted to make sure it wasn't an off-by-one error somewhere letting it happen. I guess it encodes a 'minimum size' for the drives. > have been any numbers regarding how much do "actual" drive sizes vary > in the real world when it comes to disks of same > manufacturer/model/size. I guess this probably varies from In my expereince all the ones from the same manufacturer and model are exactly the same size. Admittedly I only ever buy SCSI, but that shouldnt make too much difference should it ? -pete. From pluknet at gmail.com Mon Jun 15 11:29:26 2009 From: pluknet at gmail.com (pluknet) Date: Mon Jun 15 11:29:33 2009 Subject: coretemp(4) lockups on 6-stable Message-ID: This is 6.4-stable from April. System locks up while in `sysctl dev.cpu` (with coretemp kldloaded). So as far as I understand sched_bind() binds an executing thread to nonexistent CPU 255. Same behavior on coretemp built on 6.2. db> ps pid ppid pgrp uid state wmesg wchan cmd 34381 34380 34381 0 R+ CPU 255 sysctl [...] db> bt 34381 Tracing pid 34381 tid 100166 td 0xc8634680 sched_switch(c8634680,0,1) at sched_switch+0x143 mi_switch(1,0,c86347e0,4,c0a4e510,...) at mi_switch+0x1ba sched_bind(c8634680,4,c856f3b0,0,c0836b3b,...) at sched_bind+0x52 coretemp_get_temp_sysctl(c8ef56c0,c908c200,0,eebebc04,c8ef56c0,...) at coretemp_get_temp_sysctl+0x47 sysctl_root(0,eebebc74,4,eebebc04) at sysctl_root+0x107 userland_sysctl(c8634680,eebebc74,4,0,bfbfda8c,0,0,0,eebebc70,0) at userland_sysctl+0x112 __sysctl(c8634680,eebebd04) at __sysctl+0x93 syscall(3b,3b,3b,4,bfbfda8c,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2812407b, esp = 0xbfbfd9fc, ebp = 0xbfbfda38 --- static int coretemp_get_temp(device_t dev) { uint64_t msr; int temp; int cpu = device_get_unit(dev); struct coretemp_softc *sc = device_get_softc(dev); char stemp[16]; mtx_lock_spin(&sched_lock); sched_bind(curthread, cpu); ^^^ mtx_unlock_spin(&sched_lock); -- wbr, pluknet From pluknet at gmail.com Mon Jun 15 12:23:50 2009 From: pluknet at gmail.com (pluknet) Date: Mon Jun 15 12:23:57 2009 Subject: coretemp(4) lockups on 6-stable In-Reply-To: References: Message-ID: 2009/6/15 pluknet : > This is 6.4-stable from April. > > System locks up while in `sysctl dev.cpu` (with coretemp kldloaded). Small follow-up: Just one of my wild guesses is that coretemp doesn't play nice with ncpu > 4. A problem box is 8-way cpu. I always observe this lockup when sched_bind(curthread, cpu) called with cpu==4. While on another box `sysctl dev.cpu` works good and that box have only 4 cpu cores. > > So as far as I understand sched_bind() binds an executing thread to > nonexistent CPU 255. > Same behavior on coretemp built on 6.2. > > db> ps > ?pid ?ppid ?pgrp ? uid ? state ? wmesg ? ? wchan ? ?cmd > 34381 34380 34381 ? ? 0 ?R+ ? ? ?CPU 255 ? ? ? ? ? ? sysctl > [...] > db> bt 34381 > Tracing pid 34381 tid 100166 td 0xc8634680 > sched_switch(c8634680,0,1) at sched_switch+0x143 > mi_switch(1,0,c86347e0,4,c0a4e510,...) at mi_switch+0x1ba > sched_bind(c8634680,4,c856f3b0,0,c0836b3b,...) at sched_bind+0x52 > coretemp_get_temp_sysctl(c8ef56c0,c908c200,0,eebebc04,c8ef56c0,...) at > coretemp_get_temp_sysctl+0x47 > sysctl_root(0,eebebc74,4,eebebc04) at sysctl_root+0x107 > userland_sysctl(c8634680,eebebc74,4,0,bfbfda8c,0,0,0,eebebc70,0) at > userland_sysctl+0x112 > __sysctl(c8634680,eebebd04) at __sysctl+0x93 > syscall(3b,3b,3b,4,bfbfda8c,...) at syscall+0x2bf > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2812407b, esp = > 0xbfbfd9fc, ebp = 0xbfbfda38 --- > > static int > coretemp_get_temp(device_t dev) > { > ? ? ? ?uint64_t msr; > ? ? ? ?int temp; > ? ? ? ?int cpu = device_get_unit(dev); > ? ? ? ?struct coretemp_softc *sc = device_get_softc(dev); > ? ? ? ?char stemp[16]; > > ? ? ? ?mtx_lock_spin(&sched_lock); > ? ? ? ?sched_bind(curthread, cpu); > ? ? ? ? ^^^ > ? ? ? ?mtx_unlock_spin(&sched_lock); > > > -- > wbr, > pluknet > -- wbr, pluknet From ps at freebsd.org Mon Jun 15 15:00:15 2009 From: ps at freebsd.org (Paul Saab) Date: Mon Jun 15 15:00:47 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> <1407C6EC-873D-49AB-9F8C-6A4A6FFA9DC3@airwired.net> Message-ID: <5c0ff6a70906150736i4ee21acbh8b78cddd15f25e27@mail.gmail.com> I just merged a change from current to libstand which increases the number of open file descriptors. This could be what was causing your problems. Can you test it out with the latest RELENG_7? On Sun, Jun 14, 2009 at 7:08 PM, Dan Allen wrote: > > On 14 Jun 2009, at 5:08 PM, Daniel Eischen wrote: > > On Sun, 14 Jun 2009, Dan Allen wrote: >> >> # /dev/ad0s2: >>> 8 partitions: >>> # size offset fstype [fsize bsize bps/cpg] >>> a: 43591708 2097152 4.2BSD 0 0 0 >>> b: 2097152 0 swap >>> c: 45688860 0 unused 0 0 # "raw" part, don't >>> edit >>> >> >> Seems weird to see swap at offset 0 and partition a after swap. >> I wonder if that is screwing things up. And shouldn't the offset >> for your first slice start at offset 188747685 (from fdisk)? >> > > Interesting insights. > > I forgot to mention that there may be some discrepancies that are a remnant > of reinstalling the OS many times. (Now I know I could have used the > loader.old trick...) > > Anyway, while doing this a dozen times in a couple of days I learned that I > could speed things by not doing newfs(8) each time, so the fsize and bsize > fields are definitely messed up. Yet things seem to work fine. Weird. > > My next experiment is to redo the disk entirely. > > Dan > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From nakal at web.de Mon Jun 15 15:19:46 2009 From: nakal at web.de (Martin) Date: Mon Jun 15 15:19:53 2009 Subject: Panic on 7.2-p1 i386 Message-ID: <20090615171939.6bb955f1@zelda.local> Hi, the custom kernel, I've built on my home router catched a panic today. I don't have any dump, because swap is encrypted. I've got some information written by hand... I hope it helps a bit. fault virtual address = 0xa fault code = supervisor read, page not present instruction pointer = 0x20:0xc07834 stack pointer = 0x28:0xc39aab50 frame pointer = 0x28:0xc39aab6c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (idle: cpu0) Stopped at md_get_mem+0xf: mov 0x4(%eax),%ebx eax = 0x6 ebx = 0xc0714907 ds = sc_buffer.9247+0xe708 Stack trace: md_get_mem md_get_uint32 md_get_uint32le tc_ticktock hardlock uname -a: FreeBSD epona.local 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #1: Wed Jun 10 20:22:30 CEST 2009 root@epona.local:/usr/obj/usr/src/sys/EPONA i386 -- Martin From hartzell at alerce.com Mon Jun 15 15:47:46 2009 From: hartzell at alerce.com (George Hartzell) Date: Mon Jun 15 15:47:55 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: <18998.27937.780804.279674@already.local> Freddie Cash writes: > On Sun, Jun 14, 2009 at 9:17 AM, Dan Naumov wrote: > > > I just wanted to have an extra pair (or a dozen) of eyes look this > > configuration over before I commit to it (tested it in VMWare just in > > case, it works, so I am considering doing this on real hardware soon). > > I drew a nice diagram: http://www.pastebin.ca/1460089 Since it doesnt > > show on the diagram, let me clarify that the geom mirror consumers as > > well as the vdevz for ZFS RAIDZ are going to be partitions (raw disk > > => full disk slice => swap partition | mirror provider partition | zfs > > vdev partition | unused. > > > I don't know for sure if it's the same on FreeBSD, but on Solaris, ZFS will > disable the onboard disk cache if the vdevs are not whole disks. IOW, if > you use slices, partitions, or files, the onboard disk cache is disabled. > This can lead to poor write performance. > > Unless you can use one of the ZFS-on-root facilities, I'd look into getting > a couple of CompactFlash or USB sticks to use for the gmirror for / and /usr > (put the rest on ZFS). Then you can dedicate the entirety of all 5 drives > to ZFS. Even if you use do a bootable ZFS on root, you'll end up with a couple of gpt partitions (boot code, swap, then root) and therefor constructing your ZFS file system from a partition. Pawel said, back on April 6, 2007, "We support cache flushing operations on any GEOM provider (disk, partition, slice, anything disk-like), so bascially currently I treat everything as a whole disk [...]" Does anyone know for sure if we disable caching for partitions? g. From fjwcash at gmail.com Mon Jun 15 15:54:57 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Mon Jun 15 15:55:04 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: <18998.27937.780804.279674@already.local> References: <18998.27937.780804.279674@already.local> Message-ID: On Mon, Jun 15, 2009 at 8:47 AM, George Hartzell wrote: > Freddie Cash writes: > > On Sun, Jun 14, 2009 at 9:17 AM, Dan Naumov > wrote: > > > > > I just wanted to have an extra pair (or a dozen) of eyes look this > > > configuration over before I commit to it (tested it in VMWare just in > > > case, it works, so I am considering doing this on real hardware soon). > > > I drew a nice diagram: http://www.pastebin.ca/1460089 Since it doesnt > > > show on the diagram, let me clarify that the geom mirror consumers as > > > well as the vdevz for ZFS RAIDZ are going to be partitions (raw disk > > > => full disk slice => swap partition | mirror provider partition | zfs > > > vdev partition | unused. > > > > > > I don't know for sure if it's the same on FreeBSD, but on Solaris, ZFS > will > > disable the onboard disk cache if the vdevs are not whole disks. IOW, > if > > you use slices, partitions, or files, the onboard disk cache is > disabled. > > This can lead to poor write performance. > > > > Unless you can use one of the ZFS-on-root facilities, I'd look into > getting > > a couple of CompactFlash or USB sticks to use for the gmirror for / and > /usr > > (put the rest on ZFS). Then you can dedicate the entirety of all 5 > drives > > to ZFS. > > Even if you use do a bootable ZFS on root, you'll end up with a couple > of gpt partitions (boot code, swap, then root) and therefor > constructing your ZFS file system from a partition. > > Pawel said, back on April 6, 2007, > > "We support cache flushing operations on any GEOM provider (disk, > partition, slice, anything disk-like), so bascially currently I > treat everything as a whole disk [...]" > > Does anyone know for sure if we disable caching for partitions? > Going back through some old threads, it seems that I was mistaken, and it's only on Solaris that disk cache is disabled for vdevs created from partitions. 3 cheers for GEOM. :) -- Freddie Cash fjwcash@gmail.com From jhb at freebsd.org Mon Jun 15 16:14:09 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 15 16:14:16 2009 Subject: Let's back out LOADER_ZFS_SUPPORT from STABLE In-Reply-To: References: <1407C6EC-873D-49AB-9F8C-6A4A6FFA9DC3@airwired.net> Message-ID: <200906150853.35327.jhb@freebsd.org> On Sunday 14 June 2009 7:08:50 pm Daniel Eischen wrote: > On Sun, 14 Jun 2009, Dan Allen wrote: > > > > > On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote: > > > >> From one of your older emails, you mention you are using > >> ad0s2a as / and ad0s2b as swap, and then say that ad0s2c > >> is unused (I may have the ad0s2 part wrong). But ad0s2c > >> should be the entire slice (or partition depending on > >> the wording you are used to). > >> > >> How about posting a relevent fdisk and disklabel (or > >> gpart show) so we can see what your slices and partitions > >> look like (fdisk /dev/ad0, disklabel /dev/ad0s2). > > > > ad0s2c is the entire slice as you thought it should be. > > > > Here is fdisk and bsdlabel /dev/ad0s2: > > > > ******* Working on device /dev/ad0 ******* > > parameters extracted from in-core disklabel are: > > cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) > > > > Figures below won't work with BIOS for partitions not in cyl 1 > > parameters to be used for BIOS calculations are: > > cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) > > > > Media sector size is 512 > > Warning: BIOS sector numbering starts with sector 1 > > Information from DOS bootblock is: > > The data for partition 1 is: > > sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) > > start 63, size 188747622 (92161 Meg), flag 0 > > beg: cyl 0/ head 1/ sector 1; > > end: cyl 1023/ head 10/ sector 63 > > The data for partition 2 is: > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > start 188747685, size 45688860 (22309 Meg), flag 80 (active) > > beg: cyl 1023/ head 255/ sector 63; > > end: cyl 1023/ head 14/ sector 63 > > The data for partition 3 is: > > > > The data for partition 4 is: > > > > > > > > > > # /dev/ad0s2: > > 8 partitions: > > # size offset fstype [fsize bsize bps/cpg] > > a: 43591708 2097152 4.2BSD 0 0 0 > > b: 2097152 0 swap > > c: 45688860 0 unused 0 0 # "raw" part, don't > > edit > > Seems weird to see swap at offset 0 and partition a after swap. > I wonder if that is screwing things up. And shouldn't the offset > for your first slice start at offset 188747685 (from fdisk)? swap at offset 0 will probably break. The first 16 sectors hold the BSD disklabel and boot code. FFS filesystems leave the first 16 sectors unused, so if you let 'a' start at 0, it actually starts at 16 and you are ok. However, if you let swap start at 0, it actually uses sector 0 and the first time you swap you will trash your filesystem label (yes, this arrangement is exceedingly lame). You could fix this by either letting 'a' come first or changing the swap to start at sector 16 instead of 0. -- John Baldwin From jhb at freebsd.org Mon Jun 15 16:14:10 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 15 16:14:27 2009 Subject: lockup on 6.4 while bce in MGETHDR In-Reply-To: References: Message-ID: <200906150854.58042.jhb@freebsd.org> On Monday 15 June 2009 4:49:06 am pluknet wrote: > Hi. > > This is on 6.4-S as of April with uptime about 2 months. > Machine could not be accessed via network, didn't reply on ping. > Looking at backtrace it's here: > > if_bce.c::bce_get_buf(): > /* This is a new mbuf allocation. */ > MGETHDR(m_new, M_DONTWAIT, MT_DATA); > > > >From brk-seq: > > db> bt > Tracing pid 31 tid 100034 td 0xc833ad00 > kdb_enter(c097ef95) at kdb_enter+0x2b > siointr1(c83a3c00) at siointr1+0xce > siointr(c83a3c00) at siointr+0x5e > intr_execute_handlers(c80ee4c8,e8963abc,4,e8963b0c,c08cba63,...) at > intr_execute_handlers+0xe1 > lapic_handle_intr(38) at lapic_handle_intr+0x2e > Xapic_isr1() at Xapic_isr1+0x33 > --- interrupt, eip = 0xc06a393e, esp = 0xe8963b00, ebp = 0xe8963b0c > --- > _mtx_lock_sleep(c0a655c0,c833ad00,0,0,0) at _mtx_lock_sleep+0xb6 > kmem_malloc(c14680c0,1000,101,e8963b8c,c082cadd,...) at > kmem_malloc+0x328 > page_alloc(c1456000,1000,e8963b7f,101,c8b10016,...) at page_alloc+0x1a > slab_zalloc(c1456000,101,0,d278ca90,c915aa3c,...) at slab_zalloc+0xdd > uma_zone_slab(c1456000,1) at uma_zone_slab+0xf0 > uma_zalloc_bucket(c1456000,1) at uma_zalloc_bucket+0x15c > uma_zalloc_arg(c1456000,d0729e00,1) at uma_zalloc_arg+0x292 > bce_get_buf(c8363000,0,e8963c7c,e8963c7e,e8963c80) at bce_get_buf+0xef > bce_fill_rx_chain(c8363000,7047,d0729000,cbd86000,59375b37,...) at > bce_fill_rx_chain+0x48 > bce_rx_intr(c8363000) at bce_rx_intr+0x301 > bce_intr(c8363000) at bce_intr+0xf4 > ithread_execute_handlers(c8337c90,c8230a80) at > ithread_execute_handlers+0x125 > ithread_loop(c835f860,e8963d38) at ithread_loop+0x55 > fork_exit(c0694a38,c835f860,e8963d38) at fork_exit+0x71 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe8963d6c, ebp = 0 --- > > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 17102 17100 15549 0 L *vm page 0xcce93480 awk > 17101 17100 15549 0 L *Giant 0xc8737480 grep > 17100 17098 15549 0 S wait 0xc8726a78 sh > 17098 15570 15549 0 S wait 0xc98c2a78 sh > 16935 30771 30771 8382 RL httpd > 16656 16349 16349 10346 S biord 0xdc389368 php > 16564 16460 16460 18332 SL vmpfw 0xc365da98 lynx > 16563 16351 16351 18332 LL *vm page 0xcce93480 lynx I suspect these are your real problems. Try doing 'show lockchain 16563' or 'show lockchain 17101'. -- John Baldwin From hpcharles at gmail.com Mon Jun 15 16:30:42 2009 From: hpcharles at gmail.com (Henri-Pierre Charles) Date: Mon Jun 15 16:30:56 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090529181618.GF72047@alchemy.franken.de> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> <20090423171949.GE50221@alchemy.franken.de> <20090423200507.GA1246@mr-happy.com> <4734a3ed0905291102m3b1474adk50eb8bcf6712a742@mail.gmail.com> <20090529181618.GF72047@alchemy.franken.de> Message-ID: <4734a3ed0906150930v42b2f202k91d94d5f4e851c74@mail.gmail.com> Hello, On Fri, May 29, 2009 at 8:16 PM, Marius Strobl wrote: > On Fri, May 29, 2009 at 08:02:42PM +0200, Henri-Pierre Charles wrote: >> Hello Guys >> >> On Thu, Apr 23, 2009 at 10:05 PM, Jeff Blank wrote: >> > On Thu, Apr 23, 2009 at 07:19:49PM +0200, Marius Strobl wrote: >> >> So in combination with >> >> the low number of problem reports this really doesn't >> >> look like a generic problem of this Broadcom hardware >> >> or bge(4) and I just can suggest to disable MSI by >> >> setting the hw.pci.enable_msi tuneable to 0 for now. >> > >> > Great, this does the trick, and I'm now running today's RELENG_7. >> > Thanks for your help, and let me know if ever you'd like me to help >> > test possible fixes. >> >> I have the same computer (Dell optiplex 740) but the sysctl turnaround >> doesn't work, the bge interface seem up but no interruptions. >> >> I have to download / recompile with sys/dev/bge/if_bge.c rev >> 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6 >> >> Is there anything else to try ? > > You need to set hw.pci.enable_msi in the loader f.e. via > loader.conf rather than the corresponding sysctl as the > latter has no effect during boot. Ok, thanks it works. -- HPC From pluknet at gmail.com Mon Jun 15 17:30:42 2009 From: pluknet at gmail.com (pluknet) Date: Mon Jun 15 17:30:49 2009 Subject: coretemp(4) lockups on 6-stable In-Reply-To: References: Message-ID: 2009/6/15 pluknet : > 2009/6/15 pluknet : >> This is 6.4-stable from April. >> >> System locks up while in `sysctl dev.cpu` (with coretemp kldloaded). > > Small follow-up: > > Just one of my wild guesses is that coretemp doesn't play nice with ncpu > 4. > A problem box is 8-way cpu. I always observe this lockup when > sched_bind(curthread, cpu) called with cpu==4. While on another box > `sysctl dev.cpu` works good and that box have only 4 cpu cores. > And yet another small one: coretemp(4) works ok under 7.0+ on same h/w. >> >> So as far as I understand sched_bind() binds an executing thread to >> nonexistent CPU 255. >> Same behavior on coretemp built on 6.2. >> >> db> ps >> pid ppid pgrp uid state wmesg wchan cmd >> 34381 34380 34381 0 R+ CPU 255 sysctl >> [...] >> db> bt 34381 >> Tracing pid 34381 tid 100166 td 0xc8634680 >> sched_switch(c8634680,0,1) at sched_switch+0x143 >> mi_switch(1,0,c86347e0,4,c0a4e510,...) at mi_switch+0x1ba >> sched_bind(c8634680,4,c856f3b0,0,c0836b3b,...) at sched_bind+0x52 >> coretemp_get_temp_sysctl(c8ef56c0,c908c200,0,eebebc04,c8ef56c0,...) at >> coretemp_get_temp_sysctl+0x47 >> sysctl_root(0,eebebc74,4,eebebc04) at sysctl_root+0x107 >> userland_sysctl(c8634680,eebebc74,4,0,bfbfda8c,0,0,0,eebebc70,0) at >> userland_sysctl+0x112 >> __sysctl(c8634680,eebebd04) at __sysctl+0x93 >> syscall(3b,3b,3b,4,bfbfda8c,...) at syscall+0x2bf >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2812407b, esp = >> 0xbfbfd9fc, ebp = 0xbfbfda38 --- >> >> static int >> coretemp_get_temp(device_t dev) >> { >> uint64_t msr; >> int temp; >> int cpu = device_get_unit(dev); >> struct coretemp_softc *sc = device_get_softc(dev); >> char stemp[16]; >> >> mtx_lock_spin(&sched_lock); >> sched_bind(curthread, cpu); >> ^^^ >> mtx_unlock_spin(&sched_lock); >> >> >> -- >> wbr, >> pluknet >> > > > > -- > wbr, > pluknet > -- wbr, pluknet From jhb at freebsd.org Mon Jun 15 20:59:51 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 15 20:59:58 2009 Subject: HEADSUP: libpthread compat for 5.x and 6.x binaries Message-ID: <200906151659.27326.jhb@freebsd.org> One of the changes in FreeBSD 8.0 is the removal of support for the KSE threading library and its associated system calls. What this means in practice is that if one uses a KSE-based libpthread from 5.x or 6.x in a chroot or jail on an 8.0 system, the binaries will fail with SIGSYS. For most (possibly all) binaries, this can be worked around by using libthr instead libpthread. FreeBSD 7.0 and later ship with libthr as the threading library installed as libpthread. What I would like to find out is if there are any 5.x or 6.x binaries that use libpthread that do not run well with libthr. You can test this by using a libmap.conf(5) file to remap libpthread to libthr. For 5.x binaries you will want to remap libpthread.so.1 to libthr.so.1. For 6.x binaries you will want to remap libpthread.so.2 to libthr.so.2. This can be accomplished using an /etc/libmap.conf file that contains: # Remap 5.x and 6.x libpthread to libthr libpthread.so.1 libthr.so.1 libpthread.so.2 libthr.so.2 To my knowledge, most binaries should work fine in this configuration. One binary that I am aware of that does have problems is the 'arcconf' binary from ports. However, for this particular case there is a binary for 7.x available for use on 8.0 systems. -- John Baldwin From zbeeble at gmail.com Tue Jun 16 05:29:16 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Tue Jun 16 05:29:23 2009 Subject: Changes in the routing socket datagram between 7.0 and 7.2? Message-ID: <5f67a8c40906152229t2123e8f1ma2c1ccafbb4f8e02@mail.gmail.com> Did we change something in the routing socket's datagram between 7.0 and 7.2? I have a binary I compiled on 7.0-RELEASE and it fails to add a route on 7.2. If I recompile the source on 7.2, it works. Roughly put, the code make a datagram for the route socket like this: bzero(&rtmsg, sizeof(rtmsg)); /* Initial static part of the route message */ rtmsg.mrtm.rtm_msglen = sizeof(rtmsg); rtmsg.mrtm.rtm_type = RTM_ADD; rtmsg.mrtm.rtm_flags = RTF_UP | RTF_STATIC | RTF_GATEWAY; rtmsg.mrtm.rtm_version = RTM_VERSION; rtmsg.mrtm.rtm_addrs = RTA_DST | RTA_GATEWAY | RTA_NETMASK; /* Gateway will always be the same */ rtmsg.gateway.sin_family = AF_INET; rtmsg.gateway.sin_len = sizeof(rtmsg.gateway); /* Add a route to localhost for my address first */ rtmsg.dest.sin_addr.s_addr = cons->LtunAddr; rtmsg.mask.sin_addr.s_addr = INADDR_BROADCAST; rtmsg.mrtm.rtm_seq = htons(fsd->routeSeq++); rtmsg.gateway.sin_addr.s_addr = INADDR_LOOPBACK; From pluknet at gmail.com Tue Jun 16 10:23:49 2009 From: pluknet at gmail.com (pluknet) Date: Tue Jun 16 10:23:55 2009 Subject: 6.2 sporadically locks up Message-ID: Hi all. This is one of livelocks we have on a weekly basis. Yes, we do still use ULE scheduler on 6.2 and not moved to 7 yet. Any thought? db> ps pid ppid pgrp uid state wmesg wchan cmd 70304 69700 69670 0 R sh 70303 70292 93818 3572 RL CPU 2 chrsh 70302 70294 93818 3572 R crond 70299 93818 93818 0 R CPU 1 crond 70298 93818 93818 0 R crond 70294 93818 93818 3572 S piperd 0xd1d8d330 crond 70292 93818 93818 3572 R crond 70284 70279 70040 10229 S biord 0xdbe2e4e8 perl5.8.8 70283 70278 93818 10229 SL biord 0xdbd70710 exim-4.63-0 70279 70040 70040 10229 S wait 0xc9005860 sh 70278 69996 93818 10229 S wait 0xcaf4ac90 sh 70191 4680 4680 9738 S select 0xc0a12944 httpd 70190 4796 4796 10008 R httpd 70188 5043 5043 30532 RL httpd 70043 69999 70043 3572 Ss select 0xc0a12944 wget 70042 70000 70042 3572 Ss select 0xc0a12944 wget 70041 70001 70041 3572 Ss select 0xc0a12944 wget 70040 69996 70040 10229 Ss piperd 0xca35e990 perl5.8.8 70039 70002 70039 3572 Ss select 0xc0a12944 wget db> kill 9 70284 db> kill 9 70283 db> c telnet> send break KDB: enter: Line break on console [thread pid 70299 tid 101189 ] Stopped at kdb_enter+0x2b: nop db> ps pid ppid pgrp uid state wmesg wchan cmd 70304 69700 69670 0 R sh 70303 70292 93818 3572 RL CPU 2 chrsh 70302 70294 93818 3572 R crond 70299 93818 93818 0 R CPU 1 crond 70298 93818 93818 0 R crond 70294 93818 93818 3572 S piperd 0xd1d8d330 crond 70292 93818 93818 3572 R crond 70284 70279 70040 10229 S biord 0xdbe2e4e8 perl5.8.8 70283 70278 93818 10229 SL biord 0xdbd70710 exim-4.63-0 70279 70040 70040 10229 S wait 0xc9005860 sh 70278 69996 93818 10229 S wait 0xcaf4ac90 sh 70191 4680 4680 9738 S select 0xc0a12944 httpd 70190 4796 4796 10008 R httpd 70188 5043 5043 30532 RL httpd 70043 69999 70043 3572 Ss select 0xc0a12944 wget 70042 70000 70042 3572 Ss select 0xc0a12944 wget 70041 70001 70041 3572 Ss select 0xc0a12944 wget 70040 69996 70040 10229 Ss piperd 0xca35e990 perl5.8.8 70039 70002 70039 3572 Ss select 0xc0a12944 wget db> bt Tracing pid 70299 tid 101189 td 0xc99f9960 kdb_enter(c094016e) at kdb_enter+0x2b siointr1(c7f93000) at siointr1+0xce siointr(c7f93000) at siointr+0x5e intr_execute_handlers(c7cf24c8,eee33ad4,4,eee33b24,c0899013,...) at intr_execute _handlers+0xe1 lapic_handle_intr(37) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc067a3ce, esp = 0xeee33b18, ebp = 0xeee33b24 --- _mtx_lock_sleep(c0a06c60,c99f9960,0,0,0) at _mtx_lock_sleep+0xc6 namei(eee33c00) at namei+0x1ec kern_stat(c99f9960,2827dc14,0,eee33c74) at kern_stat+0x35 stat(c99f9960,eee33d04) at stat+0x1b syscall(3b,805003b,bfbf003b,0,1,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (188, FreeBSD ELF32, stat), eip = 0x28268453, esp = 0xbfbfd70c, ebp = 0xbfbfd7e8 --- db> bt 70283 Tracing pid 70283 tid 101809 td 0xcb250e10 sched_switch(cb250e10,0,1) at sched_switch+0x143 mi_switch(1,0,cb250e10,ef6c6a08,c06a43a4,...) at mi_switch+0x1ba sleepq_switch(dbd70710) at sleepq_switch+0x87 sleepq_wait(dbd70710,0,cb250e10,4c,dbd70710,...) at sleepq_wait+0x5c msleep(dbd70710,c0a12f80,4c,c0928ea1,0) at msleep+0x269 bwait(dbd70710,4c,c0928ea1) at bwait+0x5f bufwait(dbd70710) at bufwait+0x1a ufs_bmaparray(c8a22990,d,0,ef6c6b24,0,...) at ufs_bmaparray+0x656 ufs_bmap(ef6c6b70) at ufs_bmap+0x4b VOP_BMAP_APV(c09d5720,ef6c6b70) at VOP_BMAP_APV+0x41 vnode_pager_haspage(c8a166b4,34,0,ef6c6bd8,ef6c6bd4) at vnode_pager_haspage+0x19 7 vm_fault_additional_pages(c1351850,0,0,ef6c6c84,ef6c6c48,...) at vm_fault_additi onal_pages+0x59 vm_fault(cff46128,2838a000,2,8) at vm_fault+0xaeb trap_pfault(ef6c6d38,1,2838a3a9,2838a3a9,0,...) at trap_pfault+0x123 trap(3b,3b,3b,2838a3a9,c57,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x2810b8c8, esp = 0xbfbfe960, ebp = 0xbfbfea08 --- db> show lockchain 70283 thread 101809 (pid 70283, exim-4.63-0) inhibited db> show lockchain 70284 thread 101825 (pid 70284, perl5.8.8) inhibited db> show lockchain Giant thread -3420549 (pid 434, ) ??? (0xc099cb0c) db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xc7cfec80: pid 18 "swi4: clock sio" curpcb = 0xe6892d90 fpcurthread = none idlethread = 0xc7cfeaf0: pid 17 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid = 1 curthread = 0xc99f9960: pid 70299 "crond" curpcb = 0xeee33d90 fpcurthread = none idlethread = 0xc7cfe000: pid 16 "idle: cpu1" APIC ID = 1 currentldt = 0x50 cpuid = 2 curthread = 0xc99f9af0: pid 70303 "chrsh" curpcb = 0xeee36d90 fpcurthread = none idlethread = 0xc7cfde10: pid 15 "idle: cpu2" APIC ID = 2 currentldt = 0x50 cpuid = 3 curthread = 0xd087d320: pid 69700 "sh" curpcb = 0xf0179d90 fpcurthread = none idlethread = 0xc7cfdc80: pid 14 "idle: cpu3" APIC ID = 3 currentldt = 0x50 cpuid = 4 curthread = 0xc98f84b0: pid 69604 "httpd" curpcb = 0xeedadd90 fpcurthread = none idlethread = 0xc7cfdaf0: pid 13 "idle: cpu4" APIC ID = 4 currentldt = 0x50 cpuid = 5 curthread = 0xcaebe190: pid 69598 "httpd" curpcb = 0xf160fd90 fpcurthread = none idlethread = 0xc7cfd960: pid 12 "idle: cpu5" APIC ID = 5 currentldt = 0x50 cpuid = 6 curthread = 0xc7cfe960: pid 27 "irq17: bce1 aacu0" curpcb = 0xe688cd90 fpcurthread = none idlethread = 0xc7cfd7d0: pid 11 "idle: cpu6" APIC ID = 6 currentldt = 0x50 cpuid = 7 curthread = 0xc837fe10: pid 69711 "arcconf" curpcb = 0xf0a7ad90 fpcurthread = none idlethread = 0xc7cfd640: pid 10 "idle: cpu7" APIC ID = 7 currentldt = 0x50 db> bt 69711 Tracing pid 69711 tid 101066 td 0xc837fe10 sched_switch(7fffffff,1,0,c7e63020,c,...) at sched_switch+0x143 db> show lockchain 69711 thread 101066 (pid 69711, arcconf) running on CPU 7 db> bt 27 Tracing pid 27 tid 100017 td 0xc7cfe960 sched_switch(181cd81,8515a000,c7f65000,1,c7f55c00,...) at sched_switch+0x143 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7f5aa00 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 _end(1,c7f5ae40,0,0,0,...) at 0xc7f60480 _end(c7fbbc00,c7f57c08,31656362,0,0,...) at 0xc7e32300 db> show lockchain 27 thread 100017 (pid 27, irq17: bce1 aacu0) running on CPU 6 db> bt 18 Tracing pid 18 tid 100015 td 0xc7cfec80 sched_switch(c0a21e40,c08639e4,0,0,0,...) at sched_switch+0x143 db> show lockchain 18 thread 100015 (pid 18, swi4: clock sio) running on CPU 0 db> bt 70304 Tracing pid 70304 tid 101836 td 0xcc4064b0 fork_trampoline() at fork_trampoline db> bt 70303 Tracing pid 70303 tid 101552 td 0xc99f9af0 fork_trampoline() at fork_trampoline db> bt 70292 Tracing pid 70292 tid 100415 td 0xc98f7320 sched_switch(c98f7320,0,2) at sched_switch+0x143 mi_switch(2,0,c98f7320,a1) at mi_switch+0x1ba ast(eed8cd38) at ast+0x3fe doreti_ast() at doreti_ast+0x17 db> bt 70040 Tracing pid 70040 tid 101893 td 0xd0df1320 sched_switch(d0df1320,0,1) at sched_switch+0x143 mi_switch(1,0,ca35e990,efe1abec,c06a43f5,...) at mi_switch+0x1ba sleepq_switch(ca35e990) at sleepq_switch+0x87 sleepq_wait_sig(ca35e990) at sleepq_wait_sig+0x1d msleep(ca35e990,ca35eb00,14c,c0927184,0,...) at msleep+0x25a pipe_read(ca9f33a8,efe1acbc,cd96de80,0,d0df1320) at pipe_read+0x42d dofileread(d0df1320,4,ca9f33a8,efe1acbc,ffffffff,...) at dofileread+0x85 kern_readv(d0df1320,4,efe1acbc,8077000,1000,...) at kern_readv+0x36 read(d0df1320,efe1ad04) at read+0x45 syscall(804003b,3b,bfbf003b,0,28296da0,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x2827234f, esp = 0xbfbfc89c, ebp = 0xbfbfc8b8 --- db> show intr irq1: atkbd0 (pid 41) irq4: sio0 (no thread) irq9: acpi0 (pid 26) irq14: ata0 (pid 38) {ENTROPY} irq15: ata1 (pid 39) {ENTROPY} irq16: bce0 (pid 29) irq17: bce1 aacu0 (pid 27) irq22: uhci1 uhci3 (pid 33) irq23: uhci0 uhci+ (pid 30) swi4: clock sio (pid 18) {SOFT, NEED} swi3: vm (pid 19) {SOFT} swi1: net (pid 20) {SOFT, NEED} swi6: Giant taskq (pid 22) {SOFT} swi5: + (pid 23) {SOFT} swi2: cambio (pid 24) {SOFT} swi6: task queue (pid 25) {SOFT} swi0: sio (pid 40) {SOFT} db> show lockedbufs buf at 0xdbd65ca8 b_flags = 0x30000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8a49e90), b_data = 0xdc1e7000, b_blkno = 1513488416 b_npages = 4, pages(OBJ, IDX, PA): (0xc8da2c60, 0x234, 0x42fe8000),(0xc8da2c60, 0x235, 0xa0129000),(0xc8da2c60, 0x236, 0x7c26a000),(0xc8da2c60, 0x237, 0x52bab000) lock type bufwait: EXCL (count 1) by thread 0xd01c54b0 (pid 1029) buf at 0xdbd66830 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8254d80), b_data = 0xdc20b000, b_blkno = 2171944672 b_npages = 4, pages(OBJ, IDX, PA): (0xc8257a50, 0x102ea7dc, 0x756a8000),(0xc8257a50, 0x102ea7dd, 0x7849000),(0xc8257a50, 0x102ea7de, 0x5560a000),(0xc8257a50, 0x102ea7df, 0xb6f4b000) db> show lockedvnods Locked vnodes 0xca4d7110: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xccdb6d68 ref 0 pages 5 lock type ufs: EXCL (count 1) by thread 0xc9216190 (pid 69696) ino 13, on dev aacdu0s1e 0xc8a22990: tag ufs, type VREG usecount 11, writecount 0, refcount 14 mountedhere 0 flags () v_object 0xc8a166b4 ref 9 pages 40 lock type ufs: SHARED (count 1) ino 1768379, on dev aacdu0s1f 0xc8f92110: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xcec50420 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xca3ece10 (pid 64525) ino 14291128, on dev aacdu0s1g 0xc85bd110: tag ufs, type VREG usecount 1, writecount 1, refcount 423 mountedhere 0 flags () v_object 0xc85946b4 ref 0 pages 1970 lock type ufs: SHARED (count 1) ino 189127858, on dev aacdu0s1g 0xc8a49dd0: tag ufs, type VREG usecount 2, writecount 2, refcount 85 mountedhere 0 flags () v_object 0xc8da2c60 ref 0 pages 328 lock type ufs: SHARED (count 1) ino 189127816, on dev aacdu0s1g 0xc8df3770: tag ufs, type VDIR usecount 10, writecount 0, refcount 13 mountedhere 0 flags () v_object 0xc8da2210 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xcb25daf0 (pid 69722) ino 183912960, on dev aacdu0s1g 0xccf1b990: tag ufs, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xcb25daf0 (pid 69722) ino 183913000, on dev aacdu0s1g 0xd032f550: tag ufs, type VREG usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xd08c7318 ref 0 pages 1 lock type ufs: SHARED (count 1) ino 142034973, on dev aacdu0s1g db> bt 69722 Tracing pid 69722 tid 100908 td 0xcb25daf0 sched_switch(3408255728,0,1) at sched_switch+323 mi_switch(1,0,3408255728,4017571924,3228189604,...) at mi_switch+442 sleepq_switch(3689066592) at sleepq_switch+135 sleepq_wait(3689066592,0,3408255728,76,3689066592,...) at sleepq_wait+92 msleep(3689066592,3231788928,76,3230830241,0) at msleep+617 bwait(3689066592,76,3230830241) at bwait+95 bufwait(3689066592,1,0,0,0,...) at bufwait+26 breadn(3357887680,1471303904,0,16384,0,...) at breadn+486 bread(3357887680,1471303904,0,16384,0,4017572212) at bread+32 ffs_vget(3357590832,183913000,2,4017572316) at ffs_vget+816 ufs_lookup(4017572476) at ufs_lookup+2722 VOP_CACHEDLOOKUP_APV(3231536928,4017572476) at VOP_CACHEDLOOKUP_APV+56 vfs_cache_lookup(4017572632) at vfs_cache_lookup+178 VOP_LOOKUP_APV(3231536928,4017572632) at VOP_LOOKUP_APV+67 lookup(4017572768) at lookup+1217 namei(4017572768) at namei+922 kern_lstat(3408255728,134647808,0,4017572980) at kern_lstat+71 lstat(3408255728,4017573124) at lstat+27 syscall(59,59,59,134647845,1,...) at syscall+703 Xint0x80_syscall() at Xint0x80_syscall+31 --- syscall (190, FreeBSD ELF32, lstat), eip = 672752691, esp = 3217024908, ebp = 3217025080 --- db> bt 64525 Tracing pid 64525 tid 102165 td 0xca3ece10 sched_switch(3393113616,0,1) at sched_switch+323 mi_switch(1,0,3393113616,4011194528,3228189604,...) at mi_switch+442 sleepq_switch(3689874456) at sleepq_switch+135 sleepq_wait(3689874456,0,3393113616,76,3689874456,...) at sleepq_wait+92 msleep(3689874456,3231788928,76,3230830241,0) at msleep+617 bwait(3689874456,76,3230830241) at bwait+95 bufwait(3689874456,1,0,0,0,...) at bufwait+26 breadn(3371770128,0,0,2048,0,...) at breadn+486 bread(3371770128,0,0,2048,0,4011194740) at bread+32 ffs_blkatoff(3371770128,0,0,0,4011194848) at ffs_blkatoff+158 ufs_lookup(4011195004) at ufs_lookup+717 VOP_CACHEDLOOKUP_APV(3231536928,4011195004) at VOP_CACHEDLOOKUP_APV+56 vfs_cache_lookup(4011195160) at vfs_cache_lookup+178 VOP_LOOKUP_APV(3231536928,4011195160) at VOP_LOOKUP_APV+67 lookup(4011195296) at lookup+1217 namei(4011195296) at namei+922 kern_lstat(3393113616,3217013088,0,4011195508) at kern_lstat+71 lstat(3393113616,4011195652) at lstat+27 syscall(3230203963,59,2097211,672879355,3217010833,...) at syscall+703 Xint0x80_syscall() at Xint0x80_syscall+31 --- syscall (190, FreeBSD ELF32, lstat), eip = 672797747, esp = 3217009740, ebp = 3217013000 --- db> bt 69696 Tracing pid 69696 tid 100386 td 0xc9216190 sched_switch(3374408080,0,1) at sched_switch+323 mi_switch(1,0,3374408080,4004567636,3228189604,...) at mi_switch+442 sleepq_switch(3688649048) at sleepq_switch+135 sleepq_wait(3688649048,0,3374408080,76,3688649048,...) at sleepq_wait+92 msleep(3688649048,3231788928,76,3230830241,0) at msleep+617 bwait(3688649048,76,3230830241) at bwait+95 bufwait(3688649048,4096,0,4004567784,3227891026,...) at bufwait+26 cluster_read(3394072848,26112,0,1,0,...) at cluster_read+1617 ffs_read(4004568076) at ffs_read+607 VOP_READ_APV(3231536928,4004568076) at VOP_READ_APV+56 ufs_readdir(4004568208) at ufs_readdir+209 VOP_READDIR_APV(3231536928,4004568208) at VOP_READDIR_APV+56 getdirentries(3374408080,4004568324) at getdirentries+347 syscall(59,59,59,134693312,134688816,...) at syscall+703 Xint0x80_syscall() at Xint0x80_syscall+31 --- syscall (196, FreeBSD ELF32, getdirentries), eip = 672506011, esp = 3217023708, ebp = 3217023752 --- -- wbr, pluknet From jhb at freebsd.org Tue Jun 16 13:40:43 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 16 13:41:33 2009 Subject: 6.2 sporadically locks up In-Reply-To: References: Message-ID: <200906160830.29721.jhb@freebsd.org> On Tuesday 16 June 2009 6:23:47 am pluknet wrote: > Hi all. > > This is one of livelocks we have on a weekly basis. > Yes, we do still use ULE scheduler on 6.2 and not moved to 7 yet. > Any thought? > > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 70304 69700 69670 0 R sh > 70303 70292 93818 3572 RL CPU 2 chrsh > 70302 70294 93818 3572 R crond > 70299 93818 93818 0 R CPU 1 crond > 70298 93818 93818 0 R crond > 70294 93818 93818 3572 S piperd 0xd1d8d330 crond > 70292 93818 93818 3572 R crond > 70284 70279 70040 10229 S biord 0xdbe2e4e8 perl5.8.8 > 70283 70278 93818 10229 SL biord 0xdbd70710 exim-4.63-0 > 70279 70040 70040 10229 S wait 0xc9005860 sh > 70278 69996 93818 10229 S wait 0xcaf4ac90 sh > 70191 4680 4680 9738 S select 0xc0a12944 httpd > 70190 4796 4796 10008 R httpd > 70188 5043 5043 30532 RL httpd > 70043 69999 70043 3572 Ss select 0xc0a12944 wget > 70042 70000 70042 3572 Ss select 0xc0a12944 wget > 70041 70001 70041 3572 Ss select 0xc0a12944 wget > 70040 69996 70040 10229 Ss piperd 0xca35e990 perl5.8.8 > 70039 70002 70039 3572 Ss select 0xc0a12944 wget This is not a full listing so one cannot assume it is a deadlock. > db> show lockchain Giant > thread -3420549 (pid 434, ) ??? (0xc099cb0c) You would use 'show lock' or perhaps 'show turnstile' with specific lock variables. 'show lockchain' needs a TID or PID. > db> show allpcpu > cpuid = 0 > curthread = 0xc7cfec80: pid 18 "swi4: clock sio" > > cpuid = 1 > curthread = 0xc99f9960: pid 70299 "crond" > > cpuid = 2 > curthread = 0xc99f9af0: pid 70303 "chrsh" > > cpuid = 3 > curthread = 0xd087d320: pid 69700 "sh" > > cpuid = 4 > curthread = 0xc98f84b0: pid 69604 "httpd" > > cpuid = 5 > curthread = 0xcaebe190: pid 69598 "httpd" > > cpuid = 6 > curthread = 0xc7cfe960: pid 27 "irq17: bce1 aacu0" > > cpuid = 7 > curthread = 0xc837fe10: pid 69711 "arcconf" This is far more useful output than the truncated 'ps'. From this, all of the CPUs are busy (in at least some deadlocks, all the CPUs would be idle instead). There are several deadlocks fixed since 6.2 that I am aware of, but this doesn't look like any of those. I'm not sure why you aren't getting useful stack traces of running threads. Perhaps DDB in 6.2 doesn't know to look in stoppcbs[]. Hmm, looks like 6.2 only does that if you are using KDB_STOP_NMI. Are you using that kernel option? If not, you probably want to. -- John Baldwin From bms at incunabulum.net Tue Jun 16 14:00:53 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Jun 16 14:01:03 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> <200906020842.42330.jhb@freebsd.org> Message-ID: <4A37A591.1070907@incunabulum.net> Vlad Galu wrote: > ... > Thanks, Ivan. I'll take a better look at this after our first release, > which is due in a couple of weeks. Right now the team efforts aren't > focused on portability, so it's a low priority issue, but something > we'd definitely like to have in the future. > I've just run head first into this lack for a proof-of-concept I'm looking at -- the lack of PTHREAD_PROCESS_SHARED support on FreeBSD. Are there any other references I can start working from? cheers, BMS From avg at icyb.net.ua Tue Jun 16 15:00:41 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Jun 16 15:00:56 2009 Subject: zfs related panic In-Reply-To: <3c1674c90906121354s6d6ae7ben5082708b1586e94f@mail.gmail.com> References: <4A325E9F.2080802@icyb.net.ua> <3c1674c90906121354s6d6ae7ben5082708b1586e94f@mail.gmail.com> Message-ID: <4A37B395.20506@icyb.net.ua> on 12/06/2009 23:54 Kip Macy said the following: > show sleepchain I can only do post-mortem using jhb's scripts for kgdb: (kgdb) sleepchain 2432 thread 100263 (pid 2432, tcsh) non-lock sleep lockchain 2432 thread 100263 (pid 2432, tcsh) inhibited Not sure if this correct though and what this means. > show thread 100263 (kgdb) thr 250 [Switching to thread 250 (Thread 100263)]#0 sched_switch (td=0xffffff000cfad720, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) backtrace #0 sched_switch (td=0xffffff000cfad720, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xffffffff80302a59 in mi_switch (flags=1, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 #2 0xffffffff8032f645 in sleepq_switch (wchan=Variable "wchan" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xffffffff8032f925 in sleepq_catch_signals (wchan=0xffffff011440e548) at /usr/src/sys/kern/subr_sleepqueue.c:417 #4 0xffffffff80330219 in sleepq_wait_sig (wchan=Variable "wchan" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:594 #5 0xffffffff80302eba in _sleep (ident=0xffffff011440e548, lock=0xffffff011440e5a0, priority=360, wmesg=0xffffffff80508788 "pause", timo=0) at /usr/src/sys/kern/kern_synch.c:228 #6 0xffffffff802fc567 in kern_sigsuspend (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_sig.c:1474 #7 0xffffffff802fc5e9 in sigsuspend (td=0xffffff000cfad720, uap=Variable "uap" is not available. ) at /usr/src/sys/kern/kern_sig.c:1453 #8 0xffffffff80491d2d in syscall (frame=0xffffff8076db8c80) at /usr/src/sys/amd64/amd64/trap.c:899 #9 0xffffffff8047d00b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:339 #10 0x000000080092ce3c in ?? () Previous frame inner to this frame (corrupt stack?) -- Andriy Gapon From pluknet at gmail.com Tue Jun 16 15:03:37 2009 From: pluknet at gmail.com (pluknet) Date: Tue Jun 16 15:03:43 2009 Subject: 6.2 sporadically locks up In-Reply-To: <200906160830.29721.jhb@freebsd.org> References: <200906160830.29721.jhb@freebsd.org> Message-ID: 2009/6/16 John Baldwin : > On Tuesday 16 June 2009 6:23:47 am pluknet wrote: >> Hi all. >> >> This is one of livelocks we have on a weekly basis. >> Yes, we do still use ULE scheduler on 6.2 and not moved to 7 yet. >> Any thought? >> >> db> ps >> ?pid ?ppid ?pgrp ? uid ? state ? wmesg ? ? wchan ? ?cmd >> 70304 69700 69670 ? ? 0 ?R ? ? ? ? ? ? ? ? ? ? ? ? ? sh >> 70303 70292 93818 ?3572 ?RL ? ? ?CPU 2 ? ? ? ? ? ? ? chrsh >> 70302 70294 93818 ?3572 ?R ? ? ? ? ? ? ? ? ? ? ? ? ? crond >> 70299 93818 93818 ? ? 0 ?R ? ? ? CPU 1 ? ? ? ? ? ? ? crond >> 70298 93818 93818 ? ? 0 ?R ? ? ? ? ? ? ? ? ? ? ? ? ? crond >> 70294 93818 93818 ?3572 ?S ? ? ? piperd ? 0xd1d8d330 crond >> 70292 93818 93818 ?3572 ?R ? ? ? ? ? ? ? ? ? ? ? ? ? crond >> 70284 70279 70040 10229 ?S ? ? ? biord ? ?0xdbe2e4e8 perl5.8.8 >> 70283 70278 93818 10229 ?SL ? ? ?biord ? ?0xdbd70710 exim-4.63-0 >> 70279 70040 70040 10229 ?S ? ? ? wait ? ? 0xc9005860 sh >> 70278 69996 93818 10229 ?S ? ? ? wait ? ? 0xcaf4ac90 sh >> 70191 ?4680 ?4680 ?9738 ?S ? ? ? select ? 0xc0a12944 httpd >> 70190 ?4796 ?4796 10008 ?R ? ? ? ? ? ? ? ? ? ? ? ? ? httpd >> 70188 ?5043 ?5043 30532 ?RL ? ? ? ? ? ? ? ? ? ? ? ? ?httpd >> 70043 69999 70043 ?3572 ?Ss ? ? ?select ? 0xc0a12944 wget >> 70042 70000 70042 ?3572 ?Ss ? ? ?select ? 0xc0a12944 wget >> 70041 70001 70041 ?3572 ?Ss ? ? ?select ? 0xc0a12944 wget >> 70040 69996 70040 10229 ?Ss ? ? ?piperd ? 0xca35e990 perl5.8.8 >> 70039 70002 70039 ?3572 ?Ss ? ? ?select ? 0xc0a12944 wget > > This is not a full listing so one cannot assume it is a deadlock. Ok, usually that listing doesn't show anything interesting in this sort of lockup. I'll share a full ps output next time (sure, rather soon). > >> db> show lockchain Giant >> thread -3420549 (pid 434, ) ??? (0xc099cb0c) > > You would use 'show lock' or perhaps 'show turnstile' with specific lock > variables. ?'show lockchain' needs a TID or PID. Ok. As for turnstile, it showed nothing at all, hence omitted. > >> db> show allpcpu >> cpuid ? ? ? ?= 0 >> curthread ? ?= 0xc7cfec80: pid 18 "swi4: clock sio" >> >> cpuid ? ? ? ?= 1 >> curthread ? ?= 0xc99f9960: pid 70299 "crond" >> >> cpuid ? ? ? ?= 2 >> curthread ? ?= 0xc99f9af0: pid 70303 "chrsh" >> >> cpuid ? ? ? ?= 3 >> curthread ? ?= 0xd087d320: pid 69700 "sh" >> >> cpuid ? ? ? ?= 4 >> curthread ? ?= 0xc98f84b0: pid 69604 "httpd" >> >> cpuid ? ? ? ?= 5 >> curthread ? ?= 0xcaebe190: pid 69598 "httpd" >> >> cpuid ? ? ? ?= 6 >> curthread ? ?= 0xc7cfe960: pid 27 "irq17: bce1 aacu0" >> >> cpuid ? ? ? ?= 7 >> curthread ? ?= 0xc837fe10: pid 69711 "arcconf" > > This is far more useful output than the truncated 'ps'. ?From this, all of the > CPUs are busy (in at least some deadlocks, all the CPUs would be idle > instead). ?There are several deadlocks fixed since 6.2 that I am aware of, > but this doesn't look like any of those. ?I'm not sure why you aren't getting > useful stack traces of running threads. I'll do next time. I thought it would be similar to bt PID output and simply didn't include. As for allpcpu, I often see the picture, when one CPU runs the "irq17: bce1 aacu0" thread and another one runs arcconf. I wonder if that might be a source of bad locking or races, or.. The arcconf utility uses ioctl that goes into aac/aacu(4) internals. > Perhaps DDB in 6.2 doesn't know to > look in stoppcbs[]. ?Hmm, looks like 6.2 only does that if you are using > KDB_STOP_NMI. ?Are you using that kernel option? ?If not, you probably want > to. No, I'm not. Will that add an additional visible overhead on a running system? > > -- > John Baldwin > Thank you. -- wbr, pluknet From avg at freebsd.org Tue Jun 16 15:09:16 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Jun 16 15:09:23 2009 Subject: zfs related panic In-Reply-To: <4A37B395.20506@icyb.net.ua> References: <4A325E9F.2080802@icyb.net.ua> <3c1674c90906121354s6d6ae7ben5082708b1586e94f@mail.gmail.com> <4A37B395.20506@icyb.net.ua> Message-ID: <4A37B596.4090607@freebsd.org> on 16/06/2009 18:00 Andriy Gapon said the following: > on 12/06/2009 23:54 Kip Macy said the following: >> show sleepchain > > I can only do post-mortem using jhb's scripts for kgdb: > (kgdb) sleepchain 2432 > thread 100263 (pid 2432, tcsh) non-lock sleep I think that this was reported because td_wchan is not 'struct lock' in this case. (kgdb) fr 6 #6 0xffffffff802fc567 in kern_sigsuspend (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_sig.c:1474 (kgdb) list 1469 td->td_oldsigmask = td->td_sigmask; 1470 td->td_pflags |= TDP_OLDMASK; 1471 SIG_CANTMASK(mask); 1472 td->td_sigmask = mask; 1473 signotify(td); 1474 while (msleep(&p->p_sigacts, &p->p_mtx, PPAUSE|PCATCH, "pause", 0) == 0) 1475 /* void */; 1476 PROC_UNLOCK(p); 1477 /* always return EINTR rather than ERESTART... */ 1478 return (EINTR); (kgdb) p &p->p_sigacts $10 = (struct sigacts **) 0xffffff011440e548 (kgdb) fr 0 #0 sched_switch (td=0xffffff000cfad720, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 (kgdb) p td->td_wchan $11 = (void *) 0xffffff011440e548 (kgdb) p td->td_wmesg $12 = 0xffffffff80508788 "pause" (kgdb) backtrace #0 sched_switch (td=0xffffff000cfad720, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xffffffff80302a59 in mi_switch (flags=1, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 #2 0xffffffff8032f645 in sleepq_switch (wchan=Variable "wchan" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xffffffff8032f925 in sleepq_catch_signals (wchan=0xffffff011440e548) at /usr/src/sys/kern/subr_sleepqueue.c:417 #4 0xffffffff80330219 in sleepq_wait_sig (wchan=Variable "wchan" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:594 #5 0xffffffff80302eba in _sleep (ident=0xffffff011440e548, lock=0xffffff011440e5a0, priority=360, wmesg=0xffffffff80508788 "pause", timo=0) at /usr/src/sys/kern/kern_synch.c:228 #6 0xffffffff802fc567 in kern_sigsuspend (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_sig.c:1474 #7 0xffffffff802fc5e9 in sigsuspend (td=0xffffff000cfad720, uap=Variable "uap" is not available. ) at /usr/src/sys/kern/kern_sig.c:1453 #8 0xffffffff80491d2d in syscall (frame=0xffffff8076db8c80) at /usr/src/sys/amd64/amd64/trap.c:899 #9 0xffffffff8047d00b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:339 #10 0x000000080092ce3c in ?? () -- Andriy Gapon From jhb at freebsd.org Tue Jun 16 17:27:52 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 16 17:28:03 2009 Subject: 6.2 sporadically locks up In-Reply-To: References: <200906160830.29721.jhb@freebsd.org> Message-ID: <200906161314.56449.jhb@freebsd.org> On Tuesday 16 June 2009 11:03:34 am pluknet wrote: > 2009/6/16 John Baldwin : > As for allpcpu, I often see the picture, when one CPU runs the "irq17: > bce1 aacu0" thread > and another one runs arcconf. I wonder if that might be a source of > bad locking or races, or.. > The arcconf utility uses ioctl that goes into aac/aacu(4) internals. I wondered about that. I would ask emaste@ as he has worked with arcconf. I do think he has mentioned problems with arcconf locking up aac(4) controllers in the past. > > Perhaps DDB in 6.2 doesn't know to > > look in stoppcbs[]. ?Hmm, looks like 6.2 only does that if you are using > > KDB_STOP_NMI. ?Are you using that kernel option? ?If not, you probably want > > to. > > No, I'm not. Will that add an additional visible overhead on a running system? No, it actually allows the kernel to more reliably stop other CPUs during a panic, etc. It's enabled in GENERIC as 'STOP_NMI' in 7.0 and later. -- John Baldwin From peter at aspire.vk2pj.dyndns.org Tue Jun 16 18:53:54 2009 From: peter at aspire.vk2pj.dyndns.org (Peter Jeremy) Date: Tue Jun 16 18:54:01 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: References: Message-ID: <20090616185312.GJ9529@server.vk2pj.dyndns.org> On 2009-Jun-15 09:57:39 +0100, Pete French wrote: >In my expereince all the ones from the same manufacturer and model are >exactly the same size. Admittedly I only ever buy SCSI, but that >shouldnt make too much difference should it ? I have 3 Samsung HD103UJ disks and they have two different sizes: two are 1953523055 and the third is 1953525168 sectors -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090616/e8ef50a2/attachment.pgp From andrew-freebsd at areilly.bpc-users.org Wed Jun 17 01:17:20 2009 From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly) Date: Wed Jun 17 01:17:28 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: <20090616185312.GJ9529@server.vk2pj.dyndns.org> References: <20090616185312.GJ9529@server.vk2pj.dyndns.org> Message-ID: <20090617005335.GA27257@duncan.reilly.home> On Wed, Jun 17, 2009 at 04:53:12AM +1000, Peter Jeremy wrote: > On 2009-Jun-15 09:57:39 +0100, Pete French wrote: > >In my expereince all the ones from the same manufacturer and model are > >exactly the same size. Admittedly I only ever buy SCSI, but that > >shouldnt make too much difference should it ? > > I have 3 Samsung HD103UJ disks and they have two different sizes: > two are 1953523055 and the third is 1953525168 sectors I bought a pair of identical WD 750G SATA drives the other day and was surprised to discover that they were different sizes: ad4: 715403MB at ata2-master SATA150 ad6: 715404MB at ata3-master SATA150 Luckily for me I built the file systems on ad4, and added ad6 to the gmirror configuration. I suspect that it would have been unhappy if I'd done it the other way around. Cheers, -- Andrew From dan.naumov at gmail.com Wed Jun 17 07:34:04 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Wed Jun 17 07:34:16 2009 Subject: ZFS performance on 7.2-release/amd64 low compared to UFS2 + SoftUpdates Message-ID: I am wondering if the numbers I am seeing is something expected or is something broken somewhere. Output of bonnie -s 1024: on UFS2 + SoftUpdates: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1024 56431 94.5 88407 38.9 77357 53.3 64042 98.6 644511 98.6 23603.8 243.3 on ZFS: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1024 22591 53.7 45602 35.1 14770 13.2 45007 83.8 94595 28.0 102.2 1.2 atom# cat /boot/loader.conf vm.kmem_size="1024M" vm.kmem_size_max="1024M" vfs.zfs.arc_max="96M" The test isn't completely fair in that the test on UFS2 is done on a partition that resides on the first 16gb of a 2tb disk while the zfs test is done on the enormous 1,9tb zfs pool that comes after that partition (same disk). Can this difference in layout make up for the huge difference in performance or is there something else in play? The system is an Intel Atom 330 dualcore, 2gb ram, Western Digital Green 2tb disk. Also what would be another good way to get good numbers for comparing the performance of UFS2 vs ZFS on the same system. Sincerely, - Dan Naumov From cswiger at mac.com Wed Jun 17 07:56:41 2009 From: cswiger at mac.com (Chuck Swiger) Date: Wed Jun 17 07:56:48 2009 Subject: Does this disk/filesystem layout look sane to you? In-Reply-To: <20090617005335.GA27257@duncan.reilly.home> References: <20090616185312.GJ9529@server.vk2pj.dyndns.org> <20090617005335.GA27257@duncan.reilly.home> Message-ID: <92485F5A-C600-4514-959A-2562CE416DEB@mac.com> Hi-- On Jun 16, 2009, at 5:53 PM, Andrew Reilly wrote: > I bought a pair of identical WD 750G SATA drives the other day > and was surprised to discover that they were different sizes: > > ad4: 715403MB at ata2-master SATA150 > ad6: 715404MB at ata3-master SATA150 > > Luckily for me I built the file systems on ad4, and added ad6 to > the gmirror configuration. I suspect that it would have been > unhappy if I'd done it the other way around. Agreed. However, you might want to look carefully at the first drive via smartctl or even WDC's own utilities. It's not unusual for a drive to have some small area(s) of the disk surface which cannot record data reliably and hence are marked as bad sectors in the initial factory-provided P-LIST, and to keep some reserves as spare sectors for bad sectors which happen during normal operation (the 'grown' list aka G-LIST). If that is the reason (and there could be others-- you might even want to ping WDC's tech support about this), it's surprising that the amount of sectors marked bad is enough to change the reported size in megabytes. You might also want to double-check the actual physical label on the drive and watch out for an "RM" or "remanufactured"/"recertified" indicator. Regards, -- -Chuck From jespasac at minibofh.org Wed Jun 17 09:12:02 2009 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Wed Jun 17 09:12:10 2009 Subject: Upgrade OpenSSH in 6.3 and 7.0 RELENG Message-ID: <4A38AF82.8050407@minibofh.org> Hello folks, I need to upgrade the OpenSSH from the shiped 4.5p1 versions in 6.x and 7.x branches to 4.5p2 or higher(1). I've updated the source tree in 6.3 and 7.0 RELENG boxes with a system upgrade in mind, but the version is 4.5p1: # cat /usr/src/crypto/openssh/version.h | grep -i ssh_version_base && uname -r #define SSH_VERSION_BASE "OpenSSH_4.5p1" 6.3-RELEASE-p1 #cat /usr/src/crypto/openssh/version.h | grep -i ssh_version_base #define SSH_VERSION_BASE "OpenSSH_4.5p1" On the other I see that current vesion in -STABLE is 5.2p1, so upgrade to STABLE is an obvious option, but, sincerely, I want to avoid to upgrade to -STABLE and I prefer to keep the systems in their current RELENG. ?How can I upgrade the OpenSSH in the _same_ RELENG? ?Maybe using the ports? (1) It seems correct some pam_ldap related issues: http://www.nabble.com/Re:-Password-expiry-warning-message-from-ppolicy-td8071732.html -- Thanks, Jordi Espasa Clofent From erik at tefre.com Wed Jun 17 10:53:00 2009 From: erik at tefre.com (Erik Stian Tefre) Date: Wed Jun 17 10:53:08 2009 Subject: Upgrade OpenSSH in 6.3 and 7.0 RELENG In-Reply-To: <4A38AF82.8050407@minibofh.org> References: <4A38AF82.8050407@minibofh.org> Message-ID: <4A38C6AF.70809@tefre.com> Jordi Espasa Clofent wrote: > I need to upgrade the OpenSSH from the shiped 4.5p1 versions in 6.x and > 7.x branches to 4.5p2 or higher(1). [...] > ?How can I upgrade the OpenSSH in the _same_ RELENG? ?Maybe using the > ports? portsnap fetch update cd /usr/ports/security/openssh-portable/ make install clean /etc/rc.d/sshd stop Set sshd_enable="NO" in /etc/rc.conf Set openssh_enable="YES" in /etc/rc.conf /usr/local/etc/rc.d/openssh start This will enable the 5.2p1 sshd. The new client is installed as /usr/local/bin/ssh. Warnings: The above instructions are dumped from brain, untested and may be incomplete. It Worked For Me(tm) 3 months ago on 6.3. And your box will probably get a new host key btw. -- Erik From alson+ml at alm.flutnet.org Wed Jun 17 11:24:31 2009 From: alson+ml at alm.flutnet.org (Alson van der Meulen) Date: Wed Jun 17 11:24:40 2009 Subject: Upgrade OpenSSH in 6.3 and 7.0 RELENG In-Reply-To: <4A38C6AF.70809@tefre.com> References: <4A38AF82.8050407@minibofh.org> <4A38C6AF.70809@tefre.com> Message-ID: <20090617112426.GA1613@tafi.alm.flutnet.org> * Erik Stian Tefre [2009-06-17 12:34]: > Jordi Espasa Clofent wrote: > > ?How can I upgrade the OpenSSH in the _same_ RELENG? ?Maybe using the > > ports? > > portsnap fetch update > cd /usr/ports/security/openssh-portable/ > make install clean > /etc/rc.d/sshd stop > Set sshd_enable="NO" in /etc/rc.conf > Set openssh_enable="YES" in /etc/rc.conf > /usr/local/etc/rc.d/openssh start > > This will enable the 5.2p1 sshd. > The new client is installed as /usr/local/bin/ssh. You can also set OVERWRITE_BASE in the config menu that will pop up if you compile the openssh-portable port for the first time (or just do make config). This will install openssh in /usr. I added NO_OPENSSH=yes to make.conf (src.conf in 7.0+) so a subsequent make installworld won't overwrite it again. This will make life easier IMO because you don't have two different versions of ssh around. Having the SSH version depend on your $PATH and whether you have /usr/local mounted can be confusing, although this is not an issue for sshd. Alson From pluknet at gmail.com Wed Jun 17 12:13:33 2009 From: pluknet at gmail.com (pluknet) Date: Wed Jun 17 12:13:40 2009 Subject: panic on 6.4-R in ioapic_get_vector() during device probe Message-ID: Hi. This is on 6.4-RELEASE-p5 Early in boot (probably due to network outage):: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text*0x44f40 | readin failed elf32*loadimage: read failed GDB: no debug ports present and then.. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz (2826.26-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x40ce3bd,> AMD Features=0x20000000 AMD Features2=0x1 Cores per package: 4 real memory = 3220992000 (3071 MB) avail memory = 3150835712 (3004 MB) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 user VMEM accounting on ioapic0: Assuming intbase of 0 MPTable: Ignoring interrupt entry for missing ioapic0 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cpu0 on motherboard cpu1 on motherboard cpu2 on motherboard cpu3 on motherboard cpu4 on motherboard cpu5 on motherboard cpu6 on motherboard cpu7 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 2.0 on pci0 pci26: on pcib1 pcib2: at device 0.0 on pci26 pci27: on pcib2 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x2e fault code = supervisor read, page not present instruction pointer = 0x20:0xc08d0b72 stack pointer = 0x28:0xc0c208fc frame pointer = 0x28:0xc0c20900 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at ioapic_get_vector+0xa: movw 0x2e(%ebx),%ax db> db> bt Tracing pid 0 tid 0 td 0xc0a48dc0 ioapic_get_vector(0,2) at ioapic_get_vector+0xa mptable_pci_route_interrupt_handler(c009c0cc,c0c20944,c0c20944,1,c7d4a480,...) a t mptable_pci_route_interrupt_handler+0x2d mptable_walk_table(c08d9880,c0c20944) at mptable_walk_table+0x3d mptable_pci_route_interrupt(c7d4a380,c7d4a480,1) at mptable_pci_route_interrupt+ 0xd4 pci_assign_interrupt_method(c7d4a180,c7d4a480) at pci_assign_interrupt_method+0x 58 pci_assign_interrupt(c7d4a180,c7d4a480,1) at pci_assign_interrupt+0xc0 pci_add_resources(c7d4a180,c7d4a480,0,0,c7dfa000,...) at pci_add_resources+0x2b5 pci_add_child(c7d4a180,c7dfa000) at pci_add_child+0x52 pci_add_children(c7d4a180,1b,c4,1b,c7d4a180,...) at pci_add_children+0xf2 pci_attach(c7d4a180) at pci_attach+0x7c device_attach(c7d4a180,c0c20adc,c7d4a180,c7d4a380,0,...) at device_attach+0x58 device_probe_and_attach(c7d4a180) at device_probe_and_attach+0xc4 bus_generic_attach(c7d4a380,c7d4a380,c0c20b08,c06c4acc,c7d4a380,...) at bus_gene ric_attach+0x16 pcib_attach(c7d4a380) at pcib_attach+0x39 device_attach(c7d4a380,e,c7d4a380,c7d4a280,c7d4a280,...) at device_attach+0x58 device_probe_and_attach(c7d4a380) at device_probe_and_attach+0xc4 bus_generic_attach(c7d4a280,c7d4a280,1a,c4,1a,...) at bus_generic_attach+0x16 pci_attach(c7d4a280) at pci_attach+0x82 device_attach(c7d4a280,c0c20b94,c7d4a280,c7df9280,0,...) at device_attach+0x58 device_probe_and_attach(c7d4a280) at device_probe_and_attach+0xc4 bus_generic_attach(c7df9280,c7df9280,c0c20bc0,c06c4acc,c7df9280,...) at bus_gene ric_attach+0x16 pcib_attach(c7df9280) at pcib_attach+0x39 device_attach(c7df9280,7,c7df9280,c7df9380,c7df9380,...) at device_attach+0x58 device_probe_and_attach(c7df9280) at device_probe_and_attach+0xc4 bus_generic_attach(c7df9380,c7df9380,0,c4,0,...) at bus_generic_attach+0x16 pci_attach(c7df9380) at pci_attach+0x82 device_attach(c7df9380,c7d49080,c7df9380,c7df9400,c7df9400,...) at device_attach +0x58 device_probe_and_attach(c7df9380) at device_probe_and_attach+0xc4 bus_generic_attach(c7df9400,c7df9400,c097f501,0,0,...) at bus_generic_attach+0x1 6 mptable_hostb_attach(c7df9400) at mptable_hostb_attach+0x69 device_attach(c7df9400,c0a2cb60,c7df9400,7,c7d49080,...) at device_attach+0x58 device_probe_and_attach(c7df9400) at device_probe_and_attach+0xc4 bus_generic_attach(c7d49080,c7d49080,c7d49080,c7d49080,0,...) at bus_generic_att ach+0x16 legacy_attach(c7d49080) at legacy_attach+0x8e device_attach(c7d49080,0,c7d49080,c7d49680,0,...) at device_attach+0x58 device_probe_and_attach(c7d49080) at device_probe_and_attach+0xc4 bus_generic_attach(c7d49680,c7d49680,c7d49680,c0c20d40,c06c4acc,...) at bus_gene ric_attach+0x16 nexus_attach(c7d49680) at nexus_attach+0x13 device_attach(c7d49680,c06cfe58,c7d49680,c0a173f0,c25000,...) at device_attach+0 x58 device_probe_and_attach(c7d49680) at device_probe_and_attach+0xc4 root_bus_configure(c0c20d88,c067ab96,0,c1ec00,c1e000,...) at root_bus_configure+ 0x16 configure(0,c1ec00,c1e000,0,c0452555,...) at configure+0x9 mi_startup() at mi_startup+0x96 begin() at begin+0x2c -- wbr, pluknet From jhb at freebsd.org Wed Jun 17 12:29:40 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jun 17 12:29:47 2009 Subject: Unnamed POSIX shared semaphores In-Reply-To: <4A37A591.1070907@incunabulum.net> References: <4A37A591.1070907@incunabulum.net> Message-ID: <200906170808.51060.jhb@freebsd.org> On Tuesday 16 June 2009 10:00:49 am Bruce Simpson wrote: > Vlad Galu wrote: > > ... > > Thanks, Ivan. I'll take a better look at this after our first release, > > which is due in a couple of weeks. Right now the team efforts aren't > > focused on portability, so it's a low priority issue, but something > > we'd definitely like to have in the future. > > > > I've just run head first into this lack for a proof-of-concept I'm > looking at -- the lack of PTHREAD_PROCESS_SHARED support on FreeBSD. > > Are there any other references I can start working from? You can check the archives of threads@ where this has been discussed recently. -- John Baldwin From matheus at eternamente.info Wed Jun 17 14:09:14 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Wed Jun 17 14:09:23 2009 Subject: ZFS pool from current Message-ID: <80e5e7a7219ab28dfc5d821f14c1ba1e.squirrel@cygnus.homeunix.com> hail, I have a 8-current using a small zfs pool: [root@harry ~]# zpool status pool: zdados state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zdados ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 errors: No known data errors FreeBSD harry.tre-pb.gov.br 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Tue May 26 16:00:50 BRT 2009 root@harry.tre-pb.gov.br:/usr/obj/usr/src/sys/Core2Duo8 amd64 And for virtualbox on amd64 purposes I want to run 7.2R or STABLE to use VT-x and amd64 vm's under vbox. will I have to make anything, or it will just work ? Kip Macy created a branch were there is the new zfs code, but I didn't get it if it is in the main sources or if I need to fetch any especial code. any hints are good, thanks matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From dimitry at andric.com Wed Jun 17 14:16:14 2009 From: dimitry at andric.com (Dimitry Andric) Date: Wed Jun 17 14:16:22 2009 Subject: ZFS pool from current In-Reply-To: <80e5e7a7219ab28dfc5d821f14c1ba1e.squirrel@cygnus.homeunix.com> References: <80e5e7a7219ab28dfc5d821f14c1ba1e.squirrel@cygnus.homeunix.com> Message-ID: <4A38FAAE.7060100@andric.com> On 2009-06-17 16:09, Nenhum_de_Nos wrote: > And for virtualbox on amd64 purposes I want to run 7.2R or STABLE to use > VT-x and amd64 vm's under vbox. will I have to make anything, or it will > just work ? > > Kip Macy created a branch were there is the new zfs code, but I didn't get > it if it is in the main sources or if I need to fetch any especial code. Kip merged the ZFS v13 support to -STABLE just last month. It seems to work okay for most people, but be sure to read the UPDATING file, especially if you are upgrading existing pools. From matheus at eternamente.info Wed Jun 17 14:23:48 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Wed Jun 17 14:24:02 2009 Subject: ZFS pool from current In-Reply-To: <4A38FAAE.7060100@andric.com> References: <80e5e7a7219ab28dfc5d821f14c1ba1e.squirrel@cygnus.homeunix.com> <4A38FAAE.7060100@andric.com> Message-ID: On Wed, June 17, 2009 11:16, Dimitry Andric wrote: > On 2009-06-17 16:09, Nenhum_de_Nos wrote: >> And for virtualbox on amd64 purposes I want to run 7.2R or STABLE to use >> VT-x and amd64 vm's under vbox. will I have to make anything, or it will >> just work ? >> >> Kip Macy created a branch were there is the new zfs code, but I didn't >> get >> it if it is in the main sources or if I need to fetch any especial code. > > Kip merged the ZFS v13 support to -STABLE just last month. It seems to > work okay for most people, but be sure to read the UPDATING file, > especially if you are upgrading existing pools. thanks, I was just looking for this update on web interface to cvs and there is nothing in UPDATING for RELENG_7 there. is this really supposed to happen ? I'll get from csup now ... thanks again, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From emaste at freebsd.org Wed Jun 17 14:41:56 2009 From: emaste at freebsd.org (Ed Maste) Date: Wed Jun 17 14:42:29 2009 Subject: 6.2 sporadically locks up In-Reply-To: References: <200906160830.29721.jhb@freebsd.org> Message-ID: <20090617142952.GA73887@sandvine.com> On Tue, Jun 16, 2009 at 07:03:34PM +0400, pluknet wrote: > As for allpcpu, I often see the picture, when one CPU runs the "irq17: > bce1 aacu0" thread > and another one runs arcconf. I wonder if that might be a source of > bad locking or races, or.. > The arcconf utility uses ioctl that goes into aac/aacu(4) internals. Do you see the same result w/ the in-tree aac(4) driver as opposed to Adaptec's version? -Ed From pluknet at gmail.com Wed Jun 17 14:45:59 2009 From: pluknet at gmail.com (pluknet) Date: Wed Jun 17 14:46:07 2009 Subject: 6.2 sporadically locks up In-Reply-To: <20090617142952.GA73887@sandvine.com> References: <200906160830.29721.jhb@freebsd.org> <20090617142952.GA73887@sandvine.com> Message-ID: 2009/6/17 Ed Maste : > On Tue, Jun 16, 2009 at 07:03:34PM +0400, pluknet wrote: > >> As for allpcpu, I often see the picture, when one CPU runs the "irq17: >> bce1 aacu0" thread >> and another one runs arcconf. I wonder if that might be a source of >> bad locking or races, or.. >> The arcconf utility uses ioctl that goes into aac/aacu(4) internals. > > Do you see the same result w/ the in-tree aac(4) driver as opposed to > Adaptec's version? > > -Ed > [It's quite hard to move back to aac(4) as that requires fstab update [ aacdu0 -> aacd0] and instant reboot, because we use quotas and quotacheck looks into /etc/fstab. Such preparations as fstab update and commenting out load_aacu="YES" will give discrepancy between fstab and actual mount points.] I will try anyway. Thank you for your help. -- wbr, pluknet From hlh at restart.be Wed Jun 17 14:51:15 2009 From: hlh at restart.be (Henri Hennebert) Date: Wed Jun 17 14:51:23 2009 Subject: ZFS pool from current In-Reply-To: References: <80e5e7a7219ab28dfc5d821f14c1ba1e.squirrel@cygnus.homeunix.com> <4A38FAAE.7060100@andric.com> Message-ID: <4A3902DE.3070708@restart.be> Nenhum_de_Nos wrote: > On Wed, June 17, 2009 11:16, Dimitry Andric wrote: >> On 2009-06-17 16:09, Nenhum_de_Nos wrote: >>> And for virtualbox on amd64 purposes I want to run 7.2R or STABLE to use >>> VT-x and amd64 vm's under vbox. will I have to make anything, or it will >>> just work ? >>> >>> Kip Macy created a branch were there is the new zfs code, but I didn't >>> get >>> it if it is in the main sources or if I need to fetch any especial code. >> Kip merged the ZFS v13 support to -STABLE just last month. It seems to >> work okay for most people, but be sure to read the UPDATING file, >> especially if you are upgrading existing pools. > > thanks, I was just looking for this update on web interface to cvs and > there is nothing in UPDATING for RELENG_7 there. is this really supposed > to happen ? Sadly a known and ignored problem of cvsweb http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/120185 Henri > > I'll get from csup now ... > > thanks again, > > matheus > From joe at osoft.us Wed Jun 17 16:07:58 2009 From: joe at osoft.us (Joe Koberg) Date: Wed Jun 17 16:08:06 2009 Subject: ZFS performance on 7.2-release/amd64 low compared to UFS2 + SoftUpdates In-Reply-To: References: Message-ID: <4A390E57.9010701@osoft.us> The difference in layout can easily explain a 2x difference in sequential transfer performance. I seriously doubt your disk is really getting 23K seeks/s done in the UFS case - 100/s sounds much more reasonable for real hardware. Perhaps the results of caching? Joe Koberg Dan Naumov wrote: > I am wondering if the numbers I am seeing is something expected or is > something broken somewhere. Output of bonnie -s 1024: > > on UFS2 + SoftUpdates: > > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 1024 56431 94.5 88407 38.9 77357 53.3 64042 98.6 644511 98.6 23603.8 243.3 > > on ZFS: > > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 1024 22591 53.7 45602 35.1 14770 13.2 45007 83.8 94595 28.0 102.2 1.2 > > > atom# cat /boot/loader.conf > vm.kmem_size="1024M" > vm.kmem_size_max="1024M" > vfs.zfs.arc_max="96M" > > The test isn't completely fair in that the test on UFS2 is done on a > partition that resides on the first 16gb of a 2tb disk while the zfs > test is done on the enormous 1,9tb zfs pool that comes after that > partition (same disk). Can this difference in layout make up for the > huge difference in performance or is there something else in play? The > system is an Intel Atom 330 dualcore, 2gb ram, Western Digital Green > 2tb disk. Also what would be another good way to get good numbers for > comparing the performance of UFS2 vs ZFS on the same system. > > > Sincerely, > - Dan Naumov > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From dnelson at allantgroup.com Wed Jun 17 16:11:14 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Jun 17 16:11:21 2009 Subject: ZFS performance on 7.2-release/amd64 low compared to UFS2 + SoftUpdates In-Reply-To: References: Message-ID: <20090617161109.GA12966@dan.emsphone.com> In the last episode (Jun 17), Dan Naumov said: > I am wondering if the numbers I am seeing is something expected or is > something broken somewhere. Output of bonnie -s 1024: > > on UFS2 + SoftUpdates: > > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 1024 56431 94.5 88407 38.9 77357 53.3 64042 98.6 644511 98.6 23603.8 243.3 The insane sequential input K/sec and random seeks/sec values indicate that your entire test file was cached in memory. Try a larger file (at least 2x your installed RAM). > on ZFS: > > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 1024 22591 53.7 45602 35.1 14770 13.2 45007 83.8 94595 28.0 102.2 1.2 > -- Dan Nelson dnelson@allantgroup.com From gavin.atkinson at ury.york.ac.uk Wed Jun 17 17:31:14 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Wed Jun 17 17:31:21 2009 Subject: ZFS pool from current In-Reply-To: <4A3902DE.3070708@restart.be> References: <80e5e7a7219ab28dfc5d821f14c1ba1e.squirrel@cygnus.homeunix.com> <4A38FAAE.7060100@andric.com> <4A3902DE.3070708@restart.be> Message-ID: <1245258026.40309.50.camel@buffy.york.ac.uk> On Wed, 2009-06-17 at 16:51 +0200, Henri Hennebert wrote: > Nenhum_de_Nos wrote: > > thanks, I was just looking for this update on web interface to cvs and > > there is nothing in UPDATING for RELENG_7 there. is this really supposed > > to happen ? > > Sadly a known and ignored problem of cvsweb > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/120185 > > Henri As far as I can tell, this isn't really a problem with cvsweb, but more of a problem with the repository itself. The issue comes when a commit is made and the log message includes the magic string that CVS uses internally to track different revisions. The patch proposed in that PR appears to be more of a hack than a fix. It's the same reason that (for example) http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/ntpd lists a revision 1.335 even though the most recent commit was version 1.18. On the upside, it doesn't appear that these bogus commits have ended up replicated in the SVN repository. Gavin From hlh at restart.be Wed Jun 17 18:48:53 2009 From: hlh at restart.be (Henri Hennebert) Date: Wed Jun 17 18:49:00 2009 Subject: ZFS pool from current In-Reply-To: <1245258026.40309.50.camel@buffy.york.ac.uk> References: <80e5e7a7219ab28dfc5d821f14c1ba1e.squirrel@cygnus.homeunix.com> <4A38FAAE.7060100@andric.com> <4A3902DE.3070708@restart.be> <1245258026.40309.50.camel@buffy.york.ac.uk> Message-ID: <4A393A8F.5000909@restart.be> Gavin Atkinson wrote: > On Wed, 2009-06-17 at 16:51 +0200, Henri Hennebert wrote: >> Nenhum_de_Nos wrote: >>> thanks, I was just looking for this update on web interface to cvs and >>> there is nothing in UPDATING for RELENG_7 there. is this really supposed >>> to happen ? >> Sadly a known and ignored problem of cvsweb >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/120185 >> >> Henri > > As far as I can tell, this isn't really a problem with cvsweb, but more > of a problem with the repository itself. The issue comes when a commit > is made and the log message includes the magic string that CVS uses > internally to track different revisions. The patch proposed in that PR > appears to be more of a hack than a fix. Ok with that but there is no fix if you base your algorithm on a wrong specification. > > It's the same reason that (for example) > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/ntpd lists a revision > 1.335 even though the most recent commit was version 1.18. The hack work well in this case too. I prefer a hack instead of a confusing answer. Henri > > On the upside, it doesn't appear that these bogus commits have ended up > replicated in the SVN repository. > > Gavin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From ronald-freebsd8 at klop.yi.org Wed Jun 17 23:51:17 2009 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Wed Jun 17 23:51:30 2009 Subject: ZFS performance on 7.2-release/amd64 low compared to UFS2 + SoftUpdates In-Reply-To: References: Message-ID: On Wed, 17 Jun 2009 09:34:02 +0200, Dan Naumov wrote: > I am wondering if the numbers I am seeing is something expected or is > something broken somewhere. Output of bonnie -s 1024: > > on UFS2 + SoftUpdates: > > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > /sec %CPU > 1024 56431 94.5 88407 38.9 77357 53.3 64042 98.6 644511 98.6 > 23603.8 243.3 > > on ZFS: > > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > /sec %CPU > 1024 22591 53.7 45602 35.1 14770 13.2 45007 83.8 94595 28.0 > 102.2 1.2 > > > atom# cat /boot/loader.conf > vm.kmem_size="1024M" > vm.kmem_size_max="1024M" > vfs.zfs.arc_max="96M" Isn't 96M for ARC really small? Mine is 860M. vfs.zfs.arc_max: 860072960 kstat.zfs.misc.arcstats.size: 657383376 I think the UFS2 cache is much bigger which makes a difference in your test. Ronald. From dan.naumov at gmail.com Thu Jun 18 00:07:56 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Thu Jun 18 00:08:08 2009 Subject: ZFS performance on 7.2-release/amd64 low compared to UFS2 + SoftUpdates In-Reply-To: References: Message-ID: All the ZFS tuning guides for FreeBSD (including one on the FreeBSD ZFS wiki) have recommended values between 64M and 128M to improve stability, so that what I went with. How much of my max kmem is it safe to give to ZFS? - Dan Naumov On Thu, Jun 18, 2009 at 2:51 AM, Ronald Klop wrote: > Isn't 96M for ARC really small? > Mine is 860M. > vfs.zfs.arc_max: 860072960 > kstat.zfs.misc.arcstats.size: 657383376 > > I think the UFS2 cache is much bigger which makes a difference in your test. > > Ronald. > From petefrench at ticketswitch.com Thu Jun 18 08:29:04 2009 From: petefrench at ticketswitch.com (Pete French) Date: Thu Jun 18 08:29:11 2009 Subject: ZFS performance on 7.2-release/amd64 low compared to UFS2 + SoftUpdates In-Reply-To: Message-ID: > All the ZFS tuning guides for FreeBSD (including one on the FreeBSD > ZFS wiki) have recommended values between 64M and 128M to improve > stability, so that what I went with. How much of my max kmem is it > safe to give to ZFS? If you are on amd64 then don't tune it, it will tune itself. If you are on i386 (or an earlier verions of amd64) then 128M on a 2 gig machine should be OK, assuming you have kmem_size_max set to the full 1500 odd. Those are numbers which come up time and time again - I ran reliably with them for ages, until the latest -STABLE. -pete. From erwan at rail.eu.org Thu Jun 18 08:35:00 2009 From: erwan at rail.eu.org (Erwan David) Date: Thu Jun 18 08:35:07 2009 Subject: Upgrade from 7.1-RELEASE to 7.2-RELEASE through freebsd update Message-ID: <20090618083454.GQ5002@trusted-logic.com> I tried to upgrade my 7.1-RELEASE into 7.2-RELEASE. However freebsd-update kept asking me to merge every file in /etc whose $Id$ line changed (that makes about all files). Is there a way, as with mergemaster, to make it not consider the $Id$ line for the manual merge ? Thank you. -- Erwan From mail25 at bzerk.org Thu Jun 18 12:38:08 2009 From: mail25 at bzerk.org (Ruben de Groot) Date: Thu Jun 18 12:38:15 2009 Subject: Upgrade from 7.1-RELEASE to 7.2-RELEASE through freebsd update In-Reply-To: <20090618083454.GQ5002@trusted-logic.com> References: <20090618083454.GQ5002@trusted-logic.com> Message-ID: <20090618123802.GA27215@ei.bzerk.org> On Thu, Jun 18, 2009 at 10:34:54AM +0200, Erwan David typed: > I tried to upgrade my 7.1-RELEASE into 7.2-RELEASE. However > freebsd-update kept asking me to merge every file in /etc whose $Id$ > line changed (that makes about all files). > > Is there a way, as with mergemaster, to make it not consider the $Id$ > line for the manual merge ? You could let freebsd-update ignore /etc (but not /usr/src) and use mergemaster for your configuration files. Ruben From jhb at freebsd.org Thu Jun 18 13:37:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 18 13:39:46 2009 Subject: panic on 6.4-R in ioapic_get_vector() during device probe In-Reply-To: References: Message-ID: <200906180921.09912.jhb@freebsd.org> On Wednesday 17 June 2009 8:13:31 am pluknet wrote: > Hi. > > This is on 6.4-RELEASE-p5 > > Early in boot (probably due to network outage):: > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > /boot/kernel/acpi.ko text*0x44f40 | > readin failed > > elf32*loadimage: read failed > GDB: no debug ports present > > and then.. > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz (2826.26-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 > Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x40ce3bd ,,> > AMD Features=0x20000000 > AMD Features2=0x1 > Cores per package: 4 > real memory = 3220992000 (3071 MB) > avail memory = 3150835712 (3004 MB) > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > user VMEM accounting on > ioapic0: Assuming intbase of 0 > MPTable: Ignoring interrupt entry for missing ioapic0 > ioapic0 irqs 0-23 on motherboard The 'ignoring interrupt entry' message is very odd. Can you get output from 'mptable'? Are you able to boot with ACPI enabled? At this point I would not be surprised if the MP Table was just flat wrong on modern machines as it seems many BIOS vendors do not test it anymore but only test the ACPI tables. -- John Baldwin From pluknet at gmail.com Thu Jun 18 14:05:16 2009 From: pluknet at gmail.com (pluknet) Date: Thu Jun 18 14:05:24 2009 Subject: panic on 6.4-R in ioapic_get_vector() during device probe In-Reply-To: <200906180921.09912.jhb@freebsd.org> References: <200906180921.09912.jhb@freebsd.org> Message-ID: 2009/6/18 John Baldwin : > On Wednesday 17 June 2009 8:13:31 am pluknet wrote: >> Hi. >> >> This is on 6.4-RELEASE-p5 >> >> Early in boot (probably due to network outage):: >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> /boot/kernel/acpi.ko text*0x44f40 | >> readin failed >> >> elf32*loadimage: read failed >> GDB: no debug ports present >> >> and then.. >> >> >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(R) CPU ? ? ? ? ? E5440 ?@ 2.83GHz (2826.26-MHz 686-class > CPU) >> ? Origin = "GenuineIntel" ?Id = 0x1067a ?Stepping = 10 >> > Features=0xbfebfbff> MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> > Features2=0x40ce3bd> ,,> >> ? AMD Features=0x20000000 >> ? AMD Features2=0x1 >> ? Cores per package: 4 >> real memory ?= 3220992000 (3071 MB) >> avail memory = 3150835712 (3004 MB) >> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> ?cpu0 (BSP): APIC ID: ?0 >> ?cpu1 (AP): APIC ID: ?1 >> ?cpu2 (AP): APIC ID: ?2 >> ?cpu3 (AP): APIC ID: ?3 >> ?cpu4 (AP): APIC ID: ?4 >> ?cpu5 (AP): APIC ID: ?5 >> ?cpu6 (AP): APIC ID: ?6 >> ?cpu7 (AP): APIC ID: ?7 >> user VMEM accounting on >> ioapic0: Assuming intbase of 0 >> MPTable: Ignoring interrupt entry for missing ioapic0 >> ioapic0 irqs 0-23 on motherboard > > The 'ignoring interrupt entry' message is very odd. ?Can you get output > from 'mptable'? I'm afraid that panic was only once and due to acpi.ko network load problem. I can boot this box with acpi opted out explicitly if it makes sense, also in order to reproduce those conditions. >?Are you able to boot with ACPI enabled? Of course. These boxes boot always fine with ACPI enabled. Below is part of related dmesg (now from from 7.2) with ACPI enabled: --- FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0 irqs 0-23 on motherboard --- >?At this point I > would not be surprised if the MP Table was just flat wrong on modern machines > as it seems many BIOS vendors do not test it anymore but only test the ACPI > tables. >: # mptable =============================================================================== MPTable ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: EBDA physical address: 0x0009ad40 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0xc9 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x0009be10 signature: 'PCMP' base table length: 716 version: 1.4 checksum: 0xd6 OEM ID: 'IBM ENSW' Product ID: 'x3650 SMP ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 72 local APIC address: 0xfee00000 extended table length: 328 extended table checksum: 217 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x14 BSP, usable 6 7 10 0x0301 1 0x14 AP, usable 6 7 10 0x0301 2 0x14 AP, usable 6 7 10 0x0301 3 0x14 AP, usable 6 7 10 0x0301 4 0x14 AP, usable 6 7 10 0x0301 5 0x14 AP, usable 6 7 10 0x0301 6 0x14 AP, usable 6 7 10 0x0301 7 0x14 AP, usable 6 7 10 0x0301 -- Bus: Bus ID Type 0 PCI 1 PCI 2 PCI 3 PCI 4 PCI 5 PCI 6 PCI 7 PCI 8 PCI 9 PCI 10 PCI 11 PCI 12 PCI 13 PCI 14 PCI 15 PCI 16 PCI 17 PCI 18 PCI 19 PCI 20 PCI 21 PCI 22 PCI 23 PCI 24 PCI 25 PCI 26 PCI 27 PCI 28 PCI 29 PCI 30 PCI 31 PCI 32 PCI 33 PCI 34 PCI 35 PCI 36 PCI 37 PCI 38 ISA -- I/O APICs: APIC ID Version State Address 14 0x20 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# INT conforms conforms 38 1 14 1 INT conforms conforms 38 0 14 2 INT conforms conforms 38 3 14 3 INT conforms conforms 38 6 14 6 INT active-hi edge 38 8 14 8 INT conforms conforms 38 9 14 9 INT conforms conforms 38 12 14 12 INT conforms conforms 38 13 14 13 INT conforms conforms 38 14 14 14 INT conforms conforms 38 15 14 15 INT conforms conforms 0 8:A 14 16 INT conforms conforms 0 29:A 14 23 INT conforms conforms 0 29:B 14 22 INT conforms conforms 0 29:C 14 23 INT conforms conforms 0 29:D 14 22 INT conforms conforms 0 29:A 14 23 INT conforms conforms 0 31:B 14 20 INT conforms conforms 1 6:A 14 22 INT conforms conforms 3 0:A 14 16 INT conforms conforms 4 0:A 14 17 INT conforms conforms 6 0:A 14 17 INT conforms conforms 27 1:A 0 2 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# NMI conforms conforms 38 0 255 1 ExtINT conforms conforms 38 0 255 0 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- System Address Space bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x20000 -- System Address Space bus ID: 0 address type: memory address address base: 0xd4000 address range: 0xc000 -- System Address Space bus ID: 0 address type: memory address address base: 0xde000000 address range: 0x2000000 -- System Address Space bus ID: 0 address type: prefetch address address base: 0xd0010000 address range: 0xdff0000 -- System Address Space bus ID: 0 address type: memory address address base: 0xcd000000 address range: 0x3000000 -- System Address Space bus ID: 0 address type: memory address address base: 0xc8000000 address range: 0x2000000 -- System Address Space bus ID: 0 address type: prefetch address address base: 0xc7f00000 address range: 0x100000 -- System Address Space bus ID: 0 address type: I/O address address base: 0x0 address range: 0x3b0 -- System Address Space bus ID: 0 address type: I/O address address base: 0x3b0 address range: 0xc -- System Address Space bus ID: 0 address type: I/O address address base: 0x3bc address range: 0x4 -- System Address Space bus ID: 0 address type: I/O address address base: 0x3c0 address range: 0x20 -- System Address Space bus ID: 0 address type: I/O address address base: 0x3e0 address range: 0x2c20 -- System Address Space bus ID: 0 address type: I/O address address base: 0x3000 address range: 0x2000 -- System Address Space bus ID: 0 address type: I/O address address base: 0xff00 address range: 0x100 -- System Address Space bus ID: 0 address type: I/O address address base: 0x6000 address range: 0xa000 -- System Address Space bus ID: 0 address type: I/O address address base: 0x5000 address range: 0x1000 -- Bus Heirarchy bus ID: 38 bus info: 0x01 parent bus ID: 0 =============================================================================== -- wbr, pluknet From webmaster at kibab.com Thu Jun 18 14:14:48 2009 From: webmaster at kibab.com (Ilya Bakulin) Date: Thu Jun 18 14:15:21 2009 Subject: Issues with gjournal (heaaaaaaaaaaalp!) In-Reply-To: <7d6fde3d0906102324i7c296d40pdf5a5e853c359bc3@mail.gmail.com> References: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> <7d6fde3d0906102324i7c296d40pdf5a5e853c359bc3@mail.gmail.com> Message-ID: <20090618181558.73adfe0e.webmaster@kibab.com> On Wed, 10 Jun 2009 23:24:49 -0700 Garrett Cooper wrote: > Hi Dan, > > I'm doing that right now =\... > > orangebox# mount > /dev/ad6s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/ad6s1d.journal on /usr (ufs, asynchronous, local) > /dev/ad6s1e on /usr/home (ufs, local) > /dev/ad6s1f on /var (ufs, local) > > Thanks! > -Garrett GJournal actually doesn't work on your box now. To make it work, you MUST use special flag "-J" to newfs. See beginning of newfs(8). After you do newfs -O2 -J /dev/ad6s1d.journal and mount it, you will see somehow different "mount" output: ============================================================= kibab@kibab-nb%mount /dev/ad4s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/label/Home on /home (ufs, asynchronous, local, gjournal) ============================================================= Notice "gjournal" flag in brackets. You output doesn't contain it... -- Ilya Bakulin xmpp://kibab612@jabber.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090618/d1048980/attachment.pgp From jhb at freebsd.org Thu Jun 18 15:00:48 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 18 15:00:57 2009 Subject: panic on 6.4-R in ioapic_get_vector() during device probe In-Reply-To: References: <200906180921.09912.jhb@freebsd.org> Message-ID: <200906181012.36012.jhb@freebsd.org> On Thursday 18 June 2009 10:05:14 am pluknet wrote: > 2009/6/18 John Baldwin : > > On Wednesday 17 June 2009 8:13:31 am pluknet wrote: > >> Hi. > >> > >> This is on 6.4-RELEASE-p5 > >> > >> Early in boot (probably due to network outage):: > >> Hit [Enter] to boot immediately, or any other key for command prompt. > >> Booting [/boot/kernel/kernel]... > >> /boot/kernel/acpi.ko text*0x44f40 | > >> readin failed > >> > >> elf32*loadimage: read failed > >> GDB: no debug ports present > >> > >> and then.. > >> > >> > >> Timecounter "i8254" frequency 1193182 Hz quality 0 > >> CPU: Intel(R) Xeon(R) CPU ? ? ? ? ? E5440 ?@ 2.83GHz (2826.26-MHz 686-class > > CPU) > >> ? Origin = "GenuineIntel" ?Id = 0x1067a ?Stepping = 10 > >> > > Features=0xbfebfbff >> MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > >> > > Features2=0x40ce3bd >> ,,> > >> ? AMD Features=0x20000000 > >> ? AMD Features2=0x1 > >> ? Cores per package: 4 > >> real memory ?= 3220992000 (3071 MB) > >> avail memory = 3150835712 (3004 MB) > >> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > >> ?cpu0 (BSP): APIC ID: ?0 > >> ?cpu1 (AP): APIC ID: ?1 > >> ?cpu2 (AP): APIC ID: ?2 > >> ?cpu3 (AP): APIC ID: ?3 > >> ?cpu4 (AP): APIC ID: ?4 > >> ?cpu5 (AP): APIC ID: ?5 > >> ?cpu6 (AP): APIC ID: ?6 > >> ?cpu7 (AP): APIC ID: ?7 > >> user VMEM accounting on > >> ioapic0: Assuming intbase of 0 > >> MPTable: Ignoring interrupt entry for missing ioapic0 > >> ioapic0 irqs 0-23 on motherboard > > > > The 'ignoring interrupt entry' message is very odd. ?Can you get output > > from 'mptable'? > > I'm afraid that panic was only once and due to acpi.ko network load problem. > I can boot this box with acpi opted out explicitly if it makes sense, > also in order to reproduce those conditions. Ah, ok. Your MP Table is just plain busted so you will get this panic if you boot with ACPI disabled. You can just compile ACPI into your kernel to ensure you never boot without it. -- John Baldwin From fjwcash at gmail.com Thu Jun 18 15:25:51 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Jun 18 15:25:58 2009 Subject: ZFS performance on 7.2-release/amd64 low compared to UFS2 + SoftUpdates In-Reply-To: References: Message-ID: On Thu, Jun 18, 2009 at 1:29 AM, Pete French wrote: > > All the ZFS tuning guides for FreeBSD (including one on the FreeBSD > > ZFS wiki) have recommended values between 64M and 128M to improve > > stability, so that what I went with. How much of my max kmem is it > > safe to give to ZFS? > > If you are on amd64 then don't tune it, it will tune itself. If you > are on i386 (or an earlier verions of amd64) then 128M on a 2 gig machine > should be OK, assuming you have kmem_size_max set to the full 1500 odd. > Those are numbers which come up time and time again - I ran reliably with > them for ages, until the latest -STABLE. > My "rule of thumb" for 32-bit i386 systems has been to: - assign half of RAM to kmem (up to the max of ~1500 on 7.0/7.1) - assign half of kmem to zfs_arc_max So far, for my workloads (nfs/cifs file servers, cups print servers, rsync servers, kde4 desktop), it's worked well. -- Freddie Cash fjwcash@gmail.com From borjam at sarenet.es Thu Jun 18 15:52:17 2009 From: borjam at sarenet.es (Borja Marcos) Date: Thu Jun 18 15:52:25 2009 Subject: ZFS user library? Message-ID: Hello, I was wondering if there are plans to document and keep the ZFS user library as a reasonably stable API. I have been writing an automatic replication program, and it's ugly and clumsy to do it calling a user program. I would rather prefer to use an API, that would make it much easier to retrieve error messages, etc. Borja. From kmacy at freebsd.org Thu Jun 18 17:21:46 2009 From: kmacy at freebsd.org (Kip Macy) Date: Thu Jun 18 17:21:52 2009 Subject: ZFS user library? In-Reply-To: References: Message-ID: <3c1674c90906181021n54bd6fbei2a1a843033bc91c@mail.gmail.com> > 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 From matheus at eternamente.info Thu Jun 18 17:34:19 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Thu Jun 18 17:34:28 2009 Subject: xorg and intel driver Message-ID: hail, I know this was here before, http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004775.html, but there was no happy ending there ... is there any news ? I have a STABLE from yesterday and the xorg is too much slow. xorg is from 7.2R cdrom, intel video driver is from today. card is vgapci0@pci0:0:2:0: class=0x030000 card=0x50448086 chip=0x29c28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'P35/G33 (Bearlake) Integrated Graphics Controller' class = display subclass = VGA if more info is needed, thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From erwan at rail.eu.org Thu Jun 18 18:09:18 2009 From: erwan at rail.eu.org (Erwan David) Date: Thu Jun 18 18:10:51 2009 Subject: Upgrade from 7.1-RELEASE to 7.2-RELEASE through freebsd update In-Reply-To: <20090618123802.GA27215@ei.bzerk.org> References: <20090618083454.GQ5002@trusted-logic.com> <20090618123802.GA27215@ei.bzerk.org> Message-ID: <20090618180914.GA49300@rail.eu.org> Le Thu 18/06/2009, Ruben de Groot disait > On Thu, Jun 18, 2009 at 10:34:54AM +0200, Erwan David typed: > > I tried to upgrade my 7.1-RELEASE into 7.2-RELEASE. However > > freebsd-update kept asking me to merge every file in /etc whose $Id$ > > line changed (that makes about all files). > > > > Is there a way, as with mergemaster, to make it not consider the $Id$ > > line for the manual merge ? > > You could let freebsd-update ignore /etc (but not /usr/src) and use > mergemaster for your configuration files. > > > Ruben I do not master enough either freebsd-update nor mergemaster to tell the former not to do the merge, but only download what is necessary for the latter to work. If I understand well, I can tell not to touch /etc (removing it from MergeChanges), but I would not be able to find what is then needed for mergemaster. -- Erwan From mp at research.att.com Thu Jun 18 20:27:41 2009 From: mp at research.att.com (Mark Plotnick) Date: Thu Jun 18 20:27:47 2009 Subject: mini-HEADSUP bce owners: please test In-Reply-To: <4A26FF44.3040609@delphij.net> References: <4A26FF44.3040609@delphij.net> Message-ID: <4A3A959E.70607@research.att.com> We have a Dell R710 with its first ethernet port connected to a Dell 5524 ethernet switch. Just installed 7.2-RELEASE on it and get no connectivity over the ethernet. tcpdump shows no frames at all. Installing your patches eliminated the PHY write timeout errors, but still have no connectivity. Now, upon boot and a couple times thereafter, we see these errors: bce0: ../../../dev/bce/if_bce.c(6968): Watchdog timeout occurred, resetting! bce0: ../../../dev/bce/if_bce.c(1386); Unable to write CTX memory: cid_addr = 0x00000000, offset = 0x00000000! bce0: ../../../dev/bce/if_bce.c(1386); Unable to write CTX memory: cid_addr = 0x00000000, offset = 0x00000010! (and so on, for offsets 14, 80, 240, 258, and 25C). From dmagda at ee.ryerson.ca Thu Jun 18 22:19:58 2009 From: dmagda at ee.ryerson.ca (David Magda) Date: Thu Jun 18 22:20:05 2009 Subject: ZFS user library? In-Reply-To: <3c1674c90906181021n54bd6fbei2a1a843033bc91c@mail.gmail.com> References: <3c1674c90906181021n54bd6fbei2a1a843033bc91c@mail.gmail.com> Message-ID: <1E4B9A40-F510-42E4-8A0B-26BA01A1679C@ee.ryerson.ca> On Jun 18, 2009, at 13:21, Kip Macy wrote: >> 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. As mentioned above, there is a "libzfs" but the Sun people are still changing things a lot so they can't guarantee compatibility. One example of these changes is the crypto work being done in OpenSolaris: http://www.opensolaris.org/os/project/zfs-crypto/phase1/libzfs_api/ Is there something specific you're looking to do? The file system layer of ZFS (the "ZPL") is in flux, but there may be other components (e.g., DMU) that may be more stable (the Lustre folks are coding against it in user land). See pages 7 and 8 for the three main layers: http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf From adrian at freebsd.org Fri Jun 19 05:35:24 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Fri Jun 19 05:35:31 2009 Subject: 6.2 sporadically locks up In-Reply-To: References: <200906160830.29721.jhb@freebsd.org> <20090617142952.GA73887@sandvine.com> Message-ID: Just modify the driver slightly to hijack a different device prefix :) Adrian 2009/6/17 pluknet : > 2009/6/17 Ed Maste : >> On Tue, Jun 16, 2009 at 07:03:34PM +0400, pluknet wrote: >> >>> As for allpcpu, I often see the picture, when one CPU runs the "irq17: >>> bce1 aacu0" thread >>> and another one runs arcconf. I wonder if that might be a source of >>> bad locking or races, or.. >>> The arcconf utility uses ioctl that goes into aac/aacu(4) internals. >> >> Do you see the same result w/ the in-tree aac(4) driver as opposed to >> Adaptec's version? >> >> -Ed >> > > [It's quite hard to move back to aac(4) as that requires fstab update > [ aacdu0 -> aacd0] > ?and instant reboot, because we use quotas and quotacheck looks into /etc/fstab. > Such preparations as fstab update and commenting out load_aacu="YES" will give > discrepancy between fstab and actual mount points.] > > I will try anyway. Thank you for your help. > > -- > wbr, > pluknet > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From pluknet at gmail.com Fri Jun 19 05:38:06 2009 From: pluknet at gmail.com (pluknet) Date: Fri Jun 19 05:38:29 2009 Subject: 6.2 sporadically locks up In-Reply-To: References: <200906160830.29721.jhb@freebsd.org> <20090617142952.GA73887@sandvine.com> Message-ID: 2009/6/19 Adrian Chadd : > Just modify the driver slightly to hijack a different device prefix :) > Hi, Adrian. That's where I just go if I should have to. - .d_name = "aac", + .d_name = "aacu", (or vise versa) While here, I'd like to give some summary about locking up with "irq17:bce1 aacu0" vs arcconf scenario. Abstract: we have a number of boxes with IBM ServeRAID 8k on 6.2. That scenario takes place only with aacu b15753, and not with b15411 (at least not noticed). We take a decision some time ago to move some boxes to 6.4 (and leave vendor aacu b15753 there as it's) to see how it goes. Until now (2 or 3 weeks) there were no lockup. I hope it will so farther.. > > > Adrian > > 2009/6/17 pluknet : >> 2009/6/17 Ed Maste : >>> On Tue, Jun 16, 2009 at 07:03:34PM +0400, pluknet wrote: >>> >>>> As for allpcpu, I often see the picture, when one CPU runs the "irq17: >>>> bce1 aacu0" thread >>>> and another one runs arcconf. I wonder if that might be a source of >>>> bad locking or races, or.. >>>> The arcconf utility uses ioctl that goes into aac/aacu(4) internals. >>> >>> Do you see the same result w/ the in-tree aac(4) driver as opposed to >>> Adaptec's version? >>> >>> -Ed >>> >> >> [It's quite hard to move back to aac(4) as that requires fstab update >> [ aacdu0 -> aacd0] >> ?and instant reboot, because we use quotas and quotacheck looks into /etc/fstab. >> Such preparations as fstab update and commenting out load_aacu="YES" will give >> discrepancy between fstab and actual mount points.] >> >> I will try anyway. Thank you for your help. >> -- wbr, pluknet From dougb at FreeBSD.org Fri Jun 19 06:56:10 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jun 19 06:56:16 2009 Subject: Upgrade from 7.1-RELEASE to 7.2-RELEASE through freebsd update In-Reply-To: <20090618123802.GA27215@ei.bzerk.org> References: <20090618083454.GQ5002@trusted-logic.com> <20090618123802.GA27215@ei.bzerk.org> Message-ID: <4A3B3683.8050908@FreeBSD.org> Ruben de Groot wrote: > On Thu, Jun 18, 2009 at 10:34:54AM +0200, Erwan David typed: >> I tried to upgrade my 7.1-RELEASE into 7.2-RELEASE. However >> freebsd-update kept asking me to merge every file in /etc whose $Id$ >> line changed (that makes about all files). >> >> Is there a way, as with mergemaster, to make it not consider the $Id$ >> line for the manual merge ? Step 1, 'man mergemaster' :) Step 2, pay special attention to the -F option Step 3, pay more special attention to the -U option But seriously folks, run 'mergemaster -Fi' once, then run 'mergemaster -U'. (And seriously read the man page.) hope this helps, Doug -- This .signature sanitized for your protection From erwan at rail.eu.org Fri Jun 19 07:15:09 2009 From: erwan at rail.eu.org (Erwan David) Date: Fri Jun 19 07:15:17 2009 Subject: Upgrade from 7.1-RELEASE to 7.2-RELEASE through freebsd update In-Reply-To: <4A3B3683.8050908@FreeBSD.org> References: <20090618083454.GQ5002@trusted-logic.com> <20090618123802.GA27215@ei.bzerk.org> <4A3B3683.8050908@FreeBSD.org> Message-ID: <20090619071505.GD13761@trusted-logic.com> On Fri, Jun 19, 2009 at 08:56:03AM CEST, Doug Barton said: > Ruben de Groot wrote: > > On Thu, Jun 18, 2009 at 10:34:54AM +0200, Erwan David typed: > >> I tried to upgrade my 7.1-RELEASE into 7.2-RELEASE. However > >> freebsd-update kept asking me to merge every file in /etc whose $Id$ > >> line changed (that makes about all files). > >> > >> Is there a way, as with mergemaster, to make it not consider the $Id$ > >> line for the manual merge ? > > Step 1, 'man mergemaster' :) > Step 2, pay special attention to the -F option > Step 3, pay more special attention to the -U option > > But seriously folks, run 'mergemaster -Fi' once, then run > 'mergemaster -U'. (And seriously read the man page.) freebsd-update does not use mergemaster, that's a part of the problem. -- Erwan From mandrews at bit0.com Fri Jun 19 07:30:39 2009 From: mandrews at bit0.com (Mike Andrews) Date: Fri Jun 19 07:30:47 2009 Subject: weird problem w/ ZFS not reclaiming freed space Message-ID: Somehow I've managed to get ZFS on one of my machines into a state where it won't reclaim all space after deleting files AND snapshots off of it: (this is with 7.2-STABLE amd64, compiled June 10) # ls -la /weird total 4 drwxr-x--- 2 mysql mysql 2 Jun 19 02:42 . drwxr-xr-x 29 root wheel 1024 Jun 19 02:44 .. # df /weird Filesystem 1K-blocks Used Avail Capacity Mounted on scotch/weird 282201472 109151232 173050240 39% /weird # zfs list scotch/weird NAME USED AVAIL REFER MOUNTPOINT scotch/weird 104G 164G 104G /weird # zfs list -t snapshot | grep scotch/weird # zfs get all scotch/weird NAME PROPERTY VALUE SOURCE scotch/weird type filesystem - scotch/weird creation Wed Jun 17 1:20 2009 - scotch/weird used 104G - scotch/weird available 159G - scotch/weird referenced 104G - scotch/weird compressratio 1.00x - scotch/weird mounted yes - scotch/weird quota none default scotch/weird reservation none default scotch/weird recordsize 128K default scotch/weird mountpoint /weird local scotch/weird sharenfs off default scotch/weird checksum on default scotch/weird compression off default scotch/weird atime off local scotch/weird devices on default scotch/weird exec off local scotch/weird setuid off local scotch/weird readonly off default scotch/weird jailed off default scotch/weird snapdir hidden default scotch/weird aclmode groupmask default scotch/weird aclinherit restricted default scotch/weird canmount on default scotch/weird shareiscsi off default scotch/weird xattr off temporary scotch/weird copies 1 default scotch/weird version 3 - scotch/weird utf8only off - scotch/weird normalization none - scotch/weird casesensitivity sensitive - scotch/weird vscan off default scotch/weird nbmand off default scotch/weird sharesmb off default scotch/weird refquota none default scotch/weird refreservation none default scotch/weird primarycache all default scotch/weird secondarycache all default scotch/weird usedbysnapshots 0 - scotch/weird usedbydataset 104G - scotch/weird usedbychildren 0 - scotch/weird usedbyrefreservation 0 - If I then rsync stuff to it, space seems OK, if I continue to rsync to it every few hours, the used space grows, even if no snapshots are being taken If I do take snapshots, then change stuff, then delete the snapshots, the snapshot space does appear to be reclaimed. Also if I 'zfs destroy' the filesystem, the space is correctly reclaimed, but once I create a new one and repeat the process, the problem reappears. I have not had any luck reproducing this on another machine yet, but admittedly haven't tried super hard yet. Scrubbing the zpool returns no errors. I'm guessing zdb is my only hope at debugging this, but as I've never used it before and as it seems to dump core whenever I try running it, can someone suggest what I need to check/look for in it? I did also have a panic a few days ago that, based on the text, might be related (I do have the vmdump and core.txt) panic: solaris assert: P2PHASE(start, 1ULL << sm->sm_shift) == 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 146 ...for which I have a vmdump and a core.txt if anyone wants to look at it. From michal at sharescope.co.uk Fri Jun 19 09:07:02 2009 From: michal at sharescope.co.uk (Michal) Date: Fri Jun 19 09:07:10 2009 Subject: Open Vs Free BSD Message-ID: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> Someone once said this too me "Comparing FreeBSD and OpenBSD, FreeBSD is generally better at disk-related I/O whereas OpenBSD handles net-I/O better. No test has been carried out to prove this though." Every offence to the person which said this, but they are not the best admin ever, though they like to think they are (the worst kind I think) Can anyone shed any light, the reason I ask is we where debating about a network and he said OpenBSD on the network (routers firewall etc) and FreeBSD as the app servers (mail, files etc etc), which I can see makes sense.but without having evidence it's pointless making a claim. Thanks :-) From hk at alogis.com Fri Jun 19 09:58:36 2009 From: hk at alogis.com (Holger Kipp) Date: Fri Jun 19 09:58:44 2009 Subject: Open Vs Free BSD In-Reply-To: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> Message-ID: <20090619095832.GA58127@intserv.int1.b.intern> On Fri, Jun 19, 2009 at 09:47:35AM +0100, Michal wrote: > Someone once said this too me > > "Comparing FreeBSD and OpenBSD, FreeBSD is generally better at disk-related > I/O whereas OpenBSD handles net-I/O better. No test has been carried out to > prove this though." > > Every offence to the person which said this, but they are not the best admin > ever, though they like to think they are (the worst kind I think) Ack! > Can anyone shed any light, the reason I ask is we where debating about a > network and he said OpenBSD on the network (routers firewall etc) and > FreeBSD as the app servers (mail, files etc etc), which I can see makes > sense.but without having evidence it's pointless making a claim. You might want to look here (although it is a bit old by now) http://forums.devshed.com/bsd-help-31/freebsd-openbsd-netbsd-darwin--the-definitive-answer-73907.html For the masses: - NetBSD: Run on any hardware (including toasters) - OpenBSD: Be as secure as possible - FreeBSD: provide best system for x86-platforms This might be the reason why generally speaking OpenBSD is recommended for network tasks (where security matters), FreeBSD for server tasks (especially on x86-systems) where the application must be available (very large ports collection), and NetBSD for every hardware that isn't mainstream. But because we always see code exchange between the BSD systems where appropriate, all systems get more secure over time, support more platforms, etc. http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems http://en.wikipedia.org/wiki/Comparison_of_open_source_operating_systems Afaik MP-support in OpenBSD is much less optimized than in FreeBSD, especially as FreeBSD got rid of Giant Lock in most places since some time already. There are also old benchmarks available (2003), so this is mostly interesting from a historical point of view: http://bulk.fefe.de/scalability/ You might also want to check http://forums.2cpu.com/archive/index.php/t-17014.html http://people.freebsd.org/~kris/scaling/dfly.html http://people.freebsd.org/~kris/scaling/7.0%20and%20beyond.pdf for further information. > Thanks :-) Regards, Holger From ivoras at freebsd.org Fri Jun 19 10:21:52 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Jun 19 10:22:00 2009 Subject: Open Vs Free BSD In-Reply-To: <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> Message-ID: Kim Attree wrote: > NetBSD runs on just about anything. That's it's primary goal. Since I don't > have any weird hardware, I've never had a use for NetBSD. I don't use NetBSD either but some recent development that come from that camp are very interesting: * Journalling UFS ("smart" journalling, not gjournal) * PUFFS (BSD implementation of FUSE-like system [file system in userland]) * They had Xen dom0 and domU for years * They are starting to show decent results in SMP support, including a new scheduler (a bit similar to ULE); their GENERIC has SMP included * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 pmap. Large pages are always used if available" * I think they are working on their own ZFS port * They have ported or reimplemented Linux LVM (read+write+admin) There are of course other things; see for example http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html I have a feeling the project has been revitalized in the last few years. From cemkayali at eticaret.com.tr Fri Jun 19 10:29:39 2009 From: cemkayali at eticaret.com.tr (Cem Kayali) Date: Fri Jun 19 10:30:10 2009 Subject: Open Vs Free BSD In-Reply-To: <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> Message-ID: <4A3B602D.7060506@eticaret.com.tr> Hi, Well basically, you need to pay for additional security implementations, and this sometimes costs decrease in performance --- though i think i can always pay for that... Regards, Cem Kim Attree, 06/19/09 12:16: > You'll struggle to find a proper apples-to-apples test to prove/disprove those > statements, but commonly held BSD Lore states: > > FreeBSD offers the best performance, and it supports the most software. It's > commonly used for web or file servers and desktops. Also, FreeBSD is more > actively developed than the others. > > OpenBSD focuses on security. It runs on more platforms than FreeBSD, but less > than NetBSD. Since security is the primary goal, it's excellent for routers > and secure-by-default servers. Popular desktop applications like Mozilla and > OpenOffice are supported, but don't expect every other Linux/UNIX program to > work. > > NetBSD runs on just about anything. That's it's primary goal. Since I don't > have any weird hardware, I've never had a use for NetBSD. > > Kim Attree > IT Manager > Playsafe South Africa > > -----Original Message----- > From: owner-freebsd-stable@freebsd.org > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Michal > Sent: 19 June 2009 10:48 AM > To: misc@openbsd.org; freebsd-stable@freebsd.org > Subject: Open Vs Free BSD > > Someone once said this too me > > > > "Comparing FreeBSD and OpenBSD, FreeBSD is generally better at disk-related > I/O whereas OpenBSD handles net-I/O better. No test has been carried out to > prove this though." > > > > Every offence to the person which said this, but they are not the best admin > ever, though they like to think they are (the worst kind I think) > > > > Can anyone shed any light, the reason I ask is we where debating about a > network and he said OpenBSD on the network (routers firewall etc) and > FreeBSD as the app servers (mail, files etc etc), which I can see makes > sense.but without having evidence it's pointless making a claim. > > > > Thanks :-) > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > From avg at icyb.net.ua Fri Jun 19 10:41:00 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Jun 19 10:41:07 2009 Subject: xorg and intel driver In-Reply-To: References: Message-ID: <4A3B6B33.5040408@icyb.net.ua> on 18/06/2009 20:34 Nenhum_de_Nos said the following: > hail, > > I know this was here before, > http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004775.html, > but there was no happy ending there ... > > is there any news ? > > I have a STABLE from yesterday and the xorg is too much slow. > > xorg is from 7.2R cdrom, intel video driver is from today. card is > > vgapci0@pci0:0:2:0: class=0x030000 card=0x50448086 chip=0x29c28086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'P35/G33 (Bearlake) Integrated Graphics Controller' > class = display > subclass = VGA > > if more info is needed, I think there was a solution, but probably posted in a different thread. I made add some confusion here, but it seems that there were several different possible causes for the symptoms that you see. For me it was intel driver starting to use MSI (MFC from head). The solution was either to disable MSI via hint or to use the following patch from Robert Noland: http://people.freebsd.org/~rnoland/drm-intel-050709.patch -- Andriy Gapon From andres at msu.edu Fri Jun 19 10:45:03 2009 From: andres at msu.edu (STeve Andre') Date: Fri Jun 19 10:45:10 2009 Subject: Open Vs Free BSD In-Reply-To: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> Message-ID: <200906190623.10417.andres@msu.edu> On Friday 19 June 2009 04:47:35 Michal wrote: > Someone once said this too me > > "Comparing FreeBSD and OpenBSD, FreeBSD is generally better at disk-related > I/O whereas OpenBSD handles net-I/O better. No test has been carried out to > prove this though." > > Every offence to the person which said this, but they are not the best > admin ever, though they like to think they are (the worst kind I think) > > Can anyone shed any light, the reason I ask is we where debating about a > network and he said OpenBSD on the network (routers firewall etc) and > FreeBSD as the app servers (mail, files etc etc), which I can see makes > sense.but without having evidence it's pointless making a claim. > > Thanks :-) Michal, What does it matter? If you aren't happy with the speed of either system you can get faster hardware. You should worry about which system is best for YOU, not how fast it is. Playing the speed game is a never ending. --STeve Andre' From oliver.pntr at gmail.com Fri Jun 19 11:29:50 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Fri Jun 19 11:29:57 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> Message-ID: <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> and the security is in netbsd: http://netbsd.gw.com/cgi-bin/man-cgi?security+8+NetBSD-5.0 http://www.netbsd.org/~elad/recent/recent06.pdf On 6/19/09, Ivan Voras wrote: > Kim Attree wrote: > >> NetBSD runs on just about anything. That's it's primary goal. Since I >> don't >> have any weird hardware, I've never had a use for NetBSD. > > I don't use NetBSD either but some recent development that come from > that camp are very interesting: > > * Journalling UFS ("smart" journalling, not gjournal) > * PUFFS (BSD implementation of FUSE-like system [file system in userland]) > * They had Xen dom0 and domU for years > * They are starting to show decent results in SMP support, including a > new scheduler (a bit similar to ULE); their GENERIC has SMP included > * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 > pmap. Large pages are always used if available" > * I think they are working on their own ZFS port > * They have ported or reimplemented Linux LVM (read+write+admin) > > There are of course other things; see for example > http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html > > I have a feeling the project has been revitalized in the last few years. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From cemkayali at eticaret.com.tr Fri Jun 19 11:35:51 2009 From: cemkayali at eticaret.com.tr (Cem Kayali) Date: Fri Jun 19 11:35:59 2009 Subject: Open Vs Free BSD In-Reply-To: <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> Message-ID: <4A3B778F.5040302@eticaret.com.tr> I have used NetBSD several years on mainly amd64 platform, and these are + properties. - Xen support and boot NetBSD as dom0 and a Linux ie; Ubuntu as domU. - Clean design of rc.d scripts. Also NetBSD does not automatically populate rc.d scripts, user adds sample one (displayed after installing pkgsrc software). - Veriexec support. What is veriexec => It is set of hashes that kernel checks before deleting or running a (binary) file according to veriexec settings. - Clean documentation of CGD. Any noob user can easily configure cryptographic disk. - More stable pkgsrc softwares with respect to FreeBSD. - 32 bit and 64 bit linux emulation in amd64 port. It works almost perfectly. - More friendly mailing lists -- NetBSD people are patient somehow ;) Just someone should decide which specifications is more important for him/her. Hint: - No blob driver. - More and more security, hardly checked codes, fixed bugs (which leads to possible future holes, and later to hear 'it was fixed in OpenBSD 6 months ago') The answer is OpenBSD. Regards, Cem Oliver Pinter, 06/19/09 14:08: > and the security is in netbsd: > > http://netbsd.gw.com/cgi-bin/man-cgi?security+8+NetBSD-5.0 > http://www.netbsd.org/~elad/recent/recent06.pdf > > On 6/19/09, Ivan Voras wrote: > >> Kim Attree wrote: >> >> >>> NetBSD runs on just about anything. That's it's primary goal. Since I >>> don't >>> have any weird hardware, I've never had a use for NetBSD. >>> >> I don't use NetBSD either but some recent development that come from >> that camp are very interesting: >> >> * Journalling UFS ("smart" journalling, not gjournal) >> * PUFFS (BSD implementation of FUSE-like system [file system in userland]) >> * They had Xen dom0 and domU for years >> * They are starting to show decent results in SMP support, including a >> new scheduler (a bit similar to ULE); their GENERIC has SMP included >> * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 >> pmap. Large pages are always used if available" >> * I think they are working on their own ZFS port >> * They have ported or reimplemented Linux LVM (read+write+admin) >> >> There are of course other things; see for example >> http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html >> >> I have a feeling the project has been revitalized in the last few years. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > > From cemkayali at eticaret.com.tr Fri Jun 19 11:46:42 2009 From: cemkayali at eticaret.com.tr (Cem Kayali) Date: Fri Jun 19 11:46:49 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> Message-ID: <4A3B7A1A.4050603@eticaret.com.tr> I agree. Thanks for reminding. I will not reply to this one anymore. Regards, Cem demuel@thephinix.org, 06/19/09 14:41: > Oh why can't this versus this versus that never dies? There had been > raging debate about which OSes is much better compared to the others since > time immemorial. Sure, each one has its own merits over the others and > vice versa. So why feeding this issue up since up to this very moment, > there is no winner. > > >> and the security is in netbsd: >> >> http://netbsd.gw.com/cgi-bin/man-cgi?security+8+NetBSD-5.0 >> http://www.netbsd.org/~elad/recent/recent06.pdf >> >> On 6/19/09, Ivan Voras wrote: >> >>> Kim Attree wrote: >>> >>> >>>> NetBSD runs on just about anything. That's it's primary goal. Since I >>>> don't >>>> have any weird hardware, I've never had a use for NetBSD. >>>> >>> I don't use NetBSD either but some recent development that come from >>> that camp are very interesting: >>> >>> * Journalling UFS ("smart" journalling, not gjournal) >>> * PUFFS (BSD implementation of FUSE-like system [file system in >>> userland]) >>> * They had Xen dom0 and domU for years >>> * They are starting to show decent results in SMP support, including a >>> new scheduler (a bit similar to ULE); their GENERIC has SMP included >>> * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 >>> pmap. Large pages are always used if available" >>> * I think they are working on their own ZFS port >>> * They have ported or reimplemented Linux LVM (read+write+admin) >>> >>> There are of course other things; see for example >>> http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html >>> >>> I have a feeling the project has been revitalized in the last few years. >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >>> > > > From michal at sharescope.co.uk Fri Jun 19 12:02:49 2009 From: michal at sharescope.co.uk (Michal) Date: Fri Jun 19 12:02:57 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> Message-ID: It wasn't an argument or a versus anything. It was just a question relating to what he had said and the truth in it and the two OS's being used for different reasons. That's all. No rage, no debate or looking for any winner! -----Original Message----- From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf Of demuel@thephinix.org Sent: 19 June 2009 12:42 To: freebsd-stable@freebsd.org; misc@openbsd.org Subject: Re: Open Vs Free BSD Oh why can't this versus this versus that never dies? There had been raging debate about which OSes is much better compared to the others since time immemorial. Sure, each one has its own merits over the others and vice versa. So why feeding this issue up since up to this very moment, there is no winner. > and the security is in netbsd: > > http://netbsd.gw.com/cgi-bin/man-cgi?security+8+NetBSD-5.0 > http://www.netbsd.org/~elad/recent/recent06.pdf > > On 6/19/09, Ivan Voras wrote: >> Kim Attree wrote: >> >>> NetBSD runs on just about anything. That's it's primary goal. Since I >>> don't >>> have any weird hardware, I've never had a use for NetBSD. >> >> I don't use NetBSD either but some recent development that come from >> that camp are very interesting: >> >> * Journalling UFS ("smart" journalling, not gjournal) >> * PUFFS (BSD implementation of FUSE-like system [file system in >> userland]) >> * They had Xen dom0 and domU for years >> * They are starting to show decent results in SMP support, including a >> new scheduler (a bit similar to ULE); their GENERIC has SMP included >> * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 >> pmap. Large pages are always used if available" >> * I think they are working on their own ZFS port >> * They have ported or reimplemented Linux LVM (read+write+admin) >> >> There are of course other things; see for example >> http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html >> >> I have a feeling the project has been revitalized in the last few years. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" From demuel at thephinix.org Fri Jun 19 12:05:40 2009 From: demuel at thephinix.org (demuel@thephinix.org) Date: Fri Jun 19 12:05:47 2009 Subject: Open Vs Free BSD In-Reply-To: <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> Message-ID: Oh why can't this versus this versus that never dies? There had been raging debate about which OSes is much better compared to the others since time immemorial. Sure, each one has its own merits over the others and vice versa. So why feeding this issue up since up to this very moment, there is no winner. > and the security is in netbsd: > > http://netbsd.gw.com/cgi-bin/man-cgi?security+8+NetBSD-5.0 > http://www.netbsd.org/~elad/recent/recent06.pdf > > On 6/19/09, Ivan Voras wrote: >> Kim Attree wrote: >> >>> NetBSD runs on just about anything. That's it's primary goal. Since I >>> don't >>> have any weird hardware, I've never had a use for NetBSD. >> >> I don't use NetBSD either but some recent development that come from >> that camp are very interesting: >> >> * Journalling UFS ("smart" journalling, not gjournal) >> * PUFFS (BSD implementation of FUSE-like system [file system in >> userland]) >> * They had Xen dom0 and domU for years >> * They are starting to show decent results in SMP support, including a >> new scheduler (a bit similar to ULE); their GENERIC has SMP included >> * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 >> pmap. Large pages are always used if available" >> * I think they are working on their own ZFS port >> * They have ported or reimplemented Linux LVM (read+write+admin) >> >> There are of course other things; see for example >> http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html >> >> I have a feeling the project has been revitalized in the last few years. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > > From timo.schoeler at riscworks.net Fri Jun 19 12:21:46 2009 From: timo.schoeler at riscworks.net (Timo Schoeler) Date: Fri Jun 19 12:21:54 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> Message-ID: <4A3B7E71.5000003@riscworks.net> thus demuel@thephinix.org spake: > Oh why can't this versus this versus that never dies? There had been > raging debate about which OSes is much better compared to the others since > time immemorial. Sure, each one has its own merits over the others and > vice versa. Exactly. > So why feeding this issue up since up to this very moment, > there is no winner. The solution is very easy, IMHO... I have been quite 'radical' WRT the OS I chose to use in the past. I ran/run all, i.e. Net/Open/FreeBSD and DragonFly, among others. I took part in the BSD vs. GNU discussion in the past. But what I learnt during the years is this: * There's always a 'best choice' for the job. On the load balancer I choose OpenBSD, and on my GFs computer I install Ubuntu. Vice versa would not work. * Life's to short for those narrow-headed discussions. Timo >> and the security is in netbsd: >> >> http://netbsd.gw.com/cgi-bin/man-cgi?security+8+NetBSD-5.0 >> http://www.netbsd.org/~elad/recent/recent06.pdf >> >> On 6/19/09, Ivan Voras wrote: >>> Kim Attree wrote: >>> >>>> NetBSD runs on just about anything. That's it's primary goal. Since I >>>> don't >>>> have any weird hardware, I've never had a use for NetBSD. >>> I don't use NetBSD either but some recent development that come from >>> that camp are very interesting: >>> >>> * Journalling UFS ("smart" journalling, not gjournal) >>> * PUFFS (BSD implementation of FUSE-like system [file system in >>> userland]) >>> * They had Xen dom0 and domU for years >>> * They are starting to show decent results in SMP support, including a >>> new scheduler (a bit similar to ULE); their GENERIC has SMP included >>> * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 >>> pmap. Large pages are always used if available" >>> * I think they are working on their own ZFS port >>> * They have ported or reimplemented Linux LVM (read+write+admin) >>> >>> There are of course other things; see for example >>> http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html >>> >>> I have a feeling the project has been revitalized in the last few years. From ruben at verweg.com Fri Jun 19 12:26:39 2009 From: ruben at verweg.com (Ruben van Staveren) Date: Fri Jun 19 12:26:46 2009 Subject: Open Vs Free BSD In-Reply-To: <4A3B7E71.5000003@riscworks.net> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> <4A3B7E71.5000003@riscworks.net> Message-ID: <021E6A5D-F1BC-47DD-B860-F0AAC588F34C@verweg.com> On 19 Jun 2009, at 14:02, Timo Schoeler wrote: >> Sure, each one has its own merits over the others and >> vice versa. Above all, they contribute to the genetic diversity in the operating system pool. Which is a good thing. - Ruben From giuliano at gzorzi.net Fri Jun 19 12:27:07 2009 From: giuliano at gzorzi.net (giuliano) Date: Fri Jun 19 12:27:15 2009 Subject: routing, pf, rdr question Message-ID: <4A3B7DD3.60802@gzorzi.net> Hello, I'm trying to replace our current firewall (clavister) with freebsd/pf. I'm almost done but I have some rules I don't know how to convert. I've tried googling around but I've found nothing useful (maybe I'm looking for the wrong terms). I have the following scenario: LAN (192.168.1.0/24) connected to fxp0 (192.168.1.1) DMZ1 (10.0.1.0/24) connected to dc0 (10.0.1.1) DMZ2 (10.0.2.0/24) connected to dc1 (10.0.2.1) DMZ3 (10.0.3.0/24) connected to dc2 (10.0.3.1) DMZ4 (10.0.4.0/24) connected to dc3 (10.0.4.1) The internet is accessible through another router on the LAN (192.168.1.254). The same router provides connections to a remote office using a VPN tunnel. On the remote site there are other 4 DMZ with the same network setup of DMZ1-4. The PCs on the LAN have their default gateway set to the 192.168.1.254 router so when they try to reach any 10.0.x.x IP address they connect to the remote site. This is correct because the production servers are in the remote site and only a few people use the local DMZs that are for development/testing. To actually reach the local DMZs I've configured the clavister firewall to route all the requests for network 10.10.1.0/24 to local 10.0.1.0/24 (and the same with the other 3 DMZs) and setup some static routes on the default gateway. Can I do the same with pf without having one rdr rule for every DMZ's host ? Do I have to setup an alias on the LAN connected interface for every IP on the networks 10.10.1-4.0/24 ? Is there a better way to have a similar setup ? Maybe I can modify the destination IP during the routing process (ie: 10.10.1.10 -> 10.0.1.10, 10.10.2.53 -> 10.0.2.53, and so on) ? Thanks for your help giuliano From erwan at rail.eu.org Fri Jun 19 13:00:50 2009 From: erwan at rail.eu.org (Erwan David) Date: Fri Jun 19 13:00:57 2009 Subject: Upgrade from 7.1-RELEASE to 7.2-RELEASE through freebsd update In-Reply-To: <20090619071505.GD13761@trusted-logic.com> References: <20090618083454.GQ5002@trusted-logic.com> <20090618123802.GA27215@ei.bzerk.org> <4A3B3683.8050908@FreeBSD.org> <20090619071505.GD13761@trusted-logic.com> Message-ID: <20090619130045.GA21430@trusted-logic.com> On Fri, Jun 19, 2009 at 09:15:05AM CEST, Erwan David said: > On Fri, Jun 19, 2009 at 08:56:03AM CEST, Doug Barton said: > > Ruben de Groot wrote: > > > On Thu, Jun 18, 2009 at 10:34:54AM +0200, Erwan David typed: > > >> I tried to upgrade my 7.1-RELEASE into 7.2-RELEASE. However > > >> freebsd-update kept asking me to merge every file in /etc whose $Id$ > > >> line changed (that makes about all files). > > >> > > >> Is there a way, as with mergemaster, to make it not consider the $Id$ > > >> line for the manual merge ? > > > > Step 1, 'man mergemaster' :) > > Step 2, pay special attention to the -F option > > Step 3, pay more special attention to the -U option > > > > But seriously folks, run 'mergemaster -Fi' once, then run > > 'mergemaster -U'. (And seriously read the man page.) > > freebsd-update does not use mergemaster, that's a part of the > problem. With more details : freebsd update does this in a special merge directory, using merge(1) which does not have the -I option. mergemaster is not anoption since the file layout is not the same. -- Erwan From neal at lambdaserver.com Fri Jun 19 13:38:43 2009 From: neal at lambdaserver.com (neal hogan) Date: Fri Jun 19 13:38:50 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> Message-ID: <20090619132746.GA15972@montague.lambdaserver.com> On Fri, Jun 19, 2009 at 01:02:40PM +0100, Michal wrote: > It wasn't an argument or a versus anything. It was just a question relating > to what he had said and the truth in it and the two OS's being used for > different reasons. That's all. No rage, no debate or looking for any winner! To be fair, the subject of your thread does suggest a "battle." From linux-fan at onda.com.br Fri Jun 19 14:30:29 2009 From: linux-fan at onda.com.br (Giancarlo Razzolini) Date: Fri Jun 19 14:30:36 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com> <6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> Message-ID: <4A3B9A2A.3090908@onda.com.br> Michal escreveu: > It wasn't an argument or a versus anything. It was just a question relating > to what he had said and the truth in it and the two OS's being used for > different reasons. That's all. No rage, no debate or looking for any winner! > > -----Original Message----- > From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf Of > demuel@thephinix.org > Sent: 19 June 2009 12:42 > To: freebsd-stable@freebsd.org; misc@openbsd.org > Subject: Re: Open Vs Free BSD > > Oh why can't this versus this versus that never dies? There had been > raging debate about which OSes is much better compared to the others since > time immemorial. Sure, each one has its own merits over the others and > vice versa. So why feeding this issue up since up to this very moment, > there is no winner. > > >> and the security is in netbsd: >> >> http://netbsd.gw.com/cgi-bin/man-cgi?security+8+NetBSD-5.0 >> http://www.netbsd.org/~elad/recent/recent06.pdf >> >> On 6/19/09, Ivan Voras wrote: >> >>> Kim Attree wrote: >>> >>> >>>> NetBSD runs on just about anything. That's it's primary goal. Since I >>>> don't >>>> have any weird hardware, I've never had a use for NetBSD. >>>> >>> I don't use NetBSD either but some recent development that come from >>> that camp are very interesting: >>> >>> * Journalling UFS ("smart" journalling, not gjournal) >>> * PUFFS (BSD implementation of FUSE-like system [file system in >>> userland]) >>> * They had Xen dom0 and domU for years >>> * They are starting to show decent results in SMP support, including a >>> new scheduler (a bit similar to ULE); their GENERIC has SMP included >>> * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 >>> pmap. Large pages are always used if available" >>> * I think they are working on their own ZFS port >>> * They have ported or reimplemented Linux LVM (read+write+admin) >>> >>> There are of course other things; see for example >>> http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html >>> >>> I have a feeling the project has been revitalized in the last few years. >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >>> > > > The words you chose from the subject to the bottom of your e-mail, were the wrong ones "Open Vs Free BSD" for me, and for most here, is literally OpenBSD versus FreeBSD. The answer is: There is winner. The reason I started using OpenBSD is a very personal one, and it generally is for most of us here. Even in business the decisions are often made with the heart. So, you've got to try. I would never use OpenBSD in my laptop, because it doesn't do everything i need on my laptop. The same way i would never use ubuntu on my firewall, because it won't do neither. My 2 cents, -- Giancarlo Razzolini http://lock.razzolini.adm.br Linux User 172199 Red Hat Certified Engineer no:804006389722501 Verify:https://www.redhat.com/certification/rhce/current/ Moleque Sem Conteudo Numero #002 OpenBSD 4.5 Ubuntu 9.04 Jaunty Jackalope 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 From ricardo.ferreira at vipway.com.br Fri Jun 19 15:38:57 2009 From: ricardo.ferreira at vipway.com.br (ricardo) Date: Fri Jun 19 15:39:05 2009 Subject: RES: Open Vs Free BSD In-Reply-To: <4A3B9A2A.3090908@onda.com.br> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk><00265389C30B444288C246DF37651D0C249024DD1B@server-02.playsafesa.com><6101e8c40906190408h5b6a4496td12e2b9e4872459e@mail.gmail.com> <4A3B9A2A.3090908@onda.com.br> Message-ID: All simply rocks...be xBSD... be Linux, be *nix... whatever.. Just use the right tool for a specific need... We are running Free, Open and Net....and some decent Linux such as Debian, Red Hat among others...Love all of them... -----Mensagem original----- De: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] Em nome de Giancarlo Razzolini Enviada em: sexta-feira, 19 de junho de 2009 11:01 Para: Michal Cc: misc@openbsd.org; demuel@thephinix.org; freebsd-stable@freebsd.org Assunto: Re: Open Vs Free BSD Michal escreveu: > It wasn't an argument or a versus anything. It was just a question relating > to what he had said and the truth in it and the two OS's being used for > different reasons. That's all. No rage, no debate or looking for any winner! > > -----Original Message----- > From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf Of > demuel@thephinix.org > Sent: 19 June 2009 12:42 > To: freebsd-stable@freebsd.org; misc@openbsd.org > Subject: Re: Open Vs Free BSD > > Oh why can't this versus this versus that never dies? There had been > raging debate about which OSes is much better compared to the others since > time immemorial. Sure, each one has its own merits over the others and > vice versa. So why feeding this issue up since up to this very moment, > there is no winner. > > >> and the security is in netbsd: >> >> http://netbsd.gw.com/cgi-bin/man-cgi?security+8+NetBSD-5.0 >> http://www.netbsd.org/~elad/recent/recent06.pdf >> >> On 6/19/09, Ivan Voras wrote: >> >>> Kim Attree wrote: >>> >>> >>>> NetBSD runs on just about anything. That's it's primary goal. Since I >>>> don't >>>> have any weird hardware, I've never had a use for NetBSD. >>>> >>> I don't use NetBSD either but some recent development that come from >>> that camp are very interesting: >>> >>> * Journalling UFS ("smart" journalling, not gjournal) >>> * PUFFS (BSD implementation of FUSE-like system [file system in >>> userland]) >>> * They had Xen dom0 and domU for years >>> * They are starting to show decent results in SMP support, including a >>> new scheduler (a bit similar to ULE); their GENERIC has SMP included >>> * Possibly superpages, I'm not sure how to parse "Merged amd64 and i386 >>> pmap. Large pages are always used if available" >>> * I think they are working on their own ZFS port >>> * They have ported or reimplemented Linux LVM (read+write+admin) >>> >>> There are of course other things; see for example >>> http://www.netbsd.org/releases/formal-5/NetBSD-5.0.html >>> >>> I have a feeling the project has been revitalized in the last few years. >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >>> > > > The words you chose from the subject to the bottom of your e-mail, were the wrong ones "Open Vs Free BSD" for me, and for most here, is literally OpenBSD versus FreeBSD. The answer is: There is winner. The reason I started using OpenBSD is a very personal one, and it generally is for most of us here. Even in business the decisions are often made with the heart. So, you've got to try. I would never use OpenBSD in my laptop, because it doesn't do everything i need on my laptop. The same way i would never use ubuntu on my firewall, because it won't do neither. My 2 cents, -- Giancarlo Razzolini http://lock.razzolini.adm.br Linux User 172199 Red Hat Certified Engineer no:804006389722501 Verify:https://www.redhat.com/certification/rhce/current/ Moleque Sem Conteudo Numero #002 OpenBSD 4.5 Ubuntu 9.04 Jaunty Jackalope 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From stef-list at memberwebs.com Fri Jun 19 16:31:18 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Fri Jun 19 16:31:25 2009 Subject: HEADSUP: libpthread compat for 5.x and 6.x binaries References: <200906151659.27326.jhb@freebsd.org> Message-ID: <20090619155922.2618E171E4E@mx.npubs.com> John Baldwin wrote: > What I would like to find out is if there are any 5.x or 6.x binaries that use > libpthread that do not run well with libthr. You can test this by using a > libmap.conf(5) file to remap libpthread to libthr. For 5.x binaries you will > want to remap libpthread.so.1 to libthr.so.1. For 6.x binaries you will want > to remap libpthread.so.2 to libthr.so.2. This can be accomplished using > an /etc/libmap.conf file that contains: I'm running about a hundred jails with a libmap.conf file like that. In order to run 32-bit 6.x jails on FreeBSD 7.2 64-bit... The only time I've seen a problem, is when a threaded application binary is compiled statically. Apparently mysql is built statically sometimes. Obviously in these cases libmap.conf can't kick in. Cheers, Stef Walter From mgass at unix.csbsju.edu Fri Jun 19 17:24:31 2009 From: mgass at unix.csbsju.edu (Michael Gass) Date: Fri Jun 19 17:24:39 2009 Subject: kernel wants the wrong driver for my NIC Message-ID: <20090619172429.GA5197@unix.csbsju.edu> I'm running 7.2-stable and I replaced an old ISA NIC with a D-Link DFE-530TX+ card. According to the manual, the correct driver for this card is rl driver. The kernel insists on using the vr driver which is for the DFE-530TX. >From what I can tell, the two cards have different chipsets and so the drivers are not compatable. I can configure the vr driver, but the card does not work with it - I cannot establish a connection even with ping. Is there a way for me to force the kernel to use the rl driver? I am using a generic kernel, so all the needed drivers are built-in. Any other suggestions? Output from ifconfig and dmesg are below. Thanks, Mike Gass Minnesota USA ifconfig output --------------------------------------------------------- vr0: flags=8843 metric 0 mtu 1500 options=2808 ether 00:22:b0:6d:e8:b6 inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 dmesg output ------------------------------------------ Copyright (c) 1992-2009 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.2-STABLE #0: Sat Jun 13 09:59:29 CDT 2009 root@pavilion.home.net:/usr/obj/usr/src/sys/GENERIC module_register: module rl/miibus already exists! Module rl/miibus failed to register: 17 module_register: module cardbus/rl already exists! Module cardbus/rl failed to register: 17 module_register: module pci/rl already exists! Module pci/rl failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 268369920 (255 MB) avail memory = 248492032 (236 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xf5000000-0xf5ffffff,0xf4100000-0xf4100fff irq 11 at device 0.0 on pci1 drm0: <3D Rage Pro AGP 1X/2X> on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xf8000000 64MB info: [drm] Initialized mach64 2.0.0 20060718 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1050-0x105f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0x1060-0x107f irq 5 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 10.0 (no driver attached) vr0: port 0x1400-0x14ff mem 0xf4000000-0xf40000ff irq 3 at device 11.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x86 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:22:b0:6d:e8:b6 vr0: [ITHREAD] acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 acpi_throttle0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xca7ff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 400911857 Hz quality 800 Timecounters tick every 1.000 msec ad0: 28610MB at ata0-master UDMA33 acd0: CDROM at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s1a vr0: link state changed to DOWN vr0: link state changed to UP vr0: link state changed to DOWN vr0: link state changed to UP From mike at sentex.net Fri Jun 19 17:44:59 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Jun 19 17:45:15 2009 Subject: kernel wants the wrong driver for my NIC In-Reply-To: <20090619172429.GA5197@unix.csbsju.edu> References: <20090619172429.GA5197@unix.csbsju.edu> Message-ID: <200906191742.n5JHgf5C002804@lava.sentex.ca> At 01:24 PM 6/19/2009, Michael Gass wrote: >I'm running 7.2-stable and I replaced an old ISA NIC with >a D-Link DFE-530TX+ card. According to the manual, the What does pciconfig -lvc show ? ---Mike From fjwcash at gmail.com Fri Jun 19 17:45:02 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Fri Jun 19 17:45:16 2009 Subject: kernel wants the wrong driver for my NIC In-Reply-To: <20090619172429.GA5197@unix.csbsju.edu> References: <20090619172429.GA5197@unix.csbsju.edu> Message-ID: On Fri, Jun 19, 2009 at 10:24 AM, Michael Gass wrote: > I'm running 7.2-stable and I replaced an old ISA NIC with > a D-Link DFE-530TX+ card. According to the manual, the > correct driver for this card is rl driver. The kernel > insists on using the vr driver which is for the DFE-530TX. > >From what I can tell, the two cards have different chipsets > and so the drivers are not compatable. > > I can configure the vr driver, but the card does not work > with it - I cannot establish a connection even with ping. > > Is there a way for me to force the kernel to use the rl > driver? I am using a generic kernel, so all the needed > drivers are built-in. > "Simplest" method would be to compile a custom kernel with the rl driver and without the vr driver. Or to build a kernel without any networking drivers, so that they are all built as modules, and then use /boot/loader.conf to load just the if_rl module. One could probably also write a hints line in /boot/loader.conf to tell the vr driver to ignore that specific PCI slot or whatnot, although I've never actually done that. -- Freddie Cash fjwcash@gmail.com From ibb_orac at mbox.contact.bg Fri Jun 19 18:05:27 2009 From: ibb_orac at mbox.contact.bg (Ivailo Bonev) Date: Fri Jun 19 18:05:35 2009 Subject: Fw: kernel wants the wrong driver for my NIC Message-ID: <27E3F50B00E14B22A18308F213F9E8CF@chameleon> ----- Original Message ----- From: "Ivailo Bonev" To: "Michael Gass" Cc: Sent: Friday, June 19, 2009 8:54 PM Subject: Re: kernel wants the wrong driver for my NIC > > ----- Original Message ----- > From: "Michael Gass" > To: > Sent: Friday, June 19, 2009 8:24 PM > Subject: kernel wants the wrong driver for my NIC > > >> I'm running 7.2-stable and I replaced an old ISA NIC with a D-Link >> DFE-530TX+ card. According to the manual, the >> correct driver for this card is rl driver. The kernel >> insists on using the vr driver which is for the DFE-530TX. >>>From what I can tell, the two cards have different chipsets >> and so the drivers are not compatable. > > It's a NIC with Davicom chip... Sorry for mistake, I was looking an old picture of this NIC. I see in Linux driver - VT6102 and VT6105... From ibb_orac at mbox.contact.bg Fri Jun 19 18:21:32 2009 From: ibb_orac at mbox.contact.bg (Ivailo Bonev) Date: Fri Jun 19 18:21:39 2009 Subject: kernel wants the wrong driver for my NIC References: <20090619172429.GA5197@unix.csbsju.edu> Message-ID: <9983F3C4691B4F6B85B1FBE45E128CF5@chameleon> ----- Original Message ----- From: "Michael Gass" To: Sent: Friday, June 19, 2009 8:24 PM Subject: kernel wants the wrong driver for my NIC > I'm running 7.2-stable and I replaced an old ISA NIC with > a D-Link DFE-530TX+ card. According to the manual, the > correct driver for this card is rl driver. The kernel > insists on using the vr driver which is for the DFE-530TX. >>From what I can tell, the two cards have different chipsets > and so the drivers are not compatable. It's a NIC with Davicom chip... From freebsd07 at wayne47.com Fri Jun 19 18:36:38 2009 From: freebsd07 at wayne47.com (Michael R. Wayne) Date: Fri Jun 19 18:36:45 2009 Subject: Open Vs Free BSD In-Reply-To: <200906190623.10417.andres@msu.edu> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <200906190623.10417.andres@msu.edu> Message-ID: <20090619182326.GX12531@manor.msen.com> On Fri, Jun 19, 2009 at 06:23:09AM -0400, STeve Andre' wrote: > On Friday 19 June 2009 04:47:35 Michal wrote: > > > > "Comparing FreeBSD and OpenBSD, FreeBSD is generally better at disk-related > > I/O whereas OpenBSD handles net-I/O better. No test has been carried out to > > prove this though." > > > > Every offence to the person which said this, but they are not the best > > admin ever, though they like to think they are (the worst kind I think) > > > > Can anyone shed any light, the reason I ask is we where debating about a > > network and he said OpenBSD on the network (routers firewall etc) and > > FreeBSD as the app servers (mail, files etc etc), which I can see makes > > sense.but without having evidence it's pointless making a claim. > > > What does it matter? If you aren't happy with the speed of either system > you can get faster hardware. You should worry about which system is best > for YOU, not how fast it is. Playing the speed game is a never ending. OK, I'm going to take a guess here that English may not be Michal's primary language and re-ask his question: Given the several versions of *BSD, I have been led to understand that each excells in different ways. How do I select which one is right for my application, what are the underlying reasons that would lead me to that choice and what are the the disadvantages I am risking? This is, actually, not an inappropriate question coming from a potential new user who is not familiar with the history surrounding the various versions and would make an outstanding FAQ. As an example, we run FreeBSD on our firewalling machines because it works well enough and we prefer the reduced support costs of using a single O/S across our network. I am unsure of what the advantage of moving to OpenBSD might be and would find it very difficult to quantify the advantages (if any) versus the increased support resources required. This is a very real issue. Linux has a similar problem; I've personally been in meetings where clients examined the myriad Linux distributions and say "It's very likely that we will make the incorrect choice. So we'll go with Windows." I suspect similar events have occurred with *BSD. So, rather than jumping on people about them bringing up religous wars (because, face it, you CAN edit a file perfectly well in either vi or emacs :-), we'd all be better served by giving them enough information to make the right choice in their situation while realizing the tradeoffs they are making. /\/\ \/\/ From kmacy at freebsd.org Fri Jun 19 18:46:27 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri Jun 19 18:46:34 2009 Subject: Open Vs Free BSD In-Reply-To: <20090619182326.GX12531@manor.msen.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <200906190623.10417.andres@msu.edu> <20090619182326.GX12531@manor.msen.com> Message-ID: <3c1674c90906191146x551e70cdl564e6a0d59941484@mail.gmail.com> 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 From jhb at freebsd.org Fri Jun 19 18:50:58 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Jun 19 18:51:05 2009 Subject: kernel wants the wrong driver for my NIC In-Reply-To: <20090619172429.GA5197@unix.csbsju.edu> References: <20090619172429.GA5197@unix.csbsju.edu> Message-ID: <200906191450.48241.jhb@freebsd.org> On Friday 19 June 2009 1:24:29 pm Michael Gass wrote: > I'm running 7.2-stable and I replaced an old ISA NIC with > a D-Link DFE-530TX+ card. According to the manual, the > correct driver for this card is rl driver. The kernel > insists on using the vr driver which is for the DFE-530TX. > >From what I can tell, the two cards have different chipsets > and so the drivers are not compatable. I would assume the vr(4) driver is the right driver for your card since PCI devices probe based on PCI IDs. Also, the driver has worked well enough to read a MAC address, etc. (have you compared it with the sticker on the card, if it matches vr(4) is almost _certainly_ the correct driver). -- John Baldwin From pan at syix.com Fri Jun 19 18:22:01 2009 From: pan at syix.com (pan) Date: Fri Jun 19 19:03:52 2009 Subject: kernel wants the wrong driver for my NIC References: <20090619172429.GA5197@unix.csbsju.edu> <200906191742.n5JHgf5C002804@lava.sentex.ca> Message-ID: <96F6C77775FC4687B8AC0A0A9182C2E5@plexus> ----- Original Message ----- From: "Mike Tancsa" To: "Michael Gass" ; Sent: Friday, June 19, 2009 10:44 AM Subject: Re: kernel wants the wrong driver for my NIC : At 01:24 PM 6/19/2009, Michael Gass wrote: : >I'm running 7.2-stable and I replaced an old ISA NIC with : >a D-Link DFE-530TX+ card. According to the manual, the : : : What does pciconfig -lvc : show ? : : ---Mike Is that any different than pciconf -lvc ? From m.e.sanliturk at gmail.com Fri Jun 19 19:30:41 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Fri Jun 19 19:30:49 2009 Subject: Open Vs Free BSD In-Reply-To: <3c1674c90906191146x551e70cdl564e6a0d59941484@mail.gmail.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <200906190623.10417.andres@msu.edu> <20090619182326.GX12531@manor.msen.com> <3c1674c90906191146x551e70cdl564e6a0d59941484@mail.gmail.com> Message-ID: On Fri, Jun 19, 2009 at 2:46 PM, Kip Macy wrote: > 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 > During reading of questions and answers to such comparison issues it is possible to observe one very important ( in my opinion , missing ) concept : In engineering , there is no an abstract < better than > concept by itself . As an example we may compare : bicycle , motorcycle , car , lorry , bus . aeroplane , boat , ship , transatlantic , train , ... Which one is better than the other one ? If you give an answer that < x is better than y > you are implicitly using a MEASURE of COMPARISON to solve a PROBLEM . When that the very MEASURE of COMPARISON for the PROBLEM is not specified , the abstract comparison is NOT useful and meaningful . For that reason , it is useful at the beginning to give a description of the problem in precise terms and then ask which tool solves this problem with respect to the others with respect to advantages and disadvantages of the tools . After enumerating these ideas it is possible to make decisions to select an appropriate one which solves the problem as much as possible . Thank you very much . Mehmet Erol Sanliturk From corky1951 at comcast.net Fri Jun 19 19:37:16 2009 From: corky1951 at comcast.net (Charlie Kester) Date: Fri Jun 19 19:37:23 2009 Subject: Open Vs Free BSD In-Reply-To: <20090619182326.GX12531@manor.msen.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <200906190623.10417.andres@msu.edu> <20090619182326.GX12531@manor.msen.com> Message-ID: <20090619192403.GB2227@comcast.net> On Fri 19 Jun 2009 at 11:23:26 PDT Michael R. Wayne wrote: > >OK, I'm going to take a guess here that English may not be Michal's primary >language and re-ask his question: > > Given the several versions of *BSD, I have been led to understand > that each excells in different ways. How do I select which one > is right for my application, what are the underlying reasons > that would lead me to that choice and what are the the disadvantages > I am risking? > >This is, actually, not an inappropriate question coming from a potential >new user who is not familiar with the history surrounding the various >versions and would make an outstanding FAQ. As an example, we run FreeBSD >on our firewalling machines because it works well enough and we prefer the >reduced support costs of using a single O/S across our network. I am unsure >of what the advantage of moving to OpenBSD might be and would find it very >difficult to quantify the advantages (if any) versus the increased support >resources required. > >This is a very real issue. Linux has a similar problem; I've personally >been in meetings where clients examined the myriad Linux distributions >and say "It's very likely that we will make the incorrect choice. So we'll >go with Windows." I suspect similar events have occurred with *BSD. So, >rather than jumping on people about them bringing up religous wars (because, >face it, you CAN edit a file perfectly well in either vi or emacs :-), we'd >all be better served by giving them enough information to make the >right choice in their situation while realizing the tradeoffs they are >making. 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? From kmacy at freebsd.org Fri Jun 19 19:42:02 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri Jun 19 19:42:10 2009 Subject: Open Vs Free BSD In-Reply-To: <20090619192403.GB2227@comcast.net> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <200906190623.10417.andres@msu.edu> <20090619182326.GX12531@manor.msen.com> <20090619192403.GB2227@comcast.net> Message-ID: <3c1674c90906191242t483efa38n80c63c2e229a488c@mail.gmail.com> > 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 From rizzo at iet.unipi.it Fri Jun 19 20:40:20 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Jun 19 20:40:28 2009 Subject: skype stalls on RELENG_7 ? Message-ID: <20090619202749.GA99473@onelab2.iet.unipi.it> Hi, i am not sure what the situation is but i am starting seeing problems with skype (both 2.0 and 1.2) on a couple of RELENG_7 machines. One of the machines still uses linux 2.4 emulation and fc4, the other one has 2.6.16 and fc8 and is a fresh install of 7.2 In both cases, i see that skype remains waiting to contact the server (the 1.2 version seems to timeout earlier complaining for a password error, but the laptop next to me can connect with the same account.) Anyone else seeing similar problems ? cheers luigi From santosh at fastsoft.com Fri Jun 19 22:55:53 2009 From: santosh at fastsoft.com (Santosh Rao Gururajan) Date: Fri Jun 19 22:56:02 2009 Subject: Patch for FreeBSD 7.0 deadlock Message-ID: I am seeing problems with FreeBSD 7.0 machines that have the symptoms described in http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/043241.html Can someone please point me to a patch which has a fix for the issue described in that thread? Thanks, -santosh From mgass at unix.csbsju.edu Fri Jun 19 23:08:04 2009 From: mgass at unix.csbsju.edu (Michael Gass) Date: Fri Jun 19 23:08:11 2009 Subject: kernel wants the wrong driver for my NIC (new issue) In-Reply-To: <20090619172429.GA5197@unix.csbsju.edu> References: <20090619172429.GA5197@unix.csbsju.edu> Message-ID: <20090619230802.GA5795@unix.csbsju.edu> On Fri, Jun 19, 2009 at 12:24:29PM -0500, Michael Gass wrote: > I'm running 7.2-stable and I replaced an old ISA NIC with > a D-Link DFE-530TX+ card. According to the manual, the > correct driver for this card is rl driver. The kernel > insists on using the vr driver which is for the DFE-530TX. > >From what I can tell, the two cards have different chipsets > and so the drivers are not compatable. > I got the vr driver to work: it was an IRQ issue. Seems sio1 wanted irq 3 which is what vr0 was taking. Somehow that caused a problem. BUT I am still confused about the rl driver not working for this card. The NOTES in /usr/src/sys/conf/NOTES explicitly state that the rl driver is for the DFE-530TX+ and that the vr driver is for the DFE-530TX. I have the former and so should be using the rl drive it seems. Is this a mistake in the documentation (including the man page for each driver)? I made a new kernel without the vr driver and the result was that no driver at all was recognized for the NIC. Is there a way to force the kernel to put an entry in /dev for rl0 so that I could try to configue it for the NIC? BTW, visual inspection of the chip on my DFE-530TX+ says it is a DL10030C. Here is some relevant output from running pciconf -lvc. vr0@pci0:0:11:0: class=0x020000 card=0x14061186 chip=0x31061106 rev=0x86 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6105M/LOM Rhine III PCI Fast Ethernet Controller' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 vgapci0@pci0:1:0:0: class=0x030000 card=0x47421002 chip=0x47421002 rev=0x5c hdr=0x00 > > Output from ifconfig and dmesg are below. > > Thanks, Mike Gass Minnesota USA > > ifconfig output > --------------------------------------------------------- > vr0: flags=8843 metric 0 mtu 1500 > options=2808 > ether 00:22:b0:6d:e8:b6 > inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (100baseTX ) > status: active > plip0: flags=108810 metric 0 mtu 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > > > dmesg output > ------------------------------------------ > Copyright (c) 1992-2009 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.2-STABLE #0: Sat Jun 13 09:59:29 CDT 2009 > root@pavilion.home.net:/usr/obj/usr/src/sys/GENERIC > module_register: module rl/miibus already exists! > Module rl/miibus failed to register: 17 > module_register: module cardbus/rl already exists! > Module cardbus/rl failed to register: 17 > module_register: module pci/rl already exists! > Module pci/rl failed to register: 17 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x665 Stepping = 5 > Features=0x183f9ff > real memory = 268369920 (255 MB) > avail memory = 248492032 (236 MB) > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x2000-0x20ff mem 0xf5000000-0xf5ffffff,0xf4100000-0xf4100fff irq 11 at device 0.0 on pci1 > drm0: <3D Rage Pro AGP 1X/2X> on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xf8000000 64MB > info: [drm] Initialized mach64 2.0.0 20060718 > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1050-0x105f at device 7.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > uhci0: port 0x1060-0x107f irq 5 at device 7.2 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > pci0: at device 7.3 (no driver attached) > pci0: at device 10.0 (no driver attached) > vr0: port 0x1400-0x14ff mem 0xf4000000-0xf40000ff irq 3 at device 11.0 on pci0 > vr0: Quirks: 0x0 > vr0: Revision: 0x86 > miibus0: on vr0 > ukphy0: PHY 1 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > vr0: Ethernet address: 00:22:b0:6d:e8:b6 > vr0: [ITHREAD] > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FILTER] > cpu0: on acpi0 > acpi_throttle0: on cpu0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xca7ff pnpid ORM0000 on isa0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 400911857 Hz quality 800 > Timecounters tick every 1.000 msec > ad0: 28610MB at ata0-master UDMA33 > acd0: CDROM at ata1-master PIO4 > Trying to mount root from ufs:/dev/ad0s1a > vr0: link state changed to DOWN > vr0: link state changed to UP > vr0: link state changed to DOWN > vr0: link state changed to UP > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Michael Gass Department of Mathematics St. John's University Collegeville, MN 56321-3000 (320) 363-3090 mgass@csbsju.edu From ertr1013 at student.uu.se Sat Jun 20 00:06:02 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Sat Jun 20 00:06:10 2009 Subject: kernel wants the wrong driver for my NIC (new issue) In-Reply-To: <20090619230802.GA5795@unix.csbsju.edu> References: <20090619172429.GA5197@unix.csbsju.edu> <20090619230802.GA5795@unix.csbsju.edu> Message-ID: <20090619235047.GA57522@owl.midgard.homeip.net> On Fri, Jun 19, 2009 at 06:08:02PM -0500, Michael Gass wrote: > On Fri, Jun 19, 2009 at 12:24:29PM -0500, Michael Gass wrote: > > I'm running 7.2-stable and I replaced an old ISA NIC with > > a D-Link DFE-530TX+ card. According to the manual, the > > correct driver for this card is rl driver. The kernel > > insists on using the vr driver which is for the DFE-530TX. > > >From what I can tell, the two cards have different chipsets > > and so the drivers are not compatable. > > > > I got the vr driver to work: it was an IRQ issue. Seems > sio1 wanted irq 3 which is what vr0 was taking. Somehow that > caused a problem. > > BUT > > I am still confused about the rl driver not working for this > card. The NOTES in /usr/src/sys/conf/NOTES explicitly state > that the rl driver is for the DFE-530TX+ and that the vr > driver is for the DFE-530TX. I have the former and so should > be using the rl drive it seems. Is this a mistake in the > documentation (including the man page for each driver)? Then perhaps the card you have actually is a DFE-530TX. Or maybe the manufacturer changed which chip they use without bothering to change the name of the card - such things happen all too often. I.e. there may well exist two different 'DFE-530TX+' variants - one which uses a Realtek controller, and one which uses a VIA controller. > > I made a new kernel without the vr driver and the result was > that no driver at all was recognized for the NIC. > Is there a way to force the kernel to put an entry in /dev > for rl0 so that I could try to configue it for the NIC? No. The kernel uses the PCI chip-ID to decide which driver attaches to the card. To change which driver is used you would have to go in and modify the kernel source and build a new kernel. Don't bother doing that however, because if the vr(4) driver works for this card (as you say it does) then there is absolutely no way that the rl(4) driver would work for the same card. (And vice versa.) > > BTW, visual inspection of the chip on my DFE-530TX+ says it > is a DL10030C. > > Here is some relevant output from running pciconf -lvc. > > vr0@pci0:0:11:0: class=0x020000 card=0x14061186 chip=0x31061106 rev=0x86 hdr=0x00 > vendor = 'VIA Technologies Inc' > device = 'VT6105M/LOM Rhine III PCI Fast Ethernet Controller' > class = network > subclass = ethernet > cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 That looks very much like a VIA chip which should indeed be handled by the vr(4) driver. -- Erik Trulsson ertr1013@student.uu.se From mike at sentex.net Sat Jun 20 02:25:53 2009 From: mike at sentex.net (Mike Tancsa) Date: Sat Jun 20 02:26:04 2009 Subject: kernel wants the wrong driver for my NIC (new issue) In-Reply-To: <20090619230802.GA5795@unix.csbsju.edu> References: <20090619172429.GA5197@unix.csbsju.edu> <20090619230802.GA5795@unix.csbsju.edu> Message-ID: <200906200223.n5K2NYPB005549@lava.sentex.ca> At 07:08 PM 6/19/2009, Michael Gass wrote: >I am still confused about the rl driver not working for this >card. The NOTES in /usr/src/sys/conf/NOTES explicitly state >that the rl driver is for the DFE-530TX+ and that the vr >driver is for the DFE-530TX. The manufacturer could have changed chipsets and didnt change model numbers. Its certainly not unprecedented. Or the wrong NIC could have been sold to you by accident. >I made a new kernel without the vr driver and the result was >that no driver at all was recognized for the NIC. >Is there a way to force the kernel to put an entry in /dev >for rl0 so that I could try to configue it for the NIC? Its a vr nic. Fiddling with the PCI ids of the drivers, will not make it work. i.e. changing the device IDs that the rl attaches to and removing it from the vr. ---Mike From gaijin.k at gmail.com Sat Jun 20 03:05:33 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sat Jun 20 03:05:39 2009 Subject: skype stalls on RELENG_7 ? In-Reply-To: <20090619202749.GA99473@onelab2.iet.unipi.it> References: <20090619202749.GA99473@onelab2.iet.unipi.it> Message-ID: <1245465278.3771.18.camel@RabbitsDen> On Fri, 2009-06-19 at 22:27 +0200, Luigi Rizzo wrote: > Hi, > i am not sure what the situation is but i am starting > seeing problems with skype (both 2.0 and 1.2) on a > couple of RELENG_7 machines. One of the machines still uses > linux 2.4 emulation and fc4, the other one has 2.6.16 and fc8 > and is a fresh install of 7.2 > In both cases, i see that skype remains waiting to contact > the server (the 1.2 version seems to timeout earlier > complaining for a password error, but the laptop next > to me can connect with the same account.) > > Anyone else seeing similar problems ? I do not see this problem, my setup is quoted below. OTOH I have seen these symptoms when firewall is in place and port 80 bridge, Skype uses, is overwhelmed. Is this a possibility in your case? sunny:RabbitsDen>uname -a FreeBSD RabbitsDen.RabbitsLawn.verizon.net 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Jun 14 13:29:30 EDT 2009 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 sunny:RabbitsDen>cat /etc/make.conf CPUTYPE?=core OVERRIDE_LINUX_BASE_PORT=f8 OVERRIDE_LINUX_NONBASE_PORTS=f8 NO_FSCHG= # added by use.perl 2009-06-11 19:19:47 PERL_VERSION=5.10.0 sunny:RabbitsDen>pkg_info | grep -i skype skype-2.0.0.72,1 P2P VoIP software sunny:RabbitsDen>pkg_info | grep linux linux-f8-alsa-lib-1.0.15_1 The Advanced Linux Sound Architecture libraries (Linux Fedo linux-f8-atk-1.20.0_1 Accessibility Toolkit, Linux/i386 binary (Linux Fedora 8) linux-f8-cairo-1.4.14_1 Vector graphics library Cairo (Linux Fedora 8) linux-f8-expat-2.0.1_1 Linux/i386 binary port of Expat XML-parsing library (Linux linux-f8-fontconfig-2.4.2_1 An XML-based font configuration API for X Windows (Linux Fe linux-f8-gtk2-2.12.8_1 GTK+ library, version 2.X (Linux Fedora 8) linux-f8-pango-1.18.4_1 The pango library (Linux Fedora 8) linux-f8-png-1.2.22_1 RPM of the PNG lib (Linux Fedora 8) linux-f8-tiff-3.8.2_1 The TIFF library, Linux/i386 binary (Linux Fedora 8) linux-f8-xorg-libs-7.3_3 Xorg libraries (Linux Fedora 8) linux-flashplugin-9.0r159 Adobe Flash Player NPAPI Plugin linux-hicolor-icon-theme-0.5_3 A high-color icon theme shell from the FreeDesktop project linux-jpeg-6b.34_2 RPM of the JPEG lib linux-libsigc-2.0.17_2 Callback Framework for C++ (linux version) linux-nvu-1.0_1 A complete Web Authoring System linux-openssl-0.9.7f_2 SSL and crypto library (Linux Version) linux-realplayer-10.0.9.809.20070726 Linux RealPlayer 10 from RealNetworks linux_base-f8-8_11 Base set of packages needed in Linux mode (for i386/amd64) linux_dri-7.0_1 Binary Linux DRI libraries for 3D hardware acceleration of > > cheers > luigi > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From rizzo at iet.unipi.it Sat Jun 20 06:34:52 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Jun 20 06:35:04 2009 Subject: skype stalls on RELENG_7 ? In-Reply-To: <1245465278.3771.18.camel@RabbitsDen> References: <20090619202749.GA99473@onelab2.iet.unipi.it> <1245465278.3771.18.camel@RabbitsDen> Message-ID: <20090620064009.GA18187@onelab2.iet.unipi.it> On Fri, Jun 19, 2009 at 10:34:38PM -0400, Alexandre Sunny Kovalenko wrote: > On Fri, 2009-06-19 at 22:27 +0200, Luigi Rizzo wrote: > > Hi, > > i am not sure what the situation is but i am starting > > seeing problems with skype (both 2.0 and 1.2) on a > > couple of RELENG_7 machines. One of the machines still uses > > linux 2.4 emulation and fc4, the other one has 2.6.16 and fc8 > > and is a fresh install of 7.2 > > In both cases, i see that skype remains waiting to contact > > the server (the 1.2 version seems to timeout earlier > > complaining for a password error, but the laptop next > > to me can connect with the same account.) > > > > Anyone else seeing similar problems ? > I do not see this problem, my setup is quoted below. > > OTOH I have seen these symptoms when firewall is in place and port 80 > bridge, Skype uses, is overwhelmed. Is this a possibility in your case? > > sunny:RabbitsDen>uname -a > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 7.2-STABLE FreeBSD 7.2-STABLE > #0: Sun Jun 14 13:29:30 EDT 2009 > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > sunny:RabbitsDen>cat /etc/make.conf > CPUTYPE?=core > OVERRIDE_LINUX_BASE_PORT=f8 > OVERRIDE_LINUX_NONBASE_PORTS=f8 > NO_FSCHG= thanks a lot, the 'OVERRIDE_LINUX_NONBASE_PORTS' seems to be what i was missing. In particular, i still had some f4 ports installed. After setting OVERRIDE_LINUX_NONBASE_PORTS, I did a manual "portupgrade -f ... " on the linux ports, and then 'portupgrade -o ..." on some of the many ports which were still not updated . I am not sure what subset needs to be up to date, but bringing in linux-f8-alsa-lib-1.0.15_1 seemed to do the job. These are my linux ports now: > ls -d linux* linux-cairo-1.0.2_2 linux-jpeg-6b.34_2 linux-expat-1.95.8_2 linux-libsigc-2.0.17_2 linux-f8-alsa-lib-1.0.15_1 linux-libxml2-2.6.19_2 linux-f8-atk-1.20.0_1 linux-nvu-1.0_1 linux-f8-openssl-0.9.8b_1 linux-pango-1.10.2_3 linux-flashplugin-9.0r159 linux-png-1.2.8_4 linux-fontconfig-2.2.3_9 linux-tiff-3.7.1_2 linux-gdk-pixbuf-0.22.0.18.fc4.2_2 linux-xorg-libs-6.8.2_7 linux-gtk2-2.6.10_3 linux_base-f8-8_11 linux-hicolor-icon-theme-0.5_3 linux_dri-7.0_1 cheers luigi > # added by use.perl 2009-06-11 19:19:47 > PERL_VERSION=5.10.0 > sunny:RabbitsDen>pkg_info | grep -i skype > skype-2.0.0.72,1 P2P VoIP software > sunny:RabbitsDen>pkg_info | grep linux > linux-f8-alsa-lib-1.0.15_1 The Advanced Linux Sound Architecture > libraries (Linux Fedo > linux-f8-atk-1.20.0_1 Accessibility Toolkit, Linux/i386 binary (Linux > Fedora 8) > linux-f8-cairo-1.4.14_1 Vector graphics library Cairo (Linux Fedora 8) > linux-f8-expat-2.0.1_1 Linux/i386 binary port of Expat XML-parsing > library (Linux > linux-f8-fontconfig-2.4.2_1 An XML-based font configuration API for X > Windows (Linux Fe > linux-f8-gtk2-2.12.8_1 GTK+ library, version 2.X (Linux Fedora 8) > linux-f8-pango-1.18.4_1 The pango library (Linux Fedora 8) > linux-f8-png-1.2.22_1 RPM of the PNG lib (Linux Fedora 8) > linux-f8-tiff-3.8.2_1 The TIFF library, Linux/i386 binary (Linux Fedora > 8) > linux-f8-xorg-libs-7.3_3 Xorg libraries (Linux Fedora 8) > linux-flashplugin-9.0r159 Adobe Flash Player NPAPI Plugin > linux-hicolor-icon-theme-0.5_3 A high-color icon theme shell from the > FreeDesktop project > linux-jpeg-6b.34_2 RPM of the JPEG lib > linux-libsigc-2.0.17_2 Callback Framework for C++ (linux version) > linux-nvu-1.0_1 A complete Web Authoring System > linux-openssl-0.9.7f_2 SSL and crypto library (Linux Version) > linux-realplayer-10.0.9.809.20070726 Linux RealPlayer 10 from > RealNetworks > linux_base-f8-8_11 Base set of packages needed in Linux mode (for > i386/amd64) > linux_dri-7.0_1 Binary Linux DRI libraries for 3D hardware > acceleration of > > > > cheers > > luigi > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From andrew-freebsd at areilly.bpc-users.org Sat Jun 20 08:37:22 2009 From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly) Date: Sat Jun 20 08:37:31 2009 Subject: Recent 7-STABLE has stopped booting properly (for me): SCSI over umass and firewire implicated Message-ID: <20090620083714.GA1920@duncan.reilly.home> Hi there, Rather than jumping straight to send-pr, I thought that I'd see if anyone had experience or thoughts about this. I've had a couple of external drives on my AMD64-X2 + NVidia system for some time. The Maxtor 300G Firewire drive died recently though, and I replaced it with a 1TB WD "MyBook" firewire+usb2 drive. I also have a WD 750G MyBook that is only USB2. OK, I suspect that the 1TB WD drive might be a problem, but the 750G WD drive *used* to come up just fine. I had it work once on FW, but when I got the run_interrupt_driven_hooks: still waiting for xpt_config problem, I switched it to usb and that seemed to make it happy for a while... Anyway, I did my update-to-stable this morning, and the reboot did not go smoothly. It stopped at the dreaded: un_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config and started again after I unplugged both drives. On another reboot the 750G WD drive didn't probe at all, even after an unplug-replug exercise, and the 1TB drive grabbed da0, which the other usually uses. That time, the boot messages complained (bizarrely): xptioctl: pass driver is not in the kernel xptioctl: put "device pass" in your kernel config file I say bizarrely because I'm running a kernel config that is only: include GENERIC ident DUNCAN device atapicam nodevice atapicd # ATAPI CDROM drives nodevice atapifd # ATAPI floppy drives nodevice atapist # ATAPI tape drives so of course device pass is in there... In summary, the only way that I seem to be able to reliably boot at the moment is to * unplug the external drives while the computer is down, * let it fail to boot while attempting to mount them from the fstab file, * power them up and plug them in, in the right order, * and watch that /dev/da0 and then /dev/da1 are created, * mount them manually, * then exit the shell to allow the system to finish coming up. This clearly isn't a recipe that allows for graceful unattended recovery from power outages or remote system maintenance. I'll attach my most recent dmesg, which is "verbose", in the hope that it helps the discussion. Thanks in advance for any suggestions, -- Andrew -------------- next part -------------- Copyright (c) 1992-2009 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.2-STABLE #65: Sat Jun 20 11:08:34 EST 2009 root@duncan.reilly.home:/usr/obj/usr/src/sys/DUNCAN Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80d6e000. Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 0xffffffff80d6e1a8. Preloaded elf obj module "/boot/kernel/snd_ich.ko" at 0xffffffff80d6e818. Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff80d6ee00. Calibrating clock(s) ... i8254 clock: 1193243 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2211342742 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2211.34-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20fb1 Stepping = 1 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 3207524352 (3058 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000d9c000 - 0x00000000ba57ffff, 3112058880 bytes (759780 pages) avail memory = 3094441984 (2951 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xf6d10/0x0014 (v 0 Nvidia) ACPI: RSDT @ 0x0xbfff3000/0x0030 (v 1 Nvidia AWRDACPI 0x42302E31 AWRD 0x01010101) ACPI: FACP @ 0x0xbfff3040/0x0074 (v 1 Nvidia AWRDACPI 0x42302E31 AWRD 0x01010101) ACPI: DSDT @ 0x0xbfff30c0/0x4C3F (v 1 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000C) ACPI: FACS @ 0x0xbfff0000/0x0040 ACPI: MCFG @ 0x0xbfff7d80/0x003C (v 1 Nvidia AWRDACPI 0x42302E31 AWRD 0x01010101) ACPI: APIC @ 0x0xbfff7d00/0x007C (v 1 Nvidia AWRDACPI 0x42302E31 AWRD 0x01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Interrupt override: source 14, irq 14 MADT: Interrupt override: source 15, irq 15 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jun 20 2009 11:06:41) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.VT86.PDEV -> bus 0 dev 1 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.VT86.PIRQ -> bus 0 dev 1 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bfef0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 5 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 5 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 12 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 12 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 14 15 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 17 Validation 0 255 N 0 17 After Disable 0 255 N 0 17 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 18 Validation 0 255 N 0 18 After Disable 0 255 N 0 18 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 19 Validation 0 255 N 0 19 After Disable 0 255 N 0 19 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 16 N 0 16 Validation 0 16 N 0 16 After Disable 0 255 N 0 16 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link27: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link28: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link29: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link30: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link31: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x10de, dev=0x005e, revid=0xa3 domain=0, bus=0, slot=0, func=0 class=05-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0050, revid=0xa3 domain=0, bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0052, revid=0xa2 domain=0, bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xec00, size 5, enabled map[20]: type I/O Port, range 32, base 0x1c00, size 6, enabled map[24]: type I/O Port, range 32, base 0x1c40, size 6, enabled pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.APCS:0) pci_link26: Picked IRQ 20 with weight 0 pcib0: slot 1 INTA routed to irq 20 via \\_SB_.PCI0.APCS found-> vendor=0x10de, dev=0x005a, revid=0xa2 domain=0, bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf2102000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.APCF:0) pci_link21: Picked IRQ 21 with weight 0 pcib0: slot 2 INTA routed to irq 21 via \\_SB_.PCI0.APCF found-> vendor=0x10de, dev=0x005b, revid=0xa3 domain=0, bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfeb00000, size 8, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.PCI0.APCL:0) pci_link27: Picked IRQ 22 with weight 0 pcib0: slot 2 INTB routed to irq 22 via \\_SB_.PCI0.APCL found-> vendor=0x10de, dev=0x0059, revid=0xa2 domain=0, bus=0, slot=4, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xb800, size 8, enabled map[14]: type I/O Port, range 32, base 0xbc00, size 8, enabled map[18]: type Memory, range 32, base 0xf2105000, size 12, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.PCI0.APCJ:0) pci_link24: Picked IRQ 23 with weight 0 pcib0: slot 4 INTA routed to irq 23 via \\_SB_.PCI0.APCJ found-> vendor=0x10de, dev=0x0053, revid=0xf2 domain=0, bus=0, slot=6, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xf000, size 4, enabled found-> vendor=0x10de, dev=0x0054, revid=0xf3 domain=0, bus=0, slot=7, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x9f0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbf0, size 2, enabled map[18]: type I/O Port, range 32, base 0x970, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb70, size 2, enabled map[20]: type I/O Port, range 32, base 0xd000, size 4, enabled map[24]: type Memory, range 32, base 0xf2100000, size 12, enabled pcib0: matched entry for 0.7.INTA (src \\_SB_.PCI0.APSI:0) pci_link29: Picked IRQ 21 with weight 1 pcib0: slot 7 INTA routed to irq 21 via \\_SB_.PCI0.APSI found-> vendor=0x10de, dev=0x0055, revid=0xf3 domain=0, bus=0, slot=8, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x9e0, size 3, enabled map[14]: type I/O Port, range 32, base 0xbe0, size 2, enabled map[18]: type I/O Port, range 32, base 0x960, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb60, size 2, enabled map[20]: type I/O Port, range 32, base 0xe400, size 4, enabled map[24]: type Memory, range 32, base 0xf2101000, size 12, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.PCI0.APSJ:0) pci_link30: Picked IRQ 22 with weight 1 pcib0: slot 8 INTA routed to irq 22 via \\_SB_.PCI0.APSJ found-> vendor=0x10de, dev=0x005c, revid=0xa2 domain=0, bus=0, slot=9, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x02 (500 ns) found-> vendor=0x10de, dev=0x0057, revid=0xa3 domain=0, bus=0, slot=10, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf2103000, size 12, enabled map[14]: type I/O Port, range 32, base 0xe800, size 3, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.APCH:0) pci_link23: Picked IRQ 23 with weight 1 pcib0: slot 10 INTA routed to irq 23 via \\_SB_.PCI0.APCH found-> vendor=0x10de, dev=0x005d, revid=0xa3 domain=0, bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xa3 domain=0, bus=0, slot=12, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xa3 domain=0, bus=0, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xa3 domain=0, bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xf2102000-0xf2102fff irq 21 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf2102000 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 49 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfeb00000-0xfeb000ff irq 22 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfeb00000 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 50 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered pcm0: port 0xb800-0xb8ff,0xbc00-0xbcff mem 0xf2105000-0xf2105fff irq 23 at device 4.0 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xb800 pcm0: Reserved 0x100 bytes for rid 0x14 type 4 at 0xbc00 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 51 pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: pcm0: Codec features 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features double rate PCM, reserved 1, center DAC, surround DAC, LFE DAC, reserved 5 pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap ba408000, 4000; 0xffffff80000b9000 -> ba408000 pcm0: sndbuf_setmap ba40c000, 4000; 0xffffff80000bd000 -> ba40c000 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=60 ostat1=70 ata0: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata0: reset tp2 stat0=20 stat1=30 devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 52 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=01 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x04 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 53 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd000-0xd00f mem 0xf2100000-0xf2100fff irq 21 at device 7.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd000 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xf2100000 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata2: SATA connect time=0ms ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata3: SATA connect time=0ms ata3: reset tp1 mask=01 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xe400-0xe40f mem 0xf2101000-0xf2101fff irq 22 at device 8.0 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe400 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xf2101000 ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata4: SATA connect status=00000000 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata5: SATA connect status=00000000 ata5: [MPSAFE] ata5: [ITHREAD] pcib1: at device 9.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xf2000000-0xf20fffff pcib1: no prefetched decode pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x104c, dev=0x8025, revid=0x01 domain=0, bus=1, slot=10, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf2004000, size 11, enabled pcib1: requested memory range 0xf2004000-0xf20047ff: good map[14]: type Memory, range 32, base 0xf2000000, size 14, enabled pcib1: requested memory range 0xf2000000-0xf2003fff: good pcib1: matched entry for 1.10.INTA (src \\_SB_.PCI0.APC3:0) pci_link18: Picked IRQ 18 with weight 0 pcib1: slot 10 INTA routed to irq 18 via \\_SB_.PCI0.APC3 fwohci0: mem 0xf2004000-0xf20047ff,0xf2000000-0xf2003fff irq 18 at device 10.0 on pci1 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xf2004000 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 54 fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:14:85:56:00:e6:80:b0 fwohci0: invalid speed 7 (fixed to 3). fwohci0: Phy 1394a available S800, 3 ports. fwohci0: Link S800, max_rec 4096 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:14:85:e6:80:b0 fwe0: bpf attached fwe0: Ethernet address: 02:14:85:e6:80:b0 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:14:85:56:00:e6:80:b0 @ 0xfffe00000000, S800, maxrec 4096 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xba52c000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode nfe0: port 0xe800-0xe807 mem 0xf2103000-0xf2103fff irq 23 at device 10.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf2103000 miibus0: on nfe0 ciphy0: PHY 7 on miibus0 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:14:85:e7:78:60 nfe0: [MPSAFE] nfe0: [FILTER] pcib2: at device 11.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x9000-0x9fff pcib2: no prefetched decode pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR3 - AE_NOT_FOUND pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: at device 12.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x8000-0x8fff pcib3: no prefetched decode pcib3: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR2 - AE_NOT_FOUND pci3: on pcib3 pci3: domain=0, physical bus=3 pcib4: at device 13.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x7000-0x7fff pcib4: no prefetched decode pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR1 - AE_NOT_FOUND pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: at device 14.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xa000-0xafff pcib5: memory decode 0xf0000000-0xf1ffffff pcib5: prefetched decode 0xe0000000-0xefffffff pcib5: could not get PCI interrupt routing table for \\_SB_.PCI0.XVR0 - AE_NOT_FOUND pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x1002, dev=0x9598, revid=0x00 domain=0, bus=5, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib5: requested memory range 0xe0000000-0xefffffff: good map[18]: type Memory, range 64, base 0xf1000000, size 16, enabled pcib5: requested memory range 0xf1000000-0xf100ffff: good map[20]: type I/O Port, range 32, base 0xa000, size 8, enabled pcib5: requested I/O range 0xa000-0xa0ff: in range pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.APC3:0) pcib0: slot 14 INTA routed to irq 18 via \\_SB_.PCI0.APC3 pcib5: slot 0 INTA is routed to irq 18 found-> vendor=0x1002, dev=0xaa20, revid=0x00 domain=0, bus=5, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf1010000, size 14, enabled pcib5: requested memory range 0xf1010000-0xf1013fff: good pcib0: matched entry for 0.14.INTB (src \\_SB_.PCI0.APC4:0) pci_link19: Picked IRQ 19 with weight 0 pcib0: slot 14 INTB routed to irq 19 via \\_SB_.PCI0.APC4 pcib5: slot 0 INTB is routed to irq 19 vgapci0: port 0xa000-0xa0ff mem 0xe0000000-0xefffffff,0xf1000000-0xf100ffff irq 18 at device 0.0 on pci5 pci5: at device 0.1 (no driver attached) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 55 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 56 sio1: [FILTER] ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 57 ppbus0: [MPSAFE] ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 1: ioport 0x1c00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices ums0: on uhub0 ums0: 2 buttons. uscanner0: on uhub0 Device configuration finished. Reducing kern.maxvnodes 196147 -> 100000 procfs registered lapic: Divisor 2, Frequency 100515587 hz Timecounter "TSC" frequency 2211342742 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected.firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fwohci0: phy int ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 715403MB at ata2-master SATA150 ad4: 1465147055 sectors [1453518C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: nVidia check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 715404MB at ata3-master SATA150 ad6: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: nVidia check1 failed ad6: Adaptec check1 failed GEOM_MIRROR: Device mirror/gm0 launched (2/2). ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed pcm0: measured ac97 link rate at 47997 Hz, will use 48000 Hz GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/4a34e7954ade199c. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/4a34e7addf0b3850. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/4a34e79577a524cd. unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe0:ata1:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata1:0:0:0): CAM Status: SCSI Status Error (probe0:ata1:0:0:0): SCSI Status: Check Condition (probe0:ata1:0:0:0): UNIT ATTENTION asc:29,0 (probe0:ata1:0:0:0): Power on, reset, or bus device reset occurred (probe0:ata1:0:0:0): (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata1:0:0:0): UNIT ATTENTION asc:29,0 (probe0:ata1:0:0:0): Power on, reset, or bus device reset occurred Retrying Command (per Sense Data) (probe0:ata1:0:0:0): Retrying Command (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata1:0:0:0): CAM Status: SCSI Status Error (probe0:ata1:0:0:0): SCSI Status: Check Condition (probe0:ata1:0:0:0): NOT READY asc:3a,0 (probe0:ata1:0:0:0): Medium not present (probe0:ata1:0:0:0): (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata1:0:0:0): NOT READY asc:3a,0 (probe0:ata1:0:0:0): Medium not present Unretryable error (probe0:ata1:0:0:0): error 6 (probe0:ata1:0:0:0): Unretryable Error (probe1:sbp0:0:0:0): error 22 (probe1:sbp0:0:0:0): Unretryable Error (probe2:sbp0:0:1:0): error 22 (probe2:sbp0:0:1:0): Unretryable Error (probe3:sbp0:0:2:0): error 22 (probe3:sbp0:0:2:0): Unretryable Error (probe4:sbp0:0:3:0): error 22 (probe4:sbp0:0:3:0): Unretryable Error (probe5:sbp0:0:4:0): error 22 (probe5:sbp0:0:4:0): Unretryable Error (probe6:sbp0:0:5:0): error 22 (probe6:sbp0:0:5:0): Unretryable Error (probe7:sbp0:0:6:0): error 22 (probe7:sbp0:0:6:0): Unretryable Error (probe0:ata1:0:0:0): error 6 (probe0:ata1:0:0:0): Unretryable Error unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error pass0 at ata1 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 3.300MB/s transfers GEOM: new disk cd0 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00040010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 7 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning ISA IRQ 15 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 21 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 ioapic0: Assigning PCI IRQ 23 to local APIC 0 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error scsi_cd.c::ioctl cmd=4400648b error=25 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error Trying to mount root from ufs:/dev/mirror/gm0s1a start_init: trying /sbin/init GEOM_LABEL: Label ufsid/4a34e7954ade199c removed. GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/4a34e7954ade199c. GEOM_LABEL: Label ufsid/4a34e7addf0b3850 removed. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/4a34e7addf0b3850. GEOM_LABEL: Label ufsid/4a34e79577a524cd removed. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/4a34e79577a524cd. GEOM_LABEL: Label ufsid/4a34e7954ade199c removed. GEOM_LABEL: Label ufsid/4a34e7addf0b3850 removed. GEOM_LABEL: Label ufsid/4a34e79577a524cd removed. umass0: on uhub1 umass0:7:0:-1: Attached to scbus7 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? pass1 at umass-sim0 bus 0 target 0 lun 0 pass1: E OFMi:x ende wD irdeicstk Adac0ce ss SCSI-0 device pass1: 40.000MB/s transfers da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) GEOM_LABEL: Label for provider da0s1a is ufsid/484a3a0a61af3002. GEOM_LABEL: Label ufsid/484a3a0a61af3002 removed. fwohci0: BUS reset fwohci0: node_id=0x8800ffc0, gen=2, non CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 0 (me) firewire0: root node is not cycle master capable firewire0: bus manager 0 (me) fwohci0: too many cycle lost, no cycle master presents? fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=3, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=4, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) firewire0: New S800 device ID:0090a97488ce53aa (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error pass2 at sbp0 bus 0 target 0 lun 0 pass2: dFai1x ed Direct Access SCSI-4 device pass2: 50.000MB/s transfers da1 at sbp0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-4 device da1: 50.000MB/s transfers da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) GEOM_LABEL: Label for provider da1s1a is ufsid/4a324039d6307dd3. (probe0:sbp0:0:0:1): error 22 (probe0:sbp0:0:0:1): Unretryable Error ses0 at sbp0 bus 0 target 0 lun 1 ses0: Fixed Enclosure Services SCSI-4 device ses0: 50.000MB/s transfers ses0: SCSI-3 SES Device pass3 at sbp0 bus 0 target 0 lun 1 pass3: Fixed Enclosure Services SCSI-4 device pass3: 50.000MB/s transfers GEOM_LABEL: Label ufsid/4a324039d6307dd3 removed. GEOM_LABEL: Label for provider da0s1a is ufsid/484a3a0a61af3002. GEOM_LABEL: Label for provider da1s1a is ufsid/4a324039d6307dd3. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/4a34e79577a524cd. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/4a34e7addf0b3850. GEOM_LABEL: Label ufsid/4a34e7addf0b3850 removed. GEOM_LABEL: Label ufsid/4a34e79577a524cd removed. GEOM_LABEL: Label ufsid/4a324039d6307dd3 removed. GEOM_LABEL: Label ufsid/484a3a0a61af3002 removed. GEOM_LABEL: Label for provider md0 is ufsid/4a3c9978d1b40db4. GEOM_LABEL: Label ufsid/4a3c9978d1b40db4 removed. nfe0: link state changed to UP fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 splash: image decoder found: green_saver From onemda at gmail.com Sat Jun 20 10:01:11 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Jun 20 10:01:18 2009 Subject: kernel wants the wrong driver for my NIC (new issue) In-Reply-To: <20090619230802.GA5795@unix.csbsju.edu> References: <20090619172429.GA5197@unix.csbsju.edu> <20090619230802.GA5795@unix.csbsju.edu> Message-ID: <3a142e750906200301p28018687p16fae7d4bb767f1f@mail.gmail.com> On 6/20/09, Michael Gass wrote: > On Fri, Jun 19, 2009 at 12:24:29PM -0500, Michael Gass wrote: >> I'm running 7.2-stable and I replaced an old ISA NIC with >> a D-Link DFE-530TX+ card. According to the manual, the >> correct driver for this card is rl driver. The kernel >> insists on using the vr driver which is for the DFE-530TX. >> >From what I can tell, the two cards have different chipsets >> and so the drivers are not compatable. >> > > I got the vr driver to work: it was an IRQ issue. Seems > sio1 wanted irq 3 which is what vr0 was taking. Somehow that > caused a problem. > > BUT > > I am still confused about the rl driver not working for this > card. The NOTES in /usr/src/sys/conf/NOTES explicitly state > that the rl driver is for the DFE-530TX+ and that the vr > driver is for the DFE-530TX. I have the former and so should > be using the rl drive it seems. Is this a mistake in the > documentation (including the man page for each driver)? > > I made a new kernel without the vr driver and the result was > that no driver at all was recognized for the NIC. > Is there a way to force the kernel to put an entry in /dev > for rl0 so that I could try to configue it for the NIC? Yes, modify source code and recompile and reinstall/kldload kernel/module. -- Paul From dan.naumov at gmail.com Sat Jun 20 21:29:28 2009 From: dan.naumov at gmail.com (Dan Naumov) Date: Sat Jun 20 21:29:34 2009 Subject: ufs2 / softupdates / ZFS / disk write cache Message-ID: I have the following setup: A single consumer-grade 2tb SATA disk: Western Digital Green (model WDC WD20EADS-00R6B0). This disk is setup like this: 16gb root partition with UFS2 + softupdates, containing mostly static things: /bin /boot /etc /root /sbin /usr /var and such a 1,9tb non-redundant zfs pool on top of a slice, it hosts things like: /DATA, /home, /usr/local, /var/log and such. What should I do to ensure (as much as possible) filesystem consistency of the root filesystem in the case of the power loss? I know there have been a lot of discussions on the subject of consumer-level disks literally lying about the state of files in transit (disks telling the system that files have been written to disk while in reality they are still in disk's write cache), in turn throwing softupdates off balance (since softupdates assumes the disks don't lie about such things), in turn sometimes resulting in severe data losses in the case of a system power loss during heavy disk IO. One of the solutions that was often brought up in the mailing lists is disabling the actual disk write cache via adding hw.ata.wc=0 to /boot/loader.conf, FreeBSD 4.3 actually even had this setting by default, but this was apparently reverted back because some people have reported a write performance regression on the tune of becoming 4-6 times slower. So what should I do in my case? Should I disable disk write cache via the hw.ata.wc tunable? As far as I know, ZFS has a write cache of it's own and since the ufs2 root filesystem in my case is mostly static data, I am guessing I "shouldn't" notice that big of a performance hit. Or am I completely in the wrong here and setting hw.ata.wc=0 is going to adversely affect the write performance on both the root partition AND the zfs pool despite zfs using it's own write cache? Another thing I have been pondering is: I do have 2gb of space left unused on the system (currently being used as swap, I have 2 swap slices, one 1gb at the very beginning of the disk, the other being 2gb at the end), which I could turn into a GJOURNAL for the root filesystem... Sincerely, - Dan Naumov From naddy at mips.inka.de Sat Jun 20 23:11:45 2009 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sat Jun 20 23:11:58 2009 Subject: kernel wants the wrong driver for my NIC (new issue) References: <20090619172429.GA5197@unix.csbsju.edu> <20090619230802.GA5795@unix.csbsju.edu> Message-ID: Michael Gass wrote: > I am still confused about the rl driver not working for this > card. The NOTES in /usr/src/sys/conf/NOTES explicitly state > that the rl driver is for the DFE-530TX+ and that the vr > driver is for the DFE-530TX. I have the former and so should > be using the rl drive it seems. It's D-Link. They change the hardware without changing model numbers. -- Christian "naddy" Weisgerber naddy@mips.inka.de From ertr1013 at student.uu.se Sat Jun 20 23:11:46 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Sat Jun 20 23:11:59 2009 Subject: ufs2 / softupdates / ZFS / disk write cache In-Reply-To: References: Message-ID: <20090620231130.GA88907@owl.midgard.homeip.net> On Sun, Jun 21, 2009 at 12:29:26AM +0300, Dan Naumov wrote: > I have the following setup: > > A single consumer-grade 2tb SATA disk: Western Digital Green (model > WDC WD20EADS-00R6B0). This disk is setup like this: > > 16gb root partition with UFS2 + softupdates, containing mostly static things: > /bin /boot /etc /root /sbin /usr /var and such > > a 1,9tb non-redundant zfs pool on top of a slice, it hosts things like: > /DATA, /home, /usr/local, /var/log and such. > > What should I do to ensure (as much as possible) filesystem > consistency of the root filesystem in the case of the power loss? I > know there have been a lot of discussions on the subject of > consumer-level disks literally lying about the state of files in > transit (disks telling the system that files have been written to disk > while in reality they are still in disk's write cache), in turn > throwing softupdates off balance (since softupdates assumes the disks > don't lie about such things), in turn sometimes resulting in severe > data losses in the case of a system power loss during heavy disk IO. Note that this is not something specific to softupdates, but applies when you are not using softupdates as well. > > One of the solutions that was often brought up in the mailing lists is > disabling the actual disk write cache via adding hw.ata.wc=0 to > /boot/loader.conf, FreeBSD 4.3 actually even had this setting by > default, but this was apparently reverted back because some people > have reported a write performance regression on the tune of becoming > 4-6 times slower. So what should I do in my case? Should I disable > disk write cache via the hw.ata.wc tunable? As far as I know, ZFS has > a write cache of it's own and since the ufs2 root filesystem in my > case is mostly static data, I am guessing I "shouldn't" notice that > big of a performance hit. Or am I completely in the wrong here and > setting hw.ata.wc=0 is going to adversely affect the write performance > on both the root partition AND the zfs pool despite zfs using it's own > write cache? Why don't you try it and see if you notice the performance hit? You will almost certainly see some reduced write performance if you disable the disk's cache, but how noticable this will be for your setup and your disk usage is something only you can answer. My guess is that it will be quite noticable, but that is only a guess. (Keep in mind that UFS+softupdates does quite a bit of write-caching on its own, so just switching to ZFS is unlikely to improve write performance significantly compared to using UFS.) -- Erik Trulsson ertr1013@student.uu.se From kris at FreeBSD.org Sun Jun 21 12:18:37 2009 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jun 21 12:18:44 2009 Subject: Patch for FreeBSD 7.0 deadlock In-Reply-To: References: Message-ID: <4A3D644E.4090806@FreeBSD.org> Santosh Rao Gururajan wrote: > I am seeing problems with FreeBSD 7.0 machines that have the symptoms > described in > http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/043241.html > Can someone please point me to a patch which has a fix for the issue > described in that thread? The fix to that particular problem is included in later releases. Kris From ronald-freebsd8 at klop.yi.org Sun Jun 21 22:25:58 2009 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Sun Jun 21 22:26:20 2009 Subject: ufs2 / softupdates / ZFS / disk write cache In-Reply-To: References: Message-ID: On Sat, 20 Jun 2009 23:29:26 +0200, Dan Naumov wrote: > I have the following setup: > > A single consumer-grade 2tb SATA disk: Western Digital Green (model > WDC WD20EADS-00R6B0). This disk is setup like this: > > 16gb root partition with UFS2 + softupdates, containing mostly static > things: > /bin /boot /etc /root /sbin /usr /var and such > > a 1,9tb non-redundant zfs pool on top of a slice, it hosts things like: > /DATA, /home, /usr/local, /var/log and such. > > What should I do to ensure (as much as possible) filesystem > consistency of the root filesystem in the case of the power loss? I > know there have been a lot of discussions on the subject of > consumer-level disks literally lying about the state of files in > transit (disks telling the system that files have been written to disk > while in reality they are still in disk's write cache), in turn > throwing softupdates off balance (since softupdates assumes the disks > don't lie about such things), in turn sometimes resulting in severe > data losses in the case of a system power loss during heavy disk IO. > > One of the solutions that was often brought up in the mailing lists is > disabling the actual disk write cache via adding hw.ata.wc=0 to > /boot/loader.conf, FreeBSD 4.3 actually even had this setting by > default, but this was apparently reverted back because some people > have reported a write performance regression on the tune of becoming > 4-6 times slower. So what should I do in my case? Should I disable > disk write cache via the hw.ata.wc tunable? As far as I know, ZFS has > a write cache of it's own and since the ufs2 root filesystem in my > case is mostly static data, I am guessing I "shouldn't" notice that > big of a performance hit. Or am I completely in the wrong here and > setting hw.ata.wc=0 is going to adversely affect the write performance > on both the root partition AND the zfs pool despite zfs using it's own > write cache? > > Another thing I have been pondering is: I do have 2gb of space left > unused on the system (currently being used as swap, I have 2 swap > slices, one 1gb at the very beginning of the disk, the other being 2gb > at the end), which I could turn into a GJOURNAL for the root > filesystem... Using gjournal is a very trusted way for a good balance in consistency and speed. I don't know about any performance impact of having the journal at the other 'end' of the disk than where the fs is. You can try, because switching back is possible. Ronald. From me at dbolgheroni.eng.br Mon Jun 22 05:49:12 2009 From: me at dbolgheroni.eng.br (Daniel Bolgheroni) Date: Mon Jun 22 05:49:36 2009 Subject: Open Vs Free BSD In-Reply-To: <20090619095832.GA58127@intserv.int1.b.intern> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <20090619095832.GA58127@intserv.int1.b.intern> Message-ID: 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 FEI - Faculdade de Engenharia Industrial http://www.dbolgheroni.eng.br/mykey ASCII ribbon campaign ( ) against HTML e-mail X / \ From Anton.Parol at Sun.COM Mon Jun 22 07:59:22 2009 From: Anton.Parol at Sun.COM (Anton Parol) Date: Mon Jun 22 07:59:29 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <20090619095832.GA58127@intserv.int1.b.intern> Message-ID: <4A3F39CC.70908@sun.com> OBSD is the best choice of OS for people who like violent little fish mascots. And it has blue-boot-console-thingy (tm) . Ace. From borjam at sarenet.es Mon Jun 22 08:00:50 2009 From: borjam at sarenet.es (Borja Marcos) Date: Mon Jun 22 08:01:03 2009 Subject: ZFS user library? In-Reply-To: <1E4B9A40-F510-42E4-8A0B-26BA01A1679C@ee.ryerson.ca> References: <3c1674c90906181021n54bd6fbei2a1a843033bc91c@mail.gmail.com> <1E4B9A40-F510-42E4-8A0B-26BA01A1679C@ee.ryerson.ca> Message-ID: <8A85A6B2-2122-4D8A-BF11-F2975B1A130F@sarenet.es> On Jun 18, 2009, at 11:35 PM, David Magda wrote: > Is there something specific you're looking to do? The file system > layer of ZFS (the "ZPL") is in flux, but there may be other > components (e.g., DMU) that may be more stable (the Lustre folks are > coding against it in user land). See pages 7 and 8 for the three > main layers: > > http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf I see... Not rocket science actually. Just the standard functionality of zfs(8) without resorting to ugly execve and text parsing, something more reliable to list snapshots, etc. Maybe it's a matter of waiting... Borja. From michal at sharescope.co.uk Mon Jun 22 08:39:48 2009 From: michal at sharescope.co.uk (Michal) Date: Mon Jun 22 08:40:02 2009 Subject: Open Vs Free BSD In-Reply-To: <20090619192403.GB2227@comcast.net> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk><200906190623.10417.andres@msu.edu><20090619182326.GX12531@manor.msen.com> <20090619192403.GB2227@comcast.net> Message-ID: <0E1367A0B64E41F1A29BF418553B9CA4@ionicoffice.ionic.co.uk> -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Charlie Kester Sent: 19 June 2009 20:24 To: freebsd-stable@freebsd.org Subject: Re: Open Vs Free BSD On Fri 19 Jun 2009 at 11:23:26 PDT Michael R. Wayne wrote: > >OK, I'm going to take a guess here that English may not be Michal's primary >language and re-ask his question: > > Given the several versions of *BSD, I have been led to understand > that each excells in different ways. How do I select which one > is right for my application, what are the underlying reasons > that would lead me to that choice and what are the the disadvantages > I am risking? > >This is, actually, not an inappropriate question coming from a potential >new user who is not familiar with the history surrounding the various >versions and would make an outstanding FAQ. As an example, we run FreeBSD >on our firewalling machines because it works well enough and we prefer the >reduced support costs of using a single O/S across our network. I am unsure >of what the advantage of moving to OpenBSD might be and would find it very >difficult to quantify the advantages (if any) versus the increased support >resources required. > >This is a very real issue. Linux has a similar problem; I've personally >been in meetings where clients examined the myriad Linux distributions >and say "It's very likely that we will make the incorrect choice. So we'll >go with Windows." I suspect similar events have occurred with *BSD. So, >rather than jumping on people about them bringing up religous wars (because, >face it, you CAN edit a file perfectly well in either vi or emacs :-), we'd >all be better served by giving them enough information to make the >right choice in their situation while realizing the tradeoffs they are >making. 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? ------------------ Sorry, I would just like to add that English is my first and only language. As I said at a Terremark Europe meeting, (everyone else spoke [mostly] Dutch and English, I speak English and bad English. I think my dyslexia and general ignorance may have caused the confusion in my question. I was never asking WHO WINS WHO WINS, as I have multiple OS's running, more looking forward 2-5 years, upgrades and so forth, what should I take in to account. >From the answers I have got, I've learn that I should ask my questions better, most importantly I think there, and OBSD may not have lots of packages but it has brilliant security. A desktop might be served better with Linux of FreeBSD, but at the end of the day, it's your horse, your course. You choose as you wish. I thank you all From holger.kipp at alogis.com Mon Jun 22 09:09:16 2009 From: holger.kipp at alogis.com (Holger Kipp) Date: Mon Jun 22 09:09:24 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <20090619095832.GA58127@intserv.int1.b.intern> Message-ID: <4A3F46F2.7020904@alogis.com> Daniel Bolgheroni schrieb: > 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. > I don't think so: *NetBSD say on their website:* NetBSD is a free, fast, secure, and _highly_portable_ Unix-like Open Source operating system. It is available for a _wide_range_of_platforms_, from large-scale servers and powerful desktop systems to handheld and embedded devices. Its clean design and advanced features make it excellent for use in both production and research environments, and the source code is freely available under a business-friendly license. *OpenBSD say on their website:* The OpenBSD project produces a *FREE*, multi-platform 4.4BSD-based UNIX-like operating system. Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography . *FreeBSD say on their website:* FreeBSD is an advanced operating system for _x86_compatible (including Pentium? and Athlon^(TM)), _amd64_compatible_ (including Opteron^(TM), Athlon^(TM)64, and EM64T), ARM, IA-64, PowerPC, PC-98 and UltraSPARC? architectures. [..] With over 20,000 ported libraries and applications , FreeBSD supports applications for desktop, server, appliance, and embedded environments. Actually I like it this way, because every BSD variant has a different focus and is trying different ways to solve problems or fullfill user requirements. Whatever turns out to be best will be incorporated into the other *BSDs whenever the need arises. Each of the mentioned BSDs has its advantages and disadvantages, so what? Choose the system you seem best suited for your needs. Afaik some developers are also working on several BSD-flavours. > 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 was a fork of NetBSD but is having more of a focus on security. This is a good thing. We might not have OpenSSH, PF etc. without it. Afaik OpenBSD however is using a simple Giant Lock for MP which FreeBSD got rid of some time ago (wasn't an easy task) which now results in very good scalability of FreeBSD on MP systems. I have not checked how NetBSD is handling MP and have also not conducted any performance tests in this area, though. > OpenBSD is a GENERIC OS which can be used to do _almost_ every task a > computer system is able to. > This is true for all unix-like (and many other) operating systems. I don't see the point here. The OP did not intend to start a flame war, and I don't either. I like OpenBSD (because of the security features and supported platforms). I like NetBSD (because of the supported platforms - especially RiscPCs - and the clean implementation). I like FreeBSD because of the many available ports (which in the past was a reason to choose FreeBSD over NetBSD or OpenBSD on x86-hardware) and for other reasons. There is no general "a is better than b" here. It all depends on the requirements and what you're familiar with. I prefer FreeBSD because I have ipf, ipfw and pf to chose from, it has good MP support, ZFS and never let me down since 2.2.8. I also use OpenBSD and NetBSD occasionally and support their projects by buying their CDs and T-Shirts ever now and then. Best regards, Holger From ericfurman at fastmail.net Mon Jun 22 09:41:09 2009 From: ericfurman at fastmail.net (Eric Furman) Date: Mon Jun 22 09:41:17 2009 Subject: Open Vs Free BSD In-Reply-To: <4A3F46F2.7020904@alogis.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <20090619095832.GA58127@intserv.int1.b.intern> <4A3F46F2.7020904@alogis.com> Message-ID: <1245662976.25920.1321530053@webmail.messagingengine.com> BWAAAHAHAHAHAH, what a bunch of retards Please stop sending this crap to OBSD lists. On Mon, 22 Jun 2009 10:55:14 +0200, "Holger Kipp" said: > Daniel Bolgheroni schrieb: > > 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. > > > I don't think so: > > *NetBSD say on their website:* > NetBSD is a free, fast, secure, and _highly_portable_ Unix-like Open > Source operating system. It is available for a > _wide_range_of_platforms_, from large-scale servers and powerful desktop > systems to handheld and embedded devices. Its clean design and advanced > features make it excellent for use in both production and research > environments, and the source code is freely available under a > business-friendly license. > > *OpenBSD say on their website:* > The OpenBSD project produces a *FREE*, multi-platform 4.4BSD-based > UNIX-like operating system. Our efforts emphasize portability, > standardization, correctness, proactive security > and integrated cryptography > . > > *FreeBSD say on their website:* > FreeBSD is an advanced operating system for _x86_compatible (including > Pentium. and Athlon^(TM)), _amd64_compatible_ (including Opteron^(TM), > Athlon^(TM)64, and EM64T), ARM, IA-64, PowerPC, PC-98 and UltraSPARC. > architectures. > [..] > With over 20,000 ported libraries and applications > , FreeBSD supports > applications for desktop, server, appliance, and embedded environments. > > > Actually I like it this way, because every BSD variant has a different > focus and is trying different ways to solve problems or fullfill user > requirements. Whatever turns out to be best will be incorporated into > the other *BSDs whenever the need arises. Each of the mentioned BSDs has > its advantages and disadvantages, so what? Choose the system you seem > best suited for your needs. Afaik some developers are also working on > several BSD-flavours. > > 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 was a fork of NetBSD but is having more of a focus on security. > This is a good thing. We might not have OpenSSH, PF etc. without it. > Afaik OpenBSD however is using a simple Giant Lock for MP which FreeBSD > got rid of some time ago (wasn't an easy task) which now results in very > good scalability of FreeBSD on MP systems. I have not checked how NetBSD > is handling MP and have also not conducted any performance tests in this > area, though. > > OpenBSD is a GENERIC OS which can be used to do _almost_ every task a > > computer system is able to. > > > This is true for all unix-like (and many other) operating systems. I > don't see the point here. > > The OP did not intend to start a flame war, and I don't either. I like > OpenBSD (because of the security features and supported platforms). I > like NetBSD (because of the supported platforms - especially RiscPCs - > and the clean implementation). I like FreeBSD because of the many > available ports (which in the past was a reason to choose FreeBSD over > NetBSD or OpenBSD on x86-hardware) and for other reasons. There is no > general "a is better than b" here. It all depends on the requirements > and what you're familiar with. > > I prefer FreeBSD because I have ipf, ipfw and pf to chose from, it has > good MP support, ZFS and never let me down since 2.2.8. > I also use OpenBSD and NetBSD occasionally and support their projects by > buying their CDs and T-Shirts ever now and then. > > Best regards, > Holger > From utisoft at googlemail.com Mon Jun 22 10:21:00 2009 From: utisoft at googlemail.com (Chris Rees) Date: Mon Jun 22 10:21:06 2009 Subject: Open Vs Free BSD In-Reply-To: <1245662976.25920.1321530053@webmail.messagingengine.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <20090619095832.GA58127@intserv.int1.b.intern> <4A3F46F2.7020904@alogis.com> <1245662976.25920.1321530053@webmail.messagingengine.com> Message-ID: 2009/6/22 Eric Furman : > BWAAAHAHAHAHAH, what a bunch of ?retards > Please stop sending this crap to OBSD lists. > Oh yeah, OpenBSD people also tend to be *very* direct with conversations, demonstrated by Eric here. Not entirely a criticism, it's just that you can expect the climate in mailing lists to be completely different. Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? From matthias.andree at gmx.de Mon Jun 22 11:48:43 2009 From: matthias.andree at gmx.de (Matthias Andree) Date: Mon Jun 22 11:48:53 2009 Subject: Fix bin/102299 (has patch in PR)? Message-ID: Greetings, could anybody have a look at bin/102299 please? The PR contains a patch to fix malloc() differences between GNU libc and FreeBSD's libc, so this should be little effort. Thank you. Best regards -- Matthias Andree From vanopen at gmail.com Mon Jun 22 12:39:48 2009 From: vanopen at gmail.com (Wu, Yue) Date: Mon Jun 22 12:39:58 2009 Subject: Use n instead of Fn for choosing the OS when booting? Message-ID: <20090622123938.GA794@fbsd.hasee.cpu> Hi, list, Freebsd uses Fn to choose Nth OS on the disk, I have installed FreeBSD on the second slice of disk, so I use F2 to choose it, but sometimes I hit F2 occasionally before the boot menu is up, and F2 is my notebook for entering the setup menu, so I go into BIOS setup menu, it's annoying me sometimes, so I think why not use number key(0~9) instead of F1~F12 for choosing OS? -- Hi, Wu, Yue From eugen at kuzbass.ru Mon Jun 22 13:13:16 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Jun 22 13:13:24 2009 Subject: Use n instead of Fn for choosing the OS when booting? In-Reply-To: <20090622123938.GA794@fbsd.hasee.cpu> References: <20090622123938.GA794@fbsd.hasee.cpu> Message-ID: <20090622131311.GA39134@svzserv.kemerovo.su> On Mon, Jun 22, 2009 at 08:39:38PM +0800, Wu, Yue wrote: > Freebsd uses Fn to choose Nth OS on the disk, I have installed FreeBSD on the > second slice of disk, so I use F2 to choose it, but sometimes I hit F2 > occasionally before the boot menu is up, and F2 is my notebook for entering > the setup menu, so I go into BIOS setup menu, it's annoying me sometimes, so > I think why not use number key(0~9) instead of F1~F12 for choosing OS? In fact, BootEasy does use both - F-keys and number keys, just give it a try. Eugene Grosbein From dsuzukisanders at gmail.com Mon Jun 22 17:05:46 2009 From: dsuzukisanders at gmail.com (David Sanders) Date: Mon Jun 22 17:05:53 2009 Subject: Open Vs Free BSD In-Reply-To: <1245662976.25920.1321530053@webmail.messagingengine.com> References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <20090619095832.GA58127@intserv.int1.b.intern> <4A3F46F2.7020904@alogis.com> <1245662976.25920.1321530053@webmail.messagingengine.com> Message-ID: <6228eb140906220936w1a691ecet38ce7c0480d157a8@mail.gmail.com> 2009/6/22 Eric Furman > BWAAAHAHAHAHAH, what a bunch of retards > Please stop sending this crap to OBSD lists. That is surely one of the most brilliant replies I've ever seen from an advocacy@ address. Yes, I am being sarcastic. From kmacy at freebsd.org Mon Jun 22 18:45:42 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon Jun 22 18:45:49 2009 Subject: Open Vs Free BSD In-Reply-To: References: <735E59909DEB44AF92825EA7C65CF430@ionicoffice.ionic.co.uk> <20090619095832.GA58127@intserv.int1.b.intern> Message-ID: <3c1674c90906221145r5859316cvb63fe6a893f22c4a@mail.gmail.com> freebsd-stable is not an advocacy list. This is very off-topic. On Mon, Jun 22, 2009 at 7:06 PM, Daniel Bolgheroni 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 > 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-unsubscribe@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 From exemys at exemys.com Mon Jun 22 20:14:01 2009 From: exemys at exemys.com (Exemys) Date: Mon Jun 22 20:14:48 2009 Subject: Analog Inputs over Ethernet-WiFi-Cellular Message-ID: <1e41c6b8d28b6f50f228461e4676c97f@www.hostmailing.com> This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From santosh at fastsoft.com Mon Jun 22 21:09:14 2009 From: santosh at fastsoft.com (Santosh Rao Gururajan) Date: Mon Jun 22 21:09:21 2009 Subject: Patch for FreeBSD 7.0 deadlock In-Reply-To: <4A3D644E.4090806@FreeBSD.org> Message-ID: > > The fix to that particular problem is included in later releases. > > Kris Hi Kris. I currently cannot upgrade from FreeBSD 7.0 because it breaks some other parts of my project and also for some other non-technical reasons. It would be a lot easier for me if I had the changeset. So if it is not too much bother can you send me a link to the changeset/MFC? Thanks, -santosh From allnetgroup at yahoo.com Mon Jun 22 22:13:07 2009 From: allnetgroup at yahoo.com (ALLnetgroup) Date: Mon Jun 22 22:13:15 2009 Subject: Adding multiipul virtual domains? Message-ID: <849040.64121.qm@web34307.mail.mud.yahoo.com> I have 3 virtual domains I need to add to FreeBSD 7.2-RELEASE server using Terminal or Webmin preferably Terminal. ? ? Thanks, Michael? From glen.j.barber at gmail.com Mon Jun 22 22:22:15 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Mon Jun 22 22:22:55 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <849040.64121.qm@web34307.mail.mud.yahoo.com> References: <849040.64121.qm@web34307.mail.mud.yahoo.com> Message-ID: <4ad871310906221522o1e20d15bhae257bb500519c6@mail.gmail.com> On Mon, Jun 22, 2009 at 5:46 PM, ALLnetgroup wrote: > I have 3 virtual domains I need to add to FreeBSD 7.2-RELEASE server using Terminal or Webmin preferably Terminal. > > Virtual domains for what? -- Glen Barber From glen.j.barber at gmail.com Mon Jun 22 22:24:54 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Mon Jun 22 22:25:01 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <91315.14357.qm@web34304.mail.mud.yahoo.com> References: <91315.14357.qm@web34304.mail.mud.yahoo.com> Message-ID: <4ad871310906221524s6c556822tb8cfc99e6da2fc1e@mail.gmail.com> On Mon, Jun 22, 2009 at 6:23 PM, ALLnetgroup wrote: > For 3 domain names I just recieved. > Please don't just reply to me, because the rest of the list doesn't see your response. Your question is extremely vague. What are you trying to do? -- Glen Barber From allnetgroup at yahoo.com Mon Jun 22 22:42:43 2009 From: allnetgroup at yahoo.com (ALLnetgroup) Date: Mon Jun 22 22:42:52 2009 Subject: Adding multiipul virtual domains? Message-ID: <284871.77845.qm@web34306.mail.mud.yahoo.com> I am trying to add 3 domain name accounts:? ? domain1.com domain2.com domain3.com ? to FreeBSD 7.2-RELEASE sever?with a Static IP the domain names?are pointed to the server via godaddy. What do I need to do to add the domains to the BSD server? ? ? --- On Mon, 6/22/09, Glen Barber wrote: From: Glen Barber Subject: Re: Adding multiipul virtual domains? To: allnetgroup@yahoo.com Cc: stable@freebsd.org Date: Monday, June 22, 2009, 3:24 PM On Mon, Jun 22, 2009 at 6:23 PM, ALLnetgroup wrote: > For 3 domain names I just received. > Please don't just reply to me, because the rest of the list doesn't see your response. Your question is extremely vague.? What are you trying to do? -- Glen Barber From vanopen at gmail.com Mon Jun 22 23:38:11 2009 From: vanopen at gmail.com (Wu, Yue) Date: Mon Jun 22 23:38:18 2009 Subject: Use n instead of Fn for choosing the OS when booting? In-Reply-To: <20090622131311.GA39134@svzserv.kemerovo.su> References: <20090622123938.GA794@fbsd.hasee.cpu> <20090622131311.GA39134@svzserv.kemerovo.su> Message-ID: <20090622233800.GA779@fbsd.hasee.cpu> On Mon, Jun 22, 2009 at 09:13:11PM +0800, Eugene Grosbein wrote: > On Mon, Jun 22, 2009 at 08:39:38PM +0800, Wu, Yue wrote: > > > Freebsd uses Fn to choose Nth OS on the disk, I have installed FreeBSD on the > > second slice of disk, so I use F2 to choose it, but sometimes I hit F2 > > occasionally before the boot menu is up, and F2 is my notebook for entering > > the setup menu, so I go into BIOS setup menu, it's annoying me sometimes, so > > I think why not use number key(0~9) instead of F1~F12 for choosing OS? > > In fact, BootEasy does use both - F-keys and number keys, > just give it a try. It does the trick, thank you :) I think the screen can display number instead of Fn, and it saves one charactor and can be used for other maybe useful infos. Another question, if these are more then 12 OSes exist on disk, how to select the one that number larger than 12? :) -- Hi, Wu, Yue From dmagda at ee.ryerson.ca Mon Jun 22 23:40:40 2009 From: dmagda at ee.ryerson.ca (David Magda) Date: Mon Jun 22 23:40:47 2009 Subject: ZFS user library? In-Reply-To: <8A85A6B2-2122-4D8A-BF11-F2975B1A130F@sarenet.es> References: <3c1674c90906181021n54bd6fbei2a1a843033bc91c@mail.gmail.com> <1E4B9A40-F510-42E4-8A0B-26BA01A1679C@ee.ryerson.ca> <8A85A6B2-2122-4D8A-BF11-F2975B1A130F@sarenet.es> Message-ID: <208276CF-734E-4B82-B2DE-47BE65BA9F1D@ee.ryerson.ca> On Jun 22, 2009, at 04:00, Borja Marcos wrote: > I see... Not rocket science actually. Just the standard > functionality of zfs(8) without resorting to ugly execve and text > parsing, something more reliable to list snapshots, etc. > > Maybe it's a matter of waiting... At some point it probably will be stabilized, but it hasn't happened yet. From freebsd-nospam at yaxom.com Mon Jun 22 23:50:49 2009 From: freebsd-nospam at yaxom.com (Greg Black) Date: Mon Jun 22 23:50:59 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <284871.77845.qm@web34306.mail.mud.yahoo.com> References: <284871.77845.qm@web34306.mail.mud.yahoo.com> Message-ID: On 2009-06-22, ALLnetgroup wrote: > I am trying to add 3 domain name accounts:? > ? > domain1.com > domain2.com > domain3.com > ? > to FreeBSD 7.2-RELEASE sever?with a Static IP the domain names?are pointed to the server via godaddy. What do I need to do to add the domains to the BSD server? You need to do two things: (1) formulate a meaningful question; (2) ask your questions in a suitable forum for newbie questions. Please read the charters of the mailing lists and stop using this list for questions that don't belong here. From eculp at encontacto.net Tue Jun 23 01:28:08 2009 From: eculp at encontacto.net (eculp) Date: Tue Jun 23 01:28:17 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <284871.77845.qm@web34306.mail.mud.yahoo.com> References: <284871.77845.qm@web34306.mail.mud.yahoo.com> Message-ID: <20090622201803.351835q55iylznac@econet.encontacto.net> Quoting ALLnetgroup : > I am trying to add 3 domain name accounts:? > ? > domain1.com > domain2.com > domain3.com > ? > to FreeBSD 7.2-RELEASE sever?with a Static IP the domain names?are > pointed to the server via godaddy. What do I need to do to add the > domains to the BSD server? You really need to be more specific. To use the domains you will need at least: o. a functional DNS for each, be it on your freebsd box or not. o. Probably a mail server. Lot of options here most are in ports. o. A web server, probably apache or lighthttp that are both in ports. All of these can be handled by multiple programs, none of which are parts of the basic freebsd OS install except named, I suppose but that is if you are running your own dns, which I somehow doubt. Why don't you try reading the FreeBSD handbook that will answer most of what I mentioned. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html I would also suggest you read about the mailing lists on the http://www.freebsd.org web site to know which you should use and how to ask questions. Good luck, ed > --- On Mon, 6/22/09, Glen Barber wrote: > > > From: Glen Barber > Subject: Re: Adding multiipul virtual domains? > To: allnetgroup@yahoo.com > Cc: stable@freebsd.org > Date: Monday, June 22, 2009, 3:24 PM > > > On Mon, Jun 22, 2009 at 6:23 PM, ALLnetgroup wrote: >> For 3 domain names I just received. >> > > Please don't just reply to me, because the rest of the list doesn't > see your response. > > Your question is extremely vague.? What are you trying to do? > > > -- > Glen Barber > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From rick-freebsd2008 at kiwi-computer.com Tue Jun 23 01:45:40 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Tue Jun 23 01:45:48 2009 Subject: Use n instead of Fn for choosing the OS when booting? In-Reply-To: <20090622233800.GA779@fbsd.hasee.cpu> References: <20090622123938.GA794@fbsd.hasee.cpu> <20090622131311.GA39134@svzserv.kemerovo.su> <20090622233800.GA779@fbsd.hasee.cpu> Message-ID: <20090623011857.GA54747@keira.kiwi-computer.com> On Tue, Jun 23, 2009 at 07:38:00AM +0800, Wu, Yue wrote: > > Another question, if these are more then 12 OSes exist on disk, how to select > the one that number larger than 12? :) You can only have 4 primary partitions in an MBR. The boot0 gives choice #5 for the next disk. Thus there are only 5 choices, maximum. -- Rick C. Petty From hv at tuebingen.mpg.de Tue Jun 23 08:05:24 2009 From: hv at tuebingen.mpg.de (hv) Date: Tue Jun 23 08:05:31 2009 Subject: Use n instead of Fn for choosing the OS when booting? In-Reply-To: <20090623011857.GA54747@keira.kiwi-computer.com> References: <20090622123938.GA794@fbsd.hasee.cpu> <20090622131311.GA39134@svzserv.kemerovo.su> <20090622233800.GA779@fbsd.hasee.cpu> <20090623011857.GA54747@keira.kiwi-computer.com> Message-ID: <53C01C98-7C82-4E4F-9214-74AC0C662EA9@tuebingen.mpg.de> Am 23.06.2009 um 03:18 schrieb Rick C. Petty: > On Tue, Jun 23, 2009 at 07:38:00AM +0800, Wu, Yue wrote: >> >> Another question, if these are more then 12 OSes exist on disk, how >> to select >> the one that number larger than 12? :) > > You can only have 4 primary partitions in an MBR. The boot0 gives > choice > #5 for the next disk. Thus there are only 5 choices, maximum. Recently added (since 7.2): There are 6 possible choices. Probably the 6th only shows up, if the bios supports booting via PXE. Regards -- Henry Vogt (Fon: ++49-7071-601-511, Fax: -826) Campus Max-Planck-Institute, Spemannstr. 32-41, T?bingen, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: Signierter Teil der Nachricht Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090623/40562c67/PGP.pgp From mad at madpilot.net Tue Jun 23 10:18:38 2009 From: mad at madpilot.net (Guido Falsi) Date: Tue Jun 23 10:18:45 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <20090622201803.351835q55iylznac@econet.encontacto.net> References: <284871.77845.qm@web34306.mail.mud.yahoo.com> <20090622201803.351835q55iylznac@econet.encontacto.net> Message-ID: <20090623100610.GD84742@megatron.madpilot.net> On Mon, Jun 22, 2009 at 08:18:03PM -0500, eculp wrote: > You really need to be more specific. To use the domains you will need > at least: > > o. a functional DNS for each, be it on your freebsd box or not. > o. Probably a mail server. Lot of options here most are in ports. > o. A web server, probably apache or lighthttp that are both in ports. > > All of these can be handled by multiple programs, none of which are > parts of the basic freebsd OS install except named, I suppose but that > is if you are running your own dns, which I somehow doubt. Well the base system does include a mail server. -- Guido Falsi From pluknet at gmail.com Tue Jun 23 12:24:05 2009 From: pluknet at gmail.com (pluknet) Date: Tue Jun 23 12:24:12 2009 Subject: lock up in 6.2 (procs massively stuck in Giant) In-Reply-To: <200905131248.08465.jhb@freebsd.org> References: <200905131015.27431.jhb@freebsd.org> <200905131248.08465.jhb@freebsd.org> Message-ID: 2009/5/13 John Baldwin : > On Wednesday 13 May 2009 11:41:22 am pluknet wrote: >> 2009/5/13 John Baldwin : >> > On Wednesday 13 May 2009 2:40:33 am pluknet wrote: >> >> 2009/5/13 pluknet : >> >> > 2009/5/13 John Baldwin : >> >> >> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote: >> >> >>> Hi. >> >> >>> >> >> >>> From just another box (not from the first two mentioned earlier) >> >> >>> with a similar locking issue. If it would make sense, since there are >> >> >>> possibly a bit different conditions. >> >> >>> clock proc here is on swi4, I hope it's a non-important difference. >> >> >>> >> >> >>> ? ?18 ? ? 0 ? ? 0 ? ? 0 ?LL ? ? *Giant ? ?0xd0a6b140 [swi4: clock > sio] >> >> >>> db> bt 18 >> >> >> >> >> >> Ok, this is a known issue in 6.x. ?It is fixed in 6.4. >> >> >> >> >> >> >> Looking at the face of kern_timeout.c I suspect that was fixed in > r181012. >> > >> > No, this particular issue is fixed by a change to sched_4bsd.c in r179975. >> > >> >> Gah.. We constrained to use ule scheduler on 6.x (yes, I know that >> "it's known to be broken (c)"), since we have had a very bad interactivity >> on 4bsd on our workload. Ok, that's just another reason to move to 7.x. > > Hmmm I would have thought ULE wouldn't have suffered from this bug. ?The > problem on 4BSD was if softclock ever blocked on Giant and the thread that > held Giant was on a run queue and pinned to a specific CPU but that another > userland thread was running on that CPU already, the userland thread would > never yield the CPU so long as it kept busy since the round robin timeout > would never run. > > -- > John Baldwin > That's another sort of lockup on 6.2 we experience often. May that be connected to ULE on 6.x? I regret if this info is not enough. db> ps pid ppid pgrp uid state wmesg wchan cmd 74606 74602 68315 0 R stat 74605 74601 68315 0 S piperd 0xcd7b0198 head 74603 74601 68315 0 S piperd 0xc8ca2198 sort 74602 74601 68315 0 S wait 0xcaed6000 find 74601 68319 68315 0 S wait 0xd0f5e860 sh 74588 7495 7495 13581 S lockf 0xd1919dc0 httpd 74587 7495 7495 13581 S lockf 0xce42b400 httpd 74586 8016 8016 7336 R httpd 74585 8016 8016 7336 R httpd 74584 9498 9498 26316 R httpd 74341 3399 8150 13289 R CPU 7 perl5.8.8 74020 7495 7495 13581 S lockf 0xccf31180 httpd 74019 8247 8247 26256 R httpd 74018 8016 8016 7336 R CPU 4 httpd 72732 9190 9190 26291 RL CPU 1 httpd 72731 9190 9190 26291 S accept 0xcd31572e httpd 72729 8693 8693 26404 R httpd 72727 9190 9190 26291 S accept 0xcd31572e httpd 72726 9396 9396 26262 R httpd 72088 7495 7495 13581 S kqread 0xcb2f9400 httpd 72087 9190 9190 26291 S accept 0xcd31572e httpd 72085 9190 9190 26291 S accept 0xcd31572e httpd 72084 8162 8162 18538 R httpd 71402 7495 7495 13581 S lockf 0xccfab3c0 httpd 71401 8162 8162 18538 R httpd 71400 9190 9190 26291 S accept 0xcd31572e httpd 71399 8716 8716 26278 R CPU 3 httpd 70063 7574 7574 11303 S lockf 0xccf312c0 httpd 69417 8371 8371 25968 R httpd 69416 9030 9030 39658 R httpd 68319 68318 68315 0 S piperd 0xd1b9f198 sh 68318 68315 68315 0 S wait 0xc82f7648 lockf 68315 68313 68315 0 Ss wait 0xca914430 sh 68313 34501 34501 0 S piperd 0xcfbef000 cron 68310 8016 8016 7336 R httpd 68309 64318 64318 14620 R httpd 68308 9111 9111 26280 S lockf 0xca51cc00 httpd 68302 8595 8595 26129 RL httpd 68301 9190 9190 26291 S accept 0xcd31572e httpd 68300 8483 8483 26049 R httpd 68296 8747 8747 33525 R httpd 68287 8952 8952 26340 R httpd 68282 9110 9110 26102 R httpd 68280 9110 9110 26102 R httpd 68272 8339 8339 17137 S accept 0xcc5159f6 httpd 68271 8595 8595 26129 R httpd 68269 9470 9470 26006 R httpd 68268 9030 9030 39658 S sbwait 0xc89d0da4 httpd 68251 36391 36391 38054 R httpd 68249 7527 7527 16760 R httpd 68247 9030 9030 39658 R httpd 68245 8901 8901 26031 S accept 0xcd3159f6 httpd 68239 8928 8928 26128 R httpd 68238 8928 8928 26128 S lockf 0xd1659c40 httpd 68214 7619 7619 6478 S accept 0xcb25219e httpd 68210 8675 8675 26171 S accept 0xc8ca719e httpd 68205 8388 8388 27687 R httpd 68199 8339 8339 17137 R httpd 68197 9169 9169 26030 S accept 0xcaa7a03a httpd [...] db> sh allpcpu Current CPU: 1 cpuid = 0 curthread = 0xc7cfae10: pid 19 "swi4: clock sio" curpcb = 0xe6895d90 fpcurthread = none idlethread = 0xc7cfaaf0: pid 17 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid = 1 curthread = 0xcc20c000: pid 72732 "httpd" curpcb = 0xefcaad90 fpcurthread = none idlethread = 0xc7cfa000: pid 16 "idle: cpu1" APIC ID = 1 currentldt = 0x50 cpuid = 2 curthread = 0xc8413e10: pid 35417 "proftpd" curpcb = 0xf0e55d90 fpcurthread = none idlethread = 0xc7cf9e10: pid 15 "idle: cpu2" APIC ID = 2 currentldt = 0x50 cpuid = 3 curthread = 0xcfd37320: pid 71399 "httpd" curpcb = 0xf0786d90 fpcurthread = none idlethread = 0xc7cf9c80: pid 14 "idle: cpu3" APIC ID = 3 currentldt = 0x50 cpuid = 4 curthread = 0xd0f68320: pid 74018 "httpd" curpcb = 0xf0a79d90 fpcurthread = none idlethread = 0xc7cf9af0: pid 13 "idle: cpu4" APIC ID = 4 currentldt = 0x50 cpuid = 5 curthread = 0xcb92a640: pid 56782 "httpd" curpcb = 0xef96bd90 fpcurthread = none idlethread = 0xc7cf9960: pid 12 "idle: cpu5" APIC ID = 5 currentldt = 0x50 cpuid = 6 curthread = 0xd1e98640: pid 67921 "httpd" curpcb = 0xf1545d90 fpcurthread = none idlethread = 0xc7cf97d0: pid 11 "idle: cpu6" APIC ID = 6 currentldt = 0x50 cpuid = 7 curthread = 0xca523e10: pid 74341 "perl5.8.8" curpcb = 0xeee48d90 fpcurthread = none idlethread = 0xc7cf9640: pid 10 "idle: cpu7" APIC ID = 7 currentldt = 0x50 db> bt 74606 Tracing pid 74606 tid 100065 td 0xc8138190 sched_switch(c8138190,0,2) at sched_switch+0x143 mi_switch(2,0) at mi_switch+0x1ba critical_exit(c0a06c60,ee77e9d4,c0899240,0,28060008,...) at critical_exit+0x9d lapic_handle_timer(0) at lapic_handle_timer+0xc9 Xtimerint(c0a06c60,c8138190,0,0,0) at Xtimerint+0x30 namei(ee77ebcc) at namei+0x1ec vn_open_cred(ee77ebcc,ee77eccc,1a4,d06a0b00,5,...) at vn_open_cred+0x2ad vn_open(ee77ebcc,ee77eccc,1a4,5) at vn_open+0x1e kern_open(c8138190,2806ac48,0,1,1b6,...) at kern_open+0xb6 open(c8138190,ee77ed04) at open+0x1a syscall(3b,3b,3b,4,28070c80,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x280555af, esp = 0xbfbfebfc, ebp = 0xbfbfec28 --- db> bt 74341 Tracing pid 74341 tid 101681 td 0xca523e10 sched_switch(7,7,1,eee48a0c,c08a55d9,...) at sched_switch+0x143 MAXCPU(e5895590,62e85356,e8000110,ffffa3d5,ffb988e8,...) at 0xf7 *** error reading from address f8658d94 *** db> bt 67921 Tracing pid 67921 tid 102585 td 0xd1e98640 sched_switch(d1e98640,c7cfa960,6) at sched_switch+0x143 mi_switch(6,c7cfa960,c7cfaab8,c0a0b460,f154592c,...) at mi_switch+0x1ba maybe_preempt(c7cfa960) at maybe_preempt+0xc4 sched_add(c7cfa960,4,d1e98640,c7cfa960,f1545950,...) at sched_add+0x258 setrunqueue(f1545968,c066d0fc,0,c7cef69c,0,...) at setrunqueue+0x63 _end() at 0xd1e98640 db> show lockchain 67921 thread 102585 (pid 67921, httpd) running on CPU 6 db> show lock Giant class: sleep mutex name: Giant flags: {DEF, RECURSE} state: {OWNED, CONTESTED} owner: 0xd0f68320 (tid 102209, pid 74018, "httpd") db> bt 74018 Tracing pid 74018 tid 102209 td 0xd0f68320 sched_switch(c0a0a0b0,cd635c48,c9018f68,c0a0baf0,1,...) at sched_switch+0x143 MAXCPU(2004,cd635af0,0,16,1,...) at 0x7 _end() at 0xcb62b608 db> bt 71399 Tracing pid 71399 tid 101992 td 0xcfd37320 sched_switch(5,5,1,f0786a0c,c08a55d9,...) at sched_switch+0x143 MAXCPU(e5895590,62e85356,e8000110,ffffa3d5,ffb988e8,...) at 0xf7 *** error reading from address f8658d94 *** db> bt 35417 Tracing pid 35417 tid 102675 td 0xc8413e10 sched_switch(7,7,1,f0e55ad8,c08a55d9,...) at sched_switch+0x143 MAXCPU(e5895590,62e85356,e8000110,ffffa3d5,ffb988e8,...) at 0xf7 *** error reading from address f8658d94 *** db> show proc 74018 Process 74018 (httpd) at 0xd0f73218: state: NORMAL uid: 7336 gids: 999, 999, 7336 parent: pid 8016 at 0xcaf69648 ABI: FreeBSD ELF32 arguments: /home/xxx/etc/apache/bin/httpd threads: 1 102209 Run CPU 4 httpd db> show lockchain 74018 thread 102209 (pid 74018, httpd) running on CPU 4 db> show turnstile db> show lockedbufs buf at 0xdbda0400 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8160d80), b_data = 0xdcdb1000, b_blkno = 920752960 b_npages = 4, pages(OBJ, IDX, PA): (0xc8163084, 0x6dc3268, 0x60fd4000),(0xc8163084, 0x6dc3269, 0x58495000),(0xc8163084, 0x6dc326a, 0x1b8b6000),(0xc8163084, 0x6dc326b, 0x74f97000) db> show lockedvnods Locked vnodes db> show sleepq db> show lockmgr db> show sleepchain thread 101368 (pid 72732, httpd) running on CPU 1 db> bt 72732 Tracing pid 72732 tid 101368 td 0xcc20c000 kdb_enter(c094016e) at kdb_enter+0x2b siointr1(c7ee6c00) at siointr1+0xce siointr(c7ee6c00) at siointr+0x5e intr_execute_handlers(c7cef4c8,efcaab98,4,efcaabe8,c0899013,...) at intr_execute_handlers+0xe1 lapic_handle_intr(37) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc067a3be, esp = 0xefcaabdc, ebp = 0xefcaabe8 --- _mtx_lock_sleep(c0a06c60,cc20c000,0,0,0) at _mtx_lock_sleep+0xb6 vm_fault(ca2a1818,28747000,1,0) at vm_fault+0x1a5 trap_pfault(efcaad38,1,28747584,28747584,0,...) at trap_pfault+0x123 trap(280b003b,bfbf003b,bfbf003b,280b79c8,bfbfed84,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x28747584, esp = 0xbfbfeaec, ebp = 0xbfbfeb08 --- db> bt Tracing pid 72732 tid 101368 td 0xcc20c000 kdb_enter(c094016e) at kdb_enter+0x2b siointr1(c7ee6c00) at siointr1+0xce siointr(c7ee6c00) at siointr+0x5e intr_execute_handlers(c7cef4c8,efcaab98,4,efcaabe8,c0899013,...) at intr_execute_handlers+0xe1 lapic_handle_intr(37) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc067a3be, esp = 0xefcaabdc, ebp = 0xefcaabe8 --- _mtx_lock_sleep(c0a06c60,cc20c000,0,0,0) at _mtx_lock_sleep+0xb6 vm_fault(ca2a1818,28747000,1,0) at vm_fault+0x1a5 trap_pfault(efcaad38,1,28747584,28747584,0,...) at trap_pfault+0x123 trap(280b003b,bfbf003b,bfbf003b,280b79c8,bfbfed84,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x28747584, esp = 0xbfbfeaec, ebp = 0xbfbfeb08 --- -- wbr, pluknet From jeffrey at goldmark.org Tue Jun 23 14:01:10 2009 From: jeffrey at goldmark.org (Jeffrey Goldberg) Date: Tue Jun 23 14:01:22 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <849040.64121.qm@web34307.mail.mud.yahoo.com> References: <849040.64121.qm@web34307.mail.mud.yahoo.com> Message-ID: On Jun 22, 2009, at 4:46 PM, ALLnetgroup wrote: > I have 3 virtual domains I need to add to FreeBSD 7.2-RELEASE server > using Terminal or Webmin preferably Terminal. If you are talking about virtual web domains, then this will be configured in the Apache configuration files. Assuming you have apache22 installed from ports, then look in /usr/local/etc/apache22/extra/http-vhosts.com That will point you to some apache documentation http://httpd.apache.org/docs/2.2/vhosts/ which you should review. As others have said, you need to clarify your question. Virtual domains with respect to what? I'm just guessing that you are talking about webserver vhosts and that you are running apache. If you are talking about virtual domains for email, then you will need to let us know whether you are running the FreeBSD default sendmail installation or some other mail server system. -j -- Jeffrey Goldberg http://www.goldmark.org/jeff/ From allnetgroup at yahoo.com Tue Jun 23 14:33:38 2009 From: allnetgroup at yahoo.com (ALLnetgroup) Date: Tue Jun 23 14:33:45 2009 Subject: Adding multiipul virtual domains? Message-ID: <615319.72378.qm@web34307.mail.mud.yahoo.com> The server has 1 domain? name already setup along with: ? sendmail Webmin Apache Web Server MySQL Apache Tomcat Squid Proxy SOCKS5 PERL Mod PERL PHP OpenSSH phpBB RoundCube WebMail ? When I add a new virtual host I would like the host to have it's own directory, website?and the services above. ? ? Thank You ? --- On Tue, 6/23/09, Jeffrey Goldberg wrote: From: Jeffrey Goldberg Subject: Re: Adding multiple virtual domains? To: allnetgroup@yahoo.com Cc: stable@freebsd.org Date: Tuesday, June 23, 2009, 6:41 AM On Jun 22, 2009, at 4:46 PM, ALLnetgroup wrote: > I have 3 virtual domains I need to add to FreeBSD 7.2-RELEASE server using Terminal or Webmin preferably Terminal. If you are talking about virtual web domains, then this will be configured in the Apache configuration files.? Assuming you have apache22 installed from ports, then look in /usr/local/etc/apache22/extra/http-vhosts.com That will point you to some apache documentation http://httpd.apache.org/docs/2.2/vhosts/ which you should review. As others have said, you need to clarify your question.? Virtual domains with respect to what?? I'm just guessing that you are talking about webserver vhosts and that you are running apache. If you are talking about virtual domains for email, then you will need to let us know whether you are running the FreeBSD default sendmail installation or some other mail server system. -j --Jeffrey Goldberg? ? ? ? ? ? ? ? ? ? ? ? http://www.goldmark.org/jeff/ From eculp at encontacto.net Tue Jun 23 15:04:33 2009 From: eculp at encontacto.net (eculp) Date: Tue Jun 23 15:04:40 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <615319.72378.qm@web34307.mail.mud.yahoo.com> References: <615319.72378.qm@web34307.mail.mud.yahoo.com> Message-ID: <20090623100429.195710th19ude9z4@econet.encontacto.net> Quoting ALLnetgroup : > The server has 1 domain? name already setup along with: > ? > sendmail > Webmin > Apache Web Server > MySQL > Apache Tomcat > Squid Proxy > SOCKS5 > PERL > Mod PERL > PHP > OpenSSH > phpBB > RoundCube WebMail > ? > When I add a new virtual host I would like the host to have it's own > directory, website?and the services above. Hmmm... the link Jeffery sent you solves the apache vhosts and you will need to read the manuals for the rest to get your configuration the way you want it and ask specific questions on the questions mailing list, possibly. ed > ? > ? > Thank You > ? > --- On Tue, 6/23/09, Jeffrey Goldberg wrote: > > > From: Jeffrey Goldberg > Subject: Re: Adding multiple virtual domains? > To: allnetgroup@yahoo.com > Cc: stable@freebsd.org > Date: Tuesday, June 23, 2009, 6:41 AM > > > On Jun 22, 2009, at 4:46 PM, ALLnetgroup wrote: > >> I have 3 virtual domains I need to add to FreeBSD 7.2-RELEASE >> server using Terminal or Webmin preferably Terminal. > > If you are talking about virtual web domains, then this will be > configured in the Apache configuration files.? Assuming you have > apache22 installed from ports, then look in > > /usr/local/etc/apache22/extra/http-vhosts.com > > That will point you to some apache documentation > > http://httpd.apache.org/docs/2.2/vhosts/ > > which you should review. > > As others have said, you need to clarify your question.? Virtual > domains with respect to what?? I'm just guessing that you are > talking about webserver vhosts and that you are running apache. > > If you are talking about virtual domains for email, then you will > need to let us know whether you are running the FreeBSD default > sendmail installation or some other mail server system. > > -j > > > --Jeffrey Goldberg? ? ? ? ? ? ? ? ? ? ? ? http://www.goldmark.org/jeff/ > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From vanopen at gmail.com Tue Jun 23 15:11:17 2009 From: vanopen at gmail.com (Wu, Yue) Date: Tue Jun 23 15:11:24 2009 Subject: Use n instead of Fn for choosing the OS when booting? In-Reply-To: <53C01C98-7C82-4E4F-9214-74AC0C662EA9@tuebingen.mpg.de> References: <20090622123938.GA794@fbsd.hasee.cpu> <20090622131311.GA39134@svzserv.kemerovo.su> <20090622233800.GA779@fbsd.hasee.cpu> <20090623011857.GA54747@keira.kiwi-computer.com> <53C01C98-7C82-4E4F-9214-74AC0C662EA9@tuebingen.mpg.de> Message-ID: <20090623151105.GA1358@fbsd.hasee.cpu> On Tue, Jun 23, 2009 at 09:35:49AM +0200, hv wrote: > > Am 23.06.2009 um 03:18 schrieb Rick C. Petty: > > > On Tue, Jun 23, 2009 at 07:38:00AM +0800, Wu, Yue wrote: > >> > >> Another question, if these are more then 12 OSes exist on disk, how > >> to select > >> the one that number larger than 12? :) > > > > You can only have 4 primary partitions in an MBR. The boot0 gives > > choice > > #5 for the next disk. Thus there are only 5 choices, maximum. > > > Recently added (since 7.2): There are 6 possible choices. > Probably the 6th only shows up, if the bios supports booting via PXE. Thanks for the infos :) -- Hi, Wu, Yue From mg-fbsd3 at grant.org Tue Jun 23 19:42:39 2009 From: mg-fbsd3 at grant.org (Michael Grant) Date: Tue Jun 23 19:42:46 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <20090623100429.195710th19ude9z4@econet.encontacto.net> References: <615319.72378.qm@web34307.mail.mud.yahoo.com> <20090623100429.195710th19ude9z4@econet.encontacto.net> Message-ID: <62b856460906231221p10ae8d72gbe8cae84063babc5@mail.gmail.com> On Tue, Jun 23, 2009 at 17:04, eculp wrote: > Quoting ALLnetgroup : > >> The server has 1 domain? name already setup along with: >> >> sendmail >> Webmin >> Apache Web Server >> MySQL >> Apache Tomcat >> Squid Proxy >> SOCKS5 >> PERL >> Mod PERL >> PHP >> OpenSSH >> phpBB >> RoundCube WebMail >> >> When I add a new virtual host I would like the host to have it's own >> directory, website?and the services above. There is nothing that I know of that will automatically "add a new virtual domain" to a machine in all of these systems. I have my own home brew perl scripts which do such things but they are not usable outside my own environment. Many other people I have talked to have done the same thing or just configured each of these individually. If you are not technically savvy enough to write your own configuration management system or to modify the configuration files individually, you might consider instead of having your own machine to use a web hosting company which automatically installs and configures this stuff for you via a control panel. Incidentally this is not the first time I have seen a need for some larger "meta" confutation system for unix/linux in general. It's absolutely true that adding a domain to a system is often a multi-step process and it need not be. Like adding a user in the old days when you first edited the passwd file, the group file, made the home directory and copied over some dot files there, now it's all automated in the adduser command. A user might have several domains, mail, one or more web sites, etc. All of this gets configured into lots of different files. Then think what happens when you get rid of a user. There really aught to be some easier way which is why I ended up writing my own scripts. Michael Grant From danson at rackspace.com Tue Jun 23 19:59:57 2009 From: danson at rackspace.com (Daniel Anson) Date: Tue Jun 23 20:00:05 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <62b856460906231221p10ae8d72gbe8cae84063babc5@mail.gmail.com> References: <615319.72378.qm@web34307.mail.mud.yahoo.com><20090623100429.195710th19ude9z4@econet.encontacto.net> <62b856460906231221p10ae8d72gbe8cae84063babc5@mail.gmail.com> Message-ID: <14477_1245786512_n5NJmUY5015136_96AF20FDF4301D419B33CCE8E3A0132B0D2EAD7B@SAT4MX07.RACKSPACE.CORP> Try running plesk. --D -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Michael Grant Sent: Tuesday, June 23, 2009 2:21 PM To: allnetgroup@yahoo.com Cc: stable@freebsd.org Subject: Re: Adding multiipul virtual domains? On Tue, Jun 23, 2009 at 17:04, eculp wrote: > Quoting ALLnetgroup : > >> The server has 1 domain? name already setup along with: >> >> sendmail >> Webmin >> Apache Web Server >> MySQL >> Apache Tomcat >> Squid Proxy >> SOCKS5 >> PERL >> Mod PERL >> PHP >> OpenSSH >> phpBB >> RoundCube WebMail >> >> When I add a new virtual host I would like the host to have it's own >> directory, website?and the services above. There is nothing that I know of that will automatically "add a new virtual domain" to a machine in all of these systems. I have my own home brew perl scripts which do such things but they are not usable outside my own environment. Many other people I have talked to have done the same thing or just configured each of these individually. If you are not technically savvy enough to write your own configuration management system or to modify the configuration files individually, you might consider instead of having your own machine to use a web hosting company which automatically installs and configures this stuff for you via a control panel. Incidentally this is not the first time I have seen a need for some larger "meta" confutation system for unix/linux in general. It's absolutely true that adding a domain to a system is often a multi-step process and it need not be. Like adding a user in the old days when you first edited the passwd file, the group file, made the home directory and copied over some dot files there, now it's all automated in the adduser command. A user might have several domains, mail, one or more web sites, etc. All of this gets configured into lots of different files. Then think what happens when you get rid of a user. There really aught to be some easier way which is why I ended up writing my own scripts. Michael Grant _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@rackspace.com, and delete the original message. Your cooperation is appreciated. From ler at lerctr.org Tue Jun 23 20:25:28 2009 From: ler at lerctr.org (Larry Rosenman) Date: Tue Jun 23 20:25:36 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <14477_1245786512_n5NJmUY5015136_96AF20FDF4301D419B33CCE8E3A0132B0D2EAD7B@SAT4MX07.RACKSPACE.CORP> References: <615319.72378.qm@web34307.mail.mud.yahoo.com><20090623100429.195710th19ude9z4@econet.encontacto.net> <62b856460906231221p10ae8d72gbe8cae84063babc5@mail.gmail.com> <14477_1245786512_n5NJmUY5015136_96AF20FDF4301D419B33CCE8E3A0132B0D2EAD7B@SAT4MX07.RACKSPACE.CORP> Message-ID: <01a001c9f43d$e41c92b0$ac55b810$@org> I wouldn't wish plesk on my worst enemy. Qmail, and non-standard stuff all the way around. I have clients that use it, and I cringe when I have to debug/change something. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Daniel Anson Sent: Tuesday, June 23, 2009 2:47 PM To: Michael Grant; allnetgroup@yahoo.com Cc: stable@freebsd.org Subject: RE: Adding multiipul virtual domains? Try running plesk. --D -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Michael Grant Sent: Tuesday, June 23, 2009 2:21 PM To: allnetgroup@yahoo.com Cc: stable@freebsd.org Subject: Re: Adding multiipul virtual domains? On Tue, Jun 23, 2009 at 17:04, eculp wrote: > Quoting ALLnetgroup : > >> The server has 1 domain? name already setup along with: >> >> sendmail >> Webmin >> Apache Web Server >> MySQL >> Apache Tomcat >> Squid Proxy >> SOCKS5 >> PERL >> Mod PERL >> PHP >> OpenSSH >> phpBB >> RoundCube WebMail >> >> When I add a new virtual host I would like the host to have it's own >> directory, website?and the services above. There is nothing that I know of that will automatically "add a new virtual domain" to a machine in all of these systems. I have my own home brew perl scripts which do such things but they are not usable outside my own environment. Many other people I have talked to have done the same thing or just configured each of these individually. If you are not technically savvy enough to write your own configuration management system or to modify the configuration files individually, you might consider instead of having your own machine to use a web hosting company which automatically installs and configures this stuff for you via a control panel. Incidentally this is not the first time I have seen a need for some larger "meta" confutation system for unix/linux in general. It's absolutely true that adding a domain to a system is often a multi-step process and it need not be. Like adding a user in the old days when you first edited the passwd file, the group file, made the home directory and copied over some dot files there, now it's all automated in the adduser command. A user might have several domains, mail, one or more web sites, etc. All of this gets configured into lots of different files. Then think what happens when you get rid of a user. There really aught to be some easier way which is why I ended up writing my own scripts. Michael Grant _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@rackspace.com, and delete the original message. Your cooperation is appreciated. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From mikael at t-online.hu Wed Jun 24 09:31:32 2009 From: mikael at t-online.hu (Mikael Bak) Date: Wed Jun 24 09:31:42 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <615319.72378.qm@web34307.mail.mud.yahoo.com> References: <615319.72378.qm@web34307.mail.mud.yahoo.com> Message-ID: <4A41E8EB.4080103@t-online.hu> ALLnetgroup wrote: > The server has 1 domain name already setup along with: > > sendmail > Webmin > Apache Web Server > MySQL > Apache Tomcat > Squid Proxy > SOCKS5 > PERL > Mod PERL > PHP > OpenSSH > phpBB > RoundCube WebMail > > When I add a new virtual host I would like the host to have it's own directory, website and the services above. > Hi, If Webmin is correctly set up, then I think you should be able to add you domains there. Hopefully it'll make configuration changes for sendmail and apache. HTH, Mikael From cmdlnkid at gmail.com Wed Jun 24 09:43:27 2009 From: cmdlnkid at gmail.com (CmdLnKid) Date: Wed Jun 24 09:43:36 2009 Subject: Adding multiipul virtual domains? In-Reply-To: <62b856460906231221p10ae8d72gbe8cae84063babc5@mail.gmail.com> References: <615319.72378.qm@web34307.mail.mud.yahoo.com> <20090623100429.195710th19ude9z4@econet.encontacto.net> <62b856460906231221p10ae8d72gbe8cae84063babc5@mail.gmail.com> Message-ID: On Tue, 23 Jun 2009 15:21 -0000, mg-fbsd3 wrote: > On Tue, Jun 23, 2009 at 17:04, eculp wrote: >> Quoting ALLnetgroup : >> >>> The server has 1 domain? name already setup along with: >>> >>> sendmail >>> Webmin >>> Apache Web Server >>> MySQL >>> Apache Tomcat >>> Squid Proxy >>> SOCKS5 >>> PERL >>> Mod PERL >>> PHP >>> OpenSSH >>> phpBB >>> RoundCube WebMail >>> >>> When I add a new virtual host I would like the host to have it's own >>> directory, website?and the services above. > > There is nothing that I know of that will automatically "add a new > virtual domain" to a machine in all of these systems. I have my own > home brew perl scripts which do such things but they are not usable > outside my own environment. Many other people I have talked to have > done the same thing or just configured each of these individually. > > If you are not technically savvy enough to write your own > configuration management system or to modify the configuration files > individually, you might consider instead of having your own machine to > use a web hosting company which automatically installs and configures > this stuff for you via a control panel. > > Incidentally this is not the first time I have seen a need for some > larger "meta" confutation system for unix/linux in general. It's > absolutely true that adding a domain to a system is often a multi-step > process and it need not be. Like adding a user in the old days when > you first edited the passwd file, the group file, made the home > directory and copied over some dot files there, now it's all automated > in the adduser command. > > A user might have several domains, mail, one or more web sites, etc. > All of this gets configured into lots of different files. Then think > what happens when you get rid of a user. There really aught to be > some easier way which is why I ended up writing my own scripts. > > Michael Grant Might I suggest .... http://promote.pairlite.com/direct.pl?pl893 ;) < A li