From owner-freebsd-hardware Tue Aug 25 17:21:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA07484 for freebsd-hardware-outgoing; Tue, 25 Aug 1998 17:21:04 -0700 (PDT) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from dingo.cdrom.com (ppp-d3.dialup.hilink.com.au [203.2.144.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA07477 for ; Tue, 25 Aug 1998 17:20:58 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id RAA00891; Tue, 25 Aug 1998 17:17:45 GMT (envelope-from mike@dingo.cdrom.com) Message-Id: <199808251717.RAA00891@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Scott Drassinower cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Intel 100+ troubles In-reply-to: Your message of "Tue, 25 Aug 1998 15:44:46 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Aug 1998 17:17:44 +0000 From: Mike Smith Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > In May I posted about a problem we were (and still are) having with Intel > 100+ cards with 2.2.6. The machines are connected to a Cisco Catalyst > 2916 switch. > > Some NFS operations, on large (200+ megabyte) files or files that are > being constantly updated will simply hang; ps shows them as being in disk > wait state. They never recover and won't die. Running tail, grep, or sz > on one of these files will reproduce the problem almost every time. A > 2.2.6 NFS client reading files from a BSDI 2.1 NFS server also reproduces > the problem. There have been some serious NFS-related fixes subsequent to 2.2.6; it is quite possible that you're seeing the bugs that these addressed rather than a hardware problem. It is useful to add the 'l' flag to ps(1) and see what the hung processes have in their WCHAN field, as this gives more detail than just "disk wait". If you have an opportunity, you might want to build a 2.2.7 kernel and see if you can reproduce the problems. If you don't have the resources to do this in-house, you should be able to ask on the freebsd-stable list for someone to generate a -stable kernel for you to try. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message