From owner-freebsd-net@FreeBSD.ORG Sat Oct 13 13:00:04 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE7A016A419 for ; Sat, 13 Oct 2007 13:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B7BA413C46E for ; Sat, 13 Oct 2007 13:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9DD04bO084075 for ; Sat, 13 Oct 2007 13:00:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l9DD04wu084074; Sat, 13 Oct 2007 13:00:04 GMT (envelope-from gnats) Date: Sat, 13 Oct 2007 13:00:04 GMT Message-Id: <200710131300.l9DD04wu084074@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Adrian Punga" Cc: Subject: Re: kern/109406: [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work with Ndisgen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Punga List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2007 13:00:04 -0000 The following reply was made to PR kern/109406; it has been noted by GNATS. From: "Adrian Punga" To: bug-followup@freebsd.org, darkvincentdude@yahoo.com Cc: Subject: Re: kern/109406: [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work with Ndisgen Date: Sat, 13 Oct 2007 15:58:27 +0300 Without anymore nice ideas I got brutal and identified the call to curthread by classic print-debug and it seems a piece of "goofy" code in kern_ndis.c was calling it: /* * This may look really goofy, but apparently it is possible * to halt a miniport too soon after it's been initialized. * After MiniportInitialize() finishes, pause for 1 second * to give the chip a chance to handle any short-lived timers * that were set in motion. If we call MiniportHalt() too soon, * some of the timers may not be cancelled, because the driver * expects them to fire before the halt is called. */ tsleep(curthread->td_proc, PWAIT, "ndwait", hz); After commenting the tsleep call which seems to affect only some cards I got a little bit further: ndis0: mem 0xf4000000-0xf4003fff irq 17 at device 0.0 on pci16 ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:14:a5:f0:fa:c1 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x20:0xc4362da5 stack pointer = 0x28:0xd53cdaf0 frame pointer = 0x28:0xd53cdaf8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2283 (kldload) trap number = 12 panic: page fault I'm suspecting an uninitialized pointer returned as the current thread in some conditions. Continuing with print-debug ;) as it seems I'm not far from a solution. Adrian Punga