The kernel from boot disks hangs when installing on Asus CUV4X-E
motherboard (the famous VIA 82C686B southbridge) with a Pentium3
800MHz (6 x 133MHz) and PC133 memory.
The problem is quite reproducible: also happens on RH 7.0 and with
a kernel 2.4.3 (no patches). The system hangs/oops at different
places, ranging from CRC error decompressing kernel to oops after
the IDE chipset detection or just before loading anaconda.
This was tested on 2 machines (different cdrom, hd, memories,
etc) with the same model of motherboard. The media are also know
to be good (lot of instalations before).
It may be a kernel issue or hardware failure. Changing the memory
frequency from 133MHz to 100MHz _SOLVES_ all the problems on both
systems. (there's a feature on bios to change memory clock to 3/4 of
The memories have been tested at 133MHz and 100MHz with memtest86
v2.5 without any problems detected.
This bug looks a lot like bug 37255
Yes, it's similar to 37255... But slowing the bus clock didn't
solve the problem there: the guy has a 1GHz P3 and tried to run
at 500MHz (isn't P3 multipler locked? He must have changed cpu bus
Bug 37255: I just tried to run at 800 MHz CPU's and 100 MHz bus.
The crash was the same. I do not believe it has anything to do with speed.
this bug does not look like bug #37255.
CRC errors during kernel uncompression are 99.9% caused by some sort of hardware
problem. (usually some sort of thermal condition, or faulty RAM, faulty CPU -
although you tested it on two different boards.) Kernel uncompression happens in
16-bit mode and the 32-bit Linux kernel is not running yet, at all. The 16-bit
boot code uses standard BIOS routines and is a well-proven piece of code, we
havent had any bugs in there for ages.
it could also be the BIOS settings, if the RAM is sold as PC133, but doesnt
actually handle CAS latencies of 2 cycles properly, then you can get the same
error on two different boards, using two different RAM modules. Please set all
RAM tunings to the most conservative value and/or slow down the memory bus to
*** Bug 54386 has been marked as a duplicate of this bug. ***