On Fri, 15 Oct 2010, Robert N. M. Watson wrote:
On 15 Oct 2010, at 20:39, Garrett Cooper wrote:
But there are already some cases that aren't properly handled
today in the ddb area dealing with dumping that aren't handled
properly. Take for instance the following two scenarios:
1. Call doadu
On Fri, Oct 15, 2010 at 12:25 PM, Robert Watson wrote:
> On Thu, 14 Oct 2010, Attilio Rao wrote:
>
>>> No, what I'm saying is: UMA needs to not call its drain handlers, and
>>> ideally not call into VM to fill slabs, from the dumping context. That's
>>> easy to implement and will cause the dump to
On 15 Oct 2010, at 20:39, Garrett Cooper wrote:
>But there are already some cases that aren't properly handled
> today in the ddb area dealing with dumping that aren't handled
> properly. Take for instance the following two scenarios:
> 1. Call doadump twice from the debugger.
> 2. Call doadu
On Thu, 14 Oct 2010, Attilio Rao wrote:
No, what I'm saying is: UMA needs to not call its drain handlers, and
ideally not call into VM to fill slabs, from the dumping context. That's
easy to implement and will cause the dump to fail rather than causing the
system to hang.
My point is, howeve
2010/10/14 Robert N. M. Watson :
>
> On 14 Oct 2010, at 15:10, Attilio Rao wrote:
>
>>> My concern is less about occasional lost dumps that destabilising the
>>> dumping process: calls into the memory allocator can currently trigger a
>>> lot of interesting behaviours, such as further calls back
On 14 Oct 2010, at 15:10, Attilio Rao wrote:
>> My concern is less about occasional lost dumps that destabilising the
>> dumping process: calls into the memory allocator can currently trigger a lot
>> of interesting behaviours, such as further calls back into the VM system,
>> which can then t
2010/10/14 Robert N. M. Watson :
>
> On 13 Oct 2010, at 18:46, Ryan Stone wrote:
>
>> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
>>> + /*
>>> + * get and fill a header mbuf, then chain data as an
>>> extended
>>> + * mbuf.
>>> +
On 13 Oct 2010, at 18:46, Ryan Stone wrote:
> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
>> + /*
>> +* get and fill a header mbuf, then chain data as an
>> extended
>> +* mbuf.
>> +*/
>> + MGETHDR(m, M_DONTWAIT
On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
> + /*
> +* get and fill a header mbuf, then chain data as an
> extended
> +* mbuf.
> +*/
> + MGETHDR(m, M_DONTWAIT, MT_DATA);
>
> The idea of calling into the mbuf allo
On Wed, Oct 13, 2010 at 01:04:54PM +0200, Attilio Rao wrote:
> 2010/10/9 Robert Watson :
> > (1) Did you consider using tftp as the network dump protocol, rather than a
> > custom protocol? ??It's also a simple UDP-based, ACKed file transfer
> > protocol, with the advantage that it's widely suppo
2010/10/9 Robert Watson :
> On Fri, 8 Oct 2010, Attilio Rao wrote:
>
>>> GENERAL FRAMEWORK ARCHITECTURE
>>>
>>> Netdump is composed, right now, by an userland "server" and a kernel
>>> "client". The former is run on the target machine (where the dump will
>>> phisically happen) and it is responsibl
On Sat, Oct 09, 2010 at 02:15:39AM +0100, Robert Watson wrote:
> Network dumps would be a great addition to the FreeBSD debugging suite!
> [...]
It seems that at EuroBSDCon there was a discussion of Contiki[1] and
the uIPv6 stack[2] that it contains, and I think something like this
could be a gre
On Fri, 8 Oct 2010, Attilio Rao wrote:
GENERAL FRAMEWORK ARCHITECTURE
Netdump is composed, right now, by an userland "server" and a kernel
"client". The former is run on the target machine (where the dump will
phisically happen) and it is responsible for receiving the packets
containing cor
2010/9/28 Attilio Rao :
> In the last weeks I worked for porting the netdump infrastructure to
> FreeBSD-CURRENT on the behalf of Sandvine Incorporated.
> Netdump is a framework that aims for handling kernel coredumps over
> the TCP/IP suite in order to dump to a separate machine than the
> running
2010/9/29 Sergey Kandaurov :
> [just don't know what namely need to test, so]
>
> All made according to your instructions.
> The only way I could trigger netdump was
> to run its ddb command by hand. Neither
> debug.kdb.enter nor debug.kdb.panic don't do it.
You probabilly need to use KDB_UNATTEND
[just don't know what namely need to test, so]
All made according to your instructions.
The only way I could trigger netdump was
to run its ddb command by hand. Neither
debug.kdb.enter nor debug.kdb.panic don't do it.
Some numbers and output (bit verbose
but again don't know what need to show her
In the last weeks I worked for porting the netdump infrastructure to
FreeBSD-CURRENT on the behalf of Sandvine Incorporated.
Netdump is a framework that aims for handling kernel coredumps over
the TCP/IP suite in order to dump to a separate machine than the
running one. That may be used on an inter
17 matches
Mail list logo
