Commit-ID: c0366f5f5c1615c4f70b1bd646149ba9233830b9
Gitweb: http://git.kernel.org/tip/c0366f5f5c1615c4f70b1bd646149ba9233830b9
Author: H. Peter Anvin <[email protected]>
AuthorDate: Tue, 3 Aug 2010 10:09:56 -0700
Committer: H. Peter Anvin <[email protected]>
CommitDate: Tue, 3 Aug 2010 10:09:56 -0700
x86, cpu: RDC doesn't have CPUID, which is what c_ident is
c_ident is supposed to be a CPUID identifier, and RDC doesn't have
that.
Signed-off-by: H. Peter Anvin <[email protected]>
Cc: Mark Kelly <[email protected]>
Cc: Florian Fainelli <[email protected]>
LKML-Reference: <[email protected]>
---
arch/x86/kernel/cpu/rdc.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/rdc.c b/arch/x86/kernel/cpu/rdc.c
index c2bcdcc..e5e241c 100644
--- a/arch/x86/kernel/cpu/rdc.c
+++ b/arch/x86/kernel/cpu/rdc.c
@@ -65,7 +65,6 @@ static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
.c_vendor = "RDC",
- .c_ident = { "RDC" },
.c_identify = rdc_identify,
.c_x86_vendor = X86_VENDOR_RDC,
};
* tip-bot for H. Peter Anvin <[email protected]> wrote:
> Commit-ID: c0366f5f5c1615c4f70b1bd646149ba9233830b9
> Gitweb: http://git.kernel.org/tip/c0366f5f5c1615c4f70b1bd646149ba9233830b9
> Author: H. Peter Anvin <[email protected]>
> AuthorDate: Tue, 3 Aug 2010 10:09:56 -0700
> Committer: H. Peter Anvin <[email protected]>
> CommitDate: Tue, 3 Aug 2010 10:09:56 -0700
>
> x86, cpu: RDC doesn't have CPUID, which is what c_ident is
>
> c_ident is supposed to be a CPUID identifier, and RDC doesn't have
> that.
-tip testing found that these RDC patches cause a boot crash if a
X86_RDC321X=y kernel is booted on a regular PC:
[ 0.015999] Pid: 0, comm: swapper Not tainted 2.6.35-tip+ #23896 A8N-E/System Product Name
[ 0.015999] EIP: 0060:[<c1267d14>] EFLAGS: 00010282 CPU: 0
[ 0.015999] EIP is at strcmp+0xf/0x22
[ 0.015999] EAX: c1a81541 EBX: 00000004 ECX: 0000000f EDX: 00000000
[ 0.015999] ESI: c1a81571 EDI: 00000000 EBP: c19ccf78 ESP: c19ccf70
[ 0.015999] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 0.015999] Process swapper (pid: 0, ti=c19cc000 task=c1a07e60 task.ti=c19cc000)
[ 0.015999] Stack:
[ 0.015999] c1a81530 c1a81570 c19ccf8c c16d9b7f c1ac8538 c1a81530 c1a81570 c19ccfac
[ 0.015999] <0> c16d9dcb c104dc9f c1a15210 c1a81548 c1ac8538 00099800 c19ce000 c19ccfb4
[ 0.015999] <0> c1a89a4f c19ccfc0 c1a89d2d c1a96147 c19ccfe0 c1a84953 431d9715 00000006
[ 0.015999] Call Trace:
[ 0.015999] [<c16d9b7f>] ? get_cpu_vendor+0x22/0x8f
[ 0.015999] [<c16d9dcb>] ? identify_cpu+0xc5/0x2e0
[ 0.015999] [<c104dc9f>] ? sub_preempt_count+0x9/0x39
[ 0.015999] [<c1a89a4f>] ? identify_boot_cpu+0xd/0x23
[ 0.015999] [<c1a89d2d>] ? check_bugs+0xb/0xaf
[ 0.015999] [<c1a96147>] ? cpuset_init+0x65/0x77
[ 0.015999] [<c1a84953>] ? start_kernel+0x37e/0x392
[ 0.015999] [<c1a840c9>] ? i386_start_kernel+0xc9/0xd0
[ 0.015999] Code: c0 83 c9 ff f2 ae 4f 89 d1 49 78 06 ac aa 84 c0 75 f7 31 c0 aa 89 d8 5b 5e 5
[ 0.015999] EIP: [<c1267d14>] strcmp+0xf/0x22 SS:ESP 0068:c19ccf70
mercury:~> cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping : 2
cpu MHz : 2010.301
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy
bogomips : 4021.85
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
config attached.
Thanks,
Ingo
I couldn't reproduce this with 2.6.35 (without Peter's change),
I was trying on VirtualBox. If the detection code is causing a
problem we can just skip it if the CPU has cpuid.
Incidentally if you need some hardware to test the RDC port on I can
arrange that.
regards,
Mark
--- On Tue, 3/8/10, Ingo Molnar <[email protected]> wrote:
> From: Ingo Molnar <[email protected]>
> Subject: Re: [tip:x86/cpu] x86, cpu: RDC doesn't have CPUID, which is what c_ident is
> To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
> Cc: [email protected]
> Date: Tuesday, 3 August, 2010, 20:25
>
> * tip-bot for H. Peter Anvin <[email protected]>
> wrote:
>
> > Commit-ID:?
> c0366f5f5c1615c4f70b1bd646149ba9233830b9
> > Gitweb:? ???http://git.kernel.org/tip/c0366f5f5c1615c4f70b1bd646149ba9233830b9
> > Author:? ???H. Peter Anvin <[email protected]>
> > AuthorDate: Tue, 3 Aug 2010 10:09:56 -0700
> > Committer:? H. Peter Anvin <[email protected]>
> > CommitDate: Tue, 3 Aug 2010 10:09:56 -0700
> >
> > x86, cpu: RDC doesn't have CPUID, which is what
> c_ident is
> >
> > c_ident is supposed to be a CPUID identifier, and RDC
> doesn't have
> > that.
>
> -tip testing found that these RDC patches cause a boot
> crash if a
> X86_RDC321X=y kernel is booted on a regular PC:
>
> [? ? 0.015999] Pid: 0, comm: swapper Not tainted
> 2.6.35-tip+ #23896 A8N-E/System Product Name?
> ???
> [? ? 0.015999] EIP: 0060:[<c1267d14>]
> EFLAGS: 00010282 CPU: 0? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ???
> [? ? 0.015999] EIP is at strcmp+0xf/0x22?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ?
> [? ? 0.015999] EAX: c1a81541 EBX: 00000004 ECX:
> 0000000f EDX: 00000000? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ?
> [? ? 0.015999] ESI: c1a81571 EDI: 00000000 EBP:
> c19ccf78 ESP: c19ccf70? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ?
> [? ? 0.015999]? DS: 007b ES: 007b FS: 00d8
> GS: 00e0 SS: 0068? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ?
> [? ? 0.015999] Process swapper (pid: 0,
> ti=c19cc000 task=c1a07e60 task.ti=c19cc000)? ?
> ? ? ? ? ???
> [? ? 0.015999] Stack:? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ???
> [? ? 0.015999]? c1a81530 c1a81570 c19ccf8c
> c16d9b7f c1ac8538 c1a81530 c1a81570 c19ccfac? ?
> ? ? ???
> [? ? 0.015999] <0> c16d9dcb c104dc9f
> c1a15210 c1a81548 c1ac8538 00099800 c19ce000 c19ccfb4?
> ? ? ?
> [? ? 0.015999] <0> c1a89a4f c19ccfc0
> c1a89d2d c1a96147 c19ccfe0 c1a84953 431d9715 00000006?
> ? ? ?
> [? ? 0.015999] Call Trace:? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ?
> [? ? 0.015999]? [<c16d9b7f>] ?
> get_cpu_vendor+0x22/0x8f? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ?
> ???
> [? ? 0.015999]? [<c16d9dcb>] ?
> identify_cpu+0xc5/0x2e0? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ?
> [? ? 0.015999]? [<c104dc9f>] ?
> sub_preempt_count+0x9/0x39? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ?
> ???
> [? ? 0.015999]? [<c1a89a4f>] ?
> identify_boot_cpu+0xd/0x23? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ?
> ???
> [? ? 0.015999]? [<c1a89d2d>] ?
> check_bugs+0xb/0xaf? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ?
> [? ? 0.015999]? [<c1a96147>] ?
> cpuset_init+0x65/0x77? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ?
> [? ? 0.015999]? [<c1a84953>] ?
> start_kernel+0x37e/0x392? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ?
> ???
> [? ? 0.015999]? [<c1a840c9>] ?
> i386_start_kernel+0xc9/0xd0? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> [? ? 0.015999] Code: c0 83 c9 ff f2 ae 4f 89 d1
> 49 78 06 ac aa 84 c0 75 f7 31 c0 aa 89 d8 5b 5e 5
> [? ? 0.015999] EIP: [<c1267d14>]
> strcmp+0xf/0x22 SS:ESP 0068:c19ccf70? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ???
>
> mercury:~> cat /proc/cpuinfo
> processor??? : 0
> vendor_id??? : AuthenticAMD
> cpu family??? : 15
> model??? ??? : 35
> model name??? : AMD Athlon(tm) 64 X2 Dual
> Core Processor 3800+
> stepping??? : 2
> cpu MHz??? ??? : 2010.301
> cache size??? : 512 KB
> physical id??? : 0
> siblings??? : 2
> core id??? ??? : 0
> cpu cores??? : 2
> fpu??? ??? : yes
> fpu_exception??? : yes
> cpuid level??? : 1
> wp??? ??? : yes
> flags??? ??? : fpu vme de pse
> tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
> clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm
> 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy
> bogomips??? : 4021.85
> TLB size??? : 1024 4K pages
> clflush size??? : 64
> cache_alignment??? : 64
> address sizes??? : 40 bits physical, 48 bits
> virtual
> power management: ts fid vid ttp
>
> config attached.
>
> Thanks,
>
> ??? Ingo
>
* bifferos <[email protected]> wrote:
> I couldn't reproduce this with 2.6.35 (without Peter's change),
> I was trying on VirtualBox. If the detection code is causing a
> problem we can just skip it if the CPU has cpuid.
As i reported:
> > -tip testing found that these RDC patches cause a boot
> > crash if a X86_RDC321X=y kernel is booted on a regular PC:
Those two patches caused the crash, with the config i sent, on a regular PC.
Ingo
On 08/04/2010 02:12 AM, bifferos wrote:
>
> I couldn't reproduce this with 2.6.35 (without Peter's change),
> I was trying on VirtualBox. If the detection code is causing a
> problem we can just skip it if the CPU has cpuid.
>
> Incidentally if you need some hardware to test the RDC port on I can
> arrange that.
>
Incidentally, please do note that there is no concrete benefit to this
"support", since all it does is replicate information in /proc/cpuinfo
that is already available through lspci.
-hpa
--- On Wed, 4/8/10, H. Peter Anvin <[email protected]> wrote:
>
> Incidentally, please do note that there is no concrete
> benefit to this
> "support", since all it does is replicate information in
> /proc/cpuinfo
> that is already available through lspci.
Without the patch RDC is misreported as Cyrix Cx486SLC.
On 08/04/2010 03:59 PM, bifferos wrote:
> --- On Wed, 4/8/10, H. Peter Anvin <[email protected]> wrote:
>
>>
>> Incidentally, please do note that there is no concrete
>> benefit to this
>> "support", since all it does is replicate information in
>> /proc/cpuinfo
>> that is already available through lspci.
>
> Without the patch RDC is misreported as Cyrix Cx486SLC.
>
And what problems does that cause? Presumably none, in which case you
have to realize that the correctness threshold for this patch is
enormous, as the benefit is extremely small compared with the potential
(and actual!) harm.
-hpa
--- On Thu, 5/8/10, H. Peter Anvin <[email protected]> wrote:
> > Without the patch RDC is misreported as Cyrix
> Cx486SLC.
> >
>
> And what problems does that cause?? Presumably none,
If I don't know the CPU how do I set the tick rate?
http://android.git.kernel.org/?p=kernel/common.git;a=commitdiff_plain;h=e1b4d1143651fb3838be1117785b6e0386fa151f
On 08/04/2010 05:27 PM, bifferos wrote:
>
> --- On Thu, 5/8/10, H. Peter Anvin <[email protected]> wrote:
>>> Without the patch RDC is misreported as Cyrix
>> Cx486SLC.
>>>
>>
>> And what problems does that cause? Presumably none,
>
> If I don't know the CPU how do I set the tick rate?
>
> http://android.git.kernel.org/?p=kernel/common.git;a=commitdiff_plain;h=e1b4d1143651fb3838be1117785b6e0386fa151f
>
That's a valid use, of course, but that wasn't sent with it. Even so,
it's really a chipset property and not a CPU property and probably
should simply be set via a PCI quirk.
So, clean up the patch, add the usage, and then it can be put into the
-tip tree for the next merge window.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
The quick fix for this is:
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 490dac6..06a2dac 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -497,6 +497,9 @@ static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c)
if (!cpu_devs[i])
break;
+ if (!cpu_devs[i]->c_ident[0])
+ continue;
+
if (!strcmp(v, cpu_devs[i]->c_ident[0]) ||
(cpu_devs[i]->c_ident[1] &&
!strcmp(v, cpu_devs[i]->c_ident[1]))) {
however, Peter's requirement to remove c_ident renders my patch
somewhat less useful back on RDC. /proc/cpuinfo then lists the
vendor as 'RDC' (an improvement over not applying the patch) and
the model name as '486' (also an improvement), but for some
reason the variants in my case statement then no longer make it
through to /proc/info. I don't think this is a big deal, and I
still think the patch is worth applying with this change.
regards,
Mark
--- On Tue, 3/8/10, Ingo Molnar <[email protected]> wrote:
> From: Ingo Molnar <[email protected]>
> Subject: Re: [tip:x86/cpu] x86, cpu: RDC doesn't have CPUID, which is what c_ident is
> To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
> Cc: [email protected]
> Date: Tuesday, 3 August, 2010, 20:25
>
> * tip-bot for H. Peter Anvin <[email protected]>
> wrote:
>
> > Commit-ID:?
> c0366f5f5c1615c4f70b1bd646149ba9233830b9
> > Gitweb:? ???http://git.kernel.org/tip/c0366f5f5c1615c4f70b1bd646149ba9233830b9
> > Author:? ???H. Peter Anvin <[email protected]>
> > AuthorDate: Tue, 3 Aug 2010 10:09:56 -0700
> > Committer:? H. Peter Anvin <[email protected]>
> > CommitDate: Tue, 3 Aug 2010 10:09:56 -0700
> >
> > x86, cpu: RDC doesn't have CPUID, which is what
> c_ident is
> >
> > c_ident is supposed to be a CPUID identifier, and RDC
> doesn't have
> > that.
>
> -tip testing found that these RDC patches cause a boot
> crash if a
> X86_RDC321X=y kernel is booted on a regular PC:
>
> [? ? 0.015999] Pid: 0, comm: swapper Not tainted
> 2.6.35-tip+ #23896 A8N-E/System Product Name?
> ???
> [? ? 0.015999] EIP: 0060:[<c1267d14>]
> EFLAGS: 00010282 CPU: 0? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ???
> [? ? 0.015999] EIP is at strcmp+0xf/0x22?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ?
> [? ? 0.015999] EAX: c1a81541 EBX: 00000004 ECX:
> 0000000f EDX: 00000000? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ?
> [? ? 0.015999] ESI: c1a81571 EDI: 00000000 EBP:
> c19ccf78 ESP: c19ccf70? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ?
> [? ? 0.015999]? DS: 007b ES: 007b FS: 00d8
> GS: 00e0 SS: 0068? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ?
> [? ? 0.015999] Process swapper (pid: 0,
> ti=c19cc000 task=c1a07e60 task.ti=c19cc000)? ?
> ? ? ? ? ???
> [? ? 0.015999] Stack:? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ???
> [? ? 0.015999]? c1a81530 c1a81570 c19ccf8c
> c16d9b7f c1ac8538 c1a81530 c1a81570 c19ccfac? ?
> ? ? ???
> [? ? 0.015999] <0> c16d9dcb c104dc9f
> c1a15210 c1a81548 c1ac8538 00099800 c19ce000 c19ccfb4?
> ? ? ?
> [? ? 0.015999] <0> c1a89a4f c19ccfc0
> c1a89d2d c1a96147 c19ccfe0 c1a84953 431d9715 00000006?
> ? ? ?
> [? ? 0.015999] Call Trace:? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ?
> [? ? 0.015999]? [<c16d9b7f>] ?
> get_cpu_vendor+0x22/0x8f? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ?
> ???
> [? ? 0.015999]? [<c16d9dcb>] ?
> identify_cpu+0xc5/0x2e0? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ?
> [? ? 0.015999]? [<c104dc9f>] ?
> sub_preempt_count+0x9/0x39? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ?
> ???
> [? ? 0.015999]? [<c1a89a4f>] ?
> identify_boot_cpu+0xd/0x23? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ?
> ???
> [? ? 0.015999]? [<c1a89d2d>] ?
> check_bugs+0xb/0xaf? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ?
> [? ? 0.015999]? [<c1a96147>] ?
> cpuset_init+0x65/0x77? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ?
> [? ? 0.015999]? [<c1a84953>] ?
> start_kernel+0x37e/0x392? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ?
> ???
> [? ? 0.015999]? [<c1a840c9>] ?
> i386_start_kernel+0xc9/0xd0? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> [? ? 0.015999] Code: c0 83 c9 ff f2 ae 4f 89 d1
> 49 78 06 ac aa 84 c0 75 f7 31 c0 aa 89 d8 5b 5e 5
> [? ? 0.015999] EIP: [<c1267d14>]
> strcmp+0xf/0x22 SS:ESP 0068:c19ccf70? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ???
>
> mercury:~> cat /proc/cpuinfo
> processor??? : 0
> vendor_id??? : AuthenticAMD
> cpu family??? : 15
> model??? ??? : 35
> model name??? : AMD Athlon(tm) 64 X2 Dual
> Core Processor 3800+
> stepping??? : 2
> cpu MHz??? ??? : 2010.301
> cache size??? : 512 KB
> physical id??? : 0
> siblings??? : 2
> core id??? ??? : 0
> cpu cores??? : 2
> fpu??? ??? : yes
> fpu_exception??? : yes
> cpuid level??? : 1
> wp??? ??? : yes
> flags??? ??? : fpu vme de pse
> tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
> clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm
> 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy
> bogomips??? : 4021.85
> TLB size??? : 1024 4K pages
> clflush size??? : 64
> cache_alignment??? : 64
> address sizes??? : 40 bits physical, 48 bits
> virtual
> power management: ts fid vid ttp
>
> config attached.
>
> Thanks,
>
> ??? Ingo
>
On 08/09/2010 02:33 AM, bifferos wrote:
>
> The quick fix for this is:
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 490dac6..06a2dac 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -497,6 +497,9 @@ static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c)
> if (!cpu_devs[i])
> break;
>
> + if (!cpu_devs[i]->c_ident[0])
> + continue;
> +
> if (!strcmp(v, cpu_devs[i]->c_ident[0]) ||
> (cpu_devs[i]->c_ident[1] &&
> !strcmp(v, cpu_devs[i]->c_ident[1]))) {
>
>
> however, Peter's requirement to remove c_ident renders my patch
> somewhat less useful back on RDC. /proc/cpuinfo then lists the
> vendor as 'RDC' (an improvement over not applying the patch) and
> the model name as '486' (also an improvement), but for some
> reason the variants in my case statement then no longer make it
> through to /proc/info. I don't think this is a big deal, and I
> still think the patch is worth applying with this change.
>
Well, as I said, the generic code probably needs to change somewhat to
print that stuff.
-hpa