Re: CURRENT panics sometimes

Bill Paul wrote:
>>
>>Here it is.
>>
>>ndis0: <ASUS 802.11g Network Adapter> 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