i8042prt PS/2 driver and standby

NTDEV
1

hi

I’m using a modified version of the i8042 PS/2 version and I’m hitting a debug break in the code when I hit the power button to resume from standby.

My guess is that an interrupt is firing without the ISR being connected, based on the call stack below. Note that this is for custom hardware - I’m using a modified version of the i8042 driver, but I made very minimal changes - nothing in the area of power management.

In the driver source code, I notice that interrupts are not disabled (no call to I8xToggleInterrupts(FALSE) ) on S3/D3 but if the interrupts are level triggered, the driver’s ISR is disconnected from the interrupt (IoDisconnectInterrupt).

Can you tell me why interrupts are not being explicitly disabled? Since I doubt this is accidental, is it that interrupts shouldn’t be firing or is it that the OS handles the interrupts (in some default handler) if it does fire? Please enlighten me as to the details on this.

It may be that I’m running into hardware differences from a traditional PS/2 mouse. Maybe for a traditional PS/2 things are powered up and down differently - so you can’t get an interrupt and don’t have to worry about disabling them for D3.

When I hit the power button to resume from standby, I get the following:

Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus+0x4:
80526da8 cc int 3

The callstack:
nt!DbgBreakPointWithStatus+0x4
nt!KeEnterKernelDebugger+0x3f
nt!Kei386EoiHelper+0x627
hal+0xe18
hal!HalBeginSystemInterrupt+0xa4
pci!PciStallForPowerChange+0x77
pci!PciSetPowerManagedDevicePowerState+0xaf
pci!PciPdoSetPowerState+0xc7
pci!PciDispatchIrp+0x88
nt!IoBuildPartialMdl+0xed
nt!PoCallDriver+0x195
ACPI!ACPIDispatchForwardPowerIrp+0x40
ACPI!ACPIDeviceIrpForwardRequest+0x46
ACPI!ACPIDeviceCompleteRequest+0xc5
ACPI!ACPIDEvicePowerProessGenericPhase+0x72
nt!KiDispatchInterrupt+0x35d

thanks!

2

S. Drasnin wrote:

I’m using a modified version of the i8042 PS/2 version and I’m hitting
a debug break in the code when I hit the power button to resume from
standby.

My guess is that an interrupt is firing without the ISR being
connected, based on the call stack below. Note that this is for custom
hardware - I’m using a modified version of the i8042 driver, but I
made very minimal changes - nothing in the area of power management.

Would this be the driver in which you chose not to use
IoConnectInterrupt and instead modified the IDT directly?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Are you sure it’s even getting into that IoDisconnectInterrupts?
Normally unless you have a micro-channel architecture machine (which no
one does :-), i8042 interrupts are edge-triggered…

Try turning on the noise debug output.

Oh, and as Tim said, if you’re messing with the IDT yourself, all bets
are off.

S. Drasnin wrote:

hi

I’m using a modified version of the i8042 PS/2 version and I’m hitting a
debug break in the code when I hit the power button to resume from standby.

My guess is that an interrupt is firing without the ISR being connected,
based on the call stack below. Note that this is for custom hardware -
I’m using a modified version of the i8042 driver, but I made very
minimal changes - nothing in the area of power management.

In the driver source code, I notice that interrupts are not disabled (no
call to I8xToggleInterrupts(FALSE) ) on S3/D3 but if the interrupts are
level triggered, the driver’s ISR is disconnected from the interrupt
(IoDisconnectInterrupt).

Can you tell me why interrupts are not being explicitly disabled? Since
I doubt this is accidental, is it that interrupts shouldn’t be firing or
is it that the OS handles the interrupts (in some default handler) if it
does fire? Please enlighten me as to the details on this.

It may be that I’m running into hardware differences from a traditional
PS/2 mouse. Maybe for a traditional PS/2 things are powered up and down
differently - so you can’t get an interrupt and don’t have to worry
about disabling them for D3.

When I hit the power button to resume from standby, I get the following:

Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus+0x4:
80526da8 cc int 3

The callstack:
nt!DbgBreakPointWithStatus+0x4
nt!KeEnterKernelDebugger+0x3f
nt!Kei386EoiHelper+0x627
hal+0xe18
hal!HalBeginSystemInterrupt+0xa4
pci!PciStallForPowerChange+0x77
pci!PciSetPowerManagedDevicePowerState+0xaf
pci!PciPdoSetPowerState+0xc7
pci!PciDispatchIrp+0x88
nt!IoBuildPartialMdl+0xed
nt!PoCallDriver+0x195
ACPI!ACPIDispatchForwardPowerIrp+0x40
ACPI!ACPIDeviceIrpForwardRequest+0x46
ACPI!ACPIDeviceCompleteRequest+0xc5
ACPI!ACPIDEvicePowerProessGenericPhase+0x72
nt!KiDispatchInterrupt+0x35d

thanks!

–
Ray

4

The interrupts are not turned off b/c on legacy systems who woke on
ps/2, the interrupt needed to be enabled. I don’t see i8042prt in the
callstack below. Is your pseudo ps2 device connected via a PCI card?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Monday, December 12, 2005 5:53 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] i8042prt PS/2 driver and standby

Are you sure it’s even getting into that IoDisconnectInterrupts?
Normally unless you have a micro-channel architecture machine (which no
one does :-), i8042 interrupts are edge-triggered…

Try turning on the noise debug output.

Oh, and as Tim said, if you’re messing with the IDT yourself, all bets
are off.

S. Drasnin wrote:

hi

I’m using a modified version of the i8042 PS/2 version and I’m hitting
a
debug break in the code when I hit the power button to resume from
standby.

My guess is that an interrupt is firing without the ISR being
connected,
based on the call stack below. Note that this is for custom hardware -

I’m using a modified version of the i8042 driver, but I made very
minimal changes - nothing in the area of power management.

In the driver source code, I notice that interrupts are not disabled
(no
call to I8xToggleInterrupts(FALSE) ) on S3/D3 but if the interrupts
are
level triggered, the driver’s ISR is disconnected from the interrupt
(IoDisconnectInterrupt).

Can you tell me why interrupts are not being explicitly disabled?
Since
I doubt this is accidental, is it that interrupts shouldn’t be firing
or
is it that the OS handles the interrupts (in some default handler) if
it
does fire? Please enlighten me as to the details on this.

It may be that I’m running into hardware differences from a
traditional
PS/2 mouse. Maybe for a traditional PS/2 things are powered up and
down
differently - so you can’t get an interrupt and don’t have to worry
about disabling them for D3.

When I hit the power button to resume from standby, I get the
following:

Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus+0x4:
80526da8 cc int 3

The callstack:
nt!DbgBreakPointWithStatus+0x4
nt!KeEnterKernelDebugger+0x3f
nt!Kei386EoiHelper+0x627
hal+0xe18
hal!HalBeginSystemInterrupt+0xa4
pci!PciStallForPowerChange+0x77
pci!PciSetPowerManagedDevicePowerState+0xaf
pci!PciPdoSetPowerState+0xc7
pci!PciDispatchIrp+0x88
nt!IoBuildPartialMdl+0xed
nt!PoCallDriver+0x195
ACPI!ACPIDispatchForwardPowerIrp+0x40
ACPI!ACPIDeviceIrpForwardRequest+0x46
ACPI!ACPIDeviceCompleteRequest+0xc5
ACPI!ACPIDEvicePowerProessGenericPhase+0x72
nt!KiDispatchInterrupt+0x35d

thanks!

–
Ray

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

hi

thanks all for the replies everyone.

Regarding the other emails: What’s an IDT? Is this an x86 register? I didn’t change the driver much - the state machine was ok for me. I only had to do what Doron suggested, which is get rid of the keyboard handling code, since there is no keyboard. It starts up with polling for setup, and then the interrupts kick in - I didn’t make any interrupt-related changes.

I will check on the bus type. I’m not even sure that this is my driver problem - I know the stack doesn’t readily indicate it.
I can also try a checked version of the hal and kernel in the hopes it will give more clues.

Is there a way I can tell what interrupt fired when I’m at that DebugBreak()? Perhaps by looking at some register value? Or turning on some debug level before going into suspend?

Do you have an idea as to what would cause the DebugBreak() - is it typically because there isn’t an ISR connected to the interrupt that fired?

thanks in advance

----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Monday, December 12, 2005 9:10 PM
Subject: RE: [ntdev] i8042prt PS/2 driver and standby

The interrupts are not turned off b/c on legacy systems who woke on
ps/2, the interrupt needed to be enabled. I don’t see i8042prt in the
callstack below. Is your pseudo ps2 device connected via a PCI card?

d

-----Original Message-----
From: xxxxx@lists.osr.commailto:xxxxx
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Monday, December 12, 2005 5:53 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] i8042prt PS/2 driver and standby

Are you sure it’s even getting into that IoDisconnectInterrupts?
Normally unless you have a micro-channel architecture machine (which no
one does :-), i8042 interrupts are edge-triggered…

Try turning on the noise debug output.

Oh, and as Tim said, if you’re messing with the IDT yourself, all bets
are off.

S. Drasnin wrote:
> hi
>
> I’m using a modified version of the i8042 PS/2 version and I’m hitting
a
> debug break in the code when I hit the power button to resume from
standby.
>
> My guess is that an interrupt is firing without the ISR being
connected,
> based on the call stack below. Note that this is for custom hardware -

> I’m using a modified version of the i8042 driver, but I made very
> minimal changes - nothing in the area of power management.
>
> In the driver source code, I notice that interrupts are not disabled
(no
> call to I8xToggleInterrupts(FALSE) ) on S3/D3 but if the interrupts
are
> level triggered, the driver’s ISR is disconnected from the interrupt
> (IoDisconnectInterrupt).
>
> Can you tell me why interrupts are not being explicitly disabled?
Since
> I doubt this is accidental, is it that interrupts shouldn’t be firing
or
> is it that the OS handles the interrupts (in some default handler) if
it
> does fire? Please enlighten me as to the details on this.
>
> It may be that I’m running into hardware differences from a
traditional
> PS/2 mouse. Maybe for a traditional PS/2 things are powered up and
down
> differently - so you can’t get an interrupt and don’t have to worry
> about disabling them for D3.
>
> When I hit the power button to resume from standby, I get the
following:
>
> Break instruction exception - code 80000003 (first chance)
> nt!DbgBreakPointWithStatus+0x4:
> 80526da8 cc int 3
>
> The callstack:
> nt!DbgBreakPointWithStatus+0x4
> nt!KeEnterKernelDebugger+0x3f
> nt!Kei386EoiHelper+0x627
> hal+0xe18
> hal!HalBeginSystemInterrupt+0xa4
> pci!PciStallForPowerChange+0x77
> pci!PciSetPowerManagedDevicePowerState+0xaf
> pci!PciPdoSetPowerState+0xc7
> pci!PciDispatchIrp+0x88
> nt!IoBuildPartialMdl+0xed
> nt!PoCallDriver+0x195
> ACPI!ACPIDispatchForwardPowerIrp+0x40
> ACPI!ACPIDeviceIrpForwardRequest+0x46
> ACPI!ACPIDeviceCompleteRequest+0xc5
> ACPI!ACPIDEvicePowerProessGenericPhase+0x72
> nt!KiDispatchInterrupt+0x35d
>
> thanks!
>
>
>
>
>
>
>
>

–
Ray

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256http:

You are currently subscribed to ntdev as: xxxxx@microsoft.commailto:xxxxx
To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx</mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

6

S. Drasnin wrote:

Regarding the other emails: What’s an IDT? Is this an x86 register? I
didn’t change the driver much - the state machine was ok for me. I
only had to do what Doron suggested, which is get rid of the keyboard
handling code, since there is no keyboard. It starts up with polling
for setup, and then the interrupts kick in - I didn’t make any
interrupt-related changes.

My mistake. There was a conversation on one of the kernel groups from a
fellow who was bypassing the normal NT interrupt scheme and changing the
interrupt table himself. I thought you might have been he, but I was wrong.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.