RELENG_8 still identifies itself as 8.3-PRERELEASE
A RELENG_8 system built this morning still identifies itself as 8.3-PRERELEASE. Any chance of this becoming 8.3-STABLE soon? While this is entirely cosmetic, it does cause me issues at $JOB. -- Adrian Wontroba A fool and his money soon go partying. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 still identifies itself as 8.3-PRERELEASE
On Sun, Apr 22, 2012 at 10:39:44PM +, Bjoern A. Zeeb wrote: On 22. Apr 2012, at 21:59 , Adrian Wontroba wrote: A RELENG_8 system built this morning still identifies itself as 8.3-PRERELEASE. Any chance of this becoming 8.3-STABLE soon? While this is entirely cosmetic, it does cause me issues at $JOB. Fixed. Thanks! Thanks also for the suggestions from others. -- Adrian Wontroba ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.0-RELEASE ISO images vanished?
I could have sworn that 9.0 ISO images were on ftp.freebsd.org and mirrors, but: Remote directory: /pub/FreeBSD/releases/i386/ISO-IMAGES ftp dir 229 Entering Extended Passive Mode (|||29551|). 150 Here comes the directory listing. drwxrwxr-x2 980 100 512 Mar 22 2010 7.3 drwxrwxr-x2 980 100 512 Feb 20 2011 7.4 drwxrwxr-x2 980 100 512 Jul 19 2010 8.1 drwxrwxr-x2 980 100 512 Feb 20 2011 8.2 drwxrwxr-x2 980 100 512 Mar 05 13:55 8.3 -rw-rw-r--1 2035 100 1121 Dec 19 2005 README.TXT 226 Directory send OK. I'm OK as I torrented the ISOs when 9.0 was released. -- Adrian Wontroba The hidden flaw never remains hidden. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.0-RELEASE ISO images vanished?
On Thu, Mar 08, 2012 at 06:09:07AM +, Adrian Wontroba wrote: I could have sworn that 9.0 ISO images were on ftp.freebsd.org and mirrors, but: Remote directory: /pub/FreeBSD/releases/i386/ISO-IMAGES ftp dir 229 Entering Extended Passive Mode (|||29551|). 150 Here comes the directory listing. drwxrwxr-x2 980 100 512 Mar 22 2010 7.3 drwxrwxr-x2 980 100 512 Feb 20 2011 7.4 drwxrwxr-x2 980 100 512 Jul 19 2010 8.1 drwxrwxr-x2 980 100 512 Feb 20 2011 8.2 drwxrwxr-x2 980 100 512 Mar 05 13:55 8.3 -rw-rw-r--1 2035 100 1121 Dec 19 2005 README.TXT 226 Directory send OK. Ah, found them: Remote directory: /pub/FreeBSD/releases/i386/i386/ISO-IMAGES/9.0 ftp dir 229 Entering Extended Passive Mode (|||42984|). 150 Here comes the directory listing. -rw-r--r--1 980 100 309 Jan 06 23:44 CHECKSUM.MD5 -rw-r--r--1 980 100 449 Jan 06 23:46 CHECKSUM.SHA256 -rw-r--r--1 980 100 134739968 Jan 03 07:51 FreeBSD-9.0-RELEASE-i386-bootonly.iso -rw-r--r--1 980 100 526215168 Jan 03 07:50 FreeBSD-9.0-RELEASE-i386-disc1.iso -rw-r--r--1 980 100 2244231168 Jan 06 23:41 FreeBSD-9.0-RELEASE-i386-dvd1.iso -rw-r--r--1 980 100 560898048 Jan 03 07:51 FreeBSD-9.0-RELEASE-i386-memstick.img 226 Directory send OK. I still seem to recall /pub/FreeBSD/releases/i386/ISO-IMAGES/9.0 existing. -- Adrian Wontroba Everything takes longer than you expect. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sat, Oct 15, 2011 at 10:45:18PM +0300, Mikolaj Golub wrote: On Sat, 15 Oct 2011 11:50:22 +0200 Stefan Bethke wrote: SB Seems to do the trick, thanks! Thanks for testing! Committed. I am going to MFC it soon. Gentlemen, thank you! I can confirm that at $JOB with a RELENG_8 system post the MFC, script no longer hangs when run via batch nor consumes excessive amounts of CPU. -- Adrian Wontroba You are not drunk if you can lay on the floor without holding on. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sat, Oct 08, 2011 at 01:27:07AM +0100, Adrian Wontroba wrote: I won't be in a position to create a simpler test case, raise a PR or try patches till Tuesday evening (UK) at the earliest. So far I have been unable to reproduce the problem with portupgrade (and will probably move to portmaster). I have however found a different but possibly related problem with the new version of script in RELENG_8, for which I have raised this PR: misc/161526: script outputs corrupt if input is not from a terminal Blast, should of course been bin/ -- Adrian Wontroba In any bureaucracy, paperwork increases as you spend more and more time reporting on the less and less you are doing. Stability is achieved when you spend all of your time reporting on the nothing you are doing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Tue, Oct 04, 2011 at 02:15:24PM +0300, Mikolaj Golub wrote: For the record. The issue has been fixed in CURRENT and the fix has been merged to STABLE. At $JOB with a recent version of RELENG_8 and the new script (1.24.30.5 2011/10/04 11:08:31 trociny) I am getting hangs (system close to idle) when running a batch job which calls portupgrade. I had two hangs, in different places, while upgrading the first package. Process trees below. Reverting to an older version of script (1.24.30.4 2010/10/14 01:21:44 obrien) showed the 100% processor utilisation problem, but at least my package build from source is running. I won't be in a position to create a simpler test case, raise a PR or try patches till Tuesday evening (UK) at the earliest. hang 1 daemon 1997 0.0 0.1 3420 1152 ?? I 7:16PM 0:00.01 |-- /usr/libexec/atrun root1998 0.0 0.1 3676 1192 ?? IN7:16PM 0:00.01 | `-- sh root1999 0.0 0.1 3676 1408 ?? IN7:16PM 0:00.01 | `-- /bin/sh -e /usr/local/rjis/bin/fbsd_upgrade.sh build_packages_all root2003 0.0 0.1 3676 1420 ?? IN7:16PM 0:00.01 | |-- /bin/sh -e /usr/local/rjis/bin/fbsd_upgrade.sh build_packages_all root 71608 0.0 0.1 3676 1360 ?? IN8:19PM 0:00.02 | | `-- /bin/sh -e /usr/local/rjis/bin/fbsd_upgrade.sh build_portupgrade --all --force root 71612 0.0 0.1 3676 1364 ?? IN8:19PM 0:00.01 | | |-- /bin/sh -e /usr/local/rjis/bin/fbsd_upgrade.sh build_portupgrade --all --force root 71619 0.0 3.4 43832 34820 ?? IN8:19PM 0:13.37 | | | `-- ruby18: portupgrade: [1/280] jpeg-8_3 (ruby18) root 75064 0.0 0.1 3356 800 ?? IN8:20PM 0:00.10 | | | `-- /usr/bin/script -qa /tmp/portupgrade20111007-71619-1ozbl8u-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=jpeg-8_3 UPGRADE_PORT_VER=8_3 make BATCH=yes FETCH_BEFORE_ARGS=-q DEPENDS_TARGET=package root 75065 0.0 0.1 2912 1236 3 INs+ 8:20PM 0:00.08 | | | `-- make BATCH=yes FETCH_BEFORE_ARGS=-q DEPENDS_TARGET=package root 75182 0.0 0.1 3676 1180 3 IN+ 8:20PM 0:00.01 | | | `-- [sh] root 75348 0.0 0.1 3676 1352 3 IN+ 8:20PM 0:00.35 | | | `-- /bin/sh ./configure --enable-shared --enable-static --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=i386-portbld-freebsd8.2 root 76047 0.0 0.1 3296 756 3 IN+ 8:20PM 0:00.00 | | | `-- printf %s checking whether to enable maintainer-specific portions of Makefiles... root 71613 0.0 0.1 3296 668 ?? IN8:19PM 0:00.01 | | `-- tee /home/fbsd_upgrade/build_portupgrade.log root2004 0.0 0.1 3296 712 ?? IN7:16PM 0:00.05 | `-- tee /home/fbsd_upgrade/build_packages_all.log hang 2 root 76284 0.0 0.1 3676 1160 ?? IN8:49PM 0:00.01 | `-- sh root 76285 0.0 0.1 3676 1372 ?? IN8:49PM 0:00.01 | `-- /bin/sh -e /usr/local/rjis/bin/fbsd_upgrade.sh build_packages_all root 76289 0.0 0.1 3676 1372 ?? IN8:49PM 0:00.01 | |-- /bin/sh -e /usr/local/rjis/bin/fbsd_upgrade.sh build_packages_all root 45880 0.0 0.1 3676 1368 ?? IN9:18PM 0:00.02 | | `-- /bin/sh -e /usr/local/rjis/bin/fbsd_upgrade.sh build_portupgrade --all --force root 45884 0.0 0.1 3676 1372 ?? IN9:18PM 0:00.01 | | |-- /bin/sh -e /usr/local/rjis/bin/fbsd_upgrade.sh build_portupgrade --all --force root 45891 0.0 3.5 43832 35812 ?? IN9:18PM 0:13.27 | | | `-- ruby18: portupgrade: [1/280] jpeg-8_3 (ruby18) root 49313 0.0 0.1 3356 804 ?? IN9:19PM 0:00.10 | | | `-- /usr/bin/script -qa /tmp/portupgrade20111007-45891-b2jn17-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=jpeg-8_3 UPGRADE_PORT_VER=8_3 make BATCH=yes FETCH_BEFORE_ARGS=-q clean root 49314 0.0 0.1 2912 1124 3- INEs+ 9:19PM 0:00.06 | | | `-- make BATCH=yes FETCH_BEFORE_ARGS=-q clean root 45885 0.0 0.1 3296 668 ?? IN9:18PM 0:00.01 | | `-- tee /home/fbsd_upgrade/build_portupgrade.log root 76290 0.0 0.1 3296 668 ?? IN8:49PM 0:00.03 | `-- tee /home/fbsd_upgrade/build_packages_all.log -- Adrian Wontroba When in trouble, obfuscate. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: umass: AutoSense failed
On Fri, Dec 10, 2010 at 09:40:05AM -0500, Paul Mather wrote: (reformatted) I get something similar to this happening on 8.2-PRERELEASE. In my case, it's not during boot probing or device attachment. Instead, it happens occasionally after boot. The devices concerned are Maxtor OneTouch external USB hard drives. Every now and then, I will get something akin to the following crop up in the console log: (da1:umass-sim1:1:0:0): AutoSense failed I have three of these Maxtor OneTouch drives attached to the system as part of a ZFS pool. When I get an AutoSense failed message, it is usually accompanied by the ZFS pool being marked as faulted. The Maxtor OneTouch drives are wont to spin down and go into a deep sleep after a period of inactivity and appear very slow to wake up again when I/O occurs. I have always assumed that the AutoSense failed is associated with this---that there is some kind of timeout in the FreeBSD stack that this device is exceeding. In fact, sometimes the devices fail to probe properly during boot when they are asleep. This is what the OneTouch normally probes as: da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 : Maxtor OneTouch 0121 da0Fixed Direct Access SCSI-4 device : 40.000MB/s transfers : 953869MB da0(1953525168 512 byte sectors: 255H 63S/T 121601C) Cheers, Paul. I had this happen while backing up to two successive previously reliable UFS USB external disk drives. Plugging the USB cable into a motherboard USB socket at the back of the computer rather than a front panel socket made the problem go away. This might cure the OP's problem too. -- Adrian Wontroba If it weren't for the opinion polls we'd never know what people are undecided about. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8-STABLE Slow Write Speeds on ESXI 4.0
On Mon, Aug 09, 2010 at 09:11:24AM -0700, Jeremy Chadwick wrote: FWIW, Workstation 7.1 is fairly adamant about stating if you want faster disk I/O, pre-allocate the disk space rather than let disk use grow dynamically. I've never tested this however. Anecdotal, as I have no comparative performance figures to hand, but under VMware Server 2 on Windows, performance of non pre-allocated disks is dire and SCSI emulation is better than IDE. -- Adrian Wontroba Anything hit with a big enough hammer will fall apart. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Wed, Jan 27, 2010 at 12:25:58PM +0100, Dimitry Andric wrote: On 2010-01-27 00:15, Dan Naumov wrote: Sorry to bump into this thread so late, but for some of my servers I have been using a patch for atacontrol, to turn the APM features of the disk(s) off, for a long time. This is mostly noticable with 2.5 notebook disks, which click like crazy all the time. :) Turning off APM seems to be the LINUX world's solution to this and other similar problems. I got the impression that Windows also does this. -- Adrian Wontroba Save energy: be apathetic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Wed, Jan 27, 2010 at 01:15:17AM +0200, Dan Naumov wrote:
Can anyone confirm that using the WDIDLE3 utility on the 2TB WD20EADS
discs will not cause any issues if these disks are part of a ZFS
mirror pool? I do have backups of data, but I would rather not spend
the time rebuilding the entire system and restoring enormous amounts
of data over a 100mbit network unless I absolutely have to :)
How about using the write every 5 seconds python script posted earlier
in this thread by e...@tefre.com? Works nicely for me and stops the load
cycle count increase.
Thank you Erik!
To save searching, here is Erik's script as used here.
#!/usr/local/bin/python
# Author: Erik Stian Tefre e...@tefre.com
#Keeping this python script running prevents Load_Cycle_Count from
#incrementing on my WD15EADS drives by forcing a write every 5 seconds (2
#drive zfs mirror pool, average of 2 load cycles per minute when the
#script is not running):
import time,os
mypool = /tank
# ^^ Change to your pool!
fname = os.path.join(mypool, wd_green_anti_idle.pyfile)
c = 0
f = open(fname, w)
while True:
if c == 100:
f.close()
f = open(fname, w)
c = 0
c += 1
time.sleep(5)
f.write(a)
f.flush()
os.fsync(f.fileno())
You might find this handy too:
#!/bin/sh
# $FreeBSD:$
# PROVIDE: wd_green_anti_idle
# REQUIRE: LOGIN
. /etc/rc.subr
wd_green_anti_idle_enable=${wd_green_anti_idle_enable-NO}
name=wd_green_anti_idle
rcvar=`set_rcvar`
command=/usr/local/stade/bin/wd_green_anti_idle.py
start_cmd=wd_green_anti_idle_start
wd_green_anti_idle_start()
{
if ! checkyesno wd_green_anti_idle_enable ; then
return 0
fi
echo Starting ${name}.
${command}
}
load_rc_config $name
run_rc_command $*
Adjust command name to suit, put in /usr/local/etc/rc.d, add
wd_green_anti_idle_enable=YES to /etc/rc.conf and the script starts
running during startup. A minor bug - it doesn't close down.
--
Adrian Wontroba
A witty saying proves nothing, but saying something pointless gets
people's attention.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, Jan 26, 2010 at 07:49:05PM -0500, Damian Gerow wrote: Specific cases aside, writing to the FS is a workaround to a rather inconvenient issue. I, too, would like to see if the problem is fixed, not avoided, by using wdidle -- but I suspect I'll have to contact WD myself to get that confirmation. A convenient workaround indeed. Much easier than running DOS (I assume) firmware twidding programs or firmware updates. As for wdidle - see the tail end of http://www.readynas.com/forum/viewtopic.php?f=24t=32179. Sufficient customer complaints might produce a real firmware fix. One thing I'm sure of - the next time I buy a set of disks for my home fileserver, I'll spend some time on research rather than rushing to join the queue (8-( -- Adrian Wontroba I'd rather just believe that it's done by little elves running around. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RELEASE - -STABLE and size of /
On Fri, Jan 22, 2010 at 05:21:56PM +0100, Oliver Brandmueller wrote: I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default 512M. First step after setup was to csup to RELENG_8 and buildkernel and buildworld (no custom kernel, no make.conf). Instaling the new kernel failed, since /boot/kernel/ is already well over 230 MBytes in size. moving that to kernel.old and writing a new one with about the same size fails due to no space left on device. This is not a question; I do know how to get around this and how to configure custom kernels so they are a fragment of that size afterwards. However, I think this is a clear POLA violation. So, either GENERIC with less debugging information (symbols and stuff), which makes debugging harder or setting a higher default for / would be options, if not anyone else has better ideas. /usr/src/UPDATING has this which will allow you to remove symbols when installing a kernel: 20060118: This actually occured some time ago, but installing the kernel now also installs a bunch of symbol files for the kernel modules. This increases the size of /boot/kernel to about 67Mbytes. You will need twice this if you will eventually back this up to kernel.old on your next install. If you have a shortage of room in your root partition, you should add -DINSTALL_NODEBUG to your make arguments or add INSTALL_NODEBUG=yes to your /etc/make.conf. I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a surprise. An i386 kernel is a mere 135 MB. IMO increasing the sysinstall default root slice size for at least amd64 would be a good thing. -- Adrian Wontroba ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help With Custom Disk Layout For New Install
On Tue, Jul 07, 2009 at 06:53:31PM -0700, Drew Tomlinson wrote: ... gmirror fails silently (i.e. nothing exists in /dev/mirror). ... I can't speak for the rest of your post but have you got the following in /boot/loader.conf? geom_mirror_load=YES -- Adrian Wontroba It is far better to be deceived than to be undeceived by those we love. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7, runaway clock as guest OS on Microsoft Virtual Server
On Thu, Jan 22, 2009 at 11:08:30AM -0800, Jeffrey Williams wrote: Well this helped sort of, the clocks are running only a little fast at this point (roughly seven minutes gained over 12 hours), but now for some reason, ntpd is not resetting the clocks at all, despite multiple good time sources, it was working fine before the kern.hz change. Any reason why that would break ntpd? I'm afraid that most of the salient details are inaccessible at work, but I found this necessary to get sort of acceptable[*] time keeping in FreeBSD guests under VMware on Windows. Run a NTP server on the host. I used the Trimble NTP implementation, which I believe is no longer available. Disable Windows Time service. The last thing you want is more than one time adjustment mechanism - they fight, horribly. Run ntpd -b every minute on the guest against the host. Set VMware tools to not sync time. Make several non-standard settings in the guest's .vmx configuration file which disable time syncronisation at various points not covered by the VMware tools setting. Information found in some VMware technical documents. I'll dig this out tomorrow. End result - time skips +/- a few milliseconds each minute, and takes a while to sort itself out when the guest is suspended over a host reboot. [*] I've a thing about time. If all you want is a clock which is no slower than a minute out, and always goes forwards, ignore all of the above, don't run NTP on the guest, and set VMware tools to syncronise clocks. This is adequate for many. For my systems, I need better time keeping to distinguish cause from effect in problems involving interacting applications on multiple machines. -- Adrian Wontroba No matter what Cliff said, time is not the simplest thing (8-( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7, runaway clock as guest OS on Microsoft Virtual Server
On Fri, Jan 23, 2009 at 03:01:51AM +, Adrian Wontroba wrote: I'm afraid that most of the salient details are inaccessible at work, but I found this necessary to get sort of acceptable[*] time keeping in FreeBSD guests under VMware on Windows. Sorry, I've got VMware on the brain at present, and missed the fact that you are using MS VS. We had time keeping problems with that too. And far worse ones with FreeBSD ATA drives dropping of the system and the unforgiveable fault of data corruption on Windows drives. Though the latter problem has been fixed, we've abandoned MS VS, VMware suits us better. -- Adrian Wontroba Organic chemistry is the chemistry of carbon compounds. Biochemistry is the study of carbon compounds that crawl. -- Mike Adams ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG7 using lpt causes panic
On Tue, Jan 08, 2008 at 01:52:40PM +0700, Eugene Grosbein wrote: On Tue, Jan 08, 2008 at 03:08:57AM +, Adrian Wontroba wrote: I've recently switched some of my home systems to RELENG7. All seemed fairly well until I tried printing a CUPS test page on my backup and print server to an elderly Laserjet IIIp, where I seem to have a reproducible panic. It has happened twice. This is painful, as I have a big home fileystem (striped over two mirrors over most of two 500 GB disks). The gmirror syncronisation and background fsck leave the system close to unusable for hours while they fight over the disks. I was somewhat startled that something so basic as printing causes a panic. There have been no hardware changes since I last printed under RELENG6, but I don't print often, so hardware decay is a possibility. Is this a known problem? If not, I'll take the time to try various tests (with /home unmounted) and raise a PR. There is a PR about this problem with workaround: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117973 Eugene Grosbein My thanks to Eugene for the pointer to a known workaround (switching the printer driver to extended mode before printing with '/usr/sbin/lptcontrol -e -d /dev/lpt0.ctl') and to John for explaining the underlying issue and intentions for fixing it. -- Adrian Wontroba Heisenberg may have done it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG7 using lpt causes panic
activated. GEOM_STRIPE: Disk mirror/gmrcusr2 attached to gsrcusr. GEOM_STRIPE: Device gsrcusr activated. GEOM_STRIPE: Disk mirror/gmrcswp2 attached to gsrcswp. GEOM_STRIPE: Device gsrcswp activated. GEOM_STRIPE: Disk mirror/gmrchom2 attached to gsrchom. GEOM_STRIPE: Device gsrchom activated. GEOM_LABEL: Label for provider stripe/gsrcvar is ufs/rcvar. GEOM_LABEL: Label for provider stripe/gsrcusr is ufs/rcusr. GEOM_LABEL: Label for provider stripe/gsrcswp is label/rcswap. GEOM_LABEL: Label for provider stripe/gsrchom is ufs/rchome. Trying to mount root from ufs:/dev/ufs/rcroot bge0: link state changed to UP -- Adrian Wontroba If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's a design philosophy. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-STABLE deadlock?
On Mon, Apr 23, 2007 at 03:56:32AM +0100, Adrian Wontroba wrote: Another 6-STABLE (cvsupped on 27/03/07) example, with diagnostics taken rather sooner after the hang. Processes with wmesg=ufs feature often in the ps output. Thanks for the assorted replies. I'll try using INVARIANTS, as I'd much prefer a panic and automatic reboot rather than creeping death for this server which is only attended 06:00-22:00 weekdays yet is a critical point in our 24*7 monitoring. Sigh. Champagne tastes on a beer budget. Other background information (from memory as I can't access it from here): I'm not using unionfs / nullfs. I am using MFS and softupdates. NFS is in occassional use. NTFS is not used. The server is ancient. A 4 way Zeon, state of the art in 1998. The problem has gone from absent through reproducible if you try hard enough to strikes according to Murphy through 5.5-STABLE to 6.2-STABLE. Once the sendmail milter ABI damage is fixed I'll bring the machine up to date - it is also the build box for a dozen or so machines running something close to 6.2-RELEASE, and I'd rather not upgrade all of them them when the next ClamAV release appears. If / when it hangs again, I'll include more information and maybe even raise a real PR. -- Adrian Wontroba It's always a long day; 86400 doesn't fit into a short. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-STABLE deadlock?
On Tue, Mar 13, 2007 at 02:08:48PM +, Adrian Wontroba wrote: At work, amoungst my stable of old computers running FreeBSD, I have a Fujitsu M800 - a 4 Zeon SMP processor with 4 GB of memory. This primarily runs Nagios and a small and lightly used MySQL database, along with a few inbound FTP transfers per minute. It has a Mylex card based disc subsystem, ruling out crash dumps. At some point during 5.5-STABLE this machine started to occasionally hang ... Another 6-STABLE (cvsupped on 27/03/07) example, with diagnostics taken rather sooner after the hang. Processes with wmesg=ufs feature often in the ps output. http://www.stade.co.uk/crash1/ -- Adrian Wontroba ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror Issues
On Mon, Mar 26, 2007 at 04:44:05PM -0700, Joe Kelsey wrote: For that reason, I have decided that the SII3512 is unreliable and will replace it with a Promise controller, basically the cheapest one (TX2). I hope it works better. I've been using cheap Promise controllers for years, more recently with gmirror / gstripe. They work fine. -- Adrian Wontroba ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.2-STABLE deadlock?
At work, amoungst my stable of old computers running FreeBSD, I have a Fujitsu M800 - a 4 Zeon SMP processor with 4 GB of memory. This primarily runs Nagios and a small and lightly used MySQL database, along with a few inbound FTP transfers per minute. It has a Mylex card based disc subsystem, ruling out crash dumps. At some point during 5.5-STABLE this machine started to occasionally hang while performing its daily application housekeeping - closing and restarting Apache and Nagios, and dumping the database. Upgrading to 6.2-STABLE appeared to solve the problem, with no problems visible while running 1,000 cycles of the sequence which seemed to provoke the problem. cvsup for this version of the kernel and userland was run at 01:20 GMT on 06 March. However, shortly after 15:15 last Sunday afternoon the machine hung again out of the blue. kdb diagnostics were taken some 12 hours later, and look somewhat odd. Maybe it was left to fester for too long. ps etc output at http://www.stade.co.uk/crash/console which contains boot to boot serial console output, including some output from test cycles. I'd be grateful for any expert comments on the ps etc output. Supporting stuff. [EMAIL PROTECTED] ~/crash]# df Filesystem1K-blocks UsedAvail Capacity Mounted on /dev/mlxd0s1a50763070074 39694615%/ devfs 110 100%/dev /dev/mlxd0s1f 63541498 44355014 1410316676%/home /dev/mlxd0s1e 16244334 6784900 815988845%/usr /dev/mlxd0s1d 1012974 117456 81448213%/var /dev/md0 1646 32 1484 2%/home/topftp/instances /dev/md1 253678 132 233252 0%/tmp [EMAIL PROTECTED] ~]# find /var -inum 23 -ls 234 -rw-r--r--1 daemon daemon 60 Mar 12 20:22 /var/rwho/whod.xjamesfriis Problem stopped http and FTP logging soon after 15:14 on Sunday 11, diagnostics taken and machine rebooted around 04:30 on Monday 12. 172.19.112.92 - - [11/Mar/2007:15:14:53 +] GET / HTTP/1.0 200 688 - check_http/1.89 (nagios-plugins 1.4.3) time passes 172.19.112.92 - - [12/Mar/2007:04:44:14 +] GET / HTTP/1.0 200 688 - check_http/1.89 (nagios-plugins 1.4.3) Mar 11 15:15:35 beastie ftpd[91652]: connection from appsupcen (10.208.1.134) Mar 11 15:15:35 beastie ftpd[91652]: FTP LOGIN FROM appsupcen as topftp Mar 11 15:15:35 beastie ftpd[91652]: session root changed to /home/topftp/instances Mar 11 15:15:35 beastie ftpd[91652]: put in.env_status.html.gz = 592 bytes (wd: /topftp/appsupcen; chrooted) time passes Mar 11 15:15:35 beastie ftpd[91652]: rename in.env_status.html.gz env_status.html.gz (wd: /topftp/appsupcen; chrooted) Mar 12 04:44:31 beastie ftpd[1161]: connection from appsupcen (10.208.1.134) Mar 12 04:44:31 beastie ftpd[1161]: FTP LOGIN FROM appsupcen as topftp Mar 12 04:44:31 beastie ftpd[1161]: session root changed to /home/topftp/instances Mar 12 04:44:31 beastie ftpd[1161]: mkdir topftp/appsupcen (wd: /; chrooted) Support diary: 15:20 Beastie seems like its crashed and down; 16:54 Beastie is now longer pingable by rjmon1; 04:30 - 04:43 (support person quoting from the documentation I'd provided about what to do after a hang) Type return tilde hash (CR~#) which will make cu send a break signal to beastie, and should cause beastie to drop into the ddb kernel debugger. In the following, you may see more prompts. Type space at each for the next page. Type these debugger commands ps show pcpu show allpcpu show locks show alllocks show lockedvnods trace alltrace 04:43 - beastie now back up and working now by typing call cpu_reset() after the above commands to reboot beastie. AW: preserved and inspected diagnostic output. It looks very unlike that for previous crashes (without a serial console) where a noticable feature was many ftpd processes in a UFS state. Possibly things happened in the 12 hour period between the onset of the problem on Sunday afternoon and the diagnostics being taken on Monday morning. -- Adrian Wontroba Adrian's Birthday Celebration: Crewe Limelight, Saturday 17 March. David Hughes and Tiny Tin Lady. Free but ticketed - email me your postal address if you want to come. No under 18s. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System freeze on 6.1/2 when running makeworld and dump
On Sat, Jan 06, 2007 at 07:14:41PM +1100, Geoff Roberts wrote: I can consistantly make my system freeze when building makeworld and running dump at the same time. The system actually locks - I have to hit the reset switch to bring the system back to life. I have an old SMP machine at work which sometimes does something similar during its daily housekeeping, where Apache and Nagios are bounced and a small MySQL database dumped. It sometimes appears to hang during the database dump. The debugger shows many processes waiting for UFS. I suspect that the problem starts several minutes earlier. All of the following help to keep the problem away: Upgrading from a several months old 5-STABLE to 6-STABLE. Inserting 60 second delays at various points. Disabling SMP. No core dump available (Mylex disk controller). My next diagnostic step will be a serial console. -- Adrian Wontroba The biggest mistake you can make is to believe that you are working for someone else. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: negative runtime etc.
On Sat, Dec 16, 2006 at 06:39:09PM +0100, Vclav Haisman wrote: Hi, I have loads of following messages in newly installed virtual server (under MS Virtual Server 2005 R2) running 6.2 RC1, I am even using the stock kernel. Can I fix this? Dec 16 18:33:27 shell kernel: calcru: negative runtime of -553620 usec for pid 76484 (zsh) Dec 16 18:33:27 shell kernel: calcru: runtime went backwards from 1004708 usec to 791507 usec for pid 655 (sendmail) You can reduce them somewhat by using a slower clock tick and perhaps a different timecounter: == /boot/loader.conf == kern.hz=200 == /etc/sysctl.conf == kern.timecounter.hardware=ACPI-safe The above reduced my errors to a few hundred a day and improved time keeping. Setting up the host as an NTP server and running ntpdate once a minute seems to have sufficed to keep time accurate enough for my needs. I got my clues from VMWare documentation grin. Other problems I've seen: FreeBSD won't even boot if there is a SCSI controller attached to the guest. I still had my boot drive attached to IDE. The kernel sometimes (I've seen this twice in a couple of months) loops outputting a message which might indicate that it disliked the disk drive and has detached it. With a NT guest, iozone sometimes (after hours of disk battering) reports that it read something other than what it had written. I've not seen iozone do this on the MS 2003 host, on the same disks. The last two make me fear that the IDE emulation sometimes glitches. -- Adrian Wontroba Prof:So the American government went to IBM to come up with a data encryption standard and they came up with ... Student: EBCDIC! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck_ufs locked in snaplk
On Tue, Apr 25, 2006 at 11:46:03PM +0200, Torfinn Ingolfsen wrote: It could also be viewed as irresponsible to have servers in production _without_ a corresponding test system to test proposed changes on. True, but some us are blessed with a collection of assorted ancient cast off servers, and can not justify to money focused management a test system for every type of production server / function. We then sometimes pay the price for doing things on the cheap when an exotic bug strikes in less heavily exercised code. If you're different and you know it, test! (or clap your hands in woe?) -- Adrian Wontroba ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stability problems vith FreeBSD 5.2.1-RELEASE-p14
On Sun, Oct 02, 2005 at 07:54:25PM +0200, Jurij Kovacic wrote: The panic message is ussually somewhere along these lines: panic: kmem_malloc(4096) kmem map too small: 48496066400 total allocated cpuid =0 boot() called on cpu#0 ... A similar problem is described in http://lists.freebsd.org/pipermail/freebsd-doc/2004-May/004262.html which recommends setting VM_KMEM_SIZE_MAX 419430400 for machines with large amounts of memory. Worked for me on a recent 5-STABLE. Might work for your rather elderly release. -- Adrian Wontroba ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP support maturity? AMD64x2 or FX-57?
On Fri, Jul 22, 2005 at 01:27:30PM -0700, Frank Mayhar wrote: Personally I don't have the first clue what people have found to gripe about. It has been good, it got a _lot_ better in 5.x, and it's continuing to improve. I agree. At work I have a couple of very old 4-way servers (one with Pentium Pros, the other PIII Xeons), which run 5-STABLE happily with the stock SMP kernel configuration. Admittedly, there was a problem with SMP in 5.3-RELEASE, but that is long behind us. With 5.4 it should work almost out of the box (modulo a kernel build, and I seem to recall discussion about including SMP kernels in future releases). I can't comment about SMP on newer processors - I only get the cast offs to recycle as something useful. -- Adrian Wontroba ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.x can't read 5.x dump?
On Fri, Dec 03, 2004 at 02:36:09PM +, Ceri Davies wrote: Should I expect a dump taken from 4.X to be restorable on 5.X though? Yes. Phew. I didn't even think about the possibility of dump not being forwards compatible (8-( In passing, you may find the buffer port useful. I spent a while a couple of years ago experimenting with settings, and find this sort of thing sufficiently fast: /sbin/dump -L -0 -u -C 32 -b 32 -f - /home | /usr/local/bin/buffer -s 32k -m 16m -t | gzip | /usr/local/bin/buffer -s 32k -m 16m -t new/home.dump.gz That is, big buffers and block sizes for dump, with a 16 MB buffer of either side of gzip to absorb some of the delays in compression or writing the dump file. Sorry, no timings available at the moment. Note: * Remove the -L under Release 4 * When the above line is executed, the script has changed its CWD to the dump directory, usually on an NFS mount. * When dumping to the same machine, I include -h 0 and make the dump directory (and a slew of other recoverable by other ways ones) nodump with chflags nodump. -- Adrian Wontroba ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: APIC: Previous IPI is stuck
On Mon, Nov 15, 2004 at 04:49:56PM +1100, Andy Farkas wrote: [freebsd.org is rejecting my email (cant find hostname) so please feel free to copy this to the list] So quoted in full. On Mon, 15 Nov 2004, Adrian Wontroba wrote: ... The practice is that it it has now crashed three times in a couple of days with panic: APIC: Previous IPI is stuck, the most recent one dragging me out from home early in a Monday morning. /me raises hand I still get panics too (5.3-STABLE cvsup'd last thursday). At one stage I thought it was fixed, but I was wrong. My box does not reboot itself either. Over in current there are a couple of threads starting in late September where a few people are suffering this problem. Like them, I'm using an old (1997) Pentium Pro multiprocessor, in my case a 4 way Fujitsu M700. The machine is running with the SMP kernel (ie GENERIC + SMP), 4BSD scheduler, without preemption. Robert Watson has said it happens on his 4-way xeon box, so its not the old hardware thats to blame. (My box is an old Dell quad-ppro too). Something changed in the code around the end of August this year. I've set kern.sched.ipiwakeup.enabled=0 and crossed my fingers. Doesn't help. I already tried. Panic will still happen. Ah. Will it last the day I wonder? I'm a SMP novice. Would the machine become stable if I switched to a non-SMP kernel? Reliability is more important than speed in this case, and the opportunity for experimentation close to zero. Creditability has already been damaged by the gvinum RAID5 experience (8-( A UP kernel will probably run forever. The IPI panic can only happen on SMP kernels. Thanks. I'll switch back to GENERIC. I'm not knocking 5.3 - in all other respects it seems wonderful. I'm not knocking 5.3 either, but it seems to its not quite stable. Its more of .0 release, where things are still getting ironed out (like gvinum, which I also have problems with). RELENG_4: Time to die - for all kinds of good reasons. It was time for 5-STABLE. The future release plan looks promising, but there is still the age old problem - how do you get the more of the user population to try out and find the problems in new versions before they acquire -RELEASE status? Mea culpa - I no longer have a crash box. Time to get my mail off my own PPro (uniprocessor) box to free it up as such. If I had done this, I would have run into the vinum / gvinum issues in a less embarrassing fashion. Stephan, you mentioned that the IPI code needs rewriting in order to fix this problem... how's it going? - andyf -- Adrian Wontroba ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: APIC: Previous IPI is stuck
target 4 lun 0 sa0: WangDAT Model 3400DX 04j0 Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 15) ses0 at ahc0 bus 0 target 6 lun 0 ses0: FUJITSU SAF-TE PROCESSOR 1.00 Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device ses1 at ahc1 bus 0 target 6 lun 0 ses1: FUJITSU SAF-TE PROCESSOR 1.00 Fixed Processor SCSI-2 device ses1: 3.300MB/s transfers ses1: SAF-TE Compliant Device da0 at ahc0 bus 0 target 0 lun 0 da0: FUJITSU M2954E-512 0162 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C) da1 at ahc0 bus 0 target 1 lun 0 da1: FUJITSU M2954E-512 0162 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C) da2 at ahc0 bus 0 target 2 lun 0 da2: FUJITSU M2954E-512 0162 Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C) da3 at ahc1 bus 0 target 0 lun 0 da3: FUJITSU M2954E-512 0162 Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C) da4 at ahc1 bus 0 target 1 lun 0 da4: FUJITSU M2954E-512 0162 Fixed Direct Access SCSI-2 device da4: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da4: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C) da5 at ahc1 bus 0 target 2 lun 0 da5: SEAGATE ST39102LC 0006 Fixed Direct Access SCSI-2 device da5: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da5: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) cd0 at ahc0 bus 0 target 5 lun 0 cd0: MATSHITA CD-ROM CR-508 XS03 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM_MIRROR: Device mirror0 created (id=138753045). GEOM_MIRROR: Device mirror0: provider da0 detected. GEOM_CONCAT: Device usr2 created (id=1051984440). GEOM_CONCAT: Disk da1 attached to usr2. GEOM_CONCAT: Disk da2 attached to usr2. GEOM_MIRROR: Device mirror0: provider da3 detected. GEOM_MIRROR: Device mirror0: provider da3 activated. GEOM_MIRROR: Device mirror0: provider mirror/mirror0 launched. GEOM_MIRROR: Device mirror0: rebuilding provider da0. GEOM_CONCAT: Disk da4 attached to usr2. GEOM_CONCAT: Disk da5 attached to usr2. GEOM_CONCAT: Device usr2 activated. SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Mounting root from ufs:/dev/mirror/mirror0a WARNING: / was not properly dismounted WARNING: /var was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 4 files 2 WARNING: /usr2 was not properly dismounted -- Adrian Wontroba ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freeze in 5.3 Release Install
On Thu, Nov 11, 2004 at 06:40:47PM -0500, Mark Jacobs wrote: Probe1-6 are listed after this, all with the same error 22 After the probe6 message the machine hangs. I had something similar - 5.3 probe time kernel freezes on a machine which had been running 4.10 quite happily. Resolved it by setting PNP OS to YES in the BIOS. -- Adrian Wontroba ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd 5.3 have any problem with vinum ?
On Mon, Nov 01, 2004 at 10:05:16AM +1100, Carl Makin wrote: Do you want to yank it in 5 or 6-CURRENT? There are a *lot* of people using vinum and yanking it in 5-STABLE would force us all to use the 5.3 security branch until gvinum caught up. From my experiences today with setting up a very old machine[1] with 5.3-RC2, I think it would be best to keep both until gvinum had caught up. Vinum can do things which gvinum appears incapable of - such as initialising a RAID-5 plex. -- Adrian Wontroba [1] A Fujitsu M700 4 way Ppro - the state of the art in 1997 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kern/60555] vinum volume as a swap device not possible on FreeBSD 5.2.1
On Sat, May 15, 2004 at 03:36:11AM +0200, Conrad Burger wrote: I am trying to mirror a servers swap partition using vinum, but it doesn't seem to be possible in FreeBSD 5.2.1. Just need to know if I should downgrade to 5.1 ? There is a lengthy thread about this in -current (which I sometimes read, but don't run). The situation seems to be: * swap is supported by geom in later 5.* releases. * Other types of disk usage are soon to be moved to geom. So vinum soon won't work for ufs either. * Vinum does not yet support geom, but should in due course. * No release 5.* release will be called production until it has a working software mirror system and upgrade path. Looks like downgrading to 5.1 (or even the current production release (4.9, soon to be 4.10)), is your best short-term option. Or do without mirrored swap. -- Adrian Wontroba The blood on the leading edge is often your own ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
mergemaster (was Re: Ifconfig config of gif tunnels)
On Sun, Oct 13, 2002 at 01:05:27PM -0400, Trish Lynch wrote: I';ve done something semi-simple to manage things that possibly might get broken by mergemaster. I don't recall ever having anything broken by mergemaster. I have broken things for myself by failing to drive mergemaster properly, e.g. my not noticing that a file (i)nstalled by mergemaster should have been (m)erged, to preserve local changes. The incidence of this has much reduced since I adopted the convention of flagging files I have modified with a # MODIFIED line near the top. -- Adrian Wontroba To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
On Fri, Jun 22, 2001 at 11:54:10PM -0400, Kevin Way wrote: cvsup works fine over dialup, and not unacceptably slowly either. I cvsup the whole thing, maintaining my own local copy of the entire repository. Source, ports, doc, gnats, www. No refuse files at all (not got round to it). I normally use a 64K ISDN connection to my ISP, and the cvsup server is fairly close to them. Line utilisation is close to 100% only when rsyncing big files in the www collection (book.html etc). Most of the time line utilisation is very much less. Elapsed time is bearable. Of course, if you start with nothing, the first cvsup takes a while - 7 hours with two channels (128K) going, close to flat out as I recall. A satisfied dialup cvsup user, Me too. I started with CTM, moved to checking out stable from a cvsup mirror, and on to having my own repository. Its all a bit heavy on disk space, but that is fairly plentiful nowadays. Aside: my first UNIX box ran SCO ODT, with 120 MB of disk and 8 MB of memory. Definitely too little disk (8-( -- Adrian Wontroba To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
