Re: [LEDE-DEV] [RFC PATCH] tools/squashfs: change to upstream and update to new version 5.0-rc1

[Philip Prindeville]

Me too.


> On May 5, 2018, at 7:36 AM, Paul Spooren  wrote:
> 
> Are there any updates on this issue? I'd really like to see squasfs 5.0 used 
> in OpenWrt!
> 
> On Sat, May 27, 2017 at 8:51 PM, Hauke Mehrtens  wrote:
>> On 05/26/2017 06:13 PM, Alexander Couzens wrote:
>>> squashfs is quite long unmaintained. All patches from major
>>> distributions are integrated.
>>> Fixed timestamp is now using the environment SOURCE_DATE_EPOCH
>>> instead of arguments.
>>> Signed-off-by: Alexander Couzens 
>> Thanks for working on this.
>>> ---
>>>  include/image.mk   |   3 +-
>>>  tools/squashfs4/Makefile   |  12 +-
>>>  tools/squashfs4/patches/100-portability.patch  |  40 -
>>>  .../patches/110-allow_static_liblzma.patch |  30 -
>>>  tools/squashfs4/patches/120-cygwin_fixes.patch | 153 
>>>  tools/squashfs4/patches/150-freebsd_fixes.patch|  10 -
>>>  .../patches/160-expose_lzma_xz_options.patch   | 929 
>>> -
>>>  ...0-add_support_for_LZMA_MAGIC_to_unsqashfs.patch |  72 --
>>>  tools/squashfs4/patches/180-openbsd_compat.patch   |  24 -
>>>  .../patches/190-no_nonstatic_inline.patch  |  36 -
>>>  .../patches/200-add-fixed-timestamp-option.patch   |  82 --
>>>  11 files changed, 6 insertions(+), 1385 deletions(-)
>>>  delete mode 100644 tools/squashfs4/patches/100-portability.patch
>>>  delete mode 100644 tools/squashfs4/patches/110-allow_static_liblzma.patch
>>>  delete mode 100644 tools/squashfs4/patches/120-cygwin_fixes.patch
>>>  delete mode 100644 tools/squashfs4/patches/150-freebsd_fixes.patch
>>>  delete mode 100644 tools/squashfs4/patches/160-expose_lzma_xz_options.patch
>>>  delete mode 100644 
>>> tools/squashfs4/patches/170-add_support_for_LZMA_MAGIC_to_unsqashfs.patch
>>>  delete mode 100644 tools/squashfs4/patches/180-openbsd_compat.patch
>>>  delete mode 100644 tools/squashfs4/patches/190-no_nonstatic_inline.patch
>>>  delete mode 100644 
>>> tools/squashfs4/patches/200-add-fixed-timestamp-option.patch
>>> diff --git a/include/image.mk b/include/image.mk
>>> index ad9535d018..eaabba2d0e 100644
>>> --- a/include/image.mk
>>> +++ b/include/image.mk
>>> @@ -203,8 +203,7 @@ define Image/mkfs/squashfs
>>> $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \
>>> -nopad -noappend -root-owned \
>>> -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \
>>> -   -processors 1 \
>>> -   $(if $(SOURCE_DATE_EPOCH),-fixed-time $(SOURCE_DATE_EPOCH))
>>> +   -processors 1
>>>  endef
>>>  # $(1): board name
>>> diff --git a/tools/squashfs4/Makefile b/tools/squashfs4/Makefile
>>> index e2c9fc91cc..e176f06e86 100644
>>> --- a/tools/squashfs4/Makefile
>>> +++ b/tools/squashfs4/Makefile
>>> @@ -7,14 +7,12 @@
>>>  include $(TOPDIR)/rules.mk
>>>  PKG_NAME:=squashfs4
>>> -PKG_VERSION:=4.2
>>> +PKG_VERSION:=5.0
>>> -PKG_SOURCE:=squashfs$(PKG_VERSION).tar.gz
>>> -PKG_SOURCE_URL:=@SF/squashfs
>>> -PKG_HASH:=d9e0195aa922dbb665ed322b9aaa96e04a476ee650f39bbeadb0d00b24022e96
>>> -PKG_CAT:=zcat
>>> -
>>> -HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/squashfs$(PKG_VERSION)
>>> +PKG_SOURCE_PROTO:=git
>>> +PKG_SOURCE_DATE:=2017-05-25
>>> +PKG_SOURCE_URL:=https://github.com/lynxis/squashfs-tools.git
>>> +PKG_SOURCE_VERSION:=32a07d4156a281084c90a4b78affc8b0b32a26fc
>>>  include $(INCLUDE_DIR)/host-build.mk
>> Why not use https://github.com/squashfs-tools/squashfs-tools or what
>> will be the official repo?
>>> index 9e1c1fbb1e..00
>>> --- a/tools/squashfs4/patches/160-expose_lzma_xz_options.patch
>>> +++ /dev/null
>>> @@ -1,929 +0,0 @@
>>>  /dev/null
>>> -+++ b/squashfs-tools/lzma_xz_options.h
>> ..
>>> -+struct lzma_opts {
>>> -+  uint32_t dict_size;
>>> -+  uint32_t flags;
>>> -+#define LZMA_OPT_FLT_MASK 0x
>>> -+#define LZMA_OPT_PRE_OFF  16
>>> -+#define LZMA_OPT_PRE_MASK (0xf << LZMA_OPT_PRE_OFF)
>>> -+#define LZMA_OPT_EXTREME  20
>>> -+  uint16_t bit_opts;
>>> -+#define LZMA_OPT_LC_OFF   0
>>> -+#define LZMA_OPT_LC_MASK  (0x7 << LZMA_OPT_LC_OFF)
>>> -+#define LZMA_OPT_LP_OFF   3
>>> -+#define LZMA_OPT_LP_MASK  (0x7 << LZMA_OPT_LP_OFF)
>>> -+#define LZMA_OPT_PB_OFF   6
>>> -+#define LZMA_OPT_PB_MASK  (0x7 << LZMA_OPT_PB_OFF)
>>> -+  uint16_t fb;
>>> -+};
>> Nice that you got this change upstream. The kernel version of this
>> structure only has the first two members, but it still works.
>> See struct disk_comp_opts in fs/squashfs/xz_wrapper.c
>> Hauke
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org

[LEDE-DEV] [PATCH] brcm47xx: switch to the kernel 4.14

[Rafał Miłecki]

From: Rafał Miłecki 

The biggest (and the only?) disadventage of this is obviously an
increased image size.

For mips74k the size of vmlinux goes up from 4186684 B to 4701436 B.
Most devices use LZMA compressed kernel so probably more important is
vmlinux.lzma size which goes up from 1342945 B to the 1508498 B.

Still this isn't something that should stop target kernel bump. There
are various adventages of kernel 4.14. If kernel / image size is a
serious concern for anyone, it's perfectly possible to use previous
release which is pretty solid for the brcm47xx.

Signed-off-by: Rafał Miłecki 
Cc: Paul Wassi 
Cc: Hauke Mehrtens 
---
 target/linux/brcm47xx/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/brcm47xx/Makefile b/target/linux/brcm47xx/Makefile
index f0ac7f94a0..484f314bc1 100644
--- a/target/linux/brcm47xx/Makefile
+++ b/target/linux/brcm47xx/Makefile
@@ -13,7 +13,7 @@ FEATURES:=squashfs usb
 SUBTARGETS:=generic mips74k legacy
 MAINTAINER:=Hauke Mehrtens 
 
-KERNEL_PATCHVER:=4.9
+KERNEL_PATCHVER:=4.14
 
 define Target/Description
Build firmware images for Broadcom based BCM47xx/53xx routers with MIPS 
CPU, *not* ARM.
-- 
2.13.6


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Firewall restart crashes routers with kernel 4.14

[Lucian Cristian]

On 05.05.2018 15:56, Kristian Evensen wrote:

Hello,

When restarting the firewall on routers running latest nightly, I
frequently get the following warning:

[   74.952854] [ cut here ]
[   74.952874] WARNING: CPU: 2 PID: 0 at
net/netfilter/nf_conntrack_rtcache.c:197 0x8f6293f0
[   74.952876] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[   74.953097]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_tablt
[   74.953279]  ip_set_hash_netiface ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet
ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip
ip_set_hash_ipport ip_set_hash_ipmarm
[   74.953472]  ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   74.953512] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
4.14.37 #0
[   74.953515] Stack :     805c7ad2
0042  8052c580
[   74.953542] 8fc44834 805668e7 804f59fc 0002 
0001 8fc11c38 
[   74.953569]   805c 1233d908 0004
80452cac 7d0b0d06 000c2bff
[   74.953597]  8057 935d 805f 
 8059 8f6293f0
[   74.953625] 0009 00c5 0001 0003 0002
8036a504 0008 805c0008
[   74.953652] ...
[   74.953660] Call Trace:
[   74.953674] [<800103f8>] show_stack+0x58/0x100
[   74.953689] [<8043c03c>] dump_stack+0x9c/0xe0
[   74.953700] [<8002e190>] __warn+0xe0/0x114
[   74.953711] [<8002e254>] warn_slowpath_null+0x1c/0x28
[   74.953739] [<8f6293f0>] 0x8f6293f0
[   74.953754] ---[ end trace 6b009cc1611edaa4 ]---

The router then seems to spin on this warning, becomes
unreachable/unresponsive and never reboots. If I compile an image with
rtcache disabled (doing rmmod on the module triggers an oops),
firewall restarts works fine.

I tried to take a look at the code to check if I could spot anything
obvious, but couldn't see anything.

BR,
Kristian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


do you have hardware offloading enabled and multiwan ?

I have the same problem when I enable them

Regards


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.06 Status?

[Fernando Frediani]

I didn't mention forcing people at any point. Just having someone to be 
in charge in order to organize certain things, get people's availability 
and make more thing happen.


With regards schedule the lack of one seems not doing much good, so 
having one has the potential to improve things. And again, having a 
schedule doesn't necessarily mean every single point will get done, but 
certainly will get more attention and commitment from most of people 
around something in common. It will not be a big thing if a feature was 
skipped.


As mentioned in the other reply perhaps Release Coordinator could do 
this job fine without changing much of the whole thing.


Regards
Fernando

On 05/05/2018 15:55, Alberto Bursi wrote:

This isn't a job where you can force people to do anything.

Also, I'm not a fan of half-assing or leaving out things for the sake 
of a schedule.



-Alberto

On 05/05/2018 20:41, Fernando Frediani wrote:
One characteristic from OpenWrt, different from other projects is the 
lack of a leader or a person who can gather others together, make 
some decisions or push for them to happen. If one doesn't like this 
title it can also be "Project Manager" or "Project Coordinator". 
This, in my view, makes a big difference for things to flow in time.


Has anyone heard that saying: "A dog with many owners starves"

Perhaps it is the time to adjust the Rules 
(https://openwrt.org/rules) and add something to make it exist in 
benefit of the project.


Fernando

On 05/05/2018 07:27, Jaap Buurman wrote:

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can simply
move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen 
 wrote:

On 05/01/2018 10:47 AM, Hannu Nyman wrote:
I think that the main source tree is in pretty good shape, so 
branching

off the 18.0X rather soon might make sense


I would also think its time to branch 18.[something-soon], and 
rather than

focus on work that needs yet to be completed, look to cut hardware and
packages that are not ready for a release. There is always some 
heart ache
when such decisions are made, but at a point those decisions do 
need to be
made. Without an official release to punctuate both the core team 
and other

packagers hard work, OpenWrt/LEDE could risk losing support from the
community and its limited sponsorship. I imagine this project means
something personally to the core team, so those risks should be 
considered.


- Eric


___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm

___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] 18.06 Status?

[Luiz Angelo Daros de Luca]

> One characteristic from OpenWrt, different from other projects is the
> lack of a leader or a person who can gather others together, make some
> decisions or push for them to happen. If one doesn't like this title it
> can also be "Project Manager" or "Project Coordinator". This, in my
> view, makes a big difference for things to flow in time.

Maybe we just need someone to be the Release Coordinator, that can be
responsible for a single
release. John seems to be doing that job for this one.

ML info about 18.xx release is scarce. Maybe something was discussed
elsewhere (IRC, forum, in person)

I really thing that a time based release would work better without a
central project leader.
The "when" would already be set. The "what" is what was already commited.
It could even be automated. If something is not commited yet, just wait for
the next release.
If we could do it more often (6 or 8 months), it would not matter too much
if a feature was skipped.

I have pending patches both on maillist (improves backup) and github (fixes
easy-rsa) that I would like
to have them commited (or even rejected). Most (if not all) pending patches
on github (77) or patchwork (44)
is from developers without commit access. They are potential future
developers that will keep the project
alive. I'm not specific talking about my patches but it would be kind to
encourage new devs to have their work
considered, even to say "NAK".

Regards,
---
  Luiz Angelo Daros de Luca
 luizl...@gmail.com

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.06 Status?

[Alberto Bursi]

This isn't a job where you can force people to do anything.

Also, I'm not a fan of half-assing or leaving out things for the sake of 
a schedule.



-Alberto

On 05/05/2018 20:41, Fernando Frediani wrote:
One characteristic from OpenWrt, different from other projects is the 
lack of a leader or a person who can gather others together, make some 
decisions or push for them to happen. If one doesn't like this title 
it can also be "Project Manager" or "Project Coordinator". This, in my 
view, makes a big difference for things to flow in time.


Has anyone heard that saying: "A dog with many owners starves"

Perhaps it is the time to adjust the Rules (https://openwrt.org/rules) 
and add something to make it exist in benefit of the project.


Fernando

On 05/05/2018 07:27, Jaap Buurman wrote:

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can simply
move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen 
 wrote:

On 05/01/2018 10:47 AM, Hannu Nyman wrote:
I think that the main source tree is in pretty good shape, so 
branching

off the 18.0X rather soon might make sense


I would also think its time to branch 18.[something-soon], and 
rather than

focus on work that needs yet to be completed, look to cut hardware and
packages that are not ready for a release. There is always some 
heart ache
when such decisions are made, but at a point those decisions do need 
to be
made. Without an official release to punctuate both the core team 
and other

packagers hard work, OpenWrt/LEDE could risk losing support from the
community and its limited sponsorship. I imagine this project means
something personally to the core team, so those risks should be 
considered.


- Eric


___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm

___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] ipq40xx cpu frequency

[Christian Lamparter]

Hello,

On Friday, May 4, 2018 4:12:16 PM CEST Roman Yeryomin wrote:
> I'm seeing this
> 
> [1.275858] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 
> 632000 KHz
> [1.276620] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency 
> changed to: 716000 KHz

Sorry, but I'm having this "déjà vu"? I do remember *trying* to talk with
you about this in this thread "ipq806x: add ap.dk01.1 board support" already.

Back then you initially went with 710 MHz and I warned:
|There's a reason to stick with the 666MHz rate though. You should check
|if the device produces messages like:
|[1.399981] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 666000 
KHz
|[1.400256] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency 
changed to: 71 KHz
|(From what I know, the SBL actually sets it to 666MHz)
|
|But there's more. If you look at qualcomm's page, it's says that the
|CPU Clock Speed is 717 MHz: 
|
|Since you are working for a OEM/ODM. You could please ask what is the
|right MHz table for these devices? Unfortunately, Qualcomm never got
|around to fix this upstream and without an official statement from them
|it's very difficult to push stuff like this upstream.
Have we come full circle now?

> on ap-dk01 board (I suspect others may be affected too, I don't
> have hw to test).
Yes that is true some boards print the same warning (with different
unlisted frequencies). The patch was sent upstream to linux-clk along
with a request on how this should be handled. Sadly no maintainer
has replied, even though the some of the IPQ40XX boards are crashing
without it.

> Looks like related to your commit
> a44d435c1d ipq40xx: fix apss cpu overclocking spam
> 
> While it fixes the original problem described, it would be nice not to 
> misconfigure the clock anyway.
Hmm? I think this is a misunderstanding, or are you jumping to conclusions?
The patch does not misconfigure the clock. The 900-clk-fix.patch
message explains in detail what the patch does and why:
|This patch attempts to fix the issue by modifying
|clk_cpu_div_round_rate(), clk_cpu_div_set_rate(), clk_cpu_div_recalc_rate()
|to use a new qcom_find_freq_close() function, which returns the closest
|matching frequency, instead of the next higher. This way, the SoC in
|the FB4040 (with its max clock speed of 710.4 MHz) will no longer
|try to overclock to 761 MHz.

> Also, since the official highest frequency is 716.8MHz, wouldn't it be 
> more logical to fix it in appropriate board dts (if needed) and not in 
> the common dtsi?
The gcc-ipq4019.c clk driver has a fixed frequency table defining all
the valid frequencies. The reason why this "worked" in the past (i.e 4.9)
was a bug in the gcc-ipq4019.c driver that got fixed with:
"clk: qcom: ipq4019: Add the apss cpu pll divider clock node"
>From what I can tell, back then the clk driver didn't really program
the P_DDRPLLAPSS clock so the device was left running at the
max frequency that u-boot or SBL1 programmed it.

Anyway, I took a peek into the patches that I sent to Mathias and John.
>From what I can tell the 716.8 MHz to 716 MHz didn't happen there. But I
think I know where it comes from: You see "Sricharan R" posted this patch
to linux-msm-arm: . But please
check with Mathias too (CCd).

Thank you and best regards,
Christian



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.06 Status?

[Fernando Frediani]

One characteristic from OpenWrt, different from other projects is the 
lack of a leader or a person who can gather others together, make some 
decisions or push for them to happen. If one doesn't like this title it 
can also be "Project Manager" or "Project Coordinator". This, in my 
view, makes a big difference for things to flow in time.


Has anyone heard that saying: "A dog with many owners starves"

Perhaps it is the time to adjust the Rules (https://openwrt.org/rules) 
and add something to make it exist in benefit of the project.


Fernando

On 05/05/2018 07:27, Jaap Buurman wrote:

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can simply
move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen  wrote:

On 05/01/2018 10:47 AM, Hannu Nyman wrote:

I think that the main source tree is in pretty good shape, so branching
off the 18.0X rather soon might make sense


I would also think its time to branch 18.[something-soon], and rather than
focus on work that needs yet to be completed, look to cut hardware and
packages that are not ready for a release. There is always some heart ache
when such decisions are made, but at a point those decisions do need to be
made. Without an official release to punctuate both the core team and other
packagers hard work, OpenWrt/LEDE could risk losing support from the
community and its limited sponsorship. I imagine this project means
something personally to the core team, so those risks should be considered.

- Eric


___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm

___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.06 Status?

[John Crispin]

On 05/05/18 12:27, Jaap Buurman wrote:

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can simply
move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen  wrote:

On 05/01/2018 10:47 AM, Hannu Nyman wrote:

I think that the main source tree is in pretty good shape, so branching
off the 18.0X rather soon might make sense


I would also think its time to branch 18.[something-soon], and rather than
focus on work that needs yet to be completed, look to cut hardware and
packages that are not ready for a release. There is always some heart ache
when such decisions are made, but at a point those decisions do need to be
made. Without an official release to punctuate both the core team and other
packagers hard work, OpenWrt/LEDE could risk losing support from the
community and its limited sponsorship. I imagine this project means
something personally to the core team, so those risks should be considered.

- Eric


___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


we agreed already to branch on friday but delayed it till start of the 
week as we ran out of time before calling it a day.

    John



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v2] kernel: bump kernel 4.4 to 4.4.131 for 17.01

[Etienne Haarsma]

* Refreshed patches

Compile-tested: ar71xx
Run-tested: ar71xx

Signed-off-by: Etienne Haarsma 
---
 include/kernel-version.mk|  4 ++--
 ...03-mtd_fix_cfi_cmdset_0002_status_check.patch | 14 +++---
 ...11-mtd-cfi_cmdset_0002-force-word-write.patch |  6 +++---
 .../patches-4.4/0029-Add-dwc_otg-driver.patch|  2 +-
 ...mdset_0002-add-buffer-write-cmd-timeout.patch |  2 +-
 .../patches-4.4/630-packet_socket_type.patch | 16 
 ...cting-with-source-address-failed-policy.patch | 16 
 ...-fix-cfi-cmdset-0002-erase-status-check.patch |  4 ++--
 ...37-mtd-cfi-cmdset-0002-force-word-write.patch |  6 +++---
 9 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index 5f2f87a4af..f10bbcabbc 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,10 +3,10 @@
 LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .129
+LINUX_VERSION-4.4 = .131
 
 LINUX_KERNEL_HASH-3.18.43 = 
1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.129 = 
a165c4bada6a8d2355727ef6c97669e8c87c48f28bb410af34741c87fcf4712b
+LINUX_KERNEL_HASH-4.4.131 = 
65127add35c45acda866d10860e80bfdcc19b6c21e30e5dc9b92020a44d7c709
 
 ifdef KERNEL_PATCHVER
   LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git 
a/target/linux/ar71xx/patches-4.4/403-mtd_fix_cfi_cmdset_0002_status_check.patch
 
b/target/linux/ar71xx/patches-4.4/403-mtd_fix_cfi_cmdset_0002_status_check.patch
index 1ccce4ecec..8f41d9432c 100644
--- 
a/target/linux/ar71xx/patches-4.4/403-mtd_fix_cfi_cmdset_0002_status_check.patch
+++ 
b/target/linux/ar71xx/patches-4.4/403-mtd_fix_cfi_cmdset_0002_status_check.patch
@@ -1,6 +1,6 @@
 --- a/drivers/mtd/chips/cfi_cmdset_0002.c
 +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
-@@ -1632,8 +1632,8 @@ static int __xipram do_write_oneword(str
+@@ -1633,8 +1633,8 @@ static int __xipram do_write_oneword(str
break;
}
  
@@ -11,7 +11,7 @@
  
/* Latency issues. Drop the lock, wait a while and retry */
UDELAY(map, chip, adr, 1);
-@@ -1649,6 +1649,8 @@ static int __xipram do_write_oneword(str
+@@ -1650,6 +1650,8 @@ static int __xipram do_write_oneword(str
  
ret = -EIO;
}
@@ -20,7 +20,7 @@
xip_enable(map, chip, adr);
   op_done:
if (mode == FL_OTP_WRITE)
-@@ -2227,7 +2229,6 @@ static int cfi_amdstd_panic_write(struct
+@@ -2228,7 +2230,6 @@ static int cfi_amdstd_panic_write(struct
return 0;
  }
  
@@ -28,7 +28,7 @@
  /*
   * Handle devices with one erase region, that only implement
   * the chip erase command.
-@@ -2291,8 +2292,8 @@ static int __xipram do_erase_chip(struct
+@@ -2293,8 +2294,8 @@ static int __xipram do_erase_chip(struct
chip->erase_suspended = 0;
}
  
@@ -39,7 +39,7 @@
  
if (time_after(jiffies, timeo)) {
printk(KERN_WARNING "MTD %s(): software timeout\n",
-@@ -2312,6 +2313,7 @@ static int __xipram do_erase_chip(struct
+@@ -2314,6 +2315,7 @@ static int __xipram do_erase_chip(struct
ret = -EIO;
}
  
@@ -47,7 +47,7 @@
chip->state = FL_READY;
xip_enable(map, chip, adr);
DISABLE_VPP(map);
-@@ -2380,9 +2382,9 @@ static int __xipram do_erase_oneblock(st
+@@ -2383,9 +2385,9 @@ static int __xipram do_erase_oneblock(st
chip->erase_suspended = 0;
}
  
@@ -59,7 +59,7 @@
}
  
if (time_after(jiffies, timeo)) {
-@@ -2404,6 +2406,7 @@ static int __xipram do_erase_oneblock(st
+@@ -2407,6 +2409,7 @@ static int __xipram do_erase_oneblock(st
ret = -EIO;
}
  
diff --git 
a/target/linux/ar71xx/patches-4.4/411-mtd-cfi_cmdset_0002-force-word-write.patch
 
b/target/linux/ar71xx/patches-4.4/411-mtd-cfi_cmdset_0002-force-word-write.patch
index 39c5478182..28c6ad875d 100644
--- 
a/target/linux/ar71xx/patches-4.4/411-mtd-cfi_cmdset_0002-force-word-write.patch
+++ 
b/target/linux/ar71xx/patches-4.4/411-mtd-cfi_cmdset_0002-force-word-write.patch
@@ -35,7 +35,7 @@
  
  /* Atmel chips don't use the same PRI format as AMD chips */
  static void fixup_convert_atmel_pri(struct mtd_info *mtd)
-@@ -1791,6 +1795,7 @@ static int cfi_amdstd_write_words(struct
+@@ -1792,6 +1796,7 @@ static int cfi_amdstd_write_words(struct
  /*
   * FIXME: interleaved mode not tested, and probably not supported!
   */
@@ -43,7 +43,7 @@
  static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
unsigned long adr, const u_char *buf,
int len)
-@@ -1919,7 +1924,6 @@ static int __xipram do_write_buffer(stru
+@@ -1920,7 +1925,6 @@ static int __xipram do_write_buffer(stru
return ret;
  }
  
@@ -51,7 +51,7 @@
  static int 

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

[Roman Yeryomin]

On 2018-05-05 16:35, Linus Walleij wrote:
On Sat, May 5, 2018 at 11:25 AM, Linus Walleij 
 wrote:
On Fri, May 4, 2018 at 11:49 PM, Linus Walleij 
 wrote:
On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin  
wrote:



The GPIO LEDs does not come up though?
CONFIG_LEDS_GPIO is not in config, and
/sys/class/leds is empty.

Does it need  a separate kmod?


kmod-leds-gpio is part of DEFAULT_PACKAGES now
I guess you should run menuconfig and/or clean tmp/ to refresh 
profile

package set.


Hm I ran menuconfig and it doesn't work, and removing
tmp/ didn't help either, but selecting a different target
and then selecting CS351x again worked... shaky.

OK rebuilding this overnight and retesting.


It is still not working. Do you get GPIO LEDs on your
device with this?

AFAICT the problem is that there is no script in
/etc/modules-boot.d to load the GPIO LED module.

I'm digging into it to figure out more about how this
module load is supposed to work...


Sorry probably bad mechanics from my side, like replacing
the rootfs but not the kernel :(

The good news is: it works like a charm.

All vital components are running, drivers probe, modules
load correctly from the hard drive.


Yeah.. they should be, that's one of the most common modules here :)

On Raidsonic:
root@OpenWrt:/# lsmod | grep led
leds_gpio   2772  0
ledtrig_heartbeat   1570  0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

[Roman Yeryomin]

On 2018-05-05 17:32, Linus Walleij wrote:

On Tue, May 1, 2018 at 8:44 PM, Roman Yeryomin  wrote:

Linus, if you have time, could you check if this helps to bring 
network up

on dir-685?
https://github.com/yeryomin/openwrt/commit/b0296b1f71bd3d677c931addd6de341203fbf18f


Sadly not. At least not outofthebox. I do not know what other
devices using the RTL8366RB is doing apart from this.


What did dmesg say about it?
Did you try swconfig tool? E.g. `swconfig list` and/or `swconfig dev 
switch0 show`


Regards,
Roman

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

[Linus Walleij]

On Tue, May 1, 2018 at 8:44 PM, Roman Yeryomin  wrote:

> Linus, if you have time, could you check if this helps to bring network up
> on dir-685?
> https://github.com/yeryomin/openwrt/commit/b0296b1f71bd3d677c931addd6de341203fbf18f

Sadly not. At least not outofthebox. I do not know what other
devices using the RTL8366RB is doing apart from this.

I built the platform with this small-ish patch on top because
I needed to extract the zImage:

diff --git a/target/linux/gemini/image/Makefile
b/target/linux/gemini/image/Makefile
index 25371f6f1358..3e122fc457ae 100644
--- a/target/linux/gemini/image/Makefile
+++ b/target/linux/gemini/image/Makefile
@@ -7,9 +7,12 @@
 include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/image.mk

-# Build the special D-Link DNS-313 header generator tool
-# needed to generate the hard disk boot images then
-# build D-Link DNS-313 images using the special header tool.
+# Just copy the zImage for D-Link DIR-685
+define Build/dir685-images
+   cp $(IMAGE_KERNEL) $(BIN_DIR)/$(IMG_PREFIX)-dir685-zImage
+endef
+
+# Build D-Link DNS-313 images using the special header tool.
 # rootfs.tgz and rd.tgz contains nothing, we only need them
 # to satisfy the boot loader on the device. The zImage is
 # the only real content.
@@ -79,6 +82,8 @@ define Device/dlink-dir-685
DEVICE_TITLE := D-Link DIR-685 Xtreme N Storage Router
DEVICE_PACKAGES := $(GEMINI_NAS_PACKAGES) \
kmod-switch-rtl8366rb swconfig
+   IMAGES += dir685-image
+   IMAGE/dir685-image := dir685-images
 endef
 TARGET_DEVICES += dlink-dir-685

But I guess I should work on getting some proper flash image support
in place for this device.

I plan to repost my mainline RTL8366RB DSA patches after
some redesign,they are still not working for me, but at least
getting better in all other aspects, except actually providing
networking :(

Yours,
Linus Walleij

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC PATCH] tools/squashfs: change to upstream and update to new version 5.0-rc1

[Paul Spooren]

Are there any updates on this issue? I'd really like to see squasfs 5.0 
used in OpenWrt!


On Sat, May 27, 2017 at 8:51 PM, Hauke Mehrtens  
wrote:

On 05/26/2017 06:13 PM, Alexander Couzens wrote:

 squashfs is quite long unmaintained. All patches from major
 distributions are integrated.
 Fixed timestamp is now using the environment SOURCE_DATE_EPOCH
 instead of arguments.

 Signed-off-by: Alexander Couzens 


Thanks for working on this.


 ---
  include/image.mk   |   3 +-
  tools/squashfs4/Makefile   |  12 +-
  tools/squashfs4/patches/100-portability.patch  |  40 -
  .../patches/110-allow_static_liblzma.patch |  30 -
  tools/squashfs4/patches/120-cygwin_fixes.patch | 153 
  tools/squashfs4/patches/150-freebsd_fixes.patch|  10 -
  .../patches/160-expose_lzma_xz_options.patch   | 929 
-

  ...0-add_support_for_LZMA_MAGIC_to_unsqashfs.patch |  72 --
  tools/squashfs4/patches/180-openbsd_compat.patch   |  24 -
  .../patches/190-no_nonstatic_inline.patch  |  36 -
  .../patches/200-add-fixed-timestamp-option.patch   |  82 --
  11 files changed, 6 insertions(+), 1385 deletions(-)
  delete mode 100644 tools/squashfs4/patches/100-portability.patch
  delete mode 100644 
tools/squashfs4/patches/110-allow_static_liblzma.patch

  delete mode 100644 tools/squashfs4/patches/120-cygwin_fixes.patch
  delete mode 100644 tools/squashfs4/patches/150-freebsd_fixes.patch
  delete mode 100644 
tools/squashfs4/patches/160-expose_lzma_xz_options.patch
  delete mode 100644 
tools/squashfs4/patches/170-add_support_for_LZMA_MAGIC_to_unsqashfs.patch

  delete mode 100644 tools/squashfs4/patches/180-openbsd_compat.patch
  delete mode 100644 
tools/squashfs4/patches/190-no_nonstatic_inline.patch
  delete mode 100644 
tools/squashfs4/patches/200-add-fixed-timestamp-option.patch


 diff --git a/include/image.mk b/include/image.mk
 index ad9535d018..eaabba2d0e 100644
 --- a/include/image.mk
 +++ b/include/image.mk
 @@ -203,8 +203,7 @@ define Image/mkfs/squashfs
  	$(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) 
$@ \

-nopad -noappend -root-owned \
-comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \
 -  -processors 1 \
 -  $(if $(SOURCE_DATE_EPOCH),-fixed-time $(SOURCE_DATE_EPOCH))
 +  -processors 1
  endef

  # $(1): board name
 diff --git a/tools/squashfs4/Makefile b/tools/squashfs4/Makefile
 index e2c9fc91cc..e176f06e86 100644
 --- a/tools/squashfs4/Makefile
 +++ b/tools/squashfs4/Makefile
 @@ -7,14 +7,12 @@
  include $(TOPDIR)/rules.mk

  PKG_NAME:=squashfs4
 -PKG_VERSION:=4.2
 +PKG_VERSION:=5.0

 -PKG_SOURCE:=squashfs$(PKG_VERSION).tar.gz
 -PKG_SOURCE_URL:=@SF/squashfs
 
-PKG_HASH:=d9e0195aa922dbb665ed322b9aaa96e04a476ee650f39bbeadb0d00b24022e96

 -PKG_CAT:=zcat
 -
 -HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/squashfs$(PKG_VERSION)
 +PKG_SOURCE_PROTO:=git
 +PKG_SOURCE_DATE:=2017-05-25
 +PKG_SOURCE_URL:=https://github.com/lynxis/squashfs-tools.git
 +PKG_SOURCE_VERSION:=32a07d4156a281084c90a4b78affc8b0b32a26fc

  include $(INCLUDE_DIR)/host-build.mk



Why not use https://github.com/squashfs-tools/squashfs-tools or what
will be the official repo?


 index 9e1c1fbb1e..00
 --- a/tools/squashfs4/patches/160-expose_lzma_xz_options.patch
 +++ /dev/null
 @@ -1,929 +0,0 @@
  /dev/null
 -+++ b/squashfs-tools/lzma_xz_options.h

..

 -+struct lzma_opts {
 -+ uint32_t dict_size;
 -+ uint32_t flags;
 -+#define LZMA_OPT_FLT_MASK0x
 -+#define LZMA_OPT_PRE_OFF 16
 -+#define LZMA_OPT_PRE_MASK(0xf << LZMA_OPT_PRE_OFF)
 -+#define LZMA_OPT_EXTREME 20
 -+ uint16_t bit_opts;
 -+#define LZMA_OPT_LC_OFF  0
 -+#define LZMA_OPT_LC_MASK (0x7 << LZMA_OPT_LC_OFF)
 -+#define LZMA_OPT_LP_OFF  3
 -+#define LZMA_OPT_LP_MASK (0x7 << LZMA_OPT_LP_OFF)
 -+#define LZMA_OPT_PB_OFF  6
 -+#define LZMA_OPT_PB_MASK (0x7 << LZMA_OPT_PB_OFF)
 -+ uint16_t fb;
 -+};


Nice that you got this change upstream. The kernel version of this
structure only has the first two members, but it still works.
See struct disk_comp_opts in fs/squashfs/xz_wrapper.c

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] brcm2708: add squashfs rootfs image

[Paul Spooren]

On Thu, Mar 29, 2018 at 9:22 AM, Daniel Golle  
wrote:

On Tue, Mar 27, 2018 at 07:42:18PM +0200, Christian Lamparter wrote:

 This patch adds a image with squashfs as the root filesystem.
 A rootfs_data partition will be generated on the first boot
 and placed inside the rootfs partition (just after the squashfs
 image).

 advantages:
  - it is possible to migrate from an existing -ext4
installation and back via sysupgrade.
  - existing partition layout will not be lost.
  - slightly smaller image size.
  - support for attendedsysupgrade

 disadvantages:
  - needs f2fs + tools as well. This is because fs-tools decides on 
the
blocksize of the sdcard. So either f2fs or ext4 can get choosen 
as
the rootfs_data filesystem (depends on the size of the root 
partition).

  - rootfs_data is placed into the rootfs partition. This makes
it difficult for tools that expect a /dev/mmc0pX device.
It also makes it difficult for data recovery tools since they
might not expect to find a embedded partition or will be
confused.

 For people with existing build configurations: make sure to include 
mkf2fs
 and f2fsck package into the image... Otherwise the new -squashfs 
image will
 boot of a ram-overlay and won't keep the configurations after a 
reboot.


 Cc: Álvaro Fernández Rojas 
 Cc: Paul Spooren 
 Cc: Daniel Golle 
 Signed-off-by: Christian Lamparter 


Acked-by: Daniel Golle 


I tried the patch and the created squashfs works! However, trying a 
sysupgrade errored saying it's unsupported. Is it possible we have to 
teach the sysupgrade that squashfs is compatible, too?


Except from that, it works and runs with no problems on my RPI3, please 
merge.


Regarding the doubts of Christian, is there any problem producing the 
ext4 and squashfs per default?


Best, Paul


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

[Linus Walleij]

On Sat, May 5, 2018 at 11:25 AM, Linus Walleij  wrote:
> On Fri, May 4, 2018 at 11:49 PM, Linus Walleij  
> wrote:
>> On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin  wrote:
>>
 The GPIO LEDs does not come up though?
 CONFIG_LEDS_GPIO is not in config, and
 /sys/class/leds is empty.

 Does it need  a separate kmod?
>>>
>>> kmod-leds-gpio is part of DEFAULT_PACKAGES now
>>> I guess you should run menuconfig and/or clean tmp/ to refresh profile
>>> package set.
>>
>> Hm I ran menuconfig and it doesn't work, and removing
>> tmp/ didn't help either, but selecting a different target
>> and then selecting CS351x again worked... shaky.
>>
>> OK rebuilding this overnight and retesting.
>
> It is still not working. Do you get GPIO LEDs on your
> device with this?
>
> AFAICT the problem is that there is no script in
> /etc/modules-boot.d to load the GPIO LED module.
>
> I'm digging into it to figure out more about how this
> module load is supposed to work...

Sorry probably bad mechanics from my side, like replacing
the rootfs but not the kernel :(

The good news is: it works like a charm.

All vital components are running, drivers probe, modules
load correctly from the hard drive.

Tested-by: Linus Walleij 

Yours,
Linus Walleij

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Firewall restart crashes routers with kernel 4.14

[Kristian Evensen]

Hello,

When restarting the firewall on routers running latest nightly, I
frequently get the following warning:

[   74.952854] [ cut here ]
[   74.952874] WARNING: CPU: 2 PID: 0 at
net/netfilter/nf_conntrack_rtcache.c:197 0x8f6293f0
[   74.952876] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[   74.953097]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_tablt
[   74.953279]  ip_set_hash_netiface ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet
ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip
ip_set_hash_ipport ip_set_hash_ipmarm
[   74.953472]  ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   74.953512] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
4.14.37 #0
[   74.953515] Stack :     805c7ad2
0042  8052c580
[   74.953542] 8fc44834 805668e7 804f59fc 0002 
0001 8fc11c38 
[   74.953569]   805c 1233d908 0004
80452cac 7d0b0d06 000c2bff
[   74.953597]  8057 935d 805f 
 8059 8f6293f0
[   74.953625] 0009 00c5 0001 0003 0002
8036a504 0008 805c0008
[   74.953652] ...
[   74.953660] Call Trace:
[   74.953674] [<800103f8>] show_stack+0x58/0x100
[   74.953689] [<8043c03c>] dump_stack+0x9c/0xe0
[   74.953700] [<8002e190>] __warn+0xe0/0x114
[   74.953711] [<8002e254>] warn_slowpath_null+0x1c/0x28
[   74.953739] [<8f6293f0>] 0x8f6293f0
[   74.953754] ---[ end trace 6b009cc1611edaa4 ]---

The router then seems to spin on this warning, becomes
unreachable/unresponsive and never reboots. If I compile an image with
rtcache disabled (doing rmmod on the module triggers an oops),
firewall restarts works fine.

I tried to take a look at the code to check if I could spot anything
obvious, but couldn't see anything.

BR,
Kristian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2 00/10] at91 patch series

[Hauke Mehrtens]

On 05/04/2018 07:27 PM, Sandeep Sheriker Mallikarjun wrote:
> resending all patches again due with rebase.
> 
> Sandeep Sheriker Mallikarjun (10):
>   at91bootstrap:update to v3.8.10
>   at91: fix sdcard create image
>   uboot-at91: fetch uboot src from u-boot-at91 github
>   kernel: fix build error for external kernel.
>   at91: Add SAMA5D27 SOM1 EK board
>   at91: sdcard image with ext4 rootfs
>   uboot-at91: fix DTC command not found.
>   at91: reorganize at91 subtargets
>   at91: Add SAMA5D2 PTC EK board
>   at91: refreshing kernel configurations.
> 
>  package/boot/at91bootstrap/Makefile|  49 +-
>  package/boot/at91bootstrap/at91bootstrap.mk|   2 +-
>  package/boot/uboot-at91/Makefile   |  65 +-
>  package/kernel/linux/modules/other.mk  |   6 +-
>  package/kernel/mac80211/Makefile   |  15 +-
>  target/linux/at91/Makefile |   2 +-
>  target/linux/at91/base-files/lib/at91.sh   |   6 +
>  target/linux/at91/config-4.9   | 445 --
>  target/linux/at91/image/Makefile   |  53 +-
>  target/linux/at91/image/sama5.mk   |  90 --
>  target/linux/at91/image/sama5d2.mk |  31 +
>  target/linux/at91/image/sama5d3.mk |  33 +
>  target/linux/at91/image/sama5d4.mk |  19 +
>  target/linux/at91/legacy/config-default| 239 ++
>  ...4-ARM-at91-build-dtb-for-sama5d27-SOM1-Ek.patch | 908 
> +
>  ...105-ARM-at91-build-dtb-for-sama5d2-ptc-Ek.patch | 442 ++
>  target/linux/at91/sama5/config-default |  52 --
>  target/linux/at91/sama5/target.mk  |   9 -
>  target/linux/at91/sama5d2/config-default   | 287 +++
>  target/linux/at91/sama5d2/target.mk|  10 +
>  target/linux/at91/sama5d3/config-default   | 287 +++
>  target/linux/at91/sama5d3/target.mk|  10 +
>  target/linux/at91/sama5d4/config-default   | 287 +++
>  target/linux/at91/sama5d4/target.mk|  10 +
>  24 files changed, 3124 insertions(+), 233 deletions(-)
>  delete mode 100644 target/linux/at91/image/sama5.mk
>  create mode 100644 target/linux/at91/image/sama5d2.mk
>  create mode 100644 target/linux/at91/image/sama5d3.mk
>  create mode 100644 target/linux/at91/image/sama5d4.mk
>  create mode 100644 
> target/linux/at91/patches-4.9/104-ARM-at91-build-dtb-for-sama5d27-SOM1-Ek.patch
>  create mode 100644 
> target/linux/at91/patches-4.9/105-ARM-at91-build-dtb-for-sama5d2-ptc-Ek.patch
>  delete mode 100644 target/linux/at91/sama5/config-default
>  delete mode 100644 target/linux/at91/sama5/target.mk
>  create mode 100644 target/linux/at91/sama5d2/config-default
>  create mode 100644 target/linux/at91/sama5d2/target.mk
>  create mode 100644 target/linux/at91/sama5d3/config-default
>  create mode 100644 target/linux/at91/sama5d3/target.mk
>  create mode 100644 target/linux/at91/sama5d4/config-default
>  create mode 100644 target/linux/at91/sama5d4/target.mk
> 
This caused a build problem found by build bot:

http://phase1.builds.lede-project.org/builders/at91%2Flegacy/builds/820/steps/kmods/logs/stdio
The kernel configuration option CONFIG_POWER_RESET_AT91_SAMA5D2_SHDWC is
not set.

The build bot previously used this configuration:
https://downloads.lede-project.org/snapshots/targets/at91/legacy/config.seed

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.06 Status?

[Jaap Buurman]

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can simply
move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen  wrote:
> On 05/01/2018 10:47 AM, Hannu Nyman wrote:
>>
>> I think that the main source tree is in pretty good shape, so branching
>> off the 18.0X rather soon might make sense
>
>
> I would also think its time to branch 18.[something-soon], and rather than
> focus on work that needs yet to be completed, look to cut hardware and
> packages that are not ready for a release. There is always some heart ache
> when such decisions are made, but at a point those decisions do need to be
> made. Without an official release to punctuate both the core team and other
> packagers hard work, OpenWrt/LEDE could risk losing support from the
> community and its limited sponsorship. I imagine this project means
> something personally to the core team, so those risks should be considered.
>
> - Eric
>
>
> ___
> lede-adm mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

[Hauke Mehrtens]

On 05/05/2018 11:25 AM, Linus Walleij wrote:
> On Fri, May 4, 2018 at 11:49 PM, Linus Walleij  
> wrote:
>> On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin  wrote:
>>
 The GPIO LEDs does not come up though?
 CONFIG_LEDS_GPIO is not in config, and
 /sys/class/leds is empty.

 Does it need  a separate kmod?
>>>
>>> kmod-leds-gpio is part of DEFAULT_PACKAGES now
>>> I guess you should run menuconfig and/or clean tmp/ to refresh profile
>>> package set.
>>
>> Hm I ran menuconfig and it doesn't work, and removing
>> tmp/ didn't help either, but selecting a different target
>> and then selecting CS351x again worked... shaky.
>>
>> OK rebuilding this overnight and retesting.
> 
> It is still not working. Do you get GPIO LEDs on your
> device with this?
> 
> AFAICT the problem is that there is no script in
> /etc/modules-boot.d to load the GPIO LED module.
> 
> I'm digging into it to figure out more about how this
> module load is supposed to work...

AutoProbe has a optional 2. parameter for boot flags, please try to replace
AUTOLOAD:=$(call AutoProbe,)
with:
AUTOLOAD:=$(call AutoProbe,, 1)

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

[Linus Walleij]

On Fri, May 4, 2018 at 11:49 PM, Linus Walleij  wrote:
> On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin  wrote:
>
>>> The GPIO LEDs does not come up though?
>>> CONFIG_LEDS_GPIO is not in config, and
>>> /sys/class/leds is empty.
>>>
>>> Does it need  a separate kmod?
>>
>> kmod-leds-gpio is part of DEFAULT_PACKAGES now
>> I guess you should run menuconfig and/or clean tmp/ to refresh profile
>> package set.
>
> Hm I ran menuconfig and it doesn't work, and removing
> tmp/ didn't help either, but selecting a different target
> and then selecting CS351x again worked... shaky.
>
> OK rebuilding this overnight and retesting.

It is still not working. Do you get GPIO LEDs on your
device with this?

AFAICT the problem is that there is no script in
/etc/modules-boot.d to load the GPIO LED module.

I'm digging into it to figure out more about how this
module load is supposed to work...

Yours,
Linus Walleij

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev