* Re: [PATCH] ath5k: do not free irq after resume when card has been removed
From: Bob Copeland @ 2009-09-09 19:31 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: ath5k-devel, linux-wireless, netdev, linux-kernel, lrodriguez,
mickflemm, jirislaby, linville, johannes
In-Reply-To: <20090909175006.GA7945@vespa.holoscopio.com>
On Wed, Sep 09, 2009 at 02:50:06PM -0300, Thadeu Lima de Souza Cascardo wrote:
> This is against v2.6.31-rc9, so I get a warning with a version that's
> about to get stable. Sorry I am late in the release cycle.
Ok yes, that makes sense then.
> Since this is warning, is this worth backporting to rc?
It's too late probably, but we can send it to stable for 2.6.31.1.
Thank you for the patch by the way, just keep in mind that wireless
patches should be against the wireless-testing kernel in the future.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] ath5k: do not free irq after resume when card has been removed
From: Thadeu Lima de Souza Cascardo @ 2009-09-09 17:50 UTC (permalink / raw)
To: Bob Copeland
Cc: ath5k-devel, linux-wireless, netdev, linux-kernel, lrodriguez,
mickflemm, jirislaby, linville, johannes
In-Reply-To: <20090909033237.GC13550@hash.localnet>
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
On Tue, Sep 08, 2009 at 11:32:37PM -0400, Bob Copeland wrote:
> On Tue, Sep 08, 2009 at 09:52:31PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > ath5k will try to request irq when resuming and fails if the device
> > (like a PCMCIA card) has been removed.
>
> That's not true, ath5k no longer requests an irq when resuming.
>
I've just saw there's a commit by you in the next tree that just removes
the irq requesting and releasing in resume/suspend functions.
> > This solves this issue defining a new flag for the status bitmap to
> > indicate when irq has been successfully requested and does not try to
> > release it if not.
>
> I'd rather not fix it with a status bit. What kernel is this against?
>
This is against v2.6.31-rc9, so I get a warning with a version that's
about to get stable. Sorry I am late in the release cycle.
I've used a status bit because the drivers I took a look at did
release/request irq in suspend/resume. I couldn't find a message about
not doing it was the right thing which I thought I saw in the latest
updates to v2.6.31-rcX. I guess it was something just like your commit
which I did see some weeks ago.
Since this is warning, is this worth backporting to rc?
> --
> Bob Copeland %% www.bobcopeland.com
>
Regards,
Cascardo.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Frans Pop @ 2009-09-09 17:19 UTC (permalink / raw)
To: Mel Gorman
Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <20090909165545.GK24614@csn.ul.ie>
On Wednesday 09 September 2009, you wrote:
> The problem with this theory is that the patches have been in since Nov
> 2008 but reports are only showing up now. Frans, how sure are you that
> this is a recent problem? Is it readily reproducible?
The only thing I can say here is that I've never seen the issue before
(and thanks to logcheck I certainly would have).
The laptop is in constant use, but I rarely stress the memory like that.
Swap is almost always at 0.
I would have to make an effort to try and reproduce it, probably by again
creating some very large images and loading those in konqueror, maybe
while streaming a movie over wireless or something.
Thanks for your efforts,
FJP
^ permalink raw reply
* Re: wireless/sme.c:617 __cfg80211_disconnected I still get these daily
From: Bob Copeland @ 2009-09-09 17:04 UTC (permalink / raw)
To: ASIC Felix; +Cc: linux-wireless, Johannes Berg, Luis R. Rodriguez
In-Reply-To: <1252512190.25355.15.camel@darkslate>
On Wed, Sep 9, 2009 at 12:03 PM, ASIC Felix <ic.felix@gmail.com> wrote:
> Hi,
>
> I still get these daily.
>
> Thinkpad T43,
> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xfa360000, irq=21
>
> kernel: linville master-2009-09-08 2.6.31-rc9-wl-36500-g918dc92
Same here...
[ 4692.369907] wlan0: associated
[ 4692.369921] phy0: Allocated STA 00:23:ab:26:4d:80
[ 4692.371064] phy0: Inserted STA 00:23:ab:26:4d:80
[ 4800.046263] wlan0: deauthenticating by local choice (reason=3)
[ 4800.046329] phy0: Removed STA 00:23:ab:26:4d:80
[ 4800.051446] phy0: device now idle
[ 4800.053456] phy0: Destroyed STA 00:23:ab:26:4d:80
[ 4800.053550] wlan0: deauthenticating by local choice (reason=3)
[ 4800.053556] ------------[ cut here ]------------
[ 4800.053573] WARNING: at net/wireless/sme.c:617
__cfg80211_disconnected+0x1c9/0x210 [cfg80211]()
[ 4800.053576] Hardware name: MacBook1,1
[ 4800.053579] deauth failed: -67
Looks like we deauthed twice in a row (no idea why the second one happened)
and that made the sme code unhappy:
for (i = 0; i < MAX_AUTH_BSSES; i++) {
if (!wdev->auth_bsses[i])
continue;
bssid = wdev->auth_bsses[i]->pub.bssid;
ret = __cfg80211_mlme_deauth(rdev, dev, bssid, NULL, 0,
WLAN_REASON_DEAUTH_LEAVING);
WARN(ret, "deauth failed: %d\n", ret);
}
iw event output (this is wext)... connect failed, then we did deauth
anyway?
1252515598.767300: wlan0 (phy #0): deauth 00:17:f2:43:be:3a ->
00:23:ab:26:4d:80 reason 3: Deauthenticated because sending station is
leaving (or has left) the IBSS or ESS
1252515598.767545: wlan0 (phy #0): disconnected (local request)
1252515598.767663: wlan0 (phy #0): deauth 00:17:f2:43:be:3a ->
00:23:ab:26:4d:80 reason 3: Deauthenticated because sending station is
leaving (or has left) the IBSS or ESS
1252515598.767821: wlan0 (phy #0): failed to connect to
00:23:ab:26:4d:80, status: 1: Unspecified failure
1252515598.770943: wlan0 (phy #0): scan started
1252515598.965265: wlan0 (phy #0): failed to connect, status: 1:
Unspecified failure
1252515598.965425: wlan0 (phy #0): scan finished: 2462,
"\x02\xf4\xb2\xedr\x16\xec\xf3\x01M\xf0\x00\x10\x8bg\xcf\x99P[\x17\x9f\x8e\xd4\x98\x0aa\x03\xd1\xbc\xa7\x0d\xbe"
1252515598.965736: wlan0 (phy #0): scan started
1252515598.965882: wlan0 (phy #0): deauth 00:17:f2:43:be:3a ->
00:23:ab:26:4d:80 reason 3: Deauthenticated because sending station is
leaving (or has left) the IBSS or ESS
1252515598.966042: wlan0 (phy #0): failed to connect to
00:23:ab:26:4d:80, status: 1: Unspecified failure
1252515599.161286: wlan0 (phy #0): scan finished: 2462,
"\x02\xf4\xb2\xedr\x16\xec\xf3\x01M\xf0\x00\x10\x8bg\xcf\x99P[\x17\x9f\x8e\xd4\x98\x0aa\x03\xd1\xbc\xa7\x0d\xbe"
1252515599.167130: wlan0 (phy #0): auth 00:23:ab:26:4d:80 ->
00:17:f2:43:be:3a status: 0: Successful
1252515599.171144: wlan0 (phy #0): assoc 00:23:ab:26:4d:80 ->
00:17:f2:43:be:3a status: 0: Successful
1252515599.171283: wlan0 (phy #0): connected to 00:23:ab:26:4d:80
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Mel Gorman @ 2009-09-09 16:55 UTC (permalink / raw)
To: Frans Pop
Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <200909091759.33655.elendil@planet.nl>
On Wed, Sep 09, 2009 at 05:59:30PM +0200, Frans Pop wrote:
> On Wednesday 09 September 2009, Mel Gorman wrote:
> > Franz, in the full dmesg was there any mention of "SLUB: Unable to
> > allocate memory on node"?
>
> No, nothing at all. I double checked the kernel log, but it was completely
> quiet in the hours before and after the messages I already posted.
>
Ok, that in itself is unexpected.
Pekka, it looks from the stack trace that the failure is from
__alloc_skb and I am guessing the failure path is around here
size = SKB_DATA_ALIGN(size);
data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info),
gfp_mask, node);
if (!data)
goto nodata;
Why would the SLUB out-of-memory message not appear? It's hardly
tripping up on printk_ratelimit() is it?
> > Also, did you have any slub debug options enabled on the command line?
>
> Nope.
>
Ok, just best to rule it out.
Apologies for the scattershot approach to figuring out where the order-2
failures are coming from and am not familiar at all with the driver.
According to the logs, the card is a 4965 AG so I can only assume the relevant
driver code is iwl4965. Since commit 1ea8739648cfff4027c3db0f4cee5de87bfd3886,
this has enabled by default a module option called amsdu_size_8K. At a glance,
it looks like this will guarantee that at least order-1 allocations will be
required. Assaf and other wireless folks, is that intentional? What are the
consequences of defaulting that to being off?
What might have made this worse is commit
4018517a1a69a85c3d61b20fa02f187b80773137 which intends to fix an RX skb
alignment problem but looks like it would have the side-effect of 8192
byte allocations becoming 8448 byte allocations and kmalloc() having to do
an order-2 allocation instead of order-1. The problem with this theory is
that the patches have been in since Nov 2008 but reports are only showing
up now. Frans, how sure are you that this is a recent problem? Is it readily
reproducible?
Conceivably a better candidate for this problem is commit
4752c93c30441f98f7ed723001b1a5e3e5619829 introduced in May 2009. If there
are less than RX_QUEUE_SIZE/2 left, it starts replenishing buffers. Mohamed,
is it absolutly necessary it use GFP_ATOMIC there? If an allocation fails,
does it always mean frames are dropped or could it just replenish what it
can and try again later printing a warning only if allocation failures are
resulting in packet loss?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: AP: ath5k + hostapd occasionally sulks
From: Philip Prindeville @ 2009-09-09 16:44 UTC (permalink / raw)
To: Bob Copeland; +Cc: jon.fairbairn, linux-wireless
In-Reply-To: <b6c5339f0909090600o267ae376o432cb36b912b7c2a@mail.gmail.com>
Bob Copeland wrote:
> On Tue, Sep 8, 2009 at 1:53 PM, Philip Prindeville
> <philipp_subx@redfish-solutions.com> wrote:
>
>> I pulled compat-wireless from GIT last night (or about 1:30am mountain,
>> really) and rebuilt a 2.6.27.29 kernel.
>>
>> I'm seeing a lot of:
>>
>> Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packet
>>
>>
>> one every 10 seconds, in fact. This is with an Engenius EMP-8062+ card:
>>
>
> Ok, the timing information is useful. This is probably something (beacon
> sending?) racing with the periodic calibration, which temporarily stops
> all of the tx traffic and frees the tx buffers, then starts it all up
> again. In short, apart from the logging this shouldn't cause any
> problems, but we should probably disable the beacon tasklet during this
> time.
>
Alas it is causing problems. I have a Windows 7 client with an Atheros
card (I forget which... it's the mini-PCIe card that comes with Zotac
ION mini-itx motherboards).
I either can't associate, or associate but don't get a DHCP address or
don't pass traffic... I forget which.
I can do more testing tomorrow...
> If this only appeared all of a sudden in recent compat snapshots, it
> would be useful to know the last one that worked normally.
>
I could walk it backwards, I suppose... 2009-08-23 was definitely
working with an 9K board.
I've not tried it with a 5K board (I'm not at this location very often).
>> I'll probably have to reboot regularly, since this is on an embedded box
>> with limited CF filesystem, and I can't overflow my /var partition...
>>
>
> Ouch. For now, just take it out or demote it to debug.
>
> As for the original problem, I don't know offhand why a large download
> would trigger a cascade of these errors. The best way to track it down
> is to try to come up with a case that reproduces it and sprinkle printks
> throughout the driver, especially when we free and allocate the tx
> buffers.
>
>
^ permalink raw reply
* wireless/sme.c:617 __cfg80211_disconnected I still get these daily
From: ASIC Felix @ 2009-09-09 16:03 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: Luis R. Rodriguez
Hi,
I still get these daily.
Thinkpad T43,
phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xfa360000, irq=21
kernel: linville master-2009-09-08 2.6.31-rc9-wl-36500-g918dc92
auth: WPA-EAP PEAP
Best regards,
Felix
Sep 9 08:46:01 darkslate CROND[14154]: (root) CMD ( /usr/share/msec/promisc_check.sh)
Sep 9 08:46:22 darkslate klogd: ------------[ cut here ]------------
Sep 9 08:46:22 darkslate klogd: WARNING: at net/wireless/sme.c:617 __cfg80211_disconnected+0x1ff/0x210 [cfg80211]()
Sep 9 08:46:22 darkslate klogd: Hardware name: 1875DLU
Sep 9 08:46:22 darkslate klogd: deauth failed: -67
Sep 9 08:46:22 darkslate klogd: Modules linked in: xt_time xt_connlimit xt_realm iptable_raw xt_comment ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_ECN ipt_ecn ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_recent xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables x_tables i915 drm i2c_algo_bit aes_i586 aes_generic af_packet bridge stp llc bnep sco rfcomm l2cap bluetooth binfmt_misc
Sep 9 08:46:22 darkslate klogd: oop fuse cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table arc4 ecb ath9k mac80211 ath cfg80211 thinkpad_acpi rfkill video tg3 joydev led_class evdev output nsc_ircc irda ehci_hcd crc_ccitt i2c_i801 i2c_core uhci_hcd intel_agp rtc_cmos sr_mod libphy sg iTCO_wdt iTCO_vendor_support pcspkr yenta_socket rsrc_nonstatic button agpgart thermal ac processor battery pcmcia_core nvram usbcore ata_generic ide_pci_generic ide_gd_mod ide_core pata_acpi ata_piix ahci libata sd_mod scsi_mod crc_t10dif ext3 jbd
Sep 9 08:46:22 darkslate klogd: Pid: 1142, comm: phy0 Tainted: G W 2.6.31-rc9-wl-mnbStrip-36500-g918dc92 #77
Sep 9 08:46:22 darkslate klogd: Call Trace:
Sep 9 08:46:22 darkslate klogd: [<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<c0138d9c>] warn_slowpath_common+0x6c/0xc0
Sep 9 08:46:22 darkslate klogd: [<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<c0138e36>] warn_slowpath_fmt+0x26/0x30
Sep 9 08:46:22 darkslate klogd: [<f89134af>] __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f8910262>] ? nl80211_send_deauth+0x22/0x30 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f8911463>] __cfg80211_send_deauth+0x213/0x260 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f89ea7a3>] ? __sta_info_free+0x33/0x40 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<f89ea9d3>] ? sta_info_destroy+0xf3/0x100 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<f89f1384>] ? ieee80211_set_disassoc+0x174/0x1d0 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<f891150e>] cfg80211_send_deauth+0x5e/0x70 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f89f2f31>] ieee80211_sta_work+0x901/0x1820 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<c0134ca1>] ? update_curr+0x1b1/0x1c0
Sep 9 08:46:22 darkslate klogd: [<c013502d>] ? dequeue_task_fair+0x29d/0x2b0
Sep 9 08:46:22 darkslate klogd: [<c010254d>] ? __switch_to+0xad/0x1a0
Sep 9 08:46:22 darkslate klogd: [<c012a10f>] ? set_next_entity+0x11f/0x1b0
Sep 9 08:46:22 darkslate klogd: [<c03a3c65>] ? schedule+0x495/0xa40
Sep 9 08:46:22 darkslate klogd: [<c014fbea>] ? prepare_to_wait+0x3a/0x70
Sep 9 08:46:22 darkslate klogd: [<c014b178>] worker_thread+0x148/0x210
Sep 9 08:46:22 darkslate klogd: [<f89f2630>] ? ieee80211_sta_work+0x0/0x1820 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<c014f9a0>] ? autoremove_wake_function+0x0/0x50
Sep 9 08:46:22 darkslate klogd: [<c014b030>] ? worker_thread+0x0/0x210
Sep 9 08:46:22 darkslate klogd: [<c014f644>] kthread+0x84/0x90
Sep 9 08:46:22 darkslate klogd: [<c014f5c0>] ? kthread+0x0/0x90
Sep 9 08:46:22 darkslate klogd: [<c0104667>] kernel_thread_helper+0x7/0x10
Sep 9 08:46:22 darkslate klogd: ---[ end trace 46565fb73d858208 ]---
Sep 9 08:46:22 darkslate ifplugd(wlan0)[30335]: Link beat lost.
Sep 9 08:46:22 darkslate klogd: ------------[ cut here ]------------
Sep 9 08:46:22 darkslate klogd: WARNING: at net/wireless/sme.c:617 __cfg80211_disconnected+0x1ff/0x210 [cfg80211]()
Sep 9 08:46:22 darkslate klogd: Hardware name: 1875DLU
Sep 9 08:46:22 darkslate klogd: deauth failed: -67
Sep 9 08:46:22 darkslate klogd: Modules linked in: xt_time xt_connlimit xt_realm iptable_raw xt_comment ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_ECN ipt_ecn ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_recent xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables x_tables i915 drm i2c_algo_bit aes_i586 aes_generic af_packet bridge stp llc bnep sco rfcomm l2cap bluetooth binfmt_misc
Sep 9 08:46:22 darkslate klogd: oop fuse cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table arc4 ecb ath9k mac80211 ath cfg80211 thinkpad_acpi rfkill video tg3 joydev led_class evdev output nsc_ircc irda ehci_hcd crc_ccitt i2c_i801 i2c_core uhci_hcd intel_agp rtc_cmos sr_mod libphy sg iTCO_wdt iTCO_vendor_support pcspkr yenta_socket rsrc_nonstatic button agpgart thermal ac processor battery pcmcia_core nvram usbcore ata_generic ide_pci_generic ide_gd_mod ide_core pata_acpi ata_piix ahci libata sd_mod scsi_mod crc_t10dif ext3 jbd
Sep 9 08:46:22 darkslate klogd: Pid: 1142, comm: phy0 Tainted: G W 2.6.31-rc9-wl-mnbStrip-36500-g918dc92 #77
Sep 9 08:46:22 darkslate klogd: Call Trace:
Sep 9 08:46:22 darkslate klogd: [<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<c0138d9c>] warn_slowpath_common+0x6c/0xc0
Sep 9 08:46:22 darkslate klogd: [<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<c0138e36>] warn_slowpath_fmt+0x26/0x30
Sep 9 08:46:22 darkslate klogd: [<f89134af>] __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f8910262>] ? nl80211_send_deauth+0x22/0x30 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f8911463>] __cfg80211_send_deauth+0x213/0x260 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f89ea7a3>] ? __sta_info_free+0x33/0x40 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<f89ea9d3>] ? sta_info_destroy+0xf3/0x100 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<f89f1384>] ? ieee80211_set_disassoc+0x174/0x1d0 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<f891150e>] cfg80211_send_deauth+0x5e/0x70 [cfg80211]
Sep 9 08:46:22 darkslate klogd: [<f89f2f31>] ieee80211_sta_work+0x901/0x1820 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<c0134ca1>] ? update_curr+0x1b1/0x1c0
Sep 9 08:46:22 darkslate klogd: [<c013502d>] ? dequeue_task_fair+0x29d/0x2b0
Sep 9 08:46:22 darkslate klogd: [<c010254d>] ? __switch_to+0xad/0x1a0
Sep 9 08:46:22 darkslate klogd: [<c012a10f>] ? set_next_entity+0x11f/0x1b0
Sep 9 08:46:22 darkslate klogd: [<c03a3c65>] ? schedule+0x495/0xa40
Sep 9 08:46:22 darkslate klogd: [<c014fbea>] ? prepare_to_wait+0x3a/0x70
Sep 9 08:46:22 darkslate klogd: [<c014b178>] worker_thread+0x148/0x210
Sep 9 08:46:22 darkslate klogd: [<f89f2630>] ? ieee80211_sta_work+0x0/0x1820 [mac80211]
Sep 9 08:46:22 darkslate klogd: [<c014f9a0>] ? autoremove_wake_function+0x0/0x50
Sep 9 08:46:22 darkslate klogd: [<c014b030>] ? worker_thread+0x0/0x210
Sep 9 08:46:22 darkslate klogd: [<c014f644>] kthread+0x84/0x90
Sep 9 08:46:22 darkslate klogd: [<c014f5c0>] ? kthread+0x0/0x90
Sep 9 08:46:22 darkslate klogd: [<c0104667>] kernel_thread_helper+0x7/0x10
Sep 9 08:46:22 darkslate klogd: ---[ end trace 46565fb73d858208 ]---
Sep 9 08:46:22 darkslate ifplugd(wlan0)[30335]: Link beat lost.
Sep 9 08:46:23 darkslate ifplugd(wlan0)[30335]: Link beat detected.
Sep 9 08:46:23 darkslate ifplugd(wlan0)[30335]: Link beat detected.
dmesg -c
wlan0: deauthenticated from 00:0b:85:6f:12:ac (Reason: 1)
wlan0: direct probe to AP 00:0b:85:6f:20:8c (try 1)
wlan0 direct probe responded
wlan0: authenticate with AP 00:0b:85:6f:20:8c (try 1)
wlan0: authenticated
wlan0: associate with AP 00:0b:85:6f:20:8c (try 1)
wlan0: RX AssocResp from 00:0b:85:6f:20:8c (capab=0x421 status=17 aid=0)
wlan0: AP denied association (code=17)
wlan0: deauthenticating by local choice (reason=3)
wlan0: direct probe to AP 00:0b:85:6f:20:8c (try 1)
wlan0 direct probe responded
wlan0: authenticate with AP 00:0b:85:6f:20:8c (try 1)
wlan0: authenticated
wlan0: associate with AP 00:0b:85:6f:20:8c (try 1)
wlan0: RX AssocResp from 00:0b:85:6f:20:8c (capab=0x431 status=1 aid=16)
wlan0: AP denied association (code=1)
wlan0: direct probe to AP 00:0b:85:6f:12:ac (try 1)
wlan0 direct probe responded
wlan0: authenticate with AP 00:0b:85:6f:12:ac (try 1)
wlan0: authenticated
wlan0: associate with AP 00:0b:85:6f:12:ac (try 1)
wlan0: RX AssocResp from 00:0b:85:6f:12:ac (capab=0x431 status=0 aid=26)
wlan0: associated
wlan0: deauthenticated from 00:0b:85:6f:12:ac (Reason: 1)
wlan0: deauthenticating by local choice (reason=3)
------------[ cut here ]------------
WARNING: at net/wireless/sme.c:617 __cfg80211_disconnected+0x1ff/0x210 [cfg80211]()
Hardware name: 1875DLU
deauth failed: -67
Modules linked in: xt_time xt_connlimit xt_realm iptable_raw xt_comment ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_ECN ipt_ecn ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_recent xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables x_tables i915 drm i2c_algo_bit aes_i586 aes_generic af_packet bridge stp llc bnep sco rfcomm l2cap bluetooth binfmt_misc loop fuse cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table arc4 ecb ath9k mac80211 ath cfg80211 thinkpad_acpi rfkill video tg3 joydev led_class evdev output nsc_ircc irda ehci_hcd crc_ccitt i2c_i801 i2c_core uhci_hcd intel_agp rtc_cmos sr_mod libphy sg iTCO_wdt iTCO_vendor_support pcspkr yenta_socket rsrc_nonstatic button agpgart thermal ac processor battery pcmcia_core nvram usbcore ata_generic ide_pci_generic ide_gd_mod ide_core pata_acpi ata_piix ahci libata sd_mod scsi_mod crc_t10dif ext3 jbd
Pid: 1142, comm: phy0 Tainted: G W 2.6.31-rc9-wl-mnbStrip-36500-g918dc92 #77
Call Trace:
[<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
[<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
[<c0138d9c>] warn_slowpath_common+0x6c/0xc0
[<f89134af>] ? __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
[<c0138e36>] warn_slowpath_fmt+0x26/0x30
[<f89134af>] __cfg80211_disconnected+0x1ff/0x210 [cfg80211]
[<f8910262>] ? nl80211_send_deauth+0x22/0x30 [cfg80211]
[<f8911463>] __cfg80211_send_deauth+0x213/0x260 [cfg80211]
[<f89ea7a3>] ? __sta_info_free+0x33/0x40 [mac80211]
[<f89ea9d3>] ? sta_info_destroy+0xf3/0x100 [mac80211]
[<f89f1384>] ? ieee80211_set_disassoc+0x174/0x1d0 [mac80211]
[<f891150e>] cfg80211_send_deauth+0x5e/0x70 [cfg80211]
[<f89f2f31>] ieee80211_sta_work+0x901/0x1820 [mac80211]
[<c0134ca1>] ? update_curr+0x1b1/0x1c0
[<c013502d>] ? dequeue_task_fair+0x29d/0x2b0
[<c010254d>] ? __switch_to+0xad/0x1a0
[<c012a10f>] ? set_next_entity+0x11f/0x1b0
[<c03a3c65>] ? schedule+0x495/0xa40
[<c014fbea>] ? prepare_to_wait+0x3a/0x70
[<c014b178>] worker_thread+0x148/0x210
[<f89f2630>] ? ieee80211_sta_work+0x0/0x1820 [mac80211]
[<c014f9a0>] ? autoremove_wake_function+0x0/0x50
[<c014b030>] ? worker_thread+0x0/0x210
[<c014f644>] kthread+0x84/0x90
[<c014f5c0>] ? kthread+0x0/0x90
[<c0104667>] kernel_thread_helper+0x7/0x10
---[ end trace 46565fb73d858208 ]---
wlan0: direct probe to AP 00:0b:85:6f:12:ac (try 1)
wlan0 direct probe responded
wlan0: authenticate with AP 00:0b:85:6f:12:ac (try 1)
wlan0: authenticated
wlan0: associate with AP 00:0b:85:6f:12:ac (try 1)
wlan0: RX ReassocResp from 00:0b:85:6f:12:ac (capab=0x431 status=0 aid=25)
wlan0: associated
sometimes no re-connect, until manual /etc/init.d/network restart
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Frans Pop @ 2009-09-09 15:59 UTC (permalink / raw)
To: Mel Gorman
Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl
In-Reply-To: <20090909150418.GI24614@csn.ul.ie>
On Wednesday 09 September 2009, Mel Gorman wrote:
> Franz, in the full dmesg was there any mention of "SLUB: Unable to
> allocate memory on node"?
No, nothing at all. I double checked the kernel log, but it was completely
quiet in the hours before and after the messages I already posted.
> Also, did you have any slub debug options enabled on the command line?
Nope.
Cheers,
FJP
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Mel Gorman @ 2009-09-09 15:04 UTC (permalink / raw)
To: Larry Finger
Cc: John W. Linville, Pekka Enberg, Frans Pop, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl
In-Reply-To: <4AA67139.80301@lwfinger.net>
On Tue, Sep 08, 2009 at 09:59:05AM -0500, Larry Finger wrote:
> John W. Linville wrote:
> > On Tue, Sep 08, 2009 at 02:11:35PM +0300, Pekka Enberg wrote:
> >> On Tue, Sep 8, 2009 at 1:54 PM, Mel Gorman<mel@csn.ul.ie> wrote:
> >>> My feeling is also that a number of these page allocation failures have
> >>> been related to wireless drivers. Is that accurate? If so, have there
> >>> been changes made to the wireless stack in this cycle that would have
> >>> increased the order of pages allocated?
> >> That's my general feeling as well. We have linux-wireless CC'd so
> >> maybe this rings a bell for them.
> >
> > AFAIK, this is only the second separate report. The other related
> > to ipw2200, which actually shares no code with the iwlagn driver and
> > is not based on the mac80211 stack.
>
> A previous issue concerned the interaction between wireless and SLUB
> debugging that caused O(0) allocations to get bumped to O(1), but that
Ok, but now they are getting bumped to order-2 because that is the allocation
failure that's happening here. That's pretty risky for a __GFP_HIGH|__GFP_COMP
allocation - i.e. high-priority and atomic allocation.
> was not relevant to this case either. I'm not aware of any other page
> allocation problems with wireless.
>
Are atomic order-2 allocations really expected in wireless or has something
else changed recently? Other than slub-debug, what options have been
recently added that can push kmalloc() requests up slightly and possible
make an order-1 allocation an order-2? If it's not in wireless, has there
been additional padding added to skbuffs in the networking layer that might
have pushed an allocation over an order-1 boundary increasing the size of
the allocation to order-2?
The reporter says that the machine grinds for a bit and recovers which
is consistent with kswapd kicking in to reclaim the contiguous pages but
it's hardly desirable.
Franz, in the full dmesg was there any mention of "SLUB: Unable to allocate
memory on node"? If so, could you post the contents of that as well because
it should tell us more about the slab allocation that failed which vaguely
looks like the path that went splat. Also, did you have any slub debug
options enabled on the command line?
Thanks
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: AP: ath5k + hostapd occasionally sulks
From: Bob Copeland @ 2009-09-09 13:00 UTC (permalink / raw)
To: Philip Prindeville, jon.fairbairn; +Cc: linux-wireless
In-Reply-To: <4AA69A0D.3040608@redfish-solutions.com>
On Tue, Sep 8, 2009 at 1:53 PM, Philip Prindeville
<philipp_subx@redfish-solutions.com> wrote:
> I pulled compat-wireless from GIT last night (or about 1:30am mountain,
> really) and rebuilt a 2.6.27.29 kernel.
>
> I'm seeing a lot of:
>
> Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packet
>
>
> one every 10 seconds, in fact. This is with an Engenius EMP-8062+ card:
Ok, the timing information is useful. This is probably something (beacon
sending?) racing with the periodic calibration, which temporarily stops
all of the tx traffic and frees the tx buffers, then starts it all up
again. In short, apart from the logging this shouldn't cause any
problems, but we should probably disable the beacon tasklet during this
time.
If this only appeared all of a sudden in recent compat snapshots, it
would be useful to know the last one that worked normally.
> I'll probably have to reboot regularly, since this is on an embedded box
> with limited CF filesystem, and I can't overflow my /var partition...
Ouch. For now, just take it out or demote it to debug.
As for the original problem, I don't know offhand why a large download
would trigger a cascade of these errors. The best way to track it down
is to try to come up with a case that reproduces it and sprinkle printks
throughout the driver, especially when we free and allocate the tx
buffers.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] cfg80211: allow scanning on specified frequencies when using wext-compatibility
From: Holger Schurig @ 2009-09-09 11:09 UTC (permalink / raw)
To: John W Linville, linux-wireless, Johannes Berg
Handles the case when SIOCSIWSCAN specified iw_scan_req.num_channels and
iw_scan_req.channels[].
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Index: linux-wl/net/wireless/scan.c
===================================================================
--- linux-wl.orig/net/wireless/scan.c 2009-09-09 10:38:58.000000000 +0200
+++ linux-wl/net/wireless/scan.c 2009-09-09 11:59:39.000000000 +0200
@@ -607,6 +607,9 @@ int cfg80211_wext_siwscan(struct net_dev
if (!netif_running(dev))
return -ENETDOWN;
+ if (wrqu->data.length == sizeof(struct iw_scan_req))
+ wreq = (struct iw_scan_req *)extra;
+
rdev = cfg80211_get_dev_from_ifindex(dev_net(dev), dev->ifindex);
if (IS_ERR(rdev))
@@ -619,9 +622,14 @@ int cfg80211_wext_siwscan(struct net_dev
wiphy = &rdev->wiphy;
- for (band = 0; band < IEEE80211_NUM_BANDS; band++)
- if (wiphy->bands[band])
- n_channels += wiphy->bands[band]->n_channels;
+ /* Determine number of channels, needed to allocate creq */
+ if (wreq && wreq->num_channels)
+ n_channels = wreq->num_channels;
+ else {
+ for (band = 0; band < IEEE80211_NUM_BANDS; band++)
+ if (wiphy->bands[band])
+ n_channels += wiphy->bands[band]->n_channels;
+ }
creq = kzalloc(sizeof(*creq) + sizeof(struct cfg80211_ssid) +
n_channels * sizeof(void *),
@@ -638,22 +646,41 @@ int cfg80211_wext_siwscan(struct net_dev
creq->n_channels = n_channels;
creq->n_ssids = 1;
- /* all channels */
+ /* translate "Scan on frequencies" request */
i = 0;
for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
int j;
if (!wiphy->bands[band])
continue;
for (j = 0; j < wiphy->bands[band]->n_channels; j++) {
+
+ /* If we have a wireless request structure and the
+ * wireless request specifies frequencies, then search
+ * for the matching hardware channel.
+ */
+ if (wreq && wreq->num_channels) {
+ int k;
+ int wiphy_freq = wiphy->bands[band]->channels[j].center_freq;
+ for (k = 0; k < wreq->num_channels; k++) {
+ int wext_freq = wreq->channel_list[k].m / 100000;
+ if (wext_freq == wiphy_freq)
+ goto wext_freq_found;
+ }
+ goto wext_freq_not_found;
+ }
+
+ wext_freq_found:
creq->channels[i] = &wiphy->bands[band]->channels[j];
i++;
+ wext_freq_not_found: ;
}
}
- /* translate scan request */
- if (wrqu->data.length == sizeof(struct iw_scan_req)) {
- wreq = (struct iw_scan_req *)extra;
+ /* Set real number of channels specified in creq->channels[] */
+ creq->n_channels = i;
+ /* translate "Scan for SSID" request */
+ if (wreq) {
if (wrqu->data.flags & IW_SCAN_THIS_ESSID) {
if (wreq->essid_len > IEEE80211_MAX_SSID_LEN)
return -EINVAL;
^ permalink raw reply
* [PATCH 4/4] ath9k: Initialize the priority gpio for BT coex 3-wire
From: Vasanthakumar Thiagarajan @ 2009-09-09 9:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
In-Reply-To: <1252490152-19284-3-git-send-email-vasanth@atheros.com>
Oops, a stupid mistake in the original patch which adds coex 3-wire
support. Bluetooth priority gpio needs to be gpio 7.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/btcoex.h | 1 +
drivers/net/wireless/ath/ath9k/hw.c | 6 ++++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/btcoex.h b/drivers/net/wireless/ath/ath9k/btcoex.h
index f1baf66..297b027 100644
--- a/drivers/net/wireless/ath/ath9k/btcoex.h
+++ b/drivers/net/wireless/ath/ath9k/btcoex.h
@@ -19,6 +19,7 @@
#define ATH_WLANACTIVE_GPIO 5
#define ATH_BTACTIVE_GPIO 6
+#define ATH_BTPRIORITY_GPIO 7
#define ATH_BTCOEX_DEF_BT_PERIOD 45
#define ATH_BTCOEX_DEF_DUTY_CYCLE 55
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index c39693b..b6c6cca 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -3691,10 +3691,12 @@ void ath9k_hw_fill_cap_info(struct ath_hw *ah)
btcoex_info->btactive_gpio = ATH_BTACTIVE_GPIO;
btcoex_info->wlanactive_gpio = ATH_WLANACTIVE_GPIO;
- if (AR_SREV_9285(ah))
+ if (AR_SREV_9285(ah)) {
btcoex_info->btcoex_scheme = ATH_BTCOEX_CFG_3WIRE;
- else
+ btcoex_info->btpriority_gpio = ATH_BTPRIORITY_GPIO;
+ } else {
btcoex_info->btcoex_scheme = ATH_BTCOEX_CFG_2WIRE;
+ }
} else {
btcoex_info->btcoex_scheme = ATH_BTCOEX_CFG_NONE;
}
--
1.5.5.1
^ permalink raw reply related
* [PATCH 3/4] ath9k: Get rid of the modparam btcoex_enable
From: Vasanthakumar Thiagarajan @ 2009-09-09 9:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
In-Reply-To: <1252490152-19284-2-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8d77817..c39693b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -21,10 +21,6 @@
#include "ath9k.h"
#include "initvals.h"
-static int btcoex_enable;
-module_param(btcoex_enable, bool, 0);
-MODULE_PARM_DESC(btcoex_enable, "Enable Bluetooth coexistence support");
-
#define ATH9K_CLOCK_RATE_CCK 22
#define ATH9K_CLOCK_RATE_5GHZ_OFDM 40
#define ATH9K_CLOCK_RATE_2GHZ_OFDM 44
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/4] ath9k: Enable btcoex based on the subsystem id of the device
From: Vasanthakumar Thiagarajan @ 2009-09-09 9:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
In-Reply-To: <1252490152-19284-1-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/btcoex.c | 23 +++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/btcoex.h | 1 +
drivers/net/wireless/ath/ath9k/hw.c | 3 ++-
drivers/net/wireless/ath/ath9k/hw.h | 4 ++++
4 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/btcoex.c b/drivers/net/wireless/ath/ath9k/btcoex.c
index e8bfb01..55f607b 100644
--- a/drivers/net/wireless/ath/ath9k/btcoex.c
+++ b/drivers/net/wireless/ath/ath9k/btcoex.c
@@ -19,6 +19,29 @@
static const struct ath_btcoex_config ath_bt_config = { 0, true, true,
ATH_BT_COEX_MODE_SLOTTED, true, true, 2, 5, true };
+static const u16 ath_subsysid_tbl[] = {
+ AR9280_COEX2WIRE_SUBSYSID,
+ AT9285_COEX3WIRE_SA_SUBSYSID,
+ AT9285_COEX3WIRE_DA_SUBSYSID
+};
+
+/*
+ * Checks the subsystem id of the device to see if it
+ * supports btcoex
+ */
+bool ath_btcoex_supported(u16 subsysid)
+{
+ int i;
+
+ if (!subsysid)
+ return false;
+
+ for (i = 0; i < ARRAY_SIZE(ath_subsysid_tbl); i++)
+ if (subsysid == ath_subsysid_tbl[i])
+ return true;
+
+ return false;
+}
/*
* Detects if there is any priority bt traffic
diff --git a/drivers/net/wireless/ath/ath9k/btcoex.h b/drivers/net/wireless/ath/ath9k/btcoex.h
index 4556819..f1baf66 100644
--- a/drivers/net/wireless/ath/ath9k/btcoex.h
+++ b/drivers/net/wireless/ath/ath9k/btcoex.h
@@ -79,6 +79,7 @@ struct ath_btcoex_info {
struct ath_gen_timer *no_stomp_timer; /*Timer for no BT stomping*/
};
+bool ath_btcoex_supported(u16 subsysid);
int ath9k_hw_btcoex_init(struct ath_hw *ah);
void ath9k_hw_btcoex_enable(struct ath_hw *ah);
void ath9k_hw_btcoex_disable(struct ath_hw *ah);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 97a09db..8d77817 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -3690,7 +3690,8 @@ void ath9k_hw_fill_cap_info(struct ath_hw *ah)
pCap->num_antcfg_2ghz =
ah->eep_ops->get_num_ant_config(ah, ATH9K_HAL_FREQ_BAND_2GHZ);
- if (AR_SREV_9280_10_OR_LATER(ah) && btcoex_enable) {
+ if (AR_SREV_9280_10_OR_LATER(ah) &&
+ ath_btcoex_supported(ah->hw_version.subsysid)) {
btcoex_info->btactive_gpio = ATH_BTACTIVE_GPIO;
btcoex_info->wlanactive_gpio = ATH_WLANACTIVE_GPIO;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 64ea547..9106a0b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -45,6 +45,10 @@
#define AR5416_DEVID_AR9287_PCI 0x002D
#define AR5416_DEVID_AR9287_PCIE 0x002E
+#define AR9280_COEX2WIRE_SUBSYSID 0x309b
+#define AT9285_COEX3WIRE_SA_SUBSYSID 0x30aa
+#define AT9285_COEX3WIRE_DA_SUBSYSID 0x30ab
+
/* Register read/write primitives */
#define REG_WRITE(_ah, _reg, _val) ath9k_iowrite32((_ah), (_reg), (_val))
#define REG_READ(_ah, _reg) ath9k_ioread32((_ah), (_reg))
--
1.5.5.1
^ permalink raw reply related
* [PATCH 1/4] ath9k: Store subsystem id in struct hw_version
From: Vasanthakumar Thiagarajan @ 2009-09-09 9:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
This subsystem id will be used later to turn on the btcoex
support.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 7 ++++---
drivers/net/wireless/ath/ath9k/pci.c | 4 +++-
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
index 7dc6301..2ad7d02 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -119,7 +119,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
sc->bus_ops = &ath_ahb_bus_ops;
sc->irq = irq;
- ret = ath_init_device(AR5416_AR9100_DEVID, sc);
+ ret = ath_init_device(AR5416_AR9100_DEVID, sc, 0x0);
if (ret) {
dev_err(&pdev->dev, "failed to initialize device\n");
goto err_free_hw;
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 1c68a9d..1d59f10 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -658,7 +658,7 @@ extern struct ieee80211_ops ath9k_ops;
irqreturn_t ath_isr(int irq, void *dev);
void ath_cleanup(struct ath_softc *sc);
-int ath_init_device(u16 devid, struct ath_softc *sc);
+int ath_init_device(u16 devid, struct ath_softc *sc, u16 subsysid);
void ath_detach(struct ath_softc *sc);
const char *ath_mac_bb_name(u32 mac_bb_version);
const char *ath_rf_name(u16 rf_version);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index a592f1a..64ea547 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -390,6 +390,7 @@ struct ath9k_hw_version {
u16 phyRev;
u16 analog5GhzRev;
u16 analog2GhzRev;
+ u16 subsysid;
};
/* Generic TSF timer definitions */
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index ce011ab..3dc7b5a 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1310,7 +1310,7 @@ static int ath9k_reg_notifier(struct wiphy *wiphy,
* to allow the separation between hardware specific
* variables (now in ath_hw) and driver specific variables.
*/
-static int ath_init_softc(u16 devid, struct ath_softc *sc)
+static int ath_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid)
{
struct ath_hw *ah = NULL;
int r = 0, i;
@@ -1348,6 +1348,7 @@ static int ath_init_softc(u16 devid, struct ath_softc *sc)
ah->ah_sc = sc;
ah->hw_version.devid = devid;
+ ah->hw_version.subsysid = subsysid;
sc->sc_ah = ah;
r = ath9k_hw_init(ah);
@@ -1577,7 +1578,7 @@ void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
}
/* Device driver core initialization */
-int ath_init_device(u16 devid, struct ath_softc *sc)
+int ath_init_device(u16 devid, struct ath_softc *sc, u16 subsysid)
{
struct ieee80211_hw *hw = sc->hw;
int error = 0, i;
@@ -1585,7 +1586,7 @@ int ath_init_device(u16 devid, struct ath_softc *sc)
DPRINTF(sc, ATH_DBG_CONFIG, "Attach ATH hw\n");
- error = ath_init_softc(devid, sc);
+ error = ath_init_softc(devid, sc, subsysid);
if (error != 0)
return error;
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 8b28814..903dd8a 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -88,6 +88,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
struct ath_softc *sc;
struct ieee80211_hw *hw;
u8 csz;
+ u16 subsysid;
u32 val;
int ret = 0;
struct ath_hw *ah;
@@ -178,7 +179,8 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
sc->mem = mem;
sc->bus_ops = &ath_pci_bus_ops;
- ret = ath_init_device(id->device, sc);
+ pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &subsysid);
+ ret = ath_init_device(id->device, sc, subsysid);
if (ret) {
dev_err(&pdev->dev, "failed to initialize device\n");
goto bad3;
--
1.5.5.1
^ permalink raw reply related
* Re: b43 dma error
From: Dave Young @ 2009-09-09 8:05 UTC (permalink / raw)
To: Larry Finger
Cc: Gábor Stefanik, John Daiker, Michael Buesch, linville,
linux-wireless, bcm43xx-dev
In-Reply-To: <4AA6A2B3.2010300@lwfinger.net>
2009/9/9 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor Stefanik wrote:
>> On Tue, Sep 8, 2009 at 8:16 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>> Your PHY and your radio are the same as mine. In fact, the one thing I
>>> noticed is that you are using i386 architecture, whereas mine is
>>> x86_64. I have not tested with i386.
>>>
>>> Has anyone run the LP PHY modifications with 32-bit architecture?
>>
>> Yes, me. (With the exact same card as John.)
>
> Is it a maximum memory issue? How much for you?
1G memory for me.
>
> John and Dave: Same question.
>
> Larry
>
--
Regards
dave
^ permalink raw reply
* Re: b43 dma error
From: Dave Young @ 2009-09-09 8:02 UTC (permalink / raw)
To: Larry Finger
Cc: Michael Buesch, linville, netrolller.3d, linux-wireless,
bcm43xx-dev
In-Reply-To: <4AA67009.4020400@lwfinger.net>
On Tue, Sep 8, 2009 at 10:54 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Michael Buesch wrote:
>> On Tuesday 08 September 2009 15:47:32 Dave Young wrote:
>>> I tested wireless-testing b43 driver, but got "Fatal DMA error"
>>> then the controller keep restarting...
>>>
>>> Please tell what I can provide or test, Thanks.
>>
>> Is this a regression? If so, please bisect.
>
> It is something specific to his system as I don't see anything like
> this. In addition, there are some users on the openSUSE forums that
> have implemented the latest compat-wireless and switched away from
> Broadcom wl to b43 on their LP PHY devices. So far, no complaints from
> them.
>
> Please reboot so that we see the ssb output as well. Use the command
>
> dmesg | egrep "ssb|b43"
>
> That way we will be able to see exactly what kind of device you have
> and what revisions are in it. AFAIK, the testing to date has been
> limited to Rev 1 PHYs and Rev 2 radios.
I use a public pc and I have no lan access for my laptop, so just hand
copy something:
b43-pci-bridge 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
b43-pci-bridge 0000:0c:00.0: setting latency timer to 64
ssb SInics Silicon Backplane found on PCI device 0000:0c:00.0
b43-phy0: Broadcom 4312 WLAN found (core revision 15)
b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
>
> Larry
>
>
>
--
Regards
dave
^ permalink raw reply
* Re: AP: ath5k + hostapd occasionally sulks
From: Jon Fairbairn @ 2009-09-09 8:01 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4AA69A0D.3040608@redfish-solutions.com>
Philip Prindeville
<philipp_subx@redfish-solutions.com> writes:
> I pulled compat-wireless from GIT last night (or about 1:30am mountain,
> really) and rebuilt a 2.6.27.29 kernel.
>
> I'm seeing a lot of:
>
> Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packet
> Is this a known issue? Jon posted the same question, but I didn't see an
> answer to his question...
Most of the time it works and I don't see anything in the logs, so your
problem is worse than mine... I'm now running
compat-wireless-2009-09-07, but I doubt if that's any different.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* Re: b43 dma error
From: Markus Mueller @ 2009-09-09 7:41 UTC (permalink / raw)
To: Larry Finger
Cc: Gábor Stefanik, John Daiker, Michael Buesch, Dave Young,
linville, linux-wireless, bcm43xx-dev
In-Reply-To: <4AA70DD6.8040905@lwfinger.net>
On Tue, Sep 08, 2009 at 09:07:18PM -0500, Larry Finger wrote:
> After some tests with the 32-bit architecture, I'm now thoroughly
> confused. I tried different memory models including PAE - everything
> worked. I even generated a 2.6.31-rc9-wl kernel with John's config and
> it worked. Whatever is happening is not related to his configuration.
> I'm not sure what the problem is.
>
> I'm going to be offline for a few days - I hope the solution will be
> in my mailbox by the weekend.
I hope so, too :)
I have the same b4312 dma errors.
$ dmesg | tail -7
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
__ratelimit: 8 callbacks suppressed
b43-phy0 ERROR: Fatal DMA error: 0x00000400, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
b43-phy0: Controller RESET (DMA error) ...
b43-phy0: Controller restarted
b43-phy0: Controller restarted
I built b43 from daily tarball compat-wireless-2009-09-07,tar.bz2 .
Card: B4312 low-power phy,
BCM4312 802.11b/g [14e4:4315] (rev 01) (on a Dell Mini 10, N-Series).
Kernel: 2.6.31-rc9 . 32bit.
Hyperthreading Patch: I assume this means
http://bu3sch.de/patches/wireless-testing/20090816-1535/patches/002-b43-threaded-irq-handler.patch
I did not actually apply this patch, i just checked the source for a few
lines added in this patch and assumed it is merged in the daily tarball
already. Is this correct?
Firmware: Debian Sid. b43-fwcutter version 012 comes with 4.150 fw it
seems. On Openwrt I only found the afore mentioned "v478" firmware
http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2 .
b43-fwcutter does not work with it. Is there documentation as to how
to extract newer firmware?
I couldn't find the v5xx firmware. It's nowhere on your sites, is it?
Let me know if there is something I can do to help, but be aware I am
not knowledgeable with linux-wireless, it's my first WLAN Device in
Years. And your site is a bit.. confused.. errm confusing ;)
Cheers,
Markus
^ permalink raw reply
* Re: b43 dma error
From: Dave Young @ 2009-09-09 7:56 UTC (permalink / raw)
To: Michael Buesch; +Cc: linville, netrolller.3d, linux-wireless, bcm43xx-dev
In-Reply-To: <200909081638.36897.mb@bu3sch.de>
On Tue, Sep 8, 2009 at 10:38 PM, Michael Buesch<mb@bu3sch.de> wrote:
> On Tuesday 08 September 2009 15:47:32 Dave Young wrote:
>> I tested wireless-testing b43 driver, but got "Fatal DMA error"
>> then the controller keep restarting...
>>
>> Please tell what I can provide or test, Thanks.
>
> Is this a regression? If so, please bisect.
Not sure, It's the first time for me to use b43 with the lp-phy
because I happend to know it is supported now.
If it's a regression I can do bisection.
>
> --
> Greetings, Michael.
>
--
Regards
dave
^ permalink raw reply
* Re: b43 dma error
From: Dave Young @ 2009-09-09 7:54 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: mb, linville, linux-wireless, bcm43xx-dev
In-Reply-To: <69e28c910909080708n5233a6cfue555bfce170eb145@mail.gmail.com>
2009/9/8 Gábor Stefanik <netrolller.3d@gmail.com>:
> Do you have the threaded-IRQ patches applied?
Could you point the url? where can I get them?
> Also, what card is this?
> (BCM4312?) Try upgrading your firmare (use v478 or the new v5xx one).
>
Yes, BCM4312, I use the firmware according to the guide in
linux-wireless web page, where is the v5xx, could you tell more?
--
Regards
dave
^ permalink raw reply
* ath_tx_start+0xa6 kmemleak -- mac80211 traceb
From: Luis R. Rodriguez @ 2009-09-09 6:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
unreferenced object 0xffff88003a905720 (size 96):
comm "softirq", pid 0, jiffies 4295254599
hex dump (first 32 bytes):
40 98 9e 19 00 88 ff ff 00 00 00 00 00 00 00 00 @...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814ea375>] kmemleak_alloc+0x25/0x60
[<ffffffff81118c1b>] kmem_cache_alloc+0x14b/0x1c0
[<ffffffffa03e6cd6>] ath_tx_start+0xa6/0x8d0 [ath9k]
[<ffffffffa03dfc13>] ath9k_tx+0x133/0x2a0 [ath9k]
[<ffffffffa0247e2b>] __ieee80211_tx+0xfb/0x190 [mac80211]
[<ffffffffa0249589>] ieee80211_tx+0xf9/0x2e0 [mac80211]
[<ffffffffa0249886>] ieee80211_xmit+0x116/0x2c0 [mac80211]
[<ffffffffa0249a81>] ieee80211_tx_skb+0x51/0x70 [mac80211]
[<ffffffffa023df3d>] ieee80211_sta_work+0x6fd/0x10d0 [mac80211]
[<ffffffff8106de60>] worker_thread+0x1d0/0x380
[<ffffffff81073246>] kthread+0xa6/0xb0
[<ffffffff810130ca>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
But gdb shows me:
(gdb) l *(ath_tx_start+0xa6)
0x22d06 is in ath_tx_start (include/trace/events/kmem.h:47).
42 {(unsigned long)__GFP_THISNODE,
"GFP_THISNODE"}, \
43 {(unsigned long)__GFP_RECLAIMABLE,
"GFP_RECLAIMABLE"}, \
44 {(unsigned long)__GFP_MOVABLE, "GFP_MOVABLE"}
\
45 ) : "GFP_NOWAIT"
46
47 TRACE_EVENT(kmalloc,
48
49 TP_PROTO(unsigned long call_site,
50 const void *ptr,
51 size_t bytes_req,
But I don't have the mac80211 tracer enabled.
Luis
^ permalink raw reply
* Re: ar9271 TX/RX buffer management
From: Luis R. Rodriguez @ 2009-09-09 5:39 UTC (permalink / raw)
To: Denis Kirjanov, Benoit PAPILLAULT, Benoit PAPILLAULT
Cc: devel, ath9k-devel, Felix Fietkau, Christian Lamparter,
linux-wireless
Adding linux-wireless as I review ath9k/ar9170 tx/rx buffer management here.
On Tue, Sep 8, 2009 at 1:54 PM, Denis Kirjanov<kirjanov@gmail.com> wrote:
> Looks like tx/rx engine initialization code is very similar to ath9k
> driver.
I expect most of the driver to be very similar to ath9k, what changes
here is the transport and because of it support for HTC/HIF. What also
changes with the new transport requirements is the need to sleep
during read/writes. This is actually the main reason for a new
mac80211 driver interface. We could have mucked with ath9k itself but
feared that the changes are too intrusive so instead we'll work on a
different driver core where this is done. Technically it may be
possible in the future to have ath9k rely on the same driver core, who
knows but for now the job is to get ar9271 support up.
> The question is where to obtain some values such as the number of TX|RX
> buffers? Will these values are the same as that of the previous driver?
That's yet to be determined/developed and I'm glad you asked. First
let me review ath9k's TX/RX buffer management, then I'll review ar9170
buffer management and explain why I think we should consider doing
something a little different for ath9k_htc. Note I wrote ar9170, not
ar9271.
ath9k TX buffer management
========================
ath9k allocates a preset of TX buffers structs (struct ath_buf) upon
init and stuffs them into a spare buffer linked list. When mac80211
informs us it wants to TX an skb, ath9k_tx(), a buffer is taken from
this spare list, the skb is linked to the ath_buf, DMA'd and then the
ath_buf added onto the appropriate tx queue linked list depending on
the skb priority/TID. Upon TX completion the ath_buf is reset and put
back into the spare buffer list. When we are are low on spare ath_buf
buffers we ask mac80211 to stop sending us data, once we have enough
free spare buffers we wake the queues up again. We guarantee that we
will at some point tell mac80211 to send us data again as we only tell
mac80211 to stop sending us data if we have at least one pending
completion buffer list.
ath9k RX buffer management
=========================
ath9k allocates a preset of RX buffers and stuffs them into a linked
list. The buffers are DMA'd so that the hardware can stuff into each
buffer data for us to retrieve and send up to mac80211. Upon RX we
always allocate a new buffer prior to sending a frame up to mac80211
so that we can fill in the gap for the missing skb of the current skb
and if there is no more memory we stuff the buffer we currently are
processing into the free RX buffers linked list and disregard the
DMA'd data. We then tell the hardware it can use that same buffer
space again. If we were able to allocate a new buffer in place for the
current one we send it to mac80211 for processing. We use a
predetermined RX buffer size. This RX buffer size is the space
required to receive the biggest frame possible on the ath9k 802.11n
hardware -- which happens to be the biggest AMSDU frame. I should note
that although AMSDU frames are typically not received as I don't think
many devices or drivers support sending AMDSU frames I believe wifi
cert requires you to RX AMSDU frames. Anyway this AMSDU size
requirement pushes our RX buffer size close to 4 KB and because the
kernel only gaurantees it'll *at least* allocate the requested size we
sometimes end up allocating 8KB per buffer on some systems. We could
potentially improve upon this, I believe we'd have to link AMSDU data
together across different descriptors, and I think that's possible.
ar9170 TX buffer management
=========================
ar9170 uses a tx_pending skb_buf_head for stashing skbs mac80211 sends
it. Contrary to ath9k it uses the skb to place the private driver tx
control info for the skb to indicate to the hardware how to transmit
that frame. Aggregates are put into an another skb_queue_head for the
destination TID for the destination sta and that TID is added to a
linked list of pending TIDs which need processing. It later iterates
through the list of TIDs, and queues pending buffers ont the
tx_pending skb_buf_head. Eventually we peg the skb->data onto a urb
and submit it to the device on the endpoint.
ar9170 RX buffer management
==========================
ar9170 uses a USB stream mode to receive buffers. This means a single
urb received being processed can contain more than one data buffer.
This gets untangled by ar9170_rx() and handled individually on
ar9170_handle_mpdu(). Because the data is tangled on a stream it means
we have to allocate an skb for each frame and then copy the data onto
it. This is done on ar9170_rx_copy_data().
-------------
What I'd like to eventually see is a common shared buffer management
for TX for aggregation for drivers like ar9170 or ath9k where
aggregation is done in software. Then we won't have such different
implementations. Using the skb_buf_head usage on ar9170 seems
appealing over ath9k's linked list of buffers, however not that this
is easily possible on ar9170 as the skb->data is simply filled with
the ar9170_tx_control info. I can't think of a way to do the same on
ath9k. If we can figure out a way it'd be great so we can try to
eventually share buffer management for aggregation on mac80211. I
shall note some aspects of aggregation is handled in firmware for
ar9271, haven't gotten to review what exactly yet.
One thing which I think we should learn from how ar9170 is implemented
for ar9271 is using urb anchors.
Luis
^ permalink raw reply
* Re: [PATCH] ath5k: do not free irq after resume when card has been removed
From: Bob Copeland @ 2009-09-09 3:32 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: ath5k-devel, linux-wireless, netdev, linux-kernel, lrodriguez,
mickflemm, jirislaby, linville, johannes
In-Reply-To: <1252457551-4909-1-git-send-email-cascardo@holoscopio.com>
On Tue, Sep 08, 2009 at 09:52:31PM -0300, Thadeu Lima de Souza Cascardo wrote:
> ath5k will try to request irq when resuming and fails if the device
> (like a PCMCIA card) has been removed.
That's not true, ath5k no longer requests an irq when resuming.
> This solves this issue defining a new flag for the status bitmap to
> indicate when irq has been successfully requested and does not try to
> release it if not.
I'd rather not fix it with a status bit. What kernel is this against?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [ANN] wireless-regdb: master-2009-09-08
From: wireless @ 2009-09-09 3:10 UTC (permalink / raw)
To: linux-wireless
A new release of wireless-regdb (master-2009-09-08) is available at:
http://wireless.kernel.org/download/wireless-regdb/wireless-regdb-2009.09.08.tar.bz2
SHA1 sum: 182af543939be630f2d106028966aabffc145b91
For your convenience the individual regulatory.bin file can be downloaded from:
http://wireless.kernel.org/download/wireless-regdb/regulatory.bins/2009.09.08-regulatory.bin
SHA1 sum 9a4b9cdb1d9147dba37a4d44b0d73e3015574a2e
Here is the short log of the changes included in this
release:
John W. Linville (1):
wireless-regdb: update regulatory.bin based on preceding changes.
Luis R. Rodriguez (1):
wireless-regdb: TH gets 5 GHz enabled as of new regulatory rules
^ 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