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 naylor.b.da...@gmail.com * 0xFF6916B2 signature.asc Description: This is a digitally signed message part.
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 niclas.zeis...@gmail.com 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
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: Can't compile today's kernel: sys/cam/cam.c + CTF
On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton do...@freebsd.org 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
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 do...@freebsd.org 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:40 PM, Doug Barton do...@freebsd.org wrote: On Fri, 23 Jul 2010, Navdeep Parhar wrote: On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton do...@freebsd.org 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
[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: [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 isp_1000 ispfw: registered firmware isp_1040 ispfw: registered firmware isp_1040_it ispfw: registered firmware isp_1080 ispfw: registered firmware isp_1080_it ispfw: registered firmware isp_12160 ispfw: registered firmware isp_12160_it ispfw: registered firmware isp_2100 ispfw: registered firmware isp_2200 ispfw: registered firmware isp_2300 ispfw: registered firmware isp_2322 ispfw: registered firmware isp_2400 ispfw: registered firmware isp_2400_multi ispfw: registered firmware isp_2500 ispfw: registered firmware isp_2500_multi kbd0 at kbdmux0 nexus0: Open Firmware Nexus device pcib0: U2P UPA-PCI bridge 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: OFW PCI bus on pcib0 ebus0: PCI-EBus3 bridge mem 0xf000-0xf0ff,0xf100-0xf17f at device 12.0 on pci0 ebus0: idprom: incomplete ebus0: flashprom addr 0-0xf (no driver attached) eeprom0: EEPROM/clock addr 0x1-0x11fff on ebus0 eeprom0: model mk48t59 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 gem0: Sun ERI 10/100 Ethernet mem 0x40-0x41 at device 12.1 on pci0 miibus0: MII bus on gem0 ukphy0: Generic IEEE 802.3u media interface 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: Sun PCIO-2 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: IEEE1394(FireWire) bus on fwohci0 dcons_crom0: dcons configuration ROM on firewire0 dcons_crom0: bus_addr 0xc1128000 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:03:ba:0c:de:34 fwe0: Ethernet address: 02:03:ba:0c:de:34 fwip0: IP over FireWire 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: Sun PCIO-2 USB controller mem 0x200-0x2007fff at device 12.3 on pci0 ohci0: [ITHREAD] usbus0: Sun PCIO-2 USB controller on ohci0 pci0: old, non-VGA display device at device 3.0 (no driver attached) pci0: multimedia, audio at device 8.0 (no driver attached) atapci0: AcerLabs M5229 UDMA66 controller 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: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] machfb0: ATI Rage XL 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: OFW PCI-PCI bridge at device 5.0 on pci0 pci1: OFW PCI bus on pcib1 syscons0: System console on nexus0 syscons0: Unknown 16
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
[bsdgrep] grep -ql does not supress output
There are several places in portmaster where I use '[e]grep -ql foo' 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: [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 foo' 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
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 foo' 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
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
