Deadlock, exclusive sx so_rcv_sx, amd64
Kostik Belousov
kostikbel at gmail.com
Fri Oct 26 11:45:52 PDT 2007
On Fri, Oct 26, 2007 at 12:22:28PM -0400, John Baldwin wrote:
> On Friday 26 October 2007 05:52:07 am Gleb Kozyrev wrote:
> > On 25/10/2007, John Baldwin <jhb at freebsd.org> wrote:
> > > > Running rtorrent and ftp brings my system to a deadlock
> > > > in a few hours. Kernel still responds to pings and sends some
> > > > TCP acks.
> > ...
> > > > Please suggest any other commands to run in DDB if needed.
> > > > Cores are saved.
> > >
> > > show sleepchain <pid> will show if it's a real deadlock or not.
> > >
> >
> > This time the freeze was a matter of minutes.
> >
> > db> ps
> > pid ppid pgrp uid state wmesg wchan cmd
> > 1229 991 991 0 ? smbd
> > 1201 1195 1201 1001 SL+ pfault 0xffffffff80b1359c rtorrent
> > 1199 1193 1199 1001 Ss+ ttyin 0xffffff0001211410 tcsh
> > 1197 1193 1197 1001 Ss+ ttyin 0xffffff0001218810 tcsh
> > 1195 1193 1195 1001 Ss+ pause 0xffffff000624a0c0 tcsh
> > 1193 1192 1193 1001 SLs pfault 0xffffffff80b1359c screen
> > 1192 1190 1190 1001 S+ pause 0xffffff00013c10c0 screen
> > 1190 1189 1190 1001 Ss+ pause 0xffffff00065b40c0 tcsh
> > 1189 1187 1187 1001 S select 0xffffffff80af79d0 sshd
> > 1187 1097 1187 0 Ss sbwait 0xffffff00065346cc sshd
> > ...
> >
> > db> show alllocks
> > Process 1187 (sshd) thread 0xffffff00065ad350 (100166)
> > exclusive sx so_rcv_sx r = 0 (0xffffff0006534670) locked @
> > /usr/src/sys/kern/uipc_sockbuf.c:145
> >
> > db> show sleepchain 1187
> > thread 100166 (pid 1187, sshd) sleeping on 0xffffff00065346cc "sbwait"
> > db> show sleepchain 1201
> > thread 100164 (pid 1201, rtorrent) sleeping on 0xffffffff80b1359c "pfault"
> >
> > Nothing interesting I guess...
> > Maybe this is not a deadlock, what else can cause such a freeze?
> > I won't reboot it for a while -- maybe someone can suggest anything else.
>
> "sbwait" is waiting for data to come in on a socket and "pfault" is
> waiting on disk I/O. It is a bit odd that 1187 is holding a lock while
No, pfault means that the process handles page faults, and sleeps
waiting for some page to become available (either from cache or free list).
> sleeping though that is permitted with an sx lock. Still, if it's
> supposed to be protect socket's receive buffer that is odd. Maybe get
> a trace of the process blocked in "sbwait" (tr <pid>) and bug rwatson@
> about it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071026/0be7bc82/attachment.pgp
More information about the freebsd-current
mailing list