Bug 556990 - kernel panic iwlagn
Summary: kernel panic iwlagn
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Stanislaw Gruszka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-20 01:16 UTC by Milos Jakubicek
Modified: 2010-12-04 00:07 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-12-04 00:07:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages (864.95 KB, text/plain)
2010-01-21 23:05 UTC, Milos Jakubicek
no flags Details
new /var/log/messages (729.12 KB, text/plain)
2010-01-28 17:54 UTC, Milos Jakubicek
no flags Details
abrt kerneloops (1.18 KB, application/x-bzip2)
2010-01-28 17:57 UTC, Milos Jakubicek
no flags Details
/var/log/messages (with debugging output, without swcrypto) (945.74 KB, text/plain)
2010-02-02 19:34 UTC, Milos Jakubicek
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Intel Wireless Bugzilla 2159 0 None None None Never

Description Milos Jakubicek 2010-01-20 01:16:54 UTC
Description of problem:

After some time of using wireless, I *always* get kernel panic (dark screen, no console output, caps-lock flashing), in my /var/log/messages I *always* see:

"iwlagn 0000:02:00.0: Microcode SW error detected.  Restarting 0x12000000."

as the last message.

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

kernel-2.6.31.9-174.fc12.x86_64

I don't know how to get more logs -- is there any way how to get e.g. backtrace from the kernel panic?

My smolt profile:
http://www.smolts.org/client/show/pub_2079d6ed-4c12-4609-9d46-443e490a1010

Comment 1 Stanislaw Gruszka 2010-01-20 15:53:08 UTC
There are few options to get logs (kdump, netconsole), no one is ideal. For netconsole you need another computer to log data. Kdump may not work.

Netconsole info is here:
https://fedoraproject.org/wiki/Netconsole

Ideally if you will be able get kdump, then I could analyze memory and see what's going on in more details. Here is, a bit outdated info about kdump: http://fedoraproject.org/wiki/Kernel/kdump
There is graphical tool to setup kdump, called system-config-kdump (but there are few bug reports that it not work anymore in F12 :(, however you can give it a try).

There is also options to switch to pure terminal (alt+ctrl+F1 in example) and get info by foto camera :)

Comment 2 Stanislaw Gruszka 2010-01-20 16:00:29 UTC
Oh, a few more things. You can give new kernel a try by 

yum --enablerepo="rawhide" update kernel

This is firmware bug since we get this Microcode SW error. Bug need to be reported to intel to be fixed in firmware as well. But first lets try to stop kernel crash when it happens.

Comment 3 Milos Jakubicek 2010-01-21 17:49:45 UTC
I've tried with the rawhide kernel, the behaviour is the same, but now the error is:

Jan 21 18:25:36 localhost kernel: iwlagn 0000:02:00.0: iwl_tx_agg_start on ra = 00:1f:5b:87:06:7d tid = 0

Comment 4 Milos Jakubicek 2010-01-21 23:03:26 UTC
I should have added that it doesn't panic anymore, but oopses, but abrt is not able to get the oops -- attaching full /var/log/messages

Comment 5 Milos Jakubicek 2010-01-21 23:05:43 UTC
Created attachment 386046 [details]
/var/log/messages

Comment 6 Stanislaw Gruszka 2010-01-22 09:19:35 UTC
Some excerpts from logs:

Jan 20 01:55:08 localhost kernel: WARNING: at drivers/pci/dmar.c:598 check_zero_address+0x96/0x19b() (Not tainted)
Jan 20 01:55:08 localhost kernel: Hardware name: Aspire 1810TZ
Jan 20 01:55:08 localhost kernel: Your BIOS is broken; DMAR reported at address zero!
Jan 20 01:55:08 localhost kernel: BIOS vendor: INSYDE; Ver: v1.3303; Product Version: v1.3303
Jan 20 01:55:08 localhost kernel: Modules linked in:
Jan 20 01:55:08 localhost kernel: Pid: 0, comm: swapper Not tainted 2.6.31.9-174.fc12.x86_64 #1
Jan 20 01:55:08 localhost kernel: Call Trace:
Jan 20 01:55:08 localhost kernel: [<ffffffff81051710>] warn_slowpath_common+0x84/0x9c
Jan 20 01:55:08 localhost kernel: [<ffffffff81423853>] ? _etext+0x0/0x1
Jan 20 01:55:08 localhost kernel: [<ffffffff8105177f>] warn_slowpath_fmt+0x41/0x43
Jan 20 01:55:08 localhost kernel: [<ffffffff8173e807>] check_zero_address+0x96/0x19b
Jan 20 01:55:08 localhost kernel: [<ffffffff8126206d>] ? acpi_tb_verify_table+0x57/0x5c
Jan 20 01:55:08 localhost kernel: [<ffffffff812616cb>] ? acpi_get_table_with_size+0x5a/0xb4
Jan 20 01:55:08 localhost kernel: [<ffffffff81423853>] ? _etext+0x0/0x1
Jan 20 01:55:08 localhost kernel: [<ffffffff8173e91e>] detect_intel_iommu+0x12/0x8c
Jan 20 01:55:08 localhost kernel: [<ffffffff8171dbc3>] pci_iommu_alloc+0x5e/0x6c
Jan 20 01:55:08 localhost kernel: [<ffffffff8172d1b1>] mem_init+0x19/0x161
Jan 20 01:55:08 localhost kernel: [<ffffffff81716be3>] start_kernel+0x20b/0x3fa
Jan 20 01:55:08 localhost kernel: [<ffffffff817162a1>] x86_64_start_reservations+0xac/0xb0
Jan 20 01:55:08 localhost kernel: [<ffffffff8171639d>] x86_64_start_kernel+0xf8/0x107
Jan 20 01:55:08 localhost kernel: ---[ end trace a7919e7f17c0a725 ]---
Jan 20 01:55:08 localhost kernel: PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Jan 20 01:55:08 localhost kernel: Placing 64MB software IO TLB between ffff880020000000 - ffff880024000000
Jan 20 01:55:08 localhost kernel: software IO TLB at phys 0x20000000 - 0x24000000
Jan 20 01:55:08 localhost kernel: Memory: 3949008k/5242880k available (4238k kernel code, 1147988k absent, 145884k reserved, 2924k data, 1324k init)
Jan 20 01:55:08 localhost kernel: SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1

[snip]

Jan 21 04:55:09 localhost avahi-daemon[1272]: Withdrawing address record for 10.0.1.11 on wlan0.
Jan 21 04:55:09 localhost avahi-daemon[1272]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.0.1.11.
Jan 21 04:55:09 localhost kernel: iwlagn 0000:02:00.0: Stopping AGG while state not ON or starting
Jan 21 04:55:09 localhost kernel: iwlagn 0000:02:00.0: queue number out of range: 0, must be 10 to 19
Jan 21 04:55:09 localhost kernel: ------------[ cut here ]------------
Jan 21 04:55:09 localhost kernel: WARNING: at net/mac80211/agg-tx.c:150 ___ieee80211_stop_tx_ba_session+0x7b/0x80 [mac80211]()
Jan 21 04:55:09 localhost kernel: Hardware name: Aspire 1810TZ
Jan 21 04:55:09 localhost kernel: Modules linked in: vfat fat cryptd aes_x86_64 aes_generic hidp fuse rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand acpi_cpufreq freq_table ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec arc4 snd_hwdep ecb iwlagn snd_seq snd_seq_device snd_pcm iwlcore uvcvideo videodev btusb snd_timer v4l1_compat acer_wmi v4l2_compat_ioctl32 bluetooth mac80211 snd atl1c wmi soundcore iTCO_wdt joydev serio_raw cfg80211 i2c_i801 snd_page_alloc iTCO_vendor_support rfkill dm_multipath usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode]
Jan 21 04:55:09 localhost kernel: Pid: 1492, comm: wpa_supplicant Tainted: G        W  2.6.32.3-21.fc13.x86_64 #1
Jan 21 04:55:09 localhost kernel: Call Trace:
Jan 21 04:55:09 localhost kernel: [<ffffffff81059021>] warn_slowpath_common+0x7c/0x94
Jan 21 04:55:09 localhost kernel: [<ffffffff8105904d>] warn_slowpath_null+0x14/0x16
Jan 21 04:55:09 localhost kernel: [<ffffffffa0134e65>] ___ieee80211_stop_tx_ba_session+0x7b/0x80 [mac80211]
Jan 21 04:55:09 localhost kernel: [<ffffffffa0134f8a>] __ieee80211_stop_tx_ba_session+0x4a/0x63 [mac80211]
Jan 21 04:55:09 localhost kernel: [<ffffffffa0134830>] ieee80211_sta_tear_down_BA_sessions+0x20/0x3d [mac80211]
Jan 21 04:55:09 localhost kernel: [<ffffffffa0137416>] ieee80211_set_disassoc+0x104/0x1dc [mac80211]
Jan 21 04:55:09 localhost kernel: [<ffffffffa01379e2>] ieee80211_mgd_deauth+0x53/0xff [mac80211]
Jan 21 04:55:09 localhost kernel: [<ffffffff814816de>] ? __mutex_lock_common+0x356/0x37b
Jan 21 04:55:09 localhost kernel: [<ffffffffa00f4920>] ? wdev_lock+0x14/0x16 [cfg80211]
Jan 21 04:55:09 localhost kernel: [<ffffffffa013d60f>] ieee80211_deauth+0x1e/0x20 [mac80211]
Jan 21 04:55:09 localhost kernel: [<ffffffffa00ef0e8>] __cfg80211_mlme_deauth+0x130/0x13f [cfg80211]
Jan 21 04:55:09 localhost kernel: [<ffffffffa00f4920>] ? wdev_lock+0x14/0x16 [cfg80211]
Jan 21 04:55:09 localhost kernel: [<ffffffff81089c8e>] ? mark_lock+0x2d/0x22d
Jan 21 04:55:09 localhost kernel: [<ffffffffa00f25c4>] __cfg80211_disconnect+0x111/0x189 [cfg80211]
Jan 21 04:55:09 localhost kernel: [<ffffffffa00f49a8>] cfg80211_wext_siwmlme+0x72/0x92 [cfg80211]
Jan 21 04:55:09 localhost kernel: [<ffffffff813e6c09>] ? rtnl_lock+0x17/0x19
Jan 21 04:55:09 localhost kernel: [<ffffffff814631b6>] ioctl_standard_iw_point+0x1a8/0x24f
Jan 21 04:55:09 localhost avahi-daemon[1272]: Interface wlan0.IPv4 no longer relevant for mDNS.
Jan 21 04:55:09 localhost kernel: [<ffffffffa00f4936>] ? cfg80211_wext_siwmlme+0x0/0x92 [cfg80211]
Jan 21 04:55:09 localhost kernel: [<ffffffff814632ef>] ioctl_standard_call+0x92/0xac
Jan 21 04:55:09 localhost kernel: [<ffffffff813da8cc>] ? __dev_get_by_name+0x39/0x54
Jan 21 04:55:09 localhost kernel: [<ffffffff8146325d>] ? ioctl_standard_call+0x0/0xac
Jan 21 04:55:09 localhost kernel: [<ffffffff81462f92>] ? ioctl_private_call+0x0/0x7c
Jan 21 04:55:09 localhost kernel: [<ffffffff81462be1>] wext_ioctl_dispatch+0xe1/0x159
Jan 21 04:55:09 localhost kernel: [<ffffffff81462d6c>] wext_handle_ioctl+0x3e/0x75
Jan 21 04:55:09 localhost kernel: [<ffffffff813df774>] dev_ioctl+0x63a/0x677
Jan 21 04:55:09 localhost kernel: [<ffffffff812069e7>] ? inode_has_perm+0xaa/0xce
Jan 21 04:55:09 localhost kernel: [<ffffffff813cc367>] sock_ioctl+0x21c/0x22b
Jan 21 04:55:09 localhost kernel: [<ffffffff8113bc21>] vfs_ioctl+0x22/0x87
Jan 21 04:55:09 localhost kernel: [<ffffffff8113c18a>] do_vfs_ioctl+0x488/0x4ce
Jan 21 04:55:09 localhost kernel: [<ffffffff8113c226>] sys_ioctl+0x56/0x79
Jan 21 04:55:09 localhost kernel: [<ffffffff81458275>] ? unix_stream_recvmsg+0x1ab/0x55d
Jan 21 04:55:09 localhost kernel: [<ffffffff81011cb2>] system_call_fastpath+0x16/0x1b
Jan 21 04:55:09 localhost kernel: ---[ end trace a7919e7f17c0a727 ]---
Jan 21 04:55:09 localhost kernel: iwlagn 0000:02:00.0: Stopping AGG while state not ON or starting
Jan 21 04:55:09 localhost NetworkManager: <info>  (wlan0): cleaning up...
Jan 21 04:55:09 localhost NetworkManager: <info>  (wlan0): taking down device.
Jan 21 04:55:10 localhost avahi-daemon[1272]: Withdrawing address record for fe80::21e:64ff:fe22:5f72 on wlan0.

[snip]

Jan 21 07:31:25 localhost ntpd[1497]: Listening on interface #7 wlan0, 10.0.1.11#123 Enabled
Jan 21 07:32:01 localhost kernel: iwlagn 0000:02:00.0: iwl_tx_agg_start on ra = 00:1f:5b:87:06:7d tid = 0
Jan 21 07:32:10 localhost kernel: input: Trust Mouse 15352 as /devices/pci0000:00/0000:00:1d.2/usb6/6-2/6-2:1.0/bluetooth/hci0/hci0:11/input12
Jan 21 07:32:10 localhost kernel: generic-bluetooth 0005:0A5C:0001.0003: input,hidraw0: BLUETOOTH HID v1.29 Mouse [Trust Mouse 15352] on 0C:60:76:B5:AA:17
Jan 21 07:32:31 localhost kernel: btusb_intr_complete: hci0 urb ffff880025358210 failed to resubmit (1)
Jan 21 07:32:31 localhost kernel: btusb_bulk_complete: hci0 urb ffff880025358e70 failed to resubmit (1)
Jan 21 07:32:31 localhost kernel: btusb_bulk_complete: hci0 urb ffff880025358a50 failed to resubmit (1)
Jan 21 07:32:46 localhost kernel: btusb_intr_complete: hci0 urb ffff88007904def0 failed to resubmit (1)
Jan 21 07:32:46 localhost kernel: btusb_bulk_complete: hci0 urb ffff88007904c210 failed to resubmit (1)
Jan 21 07:32:46 localhost kernel: btusb_bulk_complete: hci0 urb ffff88007904c108 failed to resubmit (1)

Comment 9 Stanislaw Gruszka 2010-01-22 13:32:27 UTC
We have Microcode error before linux kernel warning.

>Jan 21 04:01:22 localhost kernel: iwlagn 0000:02:00.0: Microcode SW error detected.  Restarting 0x2000000.
>Jan 21 04:01:22 localhost kernel: Registered led device: iwl-phy0::radio
>Jan 21 04:01:22 localhost kernel: Registered led device: iwl-phy0::assoc
>Jan 21 04:01:22 localhost kernel: Registered led device: iwl-phy0::RX
>Jan 21 04:01:22 localhost kernel: Registered led device: iwl-phy0::TX
>Jan 21 04:20:25 localhost kernel: Process 2837(firefox) has RLIMIT_CORE set to 0
>Jan 21 04:20:25 localhost kernel: Aborting core
[snip]
>Jan 21 04:50:54 localhost kernel: iwlagn 0000:02:00.0: iwl_tx_agg_start on ra = 00:1f:5b:87:06:7d tid = 4
>Jan 21 04:52:39 localhost NetworkManager: <info>  (wlan0): supplicant connection state:  completed -> group handshake
>Jan 21 04:52:39 localhost NetworkManager: <info>  (wlan0): supplicant connection state:  group handshake -> completed
>Jan 21 04:54:58 localhost kernel: Process 8791(firefox) has RLIMIT_CORE set to 0
>Jan 21 04:54:58 localhost kernel: Aborting core
>Jan 21 04:55:09 localhost NetworkManager: <info>  Sleeping...
>Jan 21 04:55:09 localhost NetworkManager: <info>  (eth0): now unmanaged
>Jan 21 04:55:09 localhost NetworkManager: <info>  (eth0): device state change: 2 -> 1 (reason 37)
>Jan 21 04:55:09 localhost NetworkManager: <info>  (eth0): cleaning up...
>Jan 21 04:55:09 localhost NetworkManager: <info>  (eth0): taking down device.
>Jan 21 04:55:09 localhost NetworkManager: <info>  (wlan0): now unmanaged
>Jan 21 04:55:09 localhost NetworkManager: <info>  (wlan0): device state change: 8 -> 1 (reason 37)
>Jan 21 04:55:09 localhost NetworkManager: <info>  (wlan0): deactivating device (reason: 37).
>Jan 21 04:55:09 localhost NetworkManager: <info>  (wlan0): canceled DHCP transaction, dhcp client pid 2499
>Jan 21 04:55:09 localhost NetworkManager: <WARN>  check_one_route(): (wlan0) error -34 returned from rtnl_route_del(): Sucess#012
>Jan 21 04:55:09 localhost avahi-daemon[1272]: Withdrawing address record for 10.0.1.11 on wlan0.
>Jan 21 04:55:09 localhost avahi-daemon[1272]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.0.1.11.
>Jan 21 04:55:09 localhost kernel: iwlagn 0000:02:00.0: Stopping AGG while state not ON or starting
>Jan 21 04:55:09 localhost kernel: iwlagn 0000:02:00.0: queue number out of range: 0, must be 10 to 19
>Jan 21 04:55:09 localhost kernel: ------------[ cut here ]------------
>Jan 21 04:55:09 localhost kernel: WARNING: at net/mac80211/agg-tx.c:150 ___ieee80211_stop_tx_ba_session+0x7b/0x80 [mac80211]()
>Jan 21 04:55:09 localhost kernel: Hardware name: Aspire 1810TZ

Comment 10 Stanislaw Gruszka 2010-01-22 13:45:54 UTC
Does swcrypto=1 option help? To use that option please do the following
as root:

echo options iwlagn swcrypto=1 >> /etc/modprobe.d/iwlwifi.conf
echo options iwlagn swcrypto50=1 >> /etc/modprobe.d/iwlwifi.conf
rmmod iwlagn
rmmod iwlcore
modproble iwlagn

Comment 11 Milos Jakubicek 2010-01-28 17:53:41 UTC
Hmm...it seems that it helps for the rawhide kernel (2.6.32.3-21.fc13.x86_64), but not sure if also for the F12 one:

For the rawhide kernel I've got another problem: when I close the laptop lid, the X server session hangs up (I've the relevant messages from syslog, but this is a separate issue, more over, I don't know whether it is not causedy by the fact that I use the rawhide kernel with F12 X server-?).

For the F12 kernel, I'm attaching new /var/log/messages and the oops caughy by abrt. Looking into it, the report was in drm.c -- so it might be that this is also a separate issue, in that case the swcrypto option helped.

Comment 12 Milos Jakubicek 2010-01-28 17:54:30 UTC
Created attachment 387394 [details]
new /var/log/messages

Comment 13 Milos Jakubicek 2010-01-28 17:57:20 UTC
Created attachment 387395 [details]
abrt kerneloops

Comment 14 Milos Jakubicek 2010-01-28 17:58:00 UTC
(In reply to comment #11)

> For the F12 kernel, I'm attaching new /var/log/messages and the oops caughy by
> abrt. Looking into it, the report was in drm.c 
           
                                           ^^^^ Not drm.c but dmar.c, sorry.

Comment 15 Stanislaw Gruszka 2010-01-29 12:44:56 UTC
Yes, rawhide kernel is not compatible with F12 Xwindow system.

dmar issue is BIOS problem, kernel is just noisy about that. We probably should not print calltrace when it happens to not confuse people, but that was upstream developer decision with "Promote an attitude of violence to a BIOS engineer today" comment :/

F12 will update to 2.6.32 kernel as soon as fedora kernel developers cope with kernel/Xwindow compatibility. 

Since swcrypt fix the problem this is cleanly firmware issue, we have similar bug reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=519154
and upstream here 
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2052
but this is for 4965 card however and you have 1000.

Please open new bug on http://bugzilla.intellinuxwireless.org/ to allow Intel engineers to fix it. See http://www.intellinuxwireless.org/?n=fw_error_report how to report firmware bug. Note fedora kernel have all needed options enabled (maybe except PRINTK_TIMES but this is unnecessary since syslog provide timing information).

Thank you.

Comment 16 Milos Jakubicek 2010-02-02 00:58:06 UTC
Stanislaw, this just happened (with swcrypto=1!!!) -- is it the same issue or something unrelated (looks like)? I had to rmmod iwlagn and modprobe it again to get the wireless back.

Feb  2 01:20:31 localhost kernel: ------------[ cut here ]------------
Feb  2 01:20:31 localhost kernel: WARNING: at net/mac80211/util.c:272 __ieee80211_wake_queue+0x2b/0xbb [mac80211]() (Tainted: G        W )
Feb  2 01:20:31 localhost kernel: Hardware name: Aspire 1810TZ
Feb  2 01:20:31 localhost kernel: Modules linked in: vboxnetadp vboxnetflt vboxdrv hidp cryptd aes_x86_64 aes_generic fuse rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand acpi_cpufreq freq_table ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput uvcvideo snd_hda_codec_intelhdmi snd_hda_codec_realtek videodev snd_hda_intel snd_hda_codec v4l1_compat v4l2_compat_ioctl32 arc4 ecb iwlagn snd_hwdep snd_seq iwlcore snd_seq_device snd_pcm btusb snd_timer mac80211 snd cfg80211 bluetooth i2c_i801 soundcore iTCO_wdt acer_wmi atl1c rfkill iTCO_vendor_support snd_page_alloc serio_raw wmi joydev dm_multipath usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode]
Feb  2 01:20:31 localhost kernel: Pid: 0, comm: swapper Tainted: G        W  2.6.31.9-174.fc12.x86_64 #1
Feb  2 01:20:31 localhost kernel: Call Trace:
Feb  2 01:20:31 localhost kernel: <IRQ>  [<ffffffff81051710>] warn_slowpath_common+0x84/0x9c
Feb  2 01:20:31 localhost kernel: [<ffffffff8105173c>] warn_slowpath_null+0x14/0x16
Feb  2 01:20:31 localhost kernel: [<ffffffffa0151aaa>] __ieee80211_wake_queue+0x2b/0xbb [mac80211]
Feb  2 01:20:31 localhost kernel: [<ffffffffa0151f2d>] ieee80211_wake_queue_by_reason+0x3b/0x51 [mac80211]
Feb  2 01:20:31 localhost kernel: [<ffffffffa0151f53>] ieee80211_wake_queue+0x10/0x12 [mac80211]
Feb  2 01:20:31 localhost kernel: [<ffffffffa01fe970>] iwl_wake_queue+0x53/0x55 [iwlagn]
Feb  2 01:20:31 localhost kernel: [<ffffffffa01ff41e>] iwl5000_rx_reply_tx+0xaac/0xb4e [iwlagn]
Feb  2 01:20:31 localhost kernel: [<ffffffff810f0936>] ? add_partial+0x3b/0x51
Feb  2 01:20:31 localhost kernel: [<ffffffff8120a727>] ? swiotlb_bus_to_virt+0x9/0x18
Feb  2 01:20:31 localhost kernel: [<ffffffffa01ef5ed>] iwl_rx_handle+0x20e/0x3a7 [iwlagn]
Feb  2 01:20:31 localhost kernel: [<ffffffff813765ca>] ? __kfree_skb+0x7d/0x81
Feb  2 01:20:31 localhost kernel: [<ffffffffa01f0505>] ? __iwl_write32.clone.2+0xad/0xbc [iwlagn]
Feb  2 01:20:31 localhost kernel: [<ffffffffa01f11e8>] iwl_irq_tasklet+0x54b/0x6c5 [iwlagn]
Feb  2 01:20:31 localhost kernel: [<ffffffff81056113>] tasklet_action+0x85/0xe4
Feb  2 01:20:31 localhost kernel: [<ffffffff81057630>] __do_softirq+0xdd/0x1ad
Feb  2 01:20:31 localhost kernel: [<ffffffff81012eac>] call_softirq+0x1c/0x30
Feb  2 01:20:31 localhost kernel: [<ffffffff810143fb>] do_softirq+0x47/0x8d
Feb  2 01:20:31 localhost kernel: [<ffffffff81057342>] irq_exit+0x44/0x86
Feb  2 01:20:31 localhost kernel: [<ffffffff814214b5>] do_IRQ+0xa5/0xbc
Feb  2 01:20:31 localhost kernel: [<ffffffff810126d3>] ret_from_intr+0x0/0x11
Feb  2 01:20:31 localhost kernel: <EOI>  [<ffffffff81269ffa>] ? acpi_idle_enter_simple+0x111/0x145
Feb  2 01:20:31 localhost kernel: [<ffffffff81269ff3>] ? acpi_idle_enter_simple+0x10a/0x145
Feb  2 01:20:31 localhost kernel: [<ffffffff813562ef>] ? cpuidle_idle_call+0x99/0xce
Feb  2 01:20:31 localhost kernel: [<ffffffff81010c60>] ? cpu_idle+0xa6/0xe9
Feb  2 01:20:31 localhost kernel: [<ffffffff81408577>] ? rest_init+0x6b/0x6d
Feb  2 01:20:31 localhost kernel: [<ffffffff81716dc7>] ? start_kernel+0x3ef/0x3fa
Feb  2 01:20:31 localhost kernel: [<ffffffff817162a1>] ? x86_64_start_reservations+0xac/0xb0
Feb  2 01:20:31 localhost kernel: [<ffffffff8171639d>] ? x86_64_start_kernel+0xf8/0x107
Feb  2 01:20:31 localhost kernel: ---[ end trace a7919e7f17c0a727 ]---

Comment 17 Stanislaw Gruszka 2010-02-02 13:32:45 UTC
(In reply to comment #16)
> Stanislaw, this just happened (with swcrypto=1!!!) -- is it the same issue or
> something unrelated (looks like)? I had to rmmod iwlagn and modprobe it again
> to get the wireless back.

> Feb  2 01:20:31 localhost kernel: WARNING: at net/mac80211/util.c:272
> __ieee80211_wake_queue+0x2b/0xbb [mac80211]() (Tainted: G        W )

Looks like different issue, previously we had 

> WARNING: at net/mac80211/agg-tx.c:150 ___ieee80211_stop_tx_ba_session+0x7b/0x80

Call traces are different as well. In which kernel you get this?

Comment 18 Milos Jakubicek 2010-02-02 15:29:09 UTC
(In reply to comment #17)
> 
> Call traces are different as well. In which kernel you get this?    

Still the 2.6.31.9-174.fc12.x86_64.

Comment 19 Milos Jakubicek 2010-02-02 19:34:41 UTC
Created attachment 388370 [details]
/var/log/messages (with debugging output, without swcrypto)

Hmm...it happened again, this time "rmmod iwlagn" resulted into a complete hangup of the machine. See the attached /var/log/messages, note that I had enabled the debugging option for iwlagn now (as described on the Intel pages) -- though it seems to be fully working since the restart now, looking into the flood in there.
Next time it happens I'll post here and report upstream as well.

!!! I just found out that when I enabled the debugging output (debug=0x43fff), I've disabled the swcrypto=1 option to get the crashing back to be able to report upstream -- I'm sorry for confusion (means also the last backtrace is without the swcrypto option)!!!

Comment 20 Milos Jakubicek 2010-02-02 19:41:06 UTC
(In reply to comment #19)

> -- though it seems to be fully working since the restart now, looking into the
> flood in there.

Looking into your posts above this was just probaby caused by the fact that after placing the debug option I rmmod & modprobed iwlagn, but not rmmod iwlcore (therefore it didn't start fully work until the restart).

Comment 21 Sid Wilroy 2010-02-15 13:59:30 UTC
WARNING: at drivers/pci/dmar.c:598 check_zero_address+0x96/0x19b() (Not tainted)
Hardware name: HP EliteBook 8530p
Your BIOS is broken; DMAR reported at address zero!
BIOS vendor: Hewlett-Packard; Ver: 68PDV Ver. F.0F; Product Version: F.0F
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.31.12-174.2.3.fc12.x86_64 #1
Call Trace:
[<ffffffff81051710>] warn_slowpath_common+0x84/0x9c
[<ffffffff81423973>] ? _etext+0x0/0x1
[<ffffffff8105177f>] warn_slowpath_fmt+0x41/0x43
[<ffffffff8173e7fe>] check_zero_address+0x96/0x19b
[<ffffffff81262181>] ? acpi_tb_verify_table+0x57/0x5c
[<ffffffff812617df>] ? acpi_get_table_with_size+0x5a/0xb4
[<ffffffff81423973>] ? _etext+0x0/0x1
[<ffffffff8173e915>] detect_intel_iommu+0x12/0x8c
[<ffffffff8171dbc3>] pci_iommu_alloc+0x5e/0x6c
[<ffffffff8172d1a8>] mem_init+0x19/0x161
[<ffffffff81716be3>] start_kernel+0x20b/0x3fa
[<ffffffff817162a1>] x86_64_start_reservations+0xac/0xb0
[<ffffffff8171639d>] x86_64_start_kernel+0xf8/0x107

I wonder if it's just the intel_iommu

Comment 22 Milos Jakubicek 2010-02-16 10:00:47 UTC
So, finally: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2159

Comment 23 Milos Jakubicek 2010-02-16 23:59:05 UTC
Stanislaw, FYI, I've asked to add the Intel Wifi BZ to our external bugtrackers...and it's already done.

Comment 24 Stanislaw Gruszka 2010-02-21 13:53:16 UTC
(In reply to comment #21)
> WARNING: at drivers/pci/dmar.c:598 check_zero_address+0x96/0x19b() (Not
> tainted)
[snip]
> I wonder if it's just the intel_iommu 
   
Have seen that on Calgary iommu as well.

Comment 25 Chuyee 2010-03-24 02:59:57 UTC
(In reply to comment #24)
> (In reply to comment #21)
> > WARNING: at drivers/pci/dmar.c:598 check_zero_address+0x96/0x19b() (Not
> > tainted)
> [snip]
> > I wonder if it's just the intel_iommu 
> 
> Have seen that on Calgary iommu as well.    

This is a BIOS bug. You can disable it with kernel parameter intel_iommu=off.

Comment 26 Chuyee 2010-03-24 03:12:36 UTC
> WARNING: at net/mac80211/agg-tx.c:150 ___ieee80211_stop_tx_ba_session+0x7b/0x80

This one is already fixed in upstream. Please verify.

> WARNING: at net/mac80211/util.c:272 __ieee80211_wake_queue+0x2b/0xbb

Also fixed upstream.

Comment 27 Bug Zapper 2010-11-04 00:29:00 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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 28 Bug Zapper 2010-12-04 00:07:17 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.


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