On Mon, 5 Jan 2009, Terry Kennedy wrote:
I may have missed this earlier in the thread, but I don't see a kernel
stack trace of the stuck thread/process. Could you grab one using procstat
-k, DDB, or KGDB? I'd like to confirm that the 'sbwait' really reflects
waiting to send, rather than
I may have missed this earlier in the thread, but I don't see a kernel stack
trace of the stuck thread/process. Could you grab one using procstat -k, DDB,
or KGDB? I'd like to confirm that the 'sbwait' really reflects waiting to
send, rather than waiting to receive, which (for better or worse)
On Sat, 3 Jan 2009, Terry Kennedy wrote:
Sorry, I can't think of any - by the time you see it hung, whatever went
wrong has already happened. You might glean some insight from the TCP
socket state (on the FreeBSD side, use 'netstat -A' to print the PCB
address and gdb to dump the contents
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 FLAGSREF OFFSET PRO NAME
4436 rdump cwd v d - - - /tmp
4436 rdumproot v d - -
Sorry, I can't think of any - by the time you see it hung, whatever
went wrong has already happened. You might glean some insight from
the TCP socket state (on the FreeBSD side, use 'netstat -A' to print
the PCB address and gdb to dump the contents but I'm not sure how to
get this data out
On 2008-Dec-29 20:28:41 -0500, Terry Kennedy te...@tmk.com wrote:
I upgraded a box (Dell Poweredge 1550, dual PIII processors) from a kernel +
world of December 8th to one from today (December 29th) and I am experiencing
a new problem with rdump.
...
A tcpdump on both the sending and receiving
Unfortunately, you need the last packets that were exchanged in order
to identify which end has the problem (and hopefully provide some
pointers as to why). If possible, can you repeat the dump whilst you
run a tcpdump on the rdump flow and then post the last dozen or so
packets in each
On 2008-Dec-30 05:48:26 -0500, Terry Kennedy te...@tmk.com wrote:
Unfortunately, you need the last packets that were exchanged in order
to identify which end has the problem (and hopefully provide some
pointers as to why). If possible, can you repeat the dump whilst you
run a tcpdump on the
I'm pretty sure it's caused by FreeBSD. It can very well be related to
PR 117603, a real nasty dump(8) bug that was introduced in 7.0 on SMP
systems. But it should have been patched back in March by this:
jeff 2008-03-13 00:46:12 UTC
FreeBSD src repository
Modified files:
sys/kern
I'm pretty sure it's caused by FreeBSD. It can very well be related to
PR 117603, a real nasty dump(8) bug that was introduced in 7.0 on SMP
systems. But it should have been patched back in March by this:
[...]
So I'm real surprised it shows up again. We got a pretty large backup
I upgraded a box (Dell Poweredge 1550, dual PIII processors) from a kernel +
world of December 8th to one from today (December 29th) and I am experiencing
a new problem with rdump.
The symptom is that rdump stops sending data to the remote system. It is
responsive to ^T and can be aborted
11 matches
Mail list logo
