Re: Kernel quirks on QNAP TS-109 (Marvell orion)
Le 02/08/2019 à 10:58, Arnaud Patard (Rtp) a écrit :
> Hi,
>
> Martin Michlmayr <tbm@cyrius.com> writes:
>
>> * Arnaud Patard <arnaud.patard@rtp-net.org> [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 to: