From owner-lkcd@oss.sgi.com Tue Jan 9 15:41:27 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 15:41:07 -0800 Received: from riscokid.phx.mcd.mot.com ([144.191.11.25]:38152 "HELO riscokid.phx.mcd.mot.com") by oss.sgi.com with SMTP id ; Tue, 9 Jan 2001 15:40:56 -0800 Received: (saj@localhost) by riscokid.phx.mcd.mot.com (8.6.8.2/8.6.7.riscokid) id QAA19200;Tue, 9 Jan 2001 16:40:56 -0700 From: Steve James Message-Id: <200101092340.QAA19200@riscokid.phx.mcd.mot.com> Subject: kl_parent_pid() To: lkcd@oss.sgi.com Date: Tue, 9 Jan 2001 16:40:55 -0700 (MST) Cc: tjm@sgi.com, steve_james@mcg.mot.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Greetings! This is my first mail to the list. I'm porting the LKCD+lcrash as of 20 Dec 2000 to Linux 2.2.17 on the PowerPC. So far, I am very impressed! However, in the interest of better parent/child relationships, shouldn't the line: ppid = (uint64_t)KL_UINT(tsp, "task_struct", "pid"); in libklib/kl_task.c:kl_parent_pid() rather read: ppid = (uint64_t)KL_UINT(tpp, "task_struct", "pid"); thx/saj steve_james@mcg.mot.com From owner-lkcd@oss.sgi.com Tue Jan 9 16:37:18 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 16:37:08 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53797 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 16:36:57 -0800 Received: from loco.csd.sgi.com (loco.csd.sgi.com [150.166.1.62]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05333 for ; Tue, 9 Jan 2001 16:45:42 -0800 (PST) mail_from (tjm@sgi.com) Received: from sgi.com (localhost.csd.sgi.com [127.0.0.1]) by loco.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA04701; Tue, 9 Jan 2001 16:35:40 -0800 (PST) Message-ID: <3A5BAE5C.C6769EB0@sgi.com> Date: Tue, 09 Jan 2001 16:35:40 -0800 From: Tom Morano X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Steve James CC: lkcd@oss.sgi.com, Tom Morano Subject: Re: kl_parent_pid() References: <200101092340.QAA19200@riscokid.phx.mcd.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Steve James wrote: > > Greetings! > > This is my first mail to the list. I'm porting the LKCD+lcrash > as of 20 Dec 2000 to Linux 2.2.17 on the PowerPC. So far, > I am very impressed! > > However, in the interest of better parent/child relationships, > shouldn't the line: > > ppid = (uint64_t)KL_UINT(tsp, "task_struct", "pid"); > > in libklib/kl_task.c:kl_parent_pid() > > rather read: > > ppid = (uint64_t)KL_UINT(tpp, "task_struct", "pid"); Hi Steve, You are absolutely correct. Thanks! And thanks for doing work on a PowerPC port. From an lcrash point of view, you can do a lot of work without actually having LKCD kernel functionality in place. As long as you have a "namelist" file you can start up lcrash on a live system. You need to make sure that you run the configure script in lkcdutils with the --topdir flag set to your kernel source tree (if it's not /usr/src/linux). You will then be able to do a 'make namelist' from within the libklib directory. Use the resulting namelist in the following manner: # lcrash /boot/System.map /dev/mem namelist You will then be able to work on the architecture specific stuff like stack traces for running tasks. Or, you may already be beyond this point. Thanks again, Tom Take care, Tom From owner-lkcd@oss.sgi.com Wed Jan 10 14:52:46 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 14:52:26 -0800 Received: from [216.61.45.26] ([216.61.45.26]:23424 "EHLO astroarch.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 14:52:20 -0800 Received: from gallantfox ([10.0.0.9]) by astroarch.com (8.11.0/8.11.0) with SMTP id f0AMq8O08763 for ; Wed, 10 Jan 2001 16:52:09 -0600 From: "elh" To: Subject: IDE and v2.4 kernels Date: Wed, 10 Jan 2001 16:57:52 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi, I use v2.4-test11 kernels and was wondering if IDE swap devices was supported for lkcd? Every time I run /sbin/vmdump config I get a can not open device error even though the /dev/vmdump points to /dev/hda6. Any help is appreciated. _Edward Haletky From owner-lkcd@oss.sgi.com Tue Jan 16 10:25:46 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 10:25:37 -0800 Received: from riscokid.phx.mcd.mot.com ([144.191.11.25]:46863 "HELO riscokid.phx.mcd.mot.com") by oss.sgi.com with SMTP id ; Tue, 16 Jan 2001 10:25:26 -0800 Received: (saj@localhost) by riscokid.phx.mcd.mot.com (8.6.8.2/8.6.7.riscokid) id LAA10256;Tue, 16 Jan 2001 11:25:07 -0700 From: Steve James Message-Id: <200101161825.LAA10256@riscokid.phx.mcd.mot.com> Subject: PPC port vs. kl_task.c:kl_kernelstack() To: tjm@sgi.com (Tom Morano) Date: Tue, 16 Jan 2001 11:25:06 -0700 (MST) Cc: lkcd@oss.sgi.com, steve_james@riscokid.phx.mcd.mot.com In-Reply-To: <3A5BAE5C.C6769EB0@sgi.com> from "Tom Morano" at Jan 09, 2001 04:35:40 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing > And thanks for doing work on a PowerPC port. From an lcrash point of > view, you can do a lot of work without actually having LKCD kernel > functionality in place. As long as you have a "namelist" file you > can start up lcrash on a live system. You need to make sure that > you run the configure script in lkcdutils with the --topdir flag > set to your kernel source tree (if it's not /usr/src/linux). You will > then be able to do a 'make namelist' from within the libklib directory. > Use the resulting namelist in the following manner: > > # lcrash /boot/System.map /dev/mem namelist > > You will then be able to work on the architecture specific stuff like > stack traces for running tasks. Or, you may already be beyond this point. Yes, my porting effort is well beyond that point. A great many things are working. It is easy when you start with good code :) However, we have a problem. libklib/kl_task.c:kl_kernelstack() is not architecture indepentdent. This is because the thread structure for the PPC is not the same as for the other three architectures. In particular, there is no member named "esp0". (They call that "ksp" on the PPC.) There could be similar problems in other libklib code that I will uncover as I get the stack backtrace stuff working. What is your philosophy about how to handle de-genericizing things like this? For example, one approach would be to move the entire kl_kernelstack function into one of the architecture-dependent files. Or have kl_kernelstack call an architecture-dependent function to actually get the esp0/ksp. Or have kl_task.c include an architecture specific ".h" which defines a macro, which, in the case of the PPC, would transform the "esp0" references to "ksp" references? If you can't get ahold of the PPC ".h" files for the thread structure, etc., let me know and I'll mail 'em out. thx/ Steve James steve_james@phx.mcd.mot.com > Take care, > > Tom > From owner-lkcd@oss.sgi.com Tue Jan 16 10:29:46 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 10:29:37 -0800 Received: from smtp.alacritech.com ([209.10.208.82]:18959 "EHLO smtp.alacritech.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 10:29:28 -0800 Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id ckznaaaa for ; Tue, 16 Jan 2001 10:24:50 -0800 Message-ID: <3A649467.1E8C663@alacritech.com> Date: Tue, 16 Jan 2001 10:35:19 -0800 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve James CC: Tom Morano , lkcd@oss.sgi.com, steve_james@riscokid.phx.mcd.mot.com Subject: Re: PPC port vs. kl_task.c:kl_kernelstack() References: <200101161825.LAA10256@riscokid.phx.mcd.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Steve James wrote: > > > And thanks for doing work on a PowerPC port. From an lcrash point of > > view, you can do a lot of work without actually having LKCD kernel > > functionality in place. As long as you have a "namelist" file you > > can start up lcrash on a live system. You need to make sure that > > you run the configure script in lkcdutils with the --topdir flag > > set to your kernel source tree (if it's not /usr/src/linux). You will > > then be able to do a 'make namelist' from within the libklib directory. > > Use the resulting namelist in the following manner: > > > > # lcrash /boot/System.map /dev/mem namelist > > > > You will then be able to work on the architecture specific stuff like > > stack traces for running tasks. Or, you may already be beyond this point. > > Yes, my porting effort is well beyond that point. A great many > things are working. It is easy when you start with good code :) > > However, we have a problem. > libklib/kl_task.c:kl_kernelstack() is not architecture indepentdent. > This is because the thread structure for the PPC is not the > same as for the other three architectures. In particular, > there is no member named "esp0". (They call that "ksp" on > the PPC.) There could be similar problems in other libklib > code that I will uncover as I get the stack backtrace stuff > working. > > What is your philosophy about how to handle de-genericizing > things like this? For example, one approach would be to > move the entire kl_kernelstack function into one of the > architecture-dependent files. Or have kl_kernelstack > call an architecture-dependent function to actually > get the esp0/ksp. Or have kl_task.c include an > architecture specific ".h" which defines a macro, which, > in the case of the PPC, would transform the "esp0" references > to "ksp" references? I'd assume the second answer, but I'll let Tom answer definitively since that's his ball of wax. --Matt > If you can't get ahold of the PPC ".h" files for the > thread structure, etc., let me know and I'll mail 'em > out. From owner-lkcd@oss.sgi.com Tue Jan 16 10:32:07 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 10:31:57 -0800 Received: from smtp.alacritech.com ([209.10.208.82]:37391 "EHLO smtp.alacritech.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 10:31:49 -0800 Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id gkznaaaa for ; Tue, 16 Jan 2001 10:27:14 -0800 Message-ID: <3A6494F7.48703747@alacritech.com> Date: Tue, 16 Jan 2001 10:37:43 -0800 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: elh CC: lkcd@oss.sgi.com Subject: Re: IDE and v2.4 kernels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing elh wrote: > > Hi, > > I use v2.4-test11 kernels and was wondering if IDE swap devices was > supported > for lkcd? > > Every time I run /sbin/vmdump config I get a can not open device error even > though the > /dev/vmdump points to /dev/hda6. > > Any help is appreciated. > > _Edward Haletky Sorry, was on vacation ... This should work fine, Tom and I have both used IDE devices for the 2.4 kernels without a problem. Are you sure /dev/hda6 is valid? Also, can you send me the exact error message, just in case there's something else there? --Matt From owner-lkcd@oss.sgi.com Tue Jan 16 12:05:59 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 12:05:49 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:50466 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 12:05:40 -0800 Received: from loco.csd.sgi.com (loco.csd.sgi.com [150.166.1.62]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05918 for ; Tue, 16 Jan 2001 12:14:32 -0800 (PST) mail_from (tjm@sgi.com) Received: from sgi.com (localhost.csd.sgi.com [127.0.0.1]) by loco.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA18507; Tue, 16 Jan 2001 12:04:16 -0800 (PST) Message-ID: <3A64A940.8BC9E7AB@sgi.com> Date: Tue, 16 Jan 2001 12:04:16 -0800 From: Tom Morano X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Steve James CC: "Matt D. Robinson" , lkcd@oss.sgi.com, Tom Morano Subject: Re: PPC port vs. kl_task.c:kl_kernelstack() References: <200101161825.LAA10256@riscokid.phx.mcd.mot.com> <3A649467.1E8C663@alacritech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi Steve, "Matt D. Robinson" wrote: > > Steve James wrote: > > > > > And thanks for doing work on a PowerPC port. From an lcrash point of > > > view, you can do a lot of work without actually having LKCD kernel > > > functionality in place. As long as you have a "namelist" file you > > > can start up lcrash on a live system. You need to make sure that > > > you run the configure script in lkcdutils with the --topdir flag > > > set to your kernel source tree (if it's not /usr/src/linux). You will > > > then be able to do a 'make namelist' from within the libklib directory. > > > Use the resulting namelist in the following manner: > > > > > > # lcrash /boot/System.map /dev/mem namelist > > > > > > You will then be able to work on the architecture specific stuff like > > > stack traces for running tasks. Or, you may already be beyond this point. > > > > Yes, my porting effort is well beyond that point. A great many > > things are working. It is easy when you start with good code :) Thanks! :] > > > > However, we have a problem. > > libklib/kl_task.c:kl_kernelstack() is not architecture indepentdent. > > This is because the thread structure for the PPC is not the > > same as for the other three architectures. In particular, > > there is no member named "esp0". (They call that "ksp" on > > the PPC.) There could be similar problems in other libklib > > code that I will uncover as I get the stack backtrace stuff > > working. > > > > What is your philosophy about how to handle de-genericizing > > things like this? For example, one approach would be to > > move the entire kl_kernelstack function into one of the > > architecture-dependent files. Or have kl_kernelstack > > call an architecture-dependent function to actually > > get the esp0/ksp. Or have kl_task.c include an > > architecture specific ".h" which defines a macro, which, > > in the case of the PPC, would transform the "esp0" references > > to "ksp" references? Generally speaking, we're trying to have as little architecture specific code as possible. At one time, the kl_kernelstack() function was in an arch specific file, but I moved it (I didn't realize that there was a conflict with the PPC). What I have done now is to move the guts of the kl_kernelstack() call to a function called _kernelstack(), which is located in the libklib/arch//kl_kern.c file. You can pick this change up from the LKCD source repository on SourceForge. If you run across any other situations similar to this, you can put the arch specific code there as well. BTW, we really should get you set up as one of the LKCD developers, so that you can add your own changes (especially the PPC stuff) to the LKCD project. Do you already have a SourceForge login? Thanks, Tom From owner-lkcd@oss.sgi.com Tue Jan 16 12:52:49 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 12:52:29 -0800 Received: from riscokid.phx.mcd.mot.com ([144.191.11.25]:15377 "HELO riscokid.phx.mcd.mot.com") by oss.sgi.com with SMTP id ; Tue, 16 Jan 2001 12:52:03 -0800 Received: (saj@localhost) by riscokid.phx.mcd.mot.com (8.6.8.2/8.6.7.riscokid) id NAA10597;Tue, 16 Jan 2001 13:52:06 -0700 From: Steve James Message-Id: <200101162052.NAA10597@riscokid.phx.mcd.mot.com> Subject: Re: PPC port vs. kl_task.c:kl_kernelstack() To: tjm@sgi.com (Tom Morano) Date: Tue, 16 Jan 2001 13:52:05 -0700 (MST) Cc: yakker@alacritech.com (Matt D. Robinson), lkcd@oss.sgi.com, tjm@sgi.com (Tom Morano), saj@riscokid.phx.mcd.mot.com (Steve James) In-Reply-To: <3A64A940.8BC9E7AB@sgi.com> from "Tom Morano" at Jan 16, 2001 12:04:16 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing > Hi Steve, > > "Matt D. Robinson" wrote: > > > > Steve James wrote: > > > > > > However, we have a problem. > > > libklib/kl_task.c:kl_kernelstack() is not architecture indepentdent. > > > This is because the thread structure for the PPC is not the > > > same as for the other three architectures. In particular, > > > there is no member named "esp0". (They call that "ksp" on > > > the PPC.) There could be similar problems in other libklib > > > code that I will uncover as I get the stack backtrace stuff > > > working. > > > > > > What is your philosophy about how to handle de-genericizing > > > things like this? For example, one approach would be to > > > move the entire kl_kernelstack function into one of the > > > architecture-dependent files. Or have kl_kernelstack > > > call an architecture-dependent function to actually > > > get the esp0/ksp. Or have kl_task.c include an > > > architecture specific ".h" which defines a macro, which, > > > in the case of the PPC, would transform the "esp0" references > > > to "ksp" references? > > Generally speaking, we're trying to have as little architecture specific > code as possible. At one time, the kl_kernelstack() function was in > an arch specific file, but I moved it (I didn't realize that there was > a conflict with the PPC). What I have done now is to move the guts of > the kl_kernelstack() call to a function called _kernelstack(), which > is located in the libklib/arch//kl_kern.c file. You can pick > this change up from the LKCD source repository on SourceForge. If you > run across any other situations similar to this, you can put the arch > specific code there as well. This works for me. > BTW, we really should get you set up as one > of the LKCD developers, so that you can add your own changes (especially > the PPC stuff) to the LKCD project. Do you already have a SourceForge > login? No, but I will look into that. I have a whole bunch of observations/issues, etc. that I would like to share with the list before making certain changes that I have been tempted to make. thx/ Steve James steve_james@mcd.mot.com > > Thanks, > > Tom > From owner-lkcd@oss.sgi.com Tue Jan 16 12:57:59 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 12:57:50 -0800 Received: from smtp.alacritech.com ([209.10.208.82]:64015 "EHLO smtp.alacritech.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 12:57:31 -0800 Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id ctznaaaa for ; Tue, 16 Jan 2001 12:52:53 -0800 Message-ID: <3A64B71C.981A7230@alacritech.com> Date: Tue, 16 Jan 2001 13:03:24 -0800 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: lkcd@oss.sgi.com Subject: [Fwd: IDE and v2.4 kernels] Content-Type: multipart/mixed; boundary="------------A03A6A0D663D748E841F72CB" Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing This is a multi-part message in MIME format. --------------A03A6A0D663D748E841F72CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Forwarding on to the rest of the group ... --Matt --------------A03A6A0D663D748E841F72CB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3A64B406.9F33D2C7@alacritech.com> Date: Tue, 16 Jan 2001 12:50:14 -0800 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: elh Subject: Re: IDE and v2.4 kernels References: Content-Type: multipart/mixed; boundary="------------E3599B72C0D051FEE2BAFBA6" This is a multi-part message in MIME format. --------------E3599B72C0D051FEE2BAFBA6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've attached a patch to this E-mail. I've also included it in the test12 release (with one small fix), and this will be in the 2.4.0 release. Note, I haven't tested it yet, but it should work for you. Just apply it to your drivers/block/vmdump.c. Let me know ... --Matt elh wrote: > > Hi Matt, > > The error is: > > can not open device /dev/vmdump ........................ > .....................................................[-36] > > Where the ... are 1024 or so of garbage. > > I patched the test11 kernel and it just does not work. I am about > to try without adding in the kernel-2.4.0 patches for string and cipe. > > Any help is appreciated, > Edward L. Haletky > > > -----Original Message----- > > From: root@astroarch.com [mailto:root@astroarch.com]On Behalf Of Matt D. > > Robinson > > Sent: Tuesday, January 16, 2001 12:38 PM > > To: elh > > Cc: lkcd@oss.sgi.com > > Subject: Re: IDE and v2.4 kernels > > > > > > elh wrote: > > > > > > Hi, > > > > > > I use v2.4-test11 kernels and was wondering if IDE swap devices was > > > supported > > > for lkcd? > > > > > > Every time I run /sbin/vmdump config I get a can not open > > device error even > > > though the > > > /dev/vmdump points to /dev/hda6. > > > > > > Any help is appreciated. > > > > > > _Edward Haletky > > > > Sorry, was on vacation ... > > > > This should work fine, Tom and I have both used IDE devices for the 2.4 > > kernels without a problem. Are you sure /dev/hda6 is valid? Also, can > > you send me the exact error message, just in case there's something else > > there? > > > > --Matt > > --------------E3599B72C0D051FEE2BAFBA6 Content-Type: text/plain; charset=us-ascii; name="diff.patch.2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff.patch.2" --- vmdump.c.orig Tue Jan 16 12:46:59 2001 +++ vmdump.c Tue Jan 16 12:46:09 2001 @@ -5,7 +5,11 @@ * * Copyright 1999 Silicon Graphics, Inc. All rights reserved. * - * Linux 2.4 modifications by: Matt D. Robinson (yakker@alaeritech.com) + * Linux 2.3 modifications by: Matt D. Robinson (yakker@turbolinux.com) + * Copyright 2000 TurboLinux, Inc. All rights reserved. + * + * Linux 2.4 modifications by: Matt D. Robinson (yakker@alacritech.com) + * Copyright 2001 Alacritech, Inc. All rights reserved. * */ @@ -37,6 +41,10 @@ #include #include +#ifndef min +#define min(a,b) (((a)<(b))?(a):(b)) +#endif + /* make sure TRUE and false are defined */ #ifdef TRUE #undef TRUE @@ -234,7 +242,7 @@ unsigned long count, void *data) { int i; - char buf[PATH_MAX]; + char *page; /* skip over leading whitespace */ while (count && isspace(*buffer)) { @@ -242,19 +250,22 @@ ++buffer; } - /* copy the rest of the contents */ - sprintf(buf, "%s", buffer); - - /* remove trailing newline */ - buf[strlen(buf)-1] = 0; + if (!(page = (char *)__get_free_page(GFP_KERNEL))) { + return -ENOMEM; + } + + copy_from_user(page, buffer, count = (min(count, PAGE_SIZE))); + if (*(page + count - 1) == '\n') { + *(page + count - 1) = 0; + } /* call dump_open() and return results */ - i = dump_open((char *)buf); + i = dump_open(page); + free_page((unsigned long)page); if (!i) { return (count); - } else { - return (i); } + return (i); } /* --------------E3599B72C0D051FEE2BAFBA6-- --------------A03A6A0D663D748E841F72CB-- From owner-lkcd@oss.sgi.com Sat Jan 20 18:17:22 2001 Received: by oss.sgi.com id ; Sat, 20 Jan 2001 18:17:12 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:44296 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Sat, 20 Jan 2001 18:16:52 -0800 Received: (qmail 17316 invoked from network); 21 Jan 2001 02:16:41 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 21 Jan 2001 02:16:41 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: lkcd@oss.sgi.com Subject: Re: PPC port vs. kl_task.c:kl_kernelstack() In-reply-to: Your message of "Tue, 16 Jan 2001 11:25:06 PDT." <200101161825.LAA10256@riscokid.phx.mcd.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jan 2001 13:16:41 +1100 Message-ID: <25351.980043401@ocs3.ocs-net> Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing On Tue, 16 Jan 2001 11:25:06 -0700 (MST), Steve James wrote: >However, we have a problem. >libklib/kl_task.c:kl_kernelstack() is not architecture indepentdent. >This is because the thread structure for the PPC is not the >same as for the other three architectures. In particular, >there is no member named "esp0". (They call that "ksp" on >the PPC.) There could be similar problems in other libklib >code that I will uncover as I get the stack backtrace stuff >working. FYI, I just went through a similar problem when porting kdb (kernel debugger) v1.7 to IA64. The IA64 is particularly peculiar for several reasons. * It has two stacks, the normal memory stack and a separate register save engine stack. * The first 8 parameters are passed in registers, any more parameters are passed on the memory stack. * It dumps process state in two separate structures on the memory stack, one of which may not be present. You have to detect whether the second structure is available. * The only way to get an accurate stack backtrace is by using the unwind information that gcc includes in the kernel and module objects. The unwind code is interesting, as in "may you live in interesting times", in any case it is completely IA64 specific. * Data from the current function is allowed to use part of the preceding stack frame. This is very, very confusing when marking out stack frames. kdb tries to abstract the stack information into a common struct activation_record. But the IA64 showed how difficult that was to generalise so for the moment, kdb v1.7 has a lot of hardwired code in the IA64 arch directory. kdb v1.7 for IA64 is being reviewed by a couple of other IA64 developers before general release, barring any problems it will be released on Tuesday. From owner-lkcd@oss.sgi.com Sun Jan 21 14:42:47 2001 Received: by oss.sgi.com id ; Sun, 21 Jan 2001 14:42:38 -0800 Received: from mg01.austin.ibm.com ([192.35.232.18]:56467 "EHLO mailgate1.austin.ibm.com") by oss.sgi.com with ESMTP id ; Sun, 21 Jan 2001 14:42:20 -0800 Received: from austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by mailgate1.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA67406 for ; Sun, 21 Jan 2001 16:42:35 -0600 Received: from craft.austin.ibm.com (craft.austin.ibm.com [9.53.145.12]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA39654 for ; Sun, 21 Jan 2001 16:42:18 -0600 Received: (from dcraft@localhost) by craft.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id QAA41542 for lkcd@oss.sgi.com; Sun, 21 Jan 2001 16:42:18 -0600 From: Dave Craft Message-Id: <200101212242.QAA41542@craft.austin.ibm.com> Subject: module traceback To: lkcd@oss.sgi.com Date: Sun, 21 Jan 2001 16:42:09 -0600 (CST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing On the i386 linux version of lkcd I'm attempting to figure out how to get tracebacks for modules on a live system. What I've tried is merging the map produced from insmod of my module with the System.map and doing 'bt' on a task that I know is blocked in the module's code. From what I can tell the lkcd code can successfully find the correct symbol table entry correlating to function addresses in the stack frame (for both kernel and module functions) but it can't successfully read the physical page address where the modules instructions are found. For instance in the top frame lkcd subtracts c0000000 from 0xc0112b12 ("c0112750 T schedule" in the system.map) and reads /dev/mem at offset 0x112750 to validate the instructions therein. Thus I get a successful starting point of "schedule". However when it finds one of the modules functions in the traceback (c8834d78 T foo), it subtracts 0xc0000000 and attempts to read /dev/mem at offset 0x8834d78. This fails with a KLE_INVALID_READ. I believe it fails since /dev/mem is only giving me physical memory pages and that offset (142822776) is larger than the machines physical memory. So is there some function (other than subtracting 0xc0000000) needed in order to find the physical page for a kernel modules text segment? Example lkcd output: >> bt c0cda000 ================================================================ STACK TRACE FOR TASK: 0xc0cda000(foo) 0 schedule+962 [0xc0112b12] TRACE ERROR 0x800000000 ================================================================ Many thanks. Dave Craft -- --------- Opinions are mine and not IBM's ---------- Mail : dave@austin.ibm.com Phone : 512-838-8248 From owner-lkcd@oss.sgi.com Tue Jan 23 03:56:40 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 03:56:20 -0800 Received: from [202.54.26.202] ([202.54.26.202]:64221 "EHLO hindon.hss.co.in") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 03:55:55 -0800 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f0NBv7M18722 for ; Tue, 23 Jan 2001 17:27:08 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 652569DD.004060CF ; Tue, 23 Jan 2001 17:13:10 +0530 X-Lotus-FromDomain: HSS From: achowdhry@hss.hns.com To: lkcd@oss.sgi.com Message-ID: <652569DD.00405FBB.00@sandesh.hss.hns.com> Date: Tue, 23 Jan 2001 17:25:36 +0530 Subject: Query regarding char device Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi, I am trying to install your Lkcd ver 3.0 in linux ( kernel ver : 2.4.0 , Redhat 6.2 ) . while installing we need to create a raw ( character ) device and associate it to a swap area.( ie we should be able to run mkswap utility on it ). Now I don't know how to do that. It will be very nice if you can provide me some help regarding this. Waiting for ur reply Thanks and Regards Atul Chowdhry From owner-lkcd@oss.sgi.com Tue Jan 23 05:54:00 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 05:53:41 -0800 Received: from [216.61.45.26] ([216.61.45.26]:49297 "EHLO astroarch.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 05:53:29 -0800 Received: from gallantfox ([10.0.0.9]) by astroarch.com (8.11.0/8.11.0) with SMTP id f0NDrAu32750; Tue, 23 Jan 2001 07:53:10 -0600 From: "elh" To: , Subject: RE: Query regarding char device Date: Tue, 23 Jan 2001 07:59:43 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <652569DD.00405FBB.00@sandesh.hss.hns.com> Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hello, If you make a symlink from your swap area to /dev/vmdump all works as expected. Actually then /sbin/vmdump config command will do this for you. It reads the crash dump from your swap and places them on your root partition in whatever directory you specify. Best regards, Edward L. Haletky > -----Original Message----- > From: owner-lkcd@oss.sgi.com [mailto:owner-lkcd@oss.sgi.com]On Behalf Of > achowdhry@hss.hns.com > Sent: Tuesday, January 23, 2001 5:56 AM > To: lkcd@oss.sgi.com > Subject: Query regarding char device > > > > > Hi, > I am trying to install your Lkcd ver 3.0 in linux ( > kernel ver : 2.4.0 > , Redhat 6.2 ) . while installing we need to create a raw ( > character ) device > and associate it to a swap area.( ie we should be able to run > mkswap utility on > it ). Now I don't know how to do that. > It will be very nice if you can provide me some help regarding this. > Waiting for ur reply > > Thanks and Regards > Atul Chowdhry > > From owner-lkcd@oss.sgi.com Thu Jan 25 13:58:00 2001 Received: by oss.sgi.com id ; Thu, 25 Jan 2001 13:57:50 -0800 Received: from mg03.austin.ibm.com ([192.35.232.20]:479 "EHLO mailgate3.austin.ibm.com") by oss.sgi.com with ESMTP id ; Thu, 25 Jan 2001 13:57:32 -0800 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA38628 for ; Thu, 25 Jan 2001 15:55:52 -0600 Received: from craft.austin.ibm.com (craft.austin.ibm.com [9.53.145.12]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA45196 for ; Thu, 25 Jan 2001 15:57:30 -0600 Received: (from dcraft@localhost) by craft.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id PAA18134 for lkcd@oss.sgi.com; Thu, 25 Jan 2001 15:57:30 -0600 From: Dave Craft Message-Id: <200101252157.PAA18134@craft.austin.ibm.com> Subject: module traceback working To: lkcd@oss.sgi.com Date: Thu, 25 Jan 2001 15:57:30 -0600 (CST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing The other day I posted a query regarding how to get trace backs in kernel module code with lkcd on the i386. I'm not sure if anyone is interested in this (since I didn't get any responses) but I have made a couple of fixes to the baseline code as well as a minor addition to get this function to work. Note this work is just posted herein and doesn't represent any work by a lkcd maintainer. I'm not even saying it's suitable for anything other than my own educational purposes. I will also append the diff file to the end of this note. Note that this diff is just a rough first stab for my own benefit. The maintainers of lkcd (given that they know the structure better than I) would probably want this done differently. Basically the changes fall into a couple of categories. 1) Bug fixes for page table lookup on the i386: The KL_PGDIR_SHIFT and KL_PMDIR_SHIFT were wrong for the two level page directory case on the i386. The pmd_offset() function was also wrong for this case. 2) Enhancements to kl_virtop() to understand the vmalloc area: Essentially linux copies an inserted module to the vmalloc area which has an address above the PAGE_OFFSET line (0xc000000 on my machine) but it is also above physical memory. Thus to get the real physical address for these pages you must use the page directory hung off the "init_mm" memory map struct. So the changes in this area are just to get the range of the vmalloc area and use the "init_mm" info. After you fix this in lcrash you have to run it with a System.map that has the additional symbols from your module. You can get your modules symbol table at load time by using the -m option on insmod. Note you have to strip out all the extraneous stuff out of this map. cat .map | awk '/ [TtDd] / {print $0}' >> tmp.map Then append this to a new COPY of the /boot/System.map and do (sort -u) on the file. You can give lcrash this file as an option or just link /boot/System.map to your new symbol file. At that point you should be able to do a "bt" on a task that has a traceback into module routines. If anyone wants to discuss my poor attempt at getting this working or the defect fixes, just send me a note. Enjoy, Dave Craft -----------cut here for patch file---------- diff -Naur lkcd/lkcdutils/libklib/arch/i386/kl_kern.c lkcdmod/lkcdutils/libklib/arch/i386/kl_kern.c --- lkcd/lkcdutils/libklib/arch/i386/kl_kern.c Tue Jan 16 13:52:56 2001 +++ lkcdmod/lkcdutils/libklib/arch/i386/kl_kern.c Thu Jan 25 14:29:27 2001 @@ -11,6 +11,7 @@ #ifndef __KERNEL__ #define __KERNEL__ #include +#include #undef __KERNEL__ #else #endif @@ -28,6 +29,16 @@ #endif kaddr_t MEM_MAP; +kaddr_t INIT_MM; +kaddr_t KL_VMALLOC_START = 0xFFFFFFFF; +kaddr_t KL_VMALLOC_END = 0xFFFFFFFF; + +#define VMALLOC_OFFSET (8*1024*1024) +#define VMALLOC_START (((unsigned long) high_memory + 2*VMALLOC_OFFSET-1) & \ + ~(VMALLOC_OFFSET-1)) +#define VMALLOC_END (FIXADDR_START) + + /* * kl_init_kern_info() */ @@ -35,6 +46,7 @@ kl_init_kern_info() { syment_t *sp; + kaddr_t high_memory; kl_reset_error(); if (!(sp = kl_lkup_symname("num_physpages"))) { @@ -51,6 +63,19 @@ return(1); } GET_BLOCK(sp->s_addr, 4, (void*)&MEM_MAP); + + if (!(sp = kl_lkup_symname("init_mm"))) { + return(1); + } + /* init_mm is a structure offset and not a pointer */ + INIT_MM = sp->s_addr; + + if (!(sp = kl_lkup_symname("high_memory"))) { + return(1); + } + GET_BLOCK(sp->s_addr, 4, (void*)&high_memory); + KL_VMALLOC_START = VMALLOC_START; + KL_VMALLOC_END = VMALLOC_END; if (!(sp = kl_lkup_symname("__locore_lmabegin"))) { return(1); diff -Naur lkcd/lkcdutils/libklib/arch/i386/kl_page.c lkcdmod/lkcdutils/libklib/arch/i386/kl_page.c --- lkcd/lkcdutils/libklib/arch/i386/kl_page.c Thu Nov 30 20:53:44 2000 +++ lkcdmod/lkcdutils/libklib/arch/i386/kl_page.c Thu Jan 25 14:20:39 2001 @@ -23,8 +23,8 @@ #else /* CONFIG_X86_PAE */ -#define KL_PGDIR_SHIFT (KL_PAGE_SHIFT+(KL_PAGE_SHIFT-3)*1) -#define KL_PMD_SHIFT (KL_PAGE_SHIFT+(KL_PAGE_SHIFT-3)*1) +#define KL_PGDIR_SHIFT (KL_PAGE_SHIFT+(KL_PAGE_SHIFT-2)*1) +#define KL_PMD_SHIFT (KL_PAGE_SHIFT+(KL_PAGE_SHIFT-2)*1) #define KL_PTRS_PER_PGD (1UL<<(KL_PAGE_SHIFT-2)) #define KL_PTRS_PER_PMD 1 #define KL_PTRS_PER_PTE (1UL<<(KL_PAGE_SHIFT-2)) @@ -56,7 +56,10 @@ return pte_base; #else /* CONFIG_X86_PAE */ - return pmd_base; + /* higher level routines are expecting a non virtual address + * offset, which they will add KL_PAGE_OFFSET to. + */ + return pmd_base - KL_PAGE_OFFSET; #endif /* CONFIG_X86_PAE */ } diff -Naur lkcd/lkcdutils/libklib/include/klib.h lkcdmod/lkcdutils/libklib/include/klib.h --- lkcd/lkcdutils/libklib/include/klib.h Wed Dec 6 15:08:13 2000 +++ lkcdmod/lkcdutils/libklib/include/klib.h Thu Jan 25 14:34:38 2001 @@ -84,6 +84,15 @@ extern kaddr_t MEM_MAP; extern kaddr_t deftask; +#ifdef DEBUG +#define DPRINTF(x) fprintf x +#else +#define DPRINTF(x) +#endif +extern kaddr_t INIT_MM; +extern kaddr_t KL_VMALLOC_START; +extern kaddr_t KL_VMALLOC_END; + #define KL_ARCH lkcdinfo.arch #define KL_PTRSZ lkcdinfo.ptrsz #define KL_NBPW (KL_PTRSZ/8) diff -Naur lkcd/lkcdutils/libklib/kl_mem.c lkcdmod/lkcdutils/libklib/kl_mem.c --- lkcd/lkcdutils/libklib/kl_mem.c Thu Nov 30 20:52:16 2000 +++ lkcdmod/lkcdutils/libklib/kl_mem.c Thu Jan 25 14:33:52 2001 @@ -108,9 +108,19 @@ if ((KL_ARCH == ARCH_I386) && (vaddr >= KL_LOCORE_START)) { paddr = (KL_LOCORE_ADDR - KL_PAGE_OFFSET) + (vaddr - KL_LOCORE_START); - } else if (vaddr >= KL_PAGE_OFFSET) { + } else if ((vaddr >= KL_PAGE_OFFSET) && (vaddr < KL_VMALLOC_START)) { paddr = (vaddr - KL_PAGE_OFFSET); } else { + if ((vaddr >= KL_VMALLOC_START) && (vaddr < KL_VMALLOC_END)) { + mmp = kl_alloc_block(MM_STRUCT_SZ, K_TEMP); + GET_BLOCK(INIT_MM, MM_STRUCT_SZ, mmp); + if (KL_ERROR) { + kl_free_block(mmp); + mmp = NULL; + } else { + mm_alloced++; + } + } if (!mmp && deftask) { tsp = kl_alloc_block(TASK_STRUCT_SZ, K_TEMP); if (tsp) { @@ -149,5 +159,8 @@ if (mm_alloced) { kl_free_block(mmp); } + + DPRINTF((KL_ERRORFP, "kl_virtop: vaddr 0x%X paddr 0x%X error 0x%X\n", + vaddr, paddr, KL_ERROR)); return(paddr); } From owner-lkcd@oss.sgi.com Thu Jan 25 14:18:00 2001 Received: by oss.sgi.com id ; Thu, 25 Jan 2001 14:17:50 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:34379 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 25 Jan 2001 14:17:33 -0800 Received: from loco.csd.sgi.com ([150.166.1.62]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA02704 for ; Thu, 25 Jan 2001 14:17:32 -0800 (PST) mail_from (tjm@sgi.com) Received: from sgi.com (localhost.csd.sgi.com [127.0.0.1]) by loco.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA40773; Thu, 25 Jan 2001 14:15:58 -0800 (PST) Message-ID: <3A70A59E.DBFD5218@sgi.com> Date: Thu, 25 Jan 2001 14:15:58 -0800 From: Tom Morano X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Dave Craft CC: lkcd@oss.sgi.com Subject: Re: module traceback working References: <200101252157.PAA18134@craft.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi Dave, Actually, I am VERY interested in this (since I develop the lcrash utility) and had started taking a look and then got distracted. I apologize for not, at least, responding to your original post. I will take a look at the diffs you've provided with the idea of incorporating them in the tool. Thanks again for looking further into this and reporting back on your findings. Tom Dave Craft wrote: > > The other day I posted a query regarding how to get trace backs > in kernel module code with lkcd on the i386. I'm not sure if anyone is > interested in this (since I didn't get any responses) but I have > made a couple of fixes to the baseline code as well as a minor addition > to get this function to work. Note this work is just posted herein > and doesn't represent any work by a lkcd maintainer. I'm not even saying > it's suitable for anything other than my own educational purposes. > > I will also append the diff file to the end of this note. Note that > this diff is just a rough first stab for my own benefit. The maintainers > of lkcd (given that they know the structure better than I) would > probably want this done differently. > > Basically the changes fall into a couple of categories. > > 1) Bug fixes for page table lookup on the i386: The KL_PGDIR_SHIFT > and KL_PMDIR_SHIFT were wrong for the two level page directory > case on the i386. The pmd_offset() function was also wrong for > this case. > > 2) Enhancements to kl_virtop() to understand the vmalloc area: > Essentially linux copies an inserted module to the vmalloc area which > has an address above the PAGE_OFFSET line (0xc000000 on my machine) > but it is also above physical memory. Thus to get the real physical > address for these pages you must use the page directory hung off > the "init_mm" memory map struct. So the changes in this area > are just to get the range of the vmalloc area and use the "init_mm" > info. > > After you fix this in lcrash you have to run it with a System.map > that has the additional symbols from your module. You can get your > modules symbol table at load time by using the -m option on insmod. > Note you have to strip out all the extraneous stuff out of this map. > > cat .map | awk '/ [TtDd] / {print $0}' >> tmp.map > > Then append this to a new COPY of the /boot/System.map and do > (sort -u) on the file. You can give lcrash this file as an > option or just link /boot/System.map to your new symbol file. > > At that point you should be able to do a "bt" on a task that > has a traceback into module routines. > > If anyone wants to discuss my poor attempt at getting this working > or the defect fixes, just send me a note. > > Enjoy, > Dave Craft > > -----------cut here for patch file---------- > diff -Naur lkcd/lkcdutils/libklib/arch/i386/kl_kern.c lkcdmod/lkcdutils/libklib/arch/i386/kl_kern.c > --- lkcd/lkcdutils/libklib/arch/i386/kl_kern.c Tue Jan 16 13:52:56 2001 > +++ lkcdmod/lkcdutils/libklib/arch/i386/kl_kern.c Thu Jan 25 14:29:27 2001 > @@ -11,6 +11,7 @@ > #ifndef __KERNEL__ > #define __KERNEL__ > #include > +#include > #undef __KERNEL__ > #else > #endif > @@ -28,6 +29,16 @@ > #endif > kaddr_t MEM_MAP; > > +kaddr_t INIT_MM; > +kaddr_t KL_VMALLOC_START = 0xFFFFFFFF; > +kaddr_t KL_VMALLOC_END = 0xFFFFFFFF; > + > +#define VMALLOC_OFFSET (8*1024*1024) > +#define VMALLOC_START (((unsigned long) high_memory + 2*VMALLOC_OFFSET-1) & \ > + ~(VMALLOC_OFFSET-1)) > +#define VMALLOC_END (FIXADDR_START) > + > + > /* > * kl_init_kern_info() > */ > @@ -35,6 +46,7 @@ > kl_init_kern_info() > { > syment_t *sp; > + kaddr_t high_memory; > > kl_reset_error(); > if (!(sp = kl_lkup_symname("num_physpages"))) { > @@ -51,6 +63,19 @@ > return(1); > } > GET_BLOCK(sp->s_addr, 4, (void*)&MEM_MAP); > + > + if (!(sp = kl_lkup_symname("init_mm"))) { > + return(1); > + } > + /* init_mm is a structure offset and not a pointer */ > + INIT_MM = sp->s_addr; > + > + if (!(sp = kl_lkup_symname("high_memory"))) { > + return(1); > + } > + GET_BLOCK(sp->s_addr, 4, (void*)&high_memory); > + KL_VMALLOC_START = VMALLOC_START; > + KL_VMALLOC_END = VMALLOC_END; > > if (!(sp = kl_lkup_symname("__locore_lmabegin"))) { > return(1); > diff -Naur lkcd/lkcdutils/libklib/arch/i386/kl_page.c lkcdmod/lkcdutils/libklib/arch/i386/kl_page.c > --- lkcd/lkcdutils/libklib/arch/i386/kl_page.c Thu Nov 30 20:53:44 2000 > +++ lkcdmod/lkcdutils/libklib/arch/i386/kl_page.c Thu Jan 25 14:20:39 2001 > @@ -23,8 +23,8 @@ > > #else /* CONFIG_X86_PAE */ > > -#define KL_PGDIR_SHIFT (KL_PAGE_SHIFT+(KL_PAGE_SHIFT-3)*1) > -#define KL_PMD_SHIFT (KL_PAGE_SHIFT+(KL_PAGE_SHIFT-3)*1) > +#define KL_PGDIR_SHIFT (KL_PAGE_SHIFT+(KL_PAGE_SHIFT-2)*1) > +#define KL_PMD_SHIFT (KL_PAGE_SHIFT+(KL_PAGE_SHIFT-2)*1) > #define KL_PTRS_PER_PGD (1UL<<(KL_PAGE_SHIFT-2)) > #define KL_PTRS_PER_PMD 1 > #define KL_PTRS_PER_PTE (1UL<<(KL_PAGE_SHIFT-2)) > @@ -56,7 +56,10 @@ > > return pte_base; > #else /* CONFIG_X86_PAE */ > - return pmd_base; > + /* higher level routines are expecting a non virtual address > + * offset, which they will add KL_PAGE_OFFSET to. > + */ > + return pmd_base - KL_PAGE_OFFSET; > #endif /* CONFIG_X86_PAE */ > } > > diff -Naur lkcd/lkcdutils/libklib/include/klib.h lkcdmod/lkcdutils/libklib/include/klib.h > --- lkcd/lkcdutils/libklib/include/klib.h Wed Dec 6 15:08:13 2000 > +++ lkcdmod/lkcdutils/libklib/include/klib.h Thu Jan 25 14:34:38 2001 > @@ -84,6 +84,15 @@ > extern kaddr_t MEM_MAP; > extern kaddr_t deftask; > > +#ifdef DEBUG > +#define DPRINTF(x) fprintf x > +#else > +#define DPRINTF(x) > +#endif > +extern kaddr_t INIT_MM; > +extern kaddr_t KL_VMALLOC_START; > +extern kaddr_t KL_VMALLOC_END; > + > #define KL_ARCH lkcdinfo.arch > #define KL_PTRSZ lkcdinfo.ptrsz > #define KL_NBPW (KL_PTRSZ/8) > diff -Naur lkcd/lkcdutils/libklib/kl_mem.c lkcdmod/lkcdutils/libklib/kl_mem.c > --- lkcd/lkcdutils/libklib/kl_mem.c Thu Nov 30 20:52:16 2000 > +++ lkcdmod/lkcdutils/libklib/kl_mem.c Thu Jan 25 14:33:52 2001 > @@ -108,9 +108,19 @@ > if ((KL_ARCH == ARCH_I386) && (vaddr >= KL_LOCORE_START)) { > paddr = (KL_LOCORE_ADDR - KL_PAGE_OFFSET) + > (vaddr - KL_LOCORE_START); > - } else if (vaddr >= KL_PAGE_OFFSET) { > + } else if ((vaddr >= KL_PAGE_OFFSET) && (vaddr < KL_VMALLOC_START)) { > paddr = (vaddr - KL_PAGE_OFFSET); > } else { > + if ((vaddr >= KL_VMALLOC_START) && (vaddr < KL_VMALLOC_END)) { > + mmp = kl_alloc_block(MM_STRUCT_SZ, K_TEMP); > + GET_BLOCK(INIT_MM, MM_STRUCT_SZ, mmp); > + if (KL_ERROR) { > + kl_free_block(mmp); > + mmp = NULL; > + } else { > + mm_alloced++; > + } > + } > if (!mmp && deftask) { > tsp = kl_alloc_block(TASK_STRUCT_SZ, K_TEMP); > if (tsp) { > @@ -149,5 +159,8 @@ > if (mm_alloced) { > kl_free_block(mmp); > } > + > + DPRINTF((KL_ERRORFP, "kl_virtop: vaddr 0x%X paddr 0x%X error 0x%X\n", > + vaddr, paddr, KL_ERROR)); > return(paddr); > } From owner-lkcd@oss.sgi.com Thu Jan 25 15:19:10 2001 Received: by oss.sgi.com id ; Thu, 25 Jan 2001 15:19:00 -0800 Received: from tan7.ncr.com ([192.127.94.7]:25557 "EHLO esssol013.elsegundoca.ncr.com") by oss.sgi.com with ESMTP id ; Thu, 25 Jan 2001 15:18:46 -0800 Received: from eswssol002.elsegundoca.ncr.com (eswssol002 [141.206.1.4]) by esssol013.elsegundoca.ncr.com (8.9.2/8.9.2) with ESMTP id PAA01664 for ; Thu, 25 Jan 2001 15:18:47 -0800 (PST) Received: (from kim@localhost) by eswssol002.elsegundoca.ncr.com (8.8.7/8.8.5) id PAA16410 for lkcd@oss.sgi.com; Thu, 25 Jan 2001 15:18:39 -0800 (PST) Date: Thu, 25 Jan 2001 15:18:39 -0800 From: Moo Kim To: lkcd@oss.sgi.com Subject: lcrash3.0 vs. crash2.5 ? Message-ID: <20010125151839.E29190@mailbox.ElSegundoCA.NCR.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi, I recently joined the lkcd mailing and I have a newbie question. I am fairly new to Linux. I see there are two version of SVR4 UNIX crash-like utilities for Linux: 1. crash2.5 : http://www.missioncriticallinux.com/technology/crash/ 2. lcrash 3.0 : http://oss.sgi.com/projects/lkcd/ Is there any documentation/FAQ available that describes the difference between two, pros/cons, etc ? I tried to look thru the online documentation on each site and deja news, but could not find any relavent info. If someone had hands-on experience with both utilities, could you please share ? We (in NCR Corp) is looking into porting one of the existing software product (Teradata RDBMS) on Linux and this product has the kernel device driver which will be implemented as loadable module. I would be interested in knowing whether lcrash3.0 currently provide the following capability: README file in crash2.5 stated as one needs to recompile the kernel with -g option (to get debug symbol info). Does lcrash3.0 require for kernel to compie with -g option as well ? Because -g option for kernel build may not be desireable for the kernel running on a production box. It would be nice to be able to use lcrash for analyzing Linux panic dumps (as well as live system) that have kernel compiled with/without -g option. This same question also goes to kernel module as well. I see lcrash3.0 provides the 'Kerntypes' target and perhaps this is the way to load the kernel symbol information for non-debug kernel (?). Thanks in advance, Moo Kim Moo.Kim@NCR.COM NCR Corporation ph: 858-485-2233 fax: 858-485-2032 From owner-lkcd@oss.sgi.com Thu Jan 25 16:04:01 2001 Received: by oss.sgi.com id ; Thu, 25 Jan 2001 16:03:50 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:8306 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 25 Jan 2001 16:03:26 -0800 Received: from loco.csd.sgi.com ([150.166.1.62]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA00576 for ; Thu, 25 Jan 2001 16:03:19 -0800 (PST) mail_from (tjm@sgi.com) Received: from sgi.com (localhost.csd.sgi.com [127.0.0.1]) by loco.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA38841; Thu, 25 Jan 2001 16:01:48 -0800 (PST) Message-ID: <3A70BE6C.1B4401EC@sgi.com> Date: Thu, 25 Jan 2001 16:01:48 -0800 From: Tom Morano X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Moo Kim CC: lkcd@oss.sgi.com Subject: Re: lcrash3.0 vs. crash2.5 ? References: <20010125151839.E29190@mailbox.ElSegundoCA.NCR.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi Moo, Glad to have you join the LKCD list. I'll address your questions below. Moo Kim wrote: > > Hi, > > I recently joined the lkcd mailing and I have a newbie > question. I am fairly new to Linux. > > I see there are two version of SVR4 UNIX crash-like > utilities for Linux: > > 1. crash2.5 : http://www.missioncriticallinux.com/technology/crash/ > 2. lcrash 3.0 : http://oss.sgi.com/projects/lkcd/ > > Is there any documentation/FAQ available that describes the > difference between two, pros/cons, etc ? I tried to look > thru the online documentation on each site and deja news, > but could not find any relavent info. If someone had > hands-on experience with both utilities, could you please > share ? I have only limited knowledge of the crash2.5 tool from Mission Critical Linux, so I'll leave feedback on that tool for someone who is more familiar with it. I am, however, very familiar with lcrash, as I am its primary developer. > > We (in NCR Corp) is looking into porting one of the existing > software product (Teradata RDBMS) on Linux and this product > has the kernel device driver which will be implemented as > loadable module. I would be interested in knowing whether > lcrash3.0 currently provide the following capability: > > README file in crash2.5 stated as one needs to recompile > the kernel with -g option (to get debug symbol info). > > Does lcrash3.0 require for kernel to compie with -g option > as well ? Because -g option for kernel build may not be > desireable for the kernel running on a production box. > It would be nice to be able to use lcrash for analyzing Linux > panic dumps (as well as live system) that have kernel compiled > with/without -g option. This same question also goes to > kernel module as well. I see lcrash3.0 provides the > 'Kerntypes' target and perhaps this is the way to load the > kernel symbol information for non-debug kernel (?). You are correct in your assumption. Prior to the 3.0 release, lcrash was built right along with the kernel. It knew the exact arrangement of various kernel data structures because they were compiled in. The downside to this was, that the copy of lcrash you used had to be the one that matched the individual kernel you were examining. With the 3.0 release, almost all direct references to kernel header files were removed. Instead, a facility was added that would allow lcrash to determine the proper offsets to fields in kernel structures using the type information contained in the stabs portion of the symbol table. In order to get stabs data, you need to compile using the -gstabs compiler option. This, of course, is not practical when you are talking about a production kernel. What we did, however, was add a dummy module to the kernel (init/kerntypes.c) that gets built with the -gstabs flag set. The resulting object file never gets included in the kernel build. Instead, it is renamed to be the Kerntypes target you refer to above. This, along with the System.map target provide lcrash with all the type and symbol mapping information it needs. Using this mechanism, it is possible for a single lcrash binary to read core dumps from multiple kernels (include 2.2.x and 2.4.x kernels) -- all without recompiling. A side benefit to this new approach was that we no longer needed to include lcrash in the kernel source tree. The lcrash utility is now installed via the lkcdutils RPM (full source is also available for download). One other difference that I know of has to do with the generation of kernel task backtraces. The lcrash backtrace facility does not require that your i386 kernel be built using one of the registers as a frame pointer. I believe that that this is a requirement with the MC Linux tool. Also, lcrash, and LKCD, provide support for Intel ia64 boxes. I might note that, in addition to the differences in crash dump analysis tools, there are big differences in the kernel modifications necessary to generate system dumps after a PANIC. If you are interested in a more detailed comparison, you can take a look at the paper we presented at LinuxWorld 2000 in New York, NY. The paper and presentation slides are available for download from the following URL: ftp://oss.sgi.com/www/projects/lkcd/download/doc/linuxworld2000/ Hope this answers your questions. Thanks, Tom From owner-lkcd@oss.sgi.com Thu Jan 25 16:47:41 2001 Received: by oss.sgi.com id ; Thu, 25 Jan 2001 16:47:31 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:62479 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 25 Jan 2001 16:47:11 -0800 Received: (qmail 29622 invoked from network); 26 Jan 2001 00:47:06 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 26 Jan 2001 00:47:06 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Dave Craft cc: lkcd@oss.sgi.com Subject: Re: module traceback working In-reply-to: Your message of "Thu, 25 Jan 2001 15:57:30 MDT." <200101252157.PAA18134@craft.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Jan 2001 11:47:05 +1100 Message-ID: <19867.980470025@ocs3.ocs-net> Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing On Thu, 25 Jan 2001 15:57:30 -0600 (CST), Dave Craft wrote: >After you fix this in lcrash you have to run it with a System.map >that has the additional symbols from your module. You can get your >modules symbol table at load time by using the -m option on insmod. >Note you have to strip out all the extraneous stuff out of this map. > > cat .map | awk '/ [TtDd] / {print $0}' >> tmp.map > >Then append this to a new COPY of the /boot/System.map and do >(sort -u) on the file. You can give lcrash this file as an >option or just link /boot/System.map to your new symbol file. insmod -m is not reliable. There is no corresponding hook for removing a symbol table when a module is removed. Using insmod -m is a manual process, you have to set that option on every insmod and merge all the module symbols together. There is a much better method, just create /var/log/ksymoops and both insmod and rmmod will automatically save /proc/ksyms after load and unload. This log is intended for ksymoops which has exactly the same problems as lkcd, but the log can obviously be used for any kernel debugger. man insmod, see ksymoops assistance. modutils 2.4.2 adds a log file for modprobe commands so you can track the commands the kernel issued, this also uses /var/log/ksymoops.