Xavier Galleri wrote:
[...]
>> You've been complaining about this problem for at least a week.
>> Producing some code so that we can test couldn't take more than a
>> couple of hours and would have probably had your issue resolved
>> by now.
>>
>
Alfred Perlstein wrote:
> * Xavier Galleri <[EMAIL PROTECTED]> [010125 10:36] wrote:
>
>> Alfred Perlstein wrote:
>>
>>> I told you about 3 times to provide us with a stipped down source
>>> code module which reproduces this "bug".
>&g
Alfred Perlstein wrote:
> * Xavier Galleri <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> [010125 09:53]
>wrote:
>
>> Well, I am a bit disappointed to get no answer at all to my issue. Is it
>> because this is not the correct fashion to ask for support on
Xavier Galleri wrote:
> Peter Wemm wrote:
>
>> Xavier Galleri wrote:
>>
>>> Hi everybody,
>>>
>>> This mail is related to the 'Need help for crash dump analysis'
>>> mail serie and the more recent 'Information on kernel c
Peter Wemm wrote:
> Xavier Galleri wrote:
>
>> Hi everybody,
>>
>> This mail is related to the 'Need help for crash dump analysis' mail
>> serie and the more recent 'Information on kernel crash dump analysis' mail.
>
>
> Wha
Hi everybody,
This mail is related to the 'Need help for crash dump analysis' mail
serie and the more recent 'Information on kernel crash dump analysis' mail.
I have achieved to (manually) get a stack dump by getting my 'curpcb'
value at the time I call MALLOC and then issuing 'info frame' and
Hi everybody,
I have made some progress on my kernel crash dump issue and here is a
little contribution for those who would encounter the same problem as
the one I got to deal with kernel stack dump.
To begin, I recall the actual issue which is : how could I get the stack
dump of the current
th
me that I should not get ( some_counter - some_other_counter == 1 ) when
'splnet' has been called (this I have asserted by printing 'cpl' to be
equal to 0x62 at crash time) ?
Regards,
Xavier
Alfred Perlstein wrote:
> * Xavier Galleri <[EMAIL PROTECTED]> [010
n my own code, but I would greatly
appreciate to get help either on my GDB usage question or through
technical hints on where I should look at to progress in my investigation.
Thank you very much for your attention,
Rgds,
Xavier
Alfred Perlstein wrote:
> * Xavier Galleri <[EMAIL PROTECTE
?
Regards
Xavier Galleri wrote:
> Thank you for your answer,
>
> It's difficult to believe that nothing more intuitive and immediate
> can be done to get the kernel stack of any process from a GDB session
> on a kernel crash dump. Does it mean that this is something that
ody ever need until
now ?
Also, is there a mean to ask GDB to dump the kernel stack of the 'curproc'
that has been interrupted at the time of kernel panic ?
Regards,
Xavier
diman wrote:
[EMAIL PROTECTED]">On Fri, 12 Jan 2001, Xavier Galleri wrote:OK, let's mak
DB to dump the kernel stack of the 'curproc'
that has been interrupted at the time of kernel panic ?
Regards,
Xavier
diman wrote:
[EMAIL PROTECTED]">On Fri, 12 Jan 2001, Xavier Galleri wrote:
OK, let's make it a bit clearer !
[skiped]
Now, if you've r
my own code, but I would greatly appreciate
to get help either on my GDB usage question or through technical hints on
where I should look at to progress in my investigation.
Thank you very much for your attention,
Rgds,
Xavier
Alfred Perlstein wrote:
[EMAIL PROTECTED]">* Xavi
would greatly appreciate
to get help either on my GDB usage question or through technical hints on
where I should look at to progress in my investigation.
Thank you very much for your attention,
Rgds,
Xavier
Alfred Perlstein wrote:
[EMAIL PROTECTED]">* Xavier Galleri <[EMAI
ody who can help on this ?
Best regards,
Xavier
P.S.: I am still looking how I could dump the kernel stack frame of an
interrupted process from the actual interrupt kernel stack ...
Xavier Galleri wrote:
> Hi everybody,
>
> I am currently working with FreeBSD 4.1 on i386 platform on
Hi everybody,
I am currently working with FreeBSD 4.1 on i386 platform on a
pseudo-device driver that interacts with the networking subsystem in the
kernel. Basically, we are intercepting both incoming and outgoing
IP-level trafficfor specific processing. Obviously, there is also some
adminis
16 matches
Mail list logo
