Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Intel interrupt 15 - thermal?
1,059 views
Skip to first unread message
James Harris
Sep 3, 2015, 6:50:38 AM9/3/15
to
Anyone heard of interrupt 15? I hadn't. In the video below Andrew
Tanenbaum mentions it as being generated when a CPU gets too hot.
I checked a recent Intel manual and they still show CPU interrupt 15 as
reserved, as they did on the 80386.
For good measure I checked interrupt 21 too, in case Tanenbaum meant hex
15. Intel show interrupt 21 as reserved too.
Perhaps he meant interrupt 15 on the PICs rather than on the CPU but he
says he was not catching the interrupt 15 in Minix and I suspect he
would have done if it was on the PICs.
Anyway, see what you think. His comments are from 2:00 in the following
video for about 45 seconds.
https://www.youtube.com/watch?v=86_BkFsb4eI
Could he have meant the PICs? Any of you catching CPU interrupt 0x15?
Have you ever seen it trigger? Have you ever even heard of it?
James
Tanenbaum mentions it as being generated when a CPU gets too hot.
I checked a recent Intel manual and they still show CPU interrupt 15 as
reserved, as they did on the 80386.
For good measure I checked interrupt 21 too, in case Tanenbaum meant hex
15. Intel show interrupt 21 as reserved too.
Perhaps he meant interrupt 15 on the PICs rather than on the CPU but he
says he was not catching the interrupt 15 in Minix and I suspect he
would have done if it was on the PICs.
Anyway, see what you think. His comments are from 2:00 in the following
video for about 45 seconds.
https://www.youtube.com/watch?v=86_BkFsb4eI
Could he have meant the PICs? Any of you catching CPU interrupt 0x15?
Have you ever seen it trigger? Have you ever even heard of it?
James
James Harris
Sep 3, 2015, 1:15:41 PM9/3/15
to
"James Harris" <james.h...@gmail.com> wrote in message
news:ms98ig$6ar$1...@dont-email.me...
> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
> Tanenbaum mentions it as being generated when a CPU gets too hot.
>
> I checked a recent Intel manual and they still show CPU interrupt 15
> as reserved, as they did on the 80386.
>
> For good measure I checked interrupt 21 too, in case Tanenbaum meant
> hex 15. Intel show interrupt 21 as reserved too.
>
> Perhaps he meant interrupt 15 on the PICs rather than on the CPU but
> he says he was not catching the interrupt 15 in Minix and I suspect he
> would have done if it was on the PICs.
later - have facilities to generate interrupts (and lots of other stuff)
when either a CPU core or a die overheats. See the MSRs IA32_THERM_*
(for the core) and IA32_PACKAGE_THERM_* (for the die).
The mechanisms vary but, from what I have read, a CPU core overheat can
lead to an interrupt on the local APIC. What happens after that I
couldn't say. APIC interrupt handling is complex and I have never
figured it out. (Use of it is not necessary and AIUI it requires a lot
of work to set up.)
The local APIC mechanism has a way to generate an interrupt and set an
8-bit vector (if you are interested see the Local Vector Table for the
Thermal Sensor interrupt control fields). The package-level controls are
even more obscure. I can see that they can be set to generate interrupts
but not any way to control the interrupt number. Two other possibilities
occur to me: 1) the package-level thermal interrupt may use the same as
the local APIC one (though there would be more than one local APIC on
the die), and 2) the package-level thermal interrupt may only trigger an
SMI. Neither of those may be right.
Anyway, back to the local APIC vector. I have seen comments that it may
be set to 240, i.e. 0xf0. I cannot verify that but is it possible that
the upper nibble of that is, by default, mapped to the number Tanenbaum
mentions, 0xf?
Just some thoughts.
James
Rod Pemberton
Sep 3, 2015, 8:19:12 PM9/3/15
to
On Thu, 03 Sep 2015 06:50:36 -0400, James Harris <james.h...@gmail.com> wrote:
> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
> Tanenbaum mentions it as being generated when a CPU gets too hot.
>
> I checked a recent Intel manual and they still show CPU interrupt 15 as
> reserved, as they did on the 80386.
>
> For good measure I checked interrupt 21 too, in case Tanenbaum meant hex
> 15. Intel show interrupt 21 as reserved too.
>
> Perhaps he meant interrupt 15 on the PICs rather than on the CPU but he
> says he was not catching the interrupt 15 in Minix and I suspect he
> would have done if it was on the PICs.
>
> Anyway, see what you think. His comments are from 2:00 in the following
> video for about 45 seconds.
>
> [link]
> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
> Tanenbaum mentions it as being generated when a CPU gets too hot.
>
> I checked a recent Intel manual and they still show CPU interrupt 15 as
> reserved, as they did on the 80386.
>
> For good measure I checked interrupt 21 too, in case Tanenbaum meant hex
> 15. Intel show interrupt 21 as reserved too.
>
> Perhaps he meant interrupt 15 on the PICs rather than on the CPU but he
> says he was not catching the interrupt 15 in Minix and I suspect he
> would have done if it was on the PICs.
>
> Anyway, see what you think. His comments are from 2:00 in the following
> video for about 45 seconds.
>
...
> Could he have meant the PICs?
the second IDE interface.
However, I also have a note that IRQ 15h may be related to the
BIOS APM Suspend. Except, that APM was 1993, which may have
been 5 to 10 years after the timeframe A.T. was talking about.
No, I didn't and haven't checked the APM specification.
RBIL lists three things.
http://www.delorie.com/djgpp/doc/rbinter/ix/77.html
> Any of you catching CPU interrupt 0x15?
BIOS and DOS hook Int 0x15.
BIOS and DOS hook Int 0x0F.
BIOS hooks IRQ 15 (Int 0x77).
> Have you ever seen it trigger?
set of interrupts for all vectors, not just those your OS
needs, in order to trap it and/or any other spurious
interrupts. I doubt that most people would do that unless
they needed to trace all interrupts or confirm interrupts.
There is a way to find out. Remove the heat sink and
fans ... ;-)
Of course, during the stated timeframe, there were no
heatsinks on the processor. So, perhaps, you'll need
to add blow torch or heat gun to the mix? :-D
> Have you ever even heard of it?
Google search didn't find anything.
Have you considered that his recollection may be ...
inconsistent?
A.T., while he seemed coherent from the video, was
still 70 or so at the time of the video talking about
stuff recollected from memory which occurred three
decades earlier.
He also seems to have a slight penchant for telling
stories ... E.g., no MINIX, no Linux, no Android,
no smartphones, no servers, no billion dollar companies.
E.g., he could've started VMWare in the 1980's, etc.
History may have been different without his purported
sequence of events, but these things would likely still
have happened, in one form or another.
Have you considered that it was not an x86 interrupt?
The video starts with him talking about a VAX. Then,
he says he created a PC simulator since proto-MINIX was
crashing. While he said MINIX was for the IBM PC,
according to Wikipedia, the early releases supported
other processors, including the ARM which was also
available in a PC format during that era. And, he was
in the E.U. at the time (and still is), where ARM PCs
were popular. So, maybe, speculative, it was an ARM
PC, not an x86 PC? ...
Have you considered that it wasn't implemented on all
x86's or it was for a non-Intel x86?
It could've been an AMD or Cyrix or NEC V20/30 etc.
Those processors or limited implementation would explain
not being listed in the x86 manuals. Also, the x86 had
a number of obscure and specialty versions back then.
Of course, the early Minix source code is probably still
out there waiting for someone like you to read comments ...
Rod Pemberton
--
Just how many texting and calendar apps does humanity need?
Rod Pemberton
Sep 3, 2015, 8:20:48 PM9/3/15
to
On Thu, 03 Sep 2015 13:15:39 -0400, James Harris <james.h...@gmail.com> wrote:
> "James Harris" <james.h...@gmail.com> wrote in message
> news:ms98ig$6ar$1...@dont-email.me...
>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>>
>
> "James Harris" <james.h...@gmail.com> wrote in message
> news:ms98ig$6ar$1...@dont-email.me...
>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>>
>
> AFAICT certain Intel CPUs - at least some Pentium 4, Pentium M and
> later - have facilities to generate interrupts (and lots of other stuff)
> when either a CPU core or a die overheats. See the MSRs IA32_THERM_*
> (for the core) and IA32_PACKAGE_THERM_* (for the die).
These are well after the era he was talking about.
> later - have facilities to generate interrupts (and lots of other stuff)
> when either a CPU core or a die overheats. See the MSRs IA32_THERM_*
> (for the core) and IA32_PACKAGE_THERM_* (for the die).
But, that could be a clue to earlier support.
> The mechanisms vary but, from what I have read, a CPU core overheat
> can lead to an interrupt on the local APIC. What happens after that
> I couldn't say. APIC interrupt handling is complex and I have never
> figured it out. (Use of it is not necessary and AIUI it requires a
> lot of work to set up.)
> The local APIC mechanism has a way to generate an interrupt and set
> an 8-bit vector (if you are interested see the Local Vector Table for
> the Thermal Sensor interrupt control fields).
I.e., this ability to set an interrupt vector from a generated
interrupt could be used as another partial solution to the BIOS
reset issue you wanted solved. It would only work on APIC capable
machines, but that is every processor from 1993 onward.
> [...]
>
> Anyway, back to the local APIC vector. I have seen comments that
> it may be set to 240, i.e. 0xf0. I cannot verify that but is it
> possible that the upper nibble of that is, by default, mapped to
> the number Tanenbaum mentions, 0xf?
>
> Just some thoughts.
Again, there were no APICs back then, i.e., he said mid 1980's.
> Anyway, back to the local APIC vector. I have seen comments that
> it may be set to 240, i.e. 0xf0. I cannot verify that but is it
> possible that the upper nibble of that is, by default, mapped to
> the number Tanenbaum mentions, 0xf?
>
> Just some thoughts.
If the stated functionality is present, I'd suspect it was hardwired.
I.e., old feature, implemented early, preserved for decades, and
perhaps kept secret for proprietary reasons. I'd see no reason for
them to expose the info that this exists via register settings.
Intel was never happy about AMD being able to clone their processor.
Rod Pemberton
Sep 3, 2015, 8:41:47 PM9/3/15
to
On Thu, 03 Sep 2015 20:19:17 -0400, Rod Pemberton <b...@fasdfrewar.cdm> wrote:
> On Thu, 03 Sep 2015 06:50:36 -0400, James Harris <james.h...@gmail.com> wrote:
>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>>
> [...]
> On Thu, 03 Sep 2015 06:50:36 -0400, James Harris <james.h...@gmail.com> wrote:
>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>>
>
> Have you considered that it was not an x86 interrupt?
>
> The video starts with him talking about a VAX. Then,
> he says he created a PC simulator since proto-MINIX was
> crashing. While he said MINIX was for the IBM PC,
> according to Wikipedia, the early releases supported
> other processors, including the ARM which was also
> available in a PC format during that era. And, he was
> in the E.U. at the time (and still is), where ARM PCs
> were popular. So, maybe, speculative, it was an ARM
> PC, not an x86 PC? ...
Why did he even need an simulator? PCs, while expensive
> Have you considered that it was not an x86 interrupt?
>
> The video starts with him talking about a VAX. Then,
> he says he created a PC simulator since proto-MINIX was
> crashing. While he said MINIX was for the IBM PC,
> according to Wikipedia, the early releases supported
> other processors, including the ARM which was also
> available in a PC format during that era. And, he was
> in the E.U. at the time (and still is), where ARM PCs
> were popular. So, maybe, speculative, it was an ARM
> PC, not an x86 PC? ...
during the era, would've been abundant at a university,
like where he worked and works. If the code isn't working
on one machine, you try one of the other 3 dozen computers
in one of the half-dozen computer labs on campus. I.e.,
this implies to me that he was developing the code on
another platform, e.g., VAX, and cross-compiling or
cross-assembling or doing binary translation. In that
video, he said he had done binary translation and other
related work previously.
James Harris
Sep 4, 2015, 4:49:46 AM9/4/15
to
"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
news:op.x4ewifxjyfako5@localhost...
> On Thu, 03 Sep 2015 06:50:36 -0400, James Harris
> <james.h...@gmail.com> wrote:
>
>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>> Tanenbaum mentions it as being generated when a CPU gets too hot.
I have come up with some info, albeit based on a few assumptions. Rod,
> <james.h...@gmail.com> wrote:
>
>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>> Tanenbaum mentions it as being generated when a CPU gets too hot.
your comments on the age of Minix were very useful. AISI now I had been
looking in the wrong place for a deliberate thermal interrupt. (Such
could be expected from Tanenbaum's words. However, it seems more likley
to be an unintentional interrupt.)
According to
https://en.wikipedia.org/wiki/MINIX#MINIX_1.0
Minix 1.0 ran both on PCs (1981) and PC/ATs (1984). I have since seen a
Usenet post by Tanenbaum wherein he confirms this. And it seems likely
that the problem affected PCs, as mentioned below.
...
>> Could he have meant the PICs?
Technical Reference downloaded from classiccomputers.info the PC
interrupt vector listing includes these eight for the 8259:
8 Time of Day {TIMER-INT (FOOO:FEA5)}
9 Keyboard {KB_INT (FOOO:E987)}
A Unused
B Unused
C Unused (Reserved Communications)
D Unused
E Diskette {DISK_INT (FOOO:EF57)}
F Unused (Reserved Printer)
My guess is that he was talking about interrupt F on the PC and that
that was the one he had not included code to handle.
Rather than a deliberate interrupt for thermal reasons, then, he would
have been experiencing a spurious interrupt caused by or attributed to
heat. AIUI noise on any of the 8259's interrupt lines can cause a
spurious interrupt when the 8259 sees a transition which is not
maintained.
...
>> Any of you catching CPU interrupt 0x15?
>> Have you ever seen it trigger?
>
> No. I wasn't looking for it. You'd need to intall a full
> set of interrupts for all vectors, not just those your OS
> needs, in order to trap it and/or any other spurious
> interrupts. I doubt that most people would do that unless
> they needed to trace all interrupts or confirm interrupts.
something specific to handle them. ISTM better for an OS to *trap* all
256 so as to avoid the kind of problem that Tanenbaum was talking about.
Any vectors that do not have handlers can then at least be noted so that
something can tell later that a mysterious interrupt vector was invoked.
At least they won't go marching off trying to execute data as code in
uncharted memory...!
That is better than just assuming that a certain vector will never be
used, as Tanenbaum's problem illustrates. He said that Intel did not
specify that interrupt 15 could be called but they probably did say in
the 8259 datasheet that a spurious interrupt could be triggered. (I'm
pretty sure they do in the 8259A datasheet.)
In fairness, the IBM 5150 Technical Reference I got from
classiccomputers.info has a table at line 5745 and that doesn't include
a handler for interrupt F either. Tanenbaum may have initially copied
that code or simply relied on the BIOS to do something sensible.
...
> Have you considered that his recollection may be ...
> inconsistent?
>
> A.T., while he seemed coherent from the video, was
> still 70 or so at the time of the video talking about
> stuff recollected from memory which occurred three
> decades earlier.
>
> He also seems to have a slight penchant for telling
> stories ... E.g., no MINIX, no Linux, no Android,
> no smartphones, no servers, no billion dollar companies.
> E.g., he could've started VMWare in the 1980's, etc.
> History may have been different without his purported
> sequence of events, but these things would likely still
> have happened, in one form or another.
said that he lives in a bit of a fantasy world where usually he is hard
done by, and I wouldn't give his speculations above any credence. He
seems to be an effective technical communicator though. His OS books are
useful and very readable.
I think he is a clever programmer. I recall a comment of his that he
sits at night writing software to stave off boredom with the TV. I do a
lot of programming too, and for pleasure, it has to be said, but to me
it's hard work. He seems to do it easily and just for fun.
> Have you considered that it was not an x86 interrupt?
>
> The video starts with him talking about a VAX. Then,
> he says he created a PC simulator since proto-MINIX was
> crashing. While he said MINIX was for the IBM PC,
> according to Wikipedia, the early releases supported
> other processors, including the ARM which was also
> available in a PC format during that era. And, he was
> in the E.U. at the time (and still is), where ARM PCs
> were popular. So, maybe, speculative, it was an ARM
> PC, not an x86 PC? ...
http://download.minix3.org/previous-versions/simulator/
"This program is a simulator (i.e., an interpreter) for the IBM PC.
It has been tested on a VAX\(en11/750 running 4.1BSD, but since it is
entirely in
C, it should run on almost any 32\(enmachine with a C compiler and a
reasonable
UNIX system."
...
> Of course, the early Minix source code is probably still
> out there waiting for someone like you to read comments ...
floppy images but I don't think it's worth going to the trouble of
extracting the OS and sources. The info and speculations above are, I
think, a good enough answer for now.
James
James Harris
Sep 4, 2015, 4:58:40 AM9/4/15
to
"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
...
>> The local APIC mechanism has a way to generate an interrupt and set
>> an 8-bit vector (if you are interested see the Local Vector Table for
>> the Thermal Sensor interrupt control fields).
>
> Aren't you interested in this? I would think so.
> I.e., this ability to set an interrupt vector from a generated
> interrupt could be used as another partial solution to the BIOS
> reset issue you wanted solved. It would only work on APIC capable
> machines, but that is every processor from 1993 onward.
simulate a machine reboot once the OS is running. That seems more
reliable than anything else we have discussed.
...
> If the stated functionality is present, I'd suspect it was hardwired.
> I.e., old feature, implemented early, preserved for decades, and
> perhaps kept secret for proprietary reasons. I'd see no reason for
> them to expose the info that this exists via register settings.
> Intel was never happy about AMD being able to clone their processor.
supplier in order to get various contracts and that is possibly still
true. Their size relative to AMD means they don't have a lot to worry
about.
As for exposing internal details, they do publish great quantities of
info and their instruction set pages even tell competitors what RTL is
needed to encode the instructions!
James
wolfgang kern
Sep 4, 2015, 5:26:45 AM9/4/15
to
"James Harris" wrote:
> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
> Tanenbaum mentions it as being generated when a CPU gets too hot.
INT_15 is used by BIOS.
INT_0f is a reserved CPU generated exception, was perhaps once
reserved for thermal, but I never saw it in use at all.
IRQ_0f belongs to harddisks.
'APIC330: Thermal Local Vector Table Entry'
can be enabled and assigned to any of INT_20..FF.
> I checked a recent Intel manual and they still show CPU interrupt 15 as
> reserved, as they did on the 80386.
> For good measure I checked interrupt 21 too, in case Tanenbaum meant hex
> 15. Intel show interrupt 21 as reserved too.
> Perhaps he meant interrupt 15 on the PICs rather than on the CPU but he
> says he was not catching the interrupt 15 in Minix and I suspect he
> would have done if it was on the PICs.
> Anyway, see what you think. His comments are from 2:00 in the following
> video for about 45 seconds.
> https://www.youtube.com/watch?v=86_BkFsb4eI
> Could he have meant the PICs?
> Any of you catching CPU interrupt 0x15?
> Have you ever seen it trigger? Have you ever even heard of it?
__
wolfgang
Mike Gonta
Sep 4, 2015, 7:42:13 AM9/4/15
to
"James Harris" wrote:
> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
> Tanenbaum mentions it as being generated when a CPU gets too hot.
This is probably the once popular spurious interrupt 15 (0xF) the
> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
> Tanenbaum mentions it as being generated when a CPU gets too hot.
default IRQ 7 handler. Apparently much activity (getting too hot?) on
the 8259a (I once generated such spurious activity as a test by
increasing the timer frequency - IRQ 0) causes a spurious interrupt
on IRQ 7 (LPT1). One typical handler for such was to check to see if
the interrupt was "in service", if not, it could safely be ignored
(after completing with an EOI).
Mike Gonta
look and see - many look but few see
http://mikegonta.com
James Harris
Sep 4, 2015, 8:28:49 AM9/4/15
to
"Mike Gonta" <mike...@gmail.com> wrote in message
news:msc02h$2je$1...@speranza.aioe.org...
reply.
> (I once generated such spurious activity as a test by
> increasing the timer frequency - IRQ 0) causes a spurious interrupt
> on IRQ 7 (LPT1).
Why did that cause a spurious interrupt? My guess: the 8254ish PIT on
IRQ0 is not really an interrupting device; its output is a waveform and
it will therefore effectively 'deassert' its output when it is ready to
do so rather than once it has been 'serviced' by an interrupt
subroutine. As the PIT output is free-running, if the machine does not
process the previous interrupts quickly enough the PIT output could have
transitioned back to 'deasserted' state by the time the CPU told the
8259 that it was ready to service the interrupt, leading the 8259 to
treat it as spurious. Is that what you had in mind? That would be much
more likley in mode 2 (rate generator) than mode 3 (square wave). Or am
I mixing two things up...?
> One typical handler for such was to check to see if
> the interrupt was "in service", if not, it could safely be ignored
> (after completing with an EOI).
OK.
As a postscript to the main point of this post/thread here is a copy of
the BIOS listing from the IBM 5150 PC manual I mentioned earlier.
5745 ; ------------------------------------------
5746 ; THESE ARE THE VECTORS WHICH ARE MOVED INTO
5747 ; THE 8086 INTERRUPT AREA DURING POWER ON
5748 ;----------- -------- ----------------------
5749 VECTOR_TABLE LABEL WORD ; VECTOR TABLE FOR MOVE TO INTERRUPTS
5750
5751 DW OFFSET TIMER_INT ; INTERRUPT 8
5752 DW CODE
5753
5754 DW OFFSET KB_INT ; INTERRUPT 9
5755 DW CODE
5756
5757 DD 0 ; INTERRUPT A
5756 DD 0 ; INTERRUPT B
5759 DD 0 ; INTERRUPT C
5760 DD 0 ; INTERRUPT D
5761
5762 DW OFFSET DISK_INT ; INTERRUPT E
5763 DW COOE
5764
5765 DD 0 ; INTERRUPT F
5766
5767 DW OFFSET VIDEO_IO ; INTERRUPT 10H
5768 DW CODE
5769
5770 DW OFFSET EQUIPMENT ; INTERRUPT 11H
5771 DW CODE
5772
5773 DW OFFSET MEMORY_SIZE_DETERMINE ; INT 12H
5774 DW CODE
5775
5776 DW OFFSET DISKETTE_IO ; INTERRUPT 13H
5777 DW CODE
5778
5779 DW OFFSET RS232_IO ; INTERRUPT 14H
5780 DW CODE
5781
5782 DW OFFSET CASSETTE_IO ; INTERRUPT 15H
5783 DW CODE
5784
5785 DW OFFSET KEYBOARD_IO ; INTERRUPT 16H
5786 DW CODE
5787
5788 DW OFFSET PRINTER_IO ; INTERRUPT 17H
5789 DW CODE
... etc ...
This table is there to be copied to the IVT at startup but, note, it
does not contain any kind of handler for interrupt F (nor for some
others). If *IBM* did not include any kind of handler for that interrupt
then they did not expect spurious interrupts either and that is maybe
what led Tanenbaum to omit such handling from early Minix.
The IBM BIOS code above does not even have the jump address of a null
handler. An interrupt F on that would jump to 0:0 and try executing that
as code.
James
news:msc02h$2je$1...@speranza.aioe.org...
> "James Harris" wrote:
>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>
> This is probably the once popular spurious interrupt 15 (0xF) the
> default IRQ 7 handler. Apparently much activity (getting too hot?) on
> the 8259a
Good answer. That was the conclusion I came to too. See my earlier
>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>
> This is probably the once popular spurious interrupt 15 (0xF) the
> default IRQ 7 handler. Apparently much activity (getting too hot?) on
> the 8259a
reply.
> (I once generated such spurious activity as a test by
> increasing the timer frequency - IRQ 0) causes a spurious interrupt
> on IRQ 7 (LPT1).
IRQ0 is not really an interrupting device; its output is a waveform and
it will therefore effectively 'deassert' its output when it is ready to
do so rather than once it has been 'serviced' by an interrupt
subroutine. As the PIT output is free-running, if the machine does not
process the previous interrupts quickly enough the PIT output could have
transitioned back to 'deasserted' state by the time the CPU told the
8259 that it was ready to service the interrupt, leading the 8259 to
treat it as spurious. Is that what you had in mind? That would be much
more likley in mode 2 (rate generator) than mode 3 (square wave). Or am
I mixing two things up...?
> One typical handler for such was to check to see if
> the interrupt was "in service", if not, it could safely be ignored
> (after completing with an EOI).
As a postscript to the main point of this post/thread here is a copy of
the BIOS listing from the IBM 5150 PC manual I mentioned earlier.
5745 ; ------------------------------------------
5746 ; THESE ARE THE VECTORS WHICH ARE MOVED INTO
5747 ; THE 8086 INTERRUPT AREA DURING POWER ON
5748 ;----------- -------- ----------------------
5749 VECTOR_TABLE LABEL WORD ; VECTOR TABLE FOR MOVE TO INTERRUPTS
5750
5751 DW OFFSET TIMER_INT ; INTERRUPT 8
5752 DW CODE
5753
5754 DW OFFSET KB_INT ; INTERRUPT 9
5755 DW CODE
5756
5757 DD 0 ; INTERRUPT A
5756 DD 0 ; INTERRUPT B
5759 DD 0 ; INTERRUPT C
5760 DD 0 ; INTERRUPT D
5761
5762 DW OFFSET DISK_INT ; INTERRUPT E
5763 DW COOE
5764
5765 DD 0 ; INTERRUPT F
5766
5767 DW OFFSET VIDEO_IO ; INTERRUPT 10H
5768 DW CODE
5769
5770 DW OFFSET EQUIPMENT ; INTERRUPT 11H
5771 DW CODE
5772
5773 DW OFFSET MEMORY_SIZE_DETERMINE ; INT 12H
5774 DW CODE
5775
5776 DW OFFSET DISKETTE_IO ; INTERRUPT 13H
5777 DW CODE
5778
5779 DW OFFSET RS232_IO ; INTERRUPT 14H
5780 DW CODE
5781
5782 DW OFFSET CASSETTE_IO ; INTERRUPT 15H
5783 DW CODE
5784
5785 DW OFFSET KEYBOARD_IO ; INTERRUPT 16H
5786 DW CODE
5787
5788 DW OFFSET PRINTER_IO ; INTERRUPT 17H
5789 DW CODE
... etc ...
This table is there to be copied to the IVT at startup but, note, it
does not contain any kind of handler for interrupt F (nor for some
others). If *IBM* did not include any kind of handler for that interrupt
then they did not expect spurious interrupts either and that is maybe
what led Tanenbaum to omit such handling from early Minix.
The IBM BIOS code above does not even have the jump address of a null
handler. An interrupt F on that would jump to 0:0 and try executing that
as code.
James
wolfgang kern
Sep 4, 2015, 2:30:38 PM9/4/15
to
James Harris and Mike Gonta wrote
>>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>> This is probably the once popular spurious interrupt 15 (0xF) the
>> default IRQ 7 handler. Apparently much activity (getting too hot?) on
>> the 8259a
> Good answer. That was the conclusion I came to too. See my earlier
> reply.
>> (I once generated such spurious activity as a test by
>> increasing the timer frequency - IRQ 0) causes a spurious interrupt
>> on IRQ 7 (LPT1).
early non-DOS non M$ OS as a first action because of the obvious
interference with CPU-generated exeptions in that range already in
realmode. MY OS and it's premature DOS-extenders did it by relocating
IRQ_0..7 to INT_50 and IRQ_8..F to INT_58..5F like many others did.
> Why did that cause a spurious interrupt? My guess: the 8254ish PIT on
> IRQ0 is not really an interrupting device; its output is a waveform and
> it will therefore effectively 'deassert' its output when it is ready to
> do so rather than once it has been 'serviced' by an interrupt
> subroutine. As the PIT output is free-running, if the machine does not
> process the previous interrupts quickly enough the PIT output could have
> transitioned back to 'deasserted' state by the time the CPU told the
> 8259 that it was ready to service the interrupt, leading the 8259 to
> treat it as spurious. Is that what you had in mind? That would be much
> more likley in mode 2 (rate generator) than mode 3 (square wave). Or am
> I mixing two things up...?
you messed up either with timing or your IRQ-respond code was inable
to allow nested IRQ, or more worse you made the IRQ-routine call the
event-handler before other IRQs were reenabled and accepted.
for being accessed aside from VBE-PM32 support.
> 5769
> 5770 DW OFFSET EQUIPMENT ; INTERRUPT 11H
> 5771 DW CODE
> 5772
> 5773 DW OFFSET MEMORY_SIZE_DETERMINE ; INT 12H
> 5774 DW CODE
> 5775
> 5776 DW OFFSET DISKETTE_IO ; INTERRUPT 13H
> 5777 DW CODE
> 5778
> 5779 DW OFFSET RS232_IO ; INTERRUPT 14H
> 5780 DW CODE
> 5781
> 5782 DW OFFSET CASSETTE_IO ; INTERRUPT 15H
> 5783 DW CODE
> 5784
> 5785 DW OFFSET KEYBOARD_IO ; INTERRUPT 16H
> 5786 DW CODE
> 5787
> 5788 DW OFFSET PRINTER_IO ; INTERRUPT 17H
> 5789 DW CODE
> ... etc ...
you enter PM anyway.
> This table is there to be copied to the IVT at startup but, note, it
> does not contain any kind of handler for interrupt F (nor for some
> others). If *IBM* did not include any kind of handler for that interrupt
> then they did not expect spurious interrupts either and that is maybe
> what led Tanenbaum to omit such handling from early Minix.
Spurious Interrupts can only occure if no handlers for existing IRQs
are defined or if this handlers eat too much time...
> The IBM BIOS code above does not even have the jump address of a null
> handler. An interrupt F on that would jump to 0:0 and try executing that
> as code.
almost all BIOS does it, point to an EOI-only routine.
Today we have a standard IRQ/EXCeption layout:
INT0=EXC0: DIV0
_1 : DEBUG
_2 : NMI
_3 : Breakpt (special INT3)
_4 : OV (caused by INTO)
_5 : BOUND (caused by BOUND)
_6 : illegal code
_7 : x087 errors
_8 : Double Fault
_9 : x387 error
-A : invalid TSS
_B : SEG-Fault
_C : Stack-Fault
_D : General (all that arent covered elsewhere)
_E : Page Fault
_F : reserved (perhaps once meant for thermal issues?)
_10 : maskable 487 errors
_11 : Alignment Fault (if set to)
_12 : Machine Check Excptions (if enabled)
_13 : SIMD errors (if enabled)
in true RealMode we got only _0.._D and instead of the above:
_8 ; IDT-limit exceeded
_C ; stack seg-overrun
_D ; SEG-overrun
The problem always was the concurrence between exceptions and
HW-created interrupts in the range of INT08..0F.
All decent OS (exluding M$-DOS) know it and relocate the PIC.
__
wolfgang
James Harris
Sep 4, 2015, 4:43:47 PM9/4/15
to
"wolfgang kern" <now...@never.at> wrote in message
news:msco08$26s$1...@speranza.aioe.org...
...
> The problem with INT_08..0F working on IRQ_0..7 was eliminated by
> early non-DOS non M$ OS as a first action because of the obvious
> interference with CPU-generated exeptions in that range already in
> realmode. MY OS and it's premature DOS-extenders did it by relocating
> IRQ_0..7 to INT_50 and IRQ_8..F to INT_58..5F like many others did.
instead of 0x20 or 0xa0 etc?
...
> What would a spurious (hardware generated) interrupt mean ?
> you messed up either with timing or your IRQ-respond code was inable
> to allow nested IRQ, or more worse you made the IRQ-routine call the
> event-handler before other IRQs were reenabled and accepted.
...
>> This table is there to be copied to the IVT at startup but, note, it
>> does not contain any kind of handler for interrupt F (nor for some
>> others). If *IBM* did not include any kind of handler for that
>> interrupt then they did not expect spurious interrupts either and
>> that is maybe what led Tanenbaum to omit such handling from early
>> Minix.
>
> Your listing looks like out of the museum :)
> Spurious Interrupts can only occure if no handlers for existing IRQs
> are defined or if this handlers eat too much time...
>> The IBM BIOS code above does not even have the jump address of a null
>> handler. An interrupt F on that would jump to 0:0 and try executing
>> that as code.
>
> Any unassigned IRQ 'shall not' point to 0:0, it should and almost all
> BIOS does it, point to an EOI-only routine.
once copied.)
> Today we have a standard IRQ/EXCeption layout:
>
> INT0=EXC0: DIV0
> _1 : DEBUG
> _2 : NMI
> _3 : Breakpt (special INT3)
> _4 : OV (caused by INTO)
> _5 : BOUND (caused by BOUND)
> _6 : illegal code
> _7 : x087 errors
> _8 : Double Fault
> _9 : x387 error
> -A : invalid TSS
> _B : SEG-Fault
> _C : Stack-Fault
> _D : General (all that arent covered elsewhere)
> _E : Page Fault
> _F : reserved (perhaps once meant for thermal issues?)
mentioned look like they were homed elsewhere. From what we have
discussed I haven't seen any link between thermal issues and the CPU's
use of int 0x0f.
> _10 : maskable 487 errors
So you have three different x87 vectors...?
> _11 : Alignment Fault (if set to)
> _12 : Machine Check Excptions (if enabled)
> _13 : SIMD errors (if enabled)
>
> in true RealMode we got only _0.._D and instead of the above:
> _8 ; IDT-limit exceeded
> _C ; stack seg-overrun
> _D ; SEG-overrun
>
> The problem always was the concurrence between exceptions and
> HW-created interrupts in the range of INT08..0F.
if they share a vector? Of course they *should* be kept separate but
isn't the main problem one of performance?
> All decent OS (exluding M$-DOS) know it and relocate the PIC.
to keep backward compatiblity.
James
Mike Gonta
Sep 4, 2015, 6:00:02 PM9/4/15
to
"wolfgang kern" wrote:
>>>> James Harris wrote:
>>> Mike Gonta wrote:
for 32 bit protected mode not 16 bit real mode. The early Minix was only
RM16 (the same as DOS).
>> Why did that cause a spurious interrupt? My guess: the 8254ish PIT on
>> IRQ0 is not really an interrupting device; its output is a waveform and
>> it will therefore effectively 'deassert' its output when it is ready to
>> do so rather than once it has been 'serviced' by an interrupt subroutine.
>> As the PIT output is free-running, if the machine does not process the
>> previous interrupts quickly enough the PIT output could have transitioned
>> back to 'deasserted' state by the time the CPU told the 8259 that it was
>> ready to service the interrupt, leading the 8259 to treat it as spurious.
>> Is that what you had in mind? That would be much more likley in mode 2
>> (rate generator) than mode 3 (square wave). Or am I mixing two things
>> up...?
>
> What would a spurious (hardware generated) interrupt mean ?
> you messed up either with timing or your IRQ-respond code was inable to
> allow nested IRQ, or more worse you made the IRQ-routine call the
> event-handler before other IRQs were reenabled and accepted.
Of course it could mean many things, but in this case it was a hardware
"feature" of the PIC 8259A which would sometimes assert an interrupt
on IRQ 7 if there was too much activity on the other lines.
>>>> James Harris wrote:
>>> Mike Gonta wrote:
>> James Harris wrote:
>>>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>>>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>
>>> This is probably the once popular spurious interrupt 15 (0xF) the
>>> default IRQ 7 handler. Apparently much activity (getting too hot?) on
>>> the 8259a
>
>> Good answer. That was the conclusion I came to too. See my earlier reply.
>
>>> (I once generated such spurious activity as a test by
>>> increasing the timer frequency - IRQ 0) causes a spurious interrupt
>>> on IRQ 7 (LPT1).
>
> The problem with INT_08..0F working on IRQ_0..7 was eliminated by early
> non-DOS non M$ OS as a first action because of the obvious interference
> with CPU-generated exeptions in that range already in realmode. MY OS and
> it's premature DOS-extenders did it by relocating
> IRQ_0..7 to INT_50 and IRQ_8..F to INT_58..5F like many others did.
The problem is not with the assignment. The relocation was necessary
>>>> Anyone heard of interrupt 15? I hadn't. In the video below Andrew
>>>> Tanenbaum mentions it as being generated when a CPU gets too hot.
>
>>> This is probably the once popular spurious interrupt 15 (0xF) the
>>> default IRQ 7 handler. Apparently much activity (getting too hot?) on
>>> the 8259a
>
>> Good answer. That was the conclusion I came to too. See my earlier reply.
>
>>> (I once generated such spurious activity as a test by
>>> increasing the timer frequency - IRQ 0) causes a spurious interrupt
>>> on IRQ 7 (LPT1).
>
> The problem with INT_08..0F working on IRQ_0..7 was eliminated by early
> non-DOS non M$ OS as a first action because of the obvious interference
> with CPU-generated exeptions in that range already in realmode. MY OS and
> it's premature DOS-extenders did it by relocating
> IRQ_0..7 to INT_50 and IRQ_8..F to INT_58..5F like many others did.
for 32 bit protected mode not 16 bit real mode. The early Minix was only
RM16 (the same as DOS).
>> Why did that cause a spurious interrupt? My guess: the 8254ish PIT on
>> IRQ0 is not really an interrupting device; its output is a waveform and
>> it will therefore effectively 'deassert' its output when it is ready to
>> do so rather than once it has been 'serviced' by an interrupt subroutine.
>> As the PIT output is free-running, if the machine does not process the
>> previous interrupts quickly enough the PIT output could have transitioned
>> back to 'deasserted' state by the time the CPU told the 8259 that it was
>> ready to service the interrupt, leading the 8259 to treat it as spurious.
>> Is that what you had in mind? That would be much more likley in mode 2
>> (rate generator) than mode 3 (square wave). Or am I mixing two things
>> up...?
>
> What would a spurious (hardware generated) interrupt mean ?
> you messed up either with timing or your IRQ-respond code was inable to
> allow nested IRQ, or more worse you made the IRQ-routine call the
> event-handler before other IRQs were reenabled and accepted.
"feature" of the PIC 8259A which would sometimes assert an interrupt
on IRQ 7 if there was too much activity on the other lines.
Rod Pemberton
Sep 4, 2015, 9:32:26 PM9/4/15
to
On Fri, 04 Sep 2015 04:49:43 -0400, James Harris <james.h...@gmail.com> wrote:
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> news:op.x4ewifxjyfako5@localhost...
>> On Thu, 03 Sep 2015 06:50:36 -0400, James Harris
>> <james.h...@gmail.com> wrote:
>>> Anyone heard of interrupt 15? I hadn't.
>>> [...]
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> news:op.x4ewifxjyfako5@localhost...
>> On Thu, 03 Sep 2015 06:50:36 -0400, James Harris
>> <james.h...@gmail.com> wrote:
>>> Anyone heard of interrupt 15? I hadn't.
>>> Any of you catching CPU interrupt 0x15?
>>> [...]
>>> Have you ever seen it trigger?
>>
>> No. I wasn't looking for it. You'd need to intall a full
>> set of interrupts for all vectors, not just those your OS
>> needs, in order to trap it and/or any other spurious
>> interrupts. I doubt that most people would do that unless
>> they needed to trace all interrupts or confirm interrupts.
>
> There is a difference between merely trapping interrupts and doing
> something specific to handle them. ISTM better for an OS to *trap* all
> 256 so as to avoid the kind of problem that Tanenbaum was talking about.
> Any vectors that do not have handlers can then at least be noted so that
> something can tell later that a mysterious interrupt vector was invoked.
> At least they won't go marching off trying to execute data as code in
> uncharted memory...!
That's fine during development, but is it acceptable once the OS
>>> [...]
>>> Have you ever seen it trigger?
>>
>> No. I wasn't looking for it. You'd need to intall a full
>> set of interrupts for all vectors, not just those your OS
>> needs, in order to trap it and/or any other spurious
>> interrupts. I doubt that most people would do that unless
>> they needed to trace all interrupts or confirm interrupts.
>
> There is a difference between merely trapping interrupts and doing
> something specific to handle them. ISTM better for an OS to *trap* all
> 256 so as to avoid the kind of problem that Tanenbaum was talking about.
> Any vectors that do not have handlers can then at least be noted so that
> something can tell later that a mysterious interrupt vector was invoked.
> At least they won't go marching off trying to execute data as code in
> uncharted memory...!
has been released to users? ...
Well, wolfgang said he doesn't trap that many, only 0 up to 0x1F,
which are in-use or reserved for the processor. I'm sure he's
also watching the interrupts for the high IRQs too ... I'd guess
that he reprogrammed the PIC to relocate low IRQs, so he's watching
another eight interrupts for the low IRQs too ... :-)
I only wrote code to attempt to recover from IRQs, NMIs, traps,
and faults, but I don't do anything currently for NMI, faults,
or traps except watch for them. I.e., IRQs only do something.
I don't watch for any traps, aborts, or reserved interrupts.
AIR, it wasn't possible to safely recover from some of these ...
depending how one defines "recover" and "safely".
IRQ 0 to 7 (Int 0x08 to 0x0F)
IRQ 8 to 15 (Int 0x70 to 0x77)
NMI (Int 0x02)
faults (Int 0x00,0x01,0x05 to 0x08,0xA to 0xE,0x10 to 0x13)
traps none
aborts none
reserved none
other nothing
Obviously, with 'to' meaning 'through' inclusive here...
Also, my faults, traps, aborts, NMI, etc overlap with the low IRQs
since I don't relocate the BIOS default PIC vectors, although I do
reprogram the PIC to the BIOS defaults. So, your low IRQs will most
likely will be on a different set of interrupts since most OSes have
reprogrammed the PICs to relocate the low IRQs above 0x1F somewhere.
Instead of reprogramming them, I implemented code to distinquish them.
Since my OS was intended to work with DOS code which I have no control
over, I chose to preserve this flawed situation, i.e., shared interrupts.
> That is better than just assuming that a certain vector will never be
> used, as Tanenbaum's problem illustrates.
everything, at least until you're reasonably sure everything is correct.
For a release version of the OS, I'd probably watch low IRQs, high IRQs,
0x00 through 0x1F, and any OS API interrupts. What more do you need for
the OS to function? There really isn't much you can do if an unexpected
interrupt is generated which causes a serious problem. You'd need to
know about or experience the issue to write code that would fix it.
If fault tolerance is an issue, you'd ignore any and all spurious or
unexpected interrupts and continue executing. I.e., no crash, no halt,
no reboot, no stopping, recover. So, you'd set them to a "dummy" iret
routine so code execution doesn't go "off-into-the-weeds".
If security is an issue, you'd watch all of them, report them to the
user, log them, and set all of them to call a routine to handle the
unexpected issue. Security assumes the worst and takes the most
extreme measure to ensure security isn't breached. I.e., if an
unexpected interrupt was generated, you'd do a forced reboot. You
might even reset the unused vectors periodically in case malware
changes them, e.g., every 1000th timer interrupt.
If user annoyance by the OS is an issue, which is a personal pet
peeve of mine ..., you won't tell the user about them.
So, your goals here matter. AISI, they affect your design. You need
to decide on fault tolerance or security or some combination or not
an issue. AIUI, fault tolerance and security would be difficult to
co-exist.
> I do a lot of programming too, and for pleasure, it has to be said,
> but to me it's hard work. He seems to do it easily and just for fun.
Sometimes, the best solution is not to force things, but to let them
sit and age until the solution presents itself, mysteriously and
out-of-the-blue. You can't do that in a corporate environment or
with a deadline.
> [link]
>
> "This program is a simulator (i.e., an interpreter) for the IBM PC.
> It has been tested on a VAX\(en11/750 running 4.1BSD, but since it
> is entirely in C, it should run on almost any 32\(enmachine with a
> C compiler and a reasonable UNIX system."
>
It probably has bit-rotted, but otherwise might be a way to
> "This program is a simulator (i.e., an interpreter) for the IBM PC.
> It has been tested on a VAX\(en11/750 running 4.1BSD, but since it
> is entirely in C, it should run on almost any 32\(enmachine with a
> C compiler and a reasonable UNIX system."
>
execute BIOS or other 16-bit code from a 32-bit/64-bit OS.
AIR, one of the BSDs tried to get PCC up and running again,
because of the license, but it was simply too rotted to be
worth the time or effort.
Rod Pemberton
Sep 4, 2015, 9:36:55 PM9/4/15
to
On Fri, 04 Sep 2015 08:28:47 -0400, James Harris <james.h...@gmail.com> wrote:
> [...]
the original IBM PC supposedly had an unexpected interrupt
routine which saved the unexpected interrupt number in
BDA 6Bh. ATs set IRQ2.
> The IBM BIOS code above does not even have the jump address of a null
> handler. An interrupt F on that would jump to 0:0 and try executing
> that as code.
On XTs and ATs, it should jump to label D11 in the BIOS.
Later XTs will jump to D_EOI, not D11, if the Tech. Ref.
is correct. The early XT didn't set any unused vectors.
I.e., all cleared or zero. More on this stuff in a reply
to wolfgang, base on 7 Tech. Ref.'s.
> [...]
>
> This table is there to be copied to the IVT at startup but, note, it
> does not contain any kind of handler for interrupt F (nor for some
> others). If *IBM* did not include any kind of handler for that interrupt
> then they did not expect spurious interrupts either and that is maybe
> what led Tanenbaum to omit such handling from early Minix.
>
Found via a quote from a book indexed in Google Books,
> This table is there to be copied to the IVT at startup but, note, it
> does not contain any kind of handler for interrupt F (nor for some
> others). If *IBM* did not include any kind of handler for that interrupt
> then they did not expect spurious interrupts either and that is maybe
> what led Tanenbaum to omit such handling from early Minix.
>
the original IBM PC supposedly had an unexpected interrupt
routine which saved the unexpected interrupt number in
BDA 6Bh. ATs set IRQ2.
> The IBM BIOS code above does not even have the jump address of a null
> handler. An interrupt F on that would jump to 0:0 and try executing
> that as code.
Later XTs will jump to D_EOI, not D11, if the Tech. Ref.
is correct. The early XT didn't set any unused vectors.
I.e., all cleared or zero. More on this stuff in a reply
to wolfgang, base on 7 Tech. Ref.'s.
Rod Pemberton
Sep 4, 2015, 9:40:56 PM9/4/15
to
On Fri, 04 Sep 2015 14:30:16 -0400, wolfgang kern <now...@never.at> wrote:
> Any unassigned IRQ 'shall not' point to 0:0, it should and
> almost all BIOS does it, point to an EOI-only routine.
According to the PC Technical references available online,
> Any unassigned IRQ 'shall not' point to 0:0, it should and
> almost all BIOS does it, point to an EOI-only routine.
later versions of the IBM PC such as XT and AT do that.
The original IBM PC BIOS didn't do that. The original
IBM PC didn't set them at all. Unused vectors were
0000:0000h. A later version of the PC set them to D_EOI,
not D11 as in the XT and AT, according to the source ...
Most set the unused vectors to D11 which was a label for
the "TEMPORARY INTERRUPT SERVICE ROUTINE" in the BIOS.
This routine varied across the machines, but usually
included and EOI.
However, AFAICT, I probably haven't read enough of the BIOS
code, ISTM that the PC, XT, and AT only set unused interrupts
above 08 to a routine, and not unused vectors below 08. Only
two interrupts are actually set to a fake "dummy" routine
which only has an IRET. The values for that vector are the
same on PCs and ATs but different for XTs. Although, the IRET
is still available at the PC and AT location in the XT ...
Later versions of the AT also clear vectors 60 to 67, but not
the early version.
What's really interesting though are the vectors for IRQ 08h
to 0Fh (AT slave PIC) have no standard vector values. Each
of the three BIOS listings for the AT had different values.
The low IRQs for defined interrupts were kept constant across
the PC, XT, AT.
I looked at this today, so I haven't gotten to the PS/2
BIOSes yet. I looked at two PC, two XT, and three AT
BIOS listings.
wolfgang kern
Sep 5, 2015, 5:41:43 AM9/5/15
to
James Harris asked:
> ...
>
>> The problem with INT_08..0F working on IRQ_0..7 was eliminated by
>> early non-DOS non M$ OS as a first action because of the obvious
>> interference with CPU-generated exeptions in that range already in
>> realmode. MY OS and it's premature DOS-extenders did it by relocating
>> IRQ_0..7 to INT_50 and IRQ_8..F to INT_58..5F like many others did.
> I think I may have asked you this before but why did you choose 0x50
> instead of 0x20 or 0xa0 etc?
0x50. That was when I had a limited DOS in addition to my OS.
> ...
>> What would a spurious (hardware generated) interrupt mean ?
>> you messed up either with timing or your IRQ-respond code was inable
>> to allow nested IRQ, or more worse you made the IRQ-routine call the
>> event-handler before other IRQs were reenabled and accepted.
>
> That deserves a thread all of its own. Will start one.
....
point to the BIOS. The _10 and all above _0D are PM-only anyway.
>> _11 : Alignment Fault (if set to)
>> _12 : Machine Check Excptions (if enabled)
>> _13 : SIMD errors (if enabled)
>> in true RealMode we got only _0.._D and instead of the above:
>> _8 ; IDT-limit exceeded
>> _C ; stack seg-overrun
>> _D ; SEG-overrun
>> The problem always was the concurrence between exceptions and
>> HW-created interrupts in the range of INT08..0F.
> IRQs and CPU-generated interrupts can be distinguished, can't they, even
> if they share a vector? Of course they *should* be kept separate but
> isn't the main problem one of performance?
>> All decent OS (exluding M$-DOS) know it and relocate the PIC.
> Yes. No need to share them - unless, of course, you are MSDOS and need
> to keep backward compatiblity.
__
wolfgang
James Harris
Sep 5, 2015, 8:21:40 AM9/5/15
to
"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> On Fri, 04 Sep 2015 04:49:43 -0400, James Harris
> <james.h...@gmail.com> wrote:
>
>> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
>> news:op.x4ewifxjyfako5@localhost...
...
> <james.h...@gmail.com> wrote:
>
>> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
>> news:op.x4ewifxjyfako5@localhost...
>> There is a difference between merely trapping interrupts and doing
>> something specific to handle them. ISTM better for an OS to *trap*
>> all
>> 256 so as to avoid the kind of problem that Tanenbaum was talking
>> about.
>> Any vectors that do not have handlers can then at least be noted so
>> that
>> something can tell later that a mysterious interrupt vector was
>> invoked.
>> At least they won't go marching off trying to execute data as code in
>> uncharted memory...!
>
> That's fine during development, but is it acceptable once the OS
> has been released to users? ...
car but to remove the seat belts for production models? ;-)
> Well, wolfgang said he doesn't trap that many, only 0 up to 0x1F,
> which are in-use or reserved for the processor. I'm sure he's
> also watching the interrupts for the high IRQs too ... I'd guess
> that he reprogrammed the PIC to relocate low IRQs, so he's watching
> another eight interrupts for the low IRQs too ... :-)
beyond the defined end of the IDT. In Rmode, though, there is no such
control, and software can attempt to invoke any of the 256 vectors.
Still, it can cost very little to at least trap all of them. No
excursions into the weeds necessary.
...
>> That is better than just assuming that a certain vector will never be
>> used, as Tanenbaum's problem illustrates.
>
> For a development version of the OS, you might consider watching
> everything, at least until you're reasonably sure everything is
> correct.
>
> For a release version of the OS, I'd probably watch low IRQs, high
> IRQs,
> 0x00 through 0x1F, and any OS API interrupts. What more do you need
> for
> the OS to function? There really isn't much you can do if an
> unexpected
> interrupt is generated which causes a serious problem. You'd need to
> know about or experience the issue to write code that would fix it.
different categories, as follows.
CPU-generating interrupts are split into those which push an error code
and those which don't, because the cleanup of the stack has to vary. But
they are basically handled individually. Unassigned Intel-reserved
interrupts are assumed not to push an error code. I don't know what I
could do if Intel added another one there and it had an error code. My
program code, at present, would not handle it properly.
IRQs for the master PIC end with an EOI to it.
IRQs for the slave PIC end with EOIs to both slave and master.
All others.
For each vector there can be zero or more handlers. Each handler is
called in turn. Once all handlers have finished, some basic statistics
are recorded before returning to the interrupted task. Those stats
include a tally of any interrupts which are completely unhandled.
The scheme still has problems. Imagine a level-triggered device without
a handler. The faulting condition would never get reset and another
interrupt would trigger again after the IRET instruction. Such would
never get back to the prior code. That's not a problem with the scheme.
The same would happen on any OS where a level-triggered device requests
service and there is nothing to handle it.
The only thing I can think of is for the interrupt code to recognise the
problem and if it triggers to mask off the offending vector (so the
problem won't repeat) and inform a human.
> If fault tolerance is an issue, you'd ignore any and all spurious or
> unexpected interrupts and continue executing. I.e., no crash, no
> halt,
> no reboot, no stopping, recover. So, you'd set them to a "dummy" iret
> routine so code execution doesn't go "off-into-the-weeds".
>
> If security is an issue, you'd watch all of them, report them to the
> user, log them, and set all of them to call a routine to handle the
> unexpected issue. Security assumes the worst and takes the most
> extreme measure to ensure security isn't breached. I.e., if an
> unexpected interrupt was generated, you'd do a forced reboot. You
> might even reset the unused vectors periodically in case malware
> changes them, e.g., every 1000th timer interrupt.
users. It may be better to report it in some way so that technical staff
have a chance to review the cause ... thermal or otherwise....
Resetting the vectors is an interesting idea.
> If user annoyance by the OS is an issue, which is a personal pet
> peeve of mine ..., you won't tell the user about them.
>
> So, your goals here matter. AISI, they affect your design. You need
> to decide on fault tolerance or security or some combination or not
> an issue. AIUI, fault tolerance and security would be difficult to
> co-exist.
>> [link]
>>
>> "This program is a simulator (i.e., an interpreter) for the IBM PC.
>> It has been tested on a VAX\(en11/750 running 4.1BSD, but since it
>> is entirely in C, it should run on almost any 32\(enmachine with a
>> C compiler and a reasonable UNIX system."
>>
>
> It probably has bit-rotted, but otherwise might be a way to
> execute BIOS or other 16-bit code from a 32-bit/64-bit OS.
might be a bit more of a challenge. There are so many corner cases that
even well-known emulators don't always get the emulation right. The
thread on spurious interrupts should bring out a few.
James
James Harris
Sep 5, 2015, 8:44:43 AM9/5/15
to
"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> On Fri, 04 Sep 2015 14:30:16 -0400, wolfgang kern <now...@never.at>
> wrote:
>
>> Any unassigned IRQ 'shall not' point to 0:0, it should and
>> almost all BIOS does it, point to an EOI-only routine.
>
> According to the PC Technical references available online,
> later versions of the IBM PC such as XT and AT do that.
> The original IBM PC BIOS didn't do that. The original
> IBM PC didn't set them at all. Unused vectors were
> 0000:0000h. A later version of the PC set them to D_EOI,
> not D11 as in the XT and AT, according to the source ...
> Most set the unused vectors to D11 which was a label for
> the "TEMPORARY INTERRUPT SERVICE ROUTINE" in the BIOS.
> This routine varied across the machines, but usually
> included and EOI.
>
> However, AFAICT, I probably haven't read enough of the BIOS
> code, ISTM that the PC, XT, and AT only set unused interrupts
> above 08 to a routine, and not unused vectors below 08.
The 8088 only had five CPU-generated vectors:
> wrote:
>
>> Any unassigned IRQ 'shall not' point to 0:0, it should and
>> almost all BIOS does it, point to an EOI-only routine.
>
> According to the PC Technical references available online,
> later versions of the IBM PC such as XT and AT do that.
> The original IBM PC BIOS didn't do that. The original
> IBM PC didn't set them at all. Unused vectors were
> 0000:0000h. A later version of the PC set them to D_EOI,
> not D11 as in the XT and AT, according to the source ...
> Most set the unused vectors to D11 which was a label for
> the "TEMPORARY INTERRUPT SERVICE ROUTINE" in the BIOS.
> This routine varied across the machines, but usually
> included and EOI.
>
> However, AFAICT, I probably haven't read enough of the BIOS
> code, ISTM that the PC, XT, and AT only set unused interrupts
> above 08 to a routine, and not unused vectors below 08.
0: divide overflow
1: single step
2: NMI
3: breakpoint
4: overflow
As the CPU was not intended to be upgraded it was, perhaps, reasonable
that IBM only defined those five of the Intel reserved ones.
> Only
> two interrupts are actually set to a fake "dummy" routine
> which only has an IRET. The values for that vector are the
> same on PCs and ATs but different for XTs. Although, the IRET
> is still available at the PC and AT location in the XT ...
> Later versions of the AT also clear vectors 60 to 67, but not
> the early version.
>
> What's really interesting though are the vectors for IRQ 08h
> to 0Fh (AT slave PIC)
> have no standard vector values. Each
> of the three BIOS listings for the AT had different values.
> The low IRQs for defined interrupts were kept constant across
> the PC, XT, AT.
>
> I looked at this today, so I haven't gotten to the PS/2
> BIOSes yet. I looked at two PC, two XT, and three AT
> BIOS listings.
James
Rod Pemberton
Sep 5, 2015, 6:55:30 PM9/5/15
to
On Sat, 05 Sep 2015 08:21:37 -0400, James Harris <james.h...@gmail.com> wrote:
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> news:op.x4gukaxoyfako5@localhost...
>> On Fri, 04 Sep 2015 04:49:43 -0400, James Harris
>> <james.h...@gmail.com> wrote:
>>> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
>>> news:op.x4ewifxjyfako5@localhost...
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> news:op.x4gukaxoyfako5@localhost...
>> On Fri, 04 Sep 2015 04:49:43 -0400, James Harris
>> <james.h...@gmail.com> wrote:
>>> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
>>> news:op.x4ewifxjyfako5@localhost...
>>> There is a difference between merely trapping interrupts and doing
>>> something specific to handle them. ISTM better for an OS to *trap*
>>> all 256 so as to avoid the kind of problem that Tanenbaum was talking
>>> about. Any vectors that do not have handlers can then at least be
>>> noted so that something can tell later that a mysterious interrupt
>>> vector was invoked. At least they won't go marching off trying to
>>> execute data as code inuncharted memory...!
>>> something specific to handle them. ISTM better for an OS to *trap*
>>> all 256 so as to avoid the kind of problem that Tanenbaum was talking
>>> about. Any vectors that do not have handlers can then at least be
>>> noted so that something can tell later that a mysterious interrupt
>>> vector was invoked. At least they won't go marching off trying to
>>
>> That's fine during development, but is it acceptable once the OS
>> has been released to users? ...
>
> In the sense that it's OK to fit seat belts when testing a new model of
> car but to remove the seat belts for production models? ;-)
Well, more in the sense of training wheels on a bike, at some point they
>> That's fine during development, but is it acceptable once the OS
>> has been released to users? ...
>
> In the sense that it's OK to fit seat belts when testing a new model of
> car but to remove the seat belts for production models? ;-)
shouldn't be needed anymore, but they do no harm if still present. ;-)
Rod Pemberton
Sep 5, 2015, 7:42:32 PM9/5/15
to
On Sat, 05 Sep 2015 08:44:41 -0400, James Harris <james.h...@gmail.com> wrote:
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> news:op.x4gux7zkyfako5@localhost...
>> On Fri, 04 Sep 2015 14:30:16 -0400, wolfgang kern <now...@never.at>
>> wrote:
>>> Any unassigned IRQ 'shall not' point to 0:0, it should and
>>> almost all BIOS does it, point to an EOI-only routine.
>>
>> According to the PC Technical references available online,
>> later versions of the IBM PC such as XT and AT do that.
>> The original IBM PC BIOS didn't do that. The original
>> IBM PC didn't set them at all. Unused vectors were
>> 0000:0000h. A later version of the PC set them to D_EOI,
>> not D11 as in the XT and AT, according to the source ...
>> Most set the unused vectors to D11 which was a label for
>> the "TEMPORARY INTERRUPT SERVICE ROUTINE" in the BIOS.
>> This routine varied across the machines, but usually
>> included and EOI.
>>
>> However, AFAICT, I probably haven't read enough of the BIOS
>> code, ISTM that the PC, XT, and AT only set unused interrupts
>> above 08 to a routine, and not unused vectors below 08.
>
It seems I just hadn't found that BIOS routine which clears the
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> news:op.x4gux7zkyfako5@localhost...
>> On Fri, 04 Sep 2015 14:30:16 -0400, wolfgang kern <now...@never.at>
>> wrote:
>>> Any unassigned IRQ 'shall not' point to 0:0, it should and
>>> almost all BIOS does it, point to an EOI-only routine.
>>
>> According to the PC Technical references available online,
>> later versions of the IBM PC such as XT and AT do that.
>> The original IBM PC BIOS didn't do that. The original
>> IBM PC didn't set them at all. Unused vectors were
>> 0000:0000h. A later version of the PC set them to D_EOI,
>> not D11 as in the XT and AT, according to the source ...
>> Most set the unused vectors to D11 which was a label for
>> the "TEMPORARY INTERRUPT SERVICE ROUTINE" in the BIOS.
>> This routine varied across the machines, but usually
>> included and EOI.
>>
>> However, AFAICT, I probably haven't read enough of the BIOS
>> code, ISTM that the PC, XT, and AT only set unused interrupts
>> above 08 to a routine, and not unused vectors below 08.
>
unused vectors. Most XTs set a default vector for unused
vectors up to 0x1F, while ATs and later XTs set them up to 0x77.
So, only very early PCs didn't set unused vectors to BIOS label
D11, with one XT BIOS having a coding mistake of D_EOI, apparently.
> The 8088 only had five CPU-generated vectors:
>
> 0: divide overflow
> 1: single step
> 2: NMI
> 3: breakpoint
> 4: overflow
>
> As the CPU was not intended to be upgraded it was, perhaps, reasonable
> that IBM only defined those five of the Intel reserved ones.
>
>> Only
>> two interrupts are actually set to a fake "dummy" routine
>> which only has an IRET. The values for that vector are the
>> same on PCs and ATs but different for XTs. Although, the IRET
>> is still available at the PC and AT location in the XT ...
>> Later versions of the AT also clear vectors 60 to 67, but not
>> the early version.
>>
>> What's really interesting though are the vectors for IRQ 08h
>> to 0Fh (AT slave PIC)
>
> s/slave/master/ ?
>> have no standard vector values. Each
>> of the three BIOS listings for the AT had different values.
>> The low IRQs for defined interrupts were kept constant across
>> the PC, XT, AT.
>>
slave IVT. So, some XTs have dual PICs like the AT!
>> I looked at this today, so I haven't gotten to the PS/2
>> BIOSes yet. I looked at two PC, two XT, and three AT
>> BIOS listings.
>
> So, someone else is reading BIOSes too. Cool!
branches, locations. I'm not actually studying the code
just the vector setup. Either the pdf's don't index
the text properly, e.g., badly OCR'd, or the Linux
epdfview program's text search is broken ...
I still have yet to go through the many PS2 manuals.
wolfgang kern
Sep 6, 2015, 2:55:12 AM9/6/15
to
Rod Pemberton answered James Harris:
>>>> Anyone heard of interrupt 15? I hadn't.
>>>> [...]
>>>> Any of you catching CPU interrupt 0x15?
>>>> [...]
>>>> Have you ever seen it trigger?
>>> No. I wasn't looking for it. You'd need to intall a full
>>> set of interrupts for all vectors, not just those your OS
>>> needs, in order to trap it and/or any other spurious
>>> interrupts. I doubt that most people would do that unless
>>> they needed to trace all interrupts or confirm interrupts.
>> There is a difference between merely trapping interrupts and doing
>> something specific to handle them. ISTM better for an OS to *trap* all
>> 256 so as to avoid the kind of problem that Tanenbaum was talking about.
>> Any vectors that do not have handlers can then at least be noted so that
>> something can tell later that a mysterious interrupt vector was invoked.
>> At least they won't go marching off trying to execute data as code in
>> uncharted memory...!
> That's fine during development, but is it acceptable once the OS
> has been released to users? ...
> Well, wolfgang said he doesn't trap that many, only 0 up to 0x1F,
> which are in-use or reserved for the processor. I'm sure he's
> also watching the interrupts for the high IRQs too ... I'd guess
> that he reprogrammed the PIC to relocate low IRQs, so he's watching
> another eight interrupts for the low IRQs too ... :-)
care software-interrupts except the few which my OS supports
because I wont expect any uncovered SW-INT from 'my' code.
But if your OS execute code from outside, it could be of help to
cover them all, even you may not know what it's intended to do.
> I only wrote code to attempt to recover from IRQs, NMIs, traps,
> and faults, but I don't do anything currently for NMI, faults,
> or traps except watch for them. I.e., IRQs only do something.
> I don't watch for any traps, aborts, or reserved interrupts.
> AIR, it wasn't possible to safely recover from some of these ...
> depending how one defines "recover" and "safely".
Me too don't do much on exceptions, they just call the debugger
which show registers, mode and a disassembled line of the cause.
The user can then select "ignore/restart/reboot" while in admin-
mode I could also alter all register-values and jump as desired.
In former versions (while DOS were still active) I covered only
EXC_0 and 6 (DIV and Illegal instruction) to overcome some bugs
in old games.
And most of my IRQ-routines just increment a global counter and
set an event-flag followed by EOI IRET.
Only Timer, Mice and Keybd-IRQ-routines do a bit more.
__
wolfgang
NimbUs
Sep 6, 2015, 6:23:51 AM9/6/15
to
James Harris dit dans news:mseml4$pnq$1...@dont-email.me:
> IIRC, in Pmode and Lmode the CPU will report any attempt to
use a vector
> beyond the defined end of the IDT. In Rmode, though, there
is no such
> control, and software can attempt to invoke any of the 256
vectors.
You are figuring a difference which does not exist : in real
mode also (80286+), the /limit/ field is obeyed in IDTR,
though usually, for compatibility, it is set = 0xFFFF (from
reset; 0x3FF would do as well).
I found the feature helpful more than once when I was doing
low-level live 'dissection' of processors...
--
Nim'
> IIRC, in Pmode and Lmode the CPU will report any attempt to
use a vector
> beyond the defined end of the IDT. In Rmode, though, there
is no such
> control, and software can attempt to invoke any of the 256
vectors.
mode also (80286+), the /limit/ field is obeyed in IDTR,
though usually, for compatibility, it is set = 0xFFFF (from
reset; 0x3FF would do as well).
I found the feature helpful more than once when I was doing
low-level live 'dissection' of processors...
--
Nim'
NimbUs
Sep 6, 2015, 6:32:43 AM9/6/15
to
James Harris dit dans news:mseo0c$v86$1...@dont-email.me:
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
1F for future extensions, so, no, it was /not/ reasonable of
IBM's "Boca Raton" team to use them for BIOS subroutines !
Definitely a bad choice.
--
Nim'
> "Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
> The 8088 only had five CPU-generated vectors:
> 0: divide overflow
> 1: single step
> 2: NMI
> 3: breakpoint
> 4: overflow
> As the CPU was not intended to be upgraded it was, perhaps,
reasonable
> that IBM only defined those five of the Intel reserved ones.
Intel's manuals explicitely /reserved/ interrupt vectors 00->
> 0: divide overflow
> 1: single step
> 2: NMI
> 3: breakpoint
> 4: overflow
> As the CPU was not intended to be upgraded it was, perhaps,
reasonable
> that IBM only defined those five of the Intel reserved ones.
1F for future extensions, so, no, it was /not/ reasonable of
IBM's "Boca Raton" team to use them for BIOS subroutines !
Definitely a bad choice.
--
Nim'
NimbUs
Sep 6, 2015, 6:43:51 AM9/6/15
to
NimbUs dit dans news:XnFA50D7E1BDB2B7T6A7E15I9M1B9U4S@
127.0.0.1:
> You are figuring a difference which does not exist : in real
> mode also (80286+), the /limit/ field is obeyed in IDTR,
> though usually, for compatibility, it is set = 0xFFFF (from
> reset; 0x3FF would do as well).
By the way, yes, in case you wonder, any interrupt (hardware
or soft) /beyond/ the IDTR set limit /will/ cause interrupt 8
(the double fault) in real mode also; or triple fault if limit
is less than 4x8-1, of course.
Nothing beats curiosity and intelligent experimenting. No
reading of bad or not so bad manuals. Especially /not/ lengthy
usenet chatting...
Regards...
--
NimbUs
127.0.0.1:
> You are figuring a difference which does not exist : in real
> mode also (80286+), the /limit/ field is obeyed in IDTR,
> though usually, for compatibility, it is set = 0xFFFF (from
> reset; 0x3FF would do as well).
or soft) /beyond/ the IDTR set limit /will/ cause interrupt 8
(the double fault) in real mode also; or triple fault if limit
is less than 4x8-1, of course.
Nothing beats curiosity and intelligent experimenting. No
reading of bad or not so bad manuals. Especially /not/ lengthy
usenet chatting...
Regards...
--
NimbUs
James Harris
Sep 6, 2015, 7:13:35 AM9/6/15
to
"NimbUs" <nim...@xxx.invalid> wrote in message
news:XnFA50D7E1BDB2B7...@127.0.0.1...
> James Harris dit dans news:mseml4$pnq$1...@dont-email.me:
>
>
>> IIRC, in Pmode and Lmode the CPU will report any attempt to
> use a vector
>> beyond the defined end of the IDT. In Rmode, though, there
> is no such
>> control, and software can attempt to invoke any of the 256
> vectors.
>
> You are figuring a difference which does not exist : in real
> mode also (80286+), the /limit/ field is obeyed in IDTR,
> though usually, for compatibility, it is set = 0xFFFF (from
> reset; 0x3FF would do as well).
OK. Thanks for the info. In my case, though, I still need to capture all
>
>
>> IIRC, in Pmode and Lmode the CPU will report any attempt to
> use a vector
>> beyond the defined end of the IDT. In Rmode, though, there
> is no such
>> control, and software can attempt to invoke any of the 256
> vectors.
>
> You are figuring a difference which does not exist : in real
> mode also (80286+), the /limit/ field is obeyed in IDTR,
> though usually, for compatibility, it is set = 0xFFFF (from
> reset; 0x3FF would do as well).
256 for the code to work on a real 8086 (real real mode...?) or 8086
emulator.
James
James Harris
Sep 6, 2015, 7:17:19 AM9/6/15
to
"NimbUs" <nim...@xxx.invalid> wrote in message
that is not what was being referred to. For example, they may not have
come up with anything sensible in the BIOS for interrupt 6 to do.
James
James Harris
Sep 6, 2015, 7:21:27 AM9/6/15
to
"NimbUs" <nim...@xxx.invalid> wrote in message
> NimbUs dit dans news:XnFA50D7E1BDB2B7T6A7E15I9M1B9U4S@
> 127.0.0.1:
>
>> You are figuring a difference which does not exist : in real
>> mode also (80286+), the /limit/ field is obeyed in IDTR,
>> though usually, for compatibility, it is set = 0xFFFF (from
>> reset; 0x3FF would do as well).
>
> By the way, yes, in case you wonder, any interrupt (hardware
> or soft) /beyond/ the IDTR set limit /will/ cause interrupt 8
> (the double fault) in real mode also; or triple fault if limit
> is less than 4x8-1, of course.
OK.
> 127.0.0.1:
>
>> You are figuring a difference which does not exist : in real
>> mode also (80286+), the /limit/ field is obeyed in IDTR,
>> though usually, for compatibility, it is set = 0xFFFF (from
>> reset; 0x3FF would do as well).
>
> By the way, yes, in case you wonder, any interrupt (hardware
> or soft) /beyond/ the IDTR set limit /will/ cause interrupt 8
> (the double fault) in real mode also; or triple fault if limit
> is less than 4x8-1, of course.
> Nothing beats curiosity and intelligent experimenting. No
> reading of bad or not so bad manuals. Especially /not/ lengthy
> usenet chatting...
looking for a test on one machine may give you the results only for that
machine. CPUs and IO hardware vary.
IMO Usenet has been and is a great place both to discuss such issues
and, with the archives easily available, to document findings. Also,
info published here is shared with others.
James
0 new messages