> John Baldwin writes: > > On Friday 16 December 2005 03:52 pm, Andrew Gallatin wrote: > > > John Baldwin writes: > > > > On Friday 16 December 2005 11:34 am, Andrew Gallatin wrote: > > > > Looks like an ithread has preempted your driver's start routine. If you > > > > let it run some more and then break into ddb is the same thread (pid 11) > > > > still running? Also, which process is pid 11? > > It looks like the ithread is looping: > > db> show intrcnt > irq4: sio0 1007 > irq14: ata0 33 > irq17: fwohci0 1 > irq18: ndis0 757379 > irq21: ohci0+ 382 > cpu0: timer 1254872 > db> c > [halt - sent] > KDB: enter: Line break on console > [thread pid 76 tid 100049 ] > Stopped at kdb_enter+0x2f: nop > db> show intrcnt > irq4: sio0 1009 > irq14: ata0 33 > irq17: fwohci0 1 > irq18: ndis0 992263 > irq21: ohci0+ 382 > cpu0: timer 1259314 > > > I know the interrupt is actually disabled in the DPC, and > not in the interrupt handler. That's probably the problem. > The DPC is just never getting scheduled, so the interrupt > line is never lowered. Whoa whoa whoa, hold on just a second. Are you telling me your Windows driver code does not ack/mask interrupts in its MiniportISR() routine? If so, you realize that's a violation of the API and you'd never get your driver WHQL'ed thay way (that is assuming the Microsoft Driver Verifier can catch this mistake, and I'm not certain that it can). I'm kind of surprised you can get away with this in Windows at all. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul_at_windriver.com | Wind River Systems ============================================================================= <adamw> you're just BEGGING to face the moose =============================================================================Received on Sat Dec 17 2005 - 05:53:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:49 UTC