https://bugs.freedesktop.org/show_bug.cgi?id=100465 --- Comment #12 from Julien Isorce --- 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 ) 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! -- You are receiving this mail because: You are the assignee for the bug.