Re: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

[Joel Wirāmu Pauling]

I am in New Zealand, (also 5 eyes ;) and have not received one.

On 9 February 2017 at 12:04, Hartmut Knaack  wrote:

> Vincent Wiemann schrieb am 08.02.2017 um 22:29:
> > Hi everyone,
> >
> > has anyone received one of the units, yet?
>
> According to the forum, two guys from Canada, one guy from Australia and
> one guy from the UK already got their devices (all 5-eyes countries ;-).
>
> > I wonder how long it takes as my experience with TP-Link (who don't
> > really care about free software :D) is that they send their units with
> > UPS Express and it never took more than a week...
> >
> > On 17.01.2017 20:06, Hartmut Knaack wrote:
> >>
> >> OK, to answer my question: today we received an email from
> Belkin/Linksys,
> >> asking for a shipping address.
> >>
> >
> > Kind regards,
> > CodeFetch
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

[Hartmut Knaack]

Vincent Wiemann schrieb am 08.02.2017 um 22:29:
> Hi everyone,
> 
> has anyone received one of the units, yet?

According to the forum, two guys from Canada, one guy from Australia and
one guy from the UK already got their devices (all 5-eyes countries ;-).

> I wonder how long it takes as my experience with TP-Link (who don't
> really care about free software :D) is that they send their units with
> UPS Express and it never took more than a week...
> 
> On 17.01.2017 20:06, Hartmut Knaack wrote:
>>
>> OK, to answer my question: today we received an email from Belkin/Linksys,
>> asking for a shipping address.
>>
> 
> Kind regards,
> CodeFetch
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

[Vincent Wiemann]

Hi everyone,

has anyone received one of the units, yet?
I wonder how long it takes as my experience with TP-Link (who don't
really care about free software :D) is that they send their units with
UPS Express and it never took more than a week...

On 17.01.2017 20:06, Hartmut Knaack wrote:
> 
> OK, to answer my question: today we received an email from Belkin/Linksys,
> asking for a shipping address.
> 

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

Re: [OpenWrt-Devel] [LEDE-DEV] procd: service instance restart does not wait for old process to be closed before lanching the new one

[John Crispin]

On 08/02/2017 15:55, Alin Năstac wrote:
> Hi John,
> 
> One of the daemons I use takes sometime a couple of seconds to close
> after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon
> restart" there will be 2 instances of that service running in parallel
> until the initial instance will finally manage to handle the SIGTERM
> signal. This daemon registers its own ubus object, but new instance
> will fail to register its object due to name conflict with an object
> that is already existing.
> 
> The root cause of this defect is the way procd restarts a service by
> issuing a service_stop followed immediately by a service_start:
>   1) service_stop call translates to
> - instance_stop() ->  send SIGTERM signal to the old instance
> - instance_free() -> call uloop_process_delete(), which means
> in->proc.pending will be set to 0
>   2) sevice_start will launch the new instance becaise previous
> process has been already deleted
> 
> Shouldn't uloop_process_delete() be called only when process was
> closed, as it is the case in uloop.c? If so, instance_start() should
> at least set restart to 1 when (in->proc.pending && in->halt).
> 
> And isn't a bit too optimistic to assume all daemons will be stopped by 
> SIGTERM?

Hi,

probably, feel free to send a patch to fix the issue. we can help test it.

John


> BR,
> Alin
> 
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] procd: service instance restart does not wait for old process to be closed before lanching the new one

[Nishant Sharma]

On 8 February 2017 8:25:29 PM IST, "Alin Năstac" <
>And isn't a bit too optimistic to assume all daemons will be stopped by
>SIGTERM?

Case in point a squid running on PCEngines APU. Even if I configure it to force 
close connections within 2-3 seconds, it still at times takes more time.

Regards,
Nishant
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] procd: service instance restart does not wait for old process to be closed before lanching the new one

[Alin Năstac]

Hi John,

One of the daemons I use takes sometime a couple of seconds to close
after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon
restart" there will be 2 instances of that service running in parallel
until the initial instance will finally manage to handle the SIGTERM
signal. This daemon registers its own ubus object, but new instance
will fail to register its object due to name conflict with an object
that is already existing.

The root cause of this defect is the way procd restarts a service by
issuing a service_stop followed immediately by a service_start:
  1) service_stop call translates to
- instance_stop() ->  send SIGTERM signal to the old instance
- instance_free() -> call uloop_process_delete(), which means
in->proc.pending will be set to 0
  2) sevice_start will launch the new instance becaise previous
process has been already deleted

Shouldn't uloop_process_delete() be called only when process was
closed, as it is the case in uloop.c? If so, instance_start() should
at least set restart to 1 when (in->proc.pending && in->halt).

And isn't a bit too optimistic to assume all daemons will be stopped by SIGTERM?

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

[OpenWrt-Devel] procd: service instance restart does not wait for old process to be closed before lanching the new one

[Alin Năstac]

Hi John,

One of the daemons I use takes sometime a couple of seconds to close
after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon
restart" there will be 2 instances of that service running in parallel
until the initial instance will finally manage to handle the SIGTERM
signal. This daemon registers its own ubus object, but new instance
will fail to register its object due to name conflict with an object
that is already existing.

The root cause of this defect is the way procd restarts a service by
issuing a service_stop followed immediately by a service_start:
  1) service_stop call translates to
- instance_stop() ->  send SIGTERM signal to the old instance
- instance_free() -> call uloop_process_delete(), which means
in->proc.pending will be set to 0
  2) sevice_start will launch the new instance becaise previous
process has been already deleted

Shouldn't uloop_process_delete() be called only when process was
closed, as it is the case in uloop.c? If so, instance_start() should
at least set restart to 1 when (in->proc.pending && in->halt).

And isn't a bit too optimistic to assume all daemons will be stopped by SIGTERM?

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

Re: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT and multiplatform

[Hans Ulli Kroll]

Hi Linus

On Sun, 22 Jan 2017, Linus Walleij wrote:

> I got a Gemini platform from Florian Fainelli over at OpenWRT
> some time back. I finally got around to "future-proofing" the
> platform, which was the idea when he paintakingly sent the box
> over to me.
> 

now I've got my toolchain cleaned up and working ...
Tested on may nas 4220
  
here my
Acked-by: Hans Ulli Kroll 

> - FOT2G USB EHCI host

The fotg2 driver is already upstream.
I've added DT support and this driver works.
The only problem here is dis/reconnect of usb devices, but I think this 
is some driver problem here.

I must clean up my DT support patches to send them of.

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

Re: [OpenWrt-Devel] [PATCH 14/22] ARM: dts: add a devicetree for Raidsonic NAS IB-4220-B

[Hans Ulli Kroll]

HI Linus

On Tue, 7 Feb 2017, Linus Walleij wrote:

> On Sun, Feb 5, 2017 at 10:53 AM, Hans Ulli Kroll
>  wrote:
> 
> > Hi Linus,
> >
> > please add right baudrate and partition scheme for NAS 4220
> >
> > Signed-off-by: Hans Ulli Kroll 
> 
> Thanks Hans! I folded this into the NAS 4220 device tree
> and added your Signed-off-by to the patch.
> 

You can remove the PCI entries I've seen on your git tree.
NAS 4220 has no PCI interface

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