Description of problem:
On a VIA EPIA CL10K mini-itx board, the kernel has been hanging with
regularity. It appears to be during reads from the harddrive.
Version-Release number of selected component (if applicable):
How reproducible:
It's random, but has consistently left me with uptimes less than 3 days.

I was using Fedora Core 1 on this motherboard and it was working fine
with the last FC1 kernel. I skipped over FC2 due to the difficulty
of installing on the EPIA boards, and went to FC3.
The kernel oops may or may not be related to my problem, but I have
seen it at least twice on the EPIA board, and have not seen it on the
other x86 hardware I have.
I'm using EXT3 partitions and the last FC3 kernel.

I can't make any sense of the oops. We oopsed with
Unable to handle kernel paging request at virtual address a8d8f0e0
in ext3_block_to_path:0x35ed:
000035db <ext3_block_to_path>:
35db: 55 push %ebp
35dc: 57 push %edi
35dd: 56 push %esi
35de: 53 push %ebx
35df: 83 ec 0c sub $0xc,%esp
35e2: 89 d3 mov %edx,%ebx
35e4: 89 0c 24 mov %ecx,(%esp,1)
35e7: 8b 90 d4 00 00 00 mov 0xd4(%eax),%edx
35ed: 8b 82 e0 01 00 00 mov 0x1e0(%edx),%eax
Now, %edx actually holds 0x1fcc0400, so I can't see where the oops address
0xa8d8f0e0 can come from.
Here we're dereferencing inode->i_sb->s_fs_info. So we actually got an oops
looking up a field within inode->i_sb, which the filesystem never ever touches.
So if there's a software problem here, it looks more like a core VFS one than
an ext3 one. But that's still hard to square with the oops trace showing an
apparently bogus %edx.
It looks more like a hardware or hardware-related problem at first glance based
on the symptoms so far.
Do you have any other oopses captured that might shed more light on this?

I have observed the same behaviour on a few EPIA CL10K as well. We
have a dozen of these runing FC2 with no problem but I haven't been
able to get FC3 to run stable on the same hardware yet. There's no X
installed, just a minimal installation.
They freeze often right after the installation while the soft RAID1
disks are syncing with no other activity going on. I haven't seen any
of the oops Rob mentioned.

I had the same problem with a Via Ezra C3 system. It was easily
reproducible by going from an idle state to a high-cpu usage state.
Running "cat /dev/random > /dev/null" would usually cause it to fail
in minutes. Sometimes, but not always, this would appear in the
messages log: "phyrewall kernel: Warning: CPU frequency is 798000,
cpufreq assumed 731000 kHz" (the exact values would vary).
As above, disabling cpuspeed resolved the problem. The system has
been up for over 30 hours under various load conditions, where before
it always hung within 2 hours.

Okay. It's been well over two weeks, and things are looking good.
"cpuspeed" appears to have been the problem. My system has been much
more stable now. Uptimes have been good.
No further oops have been observed.
Thanks guys!