Bug 156001 - The SMP version of the kernel causes NIC operations to freeze
The SMP version of the kernel causes NIC operations to freeze
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel-utils (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-26 11:39 EDT by Matthew
Modified: 2015-01-04 17:19 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-07 22:30:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew 2005-04-26 11:39:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050224 Firefox/1.0.1 Fedora/1.0.1-1.3.1

Description of problem:
I have experiemented with 2 releases (most recent listed in version field) of the SMP version of the kernel on a SMP box (Intel Pentium 4E Prescott 3.0GHz FSB800 1MB Cache) using an ASUS P4S800 SiS648FX Socket 478 800FSB 3DDR 400 ATA133 NOT SATA ATX Motherboard w/ Audio/LAN. The FC3 installation detects the architecture and automatically installs a SMP kernel and a 'plain' kernel. When I boot, if I select the SMP kernel, then when it encounters an action during the boot process that needs to access the NIC it freezes (in my case either accessing a network time server or sshd)

Version-Release number of selected component (if applicable):
kernel-2.6.11-1.4_FC3smp

How reproducible:
Always

Steps to Reproduce:
1. There are no special steps. This was an of the shelf box. Hard drive formatted and then FC3 installed. Immediately on the first reboot after installation the boot froze when it got to sshd. Everything works fine if I select the plain non-SMP kernel 
2.
3.
  

Actual Results:  boot process froze and never progressed

Expected Results:  normal boot process should have completed

Additional info:

nothing is displayed on the screen. There is no FAILED or the like just a frozen normal boot up screen.
I have come across others in forums with this problem. Apparently a company in Pittsburg switched distro's after experiencing this problem.
Comment 1 Dave Jones 2005-07-15 16:42:06 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 2 Dave Jones 2005-10-02 21:16:59 EDT
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.
Comment 3 Matthew 2005-10-03 02:27:33 EDT
Tried latest release of SMP kernel. Problem persists unchanged.
Comment 4 Dave Jones 2005-10-03 17:33:52 EDT
What NIC is this ? can you paste lspci output please ?
Comment 5 Matthew 2005-10-04 02:05:51 EDT
 /sbin/lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS 645xx (rev 51)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS]: Unknown device 0003
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (r
ev 25)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Cont
roller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev
 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev
 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Et
hernet (rev 91)
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (re
v a1)
Comment 6 John W. Linville 2005-10-19 11:11:42 EDT
Someone else having similar problems w/ the same type of NIC reported that 
adding "acpi=off" to his kernel command line resolved the issue he was seeing.  
Could you try that as well?  You may also want to try "acpi=noirq", and 
perhaps other variations... 
 
Please try at least "acpi=off" and post the results here...thanks! 
Comment 7 Matthew 2005-10-19 11:46:17 EDT
Works like a charm! Big relief! Thx for you effort, John.

PS: It just needed acpi=off
Comment 8 John W. Linville 2005-10-20 10:49:44 EDT
You may want to try to find a BIOS update.  What motherboard/system are you 
using? 
Comment 9 Matthew 2005-10-20 11:03:16 EDT
Intel Pentium 4E Prescott 3.0GHz FSB800 1MB Cache on a ASUS P4S800 SiS648FX
Socket 478 800FSB 3DDR 400 ATA133 motherboard(In reply to comment #8)
> You may want to try to find a BIOS update.  What motherboard/system are you 
> using? 

Intel Pentium 4E Prescott 3.0GHz FSB800 1MB Cache on a ASUS P4S800 SiS648FX
Socket 478 800FSB 3DDR 400 ATA133 motherboard
Comment 10 Matthew 2005-11-07 03:13:08 EST
I am now using 2.6.12-1.1381_FC3smp and it is working fine. My only concern is
that both smp kernels I have used have don't complete the power off routine.
When I shutdown it goes through the routine but leaves the PC running. Do you
have any thoughts in this regard?
Comment 11 John W. Linville 2005-11-07 10:32:17 EST
"acpi=off" will prevent the ACPI power management functions (like power-off)  
from running.  I'm sorry.  There isn't much I can do here. 
 
This link suggests that there might be problems w/ running irqbalance on that 
motherboard: 
 
   http://www.linuxquestions.org/questions/archive/39/2005/03/3/264522 
 
You might want to try disabling it and removing the "acpi=off" to see if that 
is a helpful combination? 
Comment 12 Matthew 2005-11-08 03:00:14 EST
Yes, that does the trick (removed acpi=off disabled irqbalance).

Thanks,

Matthew
Comment 14 Dave Jones 2005-11-21 13:28:20 EST
I'm puzzled as to why this would be an irqbalance bug. It's just telling the
driver the CPU to bind to, and occasionally rebalancing.

It smells like a driver bug to me, or possibly a hardware bug where it misses
IRQs from cpu's other than the boot cpu.

very puzzling.
Comment 17 Bill Shoffner 2005-11-30 12:19:59 EST
I just wanted to weigh in with a very similar issue.  I upgraded from RH9 to 
Fedora Core4, straight off the CDs, so a UP and SMP kernel were built 
automatically.  The UP kernel worked fine, but the SMP kernel gave me no 
network support (no route to host error), whenever I tried to access a network 
site.  After reading John's comment, I tried acpi=off when starting the SMP 
kernel, and it worked.  I also removed the irqbalance process which also was 
successful.  After that, I flashed the bios on the motherboard to bring it up 
to the latest version.  That corrected the problem, even without using the 
acpi=off kernel option, and with the irqbalance process running.  Hardware 
details are below.

motherboard = Tyan Tiger 230 (S2507) Dual Pentium III 1000Mhz
old bios = 1.03   new bios = 1.06
Comment 18 Matthew Miller 2006-07-10 19:38:08 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 19 petrosyan 2008-02-07 22:30:43 EST
Fedora Core 3 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

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