Bug 177478 - airo driver enables wifiX but not ethX when first loaded
airo driver enables wifiX but not ethX when first loaded
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-10 18:14 EST by Brad Smith
Modified: 2015-01-04 17:24 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-05 08:35:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brad Smith 2006-01-10 18:14:07 EST
Description of problem:
Running kernel 2.6.14-1.1653_FC4, when I boot my thinkpad its aironet wifi
device is detected and the airo driver loaded. However, this only makes wifiX
(wifi0 on my system) available, not ethX (eth1 on my system). 

This causes a problem when "ifup eth1" is run. The is_available() function in
/etc/sysconfig/network-scripts/network-functions runs 'ip -o link' to determine
which device owns eth1's mac address. Since eth1 isn't in the list, it finds
wifi0 and tries to rename it to eth1, which doesn't work. 

The only solution I've found is to load and reload the airo module until,
eventually, eth1 shows up. It usually takes about three times. I had tried just
creating an ifcfg file for wifi0, but dhclient can't get a lease using that device.

How reproducible:
Always, at least for me.

Steps to Reproduce:
[brad@satsuki network-scripts]$ ip -o link
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue \    link/loopback
00:00:00:00:00:00 brd 00:00:00:00:00:00
5: sit0: <NOARP> mtu 1480 qdisc noop \    link/sit 0.0.0.0 brd 0.0.0.0
12: dev1292: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000\    link/ether
00:02:8a:a6:30:43 brd ff:ff:ff:ff:ff:ff
13: wifi0: <BROADCAST,MULTICAST> mtu 2312 qdisc noop qlen 100\   
link/ieee802.11 00:02:8a:a6:30:43 brd ff:ff:ff:ff:ff:ff
14: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000\   
link/ether 00:09:6b:cd:2b:87 brd ff:ff:ff:ff:ff:ff
[brad@satsuki network-scripts]$ sudo rmmod airo
[brad@satsuki network-scripts]$ sudo modprobe airo
... repeat as necessary ...
[brad@satsuki network-scripts]$ ip -o link
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue \    link/loopback
00:00:00:00:00:00 brd 00:00:00:00:00:00
5: sit0: <NOARP> mtu 1480 qdisc noop \    link/sit 0.0.0.0 brd 0.0.0.0
14: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000\   
link/ether 00:09:6b:cd:2b:87 brd ff:ff:ff:ff:ff:ff
15: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000\   
link/ether 00:02:8a:a6:30:43 brd ff:ff:ff:ff:ff:ff16: wifi0:
<BROADCAST,MULTICAST> mtu 2312 qdisc noop qlen 100\    link/ieee802.11
00:02:8a:a6:30:43 brd ff:ff:ff:ff:ff:ff
[brad@satsuki network-scripts]$ sudo ifup eth1
... at this point it should work ...
Comment 1 Dave Jones 2006-02-03 02:07:11 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
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_REPORTER 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.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 2 Brad Smith 2006-02-28 16:52:53 EST
This bug persists under kernel 2.6.15-1.1830_FC4
Comment 3 Dave Jones 2006-09-16 22:44:30 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 4 Dave Jones 2006-10-16 17:43:06 EDT
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.
Comment 5 Dave Jones 2006-11-24 17:14:24 EST
This bug has been mass-closed along with all other bugs that
have been in NEEDINFO state for several months.

Due to the large volume of inactive bugs in bugzilla, this
is the only method we have of cleaning out stale bug reports
where the reporter has disappeared.

If you can reproduce this bug after installing all the
current updates, please reopen this bug.

If you are not the reporter, you can add a comment requesting
it be reopened, and someone will get to it asap.

Thank you.
Comment 6 Jon Stanley 2008-02-05 08:35:22 EST
Closing since there was an error in previous mass-close and they remained in
NEEDINFO.

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