Description of problem: Recently purchased an HP a1540n Desktop which has an onboard nVidia 10/100 EN NIC. If I selest DHCP, the port does not come up due to a failure in DHCP negotiation. If I connect with a static IP address, it works fine. Version-Release number of selected component (if applicable): FC5 gold DVD: kernel-2.6.15-1.2054-FC5smp Processor is an AMD Athlon 64x2 CPU with 2GB memory and 250GB SATA drive. How reproducible: Always Steps to Reproduce: 1. configure DHCP 2. boot FC5 i686 kernel 3. eth0 times out during boot Actual results: No broadband connectivity. Expected results: Connectivity Additional info: Static IP address works. lspci output: 00:10.0 PCI bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) /var/log/messages information: local host: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 local host: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 local host: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 local host: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18 local host: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 local host: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 dhclient: No DHCPOFFERS received The nVidia TAM suggests this may be the same as Bug 197797. Note that DHCP works with dual boot WindowsXP Media (NIC hardware works) as well as with a Linux static IP address.
Will append /var/log/dmesg and /var/log/messages per QE request. I can make hardware available in Red Hat Raleigh if it will help Fedora Engineering.
Appending /var/log/messages, /var/log/dmesg and "lspci -vv" output. NOTE: STATIC ADDRESS APPEARS TO WORK [service network restart -> OK] BUT DNS IS STILL NOT RESOLVING NAMES. LOADING THE DNS ADDRESS DOES NOT HELP AND PUTTING A PHYSICAL IP ADDRESS IN A FIREFOX BROWSER STILL DOES NOT FIND THE PAGE. So I don't think the static IP address is working much better than DHCP. lspci -vv output: 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) Subsystem: Hewlett-Packard Company Unknown device 2a34 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (250ns min, 5000ns max) Interrupt: pin A routed to IRQ 18 Region 0: Memory at fe02b000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at f200 [size=8] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable+ DSel=0 DScale=0 PME- My workaround appears to go buy a $10 10/100 EN NIC Linux does support.
Created attachment 135200 [details] lspci -vv output
Created attachment 135201 [details] /var/log/messages
Created attachment 135202 [details] /var/log/dmesg
Reassigning to correct owner, kernel-maint.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
(this is a mass-close to kernel bugs in NEEDINFO state) As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. If you believe that this bug was closed in error, please feel free to reopen this bug.