Bug 40394 - Boot hangs starting eth0 with LNE100TX v4 on Redhat v7.1
Boot hangs starting eth0 with LNE100TX v4 on Redhat v7.1
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-13 11:12 EDT by Scott Duns
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-06 08:33:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of /proc/pci (2.21 KB, text/plain)
2001-05-14 19:26 EDT, Scott Duns
no flags Details

  None (edit)
Description Scott Duns 2001-05-13 11:12:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Description of problem:
i686 with pci LNE100TX v4 NIC hangs at eth0 start on boot or when 
accessing network if not DHCP.  Using driver from distribution.  
Reproducible simply by installing normally and running first boot if using 
DHCP.

How reproducible:
Always

Steps to Reproduce:
1.Install default network configuration - DHCP
2.Boot
3.
	

Actual Results:  Boot hangs at eth0 start

Expected Results:  OK and communicates properly

Additional info:

I was able to boot with a manual IP address after setting my network to 
manual addresses as well.  At one point I was able to ping out to my other 
PC and the router, but the network address had to be set to 192.168.0.254 
instead of 192.168.0.0 and I was unable to get to DNS over the gateway of 
192.168.0.1 which works fine from Windows.  If manual addressing is set to 
a network of 192.168.0.0, I still get the hang when I first attempt to 
access the network.
Comment 1 Scott Duns 2001-05-13 14:42:45 EDT
I found I could get past this problem by moving the NIC to PCI slot 3 from PCI
slot 4 where it shared IRQ 10 with the USB.  It shares IRQ 10 with the sound
card now, but I haven't yet gotten the sound card to work.  When I do get a
working driver for it, I may get the conflict again.  Why won't the driver share
to IRQ as Windows 98 was?
Comment 2 Arjan van de Ven 2001-05-13 16:11:30 EDT
Virtually all linux drivers share irqs. 
Can you tell me what kind of machine this is (single CPU, which one etc)
Also, the output of "lspci -v" would be very helpful.
Comment 3 Scott Duns 2001-05-14 19:26:12 EDT
Created attachment 18332 [details]
output of /proc/pci
Comment 4 Scott Duns 2001-05-15 22:15:18 EDT
Did you look at attached /proc/pci listing?
Comment 5 Arjan van de Ven 2001-05-16 04:14:26 EDT
Yes, and there was nothing weird or abnormal I could spot. I've seen
more bugs where the USB code sometimes refuses to share interrupts.
Is your keyboard a USB keyboard by chance ?
Comment 6 Arjan van de Ven 2001-05-16 04:14:39 EDT
Yes, and there was nothing weird or abnormal I could spot. I've seen
more bugs where the USB code sometimes refuses to share interrupts.
Is your keyboard a USB keyboard by chance ?
Comment 7 Alan Cox 2003-06-06 08:33:33 EDT
No reply in two years 

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