--On 7. august 2003 10:33 +0930 Greg 'groggy' Lehey <[EMAIL PROTECTED]>
wrote:
Q: If you have a crash, please supply a backtrace from the dump analysis
as discussed below under Kernel Panics. Please don't delete the crash
dump; it may be needed for further analysis.
A: Sorry, I don't have a crash
On Sunday, 3 August 2003 at 11:17:49 +0200, Eivind Olsen wrote:
> --On 3. august 2003 09:37 +0930 Greg 'groggy' Lehey <[EMAIL PROTECTED]>
> wrote:
>> Read the links I just sent you. You haven't loaded the Vinum symbols.
>
> I'm not sure exactly what to do here. I have absolutely no previous
> exp
--On 3. august 2003 09:37 +0930 Greg 'groggy' Lehey <[EMAIL PROTECTED]>
wrote:
Read the links I just sent you. You haven't loaded the Vinum symbols.
I'm not sure exactly what to do here. I have absolutely no previous
experience with kernel debugging, using gdb etc. so I'm lost without
specific
--On 3. august 2003 09:35 +0930 Greg 'groggy' Lehey <[EMAIL PROTECTED]>
wrote:
This is the real issue. Until you supply the information I ask for in
the man page or at http://www.vinumvm.org/vinum/how-to-debug.html,
only Terry can help you.
Ok, I'll try to supply that information:
Q: What proble
--On 3. august 2003 00:31 -0400 John Baldwin <[EMAIL PROTECTED]> wrote:
But you knew that. Also, Eivind, you need to use hex, not decimal
offsets from the functions. You might want to redo the g_dev_strategy()
line with 0x29 instead of 29.
I already though about that so I tested the commands both
On Sunday, 3 August 2003 at 0:31:45 -0400, John Baldwin wrote:
>
> On 03-Aug-2003 Greg 'groggy' Lehey wrote:
>> On Saturday, 2 August 2003 at 16:47:13 +0200, Eivind Olsen wrote:
>>> [EMAIL PROTECTED]:~/tmp/debug > gdb -k kernel.debug
>>> (kgdb) list *(g_dev_strategy+29)
>>
>> This is almost cert
On 03-Aug-2003 Greg 'groggy' Lehey wrote:
> On Saturday, 2 August 2003 at 16:47:13 +0200, Eivind Olsen wrote:
>> --On 2. august 2003 02:11 -0700 Terry Lambert <[EMAIL PROTECTED]>
>> wrote:
db> trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
g_dev_strategy+0x29 launch
I fear we may have gotten a bit off-topic.
E
From: Greg 'groggy' Lehey <[EMAIL PROTECTED]>
To: Terry Lambert <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Yet another crash in FreeBSD 5.1
Date: Sun, 3 Aug 2003 11:21:41 +0930
On Saturday, 2 A
On Saturday, 2 August 2003 at 18:36:24 -0700, Terry Lambert wrote:
> Greg 'groggy' Lehey wrote:
>>> The information I gave him gets him to lines of source code, instead
>>> of just function names with strange hexadecimal numbers that resolve
>>> to instruction offsets that may be specific to his c
Greg 'groggy' Lehey wrote:
> > The information I gave him gets him to lines of source code, instead
> > of just function names with strange hexadecimal numbers that resolve
> > to instruction offsets that may be specific to his compile flags,
> > date of checkout of the sources from CVS, etc..
>
>
Greg 'groggy' Lehey wrote:
> > If this is repeatable for you, it's recommended that you compile
> > Vinum statically into your kernel, so that you can look at the
> > other symbols in the traceback and obtain source lines for them,
> > as well.
>
> No. It is explicitly discouraged.
It saves the
On Saturday, 2 August 2003 at 18:06:36 -0700, Terry Lambert wrote:
> Greg 'groggy' Lehey wrote:
>>> Please take a look at an older thread named (IIRC) vinum or geom bug?
>>> Greg asked for special debug output, but it never happened again for me.
>>> A real murphy bug - it happend on three machine
On Saturday, 2 August 2003 at 17:56:49 -0700, Terry Lambert wrote:
> Greg 'groggy' Lehey wrote:
>>> You don't actually need a crash dump to debug a stack traceback.
>>
>> Great! So you know the answer? Please submit a patch.
>>
>> Seriously, this is nonsense. Yes, it's a null pointer dereferenc
Terry Lambert wrote:
> There's no reason to be paranoid about your baby with me; unlike
> some people, personally I like Vinum, so relax and realize that
> I'm not trying to blame your code by trying to help him squeeze
> more information out of the data he *is* able to gather.
To follow this up:
On Saturday, 2 August 2003 at 17:54:03 -0700, Terry Lambert wrote:
> Eivind Olsen wrote:
>> (kgdb) list *(launch_requests+448)
>> No symbol "launch_requests" in current context.
>> (kgdb) list *(vinumstart+2b2)
>> No symbol "vinumstart" in current context.
>> (kgdb)
>>
>> If anyone wants to take a
Greg 'groggy' Lehey wrote:
> > Please take a look at an older thread named (IIRC) vinum or geom bug?
> > Greg asked for special debug output, but it never happened again for me.
> > A real murphy bug - it happend on three machines once a day and after
> > Gregs response nothing happened over weeks.
Greg 'groggy' Lehey wrote:
> > You don't actually need a crash dump to debug a stack traceback.
>
> Great! So you know the answer? Please submit a patch.
>
> Seriously, this is nonsense. Yes, it's a null pointer dereference.
> What?
That is precisely what doing what I suggested discovers, Gre
Eivind Olsen wrote:
> (kgdb) list *(launch_requests+448)
> No symbol "launch_requests" in current context.
> (kgdb) list *(vinumstart+2b2)
> No symbol "vinumstart" in current context.
> (kgdb)
>
> If anyone wants to take a look at this themselves I've put the compressed
> (gzip) debug-kernel avail
On Saturday, 2 August 2003 at 16:47:13 +0200, Eivind Olsen wrote:
> --On 2. august 2003 02:11 -0700 Terry Lambert <[EMAIL PROTECTED]>
> wrote:
>>> db> trace
>>> g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
>>> g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
>>> lau
On Saturday, 2 August 2003 at 17:00:59 +0200, Eivind Olsen wrote:
> --On 2. august 2003 11:16 +0200 Bernd Walter <[EMAIL PROTECTED]>
> wrote:
>>> Looks like a problem in vinum. The other backtrace was the same, right?
>> Please take a look at an older thread named (IIRC) vinum or geom bug?
>> Gre
On Saturday, 2 August 2003 at 2:11:24 -0700, Terry Lambert wrote:
> Eivind Olsen wrote:
>> Can anyone suggest what I do next to find out about this crash?
>
>> Fatal trap 12: page fault while in kernel mode
>> fault virtual address = 0x14
>
> Dereference of NULL pointer; reference is for elemen
--On 2. august 2003 11:16 +0200 Bernd Walter <[EMAIL PROTECTED]>
wrote:
Looks like a problem in vinum. The other backtrace was the same, right?
Please take a look at an older thread named (IIRC) vinum or geom bug?
Greg asked for special debug output, but it never happened again for me.
A real mur
--On 2. august 2003 02:11 -0700 Terry Lambert <[EMAIL PROTECTED]>
wrote:
db> trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
launch_requests+0x448 vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6)
at vinumstart+0x2
[Sending to [EMAIL PROTECTED], and Kris copied in Greg so I'll also do that]
--On 2. august 2003 02:00 -0700 Kris Kennaway <[EMAIL PROTECTED]> wrote:
db> trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
launch_reque
On Sat, Aug 02, 2003 at 02:00:52AM -0700, Kris Kennaway wrote:
> On Sat, Aug 02, 2003 at 10:11:24AM +0200, Eivind Olsen wrote:
>
> > db> trace
> > g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
> > launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
Eivind Olsen wrote:
> Can anyone suggest what I do next to find out about this crash?
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x14
Dereference of NULL pointer; reference is for element at offset
0x14 in some structure; this is the equivalent of 5 32 bit ints
o
On Sat, Aug 02, 2003 at 10:11:24AM +0200, Eivind Olsen wrote:
> db> trace
> g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
> launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
> vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
I've now had yet another crash under FreeBSD 5.1 (RELENG_5_1, cvsupped 5-6
days ago) and it looks almost the same as the crash I posted about
yesterday (or was it the day before?
Here's some output from DDB:
Krasj 2.7.2003:
Fatal trap 12: page fault while in kernel mode
fault virtual address =
28 matches
Mail list logo
