286 Protected mode and Keyboard

[nestor]

I was running Checkit 3.0 System Board tests in my IBM PS/1 model 2011 (286 @ 10 MHz) and I noticed that the system made three beeps while doing "CPU Protected Mode" test.

The test passed, but after finishing the remaining tests the keyboard seems to be locked. I read somewhere that the 286 can't exit protected mode and IBM made a workaround using the 8042 keyboard controller. Can this be related?

 

[Chuck(G)]

You can exit protected mode on a 80286 without resetting the CPU, but it requires a (once) undocumented instruction and most early software didn't use it. The standard BIOS way was to store a flag in CMOS, then reset the CPU using the keyboard controller. During POST, the BIOS would pick up on the CMOS flag and short-stop the POST process and simply return to the invocation point of the "exit PM" BIOS call.

I think the issue here is that CheckIt probably doesn't provide a PM handler for the keyboard interrupt. Why should it? So the keyboard interrupt never gets serviced and you're locked out.

 

[cr1901]

You can exit protected mode on a 80286 without resetting the CPU, but it requires a (once) undocumented instruction and most early software didn't use it.

LOADALL?

The standard BIOS way was to store a flag in CMOS, then reset the CPU using the keyboard controller. During POST, the BIOS would pick up on the CMOS flag and short-stop the POST process and simply return to the invocation point of the "exit PM" BIOS call.

Thank you for answering a question I had but never made a thread about up to this point .

I think the issue here is that CheckIt probably doesn't provide a PM handler for the keyboard interrupt. Why should it? So the keyboard interrupt never gets serviced and you're locked out.

Faulty keyboard, maybe?

And wouldn't it have to provide a dummy handler, since IRQ 1 conflicts with the 286's reserved vectors in protected mode? The beeps happen WHILE the CPU is in protected mode.

 

[Chuck(G)]

Does the keyboard beep or does the speaker connected to the motherboard beep?

At any rate, there could be a bug in the PM keyboard interrupt handler or the ISR simply never chose to do anything but beep. I doubt that the matter ever came up.

You could always hook up something like SoftICE (or a genuine ICE) to see what's going on. I think SoftICE existed for the 80286, but I'm not certain.

 

[cr1901]

Does the keyboard beep or does the speaker connected to the motherboard beep?

Yea, yea... the PC speaker .

At any rate, there could be a bug in the PM keyboard interrupt handler or the ISR simply never chose to do anything but beep. I doubt that the matter ever came up.

FWIW, Checkit doesn't beep the PC speaker when I run it on my 286, so that's why I think it might be a bug in the ISR.

If ICEs STILL didn't cost an arm, leg, and other bodyparts, I would own one by now.

 

[Chuck(G)]

I seem to remember that the Intel ICE-286 setup used a special 80286 CPU with a bond-out exactly for that purpose. The 8086/8 may have had the same.

That accounts for the price.

But you never know when you'll stumble across one.

 

[george]

I am almost certain that softice for 286 if existed was never released. The first softice I've seen was 1.5x for win 3.1. Anyway what happens if the keyboard is replugged without rebooting after hanging? What happens if different keyboard is used?

 

[nestor]

Anyway what happens if the keyboard is replugged without rebooting after hanging? What happens if different keyboard is used?

Nothing, the keyboard doesn't work after being replugged. Tried with another keyboard and same result. As this checkit test works in other machines, I suppose it's a bios related bug.

 

[Chuck(G)]

Usually, this holds for just about any PS/2 keyboard interface. For some reason, the keyboard controller isn't smart enough to re-initialize the keyboard. I get this behavior (i.e. dead keyboard) right up through P4 systems. Curiously, this also applies to some systems when it comes to a PS/2 mouse.

There's no good reason why this behavior has to be. It just is.

 

[eeguru]

LOADALL?
And wouldn't it have to provide a dummy handler, since IRQ 1 conflicts with the 286's reserved vectors in protected mode? The beeps happen WHILE the CPU is in protected mode.

I assume anything entering protected mode on a 286 would also need up the base vectors on the PICs and rearrange the vector tables to match much like a 386 protected mode entry.

 

[Chuck(G)]

Well, on the 80286, LOADALL is typically used to access extended memory in real mode. On the 80286, you can't LOADALL your way back to real mode once in protected mode. While you can use the BIOS call, which involves the keyboard controller (slow to respond to requests), you can also force a "shutdown" via a triple fault from protected mode, which avoids the wait from the keyboard controller. You still need to record the "cause" in CMOS so the POST code needs to know what to do.

 

[cr1901]

Well, on the 80286, LOADALL is typically used to access extended memory in real mode. On the 80286, you can't LOADALL your way back to real mode once in protected mode. While you can use the BIOS call, which involves the keyboard controller (slow to respond to requests), you can also force a "shutdown" via a triple fault from protected mode, which avoids the wait from the keyboard controller. You still need to record the "cause" in CMOS so the POST code needs to know what to do.

The last sentence is telling to me- is the POST code you send to RAM to reset the CPU using the keyboard controller the same POST code that you would send prior to triple-faulting the CPU? In both cases, how does the BIOS know where to jump to after protected mode exit? Must you also record that in CMOS?

I really want to create a 286 protected mode demo- one that preserves DOS and let's you continue using DOS after exit (no, not using a DPMI server- that's cheating ). One issue I have is:

Okay, I've created my descriptor tables, but now I need to move the PIC interrupts- on the 286 WHERE should I move them?

And the second issue is:

Okay, I'm in protected mode... now what should I do XD? Should I do a RAM test? Copy a file to and from a disk as an exercise for the 286's full potential? Make a small miniOS? Debugger? I have all this extra memory and cool features that I can use, so I better just not piss it away and rely on DOS.

It's one thing to get to protected mode- another thing entirely to figure out what to do, since I'm "on my own."

Possibly because it was so under utilized, the 286's Protected Mode interests me more than the 386's...

 

[cr1901]

I assume anything entering protected mode on a 286 would also need up the base vectors on the PICs and rearrange the vector tables to match much like a 386 protected mode entry.

I think the issue here is that CheckIt probably doesn't provide a PM handler for the keyboard interrupt. Why should it? So the keyboard interrupt never gets serviced and you're locked out.

When I first read Chuck's post, I thought he was insinuating that Checkit didn't revector the ISR at all. But now I'm thinking that he was implying that the ISR is revectored prior to the jump to PM and that the provided PM handler simply does nothing.

 

[Chuck(G)]

I'm working from my recollections of the 5170 BIOS--and I could well be wrong about this, but the shutdown syndrome byte in CMOS location 0Fh tells the POST routines how a shutdown was arrived at--and what to do next. I suppose you could do the restart into real mode using only RAM indicators, but you'd have to modify the BIOS, which gets control at reset. The pointer to the re-entry point after reset is in 40:67-6ah.

As an interesting aside, I find it curious that since about the P2 systems, the "1234h" warm reboot flag in RAM seems to be ignored. All my systems since about the P2 go through the full RAM and peripheral diagnostics the same way as a "cold" reboot. I've long wondered if this was to avoid hacking or simply that the old warm reboot didn't do a thorough enough job of resetting everything. Anyone know for certain?

 

[sergey]

As an interesting aside, I find it curious that since about the P2 systems, the "1234h" warm reboot flag in RAM seems to be ignored. All my systems since about the P2 go through the full RAM and peripheral diagnostics the same way as a "cold" reboot. I've long wondered if this was to avoid hacking or simply that the old warm reboot didn't do a thorough enough job of resetting everything. Anyone know for certain?

I think in PCI systems warm reboot usually resets PCI and ISA buses (just like cold reboot does). I am guessing this is done so that PCI cards and ISA PnP cards will be re-enumerated and initialized correctly.
This is somewhat related: http://www.pcisig.com/reflector/msg02968.html

 

[Chuck(G)]

That doesn't explain why BIOS makers insist on doing a RAM diagnostic on a reboot. I have a Supermicro server here that takes much longer to do the (ECC) RAM diagnostic than it does to do the OS load. I can quite literally go get a cup of coffee before the OS load menu comes up.

 

[sergey]

That doesn't explain why BIOS makers insist on doing a RAM diagnostic on a reboot. I have a Supermicro server here that takes much longer to do the (ECC) RAM diagnostic than it does to do the OS load. I can quite literally go get a cup of coffee before the OS load menu comes up.

Running a full diagnostic on reboots on servers is actually a good idea. Servers might run for years without being (cold) rebooted, and some hardware failures could to occur during this time. These failures otherwise might go unnoticed causing silent data corruption. Systems with ECC memory will catch and try to correct errors. Some systems even have a capability to report these errors to OS... but some (most?!) systems don't.

 

[Chuck(G)]

It'd be better if the diagnostic-on-reboot could be bypassed.

 

[njroadfan]

That doesn't explain why BIOS makers insist on doing a RAM diagnostic on a reboot. I have a Supermicro server here that takes much longer to do the (ECC) RAM diagnostic than it does to do the OS load. I can quite literally go get a cup of coffee before the OS load menu comes up.

This is BIOS dependent. The Award Modular BIOS 6.00G core on my one P4 machine doesn't do any RAM count on a warm reboot.

 

[Chuck(G)]

This is a Supermicro dual P3 server. It does have the Award BIOS.