Created attachment 417322 [details]
dmesg (gz)

Created attachment 417323 [details]
/var/log/messages (gz)

Created attachment 417325 [details]
lsusb, lspci, lspci -n

FWIW, tried fedora 13 live usb stick, and wired networking works automatically

The tg3 driver seems to enumerate the 5906 in all cases just fine.

In the messages file, I see :

May 27 19:15:59 netkaie NetworkManager[9716]:    ifcfg-rh: Ignoring connection 'System eth0' and its device because NM_CONTROLLED was false.

That's probably why the Network Manager doesn't see it.

Does the interface show up with 'ifconfig -a'?  If so, that just means that the network scripts didn't automatically configure the device (and you wouldn't see the device with the normal 'ifconfig' command).

(In reply to comment #6)
> The tg3 driver seems to enumerate the 5906 in all cases just fine.

Does this mean you're sure it's not a kernel bug?


> In the messages file, I see :
> May 27 19:15:59 netkaie NetworkManager[9716]:    ifcfg-rh: Ignoring connection
> 'System eth0' and its device because NM_CONTROLLED was false.


Yes, the attached /var/log/messages contains that line. Testing again today, however, I no longer get this line.

This is probably because I no longer have the file /etc/sysconfig/network-scripts/ifcfg-eth0 . Why? Because my earlier test was done using a full installation. The hardware has now received a permanent Fedora installation (which works fine).

So, in order to continue with testing this issue, I boot RHEL from a USB live stick (which probably explains why I no longer have that ifcfg-eth0 file).


> That's probably why the Network Manager doesn't see it.

Not sure whether your theory is right, because I no longer get a message saying NM_CONTROLLED is false, and it still doesn't work. 

However, maybe the message is simply no longer been shonw, because I don't have a ifcfg-eth0 file?

Do you know which software module is responsible for setting it to the right value? Maybe that same component still sets it to the "not controlled" state?


> Does the interface show up with 'ifconfig -a'?  

In the new environment (same hardware, booted from live stick), both "ifconfig" and "ifconfig -a" do list eth0 (but NetworkManager still doesn't see it).


> If so, that just means that the
> network scripts didn't automatically configure the device (and you wouldn't see
> the device with the normal 'ifconfig' command).    


If you're convinced this isn't a kernel issue, we should assign this bug to the NetworkManager component.

So, since ifconfig shows eth0, can you get an ip address?

I assume Matt thought it wasn't a driver issue because there were no tg3 messages in dmesg etc. I) noticed that too but I didn't have access to a system with a 5906M to check it out. (But thanks Matt for the info.)

Once you get RHEL6 installed, would it be possible to access this system to see what the config files look like?

I'm confused, because it works now as expected.

To reiterate:

- installing RHEL6.0-20100526.2-Workstation-i386-DVD1.iso
  to harddisk
  => broken as described in the initial comments (up to comment 4)

  (I'm sure the network cable was plugged in that old experiment,
   because I was able to get a connection after I used 
   a manual ifconfig, as stated in comment 0)


- the experiments I did today (comment 7) were done with 
  the same code snapshot, a live iso
  RHEL6.0-20100526.2-Client-i386-Live.iso

  BUT => today the network cable was not plugged in

  (I simply didn't expect it to work, given I was still using a snapshot from
   the same day.)


- now I booted the live version with ethernet cable plugged in,
  and ethernet works just fine!


It seems unlikely that there is a difference between install-to-disk and boot-live-iso, but I'm tempted to install to hard disk again (which unfortunately will involve opening the notebook and installing a different harddisk).

Progress:

I installed to harddisk (again).

File
  /etc/sysconfig/network-scripts/ifcfg-eth0
contains 
  NM_CONTROLLED=no

As soon as I edit the file and change it to
  NM_CONTROLLED=yes
network-manager immediately starts up the ethernet connection.

Which software produced the incorrect file ifcfg-eth0 ?
Anaconda?

FWIW, during setup, I didn't touch any of the network related buttons (used defaults).

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Ok, so here's the problem...

Anaconda writes out ifcfg files with NM_CONTROLLED=no to make NM ignore the interface until you actually configure networking, at which point we assume that you actually want to enable networking.  That's all fine.

But if you install from the DVD and don't configure networking in the installer, you're left with NM_CONTROLLED=no in the ifcfg files after the installation is done. That's not fine.

I'd suggest for anaconda that either:

1) only use NM_CONTROLLED=no for interface configurations that NM doesn't yet support, if any, and instead set ONBOOT=no so that NM does not bring the device up automatically until needed

2) set NM_CONTROLLED=yes for all NM supported configurations before the installer exits, so that devices are managed by NM after the installation is done

(In reply to comment #13)

> I'd suggest for anaconda that either:
> 
> 1) only use NM_CONTROLLED=no for interface configurations that NM doesn't yet
> support, if any, and instead set ONBOOT=no so that NM does not bring the device
> up automatically until needed
> 
> 2) set NM_CONTROLLED=yes for all NM supported configurations before the
> installer exits, so that devices are managed by NM after the installation is
> done    

Yes, I am working on 1) (2) would silently change what user could have selected in "Configure Network").

*** This bug has been marked as a duplicate of bug 606745 ***