From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 16:30:14 2005 Return-Path: X-Original-To: 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 026C416A45F; Fri, 11 Nov 2005 16:30:13 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from portpc-design.spb.ru (portpc-design.spb.ru [81.176.64.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF0D743D49; Fri, 11 Nov 2005 16:30:11 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [85.140.159.13] (ppp85-140-159-13.pppoe.mtu-net.ru [85.140.159.13]) (authenticated bits=0) by portpc-design.spb.ru (8.13.5/8.13.5) with ESMTP id jABGU5Le009165; Fri, 11 Nov 2005 19:30:07 +0300 (MSK) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <4374C705.6070908@mcsi.pp.ru> Date: Fri, 11 Nov 2005 19:29:57 +0300 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051109 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Bill Paul References: <20051110194339.6244116A420@hub.freebsd.org> In-Reply-To: <20051110194339.6244116A420@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on 81.176.64.226 X-Virus-Status: Clean Cc: current@FreeBSD.ORG Subject: Re: CURRENT panics sometimes 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, 11 Nov 2005 16:30:14 -0000 Bill Paul wrote: >> >>Here it is. >> >>ndis0: mem 0xfeaf8000-0xfeaf9fff irq 17 >>at device 2.0 on pci2 >>ndis0: NDIS API version: 5.0 >>ndis0: Ethernet address: 00:0e:a6:c2:00:e4 > > > Hm... driver is a little old. I don't think that should matter much though. They don't have a new one on their download page :( > > >>SMP: AP CPU #1 Launched! >>Trying to mount root from ufs:/dev/ad2s3a >>WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > > > This is a little suspicious. This lasts for a long time already. This issue is known and harmless, as someone said. > > >>>- Did you add your NDIS driver to /boot/loader.conf, or are you loading >>> the driver after the system is running multiuser? >> >>I'm loading it from /boot/loader.conf > > > I would try not doing that for a while. OK, now I don't. First (and only for now) boot is successful. But I noticed, that my /etc/start_if.ndis0 which loads *.ko has been running twice during boot phase. I wonder can this be a reason somehow? # rcorder /etc/rc.d/* > /dev/null rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/newsyslog'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/syslogd'. Exit 1 > > >>>- If you are loading the driver via /boot/loader.conf, did you try >>> _not_ doing that, and loading it afterwards? >> >>No, I didn't. Even if I will do that, why the problem isn't solid? Right >>now and most of the time I'm happy with this driver loaded at boot time. > > > I'm not sure. I'm running an SMP system with a Broadcom PCI card and > haven't run into this myself. Though that's with 6.0-RELEASE, not -current. > (I'm using the same NDIS code that's in -current though.) > > How often does it crash? 1 time of 3. >>>- Is it SMP or UP? >> >>SMP. > > > It's an SMP laptop? Really? Wow. Yeah! But it's just hyperthreaded. I'm running SMP only to help you find more bugs in kernel :) > > >>>When you provide this information, maybe you will get help. >>> >>>NOTE: Windows NDIS drivers assume that by the time you intialize them, >>>the entire OS is up and running, including scheduling and, if present, >>>multiple CPUs. But in FreeBSD, the kernel is running in 'cold start' >>>state when it probes/attaches devices, and not all of the scheduling >>>mechanisms are available yet (for example, you can not msleep() while >>>cold == 1). This means loading your driver via /boot/loader.conf is >>>something of a hit-or-miss proposition: sometimes they don't work right, >>>sometimes they do. To be really safe, you should load them _after_ the >>>system has come up all the way. >>> >>>Unfortunately, it's necessary to initialize the driver briefly in >>>ndis_attach() in order to find out the device's station address. (You >>>can only do it via MiniportQueryInformation(), and that only works after >>>MiniportInitialize() has been called.) >> >>When 'ntpdate' is called during boot process, everything is (or should >>be) initialized I believe. > > > Yes, but MiniportInitialize() has already been called once while cold == 1. > What I'm saying is you have to avoid doing that entirely. Try doing it > by loading bcmwl5_sys.ko after the system has gone multiuser. If the > problem persists, then I'm just full of crap (wouldn't be the first > time) and there's something else going wrong, but I think it bears > investigating. > OK, I'll awake this thread is the problem happens again. Thanks for looking into it! > -Bill -- Maxim Maximov