Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
2010/4/21 Andrey V. Elsukov bu7c...@yandex.ru: On 21.04.2010 2:44, Maxim Sobolev wrote: Maxim Sobolev wrote: Maybe try adding hint.atkbdc.0.disabled=1 hint.atkbd.0.disabled=1 Actually it helped, thank you very much! The problem was that I have had my hints compiled into the kernel itself. Hi, Maxim. I tried to boot 9.0-CURRENT amd64 snapshot on IBM x3650 M2 and seems have the same problem, i set hints from loader prompt, but this didn't help. Can you explain what you did to boot FreeBSD faster? Hmm.. That's strange to hear. We have in production a number of x3650m2: 7.2-R, 7.3-R (all amd64). All runs flawlessly. I'll try to boot it from head today if that matters. -- wbr, pluknet ___ 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 kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
On 21.04.2010 10:01, pluknet wrote: Hmm.. That's strange to hear. We have in production a number of x3650m2: 7.2-R, 7.3-R (all amd64). All runs flawlessly. I'll try to boot it from head today if that matters. It was about 1.5 hour ago when i entered autoboot in loader prompt. It still show slowly rotated dash line at end of /boot/kernel/kernel text=x | -- WBR, Andrey V. Elsukov ___ 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 kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
On 21.04.2010 10:01, pluknet wrote: Hmm.. That's strange to hear. We have in production a number of x3650m2: 7.2-R, 7.3-R (all amd64). All runs flawlessly. I'll try to boot it from head today if that matters. It was about 1.5 hour ago when i entered autoboot in loader prompt. It still show slowly rotated dash line at end of /boot/kernel/kernel text=x | I've seen this happen when there were problems with the serial port, either missing or miss-configured. HTH, danny ___ 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: HEADS UP: SUJ Going in to head today
On Tue, 20 Apr 2010, Patrick Tracanelli wrote: Jeff Roberson escreveu: Hi Folks, You may have seen my other Soft-updates journaling (SUJ) announcements. If not, it is a journaling system that works cooperatively with soft-updates to eliminate the full background filesystem check after an unclean shutdown. SUJ may be enabled with tunefs -j enable and disabled with tunefs -j disable on an unmounted filesystem. It is backwards compatible with soft-updates with no journal. I'm going to do another round of tests and buildworld this afternoon to verify the diff and then I'm committing to head. This is a very large feature and fundamentally changes softupdates. Although it has been extensively tested by many there may be unforseen problems. If you run into an issue that you think may be suj please email me directly as well as posting on current as I sometimes miss list email and this will ensure the quickest response. Hello Jeff, McKusick and others envolved. Is an MFC technically possible? If so, are there plans to do so? I do have an 8 backport branch available although it is a little stale. I intend to keep it somewhat up to date. I think it will take some time before we have sufficient experience with SUJ in head before we want to put it back in 8. It is quite a complex and disruptive feature. Thanks, Jeff Thank you. -- Patrick Tracanelli ___ 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: HEADS UP: SUJ Going in to head today
On Tue, 20 Apr 2010 12:15:48 -1000 (HST) Jeff Roberson jrober...@jroberson.net wrote: Hi Folks, You may have seen my other Soft-updates journaling (SUJ) announcements. If not, it is a journaling system that works cooperatively with soft-updates to eliminate the full background filesystem check after an unclean shutdown. SUJ may be enabled with tunefs -j enable and disabled with tunefs -j disable on an unmounted filesystem. It is backwards compatible with soft-updates with no journal. I'm going to do another round of tests and buildworld this afternoon to verify the diff and then I'm committing to head. This is a very large feature and fundamentally changes softupdates. Although it has been extensively tested by many there may be unforseen problems. If you run into an issue that you think may be suj please email me directly as well as posting on current as I sometimes miss list email and this will ensure the quickest response. And the crowd goes wild. SUJ is _great_ and I'm glad to see it finally making it into the tree. -- Gary Jennejohn ___ 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
ANY-ONE-ELSE? ntpd+oncore+i386 doesn't work
Hi
The oncore ntp driver worked fine in my Athlon64 machine running
FreeBSD-amd64. I've tried it on a VIA-C7 and a Pentium-M based
board with an onboard serial port.
The following patch from Russell J. Yount fixes (bandaids) the issue:
Index: /usr/src/contrib/ntp/ntpd/refclock_oncore.c
===
RCS file: /home/ncvs/src/contrib/ntp/ntpd/refclock_oncore.c,v
retrieving revision 1.2
diff -u -d -r1.2 refclock_oncore.c
--- /usr/src/contrib/ntp/ntpd/refclock_oncore.c 22 Aug 2008 15:58:00 -
1.2
+++ /usr/src/contrib/ntp/ntpd/refclock_oncore.c 21 Apr 2010 08:33:55 -
@@ -1127,7 +1127,7 @@
*/
FILE*fd;
- char*cp, *cc, *ca, line[100], units[2], device[20], Msg[160], **cpp;
+ char*cp, *cc, *ca, line[100], units[2], device[32], Msg[160], **cpp;
char*dirs[] = { /etc/ntp, /etc, 0 };
int i, sign, lat_flg, long_flg, ht_flg, mode, mask;
double f1, f2, f3;
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: ANY-ONE-ELSE? ntpd+oncore+i386 doesn't work
According to Ian FREISLICH: The oncore ntp driver worked fine in my Athlon64 machine running FreeBSD-amd64. I've tried it on a VIA-C7 and a Pentium-M based board with an onboard serial port. Can you open a bug on bugs.ntp.org with the patch please? I'd rather have upstream fix it properly. Thanks. The following patch from Russell J. Yount fixes (bandaids) the issue: Just a bigger buffer then? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ 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: ANY-ONE-ELSE? ntpd+oncore+i386 doesn't work
Ollivier Robert wrote: According to Ian FREISLICH: The oncore ntp driver worked fine in my Athlon64 machine running FreeBSD-amd64. I've tried it on a VIA-C7 and a Pentium-M based board with an onboard serial port. Can you open a bug on bugs.ntp.org with the patch please? I'd rather have upstream fix it properly. Thanks. The following patch from Russell J. Yount fixes (bandaids) the issue: Just a bigger buffer then? Well, yeah: /dev/oncore.serial.0\0 is 21 chars https://bugs.ntp.org/show_bug.cgi?id=1389 Fixed in 4.2.5p248 and later. Seems FreeBSD has lagged somewhat: version=ntpd 4.2.4p5-a (1) 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
[head tinderbox] failure on i386/pc98
TB --- 2010-04-21 07:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-21 07:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-04-21 07:40:00 - cleaning the object tree TB --- 2010-04-21 07:40:21 - cvsupping the source tree TB --- 2010-04-21 07:40:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-04-21 08:59:08 - building world TB --- 2010-04-21 08:59:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-21 08:59:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-21 08:59:08 - TARGET=pc98 TB --- 2010-04-21 08:59:08 - TARGET_ARCH=i386 TB --- 2010-04-21 08:59:08 - TZ=UTC TB --- 2010-04-21 08:59:08 - __MAKE_CONF=/dev/null TB --- 2010-04-21 08:59:08 - cd /src TB --- 2010-04-21 08:59:08 - /usr/bin/make -B buildworld World build started on Wed Apr 21 08:59:09 UTC 2010 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 World build completed on Wed Apr 21 09:58:24 UTC 2010 TB --- 2010-04-21 09:58:24 - generating LINT kernel config TB --- 2010-04-21 09:58:24 - cd /src/sys/pc98/conf TB --- 2010-04-21 09:58:24 - /usr/bin/make -B LINT TB --- 2010-04-21 09:58:24 - building LINT kernel TB --- 2010-04-21 09:58:24 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-21 09:58:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-21 09:58:24 - TARGET=pc98 TB --- 2010-04-21 09:58:24 - TARGET_ARCH=i386 TB --- 2010-04-21 09:58:24 - TZ=UTC TB --- 2010-04-21 09:58:24 - __MAKE_CONF=/dev/null TB --- 2010-04-21 09:58:24 - cd /src TB --- 2010-04-21 09:58:24 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 21 09:58:24 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/libkern/umoddi3.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/pc98/apm/apm_bioscall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/pc98/cbus/cbus_dma.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/pc98/cbus/clock.c /src/sys/pc98/cbus/clock.c: In function 'clkintr': /src/sys/pc98/cbus/clock.c:178:
Re: ZFS DEADLKRES - AHCI blocks on ICH7M
Dnia 08.04.2010 Attilio Rao atti...@freebsd.org napisał/a: This may be a false positive. May you please try the following patch and report if you can fix it does fix it or not?: http://www.freebsd.org/~attilio/Sandvine/deadlkres/deadlkres-blessed.diff Thanks for your help. I have applied this patch and I am still getting the deadlock (today it was after 1802544 ticks). But there is more: I am running r203753 on one of those AHCI disabled by default laptops (Sony VGN-SZ5MN/B). I have reset the BIOS completely (by removing the CMOS battery for a moment) and it seemingly fixed the problem. I have tested this and I found out: - in ATA emulation mode things are fine. /etc/periodic/daily completes normally. - in AHCI mode /etc/periodic/daily hangs on any disk operation even dumping core is impossible from the ddb(4). I have re-enabled AHCI again and tested with your patch: /etc/periodic/daily and svnsync running in parallel hanged after some longer time and deadlkres kicked in. I presume deadlkres is properly detecting threads that hanged waiting for the disk response. This laptop has the ICH7M controller (in ATA emulation mode): atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] atapci1: Intel ICH7M SATA150 controller port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xf8644400-0xf86447ff irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: ATA channel 0 on atapci1 ata2: [ITHREAD] ata3: ATA channel 1 on atapci1 ata3: [ITHREAD] in AHCI mode it says: atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ahci0: Intel ICH7M AHCI SATA controller port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xf8644400-0xf86447ff irq 22 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: AHCI channel at channel 2 on ahci0 ahcich1: [ITHREAD] I am using this in the kernel config: device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering device ahci -- Marcin Cieslak // sa...@saper.info ___ 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: HEADS UP: SUJ Going in to head today
On Wed, Apr 21, 2010 at 12:39 AM, Gary Jennejohn gary.jennej...@freenet.de wrote: On Tue, 20 Apr 2010 12:15:48 -1000 (HST) Jeff Roberson jrober...@jroberson.net wrote: Hi Folks, You may have seen my other Soft-updates journaling (SUJ) announcements. If not, it is a journaling system that works cooperatively with soft-updates to eliminate the full background filesystem check after an unclean shutdown. SUJ may be enabled with tunefs -j enable and disabled with tunefs -j disable on an unmounted filesystem. It is backwards compatible with soft-updates with no journal. I'm going to do another round of tests and buildworld this afternoon to verify the diff and then I'm committing to head. This is a very large feature and fundamentally changes softupdates. Although it has been extensively tested by many there may be unforseen problems. If you run into an issue that you think may be suj please email me directly as well as posting on current as I sometimes miss list email and this will ensure the quickest response. And the crowd goes wild. SUJ is _great_ and I'm glad to see it finally making it into the tree. Indeed. I'm looking forward to testing the junk out of this -- this is definitely a good move forward with UFS2 :]... Cheers, -Garrett PS How does this interact with geom with journaling BTW? Has this been tested performance wise (I know it doesn't make logistical sense, but it does kind of seem to null and void the importance of geom with journaling, maybe...)? ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
i might have stumbled upon a problem with clang. i've compiled a kernel from the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. i'm now experiencing audio problems with mp3s and certain video files. playback is awfully slow and the audio output gets distorted massively. `top` however reports no high cpu load and `vmstat -i` doesn't report anything unusual either. this problem doesn't occur with a regular gcc-kernel. both kernels are running under a regular (gcc) world. i thought it might be a problem with acpi, but disabling acpi (hint.acpi.0.disabled=1) gives me a system freeze. -- Alexander Best ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On 2010-04-20 16:04, Roman Divacky wrote: Tried again with llvm r101891, still the same error... the problem is that gcc miscompiles llvm at -O3, I havent managed to contact brooks@ to change the port to default to -O2 you can do that locally I guess Tried llvm-devel-2.7.r101995 built with -O2, but no difference in the result. I guess it's a real bug in llvm. :) ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: i might have stumbled upon a problem with clang. i've compiled a kernel from the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. i'm now experiencing audio problems with mp3s and certain video files. playback is awfully slow and the audio output gets distorted massively. `top` however reports no high cpu load and `vmstat -i` doesn't report anything unusual either. this problem doesn't occur with a regular gcc-kernel. both kernels are running under a regular (gcc) world. i thought it might be a problem with acpi, but disabling acpi (hint.acpi.0.disabled=1) gives me a system freeze. I've heard about this problem but did not manage to reproduce that. can you try to bisect what file is being miscompiled? ie. compile half of the kernel with gcc and half with clang and bisect this way to a single file. we can work from there... ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Wed, Apr 21, 2010 at 05:26:03PM +0200, Dimitry Andric wrote: On 2010-04-20 16:04, Roman Divacky wrote: Tried again with llvm r101891, still the same error... the problem is that gcc miscompiles llvm at -O3, I havent managed to contact brooks@ to change the port to default to -O2 you can do that locally I guess Tried llvm-devel-2.7.r101995 built with -O2, but no difference in the result. I guess it's a real bug in llvm. :) can you try with LLVM svn trunk? it works for me ok (with -O2 compilation) ___ 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 kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
On Tuesday 20 April 2010 7:35:46 pm Matthew Jacob wrote: On 04/20/2010 03:44 PM, Maxim Sobolev wrote: Maxim Sobolev wrote: Maybe try adding hint.atkbdc.0.disabled=1 hint.atkbd.0.disabled=1 to /boot/device.hints? That has reportedly removed minute-long boot delays on some Nehalem machines. No, that have not helped at all. I measured the delay - it's about 6 minutes from boot command to the first smap message. Do you or anybody else have other ideas? Actually it helped, thank you very much! The problem was that I have had my hints compiled into the kernel itself. Me too! I can't reproduce this currently, but it would be good to debug this further. My suggestions on how to do this would be to create an array of uint64_t and save TSC values (rdtsc()) into it at specific points in the atkbd/syscons console init. You can then print out the deltas between array entries once the console is fully initialized. Moving the rdtsc() calls around should allow one to determine where in the atkbd/syscons init the long pause is happening. -- John Baldwin ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On 2010-04-21 17:24, Roman Divacky wrote:
Tried llvm-devel-2.7.r101995 built with -O2, but no difference in the
result. I guess it's a real bug in llvm. :)
can you try with LLVM svn trunk? it works for me ok (with -O2 compilation)
AFAICS the only change between r101995 and r102001 is in some
ReleaseNotes.html file, so I guess I am using the very latest, bleeding
edge revision already. :)
I'm using the following diff to the devel/llvm-devel port:
Index: devel/llvm-devel/Makefile
===
RCS file: /home/mirror/ncvs/ports/devel/llvm-devel/Makefile,v
retrieving revision 1.42
diff -u -d -r1.42 Makefile
--- devel/llvm-devel/Makefile 18 Mar 2010 19:33:23 - 1.42
+++ devel/llvm-devel/Makefile 21 Apr 2010 15:32:37 -
@@ -42,7 +42,8 @@
CONFIGURE_ARGS+= --with-f2c=${LOCALBASE}
.else
CONFIGURE_ARGS+= --disable-assertions \
- --enable-optimized
+ --enable-optimized \
+ --with-optimize-option=-O2
.endif
CONFIGURE_ARGS+= --enable-bindings=none
Index: devel/llvm-devel/Makefile.svn_rev
===
RCS file: /home/mirror/ncvs/ports/devel/llvm-devel/Makefile.svn_rev,v
retrieving revision 1.13
diff -u -d -r1.13 Makefile.svn_rev
--- devel/llvm-devel/Makefile.svn_rev 5 Apr 2010 17:33:55 - 1.13
+++ devel/llvm-devel/Makefile.svn_rev 21 Apr 2010 15:32:37 -
@@ -1 +1 @@
-SVN_REV= 100430
+SVN_REV= 101995
Index: devel/llvm-devel/distinfo
===
RCS file: /home/mirror/ncvs/ports/devel/llvm-devel/distinfo,v
retrieving revision 1.27
diff -u -d -r1.27 distinfo
--- devel/llvm-devel/distinfo 5 Apr 2010 17:33:55 - 1.27
+++ devel/llvm-devel/distinfo 21 Apr 2010 15:32:37 -
@@ -1,3 +1,3 @@
-MD5 (llvm-2.7.r100430.tar.bz2) = ab73db3fc7fbbdffda032131e31b91bf
-SHA256 (llvm-2.7.r100430.tar.bz2) =
f5933ed2e873fd65eae7ffd8a5f9077f1e42d33db573f2395f2bf56427f00e91
-SIZE (llvm-2.7.r100430.tar.bz2) = 10785591
+MD5 (llvm-2.7.r101995.tar.bz2) = 57cced37c718427b0100659fc5c09728
+SHA256 (llvm-2.7.r101995.tar.bz2) =
092b6eb50ad3e3f3789f112fe8dc4205c0259f4e29691a8cfa0d3d2329f6c3b9
+SIZE (llvm-2.7.r101995.tar.bz2) = 10897340
___
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: ANY-ONE-ELSE? ntpd+oncore+i386 doesn't work
According to Ian FREISLICH: Fixed in 4.2.5p248 and later. Seems FreeBSD has lagged somewhat: version=ntpd 4.2.4p5-a (1) ok, got the message :) TODO.add(upgrade ntpd) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky schrieb am 2010-04-21: On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: i might have stumbled upon a problem with clang. i've compiled a kernel from the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. i'm now experiencing audio problems with mp3s and certain video files. playback is awfully slow and the audio output gets distorted massively. `top` however reports no high cpu load and `vmstat -i` doesn't report anything unusual either. this problem doesn't occur with a regular gcc-kernel. both kernels are running under a regular (gcc) world. i thought it might be a problem with acpi, but disabling acpi (hint.acpi.0.disabled=1) gives me a system freeze. I've heard about this problem but did not manage to reproduce that. can you try to bisect what file is being miscompiled? ie. compile half of the kernel with gcc and half with clang and bisect this way to a single file. we can work from there... i've identified the problem to be somewhere in sys/dev/sound. i've removed device sound and device hda_snd from my kernel config and rebuild/reinstalled both kernels (gcc and clang). i then booted the clang kernel and loaded various sound.ko and snd_hda.ko combination. here're the results: sound.ko (clang) snd_hda.ko (clang) = BROKEN sound.ko (clang) snd_hda.ko (gcc) = BROKEN sound.ko (gcc) snd_hda.ko (gcc) = OK sound.ko (gcc) snd_hda.ko (clang) = OK i've attached a log documenting all clang warnings that get issued when building sys/modules/sound. in addition to those warnings i get a lot of these, but i guess they aren't harmful: clang: warning: argument unused during compilation: '-funroll-loops' clang: warning: argument unused during compilation: '-finline-limit=8000' clang: warning: argument unused during compilation: '--param inline-unit-growth=100' clang: warning: argument unused during compilation: '--param large-function-growth=1000' clang: warning: argument unused during compilation: '-mfpmath=387' clang: warning: argument unused during compilation: '-fformat-extensions' clang: warning: argument unused during compilation: '-funroll-loops' clang: warning: argument unused during compilation: '-finline-limit=8000' clang: warning: argument unused during compilation: '--param inline-unit-growth=100' clang: warning: argument unused during compilation: '--param large-function-growth=1000' clang: warning: argument unused during compilation: '-mfpmath=387' -- Alexander Best /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/feeder_rate.c:163:1: warning: initializing 'char const (*)[36]' discards qualifiers, expected 'void *' [-pedantic] SYSCTL_STRING(_hw_snd, OID_AUTO, feeder_rate_presets, CTLFLAG_RD, ^ In file included from /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/feeder_rate.c:55: In file included from @/dev/sound/pcm/sound.h:67: @/sys/sysctl.h:243:2: note: instantiated from: SYSCTL_OID(parent, nbr, name, CTLTYPE_STRING|(access), \ ^ /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/feeder_rate.c:163:1: note: instantiated from: SYSCTL_STRING(_hw_snd, OID_AUTO, feeder_rate_presets, CTLFLAG_RD, ^ /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/feeder_rate.c:164:5: note: instantiated from: feeder_rate_presets, 0, compile-time rate presets); ^~~~ 1 diagnostic generated. /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/feeder_eq.c:97:1: warning: initializing 'char const (*)[74]' discards qualifiers, expected 'void *' [-pedantic] SYSCTL_STRING(_hw_snd, OID_AUTO, feeder_eq_presets, CTLFLAG_RD, ^~~ In file included from /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/feeder_eq.c:40: In file included from @/dev/sound/pcm/sound.h:67: @/sys/sysctl.h:243:2: note: instantiated from: SYSCTL_OID(parent, nbr, name, CTLTYPE_STRING|(access), \ ^ /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/feeder_eq.c:97:1: note: instantiated from: SYSCTL_STRING(_hw_snd, OID_AUTO, feeder_eq_presets, CTLFLAG_RD, ^ /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/feeder_eq.c:98:5: note: instantiated from: feeder_eq_presets, 0, compile-time eq presets); ^~ 1 diagnostic generated. /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/sound.c:73:1: warning: initializing 'char const (*)[17]' discards qualifiers, expected 'void *' [-pedantic] SYSCTL_STRING(_hw_snd, OID_AUTO, version, CTLFLAG_RD, snd_driver_version, ^~ In file included from /usr/local/src/clangbsd/sys/modules/sound/sound/../../../dev/sound/pcm/sound.c:34: In file included from
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On 21 Apr 2010, at 18:22, Alexander Best wrote: Roman Divacky schrieb am 2010-04-21: On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: i might have stumbled upon a problem with clang. i've compiled a kernel from the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. i'm now experiencing audio problems with mp3s and certain video files. playback is awfully slow and the audio output gets distorted massively. `top` however reports no high cpu load and `vmstat -i` doesn't report anything unusual either. this problem doesn't occur with a regular gcc-kernel. both kernels are running under a regular (gcc) world. i thought it might be a problem with acpi, but disabling acpi (hint.acpi.0.disabled=1) gives me a system freeze. I've heard about this problem but did not manage to reproduce that. can you try to bisect what file is being miscompiled? ie. compile half of the kernel with gcc and half with clang and bisect this way to a single file. we can work from there... i've identified the problem to be somewhere in sys/dev/sound. i've removed device sound and device hda_snd from my kernel config and rebuild/reinstalled both kernels (gcc and clang). i then booted the clang kernel and loaded various sound.ko and snd_hda.ko combination. here're the results: sound.ko (clang) snd_hda.ko (clang) = BROKEN sound.ko (clang) snd_hda.ko (gcc) = BROKEN sound.ko (gcc) snd_hda.ko (gcc) = OK sound.ko (gcc) snd_hda.ko (clang) = OK i've attached a log documenting all clang warnings that get issued when building sys/modules/sound. in addition to those warnings i get a lot of these, but i guess they aren't harmful: clang: warning: argument unused during compilation: '-funroll-loops' clang: warning: argument unused during compilation: '-finline-limit=8000' clang: warning: argument unused during compilation: '--param inline-unit-growth=100' clang: warning: argument unused during compilation: '--param large-function-growth=1000' clang: warning: argument unused during compilation: '-mfpmath=387' clang: warning: argument unused during compilation: '-fformat-extensions' clang: warning: argument unused during compilation: '-funroll-loops' clang: warning: argument unused during compilation: '-finline-limit=8000' clang: warning: argument unused during compilation: '--param inline-unit-growth=100' clang: warning: argument unused during compilation: '--param large-function-growth=1000' clang: warning: argument unused during compilation: '-mfpmath=387' There's some assembly in feeder_rate.c. Can you check if it's being used? Regards, -- Rui Paulo ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Wed, Apr 21, 2010 at 07:22:00PM +0200, Alexander Best wrote: Roman Divacky schrieb am 2010-04-21: On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: i might have stumbled upon a problem with clang. i've compiled a kernel from the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. i'm now experiencing audio problems with mp3s and certain video files. playback is awfully slow and the audio output gets distorted massively. `top` however reports no high cpu load and `vmstat -i` doesn't report anything unusual either. this problem doesn't occur with a regular gcc-kernel. both kernels are running under a regular (gcc) world. i thought it might be a problem with acpi, but disabling acpi (hint.acpi.0.disabled=1) gives me a system freeze. I've heard about this problem but did not manage to reproduce that. can you try to bisect what file is being miscompiled? ie. compile half of the kernel with gcc and half with clang and bisect this way to a single file. we can work from there... i've identified the problem to be somewhere in sys/dev/sound. i've removed device sound and device hda_snd from my kernel config and rebuild/reinstalled both kernels (gcc and clang). i then booted the clang kernel and loaded various sound.ko and snd_hda.ko combination. here're the results: sound.ko (clang) snd_hda.ko (clang) = BROKEN sound.ko (clang) snd_hda.ko (gcc) = BROKEN sound.ko (gcc) snd_hda.ko (gcc) = OK sound.ko (gcc) snd_hda.ko (clang) = OK great work! it looks like sound.ko is the culprit.. this is amd64 because my i386 kernel plays sound just fine. could you try to bisect the sound.ko ? you can do it this way: 1) cd modules/sound/sound make CC=gcc 2) make -V SRCS | tr \n | grep -v \.h | sort | grep ^[a-m].* | xargs touch ^ this is your bisect pattern 3) make CC=clang make install 4) reload the module test the sound 5) if the sound works you swap your bisect pattern (ie. [a-m] - [n-z] etc.) if not you know that you that the miscompiled file is in you pattern and you can narrow it (ie. [a-m] - [a-g] etc.) 6) goto 1 until you compile a single file I am pretty sure you can understand this and reduce this to a single file. once we get single file that is being miscompiled we can do some slightly \more educated guess on whats going on and structure our testing a little smarter... thnx! roman ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Sat, Apr 17, 2010 at 07:03:14PM +0200, Dimitry Andric wrote: On 2010-04-16 18:08, Roman Divacky wrote: cd clangbsd make buildworld Buildworld all goes well, until this stage: -- stage 4.2: building libraries -- cd /home/dim/src/clangbsd; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/home/dim/src/clangbsd/tmp VERSION=FreeBSD 9.0-CURRENT i386 900010 INSTALL=sh /home/dim/src/clangbsd/tools/install.sh PATH=/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/sbin:/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/bin:/usr/obj/home/dim/src/clangbsd/tmp/legacy/usr/games:/usr/obj/home/dim/src/clangbsd/tmp/usr/sbin:/usr/obj/home/dim/src/clangbsd/tmp/usr/bin:/usr/obj/home/dim/src/clangbsd/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin CC=clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/o bj/home/dim/src/clangbsd/tmp/usr/lib/ CXX=clang++ -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include -isystem /usr/obj/home/dim/src/clangbsd/tmp/include/c++/4.2 -isystem /usr/obj/home/dim/src/clangbsd/tmp/include/c++/4.2/backward -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/home/dim/src/clangbsd/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_PROFILE libraries cd /home/dim/src/clangbsd; make -f Makefile.inc1 _prereq_libs; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; === gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend CC='clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/' mkdep -f .depend -a -DHAVE_CONFIG_H -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/.. -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC /home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c clang -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/home/dim/src/clangbsd/tmp/usr/include -B/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -L/usr/obj/home/dim/src/clangbsd/tmp/usr/lib/ -O2 -pipe -DHAVE_CONFIG_H -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/.. -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /home/dim/src/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c '486' is not a recognized processor for this target (ignoring processor) building static ssp_nonshared library ranlib libssp_nonshared.a sh /home/dim/src/clangbsd/tools/install.sh -C -o root -g wheel -m 444 libssp_nonshared.a /usr/obj/home/dim/src/clangbsd/tmp/usr/lib === gnu/lib/libgcc (obj,depend,all,install) make -f /home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc tm.h TARGET_CPU_DEFAULT= HEADERS=options.h i386/i386.h i386/unix.h i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h i386/freebsd.h defaults.h DEFINES= /bin/sh /home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h echo '#define EXTRA_MODES_FILE i386/i386-modes.def' tm.h make -f /home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc tconfig.h TARGET_CPU_DEFAULT= HEADERS=auto-host.h ansidecl.h DEFINES=USED_FOR_TARGET /bin/sh /home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tconfig.h make -f /home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/home/dim/src/clangbsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Wed, Apr 21, 2010 at 08:37:10PM +0200, Dimitry Andric wrote: On 2010-04-21 20:20, Roman Divacky wrote: [1m/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:140:1: [0m[0;1;35mwarning: [0m[1mcontrol may reach end of non-void function [-Wreturn-type] [0m} [0;1;32m^ [0m[1m/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:216:1: [0m[0;1;35mwarning: [0m[1mcontrol may reach end of non-void function [-Wreturn-type] [0m} [0;1;32m^ [0m[1m/home/dim/src/clangbsd/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:266:1: [0m[0;1;35mwarning: [0m[1mcontrol may reach end of non-void function [-Wreturn-type] [0m} [0;1;32m^ [0m'486' is not a recognized processor for this target (ignoring processor) what happens when you dont set CPUTYPE? I didn't set it. :) Contents of /etc/make.conf is: heh... thats a typo. anyway, I guess I'll need to check this on real i386 to see whats going on.. thnx for the report, I'll get back ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky schrieb am 2010-04-21: On Wed, Apr 21, 2010 at 07:22:00PM +0200, Alexander Best wrote: Roman Divacky schrieb am 2010-04-21: On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: i might have stumbled upon a problem with clang. i've compiled a kernel from the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. i'm now experiencing audio problems with mp3s and certain video files. playback is awfully slow and the audio output gets distorted massively. `top` however reports no high cpu load and `vmstat -i` doesn't report anything unusual either. this problem doesn't occur with a regular gcc-kernel. both kernels are running under a regular (gcc) world. i thought it might be a problem with acpi, but disabling acpi (hint.acpi.0.disabled=1) gives me a system freeze. I've heard about this problem but did not manage to reproduce that. can you try to bisect what file is being miscompiled? ie. compile half of the kernel with gcc and half with clang and bisect this way to a single file. we can work from there... i've identified the problem to be somewhere in sys/dev/sound. i've removed device sound and device hda_snd from my kernel config and rebuild/reinstalled both kernels (gcc and clang). i then booted the clang kernel and loaded various sound.ko and snd_hda.ko combination. here're the results: sound.ko (clang) snd_hda.ko (clang) = BROKEN sound.ko (clang) snd_hda.ko (gcc) = BROKEN sound.ko (gcc) snd_hda.ko (gcc) = OK sound.ko (gcc) snd_hda.ko (clang) = OK great work! it looks like sound.ko is the culprit.. this is amd64 because my i386 kernel plays sound just fine. could you try to bisect the sound.ko ? you can do it this way: 1) cd modules/sound/sound make CC=gcc 2) make -V SRCS | tr \n | grep -v \.h | sort | grep ^[a-m].* | xargs touch ^ this is your bisect pattern 3) make CC=clang make install 4) reload the module test the sound 5) if the sound works you swap your bisect pattern (ie. [a-m] - [n-z] etc.) if not you know that you that the miscompiled file is in you pattern and you can narrow it (ie. [a-m] - [a-g] etc.) 6) goto 1 until you compile a single file I am pretty sure you can understand this and reduce this to a single file. once we get single file that is being miscompiled we can do some slightly \more educated guess on whats going on and structure our testing a little smarter... hmmm...this gives me link_elf_obj: symbol feeder_matrix_default_format undefined linker_load_file: Unsupported file type when trying to load sound.ko :( something's not working. this is not related to clang. if i do `make CC=gcc make install` in step 3) i'm getting the same error. thnx! roman -- Alexander Best ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky schrieb am 2010-04-21: [snip] 1) cd modules/sound/sound make CC=gcc after this step these are the sizes of sound.ko* in modules/sound/sound: -rw-r--r-- 1 root wheel 449120 Apr 21 21:36 sound.ko -rw-r--r-- 1 root wheel 2284757 Apr 21 21:36 sound.ko.debug -rw-r--r-- 1 root wheel 2055512 Apr 21 21:36 sound.ko.symbols 2) make -V SRCS | tr \n | grep -v \.h | sort | grep ^[a-m].* | xargs touch ^ this is your bisect pattern 3) make CC=clang make install and after this step: -rw-r--r-- 1 root wheel 187480 Apr 21 21:37 sound.ko -rw-r--r-- 1 root wheel 872983 Apr 21 21:37 sound.ko.debug -rw-r--r-- 1 root wheel 792856 Apr 21 21:37 sound.ko.symbols so quite some code is missing it seems. [snip] -- Alexander Best ___ 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 kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
John Baldwin wrote: On Tuesday 20 April 2010 7:35:46 pm Matthew Jacob wrote: On 04/20/2010 03:44 PM, Maxim Sobolev wrote: Maxim Sobolev wrote: Maybe try adding hint.atkbdc.0.disabled=1 hint.atkbd.0.disabled=1 to /boot/device.hints? That has reportedly removed minute-long boot delays on some Nehalem machines. No, that have not helped at all. I measured the delay - it's about 6 minutes from boot command to the first smap message. Do you or anybody else have other ideas? Actually it helped, thank you very much! The problem was that I have had my hints compiled into the kernel itself. Me too! I can't reproduce this currently, but it would be good to debug this further. My suggestions on how to do this would be to create an array of uint64_t and save TSC values (rdtsc()) into it at specific points in the atkbd/syscons console init. You can then print out the deltas between array entries once the console is fully initialized. Moving the rdtsc() calls around should allow one to determine where in the atkbd/syscons init the long pause is happening. There is already a code to detect non-existing AT keyboard and avoid attaching atkbd to it. The code is i386-only at the moment, I am trying to figure out how to modify it so that it works on amd64 as well. -Maxim ___ 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
SYSCTL_XXX(9) manual page deficiency
Hi, According to the manual page for the SYSCTL_XXX(9) family of functions, in order to use them one needs to include sys/types.h and sys/sysctl.h. However, if you do just that the code doesn't compile due to missing DATA_SET() macros, which is defined in sys/linker_set.h. My question is whether or not sysctl.h should include sys/linker_set.h or manual page to be extended to also suggests that this include is required to use those functions? -Maxim ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote: Roman Divacky schrieb am 2010-04-21: [snip] 1) cd modules/sound/sound make CC=gcc after this step these are the sizes of sound.ko* in modules/sound/sound: -rw-r--r-- 1 root wheel 449120 Apr 21 21:36 sound.ko -rw-r--r-- 1 root wheel 2284757 Apr 21 21:36 sound.ko.debug -rw-r--r-- 1 root wheel 2055512 Apr 21 21:36 sound.ko.symbols 2) make -V SRCS | tr \n | grep -v \.h | sort | grep ^[a-m].* | xargs touch this line is wrong.. it creates empty files which are used instead of touching the existing ones... it needs to be adjusted so it touches the files (thus forcing them to be rebuilt with the second make invocation) ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky schrieb am 2010-04-21:
On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
Roman Divacky schrieb am 2010-04-21:
[snip]
1) cd modules/sound/sound make CC=gcc
after this step these are the sizes of sound.ko* in
modules/sound/sound:
-rw-r--r-- 1 root wheel 449120 Apr 21 21:36 sound.ko
-rw-r--r-- 1 root wheel 2284757 Apr 21 21:36 sound.ko.debug
-rw-r--r-- 1 root wheel 2055512 Apr 21 21:36 sound.ko.symbols
2) make -V SRCS | tr \n | grep -v \.h | sort | grep
^[a-m].*
| xargs touch
this line is wrong.. it creates empty files which are used instead
of touching the existing ones... it needs to be adjusted so it
touches the files (thus forcing them to be rebuilt with the second
make invocation)
how about something like this?
make -V SRCS | tr \n | grep -v \.h | sort | grep ^[a-m].*
/tmp/search; for i in `cat /tmp/search`; do find ../../../dev/sound -name $i
-exec touch {} +; done
--
Alexander Best
___
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: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky schrieb am 2010-04-21: On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote: Roman Divacky schrieb am 2010-04-21: [snip] 1) cd modules/sound/sound make CC=gcc after this step these are the sizes of sound.ko* in modules/sound/sound: -rw-r--r-- 1 root wheel 449120 Apr 21 21:36 sound.ko -rw-r--r-- 1 root wheel 2284757 Apr 21 21:36 sound.ko.debug -rw-r--r-- 1 root wheel 2055512 Apr 21 21:36 sound.ko.symbols 2) make -V SRCS | tr \n | grep -v \.h | sort | grep ^[a-m].* | xargs touch this line is wrong.. it creates empty files which are used instead of touching the existing ones... it needs to be adjusted so it touches the files (thus forcing them to be rebuilt with the second make invocation) ok. i think i found the file which is causing all the trouble. it's sys/dev/sound/pcm/buffer.c -- Alexander Best ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky schrieb am 2010-04-21: On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote: Roman Divacky schrieb am 2010-04-21: [snip] 1) cd modules/sound/sound make CC=gcc after this step these are the sizes of sound.ko* in modules/sound/sound: -rw-r--r-- 1 root wheel 449120 Apr 21 21:36 sound.ko -rw-r--r-- 1 root wheel 2284757 Apr 21 21:36 sound.ko.debug -rw-r--r-- 1 root wheel 2055512 Apr 21 21:36 sound.ko.symbols 2) make -V SRCS | tr \n | grep -v \.h | sort | grep ^[a-m].* | xargs touch this line is wrong.. it creates empty files which are used instead of touching the existing ones... it needs to be adjusted so it touches the files (thus forcing them to be rebuilt with the second make invocation) i'm now 100% sure that buffer.c is causing the problem. what i did to verify this was: cd sys/modules/sound/sound make CC=clang touch ../../../dev/sound/pcm/buffer.c make CC=gcc make install this gives me working sound! -- Alexander Best ___ 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: Does makeoptions WITH_CTF=yes actually work?
On Fri, Apr 16, 2010 at 03:51:40PM +0200, Alexander Leidinger wrote:
Quoting Navdeep Parhar npar...@gmail.com (from Wed, 14 Apr 2010
11:35:40 -0700):
Have you or anyone else ever used buildkernel successfully with
makeoptions WITH_CTF=yes in the conf file? Something as simple as
this does not work for me:
Copypaste patch, tabs probbly mangled:
---snip---
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 206700)
+++ Makefile.inc1 (working copy)
@@ -314,7 +314,7 @@
.endif
# kernel stage
-KMAKEENV= ${WMAKEENV}
+KMAKEENV= ${WMAKEENV:NNO_CTF=1}
KMAKE= ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME}
#
@@ -780,7 +780,7 @@
@echo --
cd ${KRNLOBJDIR}/${_kernel}; \
MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \
- ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \
+ ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS \
-f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile
# XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case.
.if !defined(MODULES_WITH_WORLD) !defined(NO_MODULES)
exists(${KERNSRCDIR}/modules)
---snip---
This lets the buildkernel generate ctf info in the object files (the
build is not finished yet, so I still have to verify that the final
kernel contains them too, but I do not see a reason ATM why this
should not be the case).
Your patch works for me, thanks. There is just one more problem with the CTF
generation that needs to be fixed:
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html
While you're here can you take a look at the patch in that email too?
Regards,
Navdeep
___
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
newsyslog patch implementing file includes
I wanted the ability for a port to have a rotating log policy so I wrote a patch for newsyslog to implement includes of other newsyslog.conf style files. Please find the patch at: http://people.freebsd.org/~gordon/patches/newsyslog.diffhttp://people.freebsd.org/%7Egordon/patches/newsyslog.diff Format for the include line in /etc/newsyslog.conf is: include /etc/defaults/newsyslog.conf Here's a quick overview of the changes: Convert the conf_entry struct from using a home rolled linked list to the queue(3) macros. Add a STAILQ to process include files. Add support for include tag to specify include files. Globbing is supported in include statements. Properly detect circular include loop dependencies. Please take a look and send me any comments you might have. Thanks, Gordon ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
On Wed, Apr 21, 2010 at 05:23:38PM +0200, Roman Divacky wrote: On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: i might have stumbled upon a problem with clang. i've compiled a kernel from the clang branch using `make kernel INSTKERNNAME=clang` and booted from it. i'm now experiencing audio problems with mp3s and certain video files. playback is awfully slow and the audio output gets distorted massively. `top` however reports no high cpu load and `vmstat -i` doesn't report anything unusual either. this problem doesn't occur with a regular gcc-kernel. both kernels are running under a regular (gcc) world. i thought it might be a problem with acpi, but disabling acpi (hint.acpi.0.disabled=1) gives me a system freeze. I've heard about this problem but did not manage to reproduce that. can you try to bisect what file is being miscompiled? ie. compile half of the kernel with gcc and half with clang and bisect this way to a single file. The FreeBSD sound subsystem has a sample-rate converter built into the feeder that (from a cursory look) is probably quite carefully tweaked to be able to perform well (or at all). I've added -multimedia to the CC line, because they're the guys who are going to know the details. It's possible that some GCC-specific manifest constants are being tested-for, with sub-optimal fall-back code being run, instead. In the mean-time, Alexander, are there any sound-related sysctls that you can tweak so that the audio playback that you're doing does *not* involve sample rate conversion? Cheers, -- Andrew ___ 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
