Re: [OpenWrt-Devel] [PATCH 2/3] swconfig: support receiving SWITCH_TYPE_LINK from kernel

[Rafał Miłecki]

On 20 December 2015 at 22:56, Florian Fainelli  wrote:
> Le 16 déc. 2015 09:21, "Rafał Miłecki"  a écrit :
>>
>> When using cli, print link state the same way kernel used to do it.
>> This will allow kernel switching PORT_LINK from SWITCH_TYPE_STRING.
>>
>> Signed-off-by: Rafał Miłecki 
>> ---
> [snip]
>> +   link->eee &
>> SWLIB_LINK_FLAG_ADVERTISED_100BASET_FULL ? "eee100 " : "",
>> +   link->eee &
>> SWLIB_LINK_FLAG_ADVERTISED_1000BASET_FULL ? "eee1000 " : "",
>
> EEE needs to be advertised, supported, and enabled on both link partners to
> be used,what you are printing here is not very clear, as this is just the
> advertised side

This behavior is copied from the current implementation. This is what
kernel was putting in a string so far and sending to the user space.
Do we want to change it? Should I handle it in this patch or separated
one? I hope there aren't send screen scraping tools using "get link".

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] swconfig: add SWITCH_TYPE_LINK and support sending link info to user space

[Rafał Miłecki]

On 20 December 2015 at 19:23, Stefan Rompf  wrote:
> On Mittwoch, 16. Dezember 2015 18:19:01 Rafał Miłecki wrote:
>
>> So far we were sending link data as a string. It got some drawbacks:
>> 1) Didn't allow writing clean user space apps reading link state. It was
>>needed to do some screen scraping.
>> 2) Forced whole PORT_LINK communication to be string based. Adding
>>support for *setting* port link required passing string and parting
>>it in the kernel space.
>
> indeed, this interface looks a lot better than passing a string. It will make
> setting the link parameters easier.
>
> Minor nitpick: I'm not sure about the naming of these attributes:
>
>> + SWITCH_LINK_FLAG_ADVERTISED_100BASET_FULL,
>> + SWITCH_LINK_FLAG_ADVERTISED_1000BASET_FULL,
>
> As far as I understand the code, they specify whether EEE should be
> adverstised / is enabled for a specific speed. Therefore maybe they should be
> called f.e.
>
> SWITCH_LINK_EEE_100BASET and
> SWITCH_LINK_EEE_1000BASET

In the current code swconfig_get_link does following:
link.eee & ADVERTISED_100baseT_Full ? "eee100 " : "",
link.eee & ADVERTISED_1000baseT_Full ? "eee1000 " : "",
this is what made me call flags like that. I'll rename them.

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Memory leak in mac80211?

[xinglp]

2015-12-21 12:03 GMT+08:00 xinglp :
> 2015-12-21 0:20 GMT+08:00 Felix Fietkau :
>> On 2015-12-20 17:00, Arjen de Korte wrote:
>>> Citeren Felix Fietkau :
>>>
 On 2015-12-20 11:52, Arjen de Korte wrote:
> Since commit 47771 it seems my WNDR4300 router suffers from a memory
> leak. Before then, the amount of free memory was always around 75%,
> but since then it steadily decreases until it runs out of memory and
> reboots. The process then starts all over again. After a couple of
> days of 'git bisect'ing, I found this to be the commit that introduced
> this phenomenon. See attached kmemleak.txt file for more information.
> I don't know how to go on from here to aid in debugging what is going
> on. Is there something else I can provide to help finding how to solve
> this?
 Please copy http://nbd.name/990-remove_full_ap_client_state.patch to
 package/kernel/mac80211/patches and try again.
>>>
>>> Still no joy, see attached kmemleak output. In about four hours time,
>>> free memory decreased by about 10% (of 128 MB). Is there anything else
>>> I can do to aid in finding the cause? This is with r47953 by the way,
>>> with the above mentioned patch included (I checked in the build_dir,
>>> the patch applied successfully.
>> Please show me your /etc/config/wireless. I will continue to go through
>> the differences between those two compat-wireless trees and make some
>> patches for you to test.
> r47954 with patch http://nbd.name/990-remove_full_ap_client_state.patch.
> For 9 hours, run as sta mode,  no obvious memory leak.
> config wifi-device 'radio0'
> option type 'mac80211'
> option hwmode '11g'
> option path 'platform/ar933x_wmac'
> option country 'JP'
> option channel '1'
> option htmode 'HT40'
>
> config wifi-iface 'sta'
> option device 'radio0'
> option mode 'sta'
> option network 'wwan'
> option ssid 'xx'
> option key 'xx'
> option encryption 'psk2'
> option wpa_group_rekey '8000'
> The 'ap mode' is in testing.
The 'ap mode' has memory leak.
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/ar933x_wmac'
option country 'JP'
option channel '1'
option htmode 'HT40'

config wifi-iface 'ap'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'xx'
option key 'xxx'
option encryption 'psk2'
option wpa_group_rekey '8000'
option macfilter 'allow'

>>
>> - Felix
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Memory leak in mac80211?

[xinglp]

2015-12-21 0:20 GMT+08:00 Felix Fietkau :
> On 2015-12-20 17:00, Arjen de Korte wrote:
>> Citeren Felix Fietkau :
>>
>>> On 2015-12-20 11:52, Arjen de Korte wrote:
 Since commit 47771 it seems my WNDR4300 router suffers from a memory
 leak. Before then, the amount of free memory was always around 75%,
 but since then it steadily decreases until it runs out of memory and
 reboots. The process then starts all over again. After a couple of
 days of 'git bisect'ing, I found this to be the commit that introduced
 this phenomenon. See attached kmemleak.txt file for more information.
 I don't know how to go on from here to aid in debugging what is going
 on. Is there something else I can provide to help finding how to solve
 this?
>>> Please copy http://nbd.name/990-remove_full_ap_client_state.patch to
>>> package/kernel/mac80211/patches and try again.
>>
>> Still no joy, see attached kmemleak output. In about four hours time,
>> free memory decreased by about 10% (of 128 MB). Is there anything else
>> I can do to aid in finding the cause? This is with r47953 by the way,
>> with the above mentioned patch included (I checked in the build_dir,
>> the patch applied successfully.
> Please show me your /etc/config/wireless. I will continue to go through
> the differences between those two compat-wireless trees and make some
> patches for you to test.
r47954 with patch http://nbd.name/990-remove_full_ap_client_state.patch.
For 9 hours, run as sta mode,  no obvious memory leak.
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/ar933x_wmac'
option country 'JP'
option channel '1'
option htmode 'HT40'

config wifi-iface 'sta'
option device 'radio0'
option mode 'sta'
option network 'wwan'
option ssid 'xx'
option key 'xx'
option encryption 'psk2'
option wpa_group_rekey '8000'
The 'ap mode' is in testing.
>
> - Felix
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/3] swconfig: support receiving SWITCH_TYPE_LINK from kernel

[Florian Fainelli]

Le 16 déc. 2015 09:21, "Rafał Miłecki"  a écrit :
>
> When using cli, print link state the same way kernel used to do it.
> This will allow kernel switching PORT_LINK from SWITCH_TYPE_STRING.
>
> Signed-off-by: Rafał Miłecki 
> ---
[snip]
> +   link->eee &
SWLIB_LINK_FLAG_ADVERTISED_100BASET_FULL ? "eee100 " : "",
> +   link->eee &
SWLIB_LINK_FLAG_ADVERTISED_1000BASET_FULL ? "eee1000 " : "",

EEE needs to be advertised, supported, and enabled on both link partners to
be used,what you are printing here is not very clear, as this is just the
advertised side

> +   link->aneg ? "auto" : "");
> +   else
> +   printf("port:%d link:down", val->port_vlan);
> +   break;
> default:
> printf("?unknown-type?");
> }
> diff --git a/package/network/config/swconfig/src/swlib.c
b/package/network/config/swconfig/src/swlib.c
> index 0dbace5..5239bf7 100644
> --- a/package/network/config/swconfig/src/swlib.c
> +++ b/package/network/config/swconfig/src/swlib.c
> @@ -51,6 +51,15 @@ static struct nla_policy
portmap_policy[SWITCH_PORTMAP_MAX] = {
> [SWITCH_PORTMAP_VIRT] = { .type = NLA_U32 },
>  };
>
> +static struct nla_policy link_policy[SWITCH_LINK_ATTR_MAX] = {
> +   [SWITCH_LINK_LINK] = { .type = NLA_U32 },
> +   [SWITCH_LINK_DUPLEX] = { .type = NLA_U32 },
> +   [SWITCH_LINK_ANEG] = { .type = NLA_U32 },
> +   [SWITCH_LINK_SPEED] = { .type = NLA_U32 },

As mentioned in patch 1, some of this fits in a boolean.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] swconfig: add SWITCH_TYPE_LINK and support sending link info to user space

[Florian Fainelli]

Le 16 déc. 2015 09:19, "Rafał Miłecki"  a écrit :
>
> So far we were sending link data as a string. It got some drawbacks:
> 1) Didn't allow writing clean user space apps reading link state. It was
>needed to do some screen scraping.
> 2) Forced whole PORT_LINK communication to be string based. Adding
>support for *setting* port link required passing string and parting
>it in the kernel space.
>
> Signed-off-by: Rafał Miłecki 
> ---

[snip]

(struct sk_buff *msg, struct genl_info *info, int attr,
> +  const struct switch_port_link *link)
> +{
> +   struct nlattr *p = NULL;
> +   int err = 0;
> +
> +   p = nla_nest_start(msg, attr);
> +   if (nla_put_u32(msg, SWITCH_LINK_LINK, link->link))

Boolean?

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_DUPLEX, link->duplex))

Same here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_ANEG, link->aneg))

And here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_TX_FLOW, link->tx_flow))

And here

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_RX_FLOW, link->rx_flow))

And here too

> +   goto nla_put_failure;
> +   if (nla_put_u32(msg, SWITCH_LINK_SPEED, link->speed))
> +   goto nla_put_failure;
> +   if (link->eee & ADVERTISED_100baseT_Full) {
> +   if (nla_put_flag(msg,
SWITCH_LINK_FLAG_ADVERTISED_100BASET_FULL))
> +   goto nla_put_failure;
> +   }
> +   if (link->eee & ADVERTISED_1000baseT_Full) {
> +   if (nla_put_flag(msg,
SWITCH_LINK_FLAG_ADVERTISED_1000BASET_FULL))
> +   goto nla_put_failure;
> +   }

As mentioned by Stefan, these should reflect that is is EEE-related.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] kernel: add at803x fix for sgmii mode

[Christian Lamparter]

Hello,

On Sunday, December 20, 2015 08:20:12 PM Roman Yeryomin wrote:
> On 20 December 2015 at 15:13, Christian Lamparter
>  wrote:
> > On Sunday, December 20, 2015 02:30:39 AM Roman Yeryomin wrote:
> >> Some (possibly broken) bootloaders incorreclty initialize at8033
> >> phy. This patch enables sgmii autonegotiation mode.
> >>
> >> Signed-off-by: Roman Yeryomin 
> >> ---
> > Can you tell us a bit about the "possibly broken" bootloaders you talk
> > about? Like what devices (based "possibly" on QCA956x) have those and
> > from where you are getting this information?
> 
> The device is uapac.
Unifi AP AC? So, GPL - Sources are hard to come by... Sad.

> But I'm taking about phy setup itself...
> 
> > I'm asking because we (Chris and I) encountered similar issues with the
> > Cisco Merakin MR18. It has a AR8035-A (confirmed by opening up the device)
> > but calls it a AR8033. The PHY apparently connected via RGMII
> > (uses QCA955X_ETH_CFG_RGMII_EN [0]) but the device needs to write some
> > calibration values to SGMII and SERDES registers in order to work [1].
> > We are quite keen to know what's going on since this seems 
> > counter-intuitive.
> 
> ..and you are talking about SoC's gmac setup, which is completely
> different thing.
>
> Also, FYI, AR8035 doesn't have sgmii, it has rgmii only.
Exactly, this is the issue here. The AR803x datasheet lists it as RGMII
only. But the Cisco's source tells me the opposite. I hoped to find a QCA
device which uses SGMII properly to check if they do the same "calibrations"
code or if the stuff is specific to the MR18. But because this device comes
from Ubiquiti, then this is probably not going to happen.

Regards,
Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/3] rb532: switch to 4.1

[Roman Yeryomin]

Signed-off-by: Roman Yeryomin 
---
 target/linux/rb532/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/rb532/Makefile b/target/linux/rb532/Makefile
index 3086462..9033eb4 100644
--- a/target/linux/rb532/Makefile
+++ b/target/linux/rb532/Makefile
@@ -11,7 +11,7 @@ BOARD:=rb532
 BOARDNAME:=Mikrotik RouterBoard 532
 FEATURES:=pci targz squashfs
 
-KERNEL_PATCHVER:=3.18
+KERNEL_PATCHVER:=4.1
 
 include $(INCLUDE_DIR)/target.mk
 DEFAULT_PACKAGES += wpad-mini kmod-ath5k kmod-input-rb532
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] rb532: build squashfs image by default

[Roman Yeryomin]

Signed-off-by: Roman Yeryomin 
---
 target/linux/rb532/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/rb532/Makefile b/target/linux/rb532/Makefile
index e5c6ad7..3086462 100644
--- a/target/linux/rb532/Makefile
+++ b/target/linux/rb532/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=mipsel
 BOARD:=rb532
 BOARDNAME:=Mikrotik RouterBoard 532
-FEATURES:=pci targz
+FEATURES:=pci targz squashfs
 
 KERNEL_PATCHVER:=3.18
 
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] rb532: increase kernel partition

[Roman Yeryomin]

4.1 got little bit larger than 4MB and I couldn't get lzma loader
working on this platform

Signed-off-by: Roman Yeryomin 
---
 target/linux/rb532/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/rb532/image/Makefile 
b/target/linux/rb532/image/Makefile
index 284b3d4..1a1f343 100644
--- a/target/linux/rb532/image/Makefile
+++ b/target/linux/rb532/image/Makefile
@@ -72,7 +72,7 @@ define Image/Build
$(CP) $(KDIR)/vmlinux.elf $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel
$(STAGING_DIR_HOST)/bin/patch-cmdline 
$(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel '$(strip $(call Image/cmdline/$(1))) '
./gen_image.sh $(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).bin \
-   4 $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel \
+   5 $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel \
$(CONFIG_TARGET_ROOTFS_PARTSIZE) $(KDIR)/root.$(1) \
128
 endef
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] swconfig: add SWITCH_TYPE_LINK and support sending link info to user space

[Stefan Rompf]

Hi Rafał,

On Mittwoch, 16. Dezember 2015 18:19:01 Rafał Miłecki wrote:

> So far we were sending link data as a string. It got some drawbacks:
> 1) Didn't allow writing clean user space apps reading link state. It was
>needed to do some screen scraping.
> 2) Forced whole PORT_LINK communication to be string based. Adding
>support for *setting* port link required passing string and parting
>it in the kernel space.

indeed, this interface looks a lot better than passing a string. It will make 
setting the link parameters easier.

Minor nitpick: I'm not sure about the naming of these attributes:

> + SWITCH_LINK_FLAG_ADVERTISED_100BASET_FULL,
> + SWITCH_LINK_FLAG_ADVERTISED_1000BASET_FULL,

As far as I understand the code, they specify whether EEE should be 
adverstised / is enabled for a specific speed. Therefore maybe they should be 
called f.e.

SWITCH_LINK_EEE_100BASET and
SWITCH_LINK_EEE_1000BASET

Stefan
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] kernel: add at803x fix for sgmii mode

[Roman Yeryomin]

On 20 December 2015 at 15:13, Christian Lamparter
 wrote:
> Hello,
>
> On Sunday, December 20, 2015 02:30:39 AM Roman Yeryomin wrote:
>> Some (possibly broken) bootloaders incorreclty initialize at8033
>> phy. This patch enables sgmii autonegotiation mode.
>>
>> Signed-off-by: Roman Yeryomin 
>> ---
> Can you tell us a bit about the "possibly broken" bootloaders you talk
> about? Like what devices (based "possibly" on QCA956x) have those and
> from where you are getting this information?

The device is uapac.
But I'm taking about phy setup itself...

> I'm asking because we (Chris and I) encountered similar issues with the
> Cisco Merakin MR18. It has a AR8035-A (confirmed by opening up the device)
> but calls it a AR8033. The PHY apparently connected via RGMII
> (uses QCA955X_ETH_CFG_RGMII_EN [0]) but the device needs to write some
> calibration values to SGMII and SERDES registers in order to work [1].
> We are quite keen to know what's going on since this seems counter-intuitive.

..and you are talking about SoC's gmac setup, which is completely
different thing.
Also, FYI, AR8035 doesn't have sgmii, it has rgmii only.

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Memory leak in mac80211?

[Felix Fietkau]

On 2015-12-20 17:00, Arjen de Korte wrote:
> Citeren Felix Fietkau :
> 
>> On 2015-12-20 11:52, Arjen de Korte wrote:
>>> Since commit 47771 it seems my WNDR4300 router suffers from a memory
>>> leak. Before then, the amount of free memory was always around 75%,
>>> but since then it steadily decreases until it runs out of memory and
>>> reboots. The process then starts all over again. After a couple of
>>> days of 'git bisect'ing, I found this to be the commit that introduced
>>> this phenomenon. See attached kmemleak.txt file for more information.
>>> I don't know how to go on from here to aid in debugging what is going
>>> on. Is there something else I can provide to help finding how to solve
>>> this?
>> Please copy http://nbd.name/990-remove_full_ap_client_state.patch to
>> package/kernel/mac80211/patches and try again.
> 
> Still no joy, see attached kmemleak output. In about four hours time,  
> free memory decreased by about 10% (of 128 MB). Is there anything else  
> I can do to aid in finding the cause? This is with r47953 by the way,  
> with the above mentioned patch included (I checked in the build_dir,  
> the patch applied successfully.
Please show me your /etc/config/wireless. I will continue to go through
the differences between those two compat-wireless trees and make some
patches for you to test.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Memory leak in mac80211?

[Arjen de Korte]

Citeren Felix Fietkau :


On 2015-12-20 11:52, Arjen de Korte wrote:

Since commit 47771 it seems my WNDR4300 router suffers from a memory
leak. Before then, the amount of free memory was always around 75%,
but since then it steadily decreases until it runs out of memory and
reboots. The process then starts all over again. After a couple of
days of 'git bisect'ing, I found this to be the commit that introduced
this phenomenon. See attached kmemleak.txt file for more information.
I don't know how to go on from here to aid in debugging what is going
on. Is there something else I can provide to help finding how to solve
this?

Please copy http://nbd.name/990-remove_full_ap_client_state.patch to
package/kernel/mac80211/patches and try again.


Still no joy, see attached kmemleak output. In about four hours time,  
free memory decreased by about 10% (of 128 MB). Is there anything else  
I can do to aid in finding the cause? This is with r47953 by the way,  
with the above mentioned patch included (I checked in the build_dir,  
the patch applied successfully.


Best regards,
Arjen


kmemleak.txt.gz
Description: GNU Zip compressed data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Issue with kernel 4.1/4.4 on Linksys-routers

[Kristian Evensen]

Hello,

I tried to compile and test trunk on two Linksys-routers (1200AC and
1900ACv2). After manually enabling the Generic Thermal sysfs driver,
compilation went fine. However, none of the routers want to boot.
Hooking up a serial shows what seems to be a filsystem issue, the
following error is repeated over and over:

[   10.985327] SQUASHFS error: xz decompression failed, data probably corrupt
[   10.985329] SQUASHFS error: squashfs_read_data failed to read block 0x1f0a53

In addition, I get the following message at different intervals (dump
is of course much longer, all ff):

[9.870883] pxa3xx-nand f10d.flash: Wait time out!!!
[   10.070883] pxa3xx-nand f10d.flash: Wait time out!!!
[   10.076226] ubi0: dumping 2048 bytes of data from PEB 125, offset 6144
[   10.082786] : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

[   10.096408] 0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

[   10.110029] 0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

[   10.123650] 0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

[   10.137270] 0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff


There is also an oops attached to all of this:

[8.531175] Unable to handle kernel paging request at virtual
address ffec
[8.538425] pgd = c0004000
[8.541141] [ffec] *pgd=1fffd821, *pte=, *ppte=
[8.547464] Internal error: Oops: 17 [#2] SMP ARM
[8.552184] Modules linked in: mwlwifi(+) mac80211 cfg80211 compat
ledtrig_usbdev xt_set ip_set_list_set ip_set_hash_netiface
ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net h
[8.619946] CPU: 0 PID: 210 Comm: irq/39-f10d Tainted: G  D
4.1.13 #4
[8.627805] Hardware name: Marvell Armada 380/385 (Device Tree)
[8.633747] task: df5ba800 ti: df6cc000 task.ti: df6cc000
[8.639168] PC is at kthread_data+0x10/0x18
[8.643367] LR is at irq_thread_dtor+0x84/0xc4
[8.647827] pc : []lr : []psr: 2093
[8.647827] sp : df6cdd28  ip : df6cdd38  fp : df6cdd34
[8.659350] r10: df5ba800  r9 : df6cdd80  r8 : c03dc01c
[8.664595] r7 :   r6 : c04b34e0  r5 : df5ba800  r4 : df5ba800
[8.671147] r3 :   r2 : df6cdd38  r1 : df6cdf28  r0 : df5ba800
[8.677701] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment user
[8.684951] Control: 10c5387d  Table: 1e51404a  DAC: 0015
[8.690719] Process irq/39-f10d (pid: 210, stack limit = 0xdf6cc210)
[8.697446] Stack: (0xdf6cdd28 to 0xdf6ce000)
[8.701820] dd20:   df6cdd4c df6cdd38 c005cea4
c0040554 df5bab78 df5ba800
[8.710031] dd40: df6cdd6c df6cdd50 c003eb64 c005ce2c 
000b c049706c df5ba800
[8.718243] dd60: df6cdd9c df6cdd70 c0029328 c003eabc 000b
0001  df5ba800
[8.726454] dd80: df6cdd9c df6cdd90 c0028468 000b df6cdddc
df6cdda0 c001c630 c0028fa8
[8.734665] dda0: df6cc210 000b c01ff72c 6093 c04106f8
0004 e7f001f2 df6cdea0
[8.742877] ddc0: c0235c54  c000a62c df6cc000 df6cddec
df6cdde0 c001c6b0 c001c35c
[8.751088] dde0: df6cde9c df6cddf0 c00091ec c001c664 0006
c005ccac 0004 
[8.759299] de00: 00030001 c0235c54 df423448 dfbd6578 df6cde6c
df6cde20 c004d3fc c004a1ec
[8.767511] de20: 3a864830 000f df5ba8b8 20d8 000f
74c0 0014 
[8.775722] de40: df5baaa8 df551810 df6cdec0 0003 0001
df50bd00 df605940 c005ccac
[8.783934] de60: df6cde84 df6cde70 c01ff764 c01ff588 df6cde9c
df6cde8c df6cdeb4 c0235c58
[8.792145] de80: 6013  df6cded4 df50bd00 df6cdefc
df6cdea0 c000a62c c0009034
[8.800356] dea0: 003c 6013 c0499214 c0499214 df662810
0800  0001
[8.808568] dec0: df50bd00 df605940 c005ccac df6cdefc df6cdcc8
df6cdee8 c005a5a0 c0235c54
[8.816779] dee0: 6013  df605940 df50bd00 df6cdf1c
df6cdf00 c005ccd0 c0235b6c
[8.824991] df00: 0004 df605960 df6cc000  df6cdf5c
df6cdf20 c005cfb4 c005ccb8
[8.833202] df20:  df50bd58  c005ce20 
df605900  df605940
[8.841413] df40: c005cee4    df6cdfac
df6cdf60 c0040028 c005cef0
[8.849624] df60: fbff   df605940 
 df6cdf78 df6cdf78
[8.857836] df80: 0001 00010001 df6cdf88 df6cdf88 df605900
c003ff2c  
[8.866047] dfa0:  df6cdfb0 c0009d28 c003ff38 
  
[8.874258] dfc0:     
  
[8.882469] dfe0: 

Re: [OpenWrt-Devel] [PATCH 2/2] kernel: add at803x fix for sgmii mode

[Christian Lamparter]

Hello,

On Sunday, December 20, 2015 02:30:39 AM Roman Yeryomin wrote:
> Some (possibly broken) bootloaders incorreclty initialize at8033
> phy. This patch enables sgmii autonegotiation mode.
> 
> Signed-off-by: Roman Yeryomin 
> ---
Can you tell us a bit about the "possibly broken" bootloaders you talk
about? Like what devices (based "possibly" on QCA956x) have those and
from where you are getting this information?

I'm asking because we (Chris and I) encountered similar issues with the
Cisco Merakin MR18. It has a AR8035-A (confirmed by opening up the device)
but calls it a AR8033. The PHY apparently connected via RGMII 
(uses QCA955X_ETH_CFG_RGMII_EN [0]) but the device needs to write some
calibration values to SGMII and SERDES registers in order to work [1].
We are quite keen to know what's going on since this seems counter-intuitive.

Regards,
Christian

[0] 

[1] 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Memory leak in mac80211?

[Felix Fietkau]

On 2015-12-20 11:52, Arjen de Korte wrote:
> Since commit 47771 it seems my WNDR4300 router suffers from a memory  
> leak. Before then, the amount of free memory was always around 75%,  
> but since then it steadily decreases until it runs out of memory and  
> reboots. The process then starts all over again. After a couple of  
> days of 'git bisect'ing, I found this to be the commit that introduced  
> this phenomenon. See attached kmemleak.txt file for more information.  
> I don't know how to go on from here to aid in debugging what is going  
> on. Is there something else I can provide to help finding how to solve  
> this?
Please copy http://nbd.name/990-remove_full_ap_client_state.patch to
package/kernel/mac80211/patches and try again.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Memory leak in mac80211?

[Arjen de Korte]

Since commit 47771 it seems my WNDR4300 router suffers from a memory  
leak. Before then, the amount of free memory was always around 75%,  
but since then it steadily decreases until it runs out of memory and  
reboots. The process then starts all over again. After a couple of  
days of 'git bisect'ing, I found this to be the commit that introduced  
this phenomenon. See attached kmemleak.txt file for more information.  
I don't know how to go on from here to aid in debugging what is going  
on. Is there something else I can provide to help finding how to solve  
this?


Best regards,
Arjen

unreferenced object 0x86469200 (size 2048):
  comm "softirq", pid 0, jiffies 8710 (age 1140.290s)
  hex dump (first 32 bytes):
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
  backtrace:
[<800f4934>] create_object+0x134/0x274
[<800f1f38>] __kmalloc+0x1bc/0x1dc
[<80247324>] ag71xx_fill_rx_buf+0x68/0xf8
[<80247e54>] ag71xx_poll+0x280/0x3d8
[<802677e0>] net_rx_action+0x110/0x2c4
[<80083ca8>] __do_softirq+0x16c/0x298
[<80083ff0>] irq_exit+0x54/0x70
[<80060830>] ret_from_irq+0x0/0x4
unreferenced object 0x86985160 (size 176):
  comm "softirq", pid 0, jiffies 8873 (age 1138.660s)
  hex dump (first 32 bytes):
80 3c 1b 20 80 3c 1b 20 00 00 00 00 00 00 00 00  .<. .<. 
00 00 00 00 85 c0 21 00 40 00 40 00 00 01 00 00  ..!.@.@.
  backtrace:
[<800f4934>] create_object+0x134/0x274
[<800f205c>] kmem_cache_alloc+0x104/0x120
[<8025e304>] __build_skb+0x40/0xc0
[<8025e3a0>] build_skb+0x1c/0x9c
[<80247d1c>] ag71xx_poll+0x148/0x3d8
[<802677e0>] net_rx_action+0x110/0x2c4
[<80083ca8>] __do_softirq+0x16c/0x298
[<80083ff0>] irq_exit+0x54/0x70
[<80060830>] ret_from_irq+0x0/0x4
[<8006f104>] r4k_wait_irqoff+0x18/0x20
[<800a0320>] cpu_startup_entry+0x110/0x138
[<803e2bc8>] start_kernel+0x468/0x488
unreferenced object 0x86a1f6e0 (size 176):
  comm "softirq", pid 0, jiffies 18273 (age 1044.660s)
  hex dump (first 32 bytes):
85 74 b9 40 85 74 b9 40 00 00 00 00 00 00 00 00  .t.@.t.@
87 5b 7a 00 85 c0 21 00 40 00 40 00 00 02 00 00  .[z...!.@.@.
  backtrace:
[<800f4934>] create_object+0x134/0x274
[<800f205c>] kmem_cache_alloc+0x104/0x120
[<8025bda4>] __alloc_skb+0x60/0x184
[<802fe844>] ndisc_alloc_skb+0x5c/0x150
[<802ffc64>] ndisc_send_ns+0xd8/0x190
[<802ffe4c>] ndisc_solicit+0x130/0x16c
[<80271314>] neigh_probe+0x54/0x7c
[<80275a7c>] neigh_timer_handler+0x1a8/0x260
[<800aaa28>] call_timer_fn.isra.3+0x24/0x80
[<800aac2c>] run_timer_softirq+0x1a8/0x1e8
[<80083ca8>] __do_softirq+0x16c/0x298
[<80083ff0>] irq_exit+0x54/0x70
[<80060830>] ret_from_irq+0x0/0x4
unreferenced object 0x857a9500 (size 512):
  comm "softirq", pid 0, jiffies 18273 (age 1044.660s)
  hex dump (first 32 bytes):
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
  backtrace:
[<800f4934>] create_object+0x134/0x274
[<800f41d0>] __kmalloc_track_caller+0x1b8/0x1d8
[<8025bce0>] __kmalloc_reserve.isra.3+0x40/0xa4
[<8025bdcc>] __alloc_skb+0x88/0x184
[<802fe844>] ndisc_alloc_skb+0x5c/0x150
[<802ffc64>] ndisc_send_ns+0xd8/0x190
[<802ffe4c>] ndisc_solicit+0x130/0x16c
[<80271314>] neigh_probe+0x54/0x7c
[<80275a7c>] neigh_timer_handler+0x1a8/0x260
[<800aaa28>] call_timer_fn.isra.3+0x24/0x80
[<800aac2c>] run_timer_softirq+0x1a8/0x1e8
[<80083ca8>] __do_softirq+0x16c/0x298
[<80083ff0>] irq_exit+0x54/0x70
[<80060830>] ret_from_irq+0x0/0x4
unreferenced object 0x8730b840 (size 176):
  comm "softirq", pid 0, jiffies 62787 (age 599.520s)
  hex dump (first 32 bytes):
85 6a b7 48 85 6a b7 48 00 00 00 00 00 00 00 00  .j.H.j.H
87 5b 7a 00 85 c0 21 00 40 00 40 00 00 02 00 00  .[z...!.@.@.
  backtrace:
[<800f4934>] create_object+0x134/0x274
[<800f205c>] kmem_cache_alloc+0x104/0x120
[<8025bda4>] __alloc_skb+0x60/0x184
[<802fe844>] ndisc_alloc_skb+0x5c/0x150
[<802ffc64>] ndisc_send_ns+0xd8/0x190
[<802ffe4c>] ndisc_solicit+0x130/0x16c
[<80271314>] neigh_probe+0x54/0x7c
[<80275a7c>] neigh_timer_handler+0x1a8/0x260
[<800aaa28>] call_timer_fn.isra.3+0x24/0x80
[<800aac2c>] run_timer_softirq+0x1a8/0x1e8
[<80083ca8>] __do_softirq+0x16c/0x298
[<80083dfc>] run_ksoftirqd+0x28/0x48
[<80098ea0>] smpboot_thread_fn+0x148/0x178
[<80096f48>] kthread+0xdc/0xe8
[<80060878>] ret_from_kernel_thread+0x14/0x1c
unreferenced object 0x85685800 (size 512):
  comm "softirq", pid 0, jiffies 62787 (age 599.530s)
  hex dump (first 32 bytes):
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
  backtrace:
[<800f4934>] create_object+0x134/0x274
[<800f41d0>] __kmalloc

Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix

[Baptiste Jonglez]

Hi,

I'm bumping again, this patch is necessary to make the gigabit switch work
on the Mikrotik 951G-2HnD (tested on CC).

Thanks,
Baptiste

On Wed, Nov 25, 2015 at 06:18:29PM +0100, Baptiste Jonglez wrote:
> Hi,
> 
> Sorry to bump up the thread again.  Is there anything blocking to merge
> this patch?
> 
> If it helps, there are user reports about setting different values of
> ath79_eth0_pll_data.pll_1000 here:
> 
>   
> https://wiki.openwrt.org/toh/mikrotik/rb2011uias#tracking_reported_experience_with_suggested_patch_for_the_5_gige_ports
> 
> Thanks,
> Baptiste
> 
> On Sat, Nov 14, 2015 at 06:30:52PM +0100, Baptiste Jonglez wrote:
> > Hi,
> > 
> > On Wed, Dec 10, 2014 at 01:40:42PM -0700, Davey Hutchison wrote:
> > > Fix pll_1000 value for eth0. Traffic would not flow from the eth0 
> > > interface. The new PLL enables delay, use ath79_setup_ar934x_eth_cfg to 
> > > also enable AR934X_ETH_CFG_RXD_DELAY.
> > 
> > I can confirm that this patch works on CC on a Routerboard 951G-2HnD
> > [http://wiki.openwrt.org/toh/mikrotik/rb951g_2hnd]
> > 
> > Without the patch, CC installs fine, but the switch does not work (traffic
> > seems to be able to flow out of the router, but nothing comes in).
> > 
> > This is a router with the "new" chipset (AR9344 rev. 3).
> > 
> > Is it possible to pull this patch, at least to trunk?  Having it in CC
> > would also be nice if another CC release is planned.
> > 
> > Thanks,
> > Baptiste
> > 
> > > Signed-off-by: Davey Hutchison 
> > > 
> > > --- target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
> > > +++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
> > > @@ -199,6 +199,7 @@
> > >   return;
> > > 
> > >   ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 |
> > > +AR934X_ETH_CFG_RXD_DELAY |
> > >  AR934X_ETH_CFG_SW_ONLY_MODE);
> > > 
> > >   ath79_register_mdio(0, 0x0);
> > > @@ -209,6 +210,7 @@
> > >   ath79_init_mac(ath79_eth0_data.mac_addr, ath79_mac_base, 0);
> > >   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
> > >   ath79_eth0_data.phy_mask = BIT(0);
> > > + ath79_eth0_pll_data.pll_1000 = 0x3e00;
> > > 
> > >   ath79_register_eth(0);
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
> 
> 
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 



> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



pgpYESz6xCKfA.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] netifd: Request DHCP option 121 (classless route) by default

[Baptiste Jonglez]

Hi,

Any news on this patch?  As requested, the v2 patch introduces a
configuration knob to disable requesting option 121.

Thanks,
Baptiste

On Fri, Nov 20, 2015 at 11:50:56PM +0100, Baptiste Jonglez wrote:
> From: Baptiste Jonglez 
> 
> This option is useful when the gateway configured by DHCP cannot be in
> the same subnet as the client.  This happens, for instance, when using
> DHCP to hand out addresses in /32 subnets.
> 
> A new configuration option "classlessroute" is available, allowing
> users to disable this feature (the option defaults to true).
> 
> Signed-off-by: Baptiste Jonglez 
> ---
>  package/network/config/netifd/files/lib/netifd/proto/dhcp.sh | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh 
> b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
> index 0e88af9..aae0e44 100755
> --- a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
> +++ b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
> @@ -20,14 +20,15 @@ proto_dhcp_init_config() {
>   proto_config_add_string zone
>   proto_config_add_string mtu6rd
>   proto_config_add_string customroutes
> + proto_config_add_boolean classlessroute
>  }
>  
>  proto_dhcp_setup() {
>   local config="$1"
>   local iface="$2"
>  
> - local ipaddr hostname clientid vendorid broadcast reqopts iface6rd 
> sendopts delegate zone6rd zone mtu6rd customroutes
> - json_get_vars ipaddr hostname clientid vendorid broadcast reqopts 
> iface6rd sendopts delegate zone6rd zone mtu6rd customroutes
> + local ipaddr hostname clientid vendorid broadcast reqopts iface6rd 
> sendopts delegate zone6rd zone mtu6rd customroutes classlessroute
> + json_get_vars ipaddr hostname clientid vendorid broadcast reqopts 
> iface6rd sendopts delegate zone6rd zone mtu6rd customroutes classlessroute
>  
>   local opt dhcpopts
>   for opt in $reqopts; do
> @@ -47,6 +48,8 @@ proto_dhcp_setup() {
>   [ -n "$mtu6rd" ] && proto_export "MTU6RD=$mtu6rd"
>   [ -n "$customroutes" ] && proto_export "CUSTOMROUTES=$customroutes"
>   [ "$delegate" = "0" ] && proto_export "IFACE6RD_DELEGATE=0"
> + # Request classless route option (see RFC 3442) by default
> + [ "$classlessroute" = "0" ] || append dhcpopts "-O 121"
>  
>   proto_export "INTERFACE=$config"
>   proto_run_command "$config" udhcpc \


pgpsywZr5Z7W0.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ramips: mtk_soc_eth vs old ralink ethernet driver for the M2M

[Russell Senior]

> "John" == John Crispin  writes:

John> i'll try to test during the day. i had tested most socs but
John> apparently 5350 still has an issue.

Yes, I saw this too, and was about to report it.  I'm seeing it on an
AsiaRF AWM002, which is also an RT5350. 

swconfig list returns nothing, fwiw.


-- 
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Why default of XATTR in kernel but not userspace?

[Daniel Dickinson]

Hi all,

I've been working on a patch for making POSIX ACL support and userspace 
support of POSIX ACL and XATTR (extended attributes) a configuration 
option at compile time and noticed something rather wonky:


While for POSIX ACL the default is disabled both at the kernel
level and in userpace (i.e. filesystem modules by default do
not support POSIX ACL and programs don't use libacl).

OTOH for XATTR support the default is for kernel modules and built-ins
to support XATTR, but block mount does not support XATTR so I'm not sure 
any filesystems are actually mounted with xattr support enabled, and, in 
addition, no programs are compiled with xattr support (that is the 
default is not support xattr in userspace by default).


I'm a little puzzled as to why this is and what is acommplished by
having XATTR support by filesystem modules, when it doesn't appear 
anything uses that support (unless overlayfs uses with jffs2 and/or
tmpfs uses it via procd, but the support would fail for anything not 
mounted by procd).


What is exactly is logic/reason for this configuration and what is 
actually going on here?  Is xattr used at all?  If it is, why the mixed 
bag of support vs. lack of support depending on how a filesystem

is mounted?

My plan is to make a config option that, when enabled, makes POSIX ACL 
support in both kernel and userpace the default (with certain exceptions 
like JFFS2 and TMPFS), along with userpace xattr support.
In addition I add to the build options menu (if the above option is 
enabled), the ability to turn on and off POSIX ACL support for each 
filesystem.


(The option if enabled also manages (on by default) NFSv4 (and off by 
default) old NFS ACL support).


In addition I have a patch to fstools that lets block mount mount with 
posix acl and xattr support enabled.


(I make this an ifdef since it's pointless without the appropriate 
kernel support).



Regards,

Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel