Bug 159082 - smp failure on dual xeon / intel serverboard
Summary: smp failure on dual xeon / intel serverboard
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
: 159110 (view as bug list)
Depends On:
Blocks: FC5Blocker FC4Update FCMETA_USB
TreeView+ depends on / blocked
Reported: 2005-05-29 02:59 UTC by Jonathan Deitch
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-03-06 15:40:57 UTC
Type: ---

Attachments (Terms of Use)

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.

Note You need to log in before you can comment on or make changes to this bug.