Messages in this thread | | | From | "Tom Sightler" <> | Subject | Cyrix Detection hangs machine on 2.0.35, 2.0.36pre13, and late 2.1.1xx | Date | Thu, 15 Oct 1998 08:25:51 -0400 |
| |
OK,
I've had this problem for a while but finally decided I should post it, especially since it's happening with the stable kernels as well. We have several fairly old machines that use the Cyrix 468DRx2/50 and 486DRx2/66 upgrade. These upgrade a 386 to something similar to a 486 and have always worked well as small linux boxes for routing, firewalling, small web servers, etc. However, upon compiling 2.0.35 I've found that these machines hang at Calibrating delay loop..., also, all the recent 2.1.xxx versions do the same, as well as 2.0.36 pre13. There was a version of 2.1.xxx around 110 that has temporarily disabled the enhanced chip detection and this version did boot on these machines.
I modified head.S back to the old 2.0.34 version and it passed Calibrating delay loop but then the machines would hang during the 'hlt' test. After much testing it seems that the problem is caused by head.S and bugs.h when they attempt to enable CPUID on these proccessors. If I remove these instructions from both places everything works properly.
My current workaround was to move the DIR0 test in head.S immediately before the attempt to enable CPUID thus giving it the opportunity to skip this code. I also added this same test to bugs.h immediately prior to the attempemt to enable CPUID there. This works for my machine and it now properly detects the chip as a Cx486 with unknown multipliers, stepping, etc.
My concern is that this may break detection of some versions of the Cyrix chips (although I'm not sure how). I'm unclear why we would attempt to enable CPUID before we check to see if we have a 6x86 class chip to begin with, but I assume it's due to the way some Cyrix chips are configured. The other solution would be to determine a way to detect these older DRx2 chips before the 6x86 and thus avoid the problem all together.
Everything I've said is from looking at the code and determining how it works on my machine and is not based on any knowledge of the Cyrix chips other than source code from the kernel and the Linux Cyrix 486DLC cache set utility. Of note, even after my changes, the kernel now properly detects my Cx486DRx2, my wifes CX6x86/133, and my own Cx6x86MMX/233 with no problems (of course it worked with two out of three of those before, but at least I didn't break it too much). These were the only Cyrix mahchines I have access to, but are a fair sampling.
Any other comments would be appreciated.
Later, Tom Sightler
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |