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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev