Date: Tue, 25 Feb 1997 00:09:42 -0800 (PST) From: Howard Lew <hlew@sequence.Stanford.EDU> To: Bruce Evans <bde@zeta.org.au> 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. Message-ID: <Pine.OSF.3.91.970225000235.6202D-100000@aeffle.Stanford.EDU> In-Reply-To: <199702240606.RAA24906@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <number>' 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.91.970225000235.6202D-100000>