Re: (Possible fix for sbp(4)) Re: Comment out sbp driver from GENERIC
Dnia 18-10-2011 o 14:12:56 Alberto Villa avi...@freebsd.org napisał(a): On Tue, Oct 18, 2011 at 1:48 PM, Wojciech A. Koszek wkos...@freebsd.czest.pl wrote: Commenting a driver out is almost always a bad idea and should be done as a last step. Well, few weeks prior to -RELEASE can be considered a last step. :) If you are impacted by sbp(4) hangs please follow this thread: http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081411.html And please let me know if a fix explained in this thread works for you. Thank you, will test it in few days. Any updates? -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 8 - bug in rename(2)
After upgrade from old RELENG_7 to fresh RELENG_8 I've met with error in log rotation script. After some digging I'v found, that rename(2) syscall sometime don't work properly. I can't reproduce problem with simple test case, but in production this problem appeared several time per day. After rename(2) sometimes old name still exists. stat for old and new names: 101 12153947 -rw-r--r-- 1 owner data 54507160 164374900 Oct 27 13:58:06 2011 Oct 27 13:58:06 2011 Oct 27 13:58:06 2011 Oct 27 13:56:05 2011 16384 321248 0 /usr/local/run/nginx/access_log 101 12153947 -rw-r--r-- 1 owner data 54507160 164377726 Oct 27 13:58:06 2011 Oct 27 13:58:06 2011 Oct 27 13:58:06 2011 Oct 27 13:56:05 2011 16384 321248 0 /usr/local/run/nginx/access_log.20111027T135806 2 files share same inode, but number of links is 1 2-nd rename for this file fail: mv: rename /usr/local/run/nginx/access_log to /usr/local/run/nginx/access_log.tmp: No such file or directory vfs.lookup_shared=0 don't affect this problem, It seems to be, that problem is related to namei (vfs) cache - old entry sometimes is not removed. Renamed file is open for write by nginx, but I don't know how this can affect namei. -- Anton Yuzhaninov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
DTrace Issues
Hey FreeBSD Stable,
I'm having issues printing out the curpsinfo-pr_psargs. Has anyone
had any success printing out the arguments passed to a program? Below
is the log of what happens when I run my script the source for my
script.
[root@fbsd-sec ~/dtrace/security]# ./log_exec.d 80
dtrace: buffer size lowered to 2m
1319724849:80:sh:sh
1319724849:80:ls:ls
^C
[root@fbsd-sec ~/dtrace/security]# cat log_exec.d
#!/usr/sbin/dtrace -s
#pragma D option quiet
proc:::exec-success
/uid == $1/
{
printf(%d:%d:%s:, walltimestamp, uid, execname);
trace(curpsinfo-pr_psargs);
printf(\n);
}
Thanks,
Shawn
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
devfs and unionfs oddity
On a build server, I have a union mount of a FreeBSD o/s build from a point-in-time under a build directory, and then I have devfs mounted on dev in the build directory as well so I can do a chroot install of packages for particular target o/s versions. mount shows this: below:/usr/app8xbuild/os-image on /usr/autobuild/images/product-image (unionfs, local) devfs on /usr/autobuild/images/product-image/dev (devfs, local, multilabel) and the system does a chroot to /usr/autobuild/images/product-image/ while installing the ports for the product. It seems impossible, but at times, after unmounting /usr/autobuild/images/product-image/dev and /usr/autobuild/images/product-image, a regular file /usr/autobuild/images/product-image/dev/null will be left as a result of redirecting some output to /dev/null during the port installs. Could there be some odd interaction of devfs and unions that allows this to happen? Guy This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
mfi timeouts
Hi, I've recently installed a new NAS at work which uses a rebranded LSI megaraid sas [root@banshee ~]# mfiutil show adapter mfi0 Adapter: Product Name: Supermicro SMC2108 Serial Number: Firmware: 12.12.0-0047 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8k Maximum Stripe: 1M I'm running 8-STABLE as of 2011-10-23 (for zfs v28 as is got 26 3Tb drives) I'm seeing a lot of messages like mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 60 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 90 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 120 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 150 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 180 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 210 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 240 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 271 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 301 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 331 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 361 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 391 SECONDS mfi0: COMMAND 0xff8000b21b08 TIMEOUT AFTER 55 SECONDS mfi0: COMMAND 0xff8000b21b08 TIMEOUT AFTER 85 SECONDS At which time I'm seeing IO stall on the array connected to the mfi adapter, this can continue for 20 minutes or so resuming randomly (or so it seems although a little more on this later on) From pciconf -lv mfi0@pci0:5:0:0:class=0x010400 card=0x070015d9 chip=0x00791000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = RAID From dmesg mfi0: LSI MegaSAS Gen2 port 0xe000-0xe0ff mem 0xfbd9c000-0xfbd9,0xfbdc-0xfbdf irq 32 at device 0.0 on pci5 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 12330 (372962922s/0x0020/info) - Shutdown command received from host mfi0: 12331 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0079/1000/0700/15d9) mfi0: 12332 (boot + 4s/0x0020/info) - Firmware version 2.120.53-1235 mfi0: 12333 (boot + 7s/0x0008/info) - Battery Present mfi0: 12334 (boot + 7s/0x0020/info) - Package version 12.12.0-0047 mfi0: 12335 (boot + 7s/0x0020/info) - Board Revision I have found this thread from a bit of googleing but it doesnt end too well. http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063821.html Was this ever taken further? One thing I have noticed is that the stall (and timeout messages) seem to go away if I query the card using mfiutil, I currently have a cron doing this every 2 minutes to see if this has been coincidence or not. Any suggestions welcome and i'm happy to provide more info if i can but I dont have a duplicate to do too much debugging on, I'm happy to try patches though. Is this worth filing a PR? Vince ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi timeouts
On Thu, Oct 27, 2011 at 11:52:51PM +0100, Vincent Hoffman wrote: I've recently installed a new NAS at work which uses a rebranded LSI megaraid sas [root@banshee ~]# mfiutil show adapter mfi0 Adapter: Product Name: Supermicro SMC2108 Serial Number: Firmware: 12.12.0-0047 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8k Maximum Stripe: 1M I'm running 8-STABLE as of 2011-10-23 (for zfs v28 as is got 26 3Tb drives) I'm seeing a lot of messages like mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 60 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 90 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 120 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 150 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 180 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 210 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 240 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 271 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 301 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 331 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 361 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 391 SECONDS mfi0: COMMAND 0xff8000b21b08 TIMEOUT AFTER 55 SECONDS mfi0: COMMAND 0xff8000b21b08 TIMEOUT AFTER 85 SECONDS At which time I'm seeing IO stall on the array connected to the mfi adapter, this can continue for 20 minutes or so resuming randomly (or so it seems although a little more on this later on) From pciconf -lv mfi0@pci0:5:0:0:class=0x010400 card=0x070015d9 chip=0x00791000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = RAID From dmesg mfi0: LSI MegaSAS Gen2 port 0xe000-0xe0ff mem 0xfbd9c000-0xfbd9,0xfbdc-0xfbdf irq 32 at device 0.0 on pci5 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 12330 (372962922s/0x0020/info) - Shutdown command received from host mfi0: 12331 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0079/1000/0700/15d9) mfi0: 12332 (boot + 4s/0x0020/info) - Firmware version 2.120.53-1235 mfi0: 12333 (boot + 7s/0x0008/info) - Battery Present mfi0: 12334 (boot + 7s/0x0020/info) - Package version 12.12.0-0047 mfi0: 12335 (boot + 7s/0x0020/info) - Board Revision I have found this thread from a bit of googleing but it doesnt end too well. http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063821.html Was this ever taken further? One thing I have noticed is that the stall (and timeout messages) seem to go away if I query the card using mfiutil, I currently have a cron doing this every 2 minutes to see if this has been coincidence or not. Any suggestions welcome and i'm happy to provide more info if i can but I dont have a duplicate to do too much debugging on, I'm happy to try patches though. Is this worth filing a PR? Can you please provide uname -a output? The version of FreeBSD you're using matters greatly here. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi timeouts
On 28/10/2011 00:04, Jeremy Chadwick wrote: On Thu, Oct 27, 2011 at 11:52:51PM +0100, Vincent Hoffman wrote: I've recently installed a new NAS at work which uses a rebranded LSI megaraid sas [root@banshee ~]# mfiutil show adapter mfi0 Adapter: Product Name: Supermicro SMC2108 Serial Number: Firmware: 12.12.0-0047 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8k Maximum Stripe: 1M I'm running 8-STABLE as of 2011-10-23 (for zfs v28 as is got 26 3Tb drives) I'm seeing a lot of messages like mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 60 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 90 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 120 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 150 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 180 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 210 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 240 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 271 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 301 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 331 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 361 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 391 SECONDS mfi0: COMMAND 0xff8000b21b08 TIMEOUT AFTER 55 SECONDS mfi0: COMMAND 0xff8000b21b08 TIMEOUT AFTER 85 SECONDS At which time I'm seeing IO stall on the array connected to the mfi adapter, this can continue for 20 minutes or so resuming randomly (or so it seems although a little more on this later on) From pciconf -lv mfi0@pci0:5:0:0:class=0x010400 card=0x070015d9 chip=0x00791000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = RAID From dmesg mfi0: LSI MegaSAS Gen2 port 0xe000-0xe0ff mem 0xfbd9c000-0xfbd9,0xfbdc-0xfbdf irq 32 at device 0.0 on pci5 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 12330 (372962922s/0x0020/info) - Shutdown command received from host mfi0: 12331 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0079/1000/0700/15d9) mfi0: 12332 (boot + 4s/0x0020/info) - Firmware version 2.120.53-1235 mfi0: 12333 (boot + 7s/0x0008/info) - Battery Present mfi0: 12334 (boot + 7s/0x0020/info) - Package version 12.12.0-0047 mfi0: 12335 (boot + 7s/0x0020/info) - Board Revision I have found this thread from a bit of googleing but it doesnt end too well. http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063821.html Was this ever taken further? One thing I have noticed is that the stall (and timeout messages) seem to go away if I query the card using mfiutil, I currently have a cron doing this every 2 minutes to see if this has been coincidence or not. Any suggestions welcome and i'm happy to provide more info if i can but I dont have a duplicate to do too much debugging on, I'm happy to try patches though. Is this worth filing a PR? Can you please provide uname -a output? The version of FreeBSD you're using matters greatly here. Sure FreeBSD banshee.foobar.net 8.2-STABLE FreeBSD 8.2-STABLE #2: Wed Oct 26 16:14:09 BST 2011 t...@banshee.foobar.net:/usr/obj/usr/src/sys/BANSHEE amd64 [root@banshee /usr/src]# svn info Path: . Working Copy Root Path: /usr/src URL: http://svn.freebsd.org/base/stable/8 Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 226708 Node Kind: directory Schedule: normal Last Changed Author: brueffer Last Changed Rev: 226671 Last Changed Date: 2011-10-23 19:37:57 +0100 (Sun, 23 Oct 2011) It's looking like the mfiutil query stopping the stall is not a coincidence the last 2 have lasted less than the every 2 minutes that i set the cron to run, much less than previously. The cron is a simple /usr/sbin/mfiutil show volumes | grep -v OPTIMAL So get at least get an email if the volume breaks ;) Oct 28 00:01:06 banshee mfi0: COMMAND 0xff8000b22d18 TIMEOUT AFTER 59 SECONDS Oct 28 00:01:36 banshee mfi0: COMMAND 0xff8000b22d18 TIMEOUT AFTER 89 SECONDS Oct 28 00:13:09 banshee mfi0: COMMAND 0xff8000b205c8 TIMEOUT AFTER 50 SECONDS Oct 28 00:13:39 banshee mfi0: COMMAND 0xff8000b205c8 TIMEOUT AFTER 80 SECONDS I'm guessing this must kick something on the card. Vince ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi timeouts
Hi, There is a patch linked to from this PR, which seems very similar: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html The problem is also consistent with running mfiutil clearing the problem. I'm about to deploy mfi controllers in a similar configuration, so I'd be very curious about whether the patch fixes the problem for you. Regards, Jan Mikkelsen On 28/10/2011, at 10:39 AM, Vincent Hoffman wrote: On 28/10/2011 00:04, Jeremy Chadwick wrote: On Thu, Oct 27, 2011 at 11:52:51PM +0100, Vincent Hoffman wrote: I've recently installed a new NAS at work which uses a rebranded LSI megaraid sas [root@banshee ~]# mfiutil show adapter mfi0 Adapter: Product Name: Supermicro SMC2108 Serial Number: Firmware: 12.12.0-0047 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8k Maximum Stripe: 1M I'm running 8-STABLE as of 2011-10-23 (for zfs v28 as is got 26 3Tb drives) I'm seeing a lot of messages like mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 60 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 90 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 120 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 150 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 180 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 210 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 240 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 271 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 301 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 331 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 361 SECONDS mfi0: COMMAND 0xff8000b216c8 TIMEOUT AFTER 391 SECONDS mfi0: COMMAND 0xff8000b21b08 TIMEOUT AFTER 55 SECONDS mfi0: COMMAND 0xff8000b21b08 TIMEOUT AFTER 85 SECONDS At which time I'm seeing IO stall on the array connected to the mfi adapter, this can continue for 20 minutes or so resuming randomly (or so it seems although a little more on this later on) From pciconf -lv mfi0@pci0:5:0:0:class=0x010400 card=0x070015d9 chip=0x00791000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = RAID From dmesg mfi0: LSI MegaSAS Gen2 port 0xe000-0xe0ff mem 0xfbd9c000-0xfbd9,0xfbdc-0xfbdf irq 32 at device 0.0 on pci5 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 12330 (372962922s/0x0020/info) - Shutdown command received from host mfi0: 12331 (boot + 4s/0x0020/info) - Firmware initialization started (PCI ID 0079/1000/0700/15d9) mfi0: 12332 (boot + 4s/0x0020/info) - Firmware version 2.120.53-1235 mfi0: 12333 (boot + 7s/0x0008/info) - Battery Present mfi0: 12334 (boot + 7s/0x0020/info) - Package version 12.12.0-0047 mfi0: 12335 (boot + 7s/0x0020/info) - Board Revision I have found this thread from a bit of googleing but it doesnt end too well. http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063821.html Was this ever taken further? One thing I have noticed is that the stall (and timeout messages) seem to go away if I query the card using mfiutil, I currently have a cron doing this every 2 minutes to see if this has been coincidence or not. Any suggestions welcome and i'm happy to provide more info if i can but I dont have a duplicate to do too much debugging on, I'm happy to try patches though. Is this worth filing a PR? Can you please provide uname -a output? The version of FreeBSD you're using matters greatly here. Sure FreeBSD banshee.foobar.net 8.2-STABLE FreeBSD 8.2-STABLE #2: Wed Oct 26 16:14:09 BST 2011 t...@banshee.foobar.net:/usr/obj/usr/src/sys/BANSHEE amd64 [root@banshee /usr/src]# svn info Path: . Working Copy Root Path: /usr/src URL: http://svn.freebsd.org/base/stable/8 Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 226708 Node Kind: directory Schedule: normal Last Changed Author: brueffer Last Changed Rev: 226671 Last Changed Date: 2011-10-23 19:37:57 +0100 (Sun, 23 Oct 2011) It's looking like the mfiutil query stopping the stall is not a coincidence the last 2 have lasted less than the every 2 minutes that i set the cron to run, much less than previously. The cron is a simple /usr/sbin/mfiutil show volumes | grep -v OPTIMAL So get at least get an email if the volume breaks ;) Oct 28 00:01:06 banshee mfi0: COMMAND 0xff8000b22d18 TIMEOUT AFTER 59 SECONDS Oct 28 00:01:36 banshee mfi0: COMMAND 0xff8000b22d18 TIMEOUT AFTER 89 SECONDS Oct 28 00:13:09 banshee mfi0: COMMAND 0xff8000b205c8 TIMEOUT AFTER 50 SECONDS Oct 28 00:13:39 banshee mfi0: COMMAND 0xff8000b205c8 TIMEOUT AFTER 80 SECONDS I'm guessing this must kick something on the card. Vince
Unable to compile stable/9
I am currently running FreeBSD amd64 stable/9 r225905, and I have been unable to compile the stable/9 branch for the past couple of weeks. On the chance that there were any oddities in my source-tree, I have completely erased and checked out svn://svn.freebsd.org/base/stable/9 from scratch. With r226876, I continue to have compilation errors. I believe it is continuing to break in the same place during buildworld, as shown below. Is this to be expected ATM? Is the branch broken? Is this an unrelated gcc error? Or is there something I'm missing? Thanks, -kurt === lib/clang/libclangarcmigrate (all) c++ -O2 -pipe -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/ARCMTActions.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/FileRemapper.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/ARCMT.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/TransARCAssign.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/TransAutoreleasePool.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate/TransBlockObjCVariable.cpp c++ -O2 -pipe -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/lib/ARCMigrate -I. -I/usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\x86_64-unknown-freebsd9.0\ -fstack-protector -fno-exceptions -fno-rtti -c
