I have had a shutdown problem similar to this one you are having for the longest while.
Besides searching all over the web for answers and posting to specific or relevant OEM forums, I also reported it to bugzilla.kernel.org back in 12/2018:
https://bugzilla.kernel.org/show_bug.cgi?id=201965
Never had a reply.
Then again this year:
https://bugzilla.kernel.org/show_bug.cgi?id=212443
Still waiting for input from somebody at bugzilla but I'm not holding my breath.
Sifting through all I have read about it, my short summary of what has been happening (for many years now) is this:
Motherboard BIOS files are not written strictly observing the specifications from the governing bodies.
They are written to the (much laxer) specifications given to them by Microsoft and the BIOS writers/OEMs accept them because if they do not, their hardware will not be "Windows Certified" which basically means that it will not be sold.
The Linux kernel people have taken the only possible stance which is to work around these 'quirks' within the kernel so that Linux will boot on most any motherboard but it is short of an uphill battle as the problem is permanent and ongoing.
As this happens, newer kernels end up revealing old and previously unseen or unreported bugs (probably your case) lurking in reused/rehashed BIOS code inside the libraries used by the usual BIOS OEM crowd ie: Intel, AMI, Phoenix, Award et al.
If you haven't yet, you could try to get a BIOS upgrade from Gigabyte if it is available and see what happens and if it does 'not' fix the problem, report it to them and see what their TS has to say.
Good luck with that, their motherboards probably have no Linux support and will probably send you to talk to A, B or C's chipset manufacturer.
The other option, which I strongly suggest, is to go back to the Linux kernel you were using before the problem arose.
But before doing that, send the Parrot OS kernel maintainers the following files from 'both' installations. ie: the one with the problem and the one without the problem.
- screenshot (at hang)
- output of
inxi -Fxxxz (as root)
- dmesg
- acpidump
- syslog
The data will help them see and try to solve the issue and maybe write a patch that may/will/should be eventually reported upstream for a fix in a next/future kernel release.
Sorry but I don't have another solution to offer.
The lesson would be that one should only purchase Linux certified HW.
But I have a Sun Microsystems workstation 'and' the same problem you have, so the lesson is actually lacking in value.
Best,
G.
