Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Feb 2015 18:31:43 +0200
From:      Beeblebrox <zaphod@berentweb.com>
To:        freebsd-current@freebsd.org
Subject:   system failure: cannot kill webkit-gtk3 if using dumbell/radeon
Message-ID:  <20150227183143.708a0656@rsbsd.rsb>

next in thread | raw e-mail | index | archive | help
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(mast=
er)-dirty)
* I started www/midori and was getting segfaults with URL that start with "=
h". I re-built midori using WITH_DEBUG=3Dyes, 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.or=
g 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 prod=
uce any of symptoms above.
When killing WebKitWeb, the higher process_numbers died, but the lower proc=
ess_numbers resisted. So the spawned processes could be killed, but the mas=
ter process could not.

--=20
FreeBSD_amd64_11-Current_RadeonKMS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150227183143.708a0656>