p54usb generates the following warning: (Note: My kernel is dirty due to testing a fix for a regression.): ------------[ cut here ]------------ WARNING: at net/mac80211/tx.c:1325 ieee80211_tx+0x23c/0x298 [mac80211]() Hardware name: HP Pavilion dv2700 Notebook PC tx refused but queue active Modules linked in: p54usb p54common led_class mac80211 cfg80211 rfkill aes_x86_64 aes_generic af_packet snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device nfs lockd nfs_acl auth_rpcgss vboxnetflt sunrpc vboxdrv cpufreq_conservative cpufreq_userspace cpufreq_powersave powernow_k8 fuse ext4 jbd2 crc16 loop dm_mod ide_cd_mod cdrom pata_amd snd_hda_codec_conexant arc4 ecb ide_pci_generic uvcvideo snd_hda_intel snd_hda_codec videodev snd_pcm v4l1_compat snd_timer v4l2_compat_ioctl32 snd amd74xx i2c_nforce2 battery soundcore ac button serio_raw k8temp joydev snd_page_alloc ide_core i2c_core forcedeth hwmon sg sd_mod ohci_hcd ehci_hcd usbcore edd ahci libata scsi_mod ext3 mbcache jbd fan thermal processor [last unloaded: led_class] Pid: 9773, comm: firefox Tainted: G W 2.6.31-rc2-Linus-dirty #181 Call Trace: [<ffffffffa068bf9a>] ? ieee80211_tx+0x23c/0x298 [mac80211] [<ffffffff8103c17e>] warn_slowpath_common+0x77/0xa4 [<ffffffff8103c1f8>] warn_slowpath_fmt+0x3c/0x3e [<ffffffff8105e38c>] ? trace_hardirqs_on+0xd/0xf [<ffffffffa068beeb>] ? ieee80211_tx+0x18d/0x298 [mac80211] [<ffffffffa068bf9a>] ieee80211_tx+0x23c/0x298 [mac80211] [<ffffffffa068bdef>] ? ieee80211_tx+0x91/0x298 [mac80211] [<ffffffffa068ccf5>] ieee80211_master_start_xmit+0x309/0x33c [mac80211] [<ffffffff811e5403>] dev_hard_start_xmit+0x254/0x302 [<ffffffff811e520d>] ? dev_hard_start_xmit+0x5e/0x302 [<ffffffff811f6760>] __qdisc_run+0xf5/0x208 [<ffffffff811e5827>] dev_queue_xmit+0x263/0x39b [<ffffffff811e5739>] ? dev_queue_xmit+0x175/0x39b [<ffffffffa068c9cc>] ieee80211_subif_start_xmit+0x53c/0x55c [mac80211] [<ffffffffa068c6b1>] ? ieee80211_subif_start_xmit+0x221/0x55c [mac80211] [<ffffffff8105e341>] ? trace_hardirqs_on_caller+0xf1/0x12f [<ffffffff811dcee9>] ? __kfree_skb+0x82/0x86 [<ffffffff811e5403>] dev_hard_start_xmit+0x254/0x302 [<ffffffff811e520d>] ? dev_hard_start_xmit+0x5e/0x302 [<ffffffff811f6760>] __qdisc_run+0xf5/0x208 [<ffffffff811e5827>] dev_queue_xmit+0x263/0x39b [<ffffffff811e5739>] ? dev_queue_xmit+0x175/0x39b [<ffffffff811eb6aa>] neigh_resolve_output+0x2a3/0x2d8 [<ffffffff81208ab3>] ip_finish_output+0x239/0x27f [<ffffffff81207294>] ? ip_generic_getfrag+0x45/0x8b [<ffffffff81208ba2>] ip_output+0xa9/0xad [<ffffffff811d8b81>] ? lock_sock_nested+0xe9/0xf8 [<ffffffff81207c35>] ip_local_out+0x20/0x24 [<ffffffff81207f08>] ip_push_pending_frames+0x2cf/0x33f [<ffffffff81222f41>] udp_push_pending_frames+0x2d1/0x32d [<ffffffff81224660>] udp_sendmsg+0x51a/0x620 [<ffffffff8122a0cc>] inet_sendmsg+0x46/0x53 [<ffffffff811d6654>] sock_sendmsg+0xdf/0xf8 [<ffffffff8105f7a1>] ? __lock_acquire+0x7c3/0x1607 [<ffffffff81200b0b>] ? __ip_route_output_key+0x1c5/0xaf0 [<ffffffff8104fecc>] ? autoremove_wake_function+0x0/0x38 [<ffffffff810b05bc>] ? fget_light+0x4c/0xe1 [<ffffffff810b063b>] ? fget_light+0xcb/0xe1 [<ffffffff810b05bc>] ? fget_light+0x4c/0xe1 [<ffffffff811d5f84>] ? sockfd_lookup_light+0x1b/0x54 [<ffffffff811d71d4>] sys_sendto+0xdf/0x107 [<ffffffff810bbc3b>] ? sys_fcntl+0x2a5/0x367 [<ffffffff810b05bc>] ? fget_light+0x4c/0xe1 [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b ---[ end trace 82e427a0c6fcfb5d ]--- A band-aid fix is available that should be suitable for 2.6.31. A more invasive fix is currently being tested for submission to wireless-testing.
I am using 2.6.31-rc6-git7 as I saw patch from http://patchwork.kernel.org/patch/34618/ is already applied but the problem still occurs. ------------[ cut here ]------------ WARNING: at net/mac80211/tx.c:1325 ieee80211_tx+0x184/0x1a1() Hardware name: ION603 tx refused but queue active Modules linked in: p54usb p54common snd_cs5535audio snd_ac97_codec ac97_bus Pid: 2131, comm: syslog-ng Tainted: G W 2.6.31-rc6-git7 #1 Call Trace: [<c102dfc0>] warn_slowpath_common+0x65/0x7c [<c14c907a>] ? ieee80211_tx+0x184/0x1a1 [<c102e00b>] warn_slowpath_fmt+0x24/0x27 [<c14c907a>] ieee80211_tx+0x184/0x1a1 [<c14c91f4>] ieee80211_tx_pending+0x15d/0x225 [<c1031e01>] tasklet_action+0x59/0x94 [<c1032b68>] __do_softirq+0xa7/0x148 [<c1032c2f>] do_softirq+0x26/0x2b [<c1032d11>] irq_exit+0x29/0x5c [<c1003fc9>] do_IRQ+0x81/0x95 [<c10030e9>] common_interrupt+0x29/0x30 ---[ end trace 9b612801f459bfad ]---
What workload does it take to cause this WARNING on your machine? I had tested with heavy and minimal loads without it happening after the patch was applied.
I'm using p54usb dongle with hostapd to share my Internet connection. After client connects with station and start browsing/downloading it takes 0.5 - 1min and suddenly network sharing stops working. The only error message comes from dmesg and it is the error mentioned before. System load was from 0.10 to 0.30 max.
Ah, it fails when using it as an AP. IO have not tested that configuration, but I will now.
I'm getting a kernel panic when I try to connect a Windows Vista host to the AP that I establish using p54usb. When my client was Linux, it transmitted data in both directions without a problem. I have yet to chase this down.
I think this might be fixed now. I was experiencing it too but I've just been running yesterday's linux-next for a couple of hours, with a Wii and Vista both connecting, and there were no panics or freezes.
@James Le Cuirot: do you know which commit caused the pleasant change ?
No idea, sorry.
Closed based on age and comment 6...