Re: [LEDE-DEV] Release planning
> On 2016-12-21 20:13, Jo-Philipp Wich wrote: > - Are there any outstanding changes? >Is there important changes we should wait for before branching the >release? Is there pending stuff in the staging trees which should >absolutely go into the first release? > Imho an important issue that has to be addressed before release is the OOM issues opkg has in devices with 32MiB of RAM. LEDE supports a around 380 devices with that ram. (according to the ToH [1]) Around half of these devices (around 180) seem to have 8 MiB or even more Flash, so it's reasonable to expect that opkg works for them. Many people upgrading from OWRT will start getting hard OOM failures when using opkg on devices where it worked fine in OWRT CC. In the bug thread [2] I proposed a possible solution that should be easy to implement for someone that knows opkg source already (I also have a 32 MiB device ready to test any patch): In low ram devices have opkg download package lists every time it needs to read them, don't keep them in tmpfs. Like "download -pipe- extract -pipe- read" without passing from tmpfs. This will murder its performance as it will need to wait for the download of all lists each time you use it, but should keep it usable. This trick shouldn't trigger the OOM as the current workaround is to comment out some of the feeds (telephony and luci for example) from the opkg feed list so they aren't downloaded, and that works fine. This might even allow opkg to work in devices with 16 MiB of ram. 1. https://lede-project.org/toh/views/toh_extended_all?dataflt%5BRAM+MB*%7E%5D=32 2. https://bugs.lede-project.org/index.php?do=details&task_id=120&only_watched=1&type%5B0%5D=&sev%5B0%5D=&due%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&reported%5B0%5D= -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Users] [OpenWrt-Devel] Talks between OpenWrt and LEDE
2016-12-23 14:19 GMT+01:00 Tobias Welz : > > Hello, > > out of curiosity: why is LibreOffice a failure of name change. > > Other projects did that as well - The team (all - beside the owner AFAIK) of > OpenElec made a new fork LibreElec. Companies do this also rename products > from time to time, maybe you remember old times a famous snack in germany > became renamed "Raider heißt jetzt Twix". (Raider is now called Twix). Or > another example from industry: "Daewoo" spent a lot of money to establish the > brand "Daewoo" in Germany. Anyway GM wiped out the brand name and just > replaced it with "Chevrolet". > > > I also like the well known name "OpenWrt" - I used it for a long time since > "white russian" - anyway i don't mind new freshness like with LEDE. As long > as people get the name change as some kind of "evolution" it's not > necessarily a bad thing to take,e.g., LEDE. > > People will also still call the project "OpenWrt" even it has another name - > others will still know that is meant - it's the same thing. > > The only bad thing is having two projects in parallel (OpenElec / LibreElec) > and people don't realize that there is something "new". > Another example of successful name change is OpenERP/ODOO http://www.enterpriseappstoday.com/erp/what-is-odoo-open-source-erp.html P.S: as a trivia fact, have a look at this : ..."The name Odoo itself may be a puzzle to some, but it is based partly on whim and partly on an analysis of startups names. Apparently, the more Os you have in your name, the more successful you tend to be. Think Microsoft, Google, Yahoo!, to name a few." Sergio. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: prepare jffs2 partition properly in factory.bin for BHR-4GRV2
hi what's the current status? On Fri, Dec 9, 2016 at 5:53 PM, FUKAUMI Naoki wrote: > "pad-rootfs" is required just after "append-rootfs". > > Signed-off-by: FUKAUMI Naoki > --- > target/linux/ar71xx/image/generic.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/ar71xx/image/generic.mk > b/target/linux/ar71xx/image/generic.mk > index 6ceabeb..b1d9af9 100644 > --- a/target/linux/ar71xx/image/generic.mk > +++ b/target/linux/ar71xx/image/generic.mk > @@ -704,6 +704,6 @@ define Device/bhr-4grv2 >MTDPARTS := > spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14528k(rootfs),1472k(kernel),64k(art)ro,16000k@0x5(firmware) >IMAGES := sysupgrade.bin factory.bin >IMAGE/sysupgrade.bin = append-rootfs | pad-rootfs | pad-to > (ROOTFS_SIZE) | append-kernel | check-size (IMAGE_SIZE) > - IMAGE/factory.bin = append-kernel | pad-to (KERNEL_SIZE) | > append-rootfs | mkbuffaloimg > + IMAGE/factory.bin = append-kernel | pad-to (KERNEL_SIZE) | > append-rootfs | pad-rootfs | mkbuffaloimg > endef > TARGET_DEVICES += bhr-4grv2 > -- > 2.7.4 > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 3/3] bcm53xx: build factory images for WZR-900DHP series
hi thank you for your review! On Tue, Dec 20, 2016 at 5:10 PM, Mathias Kresin wrote: > Please split the whole block into single Build defines. This way we you can > reuse the build steps for the WSR-1166DHP/WSR-1166DHP2 for example instead > of adding the same chain of commands again. > > Personally I prefer to prepend the unencrypted tag to the image and encrypt > only the tag within the image in a next step instead of creating an external > tag file, encrypt it and prepend it to the image. > > Doing it this way, your factory image build code could be something like > this: > > IMAGE/factory-DHP-EU.bin := append-ubi | trx-nand | > buffalo-wzr-900dhp-header | buffalo-enc -param a -param b | buffalo-tag > -param a -param b | buffalo-enc-tag -size $tagsize | mkdhpimg > > If the buffalo-tag has a fixed size, it might be more elegant to move the > size param of buffalo-enc-tag to the Build define. > > It's obviously to me that you have way more knowledge about Buffalo factory > images than I. Therefore I have not set the patches to "changes requested" > in patchwork yet. Might be possible that I've missed something and the > outlined way would not work or there isn't any benefit of doing it this way. > > Would be great if you could give me a feedback on this. > > Mathias I got (probably) better idea :) I'll prepare v2 patch. Regards, ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH netifd] system-linux: Don't set gre tunnel ttl by default to 64 (#FS312)
As the ttl of a gre tunnel was set by default to 64 the gre tunnel
failed to get active if don't fragment was disabled as setting
nopmtudisc and ttl is incompatible.
Fix this by setting the default ttl value after don't fragment
and ttl config values have been parsed.
Signed-off-by: Hans Dedecker
---
system-linux.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/system-linux.c b/system-linux.c
index 67fa2b1..52a1c17 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -2127,7 +2127,7 @@ static int system_add_gre_tunnel(const char *name, const
char *kind,
uint32_t ikey = 0, okey = 0, flags = 0, flowinfo = 0;
uint16_t iflags = 0, oflags = 0;
uint8_t tos = 0;
- int ret = 0, ttl = 64;
+ int ret = 0, ttl = 0;
nlm = nlmsg_alloc_simple(RTM_NEWLINK, NLM_F_REQUEST | NLM_F_REPLACE |
NLM_F_CREATE);
if (!nlm)
@@ -2155,8 +2155,6 @@ static int system_add_gre_tunnel(const char *name, const
char *kind,
if ((cur = tb[TUNNEL_ATTR_TTL]))
ttl = blobmsg_get_u32(cur);
- nla_put_u8(nlm, IFLA_GRE_TTL, ttl);
-
if ((cur = tb[TUNNEL_ATTR_TOS])) {
char *str = blobmsg_get_string(cur);
if (strcmp(str, "inherit")) {
@@ -2230,6 +2228,9 @@ static int system_add_gre_tunnel(const char *name, const
char *kind,
if (flags)
nla_put_u32(nlm, IFLA_GRE_FLAGS, flags);
+
+ if (!ttl)
+ ttl = 64;
} else {
struct in_addr inbuf;
bool set_df = true;
@@ -2265,17 +2266,23 @@ static int system_add_gre_tunnel(const char *name,
const char *kind,
if ((cur = tb[TUNNEL_ATTR_DF]))
set_df = blobmsg_get_bool(cur);
- /* ttl !=0 and nopmtudisc are incompatible */
- if (ttl && !set_df) {
- ret = -EINVAL;
- goto failure;
- }
+ if (!set_df) {
+ /* ttl != 0 and nopmtudisc are incompatible */
+ if (ttl) {
+ ret = -EINVAL;
+ goto failure;
+ }
+ } else if (!ttl)
+ ttl = 64;
nla_put_u8(nlm, IFLA_GRE_PMTUDISC, set_df ? 1 : 0);
nla_put_u8(nlm, IFLA_GRE_TOS, tos);
}
+ if (ttl)
+ nla_put_u8(nlm, IFLA_GRE_TTL, ttl);
+
if (oflags)
nla_put_u16(nlm, IFLA_GRE_OFLAGS, oflags);
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH netifd v2] proto: allow configuring deprecated static IPv6 addresses
Add a new boolean attribute ip6deprecated to the static protocol which can
be used to mark IPv6 addresses as deprecated (i.e., set the preferred
lifetime to 0). This is useful to configure addresses that may be used for
incoming, but not for outgoing connections unless bound explicitly.
Signed-off-by: Matthias Schiffer
---
v2: change ip6preferred to ip6deprecated with reversed logic
proto.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/proto.c b/proto.c
index 23304f3..fd48354 100644
--- a/proto.c
+++ b/proto.c
@@ -36,6 +36,7 @@ enum {
OPT_GATEWAY,
OPT_IP6GW,
OPT_IP6PREFIX,
+ OPT_IP6DEPRECATED,
__OPT_MAX,
};
@@ -47,6 +48,7 @@ static const struct blobmsg_policy
proto_ip_attributes[__OPT_MAX] = {
[OPT_GATEWAY] = { .name = "gateway", .type = BLOBMSG_TYPE_STRING },
[OPT_IP6GW] = { .name = "ip6gw", .type = BLOBMSG_TYPE_STRING },
[OPT_IP6PREFIX] = { .name = "ip6prefix", .type = BLOBMSG_TYPE_ARRAY },
+ [OPT_IP6DEPRECATED] = { .name = "ip6deprecated", .type =
BLOBMSG_TYPE_BOOL },
};
static const struct uci_blob_param_info proto_ip_attr_info[__OPT_MAX] = {
@@ -113,7 +115,7 @@ alloc_device_addr(bool v6, bool ext)
static bool
parse_addr(struct interface *iface, const char *str, bool v6, int mask,
- bool ext, uint32_t broadcast)
+ bool ext, uint32_t broadcast, bool deprecated)
{
struct device_addr *addr;
int af = v6 ? AF_INET6 : AF_INET;
@@ -136,6 +138,9 @@ parse_addr(struct interface *iface, const char *str, bool
v6, int mask,
if (broadcast)
addr->broadcast = broadcast;
+ if (deprecated)
+ addr->preferred_until = system_get_rtime();
+
vlist_add(&iface->proto_ip.addr, &addr->node, &addr->flags);
return true;
@@ -148,7 +153,8 @@ error:
static int
parse_static_address_option(struct interface *iface, struct blob_attr *attr,
- bool v6, int netmask, bool ext, uint32_t broadcast)
+ bool v6, int netmask, bool ext, uint32_t broadcast,
+ bool deprecated)
{
struct blob_attr *cur;
int n_addr = 0;
@@ -160,7 +166,7 @@ parse_static_address_option(struct interface *iface, struct
blob_attr *attr,
n_addr++;
if (!parse_addr(iface, blobmsg_data(cur), v6, netmask, ext,
- broadcast))
+ broadcast, deprecated))
return -1;
}
@@ -400,6 +406,7 @@ proto_apply_static_ip_settings(struct interface *iface,
struct blob_attr *attr)
struct blob_attr *cur;
const char *error;
unsigned int netmask = 32;
+ bool ip6deprecated;
int n_v4 = 0, n_v6 = 0;
struct in_addr bcast = {};
@@ -420,13 +427,15 @@ proto_apply_static_ip_settings(struct interface *iface,
struct blob_attr *attr)
}
}
+ ip6deprecated = blobmsg_get_bool_default(tb[OPT_IP6DEPRECATED], false);
+
if ((cur = tb[OPT_IPADDR]))
n_v4 = parse_static_address_option(iface, cur, false,
- netmask, false, bcast.s_addr);
+ netmask, false, bcast.s_addr, false);
if ((cur = tb[OPT_IP6ADDR]))
n_v6 = parse_static_address_option(iface, cur, true,
- 128, false, 0);
+ 128, false, 0, ip6deprecated);
if ((cur = tb[OPT_IP6PREFIX]))
if (parse_prefix_list(iface, cur) < 0)
--
2.11.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] subversive idea for cert alerts
I think a cool subversive thing people could do would be to have a set of stickers we could apply to routers in a retailer that had a LARGE WARNING label pointing to the relevant cert alert - and including steerage to a public firmware like lede that fixed the problem for that model. http://forums.theregister.co.uk/forum/1/2016/12/23/netgear_router_vuln/ -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] subversive idea for cert alerts
On 12/24/2016 12:21 AM, Dave Taht wrote: > I think a cool subversive thing people could do would be to have a set > of stickers we could apply to routers in a retailer that had a LARGE > WARNING label pointing to the relevant cert alert - and including > steerage to a public firmware like lede that fixed the problem for > that model. > > http://forums.theregister.co.uk/forum/1/2016/12/23/netgear_router_vuln/ > Do you really want to link open source firmwares (LEDE or whatever) with these kinds of lame teenage vandalism? (because attacking stickers to stuff on sale is vandalism, in case you don't know) The things that people do in the name of "activism" these days... Imho that's a plain bad idea, not "cool" nor "subversive" in any way. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] subversive idea for cert alerts
On Fri, Dec 23, 2016 at 3:59 PM, Alberto Bursi wrote: > On 12/24/2016 12:21 AM, Dave Taht wrote: >> I think a cool subversive thing people could do would be to have a set >> of stickers we could apply to routers in a retailer that had a LARGE >> WARNING label pointing to the relevant cert alert - and including >> steerage to a public firmware like lede that fixed the problem for >> that model. >> >> http://forums.theregister.co.uk/forum/1/2016/12/23/netgear_router_vuln/ >> > > Do you really want to link open source firmwares (LEDE or whatever) with > these kinds of lame teenage vandalism? I would argue merely attaching the cert alert would not be vandalism but a public service. But you are right, promoting an alternative firmware would probably go too far. > (because attacking stickers to stuff on sale is vandalism, in case you > don't know) Didn't. As such things go, it's trivial. https://en.wikipedia.org/wiki/Vandalism > > The things that people do in the name of "activism" these days... > Imho that's a plain bad idea, not "cool" nor "subversive" in any way. > > -Alberto > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release planning
Hi, Le 12/21/16 à 11:13, Jo-Philipp Wich a écrit : > # Open questions > > - Are there any outstanding changes? > > Is there important changes we should wait for before branching the > release? Is there pending stuff in the staging trees which should > absolutely go into the first release? I have a number of fixes for rb532 that would probably be worth making it to the release; including a kernel update to 4.4. Thanks! -- Florian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/4] rb532: Fixes and update to 4.4
Hi all, This patch series contains rb532 fixes and updates to the 4.4 kernel Thanks Florian Fainelli (4): rb532: Fix initramfs kernel images rb532: Add support for kernel 4.4 rb532: Backport fix to resolve oops during korina_restart rb532: Switch to kernel 4.4 target/linux/rb532/Makefile| 2 +- target/linux/rb532/config-4.4 | 147 + target/linux/rb532/image/Makefile | 2 +- .../linux/rb532/patches-4.4/001-cmdline_hack.patch | 20 +++ .../rb532/patches-4.4/002-rb532_nand_fixup.patch | 47 +++ ...tion_info-rename-rootfs-to-rootfs_onboard.patch | 11 ++ .../patches-4.4/100-korina_fix_napi_disable.patch | 56 7 files changed, 283 insertions(+), 2 deletions(-) create mode 100644 target/linux/rb532/config-4.4 create mode 100644 target/linux/rb532/patches-4.4/001-cmdline_hack.patch create mode 100644 target/linux/rb532/patches-4.4/002-rb532_nand_fixup.patch create mode 100644 target/linux/rb532/patches-4.4/004-rb532_partition_info-rename-rootfs-to-rootfs_onboard.patch create mode 100644 target/linux/rb532/patches-4.4/100-korina_fix_napi_disable.patch -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 4/4] rb532: Switch to kernel 4.4
Signed-off-by: Florian Fainelli --- 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 9033eb4637d4..5b37f6072e23 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:=4.1 +KERNEL_PATCHVER:=4.4 include $(INCLUDE_DIR)/target.mk DEFAULT_PACKAGES += wpad-mini kmod-ath5k kmod-input-rb532 -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/4] rb532: Add support for kernel 4.4
Signed-off-by: Florian Fainelli --- target/linux/rb532/config-4.4 | 147 + .../linux/rb532/patches-4.4/001-cmdline_hack.patch | 20 +++ .../rb532/patches-4.4/002-rb532_nand_fixup.patch | 47 +++ ...tion_info-rename-rootfs-to-rootfs_onboard.patch | 11 ++ 4 files changed, 225 insertions(+) create mode 100644 target/linux/rb532/config-4.4 create mode 100644 target/linux/rb532/patches-4.4/001-cmdline_hack.patch create mode 100644 target/linux/rb532/patches-4.4/002-rb532_nand_fixup.patch create mode 100644 target/linux/rb532/patches-4.4/004-rb532_partition_info-rename-rootfs-to-rootfs_onboard.patch diff --git a/target/linux/rb532/config-4.4 b/target/linux/rb532/config-4.4 new file mode 100644 index ..b425184f69e0 --- /dev/null +++ b/target/linux/rb532/config-4.4 @@ -0,0 +1,147 @@ +CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y +CONFIG_ARCH_DISCARD_MEMBLOCK=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_REQUIRE_GPIOLIB=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ATA=y +CONFIG_BLK_DEV_SD=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_CEVT_R4K=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_CPU_GENERIC_DUMP_TLB=y +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPS32_R1=y +CONFIG_CPU_MIPSR1=y +CONFIG_CPU_R4K_CACHE_TLB=y +CONFIG_CPU_R4K_FPU=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRC16=y +CONFIG_CRYPTO_CRC32C=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CSRC_R4K=y +CONFIG_DMA_NONCOHERENT=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +CONFIG_EXT4_FS=y +CONFIG_FS_MBCACHE=y +CONFIG_GENERIC_ATOMIC64=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_IO=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_DEVRES=y +CONFIG_GPIO_SYSFS=y +CONFIG_HARDWARE_WATCHPOINTS=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT=y +# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set +CONFIG_HAVE_ARCH_JUMP_LABEL=y +CONFIG_HAVE_ARCH_KGDB=y +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set +CONFIG_HAVE_C_RECORDMCOUNT=y +CONFIG_HAVE_DEBUG_KMEMLEAK=y +CONFIG_HAVE_DMA_API_DEBUG=y +CONFIG_HAVE_DMA_ATTRS=y +CONFIG_HAVE_DYNAMIC_FTRACE=y +CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y +CONFIG_HAVE_FUNCTION_TRACER=y +CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_HAVE_GENERIC_HARDIRQS=y +CONFIG_HAVE_IDE=y +CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MEMBLOCK_NODE_MAP=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y +CONFIG_HAVE_NET_DSA=y +CONFIG_HAVE_OPROFILE=y +CONFIG_HAVE_PERF_EVENTS=y +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_HW_HAS_PCI=y +CONFIG_HW_RANDOM=y +CONFIG_HZ=250 +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +CONFIG_HZ_PERIODIC=y +CONFIG_IMAGE_CMDLINE_HACK=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_IRQ_CPU=y +CONFIG_IRQ_FORCED_THREADING=y +CONFIG_IRQ_WORK=y +CONFIG_JBD2=y +CONFIG_KEXEC=y +CONFIG_KORINA=y +CONFIG_LEDS_MIKROTIK_RB532=y +CONFIG_MIKROTIK_RB532=y +CONFIG_MIPS=y +# CONFIG_MIPS_HUGE_TLB_SUPPORT is not set +CONFIG_MIPS_L1_CACHE_SHIFT=4 +# CONFIG_MIPS_MACHINE is not set +CONFIG_MIPS_MT_DISABLED=y +CONFIG_MODULES_USE_ELF_REL=y +CONFIG_MTD_BLOCK2MTD=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +# CONFIG_MTD_CFI_AMDSTD is not set +CONFIG_MTD_CFI_GEOMETRY=y +# CONFIG_MTD_CFI_INTELEXT is not set +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_NAND_PLATFORM=y +CONFIG_MTD_PHYSMAP=y +# CONFIG_MTD_ROOTFS_ROOT_DEV is not set +CONFIG_MTD_ROOTFS_SPLIT=y +# CONFIG_MTD_SM_COMMON is not set +# CONFIG_MTD_SPLIT is not set +CONFIG_NEED_DMA_MAP_STATE=y +CONFIG_NEED_PER_CPU_KM=y +CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y +# CONFIG_OF is not set +CONFIG_PAGEFLAGS_EXTENDED=y +CONFIG_PATA_RB532=y +CONFIG_PCI=y +CONFIG_PCI_DISABLE_COMMON_QUIRKS=y +CONFIG_PCI_DOMAINS=y +CONFIG_PERF_USE_VMALLOC=y +# CONFIG_PREEMPT_RCU is not set +CONFIG_RC32434_WDT=y +# CONFIG_RCU_STALL_COMMON is not set +CONFIG_SCSI=y +# CONFIG_SCSI_LOWLEVEL is not set +# CONFIG_SCSI_MULTI_LUN is not set +# CONFIG_SCSI_PROC_FS is not set +# CONFIG_SWAP is not set +CONFIG_SWAP_IO_SPACE=y +CONFIG_SYS_HAS_CPU_MIPS32_R1=y +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y +CONFIG_TICK_CPU_ACCOUNTING=y +CONFIG_UIDGID_CONVERTED=y +CONFIG_USB_ARCH_HAS_XHCI=y +CONFIG_VIA_RHINE=y +CONFIG_VIA_RHINE_MMIO=y +CONFIG_YAFFS_9BYTE_TAGS=y +# CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED is not set +CONFIG_YAFFS_AUTO_YAFFS2=y +# CONFIG_YAFFS_DISABLE_BACKGROUND is not set +# CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is not set +# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set +# CONFIG_YAFFS_EMPTY_LOST_AND_FOUND is not set +CONFIG_YAFFS_FS=y +CONFIG_YAFFS_XATTR=y +CONFIG_YAFFS_YAFFS1=y +CONFIG_YAFFS_YAFFS2=
[LEDE-DEV] [PATCH 3/4] rb532: Backport fix to resolve oops during korina_restart
Signed-off-by: Florian Fainelli
---
.../patches-4.4/100-korina_fix_napi_disable.patch | 56 ++
1 file changed, 56 insertions(+)
create mode 100644
target/linux/rb532/patches-4.4/100-korina_fix_napi_disable.patch
diff --git a/target/linux/rb532/patches-4.4/100-korina_fix_napi_disable.patch
b/target/linux/rb532/patches-4.4/100-korina_fix_napi_disable.patch
new file mode 100644
index ..3f80e0937d02
--- /dev/null
+++ b/target/linux/rb532/patches-4.4/100-korina_fix_napi_disable.patch
@@ -0,0 +1,56 @@
+From 5833532b49820aa221248f296c207cc50d20ca2d Mon Sep 17 00:00:00 2001
+From: Florian Fainelli
+Date: Fri, 23 Dec 2016 19:36:31 -0800
+Subject: [PATCH net] net: korina: Fix NAPI versus resources freeing
+
+Commit beb0babfb77e ("korina: disable napi on close and restart")
+introduced calls to napi_disable() that were missing before,
+unfortunately this leaves a small window during which NAPI has a chance
+to run, yet we just freed resources since korina_free_ring() has been
+called:
+
+Fix this by disabling NAPI first then freeing resource, and make sure
+that we also cancel the restart taks before doing the resource freeing.
+
+Fixes: beb0babfb77e ("korina: disable napi on close and restart")
+Reported-by: Alexandros C. Couloumbis
+Signed-off-by: Florian Fainelli
+---
+ drivers/net/ethernet/korina.c | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
+index cbeea915f026..8037426ec50f 100644
+--- a/drivers/net/ethernet/korina.c
b/drivers/net/ethernet/korina.c
+@@ -900,10 +900,10 @@ static void korina_restart_task(struct work_struct *work)
+ DMA_STAT_DONE | DMA_STAT_HALT | DMA_STAT_ERR,
+ &lp->rx_dma_regs->dmasm);
+
+- korina_free_ring(dev);
+-
+ napi_disable(&lp->napi);
+
++ korina_free_ring(dev);
++
+ if (korina_init(dev) < 0) {
+ printk(KERN_ERR "%s: cannot restart device\n", dev->name);
+ return;
+@@ -1064,12 +1064,12 @@ static int korina_close(struct net_device *dev)
+ tmp = tmp | DMA_STAT_DONE | DMA_STAT_HALT | DMA_STAT_ERR;
+ writel(tmp, &lp->rx_dma_regs->dmasm);
+
+- korina_free_ring(dev);
+-
+ napi_disable(&lp->napi);
+
+ cancel_work_sync(&lp->restart_task);
+
++ korina_free_ring(dev);
++
+ free_irq(lp->rx_irq, dev);
+ free_irq(lp->tx_irq, dev);
+ free_irq(lp->ovr_irq, dev);
+--
+2.9.3
+
--
2.9.3
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/4] rb532: Fix initramfs kernel images
The generic lzma-loader uses vmlinux.lzma as an input to compress so we need to provide a lzma compressed version of the initramfs kernel. Signed-off-by: Florian Fainelli --- 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 1a1f3437796e..7ea6532e06f5 100644 --- a/target/linux/rb532/image/Makefile +++ b/target/linux/rb532/image/Makefile @@ -28,7 +28,7 @@ define Image/Prepare $(MAKE) -C $(GENERIC_PLATFORM_DIR)/image/lzma-loader $(LOADER_MAKEOPTS) clean compile ifeq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y) $(STAGING_DIR_HOST)/bin/patch-cmdline $(KDIR)/vmlinux-initramfs '$(strip $(call Image/cmdline/yaffs2)) ' - cat $(KDIR)/vmlinux-initramfs | $(STAGING_DIR_HOST)/bin/lzma e -si -so -eos -lc1 -lp2 -pb2 > $(KDIR)/vmlinux-initramfs.lzma + cat $(KDIR)/vmlinux-initramfs | $(STAGING_DIR_HOST)/bin/lzma e -si -so -eos -lc1 -lp2 -pb2 > $(KDIR)/vmlinux.lzma $(MAKE) -C $(GENERIC_PLATFORM_DIR)/image/lzma-loader $(LOADER_MAKEOPTS) clean compile $(CP) $(KDIR)/loader.elf $(KDIR)/loader-initramfs.elf endif -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
