geof@imagen.UUCP (Geoffrey Cooper) (08/20/87)
Is there a way (I deduce from recent net messages that there is) for a
program to switch from 286 protected mode back to real address mode,
without rebooting the machine?
I understand that the only way to tell the '286 to switch is via
hardware reset. I think this means that you lose control of the
processor. Does MS-DOS have a way to accomodate such a "hot boot"?
Don't RAM disks for the PC-AT have to do this?
- Geof Cooper
IMAGEN
--
{decwrl,sun,saber}!imagen!geofbraun@m10ux.UUCP (MHx7079 mh) (08/21/87)
In article <1387@imagen.UUCP>, geof@imagen.UUCP (Geoffrey Cooper) writes: > Is there a way (I deduce from recent net messages that there is) for a > program to switch from 286 protected mode back to real address mode, > without rebooting the machine? I read in one of the trade magazines (Electronic Engineering Times) a few weeks ago that Microsoft announced that a research team of theirs had discovered a way to do this without a hardware reset. It involves something wacky like a double fault. They also announced that they would be patenting this. Microsoft really seems to have developed an attitude here. First, they equate finding a hack with "research", and then they expect a hack to be patentable. This, and the fact that IBM wants to patent their micro-channel bus specification sort of make me gag. -- Doug Braun AT+T Bell Labs, Murray Hill, NJ m10ux!braun 201 582-7039
greg@gryphon.CTS.COM (Greg Laskin) (08/23/87)
In article <3351@zen.berkeley.edu> iverson@cory.Berkeley.EDU.UUCP (Tim Iverson) writes: >In article <1387@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes: >>Is there a way (I deduce from recent net messages that there is) for a >>program to switch from 286 protected mode back to real address mode, >>without rebooting the machine? > >To answer the question; yes, there is. If you want details, look >in *any* '286 manual, or there is a BIOS call that will do this - >you can find it in the AT Technical Reference Manual. > > The IBM Bios performs this trick in the block move routine than allows copying memory across the 1MB boundary. The routine saves the state of the processor and sets up a protected mode environment and sets a bit in the CMOS ram before jamming the CPU into protected mode. To get out of protected mode the routine RESETS the processor by asserting its RESET line. This brings the processor back to real address mode and trys to reboot the machine. Remember the bit in the CMOS ram. Right, the cold boot routine checks for that bit and if it's set it jumps back to the block move bios routine which then restores the processor state and resumes processing. I believe the segmentation used by the BIOS rom prevents it being called from protected mode. -- Greg Laskin "When everybody's talking and nobody's listening, how can we decide?" INTERNET: greg@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4}!crash!gryphon!greg UUCP: {philabs, scgvaxd}!cadovax!gryphon!greg
johnl@well.UUCP (John A. Limpert) (08/24/87)
From what I have heard, they load the IDTR (interrupt descriptor table register) with 0 and execute an INT 3 instruction. This causes multiple faults and drops the 80286 back into real mode. I am not sure what state this leaves you concerning segments and the prefetch queue. I picked this info up from someone who had gone to one of the OS/2 seminars.
jay@splut.UUCP (Jay Maynard) (08/24/87)
In article <328@m10ux.UUCP>, braun@m10ux.UUCP (MHx7079 mh) writes: > This, and the fact that IBM wants to patent their micro-channel > bus specification sort of make me gag. Funny...wasn't DEC's mini bus patented, too? I remember someone getting thoroughly sued for putting out an expansion board several years ago... -- Jay Maynard, K5ZC...>splut!< | uucp: hoptoad!academ!uhnix1!nuchat!splut!jay "Don't ask ME about Unix... | (or sun!housun!nuchat) CI$: 71036,1603 I speak SNA!" | internet: beats me GEnie: JAYMAYNARD The opinions herein are shared by neither of my cats, much less anyone else.
anton@utai.UUCP (08/25/87)
In article <1387@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes: >Is there a way (I deduce from recent net messages that there is) for a >program to switch from 286 protected mode back to real address mode, >without rebooting the machine? > >I understand that the only way to tell the '286 to switch is via >hardware reset. I think this means that you lose control of the >processor. Does MS-DOS have a way to accomodate such a "hot boot"? > >Don't RAM disks for the PC-AT have to do this? > >- Geof Cooper > IMAGEN >-- >{decwrl,sun,saber}!imagen!geof There is an undocumented instruction in the 286 which will throw you back into the unprotected mode. Microsoft has found it so useful that they insist that Intel not fix it in the 386. At least, these are the rumors I heard.
ralf@b.gp.cs.cmu.edu (Ralf Brown) (08/25/87)
In article <3813@well.UUCP> johnl@well.UUCP (John A. Limpert) writes: >From what I have heard, they load the IDTR (interrupt descriptor >table register) with 0 and execute an INT 3 instruction. This causes >multiple faults and drops the 80286 back into real mode. I am not >sure what state this leaves you concerning segments and the prefetch >queue. I picked this info up from someone who had gone to one of >the OS/2 seminars. The way I understand it, if another fault occurs after the 286 starts processing a double fault (actually any multiple faults occurring on the same instruction), the 286 goes into the shutdown state. The AT has hardware to issue a reset when the 286 indicates it has entered shutdown. Could this be why the above works? If so, it wouldn't have any advantage over simply toggling the reset line through a MOV AL,0FEh/OUT 64h,AL sequence (and of course you would still have to set the magic flag in CMOS RAM). [the final fault is of course the missing interrupt descriptor table when the 286 tries to invoke the double fault exception handler] -- -=-=-=-=-=-=-=-= {harvard,seismo,ucbvax}!b.gp.cs.cmu.edu!ralf =-=-=-=-=-=-=-=- ARPAnet: RALF@B.GP.CS.CMU.EDU BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA AT&Tnet: (412) 268-3053 (school) FIDOnet: Ralf Brown at 129/31 DISCLAIMER? Who ever said I claimed anything? "I do not fear computers. I fear the lack of them..." -- Isaac Asimov
treat@sequent.UUCP (Scott Tetrick) (08/25/87)
In article <3813@well.UUCP>, johnl@well.UUCP (John A. Limpert) writes: > From what I have heard, they load the IDTR (interrupt descriptor > table register) with 0 and execute an INT 3 instruction. This causes > multiple faults and drops the 80286 back into real mode. It is important to note that it is NOT the INT 3 that returns the 80286 to real mode, but the hardware of the AT. Whenever a double fault occurs, the 80286 performs a SHUTDOWN bus cycle. This is detected by the hardware of the AT, and generates a RESET to the processor. Memory contents are still valid from before the reset. The prefetch queue is flushed on a reset.
john@hpcvlo.HP.COM (John Eaton) (08/26/87)
<<<< < There is an undocumented instruction in the 286 which will throw you back < into the unprotected mode. Microsoft has found it so useful that they < insist that Intel not fix it in the 386. At least, these are the < rumors I heard. ---------- They better be insisting that Intel add it to the 286 spec. Until they do there is no guarentee that it will still be there after the next mask rev or when any new vendor starts making chips. The I8088 had a undocumented POP CS instruction that NEC didn't put into the V-20. This caused problems for some programs that used it. John Eaton !hplabs!hp-pcd!john
greg@gryphon.CTS.COM (Greg Laskin) (08/27/87)
In article <4047@utai.UUCP> anton@ai.UUCP (Anton Geshelin) writes: >There is an undocumented instruction in the 286 which will throw you back >into the unprotected mode. Microsoft has found it so useful that they >insist that Intel not fix it in the 386. At least, these are the >rumors I heard. I saw a real posting in comp.sys.intel a few months ago that made obscure reference to such an instruction, LOADALL or thereabouts. The poster, perportedly an Intel person speaking on his own, stated: 1) The documentation for this undocumented instruction was made made available to Intel largest customers (IBM and Microsoft) under non-disclosure agreements. 2) The instruction, present in the 80286, was incompatible with the 80386. 3) The instruction was documented for the customers who got the documentation because of their "special needs" but that Intel would not support the instruction and strongly recommended against its use, in large part because of the 80386 incomptability. All information provided herein supplied with a dose of salt. -- Greg Laskin "When everybody's talking and nobody's listening, how can we decide?" INTERNET: greg@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4}!crash!gryphon!greg UUCP: {philabs, scgvaxd}!cadovax!gryphon!greg
ballou@maypo (Kenneth R. Ballou) (08/27/87)
In article <1343@gryphon.CTS.COM> greg@gryphon.CTS.COM (Greg Laskin) writes: >In article <4047@utai.UUCP> anton@ai.UUCP (Anton Geshelin) writes: >>There is an undocumented instruction in the 286 which will throw you back >>into the unprotected mode. Microsoft has found it so useful that they >>insist that Intel not fix it in the 386. At least, these are the >>rumors I heard. Well, I would be suspicious of this rumor insofar as one can disable protected mode quite readily on the 80386 without having to resort to resetting the CPU. The procedure for doing so is clearly documented in Section 14.5 of the 80386 Programmer's Reference Manual, titled "Switching back to real-address mode." The upshot is that the Protected Mode bit in the system register CR0 (akin to the MSW of the 80286) is not sticky. >I saw a real posting in comp.sys.intel a few months ago that made obscure >reference to such an instruction, LOADALL or thereabouts. > >The poster, perportedly an Intel person speaking on his own, stated: > 1) The documentation for this undocumented instruction was made > made available to Intel largest customers (IBM and Microsoft) > under non-disclosure agreements. Grumble! Speaking only for myself: >>> FLAME ON! <<< If this is true, then this is the sort of absurd information hoarding that benefits no one except whoever makes a tidy profit from a monopoly of know- ledge. Of course, I still haven't forgiven Intel (not that they care, I'm sure) for putting the global/local and privilege level bits in the *LOW THREE BITS* of the segment descriptor. I would be very impressed if anyone could give me a convincing explanation that there is enough gained by this in return for sacrificing a 29-bit linear address space. Perhaps I will be accused of participating in the seemingly popular sport of Intel bashing. However, I think my comment (about segment descriptor structure) is reasonable enough, and frankly I don't feel guilty about minor bashing of people/companies that hoard information such as "undocumented instructions" from all but the wealthiest. (Have I been listening to Richard Stallman too much? :-) :-) :-) :-) :-) ) ------------------------- Kenneth R. Ballou ballou@bosco.berkeley.edu
greg@xios.XIOS.UUCP (Greg Franks) (09/25/87)
In article <1203@cartan.Berkeley.EDU> ballou@bosco.berkeley.edu (Kenneth R. Ballou) writes: >ledge. Of course, I still haven't forgiven Intel (not that they care, I'm >sure) for putting the global/local and privilege level bits in the *LOW >THREE BITS* of the segment descriptor. I would be very impressed if anyone >could give me a convincing explanation that there is enough gained by this >in return for sacrificing a 29-bit linear address space. Tis obvious :-)... Segment table entries are all 8 bytes long. Soooo... segment_descriptor & 0xfff8 + table_offset = address Now, why they couldn't simply SHIFT THE STUPID SEGMENT DESCRIPTOR IN SILICON.... This is, of course, purely conjecture because I really don't know why intel did what they did. **** sigh **** -- Greg Franks XIOS Systems Corporation, 1600 Carling Avenue, (613) 725-5411 Ottawa, Ontario, Canada, K1Z 8R8 uunet!mnetor!dciem!nrcaer!xios!greg "Vermont ain't flat!"