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 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 2:33:50 pm Pawel Jakub Dawidek wrote:
> 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 turn
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 inform
On Tuesday, September 28, 2010 5:49:12 am Alexander Leidinger wrote:
> Quoting John Baldwin (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
Quoting John Baldwin (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 FIFO instead of a
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 wrote:
> >It turns out that the big issue here was more the savecore
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 O
[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 wrote:
>It turns out that the big issue here was more the savecore time coming
>back up rather than the time of dumping.
In my experienc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/09/23 19:31, M. Warner Losh wrote:
> In message:
> Gavin Atkinson 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
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 rar
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:
> > Gavin Atkinson writes:
> > : On Thu, 23 Sep 2010, Ken Smith wrote:
> > : > The issues talked about so far all contribute to the reason for that.
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
On Thu, 2010-09-23 at 20:31 -0600, M. Warner Losh wrote:
> In message:
> Gavin Atkinson 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 use
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 t
In message:
Gavin Atkinson 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 users
: > want to be interested in helping with the debugging (even if
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 cra
On Wed, 2010-09-22 at 22:24 +0100, Bruce Cran wrote:
> On Thu, 23 Sep 2010 00:02:30 +0300
> Andriy Gapon 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' wa
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
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 turns
On Wednesday, September 22, 2010 5:24:41 pm Bruce Cran wrote:
> On Thu, 23 Sep 2010 00:02:30 +0300
> Andriy Gapon 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 00:02:30 +0300
Andriy Gapon 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?
>
The probl
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
-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
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 gener
On Wednesday, September 22, 2010 11:23:37 am Gavin Atkinson wrote:
> 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. Howev
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 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 b
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 choo
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 an
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 backin
On Tuesday, September 21, 2010 12:53:56 pm 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 pan
On Tue, Sep 21, 2010 at 9:50 AM, John Baldwin 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 wrote:
>> > on 21/09/2010 18:27 Andriy Gapon said the following:
>> >> on 21/09/2010 18:17 m...@freebsd.org said the following
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 doubl
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
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 here-
On Tuesday, September 21, 2010 12:31:01 pm m...@freebsd.org wrote:
> On Tue, Sep 21, 2010 at 8:40 AM, Andriy Gapon 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 tha
On Tue, Sep 21, 2010 at 9:36 AM, Andriy Gapon wrote:
> on 21/09/2010 19:31 m...@freebsd.org said the following:
>> I keep forgetting, but actually _mtx_lock_sleep() will just return if
>> panicstr is set. _mtx_assert() is similarly guarded, so actually it
>> should be mostly okay.
>
> But this do
on 21/09/2010 19:31 m...@freebsd.org said the following:
> I keep forgetting, but actually _mtx_lock_sleep() will just return if
> panicstr is set. _mtx_assert() is similarly guarded, so actually it
> should be mostly okay.
But this doesn't seem to be the case for sx lock which is wrapped under
On Tue, Sep 21, 2010 at 8:40 AM, Andriy Gapon 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 panic'd.
2010/9/21 Andriy Gapon :
> 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.
>
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 :
> 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_pri
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 th
on 21/09/2010 18:17 m...@freebsd.org said the following:
> On Tue, Sep 21, 2010 at 8:07 AM, 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 b
On Tue, Sep 21, 2010 at 8:07 AM, 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 KDB_T
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 l
47 matches
Mail list logo