[CentOS] RHEL 6/CentOS

Wed May 11 11:09:22 UTC 2011
Steve Clark <sclark at netwolves.com>

On 05/11/2011 05:46 AM, Johnny Hughes wrote:
> On 05/10/2011 05:42 AM, Steve Clark wrote:
>> On 04/26/2011 08:24 AM, Steve Clark wrote:
>>> Hello,
>>>
>>> Anybody know the reason RedHat decided not to support the
>>> VIA Eden Processor?
>>>
>>> cat /proc/cpuinfo
>>> processor       : 0
>>> vendor_id       : CentaurHauls
>>> cpu family      : 6
>>> model           : 13
>>> model name      : VIA Eden Processor  500MHz
>>>
>>> I am testing, (using ayplus kernel) and get the following during bootup:
>>> Linux version 2.6.32-71.24.1.el6.centos.ayplus.1.i686 (build at 6beta32)
>>> (gcc versi
>>> on 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Fri Apr 8 17:23:21
>>> PDT 2011
>>> KERNEL supported cpus:
>>>    Intel GenuineIntel
>>>    AMD AuthenticAMD
>>>    NSC Geode by NSC
>>>    Cyrix CyrixInstead
>>>    Centaur CentaurHauls
>>>    Transmeta GenuineTMx86
>>>    Transmeta TransmetaCPU
>>>    UMC UMC UMC UMC
>>> UNSUPPORTED HARDWARE DEVICE: Centaur Processor
>>> ------------[ cut here ]------------
>>> WARNING: at kernel/unsupported.c:13
>>> mark_hardware_unsupported+0x37/0x40() (Not t
>>> ainted)
>>> Your hardware is unsupported.  Please do not report bugs, panics,
>>> oopses, etc.,
>>> on this hardware.
>>> Modules linked in:
>>> Pid: 0, comm: swapper Not tainted
>>> 2.6.32-71.24.1.el6.centos.ayplus.1.i686 #1
>>> Call Trace:
>>>   [<c0450201>] ? warn_slowpath_common+0x81/0xc0
>>>   [<c0477e67>] ? mark_hardware_unsupported+0x37/0x40
>>>   [<c0477e67>] ? mark_hardware_unsupported+0x37/0x40
>>>   [<c0450293>] ? warn_slowpath_fmt_taint+0x33/0x40
>>>   [<c0477e67>] ? mark_hardware_unsupported+0x37/0x40
>>>   [<c08056eb>] ? early_init_centaur+0xd/0x2d
>>>   [<c0a49835>] ? early_cpu_init+0x11a/0x13e
>>>   [<c0a453b3>] ? setup_arch+0x38/0xb90
>>>   [<c0450d3e>] ? vprintk+0x1ae/0x490
>>>   [<c080ba2a>] ? printk+0x17/0x1d
>>>   [<c0a5a4ee>] ? cgroup_init_subsys+0xcf/0xdb
>>>   [<c0a406da>] ? start_kernel+0xca/0x3a4
>>> ---[ end trace a7919e7f17c0a725 ]---
>>> Disabling lock debugging due to kernel taint
>>>
>>>
>>>
>>> I traced it down to this code, which is not in the standard kernel.org
>>> kernel-2.6.32.36:
>>> from kernel-2.6.32.36
>>> static void __cpuinit early_init_centaur(struct cpuinfo_x86 *c)
>>> {
>>>      switch (c->x86) {
>>>
>>>
>>> from 2.6.32-71.24.1.el6.ayplus
>>> arch/x86/kernel/cpu/centaur.c
>>>
>>> static void __cpuinit early_init_centaur(struct cpuinfo_x86 *c)
>>> {
>>>          mark_hardware_unsupported("Centaur Processor");<<<<<<<<<<
>>>          switch (c->x86) {
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>> FYI.
>> Replying to my own E-Mail after running
>> 2.6.32-71.24.1.el6 from SL. I can report that I have
>> been having lockups (hangs) on three different via centaur processor boxes.
>> The hangs require power cycling the boxes.
> If you take a look on google for "CentaurHauls i686" you will see that
> this CPU/chipset SAYS it fully supports i686 but it really does not.
> All of EL6 is i686 and not i586 (which CentaurHauls really fully supports).
>
> I think you are going to have issues with this CPU and EL6 forever.
> EL5.x should likely be used with this CPU ...
>
Thanks for the feedback.

  I guess the only thing I can say is at the start of the kernel boot it says:

KERNEL supported cpus:
   Intel GenuineIntel
   AMD AuthenticAMD
   NSC Geode by NSC
   Cyrix CyrixInstead
   Centaur CentaurHauls<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
   Transmeta GenuineTMx86
   Transmeta TransmetaCPU
   UMC UMC UMC UMC


Which implies to me that it should work. I have booted up 3 boxes using acpi=off to see
if that makes any difference. So far they have been up a couple of days, but I need them to
be up at least a week to have any faith that acpi=off makes any difference.


-- 
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos/attachments/20110511/881d8907/attachment-0004.html>