Fwd: Issue interrupt from kernel space on x64 Windows

[Helder_Daniel]

I also checked for loaded symbols with: !lmi

It seams that Wdf01000.pdb symbols are loaded.

kd> !lmi wdf01000
Loaded Module Info: [wdf01000]
(…)
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
Load Report: public symbols , not source indexed
(…)

It also seams that my driver symbols are also loaded. However the output of
the lmi is different in the remote computer and in the local computer.
For the touchpad.sys driver in the local computer:

0: kd> !lmi touchpad
Loaded Module Info: [touchpad]
(…)
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: NONE - No error - symbol load deferred from symbol
server.
Load Report: no symbols loaded

It says that symbols are not loaded.
However in the local computer I can get the logdump with:

0: kd> !wdflogdump touchpad
(…)There are 74 log entries
— start of log —
111: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000057FFA4A0948 !devobj
0xFFFFFA8005AD9790 entering Power State WdfDevStatePowerWakingDmaEnable
from (…)

In the remote computer !lmi touchpad tells me the symbols are loaded but I
can not get the logdump giving the error mentioned in my previous email.
Here is the output of lmi touchpad in the remote computer:

kd> !lmi touchpad
Loaded Module Info: [touchpad]
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from image header.
C:\Program Files (x86)\Windows
Kits\8.0\Debuggers\x64\sym\touchpad.pdb\699AE22C7EAE49DA9DE2C12270434A421\touchpad.pdb
Compiler: C - front end [17.0 bld 60315] - back end [17.0 bld 60315]
Load Report: private symbols & lines, not source indexed
C:\Program Files (x86)\Windows
Kits\8.0\Debuggers\x64\sym\touchpad.pdb\699AE22C7EAE49DA9DE2C12270434A421\touchpad.pdb

0: kd> !wdflogdump touchpad

On 7 July 2013 19:29, Helder Daniel wrote:

> OK I did it but the log is still inaccessible. I check if the driver is
> loaded with:
> !wdfkd.wdfldr
> (…)
> ImageName Ver WdfGlobals FxGlobals
> ImageAddress ImageSize
> rtc.sys v0.0 0xfffffa801925dea0 0xfffffa801925dd20
> 0xfffff88005fcb000 0x0000b000
> peauth.sys v0.0
>
> It seams to be.
> Previously I was using livekd on a single computer. Now I am using two
> computers The local computer runs the debugger and the remote computer is
> where the driver is being installed.
>
> Maybe there is a problem with symbols path but I can not find what it is.
> I check your blog at:
>
> http://blogs.msdn.com/b/doronh/archive/2006/07/31/684531.aspx#step1
>
> but it seams to be for a different version. I am using WDK 8 on Windows 8.
>
> When I try to dump the log it says:
>
> kd> !wdfkd.wdflogdump rtc
> Trace searchpath is:
>
> Trace format prefix is: %7!u!: %!FUNC! -
> Trying to extract TMF information from -
> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
> Log at fffffa801aad35e0
> Gather log: Please wait, this may take a moment (reading 68635 bytes).
> % read so far …
> warn: The log could not be accessed
> hint: Are the symbols the WDF library available?
> hint: The log is inaccessable after driver unload.
>
> It says it is trying to extract TMF info from:
> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
>
> I checked and the file exists on the local computer.
> Also .chain finds wdfkd DLL:
>
> .chain
> (…)
>
> Extension DLL chain:
> C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\wdfkd:
> image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 02:53:41 2012
> [path: C:\Program Files (x86)\Windows
> Kits\8.0\Debuggers\x64\winext\wdfkd.dll]
> (…)
>
>
> Maybe it is not finding the driver symbols (rtc.pdb).
> I have it in the build directory of the driver package of local computer:
>
> \rtc\x64\Win8Debug\rtc.pdb
>
> And I copy this folder to the remote computer from where driver is
> installed.
>
> Maybe there is a way to set the search symbol path for this directory?
> However when it breaks WinDbg shows the code of the driver at the
> breakpoint (from the local computer):
>
> (…)
> KdPrint ((“–> EvtDeviceD0Exit - moving to %s\n”,
> DbgDevicePowerString(targetState)));
> KdBreakPoint();
> deviceContext = DeviceGetContext(device);
> (…)
>
>
>
>
>
> On 7 July 2013 15:01, Doron Holan wrote:
>
>> Run wdflogdump on the rtc driver while it is still loaded, so put a bp
>> on d0exit() and run it then
>>
>>
>> d
>>
>> Bent from my Phone
>> ------------------------------
>> From: Helder Daniel
>> Sent: 7/7/2013 8:34 AM
>>
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>>
>> On 7 July 2013 12:43, Doron Holan wrote:
>>
>>> Are you creating a WDFINTERRUPT and have an assigned interrupt
>>> resource?
>>>
>> That could cause the power up path to fail. Run
>>>
>>
>> The interrupt IRQ8 was assigned to the windows rtc/cmos driver.
>> But I update it with my driver and rebooted as windows asked so I assume
>> that after reboot IRQ8 is assigned to my driver only.
>> (I did the same for the touchpad an it worked).
>> In device manager listing resources by type it shows IRQ 8 assigned to my
>> driver.
>>
>> Running !wdfkd.wdflogdump rtc (rtc driver) it gives me an error.
>> But ruuning !wdfkd.wdflogdump touchpad (touchpad driver) it gives me a
>> trace list which seams ok.
>> Vlow are the output for both drivers:
>>
>> 1) RTC
>> 0: kd> !wdfkd.wdflogdump rtc
>> warning: could not retreive framework image for client driver rtc
>> Trace searchpath is:
>>
>> Trace format prefix is: %7!u!: %!FUNC! -
>> warning: could not retreive framework image for client driver rtc
>> hint: Are symbols available for this driver?
>> hint: Did you exclude the .sys extension in the drivername parameter?
>>
>> Could not find rtc in wdfldr client list
>>
>>
>>
>> 2) TOUCHPAD
>>
>> 0: kd> !wdfkd.wdflogdump touchpad
>> Trace searchpath is:
>>
>> Trace format prefix is: %7!u!: %!FUNC! -
>> Trying to extract TMF information from -
>> c:\symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb
>> Log at fffffa800957e000
>> Gather log: Please wait, this may take a moment (reading 4024 bytes).
>> % read so far … 10, 20, 30, 100
>> There are 29 log entries
>> — start of log —
>> 1: FxIFRStart - FxIFR logging started
>> 2: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000057FFB591B48 !devobj
>>
> (…)

>
>>
>>
>>
>>
>>
>> Run !wdfkd.wdflogdump (your driver name)
>>>
>>> With correct symbols for ntos, wdf and your driver. You may need to set
>>> the tmf file path as well. That should tell you where the failure is coming
>>> from
>>>
>>> d
>>>
>>> Bent from my Phone
>>> ------------------------------
>>> From: Helder Daniel
>>> Sent: 7/7/2013 5:04 AM
>>>
>>> To: Windows System Software Devs Interest List
>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>>>
>>> On 5 July 2013 17:29, Doron Holan wrote:
>>>
>>>> If you want your ps2 driver to report input, you might as well just use
>>>> the pnpi8042 sample from the vista wdk. It is a lot work to get to that
>>>> point and you will have rewritten the existing sample
>>>>
>>>
>>> I tried to find the vista wdk download but I only find wdk 7 and wdk
>>> 8. I think the vista wdk is version 6 however in my searches I did not find
>>> it. I am continuing to search.
>>>
>>> This means EvtDeviceD0Exit returned failure. Did you trace what you
>>>> returned from this function?
>>>>
>>>
>>> it is returning STATUS_SUCCESS, the code is:
>>>
>>> NTSTATUS rtcEvtDeviceD0Exit(IN WDFDEVICE device, IN
>>> WDF_POWER_DEVICE_STATE targetState) {
>>>
>>> KdPrint ((“–> EvtDeviceD0Exit - moving to %s\n”,
>>> DbgDevicePowerString(targetState)));
>>> //Needed hardware power down here?
>>> KdPrint (( “<– EvtDeviceD0Exit\n”));
>>>
>>> return STATUS_SUCCESS;
>>> }
>>>
>>> When trying to install the driver for the RTC the sequence of call
>>> backs is this:
>>>
>>> <– EvtDevicePrepareHardware
>>> –> EvtDeviceD0Entry - comming from WdfPowerDeviceD3Final
>>> <– EvtDeviceD0Entry
>>> –> EvtDeviceD0Exit - moving to WdfPowerDeviceD3Final
>>> <– EvtDeviceD0Exit
>>> –> EvtDeviceReleaseHardware
>>>
>>> The question is why it runs EvtDeviceD0Exit immediatly after
>>> EvtDeviceD0Entry.
>>> When installing the driver for the touchpad device the call backs are:
>>>
>>> <– EvtDevicePrepareHardware
>>> –> EvtDeviceD0Entry - comming from WdfPowerDeviceD3Final
>>> <– EvtDeviceD0Entry
>>>
>>> and then go into EvtInterruptEnabled and the driver is installed.
>>> Only when uninstalling runs:
>>>
>>> –> EvtDeviceD0Exit - moving to WdfPowerDeviceD3Final
>>> <– EvtDeviceD0Exit
>>> –> EvtDeviceReleaseHardware
>>>
>>> So it seams that for the RTC after trying to install it goes to the
>>> uninstall sequence(or power down).
>>> Maybe there is need to power up the RTC hardware somehow and for the
>>> touchpad it is not required. The touchpad hardware is ps2 i8042. And the
>>> keyboard used is also a ps/2. So maybe the prt8042 driver inits the
>>> hardware when installing the keyboard driver and in the touchpad case the
>>> hardware is already power up.
>>> But in the case of the RTC maybe it is necessary some code to power it
>>> up?
>>> The code of rtcEvtDeviceD0Entry is:
>>>
>>> NTSTATUS rtcEvtDeviceD0Entry(IN WDFDEVICE device, IN
>>> WDF_POWER_DEVICE_STATE previousState) {
>>> KdPrint ((" –> EvtDeviceD0Entry - comming from %s\n",
>>> DbgDevicePowerString(previousState)));
>>> //Needed hardware power up here?
>>> KdPrint ((“<–EvtDeviceD0Entry\n”));
>>> return STATUS_SUCCESS;
>>> }
>>>
>>>
>>>
>>>
>>>> d
>>>>
>>>> Bent from my Phone
>>>> ------------------------------
>>>> From: Helder Daniel
>>>> Sent: 7/5/2013 12:04 PM
>>>>
>>>> To: Windows System Software Devs Interest List
>>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>>>>
>>>> While I am following your notes to implement a touchpad driver (I
>>>> need to find a way to pass info to the system yet, maybe an HID driver do
>>>> the trick. I am looking at it), I also tried to implement an RTC alarm
>>>> driver as well (It was my original goal).
>>>>
>>>> The driver code is essential the same I used for mouse (without the
>>>> mouse hardware init part in EvtInterruptEnable() ).
>>>> I also changed on the inf file the hardware ID to match the RTC/CMOS.
>>>>
>>>> When installing the driver (it is needed to update the cmos/RTC
>>>> driver) a reboot is required to complete install. After reboot the device
>>>> does not work properly:
>>>> In device manager going to the device -> properties it shows in the
>>>> general TAB an error:
>>>>
>>>> This device cannot start. (Code 10)
>>>>
>>>> STATUS_DEVICE_POWER_FAILURE
>>>>
>>>> Tracing the callbacks after EvtDevicePrepareHardware it runs
>>>> EvtDeviceD0Entry and immediatly runs EvtDeviceD0Exit and
>>>> EvtDeviceReleaseHardware.
>>>>
>>>> So it does not start the device properly.
>>>>
>>>>

[Helder_Daniel]

The only difference I can see between local computer (the one that runs the
debugger) and the remote computer is that in the local computer windbg
loads Wdf01000.pdb from another directory.
I found in my symbols directory (on local computer) 2 directories:

C:\Symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb

and

C:\Symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb

When trying to get a log dump from touchpad.sys(my driver) in the local
computer (livekd) it load from:

Trying to extract TMF information from -
c:\symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb

and shows me the dump.
However in the remote computer livekd(or windbg) loads it from the other
directory:

Trying to extract TMF information from -
c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
Log at fffffa801af60460

and gives the error:

Gather log: Please wait, this may take a moment (reading 68635 bytes).
% read so far …
warn: The log could not be accessed
hint: Are the symbols the WDF library available?
hint: The log is inaccessable after driver unload.

I tried to update symbols as described in this thread which reports a
similar problem:

http://www.osronline.com/showThread.cfm?link=237007~

And I have another directory in my symbols dir:

C:\Symbols\Wdf01000.pdb\7F9D3F673FE344CAB7E06E329BBAE5DD1\Wdf01000.pdb

However wdflogdump does not access it. It still access the other 2
directories. One when debugging locally ant the other remotely.
There is anyway to tell wdflogdump to try to get thr tmf file from another
*.pdb file in a specified dir?

Thanks

Helder

On 8 July 2013 11:28, Helder Daniel wrote:

> I also checked for loaded symbols with: !lmi
>
> It seams that Wdf01000.pdb symbols are loaded.
>
> kd> !lmi wdf01000
> Loaded Module Info: [wdf01000]
> (…)
> Symbol Type: PDB - Symbols loaded successfully from symbol server.
>
> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
> Load Report: public symbols , not source indexed
> (…)
>
> It also seams that my driver symbols are also loaded. However the output
> of the lmi is different in the remote computer and in the local computer.
> For the touchpad.sys driver in the local computer:
>
> 0: kd> !lmi touchpad
> Loaded Module Info: [touchpad]
> (…)
> Image Type: MEMORY - Image read successfully from loaded memory.
> Symbol Type: NONE - No error - symbol load deferred from symbol
> server.
> Load Report: no symbols loaded
>
> It says that symbols are not loaded.
> However in the local computer I can get the logdump with:
>
> 0: kd> !wdflogdump touchpad
> (…)There are 74 log entries
> — start of log —
> 111: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000057FFA4A0948 !devobj
> 0xFFFFFA8005AD9790 entering Power State WdfDevStatePowerWakingDmaEnable
> from (…)
>
> In the remote computer !lmi touchpad tells me the symbols are loaded but
> I can not get the logdump giving the error mentioned in my previous email.
> Here is the output of lmi touchpad in the remote computer:
>
> kd> !lmi touchpad
> Loaded Module Info: [touchpad]
> Image Type: MEMORY - Image read successfully from loaded memory.
> Symbol Type: PDB - Symbols loaded successfully from image header.
> C:\Program Files (x86)\Windows
> Kits\8.0\Debuggers\x64\sym\touchpad.pdb\699AE22C7EAE49DA9DE2C12270434A421\touchpad.pdb
> Compiler: C - front end [17.0 bld 60315] - back end [17.0 bld 60315]
> Load Report: private symbols & lines, not source indexed
> C:\Program Files (x86)\Windows
> Kits\8.0\Debuggers\x64\sym\touchpad.pdb\699AE22C7EAE49DA9DE2C12270434A421\touchpad.pdb
>
>
>
> 0: kd> !wdflogdump touchpad
>
> On 7 July 2013 19:29, Helder Daniel wrote:
>
>> OK I did it but the log is still inaccessible. I check if the driver is
>> loaded with:
>> !wdfkd.wdfldr
>> (…)
>> ImageName Ver WdfGlobals FxGlobals
>> ImageAddress ImageSize
>> rtc.sys v0.0 0xfffffa801925dea0 0xfffffa801925dd20
>> 0xfffff88005fcb000 0x0000b000
>> peauth.sys v0.0
>>
>> It seams to be.
>> Previously I was using livekd on a single computer. Now I am using two
>> computers The local computer runs the debugger and the remote computer is
>> where the driver is being installed.
>>
>> Maybe there is a problem with symbols path but I can not find what it is.
>> I check your blog at:
>>
>> http://blogs.msdn.com/b/doronh/archive/2006/07/31/684531.aspx#step1
>>
>> but it seams to be for a different version. I am using WDK 8 on Windows 8.
>>
>> When I try to dump the log it says:
>>
>> kd> !wdfkd.wdflogdump rtc
>> Trace searchpath is:
>>
>> Trace format prefix is: %7!u!: %!FUNC! -
>> Trying to extract TMF information from -
>> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
>> Log at fffffa801aad35e0
>> Gather log: Please wait, this may take a moment (reading 68635 bytes).
>> % read so far …
>> warn: The log could not be accessed
>> hint: Are the symbols the WDF library available?
>> hint: The log is inaccessable after driver unload.
>>
>> It says it is trying to extract TMF info from:
>> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
>>
>> I checked and the file exists on the local computer.
>> Also .chain finds wdfkd DLL:
>>
>> .chain
>> (…)
>>
>> Extension DLL chain:
>> C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\wdfkd:
>> image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 02:53:41 2012
>> [path: C:\Program Files (x86)\Windows
>> Kits\8.0\Debuggers\x64\winext\wdfkd.dll]
>> (…)
>>
>>
>> Maybe it is not finding the driver symbols (rtc.pdb).
>> I have it in the build directory of the driver package of local computer:
>>
>> \rtc\x64\Win8Debug\rtc.pdb
>>
>> And I copy this folder to the remote computer from where driver is
>> installed.
>>
>> Maybe there is a way to set the search symbol path for this directory?
>> However when it breaks WinDbg shows the code of the driver at the
>> breakpoint (from the local computer):
>>
>> (…)
>> KdPrint ((“–> EvtDeviceD0Exit - moving to %s\n”,
>> DbgDevicePowerString(targetState)));
>> KdBreakPoint();
>> deviceContext = DeviceGetContext(device);
>> (…)
>>
>>
>>
>>
>>
>> On 7 July 2013 15:01, Doron Holan wrote:
>>
>>> Run wdflogdump on the rtc driver while it is still loaded, so put a bp
>>> on d0exit() and run it then
>>>
>>>
>>> d
>>>
>>> Bent from my Phone
>>> ------------------------------
>>> From: Helder Daniel
>>> Sent: 7/7/2013 8:34 AM
>>>
>>> To: Windows System Software Devs Interest List
>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>>>
>>> On 7 July 2013 12:43, Doron Holan wrote:
>>>
>>>> Are you creating a WDFINTERRUPT and have an assigned interrupt
>>>> resource?
>>>>
>>> That could cause the power up path to fail. Run
>>>>
>>>
>>> The interrupt IRQ8 was assigned to the windows rtc/cmos driver.
>>> But I update it with my driver and rebooted as windows asked so I assume
>>> that after reboot IRQ8 is assigned to my driver only.
>>> (I did the same for the touchpad an it worked).
>>> In device manager listing resources by type it shows IRQ 8 assigned to
>>> my driver.
>>>
>>> Running !wdfkd.wdflogdump rtc (rtc driver) it gives me an error.
>>> But ruuning !wdfkd.wdflogdump touchpad (touchpad driver) it gives me a
>>> trace list which seams ok.
>>> Vlow are the output for both drivers:
>>>
>>> 1) RTC
>>> 0: kd> !wdfkd.wdflogdump rtc
>>> warning: could not retreive framework image for client driver rtc
>>> Trace searchpath is:
>>>
>>> Trace format prefix is: %7!u!: %!FUNC! -
>>> warning: could not retreive framework image for client driver rtc
>>> hint: Are symbols available for this driver?
>>> hint: Did you exclude the .sys extension in the drivername parameter?
>>>
>>> Could not find rtc in wdfldr client list
>>>
>>>
>>>
>>> 2) TOUCHPAD
>>>
>>> 0: kd> !wdfkd.wdflogdump touchpad
>>> Trace searchpath is:
>>>
>>> Trace format prefix is: %7!u!: %!FUNC! -
>>> Trying to extract TMF information from -
>>> c:\symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb
>>> Log at fffffa800957e000
>>> Gather log: Please wait, this may take a moment (reading 4024 bytes).
>>> % read so far … 10, 20, 30, 100
>>> There are 29 log entries
>>> — start of log —
>>> 1: FxIFRStart - FxIFR logging started
>>> 2: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000057FFB591B48 !devobj
>>>
>> (…)
>
>>
>>>
>>>
>>>
>>>
>>>
>>> Run !wdfkd.wdflogdump (your driver name)
>>>>
>>>> With correct symbols for ntos, wdf and your driver. You may need to set
>>>> the tmf file path as well. That should tell you where the failure is coming
>>>> from
>>>>
>>>> d
>>>>
>>>> Bent from my Phone
>>>> ------------------------------
>>>> From: Helder Daniel
>>>> Sent: 7/7/2013 5:04 AM
>>>>
>>>> To: Windows System Software Devs Interest List
>>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>>>>
>>>> On 5 July 2013 17:29, Doron Holan wrote:
>>>>
>>>>> If you want your ps2 driver to report input, you might as well just
>>>>> use the pnpi8042 sample from the vista wdk. It is a lot work to get to that
>>>>> point and you will have rewritten the existing sample
>>>>>
>>>>
>>>> I tried to find the vista wdk download but I only find wdk 7 and wdk
>>>> 8. I think the vista wdk is version 6 however in my searches I did not find
>>>> it. I am continuing to search.
>>>>
>>>> This means EvtDeviceD0Exit returned failure. Did you trace what
>>>>> you returned from this function?
>>>>>
>>>>
>>>> it is returning STATUS_SUCCESS, the code is:
>>>>
>>>> NTSTATUS rtcEvtDeviceD0Exit(IN WDFDEVICE device, IN
>>>> WDF_POWER_DEVICE_STATE targetState) {
>>>>
>>>> KdPrint ((“–> EvtDeviceD0Exit - moving to %s\n”,
>>>> DbgDevicePowerString(targetState)));
>>>> //Needed hardware power down here?
>>>> KdPrint (( “<– EvtDeviceD0Exit\n”));
>>>>
>>>> return STATUS_SUCCESS;
>>>> }
>>>>
>>>> When trying to install the driver for the RTC the sequence of call
>>>> backs is this:
>>>>
>>>> <– EvtDevicePrepareHardware
>>>> –> EvtDeviceD0Entry - comming from WdfPowerDeviceD3Final
>>>> <– EvtDeviceD0Entry
>>>> –> EvtDeviceD0Exit - moving to WdfPowerDeviceD3Final
>>>> <– EvtDeviceD0Exit
>>>> –> EvtDeviceReleaseHardware
>>>>
>>>> The question is why it runs EvtDeviceD0Exit immediatly after
>>>> EvtDeviceD0Entry.
>>>> When installing the driver for the touchpad device the call backs are:
>>>>
>>>> <– EvtDevicePrepareHardware
>>>> –> EvtDeviceD0Entry - comming from WdfPowerDeviceD3Final
>>>> <– EvtDeviceD0Entry
>>>>
>>>> and then go into EvtInterruptEnabled and the driver is installed.
>>>> Only when uninstalling runs:
>>>>
>>>> –> EvtDeviceD0Exit - moving to WdfPowerDeviceD3Final
>>>> <– EvtDeviceD0Exit
>>>> –> EvtDeviceReleaseHardware
>>>>
>>>> So it seams that for the RTC after trying to install it goes to the
>>>> uninstall sequence(or power down).
>>>> Maybe there is need to power up the RTC hardware somehow and for the
>>>> touchpad it is not required. The touchpad hardware is ps2 i8042. And the
>>>> keyboard used is also a ps/2. So maybe the prt8042 driver inits the
>>>> hardware when installing the keyboard driver and in the touchpad case the
>>>> hardware is already power up.
>>>> But in the case of the RTC maybe it is necessary some code to power it
>>>> up?
>>>> The code of rtcEvtDeviceD0Entry is:
>>>>
>>>> NTSTATUS rtcEvtDeviceD0Entry(IN WDFDEVICE device, IN
>>>> WDF_POWER_DEVICE_STATE previousState) {
>>>> KdPrint ((" –> EvtDeviceD0Entry - comming from %s\n",
>>>> DbgDevicePowerString(previousState)));
>>>> //Needed hardware power up here?
>>>> KdPrint ((“<–EvtDeviceD0Entry\n”));
>>>> return STATUS_SUCCESS;
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>> d
>>>>>
>>>>> Bent from my Phone
>>>>> ------------------------------
>>>>> From: Helder Daniel
>>>>> Sent: 7/5/2013 12:04 PM
>>>>>
>>>>> To: Windows System Software Devs Interest List
>>>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>>>>>
>>>>> While I am following your notes to implement a touchpad driver (I
>>>>> need to find a way to pass info to the system yet, maybe an HID driver do
>>>>> the trick. I am looking at it), I also tried to implement an RTC alarm
>>>>> driver as well (It was my original goal).
>>>>>
>>>>> The driver code is essential the same I used for mouse (without the
>>>>> mouse hardware init part in EvtInterruptEnable() ).
>>>>> I also changed on the inf file the hardware ID to match the RTC/CMOS.
>>>>>
>>>>> When installing the driver (it is needed to update the cmos/RTC
>>>>> driver) a reboot is required to complete install. After reboot the device
>>>>> does not work properly:
>>>>> In device manager going to the device -> properties it shows in the
>>>>> general TAB an error:
>>>>>
>>>>> This device cannot start. (Code 10)
>>>>>
>>>>> STATUS_DEVICE_POWER_FAILURE
>>>>>
>>>>> Tracing the callbacks after EvtDevicePrepareHardware it runs
>>>>> EvtDeviceD0Entry and immediatly runs EvtDeviceD0Exit and
>>>>> EvtDeviceReleaseHardware.
>>>>>
>>>>> So it does not start the device properly.
>>>>>
>>>>>

–
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

[OSR_Community_User]

The problem with symbol sets is that they are often current for the host
machine, but not consistent with the target machine. You should, if
possible, use the Microsoft Symbol Server in your symbol path; that way,
if your host is ever-so-slightly different from the target, the symbol
server will load the symbols for the target machine to its symbol cache.
Have you tried this?
joe

The only difference I can see between local computer (the one that runs
the
debugger) and the remote computer is that in the local computer windbg
loads Wdf01000.pdb from another directory.
I found in my symbols directory (on local computer) 2 directories:

C:\Symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb

and

C:\Symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb

When trying to get a log dump from touchpad.sys(my driver) in the local
computer (livekd) it load from:

Trying to extract TMF information from -
c:\symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb

and shows me the dump.
However in the remote computer livekd(or windbg) loads it from the other
directory:

Trying to extract TMF information from -
c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
Log at fffffa801af60460

and gives the error:

Gather log: Please wait, this may take a moment (reading 68635 bytes).
% read so far …
warn: The log could not be accessed
hint: Are the symbols the WDF library available?
hint: The log is inaccessable after driver unload.

I tried to update symbols as described in this thread which reports a
similar problem:

http://www.osronline.com/showThread.cfm?link=237007~

And I have another directory in my symbols dir:

C:\Symbols\Wdf01000.pdb\7F9D3F673FE344CAB7E06E329BBAE5DD1\Wdf01000.pdb

However wdflogdump does not access it. It still access the other 2
directories. One when debugging locally ant the other remotely.
There is anyway to tell wdflogdump to try to get thr tmf file from another
*.pdb file in a specified dir?

Thanks

Helder

On 8 July 2013 11:28, Helder Daniel wrote:
>
>> I also checked for loaded symbols with: !lmi
>>
>> It seams that Wdf01000.pdb symbols are loaded.
>>
>> kd> !lmi wdf01000
>> Loaded Module Info: [wdf01000]
>> (…)
>> Symbol Type: PDB - Symbols loaded successfully from symbol server.
>>
>> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
>> Load Report: public symbols , not source indexed
>> (…)
>>
>> It also seams that my driver symbols are also loaded. However the output
>> of the lmi is different in the remote computer and in the local
>> computer.
>> For the touchpad.sys driver in the local computer:
>>
>> 0: kd> !lmi touchpad
>> Loaded Module Info: [touchpad]
>> (…)
>> Image Type: MEMORY - Image read successfully from loaded memory.
>> Symbol Type: NONE - No error - symbol load deferred from symbol
>> server.
>> Load Report: no symbols loaded
>>
>> It says that symbols are not loaded.
>> However in the local computer I can get the logdump with:
>>
>> 0: kd> !wdflogdump touchpad
>> (…)There are 74 log entries
>> — start of log —
>> 111: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000057FFA4A0948 !devobj
>> 0xFFFFFA8005AD9790 entering Power State WdfDevStatePowerWakingDmaEnable
>> from (…)
>>
>> In the remote computer !lmi touchpad tells me the symbols are loaded
>> but
>> I can not get the logdump giving the error mentioned in my previous
>> email.
>> Here is the output of lmi touchpad in the remote computer:
>>
>> kd> !lmi touchpad
>> Loaded Module Info: [touchpad]
>> Image Type: MEMORY - Image read successfully from loaded memory.
>> Symbol Type: PDB - Symbols loaded successfully from image
>> header.
>> C:\Program Files (x86)\Windows
>> Kits\8.0\Debuggers\x64\sym\touchpad.pdb\699AE22C7EAE49DA9DE2C12270434A421\touchpad.pdb
>> Compiler: C - front end [17.0 bld 60315] - back end [17.0 bld
>> 60315]
>> Load Report: private symbols & lines, not source indexed
>> C:\Program Files (x86)\Windows
>> Kits\8.0\Debuggers\x64\sym\touchpad.pdb\699AE22C7EAE49DA9DE2C12270434A421\touchpad.pdb
>>
>>
>>
>> 0: kd> !wdflogdump touchpad
>>
>> On 7 July 2013 19:29, Helder Daniel wrote:
>>
>>> OK I did it but the log is still inaccessible. I check if the driver is
>>> loaded with:
>>> !wdfkd.wdfldr
>>> (…)
>>> ImageName Ver WdfGlobals FxGlobals
>>> ImageAddress ImageSize
>>> rtc.sys v0.0 0xfffffa801925dea0 0xfffffa801925dd20
>>> 0xfffff88005fcb000 0x0000b000
>>> peauth.sys v0.0
>>>
>>> It seams to be.
>>> Previously I was using livekd on a single computer. Now I am using two
>>> computers The local computer runs the debugger and the remote computer
>>> is
>>> where the driver is being installed.
>>>
>>> Maybe there is a problem with symbols path but I can not find what it
>>> is.
>>> I check your blog at:
>>>
>>> http://blogs.msdn.com/b/doronh/archive/2006/07/31/684531.aspx#step1
>>>
>>> but it seams to be for a different version. I am using WDK 8 on Windows
>>> 8.
>>>
>>> When I try to dump the log it says:
>>>
>>> kd> !wdfkd.wdflogdump rtc
>>> Trace searchpath is:
>>>
>>> Trace format prefix is: %7!u!: %!FUNC! -
>>> Trying to extract TMF information from -
>>> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
>>> Log at fffffa801aad35e0
>>> Gather log: Please wait, this may take a moment (reading 68635 bytes).
>>> % read so far …
>>> warn: The log could not be accessed
>>> hint: Are the symbols the WDF library available?
>>> hint: The log is inaccessable after driver unload.
>>>
>>> It says it is trying to extract TMF info from:
>>> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
>>>
>>> I checked and the file exists on the local computer.
>>> Also .chain finds wdfkd DLL:
>>>
>>> .chain
>>> (…)
>>>
>>> Extension DLL chain:
>>> C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\wdfkd:
>>> image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 02:53:41 2012
>>> [path: C:\Program Files (x86)\Windows
>>> Kits\8.0\Debuggers\x64\winext\wdfkd.dll]
>>> (…)
>>>
>>>
>>> Maybe it is not finding the driver symbols (rtc.pdb).
>>> I have it in the build directory of the driver package of local
>>> computer:
>>>
>>> \rtc\x64\Win8Debug\rtc.pdb
>>>
>>> And I copy this folder to the remote computer from where driver is
>>> installed.
>>>
>>> Maybe there is a way to set the search symbol path for this directory?
>>> However when it breaks WinDbg shows the code of the driver at the
>>> breakpoint (from the local computer):
>>>
>>> (…)
>>> KdPrint ((“–> EvtDeviceD0Exit - moving to %s\n”,
>>> DbgDevicePowerString(targetState)));
>>> KdBreakPoint();
>>> deviceContext = DeviceGetContext(device);
>>> (…)
>>>
>>>
>>>
>>>
>>>
>>> On 7 July 2013 15:01, Doron Holan wrote:
>>>
>>>> Run wdflogdump on the rtc driver while it is still loaded, so put a
>>>> bp
>>>> on d0exit() and run it then
>>>>
>>>>
>>>> d
>>>>
>>>> Bent from my Phone
>>>> ------------------------------
>>>> From: Helder Daniel
>>>> Sent: 7/7/2013 8:34 AM
>>>>
>>>> To: Windows System Software Devs Interest List
>>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>>>>
>>>> On 7 July 2013 12:43, Doron Holan wrote:
>>>>
>>>>> Are you creating a WDFINTERRUPT and have an assigned interrupt
>>>>> resource?
>>>>>
>>>> That could cause the power up path to fail. Run
>>>>>
>>>>
>>>> The interrupt IRQ8 was assigned to the windows rtc/cmos driver.
>>>> But I update it with my driver and rebooted as windows asked so I
>>>> assume
>>>> that after reboot IRQ8 is assigned to my driver only.
>>>> (I did the same for the touchpad an it worked).
>>>> In device manager listing resources by type it shows IRQ 8 assigned to
>>>> my driver.
>>>>
>>>> Running !wdfkd.wdflogdump rtc (rtc driver) it gives me an error.
>>>> But ruuning !wdfkd.wdflogdump touchpad (touchpad driver) it gives me
>>>> a
>>>> trace list which seams ok.
>>>> Vlow are the output for both drivers:
>>>>
>>>> 1) RTC
>>>> 0: kd> !wdfkd.wdflogdump rtc
>>>> warning: could not retreive framework image for client driver rtc
>>>> Trace searchpath is:
>>>>
>>>> Trace format prefix is: %7!u!: %!FUNC! -
>>>> warning: could not retreive framework image for client driver rtc
>>>> hint: Are symbols available for this driver?
>>>> hint: Did you exclude the .sys extension in the drivername parameter?
>>>>
>>>> Could not find rtc in wdfldr client list
>>>>
>>>>
>>>>
>>>> 2) TOUCHPAD
>>>>
>>>> 0: kd> !wdfkd.wdflogdump touchpad
>>>> Trace searchpath is:
>>>>
>>>> Trace format prefix is: %7!u!: %!FUNC! -
>>>> Trying to extract TMF information from -
>>>> c:\symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb
>>>> Log at fffffa800957e000
>>>> Gather log: Please wait, this may take a moment (reading 4024 bytes).
>>>> % read so far … 10, 20, 30, 100
>>>> There are 29 log entries
>>>> — start of log —
>>>> 1: FxIFRStart - FxIFR logging started
>>>> 2: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000057FFB591B48 !devobj
>>>>
>>> (…)
>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Run !wdfkd.wdflogdump (your driver name)
>>>>>
>>>>> With correct symbols for ntos, wdf and your driver. You may need to
>>>>> set
>>>>> the tmf file path as well. That should tell you where the failure is
>>>>> coming
>>>>> from
>>>>>
>>>>> d
>>>>>
>>>>> Bent from my Phone
>>>>> ------------------------------
>>>>> From: Helder Daniel
>>>>> Sent: 7/7/2013 5:04 AM
>>>>>
>>>>> To: Windows System Software Devs Interest List
>>>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>>>>>
>>>>> On 5 July 2013 17:29, Doron Holan
>>>>> wrote:
>>>>>
>>>>>> If you want your ps2 driver to report input, you might as well just
>>>>>> use the pnpi8042 sample from the vista wdk. It is a lot work to get
>>>>>> to that
>>>>>> point and you will have rewritten the existing sample
>>>>>>
>>>>>
>>>>> I tried to find the vista wdk download but I only find wdk 7 and wdk
>>>>> 8. I think the vista wdk is version 6 however in my searches I did
>>>>> not find
>>>>> it. I am continuing to search.
>>>>>
>>>>> This means EvtDeviceD0Exit returned failure. Did you trace what
>>>>>> you returned from this function?
>>>>>>
>>>>>
>>>>> it is returning STATUS_SUCCESS, the code is:
>>>>>
>>>>> NTSTATUS rtcEvtDeviceD0Exit(IN WDFDEVICE device, IN
>>>>> WDF_POWER_DEVICE_STATE targetState) {
>>>>>
>>>>> KdPrint ((“–> EvtDeviceD0Exit - moving to %s\n”,
>>>>> DbgDevicePowerString(targetState)));
>>>>> //Needed hardware power down here?
>>>>> KdPrint (( “<– EvtDeviceD0Exit\n”));
>>>>>
>>>>> return STATUS_SUCCESS;
>>>>> }
>>>>>
>>>>> When trying to install the driver for the RTC the sequence of call
>>>>> backs is this:
>>>>>
>>>>> <– EvtDevicePrepareHardware
>>>>> –> EvtDeviceD0Entry - comming from WdfPowerDeviceD3Final
>>>>> <– EvtDeviceD0Entry
>>>>> –> EvtDeviceD0Exit - moving to WdfPowerDeviceD3Final
>>>>> <– EvtDeviceD0Exit
>>>>> –> EvtDeviceReleaseHardware
>>>>>
>>>>> The question is why it runs EvtDeviceD0Exit immediatly after
>>>>> EvtDeviceD0Entry.
>>>>> When installing the driver for the touchpad device the call backs
>>>>> are:
>>>>>
>>>>> <– EvtDevicePrepareHardware
>>>>> –> EvtDeviceD0Entry - comming from WdfPowerDeviceD3Final
>>>>> <– EvtDeviceD0Entry
>>>>>
>>>>> and then go into EvtInterruptEnabled and the driver is installed.
>>>>> Only when uninstalling runs:
>>>>>
>>>>> –> EvtDeviceD0Exit - moving to WdfPowerDeviceD3Final
>>>>> <– EvtDeviceD0Exit
>>>>> –> EvtDeviceReleaseHardware
>>>>>
>>>>> So it seams that for the RTC after trying to install it goes to the
>>>>> uninstall sequence(or power down).
>>>>> Maybe there is need to power up the RTC hardware somehow and for the
>>>>> touchpad it is not required. The touchpad hardware is ps2 i8042. And
>>>>> the
>>>>> keyboard used is also a ps/2. So maybe the prt8042 driver inits the
>>>>> hardware when installing the keyboard driver and in the touchpad case
>>>>> the
>>>>> hardware is already power up.
>>>>> But in the case of the RTC maybe it is necessary some code to power
>>>>> it
>>>>> up?
>>>>> The code of rtcEvtDeviceD0Entry is:
>>>>>
>>>>> NTSTATUS rtcEvtDeviceD0Entry(IN WDFDEVICE device, IN
>>>>> WDF_POWER_DEVICE_STATE previousState) {
>>>>> KdPrint ((" –> EvtDeviceD0Entry - comming from %s\n",
>>>>> DbgDevicePowerString(previousState)));
>>>>> //Needed hardware power up here?
>>>>> KdPrint ((“<–EvtDeviceD0Entry\n”));
>>>>> return STATUS_SUCCESS;
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> d
>>>>>>
>>>>>> Bent from my Phone
>>>>>> ------------------------------
>>>>>> From: Helder Daniel
>>>>>> Sent: 7/5/2013 12:04 PM
>>>>>>
>>>>>> To: Windows System Software Devs Interest List
>>>>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64
>>>>>> Windows
>>>>>>
>>>>>> While I am following your notes to implement a touchpad driver (I
>>>>>> need to find a way to pass info to the system yet, maybe an HID
>>>>>> driver do
>>>>>> the trick. I am looking at it), I also tried to implement an RTC
>>>>>> alarm
>>>>>> driver as well (It was my original goal).
>>>>>>
>>>>>> The driver code is essential the same I used for mouse (without the
>>>>>> mouse hardware init part in EvtInterruptEnable() ).
>>>>>> I also changed on the inf file the hardware ID to match the
>>>>>> RTC/CMOS.
>>>>>>
>>>>>> When installing the driver (it is needed to update the cmos/RTC
>>>>>> driver) a reboot is required to complete install. After reboot the
>>>>>> device
>>>>>> does not work properly:
>>>>>> In device manager going to the device -> properties it shows in the
>>>>>> general TAB an error:
>>>>>>
>>>>>> This device cannot start. (Code 10)
>>>>>>
>>>>>> STATUS_DEVICE_POWER_FAILURE
>>>>>>
>>>>>> Tracing the callbacks after EvtDevicePrepareHardware it runs
>>>>>> EvtDeviceD0Entry and immediatly runs EvtDeviceD0Exit and
>>>>>> EvtDeviceReleaseHardware.
>>>>>>
>>>>>> So it does not start the device properly.
>>>>>>
>>>>>>
>
>
> –
> Helder Daniel
> UALG - FCT
> DEEI
>
> http://w3.ualg.pt/~hdaniel
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

[Helder_Daniel]

I think so.

kd> .sympath
Symbol search path is: srv*c:\Symbols*
http://msdl.microsoft.com/download/symbols;srv\*
Expanded Symbol search path is: srv*c:\symbols*
http://msdl.microsoft.com/download/symbols;cache\*;SRV\*http://msdl.microsoft.com/download/symbols

Maybe that why in my symbols directory (on local computer) I have 2
directories with Wdf01000.pdb file(and wdflogdump access a different one
depending on debugging local or remote pc):

C:\Symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb
C:\Symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb

Helder

On 8 July 2013 19:22, wrote:

> The problem with symbol sets is that they are often current for the host
> machine, but not consistent with the target machine. You should, if
> possible, use the Microsoft Symbol Server in your symbol path; that way,
> if your host is ever-so-slightly different from the target, the symbol
> server will load the symbols for the target machine to its symbol cache.
> Have you tried this?
> joe
>
>
> > The only difference I can see between local computer (the one that runs
> > the
> > debugger) and the remote computer is that in the local computer windbg
> > loads Wdf01000.pdb from another directory.
> > I found in my symbols directory (on local computer) 2 directories:
> >
> > C:\Symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb
> >
> > and
> >
> > C:\Symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
> >
> > When trying to get a log dump from touchpad.sys(my driver) in the local
> > computer (livekd) it load from:
> >
> > Trying to extract TMF information from -
> > c:\symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb
> >
> > and shows me the dump.
> > However in the remote computer livekd(or windbg) loads it from the other
> > directory:
> >
> > Trying to extract TMF information from -
> > c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
> > Log at fffffa801af60460
> >
> > and gives the error:
> >
> > Gather log: Please wait, this may take a moment (reading 68635 bytes).
> > % read so far …
> > warn: The log could not be accessed
> > hint: Are the symbols the WDF library available?
> > hint: The log is inaccessable after driver unload.
> >
> > I tried to update symbols as described in this thread which reports a
> > similar problem:
> >
> > http://www.osronline.com/showThread.cfm?link=237007~
> >
> > And I have another directory in my symbols dir:
> >
> >
> > C:\Symbols\Wdf01000.pdb\7F9D3F673FE344CAB7E06E329BBAE5DD1\Wdf01000.pdb
> >
> > However wdflogdump does not access it. It still access the other 2
> > directories. One when debugging locally ant the other remotely.
> > There is anyway to tell wdflogdump to try to get thr tmf file from
> another
> > *.pdb file in a specified dir?
> >
> > Thanks
> >
> > Helder
> >
> > On 8 July 2013 11:28, Helder Daniel wrote:
> >
> >> I also checked for loaded symbols with: !lmi
> >>
> >> It seams that Wdf01000.pdb symbols are loaded.
> >>
> >> kd> !lmi wdf01000
> >> Loaded Module Info: [wdf01000]
> >> (…)
> >> Symbol Type: PDB - Symbols loaded successfully from symbol server.
> >>
> >> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
> >> Load Report: public symbols , not source indexed
> >> (…)
> >>
> >> It also seams that my driver symbols are also loaded. However the output
> >> of the lmi is different in the remote computer and in the local
> >> computer.
> >> For the touchpad.sys driver in the local computer:
> >>
> >> 0: kd> !lmi touchpad
> >> Loaded Module Info: [touchpad]
> >> (…)
> >> Image Type: MEMORY - Image read successfully from loaded memory.
> >> Symbol Type: NONE - No error - symbol load deferred from symbol
> >> server.
> >> Load Report: no symbols loaded
> >>
> >> It says that symbols are not loaded.
> >> However in the local computer I can get the logdump with:
> >>
> >> 0: kd> !wdflogdump touchpad
> >> (…)There are 74 log entries
> >> — start of log —
> >> 111: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000057FFA4A0948 !devobj
> >> 0xFFFFFA8005AD9790 entering Power State WdfDevStatePowerWakingDmaEnable
> >> from (…)
> >>
> >> In the remote computer !lmi touchpad tells me the symbols are loaded
> >> but
> >> I can not get the logdump giving the error mentioned in my previous
> >> email.
> >> Here is the output of lmi touchpad in the remote computer:
> >>
> >> kd> !lmi touchpad
> >> Loaded Module Info: [touchpad]
> >> Image Type: MEMORY - Image read successfully from loaded memory.
> >> Symbol Type: PDB - Symbols loaded successfully from image
> >> header.
> >> C:\Program Files (x86)\Windows
> >>
> Kits\8.0\Debuggers\x64\sym\touchpad.pdb\699AE22C7EAE49DA9DE2C12270434A421\touchpad.pdb
> >> Compiler: C - front end [17.0 bld 60315] - back end [17.0 bld
> >> 60315]
> >> Load Report: private symbols & lines, not source indexed
> >> C:\Program Files (x86)\Windows
> >>
> Kits\8.0\Debuggers\x64\sym\touchpad.pdb\699AE22C7EAE49DA9DE2C12270434A421\touchpad.pdb
> >>
> >>
> >>
> >> 0: kd> !wdflogdump touchpad
> >>
> >> On 7 July 2013 19:29, Helder Daniel wrote:
> >>
> >>> OK I did it but the log is still inaccessible. I check if the driver is
> >>> loaded with:
> >>> !wdfkd.wdfldr
> >>> (…)
> >>> ImageName Ver WdfGlobals FxGlobals
> >>> ImageAddress ImageSize
> >>> rtc.sys v0.0 0xfffffa801925dea0 0xfffffa801925dd20
> >>> 0xfffff88005fcb000 0x0000b000
> >>> peauth.sys v0.0
> >>>
> >>> It seams to be.
> >>> Previously I was using livekd on a single computer. Now I am using two
> >>> computers The local computer runs the debugger and the remote computer
> >>> is
> >>> where the driver is being installed.
> >>>
> >>> Maybe there is a problem with symbols path but I can not find what it
> >>> is.
> >>> I check your blog at:
> >>>
> >>> http://blogs.msdn.com/b/doronh/archive/2006/07/31/684531.aspx#step1
> >>>
> >>> but it seams to be for a different version. I am using WDK 8 on Windows
> >>> 8.
> >>>
> >>> When I try to dump the log it says:
> >>>
> >>> kd> !wdfkd.wdflogdump rtc
> >>> Trace searchpath is:
> >>>
> >>> Trace format prefix is: %7!u!: %!FUNC! -
> >>> Trying to extract TMF information from -
> >>> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
> >>> Log at fffffa801aad35e0
> >>> Gather log: Please wait, this may take a moment (reading 68635 bytes).
> >>> % read so far …
> >>> warn: The log could not be accessed
> >>> hint: Are the symbols the WDF library available?
> >>> hint: The log is inaccessable after driver unload.
> >>>
> >>> It says it is trying to extract TMF info from:
> >>> c:\symbols\Wdf01000.pdb\FABEC58794454D0D9B539B58E2D0A0922\Wdf01000.pdb
> >>>
> >>> I checked and the file exists on the local computer.
> >>> Also .chain finds wdfkd DLL:
> >>>
> >>> .chain
> >>> (…)
> >>>
> >>> Extension DLL chain:
> >>> C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\wdfkd:
> >>> image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 02:53:41 2012
> >>> [path: C:\Program Files (x86)\Windows
> >>> Kits\8.0\Debuggers\x64\winext\wdfkd.dll]
> >>> (…)
> >>>
> >>>
> >>> Maybe it is not finding the driver symbols (rtc.pdb).
> >>> I have it in the build directory of the driver package of local
> >>> computer:
> >>>
> >>> \rtc\x64\Win8Debug\rtc.pdb
> >>>
> >>> And I copy this folder to the remote computer from where driver is
> >>> installed.
> >>>
> >>> Maybe there is a way to set the search symbol path for this directory?
> >>> However when it breaks WinDbg shows the code of the driver at the
> >>> breakpoint (from the local computer):
> >>>
> >>> (…)
> >>> KdPrint ((“–> EvtDeviceD0Exit - moving to %s\n”,
> >>> DbgDevicePowerString(targetState)));
> >>> KdBreakPoint();
> >>> deviceContext = DeviceGetContext(device);
> >>> (…)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 7 July 2013 15:01, Doron Holan wrote:
> >>>
> >>>> Run wdflogdump on the rtc driver while it is still loaded, so put a
> >>>> bp
> >>>> on d0exit() and run it then
> >>>>
> >>>>
> >>>> d
> >>>>
> >>>> Bent from my Phone
> >>>> ------------------------------
> >>>> From: Helder Daniel
> >>>> Sent: 7/7/2013 8:34 AM
> >>>>
> >>>> To: Windows System Software Devs Interest List
> >>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
> >>>>
> >>>> On 7 July 2013 12:43, Doron Holan wrote:
> >>>>
> >>>>> Are you creating a WDFINTERRUPT and have an assigned interrupt
> >>>>> resource?
> >>>>>
> >>>> That could cause the power up path to fail. Run
> >>>>>
> >>>>
> >>>> The interrupt IRQ8 was assigned to the windows rtc/cmos driver.
> >>>> But I update it with my driver and rebooted as windows asked so I
> >>>> assume
> >>>> that after reboot IRQ8 is assigned to my driver only.
> >>>> (I did the same for the touchpad an it worked).
> >>>> In device manager listing resources by type it shows IRQ 8 assigned to
> >>>> my driver.
> >>>>
> >>>> Running !wdfkd.wdflogdump rtc (rtc driver) it gives me an error.
> >>>> But ruuning !wdfkd.wdflogdump touchpad (touchpad driver) it gives me
> >>>> a
> >>>> trace list which seams ok.
> >>>> Vlow are the output for both drivers:
> >>>>
> >>>> 1) RTC
> >>>> 0: kd> !wdfkd.wdflogdump rtc
> >>>> warning: could not retreive framework image for client driver rtc
> >>>> Trace searchpath is:
> >>>>
> >>>> Trace format prefix is: %7!u!: %!FUNC! -
> >>>> warning: could not retreive framework image for client driver rtc
> >>>> hint: Are symbols available for this driver?
> >>>> hint: Did you exclude the .sys extension in the drivername parameter?
> >>>>
> >>>> Could not find rtc in wdfldr client list
> >>>>
> >>>>
> >>>>
> >>>> 2) TOUCHPAD
> >>>>
> >>>> 0: kd> !wdfkd.wdflogdump touchpad
> >>>> Trace searchpath is:
> >>>>
> >>>> Trace format prefix is: %7!u!: %!FUNC! -
> >>>> Trying to extract TMF information from -
> >>>> c:\symbols\Wdf01000.pdb\8F5E6B80E9924A2A8568FF5016979B7A2\Wdf01000.pdb
> >>>> Log at fffffa800957e000
> >>>> Gather log: Please wait, this may take a moment (reading 4024 bytes).
> >>>> % read so far … 10, 20, 30, 100
> >>>> There are 29 log entries
> >>>> — start of log —
> >>>> 1: FxIFRStart - FxIFR logging started
> >>>> 2: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000057FFB591B48 !devobj
> >>>>
> >>> (…)
> >>
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Run !wdfkd.wdflogdump (your driver name)
> >>>>>
> >>>>> With correct symbols for ntos, wdf and your driver. You may need to
> >>>>> set
> >>>>> the tmf file path as well. That should tell you where the failure is
> >>>>> coming
> >>>>> from
> >>>>>
> >>>>> d
> >>>>>
> >>>>> Bent from my Phone
> >>>>> ------------------------------
> >>>>> From: Helder Daniel
> >>>>> Sent: 7/7/2013 5:04 AM
> >>>>>
> >>>>> To: Windows System Software Devs Interest List
> >>>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
> >>>>>
> >>>>> On 5 July 2013 17:29, Doron Holan
> >>>>> wrote:
> >>>>>
> >>>>>> If you want your ps2 driver to report input, you might as well just
> >>>>>> use the pnpi8042 sample from the vista wdk. It is a lot work to get
> >>>>>> to that
> >>>>>> point and you will have rewritten the existing sample
> >>>>>>
> >>>>>
> >>>>> I tried to find the vista wdk download but I only find wdk 7 and wdk
> >>>>> 8. I think the vista wdk is version 6 however in my searches I did
> >>>>> not find
> >>>>> it. I am continuing to search.
> >>>>>
> >>>>> This means EvtDeviceD0Exit returned failure. Did you trace what
> >>>>>> you returned from this function?
> >>>>>>
> >>>>>
> >>>>> it is returning STATUS_SUCCESS, the code is:
> >>>>>
> >>>>> NTSTATUS rtcEvtDeviceD0Exit(IN WDFDEVICE device, IN
> >>>>> WDF_POWER_DEVICE_STATE targetState) {
> >>>>>
> >>>>> KdPrint ((“–> EvtDeviceD0Exit - moving to %s\n”,
> >>>>> DbgDevicePowerString(targetState)));
> >>>>> //Needed hardware power down here?
> >>>>> KdPrint (( “<– EvtDeviceD0Exit\n”));
> >>>>>
> >>>>> return STATUS_SUCCESS;
> >>>>> }
> >>>>>
> >>>>> When trying to install the driver for the RTC the sequence of call
> >>>>> backs is this:
> >>>>>
> >>>>> <– EvtDevicePrepareHardware
> >>>>> –> EvtDeviceD0Entry - comming from WdfPowerDeviceD3Final
> >>>>> <– EvtDeviceD0Entry
> >>>>> –> EvtDeviceD0Exit - moving to WdfPowerDeviceD3Final
> >>>>> <– EvtDeviceD0Exit
> >>>>> –> EvtDeviceReleaseHardware
> >>>>>
> >>>>> The question is why it runs EvtDeviceD0Exit immediatly after
> >>>>> EvtDeviceD0Entry.
> >>>>> When installing the driver for the touchpad device the call backs
> >>>>> are:
> >>>>>
> >>>>> <– EvtDevicePrepareHardware
> >>>>> –> EvtDeviceD0Entry - comming from WdfPowerDeviceD3Final
> >>>>> <– EvtDeviceD0Entry
> >>>>>
> >>>>> and then go into EvtInterruptEnabled and the driver is installed.
> >>>>> Only when uninstalling runs:
> >>>>>
> >>>>> –> EvtDeviceD0Exit - moving to WdfPowerDeviceD3Final
> >>>>> <– EvtDeviceD0Exit
> >>>>> –> EvtDeviceReleaseHardware
> >>>>>
> >>>>> So it seams that for the RTC after trying to install it goes to the
> >>>>> uninstall sequence(or power down).
> >>>>> Maybe there is need to power up the RTC hardware somehow and for the
> >>>>> touchpad it is not required. The touchpad hardware is ps2 i8042. And
> >>>>> the
> >>>>> keyboard used is also a ps/2. So maybe the prt8042 driver inits the
> >>>>> hardware when installing the keyboard driver and in the touchpad case
> >>>>> the
> >>>>> hardware is already power up.
> >>>>> But in the case of the RTC maybe it is necessary some code to power
> >>>>> it
> >>>>> up?
> >>>>> The code of rtcEvtDeviceD0Entry is:
> >>>>>
> >>>>> NTSTATUS rtcEvtDeviceD0Entry(IN WDFDEVICE device, IN
> >>>>> WDF_POWER_DEVICE_STATE previousState) {
> >>>>> KdPrint ((" –> EvtDeviceD0Entry - comming from %s\n",
> >>>>> DbgDevicePowerString(previousState)));
> >>>>> //Needed hardware power up here?
> >>>>> KdPrint ((“<–EvtDeviceD0Entry\n”));
> >>>>> return STATUS_SUCCESS;
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> d
> >>>>>>
> >>>>>> Bent from my Phone
> >>>>>> ------------------------------
> >>>>>> From: Helder Daniel
> >>>>>> Sent: 7/5/2013 12:04 PM
> >>>>>>
> >>>>>> To: Windows System Software Devs Interest List > >
> >>>>>> Subject: Re: [ntdev] Issue interrupt from kernel space on x64
> >>>>>> Windows
> >>>>>>
> >>>>>> While I am following your notes to implement a touchpad driver (I
> >>>>>> need to find a way to pass info to the system yet, maybe an HID
> >>>>>> driver do
> >>>>>> the trick. I am looking at it), I also tried to implement an RTC
> >>>>>> alarm
> >>>>>> driver as well (It was my original goal).
> >>>>>>
> >>>>>> The driver code is essential the same I used for mouse (without the
> >>>>>> mouse hardware init part in EvtInterruptEnable() ).
> >>>>>> I also changed on the inf file the hardware ID to match the
> >>>>>> RTC/CMOS.
> >>>>>>
> >>>>>> When installing the driver (it is needed to update the cmos/RTC
> >>>>>> driver) a reboot is required to complete install. After reboot the
> >>>>>> device
> >>>>>> does not work properly:
> >>>>>> In device manager going to the device -> properties it shows in the
> >>>>>> general TAB an error:
> >>>>>>
> >>>>>> This device cannot start. (Code 10)
> >>>>>>
> >>>>>> STATUS_DEVICE_POWER_FAILURE
> >>>>>>
> >>>>>> Tracing the callbacks after EvtDevicePrepareHardware it runs
> >>>>>> EvtDeviceD0Entry and immediatly runs EvtDeviceD0Exit and
> >>>>>> EvtDeviceReleaseHardware.
> >>>>>>
> >>>>>> So it does not start the device properly.
> >>>>>>
> >>>>>>
> >
> >
> > –
> > Helder Daniel
> > UALG - FCT
> > DEEI
> >
> > http://w3.ualg.pt/~hdaniel
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

–
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

[Helder_Daniel]

Ok that’s fine for mouse motion. No need to queue all mouse packets, just
update mouse state x and y with the cumulative of all packets mouse sent
between read requests.

But what about mouse button action? Let’s say an app needs to count right
mouse clicks.
If we just send to user space the current mouse buttons state and the
cumulative of all x and y movement, all the clicks done between the last
read request and the current are lost.

How can we track button action without storing in a queue (or something
similar) every button action?

On 30 June 2013 21:45, wrote:

Interrupts ARE disabled in the ISR, as I pointed out. You COULD queue the
requests, although you don’t need to do this in the case of a mouse; all
the user is interested in is the cumulative mouse motion between requests.
Thus, if your mouse is giving relative offsets in x,y (as most mice do)
you only need to keep a running total of these, both positive and negative
motions, and you can easily do this using hardware synchronization.

Don’t try to overthink the problem. Look for the simplest solution. A
queue of pending interrupt deltas sounds cool, but is overkill, and not
only not necessary, but inefficient. Inefficient in that if your usermode
code sends in a request to read the current position, and you have queued
up 100 entries indicating 100 x-traversals and maybe 9 y-traversals, the
app has to issue 100 read requests. But if you accumulate the deltas and
return only the current one (which may change a fraction of a nanosecond
later, but who cares?), then those 100 pending requests become only a
single cumulative request. Note that the mouse is unusual in this regard;
many devices require that your app see all the data, but for mouse motion,
it only needs a “snapshot” of the current state.

On 30 June 2013 21:45, wrote:

> The mouse is a case of a device that interrupts whether there is an IRP
> present or not. Therefore, you have to track the information, and when
> there is an IRP, you pass the information back to the caller.
>
> If all you are doing is reading the ports and “storing it in some data
> structure” then indeed you do not need to use a DPC at this point.
>
> If there is an IRP present, you will have to go to a DPC to complete it.
> All EvtIoRead does is dequeue a pending request for an IRP_MJ_READ
> operation and if there is no data (or no changed data) you may wish to
> hold the request until some data arrives/
>
> The mouse may wish to issue more interrupts, but those interrupts are
> blocked by the hardware on the core which is running the ISR, and by the
> ISR spin lock if the interrupt is routed to another core. This is
> built-in behavior and you don’t need to do anything special to get it.
> You don’t need to be disabling mouse interrupts. Note that the “data
> structure” in which you store the mouse information is accessed both at
> DIRQL level and at < DIRQL level, so you will require synchronization (the
> old KeSynchronizeExecution, or however it has been recast into KMDF) so
> you see the data as a single entity. Or, if you are only keeping 16-bit
> mouse coordinates (remember, these are going to represent physical points
> on the screen, so 16 bits will handle massive arrays of displays, wider
> than you are ever likely to see any one machine equipped with; for
> example, at 1600 horizontal pixels on a display, you would need 40
> side-by-side displays to approach the 16-bit limit), you coutd store them
> as a 16-bit pair, and update them using a single InterlockedExchange
> operation, which synchronizes a single, aligned, 32-bit access at the
> hardware level, requiring no software synchronization mechanisms. You
> only need to guarantee that the read of x,y gives you a coherent value,
> not that interrupts be blocked as the sole means of accomplishing this.
> Remember that completing an IRP is a “lengthy” operation compared to the
> potential interrupt rate, so if you just blocked interrupts, you would be
> ignoring mouse input even when you didn’t need to.
>
> Interrupts ARE disabled in the ISR, as I pointed out. You COULD queue the
> requests, although you don’t need to do this in the case of a mouse; all
> the user is interested in is the cumulative mouse motion between requests.
> Thus, if your mouse is giving relative offsets in x,y (as most mice do)
> you only need to keep a running total of these, both positive and negative
> motions, and you can easily do this using hardware synchronization.
>
> Don’t try to overthink the problem. Look for the simplest solution. A
> queue of pending interrupt deltas sounds cool, but is overkill, and not
> only not necessary, but inefficient. Inefficient in that if your usermode
> code sends in a request to read the current position, and you have queued
> up 100 entries indicating 100 x-traversals and maybe 9 y-traversals, the
> app has to issue 100 read requests. But if you accumulate the deltas and
> return only the current one (which may change a fraction of a nanosecond
> later, but who cares?), then those 100 pending requests become only a
> single cumulative request. Note that the mouse is unusual in this regard;
> many devices require that your app see all the data, but for mouse motion,
> it only needs a “snapshot” of the current state.
>
> BTW, you can discover that this is exactly how the current mouse driver
> works. Write an app that, on every mouse-move notification
> (WM_MOUSEMOVE), formats the x,y and places it in a window at the x,y
> position. You will see that if you move the mouse quickly that you might
> get values laid down an inch apart, and if you move slowly, you will get
> values laid down a pixel or two apart. So it is not like you are doing
> anything inconsistent with current mouse behavior. If you don’t like
> formatting the x,y, just draw a + at the current reported mouse
> coordinate. Same effect, somewhat easier to see.
> joe
>
>
> > Ok so let’s say we need to complete a request to read a mouse packet.
> >
> > We can service the interrupt in the ISR, read mouse packet from I/O ports
> > and store it in some data structure. So there is no need for DPC here
> > right?
> >
> > Assuming that some user space code is accessing the driver to get mouse
> > data using read callback we can sent to userspace mouse packet stored by
> > the ISR in the EvtIORead and complete the IRP, right?
> >
> > Now when IRP are being processed mouse may issue other interrupts.
> > What is the right thing to do? Disable mouse interrupts until the IRP is
> > completed? This means disable mouse interrupts at the beginning of the
> ISR
> > and enable them at the end of EvtIORead.
> >
> > Alternatively mouse interrupts could be disabled just during the ISR.
> Each
> > time the ISR runs stores each mouse packet in a queue that will be sent
> to
> > userspace in EvtIOread by arrival order. I think with this approach less
> > mouse data will be lost while interrupts are disabled.
> >
> > The question is what’s the common approach?
> > Probably there’s a better one …
> >
> >
> >
> >
> >
> >
> > On 27 June 2013 23:14, wrote:
> >
> >> DPCs are a general concept, and there is a general DPC calling
> >> mechanism.
> >> However, “registering” a DPC allows you to avoid the complexity of the
> >> fully general call and identify the DPC which you will want to queue up
> >> from the ISR. The call you show below knows the “registered” DPC and
> >> therefore hides a great deal of the gratuitous complexity of the fully
> >> general calling mechanism to make the most common case simple.
> >>
> >> So all registering it does is make the DPC known to this internal
> >> mechanism.
> >>
> >> Note that an ISR does not have to be followed immediately by a DPC. An
> >> ISR has, by modern standards, a HUGE time budget, 10us, which in an
> >> architecture that can issue 6 to 9 instructions per clock cycle, three
> >> clock cycles per nanosecond, this is a LOT of instructions. So, for
> >> example, if the interrupt comes in after a partial transfer, it is
> >> perfectly sensible to initiate the next part of the transfer in the ISR.
> >> As long as this doesn’t require any calls forbidden at DIRQL level, it
> >> is
> >> common practice. You only queue up the DPC when you need to take
> >> actions
> >> that cannot be performed at DIRQL level, such as completing the IRP, or
> >> if
> >> the nature of the device requires more than 10us of computation after an
> >> interrupt. Since the DPC is not required for each interrupt, the choice
> >> to execute the DPC requires an overt action on your part.
> >> joe
> >>
> >>
> >> > Oops!
> >> >
> >> > I thought it was enough to register the DPC.
> >> > After queuing it with:
> >> >
> >> > WdfInterruptQueueDpcForIsr( interrupt );
> >> >
> >> > DPC is called. Thanks
> >> >
> >> > I guess its similar to scheduling Linux bottom halves for execution.
> >> >
> >> >
> >> > On 27 June 2013 19:45, wrote:
> >> >
> >> >> In the ISR, I didn’t see where you requested the DPC. Unless you ask
> >> >> for
> >> >> it, it isn’t going to happen.
> >> >> joe
> >> >>
> >> >> > Hi all,
> >> >> >
> >> >> > Thank for all the suggestions.
> >> >> > The problem was the initialization of the ps/2 mouse hardware
> >> >> (actually
> >> >> > synaptics touchpad).
> >> >> > After fixing it ISR runs as mouse is moved or pressed.
> >> >> >
> >> >> > However the DPC rtcEvtInterruptDpc() does not run. I know it is not
> >> >> > running
> >> >> > because the ISR Kdprints to the debugger but the DPC does not.
> >> >> >
> >> >> > In rtcEvtPrepareHardware() both the ISR and the DPC are assigned
> >> to
> >> >> the
> >> >> > interrupt.
> >> >> > I think I did all that is required. But obviously I am missing
> >> >> something.
> >> >> > The snippet of the code is:
> >> >> >
> >> >> > rtcEvtInterruptIsr(IN WDFINTERRUPT interrupt, IN ULONG MessageID) {
> >> >> > KdPrint ((“EvtInterruptIsr\n”));
> >> >> >
> >> >> > //reenable mouse
> >> >> > // get command byte
> >> >> >
> >> >> > kbd_command_send(KEYB_CTRL, 0x20);
> >> >> > KdPrint((“ISR Command byte: 0x%x\n”, kbd_command_read()));
> >> >> >
> >> >> >
> >> >> > return TRUE;
> >> >> > }
> >> >> >
> >> >> > rtcEvtInterruptDpc(IN WDFINTERRUPT interrupt, IN WDFOBJECT device)
> >> {
> >> >> > KdPrint ((“EvtInterruptDpc\n”));
> >> >> > }
> >> >> >
> >> >> > rtcEvtPrepareHardware() {
> >> >> > //…
> >> >> > for (i=0; i> >> >> > descriptor = WdfCmResourceListGetDescriptor(resourcesTranslated,
> >> i);
> >> >> > switch (descriptor->Type) {
> >> >> > //…
> >> >> > case CmResourceTypeInterrupt:
> >> >> > deviceContext->irqLevel=descriptor->u.Interrupt.Level;
> >> >> > deviceContext->irqVector=descriptor->u.Interrupt.Vector;
> >> >> > WDF_INTERRUPT_CONFIG_INIT(&interruptConfig,
> >> >> > rtcEvtInterruptIsr,
> >> >> > rtcEvtInterruptDpc);
> >> >> >
> >> >> > interruptConfig.EvtInterruptEnable = rtcEvtInterruptEnable;
> >> >> > interruptConfig.EvtInterruptDisable = rtcEvtInterruptDisable;
> >> >> > interruptConfig.InterruptTranslated = descriptor;
> >> >> > interruptConfig.InterruptRaw =
> >> >> > WdfCmResourceListGetDescriptor(resourcesRaw, i);
> >> >> > status = WdfInterruptCreate(device,
> >> >> > &interruptConfig,
> >> >> > WDF_NO_OBJECT_ATTRIBUTES,
> >> >> > &interrupt);
> >> >> > deviceContext->interrupt=interrupt;
> >> >> > if (!NT_SUCCESS (status)) {
> >> >> > KdPrint (( “Interrupt Object create failure with status = %d\n”,
> >> >> status
> >> >> > ));
> >> >> > return status;
> >> >> > }
> >> >> > break;
> >> >> >
> >> >> > default: return STATUS_DEVICE_CONFIGURATION_ERROR;
> >> >> > }
> >> >> >
> >> >> > }
> >> >> >
> >> >> >
> >> >> >
> >> >> > Menawhile I tried to install the driver for the RTC interrupt
> >> (IRQ8).
> >> >> (It
> >> >> > was my original goal.
> >> >> > However when installing the driver (it is needed to update the
> >> >> cmos/RTC
> >> >> > driver) a reboot is required to complete install. After reboot the
> >> >> device
> >> >> > does not work properly:
> >> >> > In device manager going to the device -> properties it shows in
> >> the
> >> >> > general TAB an error:
> >> >> >
> >> >> >
> >> >> > I thought RTC is always power on, but
> >> >> > It is needed to power up rtc hardware somehow?
> >> >> >
> >> >> > Maybe the windows driver does that however I could not find a way
> >> to
> >> >> do
> >> >> > it.
> >> >> >
> >> >> >
> >> >> > I appreciate any suggestions on these 2 issues,
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > Helder
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 4 June 2013 13:59, wrote:
> >> >> >
> >> >> >> You’re using WinDbg, right? Put a break point in the ISR if
> >> you’re
> >> >> not
> >> >> >> sure you’re actually getting interrupts.
> >> >> >>
> >> >> >> Peter
> >> >> >> OSR
> >> >> >>
> >> >> >>
> >> >> >> —
> >> >> >> NTDEV is sponsored by OSR
> >> >> >>
> >> >> >> OSR is HIRING!! See http://www.osr.com/careers
> >> >> >>
> >> >> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> >> >> http://www.osr.com/seminars
> >> >> >>
> >> >> >> To unsubscribe, visit the List Server section of OSR Online at
> >> >> >> http://www.osronline.com/page.cfm?name=ListServer
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > –
> >> >> > Helder Daniel
> >> >> > UALG - FCT
> >> >> > DEEI
> >> >> >
> >> >> > http://w3.ualg.pt/~hdaniel
> >> >> >
> >> >> > —
> >> >> > NTDEV is sponsored by OSR
> >> >> >
> >> >> > Visit the list at:
> >> http://www.osronline.com/showlists.cfm?list=ntdev
> >> >> >
> >> >> > OSR is HIRING!! See http://www.osr.com/careers
> >> >> >
> >> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
> >> >> > http://www.osr.com/seminars
> >> >> >
> >> >> > To unsubscribe, visit the List Server section of OSR Online at
> >> >> > http://www.osronline.com/page.cfm?name=ListServer
> >> >>
> >> >>
> >> >>
> >> >> —
> >> >> NTDEV is sponsored by OSR
> >> >>
> >> >> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >> >>
> >> >> OSR is HIRING!! See http://www.osr.com/careers
> >> >>
> >> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> >> http://www.osr.com/seminars
> >> >>
> >> >> To unsubscribe, visit the List Server section of OSR Online at
> >> >> http://www.osronline.com/page.cfm?name=ListServer
> >> >>
> >> >>
> >> >
> >> >
> >> > –
> >> > Helder Daniel
> >> > UALG - FCT
> >> > DEEI
> >> >
> >> > http://w3.ualg.pt/~hdaniel
> >> >
> >> > —
> >> > NTDEV is sponsored by OSR
> >> >
> >> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >> >
> >> > OSR is HIRING!! See http://www.osr.com/careers
> >> >
> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
> >> > http://www.osr.com/seminars
> >> >
> >> > To unsubscribe, visit the List Server section of OSR Online at
> >> > http://www.osronline.com/page.cfm?name=ListServer
> >>
> >>
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >>
> >> OSR is HIRING!! See http://www.osr.com/careers
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >>
> >>
> >
> >
> > –
> > Helder Daniel
> > UALG - FCT
> > DEEI
> >
> > http://w3.ualg.pt/~hdaniel
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

–
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

[Doron_Holan]

You have to maintain a queue of.clicks. As a corollary, you need to report each delta too alongside those clicks for actions like dragging if you want apps to respond properly

d

Bent from my phone

---

From: Helder Danielmailto:xxxxx
Sent: ?7/?19/?2013 7:21 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows

Ok that’s fine for mouse motion. No need to queue all mouse packets, just update mouse state x and y with the cumulative of all packets mouse sent between read requests.

But what about mouse button action? Let’s say an app needs to count right mouse clicks.
If we just send to user space the current mouse buttons state and the cumulative of all x and y movement, all the clicks done between the last read request and the current are lost.

How can we track button action without storing in a queue (or something similar) every button action?

On 30 June 2013 21:45, > wrote:

Interrupts ARE disabled in the ISR, as I pointed out. You COULD queue the
requests, although you don’t need to do this in the case of a mouse; all
the user is interested in is the cumulative mouse motion between requests.
Thus, if your mouse is giving relative offsets in x,y (as most mice do)
you only need to keep a running total of these, both positive and negative
motions, and you can easily do this using hardware synchronization.

Don’t try to overthink the problem. Look for the simplest solution. A
queue of pending interrupt deltas sounds cool, but is overkill, and not
only not necessary, but inefficient. Inefficient in that if your usermode
code sends in a request to read the current position, and you have queued
up 100 entries indicating 100 x-traversals and maybe 9 y-traversals, the
app has to issue 100 read requests. But if you accumulate the deltas and
return only the current one (which may change a fraction of a nanosecond
later, but who cares?), then those 100 pending requests become only a
single cumulative request. Note that the mouse is unusual in this regard;
many devices require that your app see all the data, but for mouse motion,
it only needs a “snapshot” of the current state.

On 30 June 2013 21:45, > wrote:
The mouse is a case of a device that interrupts whether there is an IRP
present or not. Therefore, you have to track the information, and when
there is an IRP, you pass the information back to the caller.

If all you are doing is reading the ports and “storing it in some data
structure” then indeed you do not need to use a DPC at this point.

If there is an IRP present, you will have to go to a DPC to complete it.
All EvtIoRead does is dequeue a pending request for an IRP_MJ_READ
operation and if there is no data (or no changed data) you may wish to
hold the request until some data arrives/

The mouse may wish to issue more interrupts, but those interrupts are
blocked by the hardware on the core which is running the ISR, and by the
ISR spin lock if the interrupt is routed to another core. This is
built-in behavior and you don’t need to do anything special to get it.
You don’t need to be disabling mouse interrupts. Note that the “data
structure” in which you store the mouse information is accessed both at
DIRQL level and at < DIRQL level, so you will require synchronization (the
old KeSynchronizeExecution, or however it has been recast into KMDF) so
you see the data as a single entity. Or, if you are only keeping 16-bit
mouse coordinates (remember, these are going to represent physical points
on the screen, so 16 bits will handle massive arrays of displays, wider
than you are ever likely to see any one machine equipped with; for
example, at 1600 horizontal pixels on a display, you would need 40
side-by-side displays to approach the 16-bit limit), you coutd store them
as a 16-bit pair, and update them using a single InterlockedExchange
operation, which synchronizes a single, aligned, 32-bit access at the
hardware level, requiring no software synchronization mechanisms. You
only need to guarantee that the read of x,y gives you a coherent value,
not that interrupts be blocked as the sole means of accomplishing this.
Remember that completing an IRP is a “lengthy” operation compared to the
potential interrupt rate, so if you just blocked interrupts, you would be
ignoring mouse input even when you didn’t need to.

Interrupts ARE disabled in the ISR, as I pointed out. You COULD queue the
requests, although you don’t need to do this in the case of a mouse; all
the user is interested in is the cumulative mouse motion between requests.
Thus, if your mouse is giving relative offsets in x,y (as most mice do)
you only need to keep a running total of these, both positive and negative
motions, and you can easily do this using hardware synchronization.

Don’t try to overthink the problem. Look for the simplest solution. A
queue of pending interrupt deltas sounds cool, but is overkill, and not
only not necessary, but inefficient. Inefficient in that if your usermode
code sends in a request to read the current position, and you have queued
up 100 entries indicating 100 x-traversals and maybe 9 y-traversals, the
app has to issue 100 read requests. But if you accumulate the deltas and
return only the current one (which may change a fraction of a nanosecond
later, but who cares?), then those 100 pending requests become only a
single cumulative request. Note that the mouse is unusual in this regard;
many devices require that your app see all the data, but for mouse motion,
it only needs a “snapshot” of the current state.

BTW, you can discover that this is exactly how the current mouse driver
works. Write an app that, on every mouse-move notification
(WM_MOUSEMOVE), formats the x,y and places it in a window at the x,y
position. You will see that if you move the mouse quickly that you might
get values laid down an inch apart, and if you move slowly, you will get
values laid down a pixel or two apart. So it is not like you are doing
anything inconsistent with current mouse behavior. If you don’t like
formatting the x,y, just draw a + at the current reported mouse
coordinate. Same effect, somewhat easier to see.
joe

> Ok so let’s say we need to complete a request to read a mouse packet.
>
> We can service the interrupt in the ISR, read mouse packet from I/O ports
> and store it in some data structure. So there is no need for DPC here
> right?
>
> Assuming that some user space code is accessing the driver to get mouse
> data using read callback we can sent to userspace mouse packet stored by
> the ISR in the EvtIORead and complete the IRP, right?
>
> Now when IRP are being processed mouse may issue other interrupts.
> What is the right thing to do? Disable mouse interrupts until the IRP is
> completed? This means disable mouse interrupts at the beginning of the ISR
> and enable them at the end of EvtIORead.
>
> Alternatively mouse interrupts could be disabled just during the ISR. Each
> time the ISR runs stores each mouse packet in a queue that will be sent to
> userspace in EvtIOread by arrival order. I think with this approach less
> mouse data will be lost while interrupts are disabled.
>
> The question is what’s the common approach?
> Probably there’s a better one …
>
>
>
>
>
>
> On 27 June 2013 23:14, > wrote:
>
>> DPCs are a general concept, and there is a general DPC calling
>> mechanism.
>> However, “registering” a DPC allows you to avoid the complexity of the
>> fully general call and identify the DPC which you will want to queue up
>> from the ISR. The call you show below knows the “registered” DPC and
>> therefore hides a great deal of the gratuitous complexity of the fully
>> general calling mechanism to make the most common case simple.
>>
>> So all registering it does is make the DPC known to this internal
>> mechanism.
>>
>> Note that an ISR does not have to be followed immediately by a DPC. An
>> ISR has, by modern standards, a HUGE time budget, 10us, which in an
>> architecture that can issue 6 to 9 instructions per clock cycle, three
>> clock cycles per nanosecond, this is a LOT of instructions. So, for
>> example, if the interrupt comes in after a partial transfer, it is
>> perfectly sensible to initiate the next part of the transfer in the ISR.
>> As long as this doesn’t require any calls forbidden at DIRQL level, it
>> is
>> common practice. You only queue up the DPC when you need to take
>> actions
>> that cannot be performed at DIRQL level, such as completing the IRP, or
>> if
>> the nature of the device requires more than 10us of computation after an
>> interrupt. Since the DPC is not required for each interrupt, the choice
>> to execute the DPC requires an overt action on your part.
>> joe
>>
>>
>> > Oops!
>> >
>> > I thought it was enough to register the DPC.
>> > After queuing it with:
>> >
>> > WdfInterruptQueueDpcForIsr( interrupt );
>> >
>> > DPC is called. Thanks
>> >
>> > I guess its similar to scheduling Linux bottom halves for execution.
>> >
>> >
>> > On 27 June 2013 19:45, > wrote:
>> >
>> >> In the ISR, I didn’t see where you requested the DPC. Unless you ask
>> >> for
>> >> it, it isn’t going to happen.
>> >> joe
>> >>
>> >> > Hi all,
>> >> >
>> >> > Thank for all the suggestions.
>> >> > The problem was the initialization of the ps/2 mouse hardware
>> >> (actually
>> >> > synaptics touchpad).
>> >> > After fixing it ISR runs as mouse is moved or pressed.
>> >> >
>> >> > However the DPC rtcEvtInterruptDpc() does not run. I know it is not
>> >> > running
>> >> > because the ISR Kdprints to the debugger but the DPC does not.
>> >> >
>> >> > In rtcEvtPrepareHardware() both the ISR and the DPC are assigned
>> to
>> >> the
>> >> > interrupt.
>> >> > I think I did all that is required. But obviously I am missing
>> >> something.
>> >> > The snippet of the code is:
>> >> >
>> >> > rtcEvtInterruptIsr(IN WDFINTERRUPT interrupt, IN ULONG MessageID) {
>> >> > KdPrint ((“EvtInterruptIsr\n”));
>> >> >
>> >> > //reenable mouse
>> >> > // get command byte
>> >> >
>> >> > kbd_command_send(KEYB_CTRL, 0x20);
>> >> > KdPrint((“ISR Command byte: 0x%x\n”, kbd_command_read()));
>> >> >
>> >> >
>> >> > return TRUE;
>> >> > }
>> >> >
>> >> > rtcEvtInterruptDpc(IN WDFINTERRUPT interrupt, IN WDFOBJECT device)
>> {
>> >> > KdPrint ((“EvtInterruptDpc\n”));
>> >> > }
>> >> >
>> >> > rtcEvtPrepareHardware() {
>> >> > //…
>> >> > for (i=0; i>> >> > descriptor = WdfCmResourceListGetDescriptor(resourcesTranslated,
>> i);
>> >> > switch (descriptor->Type) {
>> >> > //…
>> >> > case CmResourceTypeInterrupt:
>> >> > deviceContext->irqLevel=descriptor->u.Interrupt.Level;
>> >> > deviceContext->irqVector=descriptor->u.Interrupt.Vector;
>> >> > WDF_INTERRUPT_CONFIG_INIT(&interruptConfig,
>> >> > rtcEvtInterruptIsr,
>> >> > rtcEvtInterruptDpc);
>> >> >
>> >> > interruptConfig.EvtInterruptEnable = rtcEvtInterruptEnable;
>> >> > interruptConfig.EvtInterruptDisable = rtcEvtInterruptDisable;
>> >> > interruptConfig.InterruptTranslated = descriptor;
>> >> > interruptConfig.InterruptRaw =
>> >> > WdfCmResourceListGetDescriptor(resourcesRaw, i);
>> >> > status = WdfInterruptCreate(device,
>> >> > &interruptConfig,
>> >> > WDF_NO_OBJECT_ATTRIBUTES,
>> >> > &interrupt);
>> >> > deviceContext->interrupt=interrupt;
>> >> > if (!NT_SUCCESS (status)) {
>> >> > KdPrint (( “Interrupt Object create failure with status = %d\n”,
>> >> status
>> >> > ));
>> >> > return status;
>> >> > }
>> >> > break;
>> >> >
>> >> > default: return STATUS_DEVICE_CONFIGURATION_ERROR;
>> >> > }
>> >> >
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > Menawhile I tried to install the driver for the RTC interrupt
>> (IRQ8).
>> >> (It
>> >> > was my original goal.
>> >> > However when installing the driver (it is needed to update the
>> >> cmos/RTC
>> >> > driver) a reboot is required to complete install. After reboot the
>> >> device
>> >> > does not work properly:
>> >> > In device manager going to the device -> properties it shows in
>> the
>> >> > general TAB an error:
>> >> >
>> >> >
>> >> > I thought RTC is always power on, but
>> >> > It is needed to power up rtc hardware somehow?
>> >> >
>> >> > Maybe the windows driver does that however I could not find a way
>> to
>> >> do
>> >> > it.
>> >> >
>> >> >
>> >> > I appreciate any suggestions on these 2 issues,
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Helder
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 4 June 2013 13:59, > wrote:
>> >> >
>> >> >> You’re using WinDbg, right? Put a break point in the ISR if
>> you’re
>> >> not
>> >> >> sure you’re actually getting interrupts.
>> >> >>
>> >> >> Peter
>> >> >> OSR
>> >> >>
>> >> >>
>> >> >> —
>> >> >> NTDEV is sponsored by OSR
>> >> >>
>> >> >> OSR is HIRING!! See http://www.osr.com/careers
>> >> >>
>> >> >> For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> >> http://www.osr.com/seminars
>> >> >>
>> >> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> >> http://www.osronline.com/page.cfm?name=ListServer
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > –
>> >> > Helder Daniel
>> >> > UALG - FCT
>> >> > DEEI
>> >> >
>> >> > http://w3.ualg.pt/~hdaniel
>> >> >
>> >> > —
>> >> > NTDEV is sponsored by OSR
>> >> >
>> >> > Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev
>> >> >
>> >> > OSR is HIRING!! See http://www.osr.com/careers
>> >> >
>> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> > http://www.osr.com/seminars
>> >> >
>> >> > To unsubscribe, visit the List Server section of OSR Online at
>> >> > http://www.osronline.com/page.cfm?name=ListServer
>> >>
>> >>
>> >>
>> >> —
>> >> NTDEV is sponsored by OSR
>> >>
>> >> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>> >>
>> >> OSR is HIRING!! See http://www.osr.com/careers
>> >>
>> >> For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> http://www.osr.com/seminars
>> >>
>> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> http://www.osronline.com/page.cfm?name=ListServer
>> >>
>> >>
>> >
>> >
>> > –
>> > Helder Daniel
>> > UALG - FCT
>> > DEEI
>> >
>> > http://w3.ualg.pt/~hdaniel
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>> >
>> > OSR is HIRING!! See http://www.osr.com/careers
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>
>
> –
> Helder Daniel
> UALG - FCT
> DEEI
>
> http://w3.ualg.pt/~hdaniel
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

[Helder_Daniel]

Yes. Well I guess we could accumulate x y deltas until a button change
state and then add to the queue. This will reduce the queue.
No dia 19 de Jul de 2013 15:43, “Doron Holan”
escreveu:

> You have to maintain a queue of.clicks. As a corollary, you need to
> report each delta too alongside those clicks for actions like dragging if
> you want apps to respond properly
>
> d
>
> Bent from my phone
> ------------------------------
> From: Helder Daniel
> Sent: 7/19/2013 7:21 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows
>
> Ok that’s fine for mouse motion. No need to queue all mouse packets,
> just update mouse state x and y with the cumulative of all packets mouse
> sent between read requests.
>
> But what about mouse button action? Let’s say an app needs to count
> right mouse clicks.
> If we just send to user space the current mouse buttons state and the
> cumulative of all x and y movement, all the clicks done between the last
> read request and the current are lost.
>
> How can we track button action without storing in a queue (or something
> similar) every button action?
>
> On 30 June 2013 21:45, wrote:
>
> Interrupts ARE disabled in the ISR, as I pointed out. You COULD queue
> the
> requests, although you don’t need to do this in the case of a mouse; all
> the user is interested in is the cumulative mouse motion between requests.
> Thus, if your mouse is giving relative offsets in x,y (as most mice do)
> you only need to keep a running total of these, both positive and negative
> motions, and you can easily do this using hardware synchronization.
>
> Don’t try to overthink the problem. Look for the simplest solution. A
> queue of pending interrupt deltas sounds cool, but is overkill, and not
> only not necessary, but inefficient. Inefficient in that if your usermode
> code sends in a request to read the current position, and you have queued
> up 100 entries indicating 100 x-traversals and maybe 9 y-traversals, the
> app has to issue 100 read requests. But if you accumulate the deltas and
> return only the current one (which may change a fraction of a nanosecond
> later, but who cares?), then those 100 pending requests become only a
> single cumulative request. Note that the mouse is unusual in this regard;
> many devices require that your app see all the data, but for mouse motion,
> it only needs a “snapshot” of the current state.
>
> On 30 June 2013 21:45, wrote:
>
>> The mouse is a case of a device that interrupts whether there is an IRP
>> present or not. Therefore, you have to track the information, and when
>> there is an IRP, you pass the information back to the caller.
>>
>> If all you are doing is reading the ports and “storing it in some data
>> structure” then indeed you do not need to use a DPC at this point.
>>
>> If there is an IRP present, you will have to go to a DPC to complete it.
>> All EvtIoRead does is dequeue a pending request for an IRP_MJ_READ
>> operation and if there is no data (or no changed data) you may wish to
>> hold the request until some data arrives/
>>
>> The mouse may wish to issue more interrupts, but those interrupts are
>> blocked by the hardware on the core which is running the ISR, and by the
>> ISR spin lock if the interrupt is routed to another core. This is
>> built-in behavior and you don’t need to do anything special to get it.
>> You don’t need to be disabling mouse interrupts. Note that the “data
>> structure” in which you store the mouse information is accessed both at
>> DIRQL level and at < DIRQL level, so you will require synchronization (the
>> old KeSynchronizeExecution, or however it has been recast into KMDF) so
>> you see the data as a single entity. Or, if you are only keeping 16-bit
>> mouse coordinates (remember, these are going to represent physical points
>> on the screen, so 16 bits will handle massive arrays of displays, wider
>> than you are ever likely to see any one machine equipped with; for
>> example, at 1600 horizontal pixels on a display, you would need 40
>> side-by-side displays to approach the 16-bit limit), you coutd store them
>> as a 16-bit pair, and update them using a single InterlockedExchange
>> operation, which synchronizes a single, aligned, 32-bit access at the
>> hardware level, requiring no software synchronization mechanisms. You
>> only need to guarantee that the read of x,y gives you a coherent value,
>> not that interrupts be blocked as the sole means of accomplishing this.
>> Remember that completing an IRP is a “lengthy” operation compared to the
>> potential interrupt rate, so if you just blocked interrupts, you would be
>> ignoring mouse input even when you didn’t need to.
>>
>> Interrupts ARE disabled in the ISR, as I pointed out. You COULD queue the
>> requests, although you don’t need to do this in the case of a mouse; all
>> the user is interested in is the cumulative mouse motion between requests.
>> Thus, if your mouse is giving relative offsets in x,y (as most mice do)
>> you only need to keep a running total of these, both positive and negative
>> motions, and you can easily do this using hardware synchronization.
>>
>> Don’t try to overthink the problem. Look for the simplest solution. A
>> queue of pending interrupt deltas sounds cool, but is overkill, and not
>> only not necessary, but inefficient. Inefficient in that if your usermode
>> code sends in a request to read the current position, and you have queued
>> up 100 entries indicating 100 x-traversals and maybe 9 y-traversals, the
>> app has to issue 100 read requests. But if you accumulate the deltas and
>> return only the current one (which may change a fraction of a nanosecond
>> later, but who cares?), then those 100 pending requests become only a
>> single cumulative request. Note that the mouse is unusual in this regard;
>> many devices require that your app see all the data, but for mouse motion,
>> it only needs a “snapshot” of the current state.
>>
>> BTW, you can discover that this is exactly how the current mouse driver
>> works. Write an app that, on every mouse-move notification
>> (WM_MOUSEMOVE), formats the x,y and places it in a window at the x,y
>> position. You will see that if you move the mouse quickly that you might
>> get values laid down an inch apart, and if you move slowly, you will get
>> values laid down a pixel or two apart. So it is not like you are doing
>> anything inconsistent with current mouse behavior. If you don’t like
>> formatting the x,y, just draw a + at the current reported mouse
>> coordinate. Same effect, somewhat easier to see.
>> joe
>>
>>
>> > Ok so let’s say we need to complete a request to read a mouse packet.
>> >
>> > We can service the interrupt in the ISR, read mouse packet from I/O
>> ports
>> > and store it in some data structure. So there is no need for DPC here
>> > right?
>> >
>> > Assuming that some user space code is accessing the driver to get mouse
>> > data using read callback we can sent to userspace mouse packet stored by
>> > the ISR in the EvtIORead and complete the IRP, right?
>> >
>> > Now when IRP are being processed mouse may issue other interrupts.
>> > What is the right thing to do? Disable mouse interrupts until the IRP is
>> > completed? This means disable mouse interrupts at the beginning of the
>> ISR
>> > and enable them at the end of EvtIORead.
>> >
>> > Alternatively mouse interrupts could be disabled just during the ISR.
>> Each
>> > time the ISR runs stores each mouse packet in a queue that will be sent
>> to
>> > userspace in EvtIOread by arrival order. I think with this approach less
>> > mouse data will be lost while interrupts are disabled.
>> >
>> > The question is what’s the common approach?
>> > Probably there’s a better one …
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 27 June 2013 23:14, wrote:
>> >
>> >> DPCs are a general concept, and there is a general DPC calling
>> >> mechanism.
>> >> However, “registering” a DPC allows you to avoid the complexity of the
>> >> fully general call and identify the DPC which you will want to queue up
>> >> from the ISR. The call you show below knows the “registered” DPC and
>> >> therefore hides a great deal of the gratuitous complexity of the fully
>> >> general calling mechanism to make the most common case simple.
>> >>
>> >> So all registering it does is make the DPC known to this internal
>> >> mechanism.
>> >>
>> >> Note that an ISR does not have to be followed immediately by a DPC. An
>> >> ISR has, by modern standards, a HUGE time budget, 10us, which in an
>> >> architecture that can issue 6 to 9 instructions per clock cycle, three
>> >> clock cycles per nanosecond, this is a LOT of instructions. So, for
>> >> example, if the interrupt comes in after a partial transfer, it is
>> >> perfectly sensible to initiate the next part of the transfer in the
>> ISR.
>> >> As long as this doesn’t require any calls forbidden at DIRQL level, it
>> >> is
>> >> common practice. You only queue up the DPC when you need to take
>> >> actions
>> >> that cannot be performed at DIRQL level, such as completing the IRP, or
>> >> if
>> >> the nature of the device requires more than 10us of computation after
>> an
>> >> interrupt. Since the DPC is not required for each interrupt, the
>> choice
>> >> to execute the DPC requires an overt action on your part.
>> >> joe
>> >>
>> >>
>> >> > Oops!
>> >> >
>> >> > I thought it was enough to register the DPC.
>> >> > After queuing it with:
>> >> >
>> >> > WdfInterruptQueueDpcForIsr( interrupt );
>> >> >
>> >> > DPC is called. Thanks
>> >> >
>> >> > I guess its similar to scheduling Linux bottom halves for execution.
>> >> >
>> >> >
>> >> > On 27 June 2013 19:45, wrote:
>> >> >
>> >> >> In the ISR, I didn’t see where you requested the DPC. Unless you
>> ask
>> >> >> for
>> >> >> it, it isn’t going to happen.
>> >> >> joe
>> >> >>
>> >> >> > Hi all,
>> >> >> >
>> >> >> > Thank for all the suggestions.
>> >> >> > The problem was the initialization of the ps/2 mouse hardware
>> >> >> (actually
>> >> >> > synaptics touchpad).
>> >> >> > After fixing it ISR runs as mouse is moved or pressed.
>> >> >> >
>> >> >> > However the DPC rtcEvtInterruptDpc() does not run. I know it is
>> not
>> >> >> > running
>> >> >> > because the ISR Kdprints to the debugger but the DPC does not.
>> >> >> >
>> >> >> > In rtcEvtPrepareHardware() both the ISR and the DPC are assigned
>> >> to
>> >> >> the
>> >> >> > interrupt.
>> >> >> > I think I did all that is required. But obviously I am missing
>> >> >> something.
>> >> >> > The snippet of the code is:
>> >> >> >
>> >> >> > rtcEvtInterruptIsr(IN WDFINTERRUPT interrupt, IN ULONG MessageID)
>> {
>> >> >> > KdPrint ((“EvtInterruptIsr\n”));
>> >> >> >
>> >> >> > //reenable mouse
>> >> >> > // get command byte
>> >> >> >
>> >> >> > kbd_command_send(KEYB_CTRL, 0x20);
>> >> >> > KdPrint((“ISR Command byte: 0x%x\n”, kbd_command_read()));
>> >> >> >
>> >> >> >
>> >> >> > return TRUE;
>> >> >> > }
>> >> >> >
>> >> >> > rtcEvtInterruptDpc(IN WDFINTERRUPT interrupt, IN WDFOBJECT device)
>> >> {
>> >> >> > KdPrint ((“EvtInterruptDpc\n”));
>> >> >> > }
>> >> >> >
>> >> >> > rtcEvtPrepareHardware() {
>> >> >> > //…
>> >> >> > for (i=0; i>> >> >> > descriptor = WdfCmResourceListGetDescriptor(resourcesTranslated,
>> >> i);
>> >> >> > switch (descriptor->Type) {
>> >> >> > //…
>> >> >> > case CmResourceTypeInterrupt:
>> >> >> > deviceContext->irqLevel=descriptor->u.Interrupt.Level;
>> >> >> > deviceContext->irqVector=descriptor->u.Interrupt.Vector;
>> >> >> > WDF_INTERRUPT_CONFIG_INIT(&interruptConfig,
>> >> >> > rtcEvtInterruptIsr,
>> >> >> > rtcEvtInterruptDpc);
>> >> >> >
>> >> >> > interruptConfig.EvtInterruptEnable = rtcEvtInterruptEnable;
>> >> >> > interruptConfig.EvtInterruptDisable = rtcEvtInterruptDisable;
>> >> >> > interruptConfig.InterruptTranslated = descriptor;
>> >> >> > interruptConfig.InterruptRaw =
>> >> >> > WdfCmResourceListGetDescriptor(resourcesRaw, i);
>> >> >> > status = WdfInterruptCreate(device,
>> >> >> > &interruptConfig,
>> >> >> > WDF_NO_OBJECT_ATTRIBUTES,
>> >> >> > &interrupt);
>> >> >> > deviceContext->interrupt=interrupt;
>> >> >> > if (!NT_SUCCESS (status)) {
>> >> >> > KdPrint (( “Interrupt Object create failure with status = %d\n”,
>> >> >> status
>> >> >> > ));
>> >> >> > return status;
>> >> >> > }
>> >> >> > break;
>> >> >> >
>> >> >> > default: return STATUS_DEVICE_CONFIGURATION_ERROR;
>> >> >> > }
>> >> >> >
>> >> >> > }
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Menawhile I tried to install the driver for the RTC interrupt
>> >> (IRQ8).
>> >> >> (It
>> >> >> > was my original goal.
>> >> >> > However when installing the driver (it is needed to update the
>> >> >> cmos/RTC
>> >> >> > driver) a reboot is required to complete install. After reboot the
>> >> >> device
>> >> >> > does not work properly:
>> >> >> > In device manager going to the device -> properties it shows in
>> >> the
>> >> >> > general TAB an error:
>> >> >> >
>> >> >> >
>> >> >> > I thought RTC is always power on, but
>> >> >> > It is needed to power up rtc hardware somehow?
>> >> >> >
>> >> >> > Maybe the windows driver does that however I could not find a way
>> >> to
>> >> >> do
>> >> >> > it.
>> >> >> >
>> >> >> >
>> >> >> > I appreciate any suggestions on these 2 issues,
>> >> >> >
>> >> >> > Thanks,
>> >> >> >
>> >> >> > Helder
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On 4 June 2013 13:59, wrote:
>> >> >> >
>> >> >> >> You’re using WinDbg, right? Put a break point in the ISR if
>> >> you’re
>> >> >> not
>> >> >> >> sure you’re actually getting interrupts.
>> >> >> >>
>> >> >> >> Peter
>> >> >> >> OSR
>> >> >> >>
>> >> >> >>
>> >> >> >> —
>> >> >> >> NTDEV is sponsored by OSR
>> >> >> >>
>> >> >> >> OSR is HIRING!! See http://www.osr.com/careers
>> >> >> >>
>> >> >> >> For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> >> >> http://www.osr.com/seminars
>> >> >> >>
>> >> >> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> >> >> http://www.osronline.com/page.cfm?name=ListServer
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > –
>> >> >> > Helder Daniel
>> >> >> > UALG - FCT
>> >> >> > DEEI
>> >> >> >
>> >> >> > http://w3.ualg.pt/~hdaniel
>> >> >> >
>> >> >> > —
>> >> >> > NTDEV is sponsored by OSR
>> >> >> >
>> >> >> > Visit the list at:
>> >> http://www.osronline.com/showlists.cfm?list=ntdev
>> >> >> >
>> >> >> > OSR is HIRING!! See http://www.osr.com/careers
>> >> >> >
>> >> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> >> > http://www.osr.com/seminars
>> >> >> >
>> >> >> > To unsubscribe, visit the List Server section of OSR Online at
>> >> >> > http://www.osronline.com/page.cfm?name=ListServer
>> >> >>
>> >> >>
>> >> >>
>> >> >> —
>> >> >> NTDEV is sponsored by OSR
>> >> >>
>> >> >> Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev
>> >> >>
>> >> >> OSR is HIRING!! See http://www.osr.com/careers
>> >> >>
>> >> >> For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> >> http://www.osr.com/seminars
>> >> >>
>> >> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> >> http://www.osronline.com/page.cfm?name=ListServer
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > –
>> >> > Helder Daniel
>> >> > UALG - FCT
>> >> > DEEI
>> >> >
>> >> > http://w3.ualg.pt/~hdaniel
>> >> >
>> >> > —
>> >> > NTDEV is sponsored by OSR
>> >> >
>> >> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>> >> >
>> >> > OSR is HIRING!! See http://www.osr.com/careers
>> >> >
>> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> > http://www.osr.com/seminars
>> >> >
>> >> > To unsubscribe, visit the List Server section of OSR Online at
>> >> > http://www.osronline.com/page.cfm?name=ListServer
>> >>
>> >>
>> >>
>> >> —
>> >> NTDEV is sponsored by OSR
>> >>
>> >> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>> >>
>> >> OSR is HIRING!! See http://www.osr.com/careers
>> >>
>> >> For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> http://www.osr.com/seminars
>> >>
>> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> http://www.osronline.com/page.cfm?name=ListServer
>> >>
>> >>
>> >
>> >
>> > –
>> > Helder Daniel
>> > UALG - FCT
>> > DEEI
>> >
>> > http://w3.ualg.pt/~hdaniel
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>> >
>> > OSR is HIRING!! See http://www.osr.com/careers
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>
>
> –
> Helder Daniel
> UALG - FCT
> DEEI
>
> http://w3.ualg.pt/~hdaniel
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

[Doron_Holan]

That’s not what I was suggesting

d

Bent from my phone

---

From: Helder Danielmailto:xxxxx
Sent: ?7/?21/?2013 3:17 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] Issue interrupt from kernel space on x64 Windows

Yes. Well I guess we could accumulate x y deltas until a button change state and then add to the queue. This will reduce the queue.

No dia 19 de Jul de 2013 15:43, “Doron Holan” > escreveu:
You have to maintain a queue of.clicks. As a corollary, you need to report each delta too alongside those clicks for actions like dragging if you want apps to respond properly

d

Bent from my phone
________________________________
From: Helder Danielmailto:xxxxx
Sent: 7/19/2013 7:21 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] Issue interrupt from kernel space on x64 Windows

Ok that’s fine for mouse motion. No need to queue all mouse packets, just update mouse state x and y with the cumulative of all packets mouse sent between read requests.

But what about mouse button action? Let’s say an app needs to count right mouse clicks.
If we just send to user space the current mouse buttons state and the cumulative of all x and y movement, all the clicks done between the last read request and the current are lost.

How can we track button action without storing in a queue (or something similar) every button action?

On 30 June 2013 21:45, > wrote:

Interrupts ARE disabled in the ISR, as I pointed out. You COULD queue the
requests, although you don’t need to do this in the case of a mouse; all
the user is interested in is the cumulative mouse motion between requests.
Thus, if your mouse is giving relative offsets in x,y (as most mice do)
you only need to keep a running total of these, both positive and negative
motions, and you can easily do this using hardware synchronization.

Don’t try to overthink the problem. Look for the simplest solution. A
queue of pending interrupt deltas sounds cool, but is overkill, and not
only not necessary, but inefficient. Inefficient in that if your usermode
code sends in a request to read the current position, and you have queued
up 100 entries indicating 100 x-traversals and maybe 9 y-traversals, the
app has to issue 100 read requests. But if you accumulate the deltas and
return only the current one (which may change a fraction of a nanosecond
later, but who cares?), then those 100 pending requests become only a
single cumulative request. Note that the mouse is unusual in this regard;
many devices require that your app see all the data, but for mouse motion,
it only needs a “snapshot” of the current state.

On 30 June 2013 21:45, > wrote:
The mouse is a case of a device that interrupts whether there is an IRP
present or not. Therefore, you have to track the information, and when
there is an IRP, you pass the information back to the caller.

If all you are doing is reading the ports and “storing it in some data
structure” then indeed you do not need to use a DPC at this point.

If there is an IRP present, you will have to go to a DPC to complete it.
All EvtIoRead does is dequeue a pending request for an IRP_MJ_READ
operation and if there is no data (or no changed data) you may wish to
hold the request until some data arrives/

The mouse may wish to issue more interrupts, but those interrupts are
blocked by the hardware on the core which is running the ISR, and by the
ISR spin lock if the interrupt is routed to another core. This is
built-in behavior and you don’t need to do anything special to get it.
You don’t need to be disabling mouse interrupts. Note that the “data
structure” in which you store the mouse information is accessed both at
DIRQL level and at < DIRQL level, so you will require synchronization (the
old KeSynchronizeExecution, or however it has been recast into KMDF) so
you see the data as a single entity. Or, if you are only keeping 16-bit
mouse coordinates (remember, these are going to represent physical points
on the screen, so 16 bits will handle massive arrays of displays, wider
than you are ever likely to see any one machine equipped with; for
example, at 1600 horizontal pixels on a display, you would need 40
side-by-side displays to approach the 16-bit limit), you coutd store them
as a 16-bit pair, and update them using a single InterlockedExchange
operation, which synchronizes a single, aligned, 32-bit access at the
hardware level, requiring no software synchronization mechanisms. You
only need to guarantee that the read of x,y gives you a coherent value,
not that interrupts be blocked as the sole means of accomplishing this.
Remember that completing an IRP is a “lengthy” operation compared to the
potential interrupt rate, so if you just blocked interrupts, you would be
ignoring mouse input even when you didn’t need to.

Interrupts ARE disabled in the ISR, as I pointed out. You COULD queue the
requests, although you don’t need to do this in the case of a mouse; all
the user is interested in is the cumulative mouse motion between requests.
Thus, if your mouse is giving relative offsets in x,y (as most mice do)
you only need to keep a running total of these, both positive and negative
motions, and you can easily do this using hardware synchronization.

Don’t try to overthink the problem. Look for the simplest solution. A
queue of pending interrupt deltas sounds cool, but is overkill, and not
only not necessary, but inefficient. Inefficient in that if your usermode
code sends in a request to read the current position, and you have queued
up 100 entries indicating 100 x-traversals and maybe 9 y-traversals, the
app has to issue 100 read requests. But if you accumulate the deltas and
return only the current one (which may change a fraction of a nanosecond
later, but who cares?), then those 100 pending requests become only a
single cumulative request. Note that the mouse is unusual in this regard;
many devices require that your app see all the data, but for mouse motion,
it only needs a “snapshot” of the current state.

BTW, you can discover that this is exactly how the current mouse driver
works. Write an app that, on every mouse-move notification
(WM_MOUSEMOVE), formats the x,y and places it in a window at the x,y
position. You will see that if you move the mouse quickly that you might
get values laid down an inch apart, and if you move slowly, you will get
values laid down a pixel or two apart. So it is not like you are doing
anything inconsistent with current mouse behavior. If you don’t like
formatting the x,y, just draw a + at the current reported mouse
coordinate. Same effect, somewhat easier to see.
joe

> Ok so let’s say we need to complete a request to read a mouse packet.
>
> We can service the interrupt in the ISR, read mouse packet from I/O ports
> and store it in some data structure. So there is no need for DPC here
> right?
>
> Assuming that some user space code is accessing the driver to get mouse
> data using read callback we can sent to userspace mouse packet stored by
> the ISR in the EvtIORead and complete the IRP, right?
>
> Now when IRP are being processed mouse may issue other interrupts.
> What is the right thing to do? Disable mouse interrupts until the IRP is
> completed? This means disable mouse interrupts at the beginning of the ISR
> and enable them at the end of EvtIORead.
>
> Alternatively mouse interrupts could be disabled just during the ISR. Each
> time the ISR runs stores each mouse packet in a queue that will be sent to
> userspace in EvtIOread by arrival order. I think with this approach less
> mouse data will be lost while interrupts are disabled.
>
> The question is what’s the common approach?
> Probably there’s a better one …
>
>
>
>
>
>
> On 27 June 2013 23:14, > wrote:
>
>> DPCs are a general concept, and there is a general DPC calling
>> mechanism.
>> However, “registering” a DPC allows you to avoid the complexity of the
>> fully general call and identify the DPC which you will want to queue up
>> from the ISR. The call you show below knows the “registered” DPC and
>> therefore hides a great deal of the gratuitous complexity of the fully
>> general calling mechanism to make the most common case simple.
>>
>> So all registering it does is make the DPC known to this internal
>> mechanism.
>>
>> Note that an ISR does not have to be followed immediately by a DPC. An
>> ISR has, by modern standards, a HUGE time budget, 10us, which in an
>> architecture that can issue 6 to 9 instructions per clock cycle, three
>> clock cycles per nanosecond, this is a LOT of instructions. So, for
>> example, if the interrupt comes in after a partial transfer, it is
>> perfectly sensible to initiate the next part of the transfer in the ISR.
>> As long as this doesn’t require any calls forbidden at DIRQL level, it
>> is
>> common practice. You only queue up the DPC when you need to take
>> actions
>> that cannot be performed at DIRQL level, such as completing the IRP, or
>> if
>> the nature of the device requires more than 10us of computation after an
>> interrupt. Since the DPC is not required for each interrupt, the choice
>> to execute the DPC requires an overt action on your part.
>> joe
>>
>>
>> > Oops!
>> >
>> > I thought it was enough to register the DPC.
>> > After queuing it with:
>> >
>> > WdfInterruptQueueDpcForIsr( interrupt );
>> >
>> > DPC is called. Thanks
>> >
>> > I guess its similar to scheduling Linux bottom halves for execution.
>> >
>> >
>> > On 27 June 2013 19:45, > wrote:
>> >
>> >> In the ISR, I didn’t see where you requested the DPC. Unless you ask
>> >> for
>> >> it, it isn’t going to happen.
>> >> joe
>> >>
>> >> > Hi all,
>> >> >
>> >> > Thank for all the suggestions.
>> >> > The problem was the initialization of the ps/2 mouse hardware
>> >> (actually
>> >> > synaptics touchpad).
>> >> > After fixing it ISR runs as mouse is moved or pressed.
>> >> >
>> >> > However the DPC rtcEvtInterruptDpc() does not run. I know it is not
>> >> > running
>> >> > because the ISR Kdprints to the debugger but the DPC does not.
>> >> >
>> >> > In rtcEvtPrepareHardware() both the ISR and the DPC are assigned
>> to
>> >> the
>> >> > interrupt.
>> >> > I think I did all that is required. But obviously I am missing
>> >> something.
>> >> > The snippet of the code is:
>> >> >
>> >> > rtcEvtInterruptIsr(IN WDFINTERRUPT interrupt, IN ULONG MessageID) {
>> >> > KdPrint ((“EvtInterruptIsr\n”));
>> >> >
>> >> > //reenable mouse
>> >> > // get command byte
>> >> >
>> >> > kbd_command_send(KEYB_CTRL, 0x20);
>> >> > KdPrint((“ISR Command byte: 0x%x\n”, kbd_command_read()));
>> >> >
>> >> >
>> >> > return TRUE;
>> >> > }
>> >> >
>> >> > rtcEvtInterruptDpc(IN WDFINTERRUPT interrupt, IN WDFOBJECT device)
>> {
>> >> > KdPrint ((“EvtInterruptDpc\n”));
>> >> > }
>> >> >
>> >> > rtcEvtPrepareHardware() {
>> >> > //…
>> >> > for (i=0; i>> >> > descriptor = WdfCmResourceListGetDescriptor(resourcesTranslated,
>> i);
>> >> > switch (descriptor->Type) {
>> >> > //…
>> >> > case CmResourceTypeInterrupt:
>> >> > deviceContext->irqLevel=descriptor->u.Interrupt.Level;
>> >> > deviceContext->irqVector=descriptor->u.Interrupt.Vector;
>> >> > WDF_INTERRUPT_CONFIG_INIT(&interruptConfig,
>> >> > rtcEvtInterruptIsr,
>> >> > rtcEvtInterruptDpc);
>> >> >
>> >> > interruptConfig.EvtInterruptEnable = rtcEvtInterruptEnable;
>> >> > interruptConfig.EvtInterruptDisable = rtcEvtInterruptDisable;
>> >> > interruptConfig.InterruptTranslated = descriptor;
>> >> > interruptConfig.InterruptRaw =
>> >> > WdfCmResourceListGetDescriptor(resourcesRaw, i);
>> >> > status = WdfInterruptCreate(device,
>> >> > &interruptConfig,
>> >> > WDF_NO_OBJECT_ATTRIBUTES,
>> >> > &interrupt);
>> >> > deviceContext->interrupt=interrupt;
>> >> > if (!NT_SUCCESS (status)) {
>> >> > KdPrint (( “Interrupt Object create failure with status = %d\n”,
>> >> status
>> >> > ));
>> >> > return status;
>> >> > }
>> >> > break;
>> >> >
>> >> > default: return STATUS_DEVICE_CONFIGURATION_ERROR;
>> >> > }
>> >> >
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > Menawhile I tried to install the driver for the RTC interrupt
>> (IRQ8).
>> >> (It
>> >> > was my original goal.
>> >> > However when installing the driver (it is needed to update the
>> >> cmos/RTC
>> >> > driver) a reboot is required to complete install. After reboot the
>> >> device
>> >> > does not work properly:
>> >> > In device manager going to the device -> properties it shows in
>> the
>> >> > general TAB an error:
>> >> >
>> >> >
>> >> > I thought RTC is always power on, but
>> >> > It is needed to power up rtc hardware somehow?
>> >> >
>> >> > Maybe the windows driver does that however I could not find a way
>> to
>> >> do
>> >> > it.
>> >> >
>> >> >
>> >> > I appreciate any suggestions on these 2 issues,
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Helder
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 4 June 2013 13:59, > wrote:
>> >> >
>> >> >> You’re using WinDbg, right? Put a break point in the ISR if
>> you’re
>> >> not
>> >> >> sure you’re actually getting interrupts.
>> >> >>
>> >> >> Peter
>> >> >> OSR
>> >> >>
>> >> >>
>> >> >> —
>> >> >> NTDEV is sponsored by OSR
>> >> >>
>> >> >> OSR is HIRING!! See http://www.osr.com/careers
>> >> >>
>> >> >> For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> >> http://www.osr.com/seminars
>> >> >>
>> >> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> >> http://www.osronline.com/page.cfm?name=ListServer
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > –
>> >> > Helder Daniel
>> >> > UALG - FCT
>> >> > DEEI
>> >> >
>> >> > http://w3.ualg.pt/~hdaniel
>> >> >
>> >> > —
>> >> > NTDEV is sponsored by OSR
>> >> >
>> >> > Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev
>> >> >
>> >> > OSR is HIRING!! See http://www.osr.com/careers
>> >> >
>> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> > http://www.osr.com/seminars
>> >> >
>> >> > To unsubscribe, visit the List Server section of OSR Online at
>> >> > http://www.osronline.com/page.cfm?name=ListServer
>> >>
>> >>
>> >>
>> >> —
>> >> NTDEV is sponsored by OSR
>> >>
>> >> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>> >>
>> >> OSR is HIRING!! See http://www.osr.com/careers
>> >>
>> >> For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> http://www.osr.com/seminars
>> >>
>> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> http://www.osronline.com/page.cfm?name=ListServer
>> >>
>> >>
>> >
>> >
>> > –
>> > Helder Daniel
>> > UALG - FCT
>> > DEEI
>> >
>> > http://w3.ualg.pt/~hdaniel
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>> >
>> > OSR is HIRING!! See http://www.osr.com/careers
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>
>
> –
> Helder Daniel
> UALG - FCT
> DEEI
>
> http://w3.ualg.pt/~hdaniel
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>