Re: p54spi - mesh mode summary

Re: p54spi - mesh mode summary

[Christian Lamparter]

rmgl... looks like the first mail got lost... so _resend_

On Thursday 26 March 2009 16:15:24 Max Filippov wrote:
> >> 3) Beaconing works, but not the way it should: like MPs don't hear=
 each other. Timestamps never get in sync
> >> and both MPs issue beacon during 0.1s beacon interval.
> >> I've seen it before, with stlc45xx. It shows when LMAC is set up w=
ith LMAC_SETUP_IBSS | LMAC_SETUP_TRANSPARENT flags.
> >> If there's no LMAC_SETUP_TRANSPARENT flag in LMAC setup then times=
tamps get in sync.
> >
> > FYI: The TSF will always reset when a new beacon is submitted to th=
e firmware.
> > The specs talks about that.
>=20
> I'd like to make it clear: there are timestamp field in the beacon an=
d
> timestamp associated with the received packet. These two do not
> correlate. First gets reset at beacon submission (and why firmware
> wouldn't pick up timestamp from the submitted beacon?). The second
> only gets reset on firmware reset. And it seems to me that there's no
> way to find out, what the current value of beacon timestamp is. TSF
> reported in p54_rx_data is the second.

because the hardware has at least 3 timers ;)
- One for the _mactime_ (as in rx_status.mactime)
  (of course, we can always drop RX_FLAG_TSFT flag.)
- the second one for beacon - (some firmware will fire a trap for every
  beacon they send P54_TRAP_BEACON_TX )
- and one is for the user. (which we don't need...)

> And if so, how timestamp syncing is expected to work in the following=
 case:
>=20
> <7>[  353.579189] RX beacon SA=3D00:1d:6e:9b:ee:6d
> BSSID=3D7e:2e:03:09:31:25 TSF=3D0x4aaa81 BCN=3D0x618f1f6 diff=3D-9740=
4789
> @1513
> <7>[  353.579250] wlan0: beacon TSF higher than local TSF - IBSS merg=
e
> with BSSID 7e:2e:03:09:31:25
>=20
> After which stack submit new beacon which we send to LMAC, effectivel=
y
> resetting timestamp in our beacon and not affecting TSF that we would
> report on the next received frame.
I know... p54 is does not really follow IBSS standard, but TSF sync is =
not a
"MUST" for IBSS.
http://wireless.kernel.org/en/developers/Documentation/mac80211/API

> I see constant beacon resubmission cycle. How does it work on pci/usb=
 p54?
firmware does it... all we need is to submit a beacon template. The fir=
mware
knows how to extract everything it needs (e.g intervals/dtim etc.)
out of the frame itself...

> >> - when LMAC was set up with LMAC_SETUP_TRANSPARENT flag firmware s=
eem to truncate last 2 bytes of the packet
> >> =A0 that it reports.
> > Heh, that's also a ISL3887 (USB 2nd gen) bug... But PCI devices are=
 not affected.
> > The reason "why" has probably to do with the firmware's frame align=
ment code.
> > Unfortunately the firmware for (ISL3887 and SPI) is rounding "down"=
 to 4 bytes instead of up...
> > So the FCS will be clipped... But fortunately the firmware set a bi=
t in the header that tells
> > us whenever the frames was corrupted or not (P54_HDR_FLAG_DATA_IN_F=
CS_GOOD).
> Thank you for the explanation, it made me feel much better (:
>=20
> > what happens if you change p54spi_rx the following way:?
> Actually, I did this kind of thing. And it works this way.
> But I considered it a major hack, as noone acknowledged that there's =
a
> firmware problem:
>=20
> https://garage.maemo.org/pipermail/stlc45xx-devel/2009-January/000126=
=2Ehtml
>=20
> But if there's real problem in firmware, I'd consider it mere
> workaround and put it back.
>=20
yes please do... And don't worry the frame which we'll pass to mac80211
will always have the correct length, even when the extra padding wasn't=
 used.

Regards,
	Chr
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: p54spi - mesh mode summary

[Max Filippov]

> > I see constant beacon resubmission cycle. How does it work on pci/usb
> > p54?
>
> firmware does it... all we need is to submit a beacon template. The
> firmware knows how to extract everything it needs (e.g intervals/dtim etc.)
> out of the frame itself...

> > But if there's real problem in firmware, I'd consider it mere
> > workaround and put it back.
>
> yes please do... And don't worry the frame which we'll pass to mac80211
> will always have the correct length, even when the extra padding wasn't
> used.

Thanks for your explanation, it is very useful and encouraging (:

-- 
Max

Re: p54spi - mesh mode summary

[Chunkeey]

> 2) Today it doesn't reproduce. Plink establishment passes, altough, w=
arning remains:
>=20
> 3) Beaconing works, but not the way it should: like MPs don't hear ea=
ch other. Timestamps never get in sync
> and both MPs issue beacon during 0.1s beacon interval.
> I've seen it before, with stlc45xx. It shows when LMAC is set up with=
 LMAC_SETUP_IBSS | LMAC_SETUP_TRANSPARENT flags.
> If there's no LMAC_SETUP_TRANSPARENT flag in LMAC setup then timestam=
ps get in sync.

=46YI: The TSF will always reset when a new beacon is submitted to the =
firmware.
The specs talks about that.

> 4) Pings don't go, because MPs don't answer ARP requests sent to it. =
Haven't tested for the root cause yet.
> But again, I have seen this with stlc45xx with two different causes:
> - when LMAC was set up without LMAC_SETUP_TRANSPARENT flag, ARP reque=
sts didn't pass LMAC packet filter
>   and weren't reported to the driver;
Yup, that's because the firmware will filter out any frames which are n=
ot from/for the BSSID.
(the bssid the field right next to the device own MAC in p54_setup_mac)

> - when LMAC was set up with LMAC_SETUP_TRANSPARENT flag firmware seem=
 to truncate last 2 bytes of the packet
>   that it reports.
Heh, that's also a ISL3887 (USB 2nd gen) bug... But PCI devices are not=
 affected.
The reason "why" has probably to do with the firmware's frame alignment=
 code.
Unfortunately the firmware for (ISL3887 and SPI) is rounding "down" to =
4 bytes instead of up...
So the FCS will be clipped... But fortunately the firmware set a bit in=
 the header that tells
us whenever the frames was corrupted or not (P54_HDR_FLAG_DATA_IN_FCS_G=
OOD).

what happens if you change p54spi_rx the following way:?=20

-        skb =3D dev_alloc_skb(len);
+        skb =3D dev_alloc_skb(len + 4);
        if (!skb) {
                dev_err(&priv->spi->dev, "could not alloc skb");
                return 0;
        }

        p54spi_spi_read(priv, SPI_ADRS_DMA_DATA, skb_put(skb, len), len=
);
        p54spi_sleep(priv);

+      skb_put(skb, 4);=20
        if (p54_rx(priv->hw, skb) =3D=3D 0)
                dev_kfree_skb(skb);

=20
> > Is there anything else I can do, or something you want to know?
> Are there other p54 species that use 3826.arm firmware?
I guess no... there are pci/usb/spi and shmem devices but all have thei=
r own firmware.

> Are there other sources of information regarding LMAC interaction exc=
ept
> http://wireless.kernel.org/en/developers/Documentation/specs?action=3D=
AttachFile&do=3Dget&target=3DSTSW45x0C_LMAC_API_ED1P4.pdf ?

hmm, maybe the old islsm... But then, this driver is very old now...
=20
> Who should be contacted with questions about firmware behavior?
>=20
No idea, maybe nokia knows... because the "frame alignment" can also cl=
ip QoS-(Data) or WDS Frames.

Regards,
   Chr
____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger geh=F6rt?=20
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3D3124

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: p54spi - mesh mode summary

[Max Filippov]

>> 3) Beaconing works, but not the way it should: like MPs don't hear e=
ach other. Timestamps never get in sync
>> and both MPs issue beacon during 0.1s beacon interval.
>> I've seen it before, with stlc45xx. It shows when LMAC is set up wit=
h LMAC_SETUP_IBSS | LMAC_SETUP_TRANSPARENT flags.
>> If there's no LMAC_SETUP_TRANSPARENT flag in LMAC setup then timesta=
mps get in sync.
>
> FYI: The TSF will always reset when a new beacon is submitted to the =
firmware.
> The specs talks about that.

I'd like to make it clear: there are timestamp field in the beacon and
timestamp associated with the received packet. These two do not
correlate. First gets reset at beacon submission (and why firmware
wouldn't pick up timestamp from the submitted beacon?). The second
only gets reset on firmware reset. And it seems to me that there's no
way to find out, what the current value of beacon timestamp is. TSF
reported in p54_rx_data is the second.

And if so, how timestamp syncing is expected to work in the following c=
ase:

<7>[  353.579189] RX beacon SA=3D00:1d:6e:9b:ee:6d
BSSID=3D7e:2e:03:09:31:25 TSF=3D0x4aaa81 BCN=3D0x618f1f6 diff=3D-974047=
89
@1513
<7>[  353.579250] wlan0: beacon TSF higher than local TSF - IBSS merge
with BSSID 7e:2e:03:09:31:25

After which stack submit new beacon which we send to LMAC, effectively
resetting timestamp in our beacon and not affecting TSF that we would
report on the next received frame.

I see constant beacon resubmission cycle. How does it work on pci/usb p=
54?


>> - when LMAC was set up with LMAC_SETUP_TRANSPARENT flag firmware see=
m to truncate last 2 bytes of the packet
>> =A0 that it reports.
> Heh, that's also a ISL3887 (USB 2nd gen) bug... But PCI devices are n=
ot affected.
> The reason "why" has probably to do with the firmware's frame alignme=
nt code.
> Unfortunately the firmware for (ISL3887 and SPI) is rounding "down" t=
o 4 bytes instead of up...
> So the FCS will be clipped... But fortunately the firmware set a bit =
in the header that tells
> us whenever the frames was corrupted or not (P54_HDR_FLAG_DATA_IN_FCS=
_GOOD).
Thank you for the explanation, it made me feel much better (:

> what happens if you change p54spi_rx the following way:?
Actually, I did this kind of thing. And it works this way.
But I considered it a major hack, as noone acknowledged that there's a
firmware problem:

https://garage.maemo.org/pipermail/stlc45xx-devel/2009-January/000126.h=
tml

But if there's real problem in firmware, I'd consider it mere
workaround and put it back.

--=20
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] p54spi: mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit

[Max Filippov]

 Mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit.
 Without this, 'fw_upload not allowed to DMA write' is observed at both N800 and N810.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
 drivers/net/wireless/p54/p54spi.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 2b222aa..d13268f 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -171,7 +171,7 @@ static int p54spi_wait_bit(struct p54s_priv *priv, u16 reg, __le32 bits)
 
 	for (i = 0; i < 2000; i++) {
 		p54spi_spi_read(priv, reg, &buffer, sizeof(buffer));
-		if (buffer == bits)
+		if ((buffer & bits) == bits)
 			return 1;
 
 		msleep(1);
-- 
1.5.4.3

Re: [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Christian Lamparter]

On Wednesday 25 March 2009 13:50:44 Max Filippov wrote:
> >> Sorry, I haven't been used to checkpatch.
> > But your PATCH 1/2 sailed through without any complains. ;-)
> Mere coincidence (:
> 
> > BTW: does p54spi really work now?
> I haven't tested your patch yet, but with the one that I sent it does
> work in IBSS mode.
> My aim is to wind it up in mesh mode. This doesn't work, it cannot
> establish peer link.
> I'm going to investigate it. Does mesh mode work on conventional pci/usb p54?

hmm, yes... at least with wireless-testing from yesterday. (beaconing works too)

[ 9862.704138] mesh: running mesh housekeeping
[ 9906.580204] phy3: Allocated STA 00:14:a5:45:33:ff
[ 9906.581566] phy3: Inserted STA 00:14:a5:45:33:ff
[ 9906.581581] Mesh plink: starting establishment with 00:14:a5:45:33:ff
[ 9906.634055] Mesh plink (peer, state, llid, plid, event): 00:14:a5:45:33:ff 1 28312 0 1
[ 9906.636888] Mesh plink (peer, state, llid, plid, event): 00:14:a5:45:33:ff 2 28312 55519 4
[ 9906.636895] Mesh plink with 00:14:a5:45:33:ff ESTABLISHED

64 bytes from 10.0.0.2: icmp_seq=449 ttl=64 time=1.81 ms
64 bytes from 10.0.0.2: icmp_seq=450 ttl=64 time=1.41 ms
64 bytes from 10.0.0.2: icmp_seq=451 ttl=64 time=3.52 ms
...

both peers have a p54 (one is pci, the other one usb)... I'll see if I can
get my old ath5k back to verify that it works with other devices as well.

Regards,
	Chr

Re: [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Christian Lamparter]

On Wednesday 25 March 2009 14:42:58 Christian Lamparter wrote:
> On Wednesday 25 March 2009 13:50:44 Max Filippov wrote:
> > >> Sorry, I haven't been used to checkpatch.
> > > But your PATCH 1/2 sailed through without any complains. ;-)
> > Mere coincidence (:
> > 
> > > BTW: does p54spi really work now?
> > I haven't tested your patch yet, but with the one that I sent it does
> > work in IBSS mode.
> > My aim is to wind it up in mesh mode. This doesn't work, it cannot
> > establish peer link.
> > I'm going to investigate it. Does mesh mode work on conventional pci/usb p54?
> 
> hmm, yes... at least with wireless-testing from yesterday. (beaconing works too)
> 
> [ 9862.704138] mesh: running mesh housekeeping
> [ 9906.580204] phy3: Allocated STA 00:14:a5:45:33:ff
> [ 9906.581566] phy3: Inserted STA 00:14:a5:45:33:ff
> [ 9906.581581] Mesh plink: starting establishment with 00:14:a5:45:33:ff
> [ 9906.634055] Mesh plink (peer, state, llid, plid, event): 00:14:a5:45:33:ff 1 28312 0 1
> [ 9906.636888] Mesh plink (peer, state, llid, plid, event): 00:14:a5:45:33:ff 2 28312 55519 4
> [ 9906.636895] Mesh plink with 00:14:a5:45:33:ff ESTABLISHED
> 
> 64 bytes from 10.0.0.2: icmp_seq=449 ttl=64 time=1.81 ms
> 64 bytes from 10.0.0.2: icmp_seq=450 ttl=64 time=1.41 ms
> 64 bytes from 10.0.0.2: icmp_seq=451 ttl=64 time=3.52 ms
> ...
> 
> both peers have a p54 (one is pci, the other one usb)... I'll see if I can
> get my old ath5k back to verify that it works with other devices as well.

FYI, I just finished testing with a 5 node mesh network with various drivers
(ath5k, ar9170usb and p54 mesh network) and it looks like everything works
the way it should... ( testing was done with the current wireless-testing.git )

Is there anything else I can do, or something you want to know?

Regards,
	Chr

p54spi - mesh mode summary

[Max Filippov]

> FYI, I just finished testing with a 5 node mesh network with various
> drivers (ath5k, ar9170usb and p54 mesh network) and it looks like
> everything works the way it should... ( testing was done with the current
> wireless-testing.git )
Good news.

And here's what's happening in p54spi environment:
1) yesterday's logs, with plink establishment failure:

<7>[ 1438.922118] p54spi_probe
<6>[ 1438.922271] cx3110x spi2.0: firmware: requesting 3826.arm
<6>[ 1439.032744] phy0: p54 detected a LM20 firmware
<6>[ 1439.038267] p54: rx_mtu reduced from 3240 to 2376
<6>[ 1439.043883] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
<6>[ 1439.049864] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
<6>[ 1439.055754] cx3110x spi2.0: firmware: requesting 3826.eeprom
<6>[ 1439.159376] cx3110x spi2.0: loading default eeprom...
<6>[ 1439.165723] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
<7>[ 1439.222347] phy0: Selected rate control algorithm 'minstrel'
<6>[ 1439.272353] cx3110x spi2.0: device is bound to phy0
<4>[ 1439.618513] Empty flash at 0x01ef1588 ends at 0x01ef1800
<4>[ 1439.768935] Empty flash at 0x02eb9474 ends at 0x02eb9800
<7>[ 1444.630185] usb0: eth_open
<7>[ 1444.630215] usb0: eth_start
<7>[ 1444.630368] g_ether gadget: ecm_open
<7>[ 1466.055751] m0: running mesh housekeeping
<7>[ 1515.025311] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<4>[ 1515.028027] ------------[ cut here ]------------
<4>[ 1515.035626] WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
<4>[ 1515.043316] Modules linked in: p54spi
<4>[ 1515.050976] [<c0034ff8>] (dump_stack+0x0/0x14) from [<c005b1f0>] (warn_on_slowpath+0x4c/0x68)
<4>[ 1515.059308] [<c005b1a4>] (warn_on_slowpath+0x0/0x68) from [<c006051c>] (local_bh_enable+0x54/0xbc)
<4>[ 1515.075696]  r6:c7adae00 r5:c70100a0 r4:c04594a0
<4>[ 1515.084118] [<c00604c8>] (local_bh_enable+0x0/0xbc) from [<bf000038>] (p54spi_op_tx+0x38/0x4c [p54spi])
<4>[ 1515.101422]  r4:c7adae00
<4>[ 1515.109814] [<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi]) from [<c01a4dbc>] (p54_sta_unlock+0x64/0x78)
<4>[ 1515.127698]  r5:c7ada1a0 r4:c70100a0
<4>[ 1515.136548] [<c01a4d58>] (p54_sta_unlock+0x0/0x78) from [<c01a4df8>] (p54_sta_notify+0x28/0x2c)
<4>[ 1515.146008]  r7:c7f33b80 r6:c7ada1a0 r5:60000013 r4:c7dbf400
<4>[ 1515.155621] [<c01a4dd0>] (p54_sta_notify+0x0/0x2c) from [<c02e0a40>] (sta_info_insert+0x128/0x19c)
<4>[ 1515.175122] [<c02e0918>] (sta_info_insert+0x0/0x19c) from [<c02fdb44>] (mesh_neighbour_update+0x58/0xbc)
<4>[ 1515.196240]  r8:c7f33b80 r7:00000000 r6:00000fff r5:c7ada1a0 r4:c7dbf400
<4>[ 1515.207165] [<c02fdaec>] (mesh_neighbour_update+0x0/0xbc) from [<c02fc398>] (ieee80211_mesh_work+0x188/0x2c4)
<4>[ 1515.229382] [<c02fc210>] (ieee80211_mesh_work+0x0/0x2c4) from [<c006b2bc>] (run_workqueue+0xa8/0x124)
<4>[ 1515.251843] [<c006b214>] (run_workqueue+0x0/0x124) from [<c006be20>] (worker_thread+0xec/0x100)
<4>[ 1515.263653]  r6:c7ace8a0 r5:c79d2000 r4:c7ace8a8
<4>[ 1515.275311] [<c006bd34>] (worker_thread+0x0/0x100) from [<c006ee28>] (kthread+0x5c/0x94)
<4>[ 1515.287274]  r6:c006bd34 r5:c7ace8a0 r4:c79d2000
<4>[ 1515.298962] [<c006edcc>] (kthread+0x0/0x94) from [<c005dd48>] (do_exit+0x0/0x6cc)
<4>[ 1515.310834]  r6:00000000 r5:00000000 r4:00000000
<4>[ 1515.322369] ---[ end trace 6577f51800004055 ]---
<7>[ 1515.333813] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[ 1515.334075] Mesh plink: starting establishment with 00:1d:6e:9b:ee:6d
<7>[ 1515.366638] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 1 55435 0 1
<7>[ 1515.375244] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 55435 52255 5
<7>[ 1515.383087] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 55435 52255 7
<7>[ 1515.448926] Mesh plink: starting establishment with 00:1d:6e:9b:ee:6d
<7>[ 1515.565271] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 1 45266 0 1
<7>[ 1515.652472] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 45266 42191 1
<7>[ 1515.816619] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 45266 42191 1
<7>[ 1515.988764] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 45266 42191 1
<7>[ 1516.222413] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 45266 42191 7
<7>[ 1516.384869] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1516.474268] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1516.660834] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1517.035595] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1517.620691] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1517.716322] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1517.808898] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1517.996655] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1518.309186] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1518.925549] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1519.047711] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1519.137689] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1519.332318] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1519.567132] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1519.886792] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1520.072015] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1520.162238] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1520.309277] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1520.566906] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1521.027050] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1521.197986] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1521.285534] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1521.449658] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1521.683874] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1522.120782] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1522.222321] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1522.308697] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1522.449658] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1522.722290] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.182879] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1523.349408] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.441265] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.542901] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.653998] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.808606] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1523.964532] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.051355] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.238568] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.457379] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.746228] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1524.885754] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.973095] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1525.136694] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1525.395458] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1525.809765] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1525.829907] m0: running mesh housekeeping
<7>[ 1525.910473] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1525.996636] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1526.105718] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1526.317089] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1526.573998] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8

2) Today it doesn't reproduce. Plink establishment passes, altough, warning remains:

<6>[    8.237792] cx3110x spi2.0: firmware: requesting 3826.arm
<6>[    8.343169] phy0: p54 detected a LM20 firmware
<6>[    8.348693] p54: rx_mtu reduced from 3240 to 2376
<6>[    8.354369] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
<6>[    8.360319] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
<6>[    8.366423] cx3110x spi2.0: firmware: requesting 3826.eeprom
<6>[    8.474607] cx3110x spi2.0: loading default eeprom...
<6>[    8.480833] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
<7>[    8.538937] phy0: Selected rate control algorithm 'minstrel'
<6>[    8.588103] cx3110x spi2.0: device is bound to phy0
<4>[    8.946653] Empty flash at 0x01ef1588 ends at 0x01ef1800
<4>[    9.091216] Empty flash at 0x02eb9474 ends at 0x02eb9800
<7>[   13.979885] usb0: eth_open
<7>[   13.979916] usb0: eth_start
<7>[   13.980068] g_ether gadget: ecm_open
<7>[   14.827604] g_ether gadget: notify connect true
<7>[   14.859617] g_ether gadget: notify speed 425984000
<7>[  122.496226] m0: running mesh housekeeping
<7>[  124.771694] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<4>[  124.774440] ------------[ cut here ]------------
<4>[  124.782008] WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
<4>[  124.789729] Modules linked in: p54spi
<4>[  124.797389] [<c0034ff8>] (dump_stack+0x0/0x14) from [<c005b1f0>] (warn_on_slowpath+0x4c/0x68)
<4>[  124.805721] [<c005b1a4>] (warn_on_slowpath+0x0/0x68) from [<c006051c>] (local_bh_enable+0x54/0xbc)
<4>[  124.822139]  r6:c79bbe00 r5:c7ed6e20 r4:c04594a0
<4>[  124.830562] [<c00604c8>] (local_bh_enable+0x0/0xbc) from [<bf000038>] (p54spi_op_tx+0x38/0x4c [p54spi])
<4>[  124.847926]  r4:c79bbe00
<4>[  124.856319] [<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi]) from [<c01a4dbc>] (p54_sta_unlock+0x64/0x78)
<4>[  124.874233]  r5:c79bb1a0 r4:c7ed6e20
<4>[  124.883083] [<c01a4d58>] (p54_sta_unlock+0x0/0x78) from [<c01a4df8>] (p54_sta_notify+0x28/0x2c)
<4>[  124.892574]  r7:c79a5380 r6:c79bb1a0 r5:60000013 r4:c7fec800
<4>[  124.902187] [<c01a4dd0>] (p54_sta_notify+0x0/0x2c) from [<c02e0a40>] (sta_info_insert+0x128/0x19c)
<4>[  124.921748] [<c02e0918>] (sta_info_insert+0x0/0x19c) from [<c02fdb44>] (mesh_neighbour_update+0x58/0xbc)
<4>[  124.942867]  r8:c79a5380 r7:00000000 r6:00000fff r5:c79bb1a0 r4:c7fec800
<4>[  124.953822] [<c02fdaec>] (mesh_neighbour_update+0x0/0xbc) from [<c02fc398>] (ieee80211_mesh_work+0x188/0x2c4)
<4>[  124.976039] [<c02fc210>] (ieee80211_mesh_work+0x0/0x2c4) from [<c006b2bc>] (run_workqueue+0xa8/0x124)
<4>[  124.998500] [<c006b214>] (run_workqueue+0x0/0x124) from [<c006be20>] (worker_thread+0xec/0x100)
<4>[  125.010341]  r6:c7aca920 r5:c79e8000 r4:c7aca928
<4>[  125.021968] [<c006bd34>] (worker_thread+0x0/0x100) from [<c006ee28>] (kthread+0x5c/0x94)
<4>[  125.033992]  r6:c006bd34 r5:c7aca920 r4:c79e8000
<4>[  125.045711] [<c006edcc>] (kthread+0x0/0x94) from [<c005dd48>] (do_exit+0x0/0x6cc)
<4>[  125.057613]  r6:00000000 r5:00000000 r4:00000000
<4>[  125.069148] ---[ end trace 6577f51800004055 ]---
<7>[  125.080592] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[  125.081085] Mesh plink: starting establishment with 00:1d:6e:9b:ee:6d
<7>[  125.103576] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 1 55435 0 1
<7>[  125.110412] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 55435 3385 4
<7>[  125.110473] Mesh plink with 00:1d:6e:9b:ee:6d ESTABLISHED
<7>[  183.146203] m0: running mesh housekeeping
<7>[  243.146171] m0: running mesh housekeeping
<7>[  265.520801] phy0: Removed STA 00:1d:6e:9b:ee:6d
<7>[  265.536378] phy0: Destroyed STA 00:1d:6e:9b:ee:6d

3) Beaconing works, but not the way it should: like MPs don't hear each other. Timestamps never get in sync
and both MPs issue beacon during 0.1s beacon interval.
I've seen it before, with stlc45xx. It shows when LMAC is set up with LMAC_SETUP_IBSS | LMAC_SETUP_TRANSPARENT flags.
If there's no LMAC_SETUP_TRANSPARENT flag in LMAC setup then timestamps get in sync.

(Traced with tshark -T fields -e frame.time -e wlan.sa -e wlan.seq -e wlan.fc.type_subtype -e wlan_mgt.fixed.timestamp)

08:27:47.423880000	00:1d:6e:9b:ee:6c	0	0x08	0x0000000000000580
08:27:47.433851000	00:1d:6e:9b:ee:6c	1	0x08	0x00000000000004ED
08:27:47.437849000	00:1d:6e:9b:ee:6c	2	0x08	0x0000000000000266
08:27:47.443847000	00:1d:6e:9b:ee:6c	3	0x08	0x0000000000000220
08:27:47.546857000	00:1d:6e:9b:ee:6c	4	0x08	0x0000000000019370
08:27:47.649819000	00:1d:6e:9b:ee:6c	5	0x08	0x00000000000326A4
08:27:47.751787000	00:1d:6e:9b:ee:6c	6	0x08	0x000000000004B690
08:27:47.853764000	00:1d:6e:9b:ee:6c	7	0x08	0x0000000000064474
08:27:47.955744000	00:1d:6e:9b:ee:6c	8	0x08	0x000000000007D1F4
08:27:48.058762000	00:1d:6e:9b:ee:6c	9	0x08	0x00000000000965B4
08:27:48.160737000	00:1d:6e:9b:ee:6c	10	0x08	0x00000000000AF398
08:27:48.263704000	00:1d:6e:9b:ee:6c	11	0x08	0x00000000000C830C
08:27:48.366677000	00:1d:6e:9b:ee:6c	12	0x08	0x00000000000E1537
08:27:48.467636000	00:1d:6e:9b:ee:6c	13	0x08	0x00000000000FA26C
08:27:48.571610000	00:1d:6e:9b:ee:6c	14	0x08	0x0000000000113528
08:27:48.673588000	00:1d:6e:9b:ee:6c	15	0x08	0x000000000012C690
08:27:48.775578000	00:1d:6e:9b:ee:6c	16	0x08	0x0000000000145528
08:27:48.877544000	00:1d:6e:9b:ee:6c	17	0x08	0x000000000015E35C
08:27:48.980549000	00:1d:6e:9b:ee:6c	18	0x08	0x0000000000177348
08:27:49.083530000	00:1d:6e:9b:ee:6c	19	0x08	0x0000000000190474
08:27:49.186511000	00:1d:6e:9b:ee:6c	20	0x08	0x00000000001A9690
08:27:49.287465000	00:1d:6e:9b:ee:6c	21	0x08	0x00000000001C2384
08:27:49.390436000	00:1d:6e:9b:ee:6c	22	0x08	0x00000000001DB671
08:27:49.492412000	00:1d:6e:9b:ee:6c	23	0x08	0x00000000001F44C4
08:27:49.595410000	00:1d:6e:9b:ee:6c	24	0x08	0x000000000020D3E9
08:27:49.696370000	00:1d:6e:9b:ee:6d	0	0x08	0x0000000000000569
08:27:49.698362000	00:1d:6e:9b:ee:6c	25	0x08	0x0000000000226656
08:27:49.712360000	00:1d:6e:9b:ee:6d	1	0x08	0x000000000000023D
08:27:49.713360000	00:1d:6e:9b:ee:6d	2	0x08	0x0000000000000438
08:27:49.719359000	00:1d:6e:9b:ee:6d	3	0x08	0x0000000000000296
08:27:49.720358000	00:1d:6e:9b:ee:6d	4	0x08	0x0000000000000613
08:27:49.799379000	00:1d:6e:9b:ee:6c	26	0x08	0x000000000023F2D2
08:27:49.823342000	00:1d:6e:9b:ee:6d	5	0x08	0x00000000000196A5
08:27:49.902330000	00:1d:6e:9b:ee:6c	27	0x08	0x00000000002583EA
08:27:49.925317000	00:1d:6e:9b:ee:6d	6	0x08	0x00000000000326D7
08:27:50.004346000	00:1d:6e:9b:ee:6c	28	0x08	0x00000000002712FA
08:27:50.010336000	00:1d:6e:9b:ee:6c	0	0x0d	
08:27:50.011399000			0x1d	
08:27:50.027297000	00:1d:6e:9b:ee:6d	7	0x08	0x000000000004B26D
08:27:50.028290000	00:1d:6e:9b:ee:6d	0	0x0d	
08:27:50.029305000			0x1d	
08:27:50.030287000	00:1d:6e:9b:ee:6c	1	0x0d	
08:27:50.031295000			0x1d	
08:27:50.032286000	00:1d:6e:9b:ee:6d	1	0x0d	
08:27:50.033295000			0x1d	
08:27:50.108304000	00:1d:6e:9b:ee:6c	29	0x08	0x000000000028A6CD
08:27:50.129274000	00:1d:6e:9b:ee:6d	8	0x08	0x0000000000064399
08:27:50.210268000	00:1d:6e:9b:ee:6c	30	0x08	0x00000000002A357A
08:27:50.232249000	00:1d:6e:9b:ee:6d	9	0x08	0x000000000007D30D
08:27:50.312234000	00:1d:6e:9b:ee:6c	31	0x08	0x00000000002BC642
08:27:50.334228000	00:1d:6e:9b:ee:6d	10	0x08	0x00000000000964ED
08:27:50.414218000	00:1d:6e:9b:ee:6c	32	0x08	0x00000000002D52E6
08:27:50.436206000	00:1d:6e:9b:ee:6d	11	0x08	0x00000000000AF26D
08:27:50.517218000	00:1d:6e:9b:ee:6c	33	0x08	0x00000000002EE6B9
08:27:50.539201000	00:1d:6e:9b:ee:6d	12	0x08	0x00000000000C8529
08:27:50.619169000	00:1d:6e:9b:ee:6c	34	0x08	0x00000000003073EA
08:27:50.642167000	00:1d:6e:9b:ee:6d	13	0x08	0x00000000000E1691

4) Pings don't go, because MPs don't answer ARP requests sent to it. Haven't tested for the root cause yet.
But again, I have seen this with stlc45xx with two different causes:
- when LMAC was set up without LMAC_SETUP_TRANSPARENT flag, ARP requests didn't pass LMAC packet filter
  and weren't reported to the driver;
- when LMAC was set up with LMAC_SETUP_TRANSPARENT flag firmware seem to truncate last 2 bytes of the packet
  that it reports.

> Is there anything else I can do, or something you want to know?
Are there other p54 species that use 3826.arm firmware?

Are there other sources of information regarding LMAC interaction except
http://wireless.kernel.org/en/developers/Documentation/specs?action=AttachFile&do=get&target=STSW45x0C_LMAC_API_ED1P4.pdf ?

Who should be contacted with questions about firmware behavior?

-- 
Thanks.
-- Max

Re: p54spi - mesh mode summary

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Thu, 2009-03-26 at 09:22 +0300, Max Filippov wrote:

> 3) Beaconing works, but not the way it should: like MPs don't hear each other. Timestamps never get in sync
> and both MPs issue beacon during 0.1s beacon interval.

That's perfectly fine for mesh. You're thinking of IBSS.

> 4) Pings don't go, because MPs don't answer ARP requests sent to it. Haven't tested for the root cause yet.

Maybe some multicast issue?

> Are there other sources of information regarding LMAC interaction except
> http://wireless.kernel.org/en/developers/Documentation/specs?action=AttachFile&do=get&target=STSW45x0C_LMAC_API_ED1P4.pdf ?

No; well, the header file.

> Who should be contacted with questions about firmware behavior?

I don't think we have any contact.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: p54spi - mesh mode summary

[Max Filippov]

> > 4) Pings don't go, because MPs don't answer ARP requests sent to it.
> > Haven't tested for the root cause yet.
>
> Maybe some multicast issue?

ARP requests get filtered out by LMAC.
Can anyone explain why? My 802.11s comprehension is quite weak.
Here's the packet:

IEEE 802.11 Data, Flags: ......FT
    Type/Subtype: Data (0x20)
    Frame Control: 0x0308 (Normal)
        Version: 0
        Type: Data frame (2)
        Subtype: 0
        Flags: 0x3
            DS status: WDS (AP to AP) or Mesh (MP to MP) Frame (To DS: 1 From DS: 1) (0x03)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    Duration: 0
    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
    Transmitter address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
    Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
    Fragment number: 0
    Sequence number: 2
    Source address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
    Mesh Header
        Address Extension 0
        Mesh TTL: 5
        Mesh Seq: 0
Logical-Link Control
    DSAP: SNAP (0xaa)
    IG Bit: Individual
    SSAP: SNAP (0xaa)
    CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x03)
    Organization Code: Encapsulated Ethernet (0x000000)
    Type: ARP (0x0806)
Address Resolution Protocol (request)
    Hardware type: Ethernet (0x0001)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (0x0001)
    Sender MAC address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
    Sender IP address: 192.168.4.13 (192.168.4.13)
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 192.168.4.14 (192.168.4.14)


I'm tempted to do something like this in p54_setup_mac:

-               case NL80211_IFTYPE_MESH_POINT:
                        mode = P54_FILTER_TYPE_IBSS;
                        break;
+               case NL80211_IFTYPE_MESH_POINT:
+                       mode = P54_FILTER_TYPE_IBSS | P54_FILTER_TYPE_TRANSPARENT;
+                       break;

But I guess that's bad solution, at least for pci/usb drivers.
Christian, Johannes, what would you suggest?

-- 
Thanks.
-- Max

Re: p54spi - mesh mode summary

[Christian Lamparter]

On Friday 27 March 2009 06:03:54 Max Filippov wrote:
> > > 4) Pings don't go, because MPs don't answer ARP requests sent to it.
> > > Haven't tested for the root cause yet.
> >
> > Maybe some multicast issue?
> 
> ARP requests get filtered out by LMAC.
> Can anyone explain why? My 802.11s comprehension is quite weak.
> Here's the packet:
> 
> IEEE 802.11 Data, Flags: ......FT
>     Type/Subtype: Data (0x20)
>     Frame Control: 0x0308 (Normal)
>         Version: 0
>         Type: Data frame (2)
>         Subtype: 0
>         Flags: 0x3
>             DS status: WDS (AP to AP) or Mesh (MP to MP) Frame (To DS: 1 From DS: 1) (0x03)
>             .... .0.. = More Fragments: This is the last fragment
>             .... 0... = Retry: Frame is not being retransmitted
>             ...0 .... = PWR MGT: STA will stay up
>             ..0. .... = More Data: No data buffered
>             .0.. .... = Protected flag: Data is not protected
>             0... .... = Order flag: Not strictly ordered
>     Duration: 0
>     Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
>     Transmitter address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
>     Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
>     Fragment number: 0
>     Sequence number: 2
>     Source address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
>     Mesh Header
>         Address Extension 0
>         Mesh TTL: 5
>         Mesh Seq: 0
> Logical-Link Control
>     DSAP: SNAP (0xaa)
>     IG Bit: Individual
>     SSAP: SNAP (0xaa)
>     CR Bit: Command
>     Control field: U, func=UI (0x03)
>         000. 00.. = Command: Unnumbered Information (0x00)
>         .... ..11 = Frame type: Unnumbered frame (0x03)
>     Organization Code: Encapsulated Ethernet (0x000000)
>     Type: ARP (0x0806)
> Address Resolution Protocol (request)
>     Hardware type: Ethernet (0x0001)
>     Protocol type: IP (0x0800)
>     Hardware size: 6
>     Protocol size: 4
>     Opcode: request (0x0001)
>     Sender MAC address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
>     Sender IP address: 192.168.4.13 (192.168.4.13)
>     Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
>     Target IP address: 192.168.4.14 (192.168.4.14)
> 
> 
> I'm tempted to do something like this in p54_setup_mac:
> 
> -               case NL80211_IFTYPE_MESH_POINT:
>                         mode = P54_FILTER_TYPE_IBSS;
>                         break;
> +               case NL80211_IFTYPE_MESH_POINT:
> +                       mode = P54_FILTER_TYPE_IBSS | P54_FILTER_TYPE_TRANSPARENT;
> +                       break;
> 
> But I guess that's bad solution, at least for pci/usb drivers.
> Christian, Johannes, what would you suggest?
That's odd.

P54_FILTER_TYPE_TRANSPARENT should be already set for mesh mode.

The reason is that mesh mode will automatically set the FIF_OTHER_BSS flag,
(file:net/mac80211/iface.c func:ieee80211_open lines:251 f) 

which in turn ORs the P54_FILTER_TYPE_TRANSPARENT flag to the mode...
(file:drivers/net/wireless/p54/p54common.c func: p54_setup_mac lines: 1691 f)

So, there's no need to OR a flag that gets ORed anyway?

Regards,
	Chr

Re: p54spi - mesh mode summary

[Max Filippov]

> That's odd.
>
> P54_FILTER_TYPE_TRANSPARENT should be already set for mesh mode.
>
> The reason is that mesh mode will automatically set the FIF_OTHER_BSS=
 flag,
> (file:net/mac80211/iface.c func:ieee80211_open lines:251 f)
>
> which in turn ORs the P54_FILTER_TYPE_TRANSPARENT flag to the mode...
> (file:drivers/net/wireless/p54/p54common.c func: p54_setup_mac lines:=
 1691
> f)
>
> So, there's no need to OR a flag that gets ORed anyway?

=46ound the problem, that's my fault at merge of omap and wireless-test=
ing=20
trees:
p54_configure_filter that I tested with has the following code:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *total_flags &=3D FIF_PROMISC_IN_BSS |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 FIF_OTHER_BSS |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 (*total_flags & FIF_PROMISC_IN_BSS) ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FIF_FCSFAIL : 0;

which does not what it is intended to. '|' operator has higher preceden=
ce=20
than '? :'
thus it is equivalent to *total_flags &=3D FIF_FCSFAIL; which never yie=
lds=20
neither
=46IF_PROMISC_IN_BSS nor FIF_OTHER_BSS.

Current wireless-testing head has=20

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *total_flags &=3D FIF_PROMISC_IN_BSS |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 FIF_OTHER_BSS;

at this place, which work fine.

--=20
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: p54spi - mesh mode summary

[Christian Lamparter]

On Saturday 28 March 2009 04:21:02 Max Filippov wrote:
> > That's odd.
> >
> > P54_FILTER_TYPE_TRANSPARENT should be already set for mesh mode.
> >
> > The reason is that mesh mode will automatically set the FIF_OTHER_B=
SS flag,
> > (file:net/mac80211/iface.c func:ieee80211_open lines:251 f)
> >
> > which in turn ORs the P54_FILTER_TYPE_TRANSPARENT flag to the mode.=
=2E.
> > (file:drivers/net/wireless/p54/p54common.c func: p54_setup_mac line=
s: 1691
> > f)
> >
> > So, there's no need to OR a flag that gets ORed anyway?
>=20
> Found the problem, that's my fault at merge of omap and wireless-test=
ing=20
> trees:
> p54_configure_filter that I tested with has the following code:
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *total_flags &=3D FIF_PROMISC_IN_BSS |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 FIF_OTHER_BSS |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 (*total_flags & FIF_PROMISC_IN_BSS) ?
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FIF_FCSFAIL : 0;
>=20
> which does not what it is intended to. '|' operator has higher preced=
ence=20
> than '? :'
> thus it is equivalent to *total_flags &=3D FIF_FCSFAIL; which never y=
ields=20
> neither
> FIF_PROMISC_IN_BSS nor FIF_OTHER_BSS.
>=20
> Current wireless-testing head has=20
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *total_flags &=3D FIF_PROMISC_IN_BSS |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 FIF_OTHER_BSS;
>=20
> at this place, which work fine.
Yup that was fixed by "p54: misplaced parentheses"
( c1359ddff01dc63b2770f876a94b6dd97e0473f6 )
and FCS_FAIL was removed by "p54: completely ignore rx'd frames with ba=
d FCS"
( adda7e08403adf0980efb69ffe339567df8eb8d1 )=20

your last patches had some offset, do you have more code fixes or
does everything work (properly)?

Regards,
	Chr
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: p54spi - mesh mode summary

[Max Filippov]

> 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

Re: p54spi - mesh mode summary

[Christian Lamparter]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On Sunday 29 March 2009 06:41:59 Max Filippov wrote:
> > 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)
> <4>[  213.740464] [<c00604c8>] (local_bh_enable+0x0/0xbc)
> <4>[  213.766221] [<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi])
> <4>[  213.793016] [<c01a4d34>] (p54_sta_unlock+0x0/0x78) 
hmm, sta_unlock is called from a tasklet, so we must use the irqsave functions
does this warning go away with the attached patch?

Regards,
	Chr

[-- Attachment #2: p54spi-irqsave-locks.diff --]
[-- Type: text/x-diff, Size: 2488 bytes --]

diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 155f453..5202312 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -469,9 +469,10 @@ static int p54spi_wq_tx(struct p54s_priv *priv)
 	struct ieee80211_tx_info *info;
 	struct p54_tx_info *minfo;
 	struct p54s_tx_info *dinfo;
+	unsigned long flags;
 	int ret = 0;
 
-	spin_lock_bh(&priv->tx_lock);
+	spin_lock_irqsave(&priv->tx_lock, flags);
 
 	while (!list_empty(&priv->tx_pending)) {
 		entry = list_entry(priv->tx_pending.next,
@@ -479,7 +480,7 @@ static int p54spi_wq_tx(struct p54s_priv *priv)
 
 		list_del_init(&entry->tx_list);
 
-		spin_unlock_bh(&priv->tx_lock);
+		spin_unlock_irqrestore(&priv->tx_lock, flags);
 
 		dinfo = container_of((void *) entry, struct p54s_tx_info,
 				     tx_list);
@@ -491,16 +492,14 @@ static int p54spi_wq_tx(struct p54s_priv *priv)
 
 		ret = p54spi_tx_frame(priv, skb);
 
-		spin_lock_bh(&priv->tx_lock);
-
 		if (ret < 0) {
 			p54_free_skb(priv->hw, skb);
-			goto out;
+			return ret;
 		}
-	}
 
-out:
-	spin_unlock_bh(&priv->tx_lock);
+		spin_lock_irqsave(&priv->tx_lock, flags);
+	}
+	spin_unlock_irqrestore(&priv->tx_lock, flags);
 	return ret;
 }
 
@@ -510,12 +509,13 @@ static void p54spi_op_tx(struct ieee80211_hw *dev, struct sk_buff *skb)
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct p54_tx_info *mi = (struct p54_tx_info *) info->rate_driver_data;
 	struct p54s_tx_info *di = (struct p54s_tx_info *) mi->data;
+	unsigned long flags;
 
 	BUILD_BUG_ON(sizeof(*di) > sizeof((mi->data)));
 
-	spin_lock_bh(&priv->tx_lock);
+	spin_lock_irqsave(&priv->tx_lock, flags);
 	list_add_tail(&di->tx_list, &priv->tx_pending);
-	spin_unlock_bh(&priv->tx_lock);
+	spin_unlock_irqrestore(&priv->tx_lock, flags);
 
 	queue_work(priv->hw->workqueue, &priv->work);
 }
@@ -616,6 +616,7 @@ out:
 static void p54spi_op_stop(struct ieee80211_hw *dev)
 {
 	struct p54s_priv *priv = dev->priv;
+	unsigned long flags;
 
 	if (mutex_lock_interruptible(&priv->mutex)) {
 		/* FIXME: how to handle this error? */
@@ -627,9 +628,9 @@ static void p54spi_op_stop(struct ieee80211_hw *dev)
 	cancel_work_sync(&priv->work);
 
 	p54spi_power_off(priv);
-	spin_lock_bh(&priv->tx_lock);
+	spin_lock_irqsave(&priv->tx_lock, flags);
 	INIT_LIST_HEAD(&priv->tx_pending);
-	spin_unlock_bh(&priv->tx_lock);
+	spin_unlock_irqrestore(&priv->tx_lock, flags);
 
 	priv->fw_state = FW_STATE_OFF;
 	mutex_unlock(&priv->mutex);

Re: p54spi - mesh mode summary

[Max Filippov]

> hmm, sta_unlock is called from a tasklet, so we must use the irqsave
> functions does this warning go away with the attached patch?
Yes, it does.

-- 
Thanks.
-- Max