Bug 436577 - Dell XPS M1330 w/Intel 4965 can't connect to wireless network
Dell XPS M1330 w/Intel 4965 can't connect to wireless network
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i386 Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
: 436706 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-07 19:14 EST by Mike Iglesias
Modified: 2008-03-13 11:18 EDT (History)
2 users (show)

See Also:
Fixed In Version: 2.6.24.3-28.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-13 11:18:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mike Iglesias 2008-03-07 19:14:57 EST
Description of problem:

I have a new Dell XPS M1330 with an Intel 4965 wireless card.  I'm not using
NetworkManager; I have the ifcfg-wlan0 file setup to connect to a local wireless
network.

When the system boots, it can't get an IP from the DHCP server.  Looking at the
DHCP logs, it tries to get an address it was using at my home which is not valid
at work.  The DHCP server NAKs the request, and the laptop is never heard from
again.

Sometimes it will connect if I do a "/sbin/ifup wlan0" after the system has
booted.  It seems to be hit or miss.

Looking at dmesg output, I see this:

iwl4965: Tunable channels: 11 802.11bg, 13 802.11a channels
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:0e:38:3f:14:40
wlan0: RX authentication from 00:0e:38:3f:14:40 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:0e:38:3f:14:40
wlan0: RX AssocResp from 00:0e:38:3f:14:40 (capab=0x421 status=0 aid=85)
wlan0: associated
wlan0: CTS protection enabled (BSSID=00:0e:38:3f:14:40)
wlan0: switched to long barker preamble (BSSID=00:0e:38:3f:14:40)
wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0
wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0
wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30
wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
WARNING: at net/mac80211/rx.c:1695 __ieee80211_rx_handle_packet() (Tainted: P   
    )
 [<f89c4687>] __ieee80211_rx_handle_packet+0xa7/0x9c4 [mac80211]
 [<c042535f>] inc_nr_running+0x13/0x26
 [<c0427c65>] try_to_wake_up+0x2ef/0x2f9
 [<f9809417>] _nv004178rm+0x19/0x1d [nvidia]
 [<f89c5c7f>] __ieee80211_rx+0x48d/0x4e8 [mac80211]
 [<f8a152df>] iwl4965_rx_queue_restock+0xad/0x10a [iwl4965]
 [<f89b7c7a>] ieee80211_tasklet_handler+0x3f/0xb9 [mac80211]
 [<c05be20a>] net_tx_action+0x73/0xf1
 [<c0431eea>] tasklet_action+0x58/0xb8
 [<c0431e02>] __do_softirq+0x66/0xd3
 [<c04073f9>] do_softirq+0x6c/0xce
 [<c04446df>] tick_do_update_jiffies64+0x93/0xa8
 [<c044019b>] ktime_get+0xf/0x2b
 [<c045bb1b>] handle_edge_irq+0x0/0xfc
 [<c0431cc5>] irq_exit+0x38/0x6b
 [<c04074fa>] do_IRQ+0x9f/0xb9
 [<c05264ce>] acpi_hw_register_read+0xf1/0x156
 [<c0405b6f>] common_interrupt+0x23/0x28
 [<c053850a>] acpi_idle_enter_bm+0x279/0x2ee
 [<c05a2d4d>] cpuidle_idle_call+0x5c/0x7f
 [<c05a2cf1>] cpuidle_idle_call+0x0/0x7f
 [<c040340b>] cpu_idle+0xab/0xcc
 =======================
ACPI: PCI interrupt for device 0000:0c:00.0 disabled
ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
ADDRCONF(NETDEV_UP): wlan0: link is not ready

I removed the "-q" from ifup-eth so that dhclient would be more verbose in it's
output, and got this in /var/log/messages:

Mar  7 15:54:39 localhost dhclient: wmaster0: unknown hardware address type 801
Mar  7 15:54:39 localhost dhclient: wmaster0: unknown hardware address type 801
Mar  7 15:54:39 localhost dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port
 67
Mar  7 15:54:47 localhost dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port
 67
Mar  7 15:54:47 localhost dhclient: DHCPNAK from 128.200.124.65
Mar  7 15:54:49 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 5
Mar  7 15:54:49 localhost dhclient: send_packet: Network is down
Mar  7 15:54:54 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 14
Mar  7 15:55:08 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 14
Mar  7 15:55:22 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 13
Mar  7 15:55:35 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 13
Mar  7 15:55:48 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 2
Mar  7 15:55:50 localhost dhclient: No DHCPOFFERS received.
Mar  7 15:56:09 localhost dhclient: wmaster0: unknown hardware address type 801
Mar  7 15:56:09 localhost dhclient: wmaster0: unknown hardware address type 801
Mar  7 15:56:09 localhost dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port
 67
Mar  7 15:56:15 localhost dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port
 67
Mar  7 15:56:15 localhost dhclient: DHCPNAK from 128.200.124.65
Mar  7 15:56:17 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 5
Mar  7 15:56:17 localhost dhclient: send_packet: Network is down
Mar  7 15:56:22 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 12
Mar  7 15:56:34 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 17
Mar  7 15:56:51 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 10
Mar  7 15:57:01 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 12
Mar  7 15:57:13 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 por
t 67 interval 5
Mar  7 15:57:18 localhost dhclient: No DHCPOFFERS received.

It looks to me like the error in dmesg is causing the link to drop on the 4965
wireless card, and subsequent DHCP traffic never makes it out to the DHCP server.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Mike Iglesias 2008-03-07 19:16:13 EST
Forgot to mention I'm running the 2.6.23.15-137.fc8 kernel on this laptop, with
all the patches as of a few days ago when I installed it.
Comment 2 Dave Jones 2008-03-07 19:49:05 EST
please try to reproduce this without the nvidia module loaded. the backtrace
shows some nvidia symbols, which looks really strange in that codepath.
It'd help a lot just to rule that out if you could post an untainted trace.

Thanks.
Comment 3 Mike Iglesias 2008-03-07 20:12:09 EST
Here you go:

iwl4965: Tunable channels: 11 802.11bg, 13 802.11a channels
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:0e:38:3f:14:40
wlan0: RX authentication from 00:0e:38:3f:14:40 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:0e:38:3f:14:40
wlan0: RX AssocResp from 00:0e:38:3f:14:40 (capab=0x421 status=0 aid=105)
wlan0: associated
wlan0: CTS protection enabled (BSSID=00:0e:38:3f:14:40)
wlan0: switched to long barker preamble (BSSID=00:0e:38:3f:14:40)
wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0
wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0
wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30
wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
WARNING: at net/mac80211/rx.c:1695 __ieee80211_rx_handle_packet() (Not tainted)
 [<f8981687>] __ieee80211_rx_handle_packet+0xa7/0x9c4 [mac80211]
 [<f8a264da>] iwl4965_rx_reply_rx+0xa08/0xa38 [iwl4965]
 [<c041ac3d>] native_smp_send_reschedule+0x5f/0x64
 [<c0425747>] resched_task+0x55/0x58
 [<c0427c65>] try_to_wake_up+0x2ef/0x2f9
 [<f8982c7f>] __ieee80211_rx+0x48d/0x4e8 [mac80211]
 [<f8a111a3>] iwl4965_rx_queue_update_write_ptr+0x3f1/0x3fb [iwl4965]
 [<f8a13321>] iwl4965_rx_queue_restock+0xef/0x10a [iwl4965]
 [<f8974c7a>] ieee80211_tasklet_handler+0x3f/0xb9 [mac80211]
 [<c0431eea>] tasklet_action+0x58/0xb8
 [<c0431e02>] __do_softirq+0x66/0xd3
 [<c04073f9>] do_softirq+0x6c/0xce
 [<c04446df>] tick_do_update_jiffies64+0x93/0xa8
 [<c045bb1b>] handle_edge_irq+0x0/0xfc
 [<c0431cc5>] irq_exit+0x38/0x6b
 [<c04074fa>] do_IRQ+0x9f/0xb9
 [<c05264ce>] acpi_hw_register_read+0xf1/0x156
 [<c0405b6f>] common_interrupt+0x23/0x28
 [<c053850a>] acpi_idle_enter_bm+0x279/0x2ee
 [<c05a2d4d>] cpuidle_idle_call+0x5c/0x7f
 [<c05a2cf1>] cpuidle_idle_call+0x0/0x7f
 [<c040340b>] cpu_idle+0xab/0xcc
 [<c0740a6c>] start_kernel+0x32c/0x334
 [<c0740177>] unknown_bootoption+0x0/0x195
 =======================
ACPI: PCI interrupt for device 0000:0c:00.0 disabled
ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
ADDRCONF(NETDEV_UP): wlan0: link is not ready
Comment 4 John W. Linville 2008-03-10 14:33:10 EDT
*** Bug 436706 has been marked as a duplicate of this bug. ***
Comment 5 Mike Iglesias 2008-03-12 13:54:59 EDT
I booted the laptop with koji kernel 2.6.24.3-28.fc8 today, and it's working
better.  The first time I booted it, it associated with an AP and got an IP
address, but after that would not pass traffic.  Every reboot since then has
worked, including one after leaving the laptop off for over an hour.  I haven't
done much testing so I'm not saying it's fixed yet, just working better.

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