Date: Sat, 16 May 1998 09:08:53 +0300 (EEST) From: Heikki Suonsivu <hsu@clinet.fi> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: kern/6651: Possible NFS deadlock clue Message-ID: <199805160608.JAA26766@katiska.clinet.fi>
next in thread | raw e-mail | index | archive | help
>Number: 6651 >Category: kern >Synopsis: Possible NFS deadlock clue >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri May 15 23:10:00 PDT 1998 >Last-Modified: >Originator: Heikki Suonsivu >Organization: Clinet, Espoo, Finland >Release: FreeBSD 2.2.6-STABLE i386 >Environment: NFS disks mounted back and forth. Probably any -STABLE. >Description: NFS tends to cause computers to deadlock, ie. responds to ping, often serves NFS requests (if an NFS server, not necessary), on console pressing return to login prompt gives you a new line but no "password:" query. We have had problems with servers deadlocking for ages, but this might be a clue, as I think I found a way repeat the problem. >How-To-Repeat: Take NFS client A and NFS server B. Have systems up and do some access from A to B, and while doing that, add ipfw add xxx deny log udp from A to B 2049 ie. deny all NFS traffic, but leave other NFS related ports open. Wait for a minute or so, then remove the ipfw rule. Now NFS client should awake, more or less in limited time. Instead, the hole client gets completely deadlocked, no new processes get started etcetc. I do not think this happens if all NFS services are closed simultaneously, so closing nfsd port 2049 and leaving other servives open might have something to do with this. I'm not sure about time delay required to produce the problem, it could be that it could be short. If this was also the cause of the other deadlocks, it might be that certain sequence of packets lost because of overload would wake this up, and that would explain occasional deadlocks. Incidentally the deadlocks became rarer when we went to 100 Mbps switched network. If you can't reproduce this, add the ipfw rule to client instead of the server and retry. >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805160608.JAA26766>