Re: CURRENT panics sometimes

Maxim Maximov wrote:
> Bill Paul wrote:
>>  
>>
>>>> - 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.
> 
>>  
>>
>>>> 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!

Well, loading driver (and whole NDIS) when cold==0 led to the same panic 
on fourth boot.

Third boot was even stranger, when suddenly console stopped printing 
boot messages but continued to load (determined by HDD activity and 
keyboard reactions). I had to press Ctrl-C few times when OS have been 
wating for DNS resolutions. Then it even tried to switch display to 
graphics mode when xdm comes up, but unsuccessful. Just the cursor 
disappeared. After few keypresses it reboots. Display showed nothing.

Please tell me where I should look at in KDB when this happen again? 
Examine some softclock-related struct? Anything else?

-- 
Maxim Maximov