Bug 436580

Summary: Ralink RT2500 at wlan0 and eth0. But eth0=Realtek
Product: [Fedora] Fedora Reporter: Denis CHENU <shnoulle>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: brentrbrian, flokip, harald, jmoskovc, notting
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-14 15:42:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/etc/sysconfig/hwconf none

Description Denis CHENU 2008-03-08 01:13:00 UTC
Description of problem:
This problem appear after kernel update (2.6.24.3-12) on FC8, but it appear one
time too on F9-alpha.

I had 2 network card:
eth0 = Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 
wlan0 =  RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) 
(before the update)

After the update: i don't found my realtek at eth0, but i have eth0 and wlan0
for Ralink RT2500.
But the Mac adress for eth0 is the realtek mac adress.

I test to add a network card but after reboot, it appear like a ralink , not a
RT2500.

/etc/sysconfig/networking/ifcfg-eth0 seem OK.

Version-Release number of selected component (if applicable):
- kernel-2.6.24.3-12.fc8
- system-config-network-1.4.7-1.fc8

How reproducible:
Have one Ralink RT2500 and ... eth0 card ?

Steps to Reproduce:

Actual results:


Expected results:
eth0 

Additional info:

Comment 1 Jerry James 2008-03-09 03:40:59 UTC
I wonder if this bug is related to my problem.  I have a Realtek RTL-8169 (rev
10), but no wireless card or other network card.  With kernel 2.6.24.3-12.fc8, I
get no networking whatsoever.  "ifup eth0" produces a long pause followed by a
failed message.  The card works fine with kernel-2.6.23.15-137.fc8.


Comment 2 Jerry James 2008-03-11 20:47:02 UTC
If this is the same bug, here's some more info.  The output of ethtool is
identical on both kernels.  The card-related messages in /var/log/messages and
dmesg are identical on booting into both kernels.  Running "ifup eth0" results
in a long pause, followed by a message indicating that a ping from <ADDR> to
<GATEWAY> was attempted 4 times, but failed.  The interesting thing here is that
<ADDR> is the fixed address I instructed my DHCP server to give this box,
indicating that DHCP succeeded, and <GATEWAY> is the Linksys box that acts as
both gateway and DHCP server.  What could fail post-DHCP negotiation that would
not get logged to /var/log/messages or dmesg?

Comment 3 Harald Hoyer 2008-03-12 18:47:59 UTC
(In reply to comment #0)
> Description of problem:
> This problem appear after kernel update (2.6.24.3-12) on FC8, but it appear one
> time too on F9-alpha.
> 
> I had 2 network card:
> eth0 = Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 
> wlan0 =  RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) 
> (before the update)

try this
# rm /etc/udev/rules.d/70-persistent-net.rules
 and reboot.

Comment 4 Denis CHENU 2008-03-13 00:31:12 UTC
> try this
> # rm /etc/udev/rules.d/70-persistent-net.rules
>  and reboot.

little change on rules:
before reboot:
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:50:fc:4e:0c:aa", ATTR{type}=="1", NAME="eth0"

# PCI device 0x1814:0x0201 (rt2500pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:11:09:bf:99:8c", ATTR{type}=="1", NAME="wlan0"

After reboot
$ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x10ec:0x8139 (8139too) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:50:fc:4e:0c:aa", ATTR{type}=="1", NAME="eth0"

# PCI device 0x1814:0x0201 (rt2500pci) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:11:09:bf:99:8c", ATTR{type}=="1", NAME="wlan0"


Comment 5 Harald Hoyer 2008-03-13 16:03:40 UTC
what is in your /etc/sysconfig/networking/ifcfg-* files?

Comment 6 Denis CHENU 2008-03-14 07:18:40 UTC
Hello,

it's the old network-script, before update, then coment are OK, but in
system-config-network, still ralionk for the 2.

[Shnoulle@chenu ~]$ cat /etc/sysconfig/network-script/ifcfg-*
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:50:FC:4E:0C:AA
ONBOOT=no
TYPE=Ethernet
USERCTL=yes
IPV6INIT=no
PEERDNS=no
NM_CONTROLLED=yes
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback
TYPE=Wireless
DEVICE=wlan0
BOOTPROTO=dhcp
NETMASK=
DHCP_HOSTNAME=princ
IPADDR=
DOMAIN=none
USERCTL=yes
IPV6INIT=no
PEERDNS=no
ESSID=SHRBX
MODE=Managed
RATE=Auto
HWADDR=00:11:09:bf:99:8c
ONBOOT=no
CHANNEL=1
IPV6INIT=no
NM_CONTROLLED=yes
[Shnoulle@chenu ~]$ 



Comment 7 Harald Hoyer 2008-03-14 08:22:38 UTC
Does system-config-network-1.5.1 help?

If not yet on the servers, you can download it here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=42856

Comment 8 Denis CHENU 2008-03-15 10:30:13 UTC
On F8, with system-config-network-1.5.1.

I remove eth0 connexion. I add RTL on eth1. Reboot
I remove RT2500 eth0, rename RTL eth1 -> eth0. Reboot

At reboot, i had the same think than before. RT2500 for wlan0 and eth0.

BUT: i reinstall F9. Default network manager for F9(liveCD) is NetworkManager.

And for my ethernet connexion, NM say it's a wireless connexion. I had to make
some test on F9 (deactivate NM, test with System-config-network and manual
testing: maybe it's hal)

Thank you

Comment 9 Denis CHENU 2008-03-15 17:30:29 UTC
More information on F8:
<code>$ lspci -v
00:09.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)
        Subsystem: Micro-Star International Co., Ltd. Unknown device 6834
        Flags: bus master, slow devsel, latency 32, IRQ 17
        Memory at df000000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: rt2500pci
        Kernel modules: rt2500pci

00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Flags: bus master, medium devsel, latency 32, IRQ 16
        I/O ports at ec00 [size=256]
        Memory at df002000 (32-bit, non-prefetchable) [size=256]
        [virtual] Expansion ROM at 30000000 [disabled] [size=64K]
        Kernel driver in use: 8139too
        Kernel modules: 8139cp, 8139too
$ dmesg |grep rt2500pci
[root@chenu ~]# dmesg |grep rt2500
Registered led device: rt2500pci-phy0:radio
$ dmesg |grep 8139
[root@chenu ~]# dmesg |grep 8139
8139too Fast Ethernet driver 0.9.28
eth0: RealTek RTL8139 at 0xe088c000, 00:50:fc:4e:0c:aa, IRQ 16
eth0:  Identified 8139 chip type 'RTL-8139C'
8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)</code>

Comment 10 Denis CHENU 2008-03-16 03:05:15 UTC
Created attachment 298177 [details]
/etc/sysconfig/hwconf

Comment 11 Denis CHENU 2008-03-16 03:07:25 UTC
Comment on attachment 298177 [details]
/etc/sysconfig/hwconf

It's kuzdu, in part:

With 2.6.25-0.121.rc5.git4.fc9 and 2.6.24.3-12.fc8:
[Charlotte@chenu ~]$ system-config-network -vd
[3] Sun Mar 16 03:44:27 2008: Checking Desc:	       RaLink RT2500 802.11g
Cardbus/mini-PCI
Driver: 	rt2500pci
Device: 	eth0

[3] Sun Mar 16 03:44:27 2008: Error... kudzu != actual system state
[3] Sun Mar 16 03:44:27 2008: Checking Desc:	       Realtek Semiconductor
Co., Ltd. RTL-8139/8139C/8139C+
Driver: 	8139too
Device: 	eth1
-------------
With 2.6.23.14-115.fc8
[root@chenu ~]# system-config-network -vd
[3] Sun Mar 16 03:31:20 2008: Checking Desc:	       Realtek Semiconductor
Co., Ltd. RTL-8139/8139C/8139C+
Driver: 	8139too
Device: 	eth0

[3] Sun Mar 16 03:31:20 2008: Checking Desc:	       RaLink RT2500 802.11g
Cardbus/mini-PCI
Driver: 	rt2500
Device: 	wlan0

Comment 12 Denis CHENU 2008-03-16 03:09:11 UTC
Comment on attachment 298177 [details]
/etc/sysconfig/hwconf

It's kuzdu, in part:

With 2.6.25-0.121.rc5.git4.fc9 and 2.6.24.3-12.fc8:
[Charlotte@chenu ~]$ system-config-network -vd
[3] Sun Mar 16 03:44:27 2008: Checking Desc:	       RaLink RT2500 802.11g
Cardbus/mini-PCI
Driver: 	rt2500pci
Device: 	eth0

[3] Sun Mar 16 03:44:27 2008: Error... kudzu != actual system state
[3] Sun Mar 16 03:44:27 2008: Checking Desc:	       Realtek Semiconductor
Co., Ltd. RTL-8139/8139C/8139C+
Driver: 	8139too
Device: 	eth1
-------------
With 2.6.23.14-115.fc8
[root@chenu ~]# system-config-network -vd
[3] Sun Mar 16 03:31:20 2008: Checking Desc:	       Realtek Semiconductor
Co., Ltd. RTL-8139/8139C/8139C+
Driver: 	8139too
Device: 	eth0

[3] Sun Mar 16 03:31:20 2008: Checking Desc:	       RaLink RT2500 802.11g
Cardbus/mini-PCI
Driver: 	rt2500
Device: 	wlan0
-----------
(attachement:  /etc/sysconfig/hwconf of 2.6.24.3-12.fc8

Comment 13 Harald Hoyer 2008-03-16 08:11:06 UTC
ah :) I can reproduce this on my F8 now:

# kudzu -c NETWORK -p
..
device: eth0
driver: iwl3945
desc: "Intel Corporation PRO/Wireless 3945ABG Network Connection"
..
device: eth1
driver: e100
desc: "Intel Corporation PRO/100 VE Network Connection"
...

# ethtool -i eth0
driver: e100


Comment 14 Denis CHENU 2008-03-16 14:59:36 UTC
But:
[root@chenu ~]# kudzu -c NETWORK -p
-
class: NETWORK
bus: PCI
detached: 0
device: eth0
driver: rt2500pci
desc: "RaLink RT2500 802.11g Cardbus/mini-PCI"
........
-
class: NETWORK
bus: PCI
detached: 0
device: eth1
driver: 8139too
desc: "Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+"
....

But:
[root@chenu ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:FC:4E:0C:AA  
HWaddr is my RTL-8139

(sorry for the multi-comment before .... :-|)



Comment 15 Bill Nottingham 2008-03-17 15:36:07 UTC
The F-8 kernel needs CONFIG_SYSFS_DEPRECATED set.

Comment 16 Chuck Ebbert 2008-03-18 15:26:17 UTC
(In reply to comment #15)
> The F-8 kernel needs CONFIG_SYSFS_DEPRECATED set.

What changed ??

Comment 17 Bill Nottingham 2008-03-18 16:03:10 UTC
Nothing. We've *always* needed that for F8 and earlier.

Comment 18 Chuck Ebbert 2008-03-18 18:56:59 UTC
*** Bug 437698 has been marked as a duplicate of this bug. ***

Comment 19 Bug Zapper 2008-05-14 05:52:05 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 20 Brent R Brian 2009-02-14 17:27:09 UTC
This bug is a duplicate of 457441 which is presently ACTIVE

Comment 21 Bug Zapper 2009-06-09 23:42:49 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 22 Bug Zapper 2009-07-14 15:42:28 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.