* Re: [WIP] p54: deal with allocation failures in rx path
From: Max Filippov @ 2009-07-06 13:11 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Larry Finger
In-Reply-To: <200907040053.05654.chunkeey@web.de>
> This patch tries to address a long standing issue:
> how to survive serve memory starvation situations,
> without losing the device due to missing transfer-buffers.
Christian, how does placement of skb allocation point make a
difference? Anyway skb that carry data frame will be handed to the mac
and replaced with new one. That is, this patch does not eliminate
possibility of control frame loss due to insufficient memory.
Maybe we'd better have separate reusable skb for control frames which
is never handed out from the driver?
--
Max
^ permalink raw reply
* Re: Insist on cfg80211 for new drivers?
From: Johannes Berg @ 2009-07-06 12:52 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, Luis R. Rodriguez, Dave, Karl Relton, dwmw2,
linux-wireless
In-Reply-To: <20090701193657.GD3473@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
On Wed, 2009-07-01 at 15:36 -0400, John W. Linville wrote:
> On Wed, Jul 01, 2009 at 02:35:00PM -0400, Dan Williams wrote:
>
> > That's really all I
> > care about, I don't want another WEXT-based driver accepted; I want all
> > the new ones using cfg80211.
>
> Now there is a discussion we should have had in Berlin...is it time
> to insist on cfg80211-based configuration for all new drivers?
Should we publish something like this:
http://wireless.kernel.org/wext-statement (don't want it indexed by
google yet so you need to log on to view it), for example on lwn? Just
so more application developers are also aware.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 01/10] ext4: Use rcu_barrier() on module unload.
From: Theodore Tso @ 2009-07-06 2:31 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David S. Miller, Paul E. McKenney, netdev, linux-kernel,
dougthompson, bluesmoke-devel, axboe, Patrick McHardy,
christine.caulfield, Trond.Myklebust, linux-wireless, johannes,
yoshfuji, shemminger, linux-nfs, bfields, neilb, linux-ext4,
adilger, netfilter-devel
In-Reply-To: <20090623150358.22490.24818.stgit@localhost>
On Tue, Jun 23, 2009 at 05:03:59PM +0200, Jesper Dangaard Brouer wrote:
> The ext4 module uses rcu_call() thus it should use rcu_barrier()on
> module unload.
>
> The kmem cache ext4_pspace_cachep is sometimes free'ed using
> call_rcu() callbacks. Thus, we must wait for completion of call_rcu()
> before doing kmem_cache_destroy().
>
> I have difficult determining if no new call_rcu() callbacks can be envoked.
> Would the maintainer please verify this?
Yes, that's correct. Thanks; I've included this in the ext4 patch
queue.
- Ted
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Larry Finger @ 2009-07-06 1:36 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <200907060005.55329.chunkeey@web.de>
Christian Lamparter wrote:
> hmm, can you please give this a go? (I hope this patch still applies...)
> I'm curious if you can dump the tx_queue when p54_alloc_skb fail?
The patch applied with the aid of wiggle. Since adding it, I've had 7
of the disassociation failures, but none of the queue len problems.
I have modified every place that p54_alloc_skb() fails with a printk
that tells why it failed and then calls p54_dump_tx_queue(), but I
have not gotten to test it yet. I found an oops when 2.6.31-rc2 is
booted that I'm bisecting right now.
Larry
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Max Filippov @ 2009-07-05 22:46 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Larry Finger
In-Reply-To: <200907052316.30207.jcmvbkbc@gmail.com>
> > hmm, looks like someone tries to skb_push on a NULL skb. hmmmm,
> > can you please enable ksym, it's a bit hard to see the obvious bug here.
> [ 1612.708465] skb_over_panic: text:bf000544 len:88 put:88 head:c78f4000 data:c78f4020 tail:0xc78f4078 end:0xc78f4020 dev:<NULL>
I see here valid skb with size 0x20, where we try to put 88 more bytes.
That's because p54spi_probe calls __dev_alloc_skb before p54spi_request_firmware.
It's working with the following change:
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index ab5b9b8..ff73a64 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -651,11 +651,6 @@ static int __devinit p54spi_probe(struct spi_device *spi)
priv->common.stop = p54spi_op_stop;
priv->common.tx = p54spi_op_tx;
- skb = __dev_alloc_skb(priv->common.rx_mtu, GFP_KERNEL);
- if (!skb)
- goto err_free_common;
- skb_queue_tail(&priv->rx_pool, skb);
-
ret = p54spi_request_firmware(hw);
if (ret < 0)
goto err_free_common;
@@ -664,6 +659,11 @@ static int __devinit p54spi_probe(struct spi_device *spi)
if (ret)
goto err_free_common;
+ skb = __dev_alloc_skb(priv->common.rx_mtu, GFP_KERNEL);
+ if (!skb)
+ goto err_free_common;
+ skb_queue_tail(&priv->rx_pool, skb);
+
ret = p54_register_common(hw, &priv->spi->dev);
if (ret)
goto err_free_common;
Still cannot stress-test it: it hangs in IBSS mode (I suspect rate control)
and it cannot initialize mesh: firmware doesn't respond after beacon submission.
Does mesh work now with USB/PCI?
Thanks.
-- Max
^ permalink raw reply related
* Re: [WIP] p54: deal with allocation failures in rx path
From: Christian Lamparter @ 2009-07-05 22:05 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <4A50E7C5.4040309@lwfinger.net>
On Sunday 05 July 2009 19:49:57 Larry Finger wrote:
> How sure are you of the locking? It seems that the more threads that
> I'm using, the more likely that it is to happen. Similarly, the
> disassociation errors could be overloading the firmware by adding too
> many entries. Of course, it could result from a firmware error when
> the device is driven hard.
>
> I've only given it one trial, but p54usb only survived for 24 minutes
> running my other torture test with repeating tcpperf in one terminal
> and a flood ping in a second. This one got the disassociation error
> and also a "failure to remove key" (error code -95) and two "failed to
> uodate LEDs" (error code -12).
hmm, can you please give this a go? (I hope this patch still applies...)
I'm curious if you can dump the tx_queue when p54_alloc_skb fail?
---
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 461d88f..1dc1a09 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -246,8 +246,10 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev, struct sk_buff *skb)
struct lm87_tx_hdr *hdr = (void *)skb->data - sizeof(*hdr);
data_urb = usb_alloc_urb(0, GFP_ATOMIC);
- if (!data_urb)
+ if (!data_urb) {
+ p54_free_skb(dev, skb);
return;
+ }
hdr->chksum = p54u_lm87_chksum((__le32 *)skb->data, skb->len);
hdr->device_addr = ((struct p54_hdr *)skb->data)->req_id;
@@ -269,27 +271,22 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev, struct sk_buff *skb)
static void p54u_tx_net2280(struct ieee80211_hw *dev, struct sk_buff *skb)
{
struct p54u_priv *priv = dev->priv;
- struct urb *int_urb, *data_urb;
+ struct urb *int_urb = NULL, *data_urb = NULL;
struct net2280_tx_hdr *hdr = (void *)skb->data - sizeof(*hdr);
- struct net2280_reg_write *reg;
- int err = 0;
+ struct net2280_reg_write *reg = NULL;
+ int err = -ENOMEM;
reg = kmalloc(sizeof(*reg), GFP_ATOMIC);
if (!reg)
- return;
+ goto out;
int_urb = usb_alloc_urb(0, GFP_ATOMIC);
- if (!int_urb) {
- kfree(reg);
- return;
- }
+ if (!int_urb)
+ goto out;
data_urb = usb_alloc_urb(0, GFP_ATOMIC);
- if (!data_urb) {
- kfree(reg);
- usb_free_urb(int_urb);
- return;
- }
+ if (!data_urb)
+ goto out;
reg->port = cpu_to_le16(NET2280_DEV_U32);
reg->addr = cpu_to_le32(P54U_DEV_BASE);
@@ -329,14 +326,12 @@ static void p54u_tx_net2280(struct ieee80211_hw *dev, struct sk_buff *skb)
usb_unanchor_urb(data_urb);
goto out;
}
- out:
+out:
usb_free_urb(int_urb);
usb_free_urb(data_urb);
- if (err) {
- skb_pull(skb, sizeof(*hdr));
+ if (err)
p54_free_skb(dev, skb);
- }
}
static int p54u_write(struct p54u_priv *priv,
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index ea074a6..01eadb1 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -199,7 +199,7 @@ static int p54_tx_qos_accounting_alloc(struct p54_common *priv,
queue = &priv->tx_stats[p54_queue];
spin_lock_irqsave(&priv->tx_stats_lock, flags);
- if (unlikely(queue->len > queue->limit && IS_QOS_QUEUE(p54_queue))) {
+ if (unlikely(queue->len >= queue->limit && IS_QOS_QUEUE(p54_queue))) {
spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
return -ENOSPC;
}
@@ -222,8 +222,11 @@ static void p54_tx_qos_accounting_free(struct p54_common *priv,
if (skb && IS_DATA_FRAME(skb)) {
struct p54_hdr *hdr = (void *) skb->data;
struct p54_tx_data *data = (void *) hdr->data;
+ unsigned long flags;
+ spin_lock_irqsave(&priv->tx_stats_lock, flags);
priv->tx_stats[data->hw_queue].len--;
+ spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
}
p54_wake_queues(priv);
}
@@ -504,7 +507,6 @@ static void p54_rx_eeprom_readback(struct p54_common *priv,
priv->eeprom = NULL;
tmp = p54_find_and_unlink_skb(priv, hdr->req_id);
- p54_tx_qos_accounting_free(priv, tmp);
dev_kfree_skb_any(tmp);
complete(&priv->eeprom_comp);
}
@@ -531,7 +533,6 @@ static void p54_rx_stats(struct p54_common *priv, struct sk_buff *skb)
priv->noise = p54_rssi_to_dbm(priv, le32_to_cpu(stats->noise));
tmp = p54_find_and_unlink_skb(priv, hdr->req_id);
- p54_tx_qos_accounting_free(priv, tmp);
dev_kfree_skb_any(tmp);
}
^ permalink raw reply related
* Re: [PATCH] b43/b43legacy: Fix condition in which radio LED did not initialize correctly, and remove 4 compilation warnings
From: Larry Finger @ 2009-07-05 21:58 UTC (permalink / raw)
To: John W Linville; +Cc: Michael Buesch, Johannes Berg, linux-wireless
> After the recent changes in rfkill, the radio LED used by
> b43/b43legacy
> did not always initialize correctly.
> Both b43 and b43legacy used the deprecated variable radio_enabled in
> struct ieee80211_conf.
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
John,
I have decided to push the LED failure to initialize as a regression
in 2.6.31-rcX. Is there a problem with this patch that has kept it
from being included in wireless-testing?
Larry
^ permalink raw reply
* [PATCH] cfg80211: fix giwrange
From: Johannes Berg @ 2009-07-05 21:13 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Dave
commit c4c496e49ddbf022e51adbd25cedd071329280db
Author: David Kilroy <kilroyd@googlemail.com>
Date: Thu Jun 18 23:21:14 2009 +0100
cfg80211: Advertise ciphers via WE according to driver capability
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
unfortunately broke iwrange -- it used the variable c
that needs to be 0 for the channel list.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/wext-compat.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- wireless-testing.orig/net/wireless/wext-compat.c 2009-07-05 23:10:33.000000000 +0200
+++ wireless-testing/net/wireless/wext-compat.c 2009-07-05 23:10:37.000000000 +0200
@@ -154,7 +154,7 @@ int cfg80211_wext_giwrange(struct net_de
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct iw_range *range = (struct iw_range *) extra;
enum ieee80211_band band;
- int c = 0;
+ int i, c = 0;
if (!wdev)
return -EOPNOTSUPP;
@@ -201,7 +201,7 @@ int cfg80211_wext_giwrange(struct net_de
range->avg_qual.noise = range->max_qual.noise / 2;
range->avg_qual.updated = range->max_qual.updated;
- for (c = 0; c < wdev->wiphy->n_cipher_suites; c++) {
+ for (i = 0; i < wdev->wiphy->n_cipher_suites; i++) {
switch (wdev->wiphy->cipher_suites[c]) {
case WLAN_CIPHER_SUITE_TKIP:
range->enc_capa |= (IW_ENC_CAPA_CIPHER_TKIP |
@@ -226,7 +226,6 @@ int cfg80211_wext_giwrange(struct net_de
}
for (band = 0; band < IEEE80211_NUM_BANDS; band ++) {
- int i;
struct ieee80211_supported_band *sband;
sband = wdev->wiphy->bands[band];
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Max Filippov @ 2009-07-05 19:16 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Larry Finger
In-Reply-To: <200907051600.55958.chunkeey@web.de>
> hmm, looks like someone tries to skb_push on a NULL skb. hmmmm,
> can you please enable ksym, it's a bit hard to see the obvious bug here.
Now it looks so:
[ 1612.708129] p54spi_work
[ 1612.708221] p54spi_rx
[ 1612.708251] p54spi_wakeup
[ 1612.708312] p54spi_wait_bit
[ 1612.708465] skb_over_panic: text:bf000544 len:88 put:88 head:c78f4000 data:c78f4020 tail:0xc78f4078 end:0xc78f4020 dev:<NULL>
[ 1612.721405] kernel BUG at net/core/skbuff.c:127!
[ 1612.728210] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 1612.735687] pgd = c0004000
[ 1612.743225] [00000000] *pgd=00000000
[ 1612.750946] Internal error: Oops: 817 [#1]
[ 1612.758789] Modules linked in: p54spi
[ 1612.766815] CPU: 0 Not tainted (2.6.31-rc1-omap1-wl #5)
[ 1612.775207] PC is at __bug+0x20/0x2c
[ 1612.783721] LR is at release_console_sem+0x1b8/0x1ec
[ 1612.792510] pc : [<c002fb74>] lr : [<c0052dd4>] psr: 60000113
[ 1612.792541] sp : c7aebec8 ip : c7aebdf8 fp : c7aebed4
[ 1612.810119] r10: bf000904 r9 : 00000000 r8 : c7aebf30
[ 1612.818817] r7 : c78f4020 r6 : c78f4078 r5 : c78f4020 r4 : c78f4000
[ 1612.827545] r3 : 00000000 r2 : 60000113 r1 : 0000541c r0 : 0000003a
[ 1612.836334] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 1612.845245] Control: 00c5387d Table: 87fec000 DAC: 00000017
[ 1612.854125] Process phy0 (pid: 400, stack limit = 0xc7aea268)
[ 1612.862976] Stack: (0xc7aebec8 to 0xc7aec000)
[ 1612.871673] bec0: c7aebf0c c7aebed8 c01f5620 c002fb60 c78f4000 c78f4020
[ 1612.881011] bee0: c78f4078 c78f4020 c031c14c 00000000 c784abc0 c78f4020 bf000544 c7be3b34
[ 1612.890411] bf00: c7aebf2c c7aebf10 c01f6878 c01f55d0 c7be3940 c7be3940 00000058 c784abc0
[ 1612.899810] bf20: c7aebf5c c7aebf30 bf000544 c01f6824 00000000 00583680 c7be3afc c7be3afc
[ 1612.909179] bf40: c7be3940 50000000 c7be3b0c c7843680 c7aebf84 c7aebf60 bf000a08 bf000438
[ 1612.918395] bf60: c7abf458 10000000 c7aebf98 c7be3afc c795f780 c7aea000 c7aebfc4 c7aebf88
[ 1612.927368] bf80: c006318c bf000910 c7cccae0 00000000 c7843680 c0066778 c7aebf98 c7aebf98
[ 1612.936370] bfa0: c7aebfcc c7bf5ca0 c795f780 c0063000 00000000 00000000 c7aebff4 c7aebfc8
[ 1612.945190] bfc0: c00664ac c006300c 00000000 00000000 c7aebfd0 c7aebfd0 00000000 00000000
[ 1612.953918] bfe0: 00000000 00000000 00000000 c7aebff8 c0055270 c0066438 804b2021 804b2421
[ 1612.962829] Backtrace:
[ 1612.971343] [<c002fb54>] (__bug+0x0/0x2c) from [<c01f5620>] (skb_over_panic+0x5c/0x68)
[ 1612.980621] [<c01f55c4>] (skb_over_panic+0x0/0x68) from [<c01f6878>] (skb_put+0x60/0x70)
[ 1612.989990] r7:c7be3b34 r6:bf000544 r5:c78f4020 r4:c784abc0
[ 1612.999359] [<c01f6818>] (skb_put+0x0/0x70) from [<bf000544>] (p54spi_rx+0x118/0x190 [p54spi])
[ 1613.009246] r6:c784abc0 r5:00000058 r4:c7be3940
[ 1613.018920] [<bf00042c>] (p54spi_rx+0x0/0x190 [p54spi]) from [<bf000a08>] (p54spi_work+0x104/0x2ec [p54spi])
[ 1613.039001] r8:c7843680 r7:c7be3b0c r6:50000000 r5:c7be3940 r4:c7be3afc
[ 1613.049591] [<bf000904>] (p54spi_work+0x0/0x2ec [p54spi]) from [<c006318c>] (worker_thread+0x18c/0x20c)
[ 1613.070922] r7:c7aea000 r6:c795f780 r5:c7be3afc r4:c7aebf98
[ 1613.081756] [<c0063000>] (worker_thread+0x0/0x20c) from [<c00664ac>] (kthread+0x80/0x84)
[ 1613.092926] [<c006642c>] (kthread+0x0/0x84) from [<c0055270>] (do_exit+0x0/0x5ac)
[ 1613.104125] r7:00000000 r6:00000000 r5:00000000 r4:00000000
[ 1613.115203] Code: e1a01000 e59f000c eb008e3c e3a03000 (e5833000)
[ 1613.126403] ---[ end trace 1e6c70a2c1a5ece6 ]---
Thanks.
-- Max
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Larry Finger @ 2009-07-05 17:49 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <200907051559.32958.chunkeey@web.de>
Christian,
I changed the section in p54_tx_qos_accounting_free() to be the following:
@@ -223,7 +235,10 @@ static void p54_tx_qos_accounting_free(s
struct p54_hdr *hdr = (void *) skb->data;
struct p54_tx_data *data = (void *) hdr->data;
- priv->tx_stats[data->hw_queue].len--;
+ if (priv->tx_stats[data->hw_queue].len)
+ priv->tx_stats[data->hw_queue].len--;
+ else
+ dump_stack();
}
p54_wake_queues(priv);
}
In a 1 hour period running a 'make ARCH=i386 -j6' with the kernel
sources on an NFS mounted volume, I got the following sequence of
"failures":
a. dump_stack() with call from p54_find_and_unlock_skb()
b. dump_stack() with call from p54_find_and_unlock_skb()
c. disassociation error
d. dump_stack() with call from p54_find_and_unlock_skb()
e. dump_stack() with call from p54_find_and_unlock_skb()
f. dump_stack() with call from p54_find_and_unlock_skb()
g. disassociation error
h. disassociation error
i. disassociation error
j. disassociation error
k. dump_stack() with call from p54_find_and_unlock_skb()
l. disassociation error
m. disassociation error
When the dump_stack() occurs, the interface keeps going as long as the
queue len never goes negative. With the disassociation error, the
device must be powered cycled by unplugging and replugging it. The
driver does not need to be reloaded.
If I run the kernel make with -j1 rather than -j6, the builds have
always completed. Neither of the errors show up.
A "paper over the problem" workaround for the queue len < 0 would be
- priv->tx_stats[data->hw_queue].len--;
+ if (priv->tx_stats[data->hw_queue].len)
+ priv->tx_stats[data->hw_queue].len--;
but it doesn't properly fix the problem.
How sure are you of the locking? It seems that the more threads that
I'm using, the more likely that it is to happen. Similarly, the
disassociation errors could be overloading the firmware by adding too
many entries. Of course, it could result from a firmware error when
the device is driven hard.
I've only given it one trial, but p54usb only survived for 24 minutes
running my other torture test with repeating tcpperf in one terminal
and a flood ping in a second. This one got the disassociation error
and also a "failure to remove key" (error code -95) and two "failed to
uodate LEDs" (error code -12).
^ permalink raw reply
* Re: [PATCH] rfkill: prep for rfkill API changes
From: Marcel Holtmann @ 2009-07-05 17:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1246798266.4411.1.camel@johannes.local>
Hi Johannes,
> We've designed the /dev/rfkill API in a way that we
> can increase the event struct by adding members at
> the end, should it become necessary. To validate the
> events, userspace and the kernel need to have the
> proper event size to check for -- when reading from
> the other end they need to verify that it's at least
> version 1 of the event API, with the current struct
> size, so define a constant for that and make the
> code a little more 'future proof'.
>
> Not that I expect that we'll have to change the event
> size any time soon, but it's better to write the code
> in a way that lends itself to extending.
>
> Due to the current size of the event struct, the code
> is currently equivalent, but should the event struct
> ever need to be increased the new code might not need
> changing.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
patch is fine as it is. We have discussed future extensions in this area
and I don't see any problems.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Christian Lamparter @ 2009-07-05 14:00 UTC (permalink / raw)
To: Max Filippov; +Cc: linux-wireless, Larry Finger
In-Reply-To: <200907050457.00689.jcmvbkbc@gmail.com>
On Sunday 05 July 2009 02:56:59 Max Filippov wrote:
> > This patch tries to address a long standing issue:
> > how to survive serve memory starvation situations,
> > without losing the device due to missing transfer-buffers.
> >
> > And with a flick of __GFP_NOWARN, we're able to handle ?all? memory
> > allocation failures on the rx-side during operation without much fuss.
> >
> > However, there is still an issue within the xmit-part.
> > This is likely due to p54's demand for a large free headroom for
> > every outgoing frame:
> >
> > + transport header (differs from device to device)
> > -> 16 bytes transport header (USB 1st gen)
> > -> 8 bytes for (USB 2nd gen)
> > -> 0 bytes for spi & pci
> > + 12 bytes for p54_hdr
> > + 44 bytes for p54_tx_data
> > + up to 3 bytes for alignment
> > (+ 802.11 header as well? )
> >
> > and this is where ieee80211_skb_resize comes into the play...
> > which will try to _relocate_ (alloc new, copy, free old) frame data,
> > as the headroom is most of the time simply not enough.
> > =>
> > Call Trace: (from Larry - Bug #13319 )
> > [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
> > [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
> > [<ffffffff802b6362>] new_slab+0xcf/0x28b
> > [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
> > [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
> > [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
> > [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
> > [<ffffffff802b7e60>] __kmalloc+0x119/0x194
> > [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
> > [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
> > [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211]
> > [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
> > (sl*b debug option will help to bloat even more.)
> >
> > So?! how to prevent ieee80211_skb_resize from raping
> > the bits of memory left?
> >
> > the simplest answer is probably this one:
> > https://dev.openwrt.org/changeset/15761
> > --
> >
> > back to rx failures.
> > the attached code below was only usb was tested so far!
> > you have been warned!
> >
> > regards,
> > chr
> >
> > btw: max what do you think about the p54spi changes, are they total ****?
>
> Christian, I'm trying to test it, but it seems that many things have changed since 2.6.28.
> Right now I see this:
>
> [ 416.738586] Freeing init memory: 140K
> [ 417.208801] cx3110x spi2.0: firmware: requesting 3826.arm
> [ 417.272094] hub 1-0:1.0: hub_suspend
> [ 417.272155] usb usb1: bus auto-suspend
> [ 417.295501] phy0: p54 detected a LM20 firmware
> [ 417.298034] p54: rx_mtu reduced from 3240 to 2376
> [ 417.300598] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
> [ 417.303558] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> [ 417.306732] cx3110x spi2.0: firmware: requesting 3826.eeprom
> [ 417.385742] firmware spi2.0: firmware_loading_store: vmap() failed
> [ 417.391540] cx3110x spi2.0: loading default eeprom...
> [ 417.395568] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
> [ 417.468841] phy0: Selected rate control algorithm 'minstrel'
> [ 417.473693] cx3110x spi2.0: is registered as 'phy0'
> [ 419.150909] g_ether gadget: notify connect false
> [ 419.182891] g_ether gadget: notify speed 425984000
> [ 420.409210] usb0: eth_open
> [ 420.409240] usb0: eth_start
> [ 420.409423] g_ether gadget: ecm_open
> [ 420.409454] g_ether gadget: notify connect true
> [ 420.430908] g_ether gadget: notify speed 425984000
> [ 421.186340] phy0: device now idle
> [ 421.200958] skb_over_panic: text:bf000498 len:2 put:2 head:c793a200 data:c793a220 tail:0xc793a222 end:0xc793a220 dev:<NULL>
> [ 421.211669] kernel BUG at net/core/skbuff.c:127!
> [ 421.217407] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 421.223571] pgd = c0004000
> [ 421.229797] [00000000] *pgd=00000000
> [ 421.236236] Internal error: Oops: 817 [#1]
> [ 421.242736] Modules linked in: p54spi
> [ 421.249420] CPU: 0 Not tainted (2.6.31-rc1-omap1-wl #4)
> [ 421.256378] PC is at __bug+0x1c/0x28
> [ 421.263458] LR is at __bug+0x18/0x28
> [ 421.270538] pc : [<c002f828>] lr : [<c002f824>] psr: 60000113
> [ 421.270568] sp : c798ff20 ip : 00000000 fp : 00000000
> [ 421.284851] r10: 00000000 r9 : 00000000 r8 : c7976b34
> [ 421.291870] r7 : c793a220 r6 : c793a222 r5 : c793a220 r4 : c793a200
> [ 421.298980] r3 : 00000000 r2 : c033cb84 r1 : 000045b2 r0 : 0000003a
> [ 421.306091] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> [ 421.313323] Control: 00c5387d Table: 87fe0000 DAC: 00000017
> [ 421.320526] Process phy0 (pid: 426, stack limit = 0xc798e268)
> [ 421.327697] Stack: (0xc798ff20 to 0xc7990000)
> [ 421.334747] ff20: 00000002 c01dc03c c793a200 c793a220 c793a222 c793a220 c02fba60 00000000
> [ 421.342346] ff40: c798ff40 c784abc0 c793a220 bf000498 c784abc0 c01dd1a8 00000058 c7976940
> [ 421.349975] ff60: c798ff6e bf000498 c798e000 80000058 c7976afc c7976940 50000000 c7976b0c
> [ 421.357574] ff80: 00000000 bf0008ec c796fd20 10000000 c0060510 bf000808 c796fd20 c798e000
> [ 421.365173] ffa0: c0060510 c0060650 c798ffd4 00000000 c78cc9a0 c00636ac c798ffb8 c798ffb8
> [ 421.372558] ffc0: c798ffd4 c7951d98 c796fd20 c0063440 00000000 00000000 c798ffd8 c798ffd8
> [ 421.379730] ffe0: 00000000 00000000 00000000 00000000 00000000 c002cca8 53384842 4e86725f
> [ 421.386993] Code: e1a01000 e59f000c eb0088c3 e3a03000 (e5833000)
> [ 421.394104] ---[ end trace 75ac12f5b28efc30 ]---
>
> Looks like something's wrong with firmware loading.
> I hope to fix it tomorrow and see how your changes work.
hmm, looks like someone tries to skb_push on a NULL skb. hmmmm,
can you please enable ksym, it's a bit hard to see the obvious bug here.
Regards,
Chr
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Christian Lamparter @ 2009-07-05 13:59 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <4A4FC61A.30004@lwfinger.net>
On Saturday 04 July 2009 23:14:02 Larry Finger wrote:
> Larry Finger wrote:
> > @@ -224,6 +236,7 @@ static void p54_tx_qos_accounting_free(s
> > struct p54_tx_data *data = (void *) hdr->data;
> >
> > priv->tx_stats[data->hw_queue].len--;
> > + WARN_ON(priv->tx_stats[data->hw_queue].len < 0);
> > }
> > p54_wake_queues(priv);
> > }
> >
>
> The new WARN_ON did _NOT_ trigger when the len went negative.
Now that's what I call a really cool coincident!
The only _official_ codepath where the queue len actually could be
decremented is not really responsible for this -1!
maybe, after decreasing priv->tx_stats[data->hw_queue].len--;
we should override data->hw_queue (aka mark) and place WARN_ON
everywhere (e.g. p54_free_skb / p54_find_and_unlink_skb & p54_dump_tx_queue
whenever they spot the marker.
(OT: in there's a _wrong_ p54_tx_qos_accounting_free in p54_rx_eeprom_readback
which will be removed...
however its a bit unlikely this causes this havok as the eeprom_readback is a
control frame and therefore p54_tx_qos_accounting_free is a nop for those)
> The only other place where len could be decremented is through
> txhdr->backlog. I noticed that the p54common.c had
>
> txhdr->backlog = current_queue->len;
>
> This was replaced in txrx.c by
>
> txhdr->backlog = priv->tx_stats[queue].len - 1;
>
> Was this intentional?
the spec only says "Number of backlogged frames for given queue."
however there's no word about if this count is for the number of
frames which [are already(now)]/[or will be(old behaviour)]
in the device memory window...
and to add more confusion => there's even a third interpretation:
could be this the number of frames which are still buffered by the driver,
because they don't fit yet?
Now back to the lines:
I somehow fail to see how exactly tx_stats[queue].len gets
decremented here?
as the result of priv->tx_stats[queue].len - 1 will be written into
txhdr->backlog and not priv->tx_stats[queue].len?
it's really a txhdr->backlog = priv->tx_stats[queue].len - 1;
vs.
priv->tx_stats[queue].len = priv->tx_stats[queue].len - 1;
where as the second one is obviously wrong _here_...
> To test if this is the problem, I added the following hunk:
>
> @@ -840,6 +853,7 @@ int p54_tx_80211(struct ieee80211_hw *de
> txhdr->crypt_offset = crypt_offset;
> txhdr->hw_queue = queue;
> txhdr->backlog = priv->tx_stats[queue].len - 1;
> + WARN_ON(!priv->tx_stats[queue].len);
> memset(txhdr->durations, 0, sizeof(txhdr->durations));
> txhdr->tx_antenna = ((info->antenna_sel_tx == 0) ?
> 2 : info->antenna_sel_tx - 1) & priv->tx_diversity_mask;
>
> This WARN_ON did trigger just before txq[6].len went negative. I'm now
> testing with that changed as follows:
>
> @@ -839,7 +852,8 @@ int p54_tx_80211(struct ieee80211_hw *de
> }
> txhdr->crypt_offset = crypt_offset;
> txhdr->hw_queue = queue;
> - txhdr->backlog = priv->tx_stats[queue].len - 1;
> + txhdr->backlog = priv->tx_stats[queue].len;
> + WARN_ON(priv->tx_stats[queue].len < 0);
> memset(txhdr->durations, 0, sizeof(txhdr->durations));
> txhdr->tx_antenna = ((info->antenna_sel_tx == 0) ?
> 2 : info->antenna_sel_tx - 1) & priv->tx_diversity_mask;
>
> This WARN_ON did not trigger, but I still had the queue len go negative.
well, you have to change the WARN_ON to priv->tx_stats[queue].len <= 0 (or ==)
as priv->tx_stats[queue].len will never be 0 here, because it was just
incremented by p54_tx_qos_accounting_alloc.
>
> One other question: struct p54_burst is defined in lmac.h, but it
> doesn't seem to be used anywhere. Will it be needed later?
It's on the todo list...... somewhere.
However, the LMAC API needs to be updated for this.
As there is no description (TBD) about the flags.
Regards,
Chr
^ permalink raw reply
* Re: [PATCH] rfkill: prep for rfkill API changes
From: Johannes Berg @ 2009-07-05 13:38 UTC (permalink / raw)
To: Henrique de Moraes Holschuh; +Cc: John Linville, linux-wireless
In-Reply-To: <20090705132422.GA30334@khazad-dum.debian.net>
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
On Sun, 2009-07-05 at 10:24 -0300, Henrique de Moraes Holschuh wrote:
> This is good, but not complete. Changes to the API that don't change the
> size (or those which reduces it) are a problem: they are impossible with a
> schema that detects API version by the size alone.
Umm, no, we can also add operations as required already.
> Maybe a new field with a API serial number should be added right _now_ while
> it is still not too painful to do it? This would be V2 of the API
> (detectable by the size change), but there aren't many users yet, so the
> effort to support it would not be daunting.
>
> You can also publish the API version through a read-only sysfs attribute or
> a separate IOCTL... it doesn't really need to be in-band (although in-band
> is a lot better).
No.
This patch doesn't change anything at all. It just reduces the
_subtlety_ involved in actually doing a size change, nothing more. A
real event version is _not_ necessary at all. In fact, I would argue
that basing _anything_ on the "version" rather than the "feature set" is
useless.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] rfkill: prep for rfkill API changes
From: Henrique de Moraes Holschuh @ 2009-07-05 13:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1246798266.4411.1.camel@johannes.local>
On Sun, 05 Jul 2009, Johannes Berg wrote:
> We've designed the /dev/rfkill API in a way that we
> can increase the event struct by adding members at
> the end, should it become necessary. To validate the
> events, userspace and the kernel need to have the
> proper event size to check for -- when reading from
> the other end they need to verify that it's at least
> version 1 of the event API, with the current struct
> size, so define a constant for that and make the
> code a little more 'future proof'.
>
> Not that I expect that we'll have to change the event
> size any time soon, but it's better to write the code
> in a way that lends itself to extending.
>
> Due to the current size of the event struct, the code
> is currently equivalent, but should the event struct
> ever need to be increased the new code might not need
> changing.
This is good, but not complete. Changes to the API that don't change the
size (or those which reduces it) are a problem: they are impossible with a
schema that detects API version by the size alone.
Maybe a new field with a API serial number should be added right _now_ while
it is still not too painful to do it? This would be V2 of the API
(detectable by the size change), but there aren't many users yet, so the
effort to support it would not be daunting.
You can also publish the API version through a read-only sysfs attribute or
a separate IOCTL... it doesn't really need to be in-band (although in-band
is a lot better).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* [PATCH] rfkill: prep for rfkill API changes
From: Johannes Berg @ 2009-07-05 12:51 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
We've designed the /dev/rfkill API in a way that we
can increase the event struct by adding members at
the end, should it become necessary. To validate the
events, userspace and the kernel need to have the
proper event size to check for -- when reading from
the other end they need to verify that it's at least
version 1 of the event API, with the current struct
size, so define a constant for that and make the
code a little more 'future proof'.
Not that I expect that we'll have to change the event
size any time soon, but it's better to write the code
in a way that lends itself to extending.
Due to the current size of the event struct, the code
is currently equivalent, but should the event struct
ever need to be increased the new code might not need
changing.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
include/linux/rfkill.h | 14 ++++++++++++++
net/rfkill/core.c | 10 ++++++++--
2 files changed, 22 insertions(+), 2 deletions(-)
--- wireless-testing.orig/include/linux/rfkill.h 2009-07-05 14:39:09.000000000 +0200
+++ wireless-testing/include/linux/rfkill.h 2009-07-05 14:41:58.000000000 +0200
@@ -82,6 +82,20 @@ struct rfkill_event {
__u8 soft, hard;
} __packed;
+/*
+ * We are planning to be backward and forward compatible with changes
+ * to the event struct, by adding new, optional, members at the end.
+ * When reading an event (whether the kernel from userspace or vice
+ * versa) we need to accept anything that's at least as large as the
+ * version 1 event size, but might be able to accept other sizes in
+ * the future.
+ *
+ * One exception is the kernel -- we already have two event sizes in
+ * that we've made the 'hard' member optional since our only option
+ * is to ignore it anyway.
+ */
+#define RFKILL_EVENT_SIZE_V1 8
+
/* ioctl for turning off rfkill-input (if present) */
#define RFKILL_IOC_MAGIC 'R'
#define RFKILL_IOC_NOINPUT 1
--- wireless-testing.orig/net/rfkill/core.c 2009-07-05 14:40:13.000000000 +0200
+++ wireless-testing/net/rfkill/core.c 2009-07-05 14:49:41.000000000 +0200
@@ -1076,10 +1076,16 @@ static ssize_t rfkill_fop_write(struct f
struct rfkill_event ev;
/* we don't need the 'hard' variable but accept it */
- if (count < sizeof(ev) - 1)
+ if (count < RFKILL_EVENT_SIZE_V1 - 1)
return -EINVAL;
- if (copy_from_user(&ev, buf, sizeof(ev) - 1))
+ /*
+ * Copy as much data as we can accept into our 'ev' buffer,
+ * but tell userspace how much we've copied so it can determine
+ * our API version even in a write() call, if it cares.
+ */
+ count = min(count, sizeof(ev));
+ if (copy_from_user(&ev, buf, count))
return -EFAULT;
if (ev.op != RFKILL_OP_CHANGE && ev.op != RFKILL_OP_CHANGE_ALL)
^ permalink raw reply
* Re: kernel crashes, 2.6.30, rt2x00, ath5k, ieee80211_get_*_rate, automatic rate control
From: Bob Copeland @ 2009-07-05 12:31 UTC (permalink / raw)
To: Richard Zidlicky; +Cc: linux-wireless, linville
In-Reply-To: <20090625083636.GA6323@linux-m68k.org>
On Thu, Jun 25, 2009 at 10:36:36AM +0200, Richard Zidlicky wrote:
> > The patch should already be on the way to stable, but I'll check on it.
>
> thanks, you certainly have my vote that it should get into 2.6.30.*
Ok, it has been released in 2.6.30.1.
> On an unrelated note, the ath5k device is in a netbook with an wifi LED and
> Fn-F2 hotkey to toggle wlan.
>
> The hotkey works, the LED not. What do I need to make the LED working on the
> device?
Try latest wireless-testing or 2.6.31-rc1; there may already be a fix
for your hardware thanks to recently added rfkill support.
> Also, while the hotkey works how do query the current on/off status of it
> in Linux?
There's the /dev/rfkill device (see http://git.sipsolutions.net/rfkill.git)
and I believe there are files under /sys/ as well which show the state but
I don't have the details handy (/sys/class/rfkill/xxx/state?).
Also I don't have any hardware with a kill switch/LED so YMMV :)
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Jasin Colegrove @ 2009-07-05 12:13 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <b6c5339f0907020836n6162e8b8k3c1a7a24c335ac41@mail.gmail.com>
Thanks bob for the reply. I did not mean to shout, but someone else
told me that I should make it very clear that I was not subscribed.
But, now I am so it doesn't matter :)
I guess I will just wait to file a bug after I get through the bisect
process and test out the newest compat-wireless drivers. Then I should
have a more clear picture of the issue and maybe enough technical
details to file a proper bug report. Thanks again for your time,
greatly appreciated.
On Thu, Jul 2, 2009 at 11:36 AM, Bob Copeland<me@bobcopeland.com> wrote:
> On Tue, Jun 30, 2009 at 6:50 PM, Jasin
> Colegrove<j.wholesalesupply@gmail.com> wrote:
>> I AM NOT A SUBSCRIBER. Please reply to me directly at this e-mail
>> address j.wholesalesupply@gmail.com
>
> No need to shout -- also common etiquette on Linux kernel lists is
> to "reply-all" anyway :)
>
>> Then I decided to see if it the card was working, So I tried to iwlist
>> wlan0 scan, it returned the expected results.
>
>> I would be glad to offer up as much
>> information as I can, but I don't have the slightest on how to debug
>> this issue?
>
> So to summarize:
>
> 2.6.29 works, 2.6.30 doesn't, ath9k works, ath5k doesn't, userspace
> setup is unchanged. ath5k can get scan results (which means RX is
> working at least some of the time) but dhcp does not.
>
> You said you are comfortable with the command line, in that case the
> easiest way to debug the change is to just bisect the ath5k changes
> using git. There were only 50 or so patches since 2.6.29 so you will
> likely only need to compile the kernel 5 or 6 times. You can do
> something like:
>
> $ git bisect start v2.6.30 v2.6.29 -- drivers/net/wireless/ath5k
>
>> Any help on that issue is much appreciated. Where can I
>> file the appropriate bug and what information do I need to post from a
>> technical standpoint.
>
> http://bugzilla.kernel.org/ is where you would file it, the information
> you've already given here is a good start.
>
> --
> Bob Copeland %% www.bobcopeland.com
>
^ permalink raw reply
* Re: current status of 802.11s mesh in ath5k ?
From: Bob Copeland @ 2009-07-05 12:05 UTC (permalink / raw)
To: Andrey Yurovsky; +Cc: Hans Maes, linux-wireless
In-Reply-To: <45e8e6c40906191042k5c96d3a6wff85358da22a7b92@mail.gmail.com>
On Fri, Jun 19, 2009 at 10:42:22AM -0700, Andrey Yurovsky wrote:
> > I have been working on a patch to rework the beaconing, namely using
> > bss_conf->enable_beacon and calling beacon_config whenever the beacon
> > interval or beacon changes, that might fix it but I'm not too familiar
> > with mesh details to say.
>
> 'looking forward to that patch. From the driver side, there's not
> much difference between mesh beaconing and AP or IBSS beaconing.
Can you check whether my most recent patch (I think it was 2/5 in the
ath5k series) helps? I looked at mac80211 and it seems we set
enable_beacon properly in mesh mode so that should configure beaconing
to start.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: ath5k AP support?
From: Bob Copeland @ 2009-07-05 12:02 UTC (permalink / raw)
To: Tomasz Chmielewski; +Cc: linux-wireless
In-Reply-To: <4A3AA20C.6020908@wpkg.org>
On Thu, Jun 18, 2009 at 10:22:36PM +0200, Tomasz Chmielewski wrote:
> Oh well.
> The above is with hostapd 0.7.0 snapshot.
> With 0.6.9 I can connect and the connection works fine
>
> Is it normal?
I'm not sure -- do you have anything in dmesg?
I've noticed a strange bug lately where some packets to the STA get dropped
due to some kind of off-by-u32 bug. I haven't tracked it down yet to
any certain combination of ath5k/w-t/hostapd, though.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 4/5] ath5k: do not release irq across suspend/resume
From: Bob Copeland @ 2009-07-05 11:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jiri Slaby, linville, mickflemm, lrodriguez, linux-wireless,
ath5k-devel
In-Reply-To: <200907042337.59470.rjw@sisk.pl>
On Sat, Jul 04, 2009 at 11:37:58PM +0200, Rafael J. Wysocki wrote:
> Someone recently asked on a mailing list (unfortunately I can't recall
> which one) if drivers should release irqs over suspend.
Yeah, it was linux-wireless. Original message is here:
http://marc.info/?l=linux-wireless&m=124515641807355
(The paraphrasing is rather liberal but that was the gist.)
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: BUG REPORT: libertas causing kernel lockups
From: Alexander Barinov @ 2009-07-05 8:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1246704102.16770.71.camel@johannes.local>
On Sat, 04 Jul 2009 12:41:42 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> On Sat, 2009-07-04 at 13:03 +0400, Alexander Barinov wrote:
> > The initial symptom of the bug was system lockup when executing
> > 'ifdown eth0' with 'BUG: scheduling while atomic'. Trying to
> > understand the cause of the bug and find a workaround I was able to
> > find an easier way to reproduce it. By executing
> > 'cat /proc/net/wireless' I get the same bug:
> This should have been fixed by
> 87057825824973f29cf2f37cff1e549170b2d7e6. For some reason everybody
> seems to have assumed that get_wireless_stats can sleep, which before
> that commit it could _not_.
The patch you have mentioned was not directly applicable to 2.6.30
kernel so I pulled wireless-testing git tree and compiled it. This
deteriorated the situation further - now after executing
'cat /proc/net/wireless' I get kernel lockup without any further
messages.
^ permalink raw reply
* Re: [PATCH] iwmc3200wifi: cfg80211 managed mode port
From: Johannes Berg @ 2009-07-05 1:37 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Zhu, Yi, John Linville, linux-wireless@vger.kernel.org
In-Reply-To: <20090702235513.GA4143@sortiz.org>
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
On Fri, 2009-07-03 at 01:55 +0200, Samuel Ortiz wrote:
> @@ -521,7 +521,10 @@ static int iwm_mlme_assoc_complete(struc
- union iwreq_data wrqu;
- memset(&wrqu, 0, sizeof(wrqu));
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 5/5] ath5k: write PCU registers on initial reset
From: Bob Copeland @ 2009-07-05 1:03 UTC (permalink / raw)
To: Felix Fietkau
Cc: linville, jirislaby, mickflemm, lrodriguez, linux-wireless,
ath5k-devel, stable
In-Reply-To: <4A4FA224.40006@openwrt.org>
Commit d7dc100374df0c21afd8a198336ecd7999697159, "Ath5k: unify resets"
introduced a regression into 2.6.28 where the PCU registers are never
initialized, due to ath5k_reset() always passing true for change_channel.
We subsequently program a lot of these registers but several may start
in an unknown state.
Cc: stable@kernel.org
Reported-by: Forrest Zhang <forrest@hifulltech.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
v2, without dumb thinko
drivers/net/wireless/ath/ath5k/base.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 3f55e90..80ae38d 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2687,7 +2687,7 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
sc->curchan = chan;
sc->curband = &sc->sbands[chan->band];
}
- ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, true);
+ ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, chan != NULL);
if (ret) {
ATH5K_ERR(sc, "can't reset hardware (%d)\n", ret);
goto err;
--
1.6.2.5
^ permalink raw reply related
* Re: [WIP] p54: deal with allocation failures in rx path
From: Max Filippov @ 2009-07-05 0:56 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Larry Finger
In-Reply-To: <200907040053.05654.chunkeey@web.de>
> This patch tries to address a long standing issue:
> how to survive serve memory starvation situations,
> without losing the device due to missing transfer-buffers.
>
> And with a flick of __GFP_NOWARN, we're able to handle ?all? memory
> allocation failures on the rx-side during operation without much fuss.
>
> However, there is still an issue within the xmit-part.
> This is likely due to p54's demand for a large free headroom for
> every outgoing frame:
>
> + transport header (differs from device to device)
> -> 16 bytes transport header (USB 1st gen)
> -> 8 bytes for (USB 2nd gen)
> -> 0 bytes for spi & pci
> + 12 bytes for p54_hdr
> + 44 bytes for p54_tx_data
> + up to 3 bytes for alignment
> (+ 802.11 header as well? )
>
> and this is where ieee80211_skb_resize comes into the play...
> which will try to _relocate_ (alloc new, copy, free old) frame data,
> as the headroom is most of the time simply not enough.
> =>
> Call Trace: (from Larry - Bug #13319 )
> [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
> [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
> [<ffffffff802b6362>] new_slab+0xcf/0x28b
> [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
> [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
> [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
> [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
> [<ffffffff802b7e60>] __kmalloc+0x119/0x194
> [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
> [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
> [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211]
> [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
> (sl*b debug option will help to bloat even more.)
>
> So?! how to prevent ieee80211_skb_resize from raping
> the bits of memory left?
>
> the simplest answer is probably this one:
> https://dev.openwrt.org/changeset/15761
> --
>
> back to rx failures.
> the attached code below was only usb was tested so far!
> you have been warned!
>
> regards,
> chr
>
> btw: max what do you think about the p54spi changes, are they total ****?
Christian, I'm trying to test it, but it seems that many things have changed since 2.6.28.
Right now I see this:
[ 416.738586] Freeing init memory: 140K
[ 417.208801] cx3110x spi2.0: firmware: requesting 3826.arm
[ 417.272094] hub 1-0:1.0: hub_suspend
[ 417.272155] usb usb1: bus auto-suspend
[ 417.295501] phy0: p54 detected a LM20 firmware
[ 417.298034] p54: rx_mtu reduced from 3240 to 2376
[ 417.300598] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
[ 417.303558] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
[ 417.306732] cx3110x spi2.0: firmware: requesting 3826.eeprom
[ 417.385742] firmware spi2.0: firmware_loading_store: vmap() failed
[ 417.391540] cx3110x spi2.0: loading default eeprom...
[ 417.395568] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
[ 417.468841] phy0: Selected rate control algorithm 'minstrel'
[ 417.473693] cx3110x spi2.0: is registered as 'phy0'
[ 419.150909] g_ether gadget: notify connect false
[ 419.182891] g_ether gadget: notify speed 425984000
[ 420.409210] usb0: eth_open
[ 420.409240] usb0: eth_start
[ 420.409423] g_ether gadget: ecm_open
[ 420.409454] g_ether gadget: notify connect true
[ 420.430908] g_ether gadget: notify speed 425984000
[ 421.186340] phy0: device now idle
[ 421.200958] skb_over_panic: text:bf000498 len:2 put:2 head:c793a200 data:c793a220 tail:0xc793a222 end:0xc793a220 dev:<NULL>
[ 421.211669] kernel BUG at net/core/skbuff.c:127!
[ 421.217407] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 421.223571] pgd = c0004000
[ 421.229797] [00000000] *pgd=00000000
[ 421.236236] Internal error: Oops: 817 [#1]
[ 421.242736] Modules linked in: p54spi
[ 421.249420] CPU: 0 Not tainted (2.6.31-rc1-omap1-wl #4)
[ 421.256378] PC is at __bug+0x1c/0x28
[ 421.263458] LR is at __bug+0x18/0x28
[ 421.270538] pc : [<c002f828>] lr : [<c002f824>] psr: 60000113
[ 421.270568] sp : c798ff20 ip : 00000000 fp : 00000000
[ 421.284851] r10: 00000000 r9 : 00000000 r8 : c7976b34
[ 421.291870] r7 : c793a220 r6 : c793a222 r5 : c793a220 r4 : c793a200
[ 421.298980] r3 : 00000000 r2 : c033cb84 r1 : 000045b2 r0 : 0000003a
[ 421.306091] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 421.313323] Control: 00c5387d Table: 87fe0000 DAC: 00000017
[ 421.320526] Process phy0 (pid: 426, stack limit = 0xc798e268)
[ 421.327697] Stack: (0xc798ff20 to 0xc7990000)
[ 421.334747] ff20: 00000002 c01dc03c c793a200 c793a220 c793a222 c793a220 c02fba60 00000000
[ 421.342346] ff40: c798ff40 c784abc0 c793a220 bf000498 c784abc0 c01dd1a8 00000058 c7976940
[ 421.349975] ff60: c798ff6e bf000498 c798e000 80000058 c7976afc c7976940 50000000 c7976b0c
[ 421.357574] ff80: 00000000 bf0008ec c796fd20 10000000 c0060510 bf000808 c796fd20 c798e000
[ 421.365173] ffa0: c0060510 c0060650 c798ffd4 00000000 c78cc9a0 c00636ac c798ffb8 c798ffb8
[ 421.372558] ffc0: c798ffd4 c7951d98 c796fd20 c0063440 00000000 00000000 c798ffd8 c798ffd8
[ 421.379730] ffe0: 00000000 00000000 00000000 00000000 00000000 c002cca8 53384842 4e86725f
[ 421.386993] Code: e1a01000 e59f000c eb0088c3 e3a03000 (e5833000)
[ 421.394104] ---[ end trace 75ac12f5b28efc30 ]---
Looks like something's wrong with firmware loading.
I hope to fix it tomorrow and see how your changes work.
Thanks.
-- Max
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox