Subject: Re: 2.6.15.1: persistent nasty hang in sync_page killing NFS
	(ne2k-pci / DP83815-related?), i686/PIII
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Nix <nix@esperi.org.uk>
Cc: linux-kernel@vger.kernel.org, thockin@hockin.org
In-Reply-To: <871wyq3dl3.fsf@amaterasu.srvr.nix>
References: <87fyn8artm.fsf@amaterasu.srvr.nix>
	 <1138499957.8770.91.camel@lade.trondhjem.org>
	 <87slr79knc.fsf@amaterasu.srvr.nix> <8764o23j0s.fsf@amaterasu.srvr.nix>
	 <1138566075.8711.39.camel@lade.trondhjem.org>
	 <871wyq3dl3.fsf@amaterasu.srvr.nix>
Content-Type: text/plain
Date: Sun, 29 Jan 2006 17:02:20 -0500
Message-Id: <1138572140.8711.82.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1016
Lines: 24

On Sun, 2006-01-29 at 21:54 +0000, Nix wrote:
> (and surely if it was just packet loss, we wouldn't see *every* packet
> getting lost, for *hours*, as we saw here? I left five UDP NFS sessions
> frozen on Saturday night, and they were still frozen on Sunday morning,
> several NFS servers sending the same data to the failing client over and
> over every two seconds without fail, and the client seemingly
> disregarding all of it.)

As a general rule of thumb: if tcpdump/ethereal can see the reply on the
client, then the engine socket should see it too. If tcpdump is indeed
seeing those replies, you should check the RPC code by
setting /proc/sys/sunrpc/rpc_debug to 1.

If not, then perhaps you should try the debugging settings on your NIC
driver.

Cheers,
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/