On Wed, 24 Nov 2004, Ganbold wrote: > At 06:43 PM 11/22/2004, you wrote: > > > > > > > It seems to me the problem is related to network stack and threading. > > > Am I right? How to solve this problem? > > > >I've seen reports of this problem with and without debug.mpsafenet=1, > >which suggests it is a network stack bug but not specific to locking. I've > >also seen reports that disabling TCP SACK will make the problem go away, > >which would be good to confirm. I spent the weekend building up some more > >expertise in TCP and reading a lot of TCP code, and hope to look at this > >problem in more detail today. You may want to try turning off TCP sack > >using net.inet.tcp.sack.enable=0 in sysctl.conf (or loader.conf). > > I turned off TCP sack using net.inet.tcp.sack.enable=0 in sysctl.conf > and it seems like the problem goes away. It is working for more than 20 > hours without any crash. Robert, did you find anything in network stack > code? I'm just curious. I have not yet identified a (the?) bug, although it seems likely that it has to do with the internal TCP state relating to the SACK blocks. What we need right now, I think, is a core dump, preferably on an i386 kernel since our debugging tools work best with that. My recollection, though, is that you're using an amd64 kernel, but there have been reports from others that likely are on i386. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert_at_fledge.watson.org Principal Research Scientist, McAfee ResearchReceived on Wed Nov 24 2004 - 10:14:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:23 UTC