Date: Mon, 05 Jan 2009 20:44:04 -0500 (EST) From: Terry Kennedy <terry@tmk.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-stable@FreeBSD.org Subject: Re: rdump stuck in sbwait state (RELENG_7) Message-ID: <01N3YA1PE7BE0008L3@tmk.com> In-Reply-To: "Your message dated Mon, 05 Jan 2009 14:16:57 %2B0000 (GMT)" <alpine.BSF.2.00.0901051411240.98366@fledge.watson.org> References: <01N3OFGBCXMS000125@tmk.com> <01N3OYSUCHAE000125@tmk.com> <01N3VGDZ7EOM0008L3@tmk.com> <01N3XI0VWEA00008L3@tmk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Could I ask you to also send me procstat -f output? Sure: (0:37) test4:/usr/src# procstat -f 4436 PID COMM FD T V FLAGS REF OFFSET PRO NAME 4436 rdump cwd v d -------- - - - /tmp 4436 rdump root v d -------- - - - / 4436 rdump 0 v c rw------ 31 7762 - - 4436 rdump 1 v c rw------ 31 7762 - - 4436 rdump 2 v c rw------ 31 7762 - - 4436 rdump 3 s - rw------ 6 0 TCP 204.141.35.11:892 204.141.35.63:514 4436 rdump 4 v r r------- 2 0 - - 4436 rdump 5 s - rw------ 5 0 TCP 204.141.35.11:770 204.141.35.63:1020 (0:38) test4:/usr/src# procstat -f 4439 PID COMM FD T V FLAGS REF OFFSET PRO NAME 4439 rdump cwd v d -------- - - - /tmp 4439 rdump root v d -------- - - - / 4439 rdump 0 v c rw------ 31 7762 - - 4439 rdump 1 v c rw------ 31 7762 - - 4439 rdump 2 v c rw------ 31 7762 - - 4439 rdump 3 s - rw------ 6 0 TCP 204.141.35.11:892 204.141.35.63:514 4439 rdump 4 v r r------- 2 0 - - 4439 rdump 5 s - rw------ 5 0 TCP 204.141.35.11:770 204.141.35.63:1020 4439 rdump 6 s - rw------ 4 0 UDS - 4439 rdump 7 s - rw------ 1 0 UDS - 4439 rdump 8 s - rw------ 3 0 UDS - 4439 rdump 9 s - rw------ 1 0 UDS - 4439 rdump 10 s - rw------ 2 0 UDS - 4439 rdump 11 s - rw------ 2 0 UDS - (0:39) test4:/usr/src# procstat -f 4440 PID COMM FD T V FLAGS REF OFFSET PRO NAME 4440 rdump cwd v d -------- - - - /tmp 4440 rdump root v d -------- - - - / 4440 rdump 0 v c rw------ 31 7762 - - 4440 rdump 1 v c rw------ 31 7762 - - 4440 rdump 2 v c rw------ 31 7762 - - 4440 rdump 3 s - rw------ 6 0 TCP 204.141.35.11:892 204.141.35.63:514 4440 rdump 4 v c r------- 1 0 - - 4440 rdump 5 s - rw------ 5 0 TCP 204.141.35.11:770 204.141.35.63:1020 4440 rdump 6 s - rw------ 4 0 UDS - (0:40) test4:/usr/src# procstat -f 4441 PID COMM FD T V FLAGS REF OFFSET PRO NAME 4441 rdump cwd v d -------- - - - /tmp 4441 rdump root v d -------- - - - / 4441 rdump 0 v c rw------ 31 7762 - - 4441 rdump 1 v c rw------ 31 7762 - - 4441 rdump 2 v c rw------ 31 7762 - - 4441 rdump 3 s - rw------ 6 0 TCP 204.141.35.11:892 204.141.35.63:514 4441 rdump 4 v c r------- 1 0 - - 4441 rdump 5 s - rw------ 5 0 TCP 204.141.35.11:770 204.141.35.63:1020 4441 rdump 6 s - rw------ 4 0 UDS - 4441 rdump 8 s - rw------ 3 0 UDS - (0:41) test4:/usr/src# procstat -f 4442 PID COMM FD T V FLAGS REF OFFSET PRO NAME 4442 rdump cwd v d -------- - - - /tmp 4442 rdump root v d -------- - - - / 4442 rdump 0 v c rw------ 31 7762 - - 4442 rdump 1 v c rw------ 31 7762 - - 4442 rdump 2 v c rw------ 31 7762 - - 4442 rdump 3 s - rw------ 6 0 TCP 204.141.35.11:892 204.141.35.63:514 4442 rdump 4 v c r------- 1 0 - - 4442 rdump 5 s - rw------ 5 0 TCP 204.141.35.11:770 204.141.35.63:1020 4442 rdump 6 s - rw------ 4 0 UDS - 4442 rdump 8 s - rw------ 3 0 UDS - 4442 rdump 10 s - rw------ 2 0 UDS - > In general, being blocked in soreceive() means that the application at the > other end hasn't sent data, or the other end hasn't received or correctly > processed ACKs from the local end, so isn't sending more data that it has > queued up. The condition you describe sounds more like what would happen in a > sender: that it has data to send, but the remote side hasn't ACK'd > sufficiently to send it all. Looking at the tcpdump capture at http://www.tmk.com/transient/rdump30.gz, I think everything has been ack'd by the other side. > If you have kgdb handy, it would be useful to > look at *so and *so->so_domain in the soreceive_generic frame of proc 4439. > If it's an inet socket, we'd like to see *(struct inpcb *)so->so_pcb, and if > it's a TCP socket, *(struct tcpcb *)((struct inpcb *)so->so_pcb)->inp_ppcb. Sorry, you lost me here. Can you give me detailed instructions on how to examine this data? I got as far as "proc 4439" in kgdb, but then got lost. Thanks, Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01N3YA1PE7BE0008L3>