I'm looking for /proc/cpuinfo output from following architectures: arm m68k
mips s390 sparc.
I need it but I don't have access to any of them :/
TIA
Witek Krecicki
On Sat, Jul 06, 2002 at 11:16:49AM +0200, Witek Kr?cicki wrote:
> I'm looking for /proc/cpuinfo output from following architectures: arm m68k
> mips s390 sparc.
> I need it but I don't have access to any of them :/
# cat /proc/cpuinfo
CPU: 68060
MMU: 68060
FPU: 68060
Clocking: 65.7MHz
BogoMips: 131.48
Calibration: 657408 loops
Variations: CPU:68020,68030,68040,68060
MMU:68851,Sun-3,Apollo (CPU 020 only),68040,68060
FPU:68881,68882 (CPU 020 and 030 only)
"none(soft float)",68040,68060
Not sure if you needed Sparc64, so here it is if you want it..
> cat /proc/cpuinfo
cpu : TI UltraSparc IIi
fpu : UltraSparc IIi integrated FPU
promlib : Version 3 Revision 19
prom : 3.19.4
type : sun4u
ncpus probed : 1
ncpus active : 1
Cpu0Bogo : 719.25
Cpu0ClkTck : 0000000015752a00
MMU Type : Spitfire
B.
> -----Original Message-----
> From: Witek Krecicki [mailto:[email protected]]
> Sent: Saturday, July 06, 2002 5:17 AM
> To: [email protected]
> Subject: [OT] /proc/cpuinfo output from some arch
>
>
> I'm looking for /proc/cpuinfo output from following
> architectures: arm m68k
> mips s390 sparc.
> I need it but I don't have access to any of them :/
> TIA
> Witek Krecicki
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
* Witek Kr?cicki ([email protected]) wrote:
> I'm looking for /proc/cpuinfo output from following architectures: arm m68k
> mips s390 sparc.
Well here are mips and m68k; I don't have an ARM box bootable at the
moment:
This is from my SG Indy (Dino):
>>>>>>>>>>>>>>>>>>>>>>
cpu : MIPS
cpu model : R4600 V2.0
system type : SGI Indy
BogoMIPS : 132.71
byteorder : big endian
unaligned accesses : 0
wait instruction : yes
microsecond timers : yes
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
>>>>>>>>>>>>>>>>>>>>>>
And the following shows the stunning computing power of my Sun 3/60:
>>>>>>>>>>>>>>>>>>>>>>
CPU: 68020
MMU: Sun-3
FPU: 68881
Clocking: 19.3MHz
BogoMips: 4.83
Calibration: 24192 loops
>>>>>>>>>>>>>>>>>>>>>>
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
Witek Kr?cicki <[email protected]> writes:
|> I'm looking for /proc/cpuinfo output from following architectures: arm m68k
|> mips s390 sparc.
This is arm:
Processor : Intel StrongARM-110 rev 4 (v4l)
BogoMIPS : 185.95
Features : swp half 26bit fastmult
Hardware : Rebel-NetWinder
Revision : 58ff
Serial : 0000000000001910
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sat, Jul 06, 2002 at 07:46:47PM +0200, Andreas Schwab wrote:
> Processor : Intel StrongARM-110 rev 4 (v4l)
Note that this could also be something like:
Processor : ARM/VLSI Arm1020id(wb)BRR rev 1 (v4)
or:
Processor : ARM ARM926EJ-Sid(wb)RR rev 2 (v5)
It might change further if the manufacturer decides to have a space
in their name. Basically, /proc/cpuinfo was never meant to be passed
by programs, and its not something I'd like to support with the current
format.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Hi,
On Sat, 6 Jul 2002, Russell King wrote:
> Processor : Intel StrongARM-110 rev 4 (v4l)
>
> Note that this could also be something like:
>
> Processor : ARM/VLSI Arm1020id(wb)BRR rev 1 (v4)
>
> or:
>
> Processor : ARM ARM926EJ-Sid(wb)RR rev 2 (v5)
I wonder if it's possible w/all those different formats. It's looking
completely different on alpha, arm, i386, sparc and s/390x...
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
Followup to: <[email protected]>
By author: Russell King <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Sat, Jul 06, 2002 at 07:46:47PM +0200, Andreas Schwab wrote:
> > Processor : Intel StrongARM-110 rev 4 (v4l)
>
> Note that this could also be something like:
>
> Processor : ARM/VLSI Arm1020id(wb)BRR rev 1 (v4)
>
> or:
>
> Processor : ARM ARM926EJ-Sid(wb)RR rev 2 (v5)
>
> It might change further if the manufacturer decides to have a space
> in their name. Basically, /proc/cpuinfo was never meant to be passed
> by programs, and its not something I'd like to support with the current
> format.
>
/proc/cpuinfo was *definitely* meant to be parsed by programs.
Unfortunately, lots of architectures seems to have completely missed
that fact.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Sat, Jul 06, 2002 at 03:16:07PM -0700, H. Peter Anvin wrote:
> /proc/cpuinfo was *definitely* meant to be parsed by programs.
> Unfortunately, lots of architectures seems to have completely missed
> that fact.
Sigh, its a shame such things aren't documented somewhere in the
kernel tarball.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King wrote:
> On Sat, Jul 06, 2002 at 03:16:07PM -0700, H. Peter Anvin wrote:
>
>>/proc/cpuinfo was *definitely* meant to be parsed by programs.
>>Unfortunately, lots of architectures seems to have completely missed
>>that fact.
>
> Sigh, its a shame such things aren't documented somewhere in the
> kernel tarball.
>
No kidding...
-hpa
Russell King writes:
> On Sat, Jul 06, 2002 at 03:16:07PM -0700, H. Peter Anvin wrote:
>> /proc/cpuinfo was *definitely* meant to be parsed by programs.
>> Unfortunately, lots of architectures seems to have completely missed
>> that fact.
>
> Sigh, its a shame such things aren't documented somewhere in the
> kernel tarball.
Ah, but you're supposed to remember the history!
The colons were added to make parsing easier.
I think that was done after somebody added spaces
on the left, and lots of app developers screamed
that the format had become hopeless.
Right now I'm looking to get the temperature,
clock speed, and voltage. I get the first two
on PowerPC hardware, but it's not obvious what
mess an SMP system would spit out.
On Saturday 06 July 2002 20:30, Albert D. Cahalan wrote:
>
> Right now I'm looking to get the temperature,
> clock speed, and voltage. I get the first two
> on PowerPC hardware, but it's not obvious what
> mess an SMP system would spit out.
>
Alpha Quad:
cpu : Alpha
cpu model : EV56
cpu variation : 7
cpu revision : 0
cpu serial number :
system type : Rawhide
system variation : Dodge
system revision : 0
system serial number : BT00000000
cycle frequency [Hz] : 400000000
timer frequency [Hz] : 1200.00
page size [bytes] : 8192
phys. address bits : 40
max. addr. space # : 127
BogoMIPS : 747.36
kernel unaligned acc : 0 (pc=0,va=0)
user unaligned acc : 416 (pc=12008d8d0,va=4463)
platform string : AlphaServer 7310 5/400 4MB
cpus detected : 4
cpus active : 4
cpu active mask : 000000000000000f
Intel Quad:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 10
model name : Pentium III (Cascades)
stepping : 1
cpu MHz : 701.636
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat \pse36 mmx fxsr sse
bogomips : 1399.19
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 10
model name : Pentium III (Cascades)
stepping : 1
cpu MHz : 701.636
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat \pse36 mmx fxsr sse
bogomips : 1402.47
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 10
model name : Pentium III (Cascades)
stepping : 1
cpu MHz : 701.636
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat \pse36 mmx fxsr sse
bogomips : 1402.47
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 10
model name : Pentium III (Cascades)
stepping : 1
cpu MHz : 701.636
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat \pse36 mmx fxsr sse
bogomips : 1402.47
Enjoy,
--George
Hi!
> >> /proc/cpuinfo was *definitely* meant to be parsed by programs.
> >> Unfortunately, lots of architectures seems to have completely missed
> >> that fact.
> >
> > Sigh, its a shame such things aren't documented somewhere in the
> > kernel tarball.
>
> Ah, but you're supposed to remember the history!
> The colons were added to make parsing easier.
> I think that was done after somebody added spaces
> on the left, and lots of app developers screamed
> that the format had become hopeless.
>
> Right now I'm looking to get the temperature,
> clock speed, and voltage. I get the first two
> on PowerPC hardware, but it's not obvious what
> mess an SMP system would spit out.
I thought that cpuinfo was ment to be non-chaning after boot?
Perhaps we want /proc/cpu/0/temperature containing single int?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
Pavel Machek wrote:
>
> I thought that cpuinfo was ment to be non-chaning after boot?
>
> Perhaps we want /proc/cpu/0/temperature containing single int?
>
/proc/cpu/<number>/<datapoint> would be a lot better for a whole bunch
of things.
-hpa
On Wed, Jul 10, 2002 at 03:14:49PM -0700, H. Peter Anvin wrote:
> Pavel Machek wrote:
> >
> > I thought that cpuinfo was ment to be non-chaning after boot?
> >
> > Perhaps we want /proc/cpu/0/temperature containing single int?
> >
>
> /proc/cpu/<number>/<datapoint> would be a lot better for a whole bunch
> of things.
What about /proc/sys/cpu/<number>/<datapoint> ?
We decided on the above path for cpufreq after mulling it over for several
weeks... it might be a good idea if we can all agree to put stuff in one
place, rather than spreading it out across /crap^w/proc
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
> What about /proc/sys/cpu/<number>/<datapoint> ?
What happens if the cpus are hot plugged and change ID while doing the
config 8)
On Thu, Jul 11, 2002 at 12:47:18AM +0100, Alan Cox wrote:
> > What about /proc/sys/cpu/<number>/<datapoint> ?
>
> What happens if the cpus are hot plugged and change ID while doing the
> config 8)
As far as SMP systems and cpufreq is concerned, we're going to have
a /proc/sys/cpu/all/ as well - you can't control the clock rate of
each cpu independently on such systems (otherwise they wouldn't be
very symetric.)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Hi,
On Thu, 11 Jul 2002, Russell King wrote:
> As far as SMP systems and cpufreq is concerned, we're going to have
> a /proc/sys/cpu/all/ as well - you can't control the clock rate of
> each cpu independently on such systems (otherwise they wouldn't be
> very symetric.)
Yes, asymmetric multiprocessing is a much more diffcult field, but
it's not currently an issue to us. (Well, we had this issue long ago, but
the SMP approach won, because even though it's uncool, it's still easier
to handle. Maybe AMP will return one day...)
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On Thu, Jul 11, 2002 at 12:47:18AM +0100, Alan Cox wrote:
> > What about /proc/sys/cpu/<number>/<datapoint> ?
>
> What happens if the cpus are hot plugged and change ID while doing the
> config 8)
<driverfs_mount>/root/cpu/<number>/<datapoint>
That can handle dynamic data just fine :)
greg k-h
> Yes, asymmetric multiprocessing is a much more diffcult field, but
> it's not currently an issue to us. (Well, we had this issue long ago, but
> the SMP approach won, because even though it's uncool, it's still easier
> to handle. Maybe AMP will return one day...)
Per CPU clock ratios are supported in several places. There is also a whole
research field into SMP power management that goes with it