ACPI woes in my O.S. [SOLVED]

[DaveG]

Firstly I would like to say hello to one and all as I have just joined the forum.
I have been a visitor for a while now.
Secondly, I apologize if I have posted in the wrong place.

I have made a simple Real mode OS from bits and pieces learnt from this and other forums.
The O.S. works fine, however on the newer machines with ACPI I get some strange behaviour
(which also happens in DOS 6.22 and Caldera DOS 7.02).

The strange behaviour is when using the ring indicator (R.I.) on the serial port, the machine freezes
whilst the R.I. pin is asserted then continues normally once the R.I. pin is de-asserted.
( the keyboard buffer even continues to work but the entered characters are only displayed when R.I. is de-asserted).

I have tried with the UART interrupts enabled and disabled, same thing.
I am starting to suspect it's an ACPI issue (wake-on-ring ?) and unfortunately the BIOS on many new machines (e.g. Intel D410PT)
do not allow one to totally disable ACPI.

Since I have no need for ACPI to control things like sleep mode, lid closure and openings, etc etc I would
like to inquire as to the possibility of disabling ACPI perhaps via I/O calls or even modifying the ACPI tables
as I am led to believe the ACPI does not make use of BIOS calls like APM did.

Is this something that is feasible from within Real Mode?

Thanking you in advance,
Dave.

[Combuster]

As far as prior art goes, it's rare and seems to be consistently related to driver issues. Did you implement your own serial interrupt handler or any other serial software? Does asserting RI lock up the PC during POST as well? How many machines have you tested and which exact chipsets reproduce the problem (and which ones don't)?

[DaveG]

Hello Combuster,

These machines don't cause a problem:

Old P1 200MHz MMX (desktop)
P111 600Mhz (desktop)
Micron transport TREK II (laptop)

These do:

Intel D410PT (desktop)
Compaq/HP nx7010 (laptop)
Toshiba Satellite P100-260 (laptop)

Most of the development is done under The nx7010 (compiling, making boot disks etc etc) and the physical
testing mostly done on the D410PT.

This is what I do:

Without using interrupts:

I set com1's uart's registers as follows:

IER (offset +1) set to all zeroes to disable all ints.
Then in reg MCR (offset +4) I set bit 3 low (AUX2) as this is used to also enable ints on the UART
and I set bit 1 high (RTS) and bit 0 low (DTR).
The reason for setting these last 2 bits hi and lo respectively is to generate a +V and a -V which I
then route back to Pin 9 (R.I.) via a toggle switch so I can change the R.I. status.

It all works well until I make R.I. high (-V in RS232 terms).
When this happens the machine freezes but recovers every time once I make R.I. low again.
(the display does not blank out and the keyboard buffer still works but the display is not updated).

So to answer your question about does it do it at post, no, as I have not made R.I. high yet.
The procedure described above I tried in my OS and in DOS and same result.

Using interrupts:

This I tried in DOS and simply redirected int 0Ch (com1) to int 3h just to see what would happen.
Same result as above.

In all cases when the machine returns to "normal" after de-asserting R.I. I do a read of the MSR reg (offset +6)
and bit 2 (Trialling edge Ring Indicator) is high meaning that R.I. did indeed change state.

So it seems to me that on the problem machines all of which have ACPI, this is a common issue.
R.I. seems to put the machines in some kind of sleep mode (S0 or S1 perhaps) and only come out of it
when that hardware event (as the ACPI specs describes it) disappears.

I should also add that when I boot Puppy Linux on the problem machines, all is well which is to be expected
as Linux has pretty good ACPI support.

From the little I understand of the ACPI specs, when an ACPI event occurs, it expects the OS to take over
control and deal with it and since I don't have any, it just sits and waits?

Dave.

[Combuster]

So to answer your question about does it do it at post, no, as I have not made R.I. high yet.

Then do so: it'll most likely show what I suspect and that your own code is setting the conditions for the lockup. (i.e. you are preventing other interrupts from firing)

[DaveG]

Combustor,

I suspect we are misunderstanding each other.
I use exactly the same code on all computers and it's only
a problem on the ones that I have listed in my previous posting.

I refer specifically to the code when I disable the interrupt associated with the com port only.
Since there are no UART interrupts being generated (when R.I. is asserted with the external switch)
I can't see why the computer freezes execution of my pgm, hence the reason why I am suspecting ACPI
as it only happens on the machines that have ACPI.

Dave.

[Brendan]

Hi,

The reason for setting these last 2 bits hi and lo respectively is to generate a +V and a -V which I
then route back to Pin 9 (R.I.) via a toggle switch so I can change the R.I. status.

So, you've got a noisy old toggle switch that is connected directly to a serial port input with no "switch debounce" circuitry; and you want to know why you're getting strange/erratic behaviour on computers with newer/faster/more sensitive chipsets?

From the little I understand of the ACPI specs, when an ACPI event occurs, it expects the OS to take over
control and deal with it and since I don't have any, it just sits and waits?

If the OS hasn't enabled "ACPI mode", then the BIOS/firmware handles ACPI events itself (using SMM or System Management Mode) and doesn't expect the OS to deal with ACPI events or anything else involving ACPI in any way at all.

For "Wake on Ring", it doesn't make any sense for ACPI or the BIOS to do anything at all unless the computer is actually sleeping. Also, most old computers that supported this had a BIOS option to enable/disable it. If this is the case, you can try disabling "Wake on Ring" in the BIOS to make sure that it has nothing to do with your problem. Of course most newer computers don't support "Wake on Ring" anymore (and most don't have serial ports either).

It is potentially possible that some computers may have buggy chipsets and/or buggy firmware/ACPI code. It's also very unlikely that several completely different computers (different chipsets, different firmware) have exactly the same bug.


Cheers,

Brendan

[DaveG]

Hi Brendan,

In this application it does not matter if there is switch bounce as any subsequent "false" triggers will
simply be indicated in bit 2.(i.e. the delta R.I. indicator will simply be set for each "false" trigger due to bounce).
It certainly does not explain the computer freezing.
Keep in mind that is is only a test and the final application will involve clean digital pulses going thru a MAX232.

You also mention that ACPI does not expect the OS to deal with events, I disagree.
What else then is AML and ASL for?

Although serial ports (and parallel ones too) are on the legacy list, many motherboards do still have them.
In fact the D410PT I mentioned has not one but two of them and all modern motherboards that have serial ports
do support wake-on-ring.
The problem is that wake-on-ring is now included as part of ACPI and some BIOSES do not allow the complete switching off of this.

I have been doing a lot of Googling and the "proper" implementation of ACPI seems to be something that has evaded
many manufacturers.
Google the following:
"computer freezes when phone rings" and you will see just how widespread the problem is.

Dave.

[Brendan]

Hi,

You also mention that ACPI does not expect the OS to deal with events, I disagree.
What else then is AML and ASL for?

AML and ASL is for OS's that actually do enable "ACPI mode".

Think of it like this. When the computer boots the computer is in "legacy mode" (and not "ACPI mode") and any power management events cause an SMI (System Management Interrupt) that causes the CPU to switch to SMM (System Management Mode) and execute the firmware's SMI handler. This is all entirely transparent to the OS.

If (and only if) the OS enables "ACPI mode" (typically done by writing a "trigger value" to a special IO port), the firmware reconfigures things so that all those power management events cause an SCI (System Controller Interrupt) instead of an SMI; and the OS is meant to handle the SCI (by using ACPI's AML). If the OS never enables "ACPI mode" then the computer remains in "legacy mode" and the SCI, AML, etc is never used (the BIOS/firmware continues handling everything in SMM).

I have been doing a lot of Googling and the "proper" implementation of ACPI seems to be something that has evaded
many manufacturers.
Google the following:
"computer freezes when phone rings" and you will see just how widespread the problem is.

Google for "haemorrhoids with puss" and look at all those search results - there's a massive haemorrhoid epidemic effecting almost everyone on the internet!

How many of those "computer freezes when phone rings" search results are from people with bad windows drivers, mis-configured modems, IRQ conflicts, dodgy phone lines, etc that have nothing to do with the firmware?


Cheers,

Brendan

[Combuster]

I suspect we are misunderstanding each other.
I use exactly the same code on all computers and it's only
a problem on the ones that I have listed in my previous posting

And both Brendan and I have said and suggested that forcing the blame on ACPI is most likely wrong based on how it works, and it is wrong just because you happen to have observed that as the common denominator (and you claim to have a P3 without it, which is odd to say the least) and probably did not look for other common points afterwards. Now will you try ringing the computer during early boot and again before any code of yours touches the serial port and post the result so we can actually see which one of us is right and get closer to actually solving this?

[DaveG]

Brendan,

May I suggest some Preparation H

What you said about the SMI and SMM makes perfect sense.
Since these are enabled at boot time by the BIOS, then perhaps there is also a way to disable it?
The problem is that the BIOS does not allow one to disable ACPI totally hence the reason for the freeze.

Combuster,
The PIII does allow complete switch off in the BIOS.

As you suggested, I blew the cob webs off my old dial-up modem, connected it to one of my "problem"
machines, the D410PT and if I ring my home number from my mobile the same thing happens.
What I did is make a simple routine to just print the character "D" to the screen in an endless loop.
Since I can't post a screen shot (running on a real machine versus a VM), I have included a diagram to show what happens.
Please note that at no time does any of my code go anywhere near the com port.

Dave.

[Brendan]

Hi,

What you said about the SMI and SMM makes perfect sense.
Since these are enabled at boot time by the BIOS, then perhaps there is also a way to disable it?

There's no way to disable SMI and SMM (without enabling "ACPI mode"). If you could it'd probably cause hardware failure (as it controls things like case and CPU fans, and "RAM scrubbing" for ECC), your keyboard may stop working (if it's a USB keyboard), various timers (PIT, CMOS) may cease to exist, the power button will stop working, etc.

As you suggested, I blew the cob webs off my old dial-up modem, connected it to one of my "problem"
machines, the D410PT and if I ring my home number from my mobile the same thing happens.
What I did is make a simple routine to just print the character "D" to the screen in an endless loop.
Since I can't post a screen shot (running on a real machine versus a VM), I have included a diagram to show what happens.
Please note that at no time does any of my code go anywhere near the com port.

Try that again, but change the value you print to the screen each time (e.g. "DEFGHIJKLMNO..."). Otherwise, it'd probably take 1 ms to fill the screen with "D" and after that you'd have trouble seeing the difference between new "D" characters and old "D" characters.


Cheers,

Brendan

[DaveG]

Good idea.
I will set up a counter and once say 4000 of one character are printed I change it for the next one in the alphabet.

Dave.

[DaveG]

Nope, same result.

As soon as the modem activates the R.I. line, the computer freezes
and once the R.I. line is de-activated (between rings or when I hang up), it simply carries on
from where it left off.

I read in the ACPI specs that the ACPI hardware events are wired in parallel
with the "normal" interrupts.
So even if I use the interrupts or not, it seems that ACPI takes precedence
and since the SMM routine is expecting to be serviced it waits for ever or until
the specific hardware event is no longer active.

So perhaps I should be looking at a simple way to service the SMM routine.
Is this even possible in Real Mode?

Dave.

[Brendan]

Hi,

Nope, same result.

Doh, I've run out of options. Do you have to use the ring indicator (rather than RTC/CTS or some other input)?

So perhaps I should be looking at a simple way to service the SMM routine.
Is this even possible in Real Mode?

No.

The firmware's SMM code is meant to be safely locked away in a special area in RAM (called SMRAM) that's normally inaccessible; so that regardless of how badly an OS might trash things it's still "safe". On some (hopefully rare) computers this SMRAM may not have been locked properly by the firmware, and it's potentially possible to modify the SMRAM area and the SMM code (which is scary if you think about malicious code - e.g. an undetectable and unremovable virus). Even in that case it's far from easy, and your replacement SMM code would have to correctly handle everything that the firmware's original SMM code handled (which is extremely motherboard specific). The only other alternative would be hack or replace the firmware itself, so you can modify the SMM code in flash-ROM (before it's copied to the SMRAM area). You might be able to hack a BIOS upgrade or write your own firmware (but it's more likely you'll end up with a computer that crashes during POST if you try that). The only other alternative would be to replace your BIOS with coreboot (but I wouldn't want to assume coreboot's code is without bugs, or that your computer/s are actually supported).

The only other option would be to enable "ACPI mode" so that the firmware's SMM code isn't used for much. That's not easy either (you might be able to port ACPICA if you've got enough "required functionality" already).

The easiest possible solution is to stop using the ring indicator input. The next easiest option would be using Linux or FreeBSD or something that supports ACPI already (but there's no guarantee that will actually work in all cases). If neither of the easy options are possible, then all of the other options will probably cost you months of hard work (per motherboard).


Cheers,

Brendan

[DaveG]

No problem, thanks for all your ideas and suggestions.
I was worried that ACPI was a bit "nasty" and unfortunately I was right.

The reason I need R.I. (together with all the other lines) is that I am actually
feeding the outputs to a TTL demux and then use the input lines to read from
external logic inputs (via MAX232) and I need 4 of them.

In essence I am using the serial port as a sort of mini parallel port and by using
the lines of the com port individually, I save by not having to use another UART
to serialize my external data before feeding it into the computer.

I rather like the D410PT board as it's pretty stable, does not need a noisy fan and
is pretty cheap (aprox $65).

Oh well back to plan-B, which is using the lines on com 2 (yet another reason I like this mobo, it has two com ports).

Dave.