Matthieu CERDA <kegeruneku+debian...@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 <t...@cyrius.com> writes: >>>> * Matthieu CERDA <kegeruneku+debian...@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
