From owner-freebsd-bugs Tue Feb 25 00:10:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA08022 for bugs-outgoing; Tue, 25 Feb 1997 00:10:10 -0800 (PST) Received: from aeffle.Stanford.EDU (sequence.Stanford.EDU [171.65.76.7]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA07981 for ; Tue, 25 Feb 1997 00:09:59 -0800 (PST) Received: (from hlew@localhost) by aeffle.Stanford.EDU (8.8.4/8.6.6) id AAA06425; Tue, 25 Feb 1997 00:09:42 -0800 (PST) Date: Tue, 25 Feb 1997 00:09:42 -0800 (PST) From: Howard Lew To: Bruce Evans cc: freebsd-bugs@freebsd.org Subject: Re: kern/2787: Cyrix 150+ CPU is seen as a 486, Kernels made for , i586 don't recognize the chip as 586. In-Reply-To: <199702240606.RAA24906@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 24 Feb 1997, Bruce Evans wrote: > >>At boot time, Freebsd sees the Cyrix 150+ (120Mhz) as a 486 instead of a > >>Pentium 120. When I build a kernel with the i586 option, it fails > >>to boot, the error "unrecognized cpu" so I must re-make the kernel with > >>the i486 option instead - and loose performance. > > > >A Cyrix 686 has none of the Pentium features that I586_CPU selects. From > >an instruction set perspective it is a 486. But it plugs into a Pentium > >socket. Run it with I486_CPU defined. That is your only option. > > Kato Takenori (the chief pc98 committer) has a lot of changes for better > Cyrix identification. The 6x86 is still a 486, but it is identified and > some of its features are enabled. Some more of its features can be enabled > using compile-time options. sounds like great news... Is that in 3.0-current or 2.2 or 2.1.7 kernel? > > >Basically, the CPU naming game is pretty complex now, and is likely to get > >worse when Cyrix releases the M2 and Intel releases Klamath. It seems to > >me that I386_CPU and I486_CPU were good names, but I586_CPU and I686_CPU are > >not. We could replace them all with: CPU_386, CPU_486, CPU_PENTIUM, > >CPU_PENTIUM_PRO, CPU_CYRIX_M1, etc. Or we could conditionalise on the > >feature bits (and probably add some more of our own), without relying much > >on the actual CPU type. With MMX (and maybe other stuff) it looks like you > >have to anyway. Sounds like that is the approach Microsoft is using.... The new OEMR2 shows: Pentium: Pentium(r) AMD K5: AuthenticAMD Cyrix 6x86: CyrixInstead But it would still be nice to know what cpu is powering the FreeBSD box... It looks aesthetically pleasing when we do dmesg. > > Even I[5-6]86_CPU vs the rest require messy code with ifdefs for the features > and runtime tests to check the actual cpu_class. I486_CPU isn't so good > either, since non-Intel 486's sometimes have i586 features including a > cpuid instruction to tell you which features they have. I think we should > conditionalize on the features classified by cpuid to begin with. Many of > the ifdefs would have to go away. This is good provided the runtime cost > is tiny. > > >PS Umm, how does one close a PR? Or re-label it as a handbook/doc PR? > How about table method? > Run `edit-pr ' and change the relevant words (often simply change > "open" to "closed"). Save the file, quit the editor, then write something > for a log entry. The log entry gets mailed. > > Bruce >