21 Nov
2011
21 Nov
'11
8:03 p.m.
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev