system failure: cannot kill webkit-gtk3 if using dumbell/radeon

I just hit a major kernel bug with the new Radeon code

* I'm on dumbbell's patch_38 for world/kernel (11.0-CURRENT #2 45116d3(master)-dirty)
* I started www/midori and was getting segfaults with URL that start with "h". I re-built midori using WITH_DEBUG=yes, got no output, then re-built without DEBUG enabled because I was having image display problems. Reported the problem as port issue: http://freebsd.1045724.n5.nabble.com/www-midori-dislikes-the-letter-h-td5992424.html
* At some point while using Midori (and right after I logged into Facebook) sytem started to hiccup and slow down, so I swithced to tty*. I start X.org with "startx", so I tried to kill X with "ctr+c" > no response.

Here's where it gets interesting. Each step indicated with "*" was done on different tty, all tty's were logged in as root:
* issue "# top" > tty froze, does not exit.
* Several other simple root-level commands from different TTY result in TTY freeze.
* Let's free some RAM:
"# service kill xyz" > nothing, no result
kill -9 process-name > ok
jail -r aa bb cc > tty freeze
* jls > jails still running, previous command obviously could not kill
let's kill processes:
kill -9 process_num_for_midori > ok
kill -9 process_num_for_several others > ok
kill -9 process_num_for_WebKitWeb > NOPE, DOES NOT KILL
* "# shutdown now" > hangs for ever
* On TTY1: shows signal 15, but does not proceed. Seems to have
difficulty killing jails. "ctl+alt+del" helps a bit. Shuts down
eventually, after appx 10 mins.

After restart and in xorg, one cycle of start/stop for Midori does not produce any of symptoms above.
When killing WebKitWeb, the higher process_numbers died, but the lower process_numbers resisted. So the spawned processes could be killed, but the master process could not.

-- 
FreeBSD_amd64_11-Current_RadeonKMS