From owner-freebsd-mobile@FreeBSD.ORG Thu Oct 28 04:16:49 2004 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1984E16A4CE; Thu, 28 Oct 2004 04:16:49 +0000 (GMT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 937AE43D53; Thu, 28 Oct 2004 04:16:46 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.1/8.12.9) with ESMTP id i9S4J0IB060498; Wed, 27 Oct 2004 21:19:01 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.1/8.12.9) with ESMTP id i9S4Gjl9044575; Wed, 27 Oct 2004 21:16:45 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.1/8.13.1/Submit) id i9S4GjKZ044574; Wed, 27 Oct 2004 21:16:45 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200410280416.i9S4GjKZ044574@realtime.exit.com> To: mobile@freebsd.org Date: Wed, 27 Oct 2004 21:16:45 -0700 (PDT) X-Copyright0: Copyright 2004 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL119 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: current@freebsd.org Subject: NDISulator crashness. X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: frank@exit.com List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 04:16:49 -0000 I've been using the NDISulator to run my Dell-branded Broadcom wireless card (BCM4309) as that's the only way I can do so. Unfortunately I've been running into a lot of watchdog timeouts and pretty regular crashes. I've been intending to find the time to build a DIAGNOSTIC kernel, set up with a firewire link and gdb and see just what's going on. Well, tonight I did so. The upshot is that NDIS has troubles. I've already entered a PR for the first LOR I encountered; I ran into another as well, between the VM user map mutex and the ntoskrnl dispatch lock but I didn't trace it, just noted it and kept going, because I was really looking for the page fault I had seen at one point. Well, I think I found it. At least I found _one_ page fault; I don't know if it's the only one. This one, at any rate, is in ntoskrnl_wakeup(), called by ntoskrnl_timercall() (which is the same routine with the first LOR). The reason for the page fault is that while the argument is a valid pointer, the region it points to has been zeroed. It should have the right information for a ktimer but on the call to ntoskrnl_wakeup() it has been entirely cleared. I looked but saw nothing obvious that might explain this. At this point I'm too tired to continue but hopefully I can pick it back up later in the week. I just wanted to let people know about my findings so that those more familiar with the code might be nudged into taking a look at it. (Bill? You out there?) It's very clear to me, by the way, that NDIS hasn't ever been run with all the WITNESS and DIAGNOSTIC stuff turned on, since with the diag kernel it hit the first LOR as soon as it turned on the interface and the second pretty quickly thereafter. I would encourage anyone else who might be poking around in that code to turn on all the WITNESS stuff, INVARIANTS _and_ DIAGNOSTIC; I had been running with the first two but tonight was the first time I used the third and it definitely uncovered problems. Anyway, I'm tired and beginning to ramble. I hope this helps someone and, if not, well, I'll get back to it in a day or three. Oh, and NDIS is usable with these bugs, it's just annoying to have the laptop panic every day or two. I expect that from Windows operating systems, not from FreeBSD. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/