Hello,
On Wed, Apr 18, 2018 at 11:34 AM, Kristian Evensen
wrote:
> I will keep an eye on this router, just in case, but it seems the
> problem is gone. Thanks for fixing it so fast!
The router (WG3526) has been running fine for a while now, but after
changing configuration from client to
Hi,
On Mon, May 14, 2018 at 9:03 AM, Jamie Stuart wrote:
> Hi Everyone,
> Just wondering if anyone had made any progress into integrating this in trunk
> OpenWRT.
> It’s out of my skillset unfortunately!
I don't know if the patch mentioned in the original email is in
Daniel's tree or not, but I
Hi,
Thanks for your reply, good to know that I am not alone :)
On Sat, May 5, 2018 at 9:45 PM, Lucian Cristian wrote:
> do you have hardware offloading enabled and multiwan ?
>
> I have the same problem when I enable them
The routers do support hardware offloading (ZBT WG3526 so mt7621), but
it
Hello,
When restarting the firewall on routers running latest nightly, I
frequently get the following warning:
[ 74.952854] [ cut here ]
[ 74.952874] WARNING: CPU: 2 PID: 0 at
net/netfilter/nf_conntrack_rtcache.c:197 0x8f6293f0
[ 74.952876] Modules linked in: rt2800p
Hello,
I have been doing some tests with kernel 4.14 on some MT7621-based
devices (ZBT WG2926 and WG3526). Sometimes, seemingly out of the blue,
I get the following oops:
[ 95.073332] [ cut here ]
[ 95.077988] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:320
dev_w
Hi,
On Tue, Apr 17, 2018 at 3:34 PM, Kristian Evensen
wrote:
> Thanks, great. I just started building a new image for my router, will
> test and let you know if I still see the issue.
I think I have finished my testing, at least for now, and it seems the
problem is fixed. I compiled an
On Tue, Apr 17, 2018 at 2:56 PM, Felix Fietkau wrote:
> On 2018-04-17 13:50, Kristian Evensen wrote:
>> This is with the same image as last time (commit
>> f6e6eadc99c6274207f8f2ebc739063549959a1f) and configuration (radios
>> used as clients). I see that mt76 has been updat
Hi,
On Thu, Apr 12, 2018 at 3:28 PM, Kristian Evensen
wrote:
> Thanks for the pointer. I compiled a new image KALLSYMS, but now I am
> not able to reproduce the error. Perhaps there was something dirty in
> my build directory. I will keep the image KALLSYMS on the routers and
> keep
Hi,
On Thu, Apr 12, 2018 at 1:02 PM, John Crispin wrote:
> try enabling KALLSYMS to get a verbose stack trace.
Thanks for the pointer. I compiled a new image KALLSYMS, but now I am
not able to reproduce the error. Perhaps there was something dirty in
my build directory. I will keep the image KAL
Hello,
I have recently updated some ramips mt7621-devices (ZBT WG3526) to the
latest nightly. Almost everything seems to work fine, but using either
wifi interface in client mode seems triggers an oops. I see two
different oops-messages:
Message 1:
[ 66.442802] CPU 1 Unable to handle kernel pag
: Kristian Evensen
---
include/netfilter.mk | 4
package/kernel/linux/modules/netfilter.mk | 15 +++
package/network/utils/iptables/Makefile | 15 +++
3 files changed, 34 insertions(+)
diff --git a/include/netfilter.mk b/include/netfilter.mk
index
On Thu, Oct 19, 2017 at 3:02 PM, Kristian Evensen
wrote:
> When SIGTERM times out, procd sends SIGKILL and then restarts the
> process once SIGCHLD has been received. This all works fine, with one
> exception - respawn is not restored when instance_start() is called from
> instance
Hi Karl,
Sorry for my extremely late reply. For some reason, it was not picked
up by Gmail and I did not see it before today. Since it was not picked
up by Gmail, I had to do some creative c&p, sorry in advance for weird
formatting.
>>Kristian Evensen wrote:
>> When SIGTERM
Hello,
On Thu, Nov 9, 2017 at 8:42 PM, Kristian Evensen
wrote:
> I replaced the 3526 with other devices containing the mt7530 switch
> (both mt7621 and mt7623-based boards), and the issues seems to be
> related to the switch rather than the SoC. I am able to reliably
> trigger the ti
On Thu, Nov 9, 2017 at 5:21 PM, Kristian Evensen
wrote:
> I have been hammering away on this issue during the day, and it seems
> that the DMA engine, TX, etc. works just fine. However, for some
> reason, the port with the router that has hung is able to stop the
> whole switch. If I
On Thu, Nov 9, 2017 at 12:06 PM, Kristian Evensen
wrote:
> I see that the CPU txds [384-511] have DDONE set and no SKB, while
> DDONE is not set for the DMA txds [0-383] and an skb is attached. I
> also looked at the content of the skb, and as far as I can see it is
> valid. Lo
Hello,
On Wed, Nov 8, 2017 at 10:56 PM, Kristian Evensen
wrote:
> I have been trying to solve this myself for a couple of days, but I am
> starting to run out of idea. Could it be that there is some traffic
> destined for the client (via. the 2626) that gets stuck in the TX
> queue
Hello,
It turns out that the assumption that the "transmit timed out"-issue
was related to pause frames/flow control was incorrect. I have
recently started to see the error again, with flow control disabled.
However, unlike last time, I am now able to reliably trigger the
issue.
The timeout seems
On Tue, Nov 7, 2017 at 9:34 PM, Rosen Penev wrote:
> Replace malloc+memset with calloc. Cleaner and faster in extreme situations.
>
> Signed-off-by: Rosen Penev
> ---
> libubus.c | 6 ++
> lua/ubus.c | 18 ++
> 2 files changed, 8 insertions(+), 16 deletions(-)
>
> diff --gi
Hi Piotr and Mathias,
On Sun, Nov 5, 2017 at 10:24 PM, Piotr Dymacz wrote:
> Hello Kristian,
>
> On 04.11.2017 21:53, Kristian Evensen wrote:
>>
>> The Unielec U7621-6
>>
>> (http://www.unielecinc.com/q/news/cn/p/product/detail.html?qd_guid=pyrEjfTmYf)
>
Hi,
On Sun, Nov 5, 2017 at 1:47 PM, Kristian Evensen
wrote:
> By the way, I sometimes see the board cough up different
> memory-related errors. For example, I have seen seg. faults for
> applications that are run on startup, messages like "CPU 3 Unable to
> handle kernel
Hi again,
On Sun, Nov 5, 2017 at 12:14 PM, Mathias Kresin wrote:
>> diff --git a/target/linux/ramips/image/mt7621.mk
>> b/target/linux/ramips/image/mt7621.mk
>> index 8bd7e0318f..1bdd0024e4 100644
>> --- a/target/linux/ramips/image/mt7621.mk
>> +++ b/target/linux/ramips/image/mt7621.mk
>> @@ -225
Hi Mathias,
Thanks for your comments.
On Sun, Nov 5, 2017 at 12:14 PM, Mathias Kresin wrote:
> Hey Christian,
>
> find my comments inline.
>
> 04.11.2017 21:53, Kristian Evensen:
>>
>> Notes:
>> * According to the specifications on the Unielec website, two L
website is in Chinese, but is easy to use. Click on the second
item in the list to access the recovery page, then the second item on
the next page is where you select the firmware. In order to start the
recovery, you click the button at the bottom.
Signed-off-by: Kristian Evensen
---
.../linux
Hi John,
On Sat, Aug 19, 2017 at 8:16 PM, John Crispin wrote:
> Hi All,
>
> i have a staged commit on my laptop that makes all the (upstream) ethernet
> fixes that i pushed to mt7623 work on mt7621. please hang on for a few more
> days till i finished testing the support. this will add latest ups
-value in instance_exit().
Signed-off-by: Kristian Evensen
---
service/instance.c | 6 --
service/instance.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/service/instance.c b/service/instance.c
index b7cb523..76c74ed 100644
--- a/service/instance.c
+++ b/service
specifies the correct GPIO for the left-most mini-PCIe slot
of the D240 (labeled power_mpcie2 since the slot is attached to SIM2),
and adds a GPIO that can be used to control the power of the other
mini-PCIe slot (labeled power_mpcie1).
Signed-off-by: Kristian Evensen
---
target/linux/ramips/dt
oad a firmware image.
Signed-off-by: Kristian Evensen
---
target/linux/ramips/base-files/etc/board.d/01_leds | 5 +
.../linux/ramips/base-files/etc/board.d/02_network | 3 +-
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
t
rmware
(thanks Mathias Kresin).
* Respect ordering in diag.sh (thanks Mathias Kresin).
v1->v2:
* Update "Not working" based on more testing with factory firmware.
* Changed offset of LAN MAC address.
Signed-off-by: Kristian Evensen
---
target/linux/ramips/base-files/etc/bo
On Wed, Sep 6, 2017 at 10:35 AM, Kristian Evensen
wrote:
> The HNET C108
> (http://www.szhwtech88.com/Product-product-cid-100-id-4374.html) is a
> mifi based on MT7602A, which has the following specifications:
>
> * CPU: MT7620A
> * 1x 10/100Mbps Ethernet.
> * 16 MB Flash.
ect ordering in diag.sh (thanks Mathias Kresin).
v1->v2:
* Update "Not working" based on more testing with factory firmware.
* Changed offset of LAN MAC address.
Signed-off-by: Kristian Evensen
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ramips/base-f
On Wed, Sep 6, 2017 at 10:07 AM, Mathias Kresin wrote:
> 06.09.2017 09:26, Kristian Evensen:
>>
>> On Wed, Sep 6, 2017 at 9:03 AM, Mathias Kresin wrote:
>>>>
>>>> * Wifi LED. It is always switched on.
>>>
>>>
>>>
>>
Hi,
On Wed, Sep 6, 2017 at 9:46 AM, John Crispin wrote:
> the mt7620 only has 1 usb port. if the minipcie usb works, then its wired
> there. maybe there is a gpio to switch between internal modem port and
> external port ?
Thanks for the help! I just spoke to the factory and it turns out that
po
Hi,
Thanks for the feedback.
On Wed, Sep 6, 2017 at 9:03 AM, Mathias Kresin wrote:
>> Not working:
>> * USB port.
>
>
> What does not working means? Not detected? USB devices not powered (but are
> working with an external powered hub)? Any error messages?
Not detected and no error messages, so
tory firmware.
* Changed offset of LAN MAC address.
Signed-off-by: Kristian Evensen
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-files/etc/diag.sh | 3 +
target/linux/ramips/base-files/
brick the device, the C108 supports recovery using TFTP. Keep the
reset button pressed for ~5sec when booting to trigger TFTP. Set the
address of the network interface on your machine to 10.10.10.3/24, and
rename your image file to Kernal.bin.
Signed-off-by: Kristian Evensen
---
target/linux
not ideal, but
since this error only happens when the router/switch is completely
swamped, then users/protocols/applications should not notice a
difference. It might even be better to drop packets right away, than to
buffer them for a given time.
Signed-off-by: Kristian Evensen
---
.../drivers/
Hello again,
On Sat, Aug 26, 2017 at 4:57 PM, Kristian Evensen
wrote:
> I did not have to wait very long before anything. Unfortunately, my
> router crashed right after I sent the previous email. So I guess that
> means back to the drawing board.
I have kept working on this issue throu
Hi,
On Sat, Aug 26, 2017 at 4:47 PM, Kristian Evensen
wrote:
> I guess our common theory is that something is causing TX interrupts
> not to be enabled again. After reading up on NAPI
> (https://wiki.linuxfoundation.org/networking/napi), it seems that the
> recommended way of using N
Hello again,
On Sat, Aug 26, 2017 at 12:38 PM, Kristian Evensen
wrote:
> Hi,
>
> On Sat, Aug 26, 2017 at 7:43 AM, Mingyu Li wrote:
>> Hi.
>>
>> i check the code again. found xmit_more can cause tx timeout. you can
>> reference this.
>> https://www.
Hi,
On Sat, Aug 26, 2017 at 7:43 AM, Mingyu Li wrote:
> Hi.
>
> i check the code again. found xmit_more can cause tx timeout. you can
> reference this.
> https://www.mail-archive.com/netdev@vger.kernel.org/msg123334.html
> so the patch should be like this. edit mtk_eth_soc.c
>
> tx_num =
Hi all,
On Sun, Aug 20, 2017 at 12:30 AM, John Crispin wrote:
> correct, in my testing i have been ... with 200 parallel flows ... on
> MT7623, we'll have to find out what mt7621 can achieve ... this is all using
> hwnat ...
> 1) tcp - at 50 byte frames i am able to pass 720 MBit which is > 1M FP
Hi,
On Mon, Jul 24, 2017 at 4:02 AM, Mingyu Li wrote:
> i guest the problem is there are some tx data not free. but tx
> interrupt is clean. cause tx timeout. the old code will free data
> first then clean interrupt. but there maybe new data arrive after free
> data before clean interrupt.
> so c
Hi!
On Sun, Jul 23, 2017 at 4:50 PM, Mingyu Li wrote:
> Hi.
> i write a path. could you help to verify it?
Thanks a lot, will do! I am leaving on holiday tomorrow, so testing
might take a little while, but I will get back to you as soon as
possible. Would you mind explaining a bit about what you
Hello,
I am currently facing an issue on some MT7621 (ZBT WG2626/2926 and
3526) based devices that I am, after days of fruitless digging,
seemingly unable to solve myself and I have run out of places to look
or things to test. Most devices are running LEDE 17.01, while some are
running the latest
be considered for stable, as the error also exists there.
Signed-off-by: Kristian Evensen
---
target/linux/x86/base-files/etc/board.d/01_leds| 2 +-
target/linux/x86/base-files/etc/board.d/02_network | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/x86/base
Hi,
On Fri, Apr 28, 2017 at 8:39 PM, Thomas Endt wrote:
> When will there be a precompiled 17.01 image for this device? With 17.01.2
> or with the next major release?
> I'm asking because there were some devices with snapshot support that I
> would have expected to have a 17.01.1 image available,
A gentle ping for this patch :)
-Kristian
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
default.
v2->v3:
* Indentation error.
v1->v2:
* Rename gpio and remove redundant comment (thanks Piotr Dymacz)
Signed-off-by: Kristian Evensen
---
target/linux/ramips/dts/D240.dts| 11 +++
target/linux/ramips/image/mt7620.mk | 2 +-
2 files changed, 12 insertions(+), 1 de
On Thu, Mar 2, 2017 at 1:37 PM, Kristian Evensen
wrote:
>
> + gpio-export {
> + compatible = "gpio-export";
> + #size-cells = <0>;
> +
> +power_mpcie2 {
> + gpio-export,name = "power_mpc
default.
v1->v2:
* Rename gpio and remove redundant comment (thanks Piotr Dymacz)
Signed-off-by: Kristian Evensen
---
target/linux/ramips/dts/D240.dts| 11 +++
target/linux/ramips/image/mt7620.mk | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/target/li
Hi,
On Thu, Mar 2, 2017 at 12:39 PM, Piotr Dymacz wrote:
> What about "power_mpcieX" (or something similar), where X is 1 or 2,
> depending on what is printed on the PCB (I wasn't able to find hi-res
> photo)?
Good idea and thanks for the pointer. There does not seem to be any
easy-to-find value
reflect this.
Note that until the default mt7620 target is updated, then kmod-mt76 (and thus
kmod-mt7603) will be selected by default.
Signed-off-by: Kristian Evensen
---
target/linux/ramips/dts/D240.dts| 14 ++
target/linux/ramips/image/mt7620.mk | 2 +-
2 files changed, 15
l LEDE on the router (thanks Mathias Kresin).
v1->v2:
* Misc. code cleanup (thanks Mathias Kresin)
Signed-off-by: Kristian Evensen
blabla
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-
. code cleanup (thanks Mathias Kresin)
Signed-off-by: Kristian Evensen
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-files/etc/diag.sh | 1 +
target/linux/ramips/base-files/lib/ram
On Fri, Feb 3, 2017 at 12:52 PM, Piotr Dymacz wrote:
> As this is a general problem and I'm sure it's going to grow in time,
> maybe we should start thinking about different approach for naming
> boards in system, dts files and image filenames? Including there also
> the manufacturer name would be
Hi
On Fri, Feb 3, 2017 at 11:02 AM, Piotr Dymacz wrote:
> Hi Kristian,
>
> My two cents: the general convention for board name is to not include
> the manufacturer name (Sanlinking here).
> As you can see, (almost) all other boards follow this rule, so please
> use "d240" instead of "sanlinking-d
.
Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader on the device.
v1->v2:
* Misc. code cleanup (thanks Mathias Kresin)
Signed-off-by: Kristian Evensen
Cleanup
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ram
On Thu, Feb 2, 2017 at 8:13 PM, Mathias Kresin wrote:
> Hey Kristian,
>
> thanks a lot for the patch. Find my comments inline.
Thanks a lot! Will submit a v2 soon.
-Kristian
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead
.
Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader on the device.
Signed-off-by: Kristian Evensen
---
target/linux/ramips/base-files/etc/board.d/01_leds | 5 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips
When using UCI to configure static addresses, netifd does not set the source
address of the gateway route. In order to be consistent, also set the source
address for subnet routes (this applies to all protocols).
Signed-off-by: Kristian Evensen
---
interface-ip.c | 4
proto.c| 32
61 matches
Mail list logo
