Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 174922 - ne2k-pci cold boot problem with 2.6.14-1.1644_FC5 and newer
ne2k-pci cold boot problem with 2.6.14-1.1644_FC5 and newer
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-12-04 03:17 EST by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-04 09:32:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2005-12-04 03:17:33 EST
Yesterday morning, my first cold boot after a yum update my network connection
didn't work. After may cold and warm boots I've come to the following conlusions:

My network card did not work 4 out of 5 cold boot attempts with

It did work 1 out of 1 cold boot attempts with 2.6.14-1.1663_FC5.x86_64, but
that may be just dumb luck.

If it has failed no ammount of warm booting 2.6.14-1.1644_FC5 or any newer
kernel will get it back to live. Booting 2.6.13-1.1594_FC5.x86_64 will bring it
back. Once it is alive any kernel warm-boot will work fine.

Not working / not alive in this case means that the card is detected fine. Also,
according to the ifconfig statistics frames get send fine, but nothing is
received. I found a similar bug, but with totally different hardware when
looking for duplicates: bug 174022

My card is a Compex ReadyLink 2000 (rev 0a). lspci -nv for my card gives:
00:0a.0 Class 0200: 11f6:1401 (rev 0a)
        Flags: medium devsel, IRQ 177
        I/O ports at b000 [size=32]
        [virtual] Expansion ROM at 30000000 [disabled] [size=32K]

This is with the network working. Note this might not be network related at all,
but instead a PCI IRQ routing problem, although concidering the behaviour I find
this unlikely. 

One last note I'm using the BNC (coax)/ 10-base-2 connector of my card not RJ45/UTP.
Comment 1 Hans de Goede 2005-12-05 12:34:15 EST
I've upgraded to the latest rawhide kernel, but thats no help. I've now also
experienced the problem with a warmboot.
Comment 2 John W. Linville 2005-12-05 16:51:48 EST
There was a somewhat recent change thatcould be touching this.  I've got test  
kernels that back-out that change available here:  
Please give them a try and post the results here...thanks!  
Comment 3 Hans de Goede 2005-12-06 14:37:27 EST
I'll give them a spin, it could be a couple of days before you hear from me
again, because if they seem to fix the problem I want to make sure the problem
is really fixed, which means gathering statistics (aka cold boots).

Comment 4 Hans de Goede 2005-12-06 15:27:35 EST
I'm afraid that the problem is not solved by
Comment 5 John W. Linville 2005-12-06 15:47:47 EST
Well, thanks for the info.  There isn't much else that changed in that driver 
between the kernels you cite as working and the ones that don't. 
Have you tried booting w/ "acpi=off" or "acpi=noirq" as kernel command-line 
Comment 6 Hans de Goede 2005-12-07 15:57:17 EST
I've tried:
-cold booting 2.6.14-1.1739_FC5 with acpi=noirq, no luck
-warm boot 2.6.14-1.1739_FC5 after acpi=noirq attempt, with acpi=off, this
 seems todo the trick.
Comment 7 John W. Linville 2005-12-07 16:03:54 EST
And cold boots w/ acpi=off? 
Comment 8 Hans de Goede 2005-12-07 16:09:14 EST
Also works
Comment 9 Hans de Goede 2005-12-09 13:23:45 EST
I just (accidently) did a cold boot of the latest Rawhide kernel
2.6.14-1.1743_FC5 (without acpi=off) and it worked. This might just be a lucky
shot, but I'll try it as my default kernel for the next couple of days, maybe an
upstream acpi change has fixed things.
Comment 10 John W. Linville 2005-12-09 14:01:25 EST
Do you have the latest BIOS available for your motherboard?  If not, please 
upgrade it.  Hopefully that will stabilize things for you. 
Barring that, it is often difficult to tell if something like this is a BIOS 
problem or a Linux ACPI problem.  I'm copying Len Brown (the Linux ACPI 
"dude") to see if he has any insight. 
Comment 11 Hans de Goede 2005-12-12 07:01:24 EST
2.6.14-1.1743_FC5, seems to be working a lot better, sofar only one failed
coldboot. My BIOS is indeed a bit ancient, I'll try upgrading it and keep you
Comment 12 Hans de Goede 2005-12-15 18:33:04 EST
I've upgraded my BIOS but that didn't help. But after some fiddling I have found
the real reason, this might not be a kernel bug att all but just a timing race
condition, which might be caused from userspace.

What I've done is dump my entire dmesg of a successfull boot and a failed boot
of the same kernel to 2 files and did a diff on them, which reveals the real
problem: I've got a via network interface integrated on my motherboard, but
since I have an old coax network here at home I still use my old trusty ne2k-pci
with the bnc connector. The problem is that it doesnot always get assigned the
same interface, on some boots its eth0 on others eth1 (and vica versa for the
via interface).

Now that the problem is clear, why does this happen and what can I do to try and
fix it?

Comment 13 Dave Jones 2005-12-15 20:18:57 EST
you should be able to bind an ethX name to a specific interface by using
HWADDR=00:11:22:33:44:55 in the /etc/sysconfig/networking/devices/ifcfg-ethX files

That should stop it jumping around.
Comment 14 Hans de Goede 2005-12-16 03:36:53 EST
So I sould replace/remove the DEVICE= line then?

Also this will work for me but this stil is a bug, modifying the scripts is not
a solution for technical savy users.
Comment 15 John W. Linville 2005-12-16 15:05:47 EST
DEVICE= stays.  The HWADDR= line is additional. 
Different kernel versions, BIOS updates, kernel command-line options, and 
probably other things can account for the order being different at different 
Can you provide a definite, reproducible means of reproducing the detection 
one way or the other?  If so, we might be able to narrow it down to a real 
Comment 16 Dave Jones 2005-12-16 15:49:25 EST
system-config-network also allows a 'bind to hardware' option that sets this.
Comment 17 Hans de Goede 2005-12-17 03:36:41 EST
Actually the problem is that with kernels > 2.6.13-1.1594_FC5.x86_64 I can't get
the detection order stable in anyway. Sometimes the ne2k-pci card becomes eth0,
other times eth1 .

Whos / whats task is it to load the modules? I've the feeling that the modules
are loaded in paralel and that this is timing related.
Comment 18 John W. Linville 2006-01-03 14:04:29 EST
Some modules will be loaded by rc.sysinit, others will be loaded on-demand as 
the hardware is accessed. 
Did you try adding the HWADDR= lines as mentioned in comment 13? 
Comment 19 Hans de Goede 2006-01-03 16:43:31 EST
Yes I did add the HWADDR= line as suggested and that fixes my problem. So,this
bug might be closed I say might because IMHO this behaviour should never happen,
the HWADDR= line is a hack in this case, its not like I'm swapping cards from
one slot to another, I'm only turning of the PC and turning it back on again,
and with recent kernels this causes inconsistent probing order which IMHO is _bad_ .
Comment 20 John W. Linville 2006-01-04 09:32:32 EST
I'm sorry that you don't like the HWADDR= option, but it is the best we have  
to offer.  I'm going to close this as WORKSFORME since you have a working 
solution.  Thanks! 
Comment 21 Hans de Goede 2006-01-04 09:43:07 EST
I won't reopen this since it indeed works for me, but can you please explain how
booting the same kernel twice, with nothing changed between the boots and still
getting a different probeorder is not a _bug_.
Comment 22 John W. Linville 2006-01-04 10:10:49 EST
There is no defined order for detection in the first place, so the fact that 
it changes is really just an annoyance.  The HWADDR= fixes that annoyance. 
The NIC drivers are modular.  Since you have NICs that are not covered by the 
same driver, it is the order in which the driver modules load AND _initialize_ 
that will determine which gets which name by default.  Any number of factors 
might influence the order of initialization even if they are always loaded in 
the same order.  Such factors include locking issues, event delays, and other 
code details stemming from differences between the two drivers. 

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