Re: kern/144311: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'
The following reply was made to PR kern/144311; it has been noted by GNATS. From: Yoshiaki Kasahara To: bug-follo...@freebsd.org Cc: Subject: Re: kern/144311: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to' Date: Fri, 26 Feb 2010 17:33:42 +0900 (JST) I changed the rule to use 'route-to' instead of 'reply-to' and the ICMP storm stopped. -- if_isp1="em0" isp1_router="GW1.GW1.GW1.GW1" if_isp2="em1" isp2_router="GW2.GW2.GW2.GW2" pass in all no state pass out all pass out route-to ( $if_isp1 $isp1_router ) from $if_isp1 pass out route-to ( $if_isp2 $isp2_router ) from $if_isp2 -- I'm not sure about the implementation difference of 'reply-to' and 'route-to'. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/144311: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'
The following reply was made to PR kern/144311; it has been noted by GNATS. From: Yoshiaki Kasahara To: bug-follo...@freebsd.org Cc: Subject: Re: kern/144311: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to' Date: Fri, 26 Feb 2010 18:27:17 +0900 (JST) I'm sorry that my previous follow-up was incorrect. It seems that I need 'no state' for both 'route-to' lines or they are ignored. After that, packets are redirected to correct interfaces, and ICMP storm also revived. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/144316: Installing BSD unzip utility in base system may lead to confusing.
>Number: 144316 >Category: bin >Synopsis: Installing BSD unzip utility in base system may lead to >confusing. >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 26 10:30:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Takanori Watanabe >Release:FreeBSD 9.0-CURRENT >Organization: Private >Environment: FreeBSD konata.init-main.com 9.0-CURRENT FreeBSD 9.0-CURRENT #29 r203274M: Sun Jan 31 21:14:50 JST 2010 >Description: FreeBSD unzip utility do not extract archive with password set. When extracting such archive, I used unzip(1) installed from ports, though I use normal zip archive with FreeBSD-tar. After BSD unzip utility comes to the base, I cannot extract such archive, because the BSD unzip utility is executed instead of normal unzip utility. >How-To-Repeat: Try to unzip archive with password, in clean installed account, with unzip-port installed. >Fix: chmod a-x /usr/bin/unzip or move /usr/local/bin to the head of your command search PATH. The best solution is to support extracting archive with password. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'
Old Synopsis: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to' New Synopsis: [pf] [icmp] massive ICMP storm on lo0 occurs when using pf(4) 'reply-to' Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 26 11:23:27 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144311 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144316: Installing BSD unzip(1) utility in base system may lead to confusing.
Synopsis: Installing BSD unzip(1) utility in base system may lead to confusing. State-Changed-From-To: open->closed State-Changed-By: remko State-Changed-When: Fri Feb 26 12:01:20 UTC 2010 State-Changed-Why: You can set the PATH environment variable yourself; if you require this, you should handle this. This goes for all ports that might replace base applications (like named for example). http://www.freebsd.org/cgi/query-pr.cgi?pr=144316 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/144322: truss(1) fails on 'assistant-qt4' from the port qt4-assistant-4.6.1
>Number: 144322 >Category: misc >Synopsis: truss(1) fails on 'assistant-qt4' from the port >qt4-assistant-4.6.1 >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 26 12:20:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Yuri >Release:8.0-STABLE >Organization: n/a >Environment: >Description: When I run truss on /usr/local/bin/assistant-qt4 truss prints this log and exits: mprotect(0xbf5fb000,4096,PROT_NONE) = 0 (0x0) thr_new(0xbfbfda90,0x34,0xbfbfdae4,0x33d11721,0x370de998,0x3) = 0 (0x0) -- UNKNOWN SYSCALL 1016070144 -- read(6,0x3807f018,4096) ERR#35 'Resource temporarily unavailable' compat.lseek(0x3c959784,0x3c9597b0,0xbf6fbe88,0x37037c72,0x370d84a0,0x3c959740) ERR#92 'Protocol error' compat.lseek(0x2,0x1,0x370d84a0,0x3c959740,0x0,0xbf6fbe7c) ERR#92 'Protocol error' truss: get_struct 0x1: Bad address --- end log --- >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/144323: [ieee80211] A response management frame appears in wireshark captures before the corresponding request management frame in HOSTAP mode
>Number: 144323 >Category: kern >Synopsis: [ieee80211] A response management frame appears in wireshark >captures before the corresponding request management frame in HOSTAP mode >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 26 14:20:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Alexander Egorenkov >Release:FreeBSD 8.0 STABLE >Organization: >Environment: FreeBSD dantooine 8.0-RELEASE FreeBSD 8.0-RELEASE #2: Tue Dec 15 17:56:06 CET 2009 r...@dantooine:/usr/obj/usr/src/sys/MYKERNEL i386 >Description: I was testing my Ralink WLAN driver in HOSTAP mode and noticed the following strange behaviour of net80211 while capturing frames with wireshark. All responses to management frame requests appeared in the wireshark capture **before** the corresponding request frames, e.g. Probe Responses before Probe Requests, Action Responses before Action Requests, Association Responses before Association Requests and so on. I observed this behaviour only for management frames, data frames were OK. I also did't notice this behavior in STA mode. I could provide a wireshark capture if needed. >How-To-Repeat: You need a WLAN NIC that supports HOSTAP mode. Start hostapd and capture some Probe Requests and Responses. >Fix: I investigated the problem and found out that in the function ieee80211_hostap.c:hostap_input that is responsible for processing incoming frames in HOSTAP mode a management frame is passed to bpf **after** the call to "iv_recv_mgmt". The function pointer iv_recv_mgmt that points to the function ieee80211_hostap.c:hostap_recv_mgmt processes received management frames and, furthermore, **sends** corresponding response frames if needed. And when hostap_recv_mgmt is done, management frames are passed to ieee80211_radiotap_rx. To fix the problem, the call to ieee80211_radiotap_rx in ieee80211_hostap.c:hostap_input should happen **before** the call to iv_recv_mgmt for management frames. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/144323: [ieee80211] A response management frame appears in wireshark captures before the corresponding request management frame in HOSTAP mode
Synopsis: [ieee80211] A response management frame appears in wireshark captures before the corresponding request management frame in HOSTAP mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 26 14:25:12 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144323 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/144325: [libpcap] tcpdump compiles complex expression to incorrect BPF code
>Number: 144325 >Category: bin >Synopsis: [libpcap] tcpdump compiles complex expression to incorrect BPF >code >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 26 16:00:13 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Vadim S. Goncharov >Release:FreeBSD 7.2-RELEASE i386 >Organization: Tomsk Polytechnic University >Environment: System: FreeBSD kernblitz.nuclight.avtf.net 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 r...@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 The same tcpdump -d confirmed by others on 6.x and 8.0. >Description: I tried to gather statistics on some packets based on signature in data payload, for plain traffic that was simple "tcpdump 'udp[20:4]=0x7fff'" (this works) but for PPTP things go complex and I was forced to write very complex expression. I've used cpp(1) for this. This has worked earlier in 6.4 days for me for another packets, I've just redone it for another bytes, file for cpp was roughtly the same. But this didn't match anything. After cutting down the full expression to only the most relevant part for my generated test IP-packets (see most parts below /* commented */), I was able to look at the tcpdump -d debug BPF assembly code output and identify that generated code was incorrect. >How-To-Repeat: Here is the packet which I try to match, and tcpdump debug output. Note that if you uncomment all final expression's parts and do s/INNER_IS_UTP/INNER_IS_UDP/g, this will work for up to all UDP packets inside GRE (but without signatures, of course). So bugs start to happen when IS_TORRENT_UTP(INNER_UDP_OFFSET(ppp_hdr_len)) is included. $ uuencode bug100225.pcap < bug100225.pcap # test packet to catch begin 644 bug100225.pcap MU,.RH0(`!/__W=B&2P98"P!:``...@(```!% M``!6S'4``/PO;#!.C``,V1U>'3"!B`L`,L`+IP``"^#_`P`A10``+CU* H```X$> 5) + 12) /* Actual IP byte values to find in the UDP payload of inner IP datagram */ #define IS_TORRENT_UTP(udp_hdr_start) (ip[(udp_hdr_start+20):4]=0x7fff) /* Check inner IP has UDP payload (proto 17) then calculate offset and pass it to UTP macro */ #define INNER_IS_UDP(ppp_hdr_len) (ip[GRE_DATA_START+ppp_hdr_len+9]=17) #define INNER_UDP_OFFSET(ppp_hdr_len) (GRE_DATA_START+ppp_hdr_len+IPHDRLEN(GRE_DATA_START+ppp_hdr_len)) #define INNER_IS_UTP(ppp_hdr_len) (INNER_IS_UDP(ppp_hdr_len) and IS_TORRENT_UTP(INNER_UDP_OFFSET(ppp_hdr_len))) /* * Finally, expression: sort by most frequent pattern first. * We check four possible PPP headers corresponding to IP, then * pass length of matched PPP header to checking macros. */ proto gre /*and VALID_PPTP_GRE*/ and ( /* ( (ip[GRE_DATA_START]=0x21) and INNER_IS_UTP(1) ) or ( (ip[GRE_DATA_START:2]=0xff03) and (ip[GRE_DATA_START+2]=0x21) and INNER_IS_UTP(3) ) or (*/ (ip[GRE_DATA_START:4]=0xff030021) and INNER_IS_UTP(4) /* ) or ( (ip[GRE_DATA_START:2]=0x0021) and INNER_IS_UTP(2) )*/ ) $ tcpdump -dni ng0 `cpp -P tcpdump-gre-utp-cpp` (000) ld [0] (001) jeq #0x200 jt 2jf 73 (002) ldb [13] (003) jeq #0x2fjt 4jf 73 (004) ldb [4] (005) and #0xf (006) lsh #2 (007) st M[3] (008) ldb [4] (009) and #0xf (010) lsh #2 (011) add #1 (012) tax (013) ldb [x + 4] (014) and #0x80 (015) rsh #5 (016) tax (017) ld M[3] (018) add x (019) add #12 (020) tax (021) ld [x + 4] (022) jeq #0xff030021 jt 23 jf 73 (023) ldb [4] (024) and #0xf (025) lsh #2 (026) st M[1] (027) ldb [4] (028) and #0xf (029) lsh #2 (030) add #1 (031) tax (032) ldb [x + 4] (033) and #0x80 (034) rsh #5 (035) tax (036) ld M[1] (037) add x (038) add #12 (039) add #4 (040) add #9 (041) tax (042) ldb [x + 4] (043) jeq #0x11jt 44 jf 73 (044) ldb [4] (045) and #0xf (046) lsh #2 (047) add #1 (048) tax (049) ldb [4] (050) and #0xf (051) lsh #2 (052) st M[15] (053) ldb [x + 4] (054) and #0x80 (055) rsh #5 (056) tax (057) ld M[15] (058) add x (059) add #12 (060) add #4 (061) tax (062) ldb [x + 4] (063) and #0xf (064) lsh #2 (065) tax ; here is the BUG - if this and next line cut out, then (066) ld M[11] ; it will be correct... and M[11] is never stored above (067) add x (068) add #20 (069) tax (070) ld [x + 4] (071) jeq #0x7fff jt 72 jf 73 (072) ret #96 (073) ret #0 >Fix: No known. In some cases BPF code could be manually edited and installed to kernel, but
misc/144326: PERC H200 Integrated/Adapter not recognized
>Number: 144326 >Category: misc >Synopsis: PERC H200 Integrated/Adapter not recognized >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 26 18:50:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Gabriele Riva >Release:8.0 >Organization: www.plcforum.it >Environment: >Description: Server Dell R610 PERC H200 Integrated/Adapter: the controller is not recognized, then I can not install the operating system. How do I proceed? Thanks Regards >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144306: Nasty bug in jn(3)
A review of the source history at http://svn.freebsd.org/viewvc/base/head/lib/msun/src/e_jn.c?view=log shows that this bug has been around for at 15 years. Hopefully, the patch doesn't sit in idly in the bug database. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144306: Nasty bug in jn(3)
The following reply was made to PR bin/144306; it has been noted by GNATS. From: "Steven G. Kargl" To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: bin/144306: Nasty bug in jn(3) Date: Fri, 26 Feb 2010 11:58:33 -0800 (PST) A review of the source history at http://svn.freebsd.org/viewvc/base/head/lib/msun/src/e_jn.c?view=log shows that this bug has been around for at 15 years. Hopefully, the patch doesn't sit in idly in the bug database. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144300: mdconfig(8): mdconfig -{d,l}n doesn't work
The following reply was made to PR bin/144300; it has been noted by GNATS.
From: Alexander Best
To:
Cc: Garrett Cooper
Subject: Re: bin/144300: mdconfig(8): mdconfig -{d,l}n doesn't work
Date: Fri, 26 Feb 2010 21:00:13 +0100 (CET)
This is a MIME encoded multipart message.
--+permail-20100226200013f0889e847f93-a_best01+
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
does this little patch take care of it?
cheers.
alex
--+permail-20100226200013f0889e847f93-a_best01+
Content-Type: text/plain
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="mdconfig.c.diff.txt"
SW5kZXg6IHNiaW4vbWRjb25maWcvbWRjb25maWcuYwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL21kY29u
ZmlnL21kY29uZmlnLmMJKHJldmlzaW9uIDIwNDM2NSkKKysrIHNiaW4vbWRjb25maWcvbWRjb25m
aWcuYwkod29ya2luZyBjb3B5KQpAQCAtMzczLDcgKzM3Myw3IEBACiAJCQkJCWZvdW5kID0gMTsK
IAkJCX0KIAkJCWdjID0gJnBwLT5sZ19jb25maWc7Ci0JCQlwcmludGYoIiVzIiwgcHAtPmxnX25h
bWUpOworCQkJcHJpbnRmKCIlcyVkIiwgbmZsYWcgPyAiIiA6IE1EX05BTUUsIG1kaW8ubWRfdW5p
dCk7CiAJCQlpZiAob3B0ICYgT1BUX1ZFUkJPU0UgfHwgb3B0ICYgT1BUX1VOSVQpIHsKIAkJCQl0
eXBlID0gZ2VvbV9jb25maWdfZ2V0KGdjLCAidHlwZSIpOwogCQkJCWlmIChzdHJjbXAodHlwZSwg
InZub2RlIikgPT0gMCkK
--+permail-20100226200013f0889e847f93-a_best01+--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144300: mdconfig(8): mdconfig -{d,l}n doesn't work
The following reply was made to PR bin/144300; it has been noted by GNATS.
From: Garrett Cooper
To: Alexander Best
Cc: "" ,
Garrett Cooper
Subject: Re: bin/144300: mdconfig(8): mdconfig -{d,l}n doesn't work
Date: Fri, 26 Feb 2010 12:52:17 -0800
On Feb 26, 2010, at 12:00 PM, Alexander Best wrote:
> does this little patch take care of it?
Yeah, that does the trick :}!
-Garrett
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/144329: [request] cal(1) not highlightening today in year mode
>Number: 144329 >Category: bin >Synopsis: [request] cal(1) not highlightening today in year mode >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Fri Feb 26 21:10:02 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Alexander Best >Release:9.0-CURRENT >Organization: >Environment: FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r204177M: Sun Feb 21 22:13:49 CET 2010 r...@otaku:/usr/obj/usr/src/sys/ARUNDEL amd64 >Description: (n)cal don't highlight today in year mode. this would be a useful addition imo. cheers. alex >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/144330: mbuf leakage in nfsd with zfs
>Number: 144330 >Category: kern >Synopsis: mbuf leakage in nfsd with zfs >Confidential: no >Severity: critical >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 26 21:40:02 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Gerrit Kühn >Release:8-stable as of 24th of Feb >Organization: AEI >Environment: FreeBSD mclane.rt.aei.uni-hannover.de 8.0-STABLE FreeBSD 8.0-STABLE #2: Fri Feb 26 14:15:47 CET 2010 r...@mclane.rt.aei.uni-hannover.de:/usr/obj/usr/src/sys/GENERIC amd64 >Description: When serving nfs dirs from a zfs storage, mbuffers keep being drained, but are never freed. See http://www.pmp.uni-hannover.de/test/Mitarbeiter/g_kuehn/data/mbuf.pdf as an example. y-axis is output of total mbuf clusters by netstat -m, x-axis is time in minutes. The flat region in the upper right corner corresponds to approx. 10min with nfsd turned off. Several others report similar problems (see thread on -stable with topic "mbuf leakage with nfs/zfs? (was: em0 freezes on ZFS server)"). >How-To-Repeat: Server nfs-dirs from zfs storage with 8-stable and monitor mbuf usage. >Fix: Unknown, but urgently needed. :-) >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: i386/144326: [ata] PERC H200 Integrated/Adapter not recognized on Dell R610
Old Synopsis: PERC H200 Integrated/Adapter not recognized New Synopsis: [ata] PERC H200 Integrated/Adapter not recognized on Dell R610 Responsible-Changed-From-To: freebsd-bugs->freebsd-i386 Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 26 22:09:23 UTC 2010 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=144326 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/144330: [nfs] mbuf leakage in nfsd with zfs
Old Synopsis: mbuf leakage in nfsd with zfs New Synopsis: [nfs] mbuf leakage in nfsd with zfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 26 22:25:29 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144330 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144300: [patch] mdconfig(8): mdconfig -{d,l}n doesn't work
Synopsis: [patch] mdconfig(8): mdconfig -{d,l}n doesn't work
State-Changed-From-To: open->analyzed
State-Changed-By: linimon
State-Changed-When: Fri Feb 26 22:26:03 UTC 2010
State-Changed-Why:
The contributed patch has been confirmed to fix the problem.
http://www.freebsd.org/cgi/query-pr.cgi?pr=144300
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/38256: [patch] linking pax(1) to pax_{cpio|tar}
Synopsis: [patch] linking pax(1) to pax_{cpio|tar}
State-Changed-From-To: open->analyzed
State-Changed-By: linimon
State-Changed-When: Fri Feb 26 22:30:59 UTC 2010
State-Changed-Why:
The original PR is OBE due to changes in -HEAD, but there is a suggested
change to the Makefiles that is now relevant.
http://www.freebsd.org/cgi/query-pr.cgi?pr=38256
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/38256: [patch] linking pax(1) to pax_{cpio|tar}
The following reply was made to PR bin/38256; it has been noted by GNATS.
From: Alexander Best
To:
Cc:
Subject: Re: bin/38256: [patch] linking pax(1) to pax_{cpio|tar}
Date: Sat, 27 Feb 2010 00:12:20 +0100 (CET)
This is a MIME encoded multipart message.
--+permail-201002262312201e86ffa83f08-a_best01+
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
having a look at the pax Makefile there's evidence, pax should have replaced
gnu tar/cpio. since things turned out differently these lines should be
removed. the attached patch takes care of that.
cheers.
alex
--+permail-201002262312201e86ffa83f08-a_best01+
Content-Type: text/plain
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="makefile.patch.txt"
SW5kZXg6IGJpbi9wYXgvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYmluL3BheC9NYWtlZmlsZQko
cmV2aXNpb24gMjA0Mzc0KQorKysgYmluL3BheC9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAt
MjksOCArMjksNSBAQAogU1JDUz0JYXJfaW8uYyBhcl9zdWJzLmMgYnVmX3N1YnMuYyBjYWNoZS5j
IGNwaW8uYyBmaWxlX3N1YnMuYyBmdHJlZS5jIFwKIAlnZW5fc3Vicy5jIGdldG9sZG9wdC5jIG9w
dGlvbnMuYyBwYXRfcmVwLmMgcGF4LmMgc2VsX3N1YnMuYyBcCiAJdGFibGVzLmMgdGFyLmMgdHR5
X3N1YnMuYwotI1hYWCBOT1RZRVQKLSNNQU49CXBheC4xIHRhci4xIGNwaW8uMQotI0xJTktTPQkk
e0JJTkRJUn0vcGF4ICR7QklORElSfS90YXIgJHtCSU5ESVJ9L3BheCAke0JJTkRJUn0vY3Bpbwog
CiAuaW5jbHVkZSA8YnNkLnByb2cubWs+Cg==
--+permail-201002262312201e86ffa83f08-a_best01+--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
