Re: CURRENT panics sometimes

> > If you want us to give you clues, you have to give _US_ clues.
> > 
> > For example, here are some of the things you didn't bother to say:
> > 
> > - _WHICH_ windows driver are you using with NDIS?
> 
> bcmwl5.sys
> 
> > - _WHAT_ wireless card do you have?
> 
> It presents itself as ASUS 802.11g Network Adapter. Based on Broadcom chip.
> 
> > - Complete dmesg output from your system (note: verbose boot is not
> >   necessary, but _full_ output is necessary, i.e. don't remove things
> >   you think are unimportant)
> 
> 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.

> 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.

> > - 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.
 
> > - 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?
 
> > - What kind of system is this? Laptop? Desktop? Stone knives and bearskins?
> 
> It's laptop ASUS L5 Series.
> 
> > - Is it SMP or UP?
> 
> SMP.

It's an SMP laptop? Really? Wow.
 
> > 
> > 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.

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================