Thx for the answers and suggestions. In order to make sure I am still tracking
the same hard lockup, will any failure to load the gpu microcode will lead to a
total freeze of the machine ?

Currently in the setup where I can get some logs it can fail in 2 ways:

For both it starts with: "ring 0 stalled" is detected.

1: kworker triggers the gpu soft reset.

[drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs
aborting.
[drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing C483
(len 254, WS 0, PS 4) @ 0xC4AD
[drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing BC59
(len 74, WS 0, PS 8) @ 0xBC8E
si_mc_program::radeon_mc_wait_for_idle, the one after WREG32(vram.start) and
before 
evergreen_mc_resume. Can it freeze on a call to RREG32(SRBM_STATUS) & 0x1F00 ?

2: the gl app triggers the gpu soft reset.

The first failure is then evergreen_mc_stop::radeon_mc_wait_for_idle which
reached the timeout and then same errors as 1:
But the freeze happens a bit later in the radeon_gpu_reset sequence, in
atombios_crtc_dpms in one of its atombios_X(crtc, ATOM_Y) calls.

So my question above, will any single problem during the gpu soft reset lead to
a machine freeze ? If yes then I am probably tracking now a different freeze
that the one I reported initially.

Also in kernel's drm_drv.c::drm_err I tried to add a call to sys_sync();
(#include <linux/syscalls.h>) to make sure all errors are written on disk so
that I can read them after a reboot (Instead of having null characters ^@). But
I got an undefined reference. How could I add dependcy on fs/sync.c ? I have
not search long but at first glance tty driver calls it and there is nothing
special in the Makefile.
(As an alternative I am running a while true; sleep 0.5; sync; done but it does
not work all the time)

Thx!