d80211: soft lockup in ieee80211_unregister_hw
Hi, while doing my first steps under d80211 I stumbled over a soft lockup. It's on a real SMP machine (Core 2 Duo). After the lockup the machine becomes unusable. I can reproduce it reliably by unplugging the device. The bug appears to be present in the John Linville's wireless-dev master branch, but also in Micheal Wu's zd1211rw-week51 branch. Reading the code I see that the work structs are canceled more then one time. At first in ieee80211_unregister_hw and second in ieee80211_if_shutdown called by unregister_netdev. The second cancel operation casues the soft lockup. Does anybody have an idea how to fix it? Here is the kernel log with the soft lockup. Ja 6 13:13:26 newa kernel: [ 152.647382] BUG: soft lockup detected on CPU#0! Jan 6 13:13:26 newa kernel: [ 152.647390] Jan 6 13:13:26 newa kernel: [ 152.647391] Call Trace: Jan 6 13:13:26 newa kernel: [ 152.647410] [show_trace+65/112] show_trace+0x41/0x70 Jan 6 13:13:26 newa kernel: [ 152.647419] [dump_stack+18/32] dump_stack+0x12/0x20 Jan 6 13:13:26 newa kernel: [ 152.647429] [softlockup_tick+250/288] softlockup_tick+0xfa/0x120 Jan 6 13:13:26 newa kernel: [ 152.647439] [update_process_times+87/144] update_process_times+0x57/0x90 Jan 6 13:13:26 newa kernel: [ 152.647448] [smp_local_timer_interrupt+52/96] smp_local_timer_interrupt+0x34/0x60 Jan 6 13:13:26 newa kernel: [ 152.647457] [smp_apic_timer_interrupt+89/128] smp_apic_timer_interrupt+0x59/0x80 Jan 6 13:13:26 newa kernel: [ 152.647465] [apic_timer_interrupt+102/112] apic_timer_interrupt+0x66/0x70 Jan 6 13:13:26 newa kernel: [ 152.648225] DWARF2 unwinder stuck at apic_timer_interrupt+0x66/0x70 Jan 6 13:13:26 newa kernel: [ 152.648229] Jan 6 13:13:26 newa kernel: [ 152.648232] Leftover inexact backtrace: Jan 6 13:13:26 newa kernel: [ 152.648233] Jan 6 13:13:26 newa kernel: [ 152.648237] IRQ EOI [lock_timer_base+64/96] lock_timer_base+0x40/0x60 Jan 6 13:13:26 newa kernel: [ 152.648268] [try_to_del_timer_sync+24/96] try_to_del_timer_sync+0x18/0x60 Jan 6 13:13:26 newa kernel: [ 152.648277] [del_timer_sync+12/32] del_timer_sync+0xc/0x20 Jan 6 13:13:26 newa kernel: [ 152.648301] [_end+129730637/2130872328] :80211:ieee80211_if_shutdown+0x75/0x100 Jan 6 13:13:26 newa kernel: [ 152.648323] [_end+129745001/2130872328] :80211:ieee80211_stop+0x101/0x120 Jan 6 13:13:26 newa kernel: [ 152.648334] [dev_close+88/128] dev_close+0x58/0x80 Jan 6 13:13:26 newa kernel: [ 152.648341] [unregister_netdevice+149/592] unregister_netdevice+0x95/0x250 Jan 6 13:13:26 newa kernel: [ 152.648363] [_end+129742664/2130872328] :80211:ieee80211_unregister_hw+0x90/0x220 Jan 6 13:13:26 newa kernel: [ 152.648382] [_end+129956419/2130872328] :zd1211rw_d80211:disconnect+0xab/0x120 Jan 6 13:13:26 newa kernel: [ 152.648412] [_end+128711626/2130872328] :usbcore:usb_unbind_interface+0x72/0xe0 Jan 6 13:13:26 newa kernel: [ 152.648423] [__device_release_driver+135/208] __device_release_driver+0x87/0xd0 Jan 6 13:13:26 newa kernel: [ 152.648431] [device_release_driver+51/96] device_release_driver+0x33/0x60 Jan 6 13:13:26 newa kernel: [ 152.648438] [bus_remove_device+137/176] bus_remove_device+0x89/0xb0 Jan 6 13:13:26 newa kernel: [ 152.648446] [device_del+419/496] device_del+0x1a3/0x1f0 Jan 6 13:13:26 newa kernel: [ 152.648472] [_end+128700218/2130872328] :usbcore:usb_disable_device+0x82/0x100 Jan 6 13:13:26 newa kernel: [ 152.648499] [_end+128684210/2130872328] :usbcore:usb_disconnect+0xaa/0x110 Jan 6 13:13:26 newa kernel: [ 152.648526] [_end+128687990/2130872328] :usbcore:hub_thread+0x48e/0xd20 Jan 6 13:13:26 newa kernel: [ 152.648537] [thread_return+0/237] thread_return+0x0/0xed Jan 6 13:13:26 newa kernel: [ 152.648551] [autoremove_wake_function+0/48] autoremove_wake_function+0x0/0x30 Jan 6 13:13:26 newa kernel: [ 152.648579] [_end+128686824/2130872328] :usbcore:hub_thread+0x0/0xd20 Jan 6 13:13:26 newa kernel: [ 152.648587] [keventd_create_kthread+0/128] keventd_create_kthread+0x0/0x80 Jan 6 13:13:26 newa kernel: [ 152.648594] [kthread+217/288] kthread+0xd9/0x120 Jan 6 13:13:26 newa kernel: [ 152.648604] [child_rip+10/18] child_rip+0xa/0x12 Jan 6 13:13:26 newa kernel: [ 152.648611] [keventd_create_kthread+0/128] keventd_create_kthread+0x0/0x80 Jan 6 13:13:26 newa kernel: [ 152.648620] [flat_send_IPI_mask+0/80] flat_send_IPI_mask+0x0/0x50 Jan 6 13:13:26 newa kernel: [ 152.648630] [kthread+0/288] kthread+0x0/0x120 Jan 6 13:13:26 newa kernel: [ 152.648637] [child_rip+0/18] child_rip+0x0/0x12 Jan 6 13:13:26 newa kernel: [ 152.648643] Uli -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
Ivo van Doorn wrote:
+#define __bss_tim_set(__bss, __aid) __set_bit((__aid), (__bss)-tim)
+
__set/clear_bit demands unsigned long, tim is u8. That causes quite some
warnings here.
...
static inline void bss_tim_clear(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
spin_lock(local-sta_lock);
- bss-tim[(aid)/8] = !(1((aid) % 8));
+ __bss_tim_clear(bss, aid);
spin_unlock(local-sta_lock);
Probably forgotten: we need _bh here as well.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
On Tue, 2007-01-02 at 16:22 +, Christoph Hellwig wrote: This really screams to be converted to __set_bit. Whoops, I should really have jumped into this thread earlier but somehow missed it. This cannot be converted to __set_bit because the IEEE specs mandate this format. We can insert a comment that the format must stay like this :) You have to realise that the TIM is sent as-is with the 0th bit indicating multicast traffic (IIRC) and each of the other bits indicating traffic for that AID. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
On Fri, 2007-01-05 at 21:08 +0100, Ivo van Doorn wrote: This patch uses the __set_bit and __clear_but as suggested by Christoph. It also removes the local argument since it was unused. NACK. This breaks spec compliance for drivers that use the TIM in their beacon frames. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
On Sat, 2007-01-06 at 17:52 +0100, Johannes Berg wrote: On Fri, 2007-01-05 at 21:08 +0100, Ivo van Doorn wrote: This patch uses the __set_bit and __clear_but as suggested by Christoph. It also removes the local argument since it was unused. NACK. This breaks spec compliance for drivers that use the TIM in their beacon frames. Which, in fact, is the only point we keep track of the TIM, note that we never actually test if bits there are set, the stack has better ways of keeping track of the pending traffic. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
Johannes Berg wrote: On Fri, 2007-01-05 at 21:08 +0100, Ivo van Doorn wrote: This patch uses the __set_bit and __clear_but as suggested by Christoph. It also removes the local argument since it was unused. NACK. This breaks spec compliance for drivers that use the TIM in their beacon frames. Bit ordering, I see. Then go for my original patch + comments why this is open-coded in __bss_tim_set/clear + removed unused arguments from those functions, OK? Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
On Sat, 2007-01-06 at 18:00 +0100, Jan Kiszka wrote: Johannes Berg wrote: On Fri, 2007-01-05 at 21:08 +0100, Ivo van Doorn wrote: This patch uses the __set_bit and __clear_but as suggested by Christoph. It also removes the local argument since it was unused. NACK. This breaks spec compliance for drivers that use the TIM in their beacon frames. Bit ordering, I see. Then go for my original patch + comments why this is open-coded in __bss_tim_set/clear + removed unused arguments from those functions, OK? Sounds good to me, care to send a new patch? johannes signature.asc Description: This is a digitally signed message part
[PATCH] d80211: Select CRYPTO_ECB when enabler d80211.
The d80211 stack uses ECB mode block ciphers for the WEP implementation. Make sure that support for CRYPTO_ECB is in the kernel when the d80211 stack is enabled (just like the other crypto algorithms). Signed-off-by: Gertjan van Wingerde [EMAIL PROTECTED] --- diff --git a/net/d80211/Kconfig b/net/d80211/Kconfig index 0f07d41..a6f2ba5 100644 --- a/net/d80211/Kconfig +++ b/net/d80211/Kconfig @@ -1,6 +1,7 @@ config D80211 tristate Generic IEEE 802.11 Networking Stack (dscape) select CRYPTO + select CRYPTO_ECB select CRYPTO_ARC4 select CRYPTO_AES ---help--- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] d80211: Only free WEP crypto ciphers when they have been allocated correctly.
The d80211 stack still tries to free the WEP crypto ciphers, even when
allocating them previously has failed. This results in an oops.
Make sure that the d80211 stack only frees the crypto ciphers when they have
been allocated successfully.
Signed-off-by: Gertjan van Wingerde [EMAIL PROTECTED]
---
diff --git a/net/d80211/wep.c b/net/d80211/wep.c
index dee8eae..5abcda6 100644
--- a/net/d80211/wep.c
+++ b/net/d80211/wep.c
@@ -44,8 +44,10 @@ int ieee80211_wep_init(struct ieee80211_local *local)
void ieee80211_wep_free(struct ieee80211_local *local)
{
- crypto_free_blkcipher(local-wep_tx_tfm);
- crypto_free_blkcipher(local-wep_rx_tfm);
+ if (!IS_ERR(local-wep_tx_tfm))
+ crypto_free_blkcipher(local-wep_tx_tfm);
+ if (!IS_ERR(local-wep_rx_tfm))
+ crypto_free_blkcipher(local-wep_rx_tfm);
}
static inline int ieee80211_wep_weak_iv(u32 iv, int keylen)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: Only free WEP crypto ciphers when they have been allocated correctly.
On Saturday 06 January 2007 12:00, Gertjan van Wingerde wrote: The d80211 stack still tries to free the WEP crypto ciphers, even when allocating them previously has failed. Actually, the code might not even have tried to allocate them. The ciphers are guaranteed to be allocated when the device is registered however, so we should be able to free it safely on unregister. Signed-off-by: Michael Wu [EMAIL PROTECTED] --- net/d80211/ieee80211.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c index 6e10db5..926d160 100644 --- a/net/d80211/ieee80211.c +++ b/net/d80211/ieee80211.c @@ -4715,6 +4715,7 @@ void ieee80211_unregister_hw(struct ieee skb_queue_purge(local-skb_queue_unreliable); ieee80211_dev_free_index(local); + ieee80211_wep_free(local); ieee80211_led_exit(local); } EXPORT_SYMBOL(ieee80211_unregister_hw); @@ -4724,7 +4725,6 @@ void ieee80211_free_hw(struct ieee80211_ struct ieee80211_local *local = hw_to_local(hw); ieee80211_if_free(local-mdev); - ieee80211_wep_free(local); ieee80211_dev_free(local); } EXPORT_SYMBOL(ieee80211_free_hw); pgpj7Z6FryVOG.pgp Description: PGP signature
[PATCH RESEND] 3 ixgb fixes, please pull
Hi, These 3 patches were earlier submitted and ACKed by Jeff Garzik on 12/08, 12/11. They were part of a larger submission that also included e1000 patches. The ixgb patches still need to be merged. The spurious NETIF_F_TSO flags were removed from patch Fix early TSO completion as requested. These patches apply against netdev-2.6 #upstream-fixes commit 81f4e6c190a0fa016fd7eecaf76a5f95d121afc2. Please pull: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes to receive them. Cheers, Auke see also: http://marc.theaimsgroup.com/?l=linux-netdevm=116584793808733w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=116584793729158w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=116593164226253w=2 --- Jesse Brandeburg [EMAIL PROTECTED] ixgb: Fix early TSO completion ixgb: Maybe stop TX if not enough free descriptors Aaron Salter [EMAIL PROTECTED] ixgb: Write RA register high word first, increment version --- drivers/net/ixgb/ixgb.h |1 drivers/net/ixgb/ixgb_ethtool.c |1 drivers/net/ixgb/ixgb_hw.c |3 +- drivers/net/ixgb/ixgb_main.c| 60 4 files changed, 58 insertions(+), 7 deletions(-) --- Auke Kok [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: Only free WEP crypto ciphers when they have been allocated correctly.
Michael Wu wrote: On Saturday 06 January 2007 12:00, Gertjan van Wingerde wrote: The d80211 stack still tries to free the WEP crypto ciphers, even when allocating them previously has failed. Actually, the code might not even have tried to allocate them. The ciphers are guaranteed to be allocated when the device is registered however, so we should be able to free it safely on unregister. Signed-off-by: Michael Wu [EMAIL PROTECTED] --- net/d80211/ieee80211.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c index 6e10db5..926d160 100644 --- a/net/d80211/ieee80211.c +++ b/net/d80211/ieee80211.c @@ -4715,6 +4715,7 @@ void ieee80211_unregister_hw(struct ieee skb_queue_purge(local-skb_queue_unreliable); ieee80211_dev_free_index(local); + ieee80211_wep_free(local); ieee80211_led_exit(local); } EXPORT_SYMBOL(ieee80211_unregister_hw); @@ -4724,7 +4725,6 @@ void ieee80211_free_hw(struct ieee80211_ struct ieee80211_local *local = hw_to_local(hw); ieee80211_if_free(local-mdev); - ieee80211_wep_free(local); ieee80211_dev_free(local); } EXPORT_SYMBOL(ieee80211_free_hw); OK. Your patch fixes the issue I've seen as well, and seems a bit cleaner. Acked-by: Gertjan van Wingerde [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
Bit ordering, I see. Then go for my original patch + comments why this
is open-coded in __bss_tim_set/clear + removed unused arguments from
those functions, OK?
Sounds good to me, care to send a new patch?
This patch returns to the original format for setting and clearing the tim bit,
as the IEEE specs mandate. (Comment has been added to prevent future
attempts to use the __set_bit and __clear_bit)
And the local argument has been removed.
Signed-off-by Jan Kiszka [EMAIL PROTECTED]
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..64d881c 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -558,20 +558,38 @@ struct sta_attribute {
ssize_t (*store)(struct sta_info *, const char *buf, size_t count);
};
+static inline void __bss_tim_set(struct ieee80211_if_ap *bss, int aid)
+{
+ /*
+* This format has ben mandated by the IEEE specifications,
+* so this line may not be changed to use the __set_bit() format.
+*/
+ bss-tim[(aid)/8] |= 1((aid) % 8);
+}
+
static inline void bss_tim_set(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(local-sta_lock);
- bss-tim[(aid)/8] |= 1((aid) % 8);
- spin_unlock(local-sta_lock);
+ spin_lock_bh(local-sta_lock);
+ __bss_tim_set(bss, aid);
+ spin_unlock_bh(local-sta_lock);
+}
+
+static inline void __bss_tim_clear(struct ieee80211_if_ap *bss, int aid)
+{
+ /*
+* This format has ben mandated by the IEEE specifications,
+* so this line may not be changed to use the __clear_bit() format.
+*/
+ bss-tim[(aid)/8] = !(1((aid) % 8));
}
static inline void bss_tim_clear(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(local-sta_lock);
- bss-tim[(aid)/8] = !(1((aid) % 8));
- spin_unlock(local-sta_lock);
+ spin_lock_bh(local-sta_lock);
+ __bss_tim_clear(bss, aid);
+ spin_unlock_bh(local-sta_lock);
}
/* ieee80211.c */
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index c74b431..1363a01 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -285,7 +285,9 @@ static int ieee80211_ioctl_add_sta(struct net_device *dev,
if (sta-dev != dev) {
/* Binding STA to a new interface, so remove all references to
* the old BSS. */
+ spin_lock_bh(local-sta_lock);
sta_info_remove_aid_ptr(sta);
+ spin_unlock_bh(local-sta_lock);
}
/* TODO
@@ -359,7 +361,7 @@ static int ieee80211_ioctl_remove_sta(struct
net_device *dev,
sta = sta_info_get(local, param-sta_addr);
if (sta) {
sta_info_put(sta);
- sta_info_free(sta, 1);
+ sta_info_free(sta, 0);
}
return sta ? 0 : -ENOENT;
diff --git a/net/d80211/sta_info.c b/net/d80211/sta_info.c
index 0c42ae8..f27bd0e 100644
--- a/net/d80211/sta_info.c
+++ b/net/d80211/sta_info.c
@@ -439,7 +439,7 @@ void sta_info_remove_aid_ptr(struct sta_info *sta)
sdata-local-ops-set_tim(local_to_hw(sdata-local),
sta-aid, 0);
if (sdata-bss)
- bss_tim_clear(sdata-local, sdata-bss, sta-aid);
+ __bss_tim_clear(sdata-bss, sta-aid);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/13] Linux RDMA Core Changes
[Felix Marti] In addition, is arming the CQ really in the performance path? - Don't apps poll the CQ as long as there are pending CQEs and only arm the CQ for notification once there is nothing left to do? If this is the case, it would mean that we waste a few cycles 'idle' cycles. Applications such as IPoIB might queue up packets, then ARM the CQ, and only then they are processed by the upper layers in the stack. So arming the CQ is on hot datapath. -- MST - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.20-rc3: known unfixed regressions (v4)
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject: x86_64 boot failure: IO-APIC + timer doesn't work
References : http://lkml.org/lkml/2006/12/16/101
http://lkml.org/lkml/2007/1/3/9
Submitter : Tobias Diedrich [EMAIL PROTECTED]
Caused-By : Andi Kleen [EMAIL PROTECTED]
commit b026872601976f666bae77b609dc490d1834bf77
Handled-By : Yinghai Lu [EMAIL PROTECTED]
Eric W. Biederman [EMAIL PROTECTED]
Status : patches are being discussed
Subject: BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
http://lkml.org/lkml/2006/12/29/22
http://lkml.org/lkml/2006/12/31/133
Submitter : Jon Smirl [EMAIL PROTECTED]
Damien Wyart [EMAIL PROTECTED]
Aaron Sethman [EMAIL PROTECTED]
Status : unknown
Subject: problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla [EMAIL PROTECTED]
Status : unknown
Subject: USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha [EMAIL PROTECTED]
Status : unknown
Subject: Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel [EMAIL PROTECTED]
Handled-By : Alexey Starikovskiy [EMAIL PROTECTED]
Status : problem is being debugged
Subject: ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro [EMAIL PROTECTED]
Caused-By : YOSHIFUJI Hideaki [EMAIL PROTECTED]
commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
Handled-By : YOSHIFUJI Hideaki [EMAIL PROTECTED]
Status : problem is being debugged
Subject: PIE randomization causes random failures of kernel compiles
References : http://lkml.org/lkml/2007/1/6/124
Submitter : Hugh Dickins [EMAIL PROTECTED]
Caused-By : Marcus Meissner [EMAIL PROTECTED]
commit 59287c0913cc9a6c75712a775f6c1c1ef418ef3b
Handled-By : Hugh Dickins [EMAIL PROTECTED]
Patch : http://lkml.org/lkml/2007/1/6/124
Status : patch was suggested
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: How does TX flow control work?
Jan Kiszka wrote: Jiri Benc wrote: On Wed, 03 Jan 2007 19:10:01 +0100, Jan Kiszka wrote: BUG: warning at /usr/src/rt2x00/rt2x00/ieee80211/ieee80211.c:1256/ieee80211_tx() cfa02245 ieee80211_master_start_xmit+0x105/0x430 [80211] c024e35d __ip_ct_refresh_acct+0x4d/0x60 c024fd11 tcp_packet+0x941/0x970 c0217442 qdisc_restart+0x92/0x100 c020d43d dev_queue_xmit+0xbd/0x1a0 cfa050d8 ieee80211_subif_start_xmit+0x468/0x480 [80211] c0207dca skb_clone+0x3a/0x1a0 c021d16d nf_hook_slow+0x4d/0xc0 c020d495 dev_queue_xmit+0x115/0x1a0 c0226a63 ip_output+0x1c3/0x200 c0225740 ip_finish_output+0x0/0x180 c022628b ip_queue_xmit+0x36b/0x3b0 c0224130 dst_output+0x0/0x10 ce9bae7d usb_hcd_giveback_urb+0x2d/0x60 [usbcore] c0237da2 tcp_v4_send_check+0x82/0xd0 c0237da2 tcp_v4_send_check+0x82/0xd0 c0233244 tcp_transmit_skb+0x5e4/0x610 c0234b36 __tcp_push_pending_frames+0x676/0x740 c0207f81 __alloc_skb+0x51/0x100 c022b817 tcp_sendmsg+0x897/0x980 c0153fa9 core_sys_select+0x1b9/0x2b0 c0241f1d inet_sendmsg+0x3d/0x50 c0202a8f do_sock_write+0x8f/0xa0 c020301f sock_aio_write+0x5f/0x70 c01443d3 do_sync_write+0xc3/0x100 c01247f0 autoremove_wake_function+0x0/0x40 c0144ca1 vfs_write+0xa1/0x140 c01451d3 sys_write+0x43/0x70 c0102ae7 syscall_call+0x7/0xb Does it tell you anything already? Is there something I may instrument? What could the driver do wrong to trigger such bug? Do you have CONFIG_NET_SCHED enabled? Sorry, this was most probably false alarm for the official stack. The problem now appears to be related to a patch against d80211 that is only present in the rt2x00 CVS. Jan signature.asc Description: OpenPGP digital signature
IrDA spams logfiles - since 2.6.19
I'm not on this list, so please keep me CC'ed on this thread.
Since 2.6.19 I've got a problem with my Tekram IRmate 410U
usb-irda-dongle. Until 2.6.18.3 (the latest I had before 2.6.19*)
it worked just fine. 2.6.19.1 had another change in irda-usb
but that didn't solve the problem.
As soon as I load the irda-usb module with the device plugged,
I get lots of messages of following kind into the logs:
irda_usb_hard_xmit(), Insuficient skb headroom.
(the Insuficient-typo is original)
about 7 in a second, then a 2-secs pause. Repeating
until the irda-usb module is removed again.
I then looked up the kernel-source for that particular
typo'ed word, and added some info to the log:
drivers/net/irda/irda-usb.c:448:
if (skb_headroom(skb) self-header_length) {
IRDA_DEBUG(0, %s(), Insuficient skb headroom. %d / %d \n,
__FUNCTION__, skb_headroom(skb) , self-header_length);
...
Which came out as:
irda_usb_hard_xmit(), Insuficient skb headroom. 0 / 1
Thus, while self-header_length == USB_IRDA_HEADER,
I didn't yet understand the meaning of fields
-data and -head of the skb.
I don't know, if the warning itself is right or wrong,
because other than the spamming of logs, transferring
data over irda appears to work just fine.
(I've got timestamps turned on, so usual repeat-compression
by syslogd doesn't take effect.)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
