$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 47
model name : AMD Athlon(tm) 64 Processor 3200+
...
cache size : 512 KB
...
The cache size is currently misinformed. It's not the real size because
it's 64+64+512 KiB = 640 KiB, not 512 KB.
How can i know what hw-caches use the processors?
The current kernel doesn't know well what hw-caches uses.
The good proposal is by example (the data below are not real):
* In old AMD Athlon64:
cache L1 : 64 KiB I + 64 KiB D, 64 B line, direct way, ...
cache L2 : 512 KiB I+D-shared, exclusive, 128 associative way, ...
cache L3 : none
* In Intel Core Duo:
processor : 0
cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
cache L2 : 2048 KiB Cores-shared, inclusive, 128 associative way, ...
cache L3 : none
processor : 1
cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
cache L2 : 2048 KiB cores-shared, inclusive, 128 associative way, ...
cache L3 : none
* In Quad:
processor : 0
cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
associative way, ...
cache L3 : none
...
processor : 3
cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
associative way, ...
cache L3 : none
It above is an example, put your symbols to /proc/cpuinfo in a
convenient manner.
Good bye ;)
J.C. Pizarro wrote:
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 15
> model : 47
> model name : AMD Athlon(tm) 64 Processor 3200+
> ...
> cache size : 512 KB
> ...
>
> The cache size is currently misinformed. It's not the real size because
> it's 64+64+512 KiB = 640 KiB, not 512 KB.
>
> How can i know what hw-caches use the processors?
> The current kernel doesn't know well what hw-caches uses.
>
> The good proposal is by example (the data below are not real):
> * In old AMD Athlon64:
>
> cache L1 : 64 KiB I + 64 KiB D, 64 B line, direct way, ...
> cache L2 : 512 KiB I+D-shared, exclusive, 128 associative way, ...
> cache L3 : none
>
> * In Intel Core Duo:
> processor : 0
> cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> cache L2 : 2048 KiB Cores-shared, inclusive, 128 associative way, ...
> cache L3 : none
>
> processor : 1
> cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> cache L2 : 2048 KiB cores-shared, inclusive, 128 associative way, ...
> cache L3 : none
>
> * In Quad:
> processor : 0
> cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
> associative way, ...
> cache L3 : none
> ...
> processor : 3
> cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
> associative way, ...
> cache L3 : none
>
> It above is an example, put your symbols to /proc/cpuinfo in a
> convenient manner.
>
> Good bye ;)
I think you want this:
/sys/devices/system/cpu/cpu0/cache
/proc/cpuinfo is intended to give a general summary of certain properties of the
processor that tend to be particularly interesting, and present them all in one
place. It is not intended to expose everything the kernel knows about every
processor on the system.
-- Chris
On 2008/3/25, Chris Snook <[email protected]> wrote:
> J.C. Pizarro wrote:
> > $ cat /proc/cpuinfo
> > processor : 0
> > vendor_id : AuthenticAMD
> > cpu family : 15
> > model : 47
> > model name : AMD Athlon(tm) 64 Processor 3200+
> > ...
> > cache size : 512 KB
> > ...
> >
> > The cache size is currently misinformed. It's not the real size because
> > it's 64+64+512 KiB = 640 KiB, not 512 KB.
> >
> > How can i know what hw-caches use the processors?
> > The current kernel doesn't know well what hw-caches uses.
> >
> > The good proposal is by example (the data below are not real):
> > * In old AMD Athlon64:
> >
> > cache L1 : 64 KiB I + 64 KiB D, 64 B line, direct way, ...
> > cache L2 : 512 KiB I+D-shared, exclusive, 128 associative way, ...
> > cache L3 : none
> >
> > * In Intel Core Duo:
> > processor : 0
> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> > cache L2 : 2048 KiB Cores-shared, inclusive, 128 associative way, ...
> > cache L3 : none
> >
> > processor : 1
> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> > cache L2 : 2048 KiB cores-shared, inclusive, 128 associative way, ...
> > cache L3 : none
> >
> > * In Quad:
> > processor : 0
> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
> > associative way, ...
> > cache L3 : none
> > ...
> > processor : 3
> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
> > associative way, ...
> > cache L3 : none
> >
> > It above is an example, put your symbols to /proc/cpuinfo in a
> > convenient manner.
> >
> > Good bye ;)
>
>
> I think you want this:
>
> /sys/devices/system/cpu/cpu0/cache
Thanks, but there is not easier manner to print the properties of hw-caches
unless printing recursively this tree /sys/devices/system/cpu/cpu[0-9]+/cache/
that they are only numbers without symbolic fields.
There is not manner to know the speed (in MHz) of the L1, L2 and L3 caches.
> /proc/cpuinfo is intended to give a general summary of certain properties of the
> processor that tend to be particularly interesting, and present them all in one
> place. It is not intended to expose everything the kernel knows about every
> processor on the system.
/proc/cpuinfo doesn't give a general summary because it gives superfluous info.
I think that it's better to refactorize /proc/cpuinfo still more.
(
... fields common to all present processors known by the kernel ....
[ to warn if the values are differents between cores ]
)
(
... specific fields for each processor ... by example:
processor : 0
cpu MHz : 2000.000 # normal clocked
bogomips : 4010.63
processor : 1
cpu MHz : 500.000 # underclocked for energy saving ...
bogomips : 1003.20
)
I think that all the cores are equals in almost non-weird systems.
With this scheme, the cpuinfo's reports will be smaller than before,
and non-superfluous.
> -- Chris
J.C. Pizarro wrote:
> On 2008/3/25, Chris Snook <[email protected]> wrote:
>> J.C. Pizarro wrote:
>> > $ cat /proc/cpuinfo
>> > processor : 0
>> > vendor_id : AuthenticAMD
>> > cpu family : 15
>> > model : 47
>> > model name : AMD Athlon(tm) 64 Processor 3200+
>> > ...
>> > cache size : 512 KB
>> > ...
>> >
>> > The cache size is currently misinformed. It's not the real size because
>> > it's 64+64+512 KiB = 640 KiB, not 512 KB.
>> >
>> > How can i know what hw-caches use the processors?
>> > The current kernel doesn't know well what hw-caches uses.
>> >
>> > The good proposal is by example (the data below are not real):
>> > * In old AMD Athlon64:
>> >
>> > cache L1 : 64 KiB I + 64 KiB D, 64 B line, direct way, ...
>> > cache L2 : 512 KiB I+D-shared, exclusive, 128 associative way, ...
>> > cache L3 : none
>> >
>> > * In Intel Core Duo:
>> > processor : 0
>> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
>> > cache L2 : 2048 KiB Cores-shared, inclusive, 128 associative way, ...
>> > cache L3 : none
>> >
>> > processor : 1
>> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
>> > cache L2 : 2048 KiB cores-shared, inclusive, 128 associative way, ...
>> > cache L3 : none
>> >
>> > * In Quad:
>> > processor : 0
>> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
>> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
>> > associative way, ...
>> > cache L3 : none
>> > ...
>> > processor : 3
>> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
>> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
>> > associative way, ...
>> > cache L3 : none
>> >
>> > It above is an example, put your symbols to /proc/cpuinfo in a
>> > convenient manner.
>> >
>> > Good bye ;)
>>
>>
>> I think you want this:
>>
>> /sys/devices/system/cpu/cpu0/cache
>
> Thanks, but there is not easier manner to print the properties of hw-caches
> unless printing recursively this tree /sys/devices/system/cpu/cpu[0-9]+/cache/
> that they are only numbers without symbolic fields.
Then use dmidecode. It's all in one place, and everyone expects it to be far
too long to read at a glance.
> There is not manner to know the speed (in MHz) of the L1, L2 and L3 caches.
>
>> /proc/cpuinfo is intended to give a general summary of certain properties of the
>> processor that tend to be particularly interesting, and present them all in one
>> place. It is not intended to expose everything the kernel knows about every
>> processor on the system.
>
> /proc/cpuinfo doesn't give a general summary because it gives superfluous info.
>
> I think that it's better to refactorize /proc/cpuinfo still more.
>
> (
> ... fields common to all present processors known by the kernel ....
> [ to warn if the values are differents between cores ]
> )
> (
> ... specific fields for each processor ... by example:
>
> processor : 0
> cpu MHz : 2000.000 # normal clocked
> bogomips : 4010.63
> processor : 1
> cpu MHz : 500.000 # underclocked for energy saving ...
> bogomips : 1003.20
>
> )
>
> I think that all the cores are equals in almost non-weird systems.
> With this scheme, the cpuinfo's reports will be smaller than before,
> and non-superfluous.
It's precisely that sort of weirdness we want to be able to catch at a glance.
These days, there is no possible way to make /proc/cpuinfo satisfy everyone and
still be compact. That's why we mostly leave it alone and put all the fun stuff
in /sys, which is much better suited to the ever-increasing complexity of modern
hardware.
If we refactor /proc/cpuinfo, it will break all sorts of things that use that
information to get an idea of what the system is running on. All of the info is
there in /sys now anyway, so if you want a different format, write your own
userspace tool to scrape it together. There's absolutely no need to implement
this purely cosmetic data formatting in the kernel.
-- Chris
On 2008/3/25, Chris Snook <[email protected]> wrote:
> J.C. Pizarro wrote:
> > On 2008/3/25, Chris Snook <[email protected]> wrote:
> >> J.C. Pizarro wrote:
> >> > $ cat /proc/cpuinfo
> >> > processor : 0
> >> > vendor_id : AuthenticAMD
> >> > cpu family : 15
> >> > model : 47
> >> > model name : AMD Athlon(tm) 64 Processor 3200+
> >> > ...
> >> > cache size : 512 KB
> >> > ...
> >> >
> >> > The cache size is currently misinformed. It's not the real size because
> >> > it's 64+64+512 KiB = 640 KiB, not 512 KB.
> >> >
> >> > How can i know what hw-caches use the processors?
> >> > The current kernel doesn't know well what hw-caches uses.
> >> >
> >> > The good proposal is by example (the data below are not real):
> >> > * In old AMD Athlon64:
> >> >
> >> > cache L1 : 64 KiB I + 64 KiB D, 64 B line, direct way, ...
> >> > cache L2 : 512 KiB I+D-shared, exclusive, 128 associative way, ...
> >> > cache L3 : none
> >> >
> >> > * In Intel Core Duo:
> >> > processor : 0
> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> >> > cache L2 : 2048 KiB Cores-shared, inclusive, 128 associative way, ...
> >> > cache L3 : none
> >> >
> >> > processor : 1
> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> >> > cache L2 : 2048 KiB cores-shared, inclusive, 128 associative way, ...
> >> > cache L3 : none
> >> >
> >> > * In Quad:
> >> > processor : 0
> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> >> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
> >> > associative way, ...
> >> > cache L3 : none
> >> > ...
> >> > processor : 3
> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> >> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
> >> > associative way, ...
> >> > cache L3 : none
> >> >
> >> > It above is an example, put your symbols to /proc/cpuinfo in a
> >> > convenient manner.
> >> >
> >> > Good bye ;)
> >>
> >>
> >> I think you want this:
> >>
> >> /sys/devices/system/cpu/cpu0/cache
> >
> > Thanks, but there is not easier manner to print the properties of hw-caches
> > unless printing recursively this tree /sys/devices/system/cpu/cpu[0-9]+/cache/
> > that they are only numbers without symbolic fields.
>
>
> Then use dmidecode. It's all in one place, and everyone expects it to be far
> too long to read at a glance.
>
>
> > There is not manner to know the speed (in MHz) of the L1, L2 and L3 caches.
> >
> >> /proc/cpuinfo is intended to give a general summary of certain properties of the
> >> processor that tend to be particularly interesting, and present them all in one
> >> place. It is not intended to expose everything the kernel knows about every
> >> processor on the system.
> >
> > /proc/cpuinfo doesn't give a general summary because it gives superfluous info.
> >
> > I think that it's better to refactorize /proc/cpuinfo still more.
> >
> > (
> > ... fields common to all present processors known by the kernel ....
> > [ to warn if the values are differents between cores ]
> > )
> > (
> > ... specific fields for each processor ... by example:
> >
> > processor : 0
> > cpu MHz : 2000.000 # normal clocked
> > bogomips : 4010.63
> > processor : 1
> > cpu MHz : 500.000 # underclocked for energy saving ...
> > bogomips : 1003.20
> >
> > )
> >
> > I think that all the cores are equals in almost non-weird systems.
> > With this scheme, the cpuinfo's reports will be smaller than before,
> > and non-superfluous.
>
>
> It's precisely that sort of weirdness we want to be able to catch at a glance.
> These days, there is no possible way to make /proc/cpuinfo satisfy everyone and
> still be compact. That's why we mostly leave it alone and put all the fun stuff
> in /sys, which is much better suited to the ever-increasing complexity of modern
> hardware.
>
> If we refactor /proc/cpuinfo, it will break all sorts of things that use that
> information to get an idea of what the system is running on. All of the info is
> there in /sys now anyway, so if you want a different format, write your own
> userspace tool to scrape it together. There's absolutely no need to implement
> this purely cosmetic data formatting in the kernel.
>
>
> -- Chris
Well, i understand as if this cosmetic data formatting can break the grep of
some applications.
But if the modern PC has 6 or 8 cores then it prints an equivalent to
x6 or x8 common pages in a small xterm console of 80x25 although
the panoramic TFT is bigger as 23' 1900x1200 pixels.
Tomorrow, 32 cores, it prints x32 instead of x8.
Soon, it will need cosmetic data formatting.
Hahahaha ;)
J.C. Pizarro wrote:
> On 2008/3/25, Chris Snook <[email protected]> wrote:
>> J.C. Pizarro wrote:
>> > On 2008/3/25, Chris Snook <[email protected]> wrote:
>> >> J.C. Pizarro wrote:
>> >> > $ cat /proc/cpuinfo
>> >> > processor : 0
>> >> > vendor_id : AuthenticAMD
>> >> > cpu family : 15
>> >> > model : 47
>> >> > model name : AMD Athlon(tm) 64 Processor 3200+
>> >> > ...
>> >> > cache size : 512 KB
>> >> > ...
>> >> >
>> >> > The cache size is currently misinformed. It's not the real size because
>> >> > it's 64+64+512 KiB = 640 KiB, not 512 KB.
>> >> >
>> >> > How can i know what hw-caches use the processors?
>> >> > The current kernel doesn't know well what hw-caches uses.
>> >> >
>> >> > The good proposal is by example (the data below are not real):
>> >> > * In old AMD Athlon64:
>> >> >
>> >> > cache L1 : 64 KiB I + 64 KiB D, 64 B line, direct way, ...
>> >> > cache L2 : 512 KiB I+D-shared, exclusive, 128 associative way, ...
>> >> > cache L3 : none
>> >> >
>> >> > * In Intel Core Duo:
>> >> > processor : 0
>> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
>> >> > cache L2 : 2048 KiB Cores-shared, inclusive, 128 associative way, ...
>> >> > cache L3 : none
>> >> >
>> >> > processor : 1
>> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
>> >> > cache L2 : 2048 KiB cores-shared, inclusive, 128 associative way, ...
>> >> > cache L3 : none
>> >> >
>> >> > * In Quad:
>> >> > processor : 0
>> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
>> >> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
>> >> > associative way, ...
>> >> > cache L3 : none
>> >> > ...
>> >> > processor : 3
>> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
>> >> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
>> >> > associative way, ...
>> >> > cache L3 : none
>> >> >
>> >> > It above is an example, put your symbols to /proc/cpuinfo in a
>> >> > convenient manner.
>> >> >
>> >> > Good bye ;)
>> >>
>> >>
>> >> I think you want this:
>> >>
>> >> /sys/devices/system/cpu/cpu0/cache
>> >
>> > Thanks, but there is not easier manner to print the properties of hw-caches
>> > unless printing recursively this tree /sys/devices/system/cpu/cpu[0-9]+/cache/
>> > that they are only numbers without symbolic fields.
>>
>>
>> Then use dmidecode. It's all in one place, and everyone expects it to be far
>> too long to read at a glance.
>>
>>
>> > There is not manner to know the speed (in MHz) of the L1, L2 and L3 caches.
>> >
>> >> /proc/cpuinfo is intended to give a general summary of certain properties of the
>> >> processor that tend to be particularly interesting, and present them all in one
>> >> place. It is not intended to expose everything the kernel knows about every
>> >> processor on the system.
>> >
>> > /proc/cpuinfo doesn't give a general summary because it gives superfluous info.
>> >
>> > I think that it's better to refactorize /proc/cpuinfo still more.
>> >
>> > (
>> > ... fields common to all present processors known by the kernel ....
>> > [ to warn if the values are differents between cores ]
>> > )
>> > (
>> > ... specific fields for each processor ... by example:
>> >
>> > processor : 0
>> > cpu MHz : 2000.000 # normal clocked
>> > bogomips : 4010.63
>> > processor : 1
>> > cpu MHz : 500.000 # underclocked for energy saving ...
>> > bogomips : 1003.20
>> >
>> > )
>> >
>> > I think that all the cores are equals in almost non-weird systems.
>> > With this scheme, the cpuinfo's reports will be smaller than before,
>> > and non-superfluous.
>>
>>
>> It's precisely that sort of weirdness we want to be able to catch at a glance.
>> These days, there is no possible way to make /proc/cpuinfo satisfy everyone and
>> still be compact. That's why we mostly leave it alone and put all the fun stuff
>> in /sys, which is much better suited to the ever-increasing complexity of modern
>> hardware.
>>
>> If we refactor /proc/cpuinfo, it will break all sorts of things that use that
>> information to get an idea of what the system is running on. All of the info is
>> there in /sys now anyway, so if you want a different format, write your own
>> userspace tool to scrape it together. There's absolutely no need to implement
>> this purely cosmetic data formatting in the kernel.
>>
>>
>> -- Chris
>
> Well, i understand as if this cosmetic data formatting can break the grep of
> some applications.
>
> But if the modern PC has 6 or 8 cores then it prints an equivalent to
> x6 or x8 common pages in a small xterm console of 80x25 although
> the panoramic TFT is bigger as 23' 1900x1200 pixels.
>
> Tomorrow, 32 cores, it prints x32 instead of x8.
> Soon, it will need cosmetic data formatting.
>
> Hahahaha ;)
All the more reason to use an interface that allows you to pick and choose the
data you want, like /sys.
-- Chris
On Tue, Mar 25, 2008 at 10:39:39PM +0100, J.C. Pizarro wrote:
> How can i know what hw-caches use the processors?
> The current kernel doesn't know well what hw-caches uses.
>
> The good proposal is by example (the data below are not real):
> * In old AMD Athlon64:
>
> cache L1 : 64 KiB I + 64 KiB D, 64 B line, direct way, ...
> cache L2 : 512 KiB I+D-shared, exclusive, 128 associative way, ...
> cache L3 : none
>
> * In Intel Core Duo:
> processor : 0
> cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> cache L2 : 2048 KiB Cores-shared, inclusive, 128 associative way, ...
> cache L3 : none
>
> processor : 1
> cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> cache L2 : 2048 KiB cores-shared, inclusive, 128 associative way, ...
> cache L3 : none
>
> * In Quad:
> processor : 0
> cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
> associative way, ...
> cache L3 : none
> ...
> processor : 3
> cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ...
> cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128
> associative way, ...
> cache L3 : none
See x86info. http://www.codemonkey.org.uk/projects/x86info/
Dave
--
http://www.codemonkey.org.uk
Chris Snook wrote:
>
> /sys/devices/system/cpu/cpu0/cache
>
I do not have it:
{pts/1}% uname -a
Linux cooker 2.6.25-rc6-1avb #11 Fri Mar 21 20:47:27 MSK 2008 i686 Pentium
III (Coppermine) GNU/Linux
{pts/1}% l /sys/devices/system/cpu/cpu0
cpuidle/
{pts/1}% cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 10
cpu MHz : 747.749
cache size : 256 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 sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips : 1499.05
clflush size : 32
What am I missing?
On Tue, 25 Mar 2008, Chris Snook wrote:
> I think you want this:
>
> /sys/devices/system/cpu/cpu0/cache
>
> /proc/cpuinfo is intended to give a general summary of certain properties of
> the processor that tend to be particularly interesting, and present them all
> in one place. It is not intended to expose everything the kernel knows about
> every processor on the system.
Oh my god! My caches run at different temperatures!! ;-)
| anakin$ cat /sys/devices/system/cpu/cpu0/cache/index*/size
| 64K
| 64K
| 512K
Furthermore /proc/cpuinfo misses _more_ than 128 KiB:
| anakin$ cat /proc/cpuinfo
[...]
| cache size : 512 KB
^^^^^^
[...]
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619