Re: Hardware RAID controller questions - 3Ware vs RocketRaid
Thanks for all your feedback. The problem occurs in the RAID controller BIOS (before we even boot or get to the OS install). Thanks to John for confirming these cards do work above 2TB. I will look into upgrading the firmware (on these brand new cards). Perhaps it's just the current firmware that can't handle 2TB harddrives x 3 in RAID. Cheers, Andreas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: greylisting with sendmail recommendations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/03/2010 04:08:45, Warren Block wrote: > On Fri, 19 Mar 2010, Jamie Griffin wrote: >> >> I'm thinking of implementing a greylisting milter for sendmail. I just >> wanted to ask here first to see if anyone has any feedback on which >> one might be the best to go with. I was looking at milter-greylist >> from ports, which seems quite popular, does anyone use this and have >> you found it to be effective? > > It works for me. Article that's a bit old but probably still close: > http://www.wonkity.com/~wblock/docs/greylist.pdf I like spamd from OpenBSD -- this is actually a firewall plugin which intercepts traffic to port 25. Works with any MTA. Not just greylisting, but greytrapping and teergrube. Every time you run obspamd, you make a spammer cry. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkujN+8ACgkQ8Mjk52CukIzhvACfW3AHSZ1d+QDfTxY2GVV/qy3+ oNYAoIK7n3QCv1TqGiTRqIouAZXsyZan =4t2W -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: greylisting with sendmail recommendations
> I like spamd from OpenBSD -- this is actually a firewall plugin which > intercepts traffic to port 25. Works with any MTA. > Not just greylisting, but greytrapping and teergrube. Every time you > run obspamd, you make a spammer cry. > > Cheers, > > Matthew Thanks Matthew, I like the sound of that and will check it out. Jamie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
FreeBSD NFS client goes into infinite retry loop
Hi, we use a FreeBSD 8-STABLE (from shortly after release) system as an NFS server to provide user home directories which get mounted across a few machines (all 6.3-RELEASE). For the past few weeks we have been running into problems where one particular client will go into an infinite loop where it is repeatedly trying to write data which causes the NFS server to return "reply ok 40 write ERROR: Input/output error PRE: POST:". This retry loop can cause between 20mbps and 500mbps of constant traffic on our network, depending on the size of the data associated with the failed write. We spent some time on the issue and determined that something on one of the clients is deleting a file as it is being written to by another NFS client. We were able to enable the NFS lockmgr and use lockf(1) to fix most of these conditions, and the frequency of this problem has dropped from once a night to once a week. However, it's still a problem and we can't necessarily force all of our users to "play nice" and use lockf/flock. Has anyone seen this before? No errors are being logged on the NFS server itself, but the "Server Ret-Failed" counter begins to increase rapidly whenever a client gets stuck in this infinite retry loop: Server Ret-Failed 224768961 I have a feeling that using NFS in such a matter may simply be prone to such problems, but what confuses me is why the NFS client system is infinitely retrying the write operation and causing itself so much grief. Thanks for any suggestions anyone can provide, Steve Polyack ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD NFS client goes into infinite retry loop
On Friday 19 March 2010 7:34:23 am Steve Polyack wrote: > Hi, we use a FreeBSD 8-STABLE (from shortly after release) system as an > NFS server to provide user home directories which get mounted across a > few machines (all 6.3-RELEASE). For the past few weeks we have been > running into problems where one particular client will go into an > infinite loop where it is repeatedly trying to write data which causes > the NFS server to return "reply ok 40 write ERROR: Input/output error > PRE: POST:". This retry loop can cause between 20mbps and 500mbps of > constant traffic on our network, depending on the size of the data > associated with the failed write. > > We spent some time on the issue and determined that something on one of > the clients is deleting a file as it is being written to by another NFS > client. We were able to enable the NFS lockmgr and use lockf(1) to fix > most of these conditions, and the frequency of this problem has dropped > from once a night to once a week. However, it's still a problem and we > can't necessarily force all of our users to "play nice" and use lockf/flock. > > Has anyone seen this before? No errors are being logged on the NFS > server itself, but the "Server Ret-Failed" counter begins to increase > rapidly whenever a client gets stuck in this infinite retry loop: > Server Ret-Failed > 224768961 > > I have a feeling that using NFS in such a matter may simply be prone to > such problems, but what confuses me is why the NFS client system is > infinitely retrying the write operation and causing itself so much grief. Yes, your feeling is correct. This sort of race is inherent to NFS if you do not use some sort of locking protocol to resolve the race. The infinite retries sound like a client-side issue. Have you been able to try a newer OS version on a client to see if it still causes the same behavior? -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
FreeBSD 8.0 Booting Problem on ZV5320US Laptop
I have recently installed FreeBSD8.0 on my 5 year old HP laptop with absolute 0 battery backup (behaviour same when batter removed). Installation works fine but when I try to boot into FreeBSD I get to the BTX loader screen, after having made any selection and it pauses for about 15 secs and the computer suddenly powers down. I was able to boot into the system occasionally lets say about 1 in 5 boots. I am able to install and boot into Linux without any problem. On successful boot, I did see a message "battery0: battery initialization failed" 1. Is there any way to increase the amount of debug messages printed on the screen to figure out what's happening ? 2. Has it got to do with some module crashing as, I am able to install and run LINUX without any problem ? 3. Why is there a pause of 15 secs after making the selection ? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD NFS client goes into infinite retry loop
On 03/19/10 08:31, John Baldwin wrote: On Friday 19 March 2010 7:34:23 am Steve Polyack wrote: Hi, we use a FreeBSD 8-STABLE (from shortly after release) system as an NFS server to provide user home directories which get mounted across a few machines (all 6.3-RELEASE). For the past few weeks we have been running into problems where one particular client will go into an infinite loop where it is repeatedly trying to write data which causes the NFS server to return "reply ok 40 write ERROR: Input/output error PRE: POST:". This retry loop can cause between 20mbps and 500mbps of constant traffic on our network, depending on the size of the data associated with the failed write. We spent some time on the issue and determined that something on one of the clients is deleting a file as it is being written to by another NFS client. We were able to enable the NFS lockmgr and use lockf(1) to fix most of these conditions, and the frequency of this problem has dropped from once a night to once a week. However, it's still a problem and we can't necessarily force all of our users to "play nice" and use lockf/flock. Has anyone seen this before? No errors are being logged on the NFS server itself, but the "Server Ret-Failed" counter begins to increase rapidly whenever a client gets stuck in this infinite retry loop: Server Ret-Failed 224768961 I have a feeling that using NFS in such a matter may simply be prone to such problems, but what confuses me is why the NFS client system is infinitely retrying the write operation and causing itself so much grief. Yes, your feeling is correct. This sort of race is inherent to NFS if you do not use some sort of locking protocol to resolve the race. The infinite retries sound like a client-side issue. Have you been able to try a newer OS version on a client to see if it still causes the same behavior? I can't try a newer FBSD version on the client where we are seeing the problems, but I can recreate the problem fairly easily. Perhaps I'll try it with an 8.0 client. If I remember correctly, one of the strange things is that it doesn't seem to hit "critical mass" until a few hours after the operation first fails. I may be wrong, but I'll double check that when I check vs. 8.0-release. I forgot to add this in the first post, but these are all TCP NFS v3 mounts. Thanks for the response. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD 8.0 Booting Problem on ZV5320US Laptop
>On Fri, Mar 19, 2010 at 8:20 AM, Anoop Kumar Narayanan >wrote: >I have recently installed FreeBSD8.0 on my 5 year old HP laptop with >absolute 0 battery backup (behaviour same when batter removed). >Installation works fine but when I try to boot into FreeBSD I get to >the BTX loader screen, after having made any selection and it pauses >for about 15 secs and the computer suddenly powers down. I was able to >boot into the system occasionally lets say about 1 in 5 boots. I am >able to install and boot into Linux without any problem. So then you are attempting to startup using a power adaptor (i.e. your computer is plugged in to a wall socket)? I had the reverse problem a while ago with Slackware shutting down in the middle of installation onto a Toshiba laptop while FreeBSD has always been no problem. My guess is that these issues reflect power management settings, perhaps even something in the bios. Does this occur when you use the installation or boot-only disks? Sorry this is not more help to you. Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: VirtualBox from the command line
On 19/03/2010 03:45, Warren Block wrote: On Thu, 18 Mar 2010, Adam Vande More wrote: On Thu, Mar 18, 2010 at 7:44 PM, Aiza wrote: Does VirtualBox launch from the FBSD command line? Is there a package for it in the pkg system? # VirtualBox -h Sun VirtualBox Graphical User Interface 3.1.2_OSE (C) 2005-2009 Sun Microsystems, Inc. All rights reserved. Usage: --startvm start a VM by specifying its UUID or name --rmode sdl|image select different render mode (default is sdl) There are other ways too, eg VBoxHeadless And VBoxSDL. And VBoxManage. You can even create VMs from the command line, but it's fairly involved. -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" The problem with headless VirtualBox on FreeBSD is that the VRDP Connection is set to not active on VirtualBox OSE. AFAIK that makes it impossible to use headless VirtualBox on FreeBSD. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
How to set LD_PATH elegant?
I'm a little bit new to setting library paths, so sorry for the noise. I install some packages and libraries apart the FreeBSD package/ports system and need to setup the search path for shared libraries the proper way. At this very moment I 'hardcode' this additional search path by setting ldconfig_paths= in /etc/rc.conf, but since this is a 'system related' location I'm looking for a proper and clean method setting this search path via environment variable and/or some /usr/local/etc/rc.conf.add stuff or similar. I appreciate any hint. Regards, Oliver Hartmann ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: How to set LD_PATH elegant?
On Fri, Mar 19, 2010 at 10:40 AM, O. Hartmann wrote: > I'm a little bit new to setting library paths, so sorry for the noise. > > I install some packages and libraries apart the FreeBSD package/ports system > and need > to setup the search path for shared libraries the proper way. > > At this very moment I 'hardcode' this additional search path by setting > > ldconfig_paths= > > in /etc/rc.conf, > > > but since this is a 'system related' location I'm looking for a proper and > clean method setting this search path > via environment variable and/or some /usr/local/etc/rc.conf.add stuff or > similar. > If I understand your question correctly perhaps the LD_LIBRARY_PATH is what you are looking for. It will set the search order for the libraries, not the executables which is what PATH variable is for. > I appreciate any hint. > > Regards, > > Oliver Hartmann > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Trouble Installing JKD15 On A Vanilla 8.0 Installation
I wanted to create a small test system that could host SSH, Apache, and Jboss, so I decided to install the 8.0 version of FreeBSD on Virtualbox. Everything had gone very well until I tried to install the jdk15 port. Please note that I am very comfortable with Linux (I've been using it at home for 9 years), but I'm very new to the world of FreeBSD. First, after the port had compiled on my system for many hours, it crashed with an error message stating that I was "out of swap space". I had only devoted 128 MB of RAM to the VM at this point (I planned to increase it later), so I doubled that to 256 MB and re-ran "make install clean". After doing that, I got the following error message: ===> Building for jdk-1.5.0.16p9_3,1 # Start of jdk build bsd i586 1.5.0_16-p9 build started: 10-03-19 03:37 if [ -r ./../../deploy/make/Makefile ]; then \ ( cd ./../../deploy/make; gmake sanity EXTERNALSANITYCONTROL=true CONTROL_TOPDIR=/usr/ports/java/jdk15/work/control CONTROL_TOPDIR_NAME=control ALT_OUTPUTDIR=/usr/ports/java/jdk15/work/control/build/bsd-i586 ARCH_DATA_MODEL=32 MILESTONE=p9 BUILD_NUMBER=root_19_mar_2010_03_37 JDK_BUILD_NUMBER=b00 ; ); \ fi gmake[1]: Entering directory `/usr/ports/java/jdk15/work/deploy/make' gmake[1]: Leaving directory `/usr/ports/java/jdk15/work/deploy/make' gmake[1]: Entering directory `/usr/ports/java/jdk15/work/j2se/make' gmake[1]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make' if [ -r ./../../install/make/Makefile ]; then \ ( cd ./../../install/make; gmake sanity MAKEFLAGS= EXTERNALSANITYCONTROL=true ALT_CONTROL_TOPDIR=/usr/ports/java/jdk15/work/control ALT_J2SE_TOPDIR=/usr/ports/java/jdk15/work/j2se ALT_OUTPUTDIR=/usr/ports/java/jdk15/work/control/build/bsd-i586 ALT_RTPATCH_DIR= ALT_BASE_IMAGE_ZIP= ALT_BASE_IMAGE_DIR= ALT_NEW_IMAGE_DIR= ALT_BUNDLE_DATE=19_mar_2010 ; ); \ fi gmake[1]: Entering directory `/usr/ports/java/jdk15/work/install/make' gmake[1]: Leaving directory `/usr/ports/java/jdk15/work/install/make' Build Machine Information: build machine = Build Directory Structure: CWD = /usr/ports/java/jdk15/work/control/make TOPDIR = ./../.. CONTROL_TOPDIR = ./../../control HOTSPOT_TOPDIR = ./../../hotspot J2SE_TOPDIR = ./../../j2se DEPLOY_TOPDIR = ./../../deploy INSTALL_TOPDIR = ./../../install SPONSORS_TOPDIR = ./../../sponsors Build Directives: BUILD_HOTSPOT = true BUILD_MOTIF = false BUILD_INSTALL = true BUILD_SPONSORS = false Hotspot Settings: HOTSPOT_BUILD_JOBS = Bootstrap Settings: JAVAWS_BOOTDIR = /usr/ports/java/jdk15/work/control/build/bsd-i586 BOOTSTRAP J2SDK VERSION: OUTPUTDIR = /usr/ports/java/jdk15/work/control/build/bsd-i586 Build Tool Settings: JDK_DEVTOOLS_DIR = UNIXCOMMAND_PATH = /bin/ COMPILER_PATH = /usr/bin/ DEVTOOLS_PATH = /usr/local/bin/ USRBIN_PATH = /usr/bin/ MOZILLA_HEADERS_PATH = ../src/plugin/include CC_VER = 4.2.1 PATH = /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin Build Directives: PEDANTIC = INSANE = Build Platform Settings: PLATFORM = bsd ARCH = i586 LIBARCH = i386 ARCH_FAMILY = i586 ARCH_DATA_MODEL = 32 OS_VERSION = 8.0-RELEASE FREE_SPACE = 4337918 GNU Make Settings: MAKE = gmake MAKE VERSION = MAKECMDGOALS = sanity MAKEFLAGS = w -- JDK_BUILD_NUMBER=b00 BUILD_NUMBER=root_19_mar_2010_03_37 MILESTONE=p9 ARCH_DATA_MODEL=32 ALT_OUTPUTDIR=/usr/ports/java/jdk15/work/control/build/bsd-i586 CONTROL_TOPDIR_NAME=control CONTROL_TOPDIR=/usr/ports/java/jdk15/work/control EXTERNALSANITYCONTROL=true SHELL = /bin/sh Target Build Versions: JAVAWS_VERSION = 1.5.0_16 MILESTONE = p9 BUILD_NUMBER = root_19_mar_2010_03_37 Bootstrap Settings: BOOTDIR = /usr/local/diablo-jdk1.6.0 BOOTSTRAP J2SDK VERSION: 1.6.0_07 OUTPUTDIR = /usr/ports/java/jdk15/work/control/build/bsd-i586 Build Tool Settings: JDK_DEVTOOLS_DIR = UNIXCOMMAND_PATH = /bin/ COMPILER_PATH = /usr/bin/ DEVTOOLS_PATH = /usr/local/bin/ USRBIN_PATH = /usr/bin/ MOTIF_DIR = /usr/local CC_VER = 4.2.1 ZIP_VER = 3.0 PATH = /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin TMPDIR = /usr/ports/java/jdk15/work/control/build/bsd-i586/tmp Build Directives: USE_ONLY_BOOTDIR_TOOLS = USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = J2RE_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = PARALLEL_COMPILES = false PARALLEL_COMPILE_JOBS = 2 FASTDEBUG = false INCREMENTAL_BUILD =
Re: tunefs -L issue
Wait a second. What do I have to do, mount single user to find the darn things? They have completely disappeared, not even a 'GEOM_LABEL: Label ufsid/482b3a7c20b36d8c removed' in dmesg! (thought I was previously seeing that on shutdown, not startup, now neither) Even in single user mode, root is already mounted, so I'm never going to find the label for it. I'm afraid man geom is just leaving me guessing (see below). geom label doesn't seem to think I have any disks... Handbook: % glabel status Name Status Components ufsid/486b6fc38d330916 N/A ad4s1d ufsid/486b6fc16926168e N/A ad4s1f Local: [st...@fyre /usr/home/steve]$ glabel status Name Status Components iso9660/WALL_E N/A acd0 [st...@fyre /usr/home/steve]$ ??? Steve [st...@fyre /usr/home/steve]$ glabel status Name Status Components iso9660/WALL_E N/A acd0 [st...@fyre /usr/home/steve]$ geom ufs list geom: Command 'list' not available. [st...@fyre /usr/home/steve]$ sudo geom ufs list geom: Command 'list' not available. [st...@fyre /usr/home/steve]$ sudo geom ufs help usage: geom ufs help geom ufs list [name ...] geom ufs status [-s] [name ...] geom ufs load [-v] geom ufs unload [-v] [st...@fyre /usr/home/steve]$ sudo geom ufs list /dev/ad0 geom: Command 'list' not available. [st...@fyre /usr/home/steve]$ sudo geom ufs list /dev/ad0s1 geom: Command 'list' not available. [st...@fyre /usr/home/steve]$ sudo geom ufs status geom: Command 'status' not available. [st...@fyre /usr/home/steve]$ sudo geom ufs load geom: Command 'load' not available. [st...@fyre /usr/home/steve]$ sudo geom disk list Geom name: ad0 Providers: 1. Name: ad0 Mediasize: 400087375360 (373G) Sectorsize: 512 Mode: r5w5e14 fwsectors: 63 fwheads: 16 Geom name: cd0 Providers: 1. Name: cd0 Mediasize: 4681957376 (4.4G) Sectorsize: 2048 Mode: r0w0e0 fwsectors: 0 fwheads: 0 Geom name: da0 Providers: 1. Name: da0 Mediasize: 0 (0B) Sectorsize: 0 Mode: r0w0e0 fwsectors: 0 fwheads: 0 Geom name: da1 Providers: 1. Name: da1 Mediasize: 0 (0B) Sectorsize: 0 Mode: r0w0e0 fwsectors: 0 fwheads: 0 Geom name: da2 Providers: 1. Name: da2 Mediasize: 0 (0B) Sectorsize: 0 Mode: r0w0e0 fwsectors: 0 fwheads: 0 Geom name: da3 Providers: 1. Name: da3 Mediasize: 0 (0B) Sectorsize: 0 Mode: r0w0e0 fwsectors: 0 fwheads: 0 [st...@fyre /usr/home/steve]$ sudo geom label list Geom name: acd0 Providers: 1. Name: iso9660/WALL_E Mediasize: 4681957376 (4.4G) Sectorsize: 2048 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 918 length: 4681957376 index: 0 Consumers: 1. Name: acd0 Mediasize: 4681957376 (4.4G) Sectorsize: 2048 Mode: r0w0e0 [st...@fyre /usr/home/steve]$ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Trouble Installing JKD15 On A Vanilla 8.0 Installation
On Fri, 19 Mar 2010, Tom Purl wrote: I wanted to create a small test system that could host SSH, Apache, and Jboss, so I decided to install the 8.0 version of FreeBSD on Virtualbox. Everything had gone very well until I tried to install the jdk15 port. Please note that I am very comfortable with Linux (I've been using it at home for 9 years), but I'm very new to the world of FreeBSD. First, after the port had compiled on my system for many hours, it crashed with an error message stating that I was "out of swap space". I had only devoted 128 MB of RAM to the VM at this point (I planned to increase it later), so I doubled that to 256 MB That still seems pretty small for a Java build from source. Give the VM as much memory as the host can afford. You can always reduce that after the build is done. and re-ran "make install clean". There may have been a half-built work directory still in place from the failed build. If that happens, clear it with a 'make clean'. For big ports like Java, it helps to break up the steps. Do just a make, then if it builds, make install, then after that succeeds, make clean. 1. Is Java 5 not supported on version 8 of FreeBSD? I found the following tip that apparently eliminates this error, but it really seems to be a hack to me. Is there a better way? * http://lists.freebsd.org/pipermail/freebsd-ports/2008-July/049686.html Don't know, but jkd16 works on 8. Except the Firefox plugin. 2. I think there's a possibility that this error is due to the earlier segfault of the package manager. That was not shown in your message, so it's hard to tell exactly what you mean. Unless you're talking about the port build error, which wasn't a segfault or a package manager. Would it therefore make sense to re-install it using the "make deinstall && make install clean" command? Which "it"? -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD NFS client goes into infinite retry loop
On 03/19/10 09:23, Steve Polyack wrote:
On 03/19/10 08:31, John Baldwin wrote:
On Friday 19 March 2010 7:34:23 am Steve Polyack wrote:
Hi, we use a FreeBSD 8-STABLE (from shortly after release) system as an
NFS server to provide user home directories which get mounted across a
few machines (all 6.3-RELEASE). For the past few weeks we have been
running into problems where one particular client will go into an
infinite loop where it is repeatedly trying to write data which causes
the NFS server to return "reply ok 40 write ERROR: Input/output error
PRE: POST:". This retry loop can cause between 20mbps and 500mbps of
constant traffic on our network, depending on the size of the data
associated with the failed write.
We spent some time on the issue and determined that something on one of
the clients is deleting a file as it is being written to by another NFS
client. We were able to enable the NFS lockmgr and use lockf(1) to fix
most of these conditions, and the frequency of this problem has dropped
from once a night to once a week. However, it's still a problem and we
can't necessarily force all of our users to "play nice" and use
lockf/flock.
Has anyone seen this before? No errors are being logged on the NFS
server itself, but the "Server Ret-Failed" counter begins to increase
rapidly whenever a client gets stuck in this infinite retry loop:
Server Ret-Failed
224768961
I have a feeling that using NFS in such a matter may simply be prone to
such problems, but what confuses me is why the NFS client system is
infinitely retrying the write operation and causing itself so much
grief.
Yes, your feeling is correct. This sort of race is inherent to NFS
if you do
not use some sort of locking protocol to resolve the race. The infinite
retries sound like a client-side issue. Have you been able to try a
newer OS
version on a client to see if it still causes the same behavior?
I can't try a newer FBSD version on the client where we are seeing the
problems, but I can recreate the problem fairly easily. Perhaps I'll
try it with an 8.0 client. If I remember correctly, one of the
strange things is that it doesn't seem to hit "critical mass" until a
few hours after the operation first fails. I may be wrong, but I'll
double check that when I check vs. 8.0-release.
I forgot to add this in the first post, but these are all TCP NFS v3
mounts.
Thanks for the response.
Ok, so I'm still able to trigger what appears to be the same retry loop
with an 8.0-RELEASE nfsv3 client (going on 1.5 hours now):
$ cat nfs.sh
client#!/usr/local/bin/bash
for a in {1..15} ; do
sleep 1;
echo "$a$a$";
done
client$ ./nfs.sh >~/output
the on the server while the above is running:
server$ rm ~/output
What happens is that you will see 3-4 of the same write attempts happen
per minute via tcpdump. Our previous logs show that this is how it
starts, and then ~4 hours later it begins to spiral out of control,
throwing out up to 3,000 of the same failed write requests per second.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: VirtualBox from the command line
On Fri, 19 Mar 2010, Ricardo Jesus wrote: The problem with headless VirtualBox on FreeBSD is that the VRDP Connection is set to not active on VirtualBox OSE. AFAIK that makes it impossible to use headless VirtualBox on FreeBSD. There are patches to use VNC with the OSE version: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=170485+0+archive/2010/freebsd-stable/20100221.freebsd-stable -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Elegant way to hack port source
Hi, I need to modify a file from a port before building. Specifically, the sane-backends pnm.c driver has a bug and the folks at the original project has not fixed for a while. I need to modify pnm.c in the work directory before compiling. What is an elegant way of doing this? If I make and then modify, the main make file does not see the change made in the file and will not recompile. And since there is no actual makefile in the work subdirectory I can't compile there either! There must be a FreeBSD way of dealing with modifying a port source before compiling. Please advise. Thanks in advance, Alejandro Imass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri, Mar 19, 2010 at 12:05 PM, Alejandro Imass wrote: > Hi, > > I need to modify a file from a port before building. Specifically, the > sane-backends pnm.c driver has a bug and the folks at the original > project has not fixed for a while. I need to modify pnm.c in the work > directory before compiling. What is an elegant way of doing this? If I > make and then modify, the main make file does not see the change made > in the file and will not recompile. And since there is no actual > makefile in the work subdirectory I can't compile there either! You could make a copy of graphics/sane-backends to graphics/sane-backends-devel, fix the source in the new port's directory and install it as a regular port. Check this out too http://www.freebsd.org/doc/en/books/porters-handbook/ Best regards Alberto Mijares ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD 8.0 Booting Problem on ZV5320US Laptop
On Fri, Mar 19, 2010 at 7:49 PM, Richard DeLaurell wrote: >>On Fri, Mar 19, 2010 at 8:20 AM, Anoop Kumar Narayanan >>wrote: >>I have recently installed FreeBSD8.0 on my 5 year old HP laptop with >>absolute 0 battery backup (behaviour same when batter removed). >>Installation works fine but when I try to boot into FreeBSD I get to >>the BTX loader screen, after having made any selection and it pauses >>for about 15 secs and the computer suddenly powers down. I was able to >>boot into the system occasionally lets say about 1 in 5 boots. I am >>able to install and boot into Linux without any problem. > > > So then you are attempting to startup using a power adaptor (i.e. your > computer is plugged in to a wall socket)? Yes. I don't know if its a specific Athlon XP related problem as I did observe a similar post some years ago. And, Apparently its the same thing. http://osdir.com/ml/os.freebsd.devel.hardware/2004-10/msg00044.html In this case its the installation. In my case its after the installation. > > I had the reverse problem a while ago with Slackware shutting down in the > middle of installation onto a Toshiba laptop while FreeBSD has always been > no problem. > > My guess is that these issues reflect power management settings, perhaps > even something in the bios. Maybe its something in the BIOS, but the thing is that Linux boots fine on the machine. Maybe some driver is crashing and is causing a reboot of the machine. Are there any critical drivers in the system that can result in such a problem. > > Does this occur when you use the installation or boot-only disks? I can install it just fine, but can't seem to to boot into the installed version (Once its been installed). I did create the FreeBSD swap partition before the root file-system (and it still seems to label the root file-system as 'a'), Would this affect the system boot up in anyway ? > > Sorry this is not more help to you. > > Richard > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: tunefs -L issue
On Fri, Mar 19, 2010 at 08:02:10AM -0700, Steve Franks wrote: > Wait a second. What do I have to do, mount single user to find the > darn things? They have completely disappeared, not even a > 'GEOM_LABEL: Label ufsid/482b3a7c20b36d8c removed' in dmesg! (thought > I was previously seeing that on shutdown, not startup, now neither) The following command looks also in the old messages files; bzgrep 'Label for.*ufsid' /var/log/messages.* | less > Even in single user mode, root is already mounted, so I'm never going > to find the label for it. I'm afraid man geom is just leaving me > guessing (see below). geom label doesn't seem to think I have any > disks... > > Handbook: > > % glabel status > Name Status Components > ufsid/486b6fc38d330916 N/A ad4s1d > ufsid/486b6fc16926168e N/A ad4s1f > > Local: > > [st...@fyre /usr/home/steve]$ glabel status > Name Status Components > iso9660/WALL_E N/A acd0 > [st...@fyre /usr/home/steve]$ > I don't see anything here either on my system. Doesn't tunefs -L work? (sorry, can't recall the beginning of this thread). Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpIBjHX3coBq.pgp Description: PGP signature
Re: Elegant way to hack port source
You can do it this way in the ports system: http://www.freebsd.org/doc/en/books/porters-handbook/slow-patch.html I handle all my patching for ports this way. -jgh On Fri, Mar 19, 2010 at 12:35:30PM -0400, Alejandro Imass thus spake: Hi, I need to modify a file from a port before building. Specifically, the sane-backends pnm.c driver has a bug and the folks at the original project has not fixed for a while. I need to modify pnm.c in the work directory before compiling. What is an elegant way of doing this? If I make and then modify, the main make file does not see the change made in the file and will not recompile. And since there is no actual makefile in the work subdirectory I can't compile there either! There must be a FreeBSD way of dealing with modifying a port source before compiling. Please advise. Thanks in advance, Alejandro Imass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri, Mar 19, 2010 at 12:44 PM, Alberto Mijares wrote: > On Fri, Mar 19, 2010 at 12:05 PM, Alejandro Imass wrote: >> Hi, >> >> I need to modify a file from a port before building. Specifically, the >> sane-backends pnm.c driver has a bug and the folks at the original >> project has not fixed for a while. I need to modify pnm.c in the work >> directory before compiling. What is an elegant way of doing this? If I >> make and then modify, the main make file does not see the change made >> in the file and will not recompile. And since there is no actual >> makefile in the work subdirectory I can't compile there either! > > > > You could make a copy of graphics/sane-backends to > graphics/sane-backends-devel, fix the source in the new port's > directory and install it as a regular port. > > Check this out too > > http://www.freebsd.org/doc/en/books/porters-handbook/ > > Best regards > Thanks Alberto. I have checked the porter's handbook before writing this, in fact I discovered the CONFIGURE_ARGS variable which proved very useful for passing the --enable-pnm-backend switch to the configure script. (http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/building.html#USING-CONFIGURE). Nevertheless, the problem is that pnm.c has a bug since last year and it has not been fixed, and only developers use that driver, so I guess we've all gotten used to fiddling with the source, instead of forcing the maintainer to fix it. BTW today I got tired of this BS so I formnally filed the bug: https://alioth.debian.org/tracker/index.php?func=detail&aid=312401&group_id=30186&atid=410366 Anyway, back to the port, this is the problem I have: whe I type make CONFIGURE_ARGS=--enable-pnm-backend it effectively makes all the backends in the correct way, including the infamous pnm backend. I later go to the work directory, go into the sane-backends sub-directory and modify backends/pnm.c. I latter go back to the root of the port (/usr/ports/graphics/sane-backends/) and type make again and nothing happens. In a normal make scenario, make would detct the .c had changed and re-compile and link just that file(s). In the ports make scenario, make doesn't do that. Is there a special switch to the port's make process, to actually go and re-make the source? Thanks, Alejandro Imass > > Alberto Mijares > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri, Mar 19, 2010 at 12:56 PM, Jason wrote: > You can do it this way in the ports system: > > http://www.freebsd.org/doc/en/books/porters-handbook/slow-patch.html > > I handle all my patching for ports this way. Ok. I guess I'll stop my laziness and RT-W-FM! Thanks! Alejandro Imass > > -jgh > > On Fri, Mar 19, 2010 at 12:35:30PM -0400, Alejandro Imass thus spake: >> >> Hi, >> >> I need to modify a file from a port before building. Specifically, the >> sane-backends pnm.c driver has a bug and the folks at the original >> project has not fixed for a while. I need to modify pnm.c in the work >> directory before compiling. What is an elegant way of doing this? If I >> make and then modify, the main make file does not see the change made >> in the file and will not recompile. And since there is no actual >> makefile in the work subdirectory I can't compile there either! >> >> There must be a FreeBSD way of dealing with modifying a port source >> before compiling. Please advise. >> >> Thanks in advance, >> Alejandro Imass >> ___ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to >> "freebsd-questions-unsubscr...@freebsd.org" >> > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri, Mar 19, 2010 at 12:35:30PM -0400, Alejandro Imass wrote: > Hi, > > I need to modify a file from a port before building. Specifically, the > sane-backends pnm.c driver has a bug and the folks at the original > project has not fixed for a while. I need to modify pnm.c in the work > directory before compiling. What is an elegant way of doing this? If I > make and then modify, the main make file does not see the change made > in the file and will not recompile. And since there is no actual > makefile in the work subdirectory I can't compile there either! > > There must be a FreeBSD way of dealing with modifying a port source > before compiling. Please advise. Add the patch to the files/ directory of the port. The patch should be relative to the main source directory of the port, e.g. work/foo-x.y for the foo port. Use a name for the patch that doesn't exist yet. After creating the patch, use chflags to set the uschg and uunlnk flags for your patch. This way, if the port is updated, your patch cannot be removed. But you might need to update it. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpGkk7V768wn.pgp Description: PGP signature
Re: VirtualBox from the command line
--On Friday, March 19, 2010 11:46:51 +0800 Aiza wrote: Why don't virtual box GUI start in vga mode? VirtualBox is in ports and installs as an application like Firefox. Here's a screenshot of it running on my workstation: http://www.utdallas.edu/~pauls/VirtualBox_on_FreeBSD.png And here's a shot of the menu item in KDE4: http://www.utdallas.edu/~pauls/VirtualBox_menu_KDE4.png It's the second item from the top, because it's a recently used program. It also appears in the System menu on KDE4. However you create icons to launch programs in your window manager, that's how you would create one to start VirtualBox. It has to start as an X11 program, not a commandline (terminal) program. Is this telling me that I have to have Xorg and some desktop running before VirtualBox's gui will function? Yes. VirtualBox is a GUI program designed to run alternative OSes inside the native OS. (There may be a commandline version that I'm not familiar with.) Are the scripts provided by vboxtool the only way to have command line control of VirtualBox? http://vboxtool.sourceforge.net/ See talk about vboxweb as alternate VirtualBox manager. http://vboxweb.blogspot.com/ Does not look like this is out of development yet. Anybody using this? Well, clearly I'm using the GUI version. I also use it on Mac Snow Leopard. It beats the hell out of VMware or having to run Windows natively. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri, Mar 19, 2010 at 1:01 PM, Roland Smith wrote: > On Fri, Mar 19, 2010 at 12:35:30PM -0400, Alejandro Imass wrote: >> Hi, >> >> I need to modify a file from a port before building. Specifically, the [...] > > Add the patch to the files/ directory of the port. The patch should be > relative to the main source directory of the port, e.g. work/foo-x.y for the > foo port. Use a name for the patch that doesn't exist yet. > > After creating the patch, use chflags to set the uschg and uunlnk flags for > your patch. This way, if the port is updated, your patch cannot be > removed. But you might need to update it. > Thanks! Worked like a charm!!! Nevertheless, now there is another bug :-( Cheers! Alejandro Imass > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: VirtualBox from the command line
--On Friday, March 19, 2010 08:44:48 +0800 Aiza wrote: Does VirtualBox launch from the FBSD command line? Is there a package for it in the pkg system? It's in ports. I don't know if there's a package for it, but I suspect there is, and it's probably older than the ports version. It's an application. Just like Firefox. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: tunefs -L issue
On Fri, Mar 19, 2010 at 9:57 AM, Roland Smith wrote: > On Fri, Mar 19, 2010 at 08:02:10AM -0700, Steve Franks wrote: >> Wait a second. What do I have to do, mount single user to find the >> darn things? They have completely disappeared, not even a >> 'GEOM_LABEL: Label ufsid/482b3a7c20b36d8c removed' in dmesg! (thought >> I was previously seeing that on shutdown, not startup, now neither) > > The following command looks also in the old messages files; > > bzgrep 'Label for.*ufsid' /var/log/messages.* | less > >> Even in single user mode, root is already mounted, so I'm never going >> to find the label for it. I'm afraid man geom is just leaving me >> guessing (see below). geom label doesn't seem to think I have any >> disks... >> >> Handbook: >> >> % glabel status >> Name Status Components >> ufsid/486b6fc38d330916 N/A ad4s1d >> ufsid/486b6fc16926168e N/A ad4s1f >> >> Local: >> >> [st...@fyre /usr/home/steve]$ glabel status >> Name Status Components >> iso9660/WALL_E N/A acd0 >> [st...@fyre /usr/home/steve]$ >> > > I don't see anything here either on my system. > > Doesn't tunefs -L work? (sorry, can't recall the beginning of this thread). Apparently, but only in single-user mode. I think my problem is more one of documentation. The handbook is rather obtuse on the subject. The inability to even locate or read the labels on a mounted system is about as un-POLS as I've come across lately Thanks for the help, though. I booted single-user, mounted a usb-stick, and piped the output of geom label to a file on the stick. Not fun. Only having run FBSD for 4 years or so now, I wasn't aware of any good sources for this kind of info except dmesg. I'll be looking into /var/log/messages more closely in the future. You don't see it mentioned too often in reference to noob questions. Thanks, Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: tunefs -L issue
On Fri, Mar 19, 2010 at 12:21:27PM -0700, Steve Franks wrote: > On Fri, Mar 19, 2010 at 9:57 AM, Roland Smith wrote: > > On Fri, Mar 19, 2010 at 08:02:10AM -0700, Steve Franks wrote: > >> Wait a second. What do I have to do, mount single user to find the > >> darn things? They have completely disappeared, not even a > >> 'GEOM_LABEL: Label ufsid/482b3a7c20b36d8c removed' in dmesg! (thought > >> I was previously seeing that on shutdown, not startup, now neither) > > > > The following command looks also in the old messages files; > > > > bzgrep 'Label for.*ufsid' /var/log/messages.* | less > > > >> Even in single user mode, root is already mounted, so I'm never going > >> to find the label for it. I'm afraid man geom is just leaving me > >> guessing (see below). geom label doesn't seem to think I have any > >> disks... > >> > >> Handbook: > >> > >> % glabel status > >> Name Status Components > >> ufsid/486b6fc38d330916 N/A ad4s1d > >> ufsid/486b6fc16926168e N/A ad4s1f > >> > >> Local: > >> > >> [st...@fyre /usr/home/steve]$ glabel status > >> Name Status Components > >> iso9660/WALL_E N/A acd0 > >> [st...@fyre /usr/home/steve]$ > >> > > > > I don't see anything here either on my system. > > > > > > Doesn't tunefs -L work? (sorry, can't recall the beginning of this thread). > > Apparently, but only in single-user mode. According to tunefs(8) you should be able to run it on a filesystem that has been made read-only. You can make a mounted filesystem read-only with 'mount -u -r '. You can afterwards make it read/write again with 'mount -u -w '. > I think my problem is more > one of documentation. The handbook is rather obtuse on the subject. > The inability to even locate or read the labels on a mounted system is > about as un-POLS as I've come across lately The ufsid labels are automatically removed from a filesystem when it is mounted. So it is not surprising that no ufsid labels are found on a running system. And IIRC, the automatic ufsid labels are a new feature. The handbook might be slightly behind the times. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpn4wRb6AryB.pgp Description: PGP signature
Debugging symbols in ports
Hi, Is there an elegant way to enable debugging symbols in ports in general, or is this port-specific? I have read _many_ threads regarding this but I can't seem to find a definitive position on this. I would not like to resort to the original sources but work from the ports themselves. Thanks! Alejandro Imass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri 19 Mar 2010 at 10:01:59 PDT Roland Smith wrote:
On Fri, Mar 19, 2010 at 12:35:30PM -0400, Alejandro Imass wrote:
Hi,
I need to modify a file from a port before building. Specifically, the
sane-backends pnm.c driver has a bug and the folks at the original
project has not fixed for a while. I need to modify pnm.c in the work
directory before compiling. What is an elegant way of doing this? If I
make and then modify, the main make file does not see the change made
in the file and will not recompile. And since there is no actual
makefile in the work subdirectory I can't compile there either!
There must be a FreeBSD way of dealing with modifying a port source
before compiling. Please advise.
Add the patch to the files/ directory of the port. The patch should be
relative to the main source directory of the port, e.g. work/foo-x.y for the
foo port. Use a name for the patch that doesn't exist yet.
After creating the patch, use chflags to set the uschg and uunlnk flags for
your patch. This way, if the port is updated, your patch cannot be
removed. But you might need to update it.
If the port already patches the file(s) in question, run 'make patch'
with the port makefile first, so you don't lose that work.
Then cd to the working directory and make your additional changes.
If you need to change a file that wasn't already patched by the port,
first save a copy of it using 'cp foo{,.orig}'. Then edit the copy
without the .orig suffix.
When you're done with those, use 'diff -u foo{.orig,}' to generate an
updated patchfile.
The convention is to name the patchfile 'patch-foo' (substituting the
actual name of the source file for 'foo'). But if the existing patch
uses some other pattern, use that instead.
So, if you're updating or creating a patch to foo.c which is in the
toplevel working directory for port bar, and you're in work/bar-x.y,
you would use something like the following:
diff -u foo.c{.orig,} > ../../files/patch-foo.c
Now run 'make clean' with the port makefile. From here on, 'make build'
or 'make install' will apply your new patches along with any
pre-existing ones.
Whenever I modify a port like this, I usually make a copy of it under
root's home directory and install it from there. That way, I can keep
my copy of the portstree in complete synch with the official one, and
there's no need to worry about updates quashing my changes. It also
provides a quick-and-dirty way to see which ports I've modified.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Debugging symbols in ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alejandro Imass wrote: > Hi, > > Is there an elegant way to enable debugging symbols in ports in > general, or is this port-specific? I have read _many_ threads > regarding this but I can't seem to find a definitive position on this. > I would not like to resort to the original sources but work from the > ports themselves. > > Thanks! > Alejandro Imass Hi Alejandro, Try this: make WITH_DEBUG=yes install clean WITH_DEBUG adds -g to the CFLAGS and prevents the binary from being stripped during installation. Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLo9jP0sRouByUApARAuTUAJ0X0hp7txxe6J3OAX37kEyow4WeRQCgvFQA Lz28yinkSFM79WxThqx4d04= =HAVD -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
> "Charlie" == Charlie Kester writes: Charlie> Whenever I modify a port like this, I usually make a copy of it under Charlie> root's home directory and install it from there. That way, I can keep Charlie> my copy of the portstree in complete synch with the official one, and Charlie> there's no need to worry about updates quashing my changes. It also Charlie> provides a quick-and-dirty way to see which ports I've modified. Isn't that also what /usr/ports/local is for? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
--On Friday, March 19, 2010 13:01:30 -0700 Charlie Kester wrote: Whenever I modify a port like this, I usually make a copy of it under root's home directory and install it from there. That way, I can keep my copy of the portstree in complete synch with the official one, and there's no need to worry about updates quashing my changes. It also provides a quick-and-dirty way to see which ports I've modified. To the O.P.: How about submiting the patch to the community so it can be added by the port maintainer? If it actually fixes a bug in the software you can't be the only one would benefit from the patch. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD NFS client goes into infinite retry loop
On 03/19/10 11:05, Steve Polyack wrote:
On 03/19/10 09:23, Steve Polyack wrote:
On 03/19/10 08:31, John Baldwin wrote:
On Friday 19 March 2010 7:34:23 am Steve Polyack wrote:
Hi, we use a FreeBSD 8-STABLE (from shortly after release) system
as an
NFS server to provide user home directories which get mounted across a
few machines (all 6.3-RELEASE). For the past few weeks we have been
running into problems where one particular client will go into an
infinite loop where it is repeatedly trying to write data which causes
the NFS server to return "reply ok 40 write ERROR: Input/output error
PRE: POST:". This retry loop can cause between 20mbps and 500mbps of
constant traffic on our network, depending on the size of the data
associated with the failed write.
Yes, your feeling is correct. This sort of race is inherent to NFS
if you do
not use some sort of locking protocol to resolve the race. The
infinite
retries sound like a client-side issue. Have you been able to try a
newer OS
version on a client to see if it still causes the same behavior?
I can't try a newer FBSD version on the client where we are seeing
the problems, but I can recreate the problem fairly easily. Perhaps
I'll try it with an 8.0 client. If I remember correctly, one of the
strange things is that it doesn't seem to hit "critical mass" until a
few hours after the operation first fails. I may be wrong, but I'll
double check that when I check vs. 8.0-release.
I forgot to add this in the first post, but these are all TCP NFS v3
mounts.
Thanks for the response.
Ok, so I'm still able to trigger what appears to be the same retry
loop with an 8.0-RELEASE nfsv3 client (going on 1.5 hours now):
$ cat nfs.sh
client#!/usr/local/bin/bash
for a in {1..15} ; do
sleep 1;
echo "$a$a$";
done
client$ ./nfs.sh >~/output
the on the server while the above is running:
server$ rm ~/output
What happens is that you will see 3-4 of the same write attempts
happen per minute via tcpdump. Our previous logs show that this is
how it starts, and then ~4 hours later it begins to spiral out of
control, throwing out up to 3,000 of the same failed write requests
per second.
To anyone who is interested: I did some poking around with DTrace, which
led me to the nfsiod client code.
In src/sys/nfsclient/nfs_nfsiod.c:
} else {
if (bp->b_iocmd == BIO_READ)
(void) nfs_doio(bp->b_vp, bp, bp->b_rcred, NULL);
else
(void) nfs_doio(bp->b_vp, bp, bp->b_wcred, NULL);
}
These two calls to nfs_doio trash the return codes (which are errors
cascading up from various other NFS write-related functions). I'm not
entirely familiar with the way nfsiod works, but if nfs_doio() or other
subsequent functions are supposed to be removing the current async NFS
operation from a queue which nfsiod handles, they are not doing so when
they encounter an error. They simply report the error back to the
caller, who in this case is not even looking at the value.
I've tested this by pushing the return code into a new int, errno, and
adding:
if (errno) {
NFS_DPF(ASYNCIO,
("nfssvc_iod: iod %d nfs_doio returned
errno: %d\n",
myiod, errno));
}
The result is that my problematic repeatable circumstance begins logging
"nfssvc_iod: iod 0 nfs_doio returned errno: 5" (corresponding to
NFSERR_INVAL?) for each repetition of the failed write. The only things
triggering this are my failed writes. I can also see the nfsiod0
process waking up each iteration.
Do we need some kind of "retry x times then abort" logic within
nfsiod_iod(), or does this belong in the subsequent functions, such as
nfs_doio()? I think it's best to avoid these sorts of infinite loops
which have the potential to take out the system or overload the network
due to dumb decisions made by unprivileged users.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri 19 Mar 2010 at 13:06:41 PDT Randal L. Schwartz wrote: "Charlie" == Charlie Kester writes: Charlie> Whenever I modify a port like this, I usually make a copy of it under Charlie> root's home directory and install it from there. That way, I can keep Charlie> my copy of the portstree in complete synch with the official one, and Charlie> there's no need to worry about updates quashing my changes. It also Charlie> provides a quick-and-dirty way to see which ports I've modified. Isn't that also what /usr/ports/local is for? I think so. Hopefully somebody more knowledgeable than me will confirm or deny. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri, Mar 19, 2010 at 4:18 PM, Paul Schmehl wrote: > --On Friday, March 19, 2010 13:01:30 -0700 Charlie Kester > wrote: >> >> Whenever I modify a port like this, I usually make a copy of it under >> root's home directory and install it from there. That way, I can keep >> my copy of the portstree in complete synch with the official one, and >> there's no need to worry about updates quashing my changes. It also >> provides a quick-and-dirty way to see which ports I've modified. >> > > To the O.P.: > > How about submiting the patch to the community so it can be added by the > port maintainer? If it actually fixes a bug in the software you can't be > the only one would benefit from the patch. > That was going to be my next question, but I am currently debugging to see why this common fix I've used in Linux is not not working on FBSD. The good news is that is blowing up in the same place, just that my quick and dirty patch is not working here. I submitted a bug this morning to the sane team to see what their official take is on this, and if I get it fixed temporarily for FBSD I will be sure to contact the port maintainer and send the patch. Is there a more formal way to submit patches to ports? or do I just figure out who the port maintainer is and send them patch directly? > -- > Paul Schmehl, Senior Infosec Analyst > As if it wasn't already obvious, my opinions > are my own and not those of my employer. > *** > "It is as useless to argue with those who have > renounced the use of reason as to administer > medication to the dead." Thomas Jefferson > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Samba read speed performance tuning
On a FreeBSD 8.0-RELEASE/amd64 system with a Supermicro X7SPA-H board using an Intel gigabit nic with the em driver, running on top of a ZFS mirror, I was seeing a strange issue. Local reads and writes to the pool easily saturate the disks with roughly 75mb/s throughput, which is roughly the best these drives can do. However, working with Samba, writes to a share could easily pull off 75mb/s and saturate the disks, but reads off a share were resulting in rather pathetic 18mb/s throughput. I found a threadon the FreeBSD forums (http://forums.freebsd.org/showthread.php?t=9187) and followed the suggested advice. I rebuilt Samba with AIO support, kldloaded the aio module and made the following changes to my smb.conf From: socket options=TCP_NODELAY To: socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY min receivefile size=16384 use sendfile=true aio read size = 16384 aio write size = 16384 aio write behind = true dns proxy = no[/CODE] This showed a very welcome improvement in read speed, I went from 18mb/s to 48mb/s. The write speed remained unchanged and was still saturating the disks. Now I tried the suggested sysctl tunables: atombsd# sysctl net.inet.tcp.delayed_ack=0 net.inet.tcp.delayed_ack: 1 -> 0 atombsd# sysctl net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.path_mtu_discovery: 1 -> 0 atombsd# sysctl net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.recvbuf_inc: 16384 -> 524288 atombsd# sysctl net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvbuf_max: 262144 -> 16777216 atombsd# sysctl net.inet.tcp.sendbuf_inc=524288 net.inet.tcp.sendbuf_inc: 8192 -> 524288 atombsd# sysctl net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendbuf_max: 262144 -> 16777216 atombsd# sysctl net.inet.tcp.sendspace=65536 net.inet.tcp.sendspace: 32768 -> 65536 atombsd# sysctl net.inet.udp.maxdgram=57344 net.inet.udp.maxdgram: 9216 -> 57344 atombsd# sysctl net.inet.udp.recvspace=65536 net.inet.udp.recvspace: 42080 -> 65536 atombsd# sysctl net.local.stream.recvspace=65536 net.local.stream.recvspace: 8192 -> 65536 atombsd# sysctl net.local.stream.sendspace=65536 net.local.stream.sendspace: 8192 -> 65536 This improved the read speeds a further tiny bit, now I went from 48mb/s to 54mb/s. This is it however, I can't figure out how to increase Samba read speed any further. Any ideas? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
--On Friday, March 19, 2010 17:04:17 -0400 Alejandro Imass wrote: To the O.P.: How about submiting the patch to the community so it can be added by the port maintainer? If it actually fixes a bug in the software you can't be the only one would benefit from the patch. That was going to be my next question, but I am currently debugging to see why this common fix I've used in Linux is not not working on FBSD. Ports can throw you for a loop if you're used to building from source. Others have given you good instructions on how to fix the problem, but here's a brief overview: 1) Go in to the port directory 2) Type make clean to remove any work directories 3) Type make extract - this extracts the tarball into the working directories that FreeBSD expects to find 4) Type make patch to apply any patches that the port maintainer has included 5) Enter the directory where the problem source file is - usually work/portname-version/some subdir 6) Copy it to filename.c.orig 7) Edit filename.c to include your changes 8) Diff the two files and put the resulting patch file in portdir/files (Note: If the file in question is already being patched by the port, you will need to apply your diff to file as well as the edits in the existing patch - doing that is not an exercise for the faint of heart. If that's the case here, respond and folks will help you sort it out.) 9) Edit the patch file (now in portdir/files) so that the first two lines "point" to the actual location of the file in the working directories. (For example, if the working directory has a subdir named "sc", and your file is in there, the first two lines of the patch would be edited thus: from filename.c to src/filename.c and from filename.c.orig to src/filename.c.orig 10) Return to the portdir and type make clean 11) Type make extract and then make patch - if it works, you should be able to do the install - if it doesn't work, post the errors here and we'll figure it out -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri 19 Mar 2010 at 14:34:23 PDT Paul Schmehl wrote: --On Friday, March 19, 2010 17:04:17 -0400 Alejandro Imass wrote: To the O.P.: How about submiting the patch to the community so it can be added by the port maintainer? If it actually fixes a bug in the software you can't be the only one would benefit from the patch. That was going to be my next question, but I am currently debugging to see why this common fix I've used in Linux is not not working on FBSD. Ports can throw you for a loop if you're used to building from source. Others have given you good instructions on how to fix the problem, but here's a brief overview: 1) Go in to the port directory 2) Type make clean to remove any work directories 3) Type make extract - this extracts the tarball into the working directories that FreeBSD expects to find 4) Type make patch to apply any patches that the port maintainer has included 'make patch' will also do the extract from the distfile, so you don't need your step 3 5) Enter the directory where the problem source file is - usually work/portname-version/some subdir 6) Copy it to filename.c.orig If the port maintainer has already patched filename.c, 'make patch' will already have created filename.c.orig 7) Edit filename.c to include your changes 8) Diff the two files and put the resulting patch file in portdir/files (Note: If the file in question is already being patched by the port, you will need to apply your diff to file as well as the edits in the existing patch - doing that is not an exercise for the faint of heart. If that's the case here, respond and folks will help you sort it out.) Not true. If the maintainer patched filename.c, 'make patch' will create filename.c.orig (which is the original author's file) and filename.c (which is the result of the maintainer's patches.) If you edit filename.c and then diff it from filename.c.orig, the result is a patch the includes your changes AND the maintainer's. 9) Edit the patch file (now in portdir/files) so that the first two lines "point" to the actual location of the file in the working directories. (For example, if the working directory has a subdir named "sc", and your file is in there, the first two lines of the patch would be edited thus: from filename.c to src/filename.c and from filename.c.orig to src/filename.c.orig No need for this if you do the diff from the top level of the working directory. I.e., if filename.c is in work/foo-x.y/bar/ you should cd to work/foo-x.y/ and then run diff -u bar/filename.c.orig bar/filename.c > ../../files/patch-filename.c 10) Return to the portdir and type make clean 11) Type make extract and then make patch - if it works, you should be able to do the install - if it doesn't work, post the errors here and we'll figure it out Again, no need for the separate 'make extract' step. In fact, I'd go straight to 'make build' or 'make install' here, and skip the separate 'make patch' too. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: How to set LD_PATH elegant?
In the last episode (Mar 19), O. Hartmann said: > I'm a little bit new to setting library paths, so sorry for the noise. > > I install some packages and libraries apart the FreeBSD package/ports > system and need to setup the search path for shared libraries the proper > way. > > At this very moment I 'hardcode' this additional search path by setting > > ldconfig_paths= > > in /etc/rc.conf, > > but since this is a 'system related' location I'm looking for a proper and > clean method setting this search path via environment variable and/or some > /usr/local/etc/rc.conf.add stuff or similar. Create a file in /usr/local/libdata/ldconfig/ containing the directories you want added to the ld search path. Call it something descriptive so you know what it's for. /etc/rc.d/ldconfig will process those files and run ldconfig on them on bootup. If you've installed zsh, mysql, or firefox from ports, you may already have a couple files in there. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
--On Friday, March 19, 2010 15:01:27 -0700 Charlie Kester wrote: Again, no need for the separate 'make extract' step. In fact, I'd go straight to 'make build' or 'make install' here, and skip the separate 'make patch' too. Thanks, Charles. You taught me something today. :-) -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri 19 Mar 2010 at 15:07:44 PDT Paul Schmehl wrote: --On Friday, March 19, 2010 15:01:27 -0700 Charlie Kester wrote: Again, no need for the separate 'make extract' step. In fact, I'd go straight to 'make build' or 'make install' here, and skip the separate 'make patch' too. Thanks, Charles. You taught me something today. :-) You're welcome. We're here to help. :) The main point I wanted to make was to run "make patch" BEFORE editing the port's sourcecode, so you don't lose the work done by the maintainer And you would lose that if you simply did "make extract" and then started hacking on the result. Or, what amounts to the same thing, if you grabbed the distfile and unzipped it into your home directory or somewhere. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD 8.0 Booting Problem on ZV5320US Laptop
Are you able to get to the FreeBSD splash screen (where you get a countdown to startup with a menu of 6 selections)? One of the choices there is boot w/o ACPI; you could try that if you get that far. Good luck-- Richard On Fri, Mar 19, 2010 at 11:55 AM, Anoop Kumar Narayanan wrote: > On Fri, Mar 19, 2010 at 7:49 PM, Richard DeLaurell > wrote: > >>On Fri, Mar 19, 2010 at 8:20 AM, Anoop Kumar Narayanan gmail.com>wrote: > >>I have recently installed FreeBSD8.0 on my 5 year old HP laptop with > >>absolute 0 battery backup (behaviour same when batter removed). > >>Installation works fine but when I try to boot into FreeBSD I get to > >>the BTX loader screen, after having made any selection and it pauses > >>for about 15 secs and the computer suddenly powers down. I was able to > >>boot into the system occasionally lets say about 1 in 5 boots. I am > >>able to install and boot into Linux without any problem. > > > > > > So then you are attempting to startup using a power adaptor (i.e. your > > computer is plugged in to a wall socket)? > Yes. I don't know if its a specific Athlon XP related problem as I did > observe a similar post some years ago. And, Apparently its the same > thing. > http://osdir.com/ml/os.freebsd.devel.hardware/2004-10/msg00044.html > In this case its the installation. In my case its after the installation. > > > > I had the reverse problem a while ago with Slackware shutting down in the > > middle of installation onto a Toshiba laptop while FreeBSD has always > been > > no problem. > > > > My guess is that these issues reflect power management settings, perhaps > > even something in the bios. > Maybe its something in the BIOS, but the thing is that Linux boots > fine on the machine. Maybe some driver is crashing and is causing a > reboot of the machine. Are there any critical drivers in the system > that can result in such a problem. > > > > Does this occur when you use the installation or boot-only disks? > I can install it just fine, but can't seem to to boot into the > installed version (Once its been installed). > I did create the FreeBSD swap partition before the root file-system > (and it still seems to label the root file-system as 'a'), Would this > affect the system boot up in anyway ? > > > > Sorry this is not more help to you. > > > > Richard > > ___ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" > > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
How to send a patch in a proper way?
Hi, As of today I'll try to help and create bugfix patches for usr/src and usr/ports. I've already done 2 patches and posted it to the -current list but don't really know what is the best way to post the patches. Who will "check" them? who will make the decision to use them? How should I send the patches? diff -u full path or relative path? Is there any FAQ about this issue? Thanks in advance, -- Adam PAPAI ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Kester wrote: > On Fri 19 Mar 2010 at 15:07:44 PDT Paul Schmehl wrote: >> --On Friday, March 19, 2010 15:01:27 -0700 Charlie Kester >> wrote: >>> >>> Again, no need for the separate 'make extract' step. >>> In fact, I'd go straight to 'make build' or 'make install' here, and >>> skip the separate 'make patch' too. >>> >> >> Thanks, Charles. You taught me something today. :-) > > You're welcome. We're here to help. :) > > The main point I wanted to make was to run "make patch" BEFORE > editing the port's sourcecode, so you don't lose the work done by > the maintainer > > And you would lose that if you simply did "make extract" and then > started hacking on the result. Or, what amounts to the same thing, if > you grabbed the distfile and unzipped it into your home directory or > somewhere. Here's something else that I've found really useful as a port creator, maintainer and troubleshooter. If I want to make some additional changes to a source file that is patched by a file stored in files/patch-, I'll do this: make patch # extracts source and patches files cd work/foobar/... # Now make additional edits in patched file, leaving the # .orig file alone cd ../back/to/port/directory make makepatch The makepatch target recurses through the work/foobar directory and creates diffs for all file.ext/file.ext.orig pairs. It writes them to the files/ directory with the patch- prefix on each so the patch target processes them. The only thing to watch out for here, is that makepatch has its own file naming convention that doesn't always mirror the port creator's. For instance, some ports have patch files named "patch-aa", "patch-ab", etc. The makepatch target will recreate them with filenames based on the directory and filename of the file to be patched during the build. Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLpAKV0sRouByUApARAjBOAJwLRfrND7Jky6egSVDkSuRiUdiOiACgqglr cGhgsIvFPnXzOMdVTAxWhOM= =T5+p -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: How to send a patch in a proper way?
On Fri 19 Mar 2010 at 15:20:49 PDT Adam PAPAI wrote: Hi, As of today I'll try to help and create bugfix patches for usr/src and usr/ports. I've already done 2 patches and posted it to the -current list but don't really know what is the best way to post the patches. Who will "check" them? who will make the decision to use them? How should I send the patches? diff -u full path or relative path? Is there any FAQ about this issue? For a general discussion about submitting bug reports (PR's), see http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/contrib-how.html#CONTRIB-GENERAL For PR's related to ports, see http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html Make sure that your PR uses the category "ports" and it will be reviewed by the ports committers. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Elegant way to hack port source
On Fri 19 Mar 2010 at 16:02:45 PDT Greg Larkin wrote: The makepatch target recurses through the work/foobar directory and creates diffs for all file.ext/file.ext.orig pairs. It writes them to the files/ directory with the patch- prefix on each so the patch target processes them. Now it's my turn to say "Thanks, you taught me something today!" -- Charlie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
shell script to cap first letter?
guys, i'm wondering if there is a script that i could run my plaintext files thru that would capitalize thef first letter of each sentence [[ assuming the character wasn't already a cap!]] more and more, in recent years, i have posted questions or written things that have been sloppily or casually hacked together in all lower case. this filter would have to determine what was and was not a sentence. or a sentence fragment. [ai]spell can catch "i've" and suggest "I've", etc. ideas? -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 7.79a release of Jottings: http://jottings.thought.org/index.php ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD NFS client goes into infinite retry loop
On Fri, 19 Mar 2010, John Baldwin wrote:
On Friday 19 March 2010 7:34:23 am Steve Polyack wrote:
Hi, we use a FreeBSD 8-STABLE (from shortly after release) system as an
NFS server to provide user home directories which get mounted across a
few machines (all 6.3-RELEASE). For the past few weeks we have been
running into problems where one particular client will go into an
infinite loop where it is repeatedly trying to write data which causes
the NFS server to return "reply ok 40 write ERROR: Input/output error
PRE: POST:". This retry loop can cause between 20mbps and 500mbps of
I'm afraid I don't quite understand what you mean by "causes the NFS
server to return "reply ok 40 write ERROR..."". Is this something
logged by syslog (I can't find a printf like this in the kernel
sources) or is this something that tcpdump is giving you or ???
Why I ask is that it seems to say that the server is returning EIO
(or maybe 40 == EMSGSIZE).
The server should return ESTALE (NFSERR_STALE) after a file has
been deleted. If it is returning EIO, then that will cause the
client to keep trying to write the dirty block to the server.
(EIO is interpreted by the client as a "transient error".)
[good stuff snipped]
I have a feeling that using NFS in such a matter may simply be prone to
such problems, but what confuses me is why the NFS client system is
infinitely retrying the write operation and causing itself so much grief.
Yes, your feeling is correct. This sort of race is inherent to NFS if you do
not use some sort of locking protocol to resolve the race. The infinite
retries sound like a client-side issue. Have you been able to try a newer OS
version on a client to see if it still causes the same behavior?
As John notes, having one client delete a file while another is trying
to write it, is not a good thing.
However, the server should return ESTALE after the file is deleted and
that tells the client that the write can never succeed, so it marks the
buffer cache block invalid and returns the error to the app. (The app.
may not see it, if it doesn't check for error returns upon close as well
as write, but that's another story...)
If you could look at a packet trace via wireshark when the problem
occurs, it would be nice to see what the server is returning. (If it
isn't ESTALE and the file no longer exists on the server, then thats
a server problem.) If it is returning ESTALE, then the client is busted.
(At a glance, the client code looks like it would handle ESTALE as a
fatal error for the buffer cache, but that doesn't mean it isn't broken,
just that it doesn't appear wrong. Also, it looks like mmap'd writes
won't recognize a fatal write error and will just keep trying to write
the dirty page back to the server. Take this with a big grain of salt,
since I just took a quick look at the sources. FreeBSD6->8 appear to
be pretty much the same as far as this goes, in the client.
Please let us know if you can see the server's error reply code.
Good luck with it, rick
ps: If the server isn't returning ESTALE, you could try switching to
the experimental nfs server and see if it exhibits the same behaviour?
("-e" option on both mountd and nfsd, assuming the server is
FreeBSD8.)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD NFS client goes into infinite retry loop
On Fri, 19 Mar 2010, Steve Polyack wrote:
To anyone who is interested: I did some poking around with DTrace, which led
me to the nfsiod client code.
In src/sys/nfsclient/nfs_nfsiod.c:
} else {
if (bp->b_iocmd == BIO_READ)
(void) nfs_doio(bp->b_vp, bp, bp->b_rcred, NULL);
else
(void) nfs_doio(bp->b_vp, bp, bp->b_wcred, NULL);
}
If you look t nfs_doio(), it decides whether or not to mark the buffer
invalid, based on the return value it gets. Some (EINTR, ETIMEDOUT, EIO)
are not considered fatal, but the others are. (When the async I/O
daemons call nfs_doio(), they are threads that couldn't care less if
the underlying I/O op succeeded. The outcome of the I/O operation
determines what nfs_doio() does with the buffer cache block.)
The result is that my problematic repeatable circumstance begins logging
"nfssvc_iod: iod 0 nfs_doio returned errno: 5" (corresponding to
NFSERR_INVAL?) for each repetition of the failed write. The only things
triggering this are my failed writes. I can also see the nfsiod0 process
waking up each iteration.
Nope, errno 5 is EIO and that's where the problem is. I don't know why
the server is returning EIO after the file has been deleted on the
server (I assume you did that when running your little shell script?).
Do we need some kind of "retry x times then abort" logic within nfsiod_iod(),
or does this belong in the subsequent functions, such as nfs_doio()? I think
it's best to avoid these sorts of infinite loops which have the potential to
take out the system or overload the network due to dumb decisions made by
unprivileged users.
Nope, people don't like data not getting written back to a server when
it is slow or temporarily network partitioned. The only thing that should
stop a client from retrying a write back to the server is a fatal error
from the server that says "this won't ever succeed".
I think we need to figure out if the EIO (NFS3ERR_IO in wireshark) or
if the server is sending NFS3ERR_STALE and the client is somehow munging
that into EIO, causing the confusion.
rick
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Samba read speed performance tuning
On Fri, Mar 19, 2010 at 11:14 PM, Dan Naumov wrote: > On a FreeBSD 8.0-RELEASE/amd64 system with a Supermicro X7SPA-H board > using an Intel gigabit nic with the em driver, running on top of a ZFS > mirror, I was seeing a strange issue. Local reads and writes to the > pool easily saturate the disks with roughly 75mb/s throughput, which > is roughly the best these drives can do. However, working with Samba, > writes to a share could easily pull off 75mb/s and saturate the disks, > but reads off a share were resulting in rather pathetic 18mb/s > throughput. > > I found a threadon the FreeBSD forums > (http://forums.freebsd.org/showthread.php?t=9187) and followed the > suggested advice. I rebuilt Samba with AIO support, kldloaded the aio > module and made the following changes to my smb.conf > > From: > socket options=TCP_NODELAY > > To: > socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY > min receivefile size=16384 > use sendfile=true > aio read size = 16384 > aio write size = 16384 > aio write behind = true > dns proxy = no[/CODE] > > This showed a very welcome improvement in read speed, I went from > 18mb/s to 48mb/s. The write speed remained unchanged and was still > saturating the disks. Now I tried the suggested sysctl tunables: > > atombsd# sysctl net.inet.tcp.delayed_ack=0 > net.inet.tcp.delayed_ack: 1 -> 0 > > atombsd# sysctl net.inet.tcp.path_mtu_discovery=0 > net.inet.tcp.path_mtu_discovery: 1 -> 0 > > atombsd# sysctl net.inet.tcp.recvbuf_inc=524288 > net.inet.tcp.recvbuf_inc: 16384 -> 524288 > > atombsd# sysctl net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvbuf_max: 262144 -> 16777216 > > atombsd# sysctl net.inet.tcp.sendbuf_inc=524288 > net.inet.tcp.sendbuf_inc: 8192 -> 524288 > > atombsd# sysctl net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendbuf_max: 262144 -> 16777216 > > atombsd# sysctl net.inet.tcp.sendspace=65536 > net.inet.tcp.sendspace: 32768 -> 65536 > > atombsd# sysctl net.inet.udp.maxdgram=57344 > net.inet.udp.maxdgram: 9216 -> 57344 > > atombsd# sysctl net.inet.udp.recvspace=65536 > net.inet.udp.recvspace: 42080 -> 65536 > > atombsd# sysctl net.local.stream.recvspace=65536 > net.local.stream.recvspace: 8192 -> 65536 > > atombsd# sysctl net.local.stream.sendspace=65536 > net.local.stream.sendspace: 8192 -> 65536 > > This improved the read speeds a further tiny bit, now I went from > 48mb/s to 54mb/s. This is it however, I can't figure out how to > increase Samba read speed any further. Any ideas? Oh my god... Why did noone tell me how much of an enormous performance boost vfs.zfs.prefetch_disable=0 (aka actually enabling prefetch) is. My local reads off the mirror pool jumped from 75mb/s to 96mb/s (ie. they are now nearly 25% faster than reading off an individual disk) and reads off a Samba share skyrocketed from 50mb/s to 90mb/s. By default, FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386 systems and on any amd64 systems with less than 4GB of avaiable memory. My system is amd64 with 4gb ram, but integrated video eats some of that, so the autotuning disabled the prefetch. I had read up on it and a fair amount of people seemed to have performance issues caused by having prefetch enabled and get better results with it turned off, in my case however, it seems that enabling it gave a really solid boost to performance. - Sincerely Dan Naumov ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Samba read speed performance tuning
It MAY make a big diff, but make sure during your tests you use unique files or flush the cache or you'll me testing cache speed and not disk speed. - Original Message - From: owner-freebsd-questi...@freebsd.org To: freebsd-...@freebsd.org ; freebsd-questions@freebsd.org ; FreeBSD-STABLE Mailing List ; freebsd-performa...@freebsd.org Sent: Fri Mar 19 20:28:02 2010 Subject: Re: Samba read speed performance tuning On Fri, Mar 19, 2010 at 11:14 PM, Dan Naumov wrote: > On a FreeBSD 8.0-RELEASE/amd64 system with a Supermicro X7SPA-H board > using an Intel gigabit nic with the em driver, running on top of a ZFS > mirror, I was seeing a strange issue. Local reads and writes to the > pool easily saturate the disks with roughly 75mb/s throughput, which > is roughly the best these drives can do. However, working with Samba, > writes to a share could easily pull off 75mb/s and saturate the disks, > but reads off a share were resulting in rather pathetic 18mb/s > throughput. > > I found a threadon the FreeBSD forums > (http://forums.freebsd.org/showthread.php?t=9187) and followed the > suggested advice. I rebuilt Samba with AIO support, kldloaded the aio > module and made the following changes to my smb.conf > > From: > socket options=TCP_NODELAY > > To: > socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY > min receivefile size=16384 > use sendfile=true > aio read size = 16384 > aio write size = 16384 > aio write behind = true > dns proxy = no[/CODE] > > This showed a very welcome improvement in read speed, I went from > 18mb/s to 48mb/s. The write speed remained unchanged and was still > saturating the disks. Now I tried the suggested sysctl tunables: > > atombsd# sysctl net.inet.tcp.delayed_ack=0 > net.inet.tcp.delayed_ack: 1 -> 0 > > atombsd# sysctl net.inet.tcp.path_mtu_discovery=0 > net.inet.tcp.path_mtu_discovery: 1 -> 0 > > atombsd# sysctl net.inet.tcp.recvbuf_inc=524288 > net.inet.tcp.recvbuf_inc: 16384 -> 524288 > > atombsd# sysctl net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvbuf_max: 262144 -> 16777216 > > atombsd# sysctl net.inet.tcp.sendbuf_inc=524288 > net.inet.tcp.sendbuf_inc: 8192 -> 524288 > > atombsd# sysctl net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendbuf_max: 262144 -> 16777216 > > atombsd# sysctl net.inet.tcp.sendspace=65536 > net.inet.tcp.sendspace: 32768 -> 65536 > > atombsd# sysctl net.inet.udp.maxdgram=57344 > net.inet.udp.maxdgram: 9216 -> 57344 > > atombsd# sysctl net.inet.udp.recvspace=65536 > net.inet.udp.recvspace: 42080 -> 65536 > > atombsd# sysctl net.local.stream.recvspace=65536 > net.local.stream.recvspace: 8192 -> 65536 > > atombsd# sysctl net.local.stream.sendspace=65536 > net.local.stream.sendspace: 8192 -> 65536 > > This improved the read speeds a further tiny bit, now I went from > 48mb/s to 54mb/s. This is it however, I can't figure out how to > increase Samba read speed any further. Any ideas? Oh my god... Why did noone tell me how much of an enormous performance boost vfs.zfs.prefetch_disable=0 (aka actually enabling prefetch) is. My local reads off the mirror pool jumped from 75mb/s to 96mb/s (ie. they are now nearly 25% faster than reading off an individual disk) and reads off a Samba share skyrocketed from 50mb/s to 90mb/s. By default, FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386 systems and on any amd64 systems with less than 4GB of avaiable memory. My system is amd64 with 4gb ram, but integrated video eats some of that, so the autotuning disabled the prefetch. I had read up on it and a fair amount of people seemed to have performance issues caused by having prefetch enabled and get better results with it turned off, in my case however, it seems that enabling it gave a really solid boost to performance. - Sincerely Dan Naumov ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Samba read speed performance tuning
On Fri, Mar 19, 2010 at 8:28 PM, Dan Naumov wrote: > Oh my god... Why did noone tell me how much of an enormous performance > boost vfs.zfs.prefetch_disable=0 (aka actually enabling prefetch) is. > My local reads off the mirror pool jumped from 75mb/s to 96mb/s (ie. > they are now nearly 25% faster than reading off an individual disk) > and reads off a Samba share skyrocketed from 50mb/s to 90mb/s. > > By default, FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386 > systems and on any amd64 systems with less than 4GB of avaiable > memory. My system is amd64 with 4gb ram, but integrated video eats > some of that, so the autotuning disabled the prefetch. I had read up > on it and a fair amount of people seemed to have performance issues > caused by having prefetch enabled and get better results with it > turned off, in my case however, it seems that enabling it gave a > really solid boost to performance. > My home VBox server is similar specs and I enabled the prefetch from the start. A few days ago, I added an intel SSD as the zpool cache device and the read speed is mind blowing now. This is from inside a VM frunning on it meaning ad0 is really a vdi. Once the cache is populated, HD latency is mostly a thing of the past. # diskinfo -tv /dev/ad0 /dev/ad0 512 # sectorsize 12884901888 # mediasize in bytes (12G) 25165824# mediasize in sectors 24966 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. VBf9752473-05343e4e # Disk ident. Seek times: Full stroke: 250 iter in 0.082321 sec =0.329 msec Half stroke: 250 iter in 0.078944 sec =0.316 msec Quarter stroke: 500 iter in 0.161266 sec =0.323 msec Short forward:400 iter in 0.128624 sec =0.322 msec Short backward: 400 iter in 0.131770 sec =0.329 msec Seq outer: 2048 iter in 0.667510 sec =0.326 msec Seq inner: 2048 iter in 0.691691 sec =0.338 msec Transfer rates: outside: 102400 kbytes in 0.722864 sec = 141659 kbytes/sec middle:102400 kbytes in 0.813619 sec = 125857 kbytes/sec inside:102400 kbytes in 0.838129 sec = 122177 kbytes/sec -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD NFS client goes into infinite retry loop
On 3/19/2010 9:32 PM, Rick Macklem wrote:
On Fri, 19 Mar 2010, Steve Polyack wrote:
To anyone who is interested: I did some poking around with DTrace,
which led me to the nfsiod client code.
In src/sys/nfsclient/nfs_nfsiod.c:
} else {
if (bp->b_iocmd == BIO_READ)
(void) nfs_doio(bp->b_vp, bp, bp->b_rcred, NULL);
else
(void) nfs_doio(bp->b_vp, bp, bp->b_wcred, NULL);
}
If you look t nfs_doio(), it decides whether or not to mark the buffer
invalid, based on the return value it gets. Some (EINTR, ETIMEDOUT, EIO)
are not considered fatal, but the others are. (When the async I/O
daemons call nfs_doio(), they are threads that couldn't care less if
the underlying I/O op succeeded. The outcome of the I/O operation
determines what nfs_doio() does with the buffer cache block.)
I was looking at this and noticed the above after my last post.
The result is that my problematic repeatable circumstance begins
logging "nfssvc_iod: iod 0 nfs_doio returned errno: 5" (corresponding
to NFSERR_INVAL?) for each repetition of the failed write. The only
things triggering this are my failed writes. I can also see the
nfsiod0 process waking up each iteration.
Nope, errno 5 is EIO and that's where the problem is. I don't know why
the server is returning EIO after the file has been deleted on the
server (I assume you did that when running your little shell script?).
Yes, while running the simple shell script I simply deleted the file on
the NFS server itself.
Do we need some kind of "retry x times then abort" logic within
nfsiod_iod(), or does this belong in the subsequent functions, such
as nfs_doio()? I think it's best to avoid these sorts of infinite
loops which have the potential to take out the system or overload the
network due to dumb decisions made by unprivileged users.
Nope, people don't like data not getting written back to a server when
it is slow or temporarily network partitioned. The only thing that should
stop a client from retrying a write back to the server is a fatal error
from the server that says "this won't ever succeed".
I think we need to figure out if the EIO (NFS3ERR_IO in wireshark) or
if the server is sending NFS3ERR_STALE and the client is somehow munging
that into EIO, causing the confusion.
This makes sense. According to wireshark, the server is indeed
transmitting "Status: NFS3ERR_IO (5)". Perhaps this should be STALE
instead; it sounds more correct than marking it a general IO error.
Also, the NFS server is serving its share off of a ZFS filesystem, if it
makes any difference. I suppose ZFS could be talking to the NFS server
threads with some mismatched language, but I doubt it.
Thanks for the informative response,
Steve
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD NFS client goes into infinite retry loop
On Fri, 19 Mar 2010, Steve Polyack wrote: [good stuff snipped] This makes sense. According to wireshark, the server is indeed transmitting "Status: NFS3ERR_IO (5)". Perhaps this should be STALE instead; it sounds more correct than marking it a general IO error. Also, the NFS server is serving its share off of a ZFS filesystem, if it makes any difference. I suppose ZFS could be talking to the NFS server threads with some mismatched language, but I doubt it. Ok, now I think we're making progress. If VFS_FHTOVP() doesn't return ESTALE when the file no longer exists, the NFS server returns whatever error it has returned. So, either VFS_FHTOVP() succeeds after the file has been deleted, which would be a problem that needs to be fixed within ZFS OR ZFS returns an error other than ESTALE when it doesn't exist. Try the following patch on the server (which just makes any error returned by VFS_FHTOVP() into ESTALE) and see if that helps. --- nfsserver/nfs_srvsubs.c.sav 2010-03-19 22:06:43.0 -0400 +++ nfsserver/nfs_srvsubs.c 2010-03-19 22:07:22.0 -0400 @@ -1127,6 +1127,8 @@ } } error = VFS_FHTOVP(mp, &fhp->fh_fid, vpp); + if (error != 0) + error = ESTALE; vfs_unbusy(mp); if (error) goto out; Please let me know if the patch helps, rick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
