Re: [Bugme-new] [Bug 10767] New: Seg Fault Instead of Swapping

On Wed, 21 May 2008, Brian Vowell wrote:

On 5/21/08, Ilpo Järvinen [off-list ref] wrote:

quoted

On Wed, 21 May 2008, Brian Vowell wrote:

...This TCP warning isn't sign of a problem that would cause corruption of
any kind (and the state inconsistency gets repaired there as well!), we're
debugging this already with couple of other people, so unless you have
some very good reproducer case you'll just have to wait a bit.

I don't mind waiting.  I just thought that since this happened so quickly
after upgrading to the 2.6.25.4 kernel that it might be something that was
related to changes from 2.6.25.3.

It's just due to luck (that's what makes debugging it hard). There isn't 
anything even remotely related changed in 2.6.25.3 -> 2.6.25.4 :-). Of 
course, if you really want to you can always add the debug patch the other 
2539-warning tracking people already use:

  http://marc.info/?l=linux-netdev&m=120972551120080&w=2

It will add some expensive verifications that are run multiple times per 
ACK to validate TCP's internal consistency which is normally just 
"assumed" to be valid due to performance reasons. Please note what I said 
about CONFIG_LOG_BUF_SHIFT there so that the previous disaster doesn't 
repeat itself... :-) Then you just need to occassionally see if it has 
triggered (from kernel logs).

The only thing that I can do in regards to assisting is to provide info
about what triggers the bug and/or provide access to my system to anyone who
wants to take a closer look.

At the time the bug occurred, the system was running two I/O intensive
applications.  The first was the "xfs_fsr" tool to defragment the XFS
filesystem (it was pushing about 25-30MB/sec to the array), and the rtorrent
BitTorrent client, which was pulling down a Fedora ISO at about 25mbps, and
writing to a SATA device, separate from the array where the XFS filesystem
lives.  In the past, I have seen the rtorrent client create oops errors when
running within a Xen VM.  This problem only occurred when the guest domU VM
was running XFS for its root filesystem and the host dom0 that provided the
filestore for the gues was also running XFS.  (Running the guest on ext3
stops the oops errors).  It may or may not be related to this error that I'm
reporting, but considering that the rtorrent app is the same app that was
running at the time of both segfaults and the oops errors, it makes me
suspicious and I thought that I'd mention it.

All other details but torrent are most likely irrelevant, it could be 
that the added load has some significance to window behavior but that's 
not too likely to make difference. More important would be to know with 
which host torrent was communicating at the time of the WARNING, and even 
more importantly, what "special" happened between that host and your host 
in the network. Once that becomes known thing, this will be easy to 
reproduce and it might even be that the fix is then something dead 
obvious.

Just to be clear, the bug that I'm reporting is running on a clean system,
with no Xen installed on it.

Otherwise, it's really like a bug in real life-- a small creature that is
annoying but doesn't really harm anything.

The thing I'm still concerned in this report is the presence of the other 
stacktrace which seemed to not be TCP related. Could you confirm/list all 
the other problems than the WARNING net/ipv4/tcp_input.c:2539(+its 
stacktrace) that you have been seeing. ...I'm saying this because it might 
be worth of pursuing further.

-- 
 i.