From: Max Filippov <jcmvbkbc@gmail.com>
To: Christian Lamparter <chunkeey@web.de>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org,
"John W. Linville" <linville@tuxdriver.com>
Subject: Re: p54spi - mesh mode summary
Date: Sun, 29 Mar 2009 07:41:59 +0300 [thread overview]
Message-ID: <200903290841.59902.jcmvbkbc@gmail.com> (raw)
In-Reply-To: <200903282251.42585.chunkeey@web.de>
> your last patches had some offset, do you have more code fixes or
> does everything work (properly)?
The offset is caused by the fact that I haven't merged in changes that has been done since 2009.01.09.
Now I've cherry-picked all recent patches related to p54, and IBSS and mesh are working good.
There are 3 issues that I'm focused on now:
- 'cx3110x spi2.0: WR_READY timeout' which sometimes occurs on ifdown-ifup cycle. Communication
with firmware breaks and sometimes the box hangs altogether. It looks like some locking-concurrency
issue, but I still haven't found it for sure;
- this, which happens every time when IBSS or mesh starts:
<7>[ 211.754448] wlan0: Creating new IBSS network, BSSID 56:75:0c:c5:65:0d
<7>[ 213.681352] phy0: Adding new IBSS station 00:1d:6e:9b:ee:6d (dev=wlan0)
<7>[ 213.681443] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<4>[ 213.684251] ------------[ cut here ]------------
<4>[ 213.691850] WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
<4>[ 213.699571] Modules linked in: p54spi
<4>[ 213.707231] [<c0034ff8>] (dump_stack+0x0/0x14) from [<c005b1f0>] (warn_on_slowpath+0x4c/0x68)
<4>[ 213.715623] [<c005b1a4>] (warn_on_slowpath+0x0/0x68) from [<c006051c>] (local_bh_enable+0x54/0xbc)
<4>[ 213.732041] r6:c7cc4e00 r5:c7840380 r4:c04594a0
<4>[ 213.740464] [<c00604c8>] (local_bh_enable+0x0/0xbc) from [<bf000038>] (p54spi_op_tx+0x38/0x4c [p54spi])
<4>[ 213.757829] r4:c7cc4e00
<4>[ 213.766221] [<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi]) from [<c01a4d98>] (p54_sta_unlock+0x64/0x78)
<4>[ 213.784135] r5:c7cc41a0 r4:c7840380
<4>[ 213.793016] [<c01a4d34>] (p54_sta_unlock+0x0/0x78) from [<c01a4dd4>] (p54_sta_notify+0x28/0x2c)
<4>[ 213.802507] r7:c7971380 r6:c7cc41a0 r5:60000013 r4:c79cd400
<4>[ 213.812120] [<c01a4dac>] (p54_sta_notify+0x0/0x2c) from [<c02e0a60>] (sta_info_insert+0x128/0x19c)
<4>[ 213.831681] [<c02e0938>] (sta_info_insert+0x0/0x19c) from [<c02e7b90>] (ieee80211_ibss_add_sta+0x150/0x170)
<4>[ 213.852830] r8:00000000 r7:c79cd400 r6:c7971380 r5:00000000 r4:c0416500
<4>[ 213.863786] [<c02e7a40>] (ieee80211_ibss_add_sta+0x0/0x170) from [<c02e7e3c>] (ieee80211_rx_bss_info+0x188/0x48c)
<4>[ 213.886033] r8:c701ee24 r7:00000000 r6:00000fff r5:c701ee24 r4:c701ee2e
<4>[ 213.897386] [<c02e7cb4>] (ieee80211_rx_bss_info+0x0/0x48c) from [<c02e8fac>] (ieee80211_sta_work+0x388/0xfe8)
<4>[ 213.919816] [<c02e8c24>] (ieee80211_sta_work+0x0/0xfe8) from [<c006b2bc>] (run_workqueue+0xa8/0x124)
<4>[ 213.942948] [<c006b214>] (run_workqueue+0x0/0x124) from [<c006be20>] (worker_thread+0xec/0x100)
<4>[ 213.955003] r6:c79764e0 r5:c79dc000 r4:c79764e8
<4>[ 213.966783] [<c006bd34>] (worker_thread+0x0/0x100) from [<c006ee28>] (kthread+0x5c/0x94)
<4>[ 213.978746] r6:c006bd34 r5:c79764e0 r4:c79dc000
<4>[ 213.990586] [<c006edcc>] (kthread+0x0/0x94) from [<c005dd48>] (do_exit+0x0/0x6cc)
<4>[ 214.002580] r6:00000000 r5:00000000 r4:00000000
<4>[ 214.014238] ---[ end trace 3652d538aa1ad903 ]---
- infinite beacon resubmission loop in IBSS which causes severe performance degradation, not to mention radio noise.
Before TSF sync loss:
(none):~# ping -s 50000 192.168.4.14
PING 192.168.4.14 (192.168.4.14): 50000 data bytes
50008 bytes from 192.168.4.14: seq=0 ttl=64 time=130.4 ms
50008 bytes from 192.168.4.14: seq=1 ttl=64 time=129.9 ms
50008 bytes from 192.168.4.14: seq=2 ttl=64 time=130.4 ms
50008 bytes from 192.168.4.14: seq=3 ttl=64 time=132.9 ms
50008 bytes from 192.168.4.14: seq=4 ttl=64 time=133.6 ms
After:
(none):~# ifconfig wlan0 down
(none):~# ifconfig wlan0 up
(none):~# ping -s 50000 192.168.4.14
PING 192.168.4.14 (192.168.4.14): 50000 data bytes
50008 bytes from 192.168.4.14: seq=1 ttl=64 time=629.1 ms
50008 bytes from 192.168.4.14: seq=2 ttl=64 time=825.8 ms
50008 bytes from 192.168.4.14: seq=3 ttl=64 time=421.2 ms
50008 bytes from 192.168.4.14: seq=4 ttl=64 time=745.5 ms
50008 bytes from 192.168.4.14: seq=5 ttl=64 time=548.0 ms
50008 bytes from 192.168.4.14: seq=6 ttl=64 time=296.1 ms
50008 bytes from 192.168.4.14: seq=7 ttl=64 time=501.2 ms
Hope that I make patches for at least first two issues during the next few days.
--
Thanks a lot (:
-- Max
next prev parent reply other threads:[~2009-03-29 4:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 5:30 [PATCH 1/2] p54spi: mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit Max Filippov
2009-03-25 5:30 ` [PATCH 2/2] p54spi: fix p54_upload_firmware Max Filippov
2009-03-25 11:21 ` Christian Lamparter
2009-03-25 12:00 ` Max Filippov
2009-03-25 12:45 ` [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware Christian Lamparter
2009-03-25 12:50 ` Max Filippov
2009-03-25 12:56 ` Johannes Berg
2009-03-26 2:26 ` Max Filippov
2009-03-25 13:42 ` Christian Lamparter
2009-03-25 14:34 ` Christian Lamparter
2009-03-26 6:22 ` p54spi - mesh mode summary Max Filippov
2009-03-26 8:12 ` Johannes Berg
2009-03-27 5:03 ` Max Filippov
2009-03-27 14:06 ` Christian Lamparter
2009-03-28 3:21 ` Max Filippov
2009-03-28 21:51 ` Christian Lamparter
2009-03-29 4:41 ` Max Filippov [this message]
2009-03-29 13:49 ` Christian Lamparter
2009-03-30 4:38 ` Max Filippov
2009-03-26 1:15 ` [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware Max Filippov
2009-03-25 10:55 ` [PATCH 1/2] p54spi: mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit Christian Lamparter
-- strict thread matches above, loose matches on Subject: below --
2009-03-26 12:49 p54spi - mesh mode summary Chunkeey
2009-03-26 15:15 ` Max Filippov
2009-03-26 18:33 Christian Lamparter
2009-03-27 1:55 ` Max Filippov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200903290841.59902.jcmvbkbc@gmail.com \
--to=jcmvbkbc@gmail.com \
--cc=chunkeey@web.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).