Fred:
Thanks again for a lucid explanation of things.
To address the final point first, the "second" SATA interface isn't an add-on card at all, but is actually on-board and simply separate from the ICH7 ports (for reasons that aren't exactly clear, it actually leaves one of the ICH7 channels unused and "replaces" it with the Sil3531-based channel). The BIOS is a Phoenix "StrongFrame" BIOS with a release date of 10/20/2009, so it would appear to be very up-to-date.
On the network front, I am a bit chagrined by the reporting style of some of the "multiple-instance" tests in the DOS product, and would suggest a feature addition of a "verbose" style to the logs. I can appreciate the desire to keep things brief for those who may have only limited space in which to store a test log (e.g., RAM disk), but it would be nice to be able to get more thorough reports at the user's option.
For example, in the Network Link test, I get exactly the same log output when I have ONE port connected to a network as when I have NO ports connected -- that is, the log does not say that Port#1 PASSED, Port#2 FAILED, but merely that the loopback test FAILED. Period. Brevity may be the soul of wit, but this seems a tad too terse.
This also applies in a few other cases, where the test "hierarchy" has more than two levels. That is, when a test comprises several "sub-tests", the log file tends to list the results of each of these sub-tests (e.g., RAM Memory). But, sometimes, when another level intervenes, the lowest level results get "rolled up" into a summary report for the level above (e.g., the network and network link tests). Clearly, the product "knows" the results of these lowest level tests, as it must summarize them by some accumulation -- it simply doesn't log those results as it accumulates them. For instance, there is an "EEPROM Test" within each Port under the "Intel Network" test, but the results of this sub-test are rolled-up along with the Device Registers test and the Phy Loopback test, and all the other sub-tests for each of the two Ports to create one summary PASSED/FAILED report for the entire "Intel Network" test. On the other hand, the CPU/Coprocessor tests show all sub-tests (level 2) for all CPUs (level 1), rather than, for example, declaring that "CPU Registers" FAILED, and having to figure out which of the two CPUs might have been the culprit. This seems an anomaly in the product operation. As you may have surmised, lack of "parallelism" is something of a pet peeve of mine, but in this case it really does have a substantive affect on what I can say and cannot say about the product I am testing. I don't know how likely it is that this would change any time soon.
Any approach you think seems reasonable on the SMBus front would be welcome. Just let me know what kind of information might help you deduce what is going on. As I mentioned, the SMBIOS Info screen does report SM BIOS support at revision 2.3, for whatever that's worth. Once you get down to system slots and memory devices, however, there are a lot of "Unknown" and "N/A" entries, leading me to conclude that communication over the SMBus is not succeeding. Since the board does boot, however, I suspect that the BIOS itself is correctly communicating to devices via the SMBus. This makes it appear as though the SMBus is not properly useable by clients of the BIOS -- such as PC-Doctor, for example, or -- pointedly -- any driver-level code I might want to put on the board.
