Re: svn commit: r214611 - head/sys/kern
On Wed, Jun 15, 2011 at 09:41:28AM +0400, Sergey Kandaurov wrote:
> On 15 June 2011 06:20, David Xu wrote:
> > On 2011/06/14 20:02, Sergey Kandaurov wrote:
> >> On 1 November 2010 03:42, David Xu wrote:
> >>> Author: davidxu
> >>> Date: Mon Nov 1 00:42:25 2010
> >>> New Revision: 214611
> >>> URL: http://svn.freebsd.org/changeset/base/214611
> >>>
> >>> Log:
> >>> Use integer for size of cpuset, as it won't be bigger than INT_MAX,
> >>> This is requested by bge.
> >>> Also move the sysctl into file kern_cpuset.c, because it should
> >>> always be there, it is independent of thread scheduler.
> >>
> >> Hi.
> >> This breaks for me fetching a cpusetsize value with sysconf(3) interface,
> >> as after this change sysconf(3) consumers expect a long return type, while
> >> sysctl kern.sched.cpusetsize has switched from long to int type in kernel.
> >> That makes for me sizeof(cpusize_t) from 8 to incorrect 34359738376.
> >>
> >> In particular, kvm_getpcpu(3) uses sysconf(3) to fetch cpusetsize on
> >> live kernel. That gives me a broken result:
> >> kvm_open: kcpusetsize: 8
> >> pcpu[0] = 0x801072300
> >> kvm_open: kcpusetsize: 34359738376
> >> pcpu[1] = 0x
> >> kvm_open: kcpusetsize: 8
> >> pcpu[2] = 0x801072600
> >> kvm_open: kcpusetsize: 34359738376
> >> pcpu[3] = 0x
> >>
> >> This small test indicates that that's due to int->long type conversion:
> >> long lvalue;
> >> size_t len;
> >>
> >> len = sizeof(lvalue);
> >> if (sysctlbyname("kern.sched.cpusetsize", &lvalue, &len, NULL, 0)
> >> < 0)
> >> err(1, "sysctlbyname");
> >> printf("sysctl: %ld\n", lvalue);
> >> printf("sysctl: %d -- explicitly casted to (int)\n", (int)lvalue);
> >> printf("sysconf: %ld\n", sysconf(_SC_CPUSET_SIZE));
> >> printf("sysconf: %d -- explicitly casted to (int)\n",
> >> (int)sysconf(_SC_CPUSET_SIZE));
> >>
> >> That prints:
> >> sysctl: 34359738376
> >> sysctl: 8 -- explicitly casted to (int)
> >> sysconf: 34359738376
> >> sysconf: 8 -- explicitly casted to (int)
> >>
> >> The other way to solve this other than reverting is to "fix" all cpusetsize
> >> consumers in userland. Now sysconf() saves long returned value to int:
> >>
> >> Index: lib/libkvm/kvm_pcpu.c
> >> ===
> >> --- lib/libkvm/kvm_pcpu.c (revision 223073)
> >> +++ lib/libkvm/kvm_pcpu.c (working copy)
> >> @@ -120,7 +120,7 @@
> >> void *
> >> kvm_getpcpu(kvm_t *kd, int cpu)
> >> {
> >> - long kcpusetsize;
> >> + int kcpusetsize;
> >> ssize_t nbytes;
> >> uintptr_t readptr;
> >> char *buf;
> >>
> >> So, after applying the above change all is ok:
> >> kvm_open: kcpusetsize: 8
> >> pcpu[0] = 0x801072300
> >> kvm_open: kcpusetsize: 8
> >> pcpu[1] = 0x801072600
> >> kvm_open: kcpusetsize: 8
> >> pcpu[2] = 0x801072900
> >> kvm_open: kcpusetsize: 8
> >> pcpu[3] = 0x801072c00
> >>
> >>
> > Try this patch, I think it should fix it.
> >
> > Index: lib/libc/gen/sysconf.c
> > ===
> > --- lib/libc/gen/sysconf.c (revision 221356)
> > +++ lib/libc/gen/sysconf.c (working copy)
> > @@ -599,11 +599,11 @@
> >
> > #ifdef _SC_CPUSET_SIZE
> > case _SC_CPUSET_SIZE:
> > - len = sizeof(lvalue);
> > - if (sysctlbyname("kern.sched.cpusetsize", &lvalue, &len,
> > NULL,
> > + len = sizeof(value);
> > + if (sysctlbyname("kern.sched.cpusetsize", &value, &len,
> > NULL,
> > 0) == -1)
> > return (-1);
> > - return (lvalue);
> > + return ((long)(value));
> > #endif
> >
> > default:
> >
>
> Great, thanks! Look good for me.
> Nitpicking:
> return ((long)value); should be enough (extra parenthesis).
This patch accomodates the userland to the changed ABI. Why it was
changed at all ? I would argue that keeping the stable ABI there is
more important then using a 'clean' type.
At least, the stable branches usermode is broken on the current kernel.
pgpC7u7klvMaE.pgp
Description: PGP signature
Re: svn commit: r214611 - head/sys/kern
On 2011/06/15 15:39, Kostik Belousov wrote: > This patch accomodates the userland to the changed ABI. Why it was > changed at all ? I would argue that keeping the stable ABI there is > more important then using a 'clean' type. > > At least, the stable branches usermode is broken on the current kernel. Does stable/8 support _SC_CPUSET_SIZE ? I have not looked code in stable. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r214611 - head/sys/kern
On Wed, Jun 15, 2011 at 04:08:34PM +0800, David Xu wrote: > On 2011/06/15 15:39, Kostik Belousov wrote: > > > This patch accomodates the userland to the changed ABI. Why it was > > changed at all ? I would argue that keeping the stable ABI there is > > more important then using a 'clean' type. > > > > At least, the stable branches usermode is broken on the current kernel. > > Does stable/8 support _SC_CPUSET_SIZE ? I have not looked code in > stable. Hm, no, it is not in the stable/8. Thanks for the clarification. pgpSgn76IzeWA.pgp Description: PGP signature
problems with cvsup on FreeBSD 9 snapshot 201101
Dear all, I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso Today I wanted to cvsup to a later date to upgrade to ZFS v28 and compiled port /usr/ports/net/cvsup-without-gui without problems. Starting freshly compiled cvsup then gives me "Illegal Instruction" This error seems to be identical to http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html As this was created on a vanilla 9 snapshot using the default make.conf with only cvsup settings adapted I thought this might be of interest. Have now used csup instead of cvsup (which seems to have worked fine), and started cvsup once again (seems cvsup only gives "Illegal Instruction" when a file needs to be changed...). Any ideas? Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.k...@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com -- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with cvsup on FreeBSD 9 snapshot 201101
W dniu 2011-06-15 14:23, Holger Kipp pisze: Dear all, I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso Today I wanted to cvsup to a later date to upgrade to ZFS v28 and compiled port /usr/ports/net/cvsup-without-gui without problems. Starting freshly compiled cvsup then gives me "Illegal Instruction" This error seems to be identical to http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html As this was created on a vanilla 9 snapshot using the default make.conf with only cvsup settings adapted I thought this might be of interest. Have now used csup instead of cvsup (which seems to have worked fine), and started cvsup once again (seems cvsup only gives "Illegal Instruction" when a file needs to be changed...). Any ideas? Best regards, Holger Although it's not a "fix" to your problem, doesn't cvsup became obsolete, from the moment when csup was integrated into the world (a couple of years ago I believe)? If you just want to update the ports tree, use csup. -- Bartosz Stec ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with cvsup on FreeBSD 9 snapshot 201101
W dniu 2011-06-15 14:23, Holger Kipp pisze: Have now used csup instead of cvsup (which seems to have worked fine), and started cvsup once again (seems cvsup only gives "Illegal Instruction" when a file needs to be changed...). Any ideas? Whoops, I read your message too fast, apologize. Please ignore my previous email :) -- Bartosz Stec ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with cvsup on FreeBSD 9 snapshot 201101
On 6/15/11 8:23 AM, Holger Kipp wrote: Dear all, I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso Today I wanted to cvsup to a later date to upgrade to ZFS v28 and compiled port /usr/ports/net/cvsup-without-gui without problems. Starting freshly compiled cvsup then gives me "Illegal Instruction" This error seems to be identical to http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html I've gotten the same problem, and managed to diagnose it. The problem actually isn't an illegal instruction, but a stack misalignment. If you load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a callq instruction. This is because callq needs the stack to be 16-byte aligned, and it's not for some reason. As for why it's not aligned, I don't know. -- Eric McCorkle Computer Science Ph.D Student, University of Massachusetts Research Intern, IBM Research ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with cvsup on FreeBSD 9 snapshot 201101
On Wed, Jun 15, 2011 at 10:24:46AM -0400, Eric McCorkle wrote: > On 6/15/11 8:23 AM, Holger Kipp wrote: > >Dear all, > > > >I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: > >ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso > > > > > > > >Today I wanted to cvsup to a later date to upgrade to ZFS v28 > >and compiled port /usr/ports/net/cvsup-without-gui without problems. > > > >Starting freshly compiled cvsup then gives me > > > >"Illegal Instruction" > > > >This error seems to be identical to > >http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html > > > > > > I've gotten the same problem, and managed to diagnose it. The problem > actually isn't an illegal instruction, but a stack misalignment. If you > load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a > callq instruction. This is because callq needs the stack to be 16-byte > aligned, and it's not for some reason. Stack alignment requirement is an ABI convention, and it is not enforced by CPU, except several special cases. In particular, either EFLAGS.AC bit should be set, that usually is not, or SSE instruction explicitely disallowing non-aligned access executed. Anyway, you will not get Illegal instruction fault for unaligned access. > > As for why it's not aligned, I don't know. > > -- > Eric McCorkle > Computer Science Ph.D Student, > University of Massachusetts > Research Intern, IBM Research > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" pgpbOT6ivEoap.pgp Description: PGP signature
Re: problems with cvsup on FreeBSD 9 snapshot 201101
On 6/15/11 10:46 AM, Holger Kipp wrote: Ah, ok. Do we have a compiler switch to force stack alignment to 16-Byte-boundaries? Otherwise I am really concerned that we might have similar wrong pieces of code lurking unnoticed in other binaries as well :-/ My cvsup binary is: # file /usr/local/bin/cvsup /usr/local/bin/cvsup: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900029), stripped Best regards, Holger (Accidentally replied directly to you, cc'ing list) It's certainly possible, though GCC aligns the stack correctly, or else nothing would work. CVSup is written in Modula 3. I checked the stack alignment option for FBSD_AMD64, and it is sure enough set to 16. My guess is somewhere in the native call interface, something's not being done right. I ran into a similar problem when porting the mlton compiler to Mac OS a couple of years back. -- Eric McCorkle Computer Science Ph.D student, University of Massachusetts Research Intern, IBM Research ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: problems with cvsup on FreeBSD 9 snapshot 201101
Ah, ok. Do we have a compiler switch to force stack alignment to 16-Byte-boundaries? Otherwise I am really concerned that we might have similar wrong pieces of code lurking unnoticed in other binaries as well :-/ My cvsup binary is: # file /usr/local/bin/cvsup /usr/local/bin/cvsup: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900029), stripped Best regards, Holger From: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] on behalf of Eric McCorkle [e...@shadowsun.net] Sent: 15 June 2011 16:24 To: freebsd-current@freebsd.org Subject: Re: problems with cvsup on FreeBSD 9 snapshot 201101 On 6/15/11 8:23 AM, Holger Kipp wrote: > Dear all, > > I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso > > > Today I wanted to cvsup to a later date to upgrade to ZFS v28 > and compiled port /usr/ports/net/cvsup-without-gui without problems. > > Starting freshly compiled cvsup then gives me > > "Illegal Instruction" > > This error seems to be identical to > http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html > I've gotten the same problem, and managed to diagnose it. The problem actually isn't an illegal instruction, but a stack misalignment. If you load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a callq instruction. This is because callq needs the stack to be 16-byte aligned, and it's not for some reason. As for why it's not aligned, I don't know. -- Eric McCorkle Computer Science Ph.D Student, University of Massachusetts Research Intern, IBM Research ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.k...@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com -- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Simple tidy up of puc(4) bus driver
On Tue, Jun 14, 2011 at 11:34:34AM -0400, John Baldwin wrote: > On Tuesday, June 14, 2011 10:44:18 am Alexey Shuvaev wrote: > > On Fri, Jun 10, 2011 at 03:11:02PM -0400, John Baldwin wrote: > > > On Monday, May 23, 2011 10:39:02 am John Baldwin wrote: > > > > This small patch makes the puc(4) bus drivers a little more friendly. > > > > It > > > > should now list the port for each child device in the boot messages, > > > > and > > > > devinfo -v should list the type and port of each child device in its > > > > output as > > > > well: > > > > > > Can I get a volunteer to test these changes? > > > > > Would it be OK to use r202285 as a base for your patch? > > If so, I will test it today/tomorrow. If not, it will take a little bit > > longer... > > Yes, it should apply fine to that. It doesn't touch pucdata.c which is the > only thing in the puc driver that has changed since that revision. Thanks! > Seems to work fine. Attached are relevant diff-s of dmesg.boot and devinfo -v output. Alexey. --- dmesg.boot_old 2011-06-15 16:18:52.0 +0200 +++ dmesg.boot_new 2011-06-15 16:23:56.0 +0200 @@ -49,11 +49,11 @@ pcm0: puc0: port 0x7c00-0x7c07,0x8000-0x8007,0x8400-0x8407,0x8800-0x8807,0x8c00-0x8c07,0x9000-0x900f irq 7 at device 10.0 on pci0 puc0: [FILTER] -uart2: on puc0 +uart2: at port 1 on puc0 uart2: [FILTER] -uart3: on puc0 +uart3: at port 2 on puc0 uart3: [FILTER] -ppc0: on puc0 +ppc0: at port 3 on puc0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/12 bytes threshold ppbus0: on ppc0 --- devinfo_old 2011-06-15 16:19:03.0 +0200 +++ devinfo_new 2011-06-15 16:24:02.0 +0200 @@ -38,9 +38,9 @@ hostb1 pnpinfo vendor=0x1106 device=0x3057 subvendor=0x subdevice=0x class=0x06 at slot=7 function=4 handle=\_SB_.PCI0.VTAC pcm0 pnpinfo vendor=0x1106 device=0x3058 subvendor=0x11d6 subdevice=0x7358 class=0x040100 at slot=7 function=5 puc0 pnpinfo vendor=0x9710 device=0x9835 subvendor=0x1000 subdevice=0x0012 class=0x078000 at slot=10 function=0 - uart2 - uart3 - ppc0 + uart2 pnpinfo type=1 at port=1 + uart3 pnpinfo type=1 at port=2 + ppc0 pnpinfo type=2 at port=3 ppbus0 plip0 lpt0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-CUR/amd64 CLANG: howto use gcc __builtin_ia32?
You could try using the standard header - that has inline functions which should cover all the SSE instructions. On 12 June 2011 17:43, Hartmann, O. wrote: > I use some numerical code utilizing the SIMD units of modern X86 > architectures. Code compiles well using gcc/gcc46, > but clang does not know about the __builtin_ia32_x() statements. How to > treat those in clang and how to make > C code compiling with clang utilizing those __builtin_ia32 statements? > > Thanks, > Oliver > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time keeping Issues with the low-resolution TSC timecounter
> > The problem I noticed first is that it takes unusually long until a > > key press is repeated. With the default eventtimer (HPET) it seems > > to take about 4s, which can be slightly improved by switching to > > i8254. > > > > The "error beep" seems to take longer than usual, too, > > and the system "feels sluggish" in general. > > > > An effect that is easier to measure is that the system is unable > > to properly keep the time. Again the problem is less severe when > > using i8254 instead of HPET: > > [SNIP] > > First of all, please do not mix timecounter issues with eventtimer. > They are not directly related. > > Can you please show me verbose boot messages *without* your patch? > Does "sysctl kern.timecounter.hardware=HPET" help *without* touching > eventtimers? I have the same issue with my system (Atom N270). The effect that I see is about 29 wall clock seconds are recorded as 1 system second. I had do something similar to the OP to make my system useable since it doesn't seem possible to influence timecounter choice at boot time. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time keeping Issues with the low-resolution TSC timecounter
On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote: > > > The problem I noticed first is that it takes unusually long > > > until a key press is repeated. With the default eventtimer > > > (HPET) it seems to take about 4s, which can be slightly > > > improved by switching to i8254. > > > > > > The "error beep" seems to take longer than usual, too, > > > and the system "feels sluggish" in general. > > > > > > An effect that is easier to measure is that the system is > > > unable to properly keep the time. Again the problem is less > > > severe when using i8254 instead of HPET: > > > > [SNIP] > > > > First of all, please do not mix timecounter issues with > > eventtimer. They are not directly related. > > > > Can you please show me verbose boot messages *without* your > > patch? Does "sysctl kern.timecounter.hardware=HPET" help > > *without* touching eventtimers? > > I have the same issue with my system (Atom N270). The effect that > I see is about 29 wall clock seconds are recorded as 1 system > second. Can please you send me output from the following? sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1));\ sysctl kern.timecounter; sleep 1; done' > I had do something similar to the OP to make my system useable since > it doesn't seem possible to influence timecounter choice at boot > time. You can just add the following line in /etc/sysctl.conf for now: kern.timecounter.hardware=HPET Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fast/syscall-free gettimeofday ?
If this was to be extended with cached global syscall information like gettimeofday, would we want that to be in a separate page that is marked non-executable? Is there any way to trick the kernel into leaking arbitrary (and thus executable) code? Also, would it matter for jails? Per-process info like getpid would obviously have to be a separate per-process page. Scott On Jun 14, 2011, at 10:08 AM, K. Macy wrote: > http://svnweb.freebsd.org/base/head/sys/sys/imgact.h > > kib added rudimentary support for this in January > > On Tue, Jun 14, 2011 at 6:11 PM, Luigi Rizzo wrote: >> there were discussions at some point on an imprecise but >> fast implementations of gettimeofday() that would not require >> a system call (perhaps mmapping some memory region which >> is opportunistically updated). >> >> Does anyone remember what happened about that ? >> >> Otherwise, is there any place in the kernel where i can fetch >> a struct timeval which is not off by more than, say 1 tick ? >> >> cheers >> luigi >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time keeping Issues with the low-resolution TSC timecounter
On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote: > On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote: > > > > The problem I noticed first is that it takes unusually long > > > > until a key press is repeated. With the default eventtimer > > > > (HPET) it seems to take about 4s, which can be slightly > > > > improved by switching to i8254. > > > > > > > > The "error beep" seems to take longer than usual, too, > > > > and the system "feels sluggish" in general. > > > > > > > > An effect that is easier to measure is that the system is > > > > unable to properly keep the time. Again the problem is less > > > > severe when using i8254 instead of HPET: > > > > > > [SNIP] > > > > > > First of all, please do not mix timecounter issues with > > > eventtimer. They are not directly related. > > > > > > Can you please show me verbose boot messages *without* your > > > patch? Does "sysctl kern.timecounter.hardware=HPET" help > > > *without* touching eventtimers? > > > > I have the same issue with my system (Atom N270). The effect > > that I see is about 29 wall clock seconds are recorded as 1 > > system second. > > Can please you send me output from the following? > > sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1));\ > sysctl kern.timecounter; sleep 1; done' The OP sent me some data. The following is cooked data from what I got: TSC Delta Elapsed Time ---+---+ 2245026970 2249708604 4681634 0.3003693189 2255874998 6166394 0.3956301509 2260656402 4781404 0.3067704701 2261993048 1336646 0.0857579744 2264175164 2182116 0.1400025497 2266445706 2270542 0.1456758803 2266987003 541297 0.0347291162 2267645095 658092 0.045757 2268274965 629870 0.0404118782 2268979787 704822 0.0452207294 2270482069 1502282 0.0963850274 2271140877 658808 0.0422685136 HPETDelta Elapsed Time ---+---+ 1322734365 1337156221 144218561.0072408644 1351548130 143919091.0051493276 1365949265 144011351.0057936833 1380376349 144270841.0076059946 1394823985 144476361.0090413726 1409273964 144499791.0092050107 1423719753 144457891.0089123757 1438167064 144473111.0090186742 1452613630 144465661.0089666424 1467062977 144493471.0091608710 1481522037 144590601.0098392393 1495969404 144473671.0090225853 As you can see, HPET increases normally (within errors from sleep(3) accuracy, syscall overhead, etc.) but TSC-low is totally erratic (and too low). I don't know how this can happen, though. :-( I need some time to figure it out. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time keeping Issues with the low-resolution TSC timecounter
On Wednesday 15 June 2011 06:19 pm, Jung-uk Kim wrote:
> On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote:
> > On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
> > > > > The problem I noticed first is that it takes unusually long
> > > > > until a key press is repeated. With the default eventtimer
> > > > > (HPET) it seems to take about 4s, which can be slightly
> > > > > improved by switching to i8254.
> > > > >
> > > > > The "error beep" seems to take longer than usual, too,
> > > > > and the system "feels sluggish" in general.
> > > > >
> > > > > An effect that is easier to measure is that the system is
> > > > > unable to properly keep the time. Again the problem is less
> > > > > severe when using i8254 instead of HPET:
> > > >
> > > > [SNIP]
> > > >
> > > > First of all, please do not mix timecounter issues with
> > > > eventtimer. They are not directly related.
> > > >
> > > > Can you please show me verbose boot messages *without* your
> > > > patch? Does "sysctl kern.timecounter.hardware=HPET" help
> > > > *without* touching eventtimers?
> > >
> > > I have the same issue with my system (Atom N270). The effect
> > > that I see is about 29 wall clock seconds are recorded as 1
> > > system second.
> >
> > Can please you send me output from the following?
> >
> > sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count -
> > 1));\ sysctl kern.timecounter; sleep 1; done'
>
> The OP sent me some data. The following is cooked data from what I
> got:
>
> TSC Delta Elapsed Time
> ---+---+
> 2245026970
> 22497086044681634 0.3003693189
> 22558749986166394 0.3956301509
> 22606564024781404 0.3067704701
> 22619930481336646 0.0857579744
> 22641751642182116 0.1400025497
> 22664457062270542 0.1456758803
> 2266987003541297 0.0347291162
> 2267645095658092 0.045757
> 2268274965629870 0.0404118782
> 2268979787704822 0.0452207294
> 22704820691502282 0.0963850274
> 2271140877658808 0.0422685136
>
> HPET Delta Elapsed Time
> ---+---+
> 1322734365
> 1337156221144218561.0072408644
> 1351548130143919091.0051493276
> 1365949265144011351.0057936833
> 1380376349144270841.0076059946
> 1394823985144476361.0090413726
> 1409273964144499791.0092050107
> 1423719753144457891.0089123757
> 1438167064144473111.0090186742
> 1452613630144465661.0089666424
> 1467062977144493471.0091608710
> 1481522037144590601.0098392393
> 1495969404144473671.0090225853
>
> As you can see, HPET increases normally (within errors from
> sleep(3) accuracy, syscall overhead, etc.) but TSC-low is totally
> erratic (and too low). I don't know how this can happen, though.
> :-(
>
> I need some time to figure it out.
Can you please test the attached patch? Theoretically, it should not
make a difference but I'd like to see if it does, just in case.
Thanks,
Jung-uk Kim
Index: sys/x86/x86/tsc.c
===
--- sys/x86/x86/tsc.c (revision 223102)
+++ sys/x86/x86/tsc.c (working copy)
@@ -579,6 +579,9 @@ tsc_get_timecount(struct timecounter *tc __unused)
static u_int
tsc_get_timecount_low(struct timecounter *tc)
{
+ uint32_t low, high;
- return (rdtsc() >> (int)(intptr_t)tc->tc_priv);
+ __asm __volatile("rdtsc; shrd %2,%1,%0"
+ : "=a" (low), "=d" (high) : "Ic" ((uint8_t)(intptr_t)tc->tc_priv));
+ return (low);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-06-16 00:06:25 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 00:06:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-06-16 00:06:25 - cleaning the object tree TB --- 2011-06-16 00:06:39 - cvsupping the source tree TB --- 2011-06-16 00:06:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-06-16 00:07:04 - building world TB --- 2011-06-16 00:07:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 00:07:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 00:07:04 - TARGET=sparc64 TB --- 2011-06-16 00:07:04 - TARGET_ARCH=sparc64 TB --- 2011-06-16 00:07:04 - TZ=UTC TB --- 2011-06-16 00:07:04 - __MAKE_CONF=/dev/null TB --- 2011-06-16 00:07:04 - cd /src TB --- 2011-06-16 00:07:04 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 00:07:05 UTC 2011 >>> 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 [...] cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/sbrk.c cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/twiddle.c cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/zalloc.c cc1: warnings being treated as errors /src/lib/libstand/zalloc.c: In function 'zfree': /src/lib/libstand/zalloc.c:157: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' /src/lib/libstand/zalloc.c:181: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' /src/lib/libstand/zalloc.c:212: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' *** Error code 1 Stop in /src/lib/libstand. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 00:36:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 00:36:14 - ERROR: failed to build world TB --- 2011-06-16 00:36:14 - 1270.96 user 310.14 system 1789.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fast/syscall-free gettimeofday ?
If this was to be extended with cached global syscall information like gettimeofday, would we want that to be in a separate page that is marked non-executable? Is there any way to trick the kernel into leaking arbitrary (and thus executable) code? Also, would it matter for jails? Per-process info like getpid would obviously have to be a separate per-process page. Scott In the talk about this sort of topic I have seen mention at various times of a page per system, a page per jail, a page per process and a page per thread. I'm not saying we want this all just that I've seen it mentionned.. The per-thread one is the most intersting to do challenge wise. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with cvsup on FreeBSD 9 snapshot 201101
On 6/15/11 10:58 AM, Kostik Belousov wrote: On Wed, Jun 15, 2011 at 10:24:46AM -0400, Eric McCorkle wrote: On 6/15/11 8:23 AM, Holger Kipp wrote: Dear all, I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso Today I wanted to cvsup to a later date to upgrade to ZFS v28 and compiled port /usr/ports/net/cvsup-without-gui without problems. Starting freshly compiled cvsup then gives me "Illegal Instruction" This error seems to be identical to http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html I've gotten the same problem, and managed to diagnose it. The problem actually isn't an illegal instruction, but a stack misalignment. If you load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a callq instruction. This is because callq needs the stack to be 16-byte aligned, and it's not for some reason. Stack alignment requirement is an ABI convention, and it is not enforced by CPU, except several special cases. In particular, either EFLAGS.AC bit should be set, that usually is not, or SSE instruction explicitely disallowing non-aligned access executed. Anyway, you will not get Illegal instruction fault for unaligned access. I took a closer look this afternoon, and you're right. callq with an unaligned stack pointer does *not* cause a fault. If anyone does a movaps, however, you will get a fault (SIGBUS, I believe), and if the ABI says stacks are 16-byte aligned, then libraries may assume it's safe to load from the stack with movaps, and you'll get a fault. This is what happened to mlton on Mac OS, so I thought it might be something similar going on here. Anyways, I'll look into it more. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fast/syscall-free gettimeofday ?
On Jun 15, 2011, at 6:44 PM, Julian Elischer wrote: >> If this was to be extended with cached global syscall information like >> gettimeofday, would we want that to be in a separate page that is marked >> non-executable? Is there any way to trick the kernel into leaking arbitrary >> (and thus executable) code? Also, would it matter for jails? Per-process >> info like getpid would obviously have to be a separate per-process page. >> >> Scott >> > In the talk about this sort of topic I have seen mention at various times > of a page per system, a page per jail, a page per process and a page per > thread. > > I'm not saying we want this all just that I've seen it mentionned.. > > The per-thread one is the most intersting to do challenge wise. I guess that per-thread would be done via a pointer off of the TLS data, or would it be yet another bumping of the stack? It would be interesting to see how expensive it is to go that direction. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fast/syscall-free gettimeofday ?
On Jun 15, 2011, at 6:44 PM, Julian Elischer wrote: If this was to be extended with cached global syscall information like gettimeofday, would we want that to be in a separate page that is marked non-executable? Is there any way to trick the kernel into leaking arbitrary (and thus executable) code? Also, would it matter for jails? Per-process info like getpid would obviously have to be a separate per-process page. Scott In the talk about this sort of topic I have seen mention at various times of a page per system, a page per jail, a page per process and a page per thread. I'm not saying we want this all just that I've seen it mentionned.. The per-thread one is the most intersting to do challenge wise. I guess that per-thread would be done via a pointer off of the TLS data, or would it be yet another bumping of the stack? It would be interesting to see how expensive it is to go that direction. note that I wasn't volunteering ;-) Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on arm/arm
TB --- 2011-06-16 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 02:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-16 02:10:00 - cleaning the object tree TB --- 2011-06-16 02:10:21 - cvsupping the source tree TB --- 2011-06-16 02:10:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-16 02:10:37 - building world TB --- 2011-06-16 02:10:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 02:10:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 02:10:37 - TARGET=arm TB --- 2011-06-16 02:10:37 - TARGET_ARCH=arm TB --- 2011-06-16 02:10:37 - TZ=UTC TB --- 2011-06-16 02:10:37 - __MAKE_CONF=/dev/null TB --- 2011-06-16 02:10:37 - cd /src TB --- 2011-06-16 02:10:37 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 02:10:37 UTC 2011 >>> 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 [...] cc -O -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_alloc.c cc -O -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_balloc.c cc -O -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_bswap.c cc1: warnings being treated as errors In file included from /src/usr.sbin/makefs/ffs/ffs_bswap.c:51: /obj/arm.arm/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: 'enum vtype' declared inside parameter list /obj/arm.arm/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: its scope is only this definition or declaration, which is probably not what you want /obj/arm.arm/src/tmp/usr/include/ufs/ffs/ffs_extern.h:85: warning: 'enum vtype' declared inside parameter list *** Error code 1 Stop in /src/usr.sbin/makefs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 03:00:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 03:00:11 - ERROR: failed to build world TB --- 2011-06-16 03:00:11 - 2170.97 user 616.24 system 3011.37 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on ia64/ia64
TB --- 2011-06-16 03:00:12 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 03:00:12 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-06-16 03:00:12 - cleaning the object tree TB --- 2011-06-16 03:00:23 - cvsupping the source tree TB --- 2011-06-16 03:00:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-06-16 03:00:34 - building world TB --- 2011-06-16 03:00:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 03:00:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 03:00:34 - TARGET=ia64 TB --- 2011-06-16 03:00:34 - TARGET_ARCH=ia64 TB --- 2011-06-16 03:00:34 - TZ=UTC TB --- 2011-06-16 03:00:34 - __MAKE_CONF=/dev/null TB --- 2011-06-16 03:00:34 - cd /src TB --- 2011-06-16 03:00:34 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 03:00:35 UTC 2011 >>> 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 [...] cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/sbrk.c cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/twiddle.c cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/zalloc.c cc1: warnings being treated as errors /src/lib/libstand/zalloc.c: In function 'zfree': /src/lib/libstand/zalloc.c:157: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' /src/lib/libstand/zalloc.c:181: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' /src/lib/libstand/zalloc.c:212: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' *** Error code 1 Stop in /src/lib/libstand. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 03:35:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 03:35:37 - ERROR: failed to build world TB --- 2011-06-16 03:35:37 - 1624.59 user 335.12 system 2124.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/pc98
TB --- 2011-06-16 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 02:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-06-16 02:10:00 - cleaning the object tree TB --- 2011-06-16 02:10:23 - cvsupping the source tree TB --- 2011-06-16 02:10:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-06-16 02:10:38 - building world TB --- 2011-06-16 02:10:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 02:10:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 02:10:38 - TARGET=pc98 TB --- 2011-06-16 02:10:38 - TARGET_ARCH=i386 TB --- 2011-06-16 02:10:38 - TZ=UTC TB --- 2011-06-16 02:10:38 - __MAKE_CONF=/dev/null TB --- 2011-06-16 02:10:38 - cd /src TB --- 2011-06-16 02:10:38 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 02:10:38 UTC 2011 >>> 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 [...] cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_alloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_balloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_bswap.c cc1: warnings being treated as errors In file included from /src/usr.sbin/makefs/ffs/ffs_bswap.c:51: /obj/pc98.i386/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: 'enum vtype' declared inside parameter list /obj/pc98.i386/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: its scope is only this definition or declaration, which is probably not what you want /obj/pc98.i386/src/tmp/usr/include/ufs/ffs/ffs_extern.h:85: warning: 'enum vtype' declared inside parameter list *** Error code 1 Stop in /src/usr.sbin/makefs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 04:02:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 04:02:20 - ERROR: failed to build world TB --- 2011-06-16 04:02:20 - 5490.27 user 902.85 system 6740.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on amd64/amd64
TB --- 2011-06-16 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 02:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-06-16 02:10:00 - cleaning the object tree TB --- 2011-06-16 02:10:27 - cvsupping the source tree TB --- 2011-06-16 02:10:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-06-16 02:10:40 - building world TB --- 2011-06-16 02:10:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 02:10:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 02:10:40 - TARGET=amd64 TB --- 2011-06-16 02:10:40 - TARGET_ARCH=amd64 TB --- 2011-06-16 02:10:40 - TZ=UTC TB --- 2011-06-16 02:10:40 - __MAKE_CONF=/dev/null TB --- 2011-06-16 02:10:40 - cd /src TB --- 2011-06-16 02:10:40 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 02:10:45 UTC 2011 >>> 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 [...] cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_alloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_balloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_bswap.c cc1: warnings being treated as errors In file included from /src/usr.sbin/makefs/ffs/ffs_bswap.c:51: /obj/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: 'enum vtype' declared inside parameter list /obj/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: its scope is only this definition or declaration, which is probably not what you want /obj/src/tmp/usr/include/ufs/ffs/ffs_extern.h:85: warning: 'enum vtype' declared inside parameter list *** Error code 1 Stop in /src/usr.sbin/makefs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 04:02:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 04:02:51 - ERROR: failed to build world TB --- 2011-06-16 04:02:51 - 5517.04 user 901.61 system 6771.69 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/i386
TB --- 2011-06-16 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 02:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-06-16 02:10:00 - cleaning the object tree TB --- 2011-06-16 02:10:28 - cvsupping the source tree TB --- 2011-06-16 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-06-16 02:15:52 - building world TB --- 2011-06-16 02:15:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 02:15:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 02:15:52 - TARGET=i386 TB --- 2011-06-16 02:15:52 - TARGET_ARCH=i386 TB --- 2011-06-16 02:15:52 - TZ=UTC TB --- 2011-06-16 02:15:52 - __MAKE_CONF=/dev/null TB --- 2011-06-16 02:15:52 - cd /src TB --- 2011-06-16 02:15:52 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 02:15:52 UTC 2011 >>> 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 [...] cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_alloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_balloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_bswap.c cc1: warnings being treated as errors In file included from /src/usr.sbin/makefs/ffs/ffs_bswap.c:51: /obj/i386.i386/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: 'enum vtype' declared inside parameter list /obj/i386.i386/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: its scope is only this definition or declaration, which is probably not what you want /obj/i386.i386/src/tmp/usr/include/ufs/ffs/ffs_extern.h:85: warning: 'enum vtype' declared inside parameter list *** Error code 1 Stop in /src/usr.sbin/makefs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 04:08:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 04:08:44 - ERROR: failed to build world TB --- 2011-06-16 04:08:44 - 5530.99 user 875.74 system 7124.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2011-06-16 03:35:38 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 03:35:38 - starting HEAD tinderbox run for mips/mips TB --- 2011-06-16 03:35:38 - cleaning the object tree TB --- 2011-06-16 03:35:46 - cvsupping the source tree TB --- 2011-06-16 03:35:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-06-16 03:36:14 - building world TB --- 2011-06-16 03:36:14 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 03:36:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 03:36:14 - TARGET=mips TB --- 2011-06-16 03:36:14 - TARGET_ARCH=mips TB --- 2011-06-16 03:36:14 - TZ=UTC TB --- 2011-06-16 03:36:14 - __MAKE_CONF=/dev/null TB --- 2011-06-16 03:36:14 - cd /src TB --- 2011-06-16 03:36:14 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 03:36:15 UTC 2011 >>> 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 [...] cc -O -pipe -G0 -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_alloc.c cc -O -pipe -G0 -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_balloc.c cc -O -pipe -G0 -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_bswap.c cc1: warnings being treated as errors In file included from /src/usr.sbin/makefs/ffs/ffs_bswap.c:51: /obj/mips.mipsel/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: 'enum vtype' declared inside parameter list /obj/mips.mipsel/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: its scope is only this definition or declaration, which is probably not what you want /obj/mips.mipsel/src/tmp/usr/include/ufs/ffs/ffs_extern.h:85: warning: 'enum vtype' declared inside parameter list *** Error code 1 Stop in /src/usr.sbin/makefs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 04:28:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 04:28:31 - ERROR: failed to build world TB --- 2011-06-16 04:28:31 - 2292.79 user 594.49 system 3173.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-06-16 04:08:45 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 04:08:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-06-16 04:08:45 - cleaning the object tree TB --- 2011-06-16 04:08:48 - cvsupping the source tree TB --- 2011-06-16 04:08:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-06-16 04:09:15 - building world TB --- 2011-06-16 04:09:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 04:09:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 04:09:15 - TARGET=sparc64 TB --- 2011-06-16 04:09:15 - TARGET_ARCH=sparc64 TB --- 2011-06-16 04:09:15 - TZ=UTC TB --- 2011-06-16 04:09:15 - __MAKE_CONF=/dev/null TB --- 2011-06-16 04:09:15 - cd /src TB --- 2011-06-16 04:09:15 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 04:09:15 UTC 2011 >>> 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 [...] cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/sbrk.c cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/twiddle.c cc -O2 -pipe -ffreestanding -Wformat -I/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/src/lib/libstand/../libz -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libstand/zalloc.c cc1: warnings being treated as errors /src/lib/libstand/zalloc.c: In function 'zfree': /src/lib/libstand/zalloc.c:157: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' /src/lib/libstand/zalloc.c:181: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' /src/lib/libstand/zalloc.c:212: warning: format '%d' expects type 'int', but argument 3 has type 'iaddr_t' *** Error code 1 Stop in /src/lib/libstand. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 04:36:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 04:36:43 - ERROR: failed to build world TB --- 2011-06-16 04:36:43 - 1243.49 user 308.49 system 1677.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-06-16 04:02:52 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 04:02:52 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-06-16 04:02:52 - cleaning the object tree TB --- 2011-06-16 04:03:04 - cvsupping the source tree TB --- 2011-06-16 04:03:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-06-16 04:03:18 - building world TB --- 2011-06-16 04:03:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 04:03:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 04:03:18 - TARGET=powerpc TB --- 2011-06-16 04:03:18 - TARGET_ARCH=powerpc64 TB --- 2011-06-16 04:03:18 - TZ=UTC TB --- 2011-06-16 04:03:18 - __MAKE_CONF=/dev/null TB --- 2011-06-16 04:03:18 - cd /src TB --- 2011-06-16 04:03:18 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 04:03:19 UTC 2011 >>> 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 [...] cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_alloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_balloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_bswap.c cc1: warnings being treated as errors In file included from /src/usr.sbin/makefs/ffs/ffs_bswap.c:51: /obj/powerpc.powerpc64/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: 'enum vtype' declared inside parameter list /obj/powerpc.powerpc64/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: its scope is only this definition or declaration, which is probably not what you want /obj/powerpc.powerpc64/src/tmp/usr/include/ufs/ffs/ffs_extern.h:85: warning: 'enum vtype' declared inside parameter list *** Error code 1 Stop in /src/usr.sbin/makefs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 05:01:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 05:01:24 - ERROR: failed to build world TB --- 2011-06-16 05:01:24 - 2830.02 user 597.70 system 3512.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-06-16 04:02:21 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 04:02:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-06-16 04:02:21 - cleaning the object tree TB --- 2011-06-16 04:02:32 - cvsupping the source tree TB --- 2011-06-16 04:02:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-06-16 04:03:09 - building world TB --- 2011-06-16 04:03:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 04:03:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 04:03:09 - TARGET=powerpc TB --- 2011-06-16 04:03:09 - TARGET_ARCH=powerpc TB --- 2011-06-16 04:03:09 - TZ=UTC TB --- 2011-06-16 04:03:09 - __MAKE_CONF=/dev/null TB --- 2011-06-16 04:03:09 - cd /src TB --- 2011-06-16 04:03:09 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 04:03:09 UTC 2011 >>> 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 [...] cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_alloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_balloc.c cc -O2 -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_bswap.c cc1: warnings being treated as errors In file included from /src/usr.sbin/makefs/ffs/ffs_bswap.c:51: /obj/powerpc.powerpc/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: 'enum vtype' declared inside parameter list /obj/powerpc.powerpc/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: its scope is only this definition or declaration, which is probably not what you want /obj/powerpc.powerpc/src/tmp/usr/include/ufs/ffs/ffs_extern.h:85: warning: 'enum vtype' declared inside parameter list *** Error code 1 Stop in /src/usr.sbin/makefs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 05:39:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 05:39:34 - ERROR: failed to build world TB --- 2011-06-16 05:39:34 - 4983.85 user 777.91 system 5832.74 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on arm/arm
TB --- 2011-06-16 05:40:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-16 05:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-06-16 05:40:01 - cleaning the object tree TB --- 2011-06-16 05:40:08 - cvsupping the source tree TB --- 2011-06-16 05:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-06-16 05:40:30 - building world TB --- 2011-06-16 05:40:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-16 05:40:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-16 05:40:30 - TARGET=arm TB --- 2011-06-16 05:40:30 - TARGET_ARCH=arm TB --- 2011-06-16 05:40:30 - TZ=UTC TB --- 2011-06-16 05:40:30 - __MAKE_CONF=/dev/null TB --- 2011-06-16 05:40:30 - cd /src TB --- 2011-06-16 05:40:30 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 16 05:40:30 UTC 2011 >>> 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 [...] cc -O -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_alloc.c cc -O -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_balloc.c cc -O -pipe -I/src/usr.sbin/makefs -I/src/usr.sbin/makefs/../../sys/fs/cd9660/ -I/src/usr.sbin/makefs/../../sys/ufs/ffs -I/src/usr.sbin/makefs/compat -DHAVE_STRUCT_STAT_ST_FLAGS=1 -DHAVE_STRUCT_STAT_ST_GEN=1 -I/src/usr.sbin/makefs/../mtree -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/makefs/ffs/ffs_bswap.c cc1: warnings being treated as errors In file included from /src/usr.sbin/makefs/ffs/ffs_bswap.c:51: /obj/arm.arm/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: 'enum vtype' declared inside parameter list /obj/arm.arm/src/tmp/usr/include/ufs/ffs/ffs_extern.h:60: warning: its scope is only this definition or declaration, which is probably not what you want /obj/arm.arm/src/tmp/usr/include/ufs/ffs/ffs_extern.h:85: warning: 'enum vtype' declared inside parameter list *** Error code 1 Stop in /src/usr.sbin/makefs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-16 06:30:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-16 06:30:50 - ERROR: failed to build world TB --- 2011-06-16 06:30:50 - 2208.09 user 623.55 system 3049.37 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: > On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote: > > > Can you please show me verbose boot messages *without* your > > > patch? Does "sysctl kern.timecounter.hardware=HPET" help > > > *without* touching eventtimers? > > > > I have the same issue with my system (Atom N270). The effect that > > I see is about 29 wall clock seconds are recorded as 1 system > > second. > > Can please you send me output from the following? > > sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1));\ > sysctl kern.timecounter; sleep 1; done' Interesting it doesn't seem to be constant. While there was lots going on (launching exmh and scanning my mail folders opening and reading 20k files) keyboard repeats work as normal and xclock ticks one a second. When the activity stops, xclock ticks every 6 seconds. While the system clock recorded 10 seconds of wall clock, stopwatch ran for 42 seconds. Script started on Thu Jun 16 08:23:51 2011 [mini] /usr/home/ianf $ time sh -c 'count=10; while [ $count -gt 0 ]; do count=$((cou nt - 1)); sysctl kern.timecounter; sleep 1; done' kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 12748229 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3380795670 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 9828 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1915282150 kern.timecounter.tc.TSC-low.frequency: 12469046 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 4005701 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3480043331 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 22926 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1927865521 kern.timecounter.tc.TSC-low.frequency: 12469046 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 5223570 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3552023679 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 57522 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1940447630 kern.timecounter.tc.TSC-low.frequency: 12469046 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 5712953 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3621090061 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 45866 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1953031506 kern.timecounter.tc.TSC-low.frequency: 12469046 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) ker
