Re: [LEDE-DEV] [PATCH 1/2] kernel: bump 4.9 to 4.9.100
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Patch fails after since Lantiq has been switched over to 4.14 (commit d7b7483343b5c7f157a2a97244ce9e60f4260e43): error: target/linux/lantiq/patches-4.9/0152-lantiq-VPE.patch: does not exist in index Patch failed at 0001 kernel: bump 4.9 to 4.9.100 --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] ipq806x: add kernel 4.14 support
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- ‐‐‐ Original Message ‐‐‐ On 17 May 2018 3:56 PM, John Crispin wrote: > On 17/05/18 13:47, Ram Chandra Jangir wrote: > > > Thanks Michael for confirming this, > > > > Can you please help to update the kernel partition size to 4MB for R7800 > > and send it as patch to community (lede-dev@lists.infradead.org)? > > > > This will help to enable kernel v4.14 for all ipq806x based boards. > > hang on, that would break sysupgrade or not ? Yes, it would. > > John > > > John, > > > > I do not have d7800, r7500, r7500v2 & vr2600v and hence seeking help to > > update partition size for these boards. > > > > Thanks, > > > > Ram > > > > -Original Message- > > > > From: Michael Yartys [mailto:michael.yar...@protonmail.com] > > > > Sent: Saturday, May 05, 2018 2:26 AM > > > > To: Stefan Lippers-Hollmann s@gmx.de > > > > Cc: Ram Chandra Jangir rjan...@codeaurora.org; msm-...@mcclintock.net; > > lede-dev@lists.infradead.org; nar...@codeaurora.org > > > > Subject: Re: [LEDE-DEV] [PATCH v2] ipq806x: add kernel 4.14 support > > > > Hi > > > > Can confirm that this works on my NETGEAR R7800 (ipq8065). The WLAN PCIe > > issues have been fixed. > > > > I've also included my dmesg output in the attachment. > > > > Thanks a lot for the help, Ram! > > > > Michael > > > > On 4 May 2018 9:40 PM, Stefan Lippers-Hollmann s@gmx.de wrote: > > > > > Hi > > > > > > On 2018-05-04, Ram Chandra Jangir wrote: > > > > > > > - Rebased the patches for 4.14 > > > > > > > > - Dropped spi-qup and 0027, 0028, 0029 > > > > > > > > clk patches since it's already included > > > > > > > > in upstream. > > > > > > > > > > > > Tested on IPQ AP148 Board: > > > > > > > > 1. NOR boot and NAND boot > > > > 2. Tested USB and PCIe interfaces > > > > 3. WDOG test > > > > 4. cpu frequency scaling > > > > 5. ethernet, 2G and 5G WiFi > > > > 6. ubi sysupgrade > > > > > > > > Signed-off-by: Ram Chandra Jangir rjan...@codeaurora.org > > > > ---- > > > > > > > > Changes since v1: > > > > > > > > Fixes PCIe ext reset for IPQ8065 boards > > > > > > > > With these changes my ZyXEL nbg6817 (ipq8065) works fine (PCIe and > > > > > > wlan), thanks a lot! > > > > > > New, working, gzip compressed dmesg, attached. > > > > > > Regards > > > > > > Stefan Lippers-Hollmann > > > > > > 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 --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] kernel: bump 4.14 to 4.14.41
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Tested-by: Michael Yartys Compile-tested on: ipq806x Runtime-tested on: ipq806x --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] kernel: bump 4.14 to 4.14.40
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Tested-by: Michael Yartys Compile-tested on: ipq806x Runtime-tested on: ipq806x --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: bump 4.14 to 4.14.40
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Tested-by: Michael Yartys Target: ipq806x (NETGEAR R7800) Just a heads up: Kevin has posted a 4.9.99 patch. --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: bump to 4.9.99
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Tested-by: Michael Yartys Target: ipq806x (NETGEAR R7800) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kernel: bump to 4.9.99
0x2357
#define MCU_TYPE_PLA 0x0100
#define MCU_TYPE_USB 0x
-@@ -1816,6 +1817,10 @@ static int rx_bottom(struct r8152 *tp, i
+@@ -1817,6 +1818,10 @@ static int rx_bottom(struct r8152 *tp, i
unsigned int pkt_len;
struct sk_buff *skb;
@@ -87,9 +87,9 @@ Signed-off-by: Yangbo Lu
pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
if (pkt_len < ETH_ZLEN)
break;
-@@ -4507,6 +4512,7 @@ static struct usb_device_id rtl8152_tabl
- {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x7205)},
+@@ -4509,6 +4514,7 @@ static struct usb_device_id rtl8152_tabl
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x304f)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_LINKSYS, 0x0041)},
{REALTEK_USB_DEVICE(VENDOR_ID_NVIDIA, 0x09ff)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_TPLINK, 0x0601)},
{}
@@ -156,7 +156,7 @@ Signed-off-by: Yangbo Lu
int ret;
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
-@@ -4415,6 +4415,14 @@ hub_port_init(struct usb_hub *hub, struc
+@@ -4423,6 +4423,14 @@ hub_port_init(struct usb_hub *hub, struc
else
speed = usb_speed_string(udev->speed);
diff --git
a/target/linux/mpc85xx/patches-4.9/102-powerpc-add-cmdline-override.patch
b/target/linux/mpc85xx/patches-4.9/102-powerpc-add-cmdline-override.patch
index c70ac1bb9d..55976c32b1 100644
--- a/target/linux/mpc85xx/patches-4.9/102-powerpc-add-cmdline-override.patch
+++ b/target/linux/mpc85xx/patches-4.9/102-powerpc-add-cmdline-override.patch
@@ -17,7 +17,7 @@
help
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
-@@ -1079,6 +1079,17 @@ int __init early_init_dt_scan_chosen(uns
+@@ -1082,6 +1082,17 @@ int __init early_init_dt_scan_chosen(uns
if (p != NULL && l > 0)
strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE));
--
2.15.1 (Apple Git-101)
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] kernel: bump 4.14 to 4.14.39
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- No issues. Tested-by: Michael Yartys Target: ipq806x (NETGEAR R7800) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan (8devices) board.
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> On 8 May 2018, at 21:11, Rosen Penev wrote:
>
>>
>> So out of curiosity I built this for my Archer C7 v2 ar71xx device. I also
>> modified the code to not give up on ‘OK’, so it always iterated 10 times. I
>> then ran this repeatedly using ‘watch’. Observations:
>>
>> 1) Failure only occurred on 1st check, it never appeared/re-appeared on
>> subsequent passes.
>> 2) Failure offsets are always at 32 byte intervals. That corresponds nicely
>> with cache-line size.
> Yeah the L1
>>
>> Grabbing at straws to some extent.
So I modified the user space code a little more, namely moving the usleep to
before the check (obviously still after the mmap) - I am yet to see an error.
printf("mmap addr: %p\n", addr);
data = addr;
for (i = 0; i < 10; i++) {
usleep(50);
check_data(data, page_size);
}
So that smells more of a race condition between the writer filling with 0xFF
and the reader catching up.
Again, assume that I am an idiot and am missing something fundamental.
signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan (8devices) board.
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On 8 May 2018, at 11:16, Daniel Danzberger wrote: > >>> >>> Did you encounter this issue with kernel 4.9? For me, 4.4 caused no >>> data corruption on my external hard drive. >> I can't tell right now. I was trying to use an older version with kernel 4.4, >> but it fails to build. > I just tested with 4.4 and the problem is present there as well. >>> So out of curiosity I built this for my Archer C7 v2 ar71xx device. I also modified the code to not give up on ‘OK’, so it always iterated 10 times. I then ran this repeatedly using ‘watch’. Observations: 1) Failure only occurred on 1st check, it never appeared/re-appeared on subsequent passes. 2) Failure offsets are always at 32 byte intervals. That corresponds nicely with cache-line size. Grabbing at straws to some extent. Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A signature.asc Description: Message signed with OpenPGP --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: bump 4.14 to 4.14.39
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- With the following reordering and Kevin's patch everything works for me: diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 68795f767c04..192ee1c2e969 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -4,13 +4,13 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .71 LINUX_VERSION-4.4 = .121 LINUX_VERSION-4.9 = .98 -LINUX_VERSION-4.14 = .37 +LINUX_VERSION-4.14 = .39 LINUX_KERNEL_HASH-3.18.71 = 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 LINUX_KERNEL_HASH-4.4.121 = 44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729 LINUX_KERNEL_HASH-4.9.98 = 12cd90355adbc946e7e95aa5cdef2dd99b8e166cb64fe53a91c3e1d8f81810ef -LINUX_KERNEL_HASH-4.14.37 = 8197e7ed3620713e412905430a7bf93e2048384042ffba189a66f0eeb6908e92 +LINUX_KERNEL_HASH-4.14.39 = 269fc576ab0509e10c3b26e57866aea3f272c17f172f14fd75e2676d38c1b7bd remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1 sanitize_uri=$(call qstrip,$(subst @,_,$(subst :,_,$(subst .,_,$(subst -,_,$(subst /,_,$(1))) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: bump 4.14 to 4.14.39
| 143 > > ...rk-fix-PCIe-max-read-request-size-setting.patch | 63 - > > ...td-fix-cfi-cmdset-0002-erase-status-check.patch | 4 +- > > ...0037-mtd-cfi-cmdset-0002-force-word-write.patch | 6 +- > > .../patches-4.14/0043-spi-add-mt7621-support.patch | 16 +- > > 60 files changed, 278 insertions(+), 905 deletions(-) > > create mode 100755 refresh_kernel.sh > > mode change 100755 => 100644 > target/linux/generic/pending-4.14/103-MIPS-c-r4k-fix-data-corruption-related-to-cache-coherence.patch > > delete mode 100644 > target/linux/mvebu/patches-4.14/522-PCI-aardvark-fix-logic-in-PCI-configuration-read-write-functions.patch > > delete mode 100644 > target/linux/mvebu/patches-4.14/523-PCI-aardvark-set-PIO_ADDR_LS-correctly-in-advk_pcie_rd_conf.patch > > delete mode 100644 > target/linux/mvebu/patches-4.14/525-PCI-aardvark-use-isr1-instead-of-isr0-interrupt-in-legacy-irq-mode.patch > > delete mode 100644 > target/linux/mvebu/patches-4.14/527-PCI-aardvark-fix-PCIe-max-read-request-size-setting.patch > > diff --git a/include/kernel-version.mk b/include/kernel-version.mk > > index 68795f767c04..192ee1c2e969 100644 > > --- a/include/kernel-version.mk > > +++ b/include/kernel-version.mk > > @@ -4,13 +4,13 @@ LINUX_RELEASE?=1 > > LINUX_VERSION-3.18 = .71 > > LINUX_VERSION-4.4 = .121 > > -LINUX_VERSION-4.14 = .37 > > LINUX_VERSION-4.9 = .98 > > +LINUX_VERSION-4.14 = .39 ^ Must be reordered so that 4.9 is above 4.14. Also, 4.9 is at .96 and not .98, which might also cause some issues. > > LINUX_KERNEL_HASH-3.18.71 = > 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 > > LINUX_KERNEL_HASH-4.4.121 = > 44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729 > > -LINUX_KERNEL_HASH-4.14.37 = > 8197e7ed3620713e412905430a7bf93e2048384042ffba189a66f0eeb6908e92 > > LINUX_KERNEL_HASH-4.9.98 = > 12cd90355adbc946e7e95aa5cdef2dd99b8e166cb64fe53a91c3e1d8f81810ef > > +LINUX_KERNEL_HASH-4.14.39 = > 269fc576ab0509e10c3b26e57866aea3f272c17f172f14fd75e2676d38c1b7bd > ^ The same here. Change hash if kernel 4.9.98 is also an issue. > remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1 > > sanitize_uri=$(call qstrip,$(subst @,,$(subst :,,$(subst .,,$(subst > -,,$(subst /,_,$(1))) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kmod-sched-cake: bump to latest cake 2018-05-07
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- No functional change. Code tidy ups. 735eaf2 Make sure we don't reallocate q->tins (we didn't anyway but his really makes sure) 6c5ad6e Get rid of __GFP_NOWARN flag for memory allocation 2a37333 Don't need the wrapper for kvfree, and no need to check before calling it 2b1c631 Whitespace fix 7fe6e28 compat tidyup (for older kernel versions <4.4) 93b805c pedant tidy up superfluous semicolons on switch statements Signed-off-by: Kevin Darbyshire-Bryant --- package/kernel/kmod-sched-cake/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/kernel/kmod-sched-cake/Makefile b/package/kernel/kmod-sched-cake/Makefile index fe5e2acd50..4f25e56e0e 100644 --- a/package/kernel/kmod-sched-cake/Makefile +++ b/package/kernel/kmod-sched-cake/Makefile @@ -13,9 +13,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL:=https://github.com/dtaht/sch_cake.git -PKG_SOURCE_DATE:=2018-05-04 -PKG_SOURCE_VERSION:=e848241cda393fe1fa643156bcdbe81764bfe060 -PKG_MIRROR_HASH:=70fd1f79dcdf39e47957fa6684a1a41c1b50f51896781bea0d27bc9e8ff057ab +PKG_SOURCE_DATE:=2018-05-07 +PKG_SOURCE_VERSION:=735eaf21e980117e171de9fe7ce046ab8e9f16db +PKG_MIRROR_HASH:=4dd90cf152e876371d363f2442154464cffcee5d64b916a7f4a9fb897ff0d1d9 PKG_MAINTAINER:=Kevin Darbyshire-Bryant include $(INCLUDE_DIR)/package.mk -- 2.15.1 (Apple Git-101) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: bump to 4.9.98
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Compile-tested on: ipq806x Runtime-tested on: ipq806x Tested-by: Michael Yartys ‐‐‐ Original Message ‐‐‐ On 7 May 2018 6:56 PM, Kevin Darbyshire-Bryant via Lede-dev wrote: > The sender domain has a DMARC Reject/Quarantine policy which disallows > > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > > automatically by the mailing list software.Refresh patches. > > Tested-on: ar71xx Archer C7 v2 > > Signed-off-by: Kevin Darbyshire-Bryant l...@darbyshire-bryant.me.uk > > include/kernel-version.mk | 4 ++-- > > .../linux/ar7/patches-4.9/300-add-ac49x-platform.patch | 4 ++-- > > .../403-mtd_fix_cfi_cmdset_0002_status_check.patch | 14 +++--- > > .../411-mtd-cfi_cmdset_0002-force-word-write.patch | 6 +++--- > > .../ar71xx/patches-4.9/500-MIPS-fw-myloader.patch | 2 +- > > .../ar71xx/patches-4.9/604-MIPS-ath79-no-of.patch | 2 +- > > target/linux/ath25/patches-4.9/107-ar5312_gpio.patch | 2 +- > > .../patches-4.9/950-0031-Add-dwc_otg-driver.patch | 2 +- > > ...-Fulfill-user-BO-creation-requests-from-the-k.patch | 2 +- > > ...-Fix-OOPSes-from-trying-to-cache-a-partially-.patch | 2 +- > > 15-01-MIPS-BCM63XX-add-clkdev-lookup-support.patch | 2 +- > > .../322-MIPS-BCM63XX-switch-to-IRQ_DOMAIN.patch | 2 +- > > target/linux/generic/hack-4.9/220-gc_sections.patch | 2 +- > > .../generic/hack-4.9/301-mips_image_cmdline_hack.patch | 2 +- > > .../generic/pending-4.9/300-mips_expose_boot_raw.patch | 4 ++-- > > .../generic/pending-4.9/304-mips_disable_fpu.patch | 2 +- > > ...PS-mm-remove-no-op-dma_map_ops-where-possible.patch | 12 ++-- > > ...-cfi_cmdset_0002-add-buffer-write-cmd-timeout.patch | 2 +- > > .../generic/pending-4.9/630-packet_socket_type.patch | 16 > > ...w-rejecting-with-source-address-failed-policy.patch | 16 > > .../generic/pending-4.9/890-uart_optional_sysrq.patch | 2 +- > > .../patches-4.9/090-increase_entropy_pools.patch | 2 +- > > target/linux/lantiq/patches-4.9/0152-lantiq-VPE.patch | 2 +- > > .../patches-4.9/817-usb-support-layerscape.patch | 18 +- > > .../patches-4.9/102-powerpc-add-cmdline-override.patch | 2 +- > > 25 files changed, 63 insertions(+), 63 deletions(-) > > diff --git a/include/kernel-version.mk b/include/kernel-version.mk > > index cf84e31f7b..fc0856554c 100644 > > --- a/include/kernel-version.mk > > +++ b/include/kernel-version.mk > > @@ -4,12 +4,12 @@ LINUX_RELEASE?=1 > > LINUX_VERSION-3.18 = .71 > > LINUX_VERSION-4.4 = .121 > > -LINUX_VERSION-4.9 = .96 > > +LINUX_VERSION-4.9 = .98 > > LINUX_VERSION-4.14 = .37 > > LINUX_KERNEL_HASH-3.18.71 = > 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 > > LINUX_KERNEL_HASH-4.4.121 = > 44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729 > > -LINUX_KERNEL_HASH-4.9.96 = > 826f596eb5197f8b17304649c2990dd7b766f5c79076cae79f4261c40cea877f > > +LINUX_KERNEL_HASH-4.9.98 = > 12cd90355adbc946e7e95aa5cdef2dd99b8e166cb64fe53a91c3e1d8f81810ef > > LINUX_KERNEL_HASH-4.14.37 = > 8197e7ed3620713e412905430a7bf93e2048384042ffba189a66f0eeb6908e92 > > remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1 > > diff --git a/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch > b/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch > > index 67ed3e494a..639f09709b 100644 > > --- a/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch > > +++ b/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch > > @@ -37,7 +37,7 @@ > > #define AR7_IRQ_UART0 15 > > --- a/arch/mips/Kconfig > > +++ b/arch/mips/Kconfig > > -@@ -160,7 +160,7 @@ config AR7 > > +@@ -161,7 +161,7 @@ config AR7 > > select HAVE_CLK > > help > > Support for the Texas Instruments AR7 System-on-a-Chip > > @@ -46,7 +46,7 @@ > > config ATH25 > > bool "Atheros AR231x/AR531x SoC support" > > -@@ -1004,6 +1004,7 @@ config MIPS_PARAVIRT > > +@@ -1005,6 +1005,7 @@ config MIPS_PARAVIRT > > endchoice > > source "arch/mips/alchemy/Kconfig" > > diff --git > a/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch > > b/target/linux/ar71xx/patches-4.9/403-mtd_fix_cf
[LEDE-DEV] [PATCH] kernel: bump to 4.9.98
et/linux/mpc85xx/patches-4.9/102-powerpc-add-cmdline-override.patch b/target/linux/mpc85xx/patches-4.9/102-powerpc-add-cmdline-override.patch index c70ac1bb9d..55976c32b1 100644 --- a/target/linux/mpc85xx/patches-4.9/102-powerpc-add-cmdline-override.patch +++ b/target/linux/mpc85xx/patches-4.9/102-powerpc-add-cmdline-override.patch @@ -17,7 +17,7 @@ help --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c -@@ -1079,6 +1079,17 @@ int __init early_init_dt_scan_chosen(uns +@@ -1082,6 +1082,17 @@ int __init early_init_dt_scan_chosen(uns if (p != NULL && l > 0) strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE)); -- 2.15.1 (Apple Git-101) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] dnsmasq: bump to 2.80test2
NULL, result);
+ }
+
+ if (status == STAT_SECURE)
+@@ -1948,7 +1961,7 @@ unsigned char *tcp_request(int confd, ti
+ if (status == STAT_BOGUS && extract_request(header,
m, daemon->namebuff, NULL))
+ domain = daemon->namebuff;
+
+-log_query(F_KEYTAG | F_SECSTAT, domain, NULL, result);
++log_query(F_SECSTAT, domain, NULL, result);
+
+ if (status == STAT_BOGUS)
+ {
+--- a/src/rfc1035.c
b/src/rfc1035.c
+@@ -926,12 +926,11 @@ unsigned int extract_request(struct dns_
+ return F_QUERY;
+ }
+
+-
+ size_t setup_reply(struct dns_header *header, size_t qlen,
+ struct all_addr *addrp, unsigned int flags, unsigned long ttl)
+ {
+ unsigned char *p;
+-
++
+ if (!(p = skip_questions(header, qlen)))
+ return 0;
+
+@@ -948,7 +947,12 @@ size_t setup_reply(struct dns_header *he
+ else if (flags == F_NXDOMAIN)
+ SET_RCODE(header, NXDOMAIN);
+ else if (flags == F_SERVFAIL)
+-SET_RCODE(header, SERVFAIL);
++{
++ struct all_addr a;
++ a.addr.rcode.rcode = SERVFAIL;
++ log_query(F_CONFIG | F_RCODE, "error", &a, NULL);
++ SET_RCODE(header, SERVFAIL);
++}
+ else if (flags == F_IPV4)
+ { /* we know the address */
+ SET_RCODE(header, NOERROR);
+@@ -966,8 +970,13 @@ size_t setup_reply(struct dns_header *he
+ }
+ #endif
+ else /* nowhere to forward to */
+-SET_RCODE(header, REFUSED);
+-
++{
++ struct all_addr a;
++ a.addr.rcode.rcode = REFUSED;
++ log_query(F_CONFIG | F_RCODE, "error", &a, NULL);
++ SET_RCODE(header, REFUSED);
++}
++
+ return p - (unsigned char *)header;
+ }
+
diff --git a/package/network/services/dnsmasq/patches/240-ubus.patch
b/package/network/services/dnsmasq/patches/240-ubus.patch
index 415c7a5e4c..318b13110d 100644
--- a/package/network/services/dnsmasq/patches/240-ubus.patch
+++ b/package/network/services/dnsmasq/patches/240-ubus.patch
@@ -74,7 +74,7 @@
int main (int argc, char **argv)
{
int bind_fallback = 0;
-@@ -928,6 +988,7 @@ int main (int argc, char **argv)
+@@ -931,6 +991,7 @@ int main (int argc, char **argv)
set_dbus_listeners();
#endif
@@ -82,7 +82,7 @@
#ifdef HAVE_DHCP
if (daemon->dhcp || daemon->relay4)
{
-@@ -1058,6 +1119,8 @@ int main (int argc, char **argv)
+@@ -1061,6 +1122,8 @@ int main (int argc, char **argv)
check_dbus_listeners();
#endif
@@ -104,7 +104,7 @@
mostly_clean :
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
-@@ -1415,6 +1415,8 @@ void emit_dbus_signal(int action, struct
+@@ -1421,6 +1421,8 @@ void emit_dbus_signal(int action, struct
# endif
#endif
@@ -115,7 +115,7 @@
void ipset_init(void);
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
-@@ -1621,6 +1621,10 @@ static void log_packet(char *type, void
+@@ -1636,6 +1636,10 @@ static void log_packet(char *type, void
daemon->namebuff,
string ? string : "",
err ? err : "");
--
2.15.1 (Apple Git-101)
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] igmpproxy: bump to 0.2.1
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On 7 May 2018, at 09:34, John Crispin wrote: > > Hi Kevin, > > apparently you have a 10->11 patch in your tree that needs to be applied > prior to the 11->12 update > > John Oh :-( That means https://github.com/openwrt/openwrt/pull/828 still hasn’t been applied. Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] cake: bump to 20180504 bake
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Cake is bearing fruits of kernel upstreaming efforts. diffserv-llt dropped. DSCP mapping paper died and no one using it. ack-filter re-written & simplified tc userspace & cake kmod netlink interface usage changed in non backwards compatible way, thus this once requires tc & cake to be in-step. Change due to upstream requirements. Signed-off-by: Kevin Darbyshire-Bryant --- package/kernel/kmod-sched-cake/Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/package/kernel/kmod-sched-cake/Makefile b/package/kernel/kmod-sched-cake/Makefile index 2156eee0e4..fe5e2acd50 100644 --- a/package/kernel/kmod-sched-cake/Makefile +++ b/package/kernel/kmod-sched-cake/Makefile @@ -13,9 +13,10 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL:=https://github.com/dtaht/sch_cake.git -PKG_SOURCE_DATE:=2018-03-19 -PKG_SOURCE_VERSION:=0afc1bee4e9fc5d75668cb10254ab5d2d02f0098 -PKG_MIRROR_HASH:=b8ac95753d05ff602282ed5a799f9c953f60decebc5720ee8f0101344a5acfc4 +PKG_SOURCE_DATE:=2018-05-04 +PKG_SOURCE_VERSION:=e848241cda393fe1fa643156bcdbe81764bfe060 +PKG_MIRROR_HASH:=70fd1f79dcdf39e47957fa6684a1a41c1b50f51896781bea0d27bc9e8ff057ab +PKG_MAINTAINER:=Kevin Darbyshire-Bryant include $(INCLUDE_DIR)/package.mk -- 2.15.1 (Apple Git-101) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] iproute2: import latest cake
f, "\n"); -+ }; -+ -+ fprintf(f, " thresh "); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12s", sprint_rate(tst->threshold_rate, b1)); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " target "); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12s", sprint_time(tst->target_us, b1)); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " interval"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12s", sprint_time(tst->interval_us, b1)); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " pk_delay"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12s", sprint_time(tst->peak_delay_us, b1)); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " av_delay"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12s", sprint_time(tst->avge_delay_us, b1)); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " sp_delay"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12s", sprint_time(tst->base_delay_us, b1)); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " pkts"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->sent.packets); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " bytes "); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12llu", tst->sent.bytes); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " way_inds"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->way_indirect_hits); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " way_miss"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->way_misses); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " way_cols"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->way_collisions); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " drops "); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->dropped.packets); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " marks "); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->ecn_marked.packets); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " ack_drop"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->ack_drops.packets); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " sp_flows"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->sparse_flows); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " bk_flows"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->bulk_flows); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " un_flows"); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->unresponse_flows); -+ fprintf(f, "\n"); -+ -+ fprintf(f, " max_len "); -+ FOR_EACH_TIN(stnc, tst, i) -+ fprintf(f, " %12u", tst->max_skblen); -+ fprintf(f, "\n"); ++ default: ++ fprintf(f, " &qu
[LEDE-DEV] [PATCH 0/2] bump cake support in iproute2 & kmod
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Bearing fruits of attempting to get cake upstream, a few changes most importantly to the netlink messaging for cake such that it's no longer backwards compatible, hence bumping iproute2's tc cake support and the cake module itself at the same time. Kevin Darbyshire-Bryant (2): iproute2: import latest cake cake: bump to 20180504 bake package/kernel/kmod-sched-cake/Makefile| 7 +- package/network/utils/iproute2/Makefile| 2 +- .../iproute2/patches/950-add-cake-to-tc.patch | 869 ++--- 3 files changed, 429 insertions(+), 449 deletions(-) -- 2.15.1 (Apple Git-101) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] iproute2: backport json_print-fix-hidden-64-bit-type-promotion
print_u64(PRINT_JSON,
+ "missed_errors",
+ NULL, s->rx_missed_errors);
+ if (s->rx_nohandler)
+- print_uint(PRINT_JSON,
++ print_u64(PRINT_JSON,
+ "nohandler", NULL, s->rx_nohandler);
+ }
+ close_json_object();
+
+ /* TX stats */
+ open_json_object("tx");
+- print_uint(PRINT_JSON, "bytes", NULL, s->tx_bytes);
+- print_uint(PRINT_JSON, "packets", NULL, s->tx_packets);
+- print_uint(PRINT_JSON, "errors", NULL, s->tx_errors);
+- print_uint(PRINT_JSON, "dropped", NULL, s->tx_dropped);
+- print_uint(PRINT_JSON,
++ print_u64(PRINT_JSON, "bytes", NULL, s->tx_bytes);
++ print_u64(PRINT_JSON, "packets", NULL, s->tx_packets);
++ print_u64(PRINT_JSON, "errors", NULL, s->tx_errors);
++ print_u64(PRINT_JSON, "dropped", NULL, s->tx_dropped);
++ print_u64(PRINT_JSON,
+ "carrier_errors",
+ NULL, s->tx_carrier_errors);
+- print_uint(PRINT_JSON, "collisions", NULL, s->collisions);
++ print_u64(PRINT_JSON, "collisions", NULL, s->collisions);
+ if (s->tx_compressed)
+ print_uint(PRINT_JSON,
+ "compressed",
+@@ -653,20 +653,20 @@ static void print_link_stats64(FILE *fp,
+
+ /* TX error stats */
+ if (show_stats > 1) {
+- print_uint(PRINT_JSON,
++ print_u64(PRINT_JSON,
+ "aborted_errors",
+ NULL, s->tx_aborted_errors);
+- print_uint(PRINT_JSON,
++ print_u64(PRINT_JSON,
+ "fifo_errors",
+ NULL, s->tx_fifo_errors);
+- print_uint(PRINT_JSON,
++ print_u64(PRINT_JSON,
+ "window_errors",
+ NULL, s->tx_window_errors);
+- print_uint(PRINT_JSON,
++ print_u64(PRINT_JSON,
+ "heartbeat_errors",
+ NULL, s->tx_heartbeat_errors);
+ if (carrier_changes)
+- print_uint(PRINT_JSON, "carrier_changes", NULL,
++ print_u64(PRINT_JSON, "carrier_changes", NULL,
+ rta_getattr_u32(carrier_changes));
+ }
+ close_json_object();
+--- a/lib/json_print.c
b/lib/json_print.c
+@@ -117,8 +117,10 @@ void close_json_array(enum output_type t
+ } \
+ }
+ _PRINT_FUNC(int, int);
++_PRINT_FUNC(s64, int64_t);
+ _PRINT_FUNC(hu, unsigned short);
+-_PRINT_FUNC(uint, uint64_t);
++_PRINT_FUNC(uint, unsigned int);
++_PRINT_FUNC(u64, uint64_t);
+ _PRINT_FUNC(lluint, unsigned long long int);
+ _PRINT_FUNC(float, double);
+ #undef _PRINT_FUNC
+--- a/lib/json_writer.c
b/lib/json_writer.c
+@@ -215,7 +215,12 @@ void jsonw_hu(json_writer_t *self, unsig
+ jsonw_printf(self, "%hu", num);
+ }
+
+-void jsonw_uint(json_writer_t *self, uint64_t num)
++void jsonw_uint(json_writer_t *self, unsigned int num)
++{
++ jsonw_printf(self, "%u", num);
++}
++
++void jsonw_u64(json_writer_t *self, uint64_t num)
+ {
+ jsonw_printf(self, "%"PRIu64, num);
+ }
+@@ -225,7 +230,12 @@ void jsonw_lluint(json_writer_t *self, u
+ jsonw_printf(self, "%llu", num);
+ }
+
+-void jsonw_int(json_writer_t *self, int64_t num)
++void jsonw_int(json_writer_t *self, int num)
++{
++ jsonw_printf(self, "%d", num);
++}
++
++void jsonw_s64(json_writer_t *self, int64_t num)
+ {
+ jsonw_printf(self, "%"PRId64, num);
+ }
+@@ -258,12 +268,18 @@ void jsonw_float_field_fmt(json_writer_t
+ jsonw_float_fmt(self, fmt, val);
+ }
+
+-void jsonw_uint_field(json_writer_t *self, const char *prop, uint64_t num)
++void jsonw_uint_field(json_writer_t *self, const char *prop, unsigned int num)
+ {
+ jsonw_name(self, prop);
+ jsonw_uint(self, num);
+ }
+
++void jsonw_u64_field(json_writer_t *self, const char *prop, uint64_t num)
++{
++ jsonw_name(self, prop);
++ jsonw_u64(self, num);
++}
++
+ void jsonw_hu_field(json_writer_t *self, cons
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi On Wed, 2 May 2018, Linus Walleij wrote: > On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin wrote: > > > I've prepared 4.14 branch here > > https://github.com/yeryomin/openwrt/commits/gemini-4.14 > > I think it can be merged in it's current state. The only problem I'm aware > > of is that usb is not fully working (afaik, Hans is working on it). > > I also think it should be merged as this, it will be a good base for > Hans to work on the USB stuff. I use vanilla kernel for testing The USB OTG protocol is complicated enough here, I must handle three different drivers in three different places. Hans Ulli --- End Message --- ___ 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
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi On Wed, 2 May 2018, Joel Wirāmu Pauling wrote: > It's Cortina but arm7 IIRC; there was a NDA available SDK for it based on > 2.6.something - which I started to go through the process of getting access > too a few years ago, but the platform was bought out by Realtek who > scuttled it as it was in competition with their own designs. > > The Almond+ has Zwave and Zigbee on PCI bus and Qualcomm AR9880 AC and N > radios, and a USB3 hub. Jtag fully exposed and there is even a Touchscreen > (which I think is I2C based). It would be a nice target to get working with > trunk. > Looking at wikidevi, this should be this one https://wikidevi.com/wiki/Securifi_Almond%2B There is also a spec datasheet on http://www.cortina-access.com/dhp/download/203/996/61 Hans Ulli --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kernel: bump 4.9 to 4.9.96
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Refresh patches, following required reworking: ar71xx/patches-4.9/930-chipidea-pullup.patch layerscape/patches-4.9/302-dts-support-layercape.patch sunxi/patches-4.9/0052-stmmac-form-4-12.patch Fixes for CVEs: CVE-2018-1108 CVE-2018-1092 Tested on: ar71xx Archer C7 v2 Signed-off-by: Kevin Darbyshire-Bryant --- include/kernel-version.mk | 4 +- .../patches-4.9/432-spi-rb4xx-spi-driver.patch | 2 +- .../patches-4.9/433-spi-rb4xx-cpld-driver.patch| 2 +- .../patches-4.9/435-spi-vsc7385_driver.patch | 2 +- .../patches-4.9/910-unaligned_access_hacks.patch | 4 +- .../ar71xx/patches-4.9/930-chipidea-pullup.patch | 6 +- target/linux/ath25/patches-4.9/130-watchdog.patch | 2 +- ...-detect-JEDEC-incompatible-w25q128-using-.patch | 2 +- ...-Mark-GPIO-clocks-enabled-at-boot-as-crit.patch | 2 +- ...-the-clocks-early-during-the-boot-process.patch | 4 +- ...oid-suspending-if-we-re-in-gadget-mode-18.patch | 2 +- ...port-rate-change-propagation-on-bcm2835-c.patch | 6 +- ...ow-rate-change-propagation-to-PLLH_AUX-on.patch | 2 +- ...-maybe-uninitialized-warning-in-bcm2835_c.patch | 2 +- ...-Don-t-rate-change-PLLs-on-behalf-of-DSI-.patch | 28 +-- ...m2835-Register-the-DSI0-DSI1-pixel-clocks.patch | 14 +- ...-Add-leaf-clock-measurement-support-disab.patch | 26 +-- ...2835-Mark-used-PLLs-and-dividers-CRITICAL.patch | 2 +- ...186-clk-bcm2835-Add-claim-clocks-property.patch | 14 +- .../brcm47xx/patches-4.9/831-old_gpio_wdt.patch| 2 +- .../050-usb-dwc2-Remove-unnecessary-kfree.patch| 2 +- .../090-net-generalize-napi_complete_done.patch| 4 +- .../linux/generic/hack-4.9/204-module_strip.patch | 4 +- .../linux/generic/hack-4.9/902-debloat_proc.patch | 2 +- ...x-wrong-comment-related-to-link-detection.patch | 4 +- ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 4 +- .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch | 30 +-- ...jecting-with-source-address-failed-policy.patch | 18 +- ...80-NET-skip-GRO-for-foreign-MAC-addresses.patch | 10 +- .../generic/pending-4.9/701-phy_extension.patch| 2 +- .../pending-4.9/890-uart_optional_sysrq.patch | 2 +- .../generic/pending-4.9/920-mangle_bootargs.patch | 4 +- ...eric-Mangle-bootloader-s-kernel-arguments.patch | 4 +- .../patches-4.9/0026-NET-multi-phy-support.patch | 6 +- ...ssc-add-support-for-Lantiq-SSC-SPI-contro.patch | 2 +- .../202-core-linux-support-layerscape.patch| 2 +- .../patches-4.9/301-arch-support-layerscape.patch | 2 +- .../patches-4.9/302-dts-support-layercape.patch| 8 +- .../401-mtd-spi-nor-support-layerscape.patch | 14 +- .../patches-4.9/703-phy-support-layerscape.patch | 18 +- .../803-cpufreq-support-layerscape.patch | 6 +- .../patches-4.9/812-mmc-layerscape-support.patch | 12 +- .../patches-4.9/813-qe-support-layerscape.patch| 2 +- .../sunxi/patches-4.9/0050-stmmac-form-4-10.patch | 140 ++-- .../sunxi/patches-4.9/0051-stmmac-form-4-11.patch | 56 ++--- .../sunxi/patches-4.9/0052-stmmac-form-4-12.patch | 242 + 46 files changed, 337 insertions(+), 391 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 3e9ddaa81e..9191bddc7d 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -4,12 +4,12 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .71 LINUX_VERSION-4.4 = .121 -LINUX_VERSION-4.9 = .91 +LINUX_VERSION-4.9 = .96 LINUX_VERSION-4.14 = .34 LINUX_KERNEL_HASH-3.18.71 = 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 LINUX_KERNEL_HASH-4.4.121 = 44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729 -LINUX_KERNEL_HASH-4.9.91 = 60caa752ec9fa1c426f6a2f37db3f268d0961b67a723b6443949112167b39832 +LINUX_KERNEL_HASH-4.9.96 = 826f596eb5197f8b17304649c2990dd7b766f5c79076cae79f4261c40cea877f LINUX_KERNEL_HASH-4.14.34 = 782b6c4c85275c382c820e1934d3e6003ef468f43cfc5e7c22bc07c331a12bb9 remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1 diff --git a/target/linux/ar71xx/patches-4.9/432-spi-rb4xx-spi-driver.patch b/target/linux/ar71xx/patches-4.9/432-spi-rb4xx-spi-driver.patch index 5428d3d1c2..e896d0bdf4 100644 --- a/target/linux/ar71xx/patches-4.9/432-spi-rb4xx-spi-driver.patch +++ b/target/linux/ar71xx/patches-4.9/432-spi-rb4xx-spi-driver.patch @@ -1,6 +1,6 @@ --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig -@@ -534,6 +534,12 @@ config SPI_QUP +@@ -533,6 +533,12 @@ config SPI_QUP This driver can also be built as a module. If so, the module will be called spi_qup. diff --git a/target/linux/ar71xx/patches-4.9/433-spi-rb4xx-cpld-d
[LEDE-DEV] [PATCH] iftop: bump to latest
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Choose first running interface, rather than first "up" interface (Redhat #1403025) Signed-off-by: Kevin Darbyshire-Bryant --- package/network/utils/iftop/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/network/utils/iftop/Makefile b/package/network/utils/iftop/Makefile index 8c5b47444f..ed22eb81b1 100644 --- a/package/network/utils/iftop/Makefile +++ b/package/network/utils/iftop/Makefile @@ -12,9 +12,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL:=https://code.blinkace.com/pdw/iftop.git -PKG_SOURCE_DATE:=2017-02-06 -PKG_SOURCE_VERSION:=35af3cf65f17961d173b31fd3b00166ec095c226 -PKG_MIRROR_HASH:=84131e2448ea5aa884d2bd7d58dc81741b5c476b4664a8c2c1eb34f62985804a +PKG_SOURCE_DATE:=2017-03-22 +PKG_SOURCE_VERSION:=949ed0f7e2c54c598868c270b82c2d702131a339 +PKG_MIRROR_HASH:=2ba96d9a2adf4e43aaab439a9ccab8f21b415da48d1c8939f6dcea8e6e11524f PKG_MAINTAINER:=Jo-Philipp Wich PKG_LICENSE:=GPL-2.0 -- 2.15.1 (Apple Git-101) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] igmpproxy: bump to 0.2.1
e.c
-@@ -428,6 +428,25 @@ void ageActiveRoutes() {
- }
-
- /**
-+* Counts the number of interfaces a given route is active on
-+*/
-+int numberOfInterfaces(struct RouteTable *croute) {
-+int Ix;
-+struct IfDesc *Dp;
-+int result = 0;
-+// Loop through all interfaces
-+for ( Ix = 0; (Dp = getIfByIx(Ix)); Ix++ ) {
-+// If the interface is used by the route, increase counter
-+if(BIT_TST(croute->vifBits, Dp->index)) {
-+result++;
-+}
-+}
-+my_log(LOG_DEBUG, 0, "counted %d interfaces", result);
-+return result;
-+}
-+
-+
-+/**
- * Should be called when a leave message is recieved, to
- * mark a route for the last member probe state.
- */
-@@ -439,8 +458,11 @@ void setRouteLastMemberMode(uint32_t gro
- if(croute!=NULL) {
- // Check for fast leave mode...
- if(croute->upstrState == ROUTESTATE_JOINED &&
conf->fastUpstreamLeave) {
--// Send a leave message right away..
--sendJoinLeaveUpstream(croute, 0);
-+// Send a leave message right away only when the route has been
active on only one interface
-+if (numberOfInterfaces(croute) <= 1) {
-+ my_log(LOG_DEBUG, 0, "Leaving group %d now", group);
-+sendJoinLeaveUpstream(croute, 0);
-+}
- }
- // Set the routingstate to Last member check...
- croute->upstrState = ROUTESTATE_CHECK_LAST_MEMBER;
-@@ -677,3 +699,18 @@ void logRouteTable(char *header) {
-
- my_log(LOG_DEBUG, 0,
"-");
- }
-+
-+/**
-+* Returns true when the given group belongs to the given interface
-+*/
-+int interfaceInRoute(int32_t group, int Ix) {
-+struct RouteTable* croute;
-+croute = findRoute(group);
-+if (croute != NULL) {
-+my_log(LOG_DEBUG, 0, "Interface id %d is in group $d", Ix, group);
-+return BIT_TST(croute->vifBits, Ix);
-+} else {
-+return 0;
-+}
-+}
-+
--
2.15.1 (Apple Git-101)
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kernel: bump 4.9 to 4.9.95
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Refresh patches, following required reworking: ar71xx/patches-4.9/930-chipidea-pullup.patch layerscape/patches-4.9/302-dts-support-layercape.patch sunxi/patches-4.9/0052-stmmac-form-4-12.patch Tested on: ar71xx Archer C7 v2 Signed-off-by: Kevin Darbyshire-Bryant --- include/kernel-version.mk | 4 +- .../patches-4.9/432-spi-rb4xx-spi-driver.patch | 2 +- .../patches-4.9/433-spi-rb4xx-cpld-driver.patch| 2 +- .../patches-4.9/435-spi-vsc7385_driver.patch | 2 +- .../patches-4.9/910-unaligned_access_hacks.patch | 4 +- .../ar71xx/patches-4.9/930-chipidea-pullup.patch | 6 +- target/linux/ath25/patches-4.9/130-watchdog.patch | 2 +- ...-detect-JEDEC-incompatible-w25q128-using-.patch | 2 +- ...oid-suspending-if-we-re-in-gadget-mode-18.patch | 2 +- .../400-mtd-bcm47xxpart-get-nvram.patch| 2 +- .../brcm47xx/patches-4.9/831-old_gpio_wdt.patch| 2 +- .../050-usb-dwc2-Remove-unnecessary-kfree.patch| 2 +- .../090-net-generalize-napi_complete_done.patch| 4 +- .../linux/generic/hack-4.9/204-module_strip.patch | 4 +- .../linux/generic/hack-4.9/902-debloat_proc.patch | 2 +- ...x-wrong-comment-related-to-link-detection.patch | 4 +- .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch | 30 +-- ...jecting-with-source-address-failed-policy.patch | 18 +- ...80-NET-skip-GRO-for-foreign-MAC-addresses.patch | 10 +- .../generic/pending-4.9/701-phy_extension.patch| 2 +- .../pending-4.9/890-uart_optional_sysrq.patch | 2 +- .../generic/pending-4.9/920-mangle_bootargs.patch | 4 +- ...eric-Mangle-bootloader-s-kernel-arguments.patch | 4 +- .../patches-4.9/0026-NET-multi-phy-support.patch | 6 +- ...ssc-add-support-for-Lantiq-SSC-SPI-contro.patch | 2 +- .../202-core-linux-support-layerscape.patch| 2 +- .../patches-4.9/301-arch-support-layerscape.patch | 2 +- .../patches-4.9/302-dts-support-layercape.patch| 8 +- .../401-mtd-spi-nor-support-layerscape.patch | 14 +- .../patches-4.9/703-phy-support-layerscape.patch | 18 +- .../803-cpufreq-support-layerscape.patch | 6 +- .../patches-4.9/812-mmc-layerscape-support.patch | 12 +- .../patches-4.9/813-qe-support-layerscape.patch| 2 +- .../sunxi/patches-4.9/0050-stmmac-form-4-10.patch | 140 ++-- .../sunxi/patches-4.9/0051-stmmac-form-4-11.patch | 56 ++--- .../sunxi/patches-4.9/0052-stmmac-form-4-12.patch | 242 + 36 files changed, 286 insertions(+), 340 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 3e9ddaa81e..17219f6c3f 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -4,12 +4,12 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .71 LINUX_VERSION-4.4 = .121 -LINUX_VERSION-4.9 = .91 +LINUX_VERSION-4.9 = .95 LINUX_VERSION-4.14 = .34 LINUX_KERNEL_HASH-3.18.71 = 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 LINUX_KERNEL_HASH-4.4.121 = 44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729 -LINUX_KERNEL_HASH-4.9.91 = 60caa752ec9fa1c426f6a2f37db3f268d0961b67a723b6443949112167b39832 +LINUX_KERNEL_HASH-4.9.95 = 9e5a6d27c26d0f978c573449be34d9a3b984e9e6617d1b3f0498d06fb6319ff4 LINUX_KERNEL_HASH-4.14.34 = 782b6c4c85275c382c820e1934d3e6003ef468f43cfc5e7c22bc07c331a12bb9 remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1 diff --git a/target/linux/ar71xx/patches-4.9/432-spi-rb4xx-spi-driver.patch b/target/linux/ar71xx/patches-4.9/432-spi-rb4xx-spi-driver.patch index 5428d3d1c2..e896d0bdf4 100644 --- a/target/linux/ar71xx/patches-4.9/432-spi-rb4xx-spi-driver.patch +++ b/target/linux/ar71xx/patches-4.9/432-spi-rb4xx-spi-driver.patch @@ -1,6 +1,6 @@ --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig -@@ -534,6 +534,12 @@ config SPI_QUP +@@ -533,6 +533,12 @@ config SPI_QUP This driver can also be built as a module. If so, the module will be called spi_qup. diff --git a/target/linux/ar71xx/patches-4.9/433-spi-rb4xx-cpld-driver.patch b/target/linux/ar71xx/patches-4.9/433-spi-rb4xx-cpld-driver.patch index b1cd6a545b..c44acab32e 100644 --- a/target/linux/ar71xx/patches-4.9/433-spi-rb4xx-cpld-driver.patch +++ b/target/linux/ar71xx/patches-4.9/433-spi-rb4xx-cpld-driver.patch @@ -1,6 +1,6 @@ --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig -@@ -762,6 +762,13 @@ config SPI_TLE62X0 +@@ -761,6 +761,13 @@ config SPI_TLE62X0 sysfs interface, with each line presented as a kind of GPIO exposing both switch control and diagnostic feedback. diff --git a/target/linux/ar71xx/patches-4.9/435-spi-vsc7385_driver.patch b/target/linux/ar71xx/patches-4.9/435-
[LEDE-DEV] [PATCH] wireguard: bump to 20180420
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- 7cc2668 version: bump snapshot 860c7c7 poly1305: do not place constants in different sections 5f1e4ca compat: remove unused dev_recursion_level backport 7e4b991 blake2s: remove unused helper 13225fc send: simplify skb_padding with nice macro a1525bf send: account for route-based MTU bbb2fde wg-quick: account for specified fwmark in auto routing mode c452105 qemu: bump default version dbe5223 version: bump snapshot 1d3ef31 chacha20poly1305: put magic constant behind macro cdc164c chacha20poly1305: add self tests from wycheproof 1060e54 curve25519: add self tests from wycheproof 0e1e127 wg-quick.8: fix typo 2b06b8e curve25519: precomp const correctness 8102664 curve25519: memzero in batches 1f54c43 curve25519: use cmov instead of xor for cswap fa5326f curve25519: use precomp implementation instead of sandy2x 9b19328 compat: support OpenSUSE 15 3102d28 compat: silence warning on frankenkernels 8f64c61 compat: stable kernels are now receiving b87b619 62127f9 wg-quick: hide errors on save Signed-off-by: Kevin Darbyshire-Bryant --- package/network/services/wireguard/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/network/services/wireguard/Makefile b/package/network/services/wireguard/Makefile index ba9fafa87f..9ed24ecaa3 100644 --- a/package/network/services/wireguard/Makefile +++ b/package/network/services/wireguard/Makefile @@ -11,12 +11,12 @@ include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=wireguard -PKG_VERSION:=0.0.20180304 +PKG_VERSION:=0.0.20180420 PKG_RELEASE:=1 PKG_SOURCE:=WireGuard-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=https://git.zx2c4.com/WireGuard/snapshot/ -PKG_HASH:=efb1652f0da67fb2731040439b6abb820a5e2f1bc177aa15c5dce68ea3327787 +PKG_HASH:=b58cd2acf9e8d3fe9044c06c0056bd74da1f5673a456f011d36eee3f6fb1da16 PKG_LICENSE:=GPL-2.0 Apache-2.0 PKG_LICENSE_FILES:=COPYING -- 2.15.1 (Apple Git-101) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Roman
On Tue, 10 Apr 2018, Linus Walleij wrote:
> On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin wrote:
>
> > I have tested them quickly yesterday on nas4220b board. Although I've
> > managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> > And I didn't check anything else.
> > I didn't yet look at the code but before I dive there I have a question: did
> > you have a chance to test it yourself on any of the boards? And if yes,
> > which one?
>
I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself
>From 10be6c15addac0bdb9c2d196d450aee1fcb2070b Mon Sep 17 00:00:00 2001
From: Hans Ulli Kroll
Date: Sat, 14 Apr 2018 19:13:11 +0200
Subject: [PATCH] gemini: fix fotg2 stall after port reset
Signed-off-by: Hans Ulli Kroll
---
...b-host-fotg2-restart-hcd-after-port-reset.patch | 31 ++
1 file changed, 31 insertions(+)
create mode 100644
target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch
diff --git
a/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch
b/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch
new file mode 100644
index 00..3f1de0d107
--- /dev/null
+++
b/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch
@@ -0,0 +1,31 @@
+From 731a2896e11b4e6a8d252e6c14edb1b09dbfcd46 Mon Sep 17 00:00:00 2001
+From: Hans Ulli Kroll
+Date: Sat, 14 Apr 2018 18:49:57 +0200
+Subject: [PATCH 1/2] usb: host: fotg2: restart hcd after port reset
+
+on Gemini SoC FOTG2 stalls after port reset
+rerstart the hcd.
+
+Signed-off-by: Hans Ulli Kroll
+---
+ drivers/usb/host/fotg210-hcd.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
+ /* see what we found out */
+ temp = check_reset_complete(fotg210, wIndex, status_reg,
+ fotg210_readl(fotg210, status_reg));
++
++ /* restart schedule */
++ fotg210->command |= CMD_RUN;
++ fotg210_writel(fotg210, fotg210->command,
&fotg210->regs->command);
+ }
+
+ if (!(temp & (PORT_RESUME|PORT_RESET))) {
+--
+2.16.2
+
--
2.16.2
I have some other patch here which disable the resume after
usb_hcd_resume_root_hub()
But this make no sence to me.
Greetings
Hans Ulli Kroll
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] Revert "iproute2: fix hidden uint to uin64_t promotion in json_print"
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- This reverts commit 745d0e7f4b6e8659cc967291acd33889035127f0. It looks like upstream don't want the patch so let's revert it here too. I hope a fix from upstream is forthcoming. Signed-off-by: Kevin Darbyshire-Bryant --- package/network/utils/iproute2/Makefile| 2 +- ...x-hidden-uint-to-uin64_t-promottion-in-js.patch | 65 -- 2 files changed, 1 insertion(+), 66 deletions(-) delete mode 100644 package/network/utils/iproute2/patches/910-iproute2-fix-hidden-uint-to-uin64_t-promottion-in-js.patch diff --git a/package/network/utils/iproute2/Makefile b/package/network/utils/iproute2/Makefile index d8ff5e590d..ef4befaeda 100644 --- a/package/network/utils/iproute2/Makefile +++ b/package/network/utils/iproute2/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=iproute2 PKG_VERSION:=4.15.0 -PKG_RELEASE:=2 +PKG_RELEASE:=3 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@KERNEL/linux/utils/net/iproute2 diff --git a/package/network/utils/iproute2/patches/910-iproute2-fix-hidden-uint-to-uin64_t-promottion-in-js.patch b/package/network/utils/iproute2/patches/910-iproute2-fix-hidden-uint-to-uin64_t-promottion-in-js.patch deleted file mode 100644 index a549770045..00 --- a/package/network/utils/iproute2/patches/910-iproute2-fix-hidden-uint-to-uin64_t-promottion-in-js.patch +++ /dev/null @@ -1,65 +0,0 @@ -From e1c6b35f9f978f6919e8bf651de67b30dc145543 Mon Sep 17 00:00:00 2001 -From: Kevin Darbyshire-Bryant -Date: Sun, 18 Mar 2018 08:51:08 + -Subject: [PATCH] iproute2: fix hidden uint to uin64_t promotion in json_print - -print_int used 'int' type internally, whereas print_uint used 'uint64_t' - -These helper functions eventually call vfprintf(fp, fmt, args) which is -a variable argument list function and is dependent upon 'fmt' containing -correct information about the length of the passed arguments. - -Unfortunately print_int v print_uint offered no clue to the programmer -that internally passed ints to print_uint were being promoted to 64bits, -thus the format passed in 'fmt' string vs the actual passed integer -could be different lengths. This is even more interesting on big endian -architectures where 'vfprintf' would be looking in the middle of an -int64 type. Symptoms of this included tc qdisc showing bizarre values -for a variety of fields across a variety of qdiscs (e.g. refcnt, flows, -quantum) - -print_u/int now stick with native int size. - -A similar patch has been sent upstream. - -Fixes FS#1425 - -Signed-off-by: Kevin Darbyshire-Bryant - include/json_print.h | 2 +- - lib/json_print.c | 2 +- - 2 files changed, 2 insertions(+), 2 deletions(-) - -diff --git a/include/json_print.h b/include/json_print.h -index dc4d2bb3..350d35cb 100644 a/include/json_print.h -+++ b/include/json_print.h -@@ -56,10 +56,10 @@ void close_json_array(enum output_type type, const char *delim); - print_color_##type_name(t, COLOR_NONE, key, fmt, value); \ - } - _PRINT_FUNC(int, int); -+_PRINT_FUNC(uint, unsigned int); - _PRINT_FUNC(bool, bool); - _PRINT_FUNC(null, const char*); - _PRINT_FUNC(string, const char*); --_PRINT_FUNC(uint, uint64_t); - _PRINT_FUNC(hu, unsigned short); - _PRINT_FUNC(hex, unsigned int); - _PRINT_FUNC(0xhex, unsigned int); -diff --git a/lib/json_print.c b/lib/json_print.c -index aa527af6..ae3a317d 100644 a/lib/json_print.c -+++ b/lib/json_print.c -@@ -117,8 +117,8 @@ void close_json_array(enum output_type type, const char *str) - } \ - } - _PRINT_FUNC(int, int); -+_PRINT_FUNC(uint, unsigned int); - _PRINT_FUNC(hu, unsigned short); --_PRINT_FUNC(uint, uint64_t); - _PRINT_FUNC(lluint, unsigned long long int); - #undef _PRINT_FUNC - --- -2.14.3 (Apple Git-98) - -- 2.15.1 (Apple Git-101) --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Duplicates in bind subpackages?
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Sun, Mar 25, 2018 at 02:24:57PM -0600, Philip Prindeville wrote: > Collected errors: > * check_data_file_clashes: Package bind-check wants to install file > /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkconf > But that file is already provided by package * bind-tools > * check_data_file_clashes: Package bind-check wants to install file > /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkzone > But that file is already provided by package * bind-tools > * opkg_install_cmd: Cannot install package bind-check. > * check_data_file_clashes: Package bind-dig wants to install file > /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/bin/dig > But that file is already provided by package * bind-tools > * opkg_install_cmd: Cannot install package bind-dig. > package/Makefile:65: recipe for target 'package/install’ failed Yeah, the intent is that the bind-tools package is a single package that includes all the tools, while packages such as bind-dig only contain a single specific tool. In theory bind-tools could be replaced by an empty package that simply declares dependencies on all the other tool packages. I'm not sure when this configuration was originally introduced; it's been present since before I was involved in maintaining the packages. It always felt a little odd to me, but never so much so that I felt compelled to remove it. I'm happy to consider doing so if people feel strongly about it. noah signature.asc Description: PGP signature --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] New nagging message in Flash Operations page
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > Well, my answer is: "of course I have customs files and certificates, > otherwise why would I use OpenWrt in the first place and NO, THANK YOU! I > will not perform a factory reset otherwise I will loose all of my nice > customizations". > > Is there any particular reason for this new message appearing? Is there a > new substantial change in the configuration files? If you import a backup then there will only be a reboot and not a implicit factory reset before configuration import. So if you have more then one router with different setups (configuration) and you import a configuration from one router to the other router, then the two configuration are merged! That means files that are not changed by the import will remain on the system. https://github.com/openwrt/luci/commit/10fbf9b2e45c8b723c4c5d58a9183a55715f3d04#diff-2001317459acbc977a3d9c4b6e6b25f1 I think this is not what you want! --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH v1 1/1] openssh: disable passwords for openssh server
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Just enthusiast users 2 cents.. I'm also in favour of staying/keep using passwordless login as default behaviour, even for openssh. We can not stop _all_ of the bad things a user _might_ do... As per default OpenWrt also doesn't allow much anything from WAN side etc to keep that covered too... More involved user can still do whatever they wish with their OpenWrt installations or compiletime or so on... -- Sami Olmari On Sat, Feb 17, 2018 at 3:53 PM, Karl Palsson wrote: > > Philip Prindeville wrote: >> >> >> In a perfect world, no one should ever have to build with >> patches, anything in files/, cherry-picked commits, etc. >> Everything would be expressed in the .config (or >> kernel-config). > > I think this is probably the root of all the discussion. I agree > with you that most people shouldn't want patches, but I think > it's rather silly to say that it should all be via .config. > Putting things in files/ is vastly easier and more flexible than > trying to create something for everyone in makefile and kconfig > syntax! > > I'd generally rather see a lot _less_ of things created via an > ever expanding .config and _more_ local customizations applied as > local customizations :) > > Cheers, > Karl Palsson > > > ___ > openwrt-devel mailing list > openwrt-de...@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Latest OpenWRT on Gemini v4.14
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Hauke
On Tue, 27 Feb 2018, Hauke Mehrtens wrote:
> Hi Linus,
> [adding lede-dev]
>
> Nice work, for this patch and especially for upstreaming the code into
> mainline Linux.
>
> On 02/26/2018 09:28 PM, Linus Walleij wrote:
> > Hi,
> >
> > I have a forward-port hack-ish thing for Gemini,
> > this 500K patch on top of openwrt HEAD:
> >
> > https://dflund.se/~triad/krad/gemini/0001-gemini-Forward-port-to-v4.14.patch
> >
> > It's ... big ... and just kills off the old v4.4 kernel support.
>
> Are most of the patches for kernel 4.14 already in mainline or on its
> wait into the mainline kernel?
looking at the diffstat most of the patches are in mainline.
The MAC driver is from upcoming v4.16 kernel.
The only thing is missing is the "fix" for the USB driver.
The controller is a USB2 OTG device and we need (mostly) on gemini only
the hcd part. The udc/gadget driver is also mainline.
The missing part is only the otg device driver to bind this all together,
but this is should be a showstopper for to gemini port on OpenWRT.
And for the otg driver itself, I'm currently orking on this issue ...
> Someone said he wanted to look into the gemini target as it was still on
> kernel 4.4 and therefore on the list of targets which are getting removed.
>
> Can you please run "make kernel_oldconfig" to remove the unneeded
> configuration options for the config-4.14 file.
>
> And the also "make target/linux/{clean,refresh} V=99" to make the
> patches cleanly apply.
>
> > And I can't test it on the Raidsonic aka IcyBox
> > aka NAS4220B which is an important target.
>
For NAS4220 it's on my to do list ...
> Could someone with devices supported by this target please test this and
> report back if it is working or if there are any regressions.
>
> >
> > But it's something!
> >
> > It generates the image for it, maybe you can try it out
> > and see if it works for you.
> >
> > I think it should be straight forward to apply.
> >
> > It uses the "new style" of build rules, at least a bit, until
> > I got to the custom sysupgrade format etc.
> >
> > The D-Link images are not really complete but the rootfs
> > works.
> >
> > NB: IF YOU'RE GONNA USE THIS, USE GCC 7.3.0 TO
> > BUILD. The 5.5 toolchain doesn't work.
> >
> > Is there a way to require the 7.3.x toolchain?
>
> We want to use the same toolchain for all targets and a GCC bug on mips
> was just fixed 2 days ago in upstream GCC.
> I do not know if we will use gcc 7.X for the next release as this should
> happen soon.
>
Hans Ulli Kroll
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] How to enable the zImage and squashfs files, rather than packaged as 'bin' for sys upgrade
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- I have been using OpenWRT for years, and always created the zImage and squashfs files separately, as this allows me to use uboot to write these images separately. However, in the latest ‘git’ that I have done, and configured, the directory structure of the ‘bin’ directory seems to have changed, and only the images suitable for using ‘sys upgrade’ or the equivalent are to be found. My target is an mpc85xx + p1020. For example: Old path ‘bin/mpc85xx’ contents: drwxr-xr-x 10 jeclark2006 jeclark2006 4096 Jan 27 2017 packages -rw-r--r-- 1 jeclark2006 jeclark2006 6427003 Feb 16 12:56 kernel-debug.tar.bz2 -rw-r--r-- 1 jeclark2006 jeclark2006 2308783 Feb 16 12:56 openwrt-mpc85xx-p1020-zImage -rw-r--r-- 1 jeclark2006 jeclark2006 12348 Feb 16 12:56 openwrt-mpc85xx-p1020-p1010rdb-pa.fdt -rw-r--r-- 1 jeclark2006 jeclark2006 11469 Feb 16 12:56 openwrt-mpc85xx-p1020-tl-wdr4900-v1.fdt -rw-r--r-- 1 jeclark2006 jeclark2006 11596 Feb 16 12:56 openwrt-mpc85xx-p1020-p1020rdb.fdt -rw-r--r-- 1 jeclark2006 jeclark2006 29360132 Feb 16 12:59 openwrt-mpc85xx-p1020-root.squashfs -rw-r--r-- 1 jeclark2006 jeclark2006 750 Feb 16 12:59 md5sums -rw-r--r-- 1 jeclark2006 jeclark2006 1150 Feb 16 12:59 sha256sums -rw-r--r-- 1 jeclark2006 jeclark2006 64741013 Feb 16 13:01 OpenWrt-SDK-mpc85xx-p1020_gcc-5.3.0_musl-1.1.16.Linux-x86_64.tar.bz2 -rw-r--r-- 1 jeclark2006 jeclark2006 112060144 Feb 16 13:02 OpenWrt-ImageBuilder-mpc85xx-p1020.Linux-x86_64.tar.bz2 -rw-r--r-- 1 jeclark2006 jeclark2006 35540509 Feb 16 13:03 OpenWrt-Toolchain-mpc85xx-p1020_gcc-5.3.0_musl-1.1.16.Linux-x86_64.tar.bz2 New Path ‘bin/targets/mpc85xx/p1020’ contents: -rw-r--r-- 1 jeclark2006 jeclark2006 4181602 Feb 19 16:07 openwrt-mpc85xx-p1020-hiveap-330-initramfs-kernel.bin drwxr-xr-x 2 jeclark2006 jeclark2006 4096 Feb 19 17:15 packages -rw-r--r-- 1 jeclark2006 jeclark200611233 Feb 19 17:16 openwrt-mpc85xx-p1020-hiveap-330-squashfs-fdt.bin -rw-r--r-- 1 jeclark2006 jeclark2006 44527920 Feb 19 17:16 openwrt-mpc85xx-p1020-hiveap-330-squashfs-sysupgrade.bin -rw-r--r-- 1 jeclark2006 jeclark2006 2021 Feb 19 17:16 openwrt-mpc85xx-p1020-default.manifest -rw-r--r-- 1 jeclark2006 jeclark200614802 Feb 19 17:51 config.seed -rw-r--r-- 1 jeclark2006 jeclark2006 6501822 Feb 19 17:53 kernel-debug.tar.bz2 -rw-r--r-- 1 jeclark2006 jeclark2006 2021 Feb 19 17:53 openwrt-mpc85xx-p1020.manifest -rw-r--r-- 1 jeclark2006 jeclark2006 42946668 Feb 19 18:00 openwrt-sdk-mpc85xx-p1020_gcc-5.5.0_musl.Linux-x86_64.tar.xz -rw-r--r-- 1 jeclark2006 jeclark2006 32760948 Feb 19 18:03 openwrt-imagebuilder-mpc85xx-p1020.Linux-x86_64.tar.xz -rw-r--r-- 1 jeclark2006 jeclark2006 37120577 Feb 19 18:04 openwrt-toolchain-mpc85xx-p1020_gcc-5.5.0_musl.Linux-x86_64.tar.bz2 -rw-r--r-- 1 jeclark2006 jeclark2006 1108 Feb 19 18:04 sha256sums John Clark. --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] mtdsplit differences between ar71xx linux 4.4 and 4.9?
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi guys, I am currently in the process of porting a new device (https://wiki.openwrt.org/inbox/engenius/engenius_emr3000v2) over to OpenWRT. The issue I am facing is that mtdsplit works fine with kernel 4.4 [0.903158] m25p80 spi0.0: found s25fl256s1, expected m25p80 [0.908907] m25p80 spi0.0: s25fl256s1 (32768 Kbytes) [0.913994] 7 cmdlinepart partitions found on MTD device spi0.0 [0.919997] Creating 7 MTD partitions on "spi0.0": [0.924872] 0x-0x0004 : "u-boot" [0.931890] 0x0004-0x0005 : "u-boot-env" [0.938698] 0x0005-0x0006 : "art" [0.944885] 0x0006-0x001c : "kernel" [0.951259] 0x001c-0x01fb : "rootfs" [0.957707] mtd: device 4 (rootfs) set to be root filesystem [0.963597] 1 squashfs-split partitions found on MTD device rootfs [0.969875] 0x0044-0x01fb : "rootfs_data" [0.976779] 0x01fb-0x0200 : "config" [0.983224] 0x0006-0x01fb : "firmware" but fails with this on 4.9: [0.951402] m25p80 spi0.0: found s25fl256s1, expected m25p80 [0.957203] m25p80 spi0.0: s25fl256s1 (32768 Kbytes) [0.962266] 7 cmdlinepart partitions found on MTD device spi0.0 [0.968277] Creating 7 MTD partitions on "spi0.0": [0.973141] 0x-0x0004 : "u-boot" [0.979849] 0x0004-0x0005 : "u-boot-env" [0.986630] 0x0005-0x0006 : "art" [0.992712] 0x0006-0x001c : "kernel" [0.999136] 0x001c-0x01fb : "rootfs" [1.005551] mtd: device 4 (rootfs) set to be root filesystem [1.011311] mtdsplit: error occured while reading from "rootfs" [1.017348] 0x01fb-0x0200 : "config" [1.023717] 0x0006-0x01fb : "firmware" My patches are available at https://github.com/bk138/source/tree/emr3000-wip and prefixed with "emr3k:". Anyone any hints on what I might be missing? Could it be that the way to generate a sysupgrade image has changed? Here's what I'm using for emr3000 (and what works with 4.4): https://github.com/bk138/source/blob/emr3000-wip/target/linux/ar71xx/image/senao.mk Thanks in advance, Christian --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] new RBM33G board
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- I'm quite interested about porting LEDE on it. It looks like typical MT7621A board which has PCIe slot instead of MT7603 & MT7612. ... or something much similar to Firefly FireWRT (https://wikidevi.com/wiki/Firefly_FireWRT unfortunately, discontinued due to its manufacturing cost) I successfully ported LEDE on https://wikidevi.com/wiki/WeVO_W2914NS_v2, so I think I could port LEDE on it. I think I could purchase RBM33G early next month and try tinkering with that. On 26/12/2017 02.50, dan wrote: > Guys, new product from mikrotik. RBM33G. Has a MT7621A CPU w/ 16MB > of flash, 256MB RAM, and pcie m.2. > > This thing has 2 mini pci2 slots and 3 gigabit ethernet port and looks > nearly perfect for a dual radio, quad channel mesh box. > > I see that there are some devices with this cpu already supported by > lede. Any chance someone has got their hands on this unit and know if > the bootloader is usable ie if LEDE will run on it? If not, anyone > take bounties to 'port' LEDE to a specific board? > > Thanks. > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] jshn: add functionality to read big JSON
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Am Tue, 12 Dec 2017 12:03:50 +0100
schrieb John Crispin :
> Hi Christian,
>
> small formatting nitpick inline ...
Hi John,
Re-sending with tab adjustments and a space between if and the opening paren.
Cheers,
Christian
>From fcb002d7c8db41b27713f69422a4e2baecad08b0 Mon Sep 17 00:00:00 2001
From: Christian Beier
Date: Tue, 12 Dec 2017 19:33:12 +0100
Subject: [PATCH] jshn: add functionality to read big JSON
The existing read functionality feeds the complete JSON to jshn as a
cmdline argument, leading to `-ash: jshn: Argument list too long`
errors for JSONs bigger than ca. 100KB.
This commit adds the ability to read the JSON directly from a file if
wanted, removing this shell-imposed size limit.
Tested on x86-64 and ar71xx. An mmap()-based solution was also evaluated,
but found to make no performance difference on either platform.
Signed-off-by: Christian Beier
---
jshn.c | 30 --
sh/jshn.sh | 4
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/jshn.c b/jshn.c
index 79136dd..4a69994 100644
--- a/jshn.c
+++ b/jshn.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
#include "list.h"
#include "avl.h"
@@ -300,7 +302,7 @@ out:
static int usage(const char *progname)
{
- fprintf(stderr, "Usage: %s [-n] [-i] -r |-w\n", progname);
+ fprintf(stderr, "Usage: %s [-n] [-i] -r |-R |-w\n", progname);
return 2;
}
@@ -333,6 +335,10 @@ int main(int argc, char **argv)
struct env_var *vars;
int i;
int ch;
+ int fd;
+ struct stat sb;
+ char *fbuf;
+ int ret;
avl_init(&env_vars, avl_strcmp_var, false, NULL);
for (i = 0; environ[i]; i++);
@@ -354,7 +360,7 @@ int main(int argc, char **argv)
avl_insert(&env_vars, &vars[i].avl);
}
- while ((ch = getopt(argc, argv, "p:nir:w")) != -1) {
+ while ((ch = getopt(argc, argv, "p:nir:R:w")) != -1) {
switch(ch) {
case 'p':
var_prefix = optarg;
@@ -362,6 +368,26 @@ int main(int argc, char **argv)
break;
case 'r':
return jshn_parse(optarg);
+ case 'R':
+ if ((fd = open(optarg, O_RDONLY)) == -1) {
+fprintf(stderr, "Error opening %s\n", optarg);
+return 3;
+ }
+ if (fstat(fd, &sb) == -1) {
+fprintf(stderr, "Error getting size of %s\n", optarg);
+close(fd);
+return 3;
+ }
+ if (!(fbuf = malloc(sb.st_size)) || read(fd, fbuf, sb.st_size) != sb.st_size) {
+fprintf(stderr, "Error reading %s\n", optarg);
+free(fbuf);
+close(fd);
+return 3;
+ }
+ ret = jshn_parse(fbuf);
+ free(fbuf);
+ close(fd);
+ return ret;
case 'w':
return jshn_format(no_newline, indent);
case 'n':
diff --git a/sh/jshn.sh b/sh/jshn.sh
index bf76edb..0a146e1 100644
--- a/sh/jshn.sh
+++ b/sh/jshn.sh
@@ -174,6 +174,10 @@ json_load() {
eval "`jshn -r "$1"`"
}
+json_load_file() {
+ eval "`jshn -R "$1"`"
+}
+
json_dump() {
jshn "$@" ${JSON_PREFIX:+-p "$JSON_PREFIX"} -w
}
--
2.11.0
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] toolchain: fix GCC version check causing failure on Debian Testing with gcc-7
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Peter, On Sun, Nov 26, 2017 at 5:12 PM, Peter Pöschl wrote: > In Debian Stretch/Testing gcc version 7 is called gcc-7 and g++-7 and > 'gcc -dumpversion' returns '7' which causes 'make defconfig' to fail with > >Build dependency: Please install the GNU C Compiler ... >Build dependency: Please install the GNU C++ Compiler ... > > The following patch is minimal invasive. > Alternatively, it would be more robust to use the regex >'^(4\.[8-9]|5\.[0-9]|6\.[0-9]|7(|.\[0-9]))' > instead (currently even 1.4.0 would be accepted), but this might have > backward-compatibility ramifications. a few hours ago a similar patch was pushed: [0] (I CC'ed the author of it) there are some differences between your patch and the one which is merged already maybe you could check these and rebase your patch to improve the merged patch even futher > > Signed-off-by: Peter Pöschl > --- > diff --git a/include/prereq-build.mk b/include/prereq-build.mk > index c6f99a2071..43a8da290f 100644 > --- a/include/prereq-build.mk > +++ b/include/prereq-build.mk > @@ -28,13 +28,14 @@ $(eval $(call TestHostCommand,proper-umask, \ > > $(eval $(call SetupHostCommand,gcc, \ > Please install the GNU C Compiler (gcc) 4.8 or later \ > - $(CC) -dumpversion | grep -E '(4\.[8-9]|5\.[0-9]|6\.[0-9]|7\.[0-9])', > \ > - gcc -dumpversion | grep -E '(4\.[8-9]|5\.[0-9]|6\.[0-9]|7\.[0-9])', \ > + $(CC) -dumpversion | grep -E > '(4\.[8-9]|5\.[0-9]|6\.[0-9]|^7|7\.[0-9])', \ > + gcc -dumpversion | grep -E > '(4\.[8-9]|5\.[0-9]|6\.[0-9]|^7|7\.[0-9])', \ your patch contains a match against EOL ($) which the merged version doesn't > gcc48 --version | grep gcc, \ > gcc49 --version | grep gcc, \ > gcc5 --version | grep gcc, \ > gcc6 --version | grep gcc, \ > gcc7 --version | grep gcc, \ > + gcc-7 --version | grep gcc, \ this part is new > gcc --version | grep Apple.LLVM )) > > $(eval $(call TestHostCommand,working-gcc, \ > @@ -45,13 +46,14 @@ $(eval $(call TestHostCommand,working-gcc, \ > > $(eval $(call SetupHostCommand,g++, \ > Please install the GNU C++ Compiler (g++) 4.8 or later \ > - $(CXX) -dumpversion | grep -E > '(4\.[8-9]|5\.[0-9]|6\.[0-9]|7\.[0-9])', \ > - g++ -dumpversion | grep -E '(4\.[8-9]|5\.[0-9]|6\.[0-9]|7\.[0-9])', \ > + $(CXX) -dumpversion | grep -E > '(4\.[8-9]|5\.[0-9]|6\.[0-9]|^7|7\.[0-9])', \ > + g++ -dumpversion | grep -E > '(4\.[8-9]|5\.[0-9]|6\.[0-9]|^7|7\.[0-9])', \ > g++48 --version | grep g++, \ > g++49 --version | grep g++, \ > g++5 --version | grep g++, \ > g++6 --version | grep g++, \ > g++7 --version | grep g++, \ > + g++-7 --version | grep g++, \ > g++ --version | grep Apple.LLVM )) > > $(eval $(call TestHostCommand,working-g++, \ > -- > 2.15.0 > > > _______ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev Thank you! Martin [0] https://git.lede-project.org/?p=source.git;a=commitdiff;h=8ee2d3f718c79dc7c2e5e859766e23e8058cf3a6 --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] WhiteBox Wireless Router Supplier
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Were looking for a (White Box/Lede 100% Compatible) wireless router supplier. If anyone has any recommendation. Must have: Dual Band (2.4/5.8Ac) At least 4 gigabit ports. 2 or more external antennas. Case: ISP providing wireless for customers,bulk order. --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Busybox weirdness
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 02/11/2017 09:42, Philip Prindeville wrote: On Nov 1, 2017, at 8:36 PM, Philip Prindeville wrote: Can someone else please try to reproduce this? I’m using busybox’s wget on x86_64 hardware, and when I do a “wget” of 2 http: URI’s, it mangles the second URI’s derived filename: root@lede:/tmp/x# c Downloading 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz' Connecting to 104.16.37.47:80 Writing to 'GeoIPv6.csv.gz' GeoIPv6.csv.gz 100% |***| 1496k 0:00:00 ETA Download completed (1532219 bytes) Connecting to 104.16.37.47:80 Writing to ' z;' z; 100% |***| 2338k 0:00:00 ETA Download completed (2394696 bytes) root@lede:/tmp/x# ls z;?? GeoIPv6.csv.gz root@lede:/tmp/x# What the heck? -Philip Well, I was selecting busybox’s wget, but it was silently being overwritten by something else: root@lede:/tmp/x# ls -l /bin/wget lrwxrwxrwx1 root root13 Nov 1 19:17 /bin/wget -> uclient-fetch root@lede:/tmp/x# so that’s the real culprit. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev I can reproduce partially (17.01.4), here I get garbled filename that seems due to charset mismatch: wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz http://geolite.maxmind.com/download/geoip/da tabase/GeoIPCountryCSV.zip Downloading 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz' Connecting to 2400:cb00:2048:1::6810:262f:80 Writing to 'GeoIPv6.csv.gz' GeoIPv6.csv.gz 100% |***| 1496k 0:00:00 ETA Download completed (1532219 bytes) Connecting to 2400:cb00:2048:1::6810:252f:80 Writing to '��csv.gz' ��csv.gz 100% |***| 2338k 0:00:00 ETA Download completed (2394696 bytes) It also misbehaves if the download is somehow redirected over https, for example while downloading wrtbwmon i get: wget https://github.com/Kiougar/luci-wrtbwmon/releases/download/v0.6.0/luci-wrtbwmon_0.6.0_all.ipk Downloading 'https://github.com/Kiougar/luci-wrtbwmon/releases/download/v0.6.0/luci-wrtbwmon_0.6.0_all.ipk' Connecting to 192.30.253.112:443 Redirected to /77686685/247a31e2-494d-11e7-818a-29601f00a0dc?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20171102%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20171102T073145Z&X-Amz-Expires=300&X-Amz-Signature=fc898a693aeb4664ba1bc51de9ae2d2f791707e50829d7fb9b4ceaae4d99bd53&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dluci-wrtbwmon_0.6.0_all.ipk&response-content-type=application%2Foctet-stream on github-production-release-asset-2e65be.s3.amazonaws.com Writing to '247a31e2-494d-11e7-818a-29601f00a0dc?X-Amz-Algorithm=AWS4-HMAC-SHA256' 247a31e2-494d-11e7-8 100% |***| 5245 0:00:00 ETA Download completed (5245 bytes) None of this happens with plain wget (and ca-certificates) installed. --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Serial data getting lost - bug or a feature?
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 2017-10-18 Wed, at 06:32, Valent Turkovic wrote: > So if wifi is active, in sta mode but not associated to AP then serial > communication is having issues and is loosing characters when > receiving them. Regardless of this poor behavior, I think you're going to regret it eventually if you don't have some kind of checksum and retransmit logic--implying you're also doing framing. Async serial lines can be tricky, and have non-zero bit error rates. And the framing mechanism needs to be resilient against incomplete packets (meaning, bytes dropped between transmitter and receiver). Newline-separated ASCII records with a hex CRC are not the worst idea, but you need to deal with the situation where a newline gets lost, or you get trash or fewer bytes than you needed. I've used YMODEM before for bulk data. Note that the Arduino Yún uses packets. Jay --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] WRT300N v2 AR5416 (was:MV88E6060 switch)
mem:3 pagetables:20 bounce:0 [ 15.757853] free:579 free_pcp:0 free_cma:0 [ 15.789499] DMA free:2316kB min:444kB low:552kB high:664kB active_anon:540kB inactive_anon:8kB active_file:816kB inaco [ 15.832021] lowmem_reserve[]: 0 0 0 [ 15.835528] DMA: 159*4kB (U) 76*8kB (U) 25*16kB (U) 13*32kB (U) 4*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB B [ 15.847828] 400 total pagecache pages [ 15.851504] 0 pages in swap cache [ 15.854830] Swap cache stats: add 0, delete 0, find 0/0 [ 15.860105] Free swap = 0kB [ 15.862988] Total swap = 0kB [ 15.865870] 4096 pages RAM [ 15.868616] 0 pages HighMem/MovableOnly [ 15.872456] 976 pages reserved [ 16.518904] ath9k :00:01.0: Failed to initialize device [ 16.525279] ath9k: probe of :00:01.0 failed with error -12 [ 16.535006] kmodloader: done loading kernel modules from /etc/modules.d/* is it because of low RAM? # cat /proc/meminfo MemTotal: 12480 kB MemFree: 576 kB Regards, Nerijus --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Thu, 12 Oct 2017 03:11:21 +0300 Sergey Ryazanov wrote: > > I assume the new board type should be added to the config file, > > for which this patch should be enabled? > > I do not think so. These two patches are just a quick hacks to fix > common underlying issues. > > The first patch completes the work of adding phy(s) without the > standard MDIO interface, so it should be merged to existing patches. > > The second patch fixes the issue, which was introduced by > 304-ixp4xx_eth_jumboframe.patch, which adds JumboFrames support. So we > either should completely remove jumboframe support patch. Or, if > someone really use jumboframe feature, then we should to rework this > patch to avoid memory issues when using a regular MTU. > > I can try to make normal (and formal) fixes in a couple of days. It > would be nice if you could test them when they will be ready. Thank you. Another question about wifi - there is no /etc/config/wireless file, and even if I create it and reboot the device, wifi is not working and there is no wlan0 interface. ath5k module is loaded. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Thu, 12 Oct 2017 01:30:35 +0300 Sergey Ryazanov wrote: > Try this patch, it should reduce the memory demand of the ethernet > driver, so it will have the change to get started on your router. > > Just put it to target/linux/ixp4xx/patches-4.4 along with the previous > one and rebuild your firmware. I rebuilt the image with ppp and ipv6 excluded, but it did not help, after boot only 624 kB MemFree. But with your patch it works. Thanks a lot! I assume the new board type should be added to the config file, for which this patch should be enabled? Regards, Nerijus --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Thu, 12 Oct 2017 00:15:15 +0300 Sergey Ryazanov wrote: > >> As a quick test, can you unload all kernel modules and try to set eth0 UP > >> again? > > > > Unfortunately rmmod with a list of modules does not work: > > # rmmod ip_tables ip6_tables ip6t_REJECT ... > > Usage: > > rmmod module > > so I had to unload one by one. I unloaded until there was > > # cat /proc/meminfo > > MemTotal: 12232 kB > > MemFree:1304 kB > > > > but still does not work: > > # ifconfig eth0 up > > ifconfig: SIOCSIFFLAGS: Out of memory > > Can you boot in failsafe mode again, check free memory while the > interface is Up, then bring it Down and check free memory again? That > will show which amount of memory it needs. # cat /proc/meminfo MemTotal: 12232 kB MemFree:1108 kB # ifconfig eth0 down # cat /proc/meminfo MemTotal: 12232 kB MemFree:2136 kB --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Wed, 11 Oct 2017 23:28:00 +0300 Sergey Ryazanov wrote: > > root@LEDE:/# cat /proc/meminfo > > MemTotal: 12232 kB > > MemFree: 996 kB > > Looks like this ^^^ is the cause of the "ifconfig up" failure. Your > board really have not free RAM. > > As a quick test, can you unload all kernel modules and try to set eth0 UP > again? Unfortunately rmmod with a list of modules does not work: # rmmod ip_tables ip6_tables ip6t_REJECT ... Usage: rmmod module so I had to unload one by one. I unloaded until there was # cat /proc/meminfo MemTotal: 12232 kB MemFree:1304 kB but still does not work: # ifconfig eth0 up ifconfig: SIOCSIFFLAGS: Out of memory Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Wed, 11 Oct 2017 22:50:40 +0300 Sergey Ryazanov wrote: > Khm, according to wikidevi your router is equipped with 16MB of RAM, > the ethernet driver for xscale SoCs attempts to allocate almost a 1 MB > of memory for buffers, so may be there are really no free memory for > them. Yes, RAM is 16 MB. > Check, please, memory information and list of loaded kernel modules: > # cat /proc/meminfo > # lsmod root@LEDE:/# free total used free sharedbuffers cached Mem: 12232 11352880 40632 2420 -/+ buffers/cache: 8300 3932 Swap: 0 0 0 root@LEDE:/# cat /proc/meminfo MemTotal: 12232 kB MemFree: 996 kB MemAvailable: 3316 kB Buffers: 648 kB Cached: 2384 kB SwapCached:0 kB Active: 3012 kB Inactive:796 kB Active(anon):804 kB Inactive(anon): 20 kB Active(file): 2208 kB Inactive(file): 776 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 792 kB Mapped: 1680 kB Shmem:48 kB Slab: 4436 kB SReclaimable:848 kB SUnreclaim: 3588 kB KernelStack: 280 kB PageTables: 136 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:6116 kB Committed_AS: 2456 kB VmallocTotal:1015808 kB VmallocUsed: 0 kB VmallocChunk: 0 kB root@LEDE:/# lsmod ath16602 1 ath5k ath5k 177618 0 cfg80211 231978 3 ath5k,ath,mac80211 cmac2157 0 compat 11563 3 ath5k,mac80211,cfg80211 crc_ccitt 1035 1 ppp_async crypto_hash10802 2 mac80211,cmac ip_tables 9079 3 iptable_nat,iptable_mangle,iptable_filter ip6_tables 8885 2 ip6table_mangle,ip6table_filter ip6t_REJECT 972 2 ip6table_filter 734 1 ip6table_mangle 1054 1 ipt_MASQUERADE 754 1 ipt_REJECT 938 2 iptable_filter 796 1 iptable_mangle 924 1 iptable_nat 1073 1 mac80211 405550 1 ath5k nf_conntrack 46856 8 nf_conntrack_ipv6,xt_state,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4,nf_e nf_conntrack_ipv4 5251 10 nf_conntrack_ipv6 5500 5 nf_conntrack_rtcache2482 0 nf_defrag_ipv4 924 1 nf_conntrack_ipv4 nf_defrag_ipv6 9209 1 nf_conntrack_ipv6 nf_log_common 2191 2 nf_log_ipv4,nf_log_ipv6 nf_log_ipv4 2998 0 nf_log_ipv6 3223 0 nf_nat 8675 4 xt_nat,nf_nat_redirect,nf_nat_masquerade_ipv4,nf_nat_ipv4 nf_nat_ipv4 3367 1 iptable_nat nf_nat_masquerade_ipv41517 1 ipt_MASQUERADE nf_nat_redirect 955 1 xt_REDIRECT nf_reject_ipv4 1795 1 ipt_REJECT nf_reject_ipv6 2088 1 ip6t_REJECT ppp_async 6445 0 ppp_generic20137 3 pppoe,ppp_async,pppox pppoe 7959 0 pppox 1319 1 pppoe slhc3922 1 ppp_generic x_tables 10587 22 ipt_REJECT,ipt_MASQUERADE,xt_time,xt_tcpudp,xt_state,xt_nat,xt_multiport,xt_mark,xt_s xt_LOG 899 0 xt_REDIRECT 885 0 xt_TCPMSS 2664 2 xt_comment 555125 xt_conntrack2424 14 xt_limit1129 20 xt_mac 711 0 xt_mark 768 0 xt_multiport1332 0 xt_nat 1405 0 xt_state 841 0 xt_tcpudp 1816 10 xt_time 1702 0 --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Wed, 11 Oct 2017 18:53:40 +0300 Sergey Ryazanov wrote: > A-ha! The interface survives the down/up circle but does not survive > the init procedure. > > Try to completely avoid bridge usage, e.g.: > 1. boot in normal mode > 2. disable bridge usage on "lan": > # uci delete network.lan.type > # uci commit > 3. reboot > 4. after reboot is completed, check whether IP address has been > assigned to eth0. > 5. ping Yes, after reboot eth0 has 192.168.1.1, but it does not ping. dmesg: [4.970623] init: - preinit - [6.462015] random: jshn: uninitialized urandom read (4 bytes read, 10 bits of entropy available) [6.532512] random: jshn: uninitialized urandom read (4 bytes read, 10 bits of entropy available) [6.748641] NPE-B: firmware's license can be found in /usr/share/doc/LICENSE.IPL [6.756083] NPE-B: firmware functionality 0x2, revision 0x2:1 [6.764113] eth0: link up, speed 100 Mb/s, full duplex [ 10.330454] jffs2: notice: (733) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 u. [ 10.348884] mount_root: switching to jffs2 overlay [ 10.401588] urandom-seed: Seeding with /etc/urandom.seed [ 10.553168] eth0: link down --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Wed, 11 Oct 2017 14:53:16 +0300 Sergey Ryazanov wrote: > Ok. At least we know now that the switch functioning (even without a > dedicated driver). One question left: what happens to the Ethernet > driver? > > Can you boot your router in failsafe mode again, and try to toggle > eth0 down/up? E.g.: > # ifconfig eth0 down > # ifconfig eth0 up root@(none):/# ifconfig eth0 down [ 42.063281] eth0: link down root@(none):/# ifconfig eth0 up [ 49.665365] eth0: link up, speed 100 Mb/s, full duplex root@(none):/# ifconfig eth0 down [ 62.063281] eth0: link down root@(none):/# ifconfig eth0 up [ 68.295374] eth0: link up, speed 100 Mb/s, full duplex ping stops replying after down and replies after up. > To figure out, is taking down the interface enough to break it, or > something else happened during the initialization, what prevent us to > bring it up again. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Wed, 11 Oct 2017 02:07:00 +0300 Sergey Ryazanov wrote: > Ok. I am starting to run out of ideas. Let's start guessing. > > eth0 works at least during preinit. You could check your switch > functioning in the failsafe mode: > 1. Power on router > 2. When the "Press the [f] key and hit [enter]" line will be printed > on serial console then press the "f" and hit [enter] :) > 3. You could check which IP address configured on eth0 with ifconfig > and if there are not address, then configure it manually > 4. Try to pinging in order to check switch functioning This works: = FAILSAFE MODE active # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::218:39ff:fe21:dae/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 Ping to 192.168.1.1 answers, after pinging: RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:14 errors:0 dropped:0 overruns:0 carrier:0 > Another guess is to try to disable bridge before bringing eth0 up: > 1. Boot your router in normal mode > 2. Check whether eth0 is added to the bridge or not: > # brctl show > 3. Disable the bridge and configure eth0 for standalone working: > # brctl delif br-lan eth0 > # ifconfig br-lan down > # ifconfig eth0 192.168.0.10 up > 4. Try to pinging This does not: # brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.001839210dae no eth0 # brctl delif br-lan eth0 # ifconfig br-lan down # ifconfig eth0 192.168.0.10 up ifconfig: SIOCSIFFLAGS: Out of memory # brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.001839210dae no # ifconfig -a br-lanLink encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth0 Link encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:1551 (1.5 KiB) Ping to neither 192.168.1.1 nor 192.168.0.10 does not answer. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Mon, 9 Oct 2017 01:31:29 +0300 Sergey Ryazanov wrote: > > Just tried: > > # ifconfig eth0 192.168.0.10 up > > ifconfig: SIOCSIFFLAGS: Out of memory > > # dmesg|grep eth > > [0.998445] eth0: MII PHY 32 on NPE-B > > [1.005134] eth1: MII PHY 1 on NPE-C > > [6.540687] eth0: link up, speed 100 Mb/s, full duplex > > [9.323993] eth0: link down > > [ 36.266247] device eth0 entered promiscuous mode > > Check please, is there any new kernel messages after 'ifconfig ... up' > failure (may be not directly related to eth0). Just run dmesg without > grep. I don't see anything suspicious. The full serial console log (dmesg included) is here - https://paste.fedoraproject.org/paste/P5sDjdpJr1hFZ-hp~Prwcw > It is also stranger that something bring eth0 up and then putting it > back to down. Is these strings (eth0: link up/eth0: link down) appear > in the kernel log during preinit procedure? Seems so: [4.981198] init: - preinit - [6.473760] random: jshn: uninitialized urandom read (4 bytes read, 10 bits of entropy available) [6.544511] random: jshn: uninitialized urandom read (4 bytes read, 10 bits of entropy available) [6.761251] NPE-B: firmware's license can be found in /usr/share/doc/LICENSE.IPL [6.768796] NPE-B: firmware functionality 0x2, revision 0x2:1 [6.776745] eth0: link up, speed 100 Mb/s, full duplex Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level [ 10.310754] mount_root: jffs2 not ready yet, using temporary tmpfs overlay [ 10.359891] urandom-seed: Seed file not found (/etc/urandom.seed) [ 10.492841] eth0: link down Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Sun, 8 Oct 2017 23:44:58 +0300 Sergey Ryazanov wrote: > > I assigned IP with a command > > ip a a 192.168.0.10/24 dev eth0 > > > > but ping from PC does not answer. > > Have you bring eth0 UP? I mean, could you do "ifconfig eth0 > 192.168.0.10 up" and try pinging again? Just tried: # ifconfig eth0 192.168.0.10 up ifconfig: SIOCSIFFLAGS: Out of memory # dmesg|grep eth [0.998445] eth0: MII PHY 32 on NPE-B [1.005134] eth1: MII PHY 1 on NPE-C [6.540687] eth0: link up, speed 100 Mb/s, full duplex [9.323993] eth0: link down [ 36.266247] device eth0 entered promiscuous mode # ifconfig eth0 192.168.0.10 up ifconfig: SIOCSIFFLAGS: Out of memory # ifconfig -a br-lanLink encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fde1:e263:bcc::1/60 Scope:Global UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth0 Link encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:92 (92.0 B) TX bytes:1551 (1.5 KiB) Ping still does not answer. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Tue, 3 Oct 2017 03:27:21 +0300 Sergey Ryazanov wrote: > After these lines, I carefully examine available data about WRT300Nv2 > and related code and found several interesting things. > > Usually SoC in the router have only one ethernet interface and vendors > pair it with manageable switch IC. This swith IC accepts packets from > LAN and WAN ports, then it tags them and forward to the SoC. Thus, > using VLAN tags, SoC can distinguish from which port the packet was > received and handle it appropriately. So the firmware should contains > a driver for switch IC to be able to properly configure ports and > VLANs inside the switch. > > In case of WRT300Nv2 the SoC contains two ethernet adapters: NPE-C > (eth1), which has own phy and acted as a WAN port and NPE-B (eth0), > which is connected to switch IC, each port of which is acting as LAN > port. So since all ports of switch are equal then the switch themself > requires a minimal (if any) configuration. And this router can > possibly act without any special driver for switch IC. > > Also I found why the switch is properly detected on the MDIO bus but > not used as phy-device. This happened because PHY ID for eth0 is > hardcoded inside WRT300Nv2 setup code. > > To check whether your board can act without dedicated driver for 88E6060: > * revert any earlier modifications to LEDE if you do any > * disable any drivers for 88E6060 (e.g. disable both > CONFIG_NET_DSA_MV88E6060 and CONFIG_MVSWITCH_PHY) > * place attached patch to the target/linux/ixp4xx/patches-4.4 > * rebuild and boot new firmware > * check dmesg for "eth0: link up" message > * check eth0 functioning: check packets receiving with tcpdump or > manually assign IP address to the eth0 interface (without any VLAN's > and so on) and try to ping. I did this, and now when booting I see [0.999140] eth0: MII PHY 32 on NPE-B [1.005714] eth1: MII PHY 1 on NPE-C ... [6.531972] NPE-B: firmware functionality 0x2, revision 0x2:1 [6.540066] eth0: link up, speed 100 Mb/s, full duplex [9.070970] mount_root: jffs2 not ready yet, using temporary tmpfs overlay [9.118732] urandom-seed: Seed file not found (/etc/urandom.seed) [9.250596] eth0: link down I assigned IP with a command ip a a 192.168.0.10/24 dev eth0 but ping from PC does not answer. ifconfig -a shows a few RX and TX packets: eth0 Link encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.0.10 Bcast:0.0.0.0 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 but the packet count does not increase after pinging. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Fwd: [OpenWrt-Devel] GSoC 2018 announced
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Forwarded Message Subject:[OpenWrt-Devel] GSoC 2018 announced Date: Sun, 1 Oct 2017 12:04:17 +0200 From: Andreas Bräu To: openwrt-de...@lists.openwrt.org Hi there, GSoC 2017 is barely over and Google already announced the next Summer of Code for 2018: https://developers.google.com/open-source/gsoc/ Applications start at Jan 4 2018 and will end on Jan 23. Student applications will start in March. I already prepared our wiki ideas page for new ideas: https://wiki.freifunk.net/Ideas Our 2017s ideas you can find at https://wiki.freifunk.net/Ideas_GSoC_2017 Please submit your new ideas, talk to possible students or forward this mail to people that may be interested as mentors or students. Best regards, Andi — Andreas Bräu XMPP: andibr...@jabber.weimarnetz.de Twitter:@evAltenberga <https://twitter.com/evaltenberga> Blog:https://blog.andi95.de <https://blog.andi95.de/> PGP:0xB7E04818 ___ openwrt-devel mailing list openwrt-de...@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Fri, 8 Sep 2017 22:50:13 +0300 Sergey Ryazanov wrote: > >> >> Did you see the "Marvell 88E6060 PHY driver attached" in kernel > >> >> messages log? If not then the mwswitch driver did not attached and > >> >> you should fix this first. And only then go to the interface > >> >> configuration. > >> > > >> > No, dmesg|grep 6060 does not show anything. How do I fix it? > >> > >> Try to check, which MDIO addresses PHY core (or Ethernet MAC driver) > >> scans to detect connected PHYs. > > > > I enabled #define DEBUG_MDIO 1 in ixp4xx_eth.c and got this: > > # dmesg|grep -i MII|grep -v took > > ... > > [0.976646] IXP4xx MII Bus #16: MII read [2] -> 0x141 > > [0.976747] IXP4xx MII Bus #16: MII read [3] -> 0xC87 > > [0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602 > > Looks like mvswitch driver tries to check chip here and got an > expected value 0x060X from register 3. So on the one hand the driver > is functioning, but on the other hand it can not detect switch IC. > > Can you go to the /sys/class/mdio_bus/ and for each bus check driver > and ID of the each detected device. E.g.: > # cd /sys/class/mdio_bus > # ls -l */*/driver lrwxrwxrwx1 root root 0 Jul 22 21:31 ixp4xx-eth-0/ixp4xx-eth-0:01/driver -> ../../../../../bus/mdio_bus/drivers/Generic PHY lrwxrwxrwx1 root root 0 Jul 22 21:31 ixp4xx-eth-0/ixp4xx-eth-0:10/driver -> ../../../../../bus/mdio_bus/drivers/Marvell 88E6060 > # ls -l */*/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:01/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:10/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:11/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:12/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:13/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:14/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:15/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:16/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:17/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:18/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:19/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:1a/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:1b/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:1c/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:1d/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:1e/phy_id -r--r--r--1 root root 4096 Jul 22 21:32 ixp4xx-eth-0/ixp4xx-eth-0:1f/phy_id > # cat */*/phy_id 0x8201 0x088e6060 0x01410c87 0x01410c87 0x01410c87 0x01410c87 0x0000 0x 0x 0x0602 0x0602 0x0602 0x0602 0x00000602 0x0602 0x 0x Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/3] Remove ttl==255 restriction for queries
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thursday, September 28, 2017 1:36:52 PM CEST Philip Prindeville wrote:
> Why was this test there and equally why are we removing it?
I guess it was there so umdns would ignore any forwarded mdns?
This would stop two mDNS reflectors to ping-pong each other.
The avahi-daemon manpages speaks about this in:
<https://manpages.debian.org/jessie/avahi-daemon/avahi-daemon.conf.5.en.html#SECTION_%5BREFLECTOR%5D>
Regards,
Christian
>
> > On Sep 28, 2017, at 1:09 AM, Philipp Meier
> > wrote:
> >
> > Signed-off-by: Philipp Meier
> > ---
> > interface.c | 6 --
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/interface.c b/interface.c
> > index 3904c89..7f814d2 100644
> > --- a/interface.c
> > +++ b/interface.c
> > @@ -233,9 +233,6 @@ read_socket4(struct uloop_fd *u, unsigned int events)
> >}
> >}
> >
> > -if (ttl != 255)
> > -return;
> > -
> >if (debug > 1) {
> >char buf[256];
> >
> > @@ -310,9 +307,6 @@ read_socket6(struct uloop_fd *u, unsigned int events)
> >}
> > }
> >
> > - if (ttl != 255)
> > -return;
> > -
> >if (debug > 1) {
> >char buf[256];
> >
>
>
> _______
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 4/4] ramips/RT5350F-OLINUXINO(-EVB) dts: enable ttyS1
65407] gpio-export gpio_export: 3 gpio(s) exported
> [ 0.576247] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> [ 0.590942] console [ttyS0] disabled
> [0.598130] 1500.uart: ttyS0 at MMIO 0x1500 (irq = 13,
> base_baud = 250) is a Palmchip BK-3103
> [0.617160] console [ttyS0] enabled
> [0.630939] bootconsole [early0] disabled
> [0.647968] 1c00.uartlite: ttyS1 at MMIO 0x1c00 (irq = 20,
> base_baud = 2500000) is a Palmchip BK-3103
> [0.680207] spi spi0.0: force spi mode3
>
> With swapped items in rt5350.dtsi
> [0.564356] gpio-export gpio_export: 3 gpio(s) exported
> [0.575201] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> [0.590006] console [ttyS0] disabled
> [0.597183] 1c00.uartlite: ttyS0 at MMIO 0x1c00 (irq = 20,
> base_baud = 250) is a Palmchip BK-3103
> [0.616906] console [ttyS0] enabled
> [0.630692] bootconsole [early0] disabled
> [0.647677] 1500.uart: ttyS1 at MMIO 0x1500 (irq = 13,
> base_baud = 250) is a Palmchip BK-3103
> [0.678972] spi spi0.0: force spi mode3
>
> Consequently (given that ttyS0 is configured as console in the kernel
> command line),
> the serial console moves to the pins of uart500 in the second (swapped)
> case.
> Do you have any suggestion how to solve this on the level of
> RT5350F-OLINUXINO.dtsi, without touching rt5350.dtsi?
>
>
>>
>> John
>>
>>> +
>>> systick: systick@d00 {
>>> compatible = "ralink,rt5350-systick",
>>> "ralink,cevt-systick";
>>> reg = <0xd00 0x10>;
>>
>
> Thanks, regards,
>
> Zoltan Gyarmati
> https://zgyarmati.de
>
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
[0] http://elinux.org/Device_Tree_Usage#aliases_Node
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
> 0xC87 > [0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602 > [0.979235] IXP4xx MII Bus #17: MII read [2] -> 0x141 > [0.979336] IXP4xx MII Bus #17: MII read [3] -> 0xC87 > [0.981110] IXP4xx MII Bus #18: MII read [2] -> 0x141 > [0.981211] IXP4xx MII Bus #18: MII read [3] -> 0xC87 > [0.982664] IXP4xx MII Bus #19: MII read [2] -> 0x141 > [0.982765] IXP4xx MII Bus #19: MII read [3] -> 0xC87 > [0.984184] IXP4xx MII Bus #20: MII read [2] -> 0x141 > [0.984285] IXP4xx MII Bus #20: MII read [3] -> 0xC87 > [0.985770] IXP4xx MII Bus #21: MII read [2] -> 0x0 > [0.985870] IXP4xx MII Bus #21: MII read [3] -> 0x0 > [0.987322] IXP4xx MII Bus #22: MII read [2] -> 0x0 > [0.987422] IXP4xx MII Bus #22: MII read [3] -> 0x0 > [0.988983] IXP4xx MII Bus #23: MII read [2] -> 0x0 > [0.989084] IXP4xx MII Bus #23: MII read [3] -> 0x0 > [0.990553] IXP4xx MII Bus #24: MII read [2] -> 0x0 > [0.990653] IXP4xx MII Bus #24: MII read [3] -> 0x602 > [0.992135] IXP4xx MII Bus #25: MII read [2] -> 0x0 > [0.992236] IXP4xx MII Bus #25: MII read [3] -> 0x602 > [0.993668] IXP4xx MII Bus #26: MII read [2] -> 0x0 > [0.993769] IXP4xx MII Bus #26: MII read [3] -> 0x602 > [0.995213] IXP4xx MII Bus #27: MII read [2] -> 0x0 > [0.995313] IXP4xx MII Bus #27: MII read [3] -> 0x602 > [0.996749] IXP4xx MII Bus #28: MII read [2] -> 0x0 > [0.996849] IXP4xx MII Bus #28: MII read [3] -> 0x602 > [0.998319] IXP4xx MII Bus #29: MII read [2] -> 0x0 > [0.998420] IXP4xx MII Bus #29: MII read [3] -> 0x602 > [1.21] IXP4xx MII Bus #30: MII read [2] -> 0x0 > [1.000120] IXP4xx MII Bus #30: MII read [3] -> 0x0 > [1.001588] IXP4xx MII Bus #31: MII read [2] -> 0x0 > [1.001687] IXP4xx MII Bus #31: MII read [3] -> 0x0 > [1.003068] libphy: IXP4xx MII Bus: probed > [1.010033] eth0: MII PHY 32 on NPE-B > [1.014186] IXP4xx MII Bus #1: MII read [1] -> 0x7849 > [1.014288] IXP4xx MII Bus #1: MII read [0] -> 0x1000 > [1.014393] IXP4xx MII Bus #1: MII write [0] <- 0x1000, err = 0 > [1.016811] eth1: MII PHY 1 on NPE-C --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand framework
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Monday, September 4, 2017 1:48:38 PM CEST Weijie Gao wrote: > Yes. If I search "spi-nand linux" in Google, Micron's framework is the > first result. > However, Micron's patches are based on higher version of kernel, which > require lots of modifications to port to linux-4.4. > I choose the framework from LEDE's > target/linux/pistachio/patches-4.9/, which requires only few changes. Yes exactly this is my concern: all the porting of of out-of-tree patches. linux-4.4 has only about five to six more month left before the patches will run out: <https://www.kernel.org/category/releases.html> (Projected EOL: Feb, 2018). So question is, what will ar71xx do in six month? Will it be updated to 4.9? Or will it be ported to the upcoming 4.14? (I don't know?) Would you be willing to stick around and be prepared to revisit the patch in this case too? > I've read nearly all datasheets from GigaDevice, Micron, Winbond, > Macronix, and other manufacturers. I found that their chips are not > full compatiable with each other. > For example, the ECC status bits definition. GigaDevice uses one > status to indicate the unrecoverable bits while Winbond uses two > statuses to indicate that. > And stacked die selection command is different between Micron and > Winbond. And Mircon's chip has its own plane selection bit. > > Even chips of the same manufacturer, the page size/OOB size and layout > can be different. You can see differences of GigaDevice's chips in > this patch. > > So, the mt29f_spinand is not enough, it's designed only for > Micron's chips. A micron engineer put it like this: <http://lists.infradead.org/pipermail/linux-mtd/2014-November/056531.html> " As far as I've seen from the datasheets I have available (SPI NAND GigaDevice 1Gb/2Gb/4Gb, Micron 1Gb/2Gb/4Gb), the command sequencing is the same for read/write/erase operations (read: enable ECC, read to cache, wait, read from cache, check for errors, disable ECC; write: enable ECC, write enable, program load, program execute, wait, verify, disable ECC; erase: write enable, erase block, verify). Regarding the stream of bytes for each command, the problematic commands are the read from cache ones (read, fast read, read x2, read x4, read dual read quad) that have different command format (additional dummy bytes, a plane select bit to be set). Other differences are in the structure of the protection and status registers (some of them use more ECC and protection bits according to the size of the chip). Also, each has a different ECC layout " The funny thing is, that a micron engineer made a patch back in the day that had support for both the MT29F and your GD5F with <http://lkml.iu.edu/hypermail/linux/kernel/1501.0/03747.html> >From the look of it, it seems easy to support the GD5F that way... So much so, that "this unification habbit" was picked up by imgtec for the pistachio! Just look at this pull request from an ImgTec engineer titled: "Add Imagination's Pistachio SoC and (Ci40) Marduk platform support" for openwrt project: <https://github.com/openwrt/openwrt/pull/201/files#diff-b70d21c394349496f5f6a7e6b5a05a7c> Look at the target/linux/pistachio/patches-4.4/0001-mtd-nand-Introduce-SPI-NAND-framework.patch commit message: "5. mtd: spi-nand: Support common SPI NAND devices This commit uses the recently introduced SPI NAND framework to support Micron MT29F and Gigadevice GD5F serial NAND devices. These two families of devices are fairly similar and so they are supported with only minimal differences." > The framework I chose from > <https://github.com/lede-project/source/tree/master/target/linux/pistachio/patches-4.9/413-mtd-Introduce-SPI-NAND-framework.patch> > <https://github.com/lede-project/source/tree/master/target/linux/pistachio/patches-4.9/414-mtd-spi-nand-Support-Gigadevice-GD5F.patch> > has two layers, one for generic nand operation and one for > manufacturer-specific operations, such as the ecc status check. > > I think this is a good practice. Depends on how ar71xx will play out. For now, assume let's assume that ar71xx is updated to 4.9. Then these patches would have to be moved to either ar71xx's kernel patch directory: target/linux/ar71xx/patches-4.9 Or someone would have to *move* the existing 4.9 version out of target/linux/pistachio/patches-4.9 and into target/linux/generic/patches-4.9. (Otherwise, quilt will complain because of the duplicated patches). Regards, Christian --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: Add GRO support to ag71xx
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Sunday, September 3, 2017 11:35:46 AM CEST Rosen Penev wrote: > On a TL-WN710N, this patch increases iperf performance from ~92.5 to ~93.5 > mbps. Keep in mind the WN710N is a 100mbps device. I expect greater numbers > from gigabit devices. > > Signed-off-by: Rosen Penev > --- I've done a quick test of the patch on my WD Range Extender. (It has a Atheros AR9344 rev 2 SoC @ CPU:560.000MHz, DDR:400.000MHz The PHY is a AR8035, which supports 1 GBit/s Links) The range extender (DUT) was running iperf3 server in both tests. Another desktop PC was acting as the iperf3 client. without the patch: Connecting to host range-extender, port 5201 [ 4] local 192.168.8.7 port 51518 connected to 192.168.8.204 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 23.5 MBytes 197 Mbits/sec0105 KBytes [ 4] 1.00-2.00 sec 23.7 MBytes 199 Mbits/sec0105 KBytes [ 4] 2.00-3.00 sec 23.6 MBytes 198 Mbits/sec0105 KBytes [ 4] 3.00-4.00 sec 23.0 MBytes 193 Mbits/sec0105 KBytes [ 4] 4.00-5.00 sec 23.4 MBytes 197 Mbits/sec0105 KBytes [ 4] 5.00-6.00 sec 23.3 MBytes 195 Mbits/sec0105 KBytes [ 4] 6.00-7.00 sec 23.4 MBytes 196 Mbits/sec0105 KBytes [ 4] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec0105 KBytes [ 4] 8.00-9.00 sec 23.1 MBytes 194 Mbits/sec0105 KBytes [ 4] 9.00-10.00 sec 22.1 MBytes 185 Mbits/sec0105 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 233 MBytes 195 Mbits/sec0 sender [ 4] 0.00-10.00 sec 232 MBytes 195 Mbits/sec receiver iperf Done. with the patch (gro enabled - this is done by default): Connecting to host range-extender, port 5201 [ 4] local 192.168.8.7 port 52004 connected to 192.168.8.204 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 32.7 MBytes 274 Mbits/sec0106 KBytes [ 4] 1.00-2.00 sec 32.6 MBytes 274 Mbits/sec0106 KBytes [ 4] 2.00-3.00 sec 32.4 MBytes 272 Mbits/sec0106 KBytes [ 4] 3.00-4.00 sec 32.3 MBytes 271 Mbits/sec0106 KBytes [ 4] 4.00-5.00 sec 32.5 MBytes 273 Mbits/sec0106 KBytes [ 4] 5.00-6.00 sec 32.5 MBytes 273 Mbits/sec0106 KBytes [ 4] 6.00-7.00 sec 32.6 MBytes 273 Mbits/sec0106 KBytes [ 4] 7.00-8.00 sec 32.4 MBytes 272 Mbits/sec0106 KBytes [ 4] 8.00-9.00 sec 32.6 MBytes 273 Mbits/sec0106 KBytes [ 4] 9.00-10.00 sec 31.4 MBytes 264 Mbits/sec0106 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 324 MBytes 272 Mbits/sec0 sender [ 4] 0.00-10.00 sec 324 MBytes 272 Mbits/sec receiver iperf Done. (range-extender) # ethtool -K eth0 gro off Connecting to host range-extender, port 5201 [ 4] local 192.168.8.7 port 52120 connected to 192.168.8.204 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 24.8 MBytes 208 Mbits/sec0105 KBytes [ 4] 1.00-2.00 sec 23.6 MBytes 198 Mbits/sec0105 KBytes [ 4] 2.00-3.00 sec 24.5 MBytes 206 Mbits/sec0105 KBytes [ 4] 3.00-4.00 sec 23.9 MBytes 201 Mbits/sec0105 KBytes [ 4] 4.00-5.00 sec 24.6 MBytes 207 Mbits/sec0105 KBytes [ 4] 5.00-6.00 sec 24.7 MBytes 207 Mbits/sec0105 KBytes [ 4] 6.00-7.00 sec 24.5 MBytes 206 Mbits/sec0105 KBytes [ 4] 7.00-8.00 sec 24.0 MBytes 201 Mbits/sec0105 KBytes [ 4] 8.00-9.00 sec 24.3 MBytes 204 Mbits/sec0105 KBytes [ 4] 9.00-10.00 sec 24.5 MBytes 206 Mbits/sec0105 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 244 MBytes 204 Mbits/sec0 sender [ 4] 0.00-10.00 sec 243 MBytes 204 Mbits/sec receiver iperf Done. So, the throughput went from 195 Mbits/sec to 272 Mbits/sec. The gain would be (272 Mbps - 195 Mbps) / 195 Mbps = 0.3949 ~ 40% Regards, Christian --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand framework
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Sunday, September 3, 2017 1:43:59 PM CEST hackpascal wrote: > From: Weijie Gao > > This patch adds generic SPI-NAND framework for linux-4.4. > > Files come from patches of target pistachio, but have lots of modifications > to add full support for GD5F series. > > Signed-off-by: Weijie Gao > --- Hm, from what I know multiple "generic" SPI-NAND driver/framework exist. The current favourite of linux-mtd seems to be from Micron: <http://lists.infradead.org/pipermail/linux-mtd/2017-April/073649.html> (Altought, development has sadly stalled as well ;( ) <http://lists.infradead.org/pipermail/linux-mtd/2017-April/073681.html> Is this correct? Or was there a recent attempt at upstreaming "this" older framework too that I can't find? Note: The kernel had some support for spinand since v3.13 via the staging "mt29f_spinand" driver. I had some success with it on the RT-AC58U. All I needed there was to add a custom definition for the Winbond W25N01GV chip [0] and enable CONFIG_MTD_SPINAND_MT29F=y CONFIG_MTD_SPINAND_ONDIEECC=y Maybe you too can get away with something similar to this? Until linux-mtd _finally_ knows what they want to merge. Regards, Christian [0] <https://github.com/lede-project/source/blob/master/target/linux/ipq806x/patches-4.9/104-mtd-nand-add-Winbond-manufacturer-and-chip.patch> --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Advertising Opportunities
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello I hope you don't mind me emailing you. My name is Annie and I am the Editorial lead at EditorialPR.com in the UK. We have a client at the moment that's interested in being featured on your website. Do you have any editorial advertising opportunities on the site that we could work together on? Please note; I am on a tight deadline and need to get my placements for next month agreed as soon as possible. So if you are interested please get back to me as soon as possible so I can supply you with the full details of the project. Also if you have more than one site, it would be great if you let me know so we can see if it's suitable for any of our other campaigns. Many thanks Annie-Mai EditorialPR.com This e-mail message (and its attachments) may contain confidential, proprietary or legally privileged information and is intended only for the individual named addressee. You should not review, disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmissions cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of the message. --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] dnsmasq: backport upstream fix for segfault
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Signed-off-by: Ash Benz --- ...-segfault-caused-by-early-inclusion-stdio.patch | 27 ++ 1 file changed, 27 insertions(+) create mode 100644 package/network/services/dnsmasq/patches/250-fix-segfault-caused-by-early-inclusion-stdio.patch diff --git a/package/network/services/dnsmasq/patches/250-fix-segfault-caused-by-early-inclusion-stdio.patch b/package/network/services/dnsmasq/patches/250-fix-segfault-caused-by-early-inclusion-stdio.patch new file mode 100644 index 00..f9f6556bc9 --- /dev/null +++ b/package/network/services/dnsmasq/patches/250-fix-segfault-caused-by-early-inclusion-stdio.patch @@ -0,0 +1,27 @@ +From: Christian Hesse + +We define some constants in dnsmasq.h, which have an influence on +stdio.h. So do not include stdio.h before dnsmasq.h. + +This fixes a segmentation fault caused by size mismatch for +size_t and off_t on systems where these are 4 bytes without +large file support. +Reported, debugged and tested by Arne Worner . + +Signed-off-by: Christian Hesse +--- + src/helper.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/src/helper.c b/src/helper.c +index 635677e..281cb4a 100644 +--- a/src/helper.c b/src/helper.c +@@ -14,7 +14,6 @@ +along with this program. If not, see <http://www.gnu.org/licenses/>. + */ + +-#include + #include "dnsmasq.h" + + #ifdef HAVE_SCRIPT -- 2.14.1 --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
0: MII read [3] -> 0xC87 [0.985770] IXP4xx MII Bus #21: MII read [2] -> 0x0 [0.985870] IXP4xx MII Bus #21: MII read [3] -> 0x0 [0.987322] IXP4xx MII Bus #22: MII read [2] -> 0x0 [0.987422] IXP4xx MII Bus #22: MII read [3] -> 0x0 [0.988983] IXP4xx MII Bus #23: MII read [2] -> 0x0 [0.989084] IXP4xx MII Bus #23: MII read [3] -> 0x0 [0.990553] IXP4xx MII Bus #24: MII read [2] -> 0x0 [0.990653] IXP4xx MII Bus #24: MII read [3] -> 0x602 [0.992135] IXP4xx MII Bus #25: MII read [2] -> 0x0 [0.992236] IXP4xx MII Bus #25: MII read [3] -> 0x602 [0.993668] IXP4xx MII Bus #26: MII read [2] -> 0x0 [0.993769] IXP4xx MII Bus #26: MII read [3] -> 0x602 [0.995213] IXP4xx MII Bus #27: MII read [2] -> 0x0 [0.995313] IXP4xx MII Bus #27: MII read [3] -> 0x602 [0.996749] IXP4xx MII Bus #28: MII read [2] -> 0x0 [0.996849] IXP4xx MII Bus #28: MII read [3] -> 0x602 [0.998319] IXP4xx MII Bus #29: MII read [2] -> 0x0 [0.998420] IXP4xx MII Bus #29: MII read [3] -> 0x602 [1.21] IXP4xx MII Bus #30: MII read [2] -> 0x0 [1.000120] IXP4xx MII Bus #30: MII read [3] -> 0x0 [1.001588] IXP4xx MII Bus #31: MII read [2] -> 0x0 [1.001687] IXP4xx MII Bus #31: MII read [3] -> 0x0 [1.003068] libphy: IXP4xx MII Bus: probed [1.010033] eth0: MII PHY 32 on NPE-B [1.014186] IXP4xx MII Bus #1: MII read [1] -> 0x7849 [ 1.014288] IXP4xx MII Bus #1: MII read [0] -> 0x1000 [1.014393] IXP4xx MII Bus #1: MII write [0] <- 0x1000, err = 0 [1.016811] eth1: MII PHY 1 on NPE-C Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Thu, 27 Jul 2017 21:31:01 +0300 Sergey Ryazanov wrote: > > Tried the latest LEDE. Now I see in the boot log: > > [6.507617] NPE-B: firmware's license can be found in > > /usr/share/doc/LICENSE.IPL > > [6.515168] NPE-B: firmware functionality 0x2, revision 0x2:1 > > [6.523171] eth0: link up, speed 0 Mb/s, full duplex > > Did you see the "Marvell 88E6060 PHY driver attached" in kernel > messages log? If not then the mwswitch driver did not attached and > you should fix this first. And only then go to the interface > configuration. No, dmesg|grep 6060 does not show anything. How do I fix it? > > and now I see RX and TX packets on eth0 (they were 0 before). > > Did you try to use tcpdump to see what RXed by the interface? No, but I'll try. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Sun, 23 Jul 2017 11:38:02 -0700 Florian Fainelli wrote: > > How do I configure vlan? Here I changed eth0 to eth0.1: > > > > config interface 'lan' > > option type 'bridge' > >option ifname 'eth0.1' > >option proto 'static' > >option ipaddr '192.168.1.1' > >option netmask '255.255.255.0' > >option ip6assign '60' > > I tried > config 'switch' 'eth0' >option 'enable' '1' >option 'enable_vlan' '1' >option 'reset' '1' > > config 'switch_vlan' >option 'vlan' '1' >option 'device' 'eth0' >option 'ports' '1 2 3 4 5t' > > config 'switch_vlan' >option 'vlan' '2' >option 'device' 'eth0' >option 'ports' '0 5t' > > Does not work. Do I need to have swconfig installed in order to > get the switch working? Because by default it is not installed. > > > Yes, it is necessary with this switch driver to have swconfig installed, > otherwise nothing would push CLEAN configurations to the mv88e6060 switch. I added swconfig, but still no network with the above config. Could you please give some hints if the above switch config is correct? Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- 2017-07-23 21:38, Florian Fainelli rašė: Does not work. Do I need to have swconfig installed in order to get the switch working? Because by default it is not installed. Yes, it is necessary with this switch driver to have swconfig installed, otherwise nothing would push CLEAN configurations to the mv88e6060 switch. How do I add it? I added swconfig to target/linux/ixp4xx/Makefile: DEFAULT_PACKAGES += ixp4xx-microcode fconfig swconfig but still no swconfig in generated lede-ixp4xx-generic-squashfs.img. Thanks, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- 2017-07-21 19:48, Nerijus Baliūnas via Lede-dev rašė: How do I configure vlan? Here I changed eth0 to eth0.1: config interface 'lan' option type 'bridge' option ifname 'eth0.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' I tried config 'switch' 'eth0' option 'enable' '1' option 'enable_vlan' '1' option 'reset' '1' config 'switch_vlan' option 'vlan' '1' option 'device' 'eth0' option 'ports' '1 2 3 4 5t' config 'switch_vlan' option 'vlan' '2' option 'device' 'eth0' option 'ports' '0 5t' Does not work. Do I need to have swconfig installed in order to get the switch working? Because by default it is not installed. Thanks, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- 2017-07-21 01:41, Sergey Ryazanov rašė: You should disable CONFIG_NET_DSA_MV88E6060 and select only CONFIG_MVSWITCH_PHY=y option. This two different drivers, the first one is mainstream Linux driver, and the second one is OpenWRT specific driver, which is mach more simple and small. This driver uses VLAN tags to determine which port the frame should be sent from. Try to create couple of VLAN sub-interfaces on eth0 with ID 1 and 2 and work with them. I'll try. Yes, use the latest version of LEDE, please, to avoid facing with long-forgotten bugs. Tried the latest LEDE. Now I see in the boot log: [6.507617] NPE-B: firmware's license can be found in /usr/share/doc/LICENSE.IPL [6.515168] NPE-B: firmware functionality 0x2, revision 0x2:1 [6.523171] eth0: link up, speed 0 Mb/s, full duplex and now I see RX and TX packets on eth0 (they were 0 before). How do I configure vlan? Here I changed eth0 to eth0.1: config interface 'lan' option type 'bridge' option ifname 'eth0.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' And just copy/pasted from another router: config switch option name 'rt305x' option reset '1' option enable_vlan '1' config switch_vlan option device 'rt305x' option vlan '1' option ports '0 1 2 3 5 6t' config switch_vlan option device 'rt305x' option vlan '2' option ports '4 6t' But still RX and TX packets are on eth0, not eth0.1: # ifconfig -a br-lanLink encap:Ethernet HWaddr 00:18:39:21:0D:AE inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fd63:bf56:4b8::1/60 Scope:Global UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth0 Link encap:Ethernet HWaddr 00:18:39:21:0D:AE BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:241 (241.0 B) TX bytes:1551 (1.5 KiB) eth0.1Link encap:Ethernet HWaddr 00:18:39:21:0D:AE BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth1 Link encap:Ethernet HWaddr 00:18:39:21:0D:AF BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) loLink encap:Local Loopback Thanks, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- 2017-07-21 00:36, Sergey Ryazanov rašė: No received/sent packets on br-lan and eth0 before and after modprobe mv88e6060.ko. Did you saw the "Marvel 88E6060 PHY driver attached" string in the kernel messages? If so then at least the driver detects switch chip. No. BTW, do I understand correctly - I have to use mv88e6060.ko which should use CONFIG_MVSWITCH_PHY or is CONFIG_MVSWITCH_PHY alone enough? This driver uses VLAN tags to determine which port the frame should be sent from. Try to create couple of VLAN sub-interfaces on eth0 with ID 1 and 2 and work with them. I'll try. And BTW do you use OpenWRT or LEDE and which version? Actually I use barrier breaker, as the device has only 16 MB RAM so I thought an earlier version will use less resources. But I can try later versions. Thanks, Nerijus --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- 2017-07-19 04:02, Sergey Ryazanov rašė: Linksys WRT300N v2.0 has Marvell 88e6060 switch. But ixp4xx arch does not have its driver enabled (ar71xx has it). I added CONFIG_NET_DSA_MV88E6060=m, but when I modprobe mv88e6060.ko, nothing happens. It seems driver does not hook on any hardware: This happened because this driver is quite useless on their own. It requires some assistance to properly detects switch IC either from arch code via platform device data or via DTS. Try to use OpenWRT/LEDE specific driver, which is used by ath25 and ar7 platforms by enabling CONFIG_MVSWITCH_PHY option in the kernel. I enabled CONFIG_MVSWITCH_PHY=y. But still no ethernet. When booting: [1.049060] libphy: IXP4xx MII Bus: probed [1.056182] eth0: MII PHY 32 on NPE-B [1.062966] eth1: MII PHY 1 on NPE-C [ 43.178831] NPE-B: firmware functionality 0x2, revision 0x2:1 [ 43.209983] device eth0 entered promiscuous mode [ 43.49] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready While on a working system as I found in Chinese forum ir should probably be: eth0: MII PHY 16 on NPE-B eth0: MII PHY 17 on NPE-B eth0: MII PHY 18 on NPE-B eth0: MII PHY 19 on NPE-B eth1: MII PHY 1 on NPE-C NPE-B: firmware functionality 0x2, revision 0x2:1 eth0: link down device eth0 entered promiscuous mode firmware: requesting NPE-C NPE-C: firmware functionality 0x5, revision 0x2:1 No received/sent packets on br-lan and eth0 before and after modprobe mv88e6060.ko. Thanks, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] MV88E6060 switch
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello, Linksys WRT300N v2.0 has Marvell 88e6060 switch. But ixp4xx arch does not have its driver enabled (ar71xx has it). I added CONFIG_NET_DSA_MV88E6060=m, but when I modprobe mv88e6060.ko, nothing happens. It seems driver does not hook on any hardware: # lsmod|grep mv dsa_core7693 1 mv88e6060 mv88e6060 1902 0 I would like to have working ethernet on WRT300N. Or is it possible without mv88e6060? I found in some Chinese forum that people got it working, but no info how it was done. Regards, Nerijus --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] amips/rt288x 17.01.2 missing
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, it seems like rt288x is completely missing from the 17.01.2 download pages (ie. https://downloads.lede-project.org/releases/17.01.2/targets/ramips) it was there for 17.01.1 BTW. Could someone please investigate the reason it's missing and remedy it. The device page (https://lede-project.org/toh/hwdata/airlink101/airlink101_ar670w) includes updated firmware download links which, obviously, do NOT resolve. Regards. --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] apm821xx: MR24: fix ethernet phy detection on the MR24
ernet has no link, the phy detection fails, and eth0 is not
+|created. Plugging ethernet later has no effect, because there is no
+|interface as far as the kernel is concerned. The relevant part of
+|the boot log looks like this:
+|this is the failing case:
+|
+|[0.876611] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
+|[0.882532] /plb/opb/ethernet@ef600c00: reset timeout
+|[0.888546] /plb/opb/ethernet@ef600c00: can't find PHY!
+|and the succeeding case:
+|
+|[0.876672] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
+|[0.883952] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:..
+|[0.890822] eth0: found Atheros 8035 Gigabit Ethernet PHY (0x01)
+
+Based on the comment and the commit message of
+commit 23fbb5a87c56 ("emac: Fix EMAC soft reset on 460EX/GT").
+This is because the AR8035 PHY doesn't provide the TX Clock,
+if the ethernet cable is not attached. This causes the reset
+to timeout and the PHY detection code in emac_init_phy() is
+unable to detect the AR8035 PHY. As a result, the emac driver
+bails out early and the user left with no ethernet.
+
+In order to stay compatible with existing configurations, the driver
+tries the current reset approach at first. Only if the first attempt
+timed out, it does perform one more retry with the clock input
+temporarily switched to the internal clock source for just the
+duration of the reset.
+
+LEDE-Bug: #687 <https://bugs.lede-project.org/index.php?do=details&task_id=687>
+
+Cc: Chris Blake
+Reported-by: Russell Senior
+Fixes: 23fbb5a87c56e98 ("emac: Fix EMAC soft reset on 460EX/GT")
+Reviewed-by: Andrew Lunn
+Signed-off-by: Christian Lamparter
+---
+ drivers/net/ethernet/ibm/emac/core.c | 26 ++
+ 1 file changed, 22 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/ethernet/ibm/emac/core.c
b/drivers/net/ethernet/ibm/emac/core.c
+@@ -352,6 +352,7 @@ static int emac_reset(struct emac_instan
+ {
+ struct emac_regs __iomem *p = dev->emacp;
+ int n = 20;
++ bool __maybe_unused try_internal_clock = false;
+
+ DBG(dev, "reset" NL);
+
+@@ -364,6 +365,7 @@ static int emac_reset(struct emac_instan
+ }
+
+ #ifdef CONFIG_PPC_DCR_NATIVE
++do_retry:
+ /*
+* PPC460EX/GT Embedded Processor Advanced User's Manual
+* section 28.10.1 Mode Register 0 (EMACx_MR0) states:
+@@ -371,10 +373,19 @@ static int emac_reset(struct emac_instan
+* of the EMAC. If none is present, select the internal clock
+* (SDR0_ETH_CFG[EMACx_PHY_CLK] = 1).
+* After a soft reset, select the external clock.
++ *
++ * The AR8035-A PHY Meraki MR24 does not provide a TX Clk if the
++ * ethernet cable is not attached. This causes the reset to timeout
++ * and the PHY detection code in emac_init_phy() is unable to
++ * communicate and detect the AR8035-A PHY. As a result, the emac
++ * driver bails out early and the user has no ethernet.
++ * In order to stay compatible with existing configurations, the
++ * driver will temporarily switch to the internal clock, after
++ * the first reset fails.
+*/
+ if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX)) {
+- if (dev->phy_address == 0x &&
+- dev->phy_map == 0x) {
++ if (try_internal_clock || (dev->phy_address == 0x &&
++ dev->phy_map == 0x)) {
+ /* No PHY: select internal loop clock before reset */
+ dcri_clrset(SDR0, SDR0_ETH_CFG,
+ 0, SDR0_ETH_CFG_ECS << dev->cell_index);
+@@ -392,8 +403,15 @@ static int emac_reset(struct emac_instan
+
+ #ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX)) {
+- if (dev->phy_address == 0x &&
+- dev->phy_map == 0x) {
++ if (!n && !try_internal_clock) {
++ /* first attempt has timed out. */
++ n = 20;
++ try_internal_clock = true;
++ goto do_retry;
++ }
++
++ if (try_internal_clock || (dev->phy_address == 0x &&
++ dev->phy_map == 0x)) {
+ /* No PHY: restore external clock source after reset */
+ dcri_clrset(SDR0, SDR0_ETH_CFG,
+ SDR0_ETH_CFG_ECS << dev->cell_index, 0);
--
2.1.4
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] prosody package missing on i386 for lede-17.01
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Are there any reason why does the package prosody is missing for the following x86 targets? packages-17.01/i386_geode packages-17.01/i386_i486/ packages-17.01/i386_pentium packages-17.01/i386_pentium4 --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] base-files: nand: use CI_KERNPART whenever the kernel volume is needed
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This patch is in continuation of: commit 93aa86040523
"procd: nand: make it possible to configure kernel and ubi partition"
The $CI_KERNPART variable should be used in place
of the fixed "kernel" partition name. This allows
targets to specifiy alternate names for the kernel
partition.
Cc: Chris Blake
Signed-off-by: Christian Lamparter
---
package/base-files/files/lib/upgrade/nand.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/nand.sh
b/package/base-files/files/lib/upgrade/nand.sh
index 894964e178..6b2bdba256 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -142,7 +142,7 @@ nand_upgrade_prepare_ubi() {
}
fi
- local kern_ubivol="$( nand_find_volume $ubidev kernel )"
+ local kern_ubivol="$( nand_find_volume $ubidev $CI_KERNPART )"
local root_ubivol="$( nand_find_volume $ubidev rootfs )"
local data_ubivol="$( nand_find_volume $ubidev rootfs_data )"
@@ -157,13 +157,13 @@ nand_upgrade_prepare_ubi() {
fi
# kill volumes
- [ "$kern_ubivol" ] && ubirmvol /dev/$ubidev -N kernel || true
+ [ "$kern_ubivol" ] && ubirmvol /dev/$ubidev -N $CI_KERNPART || true
[ "$root_ubivol" ] && ubirmvol /dev/$ubidev -N rootfs || true
[ "$data_ubivol" ] && ubirmvol /dev/$ubidev -N rootfs_data || true
# update kernel
if [ "$has_kernel" = "1" ]; then
- if ! ubimkvol /dev/$ubidev -N kernel -s $kernel_length; then
+ if ! ubimkvol /dev/$ubidev -N $CI_KERNPART -s $kernel_length;
then
echo "cannot create kernel volume"
return 1;
fi
@@ -270,7 +270,7 @@ nand_upgrade_tar() {
local ubidev="$( nand_find_ubi "$CI_UBIPART" )"
[ "$has_kernel" = "1" ] && {
- local kern_ubivol="$(nand_find_volume $ubidev kernel)"
+ local kern_ubivol="$(nand_find_volume $ubidev $CI_KERNPART)"
tar xf $tar_file sysupgrade-$board_name/kernel -O | \
ubiupdatevol /dev/$kern_ubivol -s $kernel_length -
}
--
2.11.0
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] ipq806x: Add support for ipq40xx AP-DK01.1-C1 and AP-DK04.1-C1
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Tuesday, May 23, 2017 12:41:41 PM CEST Ram Chandra Jangir wrote:
> On Freitag, Monday, May 22, 2017 7:22 PM Sven Eckelmann wrote:
> >On Freitag, 21. April 2017 00:25:37 CEST Ram Chandra Jangir wrote:
> > +@@ -419,18 +424,19 @@
> > + status = "disabled";
> > +
> > + gmac0: gmac0 {
> > + local-mac-address = [00 00 00 00 00 00];
> > +- vlan_tag = <1 0x1f>;
> > +- };
> > +-
> > +- gmac1: gmac1 {
> > +- local-mac-address = [00 00 00 00 00 00];
> > + qcom,phy_mdio_addr = <4>;
> > + qcom,poll_required = <1>;
> > + qcom,forced_speed = <1000>;
> > + qcom,forced_duplex = <1>;
> > + vlan_tag = <2 0x20>;
> > + };
> > ++
> > ++ gmac1: gmac1 {
> > ++ local-mac-address = [00 00 00 00 00 00];
> > ++ qcom,poll_required_dynamic = <1>;
> > ++ vlan_tag = <1 0x1e>;
> > ++ };
>
> >Why did you swap the gmac0 and gmac1 interface? I would guess that you have
> to fix the network setup for the other devices (qcom-ipq4019-rt-ac58u.dts,
> qcom- ipq4019-nbg6617.dts, qcom-ipq4019-fritz4040.dts) when you do that.
>
> >Kind regards,
> > Sven
>
> Thanks Sven,
>
> Normally we configure gmac0 for WAN group and gmac1 for LAN group,
> existing ipq806x boards are also following the same, and we would like to
> continue with the same convention. I do not see any reason to deviate this
> in ipq40xx based boards.
>
> I agree that ac58u nbg6617 and fritz4040 needs some changes, and Christian
> can help us to make the same.
No. I commented on this issue in v1 of this patch:
<https://www.mail-archive.com/lede-dev@lists.infradead.org/msg07018.html>
| For the record: eth1 IS NOT a separate MAC. From what I can tell, the
| essedma driver just maps different VLANs to multiple ethX instances.
| So both eth0 and eth1 share the same PSGMII link to the QCA8075.
| Therefore I suggest to let the kernel handle the VLAN and switch to:
|
|ucidef_add_switch "switch0" \
|"0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan"
|
|(the ucidef_set_interfaces_lan_wan gets removed)
|
|This will create eth0.1 and eth0.2 instead of eth0 and eth1.
|I've already tested this and made a patch:
|<https://github.com/chunkeey/LEDE-IPQ40XX/commit/608803737f1c072d3be141f5d8561bc8dd9a4c2d>
| [@John, I think this should fix the weird VLAN issues you had with your box]
|(I'm waiting for AP devices with a AR8036 to see how they behave here)
There's no GMAC1/eth1. it's just a virtual construct in the
essedma driver that is not upstreamable. I think any time
spent on reassigning, renaming or rearranging these custom
properties: vlan_tags, phy-mdio-addr, ... is better spend elsewhere...
Like:
- adding qca8075 support to the existing qca8k driver.
From what I know John is looking into this.
- writing a proper DSA driver for the internal ess-switch (1).
- remove cruft from essedma and get everything upstream.
(1): Chris Blake picked up an Meraki MR33. The MR33 only has a
single PHY chip: QCA8033. It's PHY ID matches the ar8035 and it
is supported by the at803x driver.
However, he ran into a big issue with the current ar40xx.c code.
The internal ess-switch does not have a working autoneg for connected
single PHYs. Meraki solved this by polling the QCA8033's MII status
register and forcing the ess-switch's port to match its speed and
duplex setting. This will need to be addressed as well!
Thanks,
Christian
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] firmware: add firmware for rtl8821ae support
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- add needed firmware to support rtl8821ae pcie adapter Signed-off-by: Hans Ulli Kroll --- package/firmware/linux-firmware/realtek.mk | 8 1 file changed, 8 insertions(+) diff --git a/package/firmware/linux-firmware/realtek.mk b/package/firmware/linux-firmware/realtek.mk index 8c3770eeea..fdd92c9a42 100644 --- a/package/firmware/linux-firmware/realtek.mk +++ b/package/firmware/linux-firmware/realtek.mk @@ -55,3 +55,11 @@ define Package/rtl8192su-firmware/install $(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8712u.bin $(1)/lib/firmware/rtlwifi endef $(eval $(call BuildPackage,rtl8192su-firmware)) + +Package/rtl8821ae-firmware = $(call Package/firmware-default,RealTek RTL8821AE firmware) +define Package/rtl8821ae-firmware/install + $(INSTALL_DIR) $(1)/lib/firmware/rtlwifi + $(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8821aefw.bin $(1)/lib/firmware/rtlwifi + $(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8821aefw_wowlan.bin $(1)/lib/firmware/rtlwifi +endef +$(eval $(call BuildPackage,rtl8821ae-firmware)) -- 2.13.0 --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.9 to 4.9.28
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Compile and run tested on ipq8064. Regards, A. Benz On 05/15/17 19:11, Koen Vandeputte wrote: - Refresh all patches - Removed upstreamed - Adapted 1 Compile tested on: bcm53xx, cns3xxx, imx6 Run tested on: cns3xxx & imx6 Signed-off-by: Koen Vandeputte --- 3rd & final attempt to bump the kernel. I would be very grateful if more people could test it on different targets. include/kernel-version.mk | 4 +- .../802-usb-xhci-force-msi-renesas-xhci.patch | 2 +- ...stmmac-Disable-frame-filtering-completely.patch | 4 +- ...stmmac-Disable-frame-filtering-completely.patch | 4 +- ...X-Add-back-handler-ignoring-external-impr.patch | 75 ...-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch | 41 --- ...ave-host-bridge-window-resource-in-struct.patch | 131 - ...-add-support-for-performing-fake-doorbell.patch | 10 +- .../patches-4.9/905-BCM53573-minor-hacks.patch | 2 +- .../patches-4.9/950-0031-Add-dwc_otg-driver.patch | 2 +- ...-thermal-driver-for-reporting-core-temper.patch | 2 +- ...le-CONFIG_MEMCG-but-leave-it-disabled-due.patch | 4 +- ...-Fix-hang-for-writing-messages-larger-tha.patch | 90 -- .../031-ubifs-fix-RENAME_WHITEOUT-support.patch| 25 .../040-01-MIPS-Introduce-irq_stack.patch | 70 --- ...2-MIPS-Stack-unwinding-while-on-IRQ-stack.patch | 42 --- ...hange-28-to-thread_info-if-coming-from-us.patch | 48 ...IPS-Switch-to-the-irq_stack-in-interrupts.patch | 116 -- ...05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch | 21 ...ack-Fix-erroneous-jal-to-plat_irq_dispatc.patch | 35 -- ...part-fix-parsing-first-block-after-aligne.patch | 40 --- .../patches-4.9/630-packet_socket_type.patch | 4 +- .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch | 22 ++-- ...jecting-with-source-address-failed-policy.patch | 22 ++-- .../generic/patches-4.9/701-phy_extension.patch| 2 +- .../710-phy-add-mdio_register_board_info.patch | 2 +- .../810-pci_disable_common_quirks.patch| 6 +- .../generic/patches-4.9/904-debloat_dma_buf.patch | 2 +- ...sdhc-imx-increase-the-pad-I-O-drive-stren.patch | 42 --- .../patches-4.9/0032-phy-add-qcom-dwc3-phy.patch | 2 +- ...om-use-scm_call-to-route-GPIO-irq-to-Apps.patch | 2 +- .../0008-MIPS-lantiq-backport-old-timer-code.patch | 2 +- .../patches-4.9/0026-NET-multi-phy-support.patch | 6 +- ...-lantiq-wifi-and-ethernet-eeprom-handling.patch | 2 +- .../patches-4.9/0001-NET-multi-phy-support.patch | 6 +- ...soc-mediatek-Add-MT2701-power-dt-bindings.patch | 10 +- ...k-Refine-scpsys-to-support-multiple-platf.patch | 19 ++- ...015-soc-mediatek-Add-MT2701-scpsys-driver.patch | 12 +- .../patches-4.9/0071-pwm-add-pwm-mediatek.patch| 16 +-- .../linux/mediatek/patches-4.9/0083-mfd-led3.patch | 4 +- .../mediatek/patches-4.9/0085-pmic-led0.patch | 3 - .../mediatek/patches-4.9/0086-pmic-led1.patch | 4 +- .../mediatek/patches-4.9/0087-pmic-led2.patch | 10 +- .../mediatek/patches-4.9/0088-pmic-led3.patch | 4 +- target/linux/mediatek/patches-4.9/0091-dsa1.patch | 3 - .../0091-net-next-mediatek-fix-DQL-support.patch | 6 +- target/linux/mediatek/patches-4.9/0092-dsa2.patch | 23 +--- target/linux/mediatek/patches-4.9/0092-dsa3.patch | 6 +- target/linux/mediatek/patches-4.9/0092-dsa4.patch | 4 +- target/linux/mediatek/patches-4.9/0092-dsa5.patch | 16 +-- .../mediatek/patches-4.9/0093-dsa-compat.patch | 18 +-- .../mediatek/patches-4.9/0094-net-affinity.patch | 12 +- target/linux/mediatek/patches-4.9/0095-ephy.patch | 12 +- .../mediatek/patches-4.9/0096-dsa-multi-cpu.patch | 30 ++--- .../mediatek/patches-4.9/0097-dsa-mt7530.patch | 6 +- ...erpc-85xx-add-gpio-keys-to-of-match-table.patch | 2 +- .../100-powerpc-85xx-tl-wdr4900-v1-support.patch | 4 +- ...ovide-a-hook-for-link-up-link-down-events.patch | 18 +-- ...-phy-move-phy-MMD-accessors-to-phy-core.c.patch | 2 +- ...oid-setting-unsupported-EEE-advertisments.patch | 2 +- ...tart-phy-autonegotiation-after-EEE-advert.patch | 2 +- ...-phy-allow-EEE-with-SGMII-interface-modes.patch | 2 +- ...hook-up-clause-45-autonegotiation-restart.patch | 2 +- ...-phy-export-phy_start_machine-for-phylink.patch | 2 +- .../patches-4.9/0034-NET-multi-phy-support.patch | 6 +- .../patches-4.9/200-rt3883-fix-pinctrl-typo.patch | 21 66 files changed, 141 insertions(+), 1030 deletions(-) delete mode 100644 target/linux/bcm53xx/patches-4.9/031-ARM-BCM5301X-Add-back-ha
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sun, May 14, 2017 at 10:13 PM, Sven Roederer wrote:
> On Sonntag, 14. Mai 2017 21:22:42 CEST Sven Roederer wrote:
>>
>> I removed the 03_gpio_export and added this to the dts:
>> gpio_export {
>> compatible = "gpio-export";
>> #size-cells = <0>;
>>
>> poe_passthrough {
>> gpio-export,name = "poe_power_port0";
>> gpio-export,output = <1>;
>> gpios = <&gpio0 496 0>;
>> };
>> };
>>
>> But booting this kernel gives:
>> [1.66] [ cut here ]
>> [1.67] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:85
>> 0x801dc2fc()
>> [1.68] invalid GPIO -22
>> [1.69] Modules linked in:
>> [1.69] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
>> [2.12] ---[ end trace ceab04cd8881362f ]---
>> [2.13] gpiod_request: invalid GPIO
>> [2.14] gpio-export gpio_export: 0 gpio(s) exported
>>
>>
>> I'm wondering on the "GPIO -22". Checking the source of
>> drivers/gpio/gpiolib.c shows gpio is of type unsigned, large enough to
>> handle gpio#496.
>>
>> Any Idea what's going on?
>> Probably it's something related to the SoC-gpios and the additional pins
>> defined from the pca9555
>>
>
> When using the following dts-file it improves, a bit:
> / {
> model = "UBNT-ERX-SFP";
>
> i2c-gpio {
> compatible = "i2c-gpio";
> gpios = <&gpio0 3 GPIO_ACTIVE_HIGH /* sda */
> &gpio0 4 GPIO_ACTIVE_HIGH /* scl */
> >;
> #address-cells = <1>;
> #size-cells = <0>;
>
> gpio_pca: pca9555@25 {
> compatible = "pca9555";
> reg = <0x25>;
you seem to be missing two properties here which indicate that this is
actually a GPIO controller:
#gpio-cells = <2>;
gpio-controller;
value 2 in #gpio-cells means that whenever you reference a GPIO (just
like you do in your poe_passthrough node) that the first parameter is
the pin number and the second parameter is the polarity (active
high/low)
gpio-controller should be self-explanatory
> };
> };
>
> gpio_export {
> compatible = "gpio-export";
> #size-cells = <0>;
>
> poe_passthrough {
> gpio-export,name = "poe_power_port0";
> gpio-export,output = <1>;
> gpios = <&gpio_pca 0 0>;
> };
>
> };
> };
>
> I think I got the trick to define a name for the PCA-gpio-chip and
> reference it in the gpio-export section.
> But it fails now with
> [ 1.64] /gpio_export/poe_passthrough: could not get #gpio-cells for
> /i2c-gpio/pca9555@25
> [1.66] [ cut here ]
> [1.67] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:85
> 0x801dc2fc()
> [ 1.68] invalid GPIO -22
> [ 1.69] Modules linked in:
> [ 1.69] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
>
> seems not to find the i2c-pca and it's gpios, as these modules are not
> compile into the kernel.
> [ 10.46] kmodloader: loading kernel modules from /etc/modules.d/*
> [ 10.47] i2c /dev entries driver
> [ 10.48] pca953x 0-0025: interrupt support not compiled in
> [ 10.50] i2c-gpio i2c-gpio: using pins 3 (SDA) and 4 (SCL)
> [ 10.51] PPP generic driver version 2.4.2
>
> They will load during init.scripts.
> I see following options:
> - use the 03-gpio script in board.d
> - compile the drivers into the kernel, but will this be done for all
> mt7621-kernels?
>
>
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello Ram, On Thursday, May 11, 2017 8:39:46 PM CEST Christian Lamparter wrote: > On Thursday, May 11, 2017 10:15:58 PM CEST Ram Chandra Jangir wrote: > > I added nand pinmux in https://patchwork.ozlabs.org/patch/761243/ , > > Could you please try with this, if it helps you. > Thanks, I'll forward it to Chris Blake. He can test it once > he returns. I'll let you know how it turned out. Chris reported: [1.40] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1 [1.007580] nand: AMD/Spansion S34ML01G2 [1.014146] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [1.018135] 11 ofpart partitions found on MTD device qcom_nand.0 [1.025449] Creating 11 MTD partitions on "qcom_nand.0": so, it's working now. Regards, Christian --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello Ram, On Thursday, May 11, 2017 10:15:58 PM CEST Ram Chandra Jangir wrote: > I added nand pinmux in https://patchwork.ozlabs.org/patch/761243/ , > Could you please try with this, if it helps you. Thanks, I'll forward it to Chris Blake. He can test it once he returns. I'll let you know how it turned out. Regards, Christian --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Who among our resident young-timers knows XMMS? Once upon a time this was a household name (FOSS folks houses). Now I reckon those who use it as a primary player do it for nostalgia. Likewise, OpenWRT while more recognizable than LEDE, is not worth as much as people here paint it, and will only remain relevant as long as people keep using it. Market/brand concept (in retail) doesn't really apply. Indifferent what name this project ends up using, just that LEDE (Linux Embedded Dev. Environment) expands the scope beyond routers, and breaks free from the "WRT" implication of wireless routers (does LEDE still have any of the original WRT source release by linksys?). LEDE sounds more fitting and gives the impression of a proper distro, which it is, rather than an improved fork/clone of an ancient source dump. No biggie, just thought I'd chime in. Good luck all. Regards, A. Benz On 05/09/17 09:33, Eric Luehrsen wrote: From a raw objective stand, OpenWrt has better market value as a brand. Its longer lived on the net and more unique audibly. If we surveyed 1000 somewhat technical people, then we would have way more recognition hits. I realize the vote concluded already, but hopefully this thought helps ease some less happy minds. --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] Add missing packages for WeVO 11AC NAS
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- mt7621.mk does not include all required packages for WeVO 11AC NAS, so official image does not support 5GHz WiFi(mt76x2) out of the box. This patch fixes that. --- target/linux/ramips/image/mt7621.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 733fb08..f5e5b34 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -30,7 +30,9 @@ define Device/11acnas DTS := 11ACNAS IMAGE_SIZE := $(ralink_default_fw_size_16M) DEVICE_TITLE := WeVO 11AC NAS Router - DEVICE_PACKAGES := kmod-mt7603 kmod-usb3 kmod-usb-ledtrig-usbport wpad-mini + DEVICE_PACKAGES := \ + kmod-mt7603 kmod-mt76x2 kmod-usb3 kmod-usb-ledtrig-usbport kmod-mt76 \ + wpad-mini endef TARGET_DEVICES += 11acnas -- 2.1.4 --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello, On Friday, May 5, 2017 9:19:36 PM CEST Ram Chandra Jangir wrote: > This change add nand boot support for IPQ40xx based > AP-DK04.1-C1 board using ubi image, also add sysupgrage > support for AP-DK04.1-C1 and generates a sysupgrade.tar > image. > > Testing: > *Tested on IPQ40xx AP-DK04.1-C1 and IPQ806x AP148 Board: > a. NAND boot > b. ubi sysupgrade > > Signed-off-by: Ram Chandra Jangir Thanks for posting this. Chris Blake is currently in the process of adding the Cisco Meraki MR33. <https://github.com/riptidewave93/LEDE-MR33> The MR33 uses the IPQ4029 and has just a Spansion S34ML01G200TFV00 128MiB NAND Flash for storage. He reported that with this patch attached. The driver is loading, but it can't access the nand: [0.860703] nand: second ID read did not match 7f,7f against 01,71 [0.861633] nand: No NAND device found The id is supposed to be 01 (manuf = Spanion), f1 (128MiB). both readings are bad. I think this is caused by two problems: 1. 7f, 7f should be 0xff, 0xff. 0x71 should be 0xf1. 2. It seems that the NAND chip was not ready on the first read. I strongly suspect (due to the MSB error for BIT 7), that at least one I/O line is missing due to a bad pinctrl/mux setup. Could you please add the pinctrl nand definitions to the dts so he can test again? Regards, Christian --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] ipq806x: Add support for ipq40xx subtarget
19-ap.dk04.1.dtsi
> > +@@ -161,5 +182,56 @@
> > + watchdog@b017000 {
> > + status = "ok";
> > + };
> > ++
> > ++ ess-switch@c00 {
> > ++ status = "ok";
> > ++ switch_mac_mode = <0x0>; /* mac mode for RGMII RMII */
> > ++ switch_initvlas = <
> > ++ 0x0007c 0x54 /* PORT0_STATUS */
> > ++ >;
> > ++ led_source@0 {
> > ++ led = <0x3>; /*led number */
> > ++ source = <0x1>; /*source id 1 */
> > ++ mode = "normal"; /*on,off,blink,normal */
> > ++ speed = "all"; /*10M,100M,1000M,all */
> > ++ freq = "auto"; /*2Hz,4Hz,8Hz,auto*/
> > ++ };
> [...]
> >Just a heads up: I had to add a "gpio-controller" to the ar40xx driver.
> >This was necessary, because the AVM FritzBox 4040 uses one of the switch
> LEDs to enable the power of both USB ports.
> >(Off-topic: Yes, the usb power will "blink" for a few seconds during boot
> :-D )
Also, where does this led_source node get parsed?
> > +diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi
> > +b/arch/arm/boot/dts/qcom-ipq4019.dtsi
> > +index 7013c85..9793611 100644
> > +--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
> > b/arch/arm/boot/dts/qcom-ipq4019.dtsi
> > +@@ -325,43 +325,47 @@
> > +
> > + mdio@9 {
> > + #address-cells = <1>;
> > +- #size-cells = <0>;
> > ++ #size-cells = <1>;
> #size-cells = <0>;
> >you don't have any size cells in the subnodes.
> [Ram]: Yes, you are right. It seems 0 is better. will add it in next patch.
Don't forget to update the device tree binding documentation as well.
> > +@@ -378,57 +384,58 @@
> > + compatible = "qcom,ess-edma";
> > + reg = <0xc08 0x8000>;
> > + qcom,page-mode = <0>;
> > +- qcom,rx_head_buf_size = <1540>;
> > +- qcom,mdio_supported;
> > +- qcom,poll_required = <1>;
> > +- qcom,num_gmac = <2>;
> > +- interrupts = <0 65 IRQ_TYPE_EDGE_RISING
> [...]
> > +-0 255 IRQ_TYPE_EDGE_RISING>;
> > ++ qcom,rx-head-buf-size = <1540>;
> > ++ qcom,num-gmac = <2>;
> >Technically, the essedma has only one. See the VLAN comment above.
> [Ram]: There are two groups in dakota boards, one is LAN group and second
> is WAN group. num-gmac tells number of groups to be created, which is
> currently set to 2.
VLAN configuration is done by userspace. The secondary (tertiary, ...) MACs
are just a virtual MACs for VLAN and nothing else. The kernel already does VLAN
for you. Please, do not waste resources for this. The essedma driver allocates
a full rx receive ring for these virtual MACs too and this is problem for 128
MiB
RAM devices like the Asus RT-AC58U.
> > + local-mac-address = [00 00 00 00 00 00];
> > +- vlan_tag = <1 0x1f>;
> > ++ qcom,phy-mdio-addr = <4>;
> > ++ qcom,poll-required = <1>;
> > ++ qcom,poll-required-dynamic = <1>;
> > ++ qcom,forced-speed = <1000>;
> > ++ qcom,forced-duplex = <1>;
> > ++ vlan-tag = <2 0x20>;
> >Ideally, fixed-link should be used instead of custom "force-speed".
> [Ram]: I think both should be same, just different way to define it.
Well, you could try to mark them (qcom,forced-speed, qcom,forced-duplex)
as deprecated. Altough, Rob or Mark will probably tell you to remove
those, since the essedma node isn't present in the upstream kernel.
> >The custom VLAN stuff ( phy-mdio-addr, vlan_tag) should be removed.
> >The userspace will deal with setting up the switch.
> [Ram]: User can setup the switch but here are some default values
> populated. Vlan tag for WAN group is 2, for LAN group is 1. This is
> pre-determined and populated with default values here. This can be
> changed from user space too. phy-mdio-addr is for enabling WAN link
> detection.
VLAN configuration is performed by userspace. Of course, if you want,
you can
Re: [LEDE-DEV] [PATCH 2/2] ipq806x: Add support for ipq40xx subtarget
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Thursday, April 13, 2017 8:40:30 PM CEST Ram Chandra Jangir wrote: > This change adds QCA IPQ40xx SoC based board support > > Supported IPQ40xx boards: > - AP-DK01.1-C1 and AP-DK04.1-C1 with nor flash boot. This is Great. There are several users which are waiting for DK04. On is the Compex WPJ428. There are several remaining issues with it: - The USB 3.0 does not work on his board and is downgraded to USB 2.0. It's working on the FB4040 and RT-AC58U though. This is what the user sees on the WPJ428: [ 30.614478] usb 1-1: new high-speed USB device number 3 using xhci-hcd [ 31.356496] xhci-hcd xhci-hcd.0.auto: Cannot set link state. [ 31.357151] usb usb2-port1: cannot disable (err = -32) Can you please check the usb port functionality on your board too? - the board fails to reboot / restart. The WPJ428 LEDE-Image will just freeze. The FB4040 and RT-AC58U doesn't have no issue though and neither does the Stock Image. Can you please check, if this is working with your image? > --- > diff --git a/target/linux/ipq806x/Makefile b/target/linux/ipq806x/Makefile > index 5a5551c..b5b36e1 100644 > --- a/target/linux/ipq806x/Makefile > +++ b/target/linux/ipq806x/Makefile > @@ -21,7 +21,7 @@ DEFAULT_PACKAGES += \ > kmod-ata-core kmod-ata-ahci kmod-ata-ahci-platform \ > kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport \ > kmod-usb3 kmod-usb-dwc3-of-simple kmod-usb-phy-qcom-dwc3 \ > - kmod-ath10k wpad-mini \ > + kmod-ath10k wpad-mini kmod-switch-ar40xx kmod-ipq40xx-edma \ the switch and edma driver are already part of the default image. Why do you want to have them as separate packages? > diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network > b/target/linux/ipq806x/base-files/etc/board.d/02_network > index 36e0fb3..082105a 100755 > --- a/target/linux/ipq806x/base-files/etc/board.d/02_network > +++ b/target/linux/ipq806x/base-files/etc/board.d/02_network > @@ -48,6 +48,12 @@ nbg6817) > ucidef_set_interface_macaddr "lan" "$hw_mac_addr" > ucidef_set_interface_macaddr "wan" "$(macaddr_add $hw_mac_addr 1)" > ;; > +ap-dk01.1-c1|\ > +ap-dk04.1-c1) > + ucidef_set_interfaces_lan_wan "eth1" "eth0" > + ucidef_add_switch "switch0" \ > + "0t@eth1" "1:lan" "2:lan" "3:lan" "4:lan" > + ;; For the record: eth1 IS NOT a separate MAC. From what I can tell, the essedma driver just maps different VLANs to multiple ethX instances. So both eth0 and eth1 share the same PSGMII link to the QCA8075. Therefore I suggest to let the kernel handle the VLAN and switch to: ucidef_add_switch "switch0" \ "0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan" (the ucidef_set_interfaces_lan_wan gets removed) This will create eth0.1 and eth0.2 instead of eth0 and eth1. I've already tested this and made a patch: <https://github.com/chunkeey/LEDE-IPQ40XX/commit/f4c1345f73bb63d7c5b9acc7e766c18b071c7885> [@John, I think this should fix the weird VLAN issues you had with your box] (I'm waiting for AP devices with a AR8036 to see how they behave here) > diff --git > a/target/linux/ipq806x/patches-4.9/851-dts-ipq40xx-Add-support-for-spi-nor-32-MB-flash-and-.patch > > b/target/linux/ipq806x/patches-4.9/851-dts-ipq40xx-Add-support-for-spi-nor-32-MB-flash-and-.patch > new file mode 100644 > index 000..5753f10 > --- /dev/null > +++ > b/target/linux/ipq806x/patches-4.9/851-dts-ipq40xx-Add-support-for-spi-nor-32-MB-flash-and-.patch > @@ -0,0 +1,111 @@ > +From 5f07811771ad92a3413248a240eaedfee09ace93 Mon Sep 17 00:00:00 2001 > +From: Ram Chandra Jangir > +Date: Fri, 24 Mar 2017 14:00:00 +0530 > +Subject: [PATCH] dts: ipq40xx: Add support for spi nor 32 MB flash and enable > + wifi support > + > +- Add micron n25q128a11 spi nor 32MB flash and fixes spi nodes > + to work on DK01 and DK04 boards. > +- Add support for default SPI configuration > +- Enable and fixed WiFi nodes to work with DK boards > + > +Signed-off-by: Ram Chandra Jangir > +--- > +[...] > +diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi > b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi > +index 768a2a4..2a5cc5e 100644 > +--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi > b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi > +@@ -81,13 +81,16 @@ > +
Re: [LEDE-DEV] Planning v17.01.1
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 04/09/2017 04:14 PM, Jo-Philipp Wich wrote: Hi, I'd like to start preparing the v17.01.1 release during the upcoming week with the goal to release final binaries during the easter holidays (~14.04. - 17.04.). You can find the current list of changes since v17.01.0 at https://lede-project.org/releases/17.01/changelog-17.01.1 If you want specific fixes cherry-picked/backported to lede-17.01, please mention them in a reply to this mail. Great! Please enable CONFIG_KERNEL_DIRECT_IO option by default when building next release kernel so that mdadm RAID can be used without re-compiling a custom image. I had spent a few hours before figuring out that mdadm lede package can't be used with stock kernel because the above option was missing, I think it is really misleading from a user point of view... For more details see: https://forum.lede-project.org/t/raid-not-working-after-update-lede-17-01-0-final-goflexnet/2500 https://bugs.lede-project.org/index.php?do=details&task_id=653 https://bugs.lede-project.org/index.php?do=details&task_id=648 thanks --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ARM64 platform updates
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello, On Tuesday, April 11, 2017 12:13:42 PM CEST Florian Fainelli wrote: > I am planning on switch the arm64 multiplatform target to 4.9 and remove > support for the ARM Foundation v8 model since QEMU is just nicer. > > Any objections? > No objections per se. But since you are already updating the arm64 target, why not also do the same to armvirt? After all, both are mostly virtual targets and from what I can tell, it's just ARMv8 vs ARMv7 (or maybe can these be folded into one?) Regards, Christian --- End Message --- _______ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Using stable wireless/kernel but trunk userspace/kernel
CONFIG_WEXT_PRIV is not set CONFIG_WATCHDOG_CORE=y +# CONFIG_WCN36XX is not set +# CONFIG_WIL6210 is not set +# CONFIG_WILC1000_SDIO is not set +# CONFIG_WILC1000_SPI is not set CONFIG_XPS=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_BCJ=y --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [AD] support me hacking on OpenWrt/LEDE
I think it's ok to make a open talk about ways to generate income for active and productive people without special expectations from the spender. Yes, we talk now directly, but while we now using german for our conversation. :-) Am 03.04.2017 um 22:34 schrieb David Lang: > May I suggest that you talk directly rather than through the mailing list? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [AD] support me hacking on OpenWrt/LEDE
Hi Daniel, as I already says: I think it was good way to payback the active community. So we talking about the possibility for you to continue your work on lede-project.org, but as an employer in our company. I have a the moment not enough time to a detailed answer your mail, but I can understand your concern. Our company is a "eierlegendewollmichsau". :-) We support Windows, Mac and do a lot of Linux-Stuff in background. We try to push proprietary solutions out and replace it with FLOSS (GPL) or minimal a opensource (BSD/MIT/...) solution. Our customer are small companies (KMU), these are flexible enough to try our way. We create stuff (but not only) like VPN, multi WAN, WLAN with multiple AP, directional radio links and similar with OpenWRT/LEDE. It was always a pain, but often the only way for our customer to get high-level functionality without CISCO and similar. If you can help us to provide better service, that would be great, but if you work only on important low-level stuff for LEDE (which I see here in this mailinglist) that is also ok for us. I shall write more today night, hope to decrease your concern. Cheers Benni Am 03.04.2017 um 12:05 schrieb Daniel Golle: > Hi Benni, > > On Mon, Apr 03, 2017 at 11:30:45AM +0200, lede-proj...@bepo.de wrote: >> Hello Daniel, >> >> I have explore the patreon site becauce I do not know it before. Short: >> I do not like this service at all (5% fee, only paypal/creditcard, ...) >> >> If you in Germany/Leipzig and a german citizen, so I can offer you an >> Midi-Job (witch include a health insurance). > > That'd be amazing, obviously :) > >> >> We use lot of openwrt (and freifunk) a couple of years (and try use LEDE >> now), so it was a good style for us to payback the active community. And >> IMHO better then collecting cash via patreon's "Klingelbeutel". > > For sure. I also try to avoid receiving payments through patreon, > but only a small fraction of the people who are supporting me right now > are from within the EU and hence have access to free SEPA transfers. > And if people provide $$$ outside of patreon I need to do all the paper > work (and when counting the hours for that 5% seems to be not too bad of > a deal...) > Some others offered sending bitcoin and such, which I for now refuse > because I don't even know how the boureaucracy (tax-wise) works in that > case, because they obviously want to remain anonymous and hence I can't > know their name and address and all that... > >> >> Our office is in Hamburg, but we want open a small office in Leipzig >> this year (asap). >> >> Is this a option for you, or is this a stupid idea? > > Depends on what you want me to do. The difference here is that patreon > allows me to do what I believe is important or fun to do and people > can reward me for that or just support me even for reasons beyond my > own understanding. A job, opposed to that, usually comes with quite > different expectations of the people who provide the cash. I usually > don't survive in those settings, because I'm not a very obediant > person (apparently so) and I simply cannot force myself to do things > which I don't believe in myself. If I try anyway, I very quickly get > very depressed, sick and angry, because I truely hate the outcomes of > most commercially motivated technological progress (such as selling > more useless stuff, knowing more about customers, brainwashing people > into mindless and ultra-dependent isolated consumers, ...) > Excuses like 'but we need to make a business somehow' don't count and > don't really increase my motivation... > Hence I shifted my commercial activity to work in kitchens most of > the time, because making good food doesn't contradict with my own will > and my expectations towards food seem to correlate with the taste and > expectations of the people entering the restaurant... Business-wise > that didn't work well, the restaurant had to close last year due to > increasing rent and labour costs (they payed minimum wage)... > > Anyway, all that may all sound too harsh and I don't even know what > your company is doing. Maybe it's totally what I believe would be great > to do and have on this planet, create a future which I'd want to live > in and so on... So please tell me more :) > > > Cheers > > > Daniel > > >> >> Cheers >> >> Benni >> >> Am 22.03.2017 um 11:22 schrieb Daniel Golle: >>> Hi everyone, >>> >>> most of you might know me for hacking on embedded stuff while having >>> the common good in mind. Because I'm practically always out of money, >>> I
Re: [LEDE-DEV] [AD] support me hacking on OpenWrt/LEDE
Hello Daniel, I have explore the patreon site becauce I do not know it before. Short: I do not like this service at all (5% fee, only paypal/creditcard, ...) If you in Germany/Leipzig and a german citizen, so I can offer you an Midi-Job (witch include a health insurance). We use lot of openwrt (and freifunk) a couple of years (and try use LEDE now), so it was a good style for us to payback the active community. And IMHO better then collecting cash via patreon's "Klingelbeutel". Our office is in Hamburg, but we want open a small office in Leipzig this year (asap). Is this a option for you, or is this a stupid idea? Cheers Benni Am 22.03.2017 um 11:22 schrieb Daniel Golle: > Hi everyone, > > most of you might know me for hacking on embedded stuff while having > the common good in mind. Because I'm practically always out of money, > I decided to setup a patreon account which can help me to gather at > least the $$$ needed to pay for obligatory health insurance and such > things. It'd be great if you spread the word and also give me feedback > (off-list!) so I can improve my patreon page. > > https://www.patreon.com/dangowrt > > > Cheers > > > Daniel > > ___ > 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] dnsmasq sometimes fails to start on 17.01.0
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 23/03/17 16:10, Gui Iribarren wrote: > Thanks both for the replies! > > I continued yeterday further debugging this, i played with this > particular number in /e/i/dnsmasq > (line 815 in http://pastebin.com/FV09f2jG) > > procd_add_raw_trigger "interface.*" 2000 /etc/init.d/dnsmasq reload > > this number, as the following link suggests > http://wiki.prplfoundation.org/wiki/Procd_reference#procd_add_raw_trigger.28event.2C_timeout.2C_.5Bscript.5D.29 > is the number of milliseconds that procd will wait after the trigger (in > this case, anything related to an "interface" AFAIU) before executing > "dnsmasq reload" > > i put 6 (60 seconds) and now the reload only happens once (after ~60 > seconds from the first "/e/i/dnsmasq boot") and dnsmasq starts without > problem > > so it looks to me like a race condition, where two "interface.*" events > are happening one after the other, triggering two consecutive reloads, > the first reload doesn't finish its work before the second reload comes, > and the second reload kills the first reload, and suicides itself for > some reason. > > setting a long raw_trigger timeout works around the problem because the > "interface.*" events happen all inside the 60 second window, and procd > runs "/e/i/dnsmasq reload" only once > > i can imagine that few people came across this since dnsmasq normally > takes less than 2 seconds to start, and so the first reload is already > done starting when the second reload is triggered. > > my added "sleeps" help reproduce the issue by artificially making > dnsmasq take always longer than 2 seconds, but without them the race > condition is still there, only it doesn't end badly every boot (only > some boots, and on some hardware) > > is this enough info to point the right direction for someone to look > into procd? (not me, not enough proficient in C, sorry) bump? i'm more than happy to do any more needed tests, given any pointer in the right direction > > (running two long "/e/i/dnsmasq reload" in parallel manually via > console, the second one doesn't kill the first one, which makes me think > that procd is the murderer) > > On 22/03/17 23:29, Yousong Zhou wrote: >> From the log, there are at least 4 runs of /etc/init.d/dnsmasq >> >> This is "/e/c/dnsmasq boot" and returns immediately because the script skips >> this phase and the dnsmasq service is expected to be brought up by interface >> trigger events >> >> root@coco:~# logread | grep dns >> Wed Mar 22 18:25:56 2017 user.notice root: guidebug dnsmasq init >> Wed Mar 22 18:25:56 2017 user.notice root: guidebug dnsmasq boot >> Wed Mar 22 18:25:56 2017 user.notice root: guidebug dnsmasq startsrv 1, >> Wed Mar 22 18:25:56 2017 user.notice root: guidebug dnsmasq srvtrg >> >> This one I do not have much clue about >> >> Wed Mar 22 18:25:57 2017 user.notice root: guidebug dnsmasq init >> >> This one was brought up by the interface trigger event. Your log stopped at >> "wait 18" without "wait 16" because the service_triggers call in the >> /e/c/dnsmasq has set the timeout of event handling to be 2000ms. That's how >> the logger and sleep call were impeding the process >> >> Wed Mar 22 18:26:06 2017 user.notice root: guidebug dnsmasq init >> Wed Mar 22 18:26:06 2017 user.notice root: guidebug dnsmasq reload >> Wed Mar 22 18:26:06 2017 user.notice root: guidebug dnsmasq startsrv , >> Wed Mar 22 18:26:06 2017 user.notice root: guidebug dnsmasq realstart >> cfg02411c wait 20 >> Wed Mar 22 18:26:08 2017 user.notice root: guidebug dnsmasq realstart >> cfg02411c wait 18 >> >> This one I also have no clue about. It didn't even make it to the >> "realstart" >> part. So checking further what happened in between was causing that should >> be >> helpful >> >> Wed Mar 22 18:26:10 2017 user.notice root: guidebug dnsmasq init >> Wed Mar 22 18:26:10 2017 user.notice root: guidebug dnsmasq reload >> Wed Mar 22 18:26:10 2017 user.notice root: guidebug dnsmasq startsrv , >> > --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 28/03/17 17:37, Daniel Golle wrote: > Hi Pau, > > On Tue, Mar 28, 2017 at 09:28:22PM +0200, Pau wrote: >> Hi. >> >> I am using the SDK and IB from LEDE 17.01.0 release (mips_24kc). I've >> been using it successfully the last days until now. I did not change >> anything but I get the error: >> >> * opkg_install_pkg: Package luci-lib-nixio sha256sum mismatch. Either >> the opkg or the package index are corrupt. Try 'opkg update'. >> >> Then I went to downloads.lede-project.org [1] and I see that there are >> new compiled packages with date "Tue Mar 28 18:35:15 2017". >> Luci-lib-nixio is one of them [2] (which now is published on the >> repository with a new version). > > Packages from the feeds and even base-packages (think: openssl) can > change after a release, just like for other distributions. i agree packages can and should be maintained, but in progressive releases. i.e. if i install ubuntu 12.04 today, i expect to have exactly the same system than what i got if i installed ubuntu 12.04 at the time of its release if i want to get the fixes that happened after the time of original 12.04 release, i'd install 12.04.1 or, install 12.04 and run "apt-get update && apt-get upgrade" the equivalent in lede would be ..."opkg update && opkg upgrade *"? but it doesn't even really make sense, given squashfs and so on. so i'm thinking out loud: wouldn't it make sense to leave the packages tree "frozen" at the time of release? and any updated packages compiled and dumped to a different feed, like 17.01-updates ? https://downloads.lede-project.org/releases/17.01-updates/packages/ i thought debian did something like this, but i just checked and the "jessie" dist *does* change over time (5 minutes ago i thought only "jessie-updates" changed) i must admit that after some thinking, i'm utterly confused, so will probably accept whatever reasoning anyone provides, all we want to do is create a firmware based on a specific LEDE release, and not fear that if we want to rebuild the exact same firmware in two months (or days!), we will get a different (broken) result :) > The error message you see more looks like being caused by inconsistent > Package index not matching the actual binaries. Maybe regenerating > the index can fix that...? > >> >> In the other hand the feeds.conf.default file included in the release >> SDK points to the specific commit >> a100738163585ae1edc24d832ca9bef1f34beef0 from Sat Jan 28 01:38:06 2017. >> The SDK published then is not consistent with the current package binary >> repositories. > > The SDK doesn't need to be consistent with all packages, but the fixed > commit (instead of a branch) is indeed misleading (and most likely got > rather political reasons, like not poluting a repo called > github.com/openwrt/packages with a branch called for-lede-17.01...) > >> >> So my question here is: what's the point for publishing a Release if the >> packages included are changing? Is this the expected behavior? > > Definitely not the expected behaviour, but packages may and should > change, eg. for bug or security fixes. > > > Cheers > > > Daniel > >> >> Thanks. >> >> [1] >> https://downloads.lede-project.org/releases/17.01.0/packages/mipsel_24kc/ >> [2] >> https://downloads.lede-project.org/releases/17.01.0/packages/mips_24kc/luci/luci-lib-nixio_git-17.073.42825-b47a21f-1_mips_24kc.ipk >> >> -- >> ./p4u >> > > > > >> ___ >> 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 > --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] stack trace: warning at .../sta_info.c:451 in LEDE 17.01.0
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 23/03/17 05:13, Koen Vandeputte wrote: > > > On 2017-03-23 02:30, Gui Iribarren via Lede-dev wrote: >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. >> >> >> ___ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev > > > ACK'ed from me. thanks! > I've also already seen this a lot. so, no misbehaviour at all, i understand. will it as a spurious warning. > > It seems to appear often when specifically using IBSS. > Looking at the code, it doesn't seem to do be a risk for a crash, as it > just drops the packet in this case. thanks a lot we had high hopes about moving on to ieee80211s, but hit blocking issues with it :( as soon as we solve them, will abandon IBSS https://lists.libremesh.org/pipermail/lime-dev/2017-March/000873.html > > Koen > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] dnsmasq sometimes fails to start on 17.01.0
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Thanks both for the replies! I continued yeterday further debugging this, i played with this particular number in /e/i/dnsmasq (line 815 in http://pastebin.com/FV09f2jG) procd_add_raw_trigger "interface.*" 2000 /etc/init.d/dnsmasq reload this number, as the following link suggests http://wiki.prplfoundation.org/wiki/Procd_reference#procd_add_raw_trigger.28event.2C_timeout.2C_.5Bscript.5D.29 is the number of milliseconds that procd will wait after the trigger (in this case, anything related to an "interface" AFAIU) before executing "dnsmasq reload" i put 6 (60 seconds) and now the reload only happens once (after ~60 seconds from the first "/e/i/dnsmasq boot") and dnsmasq starts without problem so it looks to me like a race condition, where two "interface.*" events are happening one after the other, triggering two consecutive reloads, the first reload doesn't finish its work before the second reload comes, and the second reload kills the first reload, and suicides itself for some reason. setting a long raw_trigger timeout works around the problem because the "interface.*" events happen all inside the 60 second window, and procd runs "/e/i/dnsmasq reload" only once i can imagine that few people came across this since dnsmasq normally takes less than 2 seconds to start, and so the first reload is already done starting when the second reload is triggered. my added "sleeps" help reproduce the issue by artificially making dnsmasq take always longer than 2 seconds, but without them the race condition is still there, only it doesn't end badly every boot (only some boots, and on some hardware) is this enough info to point the right direction for someone to look into procd? (not me, not enough proficient in C, sorry) (running two long "/e/i/dnsmasq reload" in parallel manually via console, the second one doesn't kill the first one, which makes me think that procd is the murderer) On 22/03/17 23:29, Yousong Zhou wrote: > From the log, there are at least 4 runs of /etc/init.d/dnsmasq > > This is "/e/c/dnsmasq boot" and returns immediately because the script skips > this phase and the dnsmasq service is expected to be brought up by interface > trigger events > > root@coco:~# logread | grep dns > Wed Mar 22 18:25:56 2017 user.notice root: guidebug dnsmasq init > Wed Mar 22 18:25:56 2017 user.notice root: guidebug dnsmasq boot > Wed Mar 22 18:25:56 2017 user.notice root: guidebug dnsmasq startsrv 1, > Wed Mar 22 18:25:56 2017 user.notice root: guidebug dnsmasq srvtrg > > This one I do not have much clue about > > Wed Mar 22 18:25:57 2017 user.notice root: guidebug dnsmasq init > > This one was brought up by the interface trigger event. Your log stopped at > "wait 18" without "wait 16" because the service_triggers call in the > /e/c/dnsmasq has set the timeout of event handling to be 2000ms. That's how > the logger and sleep call were impeding the process > > Wed Mar 22 18:26:06 2017 user.notice root: guidebug dnsmasq init > Wed Mar 22 18:26:06 2017 user.notice root: guidebug dnsmasq reload > Wed Mar 22 18:26:06 2017 user.notice root: guidebug dnsmasq startsrv , > Wed Mar 22 18:26:06 2017 user.notice root: guidebug dnsmasq realstart > cfg02411c wait 20 > Wed Mar 22 18:26:08 2017 user.notice root: guidebug dnsmasq realstart > cfg02411c wait 18 > > This one I also have no clue about. It didn't even make it to the "realstart" > part. So checking further what happened in between was causing that should be > helpful > > Wed Mar 22 18:26:10 2017 user.notice root: guidebug dnsmasq init > Wed Mar 22 18:26:10 2017 user.notice root: guidebug dnsmasq reload > Wed Mar 22 18:26:10 2017 user.notice root: guidebug dnsmasq startsrv , > --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] dnsmasq sometimes fails to start on 17.01.0
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 23/03/17 00:35, Eric Luehrsen wrote: >>>From the log, there are at least 4 runs of /etc/init.d/dnsmasq > > Is adblock or other dns intervening service being used? no adblock or anything like, but probably many "interface" events > These can double > pump the ifup event. One "restart" forcing a config change (new dns > black list) and followed by the delayed procd trigger. ok, but even in this case, at least one of the two processes should be able to start it up, and not die both :P > > - Eric --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] stack trace: warning at .../sta_info.c:451 in LEDE 17.01.0
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- dumping here more things i come across while using LEDE 17.01.0 on a TL-WR842ND a strange crash in wifi: http://pastebin.com/THLMDT6C WARNING: CPU: 0 PID: 22264 at compat-wireless-2016-10-08/net/mac80211/sta_info.c:451 0x80e84f90 [mac80211@80e8+0x5f540]() does that ring a bell for anyone? or is just a harmless warning? (adhoc vif was still working, but a vlan built on top of that was missing, which was vry strange. after running "wifi", everything came up again fine) cheers! --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
