Re: Kernel quirks on QNAP TS-109 (Marvell orion)
Matthieu CERDA <kegeruneku+debianarm@ironflake.org> 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 <tbm@cyrius.com> writes:
>>>> * Matthieu CERDA <kegeruneku+debianarm@ironflake.org> [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 to: