RE: TinyBSD Call For Testers
Hello, thank you for your posting. Can you explain, how it compares to minibsd [https://neon1.net/misc/minibsd.html]? Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-RELEASE-p4: shutdown hangs after rebuiding gmirror
[recap: machine hangs on shutdown - see original message for more details] Syncing disks, vnodes remaining...1 1 0 1 1 0 0 0 done No buffers busy after final sync Uptime: 55m39s GEOM_MIRROR: Device raid1: provider mirror/raid1 destroyed. GEOM_MIRROR: Device raid1 destroyed. FWIW the hangs occur regardless of whether I rebuild a mirror. The problem is that the box sometimes hangs and sometimes not. Of course this makes the whole gmirror totally useless (as opposed to a bit of a nuisance) It appears that the hang occurs somewhere between destruction of raid1 and 'raid1.sync'. (whatever that is) Does anyone have any clue as to what is going on or how I can debug this further? Please don't make me put solaris on this box. :) Cheers Michiel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
On Wed, Jun 08, 2005 at 08:04:28PM +0200, Marc Olzheim wrote: I remember 5.2.1 panicking left and right, on several machines, it was completely unusable. Maybe we just live in different universes. Me too, but a lot has changed since 5.2.1 which at the time was I think was called a preview. The topic is 5.4R. What parts of the OS do you feel are not production ready as compared to 4.X ? Personnally, when upgrading from 4.x to 5.x, we ran into the following 3 issues that are still not fixed in 5.4: kern/80617: Hangup writing large blocks to NFS mounted FS(Patches available) Not exremely important: just don't do that. kern/79208: i387 libm's floorf(), ceilf() and truncf() (Fixed in RELENG_5) PITA when running threaded calculations. kern/78824 socketpair()/close() race condition (Fixed in CURRENT) Patch will be MFC'd to RELENG_5 soon. Anyway: you won't catch me running an unpatched 5.4 system... I'd say stick with RELENG_5 for the time being. Since I can't seem to keep any recent RELENG_5 kernel up and running atm. I'd change my viewpoint to run 5.4 and apply all necessary stability patches yourself. I'll prepare a patchset... Marc pgpwffJfub9Iw.pgp Description: PGP signature
ATA Woes.
Folks, I'm seeing something very unusual on one of our FreeBSD 5.4 Stable boxes which I'm having a hard time getting to the bottom of. You may recall that a few weeks ago I posted regarding a server that was having trouble with WRITE_DMA and READ_DMA timeouts on it's SATA disk. We finally decided to migrate to a new disk, so we purchased a brand new Western Digital 250GB SATA drive and transferred the data across, before removing the old drive. We got about two days of trouble free access to this new disk before it too started throwing READ_DMA problems. This time they were error 40UNCORRECTABLE. Running SmartCtl on the disk showed a number of errors and there were specific files on the disk that could not be read. We moved the disk to a desktop box to confirm the problem and noted that fsck couldn't fix the errors on the drive. Assuming a dud drive, we purchased a replacement and this time we spurned SATA in favour of a PATA drive (Western Digital 200GB). We installed the drive yesterday using a brand new UDMA cable. Imagine my surprise when I came in this morning to find that this new drive was also now suffering from UNCORRECTABLE READ_DMA failures and SmartCtl confirmed that the drive wasn't happy. What are the odds of getting two dud disks from two separate batches of drives from, a reputable brand? The server itself is a 1U high rack mount installed in an AC'd machine room. It is powered from a UPS. There is space around the drive and a pair of fans draw air over the drive casing, to the casings are cool to the touch. The motherboard is an Intel S875PWP3 equipped with an Intel ICH5 chipset. Is there any known problem with using WD SATA / PATA disks with FreeBSD 5.4 Stable with the above mainboard? Is it possible that a FreeBSD bug is causing problems with these drives, including the problems reported by SmartCtl? Regards, Tony. -- Tony Byrne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
On Tue, Jul 19, 2005 at 11:28:03AM +0200, Marc Olzheim wrote: On Wed, Jun 08, 2005 at 08:04:28PM +0200, Marc Olzheim wrote: I remember 5.2.1 panicking left and right, on several machines, it was completely unusable. Maybe we just live in different universes. Me too, but a lot has changed since 5.2.1 which at the time was I think was called a preview. The topic is 5.4R. What parts of the OS do you feel are not production ready as compared to 4.X ? Personnally, when upgrading from 4.x to 5.x, we ran into the following 3 issues that are still not fixed in 5.4: kern/80617: Hangup writing large blocks to NFS mounted FS(Patches available) Not exremely important: just don't do that. kern/79208: i387 libm's floorf(), ceilf() and truncf() (Fixed in RELENG_5) PITA when running threaded calculations. kern/78824 socketpair()/close() race condition (Fixed in CURRENT) Patch will be MFC'd to RELENG_5 soon. Anyway: you won't catch me running an unpatched 5.4 system... I'd say stick with RELENG_5 for the time being. Since I can't seem to keep any recent RELENG_5 kernel up and running atm. I'd change my viewpoint to run 5.4 and apply all necessary stability patches yourself. I'll prepare a patchset... ARGH, nevermind, 5.4-release-p4 crashes on: kern/83375 Fatal trap 12 cloning a pty (Broken in 5.4-7.x) I'll have to revert to 4.10 or 4.11 for our servers, until I can manage to keep a single test machine up and rnuning... :-( Marc pgpVvfv16tHjJ.pgp Description: PGP signature
Re: FYI - RELENG_6 branch has been created.
On Mon, Jul 11, 2005 at 10:04:36PM +0100, Robert Watson wrote:
On Mon, 11 Jul 2005, Ken Smith wrote:
Just a quick note to say that as part of the FreeBSD-6.0 Release Cycle
the RELENG_6 branch tag has just been created in the CVS repository.
In preparation for the release some places in the tree now say that this
branch is -STABLE but there is still work to do before this branch will
be ready for release. People who are not in a position to help work out
the remaining bugs in the RELENG_6 branch as we work towards the
FreeBSD-6.0 Release should definitely continue using RELENG_5_4 or
RELENG_5 as appropriate.
As a further FYI, a variety of debugging features are still enabled by
default in RELENG_6, including INVARINTS, WITNESS, and user space malloc
debugging. These will remain enabled through the first snapshot from the
release candidate series in order to assist in debugging problems.
However, anyone running RELENG_6 until that time should be aware that
these debugging features result in a loss of 1/2 or more performance for
many common workloads. Depending on workload and hardware, this might or
might not present a problem for your environment -- the features are
invaluable in diagnosing problems, however, so if it's possible to leave
them on in testing, that would be useful. Obviously, tesing without them
is also desired, as they significantly perturb timing, but the first
question you'll get is can you reproduce them with debugging features
enabled? :-).
It's a trivial thing, I know, but is there any chance of someone
committing the following to RELENG_6?
lack-of-gravitas:/usr/src:% diff -u share/examples/cvsup/stable-supfile{.orig,}
--- share/examples/cvsup/stable-supfile.origTue Jul 19 12:40:25 2005
+++ share/examples/cvsup/stable-supfile Tue Jul 19 12:41:40 2005
@@ -68,9 +68,10 @@
*default host=CHANGE_THIS.FreeBSD.org
*default base=/var/db
*default prefix=/usr
-# The following line is for 5-stable. If you want 4-stable, 3-stable, or
-# 2.2-stable, change to RELENG_4, RELENG_3, or RELENG_2_2 respectively.
-*default release=cvs tag=RELENG_5
+# The following line is for 6-stable. If you want 5-stable, 4-stable,
+# 3-stable, or 2.2-stable, change to RELENG_5, RELENG_4,
+# RELENG_3, or RELENG_2_2 respectively.
+*default release=cvs tag=RELENG_6
*default delete use-rel-suffix
# If you seem to be limited by CPU rather than network or disk bandwidth, try
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 8 Dane Court Manor
School Rd
PGP: http://www.infracaninophile.co.uk/pgpkey Tilmanstone
Tel: +44 1304 617253 Kent, CT14 0JL UK
pgpmWzAPk4lF7.pgp
Description: PGP signature
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Fri, Jul 15, 2005 at 08:05:23AM -0400, Kris Kennaway wrote: Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm the only one seeing this... You're not..as noted, it's been widely reported. Could you give me any pointers to where this has been discussed before ? Would placing all of the ptsopen() and ptcclose() code under a giant lock help ? Or is the problem somewhere else ? Marc pgpjdulqRu9MZ.pgp Description: PGP signature
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Tue, Jul 19, 2005 at 01:53:14PM +0200, Marc Olzheim wrote: On Fri, Jul 15, 2005 at 08:05:23AM -0400, Kris Kennaway wrote: Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm the only one seeing this... You're not..as noted, it's been widely reported. Could you give me any pointers to where this has been discussed before ? Would placing all of the ptsopen() and ptcclose() code under a giant lock help ? Or is the problem somewhere else ? Ah, nevermind, it already operates under GIANT, so something else is molesting the tty's t_line array. Perhaps some kind of use after free issue ? Marc pgp5eUwbTdo0z.pgp Description: PGP signature
Re: ATA Woes.
Hello Tony, Tuesday, July 19, 2005, 10:37:40 AM, you wrote: TB Folks, TB I'm seeing something very unusual on one of our FreeBSD 5.4 Stable TB boxes which I'm having a hard time getting to the bottom of. Further information from my server logs: Jul 19 13:01:48 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:01:59 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=1ILLEGAL_LENGTH LBA=288810495 Jul 19 13:02:05 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:02:16 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:04:36 roo last message repeated 4 times With this disk it appears to be the same LBA each time. How can I translate that LBA offset into something indicating the file affected? I installed the *other* disk into a Windows box an ran the Western Digital Drive Tools SMART test on it. It found some sectors needing reallocation and successfully performed the reallocation. The tests (both short and long) now pass, but the drive's SMART Status remains at 'fail'. When I examine the attributes, the Raw Read Error Rate is flagged. I'm totally confused. I don't know enough about SMART to know whether I'm looking at real failing drives or some bug exposed by the interaction between drive firmware, hd controller and FreeBSD. Regards, Tony. -- Tony Byrne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TinyBSD Call For Testers
Norbert Koch wrote: Hello, thank you for your posting. Can you explain, how it compares to minibsd [https://neon1.net/misc/minibsd.html]? Norbert It is similar to minibsd in the copy proccess, but different in the configuration and image creation stages. TinyBSD does not heavily depend on chroot enviroment, it works directly in a work directory, where files copying, kernel build and hier(7) definitions are used in such an usual FreeBSD building enviroment, including mtree definitions in /etc/mtree/, using make DESTDIR and make DISTRIBUTION whenever it is possible. In fact it is pretty much closer to NanoBSD in the whole proccess, while only similar to minibsd in the copy idea. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 sip://[EMAIL PROTECTED] http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available]
Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On Mon, 2005-07-18 at 18:18 +0200, Emanuel Strobl wrote: Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: (2) /dev/cuaa* has been renamed to /dev/cuad* I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of cua? tty AFAIK is TeleTYpe... Call(-out) Unit Access, IIRC. Yes. I remember that some systems (Solaris) used the term ACU for automatic call unit, which just means a modem. I've also seen interpretations saying that cua is related to UART (universal asynchronous receiver/transmitter), which is the basic function description of a serial controller. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. ... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies.-- C.A.R. Hoare, ACM Turing Award Lecture, 1980 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4: Is it generally unstable?
On Tue, Jul 19, 2005 at 11:46:18AM +0200, Marc Olzheim wrote: Since I can't seem to keep any recent RELENG_5 kernel up and running atm. I'd change my viewpoint to run 5.4 and apply all necessary stability patches yourself. I'll prepare a patchset... ARGH, nevermind, 5.4-release-p4 crashes on: kern/83375 Fatal trap 12 cloning a pty (Broken in 5.4-7.x) I put a list of my issues with FreeBSD 5.4 together: http://www.ipv4.stack.nl/~marcolz/FreeBSD/showstoppers.html Marc pgpeCtJwqqAuQ.pgp Description: PGP signature
Re: FreeBSD -STABLE servers repeatedly crashing.
On Jul 18, 2005, at 5:39 PM, Gary Mulder wrote: Another person on the freebsd-amd64 list reported similar network- related crashes until he switched to em (Intel Gigabit Ethernet) NICs. that was probably me... but I don't have any firewall on these boxes as they are not hooked up to the internet -- just internal back-end DB servers. Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available]
On Tue, Jul 19, 2005 at 03:24:47PM +0200, Oliver Fromme wrote: Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On Mon, 2005-07-18 at 18:18 +0200, Emanuel Strobl wrote: Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: (2) /dev/cuaa* has been renamed to /dev/cuad* I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of cua? tty AFAIK is TeleTYpe... Call(-out) Unit Access, IIRC. Yes. I remember that some systems (Solaris) used the term ACU for automatic call unit, which just means a modem. Actually, Way Back When, ACUs and MODEMs were separate boxen. :-} Peace, david (who did work at an installation that had them, ca. 1976) -- David H. Wolfskill [EMAIL PROTECTED] Any given sequence of letters is a misspelling of a great many English words. See http://www.catwhisker.org/~david/publickey.gpg for public key. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 has problems with booting
Le Lundi 18 Juillet 2005 10:50, Jonathan Weiss a écrit : Hi, When I do a boot in safe mode, everything is ok. Attachted is the dmesg from the verbose boot. Did you try without acpi ? I've got a similar problem with a nforce2 based mother board. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror, sparc and SCSI problems
On Jul 9, 2005, at 9:36 AM, Chris Hodgins wrote: Danny, Thanks for the link. This was actually the first link we tried to get working and after it failed to work we followed the link on the page to http://people.freebsd.org/~rse/mirror/. Everything worked fine until we arrived at this step below. # mount /dev/mirror/gm0s1a /mnt It seems that gmirror does not give us any partitions. A listing of the mirror directory shows only the gm0 node even though da0 is partitioned. When mounting the mirror it seems that /dev/mirror/gm0 only represents the root partition. How can we get the mirror to recognise the other partitions? Thanks Chris ___ Chris, Based on my experience, it doesn't work to partition the underlying disk device da0, but rather the mirror device gm0. I've had a lot of success writing out new labels with # bsdlabel -w /dev/mirror/gm0 # bsdlabel -e /dev/mirror/gm0 Editing the partition table by hand is a bummer, but for now, since mirror devices don't show up in fdisk/disklabel tools in /stand/ sysinstall, this is the only way I know of to do it. -Stephen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Perl 5.8.7 dumps core on quotewords
Hello - I've just installed perl5.8.7 and now my cricket 1.0.5 does not work correctly. Perl abnormally exits with 'Bus error' message and throws core. After little investigation I have found out the problem is in Text::ParseWords::quotewords procedure. Test perl script which produces error is attached. If it's neccesary i will send the core file of perl. It dumps core with # perl -V Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=freebsd, osvers=5.4-stable, archname=i386-freebsd-64int uname='freebsd zeus.nordnet.ru 5.4-stable freebsd 5.4-stable #1: sat may 14 12:26:53 msd 2005 [EMAIL PROTECTED]:usrobjusrsrcsyszeus i386 ' config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.7/mach -Dprivlib=/usr/local/lib/perl5/5.8.7 -Dman3dir=/usr/local/lib/perl5/5.8.7/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.7/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.7 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.8.7/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Duseshrplib -Dccflags=-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.7/BSDPAN -Doptimize=-O -pipe -march=pentiumpro -Ud_dosuid -Ui_gdbm -Dusethreads=n -Dusemymalloc=y -Duse64bitint' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='cc', ccflags ='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.7/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-O -pipe -march=pentiumpro', cppflags='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.7/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.2 [FreeBSD] 20040728', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='-pthread -Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lm -lcrypt -lutil perllibs=-lm -lcrypt -lutil libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/local/lib/perl5/5.8.7/mach/CORE' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_LARGE_FILES Locally applied patches: defined-or Built under freebsd Compiled at Jul 19 2005 10:23:40 @INC: /usr/local/lib/perl5/site_perl/5.8.7/mach /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/5.8.6 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.7/BSDPAN /usr/local/lib/perl5/5.8.7/mach /usr/local/lib/perl5/5.8.7 . But works good with # perl -V Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=freebsd, osvers=5.4-release, archname=i386-freebsd-64int uname='freebsd freebsd.org 5.4-release freebsd 5.4-release #0: sun apr 3 15:13:31 pdt 2005 [EMAIL PROTECTED]:usrsrcsysmagickernelpath i386 ' config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.6/mach -Dprivlib=/usr/local/lib/perl5/5.8.6 -Dman3dir=/usr/local/lib/perl5/5.8.6/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.6/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.6 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.8.6/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Doptimize=-O -pipe -Duseshrplib -Dccflags=-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.6/BSDPAN -Ud_dosuid -Ui_gdbm -Dusethreads=n -Dusemymalloc=y -Duse64bitint' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='cc', ccflags ='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.6/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-O -pipe ', cppflags='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.6/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.2 [FreeBSD] 20040728', gccosandvers='' intsize=4,
Re: TinyBSD Call For Testers
On Mon, Jul 18, 2005 at 03:17:52PM -0300, Jean Milanez Melo wrote: Hello gentlemen, In the last saturday a new port has been added under sysutils/ category, ports/sysutils/tinybsd. TinyBSD is a tool which was meant to allow an easy way to build embedded systems based on FreeBSD. It is based on userland copying, library dependencies check/copy and kernel build. What's wrong with PicoBSD? -ip -- Consumer assistance doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Perl 5.8.7 dumps core on quotewords
Pavel A Crasotin wrote: Hello - I've just installed perl5.8.7 and now my cricket 1.0.5 does not work correctly. Perl abnormally exits with 'Bus error' message and throws core. After little investigation I have found out the problem is in Text::ParseWords::quotewords procedure. [details snipped] Did you upgrade perl using the ports collection? If so, did you run the provided perl-after-upgrade script? If not, can you do that and test again? See ports/UPDATING for more information on upgrading perl. -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA Woes.
On 7/19/05, Tony Byrne [EMAIL PROTECTED] wrote: Jul 19 13:01:48 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:01:59 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=1ILLEGAL_LENGTH LBA=288810495 Jul 19 13:02:05 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:02:16 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:04:36 roo last message repeated 4 times I'm totally confused. I don't know enough about SMART to know whether I'm looking at real failing drives or some bug exposed by the interaction between drive firmware, hd controller and FreeBSD. What I've recently learned the hard way is that desktop drives have no place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). -- Jon Simola Systems Administrator ABC Communications ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA Woes.
On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. On 7/19/05, Tony Byrne [EMAIL PROTECTED] wrote: Jul 19 13:01:48 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:01:59 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=1ILLEGAL_LENGTH LBA=288810495 Jul 19 13:02:05 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:02:16 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:04:36 roo last message repeated 4 times I'm totally confused. I don't know enough about SMART to know whether I'm looking at real failing drives or some bug exposed by the interaction between drive firmware, hd controller and FreeBSD. What I've recently learned the hard way is that desktop drives have no place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). Properly cooled? -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Perl 5.8.7 dumps core on quotewords
Yes, i have installed perl5.8.7 from ports And yes, i have run the perl-after-upgrade script with -f option GB Pavel A Crasotin wrote: Hello - I've just installed perl5.8.7 and now my cricket 1.0.5 does not work correctly. Perl abnormally exits with 'Bus error' message and throws core. After little investigation I have found out the problem is in Text::ParseWords::quotewords procedure. GB [details snipped] GB Did you upgrade perl using the ports collection? GB If so, did you run the provided perl-after-upgrade script? GB If not, can you do that and test again? GB See ports/UPDATING for more information on upgrading perl. -- With respect, Pavel A Crasotin OJSC SeverTransCom Tel: +7 (0852) 58-41-03, 58-01-01 Fax: +7 (0852) 58-01-01 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: ATA Woes.
Hello Wilko, Tuesday, July 19, 2005, 7:35:40 PM, you wrote: WB On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. What I've recently learned the hard way is that desktop drives have no place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). WB Properly cooled? I can't speak for Jon, but the two disks that 'failed' sequentially on me in the last 48 hours took turns in a housing that had fans installed to draw air over the drive. Smartctl reported the drive temp. as 26 Deg.C. Regards, Tony. -- Tony Byrne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA Woes.
Tony Byrne wrote: Hello Wilko, Tuesday, July 19, 2005, 7:35:40 PM, you wrote: WB On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. What I've recently learned the hard way is that desktop drives have no place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). WB Properly cooled? I can't speak for Jon, but the two disks that 'failed' sequentially on me in the last 48 hours took turns in a housing that had fans installed to draw air over the drive. Smartctl reported the drive temp. as 26 Deg.C. I don't think it's a problem of proper cooling or bad drives. I have a _desktop_ box with an 80G WDC drive in it, brand new. It installs WinXP and Linux just fine. It will not get through writing the superblocks for FreeBSD during the install _unless_ I boot the install kernel in save mode. This is installing 5.4-RELEASE, _and_ 5-Stable (several different snapshots, the most recent 8 July). This is a PATA drive, nothing special about it. The CPU is an AlthonXP 2200, mb has the VIA KT266A chipset. Out of the box, I'm having a lot of trouble installing 5.anything on this configuration. These same READ_DMA errors appear to be occurring with both SATA and PATA drives. (The drive checks out as fine. I'm about to run WDC diagnostics on it again.) John -- John T. FarmerOwner CTOGoldSword Systems [EMAIL PROTECTED] 865-691-6498 Knoxville TN Consulting, Design, Development of Networks Software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA Woes.
Jon Simola wrote: On 7/19/05, Tony Byrne [EMAIL PROTECTED] wrote: I'm totally confused. I don't know enough about SMART to know whether I'm looking at real failing drives or some bug exposed by the interaction between drive firmware, hd controller and FreeBSD. What I've recently learned the hard way is that desktop drives have no place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). I have to agree with this opinion, I recently had a WD1600JD SATA fail within a couple months of installation, and the warranty replacement failed within a week. First drive failed autodetection and made servo ticking noises. Second drive had many bad sectors. Add this to the pile of dead 3yr-old 40GB WD drives from all the workstations around here. I install SATA drives in duplicate and triplicate for this reason. Preferably in removable bays with a fan. I assume they're bad out of the box... I write them full of zeros with DD, then read it all back, then do it again. If I don't get read errors then I install them. Joe Koberg joe at osoft dot us ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM xSeries 335 and FreeBSD 5 STABLE. SMP problem
On 7/19/05, Alexander Markov [EMAIL PROTECTED] wrote: If you unload kernel and load it again at boot manually, can 335 boot? I have one 336 with 5.4 that must use this trick to boot, otherwise it hangs after ipfw2 initialized. On the other hand, I have 3 335 installed with 5.4 running SMP smoothly. Nope, this trick doesn't work for me :-( And btw, do you have LSI Logic SCSI controller on your 335? Sure. It is mpt0: LSILogic 1030 Ultra4 Adapter port 0x2300-0x23ff mem 0xfbfe-0xfbfefff I have tried it with RAID1 (with patch, performance is fine) and It can boot with/without the patch. Anyway, I use gmirror now. I'll try to upgrade BIOS today, for it seems to be the only difference between my and people in the list's hardware. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA Woes.
On 7/19/05, Wilko Bulte [EMAIL PROTECTED] wrote: On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). Properly cooled? Yeah, they're in the Supermicro 811 chassis with hotswap SATA sleds. There's a decent amount of air flowing over the drives, and SMART says they're running about 26C. Compared to my 10Krpm SCSI array that I've burned my fingers on, frequently. -- Jon Simola Systems Administrator ABC Communications ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Perl 5.8.7 dumps core on quotewords
Pavel A Crasotin wrote: Yes, i have installed perl5.8.7 from ports And yes, i have run the perl-after-upgrade script with -f option Sorry then that it's not a simple thing. I just started looking at cricket myself, and don't have a fully working installation yet (I still need to tweak the Apache config to match the local environment, or else tweak the local env to match cricket's assumptions). However, I can report that using compile, collector and graph.cgi from the command line works fine for me. On the other hand... I just ran your test script and got: Bus error (core dumped) Anyone else have clues? Since it's easily repeatable in different environments, maybe send-pr it as a demonstrable bug? -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atapicam problems
On 7/17/05, John Van Sickle [EMAIL PROTECTED] wrote: Hi, After a day or two I keep losing my /dev/cd0 and /dev/cd1 devices. When this happens I'm able to reboot and everything works again. By that I mean the drives show up in /dev again and 'camcontrol devlist' lists them. I haven't had any errors burning dvds/cds either. My log message gives me the following info after I lose the drives: atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready (probe2:ata1:0:0:0): Lost target 0??? I noticed the problem about two or so weeks ago. I tried running 'camcontrol rescan all' and 'camcontrol reset all' but it didn't help. I'd also like to note that I don't have atapicd in my kernel or acpi enabled. Not sure if that matters (hasn't in the past). Thanks for your time. uname -a FreeBSD workstation.insightbb.com http://workstation.insightbb.com 5.4-STABLE FreeBSD 5.4-STABLE #0: Fri Jul 15 20:38:58 EDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAMSON i386 camcontrol devlist Apple Co iPod 2700 at scbus0 target 0 lun 0 (pass0,da0) _NEC DVD_RW ND-3540A 1.01 at scbus2 target 0 lun 0 (pass1,cd0) PIONEER DVD-RW DVR-106D 1.07 at scbus2 target 1 lun 0 (pass2,cd1) dmesg | grep cd cd0 at ata1 bus 0 target 0 lun 0 cd0: _NEC DVD_RW ND-3540A 1.01 Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ata1 bus 0 target 1 lun 0 cd1: PIONEER DVD-RW DVR-106D 1.07 Removable CD-ROM SCSI-0 device cd1: 16.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present info from 'pciconf -vl' on my ata chipset: [EMAIL PROTECTED]:4:1: class=0x01018a card=0x chip=0x05711106 rev=0x06 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82 EIDE Controller (All VIA Chipsets)' class = mass storage subclass = ATA kernel config: machine i386 cpu I686_CPU ident SAMSON # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapifd # ATAPI floppy drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. # Parallel port device ppbus # Parallel port bus (required) # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random #
6-BETA1 PAE kernel doesn't build
Hello, The PAE kernel of 6-BETA1 only builds after disabling devices ural and ral. Ronald. PS: 6-BETA1 iso booted on a system with new hardware where my college didn't get linux booted. ;-) -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Q: RT32 (Request Tracker) + jail
Greetings, I would like to have RT running in a jailed environment. The challenge, it seems, will be to get sendmail running in the same jailed environment as RT and the other components. For those not so familiar with the components of RT, the jail would include apache1.3+modperl, MySQL, sendmail, and RT. That's a lot of stuff to get working in there! (but fortunately FreeBSD jails seem straightforward and easy) ^_^ I expect sendmail to be the real problem of the above bunch. Has anyone actually tried to do this with a big multi-part app like RT (I have not spotted anyone's documented attempts on Google) and would be willing to share to the list? Does anyone else wonder if I've lost it? (Don't answer that)... ^_^ Thanks, John H. Nyhuis Sr. Computer Specialist Dept. of Pediatrics HS RR349B, Box 356320 University of Washington Desk: (206)-685-3884 [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Q: RT32 (Request Tracker) + jail
In the last episode (Jul 19), J. Nyhuis said: I would like to have RT running in a jailed environment. The challenge, it seems, will be to get sendmail running in the same jailed environment as RT and the other components. For those not so familiar with the components of RT, the jail would include apache1.3+modperl, MySQL, sendmail, and RT. That's a lot of stuff to get working in there! (but fortunately FreeBSD jails seem straightforward and easy) ^_^ I expect sendmail to be the real problem of the above bunch. Sendmail should do just fine, I'd think. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atapicam problems
On Tue, 19 Jul 2005, John Van Sickle wrote: Anyone? Or is there another mailing list I should try? John, I'm afraid I can't help you myself, but you might want to try [EMAIL PROTECTED] Hope you have more luck there! David Adam [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On 18 Jul, Matthias Buelow wrote: Paul Mather [EMAIL PROTECTED] writes: Why would that necessarily be more successful? If the outstanding buffers count is not reducing between time intervals, it is most likely because there is some underlying hardware problem (e.g., a bad block). If the count still persists in staying put, it likely means whatever the hardware is doing to try and fix things (e.g., write reallocation) isn't working, and so the kernel may as well give up. So the kernel is relying on guesswork whether the buffers are flushed or not... You can enumerate the buffers and *try* to write them, but that doesn't guarantee they will be written successfully any more than observing the relative number left outstanding. That's rather nonsensical. If I write each buffer synchronously (and wait for the disk's response) this is for sure a lot more reliable than observing changes in the number of remaining buffers. I mean, where's the sense in the latter? It would be analogous to, in userspace, having to monitor write(2) continuously over a given time interval and check whether the number it returns eventually reaches zero. That's complete madness, imho. During syncer shutdown, the numbers being printed are actually the number of vnodes that have dirty buffers. The syncer walks the list of vnodes with dirty buffers any synchronously flushes each one to disk (modulo whatever write-caching is done by the drive). The reason that the monitors the number of dirty vnodes instead of just interating once over the list is that with softupdates, flushing one vnode to disk can cause another vnode to be dirtied and put on the list, so it can take multiple passes to flush all the dirty vnodes. Its normal to see this if the machine was at least moderately busy before being shut down. The number of dirty vnodes will start off at a high number, decrease rapidly at first, and then decrease to zero. It is not unusual to see the number bounce from zero back into the low single digits a few times before stabilizing at zero and triggering the syncer termination code. The syncer shutdown algorithm could definitely be improved to speed it up. I didn't want it to push out too many vnodes at the start of the shutdown sequence, but later in the sequence the delay intervals could be shortened and more worklist buckets could be visited per interval to speed the shutdown. One possible complication that I worry about is that the new vnodes being added to the list might not be added synchronously, so if the syncer processes the worklist and shuts down too quickly it might miss vnodes that got added too late. I've never seen a syncer shutdown timeout, though it could happen if either the underlying media became unwriteable or if a process got wedged while holding a vnode lock. In either case, it might never be possible to flush the dirty vnodes in question. The final sync code in boot() just iterated over the dirty buffers, but it was not unusual for it to get stuck on mutually dependent buffers. I would see this quite frequently if I did a shutdown immediately after running mergemaster. The final sync code would flush all but the last few buffers and finally time out. This problem was my motivation for adding the shutdown code to the syncer so that the final sync code would hopefully not have anything to do. The final sync code also gets confused if you have any ext2 file systems mounted (even read-only) and times out while waiting for the ext2 file system to release its private buffers (which only happens when the file system is unmounted). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On 16 Jul, David Taylor wrote: On Sat, 16 Jul 2005, Matthias Buelow wrote: David Taylor [EMAIL PROTECTED] writes: A corrupted journal can be detected. If it's corrupted, discard the whole thing, or only the relevant entry. The filesystem will remain consistent. If track corruption occurs after the journal is written, it doesn't matter, since at boot the journal will be replayed and all operations will be performed once more. The track which is corrupted could contain data that wasn't written to in months. How would the journal help? I don't understand this question. When the drive is powered off, the track being written to at that point may be corrupted, right? That track may contain sectors that the OS did't change. These sectors would not be mentioned in the journal. How would a journaling fs fix the corruption? I suppose this could be avoided by requiring that all writes (and journal entries) somehow correspond to a full track. (Which I suppose they may do already, but I don't think so). The track size is not constant. There are more sectors in the outer cylinder tracks than there are in inner cylinder tracks. I'm not even sure if it is possible to extract the detailed geometry info from the drive. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On 14 Jul, Matthias Buelow wrote: Kevin Oberman wrote: How can I fix it on my system? SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. You do NOT want to do that. Not only will performance drop brutally (example: drop to 1/5th of normal write speed for sequential writes, probably worse for random writes) but it will also significantly reduce the lifetime of your disk. Modern disks are designed to be used with the write-back cache enabled, so don't turn it off. There's not much performance difference with SCSI if write caching is disabled. Typical SCSI drives can handle ~63 outstanding read and write transactions and can sort them into a somewhat optimal order if tagged command queuing is in use. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. No, the problem is that FreeBSD doesn't implement request barriers and that softupdates is flawed by design and seemingly could not make use of them, even if they were available (because, as I understand it, it relies on a total ordering of all writes, unlike the partial ordering necessary for a journalled fs). Softupdates only needs to be partial ordering. It just needs to be notified when the data hits the platter so that it can send any dependent writes to the disk. Wouldn't the use of barriers have the potential to force a lot of unrelated cached write data to be written much earlier than necessary? If so, there would seem to be a performance penalty under certain workloads, though performance would still be better than with write-caching disabled. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On 14 Jul, Kevin Oberman wrote: Date: Thu, 14 Jul 2005 20:38:15 +0200 From: Anatoliy Dmytriyev [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hello, everybody! I have found unusual and dangerous situation with shutdown process: I did a copy of 200 GB data on the 870 GB partition (softupdates is enabled) by cp command. It took a lot of time when I did umount for this partition exactly after cp, but procedure finished correctly. When you unmounted the file system, that should have flushed all the dirty files to the disk. In case, if I did âshutdown âh(r)â, also exactly after cp, the shutdown procedure waited for âsyncâ (umounting of the file system) but sync process was terminated by timeout, and fsck checked and did correction of the file system after boot. Did the timeout occur during the syncer shutdown, or at the syncing disks ... step. Did you have any ext2 file systems mounted? These should be manually unmounted before shutdown because they confuse the final sync code. System 5.4-stable, RAM 4GB, processor P-IV 3GHz. How can I fix it on my system? SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. That should only make a difference in a power-fail situation, and it only makes a difference if the only unwritten data is in the drive's write cache. I am not sure if write-cache can be turned off on SCSI, but SCSI drives seem less likely to lie about when the data is actually flushed to the drive. Yes it can, and I recommend it. Use the camcontrol modepage command to set the WCE bit to 0. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
OS suddenly VERY busy
Hello! After a couple of huge tarball extracts (`make extract' in jdk14 and jdk15) I noticed, things are a little slower. During the extracts, the mouse was moving with visible jerks. Indeed, the system seems VERY busy: 11 usersLoad 1.18 1.52 1.40 Jul 20 00:14 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1060360 105932 1341624 145252 151016 count All 1750432 115908 8911872 174532 pages zfod Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow1277 total 4 1146 1819 345 443k 1640 672 266572 wire 4 irq1: atkb 1204008 act1004 irq0: clk 84.7%Sys 0.0%Intr 15.3%User 0.0%Nice 0.0%Idl 241536 inact irq6: fdc0 |||||||||| 62232 cache 128 irq8: rtc ==88784 freeirq9: acpi daefr 113 irq12: psm Namei Name-cacheDir-cache prcfr irq15: ata Calls hits% hits% react irq16: ahc 3030 3030 100 pdwak26 irq17: pcm pdpgs irq18: fwo Disks da0 cd0 cd1 pass0 pass1 pass2 intrn irq19: ohc KB/t 4.00 0.00 0.00 0.00 0.00 0.00 218912 buf irq27: skc tps 2 0 0 0 0 0 21 dirty 2 irq29: cis MB/s 0.01 0.00 0.00 0.00 0.00 0.00 10 desiredvnodes % busy0 0 0 0 0 0 92043 numvnodes The machine is idle and is not doing anything in user-space according to both top and vmstat's pigs display. Yet it is noticably slower. Trying to compile something pushes the load above 2. What is it doing? This is a single-CPU Opteron running: FreeBSD 5.4-STABLE #0: Fri Jun 10 09:11:30 EDT 2005 amd64 The box has 2Gb of RAM, but NO SWAP. Any ideas? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OS suddenly VERY busy
Mikhail T. wrote this message on Wed, Jul 20, 2005 at 00:19 -0400: After a couple of huge tarball extracts (`make extract' in jdk14 and jdk15) I noticed, things are a little slower. During the extracts, the mouse was moving with visible jerks. Indeed, the system seems VERY busy: 11 usersLoad 1.18 1.52 1.40 Jul 20 00:14 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1060360 105932 1341624 145252 151016 count All 1750432 115908 8911872 174532 pages zfod Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow1277 total 4 1146 1819 345 443k 1640 672 266572 wire 4 irq1: atkb well, I'd say 443k syscalls/time interval isn't doing nothing... [...] The machine is idle and is not doing anything in user-space according to both top and vmstat's pigs display. the problem is that your machine is so fast that all of the processes that are running are exiting before they can be observed by pigs or top (or even accumulate enough cpu time to be worth showing)... Yet it is noticably slower. Trying to compile something pushes the load above 2. What is it doing? This is a single-CPU Opteron running: FreeBSD 5.4-STABLE #0: Fri Jun 10 09:11:30 EDT 2005 amd64 The box has 2Gb of RAM, but NO SWAP. run ps lax a few times, and notice which process is fork bombing your box by seeing which process has the most changing children... (i.e. the ppid, 3rd column, of the process that isn't in the next run)... sort -n +1 -2 + diff will help find which ones... ps lax | sort -n +1 -2 tmpa; sleep 2; ps lax | sort -n +1 -2 tmpb; diff tmpa tmpb look at the ppid (3rd column) of any new or missing processes, and you probably have your culprit... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
