From owner-lkcd@oss.sgi.com Thu Feb  1 08:21:35 2001
Received:  by oss.sgi.com id <S554100AbRBAQVZ>;
	Thu, 1 Feb 2001 08:21:25 -0800
Received: from hermes.mixx.net ([212.84.196.2]:2308 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S554081AbRBAQVO>;
	Thu, 1 Feb 2001 08:21:14 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 17B52F814
	for <lkcd@oss.sgi.com>; Thu,  1 Feb 2001 17:21:12 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id ED3602CA6F; Thu,  1 Feb 2001 17:21:11 +0100 (CET)
From:   Thomas Graichen <news-innominate.bln.list.sgi.lkcd@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.bln.list.sgi.lkcd
Subject: lkcd & kdb
Date:   1 Feb 2001 16:21:11 GMT
Organization: innominate AG, Berlin, Germany
Lines:  34
Distribution: local
Message-ID: <news2mail-95c2dn$vdt$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 981044471 32189 10.0.0.31 (1 Feb 2001 16:21:11 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686))
To:     lkcd@oss.sgi.com
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

i just patched the latest lkcd patch into the SGI XFS tree (which
also contains kdb) ... it so far also works but after it has
written the dump it panics (now into kdb) on mm/memory.c line 634

                for (j = 0; j < nlast; ppage++, j++) {
                        page = *ppage;
                        if (!page)
                                continue;
                        UnlockPage(page); <-------
                }
        }
        return 0;
}

don't know what the reason for this is - kdb or 2.4.0 kernel - so
my question: did anyone else try this so far? - any solution in
sight?

it is absolutely reproducable if anyone wants to try it - but i
can also post an backtrace of the panic here if that might help
(but it does not look very interesting i think - it ends in
kiovec_unlock or something like) ... btw. i used a simple panic
module (calling panic() in init_module) via insmod to force the
panic ...

any ideas? - thanks in advance

t

-- 
thomas.graichen@innominate.com
                                                         innominate AG
                                                  the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-lkcd@oss.sgi.com Thu Feb  1 08:26:35 2001
Received:  by oss.sgi.com id <S554104AbRBAQ0Z>;
	Thu, 1 Feb 2001 08:26:25 -0800
Received: from mg03.austin.ibm.com ([192.35.232.20]:15505 "EHLO
        mailgate3.austin.ibm.com") by oss.sgi.com with ESMTP
	id <S554092AbRBAQ0U>; Thu, 1 Feb 2001 08:26:20 -0800
Received: from austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96])
	by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA65934;
	Thu, 1 Feb 2001 10:24:26 -0600
Received: from craft.austin.ibm.com (craft.austin.ibm.com [9.53.145.12])
	by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA32504;
	Thu, 1 Feb 2001 10:26:10 -0600
Received: (from dcraft@localhost) by craft.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id KAA29396; Thu, 1 Feb 2001 10:26:10 -0600
From:   Dave Craft <dcraft@austin.ibm.com>
Message-Id: <200102011626.KAA29396@craft.austin.ibm.com>
Subject: Re: lkcd & kdb
To:     graichen@innominate.de
Date:   Thu, 1 Feb 2001 10:26:10 -0600 (CST)
Cc:     lkcd@oss.sgi.com
In-Reply-To: <news2mail-95c2dn$vdt$1@mate.bln.innominate.de> from "Thomas Graichen" at Feb 01, 2001 04:21:11 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing


	I saw this less than 10 minutes ago myself on the 2.4.0
	kernel.  It still seems to produce a valid dump.  I am
	not running with the kdb patch...only lkcd.

	Dave
>
>i just patched the latest lkcd patch into the SGI XFS tree (which
>also contains kdb) ... it so far also works but after it has
>written the dump it panics (now into kdb) on mm/memory.c line 634
>
>                for (j = 0; j < nlast; ppage++, j++) {
>                        page = *ppage;
>                        if (!page)
>                                continue;
>                        UnlockPage(page); <-------
>                }
>        }
>        return 0;
>}
>
>don't know what the reason for this is - kdb or 2.4.0 kernel - so
>my question: did anyone else try this so far? - any solution in
>sight?
>
>it is absolutely reproducable if anyone wants to try it - but i
>can also post an backtrace of the panic here if that might help
>(but it does not look very interesting i think - it ends in
>kiovec_unlock or something like) ... btw. i used a simple panic
>module (calling panic() in init_module) via insmod to force the
>panic ...
>
>any ideas? - thanks in advance
>
>t
>
>-- 
>thomas.graichen@innominate.com
>                                                         innominate AG
>                                                  the linux architects
>tel: +49-30-308806-13   fax: -77             http://www.innominate.com
>


-- 
	--------- Opinions are mine and not IBM's ----------
	Mail : dave@austin.ibm.com	Phone : 512-838-8248		
                  Wish I could fly like Superman.

From owner-lkcd@oss.sgi.com Thu Feb  1 08:41:14 2001
Received:  by oss.sgi.com id <S554126AbRBAQk5>;
	Thu, 1 Feb 2001 08:40:57 -0800
Received: from hermes.mixx.net ([212.84.196.2]:1029 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S554102AbRBAQkl>;
	Thu, 1 Feb 2001 08:40:41 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id C5DD4F81E
	for <lkcd@oss.sgi.com>; Thu,  1 Feb 2001 17:40:38 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id A40D52CA6F; Thu,  1 Feb 2001 17:40:38 +0100 (CET)
From:   Thomas Graichen <news-innominate.bln.list.sgi.lkcd@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.bln.list.sgi.lkcd
Subject: disabling lkcd
Date:   1 Feb 2001 16:40:38 GMT
Organization: innominate AG, Berlin, Germany
Lines:  22
Distribution: local
Message-ID: <news2mail-95c3i6$i8f$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 981045638 18703 10.0.0.31 (1 Feb 2001 16:40:38 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686))
To:     lkcd@oss.sgi.com
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

is there an easy way to disable lkcd dumping hte kernel image on
panic? - i ask because if you have kdb and lkcd in the kernel you
may want to choose which one should react on a panic (depending
on if you are sitting in front of the system - kdb - or the system
is running somethere remotely and crashes - lkcd) ... i think
something like

  /proc/sys/vmdump/active

with either 1 or 0 (which might also be used from the vmdump script
to activate it) would be nice ... or can i disable it also easily
after i enabled it via vmdump config?

thanks in advance

t

-- 
thomas.graichen@innominate.com
                                                         innominate AG
                                                  the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-lkcd@oss.sgi.com Thu Feb  1 08:52:15 2001
Received:  by oss.sgi.com id <S554129AbRBAQwF>;
	Thu, 1 Feb 2001 08:52:05 -0800
Received: from w032.z064001165.sjc-ca.dsl.cnc.net ([64.1.165.32]:1031 "EHLO
        www.aparity.com") by oss.sgi.com with ESMTP id <S554106AbRBAQvs>;
	Thu, 1 Feb 2001 08:51:48 -0800
Received: from alacritech.com (localhost [127.0.0.1])
	by www.aparity.com (8.9.3/8.9.3) with ESMTP id IAA29967;
	Thu, 1 Feb 2001 08:58:21 -0800
Message-ID: <3A7995AD.155136E8@alacritech.com>
Date:   Thu, 01 Feb 2001 08:58:21 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     lkcd@oss.sgi.com
Subject: Re: disabling lkcd
References: <news2mail-95c3i6$i8f$1@mate.bln.innominate.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Thomas Graichen wrote:
> 
> is there an easy way to disable lkcd dumping hte kernel image on
> panic? - i ask because if you have kdb and lkcd in the kernel you
> may want to choose which one should react on a panic (depending
> on if you are sitting in front of the system - kdb - or the system
> is running somethere remotely and crashes - lkcd) ... i think
> something like
> 
>   /proc/sys/vmdump/active

Edit /etc/sysconfig/vmdump, and change DUMP_ACTIVE from 1 to 0.
The information about DUMP_ACTIVE is documented in that file.
There are a few other tunables as well.

Good guess ... :)

--Matt

> with either 1 or 0 (which might also be used from the vmdump script
> to activate it) would be nice ... or can i disable it also easily
> after i enabled it via vmdump config?
> 
> thanks in advance
> 
> t
> 
> --
> thomas.graichen@innominate.com
>                                                          innominate AG
>                                                   the linux architects
> tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-lkcd@oss.sgi.com Thu Feb  1 08:55:05 2001
Received:  by oss.sgi.com id <S554132AbRBAQy4>;
	Thu, 1 Feb 2001 08:54:56 -0800
Received: from w032.z064001165.sjc-ca.dsl.cnc.net ([64.1.165.32]:2823 "EHLO
        www.aparity.com") by oss.sgi.com with ESMTP id <S554128AbRBAQyu>;
	Thu, 1 Feb 2001 08:54:50 -0800
Received: from alacritech.com (localhost [127.0.0.1])
	by www.aparity.com (8.9.3/8.9.3) with ESMTP id JAA29975;
	Thu, 1 Feb 2001 09:01:50 -0800
Message-ID: <3A79967E.83ED9453@alacritech.com>
Date:   Thu, 01 Feb 2001 09:01:50 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Dave Craft <dcraft@austin.ibm.com>
CC:     graichen@innominate.de, lkcd@oss.sgi.com
Subject: Re: lkcd & kdb
References: <200102011626.KAA29396@craft.austin.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Dave Craft wrote:
> 
>         I saw this less than 10 minutes ago myself on the 2.4.0
>         kernel.  It still seems to produce a valid dump.  I am
>         not running with the kdb patch...only lkcd.
> 
>         Dave
> >
> >i just patched the latest lkcd patch into the SGI XFS tree (which
> >also contains kdb) ... it so far also works but after it has
> >written the dump it panics (now into kdb) on mm/memory.c line 634
> >
> >                for (j = 0; j < nlast; ppage++, j++) {
> >                        page = *ppage;
> >                        if (!page)
> >                                continue;
> >                        UnlockPage(page); <-------
> >                }
> >        }
> >        return 0;
> >}
> >
> >don't know what the reason for this is - kdb or 2.4.0 kernel - so
> >my question: did anyone else try this so far? - any solution in
> >sight?

The solution at this point is two-fold.  First, I believe you can
remove the call to free_kiovec(), and that would eliminate the
problem (if you have a system ready to try it, give it a shot).
If that doesn't work, I can explore it in more detail.  We don't
_really_ have to free the kiovec, as we're pretty much done with
I/O, and all we're going to do is reset the system anyway.  I just
had that in there for completeness.

The _real_ solution is to not use kiobufs at all.  I've got
an IDE dump driver sort of working, it's choking after about 700 pages
or so (not sure why yet), but it's coming along.  That will be our
next patch.  In the meantime, though, if the removal of free_kiovec()
fixes the problem, let me know and I'll release a patch in the meantime.

Thanks, guys.

--Matt

> >
> >it is absolutely reproducable if anyone wants to try it - but i
> >can also post an backtrace of the panic here if that might help
> >(but it does not look very interesting i think - it ends in
> >kiovec_unlock or something like) ... btw. i used a simple panic
> >module (calling panic() in init_module) via insmod to force the
> >panic ...
> >
> >any ideas? - thanks in advance
> >
> >t
> >
> >--
> >thomas.graichen@innominate.com
> >                                                         innominate AG
> >                                                  the linux architects
> >tel: +49-30-308806-13   fax: -77             http://www.innominate.com
> >
> 
> --
>         --------- Opinions are mine and not IBM's ----------
>         Mail : dave@austin.ibm.com      Phone : 512-838-8248
>                   Wish I could fly like Superman.

From owner-lkcd@oss.sgi.com Thu Feb  1 13:08:25 2001
Received:  by oss.sgi.com id <S554176AbRBAVIG>;
	Thu, 1 Feb 2001 13:08:06 -0800
Received: from hermes.mixx.net ([212.84.196.2]:5390 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S554162AbRBAVID>;
	Thu, 1 Feb 2001 13:08:03 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id BDB12F838
	for <lkcd@oss.sgi.com>; Thu,  1 Feb 2001 22:08:01 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 7ACF82CA6F; Thu,  1 Feb 2001 22:08:01 +0100 (CET)
From:   Thomas Graichen <news-innominate.bln.list.sgi.lkcd@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.bln.list.sgi.lkcd
Subject: Re: lkcd & kdb
Date:   1 Feb 2001 21:08:01 GMT
Organization: innominate AG, Berlin, Germany
Lines:  30
Distribution: local
Message-ID: <news2mail-95cj7h$rad$2@mate.bln.innominate.de>
References: <200102011626.KAA29396@craft.austin.ibm.com> <3A79967E.83ED9453@alacritech.com>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 981061681 27981 10.0.0.31 (1 Feb 2001 21:08:01 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686))
To:     lkcd@oss.sgi.com
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

"Matt D. Robinson" <yakker@alacritech.com> wrote:
>> >i just patched the latest lkcd patch into the SGI XFS tree (which
>> >also contains kdb) ... it so far also works but after it has
>> >written the dump it panics (now into kdb) on mm/memory.c line 634

> The solution at this point is two-fold.  First, I believe you can
> remove the call to free_kiovec(), and that would eliminate the
> problem (if you have a system ready to try it, give it a shot).
> If that doesn't work, I can explore it in more detail.  We don't
> _really_ have to free the kiovec, as we're pretty much done with
> I/O, and all we're going to do is reset the system anyway.  I just
> had that in there for completeness.

> The _real_ solution is to not use kiobufs at all.  I've got
> an IDE dump driver sort of working, it's choking after about 700 pages
> or so (not sure why yet), but it's coming along.  That will be our
> next patch.  In the meantime, though, if the removal of free_kiovec()
> fixes the problem, let me know and I'll release a patch in the meantime.

ok - without free_kiovec it works as expected - thanks (if you do
a new patch something against 2.4.[0,1] might be good for others
because the test1[1,2] patches have a few (simple) rejects btw.

t

-- 
thomas.graichen@innominate.com
                                                         innominate AG
                                                  the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-lkcd@oss.sgi.com Thu Feb  1 14:22:16 2001
Received:  by oss.sgi.com id <S554032AbRBAWV4>;
	Thu, 1 Feb 2001 14:21:56 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:62987 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S554025AbRBAWV2>;
	Thu, 1 Feb 2001 14:21:28 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id uiwoaaaa for <lkcd@oss.sgi.com>; Thu, 1 Feb 2001 14:16:22 -0800
Message-ID: <3A79E2C4.464114AD@alacritech.com>
Date:   Thu, 01 Feb 2001 14:27:16 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     lkcd@oss.sgi.com
Subject: Re: lkcd & kdb
References: <200102011626.KAA29396@craft.austin.ibm.com> <3A79967E.83ED9453@alacritech.com> <news2mail-95cj7h$rad$2@mate.bln.innominate.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Thomas Graichen wrote:
> 
> "Matt D. Robinson" <yakker@alacritech.com> wrote:
> >> >i just patched the latest lkcd patch into the SGI XFS tree (which
> >> >also contains kdb) ... it so far also works but after it has
> >> >written the dump it panics (now into kdb) on mm/memory.c line 634
> 
> > The solution at this point is two-fold.  First, I believe you can
> > remove the call to free_kiovec(), and that would eliminate the
> > problem (if you have a system ready to try it, give it a shot).
> > If that doesn't work, I can explore it in more detail.  We don't
> > _really_ have to free the kiovec, as we're pretty much done with
> > I/O, and all we're going to do is reset the system anyway.  I just
> > had that in there for completeness.
> 
> > The _real_ solution is to not use kiobufs at all.  I've got
> > an IDE dump driver sort of working, it's choking after about 700 pages
> > or so (not sure why yet), but it's coming along.  That will be our
> > next patch.  In the meantime, though, if the removal of free_kiovec()
> > fixes the problem, let me know and I'll release a patch in the meantime.
> 
> ok - without free_kiovec it works as expected - thanks (if you do
> a new patch something against 2.4.[0,1] might be good for others
> because the test1[1,2] patches have a few (simple) rejects btw.

I'll clean this up tonight, and try to have a patch out by tomorrow (and
if not, it'll be out Monday).  BTW, anyone really good with IDE drivers?
I've got a couple of questions and I wanted to avoid bugging Andre. :)
Some stuff about the IDE control registers.

--Matt

From owner-lkcd@oss.sgi.com Thu Feb  1 14:32:16 2001
Received:  by oss.sgi.com id <S554182AbRBAWcH>;
	Thu, 1 Feb 2001 14:32:07 -0800
Received: from Cantor.suse.de ([213.95.15.193]:48400 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S554029AbRBAWbw>;
	Thu, 1 Feb 2001 14:31:52 -0800
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id B78281E411; Thu,  1 Feb 2001 23:31:50 +0100 (MET)
Date:   Thu, 1 Feb 2001 23:31:36 +0100
From:   Andi Kleen <ak@suse.de>
To:     "Matt D. Robinson" <yakker@alacritech.com>
Cc:     Thomas Graichen <graichen@innominate.de>, lkcd@oss.sgi.com
Subject: Re: lkcd & kdb
Message-ID: <20010201233136.A31376@gruyere.muc.suse.de>
References: <200102011626.KAA29396@craft.austin.ibm.com> <3A79967E.83ED9453@alacritech.com> <news2mail-95cj7h$rad$2@mate.bln.innominate.de> <3A79E2C4.464114AD@alacritech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A79E2C4.464114AD@alacritech.com>; from yakker@alacritech.com on Thu, Feb 01, 2001 at 02:27:16PM -0800
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

On Thu, Feb 01, 2001 at 02:27:16PM -0800, Matt D. Robinson wrote:
> I'll clean this up tonight, and try to have a patch out by tomorrow (and
> if not, it'll be out Monday).  BTW, anyone really good with IDE drivers?
> I've got a couple of questions and I wanted to avoid bugging Andre. :)
> Some stuff about the IDE control registers.

Sounds all rather risky. I would recommend to try it only on test
hard disks with test controllers.


-Andi

From owner-lkcd@oss.sgi.com Thu Feb  1 15:34:17 2001
Received:  by oss.sgi.com id <S554187AbRBAXeI>;
	Thu, 1 Feb 2001 15:34:08 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:20740 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S554184AbRBAXdt>;
	Thu, 1 Feb 2001 15:33:49 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id qnwoaaaa for <lkcd@oss.sgi.com>; Thu, 1 Feb 2001 15:28:48 -0800
Message-ID: <3A79F3BD.3CBECED0@alacritech.com>
Date:   Thu, 01 Feb 2001 15:39:41 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andi Kleen <ak@suse.de>
CC:     Thomas Graichen <graichen@innominate.de>, lkcd@oss.sgi.com
Subject: Re: lkcd & kdb
References: <200102011626.KAA29396@craft.austin.ibm.com> <3A79967E.83ED9453@alacritech.com> <news2mail-95cj7h$rad$2@mate.bln.innominate.de> <3A79E2C4.464114AD@alacritech.com> <20010201233136.A31376@gruyere.muc.suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Andi Kleen wrote:
> 
> On Thu, Feb 01, 2001 at 02:27:16PM -0800, Matt D. Robinson wrote:
> > I'll clean this up tonight, and try to have a patch out by tomorrow (and
> > if not, it'll be out Monday).  BTW, anyone really good with IDE drivers?
> > I've got a couple of questions and I wanted to avoid bugging Andre. :)
> > Some stuff about the IDE control registers.
> 
> Sounds all rather risky. I would recommend to try it only on test
> hard disks with test controllers.
> 
> -Andi

Oh yea, this IDE stuff is completely experimental, so don't use it
on anything but a test system you're willing to reload against.  The
other free_kiovec() patch is just the old dump mechanism, and that's
okay as-is.

Andi, want a look at the IDE driver changes?

--Matt

From owner-lkcd@oss.sgi.com Thu Feb  1 15:49:36 2001
Received:  by oss.sgi.com id <S554193AbRBAXtR>;
	Thu, 1 Feb 2001 15:49:17 -0800
Received: from Cantor.suse.de ([213.95.15.193]:49925 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S554190AbRBAXtD>;
	Thu, 1 Feb 2001 15:49:03 -0800
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id BEB211E425; Fri,  2 Feb 2001 00:49:01 +0100 (MET)
Date:   Fri, 2 Feb 2001 00:48:52 +0100
From:   Andi Kleen <ak@suse.de>
To:     "Matt D. Robinson" <yakker@alacritech.com>
Cc:     Andi Kleen <ak@suse.de>, Thomas Graichen <graichen@innominate.de>,
        lkcd@oss.sgi.com
Subject: Re: lkcd & kdb
Message-ID: <20010202004852.A2172@gruyere.muc.suse.de>
References: <200102011626.KAA29396@craft.austin.ibm.com> <3A79967E.83ED9453@alacritech.com> <news2mail-95cj7h$rad$2@mate.bln.innominate.de> <3A79E2C4.464114AD@alacritech.com> <20010201233136.A31376@gruyere.muc.suse.de> <3A79F3BD.3CBECED0@alacritech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A79F3BD.3CBECED0@alacritech.com>; from yakker@alacritech.com on Thu, Feb 01, 2001 at 03:39:41PM -0800
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

On Thu, Feb 01, 2001 at 03:39:41PM -0800, Matt D. Robinson wrote:
> Andi Kleen wrote:
> > 
> > On Thu, Feb 01, 2001 at 02:27:16PM -0800, Matt D. Robinson wrote:
> > > I'll clean this up tonight, and try to have a patch out by tomorrow (and
> > > if not, it'll be out Monday).  BTW, anyone really good with IDE drivers?
> > > I've got a couple of questions and I wanted to avoid bugging Andre. :)
> > > Some stuff about the IDE control registers.
> > 
> > Sounds all rather risky. I would recommend to try it only on test
> > hard disks with test controllers.
> > 
> > -Andi
> 
> Oh yea, this IDE stuff is completely experimental, so don't use it
> on anything but a test system you're willing to reload against.  The
> other free_kiovec() patch is just the old dump mechanism, and that's
> okay as-is.
> 
> Andi, want a look at the IDE driver changes?

I can take a look at it, but I'm not exactly an IDE expert. 
Also send it to alan@lxorguk.ukuu.org.uk, he's interested too. 

-Andi

From owner-lkcd@oss.sgi.com Fri Feb  2 10:46:39 2001
Received:  by oss.sgi.com id <S554024AbRBBSqU>;
	Fri, 2 Feb 2001 10:46:20 -0800
Received: from [216.61.45.26] ([216.61.45.26]:38791 "EHLO astroarch.com")
	by oss.sgi.com with ESMTP id <S553967AbRBBSqP>;
	Fri, 2 Feb 2001 10:46:15 -0800
Received: from gallantfox ([10.0.0.9])
	by astroarch.com (8.11.0/8.11.0) with SMTP id f12IjqH09770
	for <lkcd@oss.sgi.com>; Fri, 2 Feb 2001 12:45:55 -0600
From:   "elh" <elh@astroarch.com>
Cc:     <lkcd@oss.sgi.com>
Subject: RE: lkcd & kdb
Date:   Fri, 2 Feb 2001 12:52:56 -0600
Message-ID: <MGECKEMFELEFIGEPDPPMOEAMCCAA.elh@astroarch.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010202004852.A2172@gruyere.muc.suse.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Is there a patch file for the 2.4.1 kernel yet?

-Edward Haletky

> -----Original Message-----
> From: owner-lkcd@oss.sgi.com [mailto:owner-lkcd@oss.sgi.com]On Behalf Of
> Andi Kleen
> Sent: Thursday, February 01, 2001 5:49 PM
> To: Matt D. Robinson
> Cc: Andi Kleen; Thomas Graichen; lkcd@oss.sgi.com
> Subject: Re: lkcd & kdb
> 
> 
> On Thu, Feb 01, 2001 at 03:39:41PM -0800, Matt D. Robinson wrote:
> > Andi Kleen wrote:
> > > 
> > > On Thu, Feb 01, 2001 at 02:27:16PM -0800, Matt D. Robinson wrote:
> > > > I'll clean this up tonight, and try to have a patch out by 
> tomorrow (and
> > > > if not, it'll be out Monday).  BTW, anyone really good with 
> IDE drivers?
> > > > I've got a couple of questions and I wanted to avoid 
> bugging Andre. :)
> > > > Some stuff about the IDE control registers.
> > > 
> > > Sounds all rather risky. I would recommend to try it only on test
> > > hard disks with test controllers.
> > > 
> > > -Andi
> > 
> > Oh yea, this IDE stuff is completely experimental, so don't use it
> > on anything but a test system you're willing to reload against.  The
> > other free_kiovec() patch is just the old dump mechanism, and that's
> > okay as-is.
> > 
> > Andi, want a look at the IDE driver changes?
> 
> I can take a look at it, but I'm not exactly an IDE expert. 
> Also send it to alan@lxorguk.ukuu.org.uk, he's interested too. 
> 
> -Andi
> 

From owner-lkcd@oss.sgi.com Fri Feb  2 14:51:50 2001
Received:  by oss.sgi.com id <S554074AbRBBWvk>;
	Fri, 2 Feb 2001 14:51:40 -0800
Received: from dnai-216-15-110-218.cust.dnai.com ([216.15.110.218]:27629 "EHLO
        mail.3pardata.com") by oss.sgi.com with ESMTP id <S554071AbRBBWvY>;
	Fri, 2 Feb 2001 14:51:24 -0800
Received: from postal.3pardata.com (3pardata.com [216.15.110.220])
	by mail.3pardata.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27631
	for <lkcd@oss.sgi.com>; Fri, 2 Feb 2001 14:51:24 -0800 (PST)
Received: from amatiel2 (dhcp-001-200.3pardata.com [192.168.1.200]) by postal.3pardata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id C40J718T; Fri, 2 Feb 2001 14:51:24 -0800
Message-ID: <050e01c08d73$7c3ef4b0$c801a8c0@3pardata.com>
From:   "Guy Edjlali" <edj@3pardata.com>
To:     <lkcd@oss.sgi.com>
Subject: Kernel BUG at memory.c:629
Date:   Fri, 2 Feb 2001 15:54:30 -0800
Organization: 3pardata
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing


Hello

I installed lkcd on a redhat 6.2 machine (dell)
It dumps the kernel. However it does not restart.
It seems stuck at:

Writing dump pages .....................
Dump complete
Kernel BUG at memory.c:629

When rebooting (after a harware reset), It starts
saving the crashdump. However, the process which
crashed the kernel (crashnow) has a stack of size 0.

Anyone else is encountering this problem ?
Thanks

- Guy Edjlali

> more analysis.1
====================
CURRENT SYSTEM TASKS
====================

    ADDR    UID    PID   PPID  STATE     FLAGS  NAME
============================================================================
===
cb036000   1044    917    917      1       100  su
cc0f6000      0    919    919      1       100  tcsh
cd076000      0    966    966      0         0  crashnow

===========================
STACK TRACE OF FAILING TASK
===========================

================================================================
STACK TRACE FOR TASK: 0xcd076000 (crashnow)
...
 0 sys_setpriority+32 [0xc011497c]
 1 system_call+44 [0xc0108f14]
================================================================

[root@eiael]# ./lcrash.0
map = /boot/System.map, vmdump = /dev/mem, outfile = stdout, kerntypes =
/boot/Kerntypes

Please wait.................
>> t 0xcd076000
ZERO SIZE!!
================================================================
STACK TRACE FOR TASK: 0xcd076000()

================================================================



From owner-lkcd@oss.sgi.com Fri Feb  2 15:06:09 2001
Received:  by oss.sgi.com id <S554087AbRBBXFu>;
	Fri, 2 Feb 2001 15:05:50 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:21009 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S554077AbRBBXFq>;
	Fri, 2 Feb 2001 15:05:46 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id ugyoaaaa for <lkcd@oss.sgi.com>; Fri, 2 Feb 2001 15:00:43 -0800
Message-ID: <3A7B3EA9.9F1C4FD@alacritech.com>
Date:   Fri, 02 Feb 2001 15:11:37 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Guy Edjlali <edj@3pardata.com>
CC:     lkcd@oss.sgi.com
Subject: Re: Kernel BUG at memory.c:629
References: <050e01c08d73$7c3ef4b0$c801a8c0@3pardata.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Guy Edjlali wrote:
> 
> Hello
> 
> I installed lkcd on a redhat 6.2 machine (dell)
> It dumps the kernel. However it does not restart.
> It seems stuck at:
> 
> Writing dump pages .....................
> Dump complete
> Kernel BUG at memory.c:629

Yes; remove the free_kiovec() from drivers/block/vmdump.c,
and re-build your kernel.  I'm in the process of building
new 2.4.0 and 2.4.1 patches right now.

--Matt

From owner-lkcd@oss.sgi.com Mon Feb  5 15:55:27 2001
Received:  by oss.sgi.com id <S554037AbRBEXzI>;
	Mon, 5 Feb 2001 15:55:08 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:59911 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S554001AbRBEXzA>;
	Mon, 5 Feb 2001 15:55:00 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id izapaaaa for <lkcd@oss.sgi.com>; Mon, 5 Feb 2001 15:49:47 -0800
Message-ID: <3A7F3EB0.382552AB@alacritech.com>
Date:   Mon, 05 Feb 2001 16:00:48 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     lkcd@oss.sgi.com
Subject: 2.4.0 and 2.4.1 status ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Just an FYI, we've finished up the patches, but we've found a small
problem on panic() dumps with the new RH 7.0 compilers where we
don't get a proper stack trace.  At least, that's where we believe
the problem is.  :)  We're working on resolving it now.

I just wanted to let people know where we were at, and that we'll
release the patches as soon as we're over this bug (hopefully in the
next day or two, tops).

Also, to Nomura-san, we'll try to add in your page typing fixes
for the 2.4.X (X > 1) revisions, so we'll actually move over to
page typing.  Thanks to everyone for their source change
recommendations so far.

--Matt

From owner-lkcd@oss.sgi.com Mon Feb  5 16:44:29 2001
Received:  by oss.sgi.com id <S553967AbRBFAoK>;
	Mon, 5 Feb 2001 16:44:10 -0800
Received: from mg02.austin.ibm.com ([192.35.232.12]:21164 "EHLO
        mg02.austin.ibm.com") by oss.sgi.com with ESMTP id <S553825AbRBFAoA>;
	Mon, 5 Feb 2001 16:44:00 -0800
Received: from austin.ibm.com (netmail2.austin.ibm.com [9.53.250.97])
	by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA39662;
	Mon, 5 Feb 2001 18:47:24 -0600
Received: from craft.austin.ibm.com (craft.austin.ibm.com [9.53.145.12])
	by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA21336;
	Mon, 5 Feb 2001 18:43:56 -0600
Received: (from dcraft@localhost) by craft.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id SAA23226; Mon, 5 Feb 2001 18:43:56 -0600
From:   Dave Craft <dcraft@austin.ibm.com>
Message-Id: <200102060043.SAA23226@craft.austin.ibm.com>
Subject: Re: 2.4.0 and 2.4.1 status ...
To:     yakker@alacritech.com (Matt D. Robinson)
Date:   Mon, 5 Feb 2001 18:43:56 -0600 (CST)
Cc:     lkcd@oss.sgi.com
In-Reply-To: <3A7F3EB0.382552AB@alacritech.com> from "Matt D. Robinson" at Feb 05, 2001 04:00:48 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing


	You may want to try the egcs compilers provided with
	RH 7.0 (compat-egcs-6.2-1.1.2.9).  These are roughly
	equivalent to the 2.91.66 gcc version provided with RH 6.2

	I've run into a number of problems with the default gcc 
	version 2.96.

	dave

>
>Just an FYI, we've finished up the patches, but we've found a small
>problem on panic() dumps with the new RH 7.0 compilers where we
>don't get a proper stack trace.  At least, that's where we believe
>the problem is.  :)  We're working on resolving it now.
>
>I just wanted to let people know where we were at, and that we'll
>release the patches as soon as we're over this bug (hopefully in the
>next day or two, tops).
>
>Also, to Nomura-san, we'll try to add in your page typing fixes
>for the 2.4.X (X > 1) revisions, so we'll actually move over to
>page typing.  Thanks to everyone for their source change
>recommendations so far.
>
>--Matt
>


-- 
	--------- Opinions are mine and not IBM's ----------
	Mail : dave@austin.ibm.com	Phone : 512-838-8248		
	            I am Jack's email closing

From owner-lkcd@oss.sgi.com Mon Feb  5 16:58:58 2001
Received:  by oss.sgi.com id <S553988AbRBFA6t>;
	Mon, 5 Feb 2001 16:58:49 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:53006 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S553825AbRBFA62>;
	Mon, 5 Feb 2001 16:58:28 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id zbbpaaaa for <lkcd@oss.sgi.com>; Mon, 5 Feb 2001 16:53:15 -0800
Message-ID: <3A7F4D8F.A2508D86@alacritech.com>
Date:   Mon, 05 Feb 2001 17:04:15 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Dave Craft <dcraft@austin.ibm.com>
CC:     lkcd@oss.sgi.com
Subject: Re: 2.4.0 and 2.4.1 status ...
References: <200102060043.SAA23226@craft.austin.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Dave Craft wrote:
> 
>         You may want to try the egcs compilers provided with
>         RH 7.0 (compat-egcs-6.2-1.1.2.9).  These are roughly
>         equivalent to the 2.91.66 gcc version provided with RH 6.2
> 
>         I've run into a number of problems with the default gcc
>         version 2.96.

Yea, we'd love to, but unfortunately we have to try to fix this,
since we shouldn't have to worry about what compiler someone uses
(theoretically).  If it's not fixable, fine, but if there's a way
to work around a compiler issue, we're obligated to do that, since
we don't want to have to go telling people "Oh, you have to use
compiler X.Y.ZZ-A.B.C.".  I agree with you about the compilers,
BTW.

More info as it becomes available ...

--Matt

> 
>         dave
> 
> >
> >Just an FYI, we've finished up the patches, but we've found a small
> >problem on panic() dumps with the new RH 7.0 compilers where we
> >don't get a proper stack trace.  At least, that's where we believe
> >the problem is.  :)  We're working on resolving it now.
> >
> >I just wanted to let people know where we were at, and that we'll
> >release the patches as soon as we're over this bug (hopefully in the
> >next day or two, tops).
> >
> >Also, to Nomura-san, we'll try to add in your page typing fixes
> >for the 2.4.X (X > 1) revisions, so we'll actually move over to
> >page typing.  Thanks to everyone for their source change
> >recommendations so far.
> >
> >--Matt
> >
> 
> --
>         --------- Opinions are mine and not IBM's ----------
>         Mail : dave@austin.ibm.com      Phone : 512-838-8248
>                     I am Jack's email closing

From owner-lkcd@oss.sgi.com Tue Feb  6 08:52:17 2001
Received:  by oss.sgi.com id <S553881AbRBFQwI>;
	Tue, 6 Feb 2001 08:52:08 -0800
Received: from mercury.eng.emc.com ([168.159.40.77]:45062 "EHLO
        mercury.lss.emc.com") by oss.sgi.com with ESMTP id <S553863AbRBFQvx>;
	Tue, 6 Feb 2001 08:51:53 -0800
Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2653.19)
	id <1LHQZYRP>; Tue, 6 Feb 2001 11:51:34 -0500
Message-ID: <221EA3AEAB55D411A2DA00D0B774E6F70A058B@marino.lss.emc.com>
From:   "goggin, edward" <goggin_edward@emc.com>
To:     "'lkcd@oss.sgi.com'" <lkcd@oss.sgi.com>
Subject: support for Linux 2.4.0 GA kernel
Date:   Tue, 6 Feb 2001 11:52:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0905D.2030EF10"
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0905D.2030EF10
Content-Type: text/plain;
	charset="iso-8859-1"

When do you think you will have a LKCD kernel patch for
Linux kernel version 2.4.0 GA?

Thanks,

Ed Goggin

------_=_NextPart_001_01C0905D.2030EF10
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>support for Linux 2.4.0 GA kernel</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>When do you think you will have a LKCD kernel patch for</FONT>
<BR><FONT SIZE=2>Linux kernel version 2.4.0 GA?</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
</P>

<P><FONT SIZE=2>Ed Goggin</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0905D.2030EF10--

From owner-lkcd@oss.sgi.com Tue Feb  6 10:09:47 2001
Received:  by oss.sgi.com id <S553889AbRBFSJi>;
	Tue, 6 Feb 2001 10:09:38 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:16145 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S553877AbRBFSJV>;
	Tue, 6 Feb 2001 10:09:21 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id bzbpaaaa for <lkcd@oss.sgi.com>; Tue, 6 Feb 2001 10:04:11 -0800
Message-ID: <3A803F2F.E47A669A@alacritech.com>
Date:   Tue, 06 Feb 2001 10:15:11 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "goggin, edward" <goggin_edward@emc.com>
CC:     "'lkcd@oss.sgi.com'" <lkcd@oss.sgi.com>
Subject: Re: support for Linux 2.4.0 GA kernel
References: <221EA3AEAB55D411A2DA00D0B774E6F70A058B@marino.lss.emc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

> "goggin, edward" wrote:
> 
> When do you think you will have a LKCD kernel patch for
> Linux kernel version 2.4.0 GA?
> 
> Thanks,
> 
> Ed Goggin

We're working on it now.  If I can fix this one x86 problem
today (turns out we've run into another eip/esp conflict in
the dump), we'll be set, and it'll be out this afternoon.

I'll probably release the 2.4.1 patch at the same time.

--Matt

From owner-lkcd@oss.sgi.com Wed Feb  7 13:20:26 2001
Received:  by oss.sgi.com id <S553712AbRBGVUF>;
	Wed, 7 Feb 2001 13:20:05 -0800
Received: from mercury.eng.emc.com ([168.159.40.77]:28174 "EHLO
        mercury.lss.emc.com") by oss.sgi.com with ESMTP id <S553708AbRBGVTx>;
	Wed, 7 Feb 2001 13:19:53 -0800
Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2653.19)
	id <1LHQ62LS>; Wed, 7 Feb 2001 16:19:32 -0500
Message-ID: <221EA3AEAB55D411A2DA00D0B774E6F70A0592@marino.lss.emc.com>
From:   "goggin, edward" <goggin_edward@emc.com>
To:     "'lkcd@oss.sgi.com'" <lkcd@oss.sgi.com>
Subject: LKCD support for Linux 2.4.0 GA kernel
Date:   Wed, 7 Feb 2001 16:20:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0914B.BCA923F0"
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0914B.BCA923F0
Content-Type: text/plain;
	charset="iso-8859-1"

Does the 3.1 directory for the kernel patch of LKCD contain the
updates for the Linux kernel version 2.4.0 GA?  I (and others)
don't have sufficient access (read+execute) in order to move around
the directory or read the files within it.  Is this intentional?

Thanks,

Ed Goggin

------_=_NextPart_001_01C0914B.BCA923F0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>LKCD support for Linux 2.4.0 GA kernel</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Does the 3.1 directory for the kernel patch of LKCD contain the</FONT>
<BR><FONT SIZE=2>updates for the Linux kernel version 2.4.0 GA?&nbsp; I (and others)</FONT>
<BR><FONT SIZE=2>don't have sufficient access (read+execute) in order to move around</FONT>
<BR><FONT SIZE=2>the directory or read the files within it.&nbsp; Is this intentional?</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
</P>

<P><FONT SIZE=2>Ed Goggin</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0914B.BCA923F0--

From owner-lkcd@oss.sgi.com Wed Feb  7 13:51:57 2001
Received:  by oss.sgi.com id <S553736AbRBGVvh>;
	Wed, 7 Feb 2001 13:51:37 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:33546 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S553724AbRBGVvN>;
	Wed, 7 Feb 2001 13:51:13 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id pfepaaaa for <lkcd@oss.sgi.com>; Wed, 7 Feb 2001 13:45:56 -0800
Message-ID: <3A81C4AA.D53D4263@alacritech.com>
Date:   Wed, 07 Feb 2001 13:56:58 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "goggin, edward" <goggin_edward@emc.com>
CC:     "'lkcd@oss.sgi.com'" <lkcd@oss.sgi.com>
Subject: Re: LKCD support for Linux 2.4.0 GA kernel
References: <221EA3AEAB55D411A2DA00D0B774E6F70A0592@marino.lss.emc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

> "goggin, edward" wrote:
> 
> Does the 3.1 directory for the kernel patch of LKCD contain the
> updates for the Linux kernel version 2.4.0 GA?  I (and others)
> don't have sufficient access (read+execute) in order to move around
> the directory or read the files within it.  Is this intentional?
> 
> Thanks,
> 
> Ed Goggin

Wow, you guys are fast. :)  I haven't copied the files in yet.
Tom and I are setting up the directories now, and they should be
all together and available at the end of today (PST).  We're
getting it done as soon as our fingers will let us. :)

--Matt

From owner-lkcd@oss.sgi.com Wed Feb  7 18:39:28 2001
Received:  by oss.sgi.com id <S553735AbRBHCjT>;
	Wed, 7 Feb 2001 18:39:19 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:61962 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S553711AbRBHCjC>;
	Wed, 7 Feb 2001 18:39:02 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id hrepaaaa for <lkcd@oss.sgi.com>; Wed, 7 Feb 2001 18:33:51 -0800
Message-ID: <3A820821.AF81D1B4@alacritech.com>
Date:   Wed, 07 Feb 2001 18:44:49 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     lkcd@oss.sgi.com
Subject: LKCD 3.1 Tree Available
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

I've made the 3.1 tree, including the latest 2.4 patches (2.4.0
and 2.4.1) as well as the latest lkcdutils RPM fully available
to those that want to download them.  I've put them through our
basic set of tests (crash, reboot, crash, reboot, repeat until
really, really tired).  Let us know of any problems you have
with them, and we'll try to fix things ASAP.  Be sure you use
the latest 'lkcdutils' RPM with the latest crash dump patches.

Thanks to everyone for their patience.  The next revision will
include some of the patches from the community (particularly for
the page typing changes).

Download from:

	ftp://oss.sgi.com/projects/lkcd/download/current/

And of course, as always, feedback (good or bad) is greatly
appreciated.

--Matt

From owner-lkcd@oss.sgi.com Thu Feb  8 10:23:05 2001
Received:  by oss.sgi.com id <S553669AbRBHSWq>;
	Thu, 8 Feb 2001 10:22:46 -0800
Received: from atlrel1.hp.com ([156.153.255.210]:20943 "HELO atlrel1.hp.com")
	by oss.sgi.com with SMTP id <S553652AbRBHSWU>;
	Thu, 8 Feb 2001 10:22:20 -0800
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel1.hp.com (Postfix) with ESMTP id C60A7A6D
	for <lkcd@oss.sgi.com>; Thu,  8 Feb 2001 13:22:18 -0500 (EST)
Received: (from nava@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id KAA24813; Thu, 8 Feb 2001 10:23:11 -0800 (PST)
From:   Nava Navaruparajah <nava@core.rose.hp.com>
Message-Id: <200102081823.KAA24813@core.rose.hp.com>
Subject: LKCD installation problem
To:     lkcd@oss.sgi.com
Date:   Thu, 08 Feb 2001 10:23:11 PST
Cc:     nava@core.rose.hp.com
X-Mailer: Elm [revision: 212.4]
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Hi,

  I am trying to install LKCD on my Redhat 6.2 server system and
running into some problems. I downloaded all the files as specified
in README for 3.1 version in current directory. Then I did the following,

1. Applied the rpm by doing,
   rpm -i lkcdutils-1.0-1.i386.rpm
2. Tried to apply patch for raw I/O by doing patch coomand as following,

[root@webside /root]# patch -p1 < raw-2.2.17.diff
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- linux-2.2.17.raw/drivers/char/Makefile.~1~ Mon Sep  4 18:39:17 2000
|+++ linux-2.2.17.raw/drivers/char/Makefile     Wed Oct  4 18:49:06 2000
--------------------------
File to patch: 


When I try to apply the patch, the above message is keep coming
and I don't know how to proceed. Am I missing any other rpm
package for raw here ?

I would apprciate your help.

Thanks,
Nava

From owner-lkcd@oss.sgi.com Thu Feb  8 10:36:36 2001
Received:  by oss.sgi.com id <S553669AbRBHSg0>;
	Thu, 8 Feb 2001 10:36:26 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:3333 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S553652AbRBHSgG>;
	Thu, 8 Feb 2001 10:36:06 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id apfpaaaa for <lkcd@oss.sgi.com>; Thu, 8 Feb 2001 10:30:46 -0800
Message-ID: <3A82E86E.BCF4C77B@alacritech.com>
Date:   Thu, 08 Feb 2001 10:41:50 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Nava Navaruparajah <nava@core.rose.hp.com>
CC:     lkcd@oss.sgi.com
Subject: Re: LKCD installation problem
References: <200102081823.KAA24813@core.rose.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Hi, Nava.  It looks like you're trying to patch your
kernel tree out of your /root directory (based on the
path in your command line).

You'll need to have the latest kernel tree on your system,
which should be located in /usr/src/linux.  If you've built
your own custom kernel, it'll be wherever you have your
kernel sources.

Traditionally, /usr/src/linux-<version>, where <version> might
be 2.2.16 or 2.2.17, etc., would be the right directory, and
/usr/src/linux is a symbolic link to that directory.

Assuming you:

	cd /usr/src/linux
	/bin/pwd

This will tell you the directory you are in, and will help you
know which kernel patch to use.  Assuming you're using 2.2.17,
based on your example below, I'll assume you are in the directory
/usr/src/linux-2.2.17.  If you are, you should then see a number
of files and directories, like 'net', 'kernel', 'mm', etc.  If
you don't, you aren't at the top of a kernel source tree.  And
if you aren't, you'll need a fully populated kernel source tree
to patch your kernel.

If you do have a full kernel source tree, the 'patch -p1'
command should work great.  If all of the above is done and
works, and you have a full kernel tree, let me know where you
got your kernel image from, and I'll test it out myself.

For more information on patching kernels, please see:

	http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html

See chapter 6 which discusses patching kernels.

I hope this helps you, if not, let me know.

Thanks!

--Matt

Nava Navaruparajah wrote:
> 
> Hi,
> 
>   I am trying to install LKCD on my Redhat 6.2 server system and
> running into some problems. I downloaded all the files as specified
> in README for 3.1 version in current directory. Then I did the following,
> 
> 1. Applied the rpm by doing,
>    rpm -i lkcdutils-1.0-1.i386.rpm
> 2. Tried to apply patch for raw I/O by doing patch coomand as following,
> 
> [root@webside /root]# patch -p1 < raw-2.2.17.diff
> can't find file to patch at input line 3
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |--- linux-2.2.17.raw/drivers/char/Makefile.~1~ Mon Sep  4 18:39:17 2000
> |+++ linux-2.2.17.raw/drivers/char/Makefile     Wed Oct  4 18:49:06 2000
> --------------------------
> File to patch:
> 
> When I try to apply the patch, the above message is keep coming
> and I don't know how to proceed. Am I missing any other rpm
> package for raw here ?
> 
> I would apprciate your help.
> 
> Thanks,
> Nava

From owner-lkcd@oss.sgi.com Fri Feb  9 13:58:19 2001
Received:  by oss.sgi.com id <S553686AbRBIV57>;
	Fri, 9 Feb 2001 13:57:59 -0800
Received: from mg01.austin.ibm.com ([192.35.232.18]:40701 "EHLO
        mailgate1.austin.ibm.com") by oss.sgi.com with ESMTP
	id <S553661AbRBIV5j>; Fri, 9 Feb 2001 13:57:39 -0800
Received: from austin.ibm.com (netmail.austin.ibm.com [9.53.250.98])
	by mailgate1.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA48288;
	Fri, 9 Feb 2001 16:00:50 -0600
Received: from craft.austin.ibm.com (craft.austin.ibm.com [9.53.145.12])
	by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA41270;
	Fri, 9 Feb 2001 15:57:17 -0600
Received: (from dcraft@localhost) by craft.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id PAA39608; Fri, 9 Feb 2001 15:57:17 -0600
From:   Dave Craft <dcraft@austin.ibm.com>
Message-Id: <200102092157.PAA39608@craft.austin.ibm.com>
Subject: Re: LKCD 3.1 Tree Available
To:     yakker@alacritech.com (Matt D. Robinson)
Date:   Fri, 9 Feb 2001 15:57:16 -0600 (CST)
Cc:     lkcd@oss.sgi.com
In-Reply-To: <3A820821.AF81D1B4@alacritech.com> from "Matt D. Robinson" at Feb 07, 2001 06:44:49 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing


	I know these things are easily figured out by people
	but the rc.sysinit-redhat70.patch is slightly wrong in
	case anyone relied on it.

	This...

 action "Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs,proc+
+if [ -x /sbin/vmdump ] ; then

	Should be this...

 action "Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs,proc
+
+if [ -x /sbin/vmdump ] ; then

	Otherwise patch says its malformed.

	dave

>
>I've made the 3.1 tree, including the latest 2.4 patches (2.4.0
>and 2.4.1) as well as the latest lkcdutils RPM fully available
>to those that want to download them.  I've put them through our
>basic set of tests (crash, reboot, crash, reboot, repeat until
>really, really tired).  Let us know of any problems you have
>with them, and we'll try to fix things ASAP.  Be sure you use
>the latest 'lkcdutils' RPM with the latest crash dump patches.
>
>Thanks to everyone for their patience.  The next revision will
>include some of the patches from the community (particularly for
>the page typing changes).
>
>Download from:
>
>	ftp://oss.sgi.com/projects/lkcd/download/current/
>
>And of course, as always, feedback (good or bad) is greatly
>appreciated.
>
>--Matt
>


-- 
	--------- Opinions are mine and not IBM's ----------
	Mail : dave@austin.ibm.com	Phone : 512-838-8248		
	            I am Jack's email closing

From owner-lkcd@oss.sgi.com Mon Feb 12 22:24:43 2001
Received:  by oss.sgi.com id <S553911AbRBMGYY>;
	Mon, 12 Feb 2001 22:24:24 -0800
Received: from dnai-216-15-110-218.cust.dnai.com ([216.15.110.218]:60066 "EHLO
        mail.3pardata.com") by oss.sgi.com with ESMTP id <S553901AbRBMGYD>;
	Mon, 12 Feb 2001 22:24:03 -0800
Received: from postal.3pardata.com (3pardata.com [192.168.1.19])
	by mail.3pardata.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22560
	for <lkcd@oss.sgi.com>; Mon, 12 Feb 2001 22:23:57 -0800 (PST)
Received: from amatiel2 (dhcp-001-200.3pardata.com [192.168.1.200]) by postal.3pardata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id C40J7PM6; Mon, 12 Feb 2001 22:23:58 -0800
Message-ID: <07b401c0958e$25f48390$c801a8c0@3pardata.com>
From:   "Guy Edjlali" <edj@3pardata.com>
To:     <lkcd@oss.sgi.com>
Subject: lkcd and kdb ? 
Date:   Mon, 12 Feb 2001 23:25:31 -0800
Organization: 3pardata
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Hello,

I was trying to run a 2.4.0 kernel with lkcd and kdb.
Has anyone tryed this? The stack for the process that
crashed the kernel (crashnow) is empty.

I modified the die function in traps.c:

void die(const char * str, struct pt_regs * regs, long err)
{
 unsigned long flags;
 console_verbose();
#if defined(CONFIG_KDB)
 (void) callout_dbfunc(&dblist_die, regs, err, -1, (void *)str);
#endif
 spin_lock_irqsave(&die_lock, flags);
#ifdef CONFIG_VMDUMP
#ifdef __SMP__
 smp_send_stop();
#endif
#endif
 printk("%s: %04lx\n", str, err & 0xffff);
 show_registers(regs);
#ifdef CONFIG_VMDUMP
 dump_execute((char *)str, regs);
#else
#if defined(CONFIG_VMDUMP_MODULE)
 if (dump_function_ptr) {
  dump_function_ptr((char *)str, regs);
 }
#endif
#endif
 spin_unlock_irqrestore(&die_lock, flags);
 do_exit(SIGSEGV);
}

Any suggestion will be welcome.
Thanks

- Guy


>> task
    ADDR    UID    PID   PPID  STATE     FLAGS  NAME
============================================================================
===
c03e2000      0      0      0      0         0  swapper
c5472000      0      1      1      1       100  init
c5466000      0      2      2      1        40  keventd
c54fc000      0      3      3      1       840  kswapd
c54fa000      0      4      4      1       840  kreclaimd
c54f8000      0      5      5      1        40  bdflush
c54f6000      0      6      6      1        40  kupdate
c54be000      0      7      7      1        40  mdrecoveryd
cf866000      1    344    344      1       140  portmap
cf7ac000      0    366    366      1       140  rpc.statd
cf6ca000      0    383    383      1       140  ypbind
cf86c000      0    389    389      1       140  ypbind
cf676000      0    442    442      1        40  automount
cf5cc000      0    447    447      1        40  automount
cf668000      0    449    449      1        40  automount
cf5bc000      0    503    503      1       140  syslogd
cf586000      0    512    512      1       140  klogd
cf42a000     99    526    526      1       140  identd
cf570000     99    530    530      1        40  identd
cf53a000     99    531    531      1        40  identd
cf58c000     99    532    532      1        40  identd
cf57c000     99    533    533      1        40  identd
cf3ec000      0    544    544      1        40  atd
cf3ae000      0    558    558      1        40  crond
cf342000      0    576    576      1       140  inetd
cf36c000      0    590    590      1       140  lpd
cf27c000      0    638    638      1       140  sendmail
cec7a000     43    727    727      1        40  xfs
cfda6000      0    767    767      1       100  mingetty
cec4a000      0    768    768      1       100  mingetty
cec60000      0    769    769      1       100  mingetty
cf258000      0    770    770      1       100  mingetty
ce986000      0    771    771      1       100  mingetty
cec4c000      0    772    772      1       100  mingetty
ce9ac000      0    775    775      1       100  in.rlogind
ce6ca000      0    778    778      1        40  rpciod
ce6c2000      0    779    779      1        40  lockd
ce706000      0    780    780      1       100  login
ce65e000   1044    781    781      1       100  csh
ce50a000   1044    811    811      0         0  crashnow
============================================================================
===
40 active task structs found
>> t ce65e000
================================================================
STACK TRACE FOR TASK: 0xce65e000(csh)

 0 schedule+1054 [0xc011708a]
 1 sys_rt_sigsuspend+220 [0xc010931c]
 2 system_call+44 [0xc010a1a0]
================================================================
>> t ce50a000
================================================================
STACK TRACE FOR TASK: 0xce50a000(crashnow)

================================================================
- Guy Edjlali
  3PARdata, Inc.                  email: guy.edjlali@3pardata.com
  4245 Technology Drive      phone: 510-354-6818
  Fremont, CA 94538


From owner-lkcd@oss.sgi.com Tue Feb 13 09:58:08 2001
Received:  by oss.sgi.com id <S553943AbRBMR5r>;
	Tue, 13 Feb 2001 09:57:47 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:63760 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S553940AbRBMR5m>;
	Tue, 13 Feb 2001 09:57:42 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id mclpaaaa for <lkcd@oss.sgi.com>; Tue, 13 Feb 2001 09:52:15 -0800
Message-ID: <3A8976EC.3E523674@alacritech.com>
Date:   Tue, 13 Feb 2001 10:03:24 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Guy Edjlali <edj@3pardata.com>
CC:     lkcd@oss.sgi.com
Subject: Re: lkcd and kdb ?
References: <07b401c0958e$25f48390$c801a8c0@3pardata.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Guy Edjlali wrote:
> 
> Hello,
> 
> I was trying to run a 2.4.0 kernel with lkcd and kdb.
> Has anyone tryed this? The stack for the process that
> crashed the kernel (crashnow) is empty.

A couple of questions:

- Did the system die due to a panic() or Oops?
- Did you modify any of the incoming registers with kdb?
- Can we get a look at the crash dump to validate it?

Thanks, Guy.

--Matt

> 
> I modified the die function in traps.c:
> 
> void die(const char * str, struct pt_regs * regs, long err)
> {
>  unsigned long flags;
>  console_verbose();
> #if defined(CONFIG_KDB)
>  (void) callout_dbfunc(&dblist_die, regs, err, -1, (void *)str);
> #endif
>  spin_lock_irqsave(&die_lock, flags);
> #ifdef CONFIG_VMDUMP
> #ifdef __SMP__
>  smp_send_stop();
> #endif
> #endif
>  printk("%s: %04lx\n", str, err & 0xffff);
>  show_registers(regs);
> #ifdef CONFIG_VMDUMP
>  dump_execute((char *)str, regs);
> #else
> #if defined(CONFIG_VMDUMP_MODULE)
>  if (dump_function_ptr) {
>   dump_function_ptr((char *)str, regs);
>  }
> #endif
> #endif
>  spin_unlock_irqrestore(&die_lock, flags);
>  do_exit(SIGSEGV);
> }
> 
> Any suggestion will be welcome.
> Thanks
> 
> - Guy
> 
> >> task
>     ADDR    UID    PID   PPID  STATE     FLAGS  NAME
> ============================================================================
> ===
> c03e2000      0      0      0      0         0  swapper
> c5472000      0      1      1      1       100  init
> c5466000      0      2      2      1        40  keventd
> c54fc000      0      3      3      1       840  kswapd
> c54fa000      0      4      4      1       840  kreclaimd
> c54f8000      0      5      5      1        40  bdflush
> c54f6000      0      6      6      1        40  kupdate
> c54be000      0      7      7      1        40  mdrecoveryd
> cf866000      1    344    344      1       140  portmap
> cf7ac000      0    366    366      1       140  rpc.statd
> cf6ca000      0    383    383      1       140  ypbind
> cf86c000      0    389    389      1       140  ypbind
> cf676000      0    442    442      1        40  automount
> cf5cc000      0    447    447      1        40  automount
> cf668000      0    449    449      1        40  automount
> cf5bc000      0    503    503      1       140  syslogd
> cf586000      0    512    512      1       140  klogd
> cf42a000     99    526    526      1       140  identd
> cf570000     99    530    530      1        40  identd
> cf53a000     99    531    531      1        40  identd
> cf58c000     99    532    532      1        40  identd
> cf57c000     99    533    533      1        40  identd
> cf3ec000      0    544    544      1        40  atd
> cf3ae000      0    558    558      1        40  crond
> cf342000      0    576    576      1       140  inetd
> cf36c000      0    590    590      1       140  lpd
> cf27c000      0    638    638      1       140  sendmail
> cec7a000     43    727    727      1        40  xfs
> cfda6000      0    767    767      1       100  mingetty
> cec4a000      0    768    768      1       100  mingetty
> cec60000      0    769    769      1       100  mingetty
> cf258000      0    770    770      1       100  mingetty
> ce986000      0    771    771      1       100  mingetty
> cec4c000      0    772    772      1       100  mingetty
> ce9ac000      0    775    775      1       100  in.rlogind
> ce6ca000      0    778    778      1        40  rpciod
> ce6c2000      0    779    779      1        40  lockd
> ce706000      0    780    780      1       100  login
> ce65e000   1044    781    781      1       100  csh
> ce50a000   1044    811    811      0         0  crashnow
> ============================================================================
> ===
> 40 active task structs found
> >> t ce65e000
> ================================================================
> STACK TRACE FOR TASK: 0xce65e000(csh)
> 
>  0 schedule+1054 [0xc011708a]
>  1 sys_rt_sigsuspend+220 [0xc010931c]
>  2 system_call+44 [0xc010a1a0]
> ================================================================
> >> t ce50a000
> ================================================================
> STACK TRACE FOR TASK: 0xce50a000(crashnow)
> 
> ================================================================
> - Guy Edjlali
>   3PARdata, Inc.                  email: guy.edjlali@3pardata.com
>   4245 Technology Drive      phone: 510-354-6818
>   Fremont, CA 94538

From owner-lkcd@oss.sgi.com Sun Feb 18 00:12:29 2001
Received:  by oss.sgi.com id <S553762AbRBRIML>;
	Sun, 18 Feb 2001 00:12:11 -0800
Received: from hermes.mixx.net ([212.84.196.2]:22277 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553716AbRBRIMF>;
	Sun, 18 Feb 2001 00:12:05 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 68E58F804
	for <lkcd@oss.sgi.com>; Sun, 18 Feb 2001 09:12:03 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 1A25A2CA6F; Sun, 18 Feb 2001 09:12:02 +0100 (CET)
From:   Thomas Graichen <news-innominate.bln.list.sgi.lkcd@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.bln.list.sgi.lkcd
Subject: Re: lkcd and kdb ?
Date:   18 Feb 2001 08:12:02 GMT
Organization: innominate AG, Berlin, Germany
Lines:  106
Distribution: local
Message-ID: <news2mail-96o04i$goj$2@mate.bln.innominate.de>
References: <07b401c0958e$25f48390$c801a8c0@3pardata.com> <3A8976EC.3E523674@alacritech.com>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 982483922 17171 10.0.0.31 (18 Feb 2001 08:12:02 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686))
To:     lkcd@oss.sgi.com
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

"Matt D. Robinson" <yakker@alacritech.com> wrote:
> Guy Edjlali wrote:
>> 
>> Hello,
>> 
>> I was trying to run a 2.4.0 kernel with lkcd and kdb.
>> Has anyone tryed this? The stack for the process that
>> crashed the kernel (crashnow) is empty.

> A couple of questions:

> - Did the system die due to a panic() or Oops?
> - Did you modify any of the incoming registers with kdb?
> - Can we get a look at the crash dump to validate it?

i did the same here and was wondering about the missing stack traces
too ... i always used a simple module calling panic() for testing
but yesterday i had a real crash and was able to get a stacktrace
- maybe the reason is the "artificial" nature of the crashing
method with a panic module?

ok - but the reason why i write this here is that i also had another
problem: the system crashed, wrote the crashdump but on trying to
analyse it on bootup it hung on the process table which you can
see very good in the analysis output from that bootup:

  c1790000      0   2635      1      1         0  sa1
  c20e2000      0   2637   2635      1         0  sadc
  c22d6000      0   2640   1344      1         0  sh
  c29d6000     26   2655      1      0        40  postmaster
  c22d6000      0   2640   1344      1         0  sh
  c29d6000     26   2655      1      0        40  postmaster
  c22d6000      0   2640   1344      1         0  sh
  c29d6000     26   2655      1      0        40  postmaster
  c22d6000      0   2640   1344      1         0  sh
  ...

any idea what happened here? ... maybe some more relevant output
from the analysis:

================
COREFILE SUMMARY
================

    The system died due to a software failure.

===================
UTSNAME INFORMATION
===================

   sysname : Linux
  nodename : oxygen.bln.innominate.de
   release : 2.4.1-XFS
   version : #4 SMP Sat Feb 17 11:13:08 CET 2001
   machine : i586
domainname : 

===============
LOG BUFFER DUMP
===============
...
<2>EXT2-fs error (device ide0(3,6)): ext2_free_blocks: Freeing blocks not in datazone - block = 85861, count = 1
    <2>EXT2-fs error (device ide0(3,6)): free_inode: reserved inode or nonexistent inode
    <4>kernel BUG at inode.c:911!
    <4>invalid operand: 0000
    <4>CPU:    0
    <4>EIP:    0010:[<c014c44f>]
    <4>EFLAGS: 00210286
    <4>eax: 0000001b   ebx: c36d74a0   ecx: 00000001   edx: 00000001
    <4>esi: c040d5e0   edi: c200fda0   ebp: c29d7f50   esp: c29d7f3c
    <4>ds: 0018   es: 0018   ss: 0018
    <4>Process postmaster (pid: 2655, stackpage=c29d7000)
    <4>Stack: c0309f29 c0309fe9 0000038f c2282d60 c36d74a0 c29d7f64 c014ab76 c36d74a0 
    <4>       00000000 c29d6000 c29d7f80 c0143ad7 c2282d60 c2282d60 c30fa000 c29d7fa0 
    <4>       c200fe10 c29d7fbc c0143ba8 c200fda0 c2282d60 c29d6000 081f69d0 081f6800 
    <4>Call Trace: [<c014ab76>] [<c0143ad7>] [<c0143ba8>] [<c0109197>] 
    <4>
    <4>Code: 0f 0b 83 c4 0c eb 7a 39 1b 74 3e f6 83 ec 00 00 00 07 75 26 
    <6>Dumping to device 0x302 [ide0(3,2)] ...
    <4>Writing dump header ...
    <4>Writing dump pages ...<2>EXT2-fs error (device ide0(3,6)): ext2_new_inode: reserved inode or inode > inodes count - block_group = 4,inode=60292
    <2>EXT2-fs error (device ide0(3,6)): ext2_find_entry: bad entry in directory #30146: inode out of bounds - offset=68, inode=30217, rec_len=20, name_len=10
    ng blocks not in datazone - block = 89400, count = 16
    <2>EXT2-fs error (device ide0(3,6)): ext2_free_blocks: Freeing blocks not in datazone - block = 89440, count = 16
    <2>EXT2-fs error (device ide0(3,6)): ext2_free_blocks: Freeing blocks not in datazone - block = 89464, count = 16
    <2>EXT2-fs error (device ide0(3,6)): ext2_free_blocks: Freeing blocks not in datazone - block = 89488, count = 16
    <2>EXT2-fs error (device ide0(3,6)): ext2_free_blocks: Freeing blocks not in datazone - block = 89512, count = 16
    <2>EXT2-fs error (device ide0(3,6)): ext2_free_blocks: Freeing blocks not in datazone - block = 89544, count = 16
    <2>EXT2-f


====================
CURRENT SYSTEM TASKS
...

a lot of thanks in advance

t

p.s.: i still have the crashdump here if there is interest in it

-- 
thomas.graichen@innominate.com
                                                         innominate AG
                                                  the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-lkcd@oss.sgi.com Sun Feb 18 00:15:10 2001
Received:  by oss.sgi.com id <S553877AbRBRIPA>;
	Sun, 18 Feb 2001 00:15:00 -0800
Received: from hermes.mixx.net ([212.84.196.2]:22789 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553757AbRBRIOo>;
	Sun, 18 Feb 2001 00:14:44 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id BD8FCF804
	for <lkcd@oss.sgi.com>; Sun, 18 Feb 2001 09:14:41 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 7C0B02CA6F; Sun, 18 Feb 2001 09:14:41 +0100 (CET)
From:   Thomas Graichen <news-innominate.bln.list.sgi.lkcd@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.bln.list.sgi.lkcd
Subject: Re: lkcd and kdb ?
Date:   18 Feb 2001 08:14:41 GMT
Organization: innominate AG, Berlin, Germany
Lines:  22
Distribution: local
Message-ID: <news2mail-96o09h$goj$3@mate.bln.innominate.de>
References: <07b401c0958e$25f48390$c801a8c0@3pardata.com> <3A8976EC.3E523674@alacritech.com> <96o04i$goj$2@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 982484081 17171 10.0.0.31 (18 Feb 2001 08:14:41 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686))
To:     lkcd@oss.sgi.com
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Thomas Graichen <graichen@innominate.de> wrote:
> ...
>    sysname : Linux
>   nodename : oxygen.bln.innominate.de
>    release : 2.4.1-XFS
>    version : #4 SMP Sat Feb 17 11:13:08 CET 2001
>    machine : i586

two more things:

* the kernel is compiled SMP but the machine is a up machine (just that
  the uname output does not mislead you)
* after a reboot of the crashdumpsaving-hanging system i was able
  to load the crash into lcrash and for instance do an "bt"

t

-- 
thomas.graichen@innominate.com
                                                         innominate AG
                                                  the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-lkcd@oss.sgi.com Sun Feb 18 12:56:54 2001
Received:  by oss.sgi.com id <S553793AbRBRU4o>;
	Sun, 18 Feb 2001 12:56:44 -0800
Received: from w032.z064001165.sjc-ca.dsl.cnc.net ([64.1.165.32]:34322 "EHLO
        www.aparity.com") by oss.sgi.com with ESMTP id <S553788AbRBRU41>;
	Sun, 18 Feb 2001 12:56:27 -0800
Received: from alacritech.com (localhost [127.0.0.1])
	by www.aparity.com (8.9.3/8.9.3) with ESMTP id NAA06278;
	Sun, 18 Feb 2001 13:06:30 -0800
Message-ID: <3A903956.11DDB178@alacritech.com>
Date:   Sun, 18 Feb 2001 13:06:30 -0800
From:   "Matt D. Robinson" <yakker@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     lkcd@oss.sgi.com
Subject: Re: lkcd and kdb ?
References: <07b401c0958e$25f48390$c801a8c0@3pardata.com> <3A8976EC.3E523674@alacritech.com> <96o04i$goj$2@mate.bln.innominate.de> <news2mail-96o09h$goj$3@mate.bln.innominate.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Just an FYI ... Guy was a great help in finding the reason
for the failed panic() cases.  As it turns out, I was using
some older macros for SMP and frame pointers.  Those have
now been corrected, and you can get the latest patches:

	http://oss.sgi.com/projects/lkcd/download/current

The new tree is 3.1.1.  Let me know if this corrects your
problem, Thomas.  It should help greatly.

--Matt

Thomas Graichen wrote:
> 
> Thomas Graichen <graichen@innominate.de> wrote:
> > ...
> >    sysname : Linux
> >   nodename : oxygen.bln.innominate.de
> >    release : 2.4.1-XFS
> >    version : #4 SMP Sat Feb 17 11:13:08 CET 2001
> >    machine : i586
> 
> two more things:
> 
> * the kernel is compiled SMP but the machine is a up machine (just that
>   the uname output does not mislead you)
> * after a reboot of the crashdumpsaving-hanging system i was able
>   to load the crash into lcrash and for instance do an "bt"
> 
> t
> 
> --
> thomas.graichen@innominate.com
>                                                          innominate AG
>                                                   the linux architects
> tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-lkcd@oss.sgi.com Wed Feb 21 11:28:06 2001
Received:  by oss.sgi.com id <S553955AbRBUT1r>;
	Wed, 21 Feb 2001 11:27:47 -0800
Received: from [65.193.106.66] ([65.193.106.66]:20500 "EHLO
        XCHANGESERVER.storigen.com") by oss.sgi.com with ESMTP
	id <S553842AbRBUT1q>; Wed, 21 Feb 2001 11:27:46 -0800
Received: from storigen.com (vmlager1.storigen.com [192.168.0.68]) by XCHANGESERVER.storigen.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 1LAWJBXG; Wed, 21 Feb 2001 14:27:34 -0500
Message-ID: <3A9414A6.D6844AC8@storigen.com>
Date:   Wed, 21 Feb 2001 14:19:03 -0500
From:   Larry Cohen <Larry.Cohen@storigen.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     lkcd@oss.sgi.com
Subject: Cant seem to create crash dumps .... help
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Hi,  I'm pretty sure I have installed the lkcd patch and utilities ok
but when I the system panics it
will hang when trying to write out the dump to the swap device.
My disks are IDE not SCSI is this a problem?
Any other thoughts?

Thanks,
Larry Cohen



From owner-lkcd@oss.sgi.com Wed Feb 21 12:03:36 2001
Received:  by oss.sgi.com id <S553973AbRBUUD1>;
	Wed, 21 Feb 2001 12:03:27 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:37637 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S553970AbRBUUDK>;
	Wed, 21 Feb 2001 12:03:10 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id cetpaaaa for <lkcd@oss.sgi.com>; Wed, 21 Feb 2001 11:57:37 -0800
Message-ID: <3A942054.683E2237@alacritech.com>
Date:   Wed, 21 Feb 2001 12:08:52 -0800
From:   "Matt D. Robinson" <matt@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Larry Cohen <Larry.Cohen@storigen.com>
CC:     lkcd@oss.sgi.com
Subject: Re: Cant seem to create crash dumps .... help
References: <3A9414A6.D6844AC8@storigen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Larry Cohen wrote:
> 
> Hi,  I'm pretty sure I have installed the lkcd patch and utilities ok
> but when I the system panics it
> will hang when trying to write out the dump to the swap device.
> My disks are IDE not SCSI is this a problem?
> Any other thoughts?
> 
> Thanks,
> Larry Cohen

Do you have the output from the console?  It sounds like you
have everything configured correctly.  If you run "/sbin/vmdump config",
are the right values showing up in /proc/sys/vmdump?  IDE and SCSI
disks should work with the 3.1.1 patches.

Typically there are problems when the right devices aren't configured
in /proc/sys/vmdump (which are updated when "/sbin/vmdump config" is
run), or /proc/sys/kernel/panic is zero, which means the system won't
reset after taking a dump.

Note that you have to modify your /etc/rc.d/rc.sysinit (or like script
depending on the Linux variant you are running) to add the /sbin/vmdump
calls.  Check out the README.

If you've done all this and it still fails, send me the console output,
along with your hardware specifications, and we'll see what we can do
about getting to the bottom of your problem.  Thanks, Larry.

--Matt

From owner-lkcd@oss.sgi.com Wed Feb 21 13:44:56 2001
Received:  by oss.sgi.com id <S553968AbRBUVoq>;
	Wed, 21 Feb 2001 13:44:46 -0800
Received: from [65.193.106.66] ([65.193.106.66]:28177 "EHLO
        XCHANGESERVER.storigen.com") by oss.sgi.com with ESMTP
	id <S553964AbRBUVoc>; Wed, 21 Feb 2001 13:44:32 -0800
Received: from storigen.com (vmlager1.storigen.com [192.168.0.68]) by XCHANGESERVER.storigen.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 1LAWJBXW; Wed, 21 Feb 2001 14:58:33 -0500
Message-ID: <3A941BE3.CFF9DE87@storigen.com>
Date:   Wed, 21 Feb 2001 14:49:55 -0500
From:   Larry Cohen <Larry.Cohen@storigen.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     lkcd@oss.sgi.com
Subject: more info on my hung crash dump ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

My prior mail stated that writing the core dump hung.
I just wanted to add that I was using a 2.4.0 kernel and this is an
Intel machine.
Thanks for any help,
Larry Cohen


From owner-lkcd@oss.sgi.com Tue Feb 27 16:06:35 2001
Received:  by oss.sgi.com id <S553767AbRB1AG0>;
	Tue, 27 Feb 2001 16:06:26 -0800
Received: from gateway.sequent.com ([192.148.1.10]:14469 "EHLO
        gateway.sequent.com") by oss.sgi.com with ESMTP id <S553761AbRB1AGN>;
	Tue, 27 Feb 2001 16:06:13 -0800
Received: from crg8.sequent.com (crg8.sequent.com [138.95.19.9])
	by gateway.sequent.com (8.9.3/8.8.5) with ESMTP id QAA02780
	for <lkcd@oss.sgi.com>; Tue, 27 Feb 2001 16:00:38 -0800 (PST)
Received: from sequent.com (w-93d233.rhe.sequent.com [138.95.93.233])
	by crg8.sequent.com (8.8.5/8.8.5/token.aware-1.2) with ESMTP id QAA04698
	for <lkcd@oss.sgi.com>; Tue, 27 Feb 2001 16:05:50 -0800 (PST)
Message-ID: <3A9C40B3.C4B0B73@sequent.com>
Date:   Tue, 27 Feb 2001 16:05:07 -0800
From:   Mark Price <mprice@sequent.com>
Organization: IBM Numa-Q
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     lkcd@oss.sgi.com
Subject: lcrash dumps core with SIGSEGV.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing


Hi Folks,

I recompiled my kernel (2.2.18) with the rawio and lckd patches,
installed
the lckd utils rpm, and rebooted.

I can panic the system and the vmdump successfully retrieves the dump
from my swap partition.

However when I try and run lcrash on either the live system or against
the dump it core dumps with a SIGSEGV.

Nothing useful in the gdb output, so I grabbed the source and recompiled
with -g flag, and made sure it wasn't being stripped. Still cores, and
the debug output still gives me no clues.

[root@w-mprice2 /root]# gdb --core=./core --exec=/sbin/lcrash
--symbols=/sbin/lcrash
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `lcrash'.
Program terminated with signal 11, Segmentation fault.
#0  0x0 in ?? ()
(gdb) bt
#0  0x0 in ?? ()
(gdb) [root@w-mprice2 /root]# 
[root@w-mprice2 /root]# exit

So looks like lcrash stomped all over its own stack.

truss gave me the following output (see below), but without a stack to
give me an
idea of where in the code we are I'm not sure it helps.

It looks like it is in the process of reading the Kerntypes file.

Has anyone here experienced these symptoms, can you offer any advice?

Cheers, Mark.

root wrote:
> 
> execve("/sbin/lcrash", ["lcrash"], [/* 22 vars */]) = 0
> fcntl64(0, F_GETFD)                     = -1 ENOSYS (Function not implemented)
> fcntl(0, F_GETFD)                       = 0
> fcntl(1, F_GETFD)                       = 0
> fcntl(2, F_GETFD)                       = 0
> _sysctl({{CTL_KERN, KERN_OSRELEASE}, 2, "2.2.18", 6, NULL, 0}) = 0
> geteuid32()                             = -1 ENOSYS (Function not implemented)
> geteuid()                               = 0
> getuid()                                = 0
> getegid()                               = 0
> getgid()                                = 0
> brk(0)                                  = 0x8174b7c
> brk(0x8174b9c)                          = 0x8174b9c
> brk(0x8175000)                          = 0x8175000
> getpid()                                = 2305
> fstat64(1, 0xbffff280)                  = -1 ENOSYS (Function not implemented)
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 1), ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000
> ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> write(1, "map = /boot/System.map, vmdump ="..., 89) = 89
> write(1, "\n", 1)                       = 1
> write(1, "Please wait...", 14)          = 14
> rt_sigaction(SIGINT, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> rt_sigaction(SIGPIPE, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> rt_sigaction(SIGABRT, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> rt_sigaction(SIGSEGV, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> rt_sigaction(SIGBUS, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> open("/dev/mem", O_RDONLY)              = 4
> brk(0x8176000)                          = 0x8176000
> open("/boot/System.map", O_RDONLY)      = 5
> fstat(5, {st_mode=S_IFREG|0644, st_size=216270, ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000
> read(5, "c0100000 A _text\nc0100000 t star"..., 4096) = 4096
> write(2, ".", 1)                        = 1
> brk(0x8177000)                          = 0x8177000
> brk(0x8178000)                          = 0x8178000
> read(5, "16_interrupt\nc0108da0 t IRQ0x17_"..., 4096) = 4096
> brk(0x8179000)                          = 0x8179000
> brk(0x817a000)                          = 0x817a000
> read(5, "rrupt\nc01093ac t IRQ0xa4_interru"..., 4096) = 4096
> brk(0x817b000)                          = 0x817b000
> brk(0x817c000)                          = 0x817c000
> read(5, "nfig_dword\nc010de1c t pci_conf2_"..., 4096) = 4096
> brk(0x817d000)                          = 0x817d000
> brk(0x817e000)                          = 0x817e000
> brk(0x817f000)                          = 0x817f000
> read(5, "dma\nc0113900 T free_uid\nc0113970"..., 4096) = 4096
> brk(0x8180000)                          = 0x8180000
> brk(0x8181000)                          = 0x8181000
> read(5, "550 t do_no_page\nc011d644 T hand"..., 4096) = 4096
> brk(0x8182000)                          = 0x8182000
> brk(0x8183000)                          = 0x8183000
> brk(0x8184000)                          = 0x8184000
> read(5, "94 T kdevname\nc0128fbc T bdevnam"..., 4096) = 4096
> brk(0x8185000)                          = 0x8185000
> write(2, ".", 1)                        = 1
> brk(0x8186000)                          = 0x8186000
> read(5, "_select\nc0132ffc t do_poll\nc0133"..., 4096) = 4096
> brk(0x8187000)                          = 0x8187000
> brk(0x8188000)                          = 0x8188000
> brk(0x8189000)                          = 0x8189000
> read(5, "ext2_permission\nc013e3b4 T ext2_"..., 4096) = 4096
> brk(0x818a000)                          = 0x818a000
> brk(0x818b000)                          = 0x818b000
> read(5, " T de_put\nc014bca4 t proc_put_in"..., 4096) = 4096
> brk(0x818c000)                          = 0x818c000
> brk(0x818d000)                          = 0x818d000
> read(5, "c\nc0155b78 t nfs_find_read\nc0155"..., 4096) = 4096
> brk(0x818e000)                          = 0x818e000
> brk(0x818f000)                          = 0x818f000
> brk(0x8190000)                          = 0x8190000
> read(5, "c_symlink\nc015dbb8 t nfs3_proc_m"..., 4096) = 4096
> brk(0x8191000)                          = 0x8191000
> brk(0x8192000)                          = 0x8192000
> read(5, "0169370 T nfssvc_encode_readlink"..., 4096) = 4096
> brk(0x8193000)                          = 0x8193000
> brk(0x8194000)                          = 0x8194000
> write(2, ".", 1)                        = 1
> read(5, "t nlmsvc_proc_granted_msg\nc01700"..., 4096) = 4096
> brk(0x8195000)                          = 0x8195000
> brk(0x8196000)                          = 0x8196000
> read(5, "de\nc0174130 t autofs_put_super\nc"..., 4096) = 4096
> brk(0x8197000)                          = 0x8197000
> brk(0x8198000)                          = 0x8198000
> brk(0x8199000)                          = 0x8199000
> read(5, "7a6a8 T dev_getbyhwaddr\nc017a6f4"..., 4096) = 4096
> brk(0x819a000)                          = 0x819a000
> brk(0x819b000)                          = 0x819b000
> read(5, "181d70 t ip_masq_user_info\nc0181"..., 4096) = 4096
> brk(0x819c000)                          = 0x819c000
> brk(0x819d000)                          = 0x819d000
> brk(0x819e000)                          = 0x819e000
> read(5, "8 t tcp_ack\nc018d40c T tcp_timew"..., 4096) = 4096
> brk(0x819f000)                          = 0x819f000
> brk(0x81a0000)                          = 0x81a0000
> read(5, "fa\nc019815c t inet_set_ifa\nc0198"..., 4096) = 4096
> brk(0x81a1000)                          = 0x81a1000
> brk(0x81a2000)                          = 0x81a2000
> read(5, "1a0f0c t packet_create\nc01a1064 "..., 4096) = 4096
> brk(0x81a3000)                          = 0x81a3000
> brk(0x81a4000)                          = 0x81a4000
> write(2, ".", 1)                        = 1
> brk(0x81a5000)                          = 0x81a5000
> read(5, "a8 T svc_release_buffer\nc01a84c4"..., 4096) = 4096
> brk(0x81a6000)                          = 0x81a6000
> brk(0x81a7000)                          = 0x81a7000
> read(5, "ing_dma\nc01b05c0 t set_pio_mode\n"..., 4096) = 4096
> brk(0x81a8000)                          = 0x81a8000
> brk(0x81a9000)                          = 0x81a9000
> read(5, "ary_port_responding\nc01ba97c t c"..., 4096) = 4096
> brk(0x81aa000)                          = 0x81aa000
> brk(0x81ab000)                          = 0x81ab000
> brk(0x81ac000)                          = 0x81ac000
> read(5, "_read_proc\nc01c0ec4 t misc_open\n"..., 4096) = 4096
> brk(0x81ad000)                          = 0x81ad000
> brk(0x81ae000)                          = 0x81ae000
> read(5, "dstate\nc01cb06c T register_leds\n"..., 4096) = 4096
> brk(0x81af000)                          = 0x81af000
> brk(0x81b0000)                          = 0x81b0000
> brk(0x81b1000)                          = 0x81b1000
> read(5, "8 t keyboard_interrupt\nc01d644c "..., 4096) = 4096
> brk(0x81b2000)                          = 0x81b2000
> brk(0x81b3000)                          = 0x81b3000
> write(2, ".", 1)                        = 1
> read(5, " get_pci_list\nc01e3888 T pcibios"..., 4096) = 4096
> brk(0x81b4000)                          = 0x81b4000
> read(5, "02168c7 ? __kstrtab___global_sti"..., 4096) = 4096
> read(5, "c ? __kstrtab_dput\nc0216f01 ? __"..., 4096) = 4096
> read(5, "__kstrtab_disable_hlt\nc0217580 ?"..., 4096) = 4096
> read(5, "ster_cvf_format\nc0217bf0 ? __kst"..., 4096) = 4096
> read(5, "r\nc021829d ? __kstrtab_pneigh_lo"..., 4096) = 4096
> read(5, "ll\nc021891a ? __kstrtab_call_in_"..., 4096) = 4096
> read(5, " __kstrtab_loop_unregister_trans"..., 4096) = 4096
> read(5, "1a418 ? __ksymtab_MCA_bus\nc021a4"..., 4096) = 4096
> read(5, "021a7d8 ? __ksymtab_lookup_dentr"..., 4096) = 4096
> read(5, "lip_buffer_push\nc021ab88 ? __ksy"..., 4096) = 4096
> read(5, "ode\nc021af28 ? __ksymtab_global_"..., 4096) = 4096
> read(5, "1b2c0 ? __ksymtab_sock_getsockop"..., 4096) = 4096
> read(5, "_notifier\nc021b660 ? __ksymtab_u"..., 4096) = 4096
> read(5, "oto\nc021b9d0 ? __ksymtab_xprt_de"..., 4096) = 4096
> read(5, "b_set_selection\nc021bd48 ? __ksy"..., 4096) = 4096
> brk(0x81b5000)                          = 0x81b5000
> read(5, " cpucount\nc021f8c4 d smp_call_fu"..., 4096) = 4096
> brk(0x81b6000)                          = 0x81b6000
> brk(0x81b7000)                          = 0x81b7000
> read(5, "_inode_operations\nc022a000 D def"..., 4096) = 4096
> read(5, "\nc022bb40 d proc_root_ioports\nc0"..., 4096) = 4096
> brk(0x81b8000)                          = 0x81b8000
> read(5, "ion1\nc022e3f0 d nlm_version3\nc02"..., 4096) = 4096
> brk(0x81b9000)                          = 0x81b9000
> brk(0x81ba000)                          = 0x81ba000
> read(5, "c0230990 D tcp_tw_death_row_slot"..., 4096) = 4096
> brk(0x81bb000)                          = 0x81bb000
> read(5, "\nc0232b94 d default_drive_params"..., 4096) = 4096
> read(5, "e0 D plain_map\nc02363e0 D shift_"..., 4096) = 4096
> brk(0x81bc000)                          = 0x81bc000
> brk(0x81bd000)                          = 0x81bd000
> read(5, "0241430 t pcibios_fixup_devices\n"..., 4096) = 4096
> brk(0x81be000)                          = 0x81be000
> brk(0x81bf000)                          = 0x81bf000
> read(5, " T pckbd_init_hw\nc0249498 T aux_"..., 4096) = 4096
> brk(0x81c0000)                          = 0x81c0000
> brk(0x81c1000)                          = 0x81c1000
> read(5, " b temparea.0\nc02796e0 b reply_b"..., 4096) = 4096
> brk(0x81c2000)                          = 0x81c2000
> write(2, ".", 1)                        = 1
> brk(0x81c3000)                          = 0x81c3000
> brk(0x81c4000)                          = 0x81c4000
> read(5, "310 B proc_net\nc0282314 B proc_s"..., 4096) = 3278
> brk(0x81c5000)                          = 0x81c5000
> brk(0x81c6000)                          = 0x81c6000
> read(5, "", 4096)                       = 0
> old_mmap(NULL, 167936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40002000
> write(2, ".", 1)                        = 1
> write(2, ".", 1)                        = 1
> write(2, ".", 1)                        = 1
> write(2, ".", 1)                        = 1
> write(2, ".", 1)                        = 1
> lseek(4, 2221736, SEEK_SET)             = 2221736
> read(4, "\310\343(\300", 4)             = 4
> brk(0x81c8000)                          = 0x81c8000
> open("/boot/Kerntypes", O_RDONLY)       = 6
> fstat(6, {st_mode=S_IFREG|0644, st_size=94920, ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4002b000
> _llseek(6, 0, [0], SEEK_SET)            = 0
> read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0\3\0\1\0\0\0\0\0\0\0"..., 4096) = 4096
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 4096, [4096], SEEK_SET)      = 0
> _llseek(6, 94208, [94208], SEEK_SET)    = 0
> read(6, "omment\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 712
> _llseek(6, 90112, [90112], SEEK_SET)    = 0
> read(6, "0,32;it_prof_value:(0,5),1312,32"..., 4096) = 4096
> read(6, "omment\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 712
> brk(0x81cb000)                          = 0x81cb000
> brk(0x81e0000)                          = 0x81e0000
> _llseek(6, 0, [0], SEEK_SET)            = 0
> read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0\3\0\1\0\0\0\0\0\0\0"..., 4096) = 4096
> read(6, "\0\0\0\0\242\0\0\0\0\0\0\0\303O\0\0\200\0\0\0\0\0\0\0\234"..., 4096) = 4096
> read(6, "\202\0\0\0\0\0\0\0d!\1\0\200\0\0\0\0\0\0\0\242!\1\0\200"..., 4096) = 4096
> read(6, "(10,5)\0int16_t:t(7,31)=(10,4)\0u_"..., 77824) = 77824
> read(6, "0,32;it_prof_value:(0,5),1312,32"..., 4096) = 4096
> brk(0x81e1000)                          = 0x81e1000
> brk(0x81e2000)                          = 0x81e2000
> brk(0x81e3000)                          = 0x81e3000
> brk(0x81e4000)                          = 0x81e4000
> brk(0x81e5000)                          = 0x81e5000
> brk(0x81e6000)                          = 0x81e6000
> brk(0x81e7000)                          = 0x81e7000
> brk(0x81e8000)                          = 0x81e8000
> brk(0x81e9000)                          = 0x81e9000
> brk(0x81ea000)                          = 0x81ea000
> brk(0x81eb000)                          = 0x81eb000
> brk(0x81ec000)                          = 0x81ec000
> brk(0x81ed000)                          = 0x81ed000
> --- SIGSEGV (Segmentation fault) ---
> rt_sigaction(SIGINT, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> rt_sigaction(SIGPIPE, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> rt_sigaction(SIGABRT, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> rt_sigaction(SIGSEGV, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> rt_sigaction(SIGBUS, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> --- SIGSEGV (Segmentation fault) ---
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++

From owner-lkcd@oss.sgi.com Wed Feb 28 16:23:43 2001
Received:  by oss.sgi.com id <S553719AbRCAAXe>;
	Wed, 28 Feb 2001 16:23:34 -0800
Received: from smtp.alacritech.com ([209.10.208.82]:13583 "EHLO
        smtp.alacritech.com") by oss.sgi.com with ESMTP id <S553650AbRCAAXY>;
	Wed, 28 Feb 2001 16:23:24 -0800
Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id reaqaaaa for <lkcd@oss.sgi.com>; Wed, 28 Feb 2001 16:17:34 -0800
Message-ID: <3A9D97CE.2804713C@alacritech.com>
Date:   Wed, 28 Feb 2001 16:29:02 -0800
From:   "Matt D. Robinson" <matt@alacritech.com>
Organization: Alacritech, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Mark Price <mprice@sequent.com>
CC:     lkcd@oss.sgi.com
Subject: Re: lcrash dumps core with SIGSEGV.
References: <3A9C40B3.C4B0B73@sequent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk
Return-Path: <owner-lkcd@oss.sgi.com>
X-Orcpt: rfc822;lkcd-outgoing

Hi, Mark.  I didn't hear from Tom, so I'll chime in.  Did you grab
the latest lkcdutils RPM from the 3.1.1 directory?  In addition,
I can build you a debug version that you can try out -- it might
get us a little more information.  Also, if you have a place where
I can take a look at the crash dumps, I could probably answer the
issue even faster.

Typically this is either a problem with the Kernsyms file, or some
other symbol related issue.  If your kernel/Kernksyms/map all match
up properly against your vmdump, then things should work great.

Let me know how I can help.  Thanks, Mark.

--Matt

P.S.  Sorry for the delay in response. :)

Mark Price wrote:
> 
> Hi Folks,
> 
> I recompiled my kernel (2.2.18) with the rawio and lckd patches,
> installed
> the lckd utils rpm, and rebooted.
> 
> I can panic the system and the vmdump successfully retrieves the dump
> from my swap partition.
> 
> However when I try and run lcrash on either the live system or against
> the dump it core dumps with a SIGSEGV.
> 
> Nothing useful in the gdb output, so I grabbed the source and recompiled
> with -g flag, and made sure it wasn't being stripped. Still cores, and
> the debug output still gives me no clues.
> 
> [root@w-mprice2 /root]# gdb --core=./core --exec=/sbin/lcrash
> --symbols=/sbin/lcrash
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i386-redhat-linux"...
> Core was generated by `lcrash'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x0 in ?? ()
> (gdb) bt
> #0  0x0 in ?? ()
> (gdb) [root@w-mprice2 /root]#
> [root@w-mprice2 /root]# exit
> 
> So looks like lcrash stomped all over its own stack.
> 
> truss gave me the following output (see below), but without a stack to
> give me an
> idea of where in the code we are I'm not sure it helps.
> 
> It looks like it is in the process of reading the Kerntypes file.
> 
> Has anyone here experienced these symptoms, can you offer any advice?
> 
> Cheers, Mark.
> 
> root wrote:
> >
> > execve("/sbin/lcrash", ["lcrash"], [/* 22 vars */]) = 0
> > fcntl64(0, F_GETFD)                     = -1 ENOSYS (Function not implemented)
> > fcntl(0, F_GETFD)                       = 0
> > fcntl(1, F_GETFD)                       = 0
> > fcntl(2, F_GETFD)                       = 0
> > _sysctl({{CTL_KERN, KERN_OSRELEASE}, 2, "2.2.18", 6, NULL, 0}) = 0
> > geteuid32()                             = -1 ENOSYS (Function not implemented)
> > geteuid()                               = 0
> > getuid()                                = 0
> > getegid()                               = 0
> > getgid()                                = 0
> > brk(0)                                  = 0x8174b7c
> > brk(0x8174b9c)                          = 0x8174b9c
> > brk(0x8175000)                          = 0x8175000
> > getpid()                                = 2305
> > fstat64(1, 0xbffff280)                  = -1 ENOSYS (Function not implemented)
> > fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 1), ...}) = 0
> > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000
> > ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> > write(1, "map = /boot/System.map, vmdump ="..., 89) = 89
> > write(1, "\n", 1)                       = 1
> > write(1, "Please wait...", 14)          = 14
> > rt_sigaction(SIGINT, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > rt_sigaction(SIGPIPE, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > rt_sigaction(SIGABRT, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > rt_sigaction(SIGSEGV, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > rt_sigaction(SIGBUS, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > open("/dev/mem", O_RDONLY)              = 4
> > brk(0x8176000)                          = 0x8176000
> > open("/boot/System.map", O_RDONLY)      = 5
> > fstat(5, {st_mode=S_IFREG|0644, st_size=216270, ...}) = 0
> > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000
> > read(5, "c0100000 A _text\nc0100000 t star"..., 4096) = 4096
> > write(2, ".", 1)                        = 1
> > brk(0x8177000)                          = 0x8177000
> > brk(0x8178000)                          = 0x8178000
> > read(5, "16_interrupt\nc0108da0 t IRQ0x17_"..., 4096) = 4096
> > brk(0x8179000)                          = 0x8179000
> > brk(0x817a000)                          = 0x817a000
> > read(5, "rrupt\nc01093ac t IRQ0xa4_interru"..., 4096) = 4096
> > brk(0x817b000)                          = 0x817b000
> > brk(0x817c000)                          = 0x817c000
> > read(5, "nfig_dword\nc010de1c t pci_conf2_"..., 4096) = 4096
> > brk(0x817d000)                          = 0x817d000
> > brk(0x817e000)                          = 0x817e000
> > brk(0x817f000)                          = 0x817f000
> > read(5, "dma\nc0113900 T free_uid\nc0113970"..., 4096) = 4096
> > brk(0x8180000)                          = 0x8180000
> > brk(0x8181000)                          = 0x8181000
> > read(5, "550 t do_no_page\nc011d644 T hand"..., 4096) = 4096
> > brk(0x8182000)                          = 0x8182000
> > brk(0x8183000)                          = 0x8183000
> > brk(0x8184000)                          = 0x8184000
> > read(5, "94 T kdevname\nc0128fbc T bdevnam"..., 4096) = 4096
> > brk(0x8185000)                          = 0x8185000
> > write(2, ".", 1)                        = 1
> > brk(0x8186000)                          = 0x8186000
> > read(5, "_select\nc0132ffc t do_poll\nc0133"..., 4096) = 4096
> > brk(0x8187000)                          = 0x8187000
> > brk(0x8188000)                          = 0x8188000
> > brk(0x8189000)                          = 0x8189000
> > read(5, "ext2_permission\nc013e3b4 T ext2_"..., 4096) = 4096
> > brk(0x818a000)                          = 0x818a000
> > brk(0x818b000)                          = 0x818b000
> > read(5, " T de_put\nc014bca4 t proc_put_in"..., 4096) = 4096
> > brk(0x818c000)                          = 0x818c000
> > brk(0x818d000)                          = 0x818d000
> > read(5, "c\nc0155b78 t nfs_find_read\nc0155"..., 4096) = 4096
> > brk(0x818e000)                          = 0x818e000
> > brk(0x818f000)                          = 0x818f000
> > brk(0x8190000)                          = 0x8190000
> > read(5, "c_symlink\nc015dbb8 t nfs3_proc_m"..., 4096) = 4096
> > brk(0x8191000)                          = 0x8191000
> > brk(0x8192000)                          = 0x8192000
> > read(5, "0169370 T nfssvc_encode_readlink"..., 4096) = 4096
> > brk(0x8193000)                          = 0x8193000
> > brk(0x8194000)                          = 0x8194000
> > write(2, ".", 1)                        = 1
> > read(5, "t nlmsvc_proc_granted_msg\nc01700"..., 4096) = 4096
> > brk(0x8195000)                          = 0x8195000
> > brk(0x8196000)                          = 0x8196000
> > read(5, "de\nc0174130 t autofs_put_super\nc"..., 4096) = 4096
> > brk(0x8197000)                          = 0x8197000
> > brk(0x8198000)                          = 0x8198000
> > brk(0x8199000)                          = 0x8199000
> > read(5, "7a6a8 T dev_getbyhwaddr\nc017a6f4"..., 4096) = 4096
> > brk(0x819a000)                          = 0x819a000
> > brk(0x819b000)                          = 0x819b000
> > read(5, "181d70 t ip_masq_user_info\nc0181"..., 4096) = 4096
> > brk(0x819c000)                          = 0x819c000
> > brk(0x819d000)                          = 0x819d000
> > brk(0x819e000)                          = 0x819e000
> > read(5, "8 t tcp_ack\nc018d40c T tcp_timew"..., 4096) = 4096
> > brk(0x819f000)                          = 0x819f000
> > brk(0x81a0000)                          = 0x81a0000
> > read(5, "fa\nc019815c t inet_set_ifa\nc0198"..., 4096) = 4096
> > brk(0x81a1000)                          = 0x81a1000
> > brk(0x81a2000)                          = 0x81a2000
> > read(5, "1a0f0c t packet_create\nc01a1064 "..., 4096) = 4096
> > brk(0x81a3000)                          = 0x81a3000
> > brk(0x81a4000)                          = 0x81a4000
> > write(2, ".", 1)                        = 1
> > brk(0x81a5000)                          = 0x81a5000
> > read(5, "a8 T svc_release_buffer\nc01a84c4"..., 4096) = 4096
> > brk(0x81a6000)                          = 0x81a6000
> > brk(0x81a7000)                          = 0x81a7000
> > read(5, "ing_dma\nc01b05c0 t set_pio_mode\n"..., 4096) = 4096
> > brk(0x81a8000)                          = 0x81a8000
> > brk(0x81a9000)                          = 0x81a9000
> > read(5, "ary_port_responding\nc01ba97c t c"..., 4096) = 4096
> > brk(0x81aa000)                          = 0x81aa000
> > brk(0x81ab000)                          = 0x81ab000
> > brk(0x81ac000)                          = 0x81ac000
> > read(5, "_read_proc\nc01c0ec4 t misc_open\n"..., 4096) = 4096
> > brk(0x81ad000)                          = 0x81ad000
> > brk(0x81ae000)                          = 0x81ae000
> > read(5, "dstate\nc01cb06c T register_leds\n"..., 4096) = 4096
> > brk(0x81af000)                          = 0x81af000
> > brk(0x81b0000)                          = 0x81b0000
> > brk(0x81b1000)                          = 0x81b1000
> > read(5, "8 t keyboard_interrupt\nc01d644c "..., 4096) = 4096
> > brk(0x81b2000)                          = 0x81b2000
> > brk(0x81b3000)                          = 0x81b3000
> > write(2, ".", 1)                        = 1
> > read(5, " get_pci_list\nc01e3888 T pcibios"..., 4096) = 4096
> > brk(0x81b4000)                          = 0x81b4000
> > read(5, "02168c7 ? __kstrtab___global_sti"..., 4096) = 4096
> > read(5, "c ? __kstrtab_dput\nc0216f01 ? __"..., 4096) = 4096
> > read(5, "__kstrtab_disable_hlt\nc0217580 ?"..., 4096) = 4096
> > read(5, "ster_cvf_format\nc0217bf0 ? __kst"..., 4096) = 4096
> > read(5, "r\nc021829d ? __kstrtab_pneigh_lo"..., 4096) = 4096
> > read(5, "ll\nc021891a ? __kstrtab_call_in_"..., 4096) = 4096
> > read(5, " __kstrtab_loop_unregister_trans"..., 4096) = 4096
> > read(5, "1a418 ? __ksymtab_MCA_bus\nc021a4"..., 4096) = 4096
> > read(5, "021a7d8 ? __ksymtab_lookup_dentr"..., 4096) = 4096
> > read(5, "lip_buffer_push\nc021ab88 ? __ksy"..., 4096) = 4096
> > read(5, "ode\nc021af28 ? __ksymtab_global_"..., 4096) = 4096
> > read(5, "1b2c0 ? __ksymtab_sock_getsockop"..., 4096) = 4096
> > read(5, "_notifier\nc021b660 ? __ksymtab_u"..., 4096) = 4096
> > read(5, "oto\nc021b9d0 ? __ksymtab_xprt_de"..., 4096) = 4096
> > read(5, "b_set_selection\nc021bd48 ? __ksy"..., 4096) = 4096
> > brk(0x81b5000)                          = 0x81b5000
> > read(5, " cpucount\nc021f8c4 d smp_call_fu"..., 4096) = 4096
> > brk(0x81b6000)                          = 0x81b6000
> > brk(0x81b7000)                          = 0x81b7000
> > read(5, "_inode_operations\nc022a000 D def"..., 4096) = 4096
> > read(5, "\nc022bb40 d proc_root_ioports\nc0"..., 4096) = 4096
> > brk(0x81b8000)                          = 0x81b8000
> > read(5, "ion1\nc022e3f0 d nlm_version3\nc02"..., 4096) = 4096
> > brk(0x81b9000)                          = 0x81b9000
> > brk(0x81ba000)                          = 0x81ba000
> > read(5, "c0230990 D tcp_tw_death_row_slot"..., 4096) = 4096
> > brk(0x81bb000)                          = 0x81bb000
> > read(5, "\nc0232b94 d default_drive_params"..., 4096) = 4096
> > read(5, "e0 D plain_map\nc02363e0 D shift_"..., 4096) = 4096
> > brk(0x81bc000)                          = 0x81bc000
> > brk(0x81bd000)                          = 0x81bd000
> > read(5, "0241430 t pcibios_fixup_devices\n"..., 4096) = 4096
> > brk(0x81be000)                          = 0x81be000
> > brk(0x81bf000)                          = 0x81bf000
> > read(5, " T pckbd_init_hw\nc0249498 T aux_"..., 4096) = 4096
> > brk(0x81c0000)                          = 0x81c0000
> > brk(0x81c1000)                          = 0x81c1000
> > read(5, " b temparea.0\nc02796e0 b reply_b"..., 4096) = 4096
> > brk(0x81c2000)                          = 0x81c2000
> > write(2, ".", 1)                        = 1
> > brk(0x81c3000)                          = 0x81c3000
> > brk(0x81c4000)                          = 0x81c4000
> > read(5, "310 B proc_net\nc0282314 B proc_s"..., 4096) = 3278
> > brk(0x81c5000)                          = 0x81c5000
> > brk(0x81c6000)                          = 0x81c6000
> > read(5, "", 4096)                       = 0
> > old_mmap(NULL, 167936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40002000
> > write(2, ".", 1)                        = 1
> > write(2, ".", 1)                        = 1
> > write(2, ".", 1)                        = 1
> > write(2, ".", 1)                        = 1
> > write(2, ".", 1)                        = 1
> > lseek(4, 2221736, SEEK_SET)             = 2221736
> > read(4, "\310\343(\300", 4)             = 4
> > brk(0x81c8000)                          = 0x81c8000
> > open("/boot/Kerntypes", O_RDONLY)       = 6
> > fstat(6, {st_mode=S_IFREG|0644, st_size=94920, ...}) = 0
> > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4002b000
> > _llseek(6, 0, [0], SEEK_SET)            = 0
> > read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0\3\0\1\0\0\0\0\0\0\0"..., 4096) = 4096
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 4096, [4096], SEEK_SET)      = 0
> > _llseek(6, 94208, [94208], SEEK_SET)    = 0
> > read(6, "omment\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 712
> > _llseek(6, 90112, [90112], SEEK_SET)    = 0
> > read(6, "0,32;it_prof_value:(0,5),1312,32"..., 4096) = 4096
> > read(6, "omment\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 712
> > brk(0x81cb000)                          = 0x81cb000
> > brk(0x81e0000)                          = 0x81e0000
> > _llseek(6, 0, [0], SEEK_SET)            = 0
> > read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0\3\0\1\0\0\0\0\0\0\0"..., 4096) = 4096
> > read(6, "\0\0\0\0\242\0\0\0\0\0\0\0\303O\0\0\200\0\0\0\0\0\0\0\234"..., 4096) = 4096
> > read(6, "\202\0\0\0\0\0\0\0d!\1\0\200\0\0\0\0\0\0\0\242!\1\0\200"..., 4096) = 4096
> > read(6, "(10,5)\0int16_t:t(7,31)=(10,4)\0u_"..., 77824) = 77824
> > read(6, "0,32;it_prof_value:(0,5),1312,32"..., 4096) = 4096
> > brk(0x81e1000)                          = 0x81e1000
> > brk(0x81e2000)                          = 0x81e2000
> > brk(0x81e3000)                          = 0x81e3000
> > brk(0x81e4000)                          = 0x81e4000
> > brk(0x81e5000)                          = 0x81e5000
> > brk(0x81e6000)                          = 0x81e6000
> > brk(0x81e7000)                          = 0x81e7000
> > brk(0x81e8000)                          = 0x81e8000
> > brk(0x81e9000)                          = 0x81e9000
> > brk(0x81ea000)                          = 0x81ea000
> > brk(0x81eb000)                          = 0x81eb000
> > brk(0x81ec000)                          = 0x81ec000
> > brk(0x81ed000)                          = 0x81ed000
> > --- SIGSEGV (Segmentation fault) ---
> > rt_sigaction(SIGINT, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > rt_sigaction(SIGPIPE, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > rt_sigaction(SIGABRT, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > rt_sigaction(SIGSEGV, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > rt_sigaction(SIGBUS, {0x8069200, [], SA_NOMASK|SA_ONESHOT|SA_SIGINFO|0x4000000}, NULL, 8) = 0
> > --- SIGSEGV (Segmentation fault) ---
> > --- SIGSEGV (Segmentation fault) ---
> > +++ killed by SIGSEGV +++