I am pretty new in this list and did not found what I was looking for on
existing threads.
I use a motherboard that has a watchdog, the way it has to be called is
with Bios interrupt call routines.
In ms-dos, I can access it with the following assembler code, and it works
fine :
mov ah, 6fh
mov al, 02h
mov bl, 0ah
int 15h
When I try the same in my kmdf driver, windows restarts immediatly. To do
so, I just put this code :
__asm {
mov ah, 6fh
mov al, 02h
mov bl, 0ah
int 15h
}
I have no other way to call this watchdog…
I saw that in x86_64, there was a function called x86BiosExecuteInterrupt
to do so, but I am in a 32 bits x86 system.
Anyone knows how to deal with this?
Other thing is that I have to deal with Win 2000 and winXP plateforms for
my driver.
The only winddk available in download page is intended to work only with
XP and higher OSes.
I thought (but maybe i am wrong) that XP and 2000 driver were compatible.
Is that the case?
Even if it is 2012, x86_64 driver api seems to handle this very very old feature with x86BiosExecuteInterrupt function.
The driver I want to write exists, but I badly can’t use it because its installation fails on some motherboard versions that I need to take into account, because of fonctionnalities I don’t need that are not present…
That’s why I am trying to write on my own another one. Being confident that it is possible to.
When you mention the ACPI BIOS code, you mean changing BIOS firmware?
Ah, no. That is not a public API. Nothing says that it works, or that it STILL works even if it once did back in 2007, or when the OS expects you to call it, or when the OS will support you callubg it. I *suspect* (I haven’t looked this up) that this function is used for doing video BIOS calls during OS startup. But, like I said, that’s a guess.
You don’t want to do this. Seriously. And if you THINK you do, you’re creating a driver that’s not reliable and shouldn’t be distributed to customers. Ever. If you STILL think you do, spend some time with Google and figure it out.
Yes.
Let’s back up for a minute. WHAT is it that you’re trying to accomplish?? Is there NOT a better way to do what you want, other than use some ancient, unsupported, architecturally aberrant interface?
wrote in message news:xxxxx@ntdev… > > Even if it is 2012, x86_64 driver api seems to handle this very very old > feature with x86BiosExecuteInterrupt function.
I need to restart PC in case of windows freeze. It happens sometimes (maybe once a month with more than 100 computers). The fact is we cannot reproduce the problem, we have no way to correct it for sure. The only issue we have is at least to restart the computer : the problem will not be solved but it will make things work better.
We discovered recently that the motherboard had an inboard watchdog. We tried it with msdos in assembler to be sure all the motherboards versions handled it, and it is the case. So I want now to write a driver.
Is it really such a bad thing making bios interrupt calls? You seems to know it is not good, but why? Why does it will be not reliable?
I googled a lot but didn’t find, I even asked the manufacturer for driver code, but no response yet.
I use a motherboard that has a watchdog, the way it has to be called
is with Bios interrupt call routines.
In ms-dos, I can access it with the following assembler code, and it
works fine :
mov ah, 6fh
mov al, 02h
mov bl, 0ah
int 15h
That’s 16-bit real-mode code, as is the BIOS.
When I try the same in my kmdf driver, windows restarts immediatly. To
do so, I just put this code :
__asm {
mov ah, 6fh
mov al, 02h
mov bl, 0ah
int 15h
}
And you’re trying to call it from a 32-bit protect mode environment. If
you really expected this to work, then you have a rather large amount of
reading to do.
Other thing is that I have to deal with Win 2000 and winXP plateforms
for my driver.
The only winddk available in download page is intended to work only
with XP and higher OSes.
I thought (but maybe i am wrong) that XP and 2000 driver were
compatible. Is that the case?
I’m very surprised you have a requirement for Win 2000. That system was
released 13 years ago, and it has not aged well. XP is provably better.
There are subtle changes in each release of the operating system. In
general, drivers built for XP will often work in 2000 without
modification (except for the system version marker in the PE header).
The kernel streaming drivers I write will actually still load and run in
Windows 98, although I haven’t tried that in a while.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Even if it is 2012, x86_64 driver api seems to handle this very very old feature with x86BiosExecuteInterrupt function.
The driver I want to write exists, but I badly can’t use it because its installation fails on some motherboard versions that I need to take into account, because of fonctionnalities I don’t need that are not present…
That’s why I am trying to write on my own another one. Being confident that it is possible to.
You are the only confident one in this conversation.
There is an undocumented kernel API called Ke386CallBios that can do
this. It’s the same API that VideoPortInt10 in videoprt.sys uses when a
display driver miniport needs to call into the VESA BIOS to set the mode
on your graphics card. It is not trivial to use, because you have to
map in enough of low memory in the right spots for it to see the BIOS to
begin with. You may need to reverse engineer videoprt.sys to figure it
all out.
In the long run, it would probably be more efficient for you to
disassemble the BIOS to figure out what that BIOS call actually does,
and then reimplement that in your driver. It’s probably only poking a
couple of I/O ports.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
See also the source code at http://www.geoffchappell.com/studies/windows/km/hal/api/x86bios/fwmemmap.htm
for an example of how to use the x86Bios emulator. The emulator, which
is implemented on Windows Vista and later, is quite full featured. It
also offers a lot of ways to crash the system. You will just have to
test it on your motherboards and see what happens.
It happens sometimes (maybe once a month with more than 100 computers). The fact is we cannot reproduce the problem, we have no way to correct it for sure.
[/quote]
I realize this is DIFFICULT, but you really DO want to find the problem and fix it at the root cause.
Buy a box that sits on the LAN and monitors the Windows system, and reboots it (via power off / power on) if it detects a failure. They work great and they’re cheap. FAR cheaper than even the time you’ve spent so far on NTDEV. Yes, even if you have to pay for 100 of them (in fact, you won’t… if you get one like the one we have here for our public systems, each device can support several target machines).
There are even devices you can plug into a USB port on the system that you can wire to the reset header on the motherboard.
If you look at it from a purely engineering perspective, is not something like this a better solution than writing some code – using undocumented interfaces – that introduces its OWN instabilities into your system? You want to fix a hang by introducing something that has the chance to create more problems than the one you’re fixing. This does not make sense to me.
Yes, it is. It’s beyond bad. It’s plain silly.
BIOS calls require real mode operation. The OS is not running in real mode. These BIOS calls are not used by Windows, except during legacy boot to read the disk and write to the display.
Please don’t attempt to use the x86Bios emulator. Doing so without properly participating in the (internal, non-exposed) synchronization mechanisms associated with it may result in catastrophic problems. It is not designed for general purpose use like this.
Software that does this sort of thing might be prone to causing problems like random system hangs or other difficult to debug malfunctions (which, I will note, is exactly the sort of problem that the OP is trying to work around!).
S (Msft)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of George M. Garner Jr.
Sent: Friday, September 07, 2012 11:04 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Bios interrupt call
See also the source code at http://www.geoffchappell.com/studies/windows/km/hal/api/x86bios/fwmemmap.htm
for an example of how to use the x86Bios emulator. The emulator, which is implemented on Windows Vista and later, is quite full featured. It also offers a lot of ways to crash the system. You will just have to test it on your motherboards and see what happens.
Ha! Ha! x86BiosCall issues a bugcheck if a bios call already is in
progress. The OP could always revert one processor to real mode and
roll his own x86BIOSCall. There is a paper by Julien Vanegue, “Hacking
the Preboot eXecution Environment. Using the BIOS network stack for
other purposes” (BACON 2008), which describes generally the process.
You save the 32 or 64-bit protected mode context, restore the IVT, jump
to 16-bit protected mode and finally to 16-bit real mode. Then you make
the BIOS call and reverse the process to return to protected mode. Most
importantly, you need to make sure that the BIOS code that you want to
execute is resident in the first MiB of memory before you try to execute
it. It may not be. While the process is complex, it can be done. Or
you could simply withdraw one processor core from the OS and keep it in
real mode.
Are you sure that this watchdog timer isn’t already exposed by ACPI?
Excellent advice, then, that you gave him previously to try this method.
You’re not seriously suggesting to the OP that he should do this on a production system, right? And, if not, why give him such hazardous advice: "Well, you could always make your own ammunition. There’s a paper on how you can make cartridge casings from rolled-up paper that I read somewhere. Just roll it up and pour in some powder and tape the bullet to the top. To fire, merely strike the primer with a hammer. While the process is complex, it can be done. "
He’s trying to fix a random hang in a group of long-running machines. Perhaps you could give him some advice that might actually help him solve his problem.
<american_cultural_reference_for_the_fairly_old> I can’t find no building to jump off, guess I’ll go f$ck with Jim Brown - R. Pryor < /american_cultural_reference_for_the_fairly_old>
-----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com Sent: Saturday, September 08, 2012 9:46 AM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Bios interrupt call
Excellent advice, then, that you gave him previously to try this method.
You’re not seriously suggesting to the OP that he should do this on a production system, right? And, if not, why give him such hazardous advice: "Well, you could always make your own ammunition. There’s a paper on how you can make cartridge casings from rolled-up paper that I read somewhere. Just roll it up and pour in some powder and tape the bullet to the top. To fire, merely strike the primer with a hammer. While the process is complex, it can be done. "
He’s trying to fix a random hang in a group of long-running machines. Perhaps you could give him some advice that might actually help him solve his problem.
There are mobos that have built-in watchdogs, and vendor provides a driver
or API to use that from a WIndows program.
Though, this may not be helpful to the OP.
– pa
Wow, so much advices… Thanks a lot to everyone.
Seems to be hard to do what i need… And bios needs to handle the code in the first Mb.
I Will check it out on monday.
I found ways to disassemble bios code by googling a little, this seems to be easy. I hope i can find an alternative way for calling watchdog.
Regards
?ric
In his initial post the OP presents a few lines of 16-bit assembly code
which results in an immediate reboot when executed in 32-bit protected
mode. Reading the Venegue article will provide the OP with a better
understanding of what is actually required, from a technical
perspective, to make those few lines of code work in a 32-bit protected
mode environment. According to Venegue’s description it requires about
400 lines of assembly code to make the round trip. I do not know if the
OP will want or be able to write those 400 lines of assembly code.
However, it does not hurt to provide him with a technical understanding
of what it would take so that he can properly evaluate the option.
The x86BiosCall option is a simpler approach. It’s principle
disadvantage appears to be that, without access to the internal
synchronization mechanisms used by the OS, the system will reboot on
occasion when it wouldn’t otherwise need to. However, based on the OP’s
description of the problem an occasional reboot may be an acceptable
risk in this scenario. The synchronization issue, which Skywing has
properly noted) is a soluble problem even without access to the internal
Windows synchronization mechanisms (or at least it may be depending on
empirical results). I did not suggest that the OP implement this option
in a production setting. I suggested that the OP try the option in a
test environment and see what happens. The first question is whether
the approach will work at all in this application. Once the OP has this
knowledge he will be in a better position to evaluate the benefits
versus risks of the approach and ways to mitigate the risks to an
acceptable level.
Based upon the description of the problem this does not appear to be
intended for use in systems designed for general public use. Rather,
the OP has a finite set of motherboards that are designed for some LOB
application. We do not know what this application is and therefore are
not in a position to evaluate the benefits versus risks of the available
options. The OP is the only one who is in a position to do that. In
responding to this thread I assume that the OP is a reasonably competent
professional who will be able to evaluate the benefits and risks if he
is presented with sufficient knowledge. I have not seen anything in his
posts that would suggest the contrary.
An ideal solution might be for the OP to design his own BIOS, as you
have suggested. However, in business the ideal solution is not always
practicable. Sometimes you have to choose among less than desirable
options. In any event, if the OP were looking for religion he would
have much rather gone to church. I doubt that he was looking for that
when he posted a message here.
It’s beyond evil. Let me expand what Peter said a bit…
Windows does a lot of things before and right after switching to protected
mode. To get what some suggested sort of right, one needs to undo them and
redo them. For production use on Windows environment, it would be a huge
undertaking even for highly sophisticated system platform sw developer.
Some RM interrupt is very expensive that would exercise a big portion of PC
platform. To get it right most of time, one would need to setup the PC
system to what real mode environment expects(setting 8259,8253, 8237, IDE
controller etc for real mode op. If if you have access to BIOS src code,
take look at how it initialized a MB you know what I mean.).
400 lines of assembly code to demonstrate how to invoke BIOS from a WELL
CONTROLLED SIMPLE PROTECTED MODE environment is about right. By SIMPLE
PROTECTED MODE env, I mean it doesn’t use advanced protected mode features
like local apic, ioapic, tpr, SMP setup, disabling legacy USB simulation
etc.
It’s easier to invoke BIOS when the OS has not fully setup its PM
environment hence has not heavily tainted the hw state left over from real
mode, i.e. calling int 10h during early boot before starting IHV’s video
driver. Once the platform is fully setup, it’s not designed to nuke it and
bring it back from real mode later except for resume from hibernation.
I strongly suggest the OP not going this path unless he has infinite amount
of time and patience and is properly equipped. Be sure to get a hardware
ICE and ice’ble motherboard with you.
Calvin
P.S.
I have done this in my own protected mode environment as I know exactly
what my PM environment expects and what RM interrupts I will be calling.
Still not surprise to hear some complains your stuff doesn’t work on model
X from vendor Y when I was doing Z once upon a time. BIOS is badly
regulated and extremely hacky. Look at how many lines of assembly code a
BIOS sets up A20 alone you get the picture.
Calling BIOS int10h is not even intended to be used by IHV’s video
driver.
You would get a bugcheck if you are lucky. What you describe isn’t sufficient to do what the thread is about safely. If you are unlucky, far more insidious problems than a bugcheck will result should one attempt to make real mode BIOS calls willy-nilly…
Remember that the real mode BIOS code expects to be able to have exclusive access to hardware resources in the environment that it programmed them in during system startup. Making real mode calls to it while the rest of the system and its device drivers have taken over ownership of these resources is a recipe for numerous flavors of disaster outside of some very, very limited and special circumstances.
S (Msft)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of George M. Garner Jr.
Sent: Saturday, September 08, 2012 8:05 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Bios interrupt call
Ha! Ha! x86BiosCall issues a bugcheck if a bios call already is in progress. The OP could always revert one processor to real mode and roll his own x86BIOSCall. There is a paper by Julien Vanegue, “Hacking the Preboot eXecution Environment. Using the BIOS network stack for other purposes” (BACON 2008), which describes generally the process.
You save the 32 or 64-bit protected mode context, restore the IVT, jump to 16-bit protected mode and finally to 16-bit real mode. Then you make the BIOS call and reverse the process to return to protected mode. Most importantly, you need to make sure that the BIOS code that you want to execute is resident in the first MiB of memory before you try to execute it. It may not be. While the process is complex, it can be done. Or you could simply withdraw one processor core from the OS and keep it in real mode.
Are you sure that this watchdog timer isn’t already exposed by ACPI?
