Re: NDIS/UMA related panic

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?

-- 
Maxim Maximov