* 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
* Re: [PATCH 5/5] ath5k: write PCU registers on initial reset
From: Bob Copeland @ 2009-07-05 0:41 UTC (permalink / raw)
To: Felix Fietkau
Cc: linville, jirislaby, mickflemm, lrodriguez, linux-wireless,
ath5k-devel, stable
In-Reply-To: <4A4FA224.40006@openwrt.org>
>> }
>> - ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, true);
>> + ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, chan == NULL);
>
> Shouldn't this be chan != NULL? I'd assume that chan is NULL the first
> time and change_channel thus should be false to initialize all the
> registers.
Yup, it should... I could swear I tested it, must've gotten lucky.
Thanks for the catch.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 4/5] ath5k: do not release irq across suspend/resume
From: Rafael J. Wysocki @ 2009-07-04 21:37 UTC (permalink / raw)
To: Jiri Slaby
Cc: Bob Copeland, linville, mickflemm, lrodriguez, linux-wireless,
ath5k-devel
In-Reply-To: <4A4FC889.9000401@gmail.com>
On Saturday 04 July 2009, Jiri Slaby wrote:
> On 07/04/2009 06:59 PM, Bob Copeland wrote:
> > Paraphrasing Rafael J. Wysocki: "drivers should not release PCI IRQs
> > in suspend." Doing so causes a warning during suspend/resume on some
> > platforms.
>
> Hmm, I added it because I was told an irq can change over suspend (or at
> least it could in the past). I think it's not true anymore, since we
> would have serious problems with the code all over the tree.
>
> I can't find where Rafael uttered those words above, do you have a link?
Someone recently asked on a mailing list (unfortunately I can't recall
which one) if drivers should release irqs over suspend.
The answer was more-or-less that drivers are not expected to do that and it
really is not recommended. In fact, we do the whole suspend_device_irqs()
thing, because the drivers are expected not to do that.
Best,
Rafael
^ permalink raw reply
* Re: [PATCH 4/5] ath5k: do not release irq across suspend/resume
From: Jiri Slaby @ 2009-07-04 21:24 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, mickflemm, lrodriguez, linux-wireless, ath5k-devel,
Rafael J. Wysocki
In-Reply-To: <1246726795-3934-5-git-send-email-me@bobcopeland.com>
On 07/04/2009 06:59 PM, Bob Copeland wrote:
> Paraphrasing Rafael J. Wysocki: "drivers should not release PCI IRQs
> in suspend." Doing so causes a warning during suspend/resume on some
> platforms.
Hmm, I added it because I was told an irq can change over suspend (or at
least it could in the past). I think it's not true anymore, since we
would have serious problems with the code all over the tree.
I can't find where Rafael uttered those words above, do you have a link?
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Thanks.
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Larry Finger @ 2009-07-04 21:14 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <4A4FB3F2.5050405@lwfinger.net>
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.
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?
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.
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?
Larry
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Larry Finger @ 2009-07-04 19:56 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <200907041928.32269.chunkeey@web.de>
Christian Lamparter wrote:
> On Saturday 04 July 2009 18:40:14 Larry Finger wrote:
>> I have logged the usb transfers, but not yet analyzed them.
> great!
>
>> This time I got a new failure - I hit this warning at
>> net/mac80211/tx.c:1299
>> retries++;
>> if (WARN(retries > 10, "tx refused but queue
>> active\n"))
>> goto drop;
>> goto retry;
>>
>
>> If I have analyzed this correctly, I hit this section of
>> p54_tx_qos_accounting_alloc at drivers/net/wireless/p54/txrx.c:204.
>> I'm running the splitup patches.
>>
>> if (unlikely(queue->len > queue->limit &&
>> IS_QOS_QUEUE(p54_queue))) {
>> spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
>> return -ENOSPC;
>> }
>>
>> Any suggestions on debugging this would be appreciated.
> ---
> diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
> index ea074a6..69fc70a 100644
> --- a/drivers/net/wireless/p54/txrx.c
> +++ b/drivers/net/wireless/p54/txrx.c
> @@ -25,6 +25,7 @@
> #include "p54.h"
> #include "lmac.h"
>
> +#define P54_MM_DEBUG
> #ifdef P54_MM_DEBUG
> static void p54_dump_tx_queue(struct p54_common *priv)
> {
> @@ -200,7 +201,18 @@ static int p54_tx_qos_accounting_alloc(struct p54_common *priv,
>
> spin_lock_irqsave(&priv->tx_stats_lock, flags);
> if (unlikely(queue->len > queue->limit && IS_QOS_QUEUE(p54_queue))) {
> + u16 ac_queue = p54_queue - P54_QUEUE_DATA;
> + int i;
> +
> + printk(KERN_DEBUG "TX queue stats\n");
> + for (i = 0; i < 8; i++)
> + printk(KERN_DEBUG "\ttxq[%d]: used %d [of %d] => %s\n",
> + i, priv->tx_stats[i].len,
> + priv->tx_stats[i].limit,
> + ieee80211_queue_stopped(priv->hw, ac_queue) ?
> + "stopped" : "running");
> spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
> + p54_dump_tx_queue(priv);
> return -ENOSPC;
> }
>
> ---
> let's hope the queue .len count does not turn negative!
Sorry. It did. The output of the printk is:
TX queue stats
txq[0]: used 0 [of 1] => running
txq[1]: used 0 [of 1] => running
txq[2]: used 0 [of 3] => running
txq[3]: used 0 [of 3] => running
txq[4]: used 0 [of 16] => running
txq[5]: used 0 [of 16] => running
txq[6]: used -1 [of 16] => running
txq[7]: used 0 [of 16] => running
phy5: / --- tx queue dump (0 entries) ---
phy5: \ --- [free: 14592], largest free block: 14592 ---
I added this statement for debugging:
@@ -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);
}
Since I added that, I have gotten about 15 of the "wlan0: no probe
response from AP 00:1a:70:46:ba:b1 - disassociating" situations where
the interface goes offline, but no more of the negative queue len
variety. It looks as if I will need to debug it first.
Larry
^ permalink raw reply
* Re: ath5k and Atheros AR242x - No scan results
From: Joel Roth @ 2009-07-04 19:10 UTC (permalink / raw)
To: Joel Roth; +Cc: Nick Kossifidis, linux-wireless
In-Reply-To: <20090701072434.GB7647@sprite>
On Tue, Jun 30, 2009 at 09:24:34PM -1000, Joel Roth wrote:
> On Wed, Jul 01, 2009 at 12:16:47AM +0300, Nick Kossifidis wrote:
> > 2009/6/30 Joel Roth <joelz@pobox.com>:
> > > Hello all,
> > >
> > > I'd appreciate some help troubleshooting my wireless connection.
> > >
> > > I have a Toshiba Satellite L305 series laptop running Debian
> > > sid with a recent, stock Debian kernel version 2.6.29-2-486.
> > >
> > > $ lspci | grep Atheros
> > >
> > > 05:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
> > >
> > > I am seeking to connect to a D-Link 614+ wireless router.
> > > For initial testing, the AP is unencrypted, unsecured.
> > >
> > > My wife's G3 i-Book with AfterTheMac USB wireless adapter
> > > connected just fine, on the first try.
> > >
> > > I believe I have the modules I should have:
> > >
> > > $ lsmod | grep 80211
> > > mac80211 139680 1 ath5k
> > > cfg80211 21576 2 ath5k,mac80211
> > >
> > > My wireless network interface is present:
> > >
> > > $ iwconfig wlan0
> > >
> > > wlan0 IEEE 802.11 ESSID:""
> > > Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
> > > Tx-Power=0 dBm
> > > Retry min limit:7 RTS thr:off Fragment thr=2352 B
> > > Link Quality:0 Signal level:0 Noise level:0
> > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> > > Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> > >
> > > $ ifconfig wlan0
> > >
> > > wlan0 Link encap:Ethernet HWaddr 00:21:63:82:82:40
> > > UP BROADCAST MULTICAST MTU:1500 Metric:1
> > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> > > collisions:0 txqueuelen:1000
> > > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> > >
> > >
> > > However, I don't find the D-Link 614+:
> > >
> > > $ iwlist wlan0 scan
> > >
> > > wlan0 No scan results
> > >
> > > And of course, dhclient fails to find a server.
> > >
> > > Am I missing something? What could I try next?
> > > I'd appreciate any pointers.
> > >
> > > Thanks.
> > >
> > > --
> > > Joel Roth
> >
> > Hello ;-)
> >
> > Can you please sent the dmesg output when ath5k loads ?
> > Also do you see any messages on dmesg while scaning ?
>
> Hi :-)
>
> On loading the ath5k driver, dmesg reports:
>
> [83838.020161] ath5k 0000:05:00.0: PCI INT A disabled
> [83852.364249] cfg80211: Using static regulatory domain info
> [83852.364253] cfg80211: Regulatory domain: US
> [83852.364255] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [83852.364258] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> [83852.364261] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [83852.364264] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [83852.364266] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [83852.364269] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [83852.364271] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> [83852.364274] cfg80211: Calling CRDA for country: US
> [83852.427844] ath5k 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> [83852.427858] ath5k 0000:05:00.0: setting latency timer to 64
> [83852.427916] ath5k 0000:05:00.0: registered as 'phy0'
> [83852.620221] wmaster0 (ath5k): not using net_device_ops yet
> [83852.620896] phy0: Selected rate control algorithm 'minstrel'
> [83852.620913] wlan0 (ath5k): not using net_device_ops yet
> [83852.621565] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
>
> On attempting to scan:
>
> [84202.916169] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>
> Thanks!
Is there anything I can glean from these diagnostics?
I can certainly compile a more recent version of the
driver.
Anything else I might try to get this hardware working
for me?
Regards,
--
Joel Roth
^ permalink raw reply
* Re: [PATCH 5/5] ath5k: write PCU registers on initial reset
From: Felix Fietkau @ 2009-07-04 18:40 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, jirislaby, mickflemm, lrodriguez, linux-wireless,
ath5k-devel, stable
In-Reply-To: <1246726795-3934-6-git-send-email-me@bobcopeland.com>
Bob Copeland wrote:
> 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>
> ---
> 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);
Shouldn't this be chan != NULL? I'd assume that chan is NULL the first
time and change_channel thus should be false to initialize all the
registers.
- Felix
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Christian Lamparter @ 2009-07-04 17:28 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <4A4F85EE.5090007@lwfinger.net>
On Saturday 04 July 2009 18:40:14 Larry Finger wrote:
> I have logged the usb transfers, but not yet analyzed them.
great!
> This time I got a new failure - I hit this warning at
> net/mac80211/tx.c:1299
> retries++;
> if (WARN(retries > 10, "tx refused but queue
> active\n"))
> goto drop;
> goto retry;
>
> If I have analyzed this correctly, I hit this section of
> p54_tx_qos_accounting_alloc at drivers/net/wireless/p54/txrx.c:204.
> I'm running the splitup patches.
>
> if (unlikely(queue->len > queue->limit &&
> IS_QOS_QUEUE(p54_queue))) {
> spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
> return -ENOSPC;
> }
>
> Any suggestions on debugging this would be appreciated.
---
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index ea074a6..69fc70a 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -25,6 +25,7 @@
#include "p54.h"
#include "lmac.h"
+#define P54_MM_DEBUG
#ifdef P54_MM_DEBUG
static void p54_dump_tx_queue(struct p54_common *priv)
{
@@ -200,7 +201,18 @@ static int p54_tx_qos_accounting_alloc(struct p54_common *priv,
spin_lock_irqsave(&priv->tx_stats_lock, flags);
if (unlikely(queue->len > queue->limit && IS_QOS_QUEUE(p54_queue))) {
+ u16 ac_queue = p54_queue - P54_QUEUE_DATA;
+ int i;
+
+ printk(KERN_DEBUG "TX queue stats\n");
+ for (i = 0; i < 8; i++)
+ printk(KERN_DEBUG "\ttxq[%d]: used %d [of %d] => %s\n",
+ i, priv->tx_stats[i].len,
+ priv->tx_stats[i].limit,
+ ieee80211_queue_stopped(priv->hw, ac_queue) ?
+ "stopped" : "running");
spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
+ p54_dump_tx_queue(priv);
return -ENOSPC;
}
---
let's hope the queue .len count does not turn negative!
regards,
Chr
^ permalink raw reply related
* [PATCH 4/5] ath5k: do not release irq across suspend/resume
From: Bob Copeland @ 2009-07-04 16:59 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland, Rafael J. Wysocki
In-Reply-To: <1246726795-3934-1-git-send-email-me@bobcopeland.com>
Paraphrasing Rafael J. Wysocki: "drivers should not release PCI IRQs
in suspend." Doing so causes a warning during suspend/resume on some
platforms.
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 4829329..3f55e90 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -674,7 +674,6 @@ ath5k_pci_suspend(struct pci_dev *pdev, pm_message_t state)
ath5k_led_off(sc);
- free_irq(pdev->irq, sc);
pci_save_state(pdev);
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
@@ -702,18 +701,8 @@ ath5k_pci_resume(struct pci_dev *pdev)
*/
pci_write_config_byte(pdev, 0x41, 0);
- err = request_irq(pdev->irq, ath5k_intr, IRQF_SHARED, "ath", sc);
- if (err) {
- ATH5K_ERR(sc, "request_irq failed\n");
- goto err_no_irq;
- }
-
ath5k_led_enable(sc);
return 0;
-
-err_no_irq:
- pci_disable_device(pdev);
- return err;
}
#endif /* CONFIG_PM */
--
1.6.2.5
^ permalink raw reply related
* [PATCH 5/5] ath5k: write PCU registers on initial reset
From: Bob Copeland @ 2009-07-04 16:59 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland, stable
In-Reply-To: <1246726795-3934-1-git-send-email-me@bobcopeland.com>
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>
---
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
* [PATCH 1/5] ath5k: send buffered frames after the beacon
From: Bob Copeland @ 2009-07-04 16:59 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
In-Reply-To: <1246726795-3934-1-git-send-email-me@bobcopeland.com>
Enable the "Content" After Beacon queue and utilize it to send
any buffered frames for power-saving clients.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 35 ++++++++++++++++++++++++++++----
drivers/net/wireless/ath/ath5k/base.h | 9 +++----
drivers/net/wireless/ath/ath5k/qcu.c | 1 -
3 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index c6e7091..87ebc46 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -218,6 +218,8 @@ static struct pci_driver ath5k_pci_driver = {
* Prototypes - MAC 802.11 stack related functions
*/
static int ath5k_tx(struct ieee80211_hw *hw, struct sk_buff *skb);
+static int ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
+ struct ath5k_txq *txq);
static int ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan);
static int ath5k_reset_wake(struct ath5k_softc *sc);
static int ath5k_start(struct ieee80211_hw *hw);
@@ -301,7 +303,8 @@ static void ath5k_desc_free(struct ath5k_softc *sc,
static int ath5k_rxbuf_setup(struct ath5k_softc *sc,
struct ath5k_buf *bf);
static int ath5k_txbuf_setup(struct ath5k_softc *sc,
- struct ath5k_buf *bf);
+ struct ath5k_buf *bf,
+ struct ath5k_txq *txq);
static inline void ath5k_txbuf_free(struct ath5k_softc *sc,
struct ath5k_buf *bf)
{
@@ -516,6 +519,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
/* Initialize driver private data */
SET_IEEE80211_DEV(hw, &pdev->dev);
hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
+ IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_NOISE_DBM;
@@ -789,12 +793,18 @@ ath5k_attach(struct pci_dev *pdev, struct ieee80211_hw *hw)
goto err_desc;
}
sc->bhalq = ret;
+ sc->cabq = ath5k_txq_setup(sc, AR5K_TX_QUEUE_CAB, 0);
+ if (IS_ERR(sc->cabq)) {
+ ATH5K_ERR(sc, "can't setup cab queue\n");
+ ret = PTR_ERR(sc->cabq);
+ goto err_bhal;
+ }
sc->txq = ath5k_txq_setup(sc, AR5K_TX_QUEUE_DATA, AR5K_WME_AC_BK);
if (IS_ERR(sc->txq)) {
ATH5K_ERR(sc, "can't setup xmit queue\n");
ret = PTR_ERR(sc->txq);
- goto err_bhal;
+ goto err_queues;
}
tasklet_init(&sc->rxtq, ath5k_tasklet_rx, (unsigned long)sc);
@@ -1232,10 +1242,10 @@ ath5k_rxbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf)
}
static int
-ath5k_txbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf)
+ath5k_txbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf,
+ struct ath5k_txq *txq)
{
struct ath5k_hw *ah = sc->ah;
- struct ath5k_txq *txq = sc->txq;
struct ath5k_desc *ds = bf->desc;
struct sk_buff *skb = bf->skb;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
@@ -2103,6 +2113,7 @@ ath5k_beacon_send(struct ath5k_softc *sc)
{
struct ath5k_buf *bf = sc->bbuf;
struct ath5k_hw *ah = sc->ah;
+ struct sk_buff *skb;
ATH5K_DBG_UNLIMIT(sc, ATH5K_DEBUG_BEACON, "in beacon_send\n");
@@ -2156,6 +2167,12 @@ ath5k_beacon_send(struct ath5k_softc *sc)
ATH5K_DBG(sc, ATH5K_DEBUG_BEACON, "TXDP[%u] = %llx (%p)\n",
sc->bhalq, (unsigned long long)bf->daddr, bf->desc);
+ skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
+ while (skb) {
+ ath5k_tx_queue(sc->hw, skb, sc->cabq);
+ skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
+ }
+
sc->bsent++;
}
@@ -2603,6 +2620,14 @@ static int
ath5k_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
{
struct ath5k_softc *sc = hw->priv;
+
+ return ath5k_tx_queue(hw, skb, sc->txq);
+}
+
+static int ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
+ struct ath5k_txq *txq)
+{
+ struct ath5k_softc *sc = hw->priv;
struct ath5k_buf *bf;
unsigned long flags;
int hdrlen;
@@ -2646,7 +2671,7 @@ ath5k_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
bf->skb = skb;
- if (ath5k_txbuf_setup(sc, bf)) {
+ if (ath5k_txbuf_setup(sc, bf, txq)) {
bf->skb = NULL;
spin_lock_irqsave(&sc->txbuflock, flags);
list_add_tail(&bf->list, &sc->txbuf);
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index f9b7f2f..65e75fb 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -114,8 +114,7 @@ struct ath5k_softc {
struct pci_dev *pdev; /* for dma mapping */
void __iomem *iobase; /* address of the device */
struct mutex lock; /* dev-level lock */
- /* FIXME: how many does it really need? */
- struct ieee80211_tx_queue_stats tx_stats[16];
+ struct ieee80211_tx_queue_stats tx_stats[AR5K_NUM_TX_QUEUES];
struct ieee80211_low_level_stats ll_stats;
struct ieee80211_hw *hw; /* IEEE 802.11 common */
struct ieee80211_supported_band sbands[IEEE80211_NUM_BANDS];
@@ -171,9 +170,8 @@ struct ath5k_softc {
struct list_head txbuf; /* transmit buffer */
spinlock_t txbuflock;
unsigned int txbuf_len; /* buf count in txbuf list */
- struct ath5k_txq txqs[2]; /* beacon and tx */
-
- struct ath5k_txq *txq; /* beacon and tx*/
+ struct ath5k_txq txqs[AR5K_NUM_TX_QUEUES]; /* tx queues */
+ struct ath5k_txq *txq; /* main tx queue */
struct tasklet_struct txtq; /* tx intr tasklet */
struct ath5k_led tx_led; /* tx led */
@@ -187,6 +185,7 @@ struct ath5k_softc {
bintval, /* beacon interval in TU */
bsent;
unsigned int nexttbtt; /* next beacon time in TU */
+ struct ath5k_txq *cabq; /* content after beacon */
struct timer_list calib_tim; /* calibration timer */
int power_level; /* Requested tx power in dbm */
diff --git a/drivers/net/wireless/ath/ath5k/qcu.c b/drivers/net/wireless/ath/ath5k/qcu.c
index 73407b3..6d5aaf0 100644
--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -411,7 +411,6 @@ int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
AR5K_QCU_MISC_FRSHED_BCN_SENT_GT |
AR5K_QCU_MISC_CBREXP_DIS |
- AR5K_QCU_MISC_RDY_VEOL_POLICY |
AR5K_QCU_MISC_CBREXP_BCN_DIS);
ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/5] ath5k: rework beacon configuration
From: Bob Copeland @ 2009-07-04 16:59 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
In-Reply-To: <1246726795-3934-1-git-send-email-me@bobcopeland.com>
Using the enable_beacon flag allows some simplifications and fixes
some corner cases in beacon handling. This change adds a state
variable for beaconing in ath5k_beacon_config and handles both
enabling and disabling, thus eliminating the need for
ath5k_beacon_disable. We also now configure the beacon when any
of the beacon parameters change, so ath5k_beacon_reconfig is no
longer needed (its mmiowb gets moved to ath5k_beacon_config).
Finally, by locking around the whole config function, we don't
need to worry about clearing the interrupt mask register before
installing the new mask.
The upshot is this correctly disables beaconing when the interfaces
are taken down, it fixes a potential restarting of beaconing
when ath5k_reset() is called, and ensures that updates to the
beacon interval take effect immediately.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 59 ++++++++++----------------------
drivers/net/wireless/ath/ath5k/base.h | 1 +
2 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 87ebc46..4829329 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2093,13 +2093,6 @@ err_unmap:
return ret;
}
-static void ath5k_beacon_disable(struct ath5k_softc *sc)
-{
- sc->imask &= ~(AR5K_INT_BMISS | AR5K_INT_SWBA);
- ath5k_hw_set_imr(sc->ah, sc->imask);
- ath5k_hw_stop_tx_dma(sc->ah, sc->bhalq);
-}
-
/*
* Transmit a beacon frame at SWBA. Dynamic updates to the
* frame contents are done as needed and the slot time is
@@ -2293,13 +2286,11 @@ ath5k_beacon_config(struct ath5k_softc *sc)
struct ath5k_hw *ah = sc->ah;
unsigned long flags;
- ath5k_hw_set_imr(ah, 0);
+ spin_lock_irqsave(&sc->block, flags);
sc->bmisscount = 0;
sc->imask &= ~(AR5K_INT_BMISS | AR5K_INT_SWBA);
- if (sc->opmode == NL80211_IFTYPE_ADHOC ||
- sc->opmode == NL80211_IFTYPE_MESH_POINT ||
- sc->opmode == NL80211_IFTYPE_AP) {
+ if (sc->enable_beacon) {
/*
* In IBSS mode we use a self-linked tx descriptor and let the
* hardware send the beacons automatically. We have to load it
@@ -2312,16 +2303,17 @@ ath5k_beacon_config(struct ath5k_softc *sc)
sc->imask |= AR5K_INT_SWBA;
if (sc->opmode == NL80211_IFTYPE_ADHOC) {
- if (ath5k_hw_hasveol(ah)) {
- spin_lock_irqsave(&sc->block, flags);
+ if (ath5k_hw_hasveol(ah))
ath5k_beacon_send(sc);
- spin_unlock_irqrestore(&sc->block, flags);
- }
} else
ath5k_beacon_update_timers(sc, -1);
+ } else {
+ ath5k_hw_stop_tx_dma(sc->ah, sc->bhalq);
}
ath5k_hw_set_imr(ah, sc->imask);
+ mmiowb();
+ spin_unlock_irqrestore(&sc->block, flags);
}
static void ath5k_tasklet_beacon(unsigned long data)
@@ -2806,7 +2798,6 @@ ath5k_remove_interface(struct ieee80211_hw *hw,
goto end;
ath5k_hw_set_lladdr(sc->ah, mac);
- ath5k_beacon_disable(sc);
sc->vif = NULL;
end:
mutex_unlock(&sc->lock);
@@ -3135,25 +3126,6 @@ out:
return ret;
}
-/*
- * Update the beacon and reconfigure the beacon queues.
- */
-static void
-ath5k_beacon_reconfig(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
-{
- int ret;
- unsigned long flags;
- struct ath5k_softc *sc = hw->priv;
-
- spin_lock_irqsave(&sc->block, flags);
- ret = ath5k_beacon_update(hw, vif);
- spin_unlock_irqrestore(&sc->block, flags);
- if (ret == 0) {
- ath5k_beacon_config(sc);
- mmiowb();
- }
-}
-
static void
set_beacon_filter(struct ieee80211_hw *hw, bool enable)
{
@@ -3176,6 +3148,7 @@ static void ath5k_bss_info_changed(struct ieee80211_hw *hw,
{
struct ath5k_softc *sc = hw->priv;
struct ath5k_hw *ah = sc->ah;
+ unsigned long flags;
mutex_lock(&sc->lock);
if (WARN_ON(sc->vif != vif))
@@ -3201,13 +3174,19 @@ static void ath5k_bss_info_changed(struct ieee80211_hw *hw,
AR5K_LED_ASSOC : AR5K_LED_INIT);
}
- if (changes & BSS_CHANGED_BEACON &&
- (vif->type == NL80211_IFTYPE_ADHOC ||
- vif->type == NL80211_IFTYPE_MESH_POINT ||
- vif->type == NL80211_IFTYPE_AP)) {
- ath5k_beacon_reconfig(hw, vif);
+ if (changes & BSS_CHANGED_BEACON) {
+ spin_lock_irqsave(&sc->block, flags);
+ ath5k_beacon_update(hw, vif);
+ spin_unlock_irqrestore(&sc->block, flags);
}
+ if (changes & BSS_CHANGED_BEACON_ENABLED)
+ sc->enable_beacon = bss_conf->enable_beacon;
+
+ if (changes & (BSS_CHANGED_BEACON | BSS_CHANGED_BEACON_ENABLED |
+ BSS_CHANGED_BEACON_INT))
+ ath5k_beacon_config(sc);
+
unlock:
mutex_unlock(&sc->lock);
}
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 65e75fb..778e422 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -190,6 +190,7 @@ struct ath5k_softc {
struct timer_list calib_tim; /* calibration timer */
int power_level; /* Requested tx power in dbm */
bool assoc; /* assocate state */
+ bool enable_beacon; /* true if beacons are on */
};
#define ath5k_hw_hasbssidmask(_ah) \
--
1.6.2.5
^ permalink raw reply related
* [PATCH 0/5] ath5k updates
From: Bob Copeland @ 2009-07-04 16:59 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
I've been sitting on these patches for much too long. But anyway,
here are some updates for ath5k. 1-2 fix beacon issues, 3 is just
minor cleanup that I had sitting around forever, 4 is a reported
suspend/resume issue from Alan Jenkins, and 5 is a reported
initialization issue from Forrest Zhang.
Bob Copeland (5):
ath5k: send buffered frames after the beacon
ath5k: rework beacon configuration
ath: remove unnecessary return in ath_regd_get_band_ctl
ath5k: do not release irq across suspend/resume
ath5k: write PCU registers on initial reset
drivers/net/wireless/ath/ath5k/base.c | 107 +++++++++++++++-----------------
drivers/net/wireless/ath/ath5k/base.h | 10 ++--
drivers/net/wireless/ath/ath5k/qcu.c | 1 -
drivers/net/wireless/ath/regd.c | 2 -
4 files changed, 55 insertions(+), 65 deletions(-)
^ permalink raw reply
* [PATCH 3/5] ath: remove unnecessary return in ath_regd_get_band_ctl
From: Bob Copeland @ 2009-07-04 16:59 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
In-Reply-To: <1246726795-3934-1-git-send-email-me@bobcopeland.com>
'default' case already returns NO_CTL
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/regd.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index eef370b..f37c832 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -569,7 +569,5 @@ u32 ath_regd_get_band_ctl(struct ath_regulatory *reg,
default:
return NO_CTL;
}
-
- return NO_CTL;
}
EXPORT_SYMBOL(ath_regd_get_band_ctl);
--
1.6.2.5
^ permalink raw reply related
* Re: [WIP] p54: deal with allocation failures in rx path
From: Larry Finger @ 2009-07-04 16:40 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <200907041211.49115.chunkeey@web.de>
Christian Lamparter wrote:
>
> hmm, is it possible for you to log the usb transfer?
> A excellent tool for this is usbmon (userspace)... can be found here:
> http://git.sipsolutions.net/usbmon.git
>
> usbmon -s 3000 -i $(USB_ID) (which is usually number between 1 and the amount of connected usb devices)) > dst
>
> and set p54common nohwcrypt=1, if you don't want to show GK/TK around ;-)
I have logged the usb transfers, but not yet analyzed them. This time
I got a new failure - I hit this warning at
net/mac80211/tx.c:1299
retries++;
if (WARN(retries > 10, "tx refused but queue
active\n"))
goto drop;
goto retry;
If I have analyzed this correctly, I hit this section of
p54_tx_qos_accounting_alloc at drivers/net/wireless/p54/txrx.c:204.
I'm running the splitup patches.
if (unlikely(queue->len > queue->limit &&
IS_QOS_QUEUE(p54_queue))) {
spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
return -ENOSPC;
}
Any suggestions on debugging this would be appreciated.
Larry
^ permalink raw reply
* [PATCH] p54: fix beacon template dtim IE corruption
From: Christian Lamparter @ 2009-07-04 16:24 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
This patch fixes a regression that sneaked in with
"[PATCH] p54: re-enable power save feature".
When p54_beacon_format_ie_tim was divided up
and rewritten to use skb_* macros.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index 42abf34..c9a0545 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -111,10 +111,6 @@ static int p54_beacon_format_ie_tim(struct sk_buff *skb)
return -EINVAL;
memmove(tim, next, skb_tail_pointer(skb) - next);
-
- if (dtim_len > 3)
- skb_trim(skb, skb->len - (dtim_len - 3));
-
tim = skb_tail_pointer(skb) - (dtim_len + 2);
/* add the dummy at the end */
@@ -123,6 +119,10 @@ static int p54_beacon_format_ie_tim(struct sk_buff *skb)
tim[2] = 0;
tim[3] = dtim_period;
tim[4] = 0;
+
+ if (dtim_len > 3)
+ skb_trim(skb, skb->len - (dtim_len - 3));
+
return 0;
}
^ permalink raw reply related
* [PATCH] p54spi: remove dead code and definitions
From: Christian Lamparter @ 2009-07-04 15:49 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Max Filippov
This patch removes some dead code:
p54spi.c:115: warning: ‘p54spi_read16’ defined but not used
and while we're at it, p54spi_registers_array is purged as well.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 9b347ce..d5f181a 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -111,15 +111,6 @@ static void p54spi_spi_write(struct p54s_priv *priv, u8 address,
spi_sync(priv->spi, &m);
}
-static u16 p54spi_read16(struct p54s_priv *priv, u8 addr)
-{
- __le16 val;
-
- p54spi_spi_read(priv, addr, &val, sizeof(val));
-
- return le16_to_cpu(val);
-}
-
static u32 p54spi_read32(struct p54s_priv *priv, u8 addr)
{
__le32 val;
@@ -139,31 +130,6 @@ static inline void p54spi_write32(struct p54s_priv *priv, u8 addr, __le32 val)
p54spi_spi_write(priv, addr, &val, sizeof(val));
}
-struct p54spi_spi_reg {
- u16 address; /* __le16 ? */
- u16 length;
- char *name;
-};
-
-static const struct p54spi_spi_reg p54spi_registers_array[] =
-{
- { SPI_ADRS_ARM_INTERRUPTS, 32, "ARM_INT " },
- { SPI_ADRS_ARM_INT_EN, 32, "ARM_INT_ENA " },
- { SPI_ADRS_HOST_INTERRUPTS, 32, "HOST_INT " },
- { SPI_ADRS_HOST_INT_EN, 32, "HOST_INT_ENA" },
- { SPI_ADRS_HOST_INT_ACK, 32, "HOST_INT_ACK" },
- { SPI_ADRS_GEN_PURP_1, 32, "GP1_COMM " },
- { SPI_ADRS_GEN_PURP_2, 32, "GP2_COMM " },
- { SPI_ADRS_DEV_CTRL_STAT, 32, "DEV_CTRL_STA" },
- { SPI_ADRS_DMA_DATA, 16, "DMA_DATA " },
- { SPI_ADRS_DMA_WRITE_CTRL, 16, "DMA_WR_CTRL " },
- { SPI_ADRS_DMA_WRITE_LEN, 16, "DMA_WR_LEN " },
- { SPI_ADRS_DMA_WRITE_BASE, 32, "DMA_WR_BASE " },
- { SPI_ADRS_DMA_READ_CTRL, 16, "DMA_RD_CTRL " },
- { SPI_ADRS_DMA_READ_LEN, 16, "DMA_RD_LEN " },
- { SPI_ADRS_DMA_WRITE_BASE, 32, "DMA_RD_BASE " }
-};
-
static int p54spi_wait_bit(struct p54s_priv *priv, u16 reg, u32 bits)
{
int i;
^ permalink raw reply related
* Re: [PATCH] p54: two endian fixes
From: Max Filippov @ 2009-07-04 13:39 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John W. Linville
In-Reply-To: <200907032101.15855.chunkeey@web.de>
> This patch fixes all CHECK_ENDIAN complains:
>
> 1. p54/fwio.c:296:6: warning: restricted __le32 degrades to integer
> p54/fwio.c:296:6: warning: restricted __le32 degrades to integer
>
> 2. p54/p54spi.c:172:32: warning: incorrect type in initializer
> p54spi.c:172:32: expected restricted __le32 [usertype] buffer
> p54/p54spi.c:172:32: got unsigned int
>
> Signed-off-by: Christian Lamparter <chunkeey@web.de>
> ---
> Max,
>
> drivers/net/wireless/p54/p54spi.c:115: warning: ‘p54spi_read16’ defined but not used
>
> looks like this function can be nuked, or do you have plans with it?
No, no plans. Also there's unused p54spi_registers_array, which seems to be cx3110x legacy.
> for (i = 0; i < 2000; i++) {
> - __le32 buffer = p54spi_read32(priv, reg);
> + u32 buffer = p54spi_read32(priv, reg);
> if ((buffer & bits) == bits)
> return 1;
> }
You're right, my fault. There used to be p54spi_spi_read here, which didn't convert endianness.
Thanks.
-- Max
^ permalink raw reply
* Make error when compiling compat-wireless 2009-07-04
From: Momonosits @ 2009-07-04 11:35 UTC (permalink / raw)
To: linux-wireless
I have Jaunty in English on a Fujitsu Laptop with a D-Link DWA-160 (rev
A) WLan Stick. This Stick uses the ar9170 Chip Set. The Compat-Wireless
Drivers support this Chip Set. I wanted to compile the latest
compat-wireless drivers (compat-wireless-2009-07-04). After issuing the
make command I received the following errors.
peter@peter-laptop:~/compat-wireless-2009-07-04$ make
./scripts/gen-compat-autoconf.sh config.mk > include/linux/compat_autoconf.h
make -C /lib/modules/2.6.28-13-generic/build
M=/home/peter/compat-wireless-2009-07-04 modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.28-13-generic'
LD /home/peter/compat-wireless-2009-07-04/drivers/misc/eeprom/built-in.o
CC [M]
/home/peter/compat-wireless-2009-07-04/drivers/misc/eeprom/eeprom_93cx6.o
In file included from <command-line>:0:
/home/peter/compat-wireless-2009-07-04/include/net/compat.h:123: error:
redefinition of ‘skb_queue_is_last’
include/linux/skbuff.h:477: error: previous definition of
‘skb_queue_is_last’ was here
/home/peter/compat-wireless-2009-07-04/include/net/compat.h:137: error:
redefinition of ‘skb_queue_next’
include/linux/skbuff.h:491: error: previous definition of
‘skb_queue_next’ was here
make[3]: ***
[/home/peter/compat-wireless-2009-07-04/drivers/misc/eeprom/eeprom_93cx6.o]
Error 1
make[2]: ***
[/home/peter/compat-wireless-2009-07-04/drivers/misc/eeprom] Error 2
make[1]: *** [_module_/home/peter/compat-wireless-2009-07-04] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.28-13-generic'
make: *** [modules] Error 2
My computing powers are not sufficient to resolve these errors, help
would be appreciated.
Thanks in advance
Peter
^ permalink raw reply
* Re: BUG REPORT: libertas causing kernel lockups
From: Johannes Berg @ 2009-07-04 10:41 UTC (permalink / raw)
To: Alexander Barinov; +Cc: linux-wireless
In-Reply-To: <20090704130346.01b2e869@dream>
[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]
On Sat, 2009-07-04 at 13:03 +0400, Alexander Barinov wrote:
> Hi,
>
> I have Eking I1 UMPC that features Marvell 8686 SDIO wireless card. I
> am currently using vanilla kernel 2.6.30, but the bug is there on
> Debian 2.26 and 2.29 as well as vanilla 2.29 kernels I tried previously
>
> 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:
>
> BUG: scheduling while atomic: cat/1885/0x00000002
> Pid: 1885, comm: cat Not tainted 2.6.30.090704 #2
> Call Trace:
> [<c042eb7f>] ? __schedule+0x37f/0x8c0
> [<c01237cd>] ? try_to_wake_up+0x8d/0x1e0
> [<c011ee0e>] ? __wake_up+0x3e/0x60
> [<c02e882c>] ? __lbs_cmd_async+0x11c/0x280
> [<c018ddbe>] ? d_rehash+0x2e/0x50
> [<c042f0d0>] ? schedule+0x10/0x30
> [<c02e8be4>] ? __lbs_cmd+0xa4/0x1a0
> [<c02ea3f0>] ? lbs_cmd_copyback+0x0/0x40
> [<c013c460>] ? autoremove_wake_function+0x0/0x50
> [<c02e67d5>] ? lbs_get_wireless_stats+0xf5/0x3c0
> [<c02ea3f0>] ? lbs_cmd_copyback+0x0/0x40
> [<c03fb1e7>] ? wireless_seq_show+0x47/0x180
> [<c03965bf>] ? dev_seq_start+0x1f/0xb0
> [<c0196c6d>] ? seq_read+0x1fd/0x360
> [<c0196a70>] ? seq_read+0x0/0x360
> [<c01b4774>] ? proc_reg_read+0x64/0xa0
> [<c01b4710>] ? proc_reg_read+0x0/0xa0
> [<c017f9ab>] ? vfs_read+0x9b/0x120
> [<c017fb01>] ? sys_read+0x41/0x80
> [<c0102f21>] ? syscall_call+0x7/0xb
>
> Please let me know if I should provide any additional details regarding
> the 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_.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Christian Lamparter @ 2009-07-04 10:11 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Max Filippov
In-Reply-To: <4A4EBB68.6050502@lwfinger.net>
On Saturday 04 July 2009 04:16:08 Larry Finger wrote:
> Christian Lamparter 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:
> >
> -- snip --
>
> > diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
> > index 461d88f..c521bbc 100644
> > --- a/drivers/net/wireless/p54/p54usb.c
> > +++ b/drivers/net/wireless/p54/p54usb.c
> > @@ -120,37 +120,14 @@ static void p54u_rx_cb(struct urb *urb)
> > }
> >
> > skb_put(skb, urb->actual_length);
> > + skb = p54_rx(dev, skb);
> >
> > - if (priv->hw_type == P54U_NET2280)
> > - skb_pull(skb, priv->common.tx_hdr_len);
> > - if (priv->common.fw_interface == FW_LM87) {
> > - skb_pull(skb, 4);
> > - skb_put(skb, 4);
> > - }
> > -
> > - if (p54_rx(dev, skb)) {
> > - skb = dev_alloc_skb(priv->common.rx_mtu + 32);
> > - if (unlikely(!skb)) {
> > - /* TODO check rx queue length and refill *somewhere* */
> > - return;
> > - }
> > + info = (struct p54u_rx_info *) skb->cb;
> > + info->urb = urb;
> > + info->dev = dev;
> > + urb->transfer_buffer = skb_tail_pointer(skb);
> > + urb->context = skb;
> >
> > - info = (struct p54u_rx_info *) skb->cb;
> > - info->urb = urb;
> > - info->dev = dev;
> > - urb->transfer_buffer = skb_tail_pointer(skb);
> > - urb->context = skb;
> > - } else {
> > - if (priv->hw_type == P54U_NET2280)
> > - skb_push(skb, priv->common.tx_hdr_len);
> > - if (priv->common.fw_interface == FW_LM87) {
> > - skb_push(skb, 4);
> > - skb_put(skb, 4);
> > - }
> > - skb_reset_tail_pointer(skb);
> > - skb_trim(skb, 0);
> > - urb->transfer_buffer = skb_tail_pointer(skb);
> > - }
> > skb_queue_tail(&priv->rx_queue, skb);
> > usb_anchor_urb(urb, &priv->submitted);
> > if (usb_submit_urb(urb, GFP_ATOMIC)) {
> > @@ -186,7 +163,7 @@ static int p54u_init_urbs(struct ieee80211_hw *dev)
> > int ret = 0;
> >
> > while (skb_queue_len(&priv->rx_queue) < 32) {
> > - skb = __dev_alloc_skb(priv->common.rx_mtu + 32, GFP_KERNEL);
> > + skb = __dev_alloc_skb(priv->common.rx_mtu, GFP_KERNEL);
> > if (!skb) {
> > ret = -ENOMEM;
> > goto err;
> > @@ -927,14 +904,17 @@ static int __devinit p54u_probe(struct usb_interface *intf,
> > #endif
> >
> > priv->hw_type = P54U_3887;
> > + priv->common.rx_wa_extra_tail_space = true;
> > dev->extra_tx_headroom += sizeof(struct lm87_tx_hdr);
> > priv->common.tx_hdr_len = sizeof(struct lm87_tx_hdr);
> > + priv->common.rx_hdr_len = sizeof(struct lm87_rx_hdr);
> > priv->common.tx = p54u_tx_lm87;
> > priv->upload_fw = p54u_upload_firmware_3887;
> > } else {
> > priv->hw_type = P54U_NET2280;
> > dev->extra_tx_headroom += sizeof(struct net2280_tx_hdr);
> > priv->common.tx_hdr_len = sizeof(struct net2280_tx_hdr);
> > + priv->common.rx_hdr_len = sizeof(struct net2280_tx_hdr);
> ==
> Should this be rx rather than tx?
I hope not...
@@ -120,37 +120,14 @@ static void p54u_rx_cb(struct urb *urb)
skb_put(skb, urb->actual_length);
if (priv->hw_type == P54U_NET2280)
skb_pull(skb, priv->common.tx_hdr_len);
net2280_tx_hdr's name is misleading, as the rx urbs have the header as well.
will probably change that to net2280_hdr in the future.
> -- skip --
>
> I have a problem that is not new with this patch. Using p54usb with
> LM87 firmware and under the heavy load of building a kernel with the
> source tree mounted with NFS, the interface will go off-line and
> cannot reconnect. When the driver is unloaded and reloaded, it is
> unable to reload the firmware. My log is as follows:
>
> usb 1-5: new high speed USB device using ehci_hcd and address 3
> usb 1-5: configuration #1 chosen from 1 choice
> cfg80211: Calling CRDA to update world regulatory domain
> usb 1-5: reset high speed USB device using ehci_hcd and address 3
> usb 1-5: firmware: requesting isl3887usb
> phy0: p54 detected a LM87 firmware
> p54: rx_mtu reduced from 3240 to 2380
> phy0: FW rev 2.13.24.0 - Softmac protocol 5.9
> phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> phy0: hwaddr 00:90:4b:d2:1f:cd, MAC:isl3892 RF:Xbow
> phy0: Selected rate control algorithm 'minstrel'
> Registered led device: p54-phy0::assoc
> Registered led device: p54-phy0::tx
> Registered led device: p54-phy0::rx
> Registered led device: p54-phy0::radio
> usb 1-5: is registered as 'phy0'
> usbcore: registered new interface driver p54usb
> wlan0: authenticate with AP 00:1a:70:46:ba:b1
> wlan0: authenticated
> wlan0: associate with AP 00:1a:70:46:ba:b1
> wlan0: RX AssocResp from 00:1a:70:46:ba:b1 (capab=0x431 status=0 aid=1)
> wlan0: associated
> wlan0: no probe response from AP 00:1a:70:46:ba:b1 - disassociating
> usbcore: deregistering interface driver p54usb
> cfg80211: Calling CRDA to update world regulatory domain
> usb 1-5: reset high speed USB device using ehci_hcd and address 3
> usb 1-5: firmware: requesting isl3887usb
> phy0: p54 detected a LM87 firmware
> p54: rx_mtu reduced from 3240 to 2380
> phy0: FW rev 2.13.24.0 - Softmac protocol 5.9
> phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> usb 1-5: (p54usb) firmware upload failed!
> p54usb: probe of 1-5:1.0 failed with error -110
>
hmm, is it possible for you to log the usb transfer?
A excellent tool for this is usbmon (userspace)... can be found here:
http://git.sipsolutions.net/usbmon.git
usbmon -s 3000 -i $(USB_ID) (which is usually number between 1 and the amount of connected usb devices)) > dst
and set p54common nohwcrypt=1, if you don't want to show GK/TK around ;-)
Regards,
Chr
^ permalink raw reply
* BUG REPORT: libertas causing kernel lockups
From: Alexander Barinov @ 2009-07-04 9:03 UTC (permalink / raw)
To: linux-wireless
Hi,
I have Eking I1 UMPC that features Marvell 8686 SDIO wireless card. I
am currently using vanilla kernel 2.6.30, but the bug is there on
Debian 2.26 and 2.29 as well as vanilla 2.29 kernels I tried previously
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:
BUG: scheduling while atomic: cat/1885/0x00000002
Pid: 1885, comm: cat Not tainted 2.6.30.090704 #2
Call Trace:
[<c042eb7f>] ? __schedule+0x37f/0x8c0
[<c01237cd>] ? try_to_wake_up+0x8d/0x1e0
[<c011ee0e>] ? __wake_up+0x3e/0x60
[<c02e882c>] ? __lbs_cmd_async+0x11c/0x280
[<c018ddbe>] ? d_rehash+0x2e/0x50
[<c042f0d0>] ? schedule+0x10/0x30
[<c02e8be4>] ? __lbs_cmd+0xa4/0x1a0
[<c02ea3f0>] ? lbs_cmd_copyback+0x0/0x40
[<c013c460>] ? autoremove_wake_function+0x0/0x50
[<c02e67d5>] ? lbs_get_wireless_stats+0xf5/0x3c0
[<c02ea3f0>] ? lbs_cmd_copyback+0x0/0x40
[<c03fb1e7>] ? wireless_seq_show+0x47/0x180
[<c03965bf>] ? dev_seq_start+0x1f/0xb0
[<c0196c6d>] ? seq_read+0x1fd/0x360
[<c0196a70>] ? seq_read+0x0/0x360
[<c01b4774>] ? proc_reg_read+0x64/0xa0
[<c01b4710>] ? proc_reg_read+0x0/0xa0
[<c017f9ab>] ? vfs_read+0x9b/0x120
[<c017fb01>] ? sys_read+0x41/0x80
[<c0102f21>] ? syscall_call+0x7/0xb
Please let me know if I should provide any additional details regarding
the bug.
--
Alex
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Johannes Berg @ 2009-07-04 7:52 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Larry Finger, Max Filippov
In-Reply-To: <200907040053.05654.chunkeey@web.de>
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
On Sat, 2009-07-04 at 00:53 +0200, Christian Lamparter wrote:
> the simplest answer is probably this one:
> https://dev.openwrt.org/changeset/15761
Humm. Davem and I looked into this problem some time ago, came up with
patches and concluded that if everything is set up correctly this
shouldn't be happening.
Look at net/mac80211/iface.c::ieee80211_if_add:
ndev->needed_headroom = local->tx_headroom +
4*6 /* four MAC addresses */
+ 2 + 2 + 2 + 2 /* ctl, dur, seq, qos */
+ 6 /* mesh */
+ 8 /* rfc1042/bridge tunnel */
- ETH_HLEN /* ethernet hard_header_len */
+ IEEE80211_ENCRYPT_HEADROOM;
ndev->needed_tailroom = IEEE80211_ENCRYPT_TAILROOM;
Due to that, skbs allocated for our device ought to have enough
headroom. If they don't, you should try to figure out where they're
coming from and why they don't,
http://johannes.sipsolutions.net/patches/kernel/all/2008-05-04-23:09/028-skb-alloc-stackdump.patch might help with that.
OTOH, I guess that you're using IPv4 and that should do things
correctly, I think.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: iwlagn: possible regressions from 2.6.29 in 2.6.30
From: Paul Collins @ 2009-07-04 6:39 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <87k52t9ynp.fsf@jenny.ondioline.org>
Paul Collins <paul@burly.ondioline.org> writes:
> reinette chatre <reinette.chatre@intel.com> writes:
>>> When I say "packets > 250 bytes" I mean 250-byte packets as claimed by
>>> "ping -s 222 mygateway":
>>>
>>> PING cornelius.lan (10.2.4.1) 222(250) bytes of data.
>>>
>>> The above will work, but "ping -s 223 cornelius" yields no replies.
>>
>> Are you saying this works before suspend, but not after resume? What do
>> you usually do to get this working again?
>
> Yes, normally it works great; I can ping with packet sizes up to the
> MTU. However, after suspend/resume and reassociation, "ping -s 223" or
> greater does not work. I get replies with "-s 222" or less,
> i.e. packets of 250 bytes or less.
>
> To get it working again I do "ifdown wlan0" followed by "ifup wlan0",
> which does the equivalent of "ip set link wlan0 down/up" and applying
> the network configuration.
>
> I will give the patch a shot when I get home.
I thought at first that the patch had moved the problem from reliably
reproducible to intermittently reproducible, but it looks like it was
simply intermittently reproducible the whole time. So, no change with
the patch applied.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ 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