Quoting John Baldwin j...@freebsd.org (from Mon, 27 Sep 2010 09:28:47 -0400):
savecore already has support for a 'minfree' file to prevent
crashdumps filling the crashdir. Maybe the default install should
include a minfree set to (say) 512MB.
The one problem this approach is it implements a
On Tuesday, September 28, 2010 5:49:12 am Alexander Leidinger wrote:
Quoting John Baldwin j...@freebsd.org (from Mon, 27 Sep 2010 09:28:47
-0400):
savecore already has support for a 'minfree' file to prevent
crashdumps filling the crashdir. Maybe the default install should
include a
On Fri, Sep 24, 2010 at 09:23:04AM -0400, John Baldwin wrote:
Because disks are big and (again, just trying to explain my
understanding of what I inherited) we want all the support
to be in place, just not turned on. There is a difference
between You can give us much better information by
On Tue, Sep 28, 2010 at 03:04:11PM -0400, John Baldwin wrote:
I am bigger fan of textdumps than minidumps, because in my opinion
textdumps provide quite a lot of useful info. I'm working with FreeBSD
kernel for years now and almost entirely avoided gdb for kernel
debugging. DDB and
On Tuesday, September 28, 2010 3:36:11 pm Pawel Jakub Dawidek wrote:
On Tue, Sep 28, 2010 at 03:04:11PM -0400, John Baldwin wrote:
I'm suggesting they provide us the core.txt.X file, not the full minidump.
A developer could then ask them to run specific commands from a subsequent
kgdb
On Friday, September 24, 2010 6:53:52 pm Peter Jeremy wrote:
[Pruning CC list and re-adding freebsd-arch on the (forlorn) hope that
this thread will move to where it belongs]
On 2010-Sep-23 07:31:13 -0700, Matthew Jacob m...@feral.com wrote:
It turns out that the big issue here was more the
On Thu, 23 Sep 2010, Ken Smith wrote:
This is definitely one I don't have a strong enough opinion
on to fight over, I sympathize with both sides. If the
general consensus is mostly towards changing so be it.
I've got no way to tell what percentage of users would
have any clue what to do with
On Thursday, September 23, 2010 11:11:24 pm Ken Smith wrote:
On Thu, 2010-09-23 at 20:31 -0600, M. Warner Losh wrote:
In message: alpine.lnx.2.00.1009231841500.23...@ury.york.ac.uk
Gavin Atkinson ga...@freebsd.org writes:
: On Thu, 23 Sep 2010, Ken Smith wrote:
: The issues
On 9/24/2010 6:23 AM, John Baldwin wrote:
The biggest argument against this (and the reason I always enable crashdumps
on all machines I am involved with) is that many panics are not easily
reproducible, esp. ones that trigger under load. If dumpdev is not on by
default, then the info from a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/09/23 19:31, M. Warner Losh wrote:
In message: alpine.lnx.2.00.1009231841500.23...@ury.york.ac.uk
Gavin Atkinson ga...@freebsd.org writes:
: On Thu, 23 Sep 2010, Ken Smith wrote:
: The issues talked about so far all
[Pruning CC list and re-adding freebsd-arch on the (forlorn) hope that
this thread will move to where it belongs]
On 2010-Sep-23 07:31:13 -0700, Matthew Jacob m...@feral.com wrote:
It turns out that the big issue here was more the savecore time coming
back up rather than the time of dumping.
In
On 25/09/2010, at 8:23, Peter Jeremy wrote:
savecore already has support for a 'minfree' file to prevent
crashdumps filling the crashdir. Maybe the default install should
include a minfree set to (say) 512MB.
Or perhaps add maxcount and set it to 1 as well as minfree at 512Mb.
--
Daniel
On Wednesday, September 22, 2010 5:24:41 pm Bruce Cran wrote:
On Thu, 23 Sep 2010 00:02:30 +0300
Andriy Gapon a...@freebsd.org wrote:
But what was the reason that dumpdev=AUTO was reverted?
I remember that POLA was quoted at the time.
I am not sure what the astonishment actually was -
There are a lot of accelerations that can be applied here- so much so
that Panasas elected to stick with minidumps rather than go to text
dumps, even though there is a fairly hard time limit that a blade can be
down before more drastic error recovery mechanisms for the shelf kick in.
It
on 23/09/2010 16:53 John Baldwin said the following:
minidumps have made the time issue less of a concern on large-memory systems
(full dumps do indeed take a long time on modern systems). I think textdumps
are just as likely to fail as regular dumps though since they both use the
same
On Wed, 2010-09-22 at 22:24 +0100, Bruce Cran wrote:
On Thu, 23 Sep 2010 00:02:30 +0300
Andriy Gapon a...@freebsd.org wrote:
But what was the reason that dumpdev=AUTO was reverted?
I remember that POLA was quoted at the time.
I am not sure what the astonishment actually was - perhaps
On Thu, 23 Sep 2010, Ken Smith wrote:
The issues talked about so far all contribute to the reason for that.
But one of the more basic gut reactions to it all is that the users
want to be interested in helping with the debugging (even if just
providing the requested info) for any sort of crash
In message: alpine.lnx.2.00.1009231841500.23...@ury.york.ac.uk
Gavin Atkinson ga...@freebsd.org writes:
: On Thu, 23 Sep 2010, Ken Smith wrote:
: The issues talked about so far all contribute to the reason for that.
: But one of the more basic gut reactions to it all is that the
On 24/09/2010, at 24:28, Ken Smith wrote:
stuff. The *bulk* of people using -stable are less interested or
flat out not interested. And have no clue what crash dumps are,
may be challenged to notice partition-getting-full issues, etc.
I'm open to having my mind changed about this if there
On Thu, 2010-09-23 at 20:31 -0600, M. Warner Losh wrote:
In message: alpine.lnx.2.00.1009231841500.23...@ury.york.ac.uk
Gavin Atkinson ga...@freebsd.org writes:
: On Thu, 23 Sep 2010, Ken Smith wrote:
: The issues talked about so far all contribute to the reason for that.
: But
On Tue, 2010-09-21 at 15:07 +, Andriy Gapon wrote:
Author: avg
Date: Tue Sep 21 15:07:44 2010
New Revision: 212964
URL: http://svn.freebsd.org/changeset/base/212964
Log:
kdb_backtrace: stack(9)-based code to print backtrace without any backend
The idea is to add KDB and
on 22/09/2010 16:46 Gavin Atkinson said the following:
Ignoring the rest of the discussion about locking, I think this is a
step in the right direction. However, what I feel we should be strongly
considering is for textdumps to be enabled by default on release media.
As more groups choose
On Wed, 2010-09-22 at 17:43 +0300, Andriy Gapon wrote:
on 22/09/2010 16:46 Gavin Atkinson said the following:
Ignoring the rest of the discussion about locking, I think this is a
step in the right direction. However, what I feel we should be strongly
considering is for textdumps to be
on 22/09/2010 18:23 Gavin Atkinson said the following:
I'm not subscribed to -arch at the moment, I probably should be. I
guess you're talking about the thread in June? I wish I'd seen that at
the time, I'm 100% in favour of it.
No, a thread in September, third decade of it :)
--
Andriy
on 22/09/2010 22:58 John Baldwin said the following:
Agreed. FWIW, I actually think that this is the only change needed as
crashinfo is enabled by default in 8.x and later. We already include symbols
in kernels by default now, so just setting dumpdev will give you the same
info you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/22/10 5:02 PM, Andriy Gapon wrote:
on 22/09/2010 22:58 John Baldwin said the following:
Agreed. FWIW, I actually think that this is the only change needed as
crashinfo is enabled by default in 8.x and later. We already include symbols
in
On Wednesday, September 22, 2010 5:15:25 pm Ken Smith wrote:
On 9/22/10 5:02 PM, Andriy Gapon wrote:
on 22/09/2010 22:58 John Baldwin said the following:
Agreed. FWIW, I actually think that this is the only change needed as
crashinfo is enabled by default in 8.x and later. We already
On Thu, 23 Sep 2010 00:02:30 +0300
Andriy Gapon a...@freebsd.org wrote:
But what was the reason that dumpdev=AUTO was reverted?
I remember that POLA was quoted at the time.
I am not sure what the astonishment actually was - perhaps 'AUTO' was
not smart enough and destroyed somebody's data?
Author: avg
Date: Tue Sep 21 15:07:44 2010
New Revision: 212964
URL: http://svn.freebsd.org/changeset/base/212964
Log:
kdb_backtrace: stack(9)-based code to print backtrace without any backend
The idea is to add KDB and KDB_TRACE options to GENERIC kernels on
stable branches, so that at
On Tue, Sep 21, 2010 at 8:07 AM, Andriy Gapon a...@freebsd.org wrote:
Author: avg
Date: Tue Sep 21 15:07:44 2010
New Revision: 212964
URL: http://svn.freebsd.org/changeset/base/212964
Log:
kdb_backtrace: stack(9)-based code to print backtrace without any backend
The idea is to add KDB
on 21/09/2010 18:27 Andriy Gapon said the following:
on 21/09/2010 18:17 m...@freebsd.org said the following:
I'd recommend using stack_print_ddb(), as that avoids any locking
which may hang depending on how the kernel panic'd.
It seems that stack_print_ddb() depends on DDB?
But the point
2010/9/21 Andriy Gapon a...@freebsd.org:
on 21/09/2010 18:27 Andriy Gapon said the following:
on 21/09/2010 18:17 m...@freebsd.org said the following:
I'd recommend using stack_print_ddb(), as that avoids any locking
which may hang depending on how the kernel panic'd.
It seems that
on 21/09/2010 18:17 m...@freebsd.org said the following:
I'd recommend using stack_print_ddb(), as that avoids any locking
which may hang depending on how the kernel panic'd.
How does the following look to you?
I hope I haven't freed too much from under DDB.
The patch compiles fine with STACK
2010/9/21 Andriy Gapon a...@freebsd.org:
on 21/09/2010 18:17 m...@freebsd.org said the following:
I'd recommend using stack_print_ddb(), as that avoids any locking
which may hang depending on how the kernel panic'd.
How does the following look to you?
I hope I haven't freed too much from
On Tue, Sep 21, 2010 at 8:40 AM, Andriy Gapon a...@freebsd.org wrote:
on 21/09/2010 18:27 Andriy Gapon said the following:
on 21/09/2010 18:17 m...@freebsd.org said the following:
I'd recommend using stack_print_ddb(), as that avoids any locking
which may hang depending on how the kernel
On Tuesday, September 21, 2010 12:31:01 pm m...@freebsd.org wrote:
On Tue, Sep 21, 2010 at 8:40 AM, Andriy Gapon a...@freebsd.org wrote:
on 21/09/2010 18:27 Andriy Gapon said the following:
on 21/09/2010 18:17 m...@freebsd.org said the following:
I'd recommend using stack_print_ddb(), as
Err, I don't think _mtx_lock_sleep() is guarded in that fashion? I have an
old patch to do that but have never committed it. If we want that we should
probably change rwlocks and sxlocks to have also not block when panicstr is
set.
Seems to me you are backing into interesting territory
Matthew Jacob wrote:
Err, I don't think _mtx_lock_sleep() is guarded in that fashion? I
have an
old patch to do that but have never committed it. If we want that we
should
probably change rwlocks and sxlocks to have also not block when
panicstr is
set.
Seems to me you are backing
Absolutely. I have patches for RELENG_7, but have had trouble moving
it to head.
Seems to me you are backing into interesting territory here- getting a
bit more like Solaris.
If you *do* do this, then you really *do* need to stop all other CPUs
when you panic, or else it's likely you'll
On Tue, Sep 21, 2010 at 9:50 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday, September 21, 2010 12:31:01 pm m...@freebsd.org wrote:
On Tue, Sep 21, 2010 at 8:40 AM, Andriy Gapon a...@freebsd.org wrote:
on 21/09/2010 18:27 Andriy Gapon said the following:
on 21/09/2010 18:17
FWIW, I think that this would be a *good* thing. One of the problems
with panic is that you can't really reset the state of the world, so
most kernel services are not reliable. Unfortunately, mechanisms for
preserving forensics for debug require some kernel services.
Seems to me you are
41 matches
Mail list logo
