Re: NDIS/UMA related panic

Maxim Maximov wrote:
> Brian Fundakowski Feldman wrote:
> 
>> On Wed, Oct 06, 2004 at 07:58:12PM +0400, Maxim Maximov wrote:
>>
>>> Brian Fundakowski Feldman wrote:
>>>
>>>> On Wed, Oct 06, 2004 at 07:04:22PM +0400, Maxim Maximov wrote:
>>>>
>>>>
>>>>> Hello.
>>>>>
>>>>>     System running kernel
>>>>>
>>>>> FreeBSD ultra.domain 6.0-CURRENT FreeBSD 6.0-CURRENT #11: Fri Oct  
>>>>> 1 19:17:59 MSD 2004     
>>>>> mcsi_at_ultra.domain:/usr/obj/usr/src/sys/ULTRA  i386
>>>>>
>>>>>     is sometimes experiencing following panic on boot after ppp 
>>>>> starts     and sends first packet to ndis0 (hand-transcribed):
>>>>>
>>>>> kernel trap 12: page fault
>>>>> db> trace
>>>>> ntoskrnl_queue_dpc(0xdeadc0de, 0, 0, 0, 0xd6b96330) +0x9
>>>>> ntoskrnl_timercall(0xc1fb51f0) +0x7a
>>>>> softclock(0) +0x17a
>>>>> ithread_loop
>>>>> fork_exit
>>>>> fork_trampoline
>>>>>
>>>>>     I'll update kernel and will re-post if the problem continues. 
>>>>> I'm posting this now because I think someone might be interested in 
>>>>> seeing 0xdeadc0de in stack trace.
>>>>
>>>>
>>>>
>>>> That very much looks like an NDIS driver bug.  Did the vendor only 
>>>> provide
>>>> one version to try?
>>>
>>>
>>> Yes. This is ASUS L5G notebook. Driver page with the one and only 
>>> Wireless driver is here: 
>>> http://www.asus.com/support/download/item.aspx?ModelName=L5G
>>>
>>> I'm running NDIS for about 1.5 months. And this panic first happens 
>>> only yesterday, so I thought this is not the driver bug. BTW, 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
>>> ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
>>> ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps
>>>
>>> Full dmesg is at http://mcsi.pp.ru/dmesg.boot
>>>
>>>
>>>> I wouldn't be surprised if NT has kernel code that
>>>> specifically tries to recover from timers going off that were stored in
>>>> memory that got freed (before they went off).
>>>>
>>
>>
>> It could conceivable be related to something this would fix:
>> <URL:http://green.homeunix.org/~green/unfuck-uma.patch>
>>
> 
> It is not. Recent kernel just paniced at the same place. However, 
> 0xdeadc0de changed to 0xdeadc0f2 or close. Are there any places in DDB I 
> should look at when it'll happen again?
> 

To whom it might be interesting (Robert Watson maybe?), commenting 
net.isr.enable=1 in sysctl.conf (thus setting it to default 0) fixed 
this problem for me.

-- 
Maxim Maximov