CURRENT panics sometimes
Maxim Maximov
mcsi at mcsi.pp.ru
Fri Nov 11 08:30:14 PST 2005
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
More information about the freebsd-current
mailing list