From owner-svn-src-head@FreeBSD.ORG Sat Mar 20 08:24:54 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87F11106566C for ; Sat, 20 Mar 2010 08:24:54 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from hosting.nash.net.ua (hosting.nash.net.ua [193.151.252.10]) by mx1.freebsd.org (Postfix) with SMTP id 778528FC19 for ; Sat, 20 Mar 2010 08:24:53 +0000 (UTC) Received: (qmail 431 invoked by uid 509); 20 Mar 2010 08:09:51 -0000 Received: from ravenloft.kiev.ua (94.244.131.95) by hosting.nash.net.ua with SMTP; 20 Mar 2010 08:09:51 -0000 Date: Sat, 20 Mar 2010 10:09:20 +0200 From: Alex Kozlov To: Bruce Evans , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI , spam@rm-rf.kiev.ua Message-ID: <20100320080920.GA80859@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: Re: svn commit: r205307 - head/sys/i386/conf X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 08:24:54 -0000 On Sat, Mar 20, 2010 at 01:27:24AM +1100, Bruce Evans wrote: > > No, this is wrong. Revert this. We do _not_ unconditionally use SSE in the > > kernel. GENERIC should run just fine on a 486. If it doesn't, that should be > > fixed, but I have not seen any reports to the contrary. > Indeed. This doesn't even break the non-SSE case, since it doesn't > remove I686_CPU or any of the code that dynamically chooses whether > to use SSE. > > Most 686's don't have SSE, since a 686 is an old name for a PentiumPro > or maybe a Pentium2 and these don't have SSE (not sure about the > Pentium2, but my old Celeron is Pentimum2-class and it only has FXSR). > However, we keep using this old name for all generations of i386's > after i586, even for generations that are really HAMMERs. Thus the > static configuration related to I*86_CPU is almost usless: it controls > only couple of options for i486 and i586, with the more complicated > and costly configuration for post-i586 being handled dynamically. > Omitting I486_CPU and I586_CPU thus has very little effect except > breaking i486 and i586, and having these options does little except > support this foot-shooting. The effect of I486_CPU is especially small. > It is: > - statically disable use of the TSC in the bogus get_cyclecount() API. > Although the TSC is dynamically configured elsewhere, this function > wants to use the TSC without any dynamic tests, so it is uses static > configuration for efficiency. > - avoid compiling in functions to initialize a 486. There is dynamic > code to use these functions as needed, but this optimization saves > a few hundred if not a few thousand bytes. > - panic if the CPU is an i486, since the necessary extra support for > an i486 (just the above 2 features) is not present. > I586_CPU gives a little more. E.g., support for fixing the F00F hardware > bug on some Pentium1's. Again there is dynamic configuration for this > but a few hundred bytes are saved by not compiling it in. To be more elaborate: i486: - use binuptime in get_cyclecount, but only if tsc_present not set - assign bzero_vector = i486_bzero if cpu family 486 - few initcpu functions for IBM Blue Lightning/Cyrix 486SLC,DLC/Cyrix 486DX/Cyrix 5x86/Cyrix 6x86 - don't panic on i486 i586: - f00f workaround - few initcpu functions for k5/k6/k6-2 to enable write alloc but only if CPU_WT_ALLOC defined - * few (i586_bzero,i586_bcopy,i586_copyout,i586_copyin,fastmove) unused functions in sys/i386/i386/support.s. Code which was supposed to initialize them were commented out in 2001 (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/npx.c.diff?r1=1.94;r2=1.95;f=h) This need to be fixed in any case. - don't panic on i586 i686: - define CPU_ENABLE_SSE - few initcpu functions for Cyrix 6x86MX/Pentium Pro/Mendocino celeron if CPU_PPRO2CELERON set - use sse2_pagezero if CPU_ENABLE_SSE set, i686_pagezero otherwise - don't panic on i686 So, yes I?86_CPU is practicaly noop. -- Adios