|
Hello,
On Sun, 8 May 2005, Mark de Vries wrote:
> Ran ~8 seconds in debug_level 8:
>
> /var/log# grep delayed kern.log | cut -d':' -f 4- | sort | uniq -c
> 272 IPVS: delayed: refcnt-1=-1 conn.n_control=0
> 1 IPVS: delayed: refcnt-1=-12 conn.n_control=0
> 104 IPVS: delayed: refcnt-1=-2 conn.n_control=0
> 26 IPVS: delayed: refcnt-1=-3 conn.n_control=0
> 8 IPVS: delayed: refcnt-1=-4 conn.n_control=0
> 1 IPVS: delayed: refcnt-1=-5 conn.n_control=0
> 1 IPVS: delayed: refcnt-1=-6 conn.n_control=0
> 1 IPVS: delayed: refcnt-1=-8 conn.n_control=0
> 3184 IPVS: delayed: refcnt-1=0 conn.n_control=0
>
> Well, that's interresting no?!
Yes, thank you!
> So... what's next? I sit back and relax while you go bug hunting?? :)
>
> Seriously, I looked over the code hoping I would find the missing inc or
> whatever... but I'm afraid this is out of my league. But if there is
> anything else you want me to try or do just let me know.
You can try the attached patch. It removes one extra
__ip_vs_conn_put from ip_vs_icmp_xmit. If it fixes the problem, it
means you receive lots of incoming ICMPs from clients. May be
FRAG_NEEDED messages?
> Rgds,
> Mark.
Regards
--
Julian Anastasov <ja@xxxxxx>
icmp_xmit.diff
Description: fix icmp_xmit
|
