From: Zachary Amsden <zach@vmware.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.14: CR4 not needed to be inspected on the 486 anymore?
Date: Thu, 03 Nov 2005 15:49:17 -0800 [thread overview]
Message-ID: <436AA1FD.3010401@vmware.com> (raw)
In-Reply-To: <Pine.LNX.4.55.0511031639310.24109@blysk.ds.pg.gda.pl>
Maciej W. Rozycki wrote:
>On Thu, 3 Nov 2005, Zachary Amsden wrote:
>
>
>
>>>disables code to retrieve the actual value of CR4 on 486-class systems
>>>(which may or may not implement the register, depending on the exact CPU
>>>type and stepping). This seems suspicious to me, but I have to admit I
>>>haven't followed the discussion on the issue if there was any.
>>>
>>>
>>>
>>>
>>This was deliberate. CR4 doesn't exist on standard 486 class systems,
>>and I'm not sure how you could make use of it anyway, since the features
>>used by Linux - machine check, page size extensions, time stamp counter,
>>global pages, are only available in Pentium and later class systems, and
>>identified by CPUID, which also doesn't exist on 486.
>>
>>
>
> Later Intel i486DX2 and i486DX4 processors (the so called "write-back
>enhanced" ones) did support page size extensions (4MB pages) and as far as
>I know we do use them on such chips. They did implement the CPUID
>instruction, too (as well as late i486SX and i486SX2 chips that did not
>support PSE). That's a counter-example that proves the actual value of
>CR4 is going to be useful on these systems. These chips also implemented
>the VME feature (the PVI and VME bits of CR4), but they may not be
>terribly useful for us.
>
> I used quite a few of such chips myself in mid 90s -- you may search
>archives of various mailing lists for examples of "cpuinfo" dumps for such
>processors.
>
Finally got the relevant information from Intel. The embedded i486DX-2/4
series does support CPUID, and PSE, and thus CR4. Ugh. Also just found
this guy:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 4
model : 7
model name : 486 DX/2-WB
stepping : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme pse
bogomips : 32.25
He won't like me too much. I'll write up a proper patch for this, a la
mode de rdmsr_safe / wrmsr_safe. At least it's not a bug, just missing
information.
Zach
next prev parent reply other threads:[~2005-11-03 23:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-03 16:12 2.6.14: CR4 not needed to be inspected on the 486 anymore? Maciej W. Rozycki
2005-11-03 16:34 ` Zachary Amsden
2005-11-03 17:20 ` Maciej W. Rozycki
2005-11-03 23:49 ` Zachary Amsden [this message]
2005-11-05 17:40 ` Andi Kleen
2005-11-07 9:38 ` Maciej W. Rozycki
2005-11-07 15:44 ` Zachary Amsden
2005-11-07 16:37 ` Maciej W. Rozycki
2005-11-07 16:51 ` Zachary Amsden
2005-11-07 17:00 ` linux-os (Dick Johnson)
2005-11-07 17:32 ` Zachary Amsden
2005-11-07 18:17 ` linux-os (Dick Johnson)
2005-11-07 19:02 ` Ondrej Zary
2005-11-07 17:11 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=436AA1FD.3010401@vmware.com \
--to=zach@vmware.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.