On Fri, 12 Jan 2007, Jim Perrin wrote:

...

I have a EPIA mini-itx board that I have been running Fedora 4 on. I want to install CentOS 4.4 on it since FC4 is no longer supported. The install goes fine but when I reboot the machine after the install I get errors like the following:

The via c3 boards require that you install and run the i586 kernel (because for some ungodly reason compatibility wasn't in via's focus) and you'll also need to disable the cpuspeed service, as it's enabled by default, and will fail on the via processor causing a kernel panic.

I installed the i586 kernel, disabled cpuspeed and rebooted the machine. No change. I am still getting the errors. The good news is the kernel panic only seems to occur randomly. Most of the time the machine hangs for a few minutes spews some errors and then continues to boot up normally.

My question now becomes is how do I force an i586 installation? The installer detects and installs i686 including glibc and the kernel. I found one document that says to pass i586 at boot time but I am still getting the i686 kernel and glibc.

I looked to google for advice but so far I cannot find anything that helps. If someone has a pointer to a good doc for this kind of thing I would appreciate a pointer.

Of course any other suggestions on how to get this working, would be appreciated.

Regards,

No, actually, it's a gcc bug. The C3 doesn't support the CMOV instruction, which is ok according to Intel documentation, and software should check whether this instruction is available. gcc implicitly expects every 686 to have this instruction. To add up to the confusion, on later VIA CPUs (those with a C5P core and later), you'll actually want to use 686 to initialize the SSE pipeline, which is necessary to make use of the xcrypt instructions (which will otherwise be invalid opcodes).

Hmm, that does explain it pretty well. I think I'll maintain my original position though and blame via, simply because I had a run of bad experiences with their chipsets early on in my computing career. I don't care what you and your 'facts' say :-P

It sits better with my unfounded beliefs that via screwed up as opposed to a gcc bug. :-)

On Sat, 13 Jan 2007, Daniel de Kok wrote:

On Fri, January 12, 2007 5:09 pm, Jim Perrin wrote:

...

The via c3 boards require that you install and run the i586 kernel (because for some ungodly reason compatability wasn't in via's focus)

No, actually, it's a gcc bug. The C3 doesn't support the CMOV instruction, which is ok according to Intel documentation, and software should check whether this instruction is available. gcc implicitly expects every 686 to have this instruction.

To add up to the confusion, on later VIA CPUs (those with a C5P core and later), you'll actually want to use 686 to initialize the SSE pipeline, which is necessary to make use of the xcrypt instructions (which will otherwise be invalid opcodes).

So is there a way to work around the bug?? Running the i586 kernel does not make the errors go away. The thing I do not understand is, why sometimes the kernel panics and other times the machine comes up and plays after spending several minutes spewing errors.

dmesg output is available here: http://www.tntechs.com/tntechs/hepa-dmesg.txt if anyone is interested in looking at it.

Regards,

On Sun, 14 Jan 2007, Daniel de Kok wrote:

On Sun, January 14, 2007 7:14 am, Tom Diehl wrote:

...

So is there a way to work around the bug?? Running the i586 kernel does not make the errors go away. The thing I do not understand is, why sometimes the kernel panics and other times the machine comes up and plays after spending several minutes spewing errors.

...

From the dmesg output:

---

hda: dma_timer_expiry: dma status == 0x21 hda: DMA timeout error hda: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest }

---

Did you disable cpufreqd? AFAIK the C3 requires that all DMA requests are stopped before changing the multiplier.

Assuming cpufreqd is part of cpuspeed then, yes it is disabled. The only thing I can find on the system that refers to cpufreq are kernel modules.

"lsmod | grep cpufreq" returns nothing. In addition: locate cpufreq, also returns nothing.

Am I missing something??

Regards,

On Mon, 15 Jan 2007, Daniel de Kok wrote:

On Mon, January 15, 2007 2:44 am, Tom Diehl wrote:

...

Assuming cpufreqd is part of cpuspeed then, yes it is disabled. The only thing I can find on the system that refers to cpufreq are kernel modules.

Yeah, sorry, I always mix up cpufreqd and cpuspeed :). Are any module related to clock scaling loaded?

Not that I see.

[root@hepa pts0 init.d]# lsmod Module Size Used by md5 4033 1 ipv6 234113 14 dm_mod 59349 0 uhci_hcd 31065 0 ehci_hcd 31045 0 via_rhine 23113 0 mii 5057 1 via_rhine ext3 116553 1 jbd 71385 1 ext3 [root@hepa pts0 init.d]#

Regards,