Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Hi. Kris Kennaway wrote: Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP realpath_cache_size (producing 2000+ lstats per request) can handle up to ~24 rps as opposed to max. 17 rps without your patch. %sys never grows over %user with your patch. On the server with optimized realpath_cache_size there's no visible influence of your patch. You said 20 before for this configuration, so I'm a bit suspicious about how seriously to treat your measurements :) Sorry, my mistake. s/ULE/4BSD. Anyway, please obtain another lock profiling trace using the same conditions as the previous one (same workload duration, etc), so we can compare what changed. OK, I'll make it a little bit later. Also I tried to find what else is slow in FreeBSD, I tried hwpmc as module and in kernel, but it fails with error: pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0x804833e0, 0x809338a0) error 78 This is related to http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64%2F111994cat= and it is impossible to use hwpmc with modern CPUs. Is kgmon profiling usable on FreeBSD 7? With best regards, Alexey Popov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Kris Kennaway wrote: what is your RAID controller configuration (read ahead/cache/write policy)? I have seen weird/bogus numbers (~100% busy) reported by systat -v when read ahead was enabled on LSI/amr controllers. I tried to run with disabled Read-ahead, but it didn't help. I just ran into this myself, and apparently it can be caused by Patrol Reads where the adapter periodically scans the disks to look for media errors. You can turn this off using -stopPR with the megarc gg port. Oops, -disPR is the correct command to disable, -stopPR just halts a PR event in progress. Wow! Really disabling Patrol Reads solves the problem. Thank you! I have many amrd's and all of them appear to have Patrol Reads enabled by default. But the problem happenes only on three of them. Is this a hardware problem? With best regards, Alexey Popov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Critical section expansion
Hi, I've been running this (http://lists.freebsd.org/pipermail/cvs-src/2007-November/084049.html ) change on RELENG_7 in production since it was committed and it's fixed a whole host of problems (NIC timeouts, TCP sessions dying under heavy disk load etc.) for me. So far it hasn't created any new ones... Just wondering if it's going to get MFC'd before the 7.0 release? Cheers Phil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
conatainer
With RELENG_7 source cvsupped 3 days ago, I noticed several occurrences of word conatainer in sys/dev/aac/aac_debug.c case AifJobCtrZero: /* Container clear operation */ device_printf(sc-aac_dev, (ConatainerZero) container %d\n, aif-data.PR[0].jd.client.container.src); break; case AifJobCtrCopy: /* Container copy operation */ device_printf(sc-aac_dev, (ConatainerCopy) container %d to %d\n, aif-data.PR[0].jd.client.container.src, aif-data.PR[0].jd.client.container.dst); ...and so on. A lot of aac debug messages talk about Conatainer something or other. Shouldn't it be Container? English is not my native language, so I didn't want to file a PR in case there actually is a word conatainer in English language. -- Toomas Aas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it O.K. to use the 7.0 ports tree on 6.3 ?
On Friday 23 November 2007, Pete French wrote: is it safe to simply untar the ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 and install away, or are there more subtle differences to tran the unwary ? The dependencies can vary depending on OS release, so it's not guaranteed to work. Use 'make fetchindex' after you install to get the latest snapshot for 6-STABLE. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it O.K. to use the 7.0 ports tree on 6.3 ?
The dependencies can vary depending on OS release, so it's not guaranteed to work. Use 'make fetchindex' after you install to get the latest snapshot for 6-STABLE. Thanks, that was the bit I had forgotten! cheers, -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Joseph Koshy wrote: Also I tried to find what else is slow in FreeBSD, I tried hwpmc as module and in kernel, but it fails with error: pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0x804833e0, 0x809338a0) error 78 There are patches you need to enable it on woodcrest. They are in my p4 branch (kris-contention) but I don't have time right now to extract them. These patches make hwpmc treat these CPUs are possessing Pentium-Pro class PMCs. Unfortunately, this is easy to do, but incorrect: - There are differences in the legal bit values that may be loaded into PMC registers for many hardware events. - hwpmc needs to be taught to support measurements on CPUs with multiple cores per package. And then there is additional work to support these CPUS at the same level as the current set: - The hardware events supported are named differently; documentation, libpmc's event selector parsing code need to be changed to suit. - The hardware supports a new class of fixed function PMCs that hwpmc needs to support. Well, this is all true, but overlooks the point that it does minimally work, which is of critical importance to people with one of these CPUs who want to actually use your tool ;) Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Maestro 2E on 6.3-PRERELEASE
I have a Maestro 2E sound card that works perfectly on 6.2-RELEASE-p8, but not on 6.3-PRERELEASE. Here's the dmesg: Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-PRERELEASE #13: Thu Nov 22 06:25:22 CST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3606.95-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf62 Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe43dSSE3,RSVD2,MON,DS_CPL,VMX,CNXT-ID,CX16,xTPR,PDCM AMD Features=0x2000LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 1073217536 (1023 MB) avail memory = 1036808192 (988 MB) ACPI APIC Table: A M I OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: A M I OEMXSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci3: ACPI PCI bus on pcib1 nvidia0: GeForce 7600 GS port 0xe800-0xe87f mem 0xdf00-0xdfff,0xe000-0xefff,0xde00-0xdeff irq 16 at device 0.0 on pci3 nvidia0: [GIANT-LOCKED] pcm0: Intel 82801G High Definition Audio Controller mem 0xdddf8000-0xdddfbfff irq 19 at device 27.0 on pci0 pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 uhci0: UHCI (generic) USB controller port 0x7000-0x701f irq 20 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0x7400-0x741f irq 17 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: UHCI (generic) USB controller port 0x7800-0x781f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: UHCI (generic) USB controller port 0x8000-0x801f irq 19 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: UHCI (generic) USB controller on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801GB/R (ICH7) USB 2.0 controller mem 0xdddff800-0xdddffbff irq 20 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib3 sio0: configured irq 21 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: 3COM PCI FaxModem port 0xa400-0xa407 irq 21 at device 0.0 on pci1 sio0: moving to sio4 sio4: type 16550A puc0: Dolphin Peripherals 4036 port 0xa800-0xa81f irq 22 at device 1.0 on pci1 sio5: Dolphin Peripherals 4036 on puc0 sio5: type 16550A sio6: Dolphin Peripherals 4036 on puc0 sio6: type 16550A pcm1: ESS Technology Maestro-2E port 0xb000-0xb0ff irq 23 at device 2.0 on pci1 pcm1: agg_rdcodec() RW_DONE timed out. pcm1: will perform cold reset. pcm1: agg_rdcodec() RW_DONE timed out. pcm1: agg_rdcodec() RW_DONE timed out. pcm1: agg_rdcodec() RW_DONE timed out. pcm1: agg_rdcodec() RW_DONE timed out. pcm1: agg_rdcodec() RW_DONE timed out. pcm1: ac97 codec invalid or not present (id == ) pcm1: mixer initialization failed! device_attach: pcm1 attach returned 6 atapci0: ITE IT8211F UDMA133 controller port 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xb800-0xb803,0xb400-0xb40f irq 19 at device 4.0 on pci1 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci1: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: ATA channel 0 on atapci1 ata1: ATA channel 1 on atapci1 atapci2: Intel ICH7 SATA300 controller port
Re: Is it O.K. to use the 7.0 ports tree on 6.3 ?
Pete French wrote: I have a set of machines running 7.0 and a set running 6.3 which I would like to use the same ports on. I was under the impression that there was only one ports tree, so is it safe to simply untar the ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 and install away, or are there more subtle differences to tran the unwary ? You've already received the right advice about not renaming the INDEX, but I think it's also worth mentioning that untar'ing a static picture of the ports tree is of little practical value unless you never plan to update the base, and you never plan to update any ports on that machine. You're much better off starting with downloading the tree with csup, that way you can maintain it more easily down the road. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld failures -6.3-PRE
韓家標 Bill Hacker wrote: Many such, Wearing out my csup welcome for 'RELENG_6'. Same or similar error when attempting to regress to 'RELENG_6_2' : undefined reference to `__mb_sb_limit' *** Error code 1 Have you cleaned out /usr/obj/ ? That's always the first place to start when you see problems of this type, especially in a -stable branch. You might also want to do 'cd /usr/src make cleandir ; make cleandir' (yes, I meant to type it twice). hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld failures -6.3-PRE
On 11/24/07, Doug Barton [EMAIL PROTECTED] wrote: ¶ Bill Hacker wrote: Many such, Wearing out my csup welcome for 'RELENG_6'. Same or similar error when attempting to regress to 'RELENG_6_2' : undefined reference to `__mb_sb_limit' *** Error code 1 Have you cleaned out /usr/obj/ ? That's always the first place to start when you see problems of this type, especially in a -stable branch. You might also want to do 'cd /usr/src make cleandir ; make cleandir' (yes, I meant to type it twice). What wrong 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: Is it O.K. to use the 7.0 ports tree on 6.3 ?
On Fri, 23 Nov 2007, Doug Barton wrote: Pete French wrote: I have a set of machines running 7.0 and a set running 6.3 which I would like to use the same ports on. I was under the impression that there was only one ports tree, so is it safe to simply untar the ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 and install away, or are there more subtle differences to tran the unwary ? You've already received the right advice about not renaming the INDEX, but I think it's also worth mentioning that untar'ing a static picture of the ports tree is of little practical value unless you never plan to update the base, and you never plan to update any ports on that machine. You're much better off starting with downloading the tree with csup, that way you can maintain it more easily down the road. Or you can just use 'portsnap fetch extract' and then for updates use 'portsnap fetch update'. This maintains the INDEX files according to your base system also; you don't need to use make fetchindex. Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld failures - 6.3-PRE
So your saying until fixed NO_TCSH should be in make.conf? On 11/23/07, 韓家標 Bill Hacker [EMAIL PROTECTED] wrote: Confirming localized failure: cd'ed to /usr/src/contrib/tcsh == triligon# ./configure checking build system type... amd64-unknown-freebsd6.3 checking host system type... amd64-unknown-freebsd6.3 checking cached host tuple... ok Tcsh will use configuration file `bsd4.4'. checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking whether gcc needs -traditional... no checking for library containing crypt... -lcrypt checking for library containing getspnam... no checking for library containing tgetent... -ltermlib checking for library containing gethostbyname... none required checking for library containing connect... none required checking for library containing iconv... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking auth.h usability... no checking auth.h presence... no checking for auth.h... no checking for inttypes.h... (cached) yes checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking for stdint.h... (cached) yes checking utmpx.h usability... no checking utmpx.h presence... no checking for utmpx.h... no checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... 4 checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether stat file-mode macros are broken... no checking for ANSI C header files... (cached) no checking for long long... yes checking for uid_t in sys/types.h... yes checking type of array argument to getgroups... gid_t checking for mode_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... (cached) yes checking for socklen_t... yes checking for struct dirent.d_ino... yes checking for struct utmp.ut_host... no checking for struct utmp.ut_user... no checking for struct utmp.ut_tv... no checking for struct utmp.ut_xtime... no checking for struct sockaddr_storage.ss_family... yes checking for an ANSI C-conforming const... yes checking for function prototypes... yes checking for working volatile... yes checking whether gethostname is declared... yes checking for dup2... yes checking for getcwd... yes checking for gethostname... yes checking for getpwent... yes checking for getutent... no checking for memmove... yes checking for memset... yes checking for nice... yes checking for nl_langinfo... yes checking for sbrk... yes checking for setpgid... yes checking for setpriority... yes checking for strerror... yes checking for strstr... yes checking for sysconf... yes checking for wcwidth... yes checking whether getpgrp requires zero arguments... yes checking whether setpgrp takes no argument... no configure: creating ./config.status config.status: creating Makefile config.status: creating config.h === triligon# make grep 'ERR_' ./sh.err.c | grep '^#define' sh.err.h gcc -E -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' -D_h_tc_const ./tc.const.c | sed -n -e 's/^\(Char STR[a-zA-Z0-9_]*\) *\[ *\].*/extern \1[];/p' | sort tc.const.h gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.dir.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.dol.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.err.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.exec.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.char.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.exp.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.file.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.func.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.glob.c gcc -c -g -O2 -I. -I.
Buildworld failures -6.3-PRE
Many such, Wearing out my csup welcome for 'RELENG_6'. Same or similar error when attempting to regress to 'RELENG_6_2' Details: = -- stage 2.3: build tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp MAKEFLAGS=-m /usr/src/tools/build/mk -j 9 -m /usr/src/share/mk /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 DESTDIR= BOOTSTRAPPING=602113 -DNO_LINT -DNO_CPU_CFLAGS -DNO_WARNS build-tools === bin/csh (obj,build-tools) grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define' sh.err.h cc -E -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='/bin/csh' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/tc.const.c /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h /usr/src/bin/csh/../../contrib/tcsh/config_f.h /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' | sort tc.const.h cc -o gethost -L/usr/obj/usr/src/tmp/legacy/usr/lib -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='/bin/csh' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/gethost.c /var/tmp//ccMRLXC4.o(.text+0x9): In function `gettoken': : undefined reference to `__mb_sb_limit' /var/tmp//ccMRLXC4.o(.text+0x8d): In function `gettoken': : undefined reference to `__mb_sb_limit' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error = I thought this had been fixed? Bill Hacker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: conatainer
On Fri, Nov 23, 2007 at 04:50:24AM -0800, Jeremy Chadwick wrote: Another fun one to grep for is teh or teh . grep -w teh :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it O.K. to use the 7.0 ports tree on 6.3 ?
Pete French wrote: I have a set of machines running 7.0 and a set running 6.3 which I would like to use the same ports on. I was under the impression that there was only one ports tree, so is it safe to simply untar the ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 and install away, or are there more subtle differences to tran the unwary ? cheers, -pcf. I think that they are the same, except INDEX-6 and INDEX-7 differ. So do your tar-untaring, and then do make fetchindex on the 6.3 machine(s). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Schedule for 6.3R is a 404
Mike Jakubik wrote Tue, 20 Nov 2007 18:26:22 -0500 (Wed 00:26 CET): Just an FYI, http://www.freebsd.org/releases/6.3R/schedule.html returns a 404. This is linked from http://www.freebsd.org/releases/. Still so at Fri Nov 23 14:52:46 CET 2007 Ive cc'd [EMAIL PROTECTED] -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Critical section expansion
On Fri, 23 Nov 2007, Philip Murray wrote: I've been running this (http://lists.freebsd.org/pipermail/cvs-src/2007-November/084049.html) change on RELENG_7 in production since it was committed and it's fixed a whole host of problems (NIC timeouts, TCP sessions dying under heavy disk load etc.) for me. So far it hasn't created any new ones... Just wondering if it's going to get MFC'd before the 7.0 release? I asked Scott about this also -- turns out he doesn't use the automated MFC after reminder system, so doesn't tag commits with MFC after. He does intend to MFC this before the release. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Krassimir Slavchev wrote: That's true but if the tests are same then they can be compared. - the code is most likely checking for changes in PHP libraries) This is not recommended for production systems. PHP code accelerators / caches do that all the time. require_once() also does it. Yes, may be it is easier to write perl/php scripts. I'm glad you're volunteering :) signature.asc Description: OpenPGP digital signature
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ivan Voras wrote: On 23/11/2007, Krassimir Slavchev [EMAIL PROTECTED] wrote: Would someone define what exact tests to be performed. Ok, using ab is fine but with what parameters it is used and against what, script or static html? It will be good to have written some perl, In this thread, it's always PHP code, with database backends. php ... scripts or C programs which simulates some kind of 'real world' work. The problem is that a realistic applications does a lot of things that are not easily simulated: That's true but if the tests are same then they can be compared. - usually has a lot of code, lots of include files, libraries, etc. (so it stresses file systems, as was shown with fstat() in the thread - the code is most likely checking for changes in PHP libraries) This is not recommended for production systems. - uses a database, which is populated with real-world data (so it has a lot of IPC of very varied sizes) - uses some kind of caching, both of compiled PHP code (eAccelerator, pecl-APC) and of data (eAccelerator, memcached) (which uses SysV SHM and IPC). Reducing all that to a C file that does all of it is very nontrivial. Yes, may be it is easier to write perl/php scripts. For classic setups with mod_php, it's not uncommon that httpd processes grow to 100 MB or more each, with all the heavy stuff brought in. Yes, that is true for mod_perl too. However, it is hard to simulate real workload. I will have 2 2xQuad Core(X5450) with 8G RAM systems (DL380G5) soon and will have about a month to play with them before put in production. If someone wish I can run specific test on them. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRrQuxJBWvpalMpkRAvL9AJ9tBgeZPxg6zYWqJUgVimIJgaxl1ACeK2kS POeyNbZBGuiQB0OKHIEtoSk= =pjb2 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Alexey Popov wrote: Hi. Kris Kennaway wrote: Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP realpath_cache_size (producing 2000+ lstats per request) can handle up to ~24 rps as opposed to max. 17 rps without your patch. %sys never grows over %user with your patch. On the server with optimized realpath_cache_size there's no visible influence of your patch. You said 20 before for this configuration, so I'm a bit suspicious about how seriously to treat your measurements :) Sorry, my mistake. s/ULE/4BSD. OK, please compare ULE to ULE with and without my patch (and remembering to enable the sysctl), and obtain lock profiling traces in both cases under identical workloads durations. That is what I need to proceed with this issue. Anyway, please obtain another lock profiling trace using the same conditions as the previous one (same workload duration, etc), so we can compare what changed. OK, I'll make it a little bit later. Also I tried to find what else is slow in FreeBSD, I tried hwpmc as module and in kernel, but it fails with error: pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0x804833e0, 0x809338a0) error 78 There are patches you need to enable it on woodcrest. They are in my p4 branch (kris-contention) but I don't have time right now to extract them. This is related to http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64%2F111994cat= and it is impossible to use hwpmc with modern CPUs. Sounds like it. Is kgmon profiling usable on FreeBSD 7? I've never bothered, it is likely to be quite slow, so it can totally change the workload you are trying to profile. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Kris Kennaway wrote: what is your RAID controller configuration (read ahead/cache/write policy)? I have seen weird/bogus numbers (~100% busy) reported by systat -v when read ahead was enabled on LSI/amr controllers. I tried to run with disabled Read-ahead, but it didn't help. I just ran into this myself, and apparently it can be caused by Patrol Reads where the adapter periodically scans the disks to look for media errors. You can turn this off using -stopPR with the megarc gg port. Oops, -disPR is the correct command to disable, -stopPR just halts a PR event in progress. Wow! Really disabling Patrol Reads solves the problem. Thank you! I have many amrd's and all of them appear to have Patrol Reads enabled by default. But the problem happenes only on three of them. Is this a hardware problem? I am not sure, maybe for some reason the patrol reads are not interfering with other disk I/O so much (e.g. the hardware prioritises them differently or something). Anyway, glad to hear it was resolved. Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers 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: 2 x quad-core system is slower that 2 x dual core on FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ivan Voras wrote: On 20/11/2007, Alexey Popov [EMAIL PROTECTED] wrote: CPU states: 5.9% user, 0.0% nice, 81.3% system, 0.0% interrupt, 12.8% idle CPU states: 82.2% user, 0.0% nice, 13.8% system, 0.0% interrupt, 4.0% idle Interesting coincidence: 1 CPU generates almost 8x less sys time then 8 CPUs. But it seems that you have found something real. Inspired by your problem I've done a simple measurement (ab) on a 4-CPU (2x2 core Opterons 2216 HE, PAE) machine I maintain, under these circumstances: Would someone define what exact tests to be performed. Ok, using ab is fine but with what parameters it is used and against what, script or static html? It will be good to have written some perl, php ... scripts or C programs which simulates some kind of 'real world' work. There are lot of people who thinking 'it is good for me' (including me) but what can be done with such hardware? Best Regards - a heavy PHP application - FastCGI - in this case, load of 4 clients - on 6-STABLE and I'm reporting similar findings: last pid: 2254; load averages: 1.43, 0.92, 0.69 up 71+08:23:06 18:00:31 153 processes: 8 running, 144 sleeping, 1 zombie CPU states: 38.8% user, 0.0% nice, 48.4% system, 3.2% interrupt, 9.6% idle Mem: 2321M Active, 1135M Inact, 313M Wired, 139M Cache, 112M Buf, 93M Free Swap: 4500M Total, 336K Used, 4500M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 2208 www 1 990 115M 19808K RUN1 0:06 36.83% php-cgi 2207 www 1 1000 114M 19348K RUN3 0:05 32.66% php-cgi 1715 www 1 990 115M 23672K CPU0 0 0:24 27.83% php-cgi 1710 www 1 1010 114M 23460K RUN1 0:31 22.17% php-cgi 1882 www 1 990 115M 23392K CPU2 3 0:18 21.34% php-cgi 1718 www 1 40 114M 22556K sbwait 0 0:21 19.14% php-cgi 2677 pgsql 1 40 977M 55768K sbwait 0 0:00 28.00% postgres We are not so performance bound as you so I didn't do measurements earlier. I cannot play with settings on this machine as it is in production, but ~~50% sys time (the measurement changes around 45% +/- 10%) seems too much. On another 4-CPU machine (2x2 Xeons 5110, AMD64) with the same application and benchmark setup, but RELENG_7, which is not yet in production, the results are slightly different: last pid: 66564; load averages: 1.87, 0.48, 0.18 up 15+05:27:03 17:09:09 113 processes: 9 running, 104 sleeping CPU states: 49.0% user, 0.0% nice, 28.8% system, 0.0% interrupt, 22.1% idle Mem: 555M Active, 295M Inact, 884M Wired, 98M Cache, 213M Buf, 135M Free Swap: 2047M Total, 2047M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 66557 www 1 1090 105M 25340K RUN3 0:14 64.99% php-cgi 66559 www 1 1090 105M 25308K RUN2 0:14 62.99% php-cgi 66561 www 1 980 105M 22196K RUN0 0:01 12.99% php-cgi 66562 www 1 980 105M 22196K RUN1 0:01 11.96% php-cgi 59043 nobody 1 470 7012K 3744K select 2 0:27 5.96% sqlcached 774 pgsql1 440 437M 112M select 2 3:55 0.00% postgres ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRp75xJBWvpalMpkRAhbVAKClBhCif9G/bYPq6hHaNxAyT9NuLwCfb8+a Aqmf9RT+LBNYqKOE6crBs9g= =LL1v -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Also I tried to find what else is slow in FreeBSD, I tried hwpmc as module and in kernel, but it fails with error: pmc: Unknown Intel CPU. module_register_init: MOD_LOAD (hwpmc, 0x804833e0, 0x809338a0) error 78 There are patches you need to enable it on woodcrest. They are in my p4 branch (kris-contention) but I don't have time right now to extract them. These patches make hwpmc treat these CPUs are possessing Pentium-Pro class PMCs. Unfortunately, this is easy to do, but incorrect: - There are differences in the legal bit values that may be loaded into PMC registers for many hardware events. - hwpmc needs to be taught to support measurements on CPUs with multiple cores per package. And then there is additional work to support these CPUS at the same level as the current set: - The hardware events supported are named differently; documentation, libpmc's event selector parsing code need to be changed to suit. - The hardware supports a new class of fixed function PMCs that hwpmc needs to support. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
On 23/11/2007, Krassimir Slavchev [EMAIL PROTECTED] wrote: Would someone define what exact tests to be performed. Ok, using ab is fine but with what parameters it is used and against what, script or static html? It will be good to have written some perl, In this thread, it's always PHP code, with database backends. php ... scripts or C programs which simulates some kind of 'real world' work. The problem is that a realistic applications does a lot of things that are not easily simulated: - usually has a lot of code, lots of include files, libraries, etc. (so it stresses file systems, as was shown with fstat() in the thread - the code is most likely checking for changes in PHP libraries) - uses a database, which is populated with real-world data (so it has a lot of IPC of very varied sizes) - uses some kind of caching, both of compiled PHP code (eAccelerator, pecl-APC) and of data (eAccelerator, memcached) (which uses SysV SHM and IPC). Reducing all that to a C file that does all of it is very nontrivial. For classic setups with mod_php, it's not uncommon that httpd processes grow to 100 MB or more each, with all the heavy stuff brought in. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Software for distribution of configuration files and changes
On Fri, Nov 23, 2007 at 02:14:14PM +0800, Quan Qiu wrote: And have you tried actually attempting to log in with root's password that way? I'm betting it doesn't work. That really worked for me. I'm running RELENG_5. The cvsid for /etc/pam.d/sshd is # $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $ sshd version: OpenSSH_3.8.1p1 FreeBSD-20060930, OpenSSL 0.9.7e-p1 25 Oct 2004 My proof: Using username root. Using keyboard-interactive authentication. Password: Last login: Fri Nov 23 09:14:27 2007 from 61.136.19.236 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.5-STABLE (JACKQQNAT) #6: Mon Nov 19 21:33:30 CST 2007 [EMAIL PROTECTED] [~] 13:51 Fri Nov 23 #cat /etc/pam.d/sshd # # $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $ ... Without PAM: Using username root. [EMAIL PROTECTED]'s password: Access denied [EMAIL PROTECTED]'s password: Okay, so then the difference between what you're seeing and what I'm seeing is likely attributed to either OpenSSH changes (less likely) or PAM configuration changes between RELENG_5 and RELENG_6 (more likely). http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/pam.d/sshd -- | 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: Critical section expansion
Philip Murray wrote: Hi, I've been running this (http://lists.freebsd.org/pipermail/cvs-src/2007-November/084049.html) change on RELENG_7 in production since it was committed and it's fixed a whole host of problems (NIC timeouts, TCP sessions dying under heavy disk load etc.) for me. So far it hasn't created any new ones... Just wondering if it's going to get MFC'd before the 7.0 release? Absolutely. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Hi Kris Kennaway wrote: Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP realpath_cache_size (producing 2000+ lstats per request) can handle up to ~24 rps as opposed to max. 17 rps without your patch. %sys never grows over %user with your patch. On the server with optimized realpath_cache_size there's no visible influence of your patch. You said 20 before for this configuration, so I'm a bit suspicious about how seriously to treat your measurements :) Sorry, my mistake. s/ULE/4BSD. OK, please compare ULE to ULE with and without my patch (and remembering to enable the sysctl), and obtain lock profiling traces in both cases under identical workloads durations. That is what I need to proceed with this issue. I didn't measured the exact values of requests per second on ULE with patch and without patch, but at first glance the benefits of the patch are similiar to 4BSD. If you need this values, I'll obtain them. Here you can find lock profiling results for 7-BETA3 GENERIC kernel with SCHED_ULE running optimized PHP and unoptimized, with your patch and without it: http://83.167.98.162/gprof/lockmgr/ This data was collected by th following script: (sysctl debug.lock.prof.reset=1 sysctl debug.lock.prof.enable=1 sleep 60 sysctl debug.lock.prof.enable=0 sysctl debug.lock.prof.stats top -d 2 -b | tail -25) AFAIU there's still high contention on lockbuilder mtxpool with patch applied. But hopefully lockmgr:ufs contention which i believe produced 80%sysCPU load is gone with your patch. Also I tried to find what else is slow in FreeBSD, I tried hwpmc as module and in kernel, but it fails with error: pmc: Unknown Intel CPU. There are patches you need to enable it on woodcrest. They are in my p4 branch (kris-contention) but I don't have time right now to extract them. I think it would be very useful because I can't see any other ways to profile FreeBSD on the modern many-cores machines. With best regards, Alexey Popov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: conatainer
On Fri, Nov 23, 2007 at 02:33:23PM +0200, Toomas Aas wrote: With RELENG_7 source cvsupped 3 days ago, I noticed several occurrences of word conatainer in sys/dev/aac/aac_debug.c ... Shouldn't it be Container? English is not my native language, so I didn't want to file a PR in case there actually is a word conatainer in English language. You're correct -- it should be container; someone was typing fast. :-) Another fun one to grep for is teh or teh . -- | 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]
Is it O.K. to use the 7.0 ports tree on 6.3 ?
I have a set of machines running 7.0 and a set running 6.3 which I would like to use the same ports on. I was under the impression that there was only one ports tree, so is it safe to simply untar the ports.tgz file from 7.0 on the 6.3 machines, rename INDEX-7 to INDEX-6 and install away, or are there more subtle differences to tran the unwary ? cheers, -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildworld failures - 6.3-PRE
Confirming localized failure: cd'ed to /usr/src/contrib/tcsh == triligon# ./configure checking build system type... amd64-unknown-freebsd6.3 checking host system type... amd64-unknown-freebsd6.3 checking cached host tuple... ok Tcsh will use configuration file `bsd4.4'. checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking whether gcc needs -traditional... no checking for library containing crypt... -lcrypt checking for library containing getspnam... no checking for library containing tgetent... -ltermlib checking for library containing gethostbyname... none required checking for library containing connect... none required checking for library containing iconv... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking auth.h usability... no checking auth.h presence... no checking for auth.h... no checking for inttypes.h... (cached) yes checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking for stdint.h... (cached) yes checking utmpx.h usability... no checking utmpx.h presence... no checking for utmpx.h... no checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... 4 checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether stat file-mode macros are broken... no checking for ANSI C header files... (cached) no checking for long long... yes checking for uid_t in sys/types.h... yes checking type of array argument to getgroups... gid_t checking for mode_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... (cached) yes checking for socklen_t... yes checking for struct dirent.d_ino... yes checking for struct utmp.ut_host... no checking for struct utmp.ut_user... no checking for struct utmp.ut_tv... no checking for struct utmp.ut_xtime... no checking for struct sockaddr_storage.ss_family... yes checking for an ANSI C-conforming const... yes checking for function prototypes... yes checking for working volatile... yes checking whether gethostname is declared... yes checking for dup2... yes checking for getcwd... yes checking for gethostname... yes checking for getpwent... yes checking for getutent... no checking for memmove... yes checking for memset... yes checking for nice... yes checking for nl_langinfo... yes checking for sbrk... yes checking for setpgid... yes checking for setpriority... yes checking for strerror... yes checking for strstr... yes checking for sysconf... yes checking for wcwidth... yes checking whether getpgrp requires zero arguments... yes checking whether setpgrp takes no argument... no configure: creating ./config.status config.status: creating Makefile config.status: creating config.h === triligon# make grep 'ERR_' ./sh.err.c | grep '^#define' sh.err.h gcc -E -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' -D_h_tc_const ./tc.const.c | sed -n -e 's/^\(Char STR[a-zA-Z0-9_]*\) *\[ *\].*/extern \1[];/p' | sort tc.const.h gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.dir.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.dol.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.err.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.exec.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.char.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.exp.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.file.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.func.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.glob.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.hist.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.init.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.lex.c gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.misc.c
Re: Buildworld failures -6.3-PRE
On 11/23/07, ¶ Bill Hacker [EMAIL PROTECTED] wrote: Many such, Wearing out my csup welcome for 'RELENG_6'. Same or similar error when attempting to regress to 'RELENG_6_2' Details: = -- stage 2.3: build tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp MAKEFLAGS=-m /usr/src/tools/build/mk -j 9 -m /usr/src/share/mk /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 DESTDIR= BOOTSTRAPPING=602113 -DNO_LINT -DNO_CPU_CFLAGS -DNO_WARNS build-tools === bin/csh (obj,build-tools) grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define' sh.err.h cc -E -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='/bin/csh' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/tc.const.c /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h /usr/src/bin/csh/../../contrib/tcsh/config_f.h /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' | sort tc.const.h cc -o gethost -L/usr/obj/usr/src/tmp/legacy/usr/lib -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='/bin/csh' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/gethost.c /var/tmp//ccMRLXC4.o(.text+0x9): In function `gettoken': : undefined reference to `__mb_sb_limit' /var/tmp//ccMRLXC4.o(.text+0x8d): In function `gettoken': : undefined reference to `__mb_sb_limit' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error = I thought this had been fixed? Same error under -current also note to those who are courious about my mergemaster patch Doug was right skipping make altogether is the wrong solution... will look into it deeeper ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld failures - 6.3-PRE
Aryeh Friedman wrote: btw I am starting with 6.2-RELEASE because of the cd issues I have mentioned should I go straight to current or should I go to 6.3 then upto current? At the current state of at least the .jp and .dk mirrors, I had breakage from RELENG_6_0, _6_1, 6_1, 6_2 and RELENG_6 All AMD-64, and attempting to build with 6.3-PRERELEASE and world last built 27 October. YMMV, and this is on of of the Tomcats, Core-D 2-core, not a GA G33-DS3R Quad Core where I'm working up HEAD as soon as the csup completes. Bill On 11/23/07, Aryeh Friedman [EMAIL PROTECTED] wrote: On 11/23/07, � Bill Hacker [EMAIL PROTECTED] wrote: Aryeh Friedman wrote: So your saying until fixed NO_TCSH should be in make.conf? Wouldn't break *my* heart, I prefer bash. But AFAIK it breaks a lot of other stuff that depends on tcsh or tcsh-as-csh. (already tried nuking that whole tree. No Joy). Bill I am about to embark on an other buildworld/mergemaster/etc and am willing to look into this in detail so I will send you a patch if I find one Confirming localized failure: cd'ed to /usr/src/contrib/tcsh == triligon# ./configure checking build system type... amd64-unknown-freebsd6.3 checking host system type... amd64-unknown-freebsd6.3 checking cached host tuple... ok Tcsh will use configuration file `bsd4.4'. checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking whether gcc needs -traditional... no checking for library containing crypt... -lcrypt checking for library containing getspnam... no checking for library containing tgetent... -ltermlib checking for library containing gethostbyname... none required checking for library containing connect... none required checking for library containing iconv... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking auth.h usability... no checking auth.h presence... no checking for auth.h... no checking for inttypes.h... (cached) yes checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking for stdint.h... (cached) yes checking utmpx.h usability... no checking utmpx.h presence... no checking for utmpx.h... no checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... 4 checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether stat file-mode macros are broken... no checking for ANSI C header files... (cached) no checking for long long... yes checking for uid_t in sys/types.h... yes checking type of array argument to getgroups... gid_t checking for mode_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... (cached) yes checking for socklen_t... yes checking for struct dirent.d_ino... yes checking for struct utmp.ut_host... no checking for struct utmp.ut_user... no checking for struct utmp.ut_tv... no checking for struct utmp.ut_xtime... no checking for struct sockaddr_storage.ss_family... yes checking for an ANSI C-conforming const... yes checking for function prototypes... yes checking for working volatile... yes checking whether gethostname is declared... yes checking for dup2... yes checking for getcwd... yes checking for gethostname... yes checking for getpwent... yes checking for getutent... no checking for memmove... yes checking for memset... yes checking for nice... yes checking for nl_langinfo... yes checking for sbrk... yes checking for setpgid... yes checking for setpriority... yes checking for strerror... yes checking for strstr... yes checking for sysconf... yes checking for wcwidth... yes checking whether getpgrp requires zero arguments... yes checking whether setpgrp takes no argument... no configure: creating ./config.status config.status: creating Makefile config.status: creating config.h === triligon# make grep 'ERR_' ./sh.err.c | grep '^#define' sh.err.h gcc -E -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' -D_h_tc_const ./tc.const.c | sed -n -e
Re: Buildworld failures - 6.3-PRE
Aryeh Friedman wrote: On 11/23/07, � Bill Hacker [EMAIL PROTECTED] wrote: Aryeh Friedman wrote: So your saying until fixed NO_TCSH should be in make.conf? Wouldn't break *my* heart, I prefer bash. But AFAIK it breaks a lot of other stuff that depends on tcsh or tcsh-as-csh. (already tried nuking that whole tree. No Joy). Bill I am about to embark on an other buildworld/mergemaster/etc and am willing to look into this in detail so I will send you a patch if I find one What I posted was 6-STABLE relevant. I'm just now updating an RD box to HEAD - may not have the problem. As to patch - don't send it to *me*. I don't use patches , OR drink blended whisky. I use rm -Rf and go back to the last thing that JFW'ed. If you can't get it right the first time Still running several 4.11-STABLE 1U's for that reason. Hardware and code that JFW (VIA CPU's). Bill Confirming localized failure: cd'ed to /usr/src/contrib/tcsh == triligon# ./configure checking build system type... amd64-unknown-freebsd6.3 checking host system type... amd64-unknown-freebsd6.3 checking cached host tuple... ok Tcsh will use configuration file `bsd4.4'. checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking whether gcc needs -traditional... no checking for library containing crypt... -lcrypt checking for library containing getspnam... no checking for library containing tgetent... -ltermlib checking for library containing gethostbyname... none required checking for library containing connect... none required checking for library containing iconv... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking auth.h usability... no checking auth.h presence... no checking for auth.h... no checking for inttypes.h... (cached) yes checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking for stdint.h... (cached) yes checking utmpx.h usability... no checking utmpx.h presence... no checking for utmpx.h... no checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... 4 checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether stat file-mode macros are broken... no checking for ANSI C header files... (cached) no checking for long long... yes checking for uid_t in sys/types.h... yes checking type of array argument to getgroups... gid_t checking for mode_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... (cached) yes checking for socklen_t... yes checking for struct dirent.d_ino... yes checking for struct utmp.ut_host... no checking for struct utmp.ut_user... no checking for struct utmp.ut_tv... no checking for struct utmp.ut_xtime... no checking for struct sockaddr_storage.ss_family... yes checking for an ANSI C-conforming const... yes checking for function prototypes... yes checking for working volatile... yes checking whether gethostname is declared... yes checking for dup2... yes checking for getcwd... yes checking for gethostname... yes checking for getpwent... yes checking for getutent... no checking for memmove... yes checking for memset... yes checking for nice... yes checking for nl_langinfo... yes checking for sbrk... yes checking for setpgid... yes checking for setpriority... yes checking for strerror... yes checking for strstr... yes checking for sysconf... yes checking for wcwidth... yes checking whether getpgrp requires zero arguments... yes checking whether setpgrp takes no argument... no configure: creating ./config.status config.status: creating Makefile config.status: creating config.h === triligon# make grep 'ERR_' ./sh.err.c | grep '^#define' sh.err.h gcc -E -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' -D_h_tc_const ./tc.const.c | sed -n -e 's/^\(Char STR[a-zA-Z0-9_]*\) *\[ *\].*/extern \1[];/p' | sort tc.const.h gcc -c -g -O2 -I. -I. -D_PATH_TCSHELL='/usr/local/bin/tcsh' sh.c gcc -c -g -O2 -I. -I.
Re: Buildworld failures - 6.3-PRE
Aryeh Friedman wrote: Here is a nasty idea... ftp the src dist files from 7.0-BETA3 do a buildworld on them then upgrade from there That's a non-starter for the Tyan's Twin BGE NIC's and IHC7 CMFM SATA controller. Bill ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld failures - 6.3-PRE
On 11/23/07, ¶ Bill Hacker [EMAIL PROTECTED] wrote: Aryeh Friedman wrote: Here is a nasty idea... ftp the src dist files from 7.0-BETA3 do a buildworld on them then upgrade from there That's a non-starter for the Tyan's Twin BGE NIC's and IHC7 CMFM SATA controller. Besides it turns out the sources for 7 are not in a dist file format yet anyways... btw I got a intresting clue on the re(4) stuff if it slows down on 6.2-release (yes I know thats not what I reported) do the following and it will clear up: ifconfig re0 192.168.2.2 -txcsum -rxcsum ifconfig lo0 127.0.0.1 route add default 192.168.2.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 failures -6.3-PRE
On Sat, Nov 24, 2007 at 04:24:36AM +, Aryeh Friedman wrote: On 11/24/07, Doug Barton [EMAIL PROTECTED] wrote: 'cd /usr/src make cleandir ; make cleandir' (yes, I meant to type it twice). What wrong with rm -rf /usr/obj? That's similar to a single 'make cleandir', though it will also delete the kernel build count (the #nn in uname -a). Note that the second 'make cleandir' is still necessary in case any cruft has been created inside /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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
