Re: mbuf leakage with nfs/zfs?
On Tue, 2 Mar 2010, Daniel Braniss wrote:
just keep sending insights/pointers and enjoy life
You could try this patch for sys/rpc/replay.c. Completely untested and
just typed into email (so don't give it to patch, just edit the file).
- try adding these 2 lines just before the end of replay_setreply() in
sys/rpc/replay.c:
- }
+ } else if (m)
+ m_freem(m);
mtx_unlock(rc-rc_lock);
}
It's the only place I can see in replay.c that might leak, rick
this is what I did:
--- a/sys/rpc/replay.c Mon Mar 01 18:29:54 2010 +0200
+++ b/sys/rpc/replay.c Fri Mar 05 09:24:17 2010 +0200
@@ -243,6 +243,9 @@
rce-rce_repbody = m;
if (m)
rc-rc_size += m_length(m, NULL);
+ } else if (m) {
+printf(free m=%p ...\n, m);
+m_freem(m);
}
mtx_unlock(rc-rc_lock);
}
but it didn't help, it's not triggered
Thanks for the explanation on the cache, things are begining to make sense.
If I understand, the reason for this cache is to prevent re-applying an
already performed rpc, which could lead to data corruption
btw, the list of CCs is rather big, so if anyone feels he rather be removed,
please let me know.
cheers,
danny
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.3-RC2 Available...
Le Thu, 04 Mar 2010 07:41:17 -0700, Reed Loefgren rloefg...@forethought.net a écrit : Hi, Good news, certainly. Will 7.3R include the gmirror improvements that were missed by 8.0R but that are in 8-STABLE? This one? http://www.freshbsd.org/?branch=RELENG_7project=freebsdcommitter=module=q=gmirror Thanks also to the FreeBSD team for their continued hard work. +1 Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Cron output mail lost with update to RELENG_7
I have discovered a problem with the mail sent by cron jobs (I refer only to logs, not invocations of mail from scripts.) They never are delivered. Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header This showed up when I upgraded the system to RELENG_7 yesterday. My previous install was RELENG_7 of May 2, 2009 and it delivered the logs without any problems. No other changes were made. postfix was 2.6.5. I have this same issue on all 8.0 systems I have, but I was blaming a fault in postfix config. Now I realize that this is not the problem. I really don't know quite where to look for this. Any clues would be appreciated. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cron output mail lost with update to RELENG_7
On Fri, Mar 5, 2010 at 1:32 PM, Kevin Oberman ober...@es.net wrote: I have discovered a problem with the mail sent by cron jobs (I refer only to logs, not invocations of mail from scripts.) They never are delivered. Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header This showed up when I upgraded the system to RELENG_7 yesterday. My previous install was RELENG_7 of May 2, 2009 and it delivered the logs without any problems. No other changes were made. postfix was 2.6.5. I have this same issue on all 8.0 systems I have, but I was blaming a fault in postfix config. Now I realize that this is not the problem. I really don't know quite where to look for this. Any clues would be appreciated. Just a guess, but have you tried running newaliases after the update? Are you sure mergemaster completed successfully? -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cron output mail lost with update to RELENG_7
On Fri, Mar 05, 2010 at 11:32:47AM -0800, Kevin Oberman wrote: I have discovered a problem with the mail sent by cron jobs (I refer only to logs, not invocations of mail from scripts.) They never are delivered. Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header This showed up when I upgraded the system to RELENG_7 yesterday. My previous install was RELENG_7 of May 2, 2009 and it delivered the logs without any problems. No other changes were made. postfix was 2.6.5. I have this same issue on all 8.0 systems I have, but I was blaming a fault in postfix config. Now I realize that this is not the problem. I really don't know quite where to look for this. Any clues would be appreciated. I don't have this issue on any of our RELENG_7 or RELENG_8 systems, all of which use postfix and WITHOUT_SENDMAIL in /etc/src.conf. It sounds like cron is trying to spawn something like mail(1) (more likely /usr/sbin/sendmail; would have to look at the code) and passing it either incorrect flags or actual content within the header itself, e.g. a missing To: line. Since postfix is involved, have you verified your /etc/mail configuration to make sure mailwrapper is referring to the correct postfix binaries? The only other thing I can think of would be, possibly, some sort of cronjob root has (either crontab -l or /etc/crontab) which makes use of the MAILTO environment variable. See cron(8) for what I'm talking about. You might have to run cron in debug mode (see -x flag; your argument list will probably be quite long :-) ) to see what it's doing. Otherwise truss or ktrace might be the only way to track down what's going on underneath. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cron output mail lost with update to RELENG_7
Date: Fri, 5 Mar 2010 14:29:32 -0600 From: Adam Vande More amvandem...@gmail.com On Fri, Mar 5, 2010 at 1:32 PM, Kevin Oberman ober...@es.net wrote: I have discovered a problem with the mail sent by cron jobs (I refer only to logs, not invocations of mail from scripts.) They never are delivered. Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header This showed up when I upgraded the system to RELENG_7 yesterday. My previous install was RELENG_7 of May 2, 2009 and it delivered the logs without any problems. No other changes were made. postfix was 2.6.5. I have this same issue on all 8.0 systems I have, but I was blaming a fault in postfix config. Now I realize that this is not the problem. I really don't know quite where to look for this. Any clues would be appreciated. Just a guess, but have you tried running newaliases after the update? Are you sure mergemaster completed successfully? Yes to both. I have also checked the aliases and mailer.conf files and they are correct. But thanks for the suggestions. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mbuf leakage with nfs/zfs?
On Fri, 5 Mar 2010, Daniel Braniss wrote:
On Tue, 2 Mar 2010, Daniel Braniss wrote:
just keep sending insights/pointers and enjoy life
You could try this patch for sys/rpc/replay.c. Completely untested and
just typed into email (so don't give it to patch, just edit the file).
- try adding these 2 lines just before the end of replay_setreply() in
sys/rpc/replay.c:
- }
+ } else if (m)
+ m_freem(m);
mtx_unlock(rc-rc_lock);
}
It's the only place I can see in replay.c that might leak, rick
this is what I did:
--- a/sys/rpc/replay.c Mon Mar 01 18:29:54 2010 +0200
+++ b/sys/rpc/replay.c Fri Mar 05 09:24:17 2010 +0200
@@ -243,6 +243,9 @@
rce-rce_repbody = m;
if (m)
rc-rc_size += m_length(m, NULL);
+ } else if (m) {
+printf(free m=%p ...\n, m);
+m_freem(m);
}
mtx_unlock(rc-rc_lock);
}
but it didn't help, it's not triggered
Hmm, well that's the only place I could see in replay.c that could leak
(and it's a pretty straightforward piece of code). This is getting
interesting. Just to confirm where we currently are...
- replay cache disabled -- no leak
- replay cache enabled (with or without the above patch) -- leak
I'll take another look, but I doubt the leak is in replay.c so... maybe
a reply from the cache is somehow handled incorrectly and that causes the
leak elsewhere? (Just a random hunch at this point.)
Thanks for the explanation on the cache, things are begining to make sense.
If I understand, the reason for this cache is to prevent re-applying an
already performed rpc, which could lead to data corruption
Yep, you've got it. It is basically a bandaid for the poor transport
semantics provided by UDP.
Having fun with this one. Thanks for the help, rick
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cron output mail lost with update to RELENG_7
On Fri, 5 Mar 2010, Kevin Oberman wrote: Date: Fri, 5 Mar 2010 14:29:32 -0600 From: Adam Vande More amvandem...@gmail.com On Fri, Mar 5, 2010 at 1:32 PM, Kevin Oberman ober...@es.net wrote: I have discovered a problem with the mail sent by cron jobs (I refer only to logs, not invocations of mail from scripts.) They never are delivered. Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:32:30 noc5 postfix/sendmail[1175]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header Mar 5 10:37:00 noc5 postfix/sendmail[1268]: fatal: root(0): No recipient addresses found in message header This showed up when I upgraded the system to RELENG_7 yesterday. My previous install was RELENG_7 of May 2, 2009 and it delivered the logs without any problems. No other changes were made. postfix was 2.6.5. I have this same issue on all 8.0 systems I have, but I was blaming a fault in postfix config. Now I realize that this is not the problem. I really don't know quite where to look for this. Any clues would be appreciated. Just a guess, but have you tried running newaliases after the update? Are you sure mergemaster completed successfully? Yes to both. I have also checked the aliases and mailer.conf files and they are correct. Maybe deinstall/reinstall postfix with the idea that the base sendmail build overwrote something set up by the postfix port? -Warren Block * Rapid City, South Dakota USA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
em(4) interface hangs under 8.0-RELEASE
I'm still having a problem where an em(4) interface mysteriously hangs and mostly stops sending/receiving packets until I issue an ifconfig emX down followed by an ifconfig emX up, which fixes the problem for some amount of time. Traffic on the interface is about a consistent 3mb/s. One interesting thing to note is that if I tcpdump the interface during the hang, I sometimes see a portion of the expected packets, usually only outbound. I've tried compiling a custom 8.0-RELEASE kernel with the em(4) driver (sys/dev/e1000) from 7.2-RELEASE as well as the same from cvs HEAD. Neither seem to fix the problem. I've also tried, as suggested in a previous thread, disabling TSO, TXCSUM, RXCSUM via the following: sysctl net.inet.tcp.tso=0 ifconfig em1 -tso -txcsum ifconfig em1 down ifconfig em1 up Relevant ifconfig and pciconf dump below. There are no attached VLAN interfaces. em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=98VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:ca:a7:b7 inet 172.31.1.3 netmask 0xfff8 broadcast 172.31.1.7 media: Ethernet autoselect (1000baseT full-duplex) status: active e...@pci0:2:2:1: class=0x02 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 05[f0] = MSI supports 1 message, 64 bit Any suggestions are greatly appreciated. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em(4) interface hangs under 8.0-RELEASE
Its using MSI? Given that its PCI-X I have no idea how robust MSI is, how bout you compile it with that disabled, use legacy IRQ and see if that makes any diff. Using TSO on anything pre-PCI Express is a bad idea, probably why its gotten a bad rep in the em driver. I have a driver in the works that is going to seperate the code for PCIE and Legacy, and I'm ripping out TSO from the Legacy stuff. The hang could be an problem with MSI though. I am not as dubious about the checksum offloads as some are, have stress tests that run for days with no issues. Let me know if that has any effect, Jack On Fri, Mar 5, 2010 at 4:48 PM, Nick Rogers ncrog...@gmail.com wrote: I'm still having a problem where an em(4) interface mysteriously hangs and mostly stops sending/receiving packets until I issue an ifconfig emX down followed by an ifconfig emX up, which fixes the problem for some amount of time. Traffic on the interface is about a consistent 3mb/s. One interesting thing to note is that if I tcpdump the interface during the hang, I sometimes see a portion of the expected packets, usually only outbound. I've tried compiling a custom 8.0-RELEASE kernel with the em(4) driver (sys/dev/e1000) from 7.2-RELEASE as well as the same from cvs HEAD. Neither seem to fix the problem. I've also tried, as suggested in a previous thread, disabling TSO, TXCSUM, RXCSUM via the following: sysctl net.inet.tcp.tso=0 ifconfig em1 -tso -txcsum ifconfig em1 down ifconfig em1 up Relevant ifconfig and pciconf dump below. There are no attached VLAN interfaces. em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=98VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:ca:a7:b7 inet 172.31.1.3 netmask 0xfff8 broadcast 172.31.1.7 media: Ethernet autoselect (1000baseT full-duplex) status: active e...@pci0:2:2:1: class=0x02 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 05[f0] = MSI supports 1 message, 64 bit Any suggestions are greatly appreciated. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
usr/sbin/service False positives
Hi Doug, FreeBSD 7.3-STABLE i386 r204701 Ive been getting the following (below sig) false positives from logcheck recently (moreso log/messages) from service(8). Is there any way that this could be worked around? This messages happen after a reboot and I am presuming that it might be because of the user of -i to env but I am unsure at this point and wanted to give a heads-up before 7.3-RELEASE. These services had never given warnings to messages before the use of service(8). # grep WARNING: /var/log/messages Regards, -- jhell -- Forwarded message -- Date: Mon, 1 Mar 2010 10:02:11 Subject: centel 2010-03-01 10:02 Security Events System Events =-=-=-=-=-=-= Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $idled_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $mpd_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $mysql_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $racoon_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $samba_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $snmpd_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $snmptrapd_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $snort_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $socks5_enable is not set properly - see rc.conf(5). Mar 1 09:12:47 centel jhell: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $apache22_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $asterisk_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $avahi_daemon_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $avahi_dnsconfd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $ddclient_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $dictd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $dovecot_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $ffserver_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $flow_capture_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $flow_fanout_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $git_daemon_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $hald_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $miniupnpd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $openbgpd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $openospfd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Mar 1 09:12:48 centel jhell: /usr/sbin/service: WARNING: $spamd_enable is not set properly - see rc.conf(5). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: usr/sbin/service False positives
On 3/5/2010 9:26 PM, jhell wrote: Hi Doug, FreeBSD 7.3-STABLE i386 r204701 Ive been getting the following (below sig) false positives from logcheck recently (moreso log/messages) from service(8). Is there any way that this could be worked around? This messages happen after a reboot and I am presuming that it might be because of the user of -i to env but I am unsure at this point and wanted to give a heads-up before 7.3-RELEASE. These services had never given warnings to messages before the use of service(8). I don't understand, how are you using the service command? It's not used by anything in the system, it's just a command line tool for administrators. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: usr/sbin/service False positives
On Sat, 6 Mar 2010 00:36, dougb@ wrote: On 3/5/2010 9:26 PM, jhell wrote: Hi Doug, FreeBSD 7.3-STABLE i386 r204701 Ive been getting the following (below sig) false positives from logcheck recently (moreso log/messages) from service(8). Is there any way that this could be worked around? This messages happen after a reboot and I am presuming that it might be because of the user of -i to env but I am unsure at this point and wanted to give a heads-up before 7.3-RELEASE. These services had never given warnings to messages before the use of service(8). I don't understand, how are you using the service command? It's not used by anything in the system, it's just a command line tool for administrators. Doug Ugh! Please ignore any message coming from me in the next 10 minutes ;) I was writing some service checks utilizing periodic about 1 month ago and doing so I was dragging in rc.subr and doing a load_rc_config and that's where the WARNING was coming from. Before I suspended that project for a month I forgot to disable that piece. Sorry for the noise. Thanks anyway, -- jhell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: usr/sbin/service False positives
On 3/5/2010 10:42 PM, jhell wrote: Before I suspended that project for a month I forgot to disable that piece. Sorry for the noise. Ok, no worries. Thanks for confirming in any case. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mbuf leakage with nfs/zfs?
[...] but it didn't help, it's not triggered Hmm, well that's the only place I could see in replay.c that could leak (and it's a pretty straightforward piece of code). This is getting interesting. Just to confirm where we currently are... - replay cache disabled -- no leak - replay cache enabled (with or without the above patch) -- leak yes and yes. I'll take another look, but I doubt the leak is in replay.c so... maybe a reply from the cache is somehow handled incorrectly and that causes the leak elsewhere? (Just a random hunch at this point.) it works ok in 7.2, so it would be interesting to compare changes ... Thanks for the explanation on the cache, things are begining to make sense. If I understand, the reason for this cache is to prevent re-applying an already performed rpc, which could lead to data corruption Yep, you've got it. It is basically a bandaid for the poor transport semantics provided by UDP. Having fun with this one. Thanks for the help, rick I'm glad :-) danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
