Bug 754183 - Intel Corporation Centrino Wireless-N 1030 BUG
Summary: Intel Corporation Centrino Wireless-N 1030 BUG
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 754181 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-15 16:19 UTC by Jorik
Modified: 2012-09-04 14:10 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-04 14:10:00 UTC
Type: ---


Attachments (Terms of Use)

Description Jorik 2011-11-15 16:19:06 UTC
Description of problem:
You can connect with this hardware, you receive an IP adress from the server, but when you start a browser, you cant connect or PING (in console) to any website or computer.

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

 Intel Corporation Centrino Wireless-N 1030 Rev 34 
 Firmware for Intel® PRO/Wireless 1000 B/G/N network adaptor
 iwl1000-firmware-39.31.5.1-1.fc16.noarch 
 

Steps to Reproduce:
1. Install FC16 fresh
2. Connect to any wireless network
3. Start a web browser
4. Connect to any site
  
Actual results:

No internet

Expected results:

Internet

Additional info:

FIX : echo options iwlagn swcrypto=1 >> /etc/modprobe.d/options.conf

http://pastebin.com/6mfUJUCj

Comment 1 Jorik 2011-11-15 16:20:54 UTC
Sorry for the double submit the first submit was a accident.

Greetings

Jorik

Comment 2 John W. Linville 2011-11-15 18:26:29 UTC
*** Bug 754181 has been marked as a duplicate of this bug. ***

Comment 3 Stanislaw Gruszka 2011-11-16 14:26:00 UTC
This is firmware issue or driver do something wrong that make firmware crash.

Is this regression, I mean did it work before on some older kernel?

Comment 4 Peter van Ieperen 2011-11-16 15:27:43 UTC
I think I have the same problem here on 2 different machines using iwlagn driver.

Start having this problem since upgrade to FC16. Laptop(Dell)/Netbook(Acer) worked fine with FC15.

Dell uses: Intel Corporation Centrino Advanced-N 6205 (rev 34)
Acer uses: Intel Corporation Centrino Wireless-N 100

The only difference here is connection is active for about 20 minutes, Then it silencely die.

I will try it with swcrypto=1.

If looking further in bugzilla, I think the following bug is also related somehow:
https://bugzilla.redhat.com/show_bug.cgi?id=753482

Comment 5 Jorik 2011-11-18 12:38:22 UTC
(In reply to comment #3)
> This is firmware issue or driver do something wrong that make firmware crash.
> 
> Is this regression, I mean did it work before on some older kernel?

[  194.715226] iwlagn 0000:0d:00.0: Tx aggregation enabled on ra = 00:0c:f6:b4:63:38 tid = 0
[  277.126468] iwlagn 0000:0d:00.0: Microcode SW error detected.  Restarting 0x2000000.
[  277.126474] iwlagn 0000:0d:00.0: Loaded firmware version: 17.168.5.2 build 35905


The issue is coming from the firmware

Comment 6 Stanislaw Gruszka 2011-11-18 13:08:20 UTC
(In reply to comment #5)
> The issue is coming from the firmware
These firmware crashes mostly happen because driver do not talk nicely to firmware. We have many examples when firmware does not crash with kernel n but crash with kernel n+1 . If that would be regression, I could look at kernel changlog and try to find commit that could possibly broke. Or if I would mange to recreate problem I could bisect it. Or eventually you could bisect it (but that need a bit of technical skills, quite lot of time and patience). If this is not regression - only Intel can fix that, but they usually do not fix iwlwifi issues happen to fedora users :-( What we could eventually do, is change to use swcrypto=1 by default on IWL 1000, but this is just workaround.

Comment 7 wey-yi.w.guy 2011-11-18 15:29:00 UTC
do you have the trace for  Microcode SW error detected? I will like to see what did Microcode reporting?

Thanks
Wey

Comment 8 Stanislaw Gruszka 2011-11-18 15:40:51 UTC
It is in: http://pastebin.com/6mfUJUCj

Comment 9 wey-yi.w.guy 2011-11-18 15:59:03 UTC
hmm, the log is for 6205 device and it is NMI watchdog timeout, which mean the uCode is not responding.

The last host command is for "REPLY_TX" and the uCode report stuck in BT-coex which does not make sense to me at all. 6205 is not an combo device.

17.168.5.2 is not the latest uCode, could we try 17.168.5.3 and see the problem still exist?

Thanks
Wey

Comment 10 John W. Linville 2012-07-19 14:38:59 UTC
Are you still able to recreate this with currently updated kernels?


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