Kernel quirks on QNAP TS-109 (Marvell orion)

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Kernel quirks on QNAP TS-109 (Marvell orion)

Matthieu CERDA-2

Greetings,

I recently got lent a spare QNAP TS-109, that I intend to run on Debian for backup purpose.

Installation went well (thanks https://www.cyrius.com/debian/orion/qnap/ts-109/) using the stretch installer, however I noticed some quirks:

  • On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work: calling it with "qcontrol --direct buzzer" outputs no error, but does nothing, and the status led stays red/green after system has booted.
  • On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does not work as well, and more annoyingly, no Ethernet interface gets initialized. dmesg shows a kernel oops. (copy attached)

Are those errors that someone here as encountered before ? (so I do not create duplicate bug reports somewhere, just in case...)

Thank you in advance !

--

Matthieu CERDA


marvell-orion-ethernet-oops.txt (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Martin Michlmayr
* Matthieu CERDA <[hidden email]> [2019-07-26 00:17]:
>   * On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
>     calling it with "qcontrol --direct buzzer" outputs no error, but
>     does nothing, and the status led stays red/green after system has
>     booted.

There are different potential causes for this but I think I've seen
this before myself and this particular issue hasn't been reported.

>   * On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does
>     not work as well, and more annoyingly, no Ethernet interface gets
>     initialized. dmesg shows a kernel oops. (copy attached)

This sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712

--
Martin Michlmayr
https://www.cyrius.com/

Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Arnaud Patard (Rtp)
Martin Michlmayr <[hidden email]> writes:

> * Matthieu CERDA <[hidden email]> [2019-07-26 00:17]:
>>   * On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
>>     calling it with "qcontrol --direct buzzer" outputs no error, but
>>     does nothing, and the status led stays red/green after system has
>>     booted.
>
> There are different potential causes for this but I think I've seen
> this before myself and this particular issue hasn't been reported.
>
>>   * On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does
>>     not work as well, and more annoyingly, no Ethernet interface gets
>>     initialized. dmesg shows a kernel oops. (copy attached)
>
> This sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712

As noted in the bug, might worth reporting to Andrew. iirc ts109 are
devices without device tree and I'm curious to see how the kernel handle
things like of_clk_get(pdev->dev.of_node, i) on a system without DT.
of_clk_get() is coded like this:

struct clk *of_clk_get(struct device_node *np, int index)
{
        return __of_clk_get(np, index, np->full_name, NULL);
}

afair in systems without DT, of_node is null, np->full_name has high
chances to crash. Again, as noted by the bug, it's likely coming from
96cb4342382290c935d933a08feb57d6d0183071 which is replacing
the devm_clk_get() call to of_clk_get().

Might worth trying to build a kernel with code looking like
(not even compile tested):

if (pdev->dev.of_node) {
        for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
            dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
...
        }
        if (!IS_ERR(of_clk_get(pdev->dev.of_node, ARRAY_SIZE(dev->clk))))
        ...
       
else {
     dev->clk[0] = clk_get(&pdev->dev, NULL);
     if (!IS_ERR(dev->clk[0]))
        clk_prepare_enable(dev->clk[0]);
}


Arnaud.

Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Matthieu CERDA-2
Le 26/07/2019 à 11:29, Arnaud Patard (Rtp) a écrit :
> Martin Michlmayr <[hidden email]> writes:
>> * Matthieu CERDA <[hidden email]> [2019-07-26 00:17]:
>>>   * On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
>>>     calling it with "qcontrol --direct buzzer" outputs no error, but
>>>     does nothing, and the status led stays red/green after system has
>>>     booted.
>> There are different potential causes for this but I think I've seen
>> this before myself and this particular issue hasn't been reported.

I'll open a bug report on the Debian package to discuss the issue there.

>>>   * On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does
>>>     not work as well, and more annoyingly, no Ethernet interface gets
>>>     initialized. dmesg shows a kernel oops. (copy attached)
>> This sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712
Yep, I looks like the exact same issue. I'll be happy to help if I can,
at least by testing the fix that Arnaud proposed below :)

> As noted in the bug, might worth reporting to Andrew. iirc ts109 are
> devices without device tree and I'm curious to see how the kernel handle
> things like of_clk_get(pdev->dev.of_node, i) on a system without DT.
> of_clk_get() is coded like this:
>
> struct clk *of_clk_get(struct device_node *np, int index)
> {
>         return __of_clk_get(np, index, np->full_name, NULL);
> }
>
> afair in systems without DT, of_node is null, np->full_name has high
> chances to crash. Again, as noted by the bug, it's likely coming from
> 96cb4342382290c935d933a08feb57d6d0183071 which is replacing
> the devm_clk_get() call to of_clk_get().
>
> Might worth trying to build a kernel with code looking like
> (not even compile tested):
>
> if (pdev->dev.of_node) {
>         for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
>             dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
> ...
>         }
>         if (!IS_ERR(of_clk_get(pdev->dev.of_node, ARRAY_SIZE(dev->clk))))
>         ...
>        
> else {
>      dev->clk[0] = clk_get(&pdev->dev, NULL);
>      if (!IS_ERR(dev->clk[0]))
>         clk_prepare_enable(dev->clk[0]);
> }
>
>
> Arnaud.

All right, I'll try to build a 4.19.0-0.bpo.5-marvell-based kernel with
the patch.

I will also try building a linux master-based kernel, to test if
https://github.com/torvalds/linux/commit/433a06d7d74e677c40b1148c70c48677ff62fb6b
solves the issue.

Thank you for the help to both of you :) (and also, thank you Martin for
the highly detailed website and instructions about QNAP devices)

Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Matthieu CERDA-2
Hello again !

Le 26/07/2019 à 22:36, Matthieu CERDA a écrit :

> Le 26/07/2019 à 11:29, Arnaud Patard (Rtp) a écrit :
>> Martin Michlmayr <[hidden email]> writes:
>>> * Matthieu CERDA <[hidden email]> [2019-07-26 00:17]:
>>>>   * On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
>>>>     calling it with "qcontrol --direct buzzer" outputs no error, but
>>>>     does nothing, and the status led stays red/green after system has
>>>>     booted.
>>> There are different potential causes for this but I think I've seen
>>> this before myself and this particular issue hasn't been reported.
> I'll open a bug report on the Debian package to discuss the issue there.
Done: https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=qcontrol

>>>>   * On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does
>>>>     not work as well, and more annoyingly, no Ethernet interface gets
>>>>     initialized. dmesg shows a kernel oops. (copy attached)
>>> This sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712
> Yep, I looks like the exact same issue. I'll be happy to help if I can,
> at least by testing the fix that Arnaud proposed below :)
>> As noted in the bug, might worth reporting to Andrew. iirc ts109 are
>> devices without device tree and I'm curious to see how the kernel handle
>> things like of_clk_get(pdev->dev.of_node, i) on a system without DT.
>> of_clk_get() is coded like this:
>> (...)
>>
>> Arnaud.
> All right, I'll try to build a 4.19.0-0.bpo.5-marvell-based kernel with
> the patch.
>
> I will also try building a linux master-based kernel, to test if
> https://github.com/torvalds/linux/commit/433a06d7d74e677c40b1148c70c48677ff62fb6b
> solves the issue.
>
> Thank you for the help to both of you :) (and also, thank you Martin for
> the highly detailed website and instructions about QNAP devices)
Well, good news. the fix Arnaud proposed seems to work! (cf patch joined
to this mail)

---8<---
[   35.281494] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[   35.348374] libphy: PHY orion-mdio-mii:08 not found
[   35.696124] libphy: PHY orion-mdio-mii:08 not found
(...)
[   35.780513] libphy: orion_mdio_bus: probed
(...)
[   35.998946] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
address 00:08:9b:ac:e2:f4
(...)
[   46.105299] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[   49.537051] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000
Mb/s, full duplex, flow control enabled
---8<---

I'll send a copy to Andrew, if that's okay with you Arnaud ?


arm-orion-ethernet-fix.patch (665 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Arnaud Patard (Rtp)
Matthieu CERDA <[hidden email]> writes:

Hi,

> Hello again !
>
> Le 26/07/2019 à 22:36, Matthieu CERDA a écrit :
>> Le 26/07/2019 à 11:29, Arnaud Patard (Rtp) a écrit :
>>> Martin Michlmayr <[hidden email]> writes:
>>>> * Matthieu CERDA <[hidden email]> [2019-07-26 00:17]:
>>>>>   * On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
>>>>>     calling it with "qcontrol --direct buzzer" outputs no error, but
>>>>>     does nothing, and the status led stays red/green after system has
>>>>>     booted.
>>>> There are different potential causes for this but I think I've seen
>>>> this before myself and this particular issue hasn't been reported.
>> I'll open a bug report on the Debian package to discuss the issue there.
> Done: https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=qcontrol
>>>>>   * On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does
>>>>>     not work as well, and more annoyingly, no Ethernet interface gets
>>>>>     initialized. dmesg shows a kernel oops. (copy attached)
>>>> This sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712
>> Yep, I looks like the exact same issue. I'll be happy to help if I can,
>> at least by testing the fix that Arnaud proposed below :)
>>> As noted in the bug, might worth reporting to Andrew. iirc ts109 are
>>> devices without device tree and I'm curious to see how the kernel handle
>>> things like of_clk_get(pdev->dev.of_node, i) on a system without DT.
>>> of_clk_get() is coded like this:
>>> (...)
>>>
>>> Arnaud.
>> All right, I'll try to build a 4.19.0-0.bpo.5-marvell-based kernel with
>> the patch.
>>
>> I will also try building a linux master-based kernel, to test if
>> https://github.com/torvalds/linux/commit/433a06d7d74e677c40b1148c70c48677ff62fb6b
>> solves the issue.
>>
>> Thank you for the help to both of you :) (and also, thank you Martin for
>> the highly detailed website and instructions about QNAP devices)
>
> Well, good news. the fix Arnaud proposed seems to work! (cf patch joined
> to this mail)
>
> ---8<---
> [   35.281494] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> [   35.348374] libphy: PHY orion-mdio-mii:08 not found
> [   35.696124] libphy: PHY orion-mdio-mii:08 not found
> (...)
> [   35.780513] libphy: orion_mdio_bus: probed
> (...)
> [   35.998946] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
> address 00:08:9b:ac:e2:f4
> (...)
> [   46.105299] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
> [   49.537051] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000
> Mb/s, full duplex, flow control enabled
> ---8<---


So, with it, your network is back ? At least no crash, so that's an
improvement.

>
> I'll send a copy to Andrew, if that's okay with you Arnaud ?

Sending the patch in its current form  will probably not get far,
unfortunately. This patch needs proper formating. I can you bear with
me, I think I should be able to provide the patch in a proper form today
(no fonctional change, only space/tab formating and a patch header added).

Once I have a proper patch, I'll send it here and bug #908712 in Cc: to
allow other people to review it. If no complain, after 2/3 days, I'll send
it to netdev@ with you and Andrew in Cc:


Arnaud

Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Arnaud Patard (Rtp)
In reply to this post by Matthieu CERDA-2
Matthieu CERDA <[hidden email]> writes:

[ Adding bug #908712 in Cc: ]

> Hello again !
>
> Le 26/07/2019 à 22:36, Matthieu CERDA a écrit :
>> Le 26/07/2019 à 11:29, Arnaud Patard (Rtp) a écrit :
>>> Martin Michlmayr <[hidden email]> writes:
>>>> * Matthieu CERDA <[hidden email]> [2019-07-26 00:17]:
>>>>>   * On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
>>>>>     calling it with "qcontrol --direct buzzer" outputs no error, but
>>>>>     does nothing, and the status led stays red/green after system has
>>>>>     booted.
>>>> There are different potential causes for this but I think I've seen
>>>> this before myself and this particular issue hasn't been reported.
>> I'll open a bug report on the Debian package to discuss the issue there.
> Done: https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=qcontrol
>>>>>   * On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does
>>>>>     not work as well, and more annoyingly, no Ethernet interface gets
>>>>>     initialized. dmesg shows a kernel oops. (copy attached)
>>>> This sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712
>> Yep, I looks like the exact same issue. I'll be happy to help if I can,
>> at least by testing the fix that Arnaud proposed below :)
>>> As noted in the bug, might worth reporting to Andrew. iirc ts109 are
>>> devices without device tree and I'm curious to see how the kernel handle
>>> things like of_clk_get(pdev->dev.of_node, i) on a system without DT.
>>> of_clk_get() is coded like this:
>>> (...)
>>>
>>> Arnaud.
>> All right, I'll try to build a 4.19.0-0.bpo.5-marvell-based kernel with
>> the patch.
>>
>> I will also try building a linux master-based kernel, to test if
>> https://github.com/torvalds/linux/commit/433a06d7d74e677c40b1148c70c48677ff62fb6b
>> solves the issue.
>>
>> Thank you for the help to both of you :) (and also, thank you Martin for
>> the highly detailed website and instructions about QNAP devices)
>
> Well, good news. the fix Arnaud proposed seems to work! (cf patch joined
> to this mail)
>
> ---8<---
> [   35.281494] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> [   35.348374] libphy: PHY orion-mdio-mii:08 not found
> [   35.696124] libphy: PHY orion-mdio-mii:08 not found
> (...)
> [   35.780513] libphy: orion_mdio_bus: probed
> (...)
> [   35.998946] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
> address 00:08:9b:ac:e2:f4
> (...)
> [   46.105299] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
> [   49.537051] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000
> Mb/s, full duplex, flow control enabled
> ---8<---
>
> I'll send a copy to Andrew, if that's okay with you Arnaud ?
As promised, please fix the updated patch. Please note that there are 2
patches, one for linux HEAD and one for 4.19. I had to make two patches
as there are changes in HEAD not present in 4.19. btw, your version of
the 4.19 patch is possibly broken with OF platforms, that's why your
patches and mine are different. For your case on orion5x, it should not
make any difference.


Arnaud

drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case

Orion5.x systems are still using machine files and not device-tree.
Commit 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be
specified for orion-mdio") has replaced devm_clk_get() with of_clk_get(),
leading to a oops at boot and not working network, as reported in
https://lists.debian.org/debian-arm/2019/07/msg00088.html and possibly in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712.

Link: https://lists.debian.org/debian-arm/2019/07/msg00088.html
Fixes: 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
Signed-off-by: Arnaud Patard <[hidden email]>
Index: linux-next/drivers/net/ethernet/marvell/mvmdio.c
===================================================================
--- linux-next.orig/drivers/net/ethernet/marvell/mvmdio.c
+++ linux-next/drivers/net/ethernet/marvell/mvmdio.c
@@ -319,20 +319,33 @@ static int orion_mdio_probe(struct platf
 
  init_waitqueue_head(&dev->smi_busy_wait);
 
- for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
- dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
- if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+ if (pdev->dev.of_node) {
+ for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
+ dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
+ if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto out_clk;
+ }
+ if (IS_ERR(dev->clk[i]))
+ break;
+ clk_prepare_enable(dev->clk[i]);
+ }
+
+ if (!IS_ERR(of_clk_get(pdev->dev.of_node,
+       ARRAY_SIZE(dev->clk))))
+ dev_warn(&pdev->dev,
+ "unsupported number of clocks, limiting to the first "
+ __stringify(ARRAY_SIZE(dev->clk)) "\n");
+ } else {
+ dev->clk[0] = clk_get(&pdev->dev, NULL);
+ if (PTR_ERR(dev->clk[0]) == -EPROBE_DEFER) {
  ret = -EPROBE_DEFER;
  goto out_clk;
  }
- if (IS_ERR(dev->clk[i]))
- break;
- clk_prepare_enable(dev->clk[i]);
+ if (!IS_ERR(dev->clk[0]))
+ clk_prepare_enable(dev->clk[0]);
  }
 
- if (!IS_ERR(of_clk_get(pdev->dev.of_node, ARRAY_SIZE(dev->clk))))
- dev_warn(&pdev->dev, "unsupported number of clocks, limiting to the first "
- __stringify(ARRAY_SIZE(dev->clk)) "\n");
 
  dev->err_interrupt = platform_get_irq(pdev, 0);
  if (dev->err_interrupt > 0 &&

[PATCH 4.19] drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case

Orion5.x systems are still using machine files and not device-tree.
Commit 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be
specified for orion-mdio") has replaced devm_clk_get() with of_clk_get(),
leading to a oops at boot and not working network, as reported in
https://lists.debian.org/debian-arm/2019/07/msg00088.html and possibly in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712.

Link: https://lists.debian.org/debian-arm/2019/07/msg00088.html
Fixes: 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
Signed-off-by: Arnaud Patard <[hidden email]>

Index: 4.19/drivers/net/ethernet/marvell/mvmdio.c
===================================================================
--- 4.19.orig/drivers/net/ethernet/marvell/mvmdio.c
+++ 4.19/drivers/net/ethernet/marvell/mvmdio.c
@@ -319,11 +319,18 @@ static int orion_mdio_probe(struct platf
 
  init_waitqueue_head(&dev->smi_busy_wait);
 
- for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
- dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
- if (IS_ERR(dev->clk[i]))
- break;
- clk_prepare_enable(dev->clk[i]);
+ if (pdev->dev.of_node) {
+ for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
+ dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
+ if (IS_ERR(dev->clk[i]))
+ break;
+ clk_prepare_enable(dev->clk[i]);
+ }
+ } else {
+ dev->clk[0] = clk_get(&pdev->dev, NULL);
+ if (!IS_ERR(dev->clk[0]))
+ clk_prepare_enable(dev->clk[0]);
+
  }
 
  dev->err_interrupt = platform_get_irq(pdev, 0);
Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Martin Michlmayr
* Arnaud Patard <[hidden email]> [2019-07-29 14:45]:
> As promised, please fix the updated patch. Please note that there are 2

Can you submit it upstream for review, or if you have already, send us
a link.

--
Martin Michlmayr
https://www.cyrius.com/

Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Arnaud Patard (Rtp)
Hi,

Martin Michlmayr <[hidden email]> writes:

> * Arnaud Patard <[hidden email]> [2019-07-29 14:45]:
>> As promised, please fix the updated patch. Please note that there are 2
>
> Can you submit it upstream for review, or if you have already, send us
> a link.

Sorry for the delay. I was waiting for some feedback before sending and
then got busy with other stuff. I've now sent it:
https://marc.info/?l=linux-netdev&m=156473570707976&w=2.

Arnaud

Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Matthieu CERDA-2
Le 02/08/2019 à 10:58, Arnaud Patard (Rtp) a écrit :

> Hi,
>
> Martin Michlmayr <[hidden email]> writes:
>
>> * Arnaud Patard <[hidden email]> [2019-07-29 14:45]:
>>> As promised, please fix the updated patch. Please note that there are 2
>> Can you submit it upstream for review, or if you have already, send us
>> a link.
> Sorry for the delay. I was waiting for some feedback before sending and
> then got busy with other stuff. I've now sent it:
> https://marc.info/?l=linux-netdev&m=156473570707976&w=2.
>
> Arnaud

That's awesome, thank you Arnaud :)

About the qcontrol-related issues, I have a conjecture you guys might be
experienced enough to debunk (or confirm), I also noticed that the
TS-109 fails to shutdown properly, either using systemd or sysvinit
(After "[  243.405182] qnap_tsx09_power_off: triggering power-off...",
it panic()'s with systemd getting killed, and stalls without powering
off, and with sysvinit it simply stalls)

After some quick research, it seems that both qcontrol related stuff
(buzzer, leds, ...) and shutting down are handled by the NAS PIC,
available through proprietary kernel stuff on stock QNAP kernel and
through GPIO / ttyS1,19200n8 on vanilla ones.

I get some:

---8<---

[   44.325898] synth uevent: /gpiochip0: failed to send uevent
[   44.325949] gpio gpiochip0: uevent: failed to send synthetic uevent

---8<---

In dmesg during boot, which I suspect means that something is wrong in
GPIO / PIC communication.

I tried to replicate the  way Linux shuts the NAS down (send 'A' over
ttyS1,19200n8) and nothing happened, neigher shutdown or line echo.

Are there known ways for the PIC access to be broken, is this specific
to my NAS (but QTS seems to work fine with it) or maybe a regression
specific to TS-X09 ?

Thanks for your time.

--

Matthieu CERDA

Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Martin Michlmayr
Copying the relevant Debian bug (#933294).

* Matthieu CERDA <[hidden email]> [2019-08-04 15:42]:
> In dmesg during boot, which I suspect means that something is wrong in
> GPIO / PIC communication.
>
> I tried to replicate the  way Linux shuts the NAS down (send 'A' over
> ttyS1,19200n8) and nothing happened, neigher shutdown or line echo.
>
> Are there known ways for the PIC access to be broken, is this specific
> to my NAS (but QTS seems to work fine with it) or maybe a regression
> specific to TS-X09 ?

I believe your analysis is correct.  This sounds very similar to what
I saw on a TS-x09 in the past.

I fetched my TS-109 from the attic and will try to see if I see the
same issue.

--
Martin Michlmayr
https://www.cyrius.com/

Reply | Threaded
Open this post in threaded view
|

Re: Bug#933294: Kernel quirks on QNAP TS-109 (Marvell orion)

Ian Campbell-5
On Sun, 2019-08-04 at 15:51 +0200, Martin Michlmayr wrote:

> Copying the relevant Debian bug (#933294).
>
> * Matthieu CERDA <[hidden email]> [2019-08-04 15:42]:
> > In dmesg during boot, which I suspect means that something is wrong in
> > GPIO / PIC communication.
> >
> > I tried to replicate the  way Linux shuts the NAS down (send 'A' over
> > ttyS1,19200n8) and nothing happened, neigher shutdown or line echo.
> >
> > Are there known ways for the PIC access to be broken, is this specific
> > to my NAS (but QTS seems to work fine with it) or maybe a regression
> > specific to TS-X09 ?
>
> I believe your analysis is correct.  This sounds very similar to what
> I saw on a TS-x09 in the past.

Sounds like this is more a kernel issue than a qcontrol one? Shall we
reassign?

>
> I fetched my TS-109 from the attic and will try to see if I see the
> same issue.
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug#933294: Kernel quirks on QNAP TS-109 (Marvell orion)

Martin Michlmayr
reassign 933294 QNAP TS-109 (orion): ttyS / PIC communication fails
thanks

* Ian Campbell <[hidden email]> [2019-08-07 20:04]:
> > I believe your analysis is correct.  This sounds very similar to what
> > I saw on a TS-x09 in the past.
>
> Sounds like this is more a kernel issue than a qcontrol one? Shall we
> reassign?

Yeah.
--
Martin Michlmayr
https://www.cyrius.com/

Reply | Threaded
Open this post in threaded view
|

Re: Kernel quirks on QNAP TS-109 (Marvell orion)

Martin Michlmayr
In reply to this post by Arnaud Patard (Rtp)
* Arnaud Patard <[hidden email]> [2019-08-02 10:58]:
> Sorry for the delay. I was waiting for some feedback before sending and
> then got busy with other stuff. I've now sent it:
> https://marc.info/?l=linux-netdev&m=156473570707976&w=2.

For the record, this has been accepted and queued for stable:
https://marc.info/?l=linux-netdev&m=156503710404939&w=2

--
Martin Michlmayr
https://www.cyrius.com/