Fimware issue with TVS-672XT on 4.5.1.1456 build 20201015

[zaszkwara]

I had the same problem. My friend from forum.qnap.net.pl is working on this problem, I am his guinea pig - so far he has helped. he is currently working on qkpg, when it's ready - I'll let you know.

[zaszkwara]

https://qnapclub.eu/pl/qpkg/1025

Ok. QPKG ready - form my TVS-672n on i9 9900t working perfect.

[sadrik]

I was relieved to find this post. I thought I was losin' it a bit.

Running 4.5.1.1461 build 20201020, and wondered about a bunch of problems.
- no CPU load in Resource Center or in the Dashboard
- no Mem usage in RC or the dashboard
- no process list in RC.
- felt sluggish, not what I expected.

I had just upgraded to an i5-9400, so this was not what I expected. Also upgraded it to 32GB of RAM.

From clues in this post, poked around at the CLI and found I had over 200 gpuhal_app's running after only about 10 hours since my last boot.

I went brute-force, moved /etc/init.d/init_gpu.sh and /sbin/gpuhal_app to /, then whacked all the gpuhal's with
# ps -aelf | grep "/sbin/gpuhal_app" | awk '{print $1}' | xargs kill
(Yes, I know I could have used 'cut'. I'm rusty.)

Watched my CPU load fall from 90 to 3.5! Woop! And my HBS backup streams from my other NAS nearly quadrupled in throughput.

Looking forward to gpuhal_app being able to properly probe the new GPU on this 9th gen i5.

[OneCD]

I went brute-force, moved /etc/init.d/init_gpu.sh and /sbin/gpuhal_app to /, then whacked all the gpuhal's with
# ps -aelf | grep "/sbin/gpuhal_app" | awk '{print $1}' | xargs kill

Code: Select all

killall gpuhal_app

... would also work, and is much faster to type.

[joobeng]

I went brute-force, moved /etc/init.d/init_gpu.sh and /sbin/gpuhal_app to /, then whacked all the gpuhal's with
# ps -aelf | grep "/sbin/gpuhal_app" | awk '{print $1}' | xargs kill

Code: Select all

killall gpuhal_app

... would also work, and is much faster to type.

Hi OneCD,

Pls explain a bit, what is the problem when we upgrade the CPU to i9-9900 etc, why is there a need to run: killall gpuhal_app ?

Will it help if we put this... killall gpuhal_app ... in autostart.sh ?

I guess even it will help, by running once, we still need to continue to execute this command: killall gpuhal_app ... periodically? Any ways to go about this

Thanks

From: HalfCD

[zaszkwara]

don't you better buy a package of fakegpuhal for 2 euro? And have peace of mind?

[rafale]

Not meaning to be cheap but... No, I would much prefer knowing what is going on and fix it myself rather than downloading an obscur package. Especially when the problem is caused by some firmware changes one can avoid by not upgrading. This does not give me peace of mind.

[OneCD]

Hey @joobeng.

I went brute-force, moved /etc/init.d/init_gpu.sh and /sbin/gpuhal_app to /, then whacked all the gpuhal's with
# ps -aelf | grep "/sbin/gpuhal_app" | awk '{print $1}' | xargs kill

Code: Select all

killall gpuhal_app

... would also work, and is much faster to type.

Pls explain a bit, what is the problem when we upgrade the CPU to i9-9900 etc, why is there a need to run: killall gpuhal_app ?

Will it help if we put this... killall gpuhal_app ... in autostart.sh ?

The best person to answer this would be @sadrik, as this is their solution.

[joobeng]

Hey @joobeng.

I went brute-force, moved /etc/init.d/init_gpu.sh and /sbin/gpuhal_app to /, then whacked all the gpuhal's with
# ps -aelf | grep "/sbin/gpuhal_app" | awk '{print $1}' | xargs kill

Code: Select all

killall gpuhal_app

... would also work, and is much faster to type.

Pls explain a bit, what is the problem when we upgrade the CPU to i9-9900 etc, why is there a need to run: killall gpuhal_app ?

Will it help if we put this... killall gpuhal_app ... in autostart.sh ?

The best person to answer this would be @sadrik, as this is their solution.

Ok. Not familiar with this. Will probably wait.

[sadrik]

I went brute-force, moved /etc/init.d/init_gpu.sh and /sbin/gpuhal_app to /, then whacked all the gpuhal's with
# ps -aelf | grep "/sbin/gpuhal_app" | awk '{print $1}' | xargs kill

Code: Select all

killall gpuhal_app

... would also work, and is much faster to type.

Sure, except I could not tell which killall command that was; on some OSs, killall is tantamount to a shutdown with extreme prejudice. I wasn't going to trust it!

[sadrik]

Hey @joobeng.

I went brute-force, moved /etc/init.d/init_gpu.sh and /sbin/gpuhal_app to /, then whacked all the gpuhal's with
# ps -aelf | grep "/sbin/gpuhal_app" | awk '{print $1}' | xargs kill

Code: Select all

killall gpuhal_app

... would also work, and is much faster to type.

Pls explain a bit, what is the problem when we upgrade the CPU to i9-9900 etc, why is there a need to run: killall gpuhal_app ?

Will it help if we put this... killall gpuhal_app ... in autostart.sh ?

The best person to answer this would be @sadrik, as this is their solution.

I don't know why the current release of the firmware gets hung up on probing the built-in Intel GPU. My system was spawning hundreds of those processes, raising my system load to over 80 (having it down around the number of cores you have is desirable!).

You can either downgrade to your old supported CPU and its diminutive core count, or go brute force and slaughter the gpu probe temporarily like I did. Your call.

Yes, my system will not be leveraging its GPU, presumably for transcoding, hybridstation, and whatever else it would like to. But I wanted those cores for virtualisation.

I see a new build has been released. I will look at that tomorrow.

[OneCD]

Sure, except I could not tell which killall command that was; on some OSs, killall is tantamount to a shutdown with extreme prejudice. I wasn't going to trust it!

On which OS does 'killall' behave that way?

[sadrik]

Sure, except I could not tell which killall command that was; on some OSs, killall is tantamount to a shutdown with extreme prejudice. I wasn't going to trust it!

On which OS does 'killall' behave that way?

Solaris for one. I’ve see it on a few others over the years too, with unfortunate results. Without man pages on the Qnap, hard to trust what it’ll do!

https://xorl.wordpress.com/2011/10/19/a ... s-killall/

[OneCD]

Solaris for one.

I'll have to remember that one.

Without man pages on the Qnap, hard to trust what it’ll do!

QTS includes QNAP's own compilation of BusyBox utilities, but lately, they've been switching-over to GNU utilities instead. I suspect the devs were tired of being hamstrung by BusyBox.

[ramx2]

Well a note, the final firmware 4.5.1.1465 build 20201024 caused my nas to reboot without notice while copying files with qfile from an external drive to the raid array.
I had to downgrade to 4.5.1.1461 build 20201020 which it’s not doing that at all!!