Re: [bsdgrep] grep -ql does not supress output
On Fri, 23 Jul 2010, Doug Barton wrote: Thanks. I took another look at it, and I think the attached patch does the trick, Oops, forgot !Lflag in the last bit, this one fixes it. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso Index: grep.c === --- grep.c (revision 210438) +++ grep.c (working copy) @@ -466,11 +466,11 @@ break; case 'L': lflag = false; - Lflag = qflag = true; + Lflag = true; break; case 'l': Lflag = false; - lflag = qflag = true; + lflag = true; break; case 'm': mflag = true; Index: util.c === --- util.c (revision 210438) +++ util.c (working copy) @@ -226,9 +226,9 @@ printf("%s:", ln.file); printf("%u\n", c); } - if (lflag && c != 0) + if (lflag && !qflag && c != 0) printf("%s\n", fn); - if (Lflag && c == 0) + if (Lflag && !qflag && c == 0) printf("%s\n", fn); if (c && !cflag && !lflag && !Lflag && binbehave == BINFILE_BIN && f->binary && !qflag) @@ -342,7 +342,7 @@ return (c); /* Binary file */ /* Dealing with the context */ - if ((tail || c) && !cflag && !qflag) { + if ((tail || c) && !cflag && !qflag && !lflag && !Lflag) { if (c) { if (!first && !prev && !tail && Aflag) printf("--\n"); ___ 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: [bsdgrep] grep -ql does not supress output
On Sat, 24 Jul 2010, Gabor Kovesdan wrote: Em 2010.07.24. 6:19, Doug Barton escreveu: There are several places in portmaster where I use '[e]grep -ql ' to signal existence of something without having to deal with the output of grep. In oldgrep this worked as advertised. In bsdgrep it doesn't. Furthermore, looking at the code it doesn't seem like it's a trivial fix since you seem to be conflating the idea of -q with "don't output the matching lines" instead of "don't output anything" which is what the old one did: case 'l': Lflag = false; lflag = qflag = true; break; Also, looking at the code it's not clear to me that the -q option has its previous behavior of halting processing for that file on the first match, but I've only given it a quick look. So, request number 1, fix it so that bsdgrep -ql doesn't output anything, and make sure that -q actually halts processing on the first match. Of course both this and the color issue will be fixed. Thanks. I took another look at it, and I think the attached patch does the trick, although you'll probably want to regression test it. I'm running some limited tests now as well. I still haven't verified that -q halts processing on the first match however. Request number 2, think about whether or not introducing this as the default was the right course of action. I held my tongue on this when you committed it, but in the past when such things have been added they start life as an option, allowing those who choose to do so to regression test them. Once they've had a shakeout period THEN the switch is flipped to make them the default. I'm not at the point yet where I'm ready to ask for you to change this, but between the color thing and this issue, that ball has started to roll, in my mind at least. We'll see what happens with more testing. This change was thoroughly tested on pointyhat and by several interested people even by you. Actually, the compatibility for non-standard GNU regexes were added when you requested it after trying out with portmaster. Yes, IIRC that was when I last tested it for you about 2 years ago. And I appreciate you adding that support. Why didn't you tell me earlier about this bug then, as well? My fuzzy recollection is that the various micro-optimizations such as this one have been added to portmaster in the intervening 2 years, but I could be wrong. If the bug and my code were both there 2 years ago, please accept my apologies for not reporting it sooner. Meanwhile, pointyhat runs are great for trying to assess bare technical compatibility with known combinations of options; however as I've learned in trying to regression-test portmaster, real human users are roughly infinitely more creative than that. :) hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo PicassoIndex: grep.c === --- grep.c (revision 210438) +++ grep.c (working copy) @@ -466,11 +466,11 @@ break; case 'L': lflag = false; - Lflag = qflag = true; + Lflag = true; break; case 'l': Lflag = false; - lflag = qflag = true; + lflag = true; break; case 'm': mflag = true; Index: util.c === --- util.c (revision 210438) +++ util.c (working copy) @@ -226,9 +226,9 @@ printf("%s:", ln.file); printf("%u\n", c); } - if (lflag && c != 0) + if (lflag && !qflag && c != 0) printf("%s\n", fn); - if (Lflag && c == 0) + if (Lflag && !qflag && c == 0) printf("%s\n", fn); if (c && !cflag && !lflag && !Lflag && binbehave == BINFILE_BIN && f->binary && !qflag) @@ -342,7 +342,7 @@ return (c); /* Binary file */ /* Dealing with the context */ - if ((tail || c) && !cflag && !qflag) { + if ((tail || c) && !cflag && !qflag && !lflag) { if (c) { if (!first && !prev && !tail && Aflag) printf("--\n"); ___ 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: [bsdgrep] grep -ql does not supress output
Em 2010.07.24. 6:19, Doug Barton escreveu: There are several places in portmaster where I use '[e]grep -ql ' to signal existence of something without having to deal with the output of grep. In oldgrep this worked as advertised. In bsdgrep it doesn't. Furthermore, looking at the code it doesn't seem like it's a trivial fix since you seem to be conflating the idea of -q with "don't output the matching lines" instead of "don't output anything" which is what the old one did: case 'l': Lflag = false; lflag = qflag = true; break; Also, looking at the code it's not clear to me that the -q option has its previous behavior of halting processing for that file on the first match, but I've only given it a quick look. So, request number 1, fix it so that bsdgrep -ql doesn't output anything, and make sure that -q actually halts processing on the first match. Of course both this and the color issue will be fixed. Request number 2, think about whether or not introducing this as the default was the right course of action. I held my tongue on this when you committed it, but in the past when such things have been added they start life as an option, allowing those who choose to do so to regression test them. Once they've had a shakeout period THEN the switch is flipped to make them the default. I'm not at the point yet where I'm ready to ask for you to change this, but between the color thing and this issue, that ball has started to roll, in my mind at least. We'll see what happens with more testing. This change was thoroughly tested on pointyhat and by several interested people even by you. Actually, the compatibility for non-standard GNU regexes were added when you requested it after trying out with portmaster. Why didn't you tell me earlier about this bug then, as well? Gabor ___ 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"
[bsdgrep] grep -ql does not supress output
There are several places in portmaster where I use '[e]grep -ql ' to signal existence of something without having to deal with the output of grep. In oldgrep this worked as advertised. In bsdgrep it doesn't. Furthermore, looking at the code it doesn't seem like it's a trivial fix since you seem to be conflating the idea of -q with "don't output the matching lines" instead of "don't output anything" which is what the old one did: case 'l': Lflag = false; lflag = qflag = true; break; Also, looking at the code it's not clear to me that the -q option has its previous behavior of halting processing for that file on the first match, but I've only given it a quick look. So, request number 1, fix it so that bsdgrep -ql doesn't output anything, and make sure that -q actually halts processing on the first match. Request number 2, think about whether or not introducing this as the default was the right course of action. I held my tongue on this when you committed it, but in the past when such things have been added they start life as an option, allowing those who choose to do so to regression test them. Once they've had a shakeout period THEN the switch is flipped to make them the default. I'm not at the point yet where I'm ready to ask for you to change this, but between the color thing and this issue, that ball has started to roll, in my mind at least. We'll see what happens with more testing. Thanks, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: Can't compile today's kernel: sys/cam/cam.c + CTF
On Fri, 23 Jul 2010, Navdeep Parhar wrote: Hmm. I think a "make toolchain" in /usr/src before you build your kernel should fix it. You probably have an old ctfconvert sitting around. Building with a clean obj directory did the trick. Thanks again! Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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] ZFS v15 patch (version 3)
Forwarding to the list. I put the patch on a Sun blade 100 with 256 megs of ram and no issues so far. (sparc64 architecture) sunburn# uname -a FreeBSD sunburn 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #6: Tue Jul 6 20:59:09 UTC 2010 r...@sunburn:/usr/obj/usr/src/sys/GENERIC sparc64 sunburn# This machine only has 256 megs of memory, but i made two 100 megabyte memory disks, mirrored them, wrote some stuff, offlined each one individually, and it all worked okay. sunburn# zpool status pool: tank state: ONLINE scrub: scrub completed after 0h0m with 0 errors on Wed Jul 7 19:26:25 2010 config: NAMESTATE READ WRITE CKSUM tank ONLINE 0 0 0 mirrorONLINE 0 0 0 md101 ONLINE 0 0 0 md102 ONLINE 0 0 0 errors: No known data errors sunburn# sunburn# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 37.8M 25.7M 37.6M /tank Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-PRERELEASE #6: Tue Jul 6 20:59:09 UTC 2010 r...@sunburn:/usr/obj/usr/src/sys/GENERIC sparc64 real memory = 268435456 (256 MB) avail memory = 243982336 (232 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (502.00 MHz CPU) ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware kbd0 at kbdmux0 nexus0: pcib0: mem 0x1fe-0x1fe,0x1fe0100-0x1fe01ff irq 2032,2030,2031,2021 on nexus0 pcib0: Hummingbird compatible, impl 0, version 0, IGN 0x1f, bus A, 33MHz pcib0: DVMA map: 0xc000 to 0xc3ff 8192 entries pcib0: [FILTER] pcib0: [FILTER] pcib0: [GIANT-LOCKED] pcib0: [ITHREAD] pcib0: [FILTER] pci0: on pcib0 ebus0: mem 0xf000-0xf0ff,0xf100-0xf17f at device 12.0 on pci0 ebus0: : incomplete ebus0: addr 0-0xf (no driver attached) eeprom0: addr 0x1-0x11fff on ebus0 eeprom0: model mk48t59 isab0: at device 7.0 on pci0 isa0: on isab0 gem0: mem 0x40-0x41 at device 12.1 on pci0 miibus0: on gem0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto gem0: 2kB RX FIFO, 2kB TX FIFO gem0: Ethernet address: xx:xx:xx:xx:xx gem0: [ITHREAD] fwohci0: mem 0x42-0x4207ff,0x422000-0x4227ff at device 12.2 on pci0 fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:03:ba:ff:fe:0c:de:34 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xc1128000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:03:ba:0c:de:34 fwe0: Ethernet address: 02:03:ba:0c:de:34 fwip0: on firewire0 fwip0: Firewire address: 00:03:ba:ff:fe:0c:de:34 @ 0xfffe, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x, SelfID Count=1, CYCLEMASTER mode ohci0: mem 0x200-0x2007fff at device 12.3 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 pci0: at device 3.0 (no driver attached) pci0: at device 8.0 (no driver attached) atapci0: port 0xa00-0xa07,0xa18-0xa1b,0xa10-0xa17,0xa08-0xa0b,0xa20-0xa2f at device 13.0 on pci0 atapci0: [ITHREAD] atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] machfb0: port 0xb00-0xbff mem 0x300-0x3ff,0x426000-0x426fff at device 19.0 on pci0 machfb0: 8 MB aperture at 0xce376000 swapped machfb0: 8188 KB SDRAM 114.765 MHz, maximum RAMDAC clock 230 MHz, DSP machfb0: resolution 1152x900 at 8 bpp pcib1: at device 5.0 on pci0 pci1: on pcib1 syscons0: on nexus0 syscons0: Unknown <16 virtual consoles, flags=0x100> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 uart1: [FILTER] Timecounter "tick" frequency 50200 Hz quality 1000 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 ad0: 8223MB at ata2-master UDMA66 ugen0.1: at usbus0 uhub0: on usbus0 acd0: CDROM at ata2-slave PIO4 GEOM: ad0: adding VTOC8 information. uhub0: 4 ports with 4 removable, self powered Trying
[bsdgrep] outputs color sequences even when stdout is not tty
I've got a breakage in bin/csh $ make depend grep '[FV]_' /usr/src/bin/csh/../../contrib/tcsh/ed.defns.c | grep '^#define' >> ed.defns.h grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define' >> sh.err.h cc -E -O2 -pipe -march=native -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DNO_NLS_CATALOGS -ggdb -std=gnu99 -fstack-protector -Wno-pointer-sign /usr/src/bin/csh/../../contrib/tcsh/tc.const.c /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h /usr/src/bin/csh/../../contrib/tcsh/config_f.h /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' | sort >> tc.const.h cc -o gethost -O2 -pipe -march=native -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DNO_NLS_CATALOGS -ggdb -std=gnu99 -fstack-protector -Wno-pointer-sign /usr/src/bin/csh/../../contrib/tcsh/gethost.c In file included from /usr/src/bin/csh/../../contrib/tcsh/sh.h:488:0, from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: ./sh.err.h:4:1: error: stray '\33' in program ./sh.err.h:4:2: error: expected identifier or '(' before '[' token ./sh.err.h:4:5: error: invalid suffix "m" on integer constant ./sh.err.h:4:5: error: expected identifier or '(' before numeric constant ... $ vis $(make -V .OBJDIR)/sh.err.h | head /* Do not edit this file, make creates it. */ #ifndef _h_sh_err #define _h_sh_err \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KFLAGS 0xf000 \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KNAME 0x1000 \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KSILENT 0x2000 \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KOLD 0x4000 \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KSYNTAX 0 $ printenv | fgrep -i grep GREP_COLOR=1;33 GREP_OPTIONS=--color --exclude \*.svn\* I think it should behave like ls(1) and gnu grep(1) and strip color sequences if stdout is not associated with terminal. ___ 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: Can't compile today's kernel: sys/cam/cam.c + CTF
On Fri, Jul 23, 2010 at 3:40 PM, Doug Barton wrote: > On Fri, 23 Jul 2010, Navdeep Parhar wrote: > >> On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton wrote: >>> >>> I'm getting this with r210435. World built fine: >>> >>> cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall >>> -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>> -Wmissing-prototypes >>> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign >>> -fformat-extensions -nostdinc -I. -I/usr/local/src/sys >>> -I/usr/local/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 >>> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow >>> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror >>> /usr/local/src/sys/i386/i386/locore.s >>> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs >>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline >>> -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. >>> -I/usr/local/src/sys -I/usr/local/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 -mno-align-long-strings >>> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >>> -mno-sse3 -ffreestanding -fstack-protector -Werror >>> /usr/local/src/sys/cam/cam.c >>> *** Signal 11 >>> >>> Removing makeoptions WITH_CTF=yes does the trick. >> >> I ran into this earlier today. ctfconvert would dump core during >> buildkernel. >> Please try r210438 > > I updated to that revision, tried just rebuilding ctfconvert, didn't work. > Then I tried installing the new ctfconvert, still doesn't work. Do I need to > go farther up the tree? Hmm. I think a "make toolchain" in /usr/src before you build your kernel should fix it. You probably have an old ctfconvert sitting around. 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"
Re: Can't compile today's kernel: sys/cam/cam.c + CTF
On Fri, 23 Jul 2010, Navdeep Parhar wrote: On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton wrote: I'm getting this with r210435. World built fine: cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/local/src/sys -I/usr/local/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/local/src/sys/i386/i386/locore.s cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/local/src/sys -I/usr/local/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/local/src/sys/cam/cam.c *** Signal 11 Removing makeoptions WITH_CTF=yes does the trick. I ran into this earlier today. ctfconvert would dump core during buildkernel. Please try r210438 I updated to that revision, tried just rebuilding ctfconvert, didn't work. Then I tried installing the new ctfconvert, still doesn't work. Do I need to go farther up the tree? Thanks for the response, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: Can't compile today's kernel: sys/cam/cam.c + CTF
On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton wrote: > I'm getting this with r210435. World built fine: > > cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I/usr/local/src/sys > -I/usr/local/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 > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/local/src/sys/i386/i386/locore.s > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I/usr/local/src/sys -I/usr/local/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 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/local/src/sys/cam/cam.c > *** Signal 11 > > Removing makeoptions WITH_CTF=yes does the trick. I ran into this earlier today. ctfconvert would dump core during buildkernel. Please try r210438 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"
Can't compile today's kernel: sys/cam/cam.c + CTF
I'm getting this with r210435. World built fine: cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/local/src/sys -I/usr/local/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/local/src/sys/i386/i386/locore.s cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/local/src/sys -I/usr/local/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/local/src/sys/cam/cam.c *** Signal 11 Removing makeoptions WITH_CTF=yes does the trick. -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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] update to NTP in base
Thanks to Niclas for taking this, I will look at it in the next few days. Le 22 juil. 2010 à 12:42, Niclas Zeising a écrit : > Hello! > The instructions at > http://www.freebsd.org/cgi/query-pr.cgi?pr=148836 > (Pr bin/148836) contains an update to the base system NTP program suite. > Please test it and report successes and failures. > Known issues: The html doc distribution is not installed, but it can be found > on the internet if needed. If it is requested by many to include it I'll make > a new patch for it. ___ 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: nvidia-driver crashing kernel on head
On Saturday 17 July 2010 17:25:27 Christian Zander wrote: > On Sat, Jul 17, 2010 at 07:24:54AM -0700, David Naylor wrote: > (...) > > > > >>> These freezes and panics are due to the driver using a spin mutex > > > >>> instead of a > > > >>> regular mutex for the per-file descriptor event_mtx. If you patch > > > >>> the driver > > > >>> to change it to be a regular mutex I think that should fix the > > > >>> problems. > > > >> > > > >> Can you give an example? :) I don't mind creating a patch for all of > > > >> them if you can illustrate what needs to be changed. > > > > > > > > See the attached patch > > > > > > In order to use 195.36.15 it was necessary to use the patch Rene sent, > > > the suggestion from jhb previously to remove some locks, plus a bit > > > more. The patch that got it working on HEAD for me (specifically > > > r209633) is attached. With that patch I could start X, and run it for a > > > while, but performance was very poor, even in comparison with the stock > > > nv driver, and it crashed a couple times (although not nearly as bad as > > > previously). > > > > > > So based on other suggestions I tried the newest release version at > > > nvidia, 256.35. Some of the same locking stuff was needed to patch it, > > > a patch for the port which includes the locking patch is also > > > attached. If you are running an amd64 system you'll have to type 'make > > > makesum' after applying this patch to the port. I'm not sure this > > > patch is complete, or what Alexey might want to do with the update, > > > but it does create an accurate plist which means you can cleanly > > > deinstall/pkg_delete when you're done. > > > > > > With 256.35 performance and stability have both been quite good, > > > comparable even to before the the drama started. The only concern I > > > have at this point is that I'm periodically getting a strange sort of > > > "flash" popping up on my screen that I didn't get while I was running > > > the nv driver recently. It looks sort of like the default X background > > > (the tiny gray crosshatch) is popping through for just a split second. > > > > I've been getting these messages on the console: > > > > NVRM: Xid (0001:00): 16, Head Count 000218d5 > > NVRM: Xid (0001:00): 8, Channel > > NVRM: Xid (0001:00): 16, Head Count 000218d6 > > NVRM: Xid (0001:00): 8, Channel 0002 > > > > This is preceded by X locking hard. I cannot VT switch to a normal > > console and sometimes the computer needs a hard reset (i.e. does not > > respond to power button). It appears to only trigger when under heavy > > load. eg > > make -C /usr/src -j8 buildworld > > > > This seems to be messing with interrupts with other subsystems as my > > network drivers are less than reliable of late. (Watchdog timeouts). > > The messages indicate that the NVIDIA driver hasn't received > interrupts from the GPU @ PCI:1:00.0 over a significant > period of time. If you are seeing similar problems with other > system components, there's a good chance that the above is > a symptom of some larger problem. I think you are right. I'm not sure if this is a hardware problem or FreeBSD. I reverted to a kernel from May 01 and the system is solid (~5 days). I'm using the patched 256.35 driver without problem. > > This happens with 195.36.15 unpatched and 256.35 patched. > > > > I have not checked if booting with WITNESS enabled works. > > > > Regards > > > > * David Naylor > > * 0xFF6916B2 signature.asc Description: This is a digitally signed message part.