Re: boot panic (NDIS, SCHED_ULE?)

Maxim Maximov wrote:
> Maxim Maximov wrote:
> 
>> Hi.
>>
>>     Got boot time panic on fresh CURRENT.
>>     NDIS hardware:
>>
>> 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
>>
>>     Panic:
>> ...
>> Timecounters tick every 1.000 msec
>> kernel trap 12 with interrupts disabled
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 00
>> fault virtual address   = 0x109
>> fault code              = supervisor read, page not present
>> instruction pointer     = 0x20:0xc06a7570
>> stack pointer           = 0x28:0xd5985cbc
>> frame pointer           = 0x28:0xd5985cc4
>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>                         = DPL 0, pres 1, def32 1, gran 1
>> processor eflags        = resume, IOPL = 0
>> current process         = 41 (Windows DPC 1)
>>
>>
>>     Hand transcribed trace, abbreviated:
>>
>>
>> Stopped at kseq_notify+0x94: cmpb 0x109(%edx), %al
> 
> 
> Debugging shows that this is:
> 
>         pcpu = pcpu_find(cpu);
>         td = pcpu->pc_curthread;
>         if (ke->ke_thread->td_priority < td->td_priority ||
> 
>                                        ^^^^^ here.
> 
>             td == pcpu->pc_idlethread) {
>                 td->td_flags |= TDF_NEEDRESCHED;
>                 ipi_selected(1 << cpu, IPI_AST);
>         }
> 
> And %edx holds 'td' pointer, not ke->ke_thread.
> So I wonder could this be sched_ule problem, just being triggered by new 
> NDIS code? I'll try to build sched_4bsd kernel now to see if it disappears.
> 

The panic remains. It has changed of course:

kick_other_cpu
sched_add
setrunqueue
sched_switch
mi_switch
sched_bind
ntoskrnl_dpc_thread
...

But it's still the same: scheduler cannot dereference pcpu->pc_curthread.

cpu1 is not started yet. 'show allpcpu' shows curthread on cpu1 as none, 
so I guess it is just illegal to call sched_bind() so early on boot.

sched_bind() was used in r1.75 of subr_ntoskrnl.c. Should I try to just 
remove this line?


>>
>>  >trace
>> kseq_notify(c1edbb24,1,c09c4520,c1edbb24,c08236bc) ...+0x94
>> sched_bind(c1edb9c0,1) ...+0x62
>> ntoskrnl_dpc_thread(c1f4fc3c,d5985d38,c1f4fc3c,c08236bc,0) ...+0x73
>> fork_exit(c08236bc,c1f4fc3c,d5985d38) ...+0xa4
>> fork_trampoline()
>>
> 
> 
> 


-- 
Maxim Maximov