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
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() >>> ieee80211_master_start_xmit+0x105/0x430 [80211] >>> __ip_ct_refresh_acct+0x4d/0x60 >>> tcp_packet+0x941/0x970 qdisc_restart+0x92/0x100 >>> dev_queue_xmit+0xbd/0x1a0 >>> ieee80211_subif_start_xmit+0x468/0x480 [80211] >>> skb_clone+0x3a/0x1a0 nf_hook_slow+0x4d/0xc0 >>> dev_queue_xmit+0x115/0x1a0 ip_output+0x1c3/0x200 >>> ip_finish_output+0x0/0x180 ip_queue_xmit+0x36b/0x3b0 >>> dst_output+0x0/0x10 usb_hcd_giveback_urb+0x2d/0x60 >>> [usbcore] >>> tcp_v4_send_check+0x82/0xd0 >>> tcp_v4_send_check+0x82/0xd0 >>> tcp_transmit_skb+0x5e4/0x610 >>> __tcp_push_pending_frames+0x676/0x740 >>> __alloc_skb+0x51/0x100 tcp_sendmsg+0x897/0x980 >>> core_sys_select+0x1b9/0x2b0 inet_sendmsg+0x3d/0x50 >>> do_sock_write+0x8f/0xa0 sock_aio_write+0x5f/0x70 >>> do_sync_write+0xc3/0x100 >>> autoremove_wake_function+0x0/0x40 >>> vfs_write+0xa1/0x140 sys_write+0x43/0x70 >>> 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
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: [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] 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
[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-netdev&m=116584793808733&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=116584793729158&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=116593164226253&w=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 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
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] 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
[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
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
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 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
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 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
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
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] [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