Date: Thu, 18 Jan 1996 16:22:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: john@starfire.mn.org Cc: hackers@freebsd.org, www@freebsd.org Subject: Re: CPU compatibility Message-ID: <199601182322.QAA06536@phaeton.artisoft.com> In-Reply-To: <199601182123.PAA04733@starfire.mn.org> from "john@starfire.mn.org" at Jan 18, 96 03:23:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> After checking the back of the FreeBSD 2.0.5 and FreeBSD 2.1 CD's and > the handbook, I have not been able to find out any specifics on CPU > compatibility. I noticed that the PC Hardware Compatibility link in > the Appendices of the handbook has disappeared (possibly due to a lack > of contributions, as it was pretty skeletal in the 2.1 release). > > My basic question is this: am I playing with fire trying to use Cyrix > CPU's? My MainBoard seems to run FreeBSD 2.1 just fine with an Intel > 80486DX(33), but when I rejumper and put in the Cx486DX2(66), I get > random reboots, shell and grep doing SEGV's, etc. This happens with > either or both caches enabled. The system is so slow with both caches > disabled that I am better off running the DX than the DX2. Cyrix went to IBM "blue lightning" based mask designs some time ago. Older Cyrix parts using the Cyrix/TI chipmasks (and older TI parts) will neither update nor invalidate L1 cache when a bus master device writes to main memory: so when you go to read after a transfer complete interrupt, you will get an L1 cache hit and get invalid data. The generic fix for this is to disable the L1 cache. Some motherboards do not update L2 cache when a bus master device writes main memory. This is a either a flaw in the cache controller chipset, a bad jumper setting, or a bas CMOS advanced options setting. The result is an L2 cache hit on invalid data. The generic fix for this is to disable the L2 cache. In general, Cyrix/TI L1 caching is disabled unless the BIOS recognizes the chip and specifically enables it. Most BIOS which does this has the option to turn the cache off, and off will be the default. If you switch to non-bus mastering DMA using controllers, the problem will also "go away". If you are adventurous, you can detect the Cyrix. An explicit BINVD for the read buffer transfer area you give to the controller, after you issue the controller command so the I/O can be processing while you are invalidating, will fix the problem. This would have to be hacked into the disk controller driver, though there should probably be some more general hooks for area reporting and a general flag for cache invalidation so it will be respected by all drivers. Look for the string "CYRIX" in /sys/i386/*/* files for more information on fixing th problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601182322.QAA06536>