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
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
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
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
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
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
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
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
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]
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
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
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
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
[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.
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
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
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
17 matches
Mail list logo
