October
97 News
Sunday,
november 30:
You will find two new patches in my Kernel patches page:
Sunday,
november 23:
Many visitors asked specifically for it, so I added a step-by-step description of the procedure to setup an Address Region Register (ARR) using set6x86. You can find it in the 6x86 registers page.
I want to thank again the various visitors that have contributed to these pages with their positive comments and suggestions in the Guestbook. Basically, your feedback determines the information that I keep adding to this site.
Friday,
november 21:
I stated on Monday that the 6x86MX architecture was the most efficient x86 architecture available in terms of performance/MHz, when compared to the AMD K6 and the Intel P54C. Well, I was wrong! I received a K6 processor yesterday and proceeded to test it at various core speed settings.
Results: the AMD K6 matches (and even beats in some cases) the 6x86MX in terms of performance/MHz.
In terms of Linux performance/$, the 6x86MX and the K6 are equivalent: they provide the best per-dollar performance available. However, whereas the 6x86MX occupies the lower part of the price/performance curve, the K6 caters for the upper segment of the Socket 7 compatible market:
|
Processor |
Clock |
Multiplier |
Kernel compilation in |
Street price* |
|
6x86MX PR166 |
133MHz |
(2 x 66) |
5 min 37 sec |
$ 85 |
|
6x86MX PR200 |
150MHz |
(2 x 75) |
5 min 03 sec |
$ 120 |
|
6x86MX PR200 |
166MHz |
(2.5 x 66) |
4 min 30 sec |
$ 120 |
|
AMD K6-166 |
166MHz |
(2.5 x 66) |
4 min 30 sec |
$ 140 |
|
6X86MX PR233 |
166MHz |
(2 x 83) |
4 min 20 sec |
$ 290 |
|
AMD K6-166 |
166MHz |
(2 x 83) |
4 min 10 sec |
$ 140 |
|
6X86MX PR233 |
187.5MHz |
(2.5x75) |
4 min 09 sec |
$ 290 |
|
AMD K6-200 |
200MHz |
(3 x 66) |
4 min 02 sec |
$ 188 |
|
AMD K6-200 overclocked |
208MHz |
(2.5 x 83) |
3 min 37 sec (EDO) |
N/A |
|
AMD K6-233 |
233MHz |
(3.5 x 66) |
3 min 37 sec (SDRAM) |
$ 340 |
| *: street prices in USD, from a small sampling of Web sites on 11/23/97. | ||||
In marketing terms, the AMD K6 is getting squeezed by Intel's P-II from above and by Cyrix' 6x86MX from below. Positioning the AMD K6 in the middle of the overall x86 processor price/performance curve is a bad strategic decision.
NS/Cyrix made a deliberate choice to occupy the lower segment and this marketing strategy seems to be paying off, specially with its MediaGX line of processors for "appliance" PCs. However, I haven't had any reports of GNU/Linux running on MediaGX processors so I can't speculate on compatibility issues for this particular processor.
In terms of performance the Cyrix MediaGX processors, based on the old 5x86 core, should be far below the relatively cheap 6x86MX PR166. I wouldn't consider them interesting for general purpose GNU/Linux use, but they look like good candidates for the future "< $500" applicance PC. Again, that fits well in the NS/Cyrix strategy.
One can also wonder how much profit NS/Cyrix is making on the IBM-manufactured 6x86MX PR166, with a die size of 197 mm2 and sold for just $85 retail. Certainly NS/Cyrix has a different strategy compared to Intel, who we can assume makes > $300 net profit per PII-300 sold, with a smaller die!
Monday,
november 17:
I have improved my small Cyrix Linux kernel patch: it now correctly identifies the various 6x86 CPU models, and even the stepping of the chips. And it has been tested with kernel 2.0.32pre6. This is just an aesthetic improvement, but many Linux users asked for it specifically. The usual reminder: this patch must be used with set6x86 for optimum performance and to workaround the 6x86 Coma bug. See my november 4 announcement for a detailed description of the patch, and also check the Kernel patches page.
Also, here is an update of my Linux kernel 2.0.0 compilation benchmarks:
|
Processor |
Clock |
Multiplier |
Kernel compilation in |
|
P54C |
150MHz |
(2 x 75) |
6 min 49 sec |
|
6x86L |
150MHz |
(2 x 75) |
6 min 43 sec |
|
6x86MX |
150MHz |
(2 x 75) |
5 min 03 sec |
|
6x86MX |
166MHz |
(2.5 x 66) |
4 min 30 sec |
|
6x86MX |
166MHz |
(2 x 83) |
4 min 20 sec |
|
AMD K6 |
233MHz |
(3.5 x 66) |
3 min 37 sec (SDRAM) |
The Intel Pentium is nearly as fast as the Cyrix 6x86L (the 2% difference is almost within the 1% error margin of this test); this was expected since these chips are of the same generation.
However, this test evidences the obvious Windows bias in the PR rating system: the 6x86L chip at 150 MHz is rated by Cyrix as equivalent to the Pentium 200, but this benchmark clearly demonstrates this is not the case for general purpose Linux use. Cyrix also rates the 6x86MX at 2 x 83 MHz as a PR-233 part, but again we notice it is far behind the AMD K6 at 233 MHz. The conclusion is that PR ratings should not be used as an indicator of performance under GNU/Linux.
Also note that in terms of performance / MHz, the 6x86MX is clearly the leader of the x86 processors tested above. And with its power-down mode enabled, it is also the coolest-running high performance processor. I will soon have more x86 processors available for further testing, so stay tuned!
Saturday,
november 15:
After some investigation and exchanging some Emails with Alexander Konosevich, here is what I found out: Serguei Shtyliov (Moscow) initially discovered the Cyrix Coma bug while writing an IDE disk driver in assembly language; Alexandr Konosevich (Omsk, West Siberia) investigated it further and produced the first public announcement about it in c't magazine, as reported on these pages 6 days ago.
Thursday,
november 13:
I am changing the name of the bug to Cyrix Coma bug, since the original name is misleading.
As promised, here is the (un)official Cyrix workaround, ported to GNU/Linux. Note that I still recommend the NO_LOCK workaround for 6x86 GNU/Linux users.
You should add the following lines to your rc.cyrix script, in the part where it has MAPEN enabled:
Be careful to copy exactly as shown, particularly the -c on the third line. Basically what this script does is setup the 6x86 for detection of the xchg opcode (0x87). When detected in the instruction stream, the xchg opcode will be serialized, bypassing the pipeline.
The performance hit of this solution is almost zero.
It's a really neat solution, except for the fact that it makes use of an undocumented feature of 6x86 family CPUs. I wish Cyrix would put up an Application Note for the undocumented registers they used in their workaround.
Wednesday,
november 12:
I received a vague reply from Cyrix telling me that they are aware of the bug.
They also sent me a short DOS utility that effectively solves the problem by serializing the xchg opcode (bypassing the pipeline); only they forgot to send me the source code, and obviously their short utility only solves the problem for DOS/Windows95 users.
Bah. I disassembled it, and it makes use of undocumented registers in the 6x86 family CPUs. You should have an equivalent set6x86 script for GNU/Linux available from my site by tomorrow morning, with a complete description of how this works.
Monday,
november 10:
I received a short reply from Cyrix that my email "has been forwarded to the proper people". That's all.
Meanwhile, I added a technical explanation of the bug in my 6x86 Coma bug page.
Thanks to Mike Jagdis and Alan Cox who both contributed to this preliminary technical explanation. I guess it could get better as soon as I manage to reach a hardware engineer at Cyrix.
Sunday,
november 9:
STOP THE PRESS AGAIN NEWS: Cyrix 6x86 family chips (all of them: the classic 6x86, the 6x86L and even the 6x86MX) have a bug with exactly the same implications as the new Pentium "F0" bug. A short user-space program will send these CPUs to limbo. What's more, the bug seems to have the same technical origins as the Pentium F0 bug: inadequate handling of locked bus cycles by the CPU instruction decoder logic. But the two bugs should not be confused.
I didn't find the Cyrix bug. It was found by Serguei Shtyliov (Moscow) and co-reported by Alexandr K. Konosevich (Omsk, West Siberia) and editor Uwe Post in an online article in the highly regarded German c't Magazine: "Bug in Cyrix Prozessoren".
And now the good news: there is a simple, inocuous workaround for the Cyrix bug!
It should work equally well under all OS's. This is not a GNU/Linux-specific solution (although as a GNU/Linux user you are getting it ahead of anybody else). You can use set6x86 to implement it, or any other utility or patch that will allow setting the 6x86 configuration registers.
Read all about this new bug and a workaround for it in my 6x86 Coma bug page. I sent an email to Cyrix about this problem.
BTW, I changed the processor bug score I put up yesterday. The new score is:
Cyrix: 0, Intel: -0.00038723568109 ;-)
Saturday,
november 8:
STOP THE PRESS NEWS: Richard B. Johnson has just reported a new Pentium bug that makes it possible for any user to stop (crash) a Linux system with a single-line program:
char x[5]={0xf0,0x0f,0xc7,0xc8,0x00}; main() { void(*f)() = x; (*f)(); }
There are in fact various instructions that will simply stop both the Pentium Classic and Pentium MMX processors dead, and are not trapped even if executed in user space. This is very bad news for tens of thousands of users.
An example: if you are an ISP, are using Intel-based server equipment and have user accounts on your servers, than any user can stop your system dead. And right now there is nothing short of processor replacement that will solve this problem!
And now guess what? Cyrix processors don't have this bug! The illegal instructions are adequately trapped :-)
I tested the 6x86L and 6x86MX, and both reported the illegal instruction and continued humming nicely. The old 6x86 is reported to be OK too.
Cyrix: 1, Intel: -0.000712765430978 ;-)
Friday,
november 7:
Kernel bug news: I am being helped by Tomasz Motilewski and Ingo Molnar (thanks, guys) to find where exactly the problem is. It seems Tomasz has never had this kind of problem on his 6x86MX Rev. 1.4, but we are using slightly different configurations. This is the kind of nasty bug that is very difficult to reproduce. On the other hand, after I applied my patch, I never saw a problem on my 6x86MX Rev. 1.3...
Stay tuned, anyway. We'll sort this one out ;-)
Tuesday,
november 4:
A new Cyrix patch (shift-click to download). It adds < 50 bytes to the kernel image, and about a dozen lines to the source code.
"Simplicity is achieved by the elimination of special cases..." - Brian Kernighan and John Mashey.
I have put together a new, short, simple Cyrix patch for both 6x86(L) and 6x86MX users. It addresses three separate problems:
What this patch does not do:
This patch can be used against kernels 2.0.29, 2.0.30, 2.0.31, and probably most earlier 2.0.x kernels and later 2.1.x kernels. It is perfectly inocuous on non-Cyrix machines.
I see no reason for not including this patch in the regular kernel source. As soon as it is sufficiently tested, I will send it to Linus. He may or may not include it in kernel 2.0.32.
If you have a 6x86MX Rev. 1.3 CPU, you should definitely apply this patch. If you have a 6x86 or 6x86L on an old motherboard and get a low bogomips value on kernel boot, then again you should use this patch. Otherwise, there is no particular reason to apply this patch; but it won't cause any problems either.
One last warning: I have tested this patch on the equipment I have available (a 6x86L and a 6x86MX Rev. 1.3). Use at your own risk.
Monday,
november 3:
Linux kernel bug report
There is a problem that affects kernels 2.0.29, 2.0.30, 2.0.31 and probably earlier 2.0.x and all later 2.1.x kernels. It only appears on the 6x86MX. If you have a 6x86 or a 6x86L, you won't ever experience this problem. The problem is related to the new Time Stamp Counter feature in the 6x86MX.
This problem causes a kernel error when the do_gettimeofday function is called (e.g. some network daemons call this function), and more specifically when do_gettimeofday is setup to call do_fast_gettimeoffset. I don't know if this happens every time the function is called or only in specific circumstances. On my 6x86MX box, it appears at intervals of 1 or 2 hours.
A one-line patch to file arch/i386/kernel/time.c will solve this problem:
Find the line if (x86_capability & 16) { towards the end of time.c. Replace with:
if (0) {
This replaces function do_fast_gettimeoffset, which appears to cause divisions by 0 on my 6x86MX Rev. 1.3, with function do_slow_gettimeoffset, which works fine. Note that do_slow_gettimeoffset does not use the Time Stamp Counter.
I have already reported the bug to the linux-kernel mailing list.
Sunday,
november 2:
I added a few paragraphs on the VIA VP-2 and VP-3 chipsets to my Motherboards page.
I have a question for those of you that take a look at my site from time to time: do you think I should add photographs of the motherboards mentionned in my Motherboards page? Right now I only have text, so it looks a little dull. On the other hands those JPEGs take a long time to load...
Also, I want to thank those of you that stopped by my Guestbook page. It really helps to have this feedback, and you will be sharing your experience with other Linux 6x86 users.
October
97 News
Last updated on November 30, 1997.
Copyright 1997 Andrew D. Balsa