By: Robert Collins on Intel newgroup
Subject: Intel deserves a Class Action lawsuit
Followup-To: comp.sys.intel,comp.lang.asm.x86
Date: 11 Jan 1998 14:44:43 -0800
Organization: Intel Secrets Web Site: x86.org
Lines: 130
Message-ID: <69bi0r$mbr@slip.net>
Reply-To: rcollins@x86.org
NNTP-Posting-Host: slip-3.slip.net
A few days ago, I was debugging one of my programs. During my program, an SMI# occurred, and I entered System Management Mode (SMM). Upon resumption from the SMM handler, my program hung. I don't know why the program hung, but I figured out a work-around. Now I'm looking for an explanation why my workaround fixes the problem.
The computer is a Pentium Pro (CPUID=617) on a Super Micro P6DNF
motherboard (BIOS=AMI v1.10).
I hooked up the computer to my logic analyzer and in-circuit emulator to see why the program was crashing upon resumption from SMM. The SMM hander was very simple. In fact, it didn't even do anything but change the resume EIP to my DOS exit routine and return to my original program. Using the logic analyzer, I noticed that a few of the undocumented areas of the SMM state save map had very peculiar values.
Every time an SMI# occurred where upon my program hung from an SMM exit, the location at SMM offset 0x7F1E contained the value 0x0021. Likewise the value at SMM offset 0x7F23 contained 0x01. Through some experimentation, I noticed that clearing the value at 0x7F23 to 0x00 allows my program to continue and return to DOS. With all due respect (whether it's deserved or not), I demand that Intel provide a public answer why setting SMM offset 0x7F23=00 fixes my problem and allows my program to resume without hanging. Why does my program continue to hang when SMM offset 0x7F23=01, but works correctly when SMM offset 0x7F23=00?
*** SOAP BOX=ON ***
While I was searching for an answer to my problem, I searched all of
the Pentium Pro manuals, the new Intel Architecture manuals, and the Pentium Pro specification update for answers. I didn't find a single description of this behavior, or a description these two locations of the P6 SMM state save map. Likewise, the errata documents didn't turn up any relevant information either.
I'm quite aware that Intel delayed the shipment of the new Intel
Architecture manual (volume 3) for six months. I assumed that the delay was used by Intel to make sure the manual was much higher quality than the inaccurate crap they've been calling "manuals" for the past 8-10 years. In search of my answer, I only had enough time to read the SMM chapter.
As I read the SMM chapter, I was amazed at the level of inaccuracies,
bordering on intentional deception. Some of the information is *TOTALLY WRONG.* If an engineer wrote an SMM handler based on Intel's disclosures within this chapter, their SMM handler might not even work. Intel's behavior is irresponsible, incompetent, and borders on a reckless disregard for the engineers who must use these manuals.
The real disappointment comes from the realization of knowing that Intel has correctly documented these behaviors, and given this information to the "holders of the secret gold books." But to the 99.999% of the remaining engineering world who doesn't have access to their NDA documents, we must write programs based on what they choose to publicly document. Then we must hope that Intel hasn't lied to us. In my case, the latter is true. My program crashed because I'm not one of the chosen 0.001% of engineers who are "blessed" with Intel's truthful documents. I'm in the category of engineers who must suffer with the inaccurate documents that are publicly released.
This is only the 50th time or so that I've wasted countless hours
debugging my program, because Intel wouldn't, couldn't, or chose not
to tell the truth in their manuals. This wanton disregard for the
countless hours of wasted resources, by engineers all over the world
must end. Unfortunately, the only way I can see this goal being
achieved is through litigation -- like a Class Action lawsuit on
behalf of all of the engineers in the world that have wasted hundreds
of hours debugging programs, only to find out that Intel refused to
release manuals which contain accurate information. In my case, Intel
refused to document the SMM state save map locations 0x7F1E and 0x7F23. As a direct result of their refusal to document these two locations, I wasted about eight hours of my time. This situation is totally unacceptable, and it must end.
Secondly I searched the Pentium Pro errata documents. I was shocked at how many bugs related to SMM. I was even more shocked that some
errata already existed for the new Intel Architecture Manual (volume
3). I was flabbergasted to find a new errata gave a totally bogus workaround to a specific problem. In fact, I've written a magazine article about this bug and provided source code to prove that their workaround is totally bogus. So why does this new errata exist -- describing this totally bogus workaround? Is this just incompetence or intentional deception?
Intel obviously doesn't care how many engineer's time they waste. I'm
speaking of engineers who aren't blessed with Intel's "gold books"
or people like DEC and Intergraph who have found their gold books taken away because Intel acted like a playground bully, having the gold books removed when they got mad. These engineers, like myself, depend upon these manuals to be somewhat accurate. We write programs based on these manuals. Then when our programs don't work, we waste countless hours debugging them. In the end, we discover that Intel's manuals were wrong, and often times intentionally omitted a description of the correct microprocessor behavior.
In the case of my program, I discovered by trial and error that I
could work around the problem. Now I'm left with the realization
that I wasted a day's worth of work because Intel was too paranoid
to tell the truth in their manuals. Why should I complain? After
all, this is only the 50th time this has happened in my career!
As far as I'm concerned, Intel has absolutely no right to waste
my time because they are too paranoid to tell the truth in their
manuals. Their misleading manuals have cost me hundreds of hours
spent over many dozen debugging sessions. I wonder how many more
engineers suffer the same fate? I'll bet hundreds of engineers
have spent tens of thousands of wasted hours because Intel refuses
to tell the truth.
As far as I'm concerned, if a Class Action lawsuit were filed against
Intel because of this, they would certainly deserve it. There is
absolutely no excuse why hundreds, maybe thousands of engineers should
waste their time because Intel refuses to give enough disclosure in
their public documents to allow the engineering community to accurately write our programs.
*** SOAP BOX=OFF ***
So, Intel. I expect an answer why clearing SMM location 0x7F23=00
fixes my problem. What do you say? Do you feel like telling the
truth today?
--
"Intel Secrets -- What Intel doesn't want you to know"( ) Robert Collins
HomePage: x86.org Anonymous FTP: ftp://ftp.x86.org
---------------------------------------------------------------------- ftp://ftp.x86.org
----------------------------------------------------------------------
Robert Collins mailto:rcollins@x86.org 408.832.6270 |
