Dimitromanolakis Apostolos writes:
>
> I was reading some time ago people reporting that they get low bogomips
> ratings on Pentium systems. I found it weird because I get 199.07 bogomips
> on a AMD K5 at 100Mhz. Here is my dump from /proc/cpuinfo;
>
> processor : 0
> cpu : 586
> model : 0
> vendor_id : AuthenticAMD
> stepping : 1
> fdiv_bug : no
> hlt_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid : yes
> wp : yes
> flags : fpu vme de pse tsc msr mce cx8 apic
> bogomips : 199.07
>
> This faster than what I get on some P166 systems.
>
> Anyway, my real problem (that may be related to the above info) is that
> pipes do not work reliable on my system. It seems gcc -pipe always fails
> (either hangs or segv's). Is there such a problem on other K5 machines?
This report claims it's a bug in the early versions of the K5. I've
not seen the bug in my stepping 1 K5, myself, but then I'm mostly
working on FreeBSD. Although Ioannis mentions the K6 bug and burnit,
it appears that he found a different bug on the K5.
--jh
--nWnLkFXL5K
Content-Type: text/plain
Content-Disposition: inline;
filename="k5"
Content-Transfer-Encoding: 7bit
Article: 50363 of comp.os.linux.hardware
Path: news-central.tiac.net!news-feed1.tiac.net!news.maxwell.syr.edu!news-peer.sprintlink.net!news.sprintlink.net!Sprint!vixen.cso.uiuc.edu!uwm.edu!uwvax!fox.cs.wisc.edu!schoinas
From: schoinas@fox.cs.wisc.edu (Ioannis Schoinas)
Newsgroups: comp.os.linux.hardware,alt.comp.periphs.mainboard.asus
Subject: Re: K6 and Linux problem SOLVED
Date: 21 Aug 1997 04:08:28 GMT
Organization: University of WI, Madison -- Computer Sciences Dept.
Lines: 68
Message-ID: <5tgevs$b21@spool.cs.wisc.edu>
References: <m3oh6sutcd.fsf@bash.linux-shell.net>
NNTP-Posting-Host: fox.cs.wisc.edu
Xref: news-central.tiac.net comp.os.linux.hardware:50363 alt.comp.periphs.mainboard.asus:54777
Simon Karpen <slk@bash.linux-shell.net> writes:
+First, relevent system config:
+Asus P55T2P4 Rev. 3.10.
+AMD K6/233 running at 233mhz (3.5x66)
+96MB LGS non-parity EDO DRAM
+Asus heatsink/fan on processor
+Extra fan blowing on voltage regulators
+The problem:
+Kernel compiles segfault around one of every 5-10 times
+(well, sig11, sig4, sig6...)
+The solution:
+compile your kernel for a 386. my theory is that the problem is
+pentium 4MB pages, but i'm still testing.
Ha! Computers will never seize to amaze me (if this indeed solves
the K6 problem). Did it make it through the burnit script?
As I said the problem with my K5lite and gcc is related to the invlpg
instruction. I traced the offending code in mm/memory.c. Changing
exactly one flush_tlb_page() call to flush_tlb() is sufficient to get
rid it of the gcc headache. It might be worthwhile to give it a try
on the K6.
Someone pointed out to me there is no reason for the K6 to have
similar problems as the K5 since the latter was developed by a
completely different team (NexGen). Cross-species jump, creepy...
Are bugs alive or what?
Anyway, the truth is that most commercial code out there is compiled
to run on 386's. This is certainly true for the "mainstream" operating
systems. As a result, it is not surprising that a processor can be
"certified" compatible (e.g., by XXCAL) even with bugs lurking in the
background. Hell, even the Linux distributions out there are all compiled
for 386's.
The following piece of code is from the 2.0.30 kernel source tree,
but it hasn't changed all the way to 2.1.51 (in case you are using
the development kernels). A more general solution is to always
invalidate the tlb by defining the flush_tlb_one() macro in
include/asm-i386/pgtbl.h to flush_tlb() (as it is for the 386's).
It may be possible that invlpg is totally broken but the error is
never encountered because of TLB replacements when going through
all the other paths.
pipa# diff -c memory.c memory.c.original
*** memory.c Wed Aug 20 22:13:50 1997
--- memory.c.original Wed Aug 20 22:00:14 1997
***************
*** 638,645 ****
flush_cache_page(vma, address);
set_pte(page_table, pte_mkwrite(pte_mkdirty(mk_pte(new_page, vma->vm_page_prot))));
free_page(old_page);
! if (vma->vm_mm == current->mm)
! flush_tlb();
return;
}
flush_cache_page(vma, address);
--- 638,644 ----
flush_cache_page(vma, address);
set_pte(page_table, pte_mkwrite(pte_mkdirty(mk_pte(new_page, vma->vm_page_prot))));
free_page(old_page);
! flush_tlb_page(vma, address);
return;
}
flush_cache_page(vma, address);
--nWnLkFXL5K
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
-- John Hood cgull@smoke.marlboro.vt.usPredictably, they all eventually wandered away, rubbing their bruises and brushing mud out of their hair. Some went off to work for the ESA, launching much smaller rockets into low orbits, while others elected to sit on their front porches drinking Jim Beam from the bottle and launching bottle rockets from the empties. [Jordan Hubbard]
--nWnLkFXL5K--