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

On Wed, Mar 4, 2015 at 8:47 AM, Beeblebrox <zaphod_at_berentweb.com> wrote:

> Hi.
> > Sorry for the delay to get back to you (including your private emails).
> Not a problem, those were various reports left to your judgment as to
> their significance. Better to provide more information rather than less.
>
> slim failure: Traced to dbus start failure at bootup. Slim now starts,
> after manual start of dbus.
> GDM failure: Starts, but after taking a long time. I'll send Koop the log
> files from my recent attempt.
>
> > You mentioned  "ghost text" with nano in vt(4). Could you please file
> > a bug in Bugzilla with a picture of what you get? Please join a dmesg
> too.
> I can confirm this is still an issue. I'll try to get to it at the soonest.
>
> > the unkillable processes are interesting. If you can reproduce
> I really don't know how it came about, so no promises. The most
> interesting part of that error however, was the behaviour of vt(4). The
> problem is not only unkillable processes, but TTY freeze when doing an
> unrelated action to the locked process. I mean, nano or top have nothing to
> do with webkit-gtk3, yet caused TTY freeze (due to GPU lock-up I ignorantly
> presume)
>
> > the flickering you see with some applications/desktop environments
> This is really serious. It has lessened, but not gone away.
> Additionally, I started to get a "sticky mouse" problem some time ago
> and I'm inclined to agree with HPS' assessment that "drm2.ko graphics
> driver has some hard spinning loops" (
> http://freebsd.1045724.n5.nabble.com/Some-unresolved-but-important-X-org-problems-td5987904.html
> )
> Have not had the hardware to test with different GPU unfortunately.
>
> Regards.
>
>
This sounds a lot like another rcorder issue. If you run "rcorder
/etc/rc.d/* /usr/locl/rtc/rc.d/* > /dev/null", do you get errors...
particularly circular dependencies? I know that webcamd and dbus have a
problem. These are very dangerous as the behavior when they occur is
undefined, very unstable and can easily result in daemons failing to start.
They are also a real pain to track down. Most often just looking at
"REQUIRES" and "BEFORE" statements is not very useful.

Note that reports of "no providers" are warnings and often normal and
expected.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman_at_gmail.com