From owner-freebsd-current@FreeBSD.ORG Tue Feb 20 01:47:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93F8E1712A1 for ; Tue, 20 Feb 2007 01:47:55 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACAD13C441 for ; Tue, 20 Feb 2007 01:47:55 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2077364nzh for ; Mon, 19 Feb 2007 17:47:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent; b=S6AnhXPI0yoMazN+HFBuuTg6xyFq1XDFiK5KkV5YukoYUHN4+RtS4yIbtDxO3QG6KR6u9YZ8P/aPoYdWxjYfAA8alKyQnAhMi87qqhtIrr92k/AJbliGjzczFW2+0FNVy61On/QFCAnnyyrsCS64Xz5oUPeiCSWB+wniAYf1ksA= Received: by 10.35.38.17 with SMTP id q17mr15370143pyj.1171936074758; Mon, 19 Feb 2007 17:47:54 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 39sm39535450nzk.2007.02.19.17.47.51; Mon, 19 Feb 2007 17:47:53 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l1K1jdb3002165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Feb 2007 10:45:40 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l1K1jafw002164; Tue, 20 Feb 2007 10:45:36 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 20 Feb 2007 10:45:35 +0900 From: Pyun YongHyeon To: "Andrey V. Elsukov" Message-ID: <20070220014535.GC912@cdnetworks.co.kr> References: <20070110120731.GA1515@shark.localdomain> <20070210171130.D47107@maildrop.int.zabbadoz.net> <45D98B62.1060402@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45D98B62.1060402@yandex.ru> User-Agent: Mutt/1.4.2.1i Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list , Sergey Zaharchenko Subject: Re: nve related LOR triggered by lots of small packets, and a hard hang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 01:47:55 -0000 On Mon, Feb 19, 2007 at 02:34:58PM +0300, Andrey V. Elsukov wrote: > Bjoern A. Zeeb ¬á¬Ú¬ê¬Ö¬ä: > >>: lock order reversal: > >>: 1st 0xc3629f00 inp (tcpinp) @ > >>/src/usr.src/sys/netinet/tcp_usrreq.c:801 > >>: 2nd 0xc0a9feec tcp (tcp) @ /src/usr.src/sys/netinet/tcp_input.c:626 > > > >I add this with LOR ID 200 to the LOR page: > > http://sources.zabbadoz.net/freebsd/lor.html#200 > Hi, All. > > I have this LOR and deadlock on my notebook with recent CURRENT. > > My hardvare detected with nve(4) as "NVIDIA nForce MCP13 Networking > Adapter": > > nve0: port 0x30b8-0x30bf mem > 0xc0007000-0xc0007fff irq 5 at device 20.0 on pci0 > nve0: Ethernet address 00:90:f5:4f:18:1b > miibus0: on nve0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > nve0: using obsoleted if_watchdog interface > > With nfe(4) as "NVIDIA nForce 430 MCP13 Networking Adapter": > > nfe0: port 0x30b8-0x30bf > mem 0xc0007000-0xc0007fff irq 5 at device 20.0 on pci0 > miibus0: on nfe0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > nfe0: using obsoleted if_watchdog interface > > DDB message: > lock order reversal: > 1st 0xc2ec2480 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:801 > 2nd 0xc07bbc6c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:638 > KDB: stack backtrace: > db_trace_self_wrapper(c06ee408) at db_trace_self_wrapper+0x25 > kdb_backtrace(0,ffffffff,c077d708,c077d730,c072f944,...) at > kdb_backtrace+0x29 > witness_checkorder(c07bbc6c,9,c06fcd51,27e) at witness_checkorder+0x586 > _mtx_lock_flags(c07bbc6c,0,c06fcd51,27e,0,...) at _mtx_lock_flags+0x84 > tcp_input(c2def300,14,c0759b80,835115ac,0,...) at tcp_input+0x432 > ip_input(c2def300) at ip_input+0x5c9 > netisr_dispatch(2,c2def300,0,c2be2000,c2df0800,...) at > netisr_dispatch+0x58 > ether_demux(c2be2000,c2def300,c2def300,c314da10,d3ee075c,...) at > ether_demux+0x28a > ether_input(c2be2000,c2def300,c2b53cd8,0,c31605fb,...) at > ether_input+0x21e > nve_ospacketrx(c2b53c00,d3ee0798,1,0,0,...) at nve_ospacketrx+0xa4 > UpdateReceiveDescRingData(c315fc64,c315fc84,c315fd24,c315fd50,c315fd68,...) > at UpdateReceiveDescRingData+0x2f8 > nve_osalloc(c2b80940,d4152010,c2b53c00,c315fbcc,c315fc64,...) at > nve_osalloc > _end(0,c2c5c008,3065766e,0,0,...) at 0xc2b80900 > _end(c2b80940,d4152010,c2b53c00,c315fbcc,c315fc64,...) at 0xc2af3630 > _end(0,c2c5c008,3065766e,0,0,...) at 0xc2b80900 > < ..too many strings ..> > > db> where > Tracing pid 1045 tid 100068 td 0xc2dea510 > kdb_enter(c06bbc68) at kdb_enter+0x2b > witness_checkorder(c07bbc6c,9,c06fcd51,27e) at witness_checkorder+0x599 > _mtx_lock_flags(c07bbc6c,0,c06fcd51,27e,0,...) at _mtx_lock_flags+0x84 > tcp_input(c2def300,14,c0759b80,835115ac,0,...) at tcp_input+0x432 > ip_input(c2def300) at ip_input+0x5c9 > netisr_dispatch(2,c2def300,0,c2be2000,c2df0800,...) at > netisr_dispatch+0x58 > ether_demux(c2be2000,c2def300,c2def300,c314da10,d3ee075c,...) at > ether_demux+0x28a > ether_input(c2be2000,c2def300,c2b53cd8,0,c31605fb,...) at > ether_input+0x21e > nve_ospacketrx(c2b53c00,d3ee0798,1,0,0,...) at nve_ospacketrx+0xa4 > UpdateReceiveDescRingData(c315fc64,c315fc84,c315fd24,c315fd50,c315fd68,...) > at UpdateReceiveDescRingData+0x2f8 > nve_osalloc(c2b80940,d4152010,c2b53c00,c315fbcc,c315fc64,...) at > nve_osalloc > _end(0,c2c5c008,3065766e,0,0,...) at 0xc2b80900 > _end(c2b80940,d4152010,c2b53c00,c315fbcc,c315fc64,...) at 0xc2af3630 > > < ..too many strings ..> > > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 1045 1043 1043 21 R CPU 0 vsftpd > > db> show allpcpu > Current CPU: 0 > > cpuid = 0 > curthread = 0xc2dea510: pid 1045 "vsftpd" > curpcb = 0xd3ee0d90 > fpcurthread = none > idlethread = 0xc2a14510: pid 10 "idle" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > > db> show locks > exclusive sleep mutex inp (tcpinp) r = 0 (0xc2ec2480) locked @ > /usr/src/sys/netinet/tcp_usrreq.c:801 > > db> show alllocks > Process 1045 (vsftpd) thread 0xc2dea510 (100068) > exclusive sleep mutex inp (tcpinp) r = 0 (0xc2ec2480) locked @ > /usr/src/sys/netinet/tcp_usrreq.c:801 > Process 21 (irq5: nvidia0 nve0) thread 0xc2ac2510 (100023) > exclusive sleep mutex tcp r = 0 (0xc07bbc6c) locked @ > /usr/src/sys/netinet/tcp_input.c:638 > > db> call boot(0) > Waiting (max 60 seconds) for system process `vnlru' to stop...Sleeping > on "suspkt" with the following non-sleepable locks held: > exclusive sleep mutex inp (tcpinp) r = 0 (0xc2ec2480) locked @ > /usr/src/sys/netinet/tcp_usrreq.c:801 > KDB: enter: witness_warn > [thread pid 1045 tid 100068 ] > Stopped at kdb_enter+0x2b: nop > > db> panic > panic: from debugger > Uptime: 7m18s > Physical memory: 434 MB > Dumping 47 MB: 32 16 > Dump complete > > If somebody have interest to help me resolve this problem, i can easy > reproduce this deadlock - the simple downloading of big file (avi > file, for example) from ftp server from my notebook will result deadlock. > > With nfe(4) i don't have this deadlock, but nfe useless for me, he > often displays message "nfe0: watchdog timeout". > Because your dmesg for nfe(4) shows 'obsoleted if_watchdog interface' message I think you've used stock nfe(4) on CURRENT. Try overhauld nfe(4) at the following URL. http://people.freebsd.org/~yongari/nfe/if_nfe.c http://people.freebsd.org/~yongari/nfe/if_nfereg.h http://people.freebsd.org/~yongari/nfe/if_nfevar.h The new nfe(4) has several protections for watchdog timeout errors reported on the driver. One user repored TSO related issues for the new driver so if you encounter strange errors in the new driver please turn off TSO capability(e.g. #ifconfig nfe0 -tso) > -- > WBR, Andrey V. Elsukov -- Regards, Pyun YongHyeon