Hooking the RTC periodic Interrupt

OSR_Community_User · July 18, 2007, 12:28pm

I want to use the periodic Interrupt of the RTC RealTimeClock
(This includes changing it’s frequency)

It seems like that using the OS way to connect to an interrupt does not work for IRQ8 (RTC) since the OS is allready using it.
( The call to HalGetInterruptVector returns 0 and the subsequent IOConnectInterrupt fails)

So my only alternative seems to be hooking the idt directly.

So here are my Questions:
Is there a way around the HalGetInterruptVector problem so I can use the OS mechanisms to hook the RTCInt?

What exactly is the RTC used for in the OS (on diffrent platforms)?
I have some test code that changes the RTC frequency and run it on the following 3 machines:
-singleCore/PIC8259 system
-singleCore/APIC system
-MultiCore/APIC system

In all 3 cases I get diffrent results:
-singleCore/PIC system: changing the frequency is okay No effect on the OS
-singleCore/APIC system: changing the frequency causes the clock in the trayBar to go faster
-Multicore/APIC system: changing the frequency causes the system to crash.

Gianluca_Varenni · July 18, 2007, 12:56pm

Why are you trying to connect to that interrupt?

You will not find much help on this mailing list wrt hooking the IDT. And
trying to change its frequency… that is even worse. The result will just
be screwing up the OS completely.

Have a nice day
GV

–
Gianluca Varenni, Windows DDK MVP

CACE Technologies
http://www.cacetech.com

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, July 18, 2007 9:29 AM
Subject: [ntdev] Hooking the RTC periodic Interrupt

>I want to use the periodic Interrupt of the RTC RealTimeClock
> (This includes changing it’s frequency)
>
> It seems like that using the OS way to connect to an interrupt does not
> work for IRQ8 (RTC) since the OS is allready using it.
> ( The call to HalGetInterruptVector returns 0 and the subsequent
> IOConnectInterrupt fails)
>
> So my only alternative seems to be hooking the idt directly.
>
> So here are my Questions:
> Is there a way around the HalGetInterruptVector problem so I can use the
> OS mechanisms to hook the RTCInt?
>
> What exactly is the RTC used for in the OS (on diffrent platforms)?
> I have some test code that changes the RTC frequency and run it on the
> following 3 machines:
> -singleCore/PIC8259 system
> -singleCore/APIC system
> -MultiCore/APIC system
>
> In all 3 cases I get diffrent results:
> -singleCore/PIC system: changing the frequency is okay No effect on the OS
> -singleCore/APIC system: changing the frequency causes the clock in the
> trayBar to go faster
> -Multicore/APIC system: changing the frequency causes the system to crash.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · July 18, 2007, 1:06pm

This is a pretty hostile action from the OS’s point of view. What do
you want to do with it? The RTC is used for a lot of stuff, and you
definitely don’t want to screw with it, and on x64 platforms what you
are doing will not work unless you workaround PatchGuard.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@siemens.com
Sent: Wednesday, July 18, 2007 12:29
To: Windows System Software Devs Interest List
Subject: [ntdev] Hooking the RTC periodic Interrupt

I want to use the periodic Interrupt of the RTC RealTimeClock
(This includes changing it’s frequency)

It seems like that using the OS way to connect to an interrupt does not
work for IRQ8 (RTC) since the OS is allready using it.
( The call to HalGetInterruptVector returns 0 and the subsequent
IOConnectInterrupt fails)

So my only alternative seems to be hooking the idt directly.

So here are my Questions:
Is there a way around the HalGetInterruptVector problem so I can use the
OS mechanisms to hook the RTCInt?

What exactly is the RTC used for in the OS (on diffrent platforms)?
I have some test code that changes the RTC frequency and run it on the
following 3 machines:
-singleCore/PIC8259 system
-singleCore/APIC system
-MultiCore/APIC system

In all 3 cases I get diffrent results:
-singleCore/PIC system: changing the frequency is okay No effect on the
OS
-singleCore/APIC system: changing the frequency causes the clock in the
trayBar to go faster
-Multicore/APIC system: changing the frequency causes the system to
crash.

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

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

Tim_Roberts · July 18, 2007, 2:08pm

xxxxx@siemens.com wrote:

I want to use the periodic Interrupt of the RTC RealTimeClock
(This includes changing it’s frequency)

No, you don’t really want to do this. Tell us what overall goal you are
trying to achieve, and we can suggest workable and maintainable ways to
achieve that goal.

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

OSR_Community_User · July 18, 2007, 3:36pm

Here is why I want to use the RTC (and can not use any other timer):
The RTC is the only timer that is driven by an independet Crystal. In our SW this is of importance. We need two independent timers with an independent clock.
PS: We could use some external clock to do that but that is not allowed in this game;)
I admit this sounds pretty crazy, but hey it’s my boss who sets the rules

So much for the why…
If I knew a little more what the RTC is used for under diffrent systems, this would be already very help full. I found out that on singleCore/PIC systems my code works pretty fine.
I hook the IDT with my RTCHandler, enable the RTC periodic Interrupts (was turned off by default)and great my handler gets called. I can change the frequency and everything is fine.

Now i run my code on a single core/APIC machine and suddenly i see that the OS already enabled the RTC interrupt during BootUp and when i change the RTC frequency my clock (trayIcon) goes faster. So this tells me the OS uses the RTC periodic interrupt where as on my old PIC machine it did not.

On a multicore system it’s the same the OS has allready enabled the periodic Interrupt and changing the frequency causes hang and/or bluescreen.

PS:I agree I don’t like the idea either but windows does not allow me to share the IRQ8

Tim_Roberts · July 18, 2007, 4:56pm

xxxxx@siemens.com wrote:

Here is why I want to use the RTC (and can not use any other timer):
The RTC is the only timer that is driven by an independet Crystal. In our SW this is of importance. We need two independent timers with an independent clock.

What’s the other timer?

PS: We could use some external clock to do that but that is not allowed in this game;)
I admit this sounds pretty crazy, but hey it’s my boss who sets the rules

Yep, my “loony” meter just pegged. I suspect this is simply a faulty
understanding of mathematics. It may be an independent crystal, but
it’s still synchronous, and it runs at such a slow clock rate that the
fact that it is separate is mostly irrelevant. Remember that each tick
of the PIT counter covers some 2,500 CPU cycles on a 3GHz CPU.

What’s the point? Are you trying to increase entropy for randomness?

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

OSR_Community_User · July 18, 2007, 4:56pm

I hear you on having to do what the boss wants, but perhaps he/she needs
to rethink what the cost of the requirement is, as this one is just not
going to go very well. Minimally, changing the RTC without Window’s
knowledge is not something that the kernel is planning on occurring. In
particular, some of the state information is cached by the HAL (like
frequency). What problems inconsistent values between actual RTC and
HAL values might cause, I have no idea, but it certainly doesn’t sound
like a stable setup. Also, Microsoft’s usage of the RTC with regards to
Universal Time has been the focus of much complaint from other vendors -
whether it is justified, I have no idea - and access to the RTC is
documented as “blocked io,” whatever that works out to be. That it
works on a PIC based machine is probably useless, unless you’re going to
run on some very old machines, as most everything is now based on ACPI,
which has it’s own contributions to the issue. This is not really my
thing, but I believe, minimally, this includes power management/wakeup,
as the whole thing is centered around the assumption that the RTC always
remains powered.

If forced to proceed with this one with changing the requirements or
adding some hardware, I would read my chipset documentation thoroughly.
There may be something in there that could help that would be less
hostile to Windows.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@siemens.com
Sent: Wednesday, July 18, 2007 15:38
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Hooking the RTC periodic Interrupt

Here is why I want to use the RTC (and can not use any other timer):
The RTC is the only timer that is driven by an independet Crystal. In
our SW this is of importance. We need two independent timers with an
independent clock.
PS: We could use some external clock to do that but that is not allowed
in this game;)
I admit this sounds pretty crazy, but hey it’s my boss who sets the
rules

So much for the why…
If I knew a little more what the RTC is used for under diffrent systems,
this would be already very help full. I found out that on singleCore/PIC
systems my code works pretty fine.
I hook the IDT with my RTCHandler, enable the RTC periodic Interrupts
(was turned off by default)and great my handler gets called. I can
change the frequency and everything is fine.

Now i run my code on a single core/APIC machine and suddenly i see that
the OS already enabled the RTC interrupt during BootUp and when i change
the RTC frequency my clock (trayIcon) goes faster. So this tells me the
OS uses the RTC periodic interrupt where as on my old PIC machine it did
not.

On a multicore system it’s the same the OS has allready enabled the
periodic Interrupt and changing the frequency causes hang and/or
bluescreen.

PS:I agree I don’t like the idea either but windows does not allow me to
share the IRQ8

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

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

Christiaan_Ghijselinck · July 18, 2007, 6:10pm

I think you are a bit too familiar with good old DOS stuff. Have you ever had the idea to write a little serial driver for a COM
port ? You install it on a free port , connect TX to RX and let it oscillate at baud rate frequencies . Don’t blame me if it won’t
work ; it’s just a 0:00 midnight idea and I’m tired.

Christiaan

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, July 18, 2007 9:38 PM
Subject: RE:[ntdev] Hooking the RTC periodic Interrupt

> Here is why I want to use the RTC (and can not use any other timer):
> The RTC is the only timer that is driven by an independet Crystal. In our SW this is of importance. We need two independent timers
> with an independent clock.
> PS: We could use some external clock to do that but that is not allowed in this game;)
> I admit this sounds pretty crazy, but hey it’s my boss who sets the rules
>
> So much for the why…
> If I knew a little more what the RTC is used for under diffrent systems, this would be already very help full. I found out that on
> singleCore/PIC systems my code works pretty fine.
> I hook the IDT with my RTCHandler, enable the RTC periodic Interrupts (was turned off by default)and great my handler gets
> called. I can change the frequency and everything is fine.
>
> Now i run my code on a single core/APIC machine and suddenly i see that the OS already enabled the RTC interrupt during BootUp and
> when i change the RTC frequency my clock (trayIcon) goes faster. So this tells me the OS uses the RTC periodic interrupt where as
> on my old PIC machine it did not.
>
> On a multicore system it’s the same the OS has allready enabled the periodic Interrupt and changing the frequency causes hang
> and/or bluescreen.
>
>
>
> PS:I agree I don’t like the idea either but windows does not allow me to share the IRQ8
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

anton_bassov · July 18, 2007, 11:33pm

> If I knew a little more what the RTC is used for under diffrent systems, this

would be already very help full.

Well, who holds you back from disassembling RTC interrupt handler on a system that uses it, i.e. the one with APIC HAL??? If you do it, you will see that, basically, it controls RTC hardware
via IO ports 0x70 and 0x71, and then updates the system time by KeUpdateSystemTime() call. One of the tasks of KeUpdateSystemTime() is requesting software interrupt 0x41. ISR for interrupt 0x41 is KiDispatchInterrupt() - this routine is responsible for handling DISPATCH_LEVEL software interrupts, and it executes DPC queue draining and context switches.

At this point you will realize that, by getting involved in the whole thing and changing RTC frequency, you are modifying one the most important parts of kernel functionality, and, hence,
are guaranteed to screw up the system.

Anton Bassov

OSR_Community_User · July 20, 2007, 1:56pm

Thanks Anton Bassov that cleared up things.
My coclusion is that depending what system you are running on (which HAL is used), the OS either uses the PITSystemTimer (IRQ0) or the RTCperiodic Interrupt(IRQ8) for it’s scheduling and DPC queue dispatching.
On older singlecore/PIC systems the OS uses the PIT and the RTC is free for use.
On pretty much all newer machines the OS uses the RTC and the PIT is free for use.

This explains also why windows does not allow to hook these IRQ’s with HalGetInterruptVector and IoConnectInterrupt for both of these IRQ’s. (HalGetInterruptVector returns 0).

This should be enough information to convince my boss that this is a bad idea?
Thanks again to all,
Robert

PS: To Christiaan Ghijselinck : Interesting idea.

OSR_Community_User · July 20, 2007, 5:40pm

Robert,

Many years ago, I used to work in PSS. One of my customers tried to =
hook the RTC interrupt. He actually appeared to accomplish it, but one =
of the really weird side effects was that data would be corrupted when =
an IOCtl used METHOD_BUFFERED. This was very intermittent. I was able =
to replicate it, but no developer wanted to touch it as the method they =
used to hook the interrupt and what they were doing was definitely not =
supported.

In other words, they thought they had succeeded, but customers =
eventually complained about data corruption. Finding this before =
shipping, as it was completely unexpected considering how much the I/O =
Manager is tested, would have taken a lot of luck and a huge test =
department.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com =
[mailto:xxxxx@lists.osr.com] On Behalf Of =
xxxxx@siemens.com
Sent: Friday, July 20, 2007 1:57 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Hooking the RTC periodic Interrupt

Thanks Anton Bassov that cleared up things.
My coclusion is that depending what system you are running on (which HAL =
is used), the OS either uses the PITSystemTimer (IRQ0) or the =
RTCperiodic Interrupt(IRQ8) for it’s scheduling and DPC queue =
dispatching.
On older singlecore/PIC systems the OS uses the PIT and the RTC is free =
for use.
On pretty much all newer machines the OS uses the RTC and the PIT is =
free for use.

This explains also why windows does not allow to hook these IRQ’s with =
HalGetInterruptVector and IoConnectInterrupt for both of these IRQ’s. =
(HalGetInterruptVector returns 0).

This should be enough information to convince my boss that this is a bad =
idea?
Thanks again to all,=20
Robert

PS: To Christiaan Ghijselinck : Interesting idea.=20
=20

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

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

__________ NOD32 2410 (20070720) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com