From owner-lkcd@oss.sgi.com Wed Aug 1 00:10:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f717AeT26369 for lkcd-outgoing; Wed, 1 Aug 2001 00:10:40 -0700 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f717AbV26366 for ; Wed, 1 Aug 2001 00:10:38 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA216506 for ; Wed, 1 Aug 2001 09:10:30 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f717ATH33528 for ; Wed, 1 Aug 2001 09:10:29 +0200 Importance: Normal Subject: Re: Msg: input buffer overflow in lcrash. To: "Evandro Tadeu S Vargas" Cc: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Wed, 1 Aug 2001 09:08:47 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 01/08/2001 09:08:48 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, I don't have a solution to this, but a "workaround". On startup lcrash tries to read files for the embedded sial-interpreter. By default such files are searched under /usr/share/sial/lcrash/. One such file is ps.sial providing a new command for lcrash. While reading this file the error occurs. Just remove this file and the file 'scripts/ps.sial' in the lcrash directory to avoid automatical loading of the file on startup and installation of ps.sial when calling 'make install', respectively. Of course, when using the workaround, you are not able to use the functionality provided by libsial. So, a real bug fix has to be found yet. PS: The error occurs not only on S390, I've also seen the error on intel platform. If I found time I'll go deeper into this. Regards, Andreas -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com Evandro Tadeu S Vargas/Brazil/IBM@IBMBR@oss.sgi.com on 07/31/2001 06:17:19 PM Please respond to Evandro Tadeu S Vargas/Brazil/IBM@IBMBR Sent by: owner-lkcd@oss.sgi.com To: lkcd@oss.sgi.com cc: Subject: Msg: input buffer overflow in lcrash. Hi, I'm testing lcrash in Linux/390 (Suse 2.2.16) for processing dump. After compiler the lkcdutils, i created an dump (using Linux/390 standalone dump) and lcrash show following msg: input buffer overflow, can't enlarge buffer because scanner uses REJECT Could you explain this message and possible solution ? TIA. Evandro Vargas From owner-lkcd@oss.sgi.com Wed Aug 1 00:41:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f717f6i27540 for lkcd-outgoing; Wed, 1 Aug 2001 00:41:06 -0700 Received: from eritas.com (brooklyn-bridge.emea.veritas.com [62.172.234.2] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f717f4V27537 for ; Wed, 1 Aug 2001 00:41:05 -0700 Received: from veritas.com (IDENT:sfalvey@sfalvey-lx [127.0.0.1]) by eritas.com (8.11.2/8.11.2) with ESMTP id f717dPg05451 for ; Wed, 1 Aug 2001 08:39:25 +0100 Message-ID: <3B67B22D.903@veritas.com> Date: Wed, 01 Aug 2001 08:39:25 +0100 From: Simon Falvey Organization: Veritas Software User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.7-crash i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: "'lkcd@oss.sgi.com'" Subject: LKCD in mainstream release? References: <69C8DD8179FCD41187CC0003470E0196DD420F@srstart.lss.emc.com> <3B6729FB.67E8DE51@alacritech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi all, Does any one have any idea when we can expect lkcd in the main kernel release? It seems to be pretty stable now. Also has anyone considered putting a hook into the SysRq key sequence to get it to crash on demand? I put one in on my system and find it very useful in diagnosing hangs. Simon From owner-lkcd@oss.sgi.com Wed Aug 1 02:06:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71964P30592 for lkcd-outgoing; Wed, 1 Aug 2001 02:06:04 -0700 Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71962V30588 for ; Wed, 1 Aug 2001 02:06:02 -0700 Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id JAA175430; Wed, 1 Aug 2001 09:49:10 +0100 Received: from d06ml023.portsmouth.uk.ibm.com (d06ml023_cs0 [9.180.35.10]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7195os104352; Wed, 1 Aug 2001 10:05:50 +0100 Importance: Normal Subject: Re: LKCD in mainstream release? To: Simon Falvey Cc: "'lkcd@oss.sgi.com'" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Richard J Moore" Date: Wed, 1 Aug 2001 10:04:52 +0100 X-MIMETrack: Serialize by Router on D06ML023/06/M/IBM(Release 5.0.6 |December 14, 2000) at 01/08/2001 10:03:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Simon, Dump triggers is certainly a thing of interest to us. But not just a keyboard sequence, and API call and in fact the ability to dump from any code path. That latter can be achieved today using DProbes to trigger a dump. What we're considering is enhancing lkcd to be able to let the system continue to run having invoked a dump for non-crash reasons. Question: what's the right key sequence? Presumably there's no definitive answer. In which case we need a configurable sequence. See any problems with that? Richard Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK Simon Falvey @oss.sgi.com on 01/08/2001 08:39:25 Please respond to Simon Falvey Sent by: owner-lkcd@oss.sgi.com To: "'lkcd@oss.sgi.com'" cc: Subject: LKCD in mainstream release? Hi all, Does any one have any idea when we can expect lkcd in the main kernel release? It seems to be pretty stable now. Also has anyone considered putting a hook into the SysRq key sequence to get it to crash on demand? I put one in on my system and find it very useful in diagnosing hangs. Simon From owner-lkcd@oss.sgi.com Wed Aug 1 07:37:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71Ebs804437 for lkcd-outgoing; Wed, 1 Aug 2001 07:37:54 -0700 Received: from eritas.com (brooklyn-bridge.emea.veritas.com [62.172.234.2] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71EbqV04434 for ; Wed, 1 Aug 2001 07:37:52 -0700 Received: from veritas.com (IDENT:sfalvey@sfalvey-lx [127.0.0.1]) by eritas.com (8.11.2/8.11.2) with ESMTP id f71Ea9506359; Wed, 1 Aug 2001 15:36:10 +0100 Message-ID: <3B6813D9.50509@veritas.com> Date: Wed, 01 Aug 2001 15:36:09 +0100 From: Simon Falvey Organization: Veritas Software User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.7-crash i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Richard J Moore CC: "'lkcd@oss.sgi.com'" Subject: Re: LKCD in mainstream release? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Richard, I have been sent an e-mail from a fellow IBMer of yours from India letting me know that a "test" release of the patch sent out to the mailling list actually contains ALT+SYSRQ+c key sequence which will invoke a crash dump. I presume that this will make it into the download area at some point for general consumption. Cheers Simon Richard J Moore wrote: >Simon, > >Dump triggers is certainly a thing of interest to us. But not just a >keyboard sequence, and API call and in fact the ability to dump from any >code path. That latter can be achieved today using DProbes to trigger a >dump. What we're considering is enhancing lkcd to be able to let the system >continue to run having invoked a dump for non-crash reasons. > >Question: what's the right key sequence? > >Presumably there's no definitive answer. In which case we need a >configurable sequence. See any problems with that? > >Richard > > >Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). >http://oss.software.ibm.com/developerworks/opensource/linux >Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 >IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK > > >Simon Falvey @oss.sgi.com on 01/08/2001 08:39:25 > >Please respond to Simon Falvey > >Sent by: owner-lkcd@oss.sgi.com > > >To: "'lkcd@oss.sgi.com'" >cc: >Subject: LKCD in mainstream release? > > >Hi all, > >Does any one have any idea when we can expect lkcd in the main kernel >release? It seems to be pretty stable now. > >Also has anyone considered putting a hook into the SysRq key sequence >to get it to crash on demand? I put one in on my system and find it very >useful in diagnosing hangs. > >Simon > > > > > > From owner-lkcd@oss.sgi.com Wed Aug 1 10:52:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71HqI109047 for lkcd-outgoing; Wed, 1 Aug 2001 10:52:18 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71HqGV09044 for ; Wed, 1 Aug 2001 10:52:16 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f71HlGs28016; Wed, 1 Aug 2001 10:47:16 -0700 Message-ID: <3B6841DF.A8EC1431@alacritech.com> Date: Wed, 01 Aug 2001 10:52:31 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Herrmann CC: Evandro Tadeu S Vargas , lkcd@oss.sgi.com Subject: Re: Msg: input buffer overflow in lcrash. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Luc, are you going to look into this, or should I? --Matt Andreas Herrmann wrote: > > Hi, > > I don't have a solution to this, but a "workaround". > On startup lcrash tries to read files for the embedded sial-interpreter. > By default such files are searched under /usr/share/sial/lcrash/. > One such file is ps.sial providing a new command for lcrash. > While reading this file the error occurs. > > Just remove this file and the file 'scripts/ps.sial' in the lcrash > directory to avoid > automatical loading of the file on startup and installation of ps.sial when > calling 'make install', respectively. > > Of course, when using the workaround, you are not able to use the > functionality provided by libsial. > So, a real bug fix has to be found yet. > > PS: The error occurs not only on S390, I've also seen the error on intel > platform. If I found time I'll go > deeper into this. > > Regards, > > Andreas > > -- > Linux for eServer Development > Tel : +49-7031-16-4640 > Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE > email : aherrman@de.ibm.com > > Evandro Tadeu S Vargas/Brazil/IBM@IBMBR@oss.sgi.com on 07/31/2001 06:17:19 > PM > > Please respond to Evandro Tadeu S Vargas/Brazil/IBM@IBMBR > > Sent by: owner-lkcd@oss.sgi.com > > To: lkcd@oss.sgi.com > cc: > Subject: Msg: input buffer overflow in lcrash. > > Hi, > > I'm testing lcrash in Linux/390 (Suse 2.2.16) for processing dump. > After compiler the lkcdutils, > i created an dump (using Linux/390 standalone dump) and lcrash show > following msg: > > input buffer overflow, can't enlarge buffer because scanner > uses REJECT > > Could you explain this message and possible solution ? > > TIA. > Evandro Vargas From owner-lkcd@oss.sgi.com Wed Aug 1 10:53:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71HrTU09086 for lkcd-outgoing; Wed, 1 Aug 2001 10:53:29 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71HrRV09081 for ; Wed, 1 Aug 2001 10:53:27 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f71Hnos28129; Wed, 1 Aug 2001 10:49:50 -0700 Message-ID: <3B684279.745C6EB9@alacritech.com> Date: Wed, 01 Aug 2001 10:55:05 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Falvey CC: Richard J Moore , "'lkcd@oss.sgi.com'" Subject: Re: LKCD in mainstream release? References: <3B6813D9.50509@veritas.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Simon Falvey wrote: > > Richard, > > I have been sent an e-mail from a fellow IBMer of yours from India > letting me know that a "test" release of the patch sent out to the > mailling list actually contains ALT+SYSRQ+c key sequence which will > invoke a crash dump. I presume that this will make it into the download > area at some point for general consumption. This is correct -- I put this in the latest test patch, and I'll be including it into the next major release. Thanks, Simon, I apologize for not getting this in sooner. Richard's concern is also correct. We'll want to extend this mechanism in the future so that DProbes, SysRQ, etc., all can call into the dump mechanism to get either a full or partial dump. This is what the plan indicates. Are there other developers out there wanting to chip in on the development of some of this new stuff? I haven't asked in a while, so I figured I'd throw that comment out again. --Matt > Cheers > > Simon > > Richard J Moore wrote: > > >Simon, > > > >Dump triggers is certainly a thing of interest to us. But not just a > >keyboard sequence, and API call and in fact the ability to dump from any > >code path. That latter can be achieved today using DProbes to trigger a > >dump. What we're considering is enhancing lkcd to be able to let the system > >continue to run having invoked a dump for non-crash reasons. > > > >Question: what's the right key sequence? > > > >Presumably there's no definitive answer. In which case we need a > >configurable sequence. See any problems with that? > > > >Richard > > > > > >Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). > >http://oss.software.ibm.com/developerworks/opensource/linux > >Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 > >IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK > > > > > >Simon Falvey @oss.sgi.com on 01/08/2001 08:39:25 > > > >Please respond to Simon Falvey > > > >Sent by: owner-lkcd@oss.sgi.com > > > > > >To: "'lkcd@oss.sgi.com'" > >cc: > >Subject: LKCD in mainstream release? > > > > > >Hi all, > > > >Does any one have any idea when we can expect lkcd in the main kernel > >release? It seems to be pretty stable now. > > > >Also has anyone considered putting a hook into the SysRq key sequence > >to get it to crash on demand? I put one in on my system and find it very > >useful in diagnosing hangs. > > > >Simon > > > > > > > > > > > > From owner-lkcd@oss.sgi.com Wed Aug 1 11:22:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71IMQA09818 for lkcd-outgoing; Wed, 1 Aug 2001 11:22:26 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71IMOV09815 for ; Wed, 1 Aug 2001 11:22:24 -0700 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01287 for ; Wed, 1 Aug 2001 11:20:12 -0700 (PDT) mail_from (lucc@sgi.com) Received: from ist.csd.sgi.com (ist.csd.sgi.com [130.62.150.28]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA77178; Wed, 1 Aug 2001 11:22:13 -0700 (PDT) Received: from sgi.com by ist.csd.sgi.com via ESMTP (980427.SGI.8.8.8/911001.SGI) id LAA62857; Wed, 1 Aug 2001 11:21:40 -0700 (PDT) Message-ID: <3B684567.7F1DC5E3@sgi.com> Date: Wed, 01 Aug 2001 14:07:35 -0400 From: Luc Chouinard Organization: SGI X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX 6.5-ALPHA-1287133520 IP32) X-Accept-Language: en MIME-Version: 1.0 To: "Matt D. Robinson" CC: lkcd@oss.sgi.com Subject: Re: Msg: input buffer overflow in lcrash. References: <3B6841DF.A8EC1431@alacritech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Yep, let me look at it more closely. It appears that this issue is more wide spred then I thought. More later. "Matt D. Robinson" wrote: > > Luc, are you going to look into this, or should I? > > --Matt > > Andreas Herrmann wrote: > > > > Hi, > > > > I don't have a solution to this, but a "workaround". > > On startup lcrash tries to read files for the embedded sial-interpreter. > > By default such files are searched under /usr/share/sial/lcrash/. > > One such file is ps.sial providing a new command for lcrash. > > While reading this file the error occurs. > > > > Just remove this file and the file 'scripts/ps.sial' in the lcrash > > directory to avoid > > automatical loading of the file on startup and installation of ps.sial when > > calling 'make install', respectively. > > > > Of course, when using the workaround, you are not able to use the > > functionality provided by libsial. > > So, a real bug fix has to be found yet. > > > > PS: The error occurs not only on S390, I've also seen the error on intel > > platform. If I found time I'll go > > deeper into this. > > > > Regards, > > > > Andreas > > > > -- > > Linux for eServer Development > > Tel : +49-7031-16-4640 > > Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE > > email : aherrman@de.ibm.com > > > > Evandro Tadeu S Vargas/Brazil/IBM@IBMBR@oss.sgi.com on 07/31/2001 06:17:19 > > PM > > > > Please respond to Evandro Tadeu S Vargas/Brazil/IBM@IBMBR > > > > Sent by: owner-lkcd@oss.sgi.com > > > > To: lkcd@oss.sgi.com > > cc: > > Subject: Msg: input buffer overflow in lcrash. > > > > Hi, > > > > I'm testing lcrash in Linux/390 (Suse 2.2.16) for processing dump. > > After compiler the lkcdutils, > > i created an dump (using Linux/390 standalone dump) and lcrash show > > following msg: > > > > input buffer overflow, can't enlarge buffer because scanner > > uses REJECT > > > > Could you explain this message and possible solution ? > > > > TIA. > > Evandro Vargas -- Luc From owner-lkcd@oss.sgi.com Wed Aug 1 14:50:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71LoN714223 for lkcd-outgoing; Wed, 1 Aug 2001 14:50:23 -0700 Received: from zok.corp.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71LoNV14218 for ; Wed, 1 Aug 2001 14:50:23 -0700 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by zok.corp.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f71LtRm09591 for ; Wed, 1 Aug 2001 14:55:27 -0700 Received: from ist.csd.sgi.com (ist.csd.sgi.com [130.62.150.28]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA94036 for <@rock.csd.sgi.com:lkcd@oss.sgi.com>; Wed, 1 Aug 2001 14:50:07 -0700 (PDT) Received: from sgi.com by ist.csd.sgi.com via ESMTP (980427.SGI.8.8.8/911001.SGI) for id OAA63195; Wed, 1 Aug 2001 14:49:50 -0700 (PDT) Message-ID: <3B687630.EDBB754@sgi.com> Date: Wed, 01 Aug 2001 17:35:44 -0400 From: Luc Chouinard Organization: SGI X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX 6.5-ALPHA-1287133520 IP32) X-Accept-Language: en MIME-Version: 1.0 To: lkcd@oss.sgi.com Subject: Re: Msg: input buffer overflow in lcrash. References: <3B6841DF.A8EC1431@alacritech.com> <3B684567.7F1DC5E3@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk It appears that the SuSe distribution has a different lex. Lex is a symb link to flex on TL and RH but is a 'exec flex -l $*' on Suse... I just checked in a version of the sial Makefile that forces flex on sourceforge. I know for sure the the -l option triggers the insertion of #define YY_USES_REJECT. Let me know if it works out for you. ciao -- Luc From owner-lkcd@oss.sgi.com Wed Aug 1 23:51:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f726p0113254 for lkcd-outgoing; Wed, 1 Aug 2001 23:51:00 -0700 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f726owV13251 for ; Wed, 1 Aug 2001 23:50:58 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA117392; Thu, 2 Aug 2001 08:50:51 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f726opW19014; Thu, 2 Aug 2001 08:50:51 +0200 Importance: Normal Subject: Re: Msg: input buffer overflow in lcrash. To: Luc Chouinard Cc: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Thu, 2 Aug 2001 08:49:07 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 02/08/2001 08:49:08 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, indeed, on my SuSe-System lex is a shell script containing 'exec /usr/bin/flex -l "$@'. Using the new Makefile, which calls flex directly, the error is gone. In fact, '-l' option for flex caused the definition of macro YY_USES_REJECT. Thanks for the fix. Andreas -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com Luc Chouinard @oss.sgi.com on 08/01/2001 11:35:44 PM Please respond to Luc Chouinard Sent by: owner-lkcd@oss.sgi.com To: lkcd@oss.sgi.com cc: Subject: Re: Msg: input buffer overflow in lcrash. It appears that the SuSe distribution has a different lex. Lex is a symb link to flex on TL and RH but is a 'exec flex -l $*' on Suse... I just checked in a version of the sial Makefile that forces flex on sourceforge. I know for sure the the -l option triggers the insertion of #define YY_USES_REJECT. Let me know if it works out for you. ciao -- Luc From owner-lkcd@oss.sgi.com Thu Aug 2 15:54:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f72MsrH01383 for lkcd-outgoing; Thu, 2 Aug 2001 15:54:53 -0700 Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f72MsoV01373 for ; Thu, 2 Aug 2001 15:54:50 -0700 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id XAA178120; Thu, 2 Aug 2001 23:35:49 +0100 Received: from d06ml023.portsmouth.uk.ibm.com (d06ml023_cs0 [9.180.35.10]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f72Msf662788; Thu, 2 Aug 2001 23:54:41 +0100 Importance: Normal Subject: Re: LKCD in mainstream release? To: Simon Falvey Cc: "'lkcd@oss.sgi.com'" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Richard J Moore" Date: Thu, 2 Aug 2001 23:41:59 +0100 X-MIMETrack: Serialize by Router on D06ML023/06/M/IBM(Release 5.0.6 |December 14, 2000) at 02/08/2001 23:52:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Simon, who sent you the mail - if it's from our team then yes it will go into the main stream - once we have closed some admin and legal issues. If it's not our group then I'll find out more about the code change. Richard Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK Simon Falvey @oss.sgi.com on 01/08/2001 15:36:09 Please respond to Simon Falvey Sent by: owner-lkcd@oss.sgi.com To: Richard J Moore/UK/IBM@IBMGB cc: "'lkcd@oss.sgi.com'" Subject: Re: LKCD in mainstream release? Richard, I have been sent an e-mail from a fellow IBMer of yours from India letting me know that a "test" release of the patch sent out to the mailling list actually contains ALT+SYSRQ+c key sequence which will invoke a crash dump. I presume that this will make it into the download area at some point for general consumption. Cheers Simon Richard J Moore wrote: >Simon, > >Dump triggers is certainly a thing of interest to us. But not just a >keyboard sequence, and API call and in fact the ability to dump from any >code path. That latter can be achieved today using DProbes to trigger a >dump. What we're considering is enhancing lkcd to be able to let the system >continue to run having invoked a dump for non-crash reasons. > >Question: what's the right key sequence? > >Presumably there's no definitive answer. In which case we need a >configurable sequence. See any problems with that? > >Richard > > >Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). >http://oss.software.ibm.com/developerworks/opensource/linux >Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 >IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK > > >Simon Falvey @oss.sgi.com on 01/08/2001 08:39:25 > >Please respond to Simon Falvey > >Sent by: owner-lkcd@oss.sgi.com > > >To: "'lkcd@oss.sgi.com'" >cc: >Subject: LKCD in mainstream release? > > >Hi all, > >Does any one have any idea when we can expect lkcd in the main kernel >release? It seems to be pretty stable now. > >Also has anyone considered putting a hook into the SysRq key sequence >to get it to crash on demand? I put one in on my system and find it very >useful in diagnosing hangs. > >Simon > > > > > > From owner-lkcd@oss.sgi.com Thu Aug 2 20:42:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f733gNc08016 for lkcd-outgoing; Thu, 2 Aug 2001 20:42:23 -0700 Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f733g8V07987 for ; Thu, 2 Aug 2001 20:42:09 -0700 Received: from f02n15e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id NAA72584 for ; Fri, 3 Aug 2001 13:37:49 +1000 From: rbharata@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.97) with SMTP id f733fVJ55398 for ; Fri, 3 Aug 2001 13:41:31 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A9D.00144231 ; Fri, 3 Aug 2001 13:41:16 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: lkcd@oss.sgi.com Message-ID: Date: Fri, 3 Aug 2001 09:02:05 +0530 Subject: Re: LKCD in mainstream release? Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=J7RRRQDa5KR8AFnWwMMaytZ18tQK2Y4TukNKGjTfSjMIRfjoYEpXywRy" Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk --0__=J7RRRQDa5KR8AFnWwMMaytZ18tQK2Y4TukNKGjTfSjMIRfjoYEpXywRy Content-type: text/plain; charset=us-ascii Content-Disposition: inline Forgot to do "reply all" for the first time and hence the discussion continued outside the lkcd mailing list. Bharata. ---------------------- Forwarded by Bharata B Rao/India/IBM on 08/03/2001 09:14 AM --------------------------- Simon Falvey on 08/01/2001 05:14:44 PM Please respond to Simon Falvey To: Bharata B Rao/India/IBM@IBMIN cc: Subject: Re: LKCD in mainstream release? Many thanks Simon rbharata@in.ibm.com wrote: >Here it is, enjoy... >Bharata. > >(See attached file: lkcd-2.4.4.NEW2.diff) > > > >Simon Falvey on 08/01/2001 04:48:23 PM > >Please respond to Simon Falvey > >To: Bharata B Rao/India/IBM@IBMIN >cc: >Subject: Re: LKCD in mainstream release? > > > > >Yes please, I had previously mentioned the SysRq idea to Matt but did >not get a response, guess he was already working on it. > >Thanks > >Simon > >rbharata@in.ibm.com wrote: > >>Simon, >>Yes it is not present in the patch you are looking into. Infact I was >> >using > >>a patch which was sent out by Matt last month on the mailing list. Here >> >he > >>had fixed some smp problems. This patch was meant for "willing to test" >>crowd. I can send it to you if you want. >> >>Bharata. >> >> >> >>Simon Falvey on 08/01/2001 03:24:29 PM >> >>Please respond to Simon Falvey >> >>To: Bharata B Rao/India/IBM@IBMIN >>cc: >>Subject: Re: LKCD in mainstream release? >> >> >> >> >>I can't seem to find it in the 2.4.4 patch >>ftp://oss.sgi.com/www/projects/lkcd/download/3.1.3/v2.4-kernel-patches/lkcd-2.4.4.diff >> > >>am I looking at the wrong version? >> >>Simon >> >>rbharata@in.ibm.com wrote: >> >>>>Hi all, >>>> >>>>Does any one have any idea when we can expect lkcd in the main kernel >>>>release? It seems to be pretty stable now. >>>> >>>>Also has anyone considered putting a hook into the SysRq key sequence >>>>to get it to crash on demand? I put one in on my system and find it very >>>>useful in diagnosing hangs. >>>> >>>This is already present. ALT+SYSRQ+c is the sequence. But haven't seen >>> >>this >> >>>working(atleast in SMP), as, here the dumping is from interrupt context. >>> >>>>Simon >>>> >>>Bharata. >>> >>> >> >>(Embedded image moved to file: pic26873.pcx) >>- att1.htm >> >> >>Part 1.1 >> >>Content-Type: >> >>text/plain >> >> >>------------------------------------------------------------------------ >>pic26873.pcx >> >>Content-Type: >> >>application/octet-stream >>Content-Encoding: >> >>base64 >> >> > > >(Embedded image moved to file: pic08113.pcx) > - att1.htm > > > Part 1.1 > > Content-Type: > > text/plain > > > ------------------------------------------------------------------------ > lkcd-2.4.4.NEW2.diff > > Content-Type: > > application/octet-stream > Content-Encoding: > > base64 > > > ------------------------------------------------------------------------ > pic08113.pcx > > Content-Type: > > application/octet-stream > Content-Encoding: > > base64 > > --0__=J7RRRQDa5KR8AFnWwMMaytZ18tQK2Y4TukNKGjTfSjMIRfjoYEpXywRy Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCjxib2R5Pg0KTWFueSB0aGFua3M8YnI+DQo8YnI+DQpT aW1vbjxicj4NCjxicj4NCjxicj4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi IGhyZWY9Im1haWx0bzpyYmhhcmF0YUBpbi5pYm0uY29tIj5yYmhhcmF0YUBpbi5pYm0uY29tPC9h PiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6Q0EyNTZBOUIu MDAzRjUyMTkuMDBAZDczbXRhMDEuYXUuaWJtLmNvbSI+PHByZSB3cmFwPSIiPkhlcmUgaXQgaXMs IGVuam95Li4uPGJyPkJoYXJhdGEuPGJyPjxicj4oU2VlIGF0dGFjaGVkIGZpbGU6IGxrY2QtMi40 LjQuTkVXMi5kaWZmKTxicj48YnI+PGJyPjxicj5TaW1vbiBGYWx2ZXkgPGEgY2xhc3M9Im1vei10 eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnNpbW9uLmZhbHZleUB2ZXJpdGFzLmNvbSI+ Jmx0O3NpbW9uLmZhbHZleUB2ZXJpdGFzLmNvbSZndDs8L2E+IG9uIDA4LzAxLzIwMDEgMDQ6NDg6 MjMgUE08YnI+PGJyPlBsZWFzZSByZXNwb25kIHRvIFNpbW9uIEZhbHZleSA8YSBjbGFzcz0ibW96 LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86c2ltb24uZmFsdmV5QHZlcml0YXMuY29t Ij4mbHQ7c2ltb24uZmFsdmV5QHZlcml0YXMuY29tJmd0OzwvYT48YnI+PGJyPlRvOiAgIEJoYXJh dGEgQiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86UmFv L0luZGlhL0lCTUBJQk1JTiI+UmFvL0luZGlhL0lCTUBJQk1JTjwvYT48YnI+Y2M6PGJyPlN1Ympl Y3Q6ICBSZTogTEtDRCBpbiBtYWluc3RyZWFtIHJlbGVhc2U/PGJyPjxicj48YnI+PGJyPjxicj5Z ZXMgcGxlYXNlLCBJIGhhZCBwcmV2aW91c2x5IG1lbnRpb25lZCB0aGUgU3lzUnEgaWRlYSB0byBN YXR0IGJ1dCBkaWQ8YnI+bm90IGdldCBhIHJlc3BvbnNlLCBndWVzcyBoZSB3YXMgYWxyZWFkeSB3 b3JraW5nIG9uIGl0Ljxicj48YnI+VGhhbmtzPGJyPjxicj5TaW1vbjxicj48YnI+PGEgY2xhc3M9 Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnJiaGFyYXRhQGluLmlibS5j b20iPnJiaGFyYXRhQGluLmlibS5jb208L2E+IHdyb3RlOjxicj48YnI+PC9wcmU+DQogIDxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUgd3JhcD0iIj5TaW1vbiw8YnI+WWVzIGl0IGlzIG5vdCBw cmVzZW50IGluIHRoZSBwYXRjaCB5b3UgYXJlIGxvb2tpbmcgaW50by4gSW5mYWN0IEkgd2FzPGJy PjwvcHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8cHJlIHdyYXA9IiI+PCEtLS0tPnVzaW5n PGJyPjwvcHJlPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUgd3JhcD0iIj5hIHBh dGNoIHdoaWNoIHdhcyBzZW50IG91dCBieSBNYXR0IGxhc3QgbW9udGggb24gdGhlIG1haWxpbmcg bGlzdC4gIEhlcmU8YnI+PC9wcmU+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICA8cHJlIHdy YXA9IiI+PCEtLS0tPmhlPGJyPjwvcHJlPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHByZSB3cmFwPSIiPmhhZCBmaXhlZCBzb21lIHNtcCBwcm9ibGVtcy4gVGhpcyBwYXRjaCB3YXMg bWVhbnQgZm9yICJ3aWxsaW5nIHRvIHRlc3QiPGJyPmNyb3dkLiBJIGNhbiBzZW5kIGl0IHRvIHlv dSBpZiB5b3Ugd2FudC48YnI+PGJyPkJoYXJhdGEuPGJyPjxicj48YnI+PGJyPlNpbW9uIEZhbHZl eSA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86c2ltb24uZmFs dmV5QHZlcml0YXMuY29tIj4mbHQ7c2ltb24uZmFsdmV5QHZlcml0YXMuY29tJmd0OzwvYT4gb24g MDgvMDEvMjAwMSAwMzoyNDoyOSBQTTxicj48YnI+UGxlYXNlIHJlc3BvbmQgdG8gU2ltb24gRmFs dmV5IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpzaW1vbi5m YWx2ZXlAdmVyaXRhcy5jb20iPiZsdDtzaW1vbi5mYWx2ZXlAdmVyaXRhcy5jb20mZ3Q7PC9hPjxi cj48YnI+VG86ICAgQmhhcmF0YSBCIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi IGhyZWY9Im1haWx0bzpSYW8vSW5kaWEvSUJNQElCTUlOIj5SYW8vSW5kaWEvSUJNQElCTUlOPC9h Pjxicj5jYzo8YnI+U3ViamVjdDogIFJlOiBMS0NEIGluIG1haW5zdHJlYW0gcmVsZWFzZT88YnI+ PGJyPjxicj48YnI+PGJyPkkgY2FuJ3Qgc2VlbSB0byBmaW5kIGl0IGluIHRoZSAyLjQuNCBwYXRj aDxicj48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJmdHA6Ly9vc3Muc2dp LmNvbS93d3cvcHJvamVjdHMvbGtjZC9kb3dubG9hZC8zLjEuMy92Mi40LWtlcm5lbC1wYXRjaGVz L2xrY2QtMi40LjQuZGlmZiI+ZnRwOi8vb3NzLnNnaS5jb20vd3d3L3Byb2plY3RzL2xrY2QvZG93 bmxvYWQvMy4xLjMvdjIuNC1rZXJuZWwtcGF0Y2hlcy9sa2NkLTIuNC40LmRpZmY8L2E+PGJyPjwv cHJlPg0KICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgIDxwcmUgd3JhcD0iIj48IS0tLS0+ PGJyPjwvcHJlPg0KICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48cHJlIHdyYXA9IiI+ YW0gSSBsb29raW5nIGF0IHRoZSB3cm9uZyB2ZXJzaW9uPzxicj48YnI+U2ltb248YnI+PGJyPjxh IGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpyYmhhcmF0YUBp bi5pYm0uY29tIj5yYmhhcmF0YUBpbi5pYm0uY29tPC9hPiB3cm90ZTo8YnI+PGJyPjwvcHJlPg0K ICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHByZSB3cmFwPSIiPkhpIGFsbCw8YnI+PGJyPkRvZXMgYW55IG9uZSBo YXZlIGFueSBpZGVhIHdoZW4gd2UgY2FuIGV4cGVjdCBsa2NkIGluIHRoZSBtYWluIGtlcm5lbDxi cj5yZWxlYXNlPyBJdCBzZWVtcyB0byBiZSBwcmV0dHkgc3RhYmxlIG5vdy48YnI+PGJyPkFsc28g aGFzIGFueW9uZSBjb25zaWRlcmVkIHB1dHRpbmcgYSBob29rIGludG8gdGhlIFN5c1JxICBrZXkg c2VxdWVuY2U8YnI+dG8gZ2V0IGl0IHRvIGNyYXNoIG9uIGRlbWFuZD8gSSBwdXQgb25lIGluIG9u IG15IHN5c3RlbSBhbmQgZmluZCBpdCB2ZXJ5PGJyPnVzZWZ1bCBpbiBkaWFnbm9zaW5nIGhhbmdz Ljxicj48YnI+PC9wcmU+DQogICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAg ICAgPHByZSB3cmFwPSIiPlRoaXMgaXMgYWxyZWFkeSBwcmVzZW50LiBBTFQrU1lTUlErYyBpcyB0 aGUgc2VxdWVuY2UuIEJ1dCBoYXZlbid0IHNlZW48YnI+PGJyPjwvcHJlPg0KICAgICAgICAgICAg ICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIDxwcmUgd3JhcD0iIj50aGlzPGJyPjxicj48 L3ByZT4NCiAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHByZSB3cmFwPSIi PndvcmtpbmcoYXRsZWFzdCBpbiBTTVApLCBhcywgaGVyZSB0aGUgZHVtcGluZyBpcyBmcm9tIGlu dGVycnVwdCBjb250ZXh0Ljxicj48YnI+PC9wcmU+DQogICAgICAgICAgICAgICAgPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHByZSB3cmFwPSIiPlNpbW9uPGJyPjxicj48L3ByZT4NCiAgICAgICAg ICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgIDxwcmUgd3JhcD0iIj5C aGFyYXRhLjxicj48YnI+PGJyPjwvcHJlPg0KICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3Rl Pg0KICAgICAgICAgICAgICAgICAgPHByZSB3cmFwPSIiPjxicj4oRW1iZWRkZWQgaW1hZ2UgbW92 ZWQgdG8gZmlsZTogcGljMjY4NzMucGN4KTxicj4tIGF0dDEuaHRtPGJyPjxicj48YnI+UGFydCAx LjE8YnI+PGJyPkNvbnRlbnQtVHlwZTo8YnI+PGJyPnRleHQvcGxhaW48YnI+PGJyPjxicj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+cGljMjY4NzMucGN4PGJyPjxicj5Db250ZW50LVR5cGU6PGJyPjxicj5h cHBsaWNhdGlvbi9vY3RldC1zdHJlYW08YnI+Q29udGVudC1FbmNvZGluZzo8YnI+PGJyPmJhc2U2 NDxicj48YnI+PGJyPjwvcHJlPg0KICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAg ICAgICAgICAgICAgICAgPHByZSB3cmFwPSIiPjwhLS0tLT48YnI+PGJyPihFbWJlZGRlZCBpbWFn ZSBtb3ZlZCB0byBmaWxlOiBwaWMwODExMy5wY3gpPGJyPiAtIGF0dDEuaHRtPGJyPjxicj48YnI+ PC9wcmU+DQogICAgICAgICAgICAgICAgICA8Y2VudGVyPg0KICAgICAgICAgICAgICAgICAgPHRh YmxlIGJvcmRlcj0iMSI+DQogICAgICAgICAgICAgICAgICAgIDx0Ym9keT4NCiAgICAgICAgICAg ICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICA8dGQ+DQogICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2IGFsaWduPSJSaWdodCIgY2xhc3M9ImhlYWRlcmRpc3BsYXluYW1l IiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyAiPg0KUGFydCAxLjE8L2Rpdj4NCiAgICAgICAgICAg ICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgICA8dGQ+DQogICAgICAg ICAgICAgICAgICAgICAgICA8dGFibGUgYm9yZGVyPSIwIj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgPHRib2R5Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDx0ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXYgYWxpZ249IlJpZ2h0IiBjbGFzcz0iaGVhZGVyZGlzcGxheW5hbWUiIHN0eWxlPSJkaXNw bGF5OiBpbmxpbmU7ICI+DQpDb250ZW50LVR5cGU6PC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkPnRleHQv cGxhaW48L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgIDwvdGJvZHk+DQogICAgICAgICAgICAgICAgICAgICAgICA8L3RhYmxl Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICA8 L3RyPg0KICAgICAgICAgICAgICAgICAgICA8L3Rib2R5Pg0KICAgICAgICAgICAgICAgICAgPC90 YWJsZT4NCiAgICAgICAgICAgICAgICAgIDwvY2VudGVyPg0KICAgICAgICAgICAgICAgICAgPGJy Pg0KICAgICAgICAgICAgICAgICAgPGhyIHdpZHRoPSI5MCUiIHNpemU9IjQiPg0KICAgICAgICAg ICAgICAgICAgPGNlbnRlcj4NCiAgICAgICAgICAgICAgICAgIDx0YWJsZSBib3JkZXI9IjEiPg0K ICAgICAgICAgICAgICAgICAgICA8dGJvZHk+DQogICAgICAgICAgICAgICAgICAgICAgPHRyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRp diBhbGlnbj0iUmlnaHQiIGNsYXNzPSJoZWFkZXJkaXNwbGF5bmFtZSIgc3R5bGU9ImRpc3BsYXk6 IGlubGluZTsgIj4NCmxrY2QtMi40LjQuTkVXMi5kaWZmPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAg ICAgICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMCI+DQogICAgICAgICAgICAgICAgICAgICAgICAg IDx0Ym9keT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8dGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 IGFsaWduPSJSaWdodCIgY2xhc3M9ImhlYWRlcmRpc3BsYXluYW1lIiBzdHlsZT0iZGlzcGxheTog aW5saW5lOyAiPg0KQ29udGVudC1UeXBlOjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZD5hcHBsaWNhdGlv bi9vY3RldC1zdHJlYW08L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPHRkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBhbGlnbj0iUmln aHQiIGNsYXNzPSJoZWFkZXJkaXNwbGF5bmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsgIj4N CkNvbnRlbnQtRW5jb2Rpbmc6PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkPmJhc2U2NDwvdGQ+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg PC90Ym9keT4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICAg ICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAg ICAgICAgICAgIDwvdGJvZHk+DQogICAgICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAg ICAgICAgICAgPC9jZW50ZXI+DQogICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg ICAgICA8aHIgd2lkdGg9IjkwJSIgc2l6ZT0iNCI+DQogICAgICAgICAgICAgICAgICA8Y2VudGVy Pg0KICAgICAgICAgICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMSI+DQogICAgICAgICAgICAgICAg ICAgIDx0Ym9keT4NCiAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAg ICAgICAgICA8dGQ+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGFsaWduPSJSaWdodCIg Y2xhc3M9ImhlYWRlcmRpc3BsYXluYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyAiPg0KcGlj MDgxMTMucGN4PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHRhYmxlIGJvcmRl cj0iMCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDx0Ym9keT4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQ+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGFsaWduPSJSaWdodCIgY2xhc3M9Imhl YWRlcmRpc3BsYXluYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyAiPg0KQ29udGVudC1UeXBl OjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDx0ZD5hcHBsaWNhdGlvbi9vY3RldC1zdHJlYW08L3RkPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdiBhbGlnbj0iUmlnaHQiIGNsYXNzPSJoZWFkZXJkaXNwbGF5 bmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsgIj4NCkNvbnRlbnQtRW5jb2Rpbmc6PC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHRkPmJhc2U2NDwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg PC90cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC90Ym9keT4NCiAgICAgICAgICAgICAg ICAgICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAg ICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgIDwvdGJvZHk+DQogICAg ICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgICAgPC9jZW50ZXI+DQogICAg ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAg ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICA8L2JvZHk+DQogICAgICAgICAg ICAgICAgICA8L2h0bWw+DQoNCg== --0__=J7RRRQDa5KR8AFnWwMMaytZ18tQK2Y4TukNKGjTfSjMIRfjoYEpXywRy-- From owner-lkcd@oss.sgi.com Thu Aug 2 20:42:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f733gMM08010 for lkcd-outgoing; Thu, 2 Aug 2001 20:42:22 -0700 Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f733g7V07986 for ; Thu, 2 Aug 2001 20:42:08 -0700 Received: from f02n15e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id NAA265426 for ; Fri, 3 Aug 2001 13:37:46 +1000 From: rbharata@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.97) with SMTP id f733fTJ55394 for ; Fri, 3 Aug 2001 13:41:29 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A9D.001442FE ; Fri, 3 Aug 2001 13:41:18 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: lkcd@oss.sgi.com Message-ID: Date: Fri, 3 Aug 2001 09:02:19 +0530 Subject: Re: LKCD in mainstream release? Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=TFQCCsnw3o44Wuru2pA4vmawVtxdYfWYr34EMM7FbshounqsFgVIgsYT" Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk --0__=TFQCCsnw3o44Wuru2pA4vmawVtxdYfWYr34EMM7FbshounqsFgVIgsYT Content-type: text/plain; charset=us-ascii Content-Disposition: inline Forgot to do "reply all" for the first time and hence the discussion continued outside the lkcd mailing list. Bharata. ---------------------- Forwarded by Bharata B Rao/India/IBM on 08/03/2001 09:14 AM --------------------------- Simon Falvey on 08/01/2001 05:14:44 PM Please respond to Simon Falvey To: Bharata B Rao/India/IBM@IBMIN cc: Subject: Re: LKCD in mainstream release? Many thanks Simon rbharata@in.ibm.com wrote: >Here it is, enjoy... >Bharata. > >(See attached file: lkcd-2.4.4.NEW2.diff) > > > >Simon Falvey on 08/01/2001 04:48:23 PM > >Please respond to Simon Falvey > >To: Bharata B Rao/India/IBM@IBMIN >cc: >Subject: Re: LKCD in mainstream release? > > > > >Yes please, I had previously mentioned the SysRq idea to Matt but did >not get a response, guess he was already working on it. > >Thanks > >Simon > >rbharata@in.ibm.com wrote: > >>Simon, >>Yes it is not present in the patch you are looking into. Infact I was >> >using > >>a patch which was sent out by Matt last month on the mailing list. Here >> >he > >>had fixed some smp problems. This patch was meant for "willing to test" >>crowd. I can send it to you if you want. >> >>Bharata. >> >> >> >>Simon Falvey on 08/01/2001 03:24:29 PM >> >>Please respond to Simon Falvey >> >>To: Bharata B Rao/India/IBM@IBMIN >>cc: >>Subject: Re: LKCD in mainstream release? >> >> >> >> >>I can't seem to find it in the 2.4.4 patch >>ftp://oss.sgi.com/www/projects/lkcd/download/3.1.3/v2.4-kernel-patches/lkcd-2.4.4.diff >> > >>am I looking at the wrong version? >> >>Simon >> >>rbharata@in.ibm.com wrote: >> >>>>Hi all, >>>> >>>>Does any one have any idea when we can expect lkcd in the main kernel >>>>release? It seems to be pretty stable now. >>>> >>>>Also has anyone considered putting a hook into the SysRq key sequence >>>>to get it to crash on demand? I put one in on my system and find it very >>>>useful in diagnosing hangs. >>>> >>>This is already present. ALT+SYSRQ+c is the sequence. But haven't seen >>> >>this >> >>>working(atleast in SMP), as, here the dumping is from interrupt context. >>> >>>>Simon >>>> >>>Bharata. >>> >>> >> >>(Embedded image moved to file: pic26873.pcx) >>- att1.htm >> >> >>Part 1.1 >> >>Content-Type: >> >>text/plain >> >> >>------------------------------------------------------------------------ >>pic26873.pcx >> >>Content-Type: >> >>application/octet-stream >>Content-Encoding: >> >>base64 >> >> > > >(Embedded image moved to file: pic08113.pcx) > - att1.htm > > > Part 1.1 > > Content-Type: > > text/plain > > > ------------------------------------------------------------------------ > lkcd-2.4.4.NEW2.diff > > Content-Type: > > application/octet-stream > Content-Encoding: > > base64 > > > ------------------------------------------------------------------------ > pic08113.pcx > > Content-Type: > > application/octet-stream > Content-Encoding: > > base64 > > --0__=TFQCCsnw3o44Wuru2pA4vmawVtxdYfWYr34EMM7FbshounqsFgVIgsYT Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCjxib2R5Pg0KTWFueSB0aGFua3M8YnI+DQo8YnI+DQpT aW1vbjxicj4NCjxicj4NCjxicj4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi IGhyZWY9Im1haWx0bzpyYmhhcmF0YUBpbi5pYm0uY29tIj5yYmhhcmF0YUBpbi5pYm0uY29tPC9h PiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6Q0EyNTZBOUIu MDAzRjUyMTkuMDBAZDczbXRhMDEuYXUuaWJtLmNvbSI+PHByZSB3cmFwPSIiPkhlcmUgaXQgaXMs IGVuam95Li4uPGJyPkJoYXJhdGEuPGJyPjxicj4oU2VlIGF0dGFjaGVkIGZpbGU6IGxrY2QtMi40 LjQuTkVXMi5kaWZmKTxicj48YnI+PGJyPjxicj5TaW1vbiBGYWx2ZXkgPGEgY2xhc3M9Im1vei10 eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnNpbW9uLmZhbHZleUB2ZXJpdGFzLmNvbSI+ Jmx0O3NpbW9uLmZhbHZleUB2ZXJpdGFzLmNvbSZndDs8L2E+IG9uIDA4LzAxLzIwMDEgMDQ6NDg6 MjMgUE08YnI+PGJyPlBsZWFzZSByZXNwb25kIHRvIFNpbW9uIEZhbHZleSA8YSBjbGFzcz0ibW96 LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86c2ltb24uZmFsdmV5QHZlcml0YXMuY29t Ij4mbHQ7c2ltb24uZmFsdmV5QHZlcml0YXMuY29tJmd0OzwvYT48YnI+PGJyPlRvOiAgIEJoYXJh dGEgQiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86UmFv L0luZGlhL0lCTUBJQk1JTiI+UmFvL0luZGlhL0lCTUBJQk1JTjwvYT48YnI+Y2M6PGJyPlN1Ympl Y3Q6ICBSZTogTEtDRCBpbiBtYWluc3RyZWFtIHJlbGVhc2U/PGJyPjxicj48YnI+PGJyPjxicj5Z ZXMgcGxlYXNlLCBJIGhhZCBwcmV2aW91c2x5IG1lbnRpb25lZCB0aGUgU3lzUnEgaWRlYSB0byBN YXR0IGJ1dCBkaWQ8YnI+bm90IGdldCBhIHJlc3BvbnNlLCBndWVzcyBoZSB3YXMgYWxyZWFkeSB3 b3JraW5nIG9uIGl0Ljxicj48YnI+VGhhbmtzPGJyPjxicj5TaW1vbjxicj48YnI+PGEgY2xhc3M9 Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnJiaGFyYXRhQGluLmlibS5j b20iPnJiaGFyYXRhQGluLmlibS5jb208L2E+IHdyb3RlOjxicj48YnI+PC9wcmU+DQogIDxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUgd3JhcD0iIj5TaW1vbiw8YnI+WWVzIGl0IGlzIG5vdCBw cmVzZW50IGluIHRoZSBwYXRjaCB5b3UgYXJlIGxvb2tpbmcgaW50by4gSW5mYWN0IEkgd2FzPGJy PjwvcHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8cHJlIHdyYXA9IiI+PCEtLS0tPnVzaW5n PGJyPjwvcHJlPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUgd3JhcD0iIj5hIHBh dGNoIHdoaWNoIHdhcyBzZW50IG91dCBieSBNYXR0IGxhc3QgbW9udGggb24gdGhlIG1haWxpbmcg bGlzdC4gIEhlcmU8YnI+PC9wcmU+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICA8cHJlIHdy YXA9IiI+PCEtLS0tPmhlPGJyPjwvcHJlPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHByZSB3cmFwPSIiPmhhZCBmaXhlZCBzb21lIHNtcCBwcm9ibGVtcy4gVGhpcyBwYXRjaCB3YXMg bWVhbnQgZm9yICJ3aWxsaW5nIHRvIHRlc3QiPGJyPmNyb3dkLiBJIGNhbiBzZW5kIGl0IHRvIHlv dSBpZiB5b3Ugd2FudC48YnI+PGJyPkJoYXJhdGEuPGJyPjxicj48YnI+PGJyPlNpbW9uIEZhbHZl eSA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86c2ltb24uZmFs dmV5QHZlcml0YXMuY29tIj4mbHQ7c2ltb24uZmFsdmV5QHZlcml0YXMuY29tJmd0OzwvYT4gb24g MDgvMDEvMjAwMSAwMzoyNDoyOSBQTTxicj48YnI+UGxlYXNlIHJlc3BvbmQgdG8gU2ltb24gRmFs dmV5IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpzaW1vbi5m YWx2ZXlAdmVyaXRhcy5jb20iPiZsdDtzaW1vbi5mYWx2ZXlAdmVyaXRhcy5jb20mZ3Q7PC9hPjxi cj48YnI+VG86ICAgQmhhcmF0YSBCIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi IGhyZWY9Im1haWx0bzpSYW8vSW5kaWEvSUJNQElCTUlOIj5SYW8vSW5kaWEvSUJNQElCTUlOPC9h Pjxicj5jYzo8YnI+U3ViamVjdDogIFJlOiBMS0NEIGluIG1haW5zdHJlYW0gcmVsZWFzZT88YnI+ PGJyPjxicj48YnI+PGJyPkkgY2FuJ3Qgc2VlbSB0byBmaW5kIGl0IGluIHRoZSAyLjQuNCBwYXRj aDxicj48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJmdHA6Ly9vc3Muc2dp LmNvbS93d3cvcHJvamVjdHMvbGtjZC9kb3dubG9hZC8zLjEuMy92Mi40LWtlcm5lbC1wYXRjaGVz L2xrY2QtMi40LjQuZGlmZiI+ZnRwOi8vb3NzLnNnaS5jb20vd3d3L3Byb2plY3RzL2xrY2QvZG93 bmxvYWQvMy4xLjMvdjIuNC1rZXJuZWwtcGF0Y2hlcy9sa2NkLTIuNC40LmRpZmY8L2E+PGJyPjwv cHJlPg0KICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgIDxwcmUgd3JhcD0iIj48IS0tLS0+ PGJyPjwvcHJlPg0KICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48cHJlIHdyYXA9IiI+ YW0gSSBsb29raW5nIGF0IHRoZSB3cm9uZyB2ZXJzaW9uPzxicj48YnI+U2ltb248YnI+PGJyPjxh IGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpyYmhhcmF0YUBp bi5pYm0uY29tIj5yYmhhcmF0YUBpbi5pYm0uY29tPC9hPiB3cm90ZTo8YnI+PGJyPjwvcHJlPg0K ICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHByZSB3cmFwPSIiPkhpIGFsbCw8YnI+PGJyPkRvZXMgYW55IG9uZSBo YXZlIGFueSBpZGVhIHdoZW4gd2UgY2FuIGV4cGVjdCBsa2NkIGluIHRoZSBtYWluIGtlcm5lbDxi cj5yZWxlYXNlPyBJdCBzZWVtcyB0byBiZSBwcmV0dHkgc3RhYmxlIG5vdy48YnI+PGJyPkFsc28g aGFzIGFueW9uZSBjb25zaWRlcmVkIHB1dHRpbmcgYSBob29rIGludG8gdGhlIFN5c1JxICBrZXkg c2VxdWVuY2U8YnI+dG8gZ2V0IGl0IHRvIGNyYXNoIG9uIGRlbWFuZD8gSSBwdXQgb25lIGluIG9u IG15IHN5c3RlbSBhbmQgZmluZCBpdCB2ZXJ5PGJyPnVzZWZ1bCBpbiBkaWFnbm9zaW5nIGhhbmdz Ljxicj48YnI+PC9wcmU+DQogICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAg ICAgPHByZSB3cmFwPSIiPlRoaXMgaXMgYWxyZWFkeSBwcmVzZW50LiBBTFQrU1lTUlErYyBpcyB0 aGUgc2VxdWVuY2UuIEJ1dCBoYXZlbid0IHNlZW48YnI+PGJyPjwvcHJlPg0KICAgICAgICAgICAg ICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIDxwcmUgd3JhcD0iIj50aGlzPGJyPjxicj48 L3ByZT4NCiAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHByZSB3cmFwPSIi PndvcmtpbmcoYXRsZWFzdCBpbiBTTVApLCBhcywgaGVyZSB0aGUgZHVtcGluZyBpcyBmcm9tIGlu dGVycnVwdCBjb250ZXh0Ljxicj48YnI+PC9wcmU+DQogICAgICAgICAgICAgICAgPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHByZSB3cmFwPSIiPlNpbW9uPGJyPjxicj48L3ByZT4NCiAgICAgICAg ICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgIDxwcmUgd3JhcD0iIj5C aGFyYXRhLjxicj48YnI+PGJyPjwvcHJlPg0KICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3Rl Pg0KICAgICAgICAgICAgICAgICAgPHByZSB3cmFwPSIiPjxicj4oRW1iZWRkZWQgaW1hZ2UgbW92 ZWQgdG8gZmlsZTogcGljMjY4NzMucGN4KTxicj4tIGF0dDEuaHRtPGJyPjxicj48YnI+UGFydCAx LjE8YnI+PGJyPkNvbnRlbnQtVHlwZTo8YnI+PGJyPnRleHQvcGxhaW48YnI+PGJyPjxicj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+cGljMjY4NzMucGN4PGJyPjxicj5Db250ZW50LVR5cGU6PGJyPjxicj5h cHBsaWNhdGlvbi9vY3RldC1zdHJlYW08YnI+Q29udGVudC1FbmNvZGluZzo8YnI+PGJyPmJhc2U2 NDxicj48YnI+PGJyPjwvcHJlPg0KICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAg ICAgICAgICAgICAgICAgPHByZSB3cmFwPSIiPjwhLS0tLT48YnI+PGJyPihFbWJlZGRlZCBpbWFn ZSBtb3ZlZCB0byBmaWxlOiBwaWMwODExMy5wY3gpPGJyPiAtIGF0dDEuaHRtPGJyPjxicj48YnI+ PC9wcmU+DQogICAgICAgICAgICAgICAgICA8Y2VudGVyPg0KICAgICAgICAgICAgICAgICAgPHRh YmxlIGJvcmRlcj0iMSI+DQogICAgICAgICAgICAgICAgICAgIDx0Ym9keT4NCiAgICAgICAgICAg ICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICA8dGQ+DQogICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2IGFsaWduPSJSaWdodCIgY2xhc3M9ImhlYWRlcmRpc3BsYXluYW1l IiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyAiPg0KUGFydCAxLjE8L2Rpdj4NCiAgICAgICAgICAg ICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgICA8dGQ+DQogICAgICAg ICAgICAgICAgICAgICAgICA8dGFibGUgYm9yZGVyPSIwIj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgPHRib2R5Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDx0ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXYgYWxpZ249IlJpZ2h0IiBjbGFzcz0iaGVhZGVyZGlzcGxheW5hbWUiIHN0eWxlPSJkaXNw bGF5OiBpbmxpbmU7ICI+DQpDb250ZW50LVR5cGU6PC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkPnRleHQv cGxhaW48L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgIDwvdGJvZHk+DQogICAgICAgICAgICAgICAgICAgICAgICA8L3RhYmxl Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICA8 L3RyPg0KICAgICAgICAgICAgICAgICAgICA8L3Rib2R5Pg0KICAgICAgICAgICAgICAgICAgPC90 YWJsZT4NCiAgICAgICAgICAgICAgICAgIDwvY2VudGVyPg0KICAgICAgICAgICAgICAgICAgPGJy Pg0KICAgICAgICAgICAgICAgICAgPGhyIHdpZHRoPSI5MCUiIHNpemU9IjQiPg0KICAgICAgICAg ICAgICAgICAgPGNlbnRlcj4NCiAgICAgICAgICAgICAgICAgIDx0YWJsZSBib3JkZXI9IjEiPg0K ICAgICAgICAgICAgICAgICAgICA8dGJvZHk+DQogICAgICAgICAgICAgICAgICAgICAgPHRyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRp diBhbGlnbj0iUmlnaHQiIGNsYXNzPSJoZWFkZXJkaXNwbGF5bmFtZSIgc3R5bGU9ImRpc3BsYXk6 IGlubGluZTsgIj4NCmxrY2QtMi40LjQuTkVXMi5kaWZmPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAg ICAgICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMCI+DQogICAgICAgICAgICAgICAgICAgICAgICAg IDx0Ym9keT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8dGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 IGFsaWduPSJSaWdodCIgY2xhc3M9ImhlYWRlcmRpc3BsYXluYW1lIiBzdHlsZT0iZGlzcGxheTog aW5saW5lOyAiPg0KQ29udGVudC1UeXBlOjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZD5hcHBsaWNhdGlv bi9vY3RldC1zdHJlYW08L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPHRkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBhbGlnbj0iUmln aHQiIGNsYXNzPSJoZWFkZXJkaXNwbGF5bmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsgIj4N CkNvbnRlbnQtRW5jb2Rpbmc6PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkPmJhc2U2NDwvdGQ+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg PC90Ym9keT4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICAg ICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAg ICAgICAgICAgIDwvdGJvZHk+DQogICAgICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAg ICAgICAgICAgPC9jZW50ZXI+DQogICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg ICAgICA8aHIgd2lkdGg9IjkwJSIgc2l6ZT0iNCI+DQogICAgICAgICAgICAgICAgICA8Y2VudGVy Pg0KICAgICAgICAgICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMSI+DQogICAgICAgICAgICAgICAg ICAgIDx0Ym9keT4NCiAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAg ICAgICAgICA8dGQ+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGFsaWduPSJSaWdodCIg Y2xhc3M9ImhlYWRlcmRpc3BsYXluYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyAiPg0KcGlj MDgxMTMucGN4PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHRhYmxlIGJvcmRl cj0iMCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDx0Ym9keT4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQ+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGFsaWduPSJSaWdodCIgY2xhc3M9Imhl YWRlcmRpc3BsYXluYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyAiPg0KQ29udGVudC1UeXBl OjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDx0ZD5hcHBsaWNhdGlvbi9vY3RldC1zdHJlYW08L3RkPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdiBhbGlnbj0iUmlnaHQiIGNsYXNzPSJoZWFkZXJkaXNwbGF5 bmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsgIj4NCkNvbnRlbnQtRW5jb2Rpbmc6PC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHRkPmJhc2U2NDwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg PC90cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC90Ym9keT4NCiAgICAgICAgICAgICAg ICAgICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAg ICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgIDwvdGJvZHk+DQogICAg ICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgICAgPC9jZW50ZXI+DQogICAg ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAg ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICA8L2JvZHk+DQogICAgICAgICAg ICAgICAgICA8L2h0bWw+DQoNCg== --0__=TFQCCsnw3o44Wuru2pA4vmawVtxdYfWYr34EMM7FbshounqsFgVIgsYT-- From owner-lkcd@oss.sgi.com Mon Aug 6 03:24:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76AOgY01982 for lkcd-outgoing; Mon, 6 Aug 2001 03:24:42 -0700 Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76AOUV01964 for ; Mon, 6 Aug 2001 03:24:30 -0700 Received: from m5.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id TAA18574 for ; Mon, 6 Aug 2001 19:24:23 +0900 (JST) (envelope-from m-kotani@pst.fujitsu.com) Received: from classic.aoi.pst.fujitsu.com by m5.gw.fujitsu.co.jp (8.9.3/3.7W-0105-Fujitsu Domain Master) id TAA05116 for ; Mon, 6 Aug 2001 19:24:19 +0900 (envelope-from m-kotani@pst.fujitsu.com) Received: from doll (dhcp72160.aoi.pst.fujitsu.com [172.23.72.160]) by classic.aoi.pst.fujitsu.com (8.9.3/8.9.3) with SMTP id TAA03513 for ; Mon, 6 Aug 2001 19:24:12 +0900 Message-ID: <016301c11e62$26abb4e0$a04817ac@aoi.pst.fujitsu.com> From: "Masashige Kotani" To: References: <20010717113618I.j-kondo@pst.fujitsu.com> <3B5552DF.1040103@pst.fujitsu.com> Subject: Re: Module support Date: Mon, 6 Aug 2001 19:25:43 +0900 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.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-lkcd@oss.sgi.com Precedence: bulk ----- Original Message ----- From: T.Ohno To: Cc: Sent: Wednesday, July 18, 2001 6:11 PM Subject: Re: Module support > Dear all > > KONDO Jyunji wrote: > > > Hi, hiro. > > > > > >> Has anyone tried to make lcrash support modules. If no one has, > >> I guess I have to reverse-engineer the query_modules system call. > >> Am I correct? > > > > > > We are trying to do that by extending lcrash and using ksymoops. > > > > > >> Since most of our proprietary kernel code (device drivers) is > >> in module, LKCD is not very useful with module support... > > > > > > I agree... > > > > At the moment, we are fixing our ideas and we'll be post it to this > > group soon. > > Please wait a moment. > > I am a Jyunji's co-worker. Now I will post our idea. > > I think Andreas's ideas are effective at debugging > a specific module. > > Our idea is different from his one and aims at the > investigation for detecting a system crash reason. > > Currently we are planning following procedure. > > 1. Extract symbols for debugging modules from > dump file by using a new lcrash option or a > dedicated command. > > 2. Create a System.map file including the all > symbols of loaded modules by passing the > result of #1 to ksymoops command. > > Using this System.map, the symbols of all modules > which was loaded in kernel when system crash occurred > are referable. > > In Andreas's idea, the modules installed at system > crash or module map files must be saved and the map files > must be loaded each lcrash. > > In our idea, as the System.map at the system crash is > generated, module replacement causes no problem > (of course after generating System.map) > and the dump is analyzable at another machine. > > Any comment and suggestion are welcomed. > > > Toshio Ohno > Hello. I am a Jyunji's co-worker too. I am making a new command for module support of lkcd as in the above mail. I think Andreas's module subcommand is a general-purpose function and very useful for bug investigation. But we have to keep symbol information of modules which were loaded at the time of system crash. So, when some of modules are replaced, the module subcommand can't deal with correct symbol information. To avoid that situation, We should have a facility which saves symbol information with saving memory dump simultaneously. So I considered and implemented the facility described below: 1) Extarct symbol information of modules which were loaded at the time of system crash from a dump file, 2) Merge them to System.map, 3) Save it as a map file which lcrash can read. This consists of a command which extracts symbols of modules and a patch of vmdump script. This command merges symbol information of modules and System.map by using ksymoops. The map file which contains symbol information of modules is saved as "map.bounds". By using lcrash with this map file, we can investigate modules' issues. Since original System.map is also saved, you can use Andreas's module subcommand if you want. The program is appended below. Comments are welcome. --Masashige Kotani The following is the patch of lkcdutils-1.0-7.tar.gz for our new command. ------------------------------------ diff -Naur lkcdutils-1.0/Makefile lkcdutils-1.0-1/Makefile --- lkcdutils-1.0/Makefile Sun May 6 01:48:02 2001 +++ lkcdutils-1.0-1/Makefile Fri Aug 3 16:25:09 2001 @@ -27,7 +27,7 @@ -include .config -SUB_DIRS = scripts libklib liballoc librl libsial lcrash +SUB_DIRS = scripts libklib liballoc librl libsial lcrash lcd_ksyms subdirs_make: for dir in $(SUB_DIRS) ; do \ diff -Naur lkcdutils-1.0/lcd_ksyms/Makefile lkcdutils-1.0-1/lcd_ksyms/Makefile --- lkcdutils-1.0/lcd_ksyms/Makefile Thu Jan 1 09:00:00 1970 +++ lkcdutils-1.0-1/lcd_ksyms/Makefile Fri Aug 3 16:26:00 2001 @@ -0,0 +1,55 @@ +# +# Makefile for lcd_ksyms +# +# Copyright 1999 Silicon Graphics, Inc. All rights reserved. +# COPYRIGHT(C) FUJITSU LIMITED 2001 +# +DEPTH = . +include $(DEPTH)/commondefs + +TARGET = lcd_ksyms +CFILES = main.c +LIBS = -lalloc -lklib -lbfd -liberty -lsial +LFLAGS = -static -rdynamic -L. -L$(TOPDIR) -L$(LKCDDIR)/libklib \ + -L$(LKCDDIR)/liballoc -L$(LKCDDIR)/libsial +OFILES = $(CFILES:.c=.o) +SUB_DIRS = man + +default: $(TARGET) + +$(TARGET): subdirs_make + $(CC) -o $@ $(LDFLAGS) $(LFLAGS) $(OFILES) $(LIBS) + +subdirs_make: $(OFILES) + for dir in $(SUB_DIRS) ; do \ + ( cd $$dir ; make TOPDIR=$(TOPDIR); cd ..) \ + done + +clean: + /bin/rm -f *.o *.a + /bin/rm -f $(DEPTH)/include/arch + for dir in $(SUB_DIRS) ; do \ + ( cd $$dir ; make TOPDIR=$(TOPDIR) ARCH=$(ARCH) clean; cd .. ); \ + done + +clobber: clean + /bin/rm -f $(TARGET) + +$(OFILES): $(HEADERS) + +# +# We avoid this for now -- you'll need to do a make clobber followed +# by a make if you want to fix this later. +# +$(HEADERS): symlinks + +symlinks: + /bin/rm -f $(HEPTH)/arch + (cd $(HPATH) ; /bin/ln -sf arch-$(ARCH) arch) + (cd $(LKCDDIR)/libklib ; make ARCH=$(ARCH) symlinks) + +install: $(TARGET) + mkdir -p $(ROOT)/sbin + mkdir -p $(ROOT)/usr/man/man1 + install -m 755 lcd_ksyms $(ROOT)/sbin/lcd_ksyms + install -m 644 man/lcd_ksyms.1 $(ROOT)/usr/man/man1 diff -Naur lkcdutils-1.0/lcd_ksyms/commondefs lkcdutils-1.0-1/lcd_ksyms/commondefs --- lkcdutils-1.0/lcd_ksyms/commondefs Thu Jan 1 09:00:00 1970 +++ lkcdutils-1.0-1/lcd_ksyms/commondefs Fri Aug 3 16:15:55 2001 @@ -0,0 +1,21 @@ +# +# Common defines for lcrash makefiles +# +# Copyright 1999 Silicon Graphics, Inc. All rights reserved. +# +VERSION = 1.5 +ifeq ($(ARCH),ia64) +EXTRA_CFLAGS = -gstabs -DARCH=$(ARCH) +else +EXTRA_CFLAGS = -gstabs -DARCH=$(ARCH) -DALLOC_DEBUG +endif + +EXTRA_CFLAGS += -Wall -Wstrict-prototypes -D_GNU_SOURCE + +HPATH = $(DEPTH)/../lcrash/include +LKCDDIR = $(DEPTH)/.. +HEADERS = $(HPATH)/command.h $(HPATH)/lcrash.h $(HPATH)/arch/trace.h +EXTRA_CFLAGS += -I$(HPATH) -I$(LKCDDIR)/libklib/include -I$(TOPDIR)/include \ + -I$(LKCDDIR)/libsial + +include $(LKCDDIR)/Rules.make diff -Naur lkcdutils-1.0/lcd_ksyms/main.c lkcdutils-1.0-1/lcd_ksyms/main.c --- lkcdutils-1.0/lcd_ksyms/main.c Thu Jan 1 09:00:00 1970 +++ lkcdutils-1.0-1/lcd_ksyms/main.c Fri Aug 3 16:15:55 2001 @@ -0,0 +1,187 @@ +/* + * Copyright 1999 Silicon Graphics, Inc. All rights reserved. + * COPYRIGHT(C) FUJITSU LIMITED 2001 + * + * $Id: main.c,v 1.7 2001/08/01 05:05:28 mkotani Exp $ + */ +#include +#include +#include +#include + +#define GK_LINE_LENGTH 255 /* ksyms' a line length */ + +#if (ARCH == ia64) +void +*kl_get_ra(void) +{ + return(0); +} +#endif + + +/* + * print_ksyms() + * + * This function outputs the kernel symbols + * of ksyms form got from a dump file. + */ +void +print_ksyms(void) +{ + syment_t *module_list_sym; /* refer the symbol "module_list" */ + struct module *next_module; /* modules are followed */ + struct module temp_module; /* searching module */ + struct module_symbol temp_syms; /* symbols are followed */ + char symbol_name[GK_LINE_LENGTH]; + char mod_name[GK_LINE_LENGTH]; /* symbol name, module name */ + int i, j; /* loop counter */ + k_error_t gb_error; /* GET_BLOCK result */ + + + kl_reset_error(); + + module_list_sym = kl_lkup_symname("module_list"); + if (module_list_sym == (syment_t *)NULL) { + KL_ERROR = KLE_NO_SYMBOLS; + return; + } + + /* searching module_list */ + gb_error = GET_BLOCK(module_list_sym->s_addr, + sizeof(struct module*), (void*)&next_module); + if (gb_error) { + KL_ERROR = gb_error; + return; + } + + if (next_module == NULL) { + KL_ERROR = KLE_INVALID_VADDR; + return; + } + + /* if each name longer than GK_LINE_LENGTH, can stop error*/ + mod_name[GK_LINE_LENGTH - 1] = '\0'; + symbol_name[GK_LINE_LENGTH - 1] = '\0'; + + /* searching all modules (and a kernel) */ + for (;next_module != NULL; next_module = temp_module.next) { + gb_error = GET_BLOCK(next_module, + sizeof(struct module), &temp_module); + if (gb_error) { + KL_ERROR = gb_error; + return; + } + if (temp_module.name == NULL) { + KL_ERROR = KLE_INVALID_VADDR; + return; + } + gb_error = GET_BLOCK(temp_module.name, + sizeof(char) * (GK_LINE_LENGTH - 1), mod_name); + if (gb_error) { + KL_ERROR = gb_error; + return; + } + + gb_error = GET_BLOCK(temp_module.syms, + sizeof(struct module_symbol), + (void*)&temp_syms); + if (gb_error) { + KL_ERROR = gb_error; + return; + } + + /* searching all symbols */ + for (i = 0; i < temp_module.nsyms; i++) { + gb_error = GET_BLOCK(&temp_module.syms[i], + sizeof(struct module_symbol), &temp_syms); + if (gb_error) { + KL_ERROR = gb_error; + return; + } + if (temp_syms.name == NULL) + continue; // need ? + + /* output */ + printf("%08x ", (unsigned long*)temp_syms.value); + j = 0; + do { + gb_error = GET_BLOCK(&temp_syms.name[(GK_LINE_LENGTH - 1) * j], + GK_LINE_LENGTH - 1, symbol_name); + if (gb_error) { + KL_ERROR = gb_error; + return; + } + printf("%s", symbol_name); + j++; + } while (strlen(symbol_name) == (GK_LINE_LENGTH - 1)); + + if (mod_name[0] != '\0') { + /* case of a module */ + printf("\t[%s", mod_name); + j = 1; + while (strlen(mod_name) == (GK_LINE_LENGTH - 1)) { + gb_error = GET_BLOCK(&temp_module.name[(GK_LINE_LENGTH - 1) * j], + GK_LINE_LENGTH - 1, mod_name); + if (gb_error) { + KL_ERROR = gb_error; + return; + } + printf("%s", mod_name); + j++; + } + printf("]"); + } + printf("\n"); + } + } +} + +/* + * main() + */ +int +main(int argc, char **argv) +{ + if (argc != 4) { + fprintf(stderr, "Usage: %s map vmdump kerntypes\n", argv[0]); + exit(1); + } + + /* Set up signal handler to handle SIGINT and to prevent lcrash + * from dumping core on SEGV and BUSERR signals. + */ + kl_sig_setup(); + + kl_init_klib(argv[1], argv[2], argv[3], 1); + if (KL_ERROR) { + if (KL_ERROR & (KLE_OPEN_ERROR|KLE_VMDUMP)) { + fprintf(KL_ERRORFP, "%s: ", argv[2]); + } else if (KL_ERROR & + (KLE_OPEN_ERROR|KLE_MAP_FILE|KLE_BAD_MAP_FILE)) { + fprintf(KL_ERRORFP, "%s: ", argv[1]); + } + kl_print_error(); + exit(1); + } + if (!STP) { + exit(1); + } + kl_init_kern_info(); + + /* output ksyms here */ + print_ksyms(); + if (KL_ERROR) { + if(KL_ERROR & (KLE_NO_SYMBOLS | KLE_INVALID_VALUE)) + fprintf(KL_ERRORFP, "module_list: "); + kl_print_error(); + exit(1); + } + + free_temp_blocks(); + exit(0); +} + + + + diff -Naur lkcdutils-1.0/lcd_ksyms/man/Makefile lkcdutils-1.0-1/lcd_ksyms/man/Makefile --- lkcdutils-1.0/lcd_ksyms/man/Makefile Thu Jan 1 09:00:00 1970 +++ lkcdutils-1.0-1/lcd_ksyms/man/Makefile Fri Aug 3 16:15:55 2001 @@ -0,0 +1,12 @@ +# +# Makefile for lcrash man library +# +# Copyright 1999 Silicon Graphics, Inc. All rights reserved. +# +DEPTH = .. + +all clean clobber install: default + +default: + +include $(TOPDIR)/Rules.make diff -Naur lkcdutils-1.0/lcd_ksyms/man/lcd_ksyms.1 lkcdutils-1.0-1/lcd_ksyms/man/lcd_ksyms.1 --- lkcdutils-1.0/lcd_ksyms/man/lcd_ksyms.1 Thu Jan 1 09:00:00 1970 +++ lkcdutils-1.0-1/lcd_ksyms/man/lcd_ksyms.1 Fri Aug 3 17:25:12 2001 @@ -0,0 +1,2 @@ + + diff -Naur lkcdutils-1.0/scripts/sbin.vmdump lkcdutils-1.0-1/scripts/sbin.vmdump --- lkcdutils-1.0/scripts/sbin.vmdump Wed Oct 18 05:58:50 2000 +++ lkcdutils-1.0-1/scripts/sbin.vmdump Fri Aug 3 18:06:08 2001 @@ -12,6 +12,7 @@ LCRASH=/sbin/lcrash MAP=/boot/System.map KERNTYPES=/boot/Kerntypes +LCD_KSYMS=/sbin/lcd_ksyms ########################################################################### # Functions @@ -101,6 +102,19 @@ /bin/cp -f $MAP map.$BOUNDS /bin/cp -f $LCRASH lcrash.$BOUNDS /bin/cp -f $KERNTYPES kerntypes.$BOUNDS + + $LCD_KSYMS map.$BOUNDS vmdump.$BOUNDS kerntypes.$BOUNDS \ + > temp_ksyms 2>/dev/null + if [ $? -ne 0 ] ; then + echo "Can not create a ksyms file." >&2 + exit 1 + fi + echo | /usr/bin/ksymoops -s temp_map -k temp_ksyms -L -m $MAP \ + -o /lib/modules/`uname -r`/ 1>/dev/null + awk '{print $1,$2,$3}' temp_map > map.$BOUNDS + /bin/rm -f temp_ksyms + /bin/rm -f temp_map + $LCRASH -r map.$BOUNDS vmdump.$BOUNDS kerntypes.$BOUNDS \ > analysis.$BOUNDS 2>&1 if [ $? -ne 0 ] ; then ------------------------------------ And the following is module program for test. ------------------------------------ #define MODULE #include #include static int *bomb; int init_module(void) { static void bomb_function(void); printk("Hello world.\n"); bomb_function(); return 0; } void cleanup_module(void) { printk("Good bye.\n"); } static void bomb_function(void) { bomb = 0x0; *bomb = 999; } ------------------------------------ The patch is applied as follows. in lkcdutils top directory $ tar zxvf lkcdutils-1.0-7.tar.gz $ cd lkcdutils-1.0 $ patch -p1 < patchfile $ ./configure --topdir=kernel directory $ make install $ insmod sys_crash.o And the loading module crashes system. A result. (a part of analysis file) $ lcrash -n 25 >> trace ================================================================ STACK TRACE FOR TASK: 0xc2a54000(insmod) 0 bomb_function+18 [0xc48af0ae] 1 init_module+22 [0xc48af076] 2 sys_init_module+1347 [0xc01147d3] 3 system_call+44 [0xc0106df4] ================================================================ A result of lcrash which didn't use the new map file. $ lcrash /boot/System.map-2.4.4 vmdump.25 kerntypes.25 >> trace ================================================================ STACK TRACE FOR TASK: 0xc2a54000(insmod) ================================================================ From owner-lkcd@oss.sgi.com Mon Aug 6 04:16:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76BGvP08437 for lkcd-outgoing; Mon, 6 Aug 2001 04:16:57 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76BGsV08420 for ; Mon, 6 Aug 2001 04:16:54 -0700 Received: (qmail 10173 invoked from network); 6 Aug 2001 11:16:50 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Aug 2001 11:16:50 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Masashige Kotani" cc: lkcd@oss.sgi.com Subject: Re: Module support In-reply-to: Your message of "Mon, 06 Aug 2001 19:25:43 +0900." <016301c11e62$26abb4e0$a04817ac@aoi.pst.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Aug 2001 21:16:49 +1000 Message-ID: <3877.997096609@ocs3.ocs-net> Sender: owner-lkcd@oss.sgi.com Precedence: bulk On Mon, 6 Aug 2001 19:25:43 +0900, "Masashige Kotani" wrote: > 1) Extarct symbol information of modules which were loaded at the > time of system crash from a dump file, > 2) Merge them to System.map, > 3) Save it as a map file which lcrash can read. >This command merges symbol information of modules and System.map by >using ksymoops. Looks good. A couple of minor points. You print addresses as %08x but 64 bit machines need %016x. Your traceback does not include the module name, almost every module has init_module() so you need to print the module name to distinguish between duplicate functions. From owner-lkcd@oss.sgi.com Mon Aug 6 10:55:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76HtmE19194 for lkcd-outgoing; Mon, 6 Aug 2001 10:55:48 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76HtkV19188 for ; Mon, 6 Aug 2001 10:55:46 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f76HqEs29387; Mon, 6 Aug 2001 10:52:14 -0700 Message-ID: <3B6EDA91.8C8F07F9@alacritech.com> Date: Mon, 06 Aug 2001 10:57:37 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Masashige Kotani , yakker@alacritech.com, lkcd@oss.sgi.com Subject: Re: Module support References: <20010717113618I.j-kondo@pst.fujitsu.com> <3B5552DF.1040103@pst.fujitsu.com> <016301c11e62$26abb4e0$a04817ac@aoi.pst.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Masashige Kotani wrote: > Hello. > I am a Jyunji's co-worker too. > I am making a new command for module support of lkcd as in the above mail. Hi, Masashige-san. I have no problems including this into the tree, as long as it isn't conflicting with Andreas' work, and it can be packaged nicely together. The conflict issue is just to make sure multiple LKCD developers are working on the same page. I'm all for the right thing going into the code base regardless, I just don't want to see conflicts in the way the work is completed. The other thing I need to know is that you are releasing this code under the GPL. Your copyright is included, which is fine, but I need to know that this code is GPL'd before I can include it into the LKCD source tree. Also, can I call this 'lkcd_ksyms'? I'd like to use that name instead of lcd_ksyms, for consistency with the package name. Otherwise, I can include this into the tree tonight. BTW, I'm almost done with the next revision of the patch (3.2), which has the dump_silence_system()/dump_resume_system(), changes to include gzip support, and a matching lkcdutils-3.2. I'm going to bump up the revision of lkcdutils to match that of the kernel patch. That way we have some more consistency with what is compatible with what. There are some big changes going into LKCD 3.2 to change tunable names, to allow for expandability for future enhancements. Are people reviewing the source tree? If so, I'll check my intermediate changes in for now so people can review them. Thanks! --Matt From owner-lkcd@oss.sgi.com Mon Aug 6 11:40:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f76Ieb021157 for lkcd-outgoing; Mon, 6 Aug 2001 11:40:37 -0700 Received: from mailgw1.br.ibm.com (igw1.br.ibm.com [32.96.196.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f76IeZV21154 for ; Mon, 6 Aug 2001 11:40:36 -0700 Received: from mailhub1.br.ibm.com (mailhub1.br.ibm.com [9.179.63.14]) by mailgw1.br.ibm.com (8.11.4/8.9.3) with ESMTP id f76Icpv27718 for ; Mon, 6 Aug 2001 15:38:51 -0300 Received: from d24bml07 (d24bml07.br.ibm.com [9.179.62.110]) by mailhub1.br.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76IeDO77664 for ; Mon, 6 Aug 2001 15:40:13 -0300 Importance: Normal Subject: Re: Msg: input buffer overflow in lcrash. To: lkcd@oss.sgi.com From: "Evandro Tadeu S Vargas" Date: Mon, 6 Aug 2001 15:40:10 -0300 Message-ID: X-MIMETrack: Serialize by Router on d24bml07/24/M/IBM(Release 5.0.6a |January 17, 2001) at 06/08/2001 03:40:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi folks, I executed the 'make' again without parm '-l' (in usr/bin/lex file - Suse) and worked fine. Thanks Luc. Evandro Vargas IGS Brasil From owner-lkcd@oss.sgi.com Tue Aug 7 04:20:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77BKpb07919 for lkcd-outgoing; Tue, 7 Aug 2001 04:20:51 -0700 Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77BKnV07907 for ; Tue, 7 Aug 2001 04:20:49 -0700 Received: from m2.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id UAA06173; Tue, 7 Aug 2001 20:20:36 +0900 (JST) (envelope-from m-kotani@pst.fujitsu.com) Received: from classic.aoi.pst.fujitsu.com by m2.gw.fujitsu.co.jp (8.9.3/3.7W-0108-Fujitsu Domain Master) id UAA02229; Tue, 7 Aug 2001 20:20:33 +0900 (JST) (envelope-from m-kotani@pst.fujitsu.com) Received: from doll (dhcp72160.aoi.pst.fujitsu.com [172.23.72.160]) by classic.aoi.pst.fujitsu.com (8.9.3/8.9.3) with SMTP id UAA09856; Tue, 7 Aug 2001 20:20:30 +0900 Message-ID: <00b801c11f33$2fdb9f40$a04817ac@aoi.pst.fujitsu.com> From: "Masashige Kotani" To: "Matt D. Robinson" , References: <20010717113618I.j-kondo@pst.fujitsu.com> <3B5552DF.1040103@pst.fujitsu.com> <016301c11e62$26abb4e0$a04817ac@aoi.pst.fujitsu.com> <3B6EDA91.8C8F07F9@alacritech.com> Subject: Re: Module support Date: Tue, 7 Aug 2001 20:22:03 +0900 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.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-lkcd@oss.sgi.com Precedence: bulk > Masashige Kotani wrote: > > Hello. > > I am a Jyunji's co-worker too. > > I am making a new command for module support of lkcd as in the above mail. > > Hi, Masashige-san. I have no problems including this into the tree, > as long as it isn't conflicting with Andreas' work, and it can be > packaged nicely together. The conflict issue is just to make sure > multiple LKCD developers are working on the same page. I'm all for > the right thing going into the code base regardless, I just don't > want to see conflicts in the way the work is completed. lkcd_ksyms and symtab subcommand has the overlapped function (use the nm command), and it becomes unnecessary to use symtab. I think debugging that will becomes easy, if it uses with lkcd_ksyms reproducing the module command and /proc/ksyms reproducing /proc/modules. > > The other thing I need to know is that you > are releasing this code under the GPL. Your copyright is included, > which is fine, but I need to know that this code is GPL'd before > I can include it into the LKCD source tree. There is no probrem to apply GPL to this code. > > Also, can I call this 'lkcd_ksyms'? I'd like to use that name instead > of lcd_ksyms, for consistency with the package name. I agree entirely. Please call it 'lkcd_ksyms'. > > Otherwise, I can include this into the tree tonight. > > BTW, I'm almost done with the next revision of the patch (3.2), which > has the dump_silence_system()/dump_resume_system(), changes to include > gzip support, and a matching lkcdutils-3.2. I'm going to bump up the > revision of lkcdutils to match that of the kernel patch. That way we > have some more consistency with what is compatible with what. > > There are some big changes going into LKCD 3.2 to change tunable names, > to allow for expandability for future enhancements. > > Are people reviewing the source tree? If so, I'll check my intermediate > changes in for now so people can review them. > > Thanks! > > --Matt > Thanks! --Masashige From owner-lkcd@oss.sgi.com Tue Aug 7 04:21:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77BLc508050 for lkcd-outgoing; Tue, 7 Aug 2001 04:21:38 -0700 Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77BLbV08047 for ; Tue, 7 Aug 2001 04:21:37 -0700 Received: from m6.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id UAA09234; Tue, 7 Aug 2001 20:21:24 +0900 (JST) (envelope-from m-kotani@pst.fujitsu.com) Received: from classic.aoi.pst.fujitsu.com by m6.gw.fujitsu.co.jp (8.9.3/3.7W-0108-Fujitsu Domain Master) id UAA08704; Tue, 7 Aug 2001 20:21:23 +0900 (envelope-from m-kotani@pst.fujitsu.com) Received: from doll (dhcp72160.aoi.pst.fujitsu.com [172.23.72.160]) by classic.aoi.pst.fujitsu.com (8.9.3/8.9.3) with SMTP id UAA09901; Tue, 7 Aug 2001 20:21:21 +0900 Message-ID: <00b901c11f33$4dbfe7a0$a04817ac@aoi.pst.fujitsu.com> From: "Masashige Kotani" To: , "Keith Owens" References: <3877.997096609@ocs3.ocs-net> Subject: Re: Module support Date: Tue, 7 Aug 2001 20:22:54 +0900 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.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-lkcd@oss.sgi.com Precedence: bulk > On Mon, 6 Aug 2001 19:25:43 +0900, > "Masashige Kotani" wrote: > > 1) Extarct symbol information of modules which were loaded at the > > time of system crash from a dump file, > > 2) Merge them to System.map, > > 3) Save it as a map file which lcrash can read. > >This command merges symbol information of modules and System.map by > >using ksymoops. > > Looks good. A couple of minor points. You print addresses as %08x but > 64 bit machines need %016x. Your traceback does not include the module > name, almost every module has init_module() so you need to print the > module name to distinguish between duplicate functions. > Although it cannot test since there is no 64 bit machine, I found that lkcdutils has print_kaddr() in each architectures. It will output address by using printing address format. About init_module, I'm thinking now. For example, Module names are added to symbol names. (only init_module and cleanup_module? the other symbols do it?) Lcrash library is changed so that a module name can print. What do you think? Thanks! --Masashige From owner-lkcd@oss.sgi.com Tue Aug 7 15:40:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77MeEm04934 for lkcd-outgoing; Tue, 7 Aug 2001 15:40:14 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77MeCV04929 for ; Tue, 7 Aug 2001 15:40:12 -0700 Received: (qmail 28545 invoked from network); 7 Aug 2001 22:40:07 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 7 Aug 2001 22:40:07 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Masashige Kotani" cc: lkcd@oss.sgi.com Subject: Re: Module support In-reply-to: Your message of "Tue, 07 Aug 2001 20:22:54 +0900." <00b901c11f33$4dbfe7a0$a04817ac@aoi.pst.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 08:40:06 +1000 Message-ID: <24330.997224006@ocs3.ocs-net> Sender: owner-lkcd@oss.sgi.com Precedence: bulk On Tue, 7 Aug 2001 20:22:54 +0900, "Masashige Kotani" wrote: >Module names are added to symbol names. >(only init_module and cleanup_module? the other symbols do it?) >Lcrash library is changed so that a module name can print. >What do you think? Do what ksymoops does. Print module symbols prefixed by [module_name]. From owner-lkcd@oss.sgi.com Tue Aug 7 16:34:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f77NYPZ12923 for lkcd-outgoing; Tue, 7 Aug 2001 16:34:25 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f77NYNV12915 for ; Tue, 7 Aug 2001 16:34:23 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f77NUts11591; Tue, 7 Aug 2001 16:30:55 -0700 Message-ID: <3B707B75.845B3ADF@alacritech.com> Date: Tue, 07 Aug 2001 16:36:21 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Masashige Kotani CC: lkcd@oss.sgi.com Subject: Re: Module support References: <20010717113618I.j-kondo@pst.fujitsu.com> <3B5552DF.1040103@pst.fujitsu.com> <016301c11e62$26abb4e0$a04817ac@aoi.pst.fujitsu.com> <3B6EDA91.8C8F07F9@alacritech.com> <00b801c11f33$2fdb9f40$a04817ac@aoi.pst.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Masashige Kotani wrote: > > > Masashige Kotani wrote: > > > Hello. > > > I am a Jyunji's co-worker too. > > > I am making a new command for module support of lkcd as in the above > mail. > > > > Hi, Masashige-san. I have no problems including this into the tree, > > as long as it isn't conflicting with Andreas' work, and it can be > > packaged nicely together. The conflict issue is just to make sure > > multiple LKCD developers are working on the same page. I'm all for > > the right thing going into the code base regardless, I just don't > > want to see conflicts in the way the work is completed. > > lkcd_ksyms and symtab subcommand has the overlapped function (use the nm > command), and it becomes unnecessary to use symtab. That's fine -- again, I don't mind that there are different ways of doing this, as I suspect at some point some of this methodology is going to merge regardless. > I think debugging that will becomes easy, if it uses with lkcd_ksyms > reproducing the module command and /proc/ksyms reproducing /proc/modules. > > > > > The other thing I need to know is that you > > are releasing this code under the GPL. Your copyright is included, > > which is fine, but I need to know that this code is GPL'd before > > I can include it into the LKCD source tree. > > There is no probrem to apply GPL to this code. Okay, then I can put it in. It will be released under the GPL. > > Also, can I call this 'lkcd_ksyms'? I'd like to use that name instead > > of lcd_ksyms, for consistency with the package name. > > I agree entirely. Please call it 'lkcd_ksyms'. Great. > > > > Otherwise, I can include this into the tree tonight. > > > > BTW, I'm almost done with the next revision of the patch (3.2), which > > has the dump_silence_system()/dump_resume_system(), changes to include > > gzip support, and a matching lkcdutils-3.2. I'm going to bump up the > > revision of lkcdutils to match that of the kernel patch. That way we > > have some more consistency with what is compatible with what. > > > > There are some big changes going into LKCD 3.2 to change tunable names, > > to allow for expandability for future enhancements. > > > > Are people reviewing the source tree? If so, I'll check my intermediate > > changes in for now so people can review them. > > > > Thanks! > > > > --Matt > > > > Thanks! > > --Masashige --Matt From owner-lkcd@oss.sgi.com Thu Aug 9 02:28:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f799SgH32261 for lkcd-outgoing; Thu, 9 Aug 2001 02:28:42 -0700 Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f799SdV32258 for ; Thu, 9 Aug 2001 02:28:40 -0700 Received: from m1.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0104-Fujitsu Gateway) id SAA00970; Thu, 9 Aug 2001 18:28:17 +0900 (JST) (envelope-from m-kotani@pst.fujitsu.com) Received: from classic.aoi.pst.fujitsu.com by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0108-Fujitsu Domain Master) id SAA27820; Thu, 9 Aug 2001 18:28:10 +0900 (JST) (envelope-from m-kotani@pst.fujitsu.com) Received: from doll (dhcp72160.aoi.pst.fujitsu.com [172.23.72.160]) by classic.aoi.pst.fujitsu.com (8.9.3/8.9.3) with SMTP id SAA08098; Thu, 9 Aug 2001 18:28:02 +0900 Message-ID: <002301c120b5$d2a23620$a04817ac@aoi.pst.fujitsu.com> From: "Masashige Kotani" To: "Keith Owens" , "Matt D. Robinson" Cc: References: <24330.997224006@ocs3.ocs-net> Subject: Re: Module support Date: Thu, 9 Aug 2001 18:29:41 +0900 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-lkcd@oss.sgi.com Precedence: bulk ----- Original Message ----- From: Keith Owens To: Masashige Kotani Cc: Sent: Wednesday, August 08, 2001 7:40 AM Subject: Re: Module support > >Module names are added to symbol names. > >(only init_module and cleanup_module? the other symbols do it?) > >Lcrash library is changed so that a module name can print. > >What do you think? > > Do what ksymoops does. Print module symbols prefixed by [module_name]. > OK. I will fix lkcd_ksyms according to your comment. However, this fix will forces users to specify symbol names in modules with prefixed by [module]. Like this, >> sym [modulename]symbol Matt, is this accepted? --Masashige From owner-lkcd@oss.sgi.com Fri Aug 10 07:42:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AEg4k14215 for lkcd-outgoing; Fri, 10 Aug 2001 07:42:04 -0700 Received: from ureach.com (mail.ureach.com [63.150.151.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AEg3V14212 for ; Fri, 10 Aug 2001 07:42:03 -0700 Received: from www23.ureach.com (IDENT:root@www23.ureach.com [172.16.2.51]) by ureach.com (8.9.1/8.8.5) with ESMTP id KAA12794 for ; Fri, 10 Aug 2001 10:41:58 -0400 Received: (from nobody@localhost) by www23.ureach.com (8.9.3/8.9.1) id KAA17918; Fri, 10 Aug 2001 10:41:58 -0400 Date: Fri, 10 Aug 2001 10:41:58 -0400 Message-Id: <200108101441.KAA17918@www23.ureach.com> To: lkcd@oss.sgi.com From: Kapish K Reply-to: Subject: query on dump Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hello, One quick question. We have configured a system to dump and everything is set up properly. The kernel panics and Oopses, but we do not get any dump at all. log shows dumpdevice having been opened with a value ( 305 for dumpdev in hex ).. just got this problem now...shall look into this... but in the meanwhile, any ideas why we should not see a dump at all?? Kindly cc to the id, as I don't think I am on the list. TIA ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From owner-lkcd@oss.sgi.com Fri Aug 10 15:06:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7AM67r30639 for lkcd-outgoing; Fri, 10 Aug 2001 15:06:07 -0700 Received: from ureach.com (mail.ureach.com [63.150.151.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7AM66V30635 for ; Fri, 10 Aug 2001 15:06:06 -0700 Received: from www23.ureach.com (IDENT:root@www23.ureach.com [172.16.2.51]) by ureach.com (8.9.1/8.8.5) with ESMTP id SAA17190 for ; Fri, 10 Aug 2001 18:06:00 -0400 Received: (from nobody@localhost) by www23.ureach.com (8.9.3/8.9.1) id SAA06906; Fri, 10 Aug 2001 18:06:00 -0400 Date: Fri, 10 Aug 2001 18:06:00 -0400 Message-Id: <200108102206.SAA06906@www23.ureach.com> To: lkcd@oss.sgi.com From: Kapish K Reply-to: Subject: hang while dumping Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hello, the earlier Oops wasn't dumping, 'coz I guess it was taking way too long dumping the whole call trace out - why, I don't know. It takes about 30 - 40 mins of call trace dumping to screen that it does when the system oopses and then we see no dump. Turned the call trace code print code off, and then we see that the dump just hangs - at 'Writing dump pages' .... But it gets to the dump facility from an oops - so, is it because the system is not quite oopsed in the sense that there still is some activity going on , in the system, while its dumping, and hence it is hanging at something? another observation is that at that point, a ping to the system does work - meaning the network card seems to be able to receive packets.. any suggestions or ideas as to what this could imply would be most welcome.. TIA ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From owner-lkcd@oss.sgi.com Mon Aug 13 10:41:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7DHfAf14453 for lkcd-outgoing; Mon, 13 Aug 2001 10:41:10 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7DHf8j14449 for ; Mon, 13 Aug 2001 10:41:09 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f7DHZBO04392; Mon, 13 Aug 2001 10:35:16 -0700 Message-ID: <3B78119B.E315F431@alacritech.com> Date: Mon, 13 Aug 2001 10:42:51 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: kapish@ureach.com CC: lkcd@oss.sgi.com Subject: Re: hang while dumping References: <200108102206.SAA06906@www23.ureach.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Kapish K wrote: > > Hello, > the earlier Oops wasn't dumping, 'coz I guess it was > taking way too long dumping the whole call trace out - why, I > don't know. It takes about 30 - 40 mins of call trace dumping to > screen that it does when the system oopses and then we see no > dump. Turned the call trace code print code off, and then we see > that the dump just hangs - at 'Writing dump pages' .... But it > gets to the dump facility from an oops - so, is it because the > system is not quite oopsed in the sense that there still is some > activity going on , in the system, while its dumping, and hence > it is hanging at something? another observation is that at that > point, a ping to the system does work - meaning the network card > seems to be able to receive packets.. > any suggestions or ideas as to what this could imply would be > most welcome.. > TIA Hi, Kapish. Sorry for the delay in response. My first recommendation is to take the last patch posted to this list (look at the archives on LKCD, and you'll see it there). If you don't find it, E-mail me directly. That patch includes some fixes for dump_silence_system(). It doesn't take care of everything, but does resolve most things. There's an additional patch from Tony at Storigen that I'm reviewing now to see if it deals with all the rest of the interrupt hangs. Let me know what happens. Thanks. --Matt From owner-lkcd@oss.sgi.com Wed Aug 15 15:51:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7FMpPV23405 for lkcd-outgoing; Wed, 15 Aug 2001 15:51:25 -0700 Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7FMpKj23359 for ; Wed, 15 Aug 2001 15:51:22 -0700 Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04578 for ; Wed, 15 Aug 2001 15:51:14 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 15:50:18 -0700 Message-ID: From: Hiro Sugawara To: "'lkcd@oss.sgi.com'" Subject: RE: Module support Date: Wed, 15 Aug 2001 15:50:17 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-lkcd@oss.sgi.com Precedence: bulk Hi, I'd like to report that I have partially implemented our own kernel modules support in lcrash. It is still "partial" because I have only verified in live debug mode using /dev/kmem. But I believe it is not too difficult to make this available also for crash dumps. Having been watching the discussions here, I noticed most participants assume to use LKCD in workstation type environments, which is different from our embedded Linux application in a few key aspects. So, I decided to develop our own way and to take the risk of code diversion from the main line. Well, here are the main things I've so far implemented: - Cross debugging from SunOS to PPC Linux LCRASH runs on a SunOS 5 (a.k.a. Solaris 2) workstation to analyze the kernel memory of a PPC Linux target. - Read-only live kernel debugging over TCP/IP The target Linux system runs a modified version of GDBSERVER. LCRASH on the host and GDBSERVER on the target communicate with each other over a TCP/IP socket (serial line possible as well) for reading the target's memory contents. If the vmdump file name is in the form of "xxxx:yyyy," LCRASH will interpret this as "xxxx" is the target's host name or IP address and that "yyyy" is the port number and will open a socket. If the vmdump file is a tty, LCRASH will open the serial port for communication. The protocol is based on the GDB/GDBSERVER protocol with minor enhancements. - Accessing virtual addresses LCRASH (GDBSERVER) uses /dev/kmem, not /dev/mem, for accessing the target's kernel memory for two reasons: 1) A simple port of x86 code for PPC could not correctly access addresses above high_memory probably because of some MMU difference; 2) Due to our limited crash dump device size, we must implement a selective dumping scheme which will save only the "interesting" memory segments and will anyway need to work in the virtual address space. - No use of System.map To reduce the number of files to be archived for each release, I made LCRASH use the ELF kernel executable with full debug information for both kernel symbols and kernel structure information. LCRASH popen's "nm vmlinux|grep xyz" internally. This eliminates the need of separate "systypes" file creation (and archiving) as well. - Modules support Before going to show the prompt, LCRASH reads the target memory around "module_list" to assemble an internal kernel module list for the target. This has been the case for live kernel debugging. We may attach a kernel module directory structure to the crash dump when we are ready to deal with a real kernel crash dump. The new "module" command takes one argument to tell it the "root" directory location of the target file system image visible on the host's file system. Under this directory, LCRASH reads each module file listed in the internal module list, relocates its symbols according to the relocation base addresses in the list, then adds those symbols to LCRASH's internal symbol B-tree. For example, for "module /home/hiro/oss," the target's "/lib/modules/xyz.o" module is read from "/home/hiro/oss/lib/modules/xyz.o" on the host. So far my LCRASH is working fine as a read-only kernel debugger with the desired modules support. I need to make the real crash dump analysis available with the above features. Then I plan to implement a couple of more enhancements like vmdump to ELF core file for using GDB for source level analysis, etc. -------- BTW, I've noticed a couple of issues in the current LCRASH source code like... - Non-stopping Makefiles The whole make process from the top continues to the end even if a make in a subdirectory fails. This pretends that the make process was successful and thus often appears very misleading. - Misleading naming "vmdump" should be called "pmdump" because it is a physical memory; "core_kmem" should be called "core_mem" because it accesses /dev/mem, not /dev/kmem. - No endian consideration Probably because LCRASH was developed with only self-operation in mind, there's no endian care: kl_int() and its relatives do not work in a cross environment where the host and the target have different endians. Regards, hiro From owner-lkcd@oss.sgi.com Thu Aug 16 06:03:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GD3ss27900 for lkcd-outgoing; Thu, 16 Aug 2001 06:03:54 -0700 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GD3mj27896 for ; Thu, 16 Aug 2001 06:03:49 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA141464; Thu, 16 Aug 2001 15:03:30 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GD3TB86974; Thu, 16 Aug 2001 15:03:29 +0200 Importance: Normal Subject: new lcrash features To: lkcd@oss.sgi.com Cc: "Matt D. Robinson" , "Tom Morano" X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Thu, 16 Aug 2001 15:01:27 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 16/08/2001 15:01:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Today I have checked in several files to sourceforge. The changes affect the directory lkcdutils. Path names below are relative to this directory. Here is a list of the changed files (some files are mentioned several times): ./configure ./get_bfd_version.c -> added ./lcrash/include/dis-asm.h Support for different binutils versions while configuring lcrash (needed for dis command for most platforms). There was a change in a common structure in dis-asm.h and hence the usage of libopcodes.a was influenced (binutils starting from version 2.11 are affected). This was leading to a SIGSEGV in lcrash, and causing dis command to fail - depending on which version of libopcode.a was installed on the system. Lcrash works now with both versions of libopcodes.a. ./lcrash/arch/s390/lib/dis.c ./lcrash/arch/s390/lib/trace.c ./lcrash/include/arch-s390/trace.h ./libklib/include/asm-s390/kl_arch.h s390 specific changes ./libklib/include/kl_btnode.h ./libklib/kl_btnode.c Make usage of real AVL-tree. Reason for change: low performance of old implementation of an balanced binary tree. This changes are due to Michael Geselbracht. ./lcrash/cmds/Makefile ./lcrash/cmds/cmds.c Changes needed for removal/introduction of old/new lcrash commands and aliases. ./lcrash/include/lcrash.h ./lcrash/cmds/command.c ./lcrash/main.c Introduction of an iteration threshold. Can be used to avoid endless loops. Such loops can easily occur when broken next pointers are followed in the dump This threshold value can currently be changed by commands walk and module (default is 10000). It is used in loops when walking through chained lists (walk_structs()), and when reading module information (like module symbols) from the dump. ./lcrash/cmds/cmd_addtypes.c -> removed ./lcrash/cmds/cmd_namelist.c Integrate handling of namelists in one command. Use 'namelist -a' to add new namelists. 'addtypes' is an alias for this. ./lcrash/cmds/cmd_sizeof.c 'sizeof -o struct.field' returns offset of field in struct. An alias 'offset' exists for this. Sure, this is not the best solution for an offset command, but as I found out it was the very easiest one. :) ./lcrash/cmds/cmd_walk.c New feature to walk through 'list_head' structures instead of using next pointers. Support for iteration threshold. ./lcrash/cmds/cmd_symbol.c -> removed ./lcrash/cmds/cmd_symtab.c -> added ./lcrash/cmds/cmd_findsym.c ./lcrash/util.c ./libklib/include/kl_sym.h -> added ./libklib/include/klib.h ./libklib/kl_symbol.c ./libklib/klib.c Support for multiple symbol tables. 'symbol' became obsolete when 'symtab' was introduced. An alias 'symbol' exists for 'findsym'. With 'findsym -f' you can search for symbols comparing only the first characters of all symbols (internally a strncmp() is performed). An additional symbol table (besides System.map) is loaded during startup of lcrash. It contains exported kernel symbols and is named __ksymtab__. As all other symbol tables, this table can be removed and recreated in lcrash using the 'symtab' command. Recreation of __ksymtab__ becomes necessary when analyzing a live system and some modules are (remove and) added. ./libklib/include/asm-alpha/kl_sym.h -> removed ./libklib/include/asm-i386/kl_sym.h -> removed ./libklib/include/asm-ia64/kl_sym.h -> removed ./libklib/include/asm-s390/kl_sym.h -> removed ./libklib/include/kl_sym.h -> added Because asm-*/kl_sym.h did not contain any arch dependent/specific stuff, one common file kl_sym.h is used for all platforms. ./lcrash/Makefile ./lcrash/module.c -> added ./lcrash/struct.c ./lcrash/include/lcrash.h ./libklib/kl_util.c Support for struct module. Like task_struct the struct module has now predifined print functions. ./lcrash/cmds/cmd_module.c -> added ./lcrash/include/lcrash.h New command module for viewing loaded modules and to display exported kernel/module symbols. ./lcrash/include/command.h ./lcrash/struct.c Support for struct list_head in walk command. ./libklib/kl_stabs.c Bug fix: st_member_offset should return negative value to indicate an error. Bug fix: sizeof command supports now also typedefs. ./lcrash/cmds/cmd_whatis.c Bug fix: whatis command works now correct for typedefs of typedefs. ./libklib/include/kl_typeinfo.h ./lcrash/include/lcrash.h Changed values of flags. The revision before my changes in lkcdutils are tagged in the cvs repository. I used a sticky tag 'before_module_support'. That means everyone is able to receive the former lcrash version (as of 20001/08/15) by using: "cvs checkout -r before_module_support lkcdutils" (see lkcd sourceforge web side for additional parameters) It is even possible to work in that branch, if there are any conflicts with the new stuff. I plan to put another mail to the list to describe the new features a little bit. Sorry for the delay in checking in the new stuff. This was due to an internal legal clearance process that we must pass when putting new things to open source. I know especially regarding module support of lcrash some people have waited to look at the stuff I have done ... Regards, Andreas -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com From owner-lkcd@oss.sgi.com Thu Aug 16 09:51:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GGpw401585 for lkcd-outgoing; Thu, 16 Aug 2001 09:51:58 -0700 Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GGplj01582 for ; Thu, 16 Aug 2001 09:51:47 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA65466 for ; Thu, 16 Aug 2001 18:51:37 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GGpbS27208 for ; Thu, 16 Aug 2001 18:51:37 +0200 Importance: Normal Subject: description: walk To: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Thu, 16 Aug 2001 18:49:34 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 16/08/2001 18:49:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Here is some description about walk command regarding list_head support and use of iteration_threshold. (my comments are surrounded by /* */) >> ? walk COMMAND: walk -l struct field|offset addr [-f] [-n] [-h n|p] struct field|offset addr -s [-h n|p] struct field|offset addr -h n|p -t address offset size [-i iteration_threshold] [-w outfile] Walk a linked list of kernel structures or memory blocks. OPTIONS: -l Show a list of special structures that can be displayed in a predefined formatted manner. Currently there is support for a handful special structures. struct field|offset addr [-f] [-n] [-h n|p] Display each entry of a linked list of special structures in a predefined formatted way. By default the output consists of one line for each structure. Using "-f" and/or "-n" a more detailed output is given. "-f" can be used for all special structures. "-n" works for special structures mm_struct and task_struct. struct field|offset addr -s [-h n|p] Each structure of a linked list is displayed in its entirety - in a C-like format. All structures for which type information is available can be displayed in this manner. -h n|p A linked list is constructed by following 'list_head' structures instead of next pointers. The argument specifies wether to follow the next pointers of struct list_head (using 'n') or to follow the prev pointers of struct list_head (by using 'p'). 'field' or 'offset' is regarded as a member of type 'list_head' instead of a next pointer within the 'struct'. 'addr' is interpreted as a pointer to an anchor of a linked list of 'struct list_head' structures. struct field|offset addr -h n|p -t Display each entry of a linked 'list_head'-list in one line. For each entry the address to the 'struct' structure, the address to the 'list_head' member within 'struct', and previous and next pointer of the embedded 'list_head' are given. address offset size Do a hex memory dump of each structure in a list. A start address ('address') of a structure, a byte offset ('offset') for the next pointer in the structure, and a structure size ('size') are required. 'size' bytes will be dumped for each entry in the constructed list. -i iteration_threshold By default certain loops are interrupted after 10'000 iterations to avoid endless loops while following invalid pointers. Using this option you can change the threshold for the current command. A value '0' means infinite iteration threshold, i.e. no interruption of the loop is caused by reaching the threshold. While using "struct field|offset addr" without "-h" a structure name ('struct'), a field name ('field') or byte offset ('offset') for the next pointer within the structure, and a pointer ('addr') to the first entry of the linked list must be given. Note: Using "-h" the anchor is not displayed as a structure 'struct'. /* Example 1: walking through list_head lists Lets see of what use are list_head structures. */ >> task ADDR UID PID PPID STATE FLAGS NAME =============================================================================== 0x1ac000 0 0 0 0 0 swapper 0x9dc000 0 1 0 1 0x100 init 0x9bc000 0 2 1 1 0x40 kmcheck 0x9b4000 0 3 1 1 0x40 keventd 0x960000 0 4 1 1 0x840 kswapd 0x95c000 0 5 1 1 0x840 kreclaimd 0x958000 0 6 1 1 0x40 bdflush 0x954000 0 7 1 2 0x40 kupdated 0x7844000 0 63 1 1 0x40 mdrecoveryd 0x73cc000 0 303 1 2 0x40 syslogd 0x7c24000 0 308 1 1 0x140 klogd 0x697c000 32 318 1 1 0x140 portmap 0x6910000 29 331 1 1 0x140 rpc.statd 0x66cc000 0 378 1 1 0x140 sshd 0x6644000 0 394 1 1 0x140 xinetd 0x61a0000 0 413 1 1 0x140 sendmail 0x7da4000 0 424 1 1 0x40 crond 0x5d48000 43 522 1 1 0x140 xfs 0x7db8000 0 542 1 1 0x100 login 0x5904000 0 615 542 1 0x100 bash 0x5688000 0 680 3 1 0x40 keventd 0x55f4000 0 848 615 0 0 cat 0x568c000 0 849 394 0 0x100 in.telnetd 0x5594000 0 850 849 0 0 login =============================================================================== 24 active task structs found >> offset task_struct.run_list Offset: 104 bytes. /* task_struct.run_list is of type (list_head*) */ >> print 0x5594000+104 -x 0x5594068 /* Now we've got a pointer to a list_head, we use it as the anchor */ >> walk task_struct run_list 0x5594068 -h n -t STRUCT ADDR PREV LISTHEAD NEXT ============================================================================ 0 0x568c068 0x5594068 0x55f4068 0x55f4000 0x5594068 0x55f4068 0x1b25b0 0x1b2548 0x55f4068 0x1b25b0 0x568c068 0x568c000 0x1b25b0 0x568c068 0x5594068 ============================================================================ >> walk task_struct run_list 0x5594068 -h n ADDR UID PID PPID STATE FLAGS NAME =============================================================================== 0x55f4000 0 848 615 0 0 cat 0x1b2548 1780328 0 0 0 0 0x568c000 0 849 394 0 0x100 in.telnetd =============================================================================== /* We have chosen a wrong anchor, the 2nd element seems not to be a task_struct. You can see this by looking up 0x1b2548 in the task table above. So we choose this 2nd element as the new anchor. Take care, it corresponds to the 3rd element in the table before the last one. Up there we get from line 3, column 3 the desired address of the anchor: 0x1b25b0. */ >> walk task_struct run_list 0x1b25b0 -h n -t STRUCT ADDR PREV LISTHEAD NEXT ============================================================================ 0 0x55f4068 0x1b25b0 0x568c068 0x568c000 0x1b25b0 0x568c068 0x5594068 0x5594000 0x568c068 0x5594068 0x55f4068 0x55f4000 0x5594068 0x55f4068 0x1b25b0 ============================================================================ >> walk task_struct run_list 0x1b25b0 -h n ADDR UID PID PPID STATE FLAGS NAME =============================================================================== 0x568c000 0 849 394 0 0x100 in.telnetd 0x5594000 0 850 849 0 0 login 0x55f4000 0 848 615 0 0 cat =============================================================================== /* Cool. What we've got is the list of running tasks. What a waste of time. We could have seen this by looking up "STATE 0" processes in the task table above. But, let's look for more information about the anchor: */ >> fsym 0x1b25b0 ADDR OFFSET TYPE NAME ============================================================ 0x1b25b0 0 LOCAL_DATA runqueue_head ============================================================ 1 symbol found /* Ok, makes sens to me. */ /* Using '-h p' changes the direction of our walk: */ >> walk task_struct run_list 0x1b25b0 -h p ADDR UID PID PPID STATE FLAGS NAME =============================================================================== 0x55f4000 0 848 615 0 0 cat 0x5594000 0 850 849 0 0 login 0x568c000 0 849 394 0 0x100 in.telnetd =============================================================================== >> walk task_struct run_list 0x1b25b0 -h p -t STRUCT ADDR NEXT LISTHEAD PREV ============================================================================ 0 0x568c068 0x1b25b0 0x55f4068 0x55f4000 0x1b25b0 0x55f4068 0x5594068 0x5594000 0x55f4068 0x5594068 0x568c068 0x568c000 0x5594068 0x568c068 0x1b25b0 ============================================================================ /* Example 2: iteration threshold */ >> fsym inode_in_use inode_unused /* Further anchors of some list_head lists. */ ADDR OFFSET TYPE NAME ============================================================ 0xc0243e40 0 GLOBAL_DATA inode_in_use 0xc0243e48 0 LOCAL_DATA inode_unused ============================================================ 2 symbols found >> walk inode i_list 0xc0243e40 -h n Neither a "predefined"structure, nor options '-s' or '-t' specified. Can't print structure. /* Bad luck. We will use '-t' and not '-s' for this demonstration. (Just take a look at 'whatis inode', and you know why.) */ >> walk inode i_list 0xc0243e40 -h n -t STRUCT ADDR PREV LISTHEAD NEXT ============================================ 0 0xcff38008 0xc0243e40 0xc5501c38 WARNING: Pointer broken. 0xc579c3e0, SHOULD BE: 0xc0243e40 0xc5501c30 0xc579c3e0 0xc5501c38 0xc6314f68 0xc6314f60 0xc5501c38 0xc6314f68 0xc2c44e20 0xc2c44e18 0xc6314f68 0xc2c44e20 0xc8671340 0xc8671338 0xc2c44e20 0xc8671340 0xc54da528 0xc54da520 0xc8671340 0xc54da528 0xcbde6528 0xcbde6520 0xc54da528 0xcbde6528 0xcf8771f8 ... 0xcaa8f710 0xca663340 0xcaa8f718 0xcb472b90 0xcb472b88 0xcaa8f718 0xcb472b90 0xcb3e8b90 0xcb3e8b88 0xcb472b90 0xcb3e8b90 0xcb3e9af0 0xcb3e9ae8 0xcb3e8b90 0xcb3e9af0 0xcc279860 0xcc279858 0xcb3e9af0 0xcc279860 0xcc2f9488 0xcc2f9480 0xcc279860 0xcc2f9488 0xcd00c900 0xcd00c8f8 0xcc2f9488 0xcd00c900 0xcceeb488 WARNING: Iteration threshold reached. Current threshold: 10000. Use "-i" to change threshold. /* Ooops, something broken ... My dump was generated using 'livedump' in lcrash. So probably some inodes have changed. Furthermore the default iteration threshold was reached. We try again without any threshold value: */ >> walk inode i_list 0xc0243e40 -h n -t -i 0 STRUCT ADDR PREV LISTHEAD NEXT ============================================ 0 0xcff38008 0xc0243e40 0xc5501c38 WARNING: Pointer broken. 0xc579c3e0, SHOULD BE: 0xc0243e40 0xc5501c30 0xc579c3e0 0xc5501c38 0xc6314f68 0xc6314f60 0xc5501c38 0xc6314f68 0xc2c44e20 0xc2c44e18 0xc6314f68 0xc2c44e20 0xc8671340 0xc8671338 0xc2c44e20 0xc8671340 0xc54da528 0xc54da520 0xc8671340 0xc54da528 0xcbde6528 0xcbde6520 0xc54da528 0xcbde6528 0xcf8771f8 ... 0xcfbfe7b0 0xcf985488 0xcfbfe7b8 0xcf8df9a8 0xcf8df9a0 0xcfbfe7b8 0xcf8df9a8 0xcf9383e0 0xcf9383d8 0xcf8df9a8 0xcf9383e0 0xcfbfe298 0xcfbfe290 0xcf9383e0 0xcfbfe298 0xcfbfe3e0 0xcfbfe3d8 0xcfbfe298 0xcfbfe3e0 0xcfbfe528 0xcfbfe520 0xcfbfe3e0 0xcfbfe528 0xcfbff340 0xcfbff338 0xcfbfe528 0xcfbff340 0xcff38e20 0xcff38e18 0xcfbff340 0xcff38e20 0xcff395d0 0xcff395c8 0xcff38e20 0xcff395d0 0xcff39860 0xcff39858 0xcff395d0 0xcff39860 0xcff39c38 0xcff39c30 0xcff39860 0xcff39c38 0xcff39d80 0xcff39d78 0xcff39c38 0xcff39d80 0xcff38008 0xcff38000 0xcff39d80 0xcff38008 0xc0243e40 ============================================ /* In fact after some time we came to a happy end. So there was no endless loop. But let's look at the broken prev pointer again: */ >> walk inode i_list 0xc0243e40 -h n -t -i 5 STRUCT ADDR PREV LISTHEAD NEXT ============================================ 0 0xcff38008 0xc0243e40 0xc5501c38 WARNING: Pointer broken. 0xc579c3e0, SHOULD BE: 0xc0243e40 0xc5501c30 0xc579c3e0 0xc5501c38 0xc6314f68 0xc6314f60 0xc5501c38 0xc6314f68 0xc2c44e20 0xc2c44e18 0xc6314f68 0xc2c44e20 0xc8671340 0xc8671338 0xc2c44e20 0xc8671340 0xc54da528 0xc54da520 0xc8671340 0xc54da528 0xcbde6528 WARNING: Iteration threshold reached. Current threshold: 5. Use "-i" to change threshold. /* Walking the other way around everything seems ok: */ >> walk inode i_list 0xc0243e40 -h p -t -i 5 STRUCT ADDR NEXT LISTHEAD PREV ============================================ 0 0xc5501c38 0xc0243e40 0xcff38008 0xcff38000 0xc0243e40 0xcff38008 0xcff39d80 0xcff39d78 0xcff38008 0xcff39d80 0xcff39c38 0xcff39c30 0xcff39d80 0xcff39c38 0xcff39860 0xcff39858 0xcff39c38 0xcff39860 0xcff395d0 0xcff395c8 0xcff39860 0xcff395d0 0xcff38e20 WARNING: Iteration threshold reached. Current threshold: 5. Use "-i" to change threshold. >> Regards, Andreas -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com From owner-lkcd@oss.sgi.com Thu Aug 16 09:53:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GGrKc01627 for lkcd-outgoing; Thu, 16 Aug 2001 09:53:20 -0700 Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GGrCj01622 for ; Thu, 16 Aug 2001 09:53:12 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA237758 for ; Thu, 16 Aug 2001 18:53:04 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GGr3S65370 for ; Thu, 16 Aug 2001 18:53:03 +0200 Importance: Normal Subject: description: symtab and module To: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Thu, 16 Aug 2001 18:51:01 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 16/08/2001 18:51:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Remark: This was written some time ago. The output of 'symtab -l' and 'symtab -a' has slightly changed since then. But it gives an idea of how to use commands symtab and module. Analyzing kernel modules: This should describe how to use lcrash in analyzing kernel modules. First of all we make use of lcrash commands namelist and symtab. We have a kernel module my_dummy.o containing a locale variable DUMMY of type dummy_t. The corresponding code fragment is as follows: typedef struct dummy_s{ int member1; char *member2; struct dummy_s *member3; } dummy_t; static dummy_t DUMMY={0, "just a demonstration", &DUMMY}; Our intention will be to examine this local data with lcrash. To make it little more tricky we analyze a live dump and the module will be loaded while lcrash is running. Our module was compiled using option -gstabs to create type information. The symbol table of the module was generated using a command line like "nm my_dummy.o > /tmp/my_dummy.map". The file my_dummy.o was also copied to /tmp. 1.Start lcrash. PWD: ~ RC: 0 root@lion28>lcrash /boot/System.map-2.2.18 /dev/mem /boot/Kerntypes map = /boot/System.map-2.2.18, vmdump = /dev/mem, outfile = stdout, kerntypes = /boot/Kerntypes Please wait... Loading system map ........................... Done. Loading type info (Kerntypes) ... Done. Loading ksyms from dump ........ Done. >> 2.Look what modules are loaded. >> module ADDR SIZE USED NAME REFS =========================================================================== d0103000 17928 1 ibmtr_cs [] d00fe000 6608 2 ds [ibmtr_cs] d00f3000 23408 2 i82365 [] d00e6000 46848 0 pcmcia_core [ibmtr_cs ds i82365] c02ad0e0 0 1 kernel_module [] =========================================================================== 3.From another shell, load module my_dummy. PWD: /home/aherrman/CPP/crash_ex RC: 0 root@lion28>insmod my_dummy.o PWD: /home/aherrman/CPP/crash_ex RC: 0 root@lion28> 4.Verify the former action with lcrash. >> module ADDR SIZE USED NAME REFS =========================================================================== d0000000 1120 0 my_dummy [] d0103000 17928 1 ibmtr_cs [] d00fe000 6608 2 ds [ibmtr_cs] d00f3000 23408 2 i82365 [] d00e6000 46848 0 pcmcia_core [ibmtr_cs ds i82365] c02ad0e0 0 1 kernel_module [] =========================================================================== 5.Look which symbols of the new module are exported. >> module -f my_dummy EXPORTED MODULE SYMBOLS: =========================================================================== Module: my_dummy Number of exported symbols: 6 ADDR NAME [MODULE] d0000000 __insmod_my_dummy_O/home/aherrman/CPP/crash_ex/my_dummy.o_ M3B1CDF3B_V131602 [my_dummy] d0000060 dummy_init [my_dummy] d0000060 __insmod_my_dummy_S.text_L447 [my_dummy] d000021f __insmod_my_dummy_S.rodata_L29 [my_dummy] d000041c __insmod_my_dummy_S.bss_L16 [my_dummy] d0000240 __insmod_my_dummy_S.data_L260 [my_dummy] =========================================================================== 6.Load type information of the module. >> namelist -a /tmp/my_dummy.o .The current namelist is /tmp/my_dummy.o (1) >> namelist INDEX NAMELIST ================================================= 0 /boot/Kerntypes 1 /tmp/my_dummy.o ================================================= The current namelist is /tmp/my_dummy.o (1) 7.Load symbol table of the module. >> symtab -a /tmp/my_dummy.map my_dummy Adding symbol table. filename: /tmp/my_dummy.map text_offset: 0 data_offset: 0 rodata_offset: 0 bss_offset: 0 module size: 1120 ..Done. Something went wrong, offsets of text and data sections of the module should not be zero. This is caused by the fact, that we added our module after lcrash was started. We have to remove the loaded symbol table and we have to recreate the table __ksymtab__. 8.Remove our new symbol table and __ksymtab__. >> symtab -l Loaded symbol tables: =========================================================================== #SYMS: 7803 /boot/System.map-2.2.18 TEXT: 0 DATA: 0 RODATA: 0 BSS: 0 #SYMS: 1163 __ksymtab__ TEXT: 0 DATA: 0 RODATA: 0 BSS: 0 #SYMS: 14 /tmp/my_dummy.map [my_dummy] TEXT: 0 DATA: 0 RODATA: 0 BSS: 0 =========================================================================== >> symtab -r /tmp/my_dummy.map Removing symbol table. Done. >> symtab -r __ksymtab__ Removing symbol table. Done. 9.Recreate symbol table __ksymtab__. >> symtab -a __ksymtab__ Adding symbol table. Loading ksyms from dump ........ Done. 10.Load our new symbol table again. >> symtab -a /tmp/my_dummy.map my_dummy Adding symbol table. filename: /tmp/my_dummy.map text_offset: d0000060 data_offset: d0000240 rodata_offset: d000021f bss_offset: d000041c module size: 1120 ..Done. >> symtab -l Loaded symbol tables: =========================================================================== #SYMS: 7803 /boot/System.map-2.2.18 TEXT: 0 DATA: 0 RODATA: 0 BSS: 0 #SYMS: 1169 __ksymtab__ TEXT: 0 DATA: 0 RODATA: 0 BSS: 0 #SYMS: 14 /tmp/my_dummy.map [my_dummy] TEXT: d0000060 DATA: d0000240 RODATA: d000021f BSS: d000041c =========================================================================== 11.Look which symbols are available in module my_dummy. >> symtab -l -f /tmp/my_dummy.map =========================================================================== #SYMS: 14 /tmp/my_dummy.map [my_dummy] TEXT: d0000060 DATA: d0000240 RODATA: d000021f BSS: d000041c ADDR OFFSET TYPE NAME ------------------------------------------------------------ d0000060 0 GLOBAL_TEXT dummy_init d00000f0 0 LOCAL_TEXT dummy_xmit d0000130 0 LOCAL_TEXT dummy_get_stats d0000140 0 LOCAL_TEXT dummy_open d0000160 0 LOCAL_TEXT dummy_close d0000180 0 LOCAL_TEXT set_multicast_list d0000190 0 LOCAL_TEXT dummy_probe d00001b0 0 GLOBAL_TEXT init_module d00001f0 0 GLOBAL_TEXT cleanup_module d000021f 0 LOCAL_TEXT Letext d0000240 0 LOCAL_DATA DUMMY d0000260 0 LOCAL_DATA dev_dummy d000041c 0 LOCAL_DATA dummy_name d00004c0 0 ABS /tmp/my_dummy.map_END ------------------------------------------------------------ =========================================================================== 12.Try to examine the local variable DUMMY of our module. >> whatis DUMMY ADDR OFFSET TYPE NAME ============================================================ d0000240 0 LOCAL_DATA DUMMY >> whatis dummy_t struct dummy_s struct dummy_s { int member1; char *member2; struct dummy_s *member3; }; >> print *(dummy_t*) d0000240 struct dummy_s { member1 = 0 member2 = 0xd000021f member3 = 0xd0000240 } >> whatis dummy_s.member2 char * >> print (char*) 0xd000021f 0xd000021f "just a demonstration" Furthermore an additional symbol table of a kernel module provides you function names when setting up stack back-traces with trace or strace and when using disassembling routine dis. Have fun, Andreas -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com From owner-lkcd@oss.sgi.com Thu Aug 16 10:20:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7GHKh902277 for lkcd-outgoing; Thu, 16 Aug 2001 10:20:43 -0700 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7GHKfj02274 for ; Thu, 16 Aug 2001 10:20:41 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id TAA192012; Thu, 16 Aug 2001 19:20:34 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GHKYB212582; Thu, 16 Aug 2001 19:20:34 +0200 Importance: Normal Subject: Re: Module support To: "Matt D. Robinson" Cc: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Andreas Herrmann" Date: Thu, 16 Aug 2001 19:18:31 +0200 X-MIMETrack: Serialize by Router on D12ML033/12/M/IBM(Release 5.0.6 |December 14, 2000) at 16/08/2001 19:18:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Matt Robinson wrote: >Masashige Kotani wrote: >> Hello. >> I am a Jyunji's co-worker too. >> I am making a new command for module support of lkcd as in the above mail. >Hi, Masashige-san. I have no problems including this into the tree, >as long as it isn't conflicting with Andreas' work, and it can be >packaged nicely together. The conflict issue is just to make sure >multiple LKCD developers are working on the same page. I'm all for >the right thing going into the code base regardless, I just don't >want to see conflicts in the way the work is completed. I can't see any conflicts. The only general restriction is as follows: If you have 2 symbol tables containing information for the same symbol, then this symbol will be found in the symbol table that was first added. Example: You have a System.map containing already all symbols of all of your loaded modules. This table is loaded during lcrash startup. If you load a further symbol table for one of your loaded modules (using 'symtab -a'), then this is of no use, because the symbol information is received via System.map that was first loaded. -- Linux for eServer Development Tel : +49-7031-16-4640 Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE email : aherrman@de.ibm.com From owner-lkcd@oss.sgi.com Sun Aug 26 23:41:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7R6f9M15432 for lkcd-outgoing; Sun, 26 Aug 2001 23:41:09 -0700 Received: from nakedeye.aparity.com (w032.z064001165.sjc-ca.dsl.cnc.net [64.1.165.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7R6f3d15429 for ; Sun, 26 Aug 2001 23:41:03 -0700 Received: from alacritech.com (w032.z064001165.sjc-ca.dsl.cnc.net [64.1.165.32]) by nakedeye.aparity.com (8.11.2/8.11.2) with ESMTP id f7R6iRN12041 for ; Sun, 26 Aug 2001 23:44:30 -0700 Message-ID: <3B89EB02.7D4C88DC@alacritech.com> Date: Sun, 26 Aug 2001 23:38:58 -0700 From: "Matt D. Robinson" X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: lkcd@oss.sgi.com Subject: Latest LKCD check-ins ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Okay, I've checked in a slew of files to LKCD. Here's the gist of what's been done: 1) Moving away from vmdump.c to dump.c, since dumping is taking on a context of being more than vm, per se. 2) Dumping is now configured via an ioctl() on the dump device. The dump device is /dev/dump, and is used for all dump configuration. The old method of writing to /proc is gone, replaced by an ioctl() interface. So you open() /dev/dump, then you ioctl(fd, DIOSDUMPDEV, 0x304), where /dev/hda4 might be 0x304. 3) The dump code can now be built as a module. If you use the new module code added to LKCD, you should be able to do module dumps (yea!) 4) Dump compression is now implemented as a separate component built into the kernel via a list. For example, if you build dump as a module, you can also build dump_rle as a module as well. I haven't finished the gzip module (still putting in the deflate() code), but that's the next step. Still left to do on my list: 1) Fix the rest of the SMP dumping issues; 2) Added dump_gzip.c support (rather, finished what I've checked into the 2.4 tree in the SourceForge repository); 3) Add gzip support to lcrash (libklib); 4) Check in 'dumpconfig', which will be the dump configuration utility (dumpconfig -s /dev/hda4 -l 8 -f 2 -c 1, for example). This leads to (5), which is ... 5) Change all the dump scripts to use 'dumpconfig', and; 6) Create a new RPM image and new release for 4.0. ... and if I can finish it before 4.0 ... 7) Add dump block and char operations for devices in order to support raw dumping in the future (per Andrea). See some of you at LinuxWorld. I'll be there Tuesday and Thursday. --Matt Checking in the latest snapshot of the LKCD 4.0 release. This builds an entirely new base driver that moves compression to an external module, builds as a module, and is now tuned and configured via an ioctl() rather than the old /proc interface. Voila. Copying lkcd@oss.sgi.com for details. I'll include a patch in the mail tomorrow morning, but in the meantime, if you play with this stuff, check it out and let me know what you think. CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: Makefile Documentation/Configure.help arch/i386/config.in CVS: arch/i386/boot/Makefile arch/i386/boot/install.sh CVS: arch/i386/kernel/Makefile arch/i386/kernel/smp.c CVS: arch/i386/kernel/smpboot.c arch/i386/kernel/traps.c CVS: arch/i386/mm/init.c drivers/block/Makefile CVS: drivers/block/vmdump.c drivers/char/sysrq.c CVS: include/linux/vmdump.h init/kerntypes.c init/main.c CVS: kernel/ksyms.c kernel/panic.c kernel/sched.c CVS: Added Files: CVS: arch/i386/kernel/dump.c drivers/block/dump.c CVS: drivers/block/dump_gzip.c drivers/block/dump_rle.c CVS: drivers/block/dump_zlib.h include/asm-alpha/dump.h CVS: include/asm-i386/dump.h include/asm-ia64/dump.h CVS: include/linux/dump.h CVS: ---------------------------------------------------------------------- Checking in changes for the new set of dump mechanisms with LKCD 4.0. We've changed the kernel dumping code from vmdump.c to dump.c, so this makes things work "better" as far as dumping is concerned. Things left to fix/add: 1) Remove old uncompress mechanism which relies solely on RLE. This has to be expanded to look at the dh_dump_compress field in the header to look for RLE, GZIP, or whatever. 2) Add inflate() mechanisms to the libklib compression code. 3) Correct live dumping to be able to use GZIP compression. CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: lcrash/vmdump.c lcrash/cmds/cmd_livedump.c libklib/kl_cmp.c CVS: libklib/kl_savedump.c libklib/kl_util.c libklib/include/klib.h CVS: libklib/include/vmdump.h CVS: Added Files: CVS: libklib/include/dump.h libklib/include/asm-i386/dump.h CVS: libklib/include/asm-ia64/dump.h CVS: libklib/include/asm-s390/dump.h CVS: ---------------------------------------------------------------------- From owner-lkcd@oss.sgi.com Wed Aug 29 06:43:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7TDh2T24144 for lkcd-outgoing; Wed, 29 Aug 2001 06:43:02 -0700 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7TDh0d24141 for ; Wed, 29 Aug 2001 06:43:00 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA38028 for ; Wed, 29 Aug 2001 09:40:37 -0400 Received: from d01ml087.pok.ibm.com (d01ml087.pok.ibm.com [9.117.250.87]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TDYi7165258 for ; Wed, 29 Aug 2001 09:34:45 -0400 Importance: Normal Subject: To: lkcd@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Radha Kandadai" Date: Wed, 29 Aug 2001 09:42:46 -0400 X-MIMETrack: Serialize by Router on D01ML087/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 08/29/2001 09:42:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-lkcd@oss.sgi.com Precedence: bulk Can anyone help me out with this problem. I am running redhat 7.1 kernel with lkcd 2.4.2 patches. Some times after system crash, it doesn't finish writing vmdump. In the syslog I see the following 2 lines and it just sits there.. Aug 28 13:45:02 c5an39 kernel: Dumping to device 0x807 [sd(8,7)] ... Aug 28 13:45:02 c5an39 kernel: Writing dump header ... Can anyone explain what's problem and how to fix it.. Thanks ------------------ Radha Kandadai radhak@us.ibm.com Dept LNLA 522 South Road Poughkeepsie, NY 12601 845-433-7084 (TL 293-7084) From owner-lkcd@oss.sgi.com Wed Aug 29 17:00:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7U00Qe05294 for lkcd-outgoing; Wed, 29 Aug 2001 17:00:26 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7U00Od05291 for ; Wed, 29 Aug 2001 17:00:24 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f7TNtLO02464; Wed, 29 Aug 2001 16:55:21 -0700 Message-ID: <3B8D82A1.2EEE8C85@alacritech.com> Date: Wed, 29 Aug 2001 17:02:41 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Radha Kandadai CC: lkcd@oss.sgi.com Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Radha Kandadai wrote: > > Can anyone help me out with this problem. I am running redhat 7.1 kernel > with lkcd 2.4.2 patches. Some times after system crash, it doesn't finish > writing vmdump. In the syslog I see the following 2 lines and it just sits > there.. > > Aug 28 13:45:02 c5an39 kernel: Dumping to device 0x807 [sd(8,7)] ... > Aug 28 13:45:02 c5an39 kernel: Writing dump header ... > > Can anyone explain what's problem and how to fix it.. > > Thanks > > ------------------ > Radha Kandadai radhak@us.ibm.com > Dept LNLA > 522 South Road > Poughkeepsie, NY 12601 > 845-433-7084 (TL 293-7084) I need to know which patch you're using ... my guess is you're using the patch where we mess with disabling the APIC if you aren't on CPU 0, which isn't right. I'm going to turn all that back to the way it was (yes, I realize some dumps that use the default I/O path will have problems), but the next fix with using a dump block device_operations functionality will be on the horizon pretty soon now. Anyway, let me know which patch you're using, so I can tell you what to fix in the meantime. --Matt From owner-lkcd@oss.sgi.com Fri Aug 31 10:55:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f7VHtWM24832 for lkcd-outgoing; Fri, 31 Aug 2001 10:55:32 -0700 Received: from crotus.sc.intel.com (scfdns02.sc.intel.com [143.183.152.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f7VHtPd24827 for ; Fri, 31 Aug 2001 10:55:30 -0700 Received: from cyclone.sc.intel.com (cyclone.sc.intel.com [143.183.251.112]) by crotus.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with ESMTP id RAA23336; Fri, 31 Aug 2001 17:55:19 GMT Received: from intel.com (IDENT:rschaal@cyclone.sc.intel.com [143.183.251.112]) by cyclone.sc.intel.com (8.9.3/8.9.3) with ESMTP id KAA12076; Fri, 31 Aug 2001 10:46:27 -0700 Message-ID: <3B8FCD73.12E1015B@intel.com> Date: Fri, 31 Aug 2001 10:46:27 -0700 From: Richard Schaal Reply-To: richard.schaal@intel.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: lkcd@oss.sgi.com CC: richard.schaal@intel.com Subject: LKCD + KDB ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Greetings, I've retrieved the patch and applied it to the Linux-2.4.9 kernel running on a RedHat 7.1 system. I've made some tweaks to startup scripts and the kernel patch in order to get a smooth operation as described in your documentation. Let me know if you need these to add to your collection. My question is this - I have been a fan of the kernel debugger for some time, and have had a bit of difficulty resolving how to configure both capabilities into my kernel. I guess what I'd like to have happen is to have the system enter the debugger on an oops, then have the option of dumping the system from the debugger, or to dump the system automatically after the debugger is exited. What is your thinking on this? Did I goof something up in applying the patches for the two features? Thanks, Richard -- Richard.Schaal@intel.com Intel Corporation Ph: (408)765-1579 Richard Schaal Mail Stop SC12-308 3600 Juliette Lane "I can type faster than I think!" Santa Clara, CA 95052 From owner-lkcd@oss.sgi.com Fri Aug 31 19:02:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8122oB03264 for lkcd-outgoing; Fri, 31 Aug 2001 19:02:50 -0700 Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8122kd03261 for ; Fri, 31 Aug 2001 19:02:46 -0700 Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f811vmO13743; Fri, 31 Aug 2001 18:57:48 -0700 Message-ID: <3B904258.876EDD16@alacritech.com> Date: Fri, 31 Aug 2001 19:05:12 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: richard.schaal@intel.com CC: lkcd@oss.sgi.com Subject: Re: LKCD + KDB ? References: <3B8FCD73.12E1015B@intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Richard Schaal wrote: > > Greetings, > I've retrieved the patch and applied it to the Linux-2.4.9 kernel > running on a RedHat 7.1 system. > I've made some tweaks to startup scripts and the kernel patch in order > to get a smooth operation as > described in your documentation. Let me know if you need these to add > to your collection. > > My question is this - I have been a fan of the kernel debugger for some > time, and have had a bit of difficulty > resolving how to configure both capabilities into my kernel. I guess > what I'd like to have happen is to > have the system enter the debugger on an oops, then have the option of > dumping the system from the debugger, or > to dump the system automatically after the debugger is exited. There's no great way to do this right now. If in kdb you can set the field of 'dump_okay' field to FALSE, then reset it after dropping back from the debugger state, that'd be fine. I guess we could also add in something for kdb, a one-time thing, so kdb can set dump_kdb to TRUE, and when dump_execute() gets called, dump_kdb is checked, and if set to TRUE, resets it to FALSE. Then add a kdb command that sets the field for you ... Would that work? --Matt > What is your thinking on this? Did I goof something up in applying the > patches for the two features? > > Thanks, > Richard > > -- > Richard.Schaal@intel.com Intel Corporation > Ph: (408)765-1579 Richard Schaal > Mail Stop SC12-308 > 3600 Juliette Lane > "I can type faster than I think!" Santa Clara, CA 95052