rdump stuck in sbwait state (RELENG_7)
Terry Kennedy
terry at tmk.com
Tue Jan 6 02:51:16 UTC 2009
> 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 at tmk.com New York, NY USA
More information about the freebsd-stable
mailing list