Bug 136257

Summary: VIA C3 Erza-T lockup randomly on FC3T3
Product: [Fedora] Fedora Reporter: Paul Coleman <pdcoleman>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 3CC: pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-20 04:52:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paul Coleman 2004-10-18 22:13:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041016
Firefox/0.10.1

Description of problem:
System locks up randomly between 1 and 10 minutes.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Boot system
2. 
3.
    

Actual Results:   System lockup in 1 to 10 minutes

Expected Results:  No lockup

Additional info:

System was stable under FC2. Memtest ran for hours, no errors. Logfile
files seem OK except for one kernel warning I caught once that
referenced CPUfreq mismatch between actual and expected. Bug 125419 on
FC2 seems to be similar on a VIA C3 Samual 2. Its an older bug and
still open. I did not have that problem back then.

Comment 1 Paul Coleman 2004-10-19 17:13:53 UTC
I found this in a via forum discussing lockups.

"I have kernel 2.6.9-rc1-mm2 running now for more than 2 weeks with
enabled longhaul module and frequent cpu-frequency changes (through
powersaved). Very important seem to be some patches that are only part
of the mm kernel patches. I have tried 2.6.9-rc1 , 2.6.9-rc2 and
2.6.8.1 (with longhaul.c from 2.6.9-rc1-mm2) and all locked the
machine up. Some patches inside the mm package seem to be necessary
for cpufreq scaling to work without lockups (except for the longhaul.c
patch). I guess later mm patches will also work (2.6.9-rc1-mm6,
2.6.9-rc2-mm1)"

Comment 2 Paul Coleman 2004-10-20 23:44:50 UTC
This is a show stopper for FC3 for anyone using a Via C3 (at least an
Ezra-T). Today playing around booting that system I noticed that if I
keeped the mouse moving it changed a lockup to a very slow system.
Interrupts?

Editorial: The Via stuff is becoming a large consumer of my time in
testing and installing systems. I see no one from Via actively
involved in the community. Sigh! I tried to change the priority of thr
bug but it wouldn't let me.

Comment 3 Jorge Gonzalez 2004-10-23 12:20:04 UTC
I also had installation problems with FC2 on a VIA Eden VE5000 mobo,
with a C3 CPU. Installation kernel wouldn't even boot. From the
explanation given here:

http://www.livejournal.com/users/notbrainsurgery/2429.html

it looks like the kernel identifies the C3 CPU as i686 class (which
seems correct) but there's an optional characteristic for the i686
arch (conditional movs), which Intel implements and C3 does not, but
which gcc assumes to be available for all i686. So RPMs created for
the i686 potentially can hangup or reboot the machine, and only i586
RPMs should be used.

More info in the link given.

BTW, I confirmed the problem by installing FC1 (goes well), installing
apt, apt-get dist-upgrading to FC2 and then without rebooting deleting
the i686 kernel RPMs and installing the i586 ones. Now it's working
ok. It's taken me months to realize this.

Comment 4 Dave Jones 2004-11-20 04:52:24 UTC
the installer/up2date shouldn't have installed a 686 kernel on the earlier C3s.
There's logic in both to explicitly handle this case.

Sounds like apt-get misses the same logic.

The original poster. assuming they are using a 586 kernel, might be getting
bitten by the longhaul driver, which does seem to have some issues still.
Sounds like a dupe of 125419.


*** This bug has been marked as a duplicate of 125419 ***