Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 159082

Summary: smp failure on dual xeon / intel serverboard
Product: [Fedora] Fedora Reporter: Jonathan Deitch <pinball>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: davej, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-06 15:40:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 150222, 158504, 165247    

Description Jonathan Deitch 2005-05-29 02:59:22 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
System will boot smp clear through to the login prompt, no errors.

But as SOON as the kernel inits at the start of the boot process, *all IO locks
up*.  No keyboard, no mouse, no network, nothing.

So once the system has finished booting, it's completely unusable : it sits
there blinking a cursor, and is totally inaccesible via keyboard, mouse, or network.

This happens regardless of runlevel (single, multiuser, X).

Verified on a stock FC4T3 install, and with all yum updates installed, and on every
2.6.11 FC4 smp kernel available right up to the new 1363 one.

System was installed as "server", with all defaults taken during install.

Logs not only show no errors, but do not log the fact that the system booted
smp, period.  It's like syslog never even ran.

Board is a Intel SE7501CW2, with two 1.8ghz Xeons, 512mb memory.

There are NO io cards installed, and the system is stock off the FC4T3 isos.

I've tried running all yum updates; no help ... I've tried every FC4 smp kernel
from FC4_1267 to the current 1363, all have the same exact result.

It makes no difference if I'm running the stock install off the ISOs, or have
run yum update to bring to current.

All of the above kernels boot perfectly in *non* smp.  It's just smp kernels --
any smp --that flat-out fail.

Knoppix 3.82 (running a 2.6.11 kernel) boots flawleslly into smp.

- Jonathan

Version-Release number of selected component (if applicable):
all 2.6.11 FC4 smp kernels (1267 to current)

How reproducible:

Steps to Reproduce:
1.  Install FC4T3
2.  Boot into a smp kernel
3.  Lockup

Actual Results:  System was locked up.  No io was possible : keyboard, mouse, or network.

Expected Results:  System should run normally.

Additional info:

Board is an Intel SE7501CW2, with two 1.8ghz Xeons, 512mb memory.

There are NO io cards installed.

Comment 1 Jonathan Deitch 2005-05-30 00:01:07 UTC
*** Bug 159110 has been marked as a duplicate of this bug. ***

Comment 2 Jonathan Deitch 2005-06-01 02:01:53 UTC
This problem is worse than originally thought.

The same exact issue happens on stock FC3 with the 2.6.9 kernel series, from the
stock kernel supplied with the ISOs to the very last one available via updates.

System IO is completely frozen the second you boot a smp kernel : no keyboard,
mouse, or network.  The boot process itself completes with no errors, but the
system is totally inaccessible due to the frozen IO.  Non-smp boots flawlessly.

Comment 3 Jonathan Deitch 2005-06-01 05:54:00 UTC
Ok, another update.

On the suggestion of someone in #fedora, I disabled "USB Legacy" in bios - that
has solved the problem.

How a USB setting can affect keyboard, mouse, and network is beyond me,
especially since there are no USB devices plugged into the system.

But it did ...

Comment 4 Dave Jones 2005-06-01 06:03:27 UTC
we usually recommend that setting be disabled. Though recently it does seem to
have caused more problems than it has previously. 2.6.10 changed the way USB
probing occurs, so its possible that the new style is more sensitive than the
old style.

Comment 5 Warren Togami 2006-03-06 15:40:57 UTC
Closing due to lack of activity.  If you are having this exact problem in FC5,
please re-open this bug or create a new one.