Re: [stable 9] broken hwpstate calls
on 07/06/2012 02:02 Jung-uk Kim said the following: Any way, hwpstate still isn't quite right even without your patch. sys/kern/kern_cpu.c cpufreq_curr_sysctl() - CPUFREQ_SET() - /* for all CPU devices */ cf_set_method() - /* thread_lock(), sched_bind(), ... */ CPUFREQ_DRV_SET() - sys/x86/cpufreq/hwpstate.c hwpstate_set() - hwpstate_goto_pstate()/* for each CPU unit */ /* thread_lock(), sched_bind(), ... */ Oh, I didn't realize that there was the cpufreq-level loop over all CPUs! That really sucks. Maybe some day we should accept that different CPUs could legitimately be in different P-states and provide support for that throughout the stack (from powerd to drivers). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
At Thu, 07 Jun 2012 09:12:55 +0700, Erich wrote: Hi, On 07 June 2012 3:01:07 Момчил Иванов wrote: temperature. It was constantly increasing from about 33 C. I took a look at top and saw that both processes were wildly jumping accross the cores, i.e. CPU0 and CPU1. So before reading all the papers about the ULE scheduler and the source code, I would like to as a simple question: is it that stupid? maybe, maybe not. It could be that the difference is minor as the cache for both kernels is in the same chip. I mean, there are just 2 processes running (except of top, X and ... which should be scheduled occasionally) on 2 cores of one physical processor. Why sould each be scheduled on a different core each time? I did cpuset to pin each to a specific core and got to about a constant temperature of 72 C. I am affraid to cpuset -l 0,1 -p ... both of them since I might again get at 100 C. This would be the interesting point? Did it happen because of the dirt or because or the scheduler. Is there some remedy? I think that the only remedy available is the one you applied. Erich I've repeated the same experiment just now, setting both processes on both cores with cpuset. The temperature got to about 72-74 C, so the two small pieces of dirt that came out, the fresh thermal liquid and tightening the screws probably gave me 10 about C on idle (from 53 C down to 45 C) and 30 C on full load. I didn't expect that much... Though, it was strange seeing both processes hopping around... I will probably go back to the 4BSD scheduler if my laptop does another self-shutdown in the next few days as Doug suggested. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable 9] broken hwpstate calls
On 06/07/12 11:10, Andriy Gapon wrote: on 07/06/2012 02:02 Jung-uk Kim said the following: Any way, hwpstate still isn't quite right even without your patch. sys/kern/kern_cpu.c cpufreq_curr_sysctl() - CPUFREQ_SET() -/* for all CPU devices */ cf_set_method() -/* thread_lock(), sched_bind(), ... */ CPUFREQ_DRV_SET() - sys/x86/cpufreq/hwpstate.c hwpstate_set() - hwpstate_goto_pstate() /* for each CPU unit */ /* thread_lock(), sched_bind(), ... */ Oh, I didn't realize that there was the cpufreq-level loop over all CPUs! That really sucks. Maybe some day we should accept that different CPUs could legitimately be in different P-states and provide support for that throughout the stack (from powerd to drivers). Support for different P-states on different CPUs can be useful if CPUs have different capabilities. I believe it is very rare, but possible. At this moment cpufreq should set for each CPU frequency closest to one that was set on BSP. It should be possible to make powerd to read sets of frequencies from all CPUs and do the same, just more intelligently. Same time using very different frequencies for different CPUs can IMHO be very problematic even in theory. For SMP systems it is quite difficult (because of threads migration and possible inter-operations of multiple threads) to identify cases when even global frequency can be reduced without proportional performance penalty. Making in per-CPU multiplies number of options and requires awareness from the scheduler. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
Hi, On 07 June 2012 10:16:07 Momchil Ivanov wrote: At Thu, 07 Jun 2012 09:12:55 +0700, Erich wrote: I've repeated the same experiment just now, setting both processes on both cores with cpuset. The temperature got to about 72-74 C, so the two small pieces of dirt that came out, the fresh thermal liquid and tightening the screws probably gave me 10 about C on idle (from 53 C down to 45 C) and 30 C on full load. I didn't expect that much... this sounds very normal to me. I clean my desktop every two months of operation. A drop of 10K is normal just for blowing the heat sink. The best design of a notebook I every have seen was my old Fujitsu. I used it from 2004 until the beginning of the year without any cleaning and any problems with dirt. After it was dead I disassembled it and did not find any dust blocking anything. Though, it was strange seeing both processes hopping around... I will probably go back to the 4BSD scheduler if my laptop does another self-shutdown in the next few days as Doug suggested. This switch might always help. I did some tests more than a year ago. I left the BSD Scheduler then on the single core Fujitsu notebook mentioned above but used the new one my desktop machine. It will also depend on the software you are running. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Netflix's New Peering Appliance Uses FreeBSD
On 06.06.12 03:16, Scott Long wrote: [...] Each disk has its own UFS+J filesystem, except for the SSDs that are mirrored together with gmirror. The SSDs hold the OS image and cache some of the busiest content. The other disks hold nothing but the audio and video files for our content streams. Could you please explain the rationale of using UFS+J for this large storage. Your published documentation states that you have reasonable redundancy in case of multiple disk failure and I wonder how you handle this with plain UFS. Things like avoiding hangs and panics when an disk is going to die. Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on arm/arm
TB --- 2012-06-07 09:03:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-06-07 09:03:00 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-07 09:03:00 - starting RELENG_8 tinderbox run for arm/arm TB --- 2012-06-07 09:03:00 - cleaning the object tree TB --- 2012-06-07 09:03:08 - cvsupping the source tree TB --- 2012-06-07 09:03:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2012-06-07 09:04:18 - building world TB --- 2012-06-07 09:04:18 - CROSS_BUILD_TESTING=YES TB --- 2012-06-07 09:04:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-07 09:04:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-07 09:04:18 - SRCCONF=/dev/null TB --- 2012-06-07 09:04:18 - TARGET=arm TB --- 2012-06-07 09:04:18 - TARGET_ARCH=arm TB --- 2012-06-07 09:04:18 - TZ=UTC TB --- 2012-06-07 09:04:18 - __MAKE_CONF=/dev/null TB --- 2012-06-07 09:04:18 - cd /src TB --- 2012-06-07 09:04:18 - /usr/bin/make -B buildworld World build started on Thu Jun 7 09:04:18 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 from.1.gz === usr.bin/fstat (all) cc -O -pipe -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O -pipe -D_KVM_VNODE -DZFS -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O -pipe -D_KVM_VNODE -DZFS -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc1: warnings being treated as errors /src/usr.bin/fstat/fstat.c: In function 'shmtrans': /src/usr.bin/fstat/fstat.c:991: warning: format '%6ju' expects type 'uintmax_t', but argument 3 has type 'size_t' *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-07 09:37:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-07 09:37:27 - ERROR: failed to build world TB --- 2012-06-07 09:37:27 - 1533.90 user 345.52 system 2066.62 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Documenting 'make config' options
On 07.06.12 08:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. I have considered this lack of information about port options myself. Sometimes, when installing new (to your understanding) software finding out what those options actually do and what are the real implications is very hard. The same situation, even worse happens when you update an port and the new version has introduced yet new options. Sometimes, hints on what those do end up in /usr/ports/UPDATING. It is clear, that something has to be done. Unfortunately, you can't just force port maintainers to document it, because of many reasons. One not very obvious reason is that many ports use pretty much 'generic' options, like WITHOUT_CUPS. For most such ports, this means I don't want cups on my system, but in few it might mean something different. Finding adequate way to document all this is a bit tricky. Good ideas are welcome. The idea Warren Block has is very useful and I fully agree that there should be some option to reset to default. It would be also extremely helpful if the dialog UI indicates somehow which options are set to something different from the default. Lacking this information is a big waste of time, especially when upgrading older ports. Or having the saved options lying around from an previous install of that port. At least, some way of mandatory describing of what setting particular option for a port does, outside of what is found in the Makefile and in plain English will be very, very useful. [off topic] By the way, on the waste of time. I view it a bit differently, when it comes to internet mailing lists. Suppose I waste 30 minutes of my time researching and preparing an response to a stupid question. It is apparently my decision to do so and nobody is blaming anyone. But imagine, this mailing list is read by tens, hundreds, thousands or even tens of thousands people (Google searches not accounted for). All those people are going to read the stupid question and the trivial answer. This is huge waste of time. Doesn't help that all those people are willingly wasting their time. Of course, we need discussions like this as a lot of people learn new things. Just the proper balance sometimes is difficult to achieve. But those who ask, will do better for everyone to try to comprehend what they have been told, before continuing their jihad. Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on i386/i386
TB --- 2012-06-07 09:15:57 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-06-07 09:15:57 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-07 09:15:57 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2012-06-07 09:15:57 - cleaning the object tree TB --- 2012-06-07 09:16:06 - cvsupping the source tree TB --- 2012-06-07 09:16:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2012-06-07 09:16:18 - building world TB --- 2012-06-07 09:16:18 - CROSS_BUILD_TESTING=YES TB --- 2012-06-07 09:16:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-07 09:16:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-07 09:16:18 - SRCCONF=/dev/null TB --- 2012-06-07 09:16:18 - TARGET=i386 TB --- 2012-06-07 09:16:18 - TARGET_ARCH=i386 TB --- 2012-06-07 09:16:18 - TZ=UTC TB --- 2012-06-07 09:16:18 - __MAKE_CONF=/dev/null TB --- 2012-06-07 09:16:18 - cd /src TB --- 2012-06-07 09:16:18 - /usr/bin/make -B buildworld World build started on Thu Jun 7 09:16:19 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 from.1.gz === usr.bin/fstat (all) cc -O2 -pipe -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc1: warnings being treated as errors /src/usr.bin/fstat/fstat.c: In function 'shmtrans': /src/usr.bin/fstat/fstat.c:991: warning: format '%6ju' expects type 'uintmax_t', but argument 3 has type 'size_t' *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-07 09:57:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-07 09:57:31 - ERROR: failed to build world TB --- 2012-06-07 09:57:31 - 1950.80 user 354.80 system 2493.69 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on mips/mips
TB --- 2012-06-07 09:38:07 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-06-07 09:38:07 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-07 09:38:07 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-06-07 09:38:07 - cleaning the object tree TB --- 2012-06-07 09:38:14 - cvsupping the source tree TB --- 2012-06-07 09:38:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2012-06-07 09:38:39 - building world TB --- 2012-06-07 09:38:39 - CROSS_BUILD_TESTING=YES TB --- 2012-06-07 09:38:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-07 09:38:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-07 09:38:39 - SRCCONF=/dev/null TB --- 2012-06-07 09:38:39 - TARGET=mips TB --- 2012-06-07 09:38:39 - TARGET_ARCH=mips TB --- 2012-06-07 09:38:39 - TZ=UTC TB --- 2012-06-07 09:38:39 - __MAKE_CONF=/dev/null TB --- 2012-06-07 09:38:39 - cd /src TB --- 2012-06-07 09:38:39 - /usr/bin/make -B buildworld World build started on Thu Jun 7 09:38:39 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 from.1.gz === usr.bin/fstat (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -D_KVM_VNODE -DZFS -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -D_KVM_VNODE -DZFS -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc1: warnings being treated as errors /src/usr.bin/fstat/fstat.c: In function 'shmtrans': /src/usr.bin/fstat/fstat.c:991: warning: format '%6ju' expects type 'uintmax_t', but argument 3 has type 'size_t' *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-07 10:10:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-07 10:10:53 - ERROR: failed to build world TB --- 2012-06-07 10:10:53 - 1480.13 user 321.11 system 1965.23 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on i386/pc98
TB --- 2012-06-07 09:31:28 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-06-07 09:31:28 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-07 09:31:28 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2012-06-07 09:31:28 - cleaning the object tree TB --- 2012-06-07 09:31:42 - cvsupping the source tree TB --- 2012-06-07 09:31:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2012-06-07 09:31:54 - building world TB --- 2012-06-07 09:31:54 - CROSS_BUILD_TESTING=YES TB --- 2012-06-07 09:31:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-07 09:31:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-07 09:31:54 - SRCCONF=/dev/null TB --- 2012-06-07 09:31:54 - TARGET=pc98 TB --- 2012-06-07 09:31:54 - TARGET_ARCH=i386 TB --- 2012-06-07 09:31:54 - TZ=UTC TB --- 2012-06-07 09:31:54 - __MAKE_CONF=/dev/null TB --- 2012-06-07 09:31:54 - cd /src TB --- 2012-06-07 09:31:54 - /usr/bin/make -B buildworld World build started on Thu Jun 7 09:31:55 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 from.1.gz === usr.bin/fstat (all) cc -O2 -pipe -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc1: warnings being treated as errors /src/usr.bin/fstat/fstat.c: In function 'shmtrans': /src/usr.bin/fstat/fstat.c:991: warning: format '%6ju' expects type 'uintmax_t', but argument 3 has type 'size_t' *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-07 10:12:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-07 10:12:45 - ERROR: failed to build world TB --- 2012-06-07 10:12:45 - 1937.20 user 362.05 system 2477.01 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ULE Scheduler
On 07.06.12 11:16, Momchil Ivanov wrote: Though, it was strange seeing both processes hopping around... I will probably go back to the 4BSD scheduler if my laptop does another self-shutdown in the next few days as Doug suggested. You never run just two processes on FreeBSD, ever. The kernel too runs multiple threads. However small the CPU usage of the other processes is, they must run from time to time, kicking out at least one of your CPU intensive processes, possibly kicking them out both, as well. When that happens, and they are queued to run again it does not matter much on which core they ran before, because chances are it's cache will be invalidated anyway. Also, different CPUs have different cache affinity. ULE is supposed to be aware of this, while the 4BSD scheduler is not. In any case, on an older single/dual core CPU there is rarely any difference between both schedulers. Differences might appear in modern multi-core CPUs.. Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on powerpc/powerpc
TB --- 2012-06-07 09:48:49 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-06-07 09:48:49 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-07 09:48:49 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2012-06-07 09:48:49 - cleaning the object tree TB --- 2012-06-07 09:48:56 - cvsupping the source tree TB --- 2012-06-07 09:48:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2012-06-07 09:49:40 - building world TB --- 2012-06-07 09:49:40 - CROSS_BUILD_TESTING=YES TB --- 2012-06-07 09:49:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-07 09:49:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-07 09:49:40 - SRCCONF=/dev/null TB --- 2012-06-07 09:49:40 - TARGET=powerpc TB --- 2012-06-07 09:49:40 - TARGET_ARCH=powerpc TB --- 2012-06-07 09:49:40 - TZ=UTC TB --- 2012-06-07 09:49:40 - __MAKE_CONF=/dev/null TB --- 2012-06-07 09:49:40 - cd /src TB --- 2012-06-07 09:49:40 - /usr/bin/make -B buildworld World build started on Thu Jun 7 09:49:40 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 from.1.gz === usr.bin/fstat (all) cc -O2 -pipe -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc1: warnings being treated as errors /src/usr.bin/fstat/fstat.c: In function 'shmtrans': /src/usr.bin/fstat/fstat.c:991: warning: format '%6ju' expects type 'uintmax_t', but argument 3 has type 'size_t' *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-07 10:29:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-07 10:29:06 - ERROR: failed to build world TB --- 2012-06-07 10:29:06 - 1953.41 user 342.99 system 2417.38 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
usr.bin/fstat warnings being treated as errors on i386
Is anyone else seeing this on a vanilla source tree ? cc1: warnings being treated as errors /usr/src/usr.bin/fstat/fstat.c:159: warning: 'struct shmfd' declared inside parameter list /usr/src/usr.bin/fstat/fstat.c:159: warning: its scope is only this definition or declaration, which is probably not what you want /usr/src/usr.bin/fstat/fstat.c:951: warning: 'struct shmfd' declared inside parameter list /usr/src/usr.bin/fstat/fstat.c:952: error: conflicting types for 'shmtrans' /usr/src/usr.bin/fstat/fstat.c:159: error: previous declaration of 'shmtrans' was here /usr/src/usr.bin/fstat/fstat.c: In function 'shmtrans': /usr/src/usr.bin/fstat/fstat.c:953: error: storage size of 'shm' isn't known /usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of 'sizeof' to incomplete type 'struct shmfd' /usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of 'sizeof' to incomplete type 'struct shmfd' /usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of 'sizeof' to incomplete type 'struct shmfd' /usr/src/usr.bin/fstat/fstat.c:953: warning: unused variable 'shm' *** Error code 1 -- - (2^(N-1)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Netflix's New Peering Appliance Uses FreeBSD
On Jun 7, 2012, at 3:09 AM, Daniel Kalchev wrote: On 06.06.12 03:16, Scott Long wrote: [...] Each disk has its own UFS+J filesystem, except for the SSDs that are mirrored together with gmirror. The SSDs hold the OS image and cache some of the busiest content. The other disks hold nothing but the audio and video files for our content streams. Could you please explain the rationale of using UFS+J for this large storage. Your published documentation states that you have reasonable redundancy in case of multiple disk failure and I wonder how you handle this with plain UFS. Things like avoiding hangs and panics when an disk is going to die. Redundancy happens by allowing the streaming clients to choose multiple other sources for their stream, and buffer enough of the stream to make a switchover appear seamless. That other source might be a peer node on the same network, or might be a node that is upstream or on a different network. The point of the caches is to hold as much content as possible, and we've found that it's more effective to maximize capacity but allow drives to fail in place than to significantly reduce capacity with hardware or software RAID. When a disk starts having problems that affect its ability to deliver data on time, any clients affected by it simply switch to a different source. When the disk does finally die, it is removed from the available pool and content is reshuffled on the other drives during the next daily content update. Once enough disks fail that the cache is no longer effective, it gets replaced. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on arm/arm
TB --- 2012-06-07 14:28:07 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-06-07 14:28:07 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-07 14:28:07 - starting RELENG_8 tinderbox run for arm/arm TB --- 2012-06-07 14:28:07 - cleaning the object tree TB --- 2012-06-07 14:28:16 - cvsupping the source tree TB --- 2012-06-07 14:28:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2012-06-07 14:28:28 - building world TB --- 2012-06-07 14:28:28 - CROSS_BUILD_TESTING=YES TB --- 2012-06-07 14:28:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-07 14:28:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-07 14:28:28 - SRCCONF=/dev/null TB --- 2012-06-07 14:28:28 - TARGET=arm TB --- 2012-06-07 14:28:28 - TARGET_ARCH=arm TB --- 2012-06-07 14:28:28 - TZ=UTC TB --- 2012-06-07 14:28:28 - __MAKE_CONF=/dev/null TB --- 2012-06-07 14:28:28 - cd /src TB --- 2012-06-07 14:28:28 - /usr/bin/make -B buildworld World build started on Thu Jun 7 14:28:28 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 from.1.gz === usr.bin/fstat (all) cc -O -pipe -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O -pipe -D_KVM_VNODE -DZFS -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O -pipe -D_KVM_VNODE -DZFS -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc1: warnings being treated as errors /src/usr.bin/fstat/fstat.c: In function 'shmtrans': /src/usr.bin/fstat/fstat.c:991: warning: format '%6ju' expects type 'uintmax_t', but argument 3 has type 'size_t' *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-07 15:01:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-07 15:01:44 - ERROR: failed to build world TB --- 2012-06-07 15:01:44 - 1537.02 user 349.72 system 2016.80 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on i386/i386
TB --- 2012-06-07 14:52:52 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-06-07 14:52:52 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-07 14:52:52 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2012-06-07 14:52:52 - cleaning the object tree TB --- 2012-06-07 14:53:01 - cvsupping the source tree TB --- 2012-06-07 14:53:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2012-06-07 14:53:25 - building world TB --- 2012-06-07 14:53:25 - CROSS_BUILD_TESTING=YES TB --- 2012-06-07 14:53:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-07 14:53:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-07 14:53:25 - SRCCONF=/dev/null TB --- 2012-06-07 14:53:25 - TARGET=i386 TB --- 2012-06-07 14:53:25 - TARGET_ARCH=i386 TB --- 2012-06-07 14:53:25 - TZ=UTC TB --- 2012-06-07 14:53:25 - __MAKE_CONF=/dev/null TB --- 2012-06-07 14:53:25 - cd /src TB --- 2012-06-07 14:53:25 - /usr/bin/make -B buildworld World build started on Thu Jun 7 14:53:26 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 from.1.gz === usr.bin/fstat (all) cc -O2 -pipe -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc1: warnings being treated as errors /src/usr.bin/fstat/fstat.c: In function 'shmtrans': /src/usr.bin/fstat/fstat.c:991: warning: format '%6ju' expects type 'uintmax_t', but argument 3 has type 'size_t' *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-07 15:34:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-07 15:34:44 - ERROR: failed to build world TB --- 2012-06-07 15:34:44 - 1962.02 user 357.80 system 2512.34 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on i386/pc98
TB --- 2012-06-07 14:56:46 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-06-07 14:56:46 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-07 14:56:46 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2012-06-07 14:56:46 - cleaning the object tree TB --- 2012-06-07 14:56:54 - cvsupping the source tree TB --- 2012-06-07 14:56:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2012-06-07 14:57:11 - building world TB --- 2012-06-07 14:57:11 - CROSS_BUILD_TESTING=YES TB --- 2012-06-07 14:57:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-07 14:57:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-07 14:57:11 - SRCCONF=/dev/null TB --- 2012-06-07 14:57:11 - TARGET=pc98 TB --- 2012-06-07 14:57:11 - TARGET_ARCH=i386 TB --- 2012-06-07 14:57:11 - TZ=UTC TB --- 2012-06-07 14:57:11 - __MAKE_CONF=/dev/null TB --- 2012-06-07 14:57:11 - cd /src TB --- 2012-06-07 14:57:11 - /usr/bin/make -B buildworld World build started on Thu Jun 7 14:57:11 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 from.1.gz === usr.bin/fstat (all) cc -O2 -pipe -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O2 -pipe -D_KVM_VNODE -DZFS -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc1: warnings being treated as errors /src/usr.bin/fstat/fstat.c: In function 'shmtrans': /src/usr.bin/fstat/fstat.c:991: warning: format '%6ju' expects type 'uintmax_t', but argument 3 has type 'size_t' *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-07 15:38:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-07 15:38:31 - ERROR: failed to build world TB --- 2012-06-07 15:38:31 - 1952.38 user 367.87 system 2505.54 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: usr.bin/fstat warnings being treated as errors on i386
On Thursday, June 07, 2012 9:29:20 am Jason Hellenthal wrote: Is anyone else seeing this on a vanilla source tree ? cc1: warnings being treated as errors /usr/src/usr.bin/fstat/fstat.c:159: warning: 'struct shmfd' declared inside parameter list /usr/src/usr.bin/fstat/fstat.c:159: warning: its scope is only this definition or declaration, which is probably not what you want /usr/src/usr.bin/fstat/fstat.c:951: warning: 'struct shmfd' declared inside parameter list /usr/src/usr.bin/fstat/fstat.c:952: error: conflicting types for 'shmtrans' /usr/src/usr.bin/fstat/fstat.c:159: error: previous declaration of 'shmtrans' was here /usr/src/usr.bin/fstat/fstat.c: In function 'shmtrans': /usr/src/usr.bin/fstat/fstat.c:953: error: storage size of 'shm' isn't known /usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of 'sizeof' to incomplete type 'struct shmfd' /usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of 'sizeof' to incomplete type 'struct shmfd' /usr/src/usr.bin/fstat/fstat.c:961: error: invalid application of 'sizeof' to incomplete type 'struct shmfd' /usr/src/usr.bin/fstat/fstat.c:953: warning: unused variable 'shm' *** Error code 1 I think you got part of a commit. Have you tried re-running csup? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Mergemaster Fails
On 06/06/12 21:20, Chris Nehren wrote: Have you tried ctrl-t? This will send SIGINFO to the process which No response to any key except ^z Additionally, the output of ps ax -d (show process trees) would be helpful. This should also show what mergemaster is waiting on. Viewing the output of the script with vi ... ^M @@ -4165,7 +4173,7 @@^M match bus uhub[0-9]+;^M match mode host;^M match vendor 0x9710;^M - match product 0x7830;^M + match product (0x7830|0x7832);^M action kldload -n if_mos;^M };^M ^M @@ -4336,5 +4344,5 @@^M action kldload -n umass;^M };^M ^M -# 1652 USB entries processed^M +# 1654 USB entries processed^M ^M ^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^G^M^[[K^[[7m(END)^[[27m^[[K^M^[[K^[[?1l^[^M Suspended^M ... There are a large number of control characters, then (END) then, no response to any key except ^z. from ps -ax -d: PID PPID STAT TIME COMMAND 00 DLs 0:00.02 [kernel] 10 ILs 0:00.02 - /sbin/init -- 1031 Is0:00.00 |-- adjkerntz -i 7531 Ss0:00.02 |-- /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/m 7731 Is0:00.00 |-- /sbin/devd 8931 Is0:00.00 |-- dhclient: em0 [priv] (dhclient) 9311 Is0:00.00 |-- dhclient: em0 (dhclient) 9721 Ss0:00.00 |-- /usr/sbin/syslogd -s 9861 Ss0:00.00 |-- /usr/sbin/rpcbind 10191 Is0:00.00 |-- /usr/sbin/mountd -r 10251 Is0:00.01 |-- nfsd: master (nfsd) 1026 1025 S 0:00.00 | `-- nfsd: server (nfsd) 10401 Is0:00.01 |-- /usr/local/sbin/cupsd -C /usr/local/etc/cups/cupsd. 10561 Ss0:00.00 |-- /usr/local/sbin/nmbd -D -s /usr/local/etc/smb.conf 10591 Ss0:00.01 |-- /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf 1107 1059 I 0:00.00 | `-- /usr/local/sbin/smbd -D -s /usr/local/etc/smb.con 10901 Ss0:00.00 |-- /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pi 11121 Ss0:00.05 |-- /usr/local/bin/postgres -D /usr/local/pgsql/data 1114 1112 Ss0:00.00 | |-- postgres: writer process(postgres) 1115 1112 Ss0:00.00 | |-- postgres: wal writer process(postgres) 1116 1112 Ss0:00.00 | |-- postgres: autovacuum launcher process (postgre 1117 1112 Ss0:00.00 | `-- postgres: stats collector process (postgres) 11261 Is0:00.00 |-- /usr/local/bin/dbus-daemon --system 11391 Ss0:00.00 |-- sendmail: accepting connections (sendmail) 11471 Is0:00.00 |-- sendmail: Queue runner@00:30:00 for /var/spool/clie 11771 Is0:00.00 |-- /usr/sbin/sshd 11811 Is0:00.00 |-- /usr/sbin/cron -s 12051 Is0:00.00 |-- /usr/sbin/inetd -wW -C 60 12371 Is0:00.13 |-- /usr/local/sbin/hald 1240 1237 I 0:00.01 | `-- hald-runner 1262 1240 I 0:00.00 | |-- hald-addon-mouse-sysmouse: /dev/ums0 (hald-addo 1304 1240 S 0:00.01 | `-- hald-addon-storage: /dev/cd0 (hald-addon-storag 12251 Is0:00.00 |-- login [pam] (login) 1308 1225 I+0:00.01 | `-- -tcsh (tcsh) 1320 1308 I 0:00.00 | `-- /bin/sh /usr/local/bin/startx 1338 1320 I 0:00.00 | `-- xinit /home/tomdean/.xinitrc -- /usr/local/bi 1339 1338 R 0:06.58 | |-- /usr/local/bin/X :0 -auth /home/tomdean/.se 1341 1338 I 0:00.01 | `-- /usr/local/bin/xterm -j -sk -sb -sl 1000 -f 1342 1341 I 0:00.01 | |-- twm 1343 1341 S 0:00.07 | |-- xclock -digital -update 1 -geometry 230x3 1344 1341 I 0:00.01 | |-- /usr/local/bin/xterm -j -sk -sb -sl 1000 1354 1344 Is+ 0:00.02 | | `-- tcsh 1363 1354 I 0:00.01 | | `-- /usr/local/bin/xterm -bd red -cr red 1365 1363 Is0:00.01 | | `-- su 1366 1365 I 0:00.01 | | `-- _su (csh) 1368 1366 I+0:00.00 | | `-- script /tmp/mergemaster 1369 1368 Is0:00.01 | | `-- /bin/csh -i 1371 1369 I+0:00.05 | | `-- /bin/sh /usr/sbin/mergemast 2423 1371 I+0:00.00 | | `-- less 1345 1341 S 0:00.02 | |-- /usr/local/bin/xterm -j -sk -sb -sl 1000 1352 1345 Ss0:00.02 | | `-- tcsh 2429 1352 R+0:00.00 | | `-- /bin/ps -o pid,ppid,stat,time,command 1346 1341 I 0:00.01 | |-- /usr/local/bin/xterm -j -sk -sb -sl 1000 1353 1346 Is+ 0:00.01 | | `-- tcsh 1351 1341 Is+
Re: Why Are You NOT Using FreeBSD ?
Phil Regnauld wrote: David Magda (dmagda) writes: On Jun 1, 2012, at 09:12, Phil Regnauld wrote: * Gluster For very large FSes, nothing beats it, especially now that 3.3 has been released. Isilon built their OneFS on top of FreeBSD, does that count? :) Panasas too IIRC. In the case of Panasas, I believe that they only provide a client driver for Linux to talk to their object storage appliance. There is an NFSv4.1 pNFS object layout that they have developed, but it requires an ODS2 (I think I got that right?) stack and it's unlikely that the client I am working on will be able to do this any time soon. rick Good pointers, thanks. It's still appliance, but good to know that FreeBSD is out there :) Phil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Mergemaster Fails
On Thu, Jun 07, 2012 at 10:05:24 -0700 , Thomas D. Dean wrote: On 06/06/12 21:20, Chris Nehren wrote: Have you tried ctrl-t? This will send SIGINFO to the process which No response to any key except ^z Additionally, the output of ps ax -d (show process trees) would be helpful. This should also show what mergemaster is waiting on. Viewing the output of the script with vi ... ^M @@ -4165,7 +4173,7 @@^M match bus uhub[0-9]+;^M match mode host;^M match vendor 0x9710;^M - match product 0x7830;^M + match product (0x7830|0x7832);^M action kldload -n if_mos;^M [snipped] There are a large number of control characters, then (END) then, no response to any key except ^z. It looks like there's a pager (probably less) that's waiting for you to respond. The output suggests it's showing you the results of diffing an old file with a new one--could be either /etc/devd.conf or /etc/usb.conf. from ps -ax -d: PID PPID STAT TIME COMMAND [snipped] 1339 1338 R 0:06.58 | |-- /usr/local/bin/X :0 -auth /home/tomdean/.se 1341 1338 I 0:00.01 | `-- /usr/local/bin/xterm -j -sk -sb -sl 1000 -f 1342 1341 I 0:00.01 | |-- twm 1343 1341 S 0:00.07 | |-- xclock -digital -update 1 -geometry 230x3 1344 1341 I 0:00.01 | |-- /usr/local/bin/xterm -j -sk -sb -sl 1000 1354 1344 Is+ 0:00.02 | | `-- tcsh 1363 1354 I 0:00.01 | | `-- /usr/local/bin/xterm -bd red -cr red 1365 1363 Is0:00.01 | | `-- su 1366 1365 I 0:00.01 | | `-- _su (csh) 1368 1366 I+0:00.00 | | `-- script /tmp/mergemaster 1369 1368 Is0:00.01 | | `-- /bin/csh -i 1371 1369 I+0:00.05 | | `-- /bin/sh /usr/sbin/mergemast 2423 1371 I+0:00.00 | | `-- less And this confirms it. So you'll probably want to examine the changes in the script(1) output and then quit the pager. I would also recommend running mergemaster in single user mode to avoid this sort of thing. X11 complicates things an awful lot. -- Thanks and best regards, Chris Nehren pgpUFFcj0563R.pgp Description: PGP signature
mpt: Unable to memory map registers
Hi, I just upgraded a few machines from 8.2-STABLE (r221983) to 9.0-STABLE (r234600) and now they can't find any disk because SAS controller cannot initialize with the following diagnostic: mpt0: LSILogic SAS/SATA Adapter port 0xd000-0xd0ff irq 26 at device 3.0 on pci6 mpt0: 0x4000 bytes of rid 0x14 res 3 failed (0, 0x). mpt0: Unable to memory map registers. mpt0: Giving Up. pciconf -lv: mpt0@pci0:6:3:0:class=0x01 card=0x81dd1043 chip=0x00541000 rev=0x02 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS1068 PCI-X Fusion-MPT SAS' class = mass storage subclass = SCSI I tried to boot to latest HEAD and found the same problem. I also tried to build kernel with mpt driver from my 8.2. Controller didn't initialize with the same diagnostic. So it looks like the problem is not in mpt driver. Any help would be appreciated. -- Andrey Zonov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD ?
David Magda wrote: On Jun 1, 2012, at 21:03, Chris Nehren wrote: You say your'e using ZVOLs but then recommend gluster for large filesystems. I would like to take a moment to point out that one of the design goals of ZFS was to scale beyond the capabilities of current hardware. What does gluster do that ZFS does not? I'm not trying to troll here, but am genuinely curious about ZFS's shortfalls in one of the problem domains it seeks to address. ZFS is for storing file systems on locally connected block devices. Gluster is a network file system where data can be distributed over many nodes. So ZFS can ensure that bits-on-disk stay safe through checksums and mirroring / RAIDZ, while Gluster allows entire file servers to go offline and the files are still accessible because you have a kind of network-level RAID going on. This also helps in performance since instead of clients pounding on one file server (as usually happens with NFS), every write is sent to many data nodes so you're striping across many network elements. Think of it as NFS on steroids. A competitive open source equivalent would be Lustre, while Isilon and Panasas would probably be commercial alternatives (though they do NFS / CIFS on the 'front-end' and the distributed magic occurs on a 'back-end' network between the appliances). http://en.wikipedia.org/wiki/GlusterFS http://en.wikipedia.org/wiki/Lustre_(file_system) Just fyi, someone is currently working on an NFSv4.1 pNFS layout type for Lustre. As such, once that layout is implemented, the NFSv4.1 client I am working on should be able to use a Lustre server cluster. So, it could be a while (next summer, maybe?), but that should be FreeBSD eventually. (I have no idea how easy porting of the Lustre server to FreeBSD would be?) Having said the above, I am not familiar with either Gluster or Lustre, so take the above as based on what little I currently know, rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Mergemaster Fails
On 06/07/12 10:55, Chris Nehren wrote: On Thu, Jun 07, 2012 at 10:05:24 -0700 , Thomas D. Dean wrote: It looks like there's a pager (probably less) that's waiting for you to respond. The output suggests it's showing you the results of diffing an old file with a new one--could be either /etc/devd.conf or /etc/usb.conf. This is obvious, but, what is causing the hang. I get it from the console as well as in an xterm. Tom Dean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD ?
Am 06.06.2012 um 20:59 schrieb Dave Hayes: I believe this is the first time I've seen more documentation labeled as extraneous. :) I had thought to suggest an implementation by having a simple pkg-option-desr file which describes the options and implications in each port. Are you suggesting that such a file would be unwelcome? No, but take a look at the nginx port, which (I'm too lazy to count) has gained a couple of dozens of options over the years. It's a bit of an extreme example, I know - but nevertheless. I've enabled some that I know what they do and some where I think I know what they do. Some are default on, so I left them on. The rest I disabled if I knew I wouldn't ever need them. Documenting all of them would probably be a huge endeavor - and I'm glad that Sergey keeps the ports updated super-fast and chases down all the updates of 3rd-party patches (which often have little more than the source itself as documentation) etc. Asking him to do even more work - I wouldn't dare to do that ;-) It's really the person who is running make config who has to read up on all the options and decide if (s)he needs them. Sometimes, options only make sense in context of the selection of options of other ports and it thus may no be easily explainable in one line. I don't maintain any ports, I just build about 600 of them in our private tinderbox. IMO, you can't really maintain more than a couple of FreeBSD-servers professionally without some sort of central package-building. The earlier people realize this, the less pain they will have to suffer. In practice, you realize it 50 or 100 servers too late... The work that goes into the ports-tree is tremendous and once you start running your own tinderbox, maintain some 3rd-party patches yourself and just generally dig deeper into this stuff you begin to realize just how difficult this is. What I do (or try to do) on my tinderbox is to take a frozen ports-tree towards a release and build packages from it (trying to minimize the number of unique builds per portstree) After the tree is open again, I try to get the stuff that interests me, the security-patches (e.g. the recent php bug) or other stuff that is useful for us as an update directly from CVS for the 600 or so ports that we actually use. Of course, this only works until something in the ports-framework changes significantly (like that options-ng thing recently) and I either have to update the whole ports-tree or just wait till the next pre-release freeze. I found that currently the fastest way to update my packages on a server is to pkg_delete -fa and then pkg_add the stuff back that I need (more or less the same packages everywhere, anyway). Portupgrade is far too slow to be of any practical use (and more than a handful of package-management-tools in the ports-mgnt category isn't really helpful, either - who has the time to test them all?) I hope that pkgng will solve most of these problems and enable me to update my ports-tree more often. Unfortunately, by then some of the FreeBSD-servers will have moved into our private cloud (using Joyent's private cloud, which, incidentally uses NetBSD's pkgsrc - we will have to see how that works out longtime) Personally, I don't need more frequent FreeBSD-releases but two or maybe three ports-tree freezes per year would be good. So, FreeBSD 9.0-RELEASE, FreeBSD 9.0-U1, FreeBSD 9.0U2 would be cool ;-) Would that be a lot of additional work? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ATI Mobility Radeon HD 5470
Hello. Can I use this video card with FreeBSD? If yes so, where I can driver download? Best regards, Vladimir Vasilenko vladi...@shumbely.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Mergemaster Fails
On Thu, Jun 07, 2012 at 10:05:24AM -0700, Thomas D. Dean wrote:
On 06/06/12 21:20, Chris Nehren wrote:
Have you tried ctrl-t? This will send SIGINFO to the process which
No response to any key except ^z
Doesn't ^t work at all for you?
If you're using tcsh and some *rxvt terminal emulator add this to your
.[t]cshrc:
# Quirk for urxvt
if(${?COLORTERM}) then
if(${COLORTERM} == rxvt-xpm ${OSTYPE} == FreeBSD) then
/bin/stty status ^t
endif
endif
pgpfOOQGeU4aJ.pgp
Description: PGP signature
Re: ULE Scheduler
Am Thu, 07 Jun 2012 03:01:07 +0200 schrieb Момчил Иванов momc...@xaxo.eu: Is there some remedy? Hi, I remember this series, I've had a T60p and when I compiled world, I placed a fan in front of it to cool it down from 100°C. The difference with T60p was that it simply shut off reaching 101°C. The problem is the hardware, not FreeBSD. T60p and obviously T60, too, was made by some crazy people who had the idea to cool the CPU und the GPU under the same heat sink. The funny thing is that the GPU is running at 70°C all the time, because FreeBSD does not implement voltage regulation for the VGA chipset. The result is that the GPU warms up the CPU to at least 55°C while idle. If you want to have a cooler CPU implement power saving for the Radeon chipset there. Martin signature.asc Description: PGP signature
Re: ULE Scheduler
At Fri, 8 Jun 2012 00:54:15 +0200, Martin Sugioarto wrote: [1 text/plain; UTF-8 (quoted-printable)] Am Thu, 07 Jun 2012 03:01:07 +0200 schrieb Момчил Иванов momc...@xaxo.eu: Is there some remedy? Hi, I remember this series, I've had a T60p and when I compiled world, I placed a fan in front of it to cool it down from 100°C. The difference with T60p was that it simply shut off reaching 101°C. The problem is the hardware, not FreeBSD. T60p and obviously T60, too, was made by some crazy people who had the idea to cool the CPU und the GPU under the same heat sink. The funny thing is that the GPU is running at 70°C all the time, because FreeBSD does not implement voltage regulation for the VGA chipset. The result is that the GPU warms up the CPU to at least 55°C while idle. If you want to have a cooler CPU implement power saving for the Radeon chipset there. Martin [2 signature.asc application/pgp-signature (7bit)] Hi, well, that is not true, I have been using the laptop since more than 4 years without any problems. The thing is that yesterday I had it docked and that seems to raise the idle temperature by about 10°C, so I get docked somewhere about 42°C when doing nothing computationally intensive: hw.acpi.thermal.tz0.temperature: 50.0C hw.acpi.thermal.tz1.temperature: 42.0C dev.cpu.0.temperature: 42.0C dev.cpu.1.temperature: 42.0C So I probably have to shift things around to give the dock a bit more room. However, the dust, the thermal liquid and the screws seem to have contributed to the temperature increase too. The GPU (Nvidia Quadro NVS 140M) might be an issue, nvidia-settings says 58°C (I am not running any fancy graphics) and I've seen it getting over 100-120°C before, when I am doing some opengl stuff. With the latter I mean, that I know how to intentionally kill it. Anyway, I have solved my problem and that seems to not be related to ULE at all. However, it was still surprising for me to find out how ULE schedules computationally intensive tasks. Regards, Momchil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Netflix's New Peering Appliance Uses FreeBSD
On Jun 5, 2012, at 6:16 PM, Scott Long wrote: Yes, we are indeed using FreeBSD at Netflix! For those who are interested, I recently moved from Yahoo to Netflix to help support FreeBSD for them, and I'm definitely impressed with what is going on there. Other than a few small changes, we're using stock FreeBSD 9, tracking the 9-stable branch on a regular basis. Our chassis is a semi-custom 4U 19 form factor with thirty six 3TB SATA disks and 2 SSDs. Each disk has its own UFS+J filesystem, except for the SSDs that are mirrored together with gmirror. The SSDs hold the OS image and cache some of the busiest content. The other disks hold nothing but the audio and video files for our content streams. We connect to the outside world via a twin-port Intel 10GBe optical NIC (only one port is active at the moment), and we use LSI MPT2 controllers for 32 of the 36 disks. The other 4 disks connect to the onboard AHCI SATA controller. All of the disks are direct-attach with no SAS backplanes or expanders. Out-of-band management happens via IPMI on an on-board 1Gb NIC. The entire system consumes around 500W of power, making it a very efficient appliance for its functionality. Netflix is also at the front of the internet pack with IPv6 roll-out, and FreeBSD plays an essential part of that. We've been working hard on stabilizing the FreeBSD IPv6 stack for production-level traffic, and I recommend that all users of IPv6 update to the latest patches in 9-stable and 8-stable. Contact me directly if you have questions about this. That said, we're excited about World IPv6 Day, and we're ready with DNS records and content service from both Amazon and the traditional CDNs as well as our OpenConnect network. From an advocacy standpoint, Netflix represents 30% of all North American internet traffic during peak hours, and FreeBSD is becoming an integral part of that metric as we shift traffic off of the traditional CDNs. We're expanding quickly, which means that FreeBSD is once again a core part of the internet infrastructure. As we find and fix stability and performance issues, we're aggressively pushing those changes into FreeBSD so that everyone can benefit from them, just as we benefit from the contributions of the rest of the FreeBSD ecosystem. We're proud to be a part of the community, and look forward to a long-term relationship with FreeBSD. If you have any questions, let me know or follow the information links on the OpenConnect web site. I wanted to follow up on this briefly. I jumped the gun a little bit in talking about this publicly, since the Openconnect website wasn't fully globally online at the time. It is now, so anyone who previously had trouble getting to it should try again at https://signup.netflix.com/openconnect. Also, I mistakenly claimed that our regular CDN partners were serving streaming content over IPv6. This isn't the case, only OpenConnect is, and I apologize for any confusion (hey, I've only just started at Netflix, and I couldn't even spell IPv6 two weeks ago =-) Finally, I wanted to thank the NginX developers, they've done an amazing job supporting us. The community enthusiasm and interest has been outstanding so far, so please feel free to continue to ask questions on the mailing list and to make formal inquires to Netflix. Thanks, Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Netflix's New Peering Appliance Uses FreeBSD
Hi Scott, [...] I wanted to follow up on this briefly. I jumped the gun a little bit in talking about this publicly, since the Openconnect website wasn't fully globally online at the time. It is now, so anyone who previously had trouble getting to it should try again at https://signup.netflix.com/openconnect. Also, I mistakenly claimed that our regular CDN partners were serving streaming content over IPv6. This isn't the case, only OpenConnect is, and I apologize for any confusion (hey, I've only just started at Netflix, and I couldn't even spell IPv6 two weeks ago =-) Finally, I wanted to thank the NginX developers, they've done an amazing job supporting us. On behalf of nginx team I'd like to thank you and all Netflix team for the chance to work on such an interesting project and your help and cooperation. Thanks much! -- Maxim Konovalov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
