Bug 11295 - eth0 and eth1 randomly fail and hang on boot.
Summary: eth0 and eth1 randomly fail and hang on boot.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 6.2
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-05-08 11:04 UTC by chris
Modified: 2014-03-17 02:13 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-08-07 05:48:09 UTC
Embargoed:


Attachments (Terms of Use)

Description chris 2000-05-08 11:04:27 UTC
I work for SplitInfinity networks and we install a large base
of RedHat machines every day.

Ever since we started using 6.2, we have noticed that on occasion
(actually pretty often) the systems hang on re-boot at the
Bringing up eth0 and eth1 lines at random. Sometimes its eth0, sometimes
its eth1.  We have experienced this on many different hardware configs
now.Both single and dual network cards as well as completely different
components.  Right now we use the 2.2.15 release kernel which we build
monolithic for our needs. We have seen the same problem with the kernel
supplied with the boxed set from RH as well though.

Any news on this? I see alot of people with the same problem.

I see this in my boot.log too:

This is from when it worked....... its like 30% of the time
it will hang on bringing up the eth's on boot, the rest of
the time its fine.  Oddly enough, if I keep re-booting and
cant get it up I can go into single user mode and
/etc/rc.d/init.d/network it, and it will come up just fine.

Once again, this time (in this log) it worked:

May  8 03:47:34 dike sysctl: net.ipv4.ip_forward = 0
May  8 03:47:34 dike sysctl: net.ipv4.conf.all.rp_filter = 1
May  8 03:47:34 dike sysctl: net.ipv4.ip_always_defrag = 0
May  8 03:47:34 dike sysctl: kernel.sysrq = 0
May  8 03:47:34 dike network: Setting network parameters succeeded
May  8 03:47:34 dike ifup: SIOCADDRT: Network is unreachable
May  8 03:47:34 dike network: Bringing up interface lo succeeded
May  8 03:47:35 dike network: Bringing up interface eth0 succeeded
May  8 03:47:35 dike ifup: ipcalc: ip address expected
May  8 03:47:35 dike last message repeated 2 times
May  8 03:47:35 dike ifup: broadcast: Unknown host
May  8 03:47:35 dike ifup: Usage: grep [OPTION]... PATTERN [FILE]...
May  8 03:47:35 dike ifup: Try `grep --help' for more information.
May  8 03:47:35 dike ifup: netmask: Unknown host
May  8 03:47:35 dike ifup: SIOCADDRT: Network is unreachable
May  8 03:47:35 dike network: Bringing up interface eth1 succeeded
May  8 03:47:35 dike random: Initializing random number generator succeeded
May  8 03:47:37 dike sshd: sshd startup succeeded

Now, lets see if I can get it to fail:
Nope, oddly enough I cant right now...... If I do, I will let you know.

Noticed something odd in the routes though:

Is there supposed to be 2 entries for 192.168.1.1 as default routes??


[root@dike /root]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
dike.splitinfin *               255.255.255.255 UH    0      0        0
eth0
192.168.1.0     *               255.255.255.0   U     0      0        0
eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         192.168.1.1     0.0.0.0         UG    0      0        0
eth0
default         192.168.1.1     0.0.0.0         UG    1      0        0
eth0
[root@dike /root]#

Oh, better add the glitter:
PIII600 processors on INTEL CA810E Motherboards with a LinkSys PCI 10/100
card and the Build on Board Intel Chipset Ethernet port.

Comment 1 Bill Nottingham 2000-08-07 05:48:07 UTC
What do your ifcfg files look like? It almost seems like
there's a syntax error somewhere.

Comment 2 Bill Nottingham 2001-01-30 00:53:36 UTC
the duplicate route will be fixed in 5.60-1; as for the hang on
boot, it *sounds* like it's the eepro100 'out-of-resources' problem.


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