Bug 151471

Summary:	udev disables network card
Product:	[Fedora] Fedora	Reporter:	David del Campo <delcampo>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED CANTFIX	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	pfrields, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-10-03 01:05:02 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 David del Campo 2005-03-18 11:55:21 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Description of problem:
Booting a standard FC3 installation on this dual-processor machine shows "Starting udev: Disabling IRQ #9" and then the network card initialization fails. Once logged in, activating the card always fails even if the card is reinstalled. The card is an Intel PRO 100/S, but if I change it for a Realtek RTL-8029(AS) the problem remains. Both cards worked perfectly when the machine was Red Hat 9, and Windows has no problem whatsoever with them (so the cards are not broken and the motherboard, an Iwill DVD266-R, can see them fine). I have moved the cards to different PCI slots but the problem persists.

Version-Release number of selected component (if applicable):
udev-039-8.FC3

How reproducible:
Always

Steps to Reproduce:
1. Install FC3 (any option will do)
2. Boot up the freshly installed machine

Actual Results:  During booting you get the "Starting udev: Disabling IRQ #9" and the network card initialization fails

Expected Results:  The network card should have started and picked up the IP address my DHCP server offered to it

Additional info:

Comment 1 Harald Hoyer 2005-03-18 15:02:11 UTC

this is most likely the kernel that prints that message, not udev

Comment 2 Sitsofe Wheeler 2005-03-18 20:25:31 UTC

You can try the boot parameters
acpi=off
noapic
and see if the problem changes
It would also help if you indicated which kernel you are running (uname -r)

Comment 3 David del Campo 2005-03-21 17:04:45 UTC

(In reply to comment #2)
> You can try the boot parameters
> acpi=off
> noapic
> and see if the problem changes
> It would also help if you indicated which kernel you are running (uname -r)

The original report was posted when the machine had the 2.6.9-1.667 (both SMP 
and single-proc) kernels.

After the note about this being a kernel issue, I installed the 2.6.10-
1.770_FC3 (again both SMP and single-proc) kernel. Under this kernel, the 
problem persists in the SMP version but we get an extra error message during 
boot:

irq 9:nobody cared (try booting with "irqpoll" option)

I followed the advise about the irqpoll kernel option (I added it at the end of 
the kernel arguments in the grub append console), but this only resulted in the 
boot freezing after the lines:

...
Uncompressing Linux... Ok, booting the kernel
audit(1111423460.946:0): initialized

When booting the single-processor 2.6.10-1.770_FC3 kernel, and after 
successfully booting once with the irqpoll kernel option, the problem 
disappears and the network card works fine.

Using the "acpi=off noapic" kernel options solves the problem with all the 
kernels.

Is this the solution then? What was wrong?

Comment 4 Sitsofe Wheeler 2005-03-21 23:58:15 UTC

Probably and I don't know. I don't know enough about the intracacies of hardware
to know exactly what causes these problem (buggy BIOSes seems to be a favourite)
but I *do* know that they are often acpi or apic related (probably due to the
way that this changes how IRQs are routed). You may want to narrow down whether
just acpi=off or just noapic makes the problem go away. If you are adventurous
you can try checking whether there is a BIOS upgrade for your mobo but you do so
at YOUR OWN RISK. You may have an upgrade and find it doesn't make any
difference at all or breaks something else...

If irqpoll is fixing a problem though, then that suggests a bug in a driver that
needs to be reported to the address mentioned in the startup messages.

Comment 5 David del Campo 2005-03-22 11:27:43 UTC

(In reply to comment #4)
> Probably and I don't know. I don't know enough about the intracacies of
> hardware
> to know exactly what causes these problem (buggy BIOSes seems to be a
> favourite)
> but I *do* know that they are often acpi or apic related (probably due to the
> way that this changes how IRQs are routed). You may want to narrow down
> whether
> just acpi=off or just noapic makes the problem go away. If you are adventurous
> you can try checking whether there is a BIOS upgrade for your mobo but you do
> so
> at YOUR OWN RISK. You may have an upgrade and find it doesn't make any
> difference at all or breaks something else...
> If irqpoll is fixing a problem though, then that suggests a bug in a driver
> that
> needs to be reported to the address mentioned in the startup messages.

I have just booted using the acpi=off kernel option and that alone seems to fix 
the problem. The motherboard is too old for Iwill to keep updated BIOSes for it.

Comment 6 Dave Jones 2005-07-15 20:30:02 UTC

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 7 Dave Jones 2005-10-03 01:05:02 UTC

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.