Timo always says everything is correct. Unfortunately this is not the case.
_disable and setting IRQL to PASSIVE_LEVEL makes no sense whatsoever. You basically hacked the HAL to support a bug in KDBG. Good job. -- Best regards, Alex Ionescu On 2011-11-19, at 6:50 AM, Cameron Gutman wrote: > >> I would like to ask our kernel gurus if this one is correct. >> > > Timo says it is correct. > > Let me also explain the problem that I fixed: > > So basically, I asked Sylvain to help me test a patch for supporting PS/2 > hotplugging. I had added an ASSERT(FALSE) in the ISR when we got the magic > packet that indicated a reconnect. But when that was executed, something very > strange happened. So the assertion was triggered when Value == 0xAA. Then, > after the assertion, it would jump down to the reset code and check Value > again. This time Value == 0x00, yet nothing set Value between the assertion > and the 2nd check. After a closer look, I found that the ISR had actually ran > again AFTER Kdbg was entered via the assertion. The reason was that Kdbg > calls _disable() then lowers the IRQL to PASSIVE_LEVEL. This triggered all > pending software interrupts (APCs, DPCs, and more), which would preempt Kdbg > even while running with interrupts off, which Kdbg obviously did not expect. > Upon discussion with Timo, it appears that the whole software interrupts > thing is basically a hack for the standard PIC. x64, APIC, and other > architectures have no need for this because they use real interrupts instead > of emulated software interrupts. > > Hopefully that clears things up a bit. > > > Regards, > Cameron > _______________________________________________ > Ros-dev mailing list > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
