* Ivan Voras <[EMAIL PROTECTED]> [080915 16:05] wrote: > 2008/9/13 Alfred Perlstein <[EMAIL PROTECTED]>: > > >> Yes, it's multithreaded apache. This did help somewhat - when I show > >> threads in top > >> I see that it's not actually stuck in umtxn - there's one thread that > >> consumes the CPU and it's apparently always running (in state CPUx). > >> > >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > >> 7212 www 103 0 30340K 7932K CPU2 2 444:23 99.02% httpd > >> > >> I'm currently upgrading the system to 7-STABLE, to see if it helps. > > It didn't help. Exactly the same symptom happened again. It looks like > it happens a few days after the last system reboot. After it happens > the first time, restarting Apache immediately produces one such > "stuck" thread - it looks like some system state gets corrupted over > time. > > >> How do I pick what thread to backtrace in gdb? > > > > i think the command is 'info threads' or 'show > > threads' then i think you just type > > 'thread FOO' to select the thread. > > Both commands don't work / don't exist. Any others? > > (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE > suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. > I'm looking for ideas)
I'm sorry, I really can't help at this point other than to look through the documents myself to figure out how to do a backtrace/select threads. Give it a shot, and let us know and we can go further. Apologies, -Alfred _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"