Le 02/08/2019 à 10:58, Arnaud Patard (Rtp) a écrit : > Hi, > > Martin Michlmayr <t...@cyrius.com> writes: > >> * Arnaud Patard <arnaud.pat...@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
