Sebastian Hesselbarth писал 12.04.2015 14:20:
> On 11.04.2015 22:29, Andrew Andrianov wrote:
>> Signed-off-by: Andrew Andrianov <[email protected]>
>
> Andrew,
>
> thanks for providing this dts, please _always_ add a commit log
> describing what the patch is about. The introduction in the cover
> letter is nice, but it will be gone once the patches are applied,
> so this patch needs some log, too.
>
> I also have a DNS-327L and I thought I started a dts, but either
> I misremember or I just cannot find it.
>
> Anyways, some comments below.
>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/armada-370-dlink-dns327l.dts | 309
>> ++++++++++++++++++++++++
>> 2 files changed, 310 insertions(+)
>> create mode 100644 arch/arm/boot/dts/armada-370-dlink-dns327l.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index a1c776b..8535e4e 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -612,6 +612,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
>> zynq-zybo.dtb
>> dtb-$(CONFIG_MACH_ARMADA_370) += \
>> armada-370-db.dtb \
>> + armada-370-dlink-dns327l.dtb \
>> armada-370-mirabox.dtb \
>> armada-370-netgear-rn102.dtb \
>> armada-370-netgear-rn104.dtb \
>> diff --git a/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
>> b/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
>> new file mode 100644
>> index 0000000..12bc072
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
>> @@ -0,0 +1,309 @@
>> +/*
>> + * Device Tree file for DLINK DNS-327L
>
> Just a nit, but the company's logo uses "D-Link" so we should
> use that in here.
>
> I am fine with the file named "-370-dlink-dns" though.
>
>> + * Copyright (C) 2014, Andrew Andrianov <[email protected]>
>
> +2015?
>
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + */
>
> Andrew Lunn already mentioned dual licensing here.
>
>> +/* Remaining mysteries:
>> + *
>> + * There's still something unknown on i2c address 0x13
>
> Well, I can at least tell it is a "device" instead of "something" ;)
>
> I am ok with the comment about an "unknown device at i2c address 0x13".
>
>> + * CONFIG_ARM_MVEBU_V7_CPUIDLE=y causes hard freezes every 1-8 hours
>
> I don't think the dts is the right place for Linux issues.
Not sure if that's a hardware weirdness or software issue (yet).
Just checked - this goblin is there in 4.0-rc7.
>
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include "armada-370.dtsi"
>> +
>> +/ {
>> + model = "DLINK DNS-327L";
>
> "D-Link DNS-327L"
>
>> + compatible = "dlink,dns327l",
>> + "marvell,armada370",
>> + "marvell,armada-370-xp";
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200 earlyprintk";
>> + };
>
> Andrew Lunn already mentioned stdout-path property.
>
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x20000000>; /* 512 MiB */
>> + };
>> +
>> + soc {
>> + ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
>> + MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
>> +
>> + pcie-controller {
>> + status = "okay";
>> +
>> + /* Connected to Marvell SATA controller */
>
> Really? It is actually using the two internal SATA ports.
Ouch, just a left-over from the netgear DTS file
>
>> + pcie@1,0 {
>> + /* Port 0, Lane 0 */
>> + status = "okay";
>> + };
>> +
>> + /* Connected to NEC USB 3.0 controller */
>
> Please just enable the port where the USB3 controller is connected
> to. Could be the other one.
>
>> + pcie@2,0 {
>> + /* Port 1, Lane 0 */
>> + status = "okay";
>> + };
>> + };
>> +
>> + internal-regs {
>> + serial@12000 {
>> + status = "okay";
>> + };
>> +
>> + serial@12100 {
>> + status = "okay";
>> + };
>
> &uart0 { status = "okay" };
> &uart1 { status = "okay" };
>
> And move to bottom of the file. We try not to replay the bus structure
> on board level all the time, if possible.
>
>> + sata@a0000 {
>> + nr-ports = <2>;
>> + status = "okay";
>> + };
>
> Ok, sata has no node label, yet. It has to stay here.
>
>> + mdio {
>> + phy0: ethernet-phy@0 { /* Marvell 88E1318 */
>> + reg = <0>;
>> + };
>> + };
>
> Something is wrong with indention of the node above and we do have
> a node label for &mdio so it can also move.
>
>> + ethernet@74000 {
>> + status = "okay";
>> + phy = <&phy0>;
>> + phy-mode = "rgmii-id";
>> + };
>
> ditto, ð1.
>
>> + usb@50000 {
>> + status = "okay";
>> + };
>
> Again, no node label, yet.
>
>> + i2c@11000 {
>> + compatible = "marvell,mv64xxx-i2c";
>> + clock-frequency = <100000>;
>> + status = "okay";
>> + };
>
> &i2c0, so please move.
>
>> + nand@d0000 {
>
> Again, no node label, yet.
>
> I guess there will be a cleanup patch set adding proper labels to
> armada-370-xp.dtsi some day.
>
>> + status = "okay";
>> + num-cs = <1>;
>
> I stumbled upon this on ix4-300d already while adding support for
> pxa3xx nfc on barebox bootloader for the armada370/xp type of nfc
> controller.
>
> It is most likely the flash is connected to cs0 just because it is one
> selected if boot source is NAND.
>
> It could be that current barebox and Linux nfc driver deal with
> the property differently, I haven't really checked yet.
>
>> + marvell,nand-keep-config;
>> + marvell,nand-enable-arbiter;
>> + nand-on-flash-bbt;
>
> Do you know the ECC scheme used?
Any hints on how to find it apart from dumping NAND controller registers
from bootloader ?
>
> If so, please add corresponding nand-ecc-strength and
> nand-ecc-step-size properties.
>
>> + partition@0 {
>> + label = "u-boot";
>> + /* 1.0 MiB */
>> + reg = <0x0000000 0x100000>;
>> + read-only;
>> + };
>> +
>> + partition@100000 {
>> + label = "u-boot-env";
>> + /* 128 KiB */
>> + reg = <0x100000 0x20000>;
>> + read-only;
>> + };
>> +
>> + partition@120000 {
>> + label = "uImage";
>> + /* 7 MiB */
>> + reg = <0x120000 0x700000>;
>> + };
>> +
>> + partition@820000 {
>> + label = "ubifs";
>> + /* ~ 84 MiB */
>> + reg = <0x820000 0x54e0000>;
>> + };
>> +
>> + /* Hardwired into stock bootloader */
>
> I don't get the comment above.
The stock u-boot is hacked with a 'failsafe' kernel address.
If for some reason running the 'bootcmd' fails, it reads
5MiBs from partition @ (5d00000 + 0x800) and tries to boot it.
There's no way to change this via environment, only by replacing
the bootloader.
Personally I'm more happy with a simpler partition table, but I
guess upstream should be oriented towards the stock bootloader.
>
>> + partition@800000 {
>
> partition@5d00000
>
>> + label = "failsafe-uImage";
>> + /* 5 MiB */
>> + reg = <0x5d00000 0x500000>;
>> + };
>> +
>> + partition@6200000 {
>> + label = "failsafe-fs";
>> + /* 29 MiB */
>> + reg = <0x6200000 0x1d00000>;
>> + };
>> +
>> + partition@7f00000 {
>> + label = "bbt";
>> + /* 1 MiB for BBT */
>> + reg = <0x7f00000 0x100000>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + gpio-keys {
>> + compatible = "gpio-keys";
>> + pinctrl-0 = <
>> + &backup_button_pin
>> + &power_button_pin>;
>> + pinctrl-names = "default";
>> +
>> + power-button {
>> + label = "Power Button";
>> + linux,code = <KEY_POWER>;
>> + gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + backup-button {
>> + label = "Backup Button";
>> + linux,code = <KEY_COPY>;
>
> Hmm, is KEY_COPY the best option?
>> + gpios = <&gpio1 31 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + reset-button {
>> + label = "Reset Button";
>> + linux,code = <KEY_RESTART>;
>> + gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> +
>
> Double empty lines above.
>
>> + };
>> +
>> + gpio-leds {
>> + compatible = "gpio-leds";
>> + pinctrl-0 = <
>> + &sata_l_amber_pin
>> + &sata_r_amber_pin
>> + &backup_led_pin>;
>> +
>> + pinctrl-names = "default";
>> +
>> + sata-r-amber-pin {
>> + label = "dns327l:amber:sata-r";
>> + gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
>> + default-state = "keep";
>
> Wrong indention.
>
>> + };
>> +
>> + sata-l-amber-pin {
>> + label = "dns327l:amber:sata-l";
>> + gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
>> + default-state = "keep";
>> + };
>> +
>> + backup-led-pin {
>> + label = "dns327l:white:usb";
>> + gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
>> + default-state = "keep";
>> + };
>> +
>
> ditto for all gpio nodes above, and another empty line.
>
>> + };
>> +
>> + regulators {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-0 = <&xhci_pwr_pin
>> + &sata1_pwr_pin
>> + &sata2_pwr_pin>;
>> +
>> + pinctrl-names = "default";
>> +
>> + usb_power: regulator@1 {
>
> Wrong indention.
>
>> + compatible = "regulator-fixed";
>> + reg = <1>;
>> + regulator-name = "USB3.0 Port Power";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + enable-active-high;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + gpio = <&gpio0 13 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + sata1_power: regulator@2 {
>
> ditto.
>
>> + compatible = "regulator-fixed";
>> + reg = <1>;
>
> reg = <2>;
>
>> + regulator-name = "SATA-1 Power";
>
> Front HDD LEDs are actually labeled "L" and "R", can you evaluate
> which 0/1 matches L/R and rename the regulator names accordingly?
>
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + enable-active-high;
>> + regulator-always-on;
>> + gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + sata2_power: regulator@3 {
>
> Wrong indention.
>
>> + compatible = "regulator-fixed";
>> + reg = <1>;
>
> reg = <3>;
>
>> + regulator-name = "SATA-2 Power";
>
> Same comment about the 0/1 vs L/R naming.
>
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + enable-active-high;
>> + regulator-always-on;
>> + gpio = <&gpio1 24 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +};
>> +
>> +&pinctrl {
>> + sata1_white_pin: sata1-white-pin {
>> + marvell,pins = "mpp55";
>> + marvell,function = "sata1";
>> + };
>> +
>> + sata_r_amber_pin: sata-r-amber-pin {
>> + marvell,pins = "mpp52";
>> + marvell,function = "gpio";
>> + };
>> +
>> + sata2_white_pin: sata2-white-pin {
>> + marvell,pins = "mpp57";
>> + marvell,function = "sata0";
>> + };
>> +
>> + sata_l_amber_pin: sata-l-amber-pin {
>> + marvell,pins = "mpp53";
>> + marvell,function = "gpio";
>> + };
>
> If you find the 0/1, L/R mapping you should use it all over this file.
>
> Sebastian
>
>> +
>> + backup_led_pin: backup-led-pin {
>> + marvell,pins = "mpp61";
>> + marvell,function = "gpo";
>> + };
>> +
>> + xhci_pwr_pin: xhci-pwr-pin {
>> + marvell,pins = "mpp13";
>> + marvell,function = "gpio";
>> + };
>> +
>> + sata1_pwr_pin: sata1-pwr-pin {
>> + marvell,pins = "mpp54";
>> + marvell,function = "gpio";
>> + };
>> +
>> + sata2_pwr_pin: sata2-pwr-pin {
>> + marvell,pins = "mpp56";
>> + marvell,function = "gpio";
>> + };
>> +
>> + power_button_pin: power-button-pin {
>> + marvell,pins = "mpp65";
>> + marvell,function = "gpio";
>> + };
>> +
>> + backup_button_pin: backup-button-pin {
>> + marvell,pins = "mpp63";
>> + marvell,function = "gpio";
>> + };
>> +
>> + reset_button_pin: reset-button-pin {
>> + marvell,pins = "mpp64";
>> + marvell,function = "gpio";
>> + };
>> +};
>>
Thanks for the review, I'll resubmit the fixed patchset shortly.
Please disregard my [PATCH v2] messages. I've send them the moment
before
I noticed your email and review.
--
Regards,
Andrew
On 12.04.2015 13:43, Andrew wrote:
> Sebastian Hesselbarth писал 12.04.2015 14:20:
>> On 11.04.2015 22:29, Andrew Andrianov wrote:
>>> Signed-off-by: Andrew Andrianov <[email protected]>
[...]
>>> + * CONFIG_ARM_MVEBU_V7_CPUIDLE=y causes hard freezes every 1-8 hours
>>
>> I don't think the dts is the right place for Linux issues.
>
> Not sure if that's a hardware weirdness or software issue (yet).
> Just checked - this goblin is there in 4.0-rc7.
I understand the issue, but still the dts is not the right place
for this comment.
[...]
>>> + marvell,nand-keep-config;
>>> + marvell,nand-enable-arbiter;
>>> + nand-on-flash-bbt;
>>
>> Do you know the ECC scheme used?
>
> Any hints on how to find it apart from dumping NAND controller registers
> from bootloader ?
From the original bootlog:
armada-nand armada-nand.0: Initialize HAL based NFC in 8bit mode with
DMA Disabled using BCH 4bit ECC
that translates into
nand-ecc-strength = <4>;
nand-ecc-step-size = <512>;
[...]
>>> + /* Hardwired into stock bootloader */
>>
>> I don't get the comment above.
>
> The stock u-boot is hacked with a 'failsafe' kernel address.
Ok, the above partition isn't passed by the bootloader on mtdparts
cmdline, i.e. that is why you call it "hardwired" ?
Just remove the comment, actually the whole partition table is
"hacked" into the stock bootloader.
> If for some reason running the 'bootcmd' fails, it reads
> 5MiBs from partition @ (5d00000 + 0x800) and tries to boot it.
> There's no way to change this via environment, only by replacing
> the bootloader.
> Personally I'm more happy with a simpler partition table, but I
> guess upstream should be oriented towards the stock bootloader.
Yeah, leave the original partition table. Any other, smarter
bootloader can replace it.
[...]
> Thanks for the review, I'll resubmit the fixed patchset shortly.
> Please disregard my [PATCH v2] messages. I've send them the moment before
> I noticed your email and review.
Please always leave the Cc-list in place.
And you should relax and leave patches there a day or two (or three).
Not everybody is reading patches immediately.
We are in no hurry, the current merge window is already closed,
the new one is 6 weeks away.
Sebastian
Sebastian Hesselbarth писал 12.04.2015 15:16:
> On 12.04.2015 13:43, Andrew wrote:
>> Sebastian Hesselbarth писал 12.04.2015 14:20:
>>> On 11.04.2015 22:29, Andrew Andrianov wrote:
>>>> Signed-off-by: Andrew Andrianov <[email protected]>
> [...]
>>>> + * CONFIG_ARM_MVEBU_V7_CPUIDLE=y causes hard freezes every 1-8
>>>> hours
>>>
>>> I don't think the dts is the right place for Linux issues.
>>
>> Not sure if that's a hardware weirdness or software issue (yet).
>> Just checked - this goblin is there in 4.0-rc7.
>
> I understand the issue, but still the dts is not the right place
> for this comment.
Okay, got it.
I'll file a bug about this issue to the the bugzilla. However something
tells me it might not be cpuidle, but D-link. This one's sounds nasty
and it has been around since 3.16.x. How could it go unnoticed?
Unfortunately I have no other armada-370 hardware to test it.
>
> [...]
>>>> + marvell,nand-keep-config;
>>>> + marvell,nand-enable-arbiter;
>>>> + nand-on-flash-bbt;
>>>
>>> Do you know the ECC scheme used?
>>
>> Any hints on how to find it apart from dumping NAND controller
>> registers
>> from bootloader ?
>
> From the original bootlog:
>
> armada-nand armada-nand.0: Initialize HAL based NFC in 8bit mode with
> DMA Disabled using BCH 4bit ECC
>
> that translates into
>
> nand-ecc-strength = <4>;
> nand-ecc-step-size = <512>;
Thanks!
>
> [...]
>>>> + /* Hardwired into stock bootloader */
>>>
>>> I don't get the comment above.
>>
>> The stock u-boot is hacked with a 'failsafe' kernel address.
>
> Ok, the above partition isn't passed by the bootloader on mtdparts
> cmdline, i.e. that is why you call it "hardwired" ?
As far I got - stock u-boot knows nothing about partition tables and
operates just on raw NAND offsets.
> Just remove the comment, actually the whole partition table is
> "hacked" into the stock bootloader.
>
>> If for some reason running the 'bootcmd' fails, it reads
>> 5MiBs from partition @ (5d00000 + 0x800) and tries to boot it.
>> There's no way to change this via environment, only by replacing
>> the bootloader.
>> Personally I'm more happy with a simpler partition table, but I
>> guess upstream should be oriented towards the stock bootloader.
>
> Yeah, leave the original partition table. Any other, smarter
> bootloader can replace it.
>
> [...]
>> Thanks for the review, I'll resubmit the fixed patchset shortly.
>> Please disregard my [PATCH v2] messages. I've send them the moment
>> before
>> I noticed your email and review.
>
> Please always leave the Cc-list in place.
Sorry, I had to resend that email twice. First one to you, next to the
list
and others. I'm quite new to LKML so still playing with proper email
setup.
> And you should relax and leave patches there a day or two (or three).
> Not everybody is reading patches immediately.
>
> We are in no hurry, the current merge window is already closed,
> the new one is 6 weeks away.
>
> Sebastian
I only have a chance to play with the hardware at the weekend, since the
spare dns327l is at the country house, so I try to send fixes as soon as
get feedback while I can quickly test it.
--
Regards,
Andrew
> Okay, got it.
> I'll file a bug about this issue to the the bugzilla. However something
> tells me it might not be cpuidle, but D-link. This one's sounds nasty
> and it has been around since 3.16.x. How could it go unnoticed?
> Unfortunately I have no other armada-370 hardware to test it.
Hi Andrew
A few of us here do have hardware to test with. Please give a detailed
description of how you reproduce the issue, and your kernel
configuration, if different from mvebu_v7_defconfig, or
multi_v7_defconfig.
Thanks
Andrew
Andrew Lunn писал 12.04.2015 17:58:
>> Okay, got it.
>> I'll file a bug about this issue to the the bugzilla. However
>> something
>> tells me it might not be cpuidle, but D-link. This one's sounds nasty
>> and it has been around since 3.16.x. How could it go unnoticed?
>> Unfortunately I have no other armada-370 hardware to test it.
>
> Hi Andrew
>
> A few of us here do have hardware to test with. Please give a detailed
> description of how you reproduce the issue, and your kernel
> configuration, if different from mvebu_v7_defconfig, or
> multi_v7_defconfig.
>
> Thanks
> Andrew
arch/arm/configs/mvebu_v7_defconfig has CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
so it should be sufficient to reproduce the issue. I first encountered
this issue using that very config and observed it on 2 DNS-327L boxes I
own.
All I have to do to trigger the bug - enable cpuidle driver and let the
box
sit for some 4-12 hours, till it hard-freezes. If wdt is enabled - wdt
reboot
will happen. With cpuidle disabled I hit 50+ days of uptime with no
issue.
I have also attached the config that I used to reproduce this issue
today
on 4.0-rc7. Just in case.
Since DNS-327L has no JTAG whatsoever there's little I can do to debug
this one myself. I had a feeling though it was somehow related to power
supply: e.g. non-stock power supply 'looked like' triggered the bug more
often. But poking with oscilloscope around all the power lines didn't
show
any difference.
--
Regards,
Andrew
On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
> Andrew Lunn ?????????? 12.04.2015 17:58:
> >>Okay, got it.
> >>I'll file a bug about this issue to the the bugzilla. However
> >>something
> >>tells me it might not be cpuidle, but D-link. This one's sounds nasty
> >>and it has been around since 3.16.x. How could it go unnoticed?
> >>Unfortunately I have no other armada-370 hardware to test it.
> >
> >Hi Andrew
> >
> >A few of us here do have hardware to test with. Please give a detailed
> >description of how you reproduce the issue, and your kernel
> >configuration, if different from mvebu_v7_defconfig, or
> >multi_v7_defconfig.
> >
> > Thanks
> > Andrew
>
>
> arch/arm/configs/mvebu_v7_defconfig has CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
> so it should be sufficient to reproduce the issue. I first encountered
> this issue using that very config and observed it on 2 DNS-327L boxes I
> own.
>
> All I have to do to trigger the bug - enable cpuidle driver and let
> the box
> sit for some 4-12 hours, till it hard-freezes. If wdt is enabled -
> wdt reboot
> will happen.
That simple! Well i've got a 370RD which has been sat mostly idle for
weeks, using the mvebu_v7_defconfig, with a few addition things turned
on for testing the Ethernet switch on the board. I've not had that
lockup.
One thing you can try to narrow it down is the disable the second idle
mode. Take a look at armada370_idle_driver. Keep the
ARM_CPUIDLE_WFI_STATE but disable the "Deep Idle" state.
Andrew
Hi Andrew(s),
On 12/04/2015 21:47, Andrew Lunn wrote:
> On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
>> Andrew Lunn ?????????? 12.04.2015 17:58:
>>>> Okay, got it.
>>>> I'll file a bug about this issue to the the bugzilla. However
>>>> something
>>>> tells me it might not be cpuidle, but D-link. This one's sounds nasty
>>>> and it has been around since 3.16.x. How could it go unnoticed?
>>>> Unfortunately I have no other armada-370 hardware to test it.
>>>
>>> Hi Andrew
>>>
>>> A few of us here do have hardware to test with. Please give a detailed
>>> description of how you reproduce the issue, and your kernel
>>> configuration, if different from mvebu_v7_defconfig, or
>>> multi_v7_defconfig.
>>>
>>> Thanks
>>> Andrew
>>
>>
>> arch/arm/configs/mvebu_v7_defconfig has CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
>> so it should be sufficient to reproduce the issue. I first encountered
>> this issue using that very config and observed it on 2 DNS-327L boxes I
>> own.
>>
>> All I have to do to trigger the bug - enable cpuidle driver and let
>> the box
>> sit for some 4-12 hours, till it hard-freezes. If wdt is enabled -
>> wdt reboot
>> will happen.
>
> That simple! Well i've got a 370RD which has been sat mostly idle for
> weeks, using the mvebu_v7_defconfig, with a few addition things turned
> on for testing the Ethernet switch on the board. I've not had that
> lockup.
>
> One thing you can try to narrow it down is the disable the second idle
> mode. Take a look at armada370_idle_driver. Keep the
> ARM_CPUIDLE_WFI_STATE but disable the "Deep Idle" state.
Actually you don't have to modify the kernel you can setup the CPU idle level
you want at runtime:
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
will disable the state1. By doing this on Armada 370 then you
will only use the WFI state.
Do you still have this issue on v4.0-rc7?
Thanks,
Gregory
>
> Andrew
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Gregory CLEMENT писал 13.04.2015 17:16:
> Hi Andrew(s),
>
> On 12/04/2015 21:47, Andrew Lunn wrote:
>> On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
>>> Andrew Lunn ?????????? 12.04.2015 17:58:
>>>>> Okay, got it.
>>>>> I'll file a bug about this issue to the the bugzilla. However
>>>>> something
>>>>> tells me it might not be cpuidle, but D-link. This one's sounds
>>>>> nasty
>>>>> and it has been around since 3.16.x. How could it go unnoticed?
>>>>> Unfortunately I have no other armada-370 hardware to test it.
>>>>
>>>> Hi Andrew
>>>>
>>>> A few of us here do have hardware to test with. Please give a
>>>> detailed
>>>> description of how you reproduce the issue, and your kernel
>>>> configuration, if different from mvebu_v7_defconfig, or
>>>> multi_v7_defconfig.
>>>>
>>>> Thanks
>>>> Andrew
>>>
>>>
>>> arch/arm/configs/mvebu_v7_defconfig has
>>> CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
>>> so it should be sufficient to reproduce the issue. I first
>>> encountered
>>> this issue using that very config and observed it on 2 DNS-327L boxes
>>> I
>>> own.
>>>
>>> All I have to do to trigger the bug - enable cpuidle driver and let
>>> the box
>>> sit for some 4-12 hours, till it hard-freezes. If wdt is enabled -
>>> wdt reboot
>>> will happen.
>>
>> That simple! Well i've got a 370RD which has been sat mostly idle for
>> weeks, using the mvebu_v7_defconfig, with a few addition things turned
>> on for testing the Ethernet switch on the board. I've not had that
>> lockup.
>>
>> One thing you can try to narrow it down is the disable the second idle
>> mode. Take a look at armada370_idle_driver. Keep the
>> ARM_CPUIDLE_WFI_STATE but disable the "Deep Idle" state.
>
> Actually you don't have to modify the kernel you can setup the CPU idle
> level
> you want at runtime:
>
> echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
>
> will disable the state1. By doing this on Armada 370 then you
> will only use the WFI state.
>
> Do you still have this issue on v4.0-rc7?
Yep, I can confirm having this issue on 4.0-rc7. I will only be able to
test if
disabling state1 fixes it the next weekend.
>
> Thanks,
>
> Gregory
>
>
>
>>
>> Andrew
>>
--
Regards,
Andrew
Hi Andrew,
On 13/04/2015 16:32, Andrew wrote:
> Gregory CLEMENT писал 13.04.2015 17:16:
>> Hi Andrew(s),
>>
>> On 12/04/2015 21:47, Andrew Lunn wrote:
>>> On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
>>>> Andrew Lunn ?????????? 12.04.2015 17:58:
>>>>>> Okay, got it.
>>>>>> I'll file a bug about this issue to the the bugzilla. However
>>>>>> something
>>>>>> tells me it might not be cpuidle, but D-link. This one's sounds
>>>>>> nasty
>>>>>> and it has been around since 3.16.x. How could it go unnoticed?
>>>>>> Unfortunately I have no other armada-370 hardware to test it.
>>>>>
>>>>> Hi Andrew
>>>>>
>>>>> A few of us here do have hardware to test with. Please give a
>>>>> detailed
>>>>> description of how you reproduce the issue, and your kernel
>>>>> configuration, if different from mvebu_v7_defconfig, or
>>>>> multi_v7_defconfig.
>>>>>
>>>>> Thanks
>>>>> Andrew
>>>>
>>>>
>>>> arch/arm/configs/mvebu_v7_defconfig has
>>>> CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
>>>> so it should be sufficient to reproduce the issue. I first
>>>> encountered
>>>> this issue using that very config and observed it on 2 DNS-327L boxes
>>>> I
>>>> own.
>>>>
>>>> All I have to do to trigger the bug - enable cpuidle driver and let
>>>> the box
>>>> sit for some 4-12 hours, till it hard-freezes. If wdt is enabled -
>>>> wdt reboot
>>>> will happen.
>>>
>>> That simple! Well i've got a 370RD which has been sat mostly idle for
>>> weeks, using the mvebu_v7_defconfig, with a few addition things turned
>>> on for testing the Ethernet switch on the board. I've not had that
>>> lockup.
>>>
>>> One thing you can try to narrow it down is the disable the second idle
>>> mode. Take a look at armada370_idle_driver. Keep the
>>> ARM_CPUIDLE_WFI_STATE but disable the "Deep Idle" state.
>>
>> Actually you don't have to modify the kernel you can setup the CPU idle
>> level
>> you want at runtime:
>>
>> echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
>>
>> will disable the state1. By doing this on Armada 370 then you
>> will only use the WFI state.
>>
>> Do you still have this issue on v4.0-rc7?
>
> Yep, I can confirm having this issue on 4.0-rc7. I will only be able to
> test if
> disabling state1 fixes it the next weekend.
Did you manage to do some test this week-end?
Thanks,
Gregory
>
>>
>> Thanks,
>>
>> Gregory
>>
>>
>>
>>>
>>> Andrew
>>>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Gregory CLEMENT писал 20.04.2015 18:04:
> Hi Andrew,
>
> On 13/04/2015 16:32, Andrew wrote:
>> Gregory CLEMENT писал 13.04.2015 17:16:
>>> Hi Andrew(s),
>>>
>>> On 12/04/2015 21:47, Andrew Lunn wrote:
>>>> On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
>>>>> Andrew Lunn ?????????? 12.04.2015 17:58:
>>>>>>> Okay, got it.
>>>>>>> I'll file a bug about this issue to the the bugzilla. However
>>>>>>> something
>>>>>>> tells me it might not be cpuidle, but D-link. This one's sounds
>>>>>>> nasty
>>>>>>> and it has been around since 3.16.x. How could it go unnoticed?
>>>>>>> Unfortunately I have no other armada-370 hardware to test it.
>>>>>>
>>>>>> Hi Andrew
>>>>>>
>>>>>> A few of us here do have hardware to test with. Please give a
>>>>>> detailed
>>>>>> description of how you reproduce the issue, and your kernel
>>>>>> configuration, if different from mvebu_v7_defconfig, or
>>>>>> multi_v7_defconfig.
>>>>>>
>>>>>> Thanks
>>>>>> Andrew
>>>>>
>>>>>
>>>>> arch/arm/configs/mvebu_v7_defconfig has
>>>>> CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
>>>>> so it should be sufficient to reproduce the issue. I first
>>>>> encountered
>>>>> this issue using that very config and observed it on 2 DNS-327L
>>>>> boxes
>>>>> I
>>>>> own.
>>>>>
>>>>> All I have to do to trigger the bug - enable cpuidle driver and let
>>>>> the box
>>>>> sit for some 4-12 hours, till it hard-freezes. If wdt is enabled -
>>>>> wdt reboot
>>>>> will happen.
>>>>
>>>> That simple! Well i've got a 370RD which has been sat mostly idle
>>>> for
>>>> weeks, using the mvebu_v7_defconfig, with a few addition things
>>>> turned
>>>> on for testing the Ethernet switch on the board. I've not had that
>>>> lockup.
>>>>
>>>> One thing you can try to narrow it down is the disable the second
>>>> idle
>>>> mode. Take a look at armada370_idle_driver. Keep the
>>>> ARM_CPUIDLE_WFI_STATE but disable the "Deep Idle" state.
>>>
>>> Actually you don't have to modify the kernel you can setup the CPU
>>> idle
>>> level
>>> you want at runtime:
>>>
>>> echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
>>>
>>> will disable the state1. By doing this on Armada 370 then you
>>> will only use the WFI state.
>>>
>>> Do you still have this issue on v4.0-rc7?
>>
>> Yep, I can confirm having this issue on 4.0-rc7. I will only be able
>> to
>> test if
>> disabling state1 fixes it the next weekend.
>
> Did you manage to do some test this week-end?
>
> Thanks,
>
> Gregory
>
>
>>
>>>
>>> Thanks,
>>>
>>> Gregory
>>>
>>>
>>>
>>>>
>>>> Andrew
>>>>
>>
Sorry, I've been away for the weekend but managed to take the
hardware home on my way back. I'll rig it for a long test today
in the evening. Expect some test results somewhere around Wednesday.
(Guess it doesn't count unless it's stable for 24+ hours).
--
Regards,
Andrew
On 20/04/2015 17:15, Andrew wrote:
> Gregory CLEMENT писал 20.04.2015 18:04:
>> Hi Andrew,
>>
>> On 13/04/2015 16:32, Andrew wrote:
>>> Gregory CLEMENT писал 13.04.2015 17:16:
>>>> Hi Andrew(s),
>>>>
>>>> On 12/04/2015 21:47, Andrew Lunn wrote:
>>>>> On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
>>>>>> Andrew Lunn ?????????? 12.04.2015 17:58:
>>>>>>>> Okay, got it.
>>>>>>>> I'll file a bug about this issue to the the bugzilla. However
>>>>>>>> something
>>>>>>>> tells me it might not be cpuidle, but D-link. This one's sounds
>>>>>>>> nasty
>>>>>>>> and it has been around since 3.16.x. How could it go unnoticed?
>>>>>>>> Unfortunately I have no other armada-370 hardware to test it.
>>>>>>>
>>>>>>> Hi Andrew
>>>>>>>
>>>>>>> A few of us here do have hardware to test with. Please give a
>>>>>>> detailed
>>>>>>> description of how you reproduce the issue, and your kernel
>>>>>>> configuration, if different from mvebu_v7_defconfig, or
>>>>>>> multi_v7_defconfig.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>> arch/arm/configs/mvebu_v7_defconfig has
>>>>>> CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
>>>>>> so it should be sufficient to reproduce the issue. I first
>>>>>> encountered
>>>>>> this issue using that very config and observed it on 2 DNS-327L
>>>>>> boxes
>>>>>> I
>>>>>> own.
>>>>>>
>>>>>> All I have to do to trigger the bug - enable cpuidle driver and let
>>>>>> the box
>>>>>> sit for some 4-12 hours, till it hard-freezes. If wdt is enabled -
>>>>>> wdt reboot
>>>>>> will happen.
>>>>>
>>>>> That simple! Well i've got a 370RD which has been sat mostly idle
>>>>> for
>>>>> weeks, using the mvebu_v7_defconfig, with a few addition things
>>>>> turned
>>>>> on for testing the Ethernet switch on the board. I've not had that
>>>>> lockup.
>>>>>
>>>>> One thing you can try to narrow it down is the disable the second
>>>>> idle
>>>>> mode. Take a look at armada370_idle_driver. Keep the
>>>>> ARM_CPUIDLE_WFI_STATE but disable the "Deep Idle" state.
>>>>
>>>> Actually you don't have to modify the kernel you can setup the CPU
>>>> idle
>>>> level
>>>> you want at runtime:
>>>>
>>>> echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
>>>>
>>>> will disable the state1. By doing this on Armada 370 then you
>>>> will only use the WFI state.
>>>>
>>>> Do you still have this issue on v4.0-rc7?
>>>
>>> Yep, I can confirm having this issue on 4.0-rc7. I will only be able
>>> to
>>> test if
>>> disabling state1 fixes it the next weekend.
>>
>> Did you manage to do some test this week-end?
>>
>> Thanks,
>>
>> Gregory
>>
>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Gregory
>>>>
>>>>
>>>>
>>>>>
>>>>> Andrew
>>>>>
>>>
>
> Sorry, I've been away for the weekend but managed to take the
No problem
> hardware home on my way back. I'll rig it for a long test today
> in the evening. Expect some test results somewhere around Wednesday.
> (Guess it doesn't count unless it's stable for 24+ hours).
great! thanks to take care of it.
Gregory
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Gregory CLEMENT писал 20.04.2015 18:17:
> On 20/04/2015 17:15, Andrew wrote:
>> Gregory CLEMENT писал 20.04.2015 18:04:
>>> Hi Andrew,
>>>
>>> On 13/04/2015 16:32, Andrew wrote:
>>>> Gregory CLEMENT писал 13.04.2015 17:16:
>>>>> Hi Andrew(s),
>>>>>
>>>>> On 12/04/2015 21:47, Andrew Lunn wrote:
>>>>>> On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
>>>>>>> Andrew Lunn ?????????? 12.04.2015 17:58:
>>>>>>>>> Okay, got it.
>>>>>>>>> I'll file a bug about this issue to the the bugzilla. However
>>>>>>>>> something
>>>>>>>>> tells me it might not be cpuidle, but D-link. This one's sounds
>>>>>>>>> nasty
>>>>>>>>> and it has been around since 3.16.x. How could it go unnoticed?
>>>>>>>>> Unfortunately I have no other armada-370 hardware to test it.
>>>>>>>>
>>>>>>>> Hi Andrew
>>>>>>>>
>>>>>>>> A few of us here do have hardware to test with. Please give a
>>>>>>>> detailed
>>>>>>>> description of how you reproduce the issue, and your kernel
>>>>>>>> configuration, if different from mvebu_v7_defconfig, or
>>>>>>>> multi_v7_defconfig.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Andrew
>>>>>>>
>>>>>>>
>>>>>>> arch/arm/configs/mvebu_v7_defconfig has
>>>>>>> CONFIG_ARM_MVEBU_V7_CPUIDLE=y,
>>>>>>> so it should be sufficient to reproduce the issue. I first
>>>>>>> encountered
>>>>>>> this issue using that very config and observed it on 2 DNS-327L
>>>>>>> boxes
>>>>>>> I
>>>>>>> own.
>>>>>>>
>>>>>>> All I have to do to trigger the bug - enable cpuidle driver and
>>>>>>> let
>>>>>>> the box
>>>>>>> sit for some 4-12 hours, till it hard-freezes. If wdt is enabled
>>>>>>> -
>>>>>>> wdt reboot
>>>>>>> will happen.
>>>>>>
>>>>>> That simple! Well i've got a 370RD which has been sat mostly idle
>>>>>> for
>>>>>> weeks, using the mvebu_v7_defconfig, with a few addition things
>>>>>> turned
>>>>>> on for testing the Ethernet switch on the board. I've not had that
>>>>>> lockup.
>>>>>>
>>>>>> One thing you can try to narrow it down is the disable the second
>>>>>> idle
>>>>>> mode. Take a look at armada370_idle_driver. Keep the
>>>>>> ARM_CPUIDLE_WFI_STATE but disable the "Deep Idle" state.
>>>>>
>>>>> Actually you don't have to modify the kernel you can setup the CPU
>>>>> idle
>>>>> level
>>>>> you want at runtime:
>>>>>
>>>>> echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
>>>>>
>>>>> will disable the state1. By doing this on Armada 370 then you
>>>>> will only use the WFI state.
>>>>>
>>>>> Do you still have this issue on v4.0-rc7?
>>>>
>>>> Yep, I can confirm having this issue on 4.0-rc7. I will only be able
>>>> to
>>>> test if
>>>> disabling state1 fixes it the next weekend.
>>>
>>> Did you manage to do some test this week-end?
>>>
>>> Thanks,
>>>
>>> Gregory
>>>
>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gregory
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>
>>
>> Sorry, I've been away for the weekend but managed to take the
>
> No problem
>
>> hardware home on my way back. I'll rig it for a long test today
>> in the evening. Expect some test results somewhere around Wednesday.
>> (Guess it doesn't count unless it's stable for 24+ hours).
>
>
> great! thanks to take care of it.
>
> Gregory
>>
Sorry for the long delay with testing, but here come the results.
I've rebased everything to 4.1-rc1
1. WFI + DeepIdle => freeze after approx:
* 1 hours and 30 minutes, first test
* 3 hours and 40 minutes, second test
2. WFI only (DeepIdle disabled via sysfs) => Still alive after 13 hours
and counting
The proper patchset will follow as soon as I figure out what change
broke
dns320l-daemon (The utility that speaks to weltrend mcu on ttyS1)
It was working on 3.18.6, on 3.19 and up - it writes data to the port
(and mcu acks it),
but can't read any responses.
Same thing happens to the python (pyserial inside) implementation of the
fan-daemon:
https://github.com/martignlo/DNS-320L
--
Regards,
Andrew
On 03.05.2015 12:18, Andrew wrote:
[...]
> Sorry for the long delay with testing, but here come the results.
> I've rebased everything to 4.1-rc1
>
> 1. WFI + DeepIdle => freeze after approx:
> * 1 hours and 30 minutes, first test
> * 3 hours and 40 minutes, second test
> 2. WFI only (DeepIdle disabled via sysfs) => Still alive after 13 hours
> and counting
>
> The proper patchset will follow as soon as I figure out what change broke
> dns320l-daemon (The utility that speaks to weltrend mcu on ttyS1)
> It was working on 3.18.6, on 3.19 and up - it writes data to the port
> (and mcu acks it),
> but can't read any responses.
>
> Same thing happens to the python (pyserial inside) implementation of the
> fan-daemon:
> https://github.com/martignlo/DNS-320L
Andrew,
did you realize that you request a non-standard UART baudrate in your
python code above:
port = serial.Serial("/dev/ttyS1", 115600, 8, "N", 1, 0.1)
s/115600/115200/
Does that fix your communication issues?
Sebastian
Sebastian Hesselbarth писал 03.05.2015 13:58:
> On 03.05.2015 12:18, Andrew wrote:
> [...]
>> Sorry for the long delay with testing, but here come the results.
>> I've rebased everything to 4.1-rc1
>>
>> 1. WFI + DeepIdle => freeze after approx:
>> * 1 hours and 30 minutes, first test
>> * 3 hours and 40 minutes, second test
>> 2. WFI only (DeepIdle disabled via sysfs) => Still alive after 13
>> hours
>> and counting
>>
>> The proper patchset will follow as soon as I figure out what change
>> broke
>> dns320l-daemon (The utility that speaks to weltrend mcu on ttyS1)
>> It was working on 3.18.6, on 3.19 and up - it writes data to the port
>> (and mcu acks it),
>> but can't read any responses.
>>
>> Same thing happens to the python (pyserial inside) implementation of
>> the
>> fan-daemon:
>> https://github.com/martignlo/DNS-320L
>
> Andrew,
>
> did you realize that you request a non-standard UART baudrate in your
> python code above:
>
> port = serial.Serial("/dev/ttyS1", 115600, 8, "N", 1, 0.1)
>
> s/115600/115200/
>
> Does that fix your communication issues?
>
> Sebastian
If life was that simple ;-)
Unfortunately that's not the issue.
dns320l-daemon ( http://www.aboehler.at/hg/dns320l-daemon ) uses correct
115200 baud and
doesn't work either.
Since I can transmit, but can't receive, I will be first checking out
mpp settings
If that doesn't help, I guess it's git-bisect time.
--
Regards,
Andrew
Hi Andrew,
>
> Sorry for the long delay with testing, but here come the results.
> I've rebased everything to 4.1-rc1
>
> 1. WFI + DeepIdle => freeze after approx:
> * 1 hours and 30 minutes, first test
> * 3 hours and 40 minutes, second test
> 2. WFI only (DeepIdle disabled via sysfs) => Still alive after 13 hours
> and counting
Thanks for testing it. So, to sum-up, WFI+DeepIdle makes the board freeze
after a few hours in 4.1-rc1 and 4.0 for sure. Are you aware of any version
that did not freeze? It would help to know if it was a regression or not.
Andrew Lunn did not report any issue on his 370RD however I will test
it also on an other Armada 370 base board (a Mirabox) using the .config
you already sent.
But what I expect is either a hardware issue, or a hardware configuration
issue in U-Boot. We still rely a lot on the bootloader and I fear that
we have some implicit assumptions.
By the way do you have access on the bootloader sources or at least could
you give us the U-boot version used?
Thanks,
Gregory
>
> The proper patchset will follow as soon as I figure out what change
> broke
> dns320l-daemon (The utility that speaks to weltrend mcu on ttyS1)
> It was working on 3.18.6, on 3.19 and up - it writes data to the port
> (and mcu acks it),
> but can't read any responses.
>
> Same thing happens to the python (pyserial inside) implementation of the
> fan-daemon:
> https://github.com/martignlo/DNS-320L
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Gregory CLEMENT писал 06.05.2015 15:13:
> Hi Andrew,
>
>
>>
>> Sorry for the long delay with testing, but here come the results.
>> I've rebased everything to 4.1-rc1
>>
>> 1. WFI + DeepIdle => freeze after approx:
>> * 1 hours and 30 minutes, first test
>> * 3 hours and 40 minutes, second test
>> 2. WFI only (DeepIdle disabled via sysfs) => Still alive after 13
>> hours
>> and counting
>
> Thanks for testing it. So, to sum-up, WFI+DeepIdle makes the board
> freeze
> after a few hours in 4.1-rc1 and 4.0 for sure. Are you aware of any
> version
> that did not freeze? It would help to know if it was a regression or
> not.
I've been observing it since 3.16 or so, when I first got mainline
running on
the box. So my guess would be that it is NOT a regression.
> Andrew Lunn did not report any issue on his 370RD however I will test
> it also on an other Armada 370 base board (a Mirabox) using the .config
> you already sent.
>
> But what I expect is either a hardware issue, or a hardware
> configuration
> issue in U-Boot. We still rely a lot on the bootloader and I fear that
> we have some implicit assumptions.
>
> By the way do you have access on the bootloader sources or at least
> could
> you give us the U-boot version used?
AFAIK there's no GPL source drop for DNS-327L just yet. I'm using stock
uboot:
U-Boot 2009.08-00043-gcfe3b76-dirty (Dec 03 2012 - 15:27:58)
Marvell version: 1.1.2 NQ.DNS-327.01
Didn't risk to burn upstream u-boot, just in case the hardware required
any
special hacks to work.
> Thanks,
>
> Gregory
>
>
>
>>
>> The proper patchset will follow as soon as I figure out what change
>> broke
>> dns320l-daemon (The utility that speaks to weltrend mcu on ttyS1)
>> It was working on 3.18.6, on 3.19 and up - it writes data to the port
>> (and mcu acks it),
>> but can't read any responses.
>>
>> Same thing happens to the python (pyserial inside) implementation of
>> the
>> fan-daemon:
>> https://github.com/martignlo/DNS-320L
>>
--
Regards,
Andrew