Tijl Coosemans wrote:
On Wednesday 13 January 2010 15:36:49 Kostik Belousov wrote:
On Wed, Jan 13, 2010 at 08:03:12AM -0500, Gardner Bell wrote:
Kostik Belousov wrote:
On Tue, Jan 12, 2010 at 06:15:31PM -0500, Gardner Bell wrote:
Just updated my 8.0-STABLE desktop to r202128 the other day and
can no longer run certain windows executables through wine without
them almost immediately entering the STOP state and using 100% CPU
for a short period of time.  Has anyone else ran into a similar
issue lately?

I'm able to get the program to continue as normal by attaching the
pid trough gdb, but would for obvious reasons prefer not to do
that.  Any help trying to find the underlying cause would be
appreciated as this has not been a problem with revisions previous
to r202128.
You can check whether the process is multithreaded (most likely, it
is), and, if so, what is the state of different threads. procstat
-t <pid> and then procstat -k <pid> would probably give some
information for the start.
Here's the output from procstat -k and -t.  I've compiled my kernel
with KDB and DDB support if there is anything needed from that.

  PID    TID COMM             TDNAME           CPU  PRI STATE   WCHAN
44900 100162 wine             initial thread     1  160 stop    -
44900 100178 wine             -                  1  131 stop    -
44900 100179 wine             -                  1  140 stop    -
44900 100180 wine             -                  0  160 stop    piperd
44900 100182 wine             -                  1  160 stop    select
44900 100183 wine             -                  0  160 stop    -
44900 100184 wine             -                  0  160 stop    -
44900 100185 wine             -                  1  160 stop    -
44900 100186 wine             -                  0  160 stop    -
44900 100190 wine             -                  0  160 stop    -
44900 100191 wine             -                  0  160 stop    piperd
44900 100192 wine             -                  1  160 stop    -
44900 100194 wine             -                  0  160 stop    -
44900 100195 wine             -                  0  141 stop    piperd
44900 100200 wine             -                  1  160 stop    -
44900 100201 wine             -                  1  160 stop    -
44900 100202 wine             -                  0  160 stop    piperd
44900 100203 wine             -                  1  160 stop    piperd
44900 100204 wine             -                  1  160 stop    piperd
44900 100205 wine             -                  0  160 stop    -
44900 100206 wine             -                  0  160 stop    -

%procstat -k 44900
PID TID COMM TDNAME KSTACK 44900 100162 wine initial thread mi_switch thread_suspend_check as t doreti_ast 44900 100178 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _cv_timedwait_sig seltdwait kern_select select
      syscall Xint0x80_syscall
44900 100179 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _cv_timedwait_sig seltdwait kern_select select
      syscall Xint0x80_syscall
44900 100180 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv read syscall
           Xint0x80_syscall
44900 100182 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _cv_wait_sig seltdwait poll syscall Xint0x80_syscall

44900 100183 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _cv_timedwait_sig seltdwait poll syscall Xint0x
      80_syscall
44900 100184 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _cv_timedwait_sig seltdwait kern_select select
      syscall Xint0x80_syscall
44900 100185 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _cv_timedwait_sig seltdwait kern_select select
      syscall Xint0x80_syscall
44900 100186 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _cv_timedwait_sig seltdwait kern_select select
      syscall Xint0x80_syscall
44900 100190 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _cv_timedwait_sig seltdwait kern_select select
      syscall Xint0x80_syscall
44900 100191 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv read syscall
           Xint0x80_syscall
44900 100192 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv read syscall
           Xint0x80_syscall
44900 100194 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv read syscall
           Xint0x80_syscall
44900 100195 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv read syscall
           Xint0x80_syscall
44900 100200 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _sleep kern_kevent kevent syscall Xint0x80_sysc
      all
44900 100201 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _sleep kern_kevent kevent syscall Xint0x80_sysc
      all
44900 100202 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv read syscall
           Xint0x80_syscall
44900 100203 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv read syscall
           Xint0x80_syscall
44900 100204 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv read syscall
           Xint0x80_syscall
44900 100205 wine - mi_switch sleepq_switch sleepq_ca tch_signals sleepq_timedwait_sig _sleep kern_kevent kevent syscall Xint0x80_sysc
      all
44900 100206 wine - mi_switch thread_suspend_switch c ursig ast doreti_ast
Besides weird formatting of procstat -k output, I do not see anything
wrong in the state of the process. It got SIGSTOP, I am sure.
Attaching gdb helps because debugger gets signal reports instead of
target process getting the signal actions on signal delivery.

The only question is why the process gets SIGSTOP at all.

Wine uses ptrace(2) sometimes. The SIGSTOP could have come from that.
I recently submitted http://www.freebsd.org/cgi/query-pr.cgi?pr=142757
describing a problem with ptrace and signals, so you might want to give
the kernel patch a try.

This patch fixes the issue of wine going into SIGSTOP.  Thanks Tijl.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to