From owner-freebsd-net@FreeBSD.ORG Fri Jul 6 19:23:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9D2616A41F for ; Fri, 6 Jul 2007 19:23:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7452C13C48A for ; Fri, 6 Jul 2007 19:23:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I6tOd-000CnZ-HQ for freebsd-net@freebsd.org; Fri, 06 Jul 2007 22:23:24 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l66JN1EA003420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 22:23:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l66JN1Wq048058; Fri, 6 Jul 2007 22:23:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l66JN0ax048057; Fri, 6 Jul 2007 22:23:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 6 Jul 2007 22:23:00 +0300 From: Kostik Belousov To: Alex Keda Message-ID: <20070706192300.GI2200@deviant.kiev.zoral.com.ua> References: <468E5A94.3030509@lissyara.su> <20070706154247.GH2200@deviant.kiev.zoral.com.ua> <468E88BB.2020009@lissyara.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lLbDBsvWahy0xqFJ" Content-Disposition: inline In-Reply-To: <468E88BB.2020009@lissyara.su> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 9596209fecb99bc4db4bd854cc333b75 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1190 [July 06 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-net@freebsd.org Subject: Re: Fatal double fault while copy to NFS filesystems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2007 19:23:26 -0000 --lLbDBsvWahy0xqFJ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 06, 2007 at 10:23:55PM +0400, Alex Keda wrote: > Kostik Belousov =D0=C9=DB=C5=D4: > >On Fri, Jul 06, 2007 at 07:07:00PM +0400, Alex Keda wrote: > > =20 > >>When I copy files to NFS on another host kernel crash: > >>Fatal double fault: > >>eip =3D 0xc07e9e29 > >>esp =3D 0xe31a3000 > >>ebp =3D 0xe31a3000 > >>cpuid =3D 1; apic id =3D 01 > >>panic: double fault > >>cpuid =3D 1 > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>before this, I see on /var/log/messages > >>nve0: device timeout > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>how repeat problem: > >>ussr# df -h > >>Filesystem Size Used Avail Capacity Mounted on > >>/dev/ad0s1a 72G 6.1G 60G 9% / > >>devfs 1.0K 1.0K 0B 100% /dev > >>ussr# dd if=3D/dev/zero of=3Dfile_20mb bs=3D1m count=3D20 > >>ussr# mount 192.168.254.254:/shares /mnt/ > >>ussr# df -h > >>Filesystem Size Used Avail Capacity Mounted on > >>/dev/ad0s1a 72G 6.1G 60G 9% / > >>devfs 1.0K 1.0K 0B 100% /dev > >>192.168.254.254:/shares 271G 179G 89G 67% /mnt > >>ussr# cp file_20mb /mnt/ > >>then, after 3-5 second I see "device timeout", and later, after 5-7=20 > >>seconds - system crash > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>another information - this problem appearance after I upgrade remote=20 > >>machine (6.2-RELEASE-p5), I change CPU from Celeron 466 to PIII 800. > >>interface on remote machine - 3com509b > >>if I slow copy to remote machine (~100kb/s - 10% interface usage) - all= =20 > >>good. System not crash... > >>if I copy from remote machine - all good - system not crash... > >>on logs on remote machine - all clean. > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>3 days ago I upgrade my system to 6.2-RELEASE-p5, but - problem exists.= .. > >> =20 > > > >Double fault issue might be the problem that is fixed in CURRENT/RELENG_= 6. > >To confirm this, ddb backtrace after the panic will be helpful. You will > >need to compile DDB into the kernel, obtain DDB prompt after the panic > >and issue "bt" command. > > =20 > Fatal double fault: > eip =3D 0xc07e8bd9 > esp =3D 0xe3793000 > ebp =3D 0xe3793020 > cpuid =3D 0; apic id =3D 00 > panic:double fault > cpuid =3D 0 > KDB: enter: panic > [thread pid 25 tid 100019] > Stopped at kdb_enter+0x2b:nop >=20 > Tracing pid 25 tid 100019 td 0xc527b600 > kdb_enter(c090f266) at kdb_enter+0x2b > panic(c092d4c9,c092d671,0,0,0,...) at panic+0x127 > dblfault_handler() at dblfault_handler+0x7a > --- trap 0x17, eip =3D 0xc07e88bd9, esp =3D 0xe3793000, ebp =3D 0xe379302= 0 --- > uma_zfree_arg(c1857960,c5718900,0) at uma_zfree_arg+0x21 > m_freem(c5718900,e54ad000,e52ac65c,c543e810,1,...) at m_freem+0x2e > nve_ospackettx(c543e800,e52ac65c,1,e54ad000,0,...) at nve_ospackettx+0x57 > UpdateTransmitDescRingData() at UpdateTransmitDescRingData+0xd3 Is this the full trace ? It seems to be unlikely that this is a problem I thought of. --lLbDBsvWahy0xqFJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGjpaTC3+MBN1Mb4gRAnXmAJ98rCLbvpBli/mbs3HbM1ep8+Mt4ACbBsfh mQQ06EaRWzMubIK1CSDwBsE= =4vko -----END PGP SIGNATURE----- --lLbDBsvWahy0xqFJ--