Hi
Here is the unknown CPU mensioned earlier.
It is a SiS55x CPU from Silicon Integrated Systems Corp.
This is a Pentium 5 like CPU primary target embedded devices. It is a
System-On-Chip with several i/o devices like AC97, USB, IDE and net on
board. The same core is used in SiS550, SiS551 and SiS552 as the
difference is only which periferial devices which is added. Then the
CPU can not detect the model but the kernel should be able to detect
the other devices connected internally to SiS551 and SiS552. So, the
model_id would be '0' and then the text 'SiS55x' as model_name.
Detected CPU flags in /proc/cpuinfo and in the datasheet:
flags : fpu tsc cx8 mmx
Instruction and data cache is 8KB each it says in the datasheet. I'm
not sure but it does not look like it is written in dmesg.
ACPI sleep supports S1 S2 S3 S4 S5.
CPU power states supports C0 C1 C2 C3.
See attachment. (I hope it gets here!)
Signed-off-by: Hans Schou <[email protected]>
Hans Schou <[email protected]> writes:
> flags : fpu tsc cx8 mmx
>
> Instruction and data cache is 8KB each it says in the datasheet. I'm
> not sure but it does not look like it is written in dmesg.
>
> ACPI sleep supports S1 S2 S3 S4 S5.
>
> CPU power states supports C0 C1 C2 C3.
>
> See attachment. (I hope it gets here!)
Your attachment seems to be windows line end damaged.
Also the changes are so small that it's not worth adding a CONFIG
for it. Just add it unconditionally.
And hardcoding the cache size for all of SiS seems a bit extreme.
What happens when SiS ever brings out another part with different caches?
Ideally figure out some way to detect this particular CPU and only
use 8 KB only for that. Alternatively ignore it (there's nothing
really in the kernel that uses the cache sizes anyways)
-Andi
On Mon, 13 Oct 2008, Andi Kleen wrote:
> Hans Schou <[email protected]> writes:
>
>
>> flags : fpu tsc cx8 mmx
>>
>> Instruction and data cache is 8KB each it says in the datasheet. I'm
>> not sure but it does not look like it is written in dmesg.
>>
>> ACPI sleep supports S1 S2 S3 S4 S5.
>>
>> CPU power states supports C0 C1 C2 C3.
>>
>> See attachment. (I hope it gets here!)
>
> Your attachment seems to be windows line end damaged.
Strange, Pine usually do it right with file attachments.
(what is "windows line end damaged"?)
> Also the changes are so small that it's not worth adding a CONFIG
> for it. Just add it unconditionally.
I was not trying to invent anything. It is almost a copy of the UMC
CPU, except that it is 586 code.
> And hardcoding the cache size for all of SiS seems a bit extreme.
> What happens when SiS ever brings out another part with different
> caches? Ideally figure out some way to detect this particular CPU
> and only use 8 KB only for that. Alternatively ignore it (there's
> nothing really in the kernel that uses the cache sizes anyways)
In that case the cache could be deleted.
One annoying thing is that the "model name" in /proc/cpuinfo is
written as "00/55" instead of "SiS55x" when the CPU is not detected.
The worst problem is that an unknown CPU writes:
printk(KERN_ERR "CPU: Your system may be unstable.\n");
and the SiS55x is not unstable. Not until now at least and it has been
on the market for 5 years.
Maybe the message could be changed to something less catastrophic when
CPU is unknown.
So, many solutions could be be better than the one there is now.
And if the new solution will be usefull for other unknown CPU's it
will be even better.
/hans
> >Your attachment seems to be windows line end damaged.
>
> Strange, Pine usually do it right with file attachments.
It likely was added on some Windows system.
> (what is "windows line end damaged"?)
It used MSDOS style \r\n line terminators instead of Unix style \n.
>
> >Also the changes are so small that it's not worth adding a CONFIG
> >for it. Just add it unconditionally.
>
> I was not trying to invent anything. It is almost a copy of the UMC
> CPU, except that it is 586 code.
Then the comment applies to that one too.
>
> >And hardcoding the cache size for all of SiS seems a bit extreme.
> >What happens when SiS ever brings out another part with different
> >caches? Ideally figure out some way to detect this particular CPU
> >and only use 8 KB only for that. Alternatively ignore it (there's
> >nothing really in the kernel that uses the cache sizes anyways)
>
> In that case the cache could be deleted.
>
> One annoying thing is that the "model name" in /proc/cpuinfo is
> written as "00/55" instead of "SiS55x" when the CPU is not detected.
Is that really so bad?
>
> The worst problem is that an unknown CPU writes:
> printk(KERN_ERR "CPU: Your system may be unstable.\n");
Perhaps it would be better to just remove that printk.
Its truth seems doubtful.
> and the SiS55x is not unstable. Not until now at least and it has been
> on the market for 5 years.
>
> Maybe the message could be changed to something less catastrophic when
> CPU is unknown.
Yes that would be a good idea.
-Andi
On Tue, 14 Oct 2008, Andi Kleen wrote:
>>> Your attachment seems to be windows line end damaged.
>>
>> Strange, Pine usually do it right with file attachments.
>
> It likely was added on some Windows system.
>> (what is "windows line end damaged"?)
>
> It used MSDOS style \r\n line terminators instead of Unix style \n.
Yes, I do know what a CR/LF (Carriage Return Line Feed) is but I
didn't send any. I really dont understand what you are talking about.
I looked at the mail returned from vger.kernel.org which was fine, and
this web-page is also OK.
http://www.gossamer-threads.com/lists/linux/kernel/983150
There is no CR here:
od -t x1 patch-sis55x | grep 0d
If any CR/LF in your file you must have added them yourself.
/hans
> If any CR/LF in your file you must have added them yourself.
There were definitely CR/LFs in the patch attachment you sent.
And no my mailer doesn't add them.
-Andi
--
[email protected]
On Wed, 15 Oct 2008, Andi Kleen wrote:
> > If any CR/LF in your file you must have added them yourself.
>
> There were definitely CR/LFs in the patch attachment you sent.
> And no my mailer doesn't add them.
Interesting. I didn't see any CR/LFs neither, after exporting the
attachment to a file (I'm using pine).
However, when doing a base64 decode on the raw attachment data, the
CR/LFs did pop up.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, 14 Oct 2008, Hans Schou wrote:
> If any CR/LF in your file you must have added them yourself.
Sorry, you are right. Pine do change attachment which is recognized as
ASCII text files. Pine thinks the right thing to do, based on the file
extension, is to convert a text file to CR/LF:
http://www.washington.edu/pine/faq/attachments.html#7.2.1
I could not find a way within Pine where I could attach a file in way
where everything is preserved as is, but regarding the actual case
with SiS55x I don't think there is a need for posting the patch
correctly anyway. The patch was not that popular after all.
rgds/hans
On Wed, 15 Oct 2008, Geert Uytterhoeven wrote:
> On Wed, 15 Oct 2008, Andi Kleen wrote:
>>> If any CR/LF in your file you must have added them yourself.
>>
>> There were definitely CR/LFs in the patch attachment you sent.
>> And no my mailer doesn't add them.
>
> Interesting. I didn't see any CR/LFs neither, after exporting the
> attachment to a file (I'm using pine).
As far as I could see, Pine does this:
1. If file has not extension like: .zip .jpg .exe, see it as ASCII
2. Add CR/LF to the file
3. Encode file as base64
On reception of the file:
1. Decode file as specified (in this case base64)
2. If it looks like a text file, convert CR/LF to LF.
> However, when doing a base64 decode on the raw attachment data, the
> CR/LFs did pop up.
I think time is up for getting rid of Pine and there stupid license.
I'll check if "nail" can handle attachment correctly.
/hans
On Thu, 16 Oct 2008, Hans Schou wrote:
> On Wed, 15 Oct 2008, Geert Uytterhoeven wrote:
> > On Wed, 15 Oct 2008, Andi Kleen wrote:
> > > > If any CR/LF in your file you must have added them yourself.
> > >
> > > There were definitely CR/LFs in the patch attachment you sent.
> > > And no my mailer doesn't add them.
> >
> > Interesting. I didn't see any CR/LFs neither, after exporting the
> > attachment to a file (I'm using pine).
>
> As far as I could see, Pine does this:
>
> 1. If file has not extension like: .zip .jpg .exe, see it as ASCII
> 2. Add CR/LF to the file
> 3. Encode file as base64
>
> On reception of the file:
>
> 1. Decode file as specified (in this case base64)
> 2. If it looks like a text file, convert CR/LF to LF.
>
> > However, when doing a base64 decode on the raw attachment data, the
> > CR/LFs did pop up.
>
> I think time is up for getting rid of Pine and there stupid license. I'll
> check if "nail" can handle attachment correctly.
alpine?
But, why do you send patches as attachments in the first place?
It's recommended to _not_ do that, for easier review.
Pine can handle that fine since ages (I switched from elm to pine 13 or
so years ago).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 15 Oct 2008, H. Peter Anvin wrote:
> Hans Schou wrote:
>>
>> Detected CPU flags in /proc/cpuinfo and in the datasheet:
>> flags : fpu tsc cx8 mmx
>>
>> Instruction and data cache is 8KB each it says in the datasheet. I'm not
>> sure but it does not look like it is written in dmesg.
>>
>
> Could you post /proc/cpuinfo from this machine?
Sure. Here it is with a kernel 2.6.25 - not the patch below:
processor : 0
vendor_id : SiS SiS SiS
cpu family : 5
model : 0
model name : 05/00
stepping : 5
cpu MHz : 200.008
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu tsc cx8 mmx
bogomips : 401.32
clflush size : 32
Please note that the vendor_id has a space in the end:
"SiS SiS SiS "
> P.S. Please send x86 patches to [email protected] as well as LKML.
OK. I had a problem with Pine doing linewrap. I try again.
diff -Naur a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
--- a/arch/x86/Kconfig.cpu 2008-10-11 23:03:47.000000000 +0200
+++ b/arch/x86/Kconfig.cpu 2008-10-12 00:30:08.000000000 +0200
@@ -242,6 +242,13 @@
Select this for a VIA C7. Selecting this uses the correct cache
shift and tells gcc to treat the CPU as a 686.
+config MSIS55X
+ bool "SiS55x"
+ depends on X86_32
+ help
+ Select this for a SiS550/551/552 SoC. Selecting this uses the
+ correct cache shift and tells gcc to treat the CPU as a 586.
+
config MPSC
bool "Intel P4 / older Netburst based Xeon"
depends on X86_64
@@ -309,7 +316,7 @@
int
default "7" if MPENTIUM4 || X86_GENERIC || GENERIC_CPU || MPSC
default "4" if X86_ELAN || M486 || M386 || MGEODEGX1
- default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX
+ default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX || MSIS55X
default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MVIAC7
config X86_XADD
@@ -351,7 +358,7 @@
config X86_ALIGNMENT_16
def_bool y
- depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || X86_ELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2 || MGEODEGX1
+ depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || X86_ELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2 || MGEODEGX1 || MSIS55X
config X86_INTEL_USERCOPY
def_bool y
@@ -387,7 +394,7 @@
config X86_TSC
def_bool y
- depends on ((MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ) || X86_64
+ depends on ((MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MSIS55X || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ) || X86_64
config X86_CMPXCHG64
def_bool y
@@ -464,6 +471,13 @@
help
This enables extended support for UMC processors
+config CPU_SUP_SIS_32
+ default y
+ bool "Support SiS processors" if PROCESSOR_SELECT
+ depends on !64BIT
+ help
+ This enables extended support for SiS processors
+
config X86_DS
bool "Debug Store support"
default y
diff -Naur a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
--- a/arch/x86/kernel/cpu/Makefile 2008-10-11 23:03:47.000000000 +0200
+++ b/arch/x86/kernel/cpu/Makefile 2008-10-03 23:56:53.000000000 +0200
@@ -15,6 +15,7 @@
obj-$(CONFIG_CPU_SUP_CENTAUR_64) += centaur_64.o
obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
+obj-$(CONFIG_CPU_SUP_SIS_32) += sis.o
obj-$(CONFIG_X86_MCE) += mcheck/
obj-$(CONFIG_MTRR) += mtrr/
diff -Naur a/arch/x86/kernel/cpu/sis.c b/arch/x86/kernel/cpu/sis.c
--- a/arch/x86/kernel/cpu/sis.c 1970-01-01 01:00:00.000000000 +0100
+++ b/arch/x86/kernel/cpu/sis.c 2008-10-11 11:04:23.000000000 +0200
@@ -0,0 +1,25 @@
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <asm/processor.h>
+#include "cpu.h"
+
+static unsigned int __cpuinit sis_size_cache(struct cpuinfo_x86 *c, unsigned int size)
+{
+ return 8;
+}
+
+static struct cpu_dev sis_cpu_dev __cpuinitdata = {
+ .c_vendor = "SiS",
+ .c_ident = { "SiS SiS SiS " },
+ .c_models = {
+ { .vendor = X86_VENDOR_SIS, .family = 5, .model_names =
+ {
+ [0] = "SiS55x",
+ }
+ },
+ },
+ .c_size_cache = sis_size_cache,
+ .c_x86_vendor = X86_VENDOR_SIS,
+};
+
+cpu_dev_register(sis_cpu_dev);
diff -Naur a/include/asm-x86/processor.h b/include/asm-x86/processor.h
--- a/include/asm-x86/processor.h 2008-10-11 23:03:47.000000000 +0200
+++ b/include/asm-x86/processor.h 2008-10-03 23:53:00.000000000 +0200
@@ -119,7 +119,8 @@
#define X86_VENDOR_CENTAUR 5
#define X86_VENDOR_TRANSMETA 7
#define X86_VENDOR_NSC 8
-#define X86_VENDOR_NUM 9
+#define X86_VENDOR_SIS 9
+#define X86_VENDOR_NUM 10
#define X86_VENDOR_UNKNOWN 0xff
On Thu, 16 Oct 2008, Geert Uytterhoeven wrote:
>> I think time is up for getting rid of Pine and there stupid license. I'll
>> check if "nail" can handle attachment correctly.
>
> alpine?
Well, Gentoo didn't have it and it is probably a "wrong" license.
> But, why do you send patches as attachments in the first place?
Ingo said I could do so when it was something to do with x86 patches.
Anyway, it looks like ^R in Pine did work correctly.
> It's recommended to _not_ do that, for easier review.
OK.
> Pine can handle that fine since ages (I switched from elm to pine 13 or
> so years ago).
Yes, my so called friends have been bullying me for that long with the Pine
license. Mutt is not an option either.
/hans
On Thu, 16 Oct 2008, Hans Schou wrote:
> > But, why do you send patches as attachments in the first place?
>
> Ingo said I could do so when it was something to do with x86 patches.
> Anyway, it looks like ^R in Pine did work correctly.
You've got:
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
in your headers -- it may be good for poetry, but will guarantee you
breakage with inline patches. There's an option to disable it.
Maciej
On Thu, 16 Oct 2008, Maciej W. Rozycki wrote:
> On Thu, 16 Oct 2008, Hans Schou wrote:
>
> > > But, why do you send patches as attachments in the first place?
> >
> > Ingo said I could do so when it was something to do with x86 patches.
> > Anyway, it looks like ^R in Pine did work correctly.
>
> You've got:
>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Thanks:
[X] quell-flowed-text
> in your headers -- it may be good for poetry, but will guarantee you
> breakage with inline patches. There's an option to disable it.
Maybe I should start on poetry instead of kernel-patching.
"Tired of bugs?
Then try Linux."
...I don't think I can do that for a living.
/hans