From owner-freebsd-current@FreeBSD.ORG Fri Jul 21 12:34:16 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C0BF16A4DA for ; Fri, 21 Jul 2006 12:34:16 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id E955443D46 for ; Fri, 21 Jul 2006 12:34:15 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 2B5C124D90 for ; Fri, 21 Jul 2006 14:34:15 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 761DA9B51C for ; Fri, 21 Jul 2006 12:34:48 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 5EC2A405F; Fri, 21 Jul 2006 14:34:48 +0200 (CEST) Date: Fri, 21 Jul 2006 14:34:48 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20060721123448.GV6253@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Subject: em(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 12:34:16 -0000 Hi, I am running a two month old current (dated from May 24), and I am experiencing watchdog timeouts with my em(4) adapter when running some CPU bound workload involving a computational perl script. Unfortunately this bugs occurs very infrequently, I can't trigger it each time I run this job. FWIW, the command line is something like this : % gzip -dc data.gz | perlscript > chewed_data I recompiled em(4) with DEBUG_INIT, DEBUG_IOCTL and DEBUG_HW all set to 1, but it doesn't seem to provide valuable information : % Jul 21 11:17:14 neuneuf kernel: em0: watchdog timeout -- resetting % Jul 21 11:17:14 neuneuf kernel: em_init: begin % Jul 21 11:17:14 neuneuf kernel: em_stop: begin % Jul 21 11:17:14 neuneuf kernel: free_transmit_structures: begin % Jul 21 11:17:14 neuneuf kernel: free_receive_structures: begin % Jul 21 11:17:14 neuneuf kernel: em_init: pba=48K % Jul 21 11:17:14 neuneuf kernel: em_hardware_init: begin % Jul 21 11:17:14 neuneuf kernel: em_initialize_transmit_unit: begin % Jul 21 11:17:14 neuneuf kernel: Base = 1ebf9000, Length = 1000 % Jul 21 11:17:14 neuneuf kernel: % Jul 21 11:17:14 neuneuf kernel: em_set_multi: begin % Jul 21 11:17:14 neuneuf kernel: em_initialize_receive_unit: begin % Jul 21 11:17:14 neuneuf kernel: em0: link state changed to DOWN % Jul 21 11:17:16 neuneuf kernel: em0: link state changed to UP % Jul 21 11:17:16 neuneuf kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) % Jul 21 11:17:16 neuneuf kernel: em_media_status: begin The ship is: % em0@pci3:11:0: class=0x020000 card=0x02871014 chip=0x10138086 rev=0x00 hdr=0x00 % vendor = 'Intel Corporation' % device = '82541EI Gigabit Ethernet Controller (Copper)' % class = network % subclass = ethernet The interrupt is shared with uhci0: % neuneuf:/sys:112# vmstat -i % interrupt total rate % irq1: atkbd0 39216 0 % irq14: ata0 4801030 3 % irq16: em0 uhci0++ 919491852 688 % irq19: uhci1 35141 0 % irq23: ehci0 1 0 % cpu0: timer 2670435076 1999 % Total 3594802316 2692 I can't try DEVICE_POLLING right now since IIRC I should recompile the whole kernel (right now I am using the if_em module so that I can tune the driver without rebooting). Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >