Re: system failure: cannot kill webkit-gtk3 if using dumbell/radeon
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. -- FreeBSD_amd64_11-Current_RadeonKMS Please include my email when responding-I may have unabled auto-delivery. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: system failure: cannot kill webkit-gtk3 if using dumbell/radeon
On Wed, Mar 4, 2015 at 8:47 AM, Beeblebrox zap...@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: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: system failure: cannot kill webkit-gtk3 if using dumbell/radeon
Hi! Sorry for the delay to get back to you (including your private emails). I'll answer to all at once here, I hope you don't mind :) I'm not sure the issues you have with the 'h' letter in Midori, the flickering you see with some applications/desktop environments or the slim/GDM failure are related to this DRM update or the kernel video drivers in general. I CC'd Koop Mast, in case he can help debug GDM. You mentionned 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. However, the unkillable processes are interesting. If you can reproduce this, could you please post the output of procstat -kk -a when this happens? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: system failure: cannot kill webkit-gtk3 if using dumbell/radeon
I see some errors in my last post, correcting: I used # service onestop xyz and NOT # service kill xyz One of the TTY freezes occurred when exiting nano: ctrl+x, y (exit save) -- FreeBSD_amd64_11-Current_RadeonKMS Please include my email when responding (use Reply To All) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
