From: Xin Li
To: Jin Guojun
Cc: questi...@freebsd.org; hack...@freebsd.org
Sent: Sun, September 30, 2012 1:07:40 PM
Subject: Re: system hangs during dump + compress > usb2-drive
On 9/29/12 10:49 PM, Jin Guojun wrote:
> In FreeBSD 8.3 release (possi
nyCompress > usb-drive hang
> content is 3GB or larger (did not try around 2GB yet)
>
> When system hangs, no sub system, such video, network, etc, will
> function. Typically, the unfinished compressed dump file is around
> 1.5-2.7GB, so guessing dumped file content is
p-file from STAT drive to a USB drive OK
dump small-FS-on-SATA-drive | anyCompress > usb-drive OK
small -- 1.8GB or less
dump large-FS-on-SATA-drive | anyCompress > usb-drive hang
content is 3GB or larger (did not try around 2GB yet)
When system hangs, no sub system
Linda Messerschmidt wrote:
Well, this is interesting. I got really frustrated with the other
approach, so I thought I'd thin a machine down absolutely as far as I
could, eliminate every possible source of delay, and see what happens.
I killed everything... cron, RPC, NFS, devd, gmon, nrpe, ever
OK, first, I figured out the seven second thing. I actually had
already found that particular issue earlier in the troubleshooting
process, but forgot all about it when I pulled in a second machine to
test with. It was simply a case of setting Apache's
MaxRequestsPerChild to a very low value (128
On Sat, Sep 12, 2009 at 2:52 AM, Linda Messerschmidt
wrote:
> On Sat, Sep 12, 2009 at 1:47 AM, Julian Elischer wrote:
>> ok now we need to describe the hang.. if you can predictably get a hang
>> every 7 seconds does this mean that it doesn't respond to keyboard for a
>> moment every 7 seconds?
On Sat, Sep 12, 2009 at 1:47 AM, Julian Elischer wrote:
> ok now we need to describe the hang.. if you can predictably get a hang
> every 7 seconds does this mean that it doesn't respond to keyboard for a
> moment every 7 seconds?
It's possible.
> or that it doesn't accept packets every 7 secon
Linda Messerschmidt wrote:
On Sat, Sep 12, 2009 at 12:06 AM, Julian Elischer wrote:
does the system have a serial console? how about a normal console /keyboard?
It has an IP KVM.
how often deos it hang? and for how long?
Well, this is interesting. I got really frustrated with the other
On Sat, Sep 12, 2009 at 12:06 AM, Julian Elischer wrote:
> does the system have a serial console? how about a normal console /keyboard?
It has an IP KVM.
> how often deos it hang? and for how long?
Well, this is interesting. I got really frustrated with the other
approach, so I thought I'd th
Linda Messerschmidt wrote:
OK, I have learned that ktrdump looks up the name of the process
associated with a particular KSE at the the time of the dump, so if
it's changed since tracing stopped, it will blissfully blame the wrong
process. I understand why that's the case, but it still sucks for
OK, I have learned that ktrdump looks up the name of the process
associated with a particular KSE at the the time of the dump, so if
it's changed since tracing stopped, it will blissfully blame the wrong
process. I understand why that's the case, but it still sucks for
troubleshooting. :(
This ti
On Fri, Sep 11, 2009 at 3:06 PM, John Baldwin wrote:
> Something like this:
Ah, I understand now. :)
Got up to 17 seconds of trace with that change.
> Hmm. It works well for me for doing traces.
It definitely works, it just always seems to have some-or-another
weird artifact.
But, with the l
On Friday 11 September 2009 1:35:00 pm Linda Messerschmidt wrote:
> On Fri, Sep 11, 2009 at 11:02 AM, John Baldwin wrote:
> > Try turning off KTR_LOCK for spin mutexes (just force LO_QUIET on in
> > mtx_init() if MTX_SPIN is set)
>
> I have *no* idea what you just said. :)
>
> Which is fine. Bu
On Friday 11 September 2009 11:35:14 am Julian Elischer wrote:
> John Baldwin wrote:
> >
> >
> > A more recently schedgraph.py might also
> > fix the bugs you were seeing with the idle threads looking too long (esp.
at
> > the start and end of graphs).
>
> not unless something has been fixed
On Fri, Sep 11, 2009 at 11:02 AM, John Baldwin wrote:
> Try turning off KTR_LOCK for spin mutexes (just force LO_QUIET on in
> mtx_init() if MTX_SPIN is set)
I have *no* idea what you just said. :)
Which is fine. But more to the point, I have no idea how to do it. :)
> A more recently schedgra
John Baldwin wrote:
A more recently schedgraph.py might also
fix the bugs you were seeing with the idle threads looking too long (esp. at
the start and end of graphs).
not unless something has been fixed in the last week or so.
___
freebsd-hac
On Thursday 10 September 2009 9:34:30 pm Linda Messerschmidt wrote:
> Just to follow up, I've been doing some testing with masking for
> KTR_LOCK rather than KTR_SCHED.
>
> I'm having trouble with this because I have the KTR buffer size set to
> 1048576 entries, and with only KTR_LOCK enabled, thi
Just to follow up, I've been doing some testing with masking for
KTR_LOCK rather than KTR_SCHED.
I'm having trouble with this because I have the KTR buffer size set to
1048576 entries, and with only KTR_LOCK enabled, this isn't enough for
even a full second of tracing; the sample I'm working with
On Thu, Sep 10, 2009 at 2:46 PM, Julian Elischer wrote:
> I've noticed that schedgraph tends to show the idle threads slightly
> skewed one way or the other. I think there is a cumulative rounding
> error in the way they are drawn due to the fact that they are run so
> often. Check the raw data a
Linda Messerschmidt wrote:
On Thu, Sep 10, 2009 at 12:57 PM, Ryan Stone wrote:
You should be able to run schedgraph.py on a windows machine with python
installed. It works just fine for me on XP.
Don't have any of those either, but I *did* get it working on a Mac
right out of the box. Should
On Thu, Sep 10, 2009 at 12:57 PM, Ryan Stone wrote:
> You should be able to run schedgraph.py on a windows machine with python
> installed. It works just fine for me on XP.
Don't have any of those either, but I *did* get it working on a Mac
right out of the box. Should have thought of that soone
You should be able to run schedgraph.py on a windows machine with python
installed. It works just fine for me on XP.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "
On Thu, Aug 27, 2009 at 5:29 PM, John Baldwin wrote:
> Ah, cool, what you want to do is use KTR with KTR_SCHED and then use
> schedgraph.py (src/tools/sched) to get a visual picture of what the box does
> during a hang. The timestamps in KTR are TSC cycle counts rather than an
> actual wall time w
On Thu, Aug 27, 2009 at 04:14:39PM -0400, Linda Messerschmidt wrote:
> On Wed, Aug 26, 2009 at 4:42 PM, John Baldwin wrote:
> > One thing to note is that ktrace only logs voluntary context switches (i.e.
> > call to tsleep or waiting on a condition variable). It specifically does
> > not
> > log
On Wed, Aug 26, 2009 at 4:42 PM, John Baldwin wrote:
> One thing to note is that ktrace only logs voluntary context switches (i.e.
> call to tsleep or waiting on a condition variable). It specifically does not
> log preemptions or blocking on a mutex,
I was not aware, thanks.
> so in theory if y
On Wed, 26 Aug 2009, Linda Messerschmidt wrote:
I'm trying to troubleshoot an intermittent Apache performance problem,
and I've narrowed it down using to what appears to be a brief
whole-system hang that last from 0.5 - 3 seconds. They occur every
few minutes.
One thought would be to use "ps"
On Wednesday 26 August 2009 3:03:13 pm Linda Messerschmidt wrote:
> I'm trying to troubleshoot an intermittent Apache performance problem,
> and I've narrowed it down using to what appears to be a brief
> whole-system hang that last from 0.5 - 3 seconds. They occur every
> few minutes.
One thing
I'm trying to troubleshoot an intermittent Apache performance problem,
and I've narrowed it down using to what appears to be a brief
whole-system hang that last from 0.5 - 3 seconds. They occur every
few minutes.
I took the rather extreme step of doing "ktrace -t cnisuwt -i -d -p 1"
and then I wa
t see that there were two jumpers on the disc to set the
termination :-(
Greetings Andreas
On Wed, 27 Sep 2000, Zhiui Zhang wrote:
>
> I am debugging a program that does a lot of disk I/O and the system hangs
> briefly with the some repeated messages that looks like:
>
> (da0:
I am debugging a program that does a lot of disk I/O and the system hangs
briefly with the some repeated messages that looks like:
(da0:ahc0:0:0:0): SCB 0x0 - Timed out in Data-in phase, SEQADDR==0x88
(da0:ahc0:0:0:0): BDR message in message buffer
(da0:ahc0:0:0:0): SCB 0x0 - Timed out in Data
Hi Soren,
Thanks a lot for the help. CTRL+ALT+ESC works. Thanks once again. Now we
can do some analysis.
regards
--gb
On Wed, 31 May 2000, Soren Schmidt wrote:
> It seems G.B.Naidu wrote:
> >
> > I have posted this earlier. I didnt get any reply about system hangs.
> >
It seems G.B.Naidu wrote:
>
> I have posted this earlier. I didnt get any reply about system hangs.
> Please some body help me out to track down these hangs. Questions are
> below.
Have you tried putting DDB into the kernel, and tried to
hit ALT+CTRL+ESC to go into the debugger
Hi,
I have posted this earlier. I didnt get any reply about system hangs.
Please some body help me out to track down these hangs. Questions are
below.
thanks
--gb
-- Forwarded message --
Date: Tue, 30 May 2000 14:32:30 +0530 (IST)
From: G.B.Naidu <[EMAIL PROTECTED]&
Hi,
Please see my comments below:
On Tue, 30 May 2000, Koster, K.J. wrote:
> >
> > We have made some kernel changes. And accordingly we are
> > testing the changes using some user level daemon. After
> > sending some packets, the system hangs. The number of
> >
Hi Guys,
My system hangs. I know how to take core dumps and start debugging if it
is panicing. But the system hangs, then I cant do anything. The only thing
I can do is reset or power off and on.
What I would like to know is how to handle hangs. I guess that panic and
hangs are different
I think, generically, you want to look at
http://www.freebsd.org/handbook/kerneldebug.html
in particular 22.4
--
Joshua Goodall
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
>
> We have made some kernel changes. And accordingly we are
> testing the changes using some user level daemon. After
> sending some packets, the system hangs. The number of
> packets sent before the system hangs varies from time to
> time.
>
What kind of changes? What
Hi,
We have made some kernel changes. And accordingly we are testing the
changes using some user level daemon. After sending some packets, the
system hangs. The number of packets sent before the system hangs varies
from time to time.
Could some body tell me how to know what is happening? How
38 matches
Mail list logo
