Re: possible zfs bug? lost all pools
Did you run '/etc/rc.d.hostid start' first? IIRC, it is needed before zfs will mount in single-user mode. Just curious, as I've been wanting to fiddle around with ZFS in my spare time... what is the solution here if you have failed hardware and you want to move your ZFS disks to another system (with a different host id)? 'zpool import' possible with a -f. man 1m zpool. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ubench on v6 a v7
My home computer (no internet access, cannot share results :-) is single processor Athlon 64 on 2250 Mhz/512 KB L2. Visually I have seen that on stable it doesn't behave as speedily as on FreeBSD number 6. I have checked utility in subject (which is probably not the best alternative) and it shows me on memory test half of the speed that was in v6 while using default MALLOC_OPTIONS at each version. There could be certain speed up changing it but IMHO there can not be any we to make it as fast as in previous version. Is there anyone who could make a logical explanation? (I think it has something to do with new malloc optimization for multi processor systems but I might compiled also libc on FreeBSD 7 with wrong options). Even using simple compat6x libc (with libmap.conf) helps to speed up things there. All those measurement are my just my non generalized opinion and I hope I am wrong :-) Karel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk access/MPT under ESX3.5
Hello, monitor# camcontrol negotiate 0:0 -W 16 Current Parameters: (pass0:mpt0:0:0:0): sync parameter: 0 (pass0:mpt0:0:0:0): offset: 0 (pass0:mpt0:0:0:0): bus width: 8 bits (pass0:mpt0:0:0:0): disconnection is enabled (pass0:mpt0:0:0:0): tagged queueing is enabled monitor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 32.421679 secs (32341817 bytes/sec) monitor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 20.355797 secs (51512402 bytes/sec) No improvements. But it looks like it did not renegotiated the transfers data rate that for some odd reasons are setted as 3.3MB/S instead of 320mb/s. I made some tests using linux 2.18 (debian): debiantest:/home/daniel# uname -a Linux debiantest 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686 GNU/Linux scsi0 : ioc0: LSI53C1030, FwRev=h, Ports=1, MaxQ=128, IRQ=169 Vendor: VMwareModel: Virtual disk Rev: 1.0 Type: Direct-Access ANSI SCSI revision: 02 target0:0:0: Beginning Domain Validation target0:0:0: Domain Validation skipping write tests target0:0:0: Ending Domain Validation target0:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset 127) debiantest:/home/daniel# dd if=/dev/zero of=dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 5.01316 seconds, 209 MB/s =( Shunsuke SHINOMIYA ha scritto: da0 at mpt0 bus 0 target 0 lun 0 da0: VMware Virtual disk 1.0 Fixed Direct Access SCSI-2 device da0: 3.300MB/s transfers da0: Command Queueing Enabled da0: 34816MB (71303168 512 byte sectors: 255H 63S/T 4438C) Can you re-negotiate transfer rate, using camcontrol? `camcontrol negotiate 0:0 -W 16' might improve that transfer settings. camcontrol needs passthrough device support in a kernel. -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Disk access/MPT under ESX3.5
Hello, Daniel Can you execute camcontrol with some parameters again? For example, `camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000'. -- Shunsuke SHINOMIYA [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: Disk access/MPT under ESX3.5
Oh, btw, this make improvements only on 7.0-Release and Stable using ULE scheduler. - Using 4BSD Scheduler will improve disk access speed but no cpu usage. - On FreeBSD 6.2 and 6.3 this make no difference on cpu usage/speed (about 60mb/sec maximum using 100% cpu). Thanks, Daniel Daniel Ponticello ha scritto: Much better: endevor# camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000 Current Parameters: (pass0:mpt0:0:0:0): sync parameter: 8 (pass0:mpt0:0:0:0): frequency: 160.000MHz (pass0:mpt0:0:0:0): offset: 127 (pass0:mpt0:0:0:0): bus width: 16 bits (pass0:mpt0:0:0:0): disconnection is enabled (pass0:mpt0:0:0:0): tagged queueing is enabled endevor# camcontrol inquiry da0 pass0: VMware Virtual disk 1.0 Fixed Direct Access SCSI-2 device pass0: 80.000MB/s transfers (40.000MHz, offset 127, 16bit), Command Queueing Enabled endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 20.364577 secs (51490193 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.525560 secs (90978311 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.833996 secs (88607094 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 12.779979 secs (82048335 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.812926 secs (88765137 bytes/sec) Also CPU system load is lower: 40% instead of 70% on dual cpu, and 23% instead of 50% on quad cpu. Still not as fast as debian, but really really usable now =) how i can make it mantain these settings at boot? Also, do you know why the first dd was slower? Thanks, Daniel Shunsuke SHINOMIYA ha scritto: Hello, Daniel Can you execute camcontrol with some parameters again? For example, `camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000'. -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Suspend/resume on IBM X31
Greetings I am having trouble with suspend/resume on my Thinkpad X31, running 7.0-STABLE as of April 23. Any help would be appreciated. First problem: When I run acpiconf -s3 from mulituser mode, the system suspends immediately, without executing /etc/rc.suspend (which has mode 755); then on resume, I get a panic. Second problem: When the system panics, I don't get a dump (or textdump for that matter, when I turn them on); in the boot messages, I see kernel dumps on /dev/ad0s2b and then later (from memory), Looking for core dumps on /dev/ad0s2b savecore: no dumps found or somesuch. I know from trying out textdumps that dumping works in other circumstances. These issues together make it hard to debug further, but I did a few tests in single-user mode. First, with no services running, acpiconf -s3 seems to work OK (although /etc/rc.suspend is still not executed) - I can suspend and resume and the machine keeps working. See: http://homepages.ihug.co.nz/~sweetnavelorange/dmesg.1 for my dmesg after one successful cycle - there are a few warnings to do with firewire. However if I start powerd before suspending, I get the following extra kernel messages (hand transcribed): acpi_ec0: warning: EC done before starting event wait subdisk0: detached ad0: detached and any subsequent attempts to access the disk (eg. dmesg/some/file, kldstat) produce errors of the form: g_vfs_done(): ad0s2e[READ(offset=8478572544, length=16384)] error=6 and eventually another panic. Of course if /etc/rc.suspend worked, I could disable powerd before suspending :-/. If anyone has any ideas, I'd love to hear them, and I'll provide any more info that's needed. Other than this, I'm really pleased with FreeBSD 7 - thanks all! -James Butler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk access/MPT under ESX3.5
Much better: endevor# camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000 Current Parameters: (pass0:mpt0:0:0:0): sync parameter: 8 (pass0:mpt0:0:0:0): frequency: 160.000MHz (pass0:mpt0:0:0:0): offset: 127 (pass0:mpt0:0:0:0): bus width: 16 bits (pass0:mpt0:0:0:0): disconnection is enabled (pass0:mpt0:0:0:0): tagged queueing is enabled endevor# camcontrol inquiry da0 pass0: VMware Virtual disk 1.0 Fixed Direct Access SCSI-2 device pass0: 80.000MB/s transfers (40.000MHz, offset 127, 16bit), Command Queueing Enabled endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 20.364577 secs (51490193 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.525560 secs (90978311 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.833996 secs (88607094 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 12.779979 secs (82048335 bytes/sec) endevor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 11.812926 secs (88765137 bytes/sec) Also CPU system load is lower: 40% instead of 70% on dual cpu, and 23% instead of 50% on quad cpu. Still not as fast as debian, but really really usable now =) how i can make it mantain these settings at boot? Also, do you know why the first dd was slower? Thanks, Daniel Shunsuke SHINOMIYA ha scritto: Hello, Daniel Can you execute camcontrol with some parameters again? For example, `camcontrol negotiate 0:0 -W 16 -O 127 -R 40.000'. -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Suspend/resume on IBM X31
On Mon, May 19, 2008 at 10:24:43PM +1200, James Butler wrote: Second problem: When the system panics, I don't get a dump (or textdump for that matter, when I turn them on); in the boot messages, I see kernel dumps on /dev/ad0s2b and then later (from memory), Looking for core dumps on /dev/ad0s2b savecore: no dumps found or somesuch. I know from trying out textdumps that dumping works in other circumstances. This is a known problem, but is difficult to solve (chicken-and-egg situation). There's an open PR for it. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: udf
on 16/05/2008 19:48 Scott Long said the following: There is no write support in UDF in FreeBSD. When I wrote the fs code, packet writing was the only way to do discrete writes, and it's very hard to make that work with a traditional VM system. Now with DVD+R, it's probably worth someone's time to look at it (though the append-only nature of +R means that there are still some nasty VM complications to deal with). Until that happens, mkisofs can be used to create a static UDF filesystem. BTW, Remko has kindly notified me that Reinoud Zandijk has completed his long work on UDF write support in NetBSD. I think that porting his work is our best chance to get write support in FreeBSD too. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: udf
Andriy Gapon wrote: on 16/05/2008 19:48 Scott Long said the following: There is no write support in UDF in FreeBSD. When I wrote the fs code, packet writing was the only way to do discrete writes, and it's very hard to make that work with a traditional VM system. Now with DVD+R, it's probably worth someone's time to look at it (though the append-only nature of +R means that there are still some nasty VM complications to deal with). Until that happens, mkisofs can be used to create a static UDF filesystem. BTW, Remko has kindly notified me that Reinoud Zandijk has completed his long work on UDF write support in NetBSD. I think that porting his work is our best chance to get write support in FreeBSD too. I think you'll find that implementing VOPs and filling in UDF data structures will be easy, while interacting with the VM will be many orders of magnitude harder. Still it should be a fun challenge for someone to do. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildworld Fails RELENG_7
Sources checked out yesterday, updated this morning using cvsup and repository at cvsup12.freebsd.org. The build fails in /usr/src/lib/libc /usr/bin/gcc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/fcntl.c /usr/src/lib/libc/sys/fcntl.c: In function 'fcntl': /usr/src/lib/libc/sys/fcntl.c:42: error: storage size of 'ofl' isn't known /usr/src/lib/libc/sys/fcntl.c:67: error: 'F_OGETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:67: error: (Each undeclared identifier is reported only once /usr/src/lib/libc/sys/fcntl.c:67: error: for each function it appears in.) /usr/src/lib/libc/sys/fcntl.c:74: error: 'struct flock' has no member named 'l_sysid' /usr/src/lib/libc/sys/fcntl.c:79: error: 'F_OSETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:82: error: 'F_OSETLKW' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:42: warning: unused variable 'ofl' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? On 19 May 2008, at 16:17, Dave Uhring wrote: Sources checked out yesterday, updated this morning using cvsup and repository at cvsup12.freebsd.org. The build fails in /usr/src/lib/ libc /usr/bin/gcc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -I/ usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/ src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../ contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/ libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES - DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING - DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno- uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/fcntl.c /usr/src/lib/libc/sys/fcntl.c: In function 'fcntl': /usr/src/lib/libc/sys/fcntl.c:42: error: storage size of 'ofl' isn't known /usr/src/lib/libc/sys/fcntl.c:67: error: 'F_OGETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:67: error: (Each undeclared identifier is reported only once /usr/src/lib/libc/sys/fcntl.c:67: error: for each function it appears in.) /usr/src/lib/libc/sys/fcntl.c:74: error: 'struct flock' has no member named 'l_sysid' /usr/src/lib/libc/sys/fcntl.c:79: error: 'F_OSETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:82: error: 'F_OSETLKW' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:42: warning: unused variable 'ofl' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: how much memory does increasing max rules for IPFW take up?
On May 18, 2008, at 3:26 AM, Ian Smith wrote: Hashed per flow, (srcip^destip^srcport^dstport) mod curr_dyn_buckets, so packets for both directions of a given flow hash to the same bucket. In the case you mention, you could likely expect reasonable distribution by src_ip/src_port. Thanks for the detailed info. This really helps. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible zfs bug? lost all pools
JoaoBR [EMAIL PROTECTED] wrote: man page thar zfs can not be a dump device, not sure if I understand it as meant but I can dump to zfs very well and fast as long as recordsize=128 I assume you tried dump(8), while the sentence in the man page is about using a ZFS volume as dumpon(8) target: %sudo dumpon -v /dev/zvol/tank/swap dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported Fabian signature.asc Description: PGP signature
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. [EMAIL PROTECTED] /usr/include/sys]# ls *.orig fcntl.h.orig tree.h.orig umtx.h.orig Just got another stoppage in /usr/src/gnu/lib/libstdc++. /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory The #include declaration has that header file in the local directory. It exists in /usr/obj, however. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:38:25AM -0500, Dave Uhring wrote: On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. [EMAIL PROTECTED] /usr/include/sys]# ls *.orig fcntl.h.orig tree.h.orig umtx.h.orig Just got another stoppage in /usr/src/gnu/lib/libstdc++. /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory The #include declaration has that header file in the local directory. It exists in /usr/obj, however. Is there some reason you're using -DNO_CLEAN, and haven't just nuked /usr/obj/* and done buildworld normally? I can't reproduce any of this behaviour on any of our RELENG_7 systems. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On 19 May 2008, at 17:38, Dave Uhring wrote: On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. You should never have to copy any header files to /usr/include to get a buildworld to work. Try without the -DNO_CLEAN and if that still fails, clean your /usr/obj (e.g. with rm -rf /usr/obj/*). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: udf
: BTW, Remko has kindly notified me that Reinoud Zandijk has completed his : long work on UDF write support in NetBSD. I think that porting his work : is our best chance to get write support in FreeBSD too. : : :I think you'll find that implementing VOPs and filling in UDF data :structures will be easy, while interacting with the VM will be many :orders of magnitude harder. Still it should be a fun challenge for :someone to do. : :Scott One avenue that can be persued would be to finish the UIO_NOCOPY support in the vm/vnode_pager.c. You have UIO_NOCOPY support for the putpages code but not the getpages code. If that were done the VFS can simply use VMIO-backed buffer cache buffers (they have to be VMIO-backed for UIO_NOCOPY to work properly)... and not have to deal with getpages or putpages at all. The vnode pager would convert them to a UIO_NOCOPY VOP_READ or VOP_WRITE as appropriate. The entire VM coding burden winds up being in the kernel proper and not in the VFS at all. IMHO implementing per-VFS getpages/putpages is an exercise in frustration, to be avoided at all costs. Plus once you have a generic getpages/putpages layer in vm/vnode_pager.c the VFS code no longer has to mess with VM pages anywhere and winds up being far more portable. I did the necessary work in DragonFly in order to avoid having to mess with VM pages in HAMMER. Primary work: * It is a good idea to require that all vnode-based buffer cache buffers be B_VMIO backed (aka have a VM object). It ensures a clean interface and avoids confusion, and also cleans up numerous special cases that are simply not needed in this day and age. * Add support for UIO_NOCOPY in generic getpages. Get rid of all the special cases for small-block filesystems in getpages. Make it completely generic and simply issue the UIO_NOCOPY VOP_READ/VOP_WRITE. * Make minor adjustments to existing VFSs (but nothing prevents them from still rolling their own getpages/putpages so no major changes are needed). And then enjoy the greatly simplified VFS interactions that result. I would also recommend removing the VOP_BMAP() from the generic getpages/putpages code and simply letting the VFS's VOP_READ/VOP_WRITE deal with it. The BMAP calls were being made from getpages/putpages to check for discontiguous blocks, to avoid unnecessary disk seeks. Those checks are virtually worthless on today's modern hardware particularly since filesystems already localize most data accesses. In other words, if your filesystem is fragmented you are going to be doing the seeks anyway, probably. -Matt Matthew Dillon [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: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 05:42:56PM +0100, Doug Rabson wrote: On 19 May 2008, at 17:38, Dave Uhring wrote: On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. You should never have to copy any header files to /usr/include to get a buildworld to work. Try without the -DNO_CLEAN and if that still fails, clean your /usr/obj (e.g. with rm -rf /usr/obj/*). The build is going nowhere without the correct header files in /usr/include/sys. I have repeatedly cleaned /usr/obj to no avail, but I have a better method for doing that: umount /usr/obj newfs /dev/da4s2f mount /usr/obj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: Is there some reason you're using -DNO_CLEAN, and haven't just nuked /usr/obj/* and done buildworld normally? I can't reproduce any of this behaviour on any of our RELENG_7 systems. I have repeately nuked /usr/obj. That is not going to put updated header files where they need to be. I'm using -DNO_CLEAN in order to get the system to a point where a build just might succeed without -DNO_CLEAN and I'm not getting there without some header files being in the right place. Remember I'm starting from a RELEASE userland. This is just about as bad as jumping from one full release to the next :( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:54:21AM -0500, Dave Uhring wrote: On Mon, May 19, 2008 at 05:42:56PM +0100, Doug Rabson wrote: On 19 May 2008, at 17:38, Dave Uhring wrote: On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. You should never have to copy any header files to /usr/include to get a buildworld to work. Try without the -DNO_CLEAN and if that still fails, clean your /usr/obj (e.g. with rm -rf /usr/obj/*). The build is going nowhere without the correct header files in /usr/include/sys. Is there breakage of some sort being caused by your make.conf or (less probable) your src.conf? Any filesystem corruption (boot single user and force fsck on all the filesystems)? In all the years I've used FreeBSD, I've never had to copy include files from parts of /usr/src to get buildworld to work, so this is very odd behaviour. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On 19 May 2008, at 17:58, Dave Uhring wrote: On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: Is there some reason you're using -DNO_CLEAN, and haven't just nuked /usr/obj/* and done buildworld normally? I can't reproduce any of this behaviour on any of our RELENG_7 systems. I have repeately nuked /usr/obj. That is not going to put updated header files where they need to be. I'm using -DNO_CLEAN in order to get the system to a point where a build just might succeed without -DNO_CLEAN and I'm not getting there without some header files being in the right place. Remember I'm starting from a RELEASE userland. This is just about as bad as jumping from one full release to the next :( The thing is that a working buildworld doesn't depend on headers from / usr/include. One of the first thing it does is install a set of new headers in somewhere like /usr/obj/usr/src/tmp. At this point, it might be useful to see a log of a failed buildworld attempt to see what is going wrong. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 09:59:25AM -0700, Jeremy Chadwick wrote: Is there breakage of some sort being caused by your make.conf or (less probable) your src.conf? Any filesystem corruption (boot single user and force fsck on all the filesystems)? [EMAIL PROTECTED] /etc]$ grep -v ^# make.conf CPUTYPE?=athlon64 CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 CXXFLAGS+= -fconserve-space MAKE_SHELL?=sh COPTFLAGS= -O -pipe INSTALL=install -C MTREE_FOLLOWS_SYMLINKS= -L ENABLE_SUID_SSH= NO_SENDMAIL= NO_PROFILE= DOC_LANG= en_US.ISO8859-1 src.conf is untouched. In all the years I've used FreeBSD, I've never had to copy include files from parts of /usr/src to get buildworld to work, so this is very odd behaviour. Start with a clean RELEASE userland and try to build RELENG_7 today :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:58:07AM -0500, Dave Uhring wrote: On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: Is there some reason you're using -DNO_CLEAN, and haven't just nuked /usr/obj/* and done buildworld normally? I can't reproduce any of this behaviour on any of our RELENG_7 systems. I have repeately nuked /usr/obj. That is not going to put updated header files where they need to be. It's apparent you don't quite understand. The updated header files reside in /usr/src, and ***remain there*** until installworld is done. The buildworld process will include the updated header files, trumping most of those which are in /usr/include. You do not need to copy any files from /usr/src/sys/sys to /usr/include or anywhere else to get buildworld to work. If you're having to do that, the problem is very likely elsewhere. I'm using -DNO_CLEAN in order to get the system to a point where a build just might succeed without -DNO_CLEAN and I'm not getting there without some header files being in the right place. Remember I'm starting from a RELEASE userland. This is just about as bad as jumping from one full release to the next :( Okay, so you installed 7.0-RELEASE on a machine. Did you choose to install src from the CD/DVD when installing? (If so, you will need to adopt the version you installed to the current version, see the cvsup FAQ here: http://www.cvsup.org/faq.html#caniadopt -- and you'll need to do this for ports if you installed the ports tree off the CD/DVD as well) If you csup'd, what tag did you use? RELENG_7? I'm assuming so. Did you use src-all, or are you using a custom supfile? We use /usr/share/examples/cvsup/stable-supfile. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 12:03:34PM -0500, Dave Uhring wrote: On Mon, May 19, 2008 at 09:59:25AM -0700, Jeremy Chadwick wrote: Is there breakage of some sort being caused by your make.conf or (less probable) your src.conf? Any filesystem corruption (boot single user and force fsck on all the filesystems)? [EMAIL PROTECTED] /etc]$ grep -v ^# make.conf CPUTYPE?=athlon64 CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 CXXFLAGS+= -fconserve-space MAKE_SHELL?=sh COPTFLAGS= -O -pipe INSTALL=install -C MTREE_FOLLOWS_SYMLINKS= -L ENABLE_SUID_SSH= NO_SENDMAIL= NO_PROFILE= DOC_LANG= en_US.ISO8859-1 Can you please comment out all of the above and see if the problem persists? In all the years I've used FreeBSD, I've never had to copy include files from parts of /usr/src to get buildworld to work, so this is very odd behaviour. Start with a clean RELEASE userland and try to build RELENG_7 today :) Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money is on that I won't be able to reproduce the problem. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:06:19AM -0700, Jeremy Chadwick wrote: On Mon, May 19, 2008 at 12:03:34PM -0500, Dave Uhring wrote: [EMAIL PROTECTED] /etc]$ grep -v ^# make.conf CPUTYPE?=athlon64 CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 CXXFLAGS+= -fconserve-space MAKE_SHELL?=sh COPTFLAGS= -O -pipe INSTALL=install -C MTREE_FOLLOWS_SYMLINKS= -L ENABLE_SUID_SSH= NO_SENDMAIL= NO_PROFILE= DOC_LANG= en_US.ISO8859-1 Can you please comment out all of the above and see if the problem persists? Sure, but that is not going to put the correct headers where the sources are looking for them. Nor is it going to put groff headers into a directory where the #include driver.h is declared within a source file and the directory contains *no* headers. In particular, /usr/src/contrib/groff/src/libs/libdriver has no header files at all, yet input.cpp in that directory has these declarations: #include driver.h #include device.h Start with a clean RELEASE userland and try to build RELENG_7 today :) Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money is on that I won't be able to reproduce the problem. VMware? Give me a break! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:02:23AM -0700, David Wolfskill wrote: On Mon, May 19, 2008 at 11:54:21AM -0500, Dave Uhring wrote: The build is going nowhere without the correct header files in /usr/include/sys. That appears to indicate that your build environment is fundamentally broken.. You might consider doing the build within script(1), then making the resulting script file available for folks to examine. I posted the relevant output from make buildworld. Copying the 3 new header files from /usr/src/sys/sys to /usr/include/sys solved my original problem. I'm sure that after a successful buildworld and installworld that the original problem will go away. The problem now is in the build of groff: [EMAIL PROTECTED] /usr/src/contrib/groff/src/devices/grodvi]# ls *.h ls: *.h: No such file or directory However, dvi.cpp in that directory has this: #include driver.h #include nonposix.h #include paper.h ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:06:19AM -0700, Jeremy Chadwick wrote: Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money is on that I won't be able to reproduce the problem. Something I thought of while doing the above: there's been reports in the past of problems with buildworld (or building software in general) bombing out or behaving oddly due to clock issues on the local machine. If you don't use ntpd, consider doing so. Otherwise, at least use ntpdate once to set your clock to something sane. Anyway. I've completed the above using VMware. Installation was 7.0-RELEASE i386. fdisk and label were defaults, and for distributions I chose base, kernels, dict, doc, games, info, man, and catman. (I do not pick src and ports because I don't care to deal with the adoption method.) I also configured the network (nothing out of the ordinary; pure DHCP), and the time zone (PDT). Immediately after the system was up, I did the following: # csup -h cvsup4.freebsd.org -g -L 2 -4 /usr/share/examples/cvsup/stable-supfile This picked up src-all using the RELENG_7 tag. I then attempted a buildworld (cd /usr/src time make -j2 buildworld). It's just begun stage 2.3, but so far no issues. I'll report back in about 30 minutes or so, when it has a chance to finish. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:04:28AM -0700, Jeremy Chadwick wrote: On Mon, May 19, 2008 at 11:58:07AM -0500, Dave Uhring wrote: I have repeately nuked /usr/obj. That is not going to put updated header files where they need to be. It's apparent you don't quite understand. The updated header files reside in /usr/src, and ***remain there*** until installworld is done. That is as it should be. The buildworld process will include the updated header files, trumping most of those which are in /usr/include. Does not happen. The header files included were those from /usr/include/sys, not /usr/src/sys/sys. The errors would not have occurred if the header files in /usr/src/sys/sys were being referenced by sys/header.h In any case, that problem has been solved by putting the updated header files in /usr/include/sys and will be properly fixed when I can finally make installworld. Remember I'm starting from a RELEASE userland. This is just about as bad as jumping from one full release to the next :( Okay, so you installed 7.0-RELEASE on a machine. Did you choose to install src from the CD/DVD when installing? (If so, you will need to adopt the version you installed to the current version, see the cvsup FAQ here: http://www.cvsup.org/faq.html#caniadopt -- and you'll need to do this for ports if you installed the ports tree off the CD/DVD as well) If you csup'd, what tag did you use? RELENG_7? I'm assuming so. Did you use src-all, or are you using a custom supfile? We use /usr/share/examples/cvsup/stable-supfile. Whatever tag was in /usr/share/examples/cvsup/stable-supfile. In fact it is: *default release=cvs tag=RELENG_7 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 06:00:39PM +0100, Doug Rabson wrote: The thing is that a working buildworld doesn't depend on headers from /usr/include. One of the first thing it does is install a set of new headers in somewhere like /usr/obj/usr/src/tmp. At this point, it might be useful to see a log of a failed buildworld attempt to see what is going wrong. Putting the updated header files in /usr/include/sys solved that problem. Whether is was the correct solution or not is moot since the build continued from the previous stoppage in libc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: Something I thought of while doing the above: there's been reports in the past of problems with buildworld (or building software in general) bombing out or behaving oddly due to clock issues on the local machine. If you don't use ntpd, consider doing so. Otherwise, at least use ntpdate once to set your clock to something sane. I hadn't yet started ntpd but [EMAIL PROTECTED] /etc]# ntpdate newton 19 May 13:29:22 ntpdate[55524]: step time server 192.168.0.8 offset -1.044724 sec I doubt that a second off would make any difference. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:02:01AM -0700, David Wolfskill wrote: On Mon, May 19, 2008 at 12:53:58PM -0500, Dave Uhring wrote: I posted the relevant output from make buildworld. Copying the 3 new header files from /usr/src/sys/sys to /usr/include/sys solved my original problem. s/solved/circumvented/ :) Whatever, libc does build now. freebeast(8.0-C)[52] ls -l usr/src/contrib/groff/src/devices/grodvi/*.h ls: No match. freebeast(8.0-C)[53] grep '#include ' usr/src/contrib/groff/src/devices/grodvi/dvi.cpp #include driver.h #include nonposix.h #include paper.h freebeast(8.0-C)[54] The compilation of dvi.cpp uses -I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../src/include (among other things); I expect you will find the needed header files in those directories. If a -I/some/directory is used as a CFLAG then the *include directive must read #include driver.h, *not* #include driver.h. The latter demands that the header file be in the same directory as the source file. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
Dave Uhring [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 11:02:01AM -0700, David Wolfskill wrote: On Mon, May 19, 2008 at 12:53:58PM -0500, Dave Uhring wrote: I posted the relevant output from make buildworld. Copying the 3 new header files from /usr/src/sys/sys to /usr/include/sys solved my original problem. s/solved/circumvented/ :) Whatever, libc does build now. freebeast(8.0-C)[52] ls -l usr/src/contrib/groff/src/devices/grodvi/*.h ls: No match. freebeast(8.0-C)[53] grep '#include ' usr/src/contrib/groff/src/devices/grodvi/dvi.cpp #include driver.h #include nonposix.h #include paper.h freebeast(8.0-C)[54] The compilation of dvi.cpp uses -I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../src/include (among other things); I expect you will find the needed header files in those directories. If a -I/some/directory is used as a CFLAG then the *include directive must read #include driver.h, *not* #include driver.h. The latter demands that the header file be in the same directory as the source file. Not that it necessarily affects what you're going through, but that last statement is incorrect. The double quotes are (according to the C standard) implementation defined, and gcc (like many other compilers) will prefer the local directory for the double quotes, but will search the entire search path if it doesn't find the file there. It also has some really wacky command-line parameters to control which directories are searched (by *both* #include syntaxes) down to a ridiculously fine level. The only use I've ever had for such things was in cross-compile environments targeting multiple architectures in a single build tree, and even then it isn't really necessary. - Lowell -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: This picked up src-all using the RELENG_7 tag. I then attempted a buildworld (cd /usr/src time make -j2 buildworld). It's just begun stage 2.3, but so far no issues. I'll report back in about 30 minutes or so, when it has a chance to finish. The compile has finished successfully. Took 1 hour 15 minutes. Another user also mailed me (privately) adding that he too cannot reproduce this problem. I will attempt the same with your make.conf to see if it's any different. But at this point, it appears the issue is with your system or system configuration. I just wish I knew what was doing it. Any odd filesystem mount flags (output of mount)? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
Dave Uhring wrote: If a -I/some/directory is used as a CFLAG then the *include directive must read #include driver.h, *not* #include driver.h. The latter demands that the header file be in the same directory as the source file. Absolutely not true. Directly from the gcc online manual: GCC looks for headers requested with #include file first in the directory containing the current file, then in the directories as specified by -iquote options, then in the same places it would have looked for a header requested with angle brackets. For example, if /usr/include/sys/stat.h contains #include types.h, GCC looks for types.h first in /usr/include/sys, then in its usual search path. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
geom_raid5 + FreeBSD 7.0-STABLE + 5x500Gb (1.8T UFS volume) -- crashes :(
Hello, Arne.
I try to build storage server for my home (I have a LOT of media
files) with FreeBSD 7, 5xHDD (WD 500Gb) and geom_raid5 (simple
version from perforce, beacuse
http://home.tiscali.de/cmdr_faako/geom_raid5.tbz is not patched for FreeBSD7).
Array FS were created with default arguments:
# graid5 label storage ad6 ad8 ad10 ad12 ad14
# newfs -O2 -U /dev/raid5/storage
# mount /dev/raid5/storage /usr/home/storage
I use additional (sixth) HDD for system, labeled ins tandard way. So,
raid is used only for data, not for swap or booting.
I've started from simple tests: building world with /usr/src on
system disk and obj (MAKEOBJDIRPREFIX) on RAID5.
After first build I've run `rm -rf ${MAKEOBJDIRPREFIX}'. It
returns to shell pretty quickly, and to be sure, that FS is synced I've
tried `umount /usr/home/storage'. I've got DEVICE BUSY!
I've called `df -h' and it shows, that I have NEGATIVE amount of
space on /usr/home/storage (about -14Mb of 1.8Tb). After calling
sync sync sycn, umount finished without errors, but second
later system CRASHED with ffs freed free frag.
After reboot, RAID5 becomes REBUILDING HOT and system crashed again
when fsck start to checks filesystem on RAID :(
And again :( So, I boot to single-user and remove auto-mount of RAID
volume...
Manual run of fsck fails with fsck_ufs: bad inode number 32360448
to nextinode...
Is it problem of UFS or graid5 or what?
--
// Black Lion AKA Lev Serebryakov [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: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 12:16:46PM -0700, Jeremy Chadwick wrote: On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: This picked up src-all using the RELENG_7 tag. I then attempted a buildworld (cd /usr/src time make -j2 buildworld). It's just begun stage 2.3, but so far no issues. I'll report back in about 30 minutes or so, when it has a chance to finish. That is what I did after the first build using the original RELEASE sources and updated using csup. I blew away /usr/src and cvsupped a fresh RELENG_7 source tree. The compile has finished successfully. Took 1 hour 15 minutes. Another user also mailed me (privately) adding that he too cannot reproduce this problem. Last time I succeeded in building world on another box it took 47 minutes :-) That's still a long way from years back when RELENG_4 built in 30 minutes on a machine with an Athlon Tbird 1.2GHz processor. Double the processor speed and quadruple the memory and the build takes 50% longer. I will attempt the same with your make.conf to see if it's any different. But at this point, it appears the issue is with your system or system configuration. I just wish I knew what was doing it. Any odd filesystem mount flags (output of mount)? [EMAIL PROTECTED] /usr/src/contrib/groff]# mount /dev/ad4s2a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad4s2h on /home (ufs, local, soft-updates) /dev/ad4s2e on /usr (ufs, local, soft-updates) /dev/ad4s2g on /usr/local (ufs, local, soft-updates) /dev/ad4s2d on /var (ufs, local, soft-updates) /dev/md0 on /tmp (ufs, local, soft-updates) /dev/ad4s2f on /usr/obj (ufs, asynchronous, local, noatime) [EMAIL PROTECTED] /usr/src/contrib/groff]# Not even an NFS mount. I'm trying to update to FreeBSD-STABLE to use on my home file server. At present it has OpenSolaris installed but that OS does not have the Ethernet driver I need and I want to be able to use 2 Adaptec 29160N HBAs in the system. But I only have 2 PCI slots and I would like to remove the Intel NIC and use the system's on-board nfe NIC. I'll blow away /usr/src and /usr/obj, cvsup the entire RELENG_7 source tree again and once more attempt to buildworld. If that fails, Solaris stays on the server. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom_raid5 + FreeBSD 7.0-STABLE + 5x500Gb (1.8T UFS volume) -- crashes :(
Hello, Arne. You wrote 19 мая 2008 г., 23:42:20: I've called `df -h' and it shows, that I have NEGATIVE amount of space on /usr/home/storage (about -14Mb of 1.8Tb). Negative amount of USED space, sorry. -- // Black Lion AKA Lev Serebryakov [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: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 02:54:31PM -0400, Lowell Gilbert wrote: Dave Uhring [EMAIL PROTECTED] writes: If a -I/some/directory is used as a CFLAG then the *include directive must read #include driver.h, *not* #include driver.h. The latter demands that the header file be in the same directory as the source file. Not that it necessarily affects what you're going through, but that last statement is incorrect. The double quotes are (according to the C standard) implementation defined, and gcc (like many other compilers) will prefer the local directory for the double quotes, but will search the entire search path if it doesn't find the file there. The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: On Mon, May 19, 2008 at 02:54:31PM -0400, Lowell Gilbert wrote: Dave Uhring [EMAIL PROTECTED] writes: If a -I/some/directory is used as a CFLAG then the *include directive must read #include driver.h, *not* #include driver.h. The latter demands that the header file be in the same directory as the source file. Not that it necessarily affects what you're going through, but that last statement is incorrect. The double quotes are (according to the C standard) implementation defined, and gcc (like many other compilers) will prefer the local directory for the double quotes, but will search the entire search path if it doesn't find the file there. The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. This starts to narrow down the problem you're having a bit, I think. Given that this is different from the expected behavior and the behavior others are seeing, this sounds to me like either 1) the wrong compiler or version of the compiler is being found and used in place of the desired gcc instance, or 2) something in your shell or environment is somehow getting into the buildworld environment and causing make or the inner shell to misparse the commandline to gcc. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: On May 19, 2008, at 1:21 PM, Dave Uhring wrote: In any case, that problem has been solved by putting the updated header files in /usr/include/sys and will be properly fixed when I can finally make installworld. I did not have to manually move or copy any header files. *default release=cvs tag=RELENG_7 My build on that, csupped just after seeing your first message in this thread, has just completed. make buildworld worked just fine without error. I'm also on athlon64. All the headers that I needed were in the right places in /usr/src Did you start from a RELEASE source tree and userland? So all I can say is that things worked for me. I really suspect that you got /usr/src and /usr/obj into some sort of inconsistent state. I completely removed both, cvsupped a new RELENG_7 source tree, removed /etc/make.conf and got this: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: 'asm' operand has impossible constraints *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. real8m58.524s user7m18.995s sys 1m22.150s Solaris Nevada b_87 is installing on the server this minute instead of FreeBSD. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On May 19, 2008, at 1:21 PM, Dave Uhring wrote: In any case, that problem has been solved by putting the updated header files in /usr/include/sys and will be properly fixed when I can finally make installworld. I did not have to manually move or copy any header files. *default release=cvs tag=RELENG_7 My build on that, csupped just after seeing your first message in this thread, has just completed. make buildworld worked just fine without error. I'm also on athlon64. All the headers that I needed were in the right places in /usr/src So all I can say is that things worked for me. I really suspect that you got /usr/src and /usr/obj into some sort of inconsistent state. Cheers, -j -- Jeffrey Goldberghttp://www.goldmark.org/jeff/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On 2008-May-19 11:38:25 -0500, Dave Uhring [EMAIL PROTECTED] wrote: Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. You have this backwards. If you are getting wierd buildworld errors, your first step should be to delete /usr/obj and then run 'make clean'. My guess is that you have some cruft in your /usr/src. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpU4xKEcmIrh.pgp Description: PGP signature
Re: Buildworld Fails RELENG_7
On May 19, 2008, at 7:02 PM, Dave Uhring wrote: On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: I did not have to manually move or copy any header files. Did you start from a RELEASE source tree and userland? No. I was upgrading from STABLE last built about on April 29. However near the beginning of April I did move from RELEASE to STABLE. So several builds ago, I had moved from RELEASE to STABLE. So all I can say is that things worked for me. I really suspect that you got /usr/src and /usr/obj into some sort of inconsistent state. I completely removed both, cvsupped a new RELENG_7 source tree, removed /etc/make.conf and got this: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: 'asm' operand has impossible constraints *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. real8m58.524s user7m18.995s sys 1m22.150s I have no idea of what the problem may be. I'm hoping that someone more knowledgeable will be able to help. What is interesting here is that this latest error does not appear to be the result of missing header files. Best of luck with this, -j ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. This starts to narrow down the problem you're having a bit, I think. Given that this is different from the expected behavior and the behavior others are seeing, this sounds to me like either 1) the wrong compiler or version of the compiler is being found and used in place of the desired gcc instance, or 2) something in your shell or environment is somehow getting into the buildworld environment and causing make or the inner shell to misparse the commandline to gcc. The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS= Nothing else in my environment would have affected the compiler. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. This starts to narrow down the problem you're having a bit, I think. Given that this is different from the expected behavior and the behavior others are seeing, this sounds to me like either 1) the wrong compiler or version of the compiler is being found and used in place of the desired gcc instance, or 2) something in your shell or environment is somehow getting into the buildworld environment and causing make or the inner shell to misparse the commandline to gcc. The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS= This does NOT remove CFLAGS from the environment. env -i PATH=$PATH make ... will clear the enviornment and just add PATH. e.g. % env -i PATH=$PATH SHELL=$SHELL HOME=$HOME printenv PATH=/home/marka/gnu/bin:/home/marka/bin/mask:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marka/bin:/usr/local/sbin SHELL=/bin/csh HOME=/home/marka % Nothing else in my environment would have affected the compiler. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [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: Buildworld Fails RELENG_7
Dave Uhring wrote: On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. This starts to narrow down the problem you're having a bit, I think. Given that this is different from the expected behavior and the behavior others are seeing, this sounds to me like either 1) the wrong compiler or version of the compiler is being found and used in place of the desired gcc instance, or 2) something in your shell or environment is somehow getting into the buildworld environment and causing make or the inner shell to misparse the commandline to gcc. The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS= Nothing else in my environment would have affected the compiler I suspect there is still *something* affecting your compiler, though where from I couldn't even guess. According to this message: http://gcc.gnu.org/ml/gcc-help/2007-04/msg00200.html the most recent error you posted, from inside OpenSSL, only happens if you compile the library at -O0, which is definitely not the default behavior. If you've already blown away your FreeBSD environment there's obviously not much more you can do to track down the problem, but it would be interesting to know what: make -V CFLAGS actually returned from within /usr/src. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disk access/MPT under ESX3.5
On Mon, May 19, 2008 at 11:02:31AM +0200, Daniel Ponticello wrote: Hello, monitor# camcontrol negotiate 0:0 -W 16 Current Parameters: (pass0:mpt0:0:0:0): sync parameter: 0 (pass0:mpt0:0:0:0): offset: 0 (pass0:mpt0:0:0:0): bus width: 8 bits (pass0:mpt0:0:0:0): disconnection is enabled (pass0:mpt0:0:0:0): tagged queueing is enabled monitor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 32.421679 secs (32341817 bytes/sec) monitor# dd if=/dev/zero of=/var/tmp/dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 20.355797 secs (51512402 bytes/sec) No improvements. But it looks like it did not renegotiated the transfers data rate that for some odd reasons are setted as 3.3MB/S instead of 320mb/s. I made some tests using linux 2.18 (debian): debiantest:/home/daniel# uname -a Linux debiantest 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686 GNU/Linux scsi0 : ioc0: LSI53C1030, FwRev=h, Ports=1, MaxQ=128, IRQ=169 Vendor: VMwareModel: Virtual disk Rev: 1.0 Type: Direct-Access ANSI SCSI revision: 02 target0:0:0: Beginning Domain Validation target0:0:0: Domain Validation skipping write tests target0:0:0: Ending Domain Validation target0:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU RDSTRM RTI WRFLOW PCOMP (6.25 ns, offset 127) debiantest:/home/daniel# dd if=/dev/zero of=dead.file bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 5.01316 seconds, 209 MB/s For the Linux test, are you sure it didn't cache part of the write before returning? You may need to add some syncs and make it part of the elapsed time. Just checking because this seems to be my experience. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS= Nothing else in my environment would have affected the compiler. You're not using make -j when building world are you? If so, remove that and see if it then builds properly. Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: # export CFLAGS= This does NOT remove CFLAGS from the environment. It does when you shell is bash. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: # export CFLAGS= This does NOT remove CFLAGS from the environment. It does when you shell is bash. I think what Mark was getting at is that simply setting CFLAGS to prior to make does not trump the setting of CFLAGS in make.conf/src.conf. So if you haven't removed/commented that from your make.conf, the export command above will do nothing for the actual build environment. Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:08:22PM -0400, Josh Carroll wrote: The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS= Nothing else in my environment would have affected the compiler. You're not using make -j when building world are you? If so, remove that and see if it then builds properly. No, even though it is a dual-core system. I did not want to chance a race condition. I simply executed 'make buildworld' initially, then 'make -DNO_CLEAN buildworld' when I encountered problems in the build. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
No, even though it is a dual-core system. I did not want to chance a race condition. I simply executed 'make buildworld' initially, then 'make -DNO_CLEAN buildworld' when I encountered problems in the build. Ok, it was worth asking, just to rule out the obvious. I'm still not sure where your logic in using -DNOCLEAN comes in, for a failed build. I would expect that to continue to fail in most circumstances if it were already failing. So I think in one of your other mails you said you're installing something else now? Solaris? If so, this thread is moot, since you aren't running FreeBSD on the box anymore, and no one has been able to reproduce your problem. I think the most likely culprits have already been mentioned in the thread so far anyway. Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: # export CFLAGS= This does NOT remove CFLAGS from the environment. It does when you shell is bash. bash is broken. Empty environment variables have meaning. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [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: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:59:18PM -0400, Josh Carroll wrote: On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: # export CFLAGS= This does NOT remove CFLAGS from the environment. It does when you shell is bash. I think what Mark was getting at is that simply setting CFLAGS to prior to make does not trump the setting of CFLAGS in make.conf/src.conf. So if you haven't removed/commented that from your make.conf, the export command above will do nothing for the actual build environment. Before that last build I had removed /etc/make.conf and had never touched src.conf. CFLAGS was empty. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote:
# export CFLAGS=
This does NOT remove CFLAGS from the environment.
It does when you shell is bash.
bash is broken. Empty environment variables have meaning.
Mark
And when tested does behave the way you describe.
Mark
drugs:9.5.x 13:30 {4371} % bash
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ FOO=ll
[EMAIL PROTECTED] ~/cvs/9.5.x]$ export FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
FOO=ll
[EMAIL PROTECTED] ~/cvs/9.5.x]$ FOO=
[EMAIL PROTECTED] ~/cvs/9.5.x]$ export FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
FOO=
[EMAIL PROTECTED] ~/cvs/9.5.x]$ env -i PATH=$PATH printenv | grep FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [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: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:10:32PM -0400, Josh Carroll wrote: No, even though it is a dual-core system. I did not want to chance a race condition. I simply executed 'make buildworld' initially, then 'make -DNO_CLEAN buildworld' when I encountered problems in the build. Ok, it was worth asking, just to rule out the obvious. I'm still not sure where your logic in using -DNOCLEAN comes in, for a failed build. I would expect that to continue to fail in most circumstances if it were already failing. If you fix what caused the build to break and want to find any other failure points there is little point in restarting the build from zero. So I think in one of your other mails you said you're installing something else now? Solaris? If so, this thread is moot, since you aren't running FreeBSD on the box anymore, and no one has been able to reproduce your problem. I think the most likely culprits have already been mentioned in the thread so far anyway. I would still like to get FreeBSD on that server but with the latest improvements to ZFS. The release version is not going to do that for me and the only way that I can get up-to-date binaries is to build a new world and kernel. I'll give it another days' try and if that still fails Solaris will stay on the server. This BTW is not my first time building world on FreeBSD. I followed STABLE from 3.4 through the end of RELENG_4 and I never had such problems with a simple compile. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 03:03:42PM -0500, Dave Uhring wrote: [EMAIL PROTECTED] /usr/src/contrib/groff]# mount /dev/ad4s2a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad4s2h on /home (ufs, local, soft-updates) /dev/ad4s2e on /usr (ufs, local, soft-updates) /dev/ad4s2g on /usr/local (ufs, local, soft-updates) /dev/ad4s2d on /var (ufs, local, soft-updates) /dev/md0 on /tmp (ufs, local, soft-updates) /dev/ad4s2f on /usr/obj (ufs, asynchronous, local, noatime) [EMAIL PROTECTED] /usr/src/contrib/groff]# Not even an NFS mount. I'm trying to update to FreeBSD-STABLE to use on my home file server. At present it has OpenSolaris installed but that OS does not have the Ethernet driver I need and I want to be able to use 2 Adaptec 29160N HBAs in the system. But I only have 2 PCI slots and I would like to remove the Intel NIC and use the system's on-board nfe NIC. I'll blow away /usr/src and /usr/obj, cvsup the entire RELENG_7 source tree again and once more attempt to buildworld. If that fails, Solaris stays on the server. And please be sure to nuke /var/db/sup/src-all (or /usr/sup/src-all if you're using cvsup for some reason). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 12:16:46PM -0700, Jeremy Chadwick wrote: I will attempt the same with your make.conf to see if it's any different. I'll add that while I slept, I let a 'make buildworld' go with your exact make.conf flags -- it completed successfully. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
