From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753398AbYHLUyo (ORCPT ); Tue, 12 Aug 2008 16:54:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751942AbYHLUyd (ORCPT ); Tue, 12 Aug 2008 16:54:33 -0400 Received: from py-out-1112.google.com ([64.233.166.176]:14237 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243AbYHLUyc (ORCPT ); Tue, 12 Aug 2008 16:54:32 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tF+mbV5joA+ROlpuFXdoLPxBASQdO2TPhr9+rBCEd7UnXWNj0eUFaDHHE+c6SFEATQ sHnbldNzDyZeqS05oLGYG/V4dK2WggwWHkz2b2cKasK6P/GIr8tD3YcAutafD2sZs1fK oFoRc0V166RZoar0slWW4bOs+bQSMbK375+Rs= Message-ID: <19f34abd0808121354n5374b51n88f3c131567c4989@mail.gmail.com> Date: Tue, 12 Aug 2008 22:54:31 +0200 From: "Vegard Nossum" To: "Alexey Dobriyan" Subject: Re: latest -git: kernel hangs when pulling the plug on 8139too Cc: "netdev@vger.kernel.org" , LKML In-Reply-To: <19f34abd0808121346w60f37ac0mf8e4ed20549af0e1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19f34abd0808110949n5d7d363es66325b87a8fb0fd1@mail.gmail.com> <20080811192739.GB5791@martell.zuzino.mipt.ru> <19f34abd0808121020l4a0552a0v3d48b181d980d600@mail.gmail.com> <19f34abd0808121202p6a59917ey561ac48012fb92ca@mail.gmail.com> <19f34abd0808121346w60f37ac0mf8e4ed20549af0e1@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Oops, I spoke a bit too soon. On Tue, Aug 12, 2008 at 10:46 PM, Vegard Nossum wrote: > [] nmi_watchdog_tick+0x1d5/0x1e0 > [] do_nmi+0x97/0x2d0 > [] nmi_stack_correct+0x26/0x2b > [] ? as_remove_queued_request+0x9b/0xb0 > [] ? delay_tsc+0x98/0xb8 > [] __delay+0x9/0x10 > [] _raw_spin_lock+0xb9/0x140 > [] ? trace_hardirqs_off+0xb/0x10 > [] _spin_lock_irqsave+0x76/0x90 > [] ? rtl8139_start_xmit+0x65/0x130 > [] rtl8139_start_xmit+0x65/0x130 Acquires &tp->lock. > [] netpoll_send_skb+0x158/0x1a0 > [] netpoll_send_udp+0x1db/0x1f0 > [] write_msg+0x8c/0xc0 > [] __call_console_drivers+0x53/0x60 > [] _call_console_drivers+0x4b/0x90 > [] release_console_sem+0xc5/0x1f0 > [] vprintk+0x1ab/0x3e0 > [] ? _spin_unlock_irqrestore+0x6c/0x70 > [] ? __queue_work+0x31/0x40 > [] ? queue_work+0x45/0x50 > [] ? queue_delayed_work+0xf/0x30 > [] ? _spin_unlock_irqrestore+0x43/0x70 > [] ? schedule_delayed_work+0x11/0x20 > [] printk+0x1b/0x20 > [] mii_check_media+0x196/0x1e0 > [] ? _spin_lock+0x5b/0x70 > [] rtl_check_media+0x24/0x30 > [] rtl8139_interrupt+0x42a/0x4a0 Acquires &tp->lock. > [] handle_IRQ_event+0x28/0x70 > [] handle_fasteoi_irq+0x6b/0xe0 > [] do_IRQ+0x48/0xa0 > [] ? trace_hardirqs_off_thunk+0xc/0x18 > [] common_interrupt+0x28/0x30 > [] ? update_wall_time+0x36b/0x7d0 > [] ? mwait_idle+0x3c/0x50 > [] cpu_idle+0x6c/0x120 > [] rest_init+0x62/0x70 > ======================= > <4>---[ end trace 33bf576b6277932f ]--- > > ...this seems to contain at least a little bit of useful information. > > Looks to me like it's quite simply a recursive printk. I don't > understand why the printk code doesn't catch this, though. Nope. It tries to take a lock that is already held. Instead: How can it be solved? Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036