From owner-lkcd@oss.sgi.com Mon Sep 4 06:09:17 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 06:08:58 -0700 Received: from f237.law4.hotmail.com ([216.33.149.237]:18950 "EHLO hotmail.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 06:08:24 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Sep 2000 06:07:53 -0700 Received: from 204.177.156.26 by lw4fd.law4.hotmail.msn.com with HTTP; Mon, 04 Sep 2000 13:07:53 GMT X-Originating-IP: [204.177.156.26] From: "Sushil Agrawal" To: lkcd@oss.sgi.com Subject: lkcd on Linux 2.3.99-pre9 Date: Mon, 04 Sep 2000 13:07:53 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Sep 2000 13:07:53.0769 (UTC) FILETIME=[22D23190:01C01671] Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi, I downloaded the lkcd from the following site: ftp://oss.sgi.com/projects/lkcd/download/2.0.1/ During making the '/usr/src/linux/cmd' directory, ld gave the error that klib not found (because of -lklib in the Makefile). >From where should I get this klib library? I am running Linux 2.3.99 on a pentium pc. Thanks, Sushil. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-lkcd@oss.sgi.com Mon Sep 4 11:41:28 2000 Received: by oss.sgi.com id ; Mon, 4 Sep 2000 11:41:19 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:46875 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 4 Sep 2000 11:40:48 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA28542 for ; Mon, 4 Sep 2000 11:31:53 -0700 (PDT) mail_from (tjm@sgi.com) Received: from loco.csd.sgi.com (loco.csd.sgi.com [150.166.1.62]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA74585 for ; Mon, 4 Sep 2000 11:39:01 -0700 (PDT) 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 LAA86050; Mon, 4 Sep 2000 11:36:30 -0700 (PDT) Message-ID: <39B3EBAD.16660944@sgi.com> Date: Mon, 04 Sep 2000 11:36:29 -0700 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: Sushil Agrawal CC: lkcd@oss.sgi.com, Tom Morano Subject: Re: lkcd on Linux 2.3.99-pre9 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 Sushil Agrawal wrote: > > Hi, > > I downloaded the lkcd from the following site: > > ftp://oss.sgi.com/projects/lkcd/download/2.0.1/ > > During making the '/usr/src/linux/cmd' directory, ld > gave the error that klib not found (because of -lklib > in the Makefile). > > >From where should I get this klib library? Hi Sushil, The klib library is part of LKCD. The fact that it isn't being built means that one of the modules in the library is not being built. Check earlier in the build output to see where it may be failing. Most likely it is because of a problem in a Makefile, that has subsequently been fixed. You might want to check the latest version of lcrash out from the source repository on SourceForge and try that. The libklib library is in the kernel/cmd/lcrash sub directory. If the lcrash build fails for some reason, the kernel build will fail too. Thanks, Tom > > I am running Linux 2.3.99 on a pentium pc. > > Thanks, > Sushil. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. From owner-lkcd@oss.sgi.com Wed Sep 13 00:43:36 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 00:43:26 -0700 Received: from pallas.veritas.com ([204.177.156.25]:31991 "EHLO pallas.veritas.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 00:43:05 -0700 Received: from megami.veritas.com (megami.veritas.com [192.203.46.101]) by pallas.veritas.com (8.9.1a/8.9.1) with SMTP id AAA01001 for ; Wed, 13 Sep 2000 00:43:07 -0700 (PDT) Received: from [172.16.5.30]([172.16.5.30]) (540 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Wed, 13 Sep 2000 00:43:03 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #4 built 1999-Aug-24) Date: Wed, 13 Sep 2000 01:15:43 +0530 (IST) From: Sushil X-Sender: sushil@fs4.vxindia.veritas.com To: lkcd@oss.sgi.com Subject: lkcd patch for 2.4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi, Is there a lkcd patch for 2.4 kernels (specifically 2.4 test4)? Thanks, Sushil. From owner-lkcd@oss.sgi.com Wed Sep 13 09:53:10 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 09:53:00 -0700 Received: from smtp.alacritech.com ([209.10.208.82]:45834 "EHLO smtp.alacritech.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 09:52:52 -0700 Received: from [10.1.1.27] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id hcmhaaaa for ; Wed, 13 Sep 2000 09:51:44 -0700 Message-ID: <39BFB145.75319FE8@alacritech.com> Date: Wed, 13 Sep 2000 09:54:29 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sushil CC: lkcd@oss.sgi.com Subject: Re: lkcd patch for 2.4 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 Yes -- If anyone is interested in the patch, let me know, and I'll send it to your personally. I can't send it to this list, and they are in the process of cleaning up my account on oss.sgi.com so I can put the latest image up. It's against 2.4.0-test7. You have to build cmd/lcrash by hand for now, but the kernel stuff configs and builds into your kernel just fine. --Matt Sushil wrote: > > Hi, > Is there a lkcd patch for 2.4 kernels (specifically 2.4 test4)? > > Thanks, > Sushil. From owner-lkcd@oss.sgi.com Mon Sep 18 04:57:40 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 04:57:30 -0700 Received: from [204.177.156.25] ([204.177.156.25]:2783 "EHLO pallas.veritas.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 04:57:09 -0700 Received: from megami.veritas.com (megami.veritas.com [192.203.46.101]) by pallas.veritas.com (8.9.1a/8.9.1) with SMTP id EAA26189 for ; Mon, 18 Sep 2000 04:55:19 -0700 (PDT) Received: from [172.16.5.30]([172.16.5.30]) (4573 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Mon, 18 Sep 2000 04:55:12 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #4 built 1999-Aug-24) Date: Mon, 18 Sep 2000 05:28:13 +0530 (IST) From: Sushil X-Sender: sushil@fs4.vxindia.veritas.com To: lkcd@oss.sgi.com Subject: lkcd with modules Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi, I am using lkcd with 2.4.0-test7 kernel using the latest lkcd patch for 2.4.0-test7. Is it possible to use lkcd for debugging modules? Specifically, is it possible to - 1. get trace of a process which was executing a function from a dynamically loaded module at the time of crash? 2. get the disassembly of a function from a dynamically loaded module whose pages are in the lkcd dump? assuming that the virtual addresses of module symbols are available (using insmod -m) and are integrated with System.map and are supplied to lcrash. Using lcrash I am not able to do the above two things and to me it seems impossible because lcrash converts the virtual addresses to physical addresses by subtracting the PAGE_OFFSET (= 0xc0000000) from the virtual address (kl_virtop function in lib/libklib/arch/i386/kl_mem.c). kl_virtop(kaddr_t vaddr, void *m) { . . . } else if (vaddr >= KL_PAGE_OFFSET) { paddr = (vaddr - KL_PAGE_OFFSET); . . . } This works fine with statically compiled kernel symbols but does not work with modules because module symbols are assigned virtual addresses much above the (PAGE_OFFSET + total_ram) mark (using __vmalloc) and therefore virtual_address - PAGE_OFFSET will not give the correct physical addresses for the virtual addresses corresponding to module symbols. For example: In my case a module was assigned virtual addresses starting from 0xc8829060. I have 128 MB of ram. But (0xc8829060 - 0xc0000000) gives a starting physical address of 142774368 for the module which is around 136 MB which is greater than the total ram (128 MB). When lcrash tries to read this address in the saved crash dump or in the online /dev/mem, it gets error because that offset does not exist in the ram. Is there a way to use lkcd with modules? I read the following mail from the Nov. 1999 lkcd mailing-list archive and it seems somebody is working on using lkcd with modules. ------------------------------------------------------------ From owner-lkcd@oss.sgi.com Thu Nov 11 21:49:19 1999 Received: by oss.sgi.com id ; Thu, 11 Nov 1999 21:49:10 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:41996 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 11 Nov 1999 21:48:51 -0800 Received: (qmail 16033 invoked by uid 502); 12 Nov 1999 05:54:03 -0000 Message-ID: <19991112055403.16032.qmail@mail.ocs.com.au> Received: (qmail 16026 invoked from network); 12 Nov 1999 05:54:02 -0000 Received: from ocs4.ocs-net (192.168.255.4) by mail.ocs.com.au with SMTP; 12 Nov 1999 05:54:02 -0000 X-Mailer: exmh version 2.0.2 From: Keith Owens To: lkcd@oss.sgi.com Subject: Re: LKCD Priority List In-reply-to: Your message of "Thu, 11 Nov 1999 16:42:58 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Nov 1999 16:54:01 +1100 Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing On Thu, 11 Nov 1999 16:42:58 -0800 (PST), Matt Robinson wrote: > - A port to Linux 2.3.X (latest). Done for 2.3.26, bar the lack of kernel mappings for kiobufs. When SCT finishes his new kiobuf mapping mechanism, I'll upgrade my patch, get it working and release it. >There may be other points I'm neglecting, so feel free to point out >what you feel is missing or something you'd like to see. Thanks. Module support. We need to dump pages occupied by modules and construct a merged System.map that includes all the module symbols as well as the kernel symbols. ksymoops -s already builds a merged map from System.map, /proc/ksyms and the module object files, no point in reinventing the wheel. As both the ksymoops and modutils maintainer, I guess I'll volunteer to hook ksymoops and lkcd together. ---------------------------------------------------------------------- Any information, pointers etc. will be very helpful and appreciated. Thanks and Regards, Sushil. From owner-lkcd@oss.sgi.com Tue Sep 19 11:05:24 2000 Received: by oss.sgi.com id ; Tue, 19 Sep 2000 11:05:14 -0700 Received: from smtp.alacritech.com ([209.10.208.82]:50192 "EHLO smtp.alacritech.com") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 11:05:00 -0700 Received: from [10.1.1.164] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id zduhaaaa for ; Tue, 19 Sep 2000 11:03:37 -0700 Message-ID: <39C7AB29.47EF5699@alacritech.com> Date: Tue, 19 Sep 2000 11:06:33 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sushil CC: lkcd@oss.sgi.com Subject: Re: lkcd with modules 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 Sushil wrote: > Hi, > > I am using lkcd with 2.4.0-test7 kernel using the latest lkcd > patch for 2.4.0-test7. > > Is it possible to use lkcd for debugging modules? Specifically, > is it possible to - > > 1. get trace of a process which was executing a function from > a dynamically loaded module at the time of crash? Currently there's no mechanism for dumping out stack traces into modules. This is something that still has to be done. We realize it is a big hole in lcrash at this point, but other priorities, such as working with IA64, have taken precedence. > 2. get the disassembly of a function from a dynamically loaded > module whose pages are in the lkcd dump? Same issue. Disassembly works if it knows where to read the instructions from. > assuming that the virtual addresses of module symbols are available > (using insmod -m) and are integrated with System.map and are > supplied to lcrash. > > Using lcrash I am not able to do the above two things and > to me it seems impossible because lcrash converts > the virtual addresses to physical addresses by subtracting > the PAGE_OFFSET (= 0xc0000000) from the virtual address > > (kl_virtop function in lib/libklib/arch/i386/kl_mem.c). > > kl_virtop(kaddr_t vaddr, void *m) > { > > . . . > > } else if (vaddr >= KL_PAGE_OFFSET) { > paddr = (vaddr - KL_PAGE_OFFSET); > > . . . > > } > > This works fine with statically compiled kernel symbols but > does not work with modules because module symbols are assigned > virtual addresses much above the (PAGE_OFFSET + total_ram) > mark (using __vmalloc) and therefore virtual_address - PAGE_OFFSET > will not give the correct physical addresses for the virtual > addresses corresponding to module symbols. Right. > For example: > In my case a module was assigned virtual addresses starting > from 0xc8829060. I have 128 MB of ram. > But (0xc8829060 - 0xc0000000) gives a starting physical address > of 142774368 for the module which is around 136 MB which is greater > than the total ram (128 MB). When lcrash tries to read this address > in the saved crash dump or in the online /dev/mem, it gets error because > that offset does not exist in the ram. > > Is there a way to use lkcd with modules? Again, not currently. It's something that we know we have to do, but we're trying to finalize how to get our stuff into the kernel (the right way this time) and then we can attack that problem. Keith Owens has already spoken to us about helping to get this to work (even if it is just a pointer to some code he's written). --Matt From owner-lkcd@oss.sgi.com Wed Sep 20 22:34:49 2000 Received: by oss.sgi.com id ; Wed, 20 Sep 2000 22:34:29 -0700 Received: from pallas.veritas.com ([204.177.156.25]:38057 "EHLO pallas.veritas.com") by oss.sgi.com with ESMTP id ; Wed, 20 Sep 2000 22:34:13 -0700 Received: from megami.veritas.com (megami.veritas.com [192.203.46.101]) by pallas.veritas.com (8.9.1a/8.9.1) with SMTP id WAA18918; Wed, 20 Sep 2000 22:34:20 -0700 (PDT) Received: from [172.16.5.30]([172.16.5.30]) (6274 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Wed, 20 Sep 2000 22:34:11 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #4 built 1999-Aug-24) Date: Wed, 20 Sep 2000 23:06:07 +0530 (IST) From: Sushil X-Sender: sushil@fs4.vxindia.veritas.com To: "Matt D. Robinson" cc: lkcd@oss.sgi.com, Sushil Subject: Re: lkcd with modules In-Reply-To: <39C7AB29.47EF5699@alacritech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Hi Matt, I added a small code to the kl_mem.c which converts a virtual address to physical address through the page tables. The patch is appended below. Using this code I am able to disassemble functions of a module which resides in the saved dump. But when I try to print trace of processes which were working with the module functions (using trace -a), lcrash loops and infinitely oscillates between the kl_virtop() and kl_virtop_nonident() (new function added) functions with the same set of virtual addresses. I am looking at it but surely suggestions/comments from you will help in quickly locating and solving the problem. Thanks and Regards. Sushil. --- linux1/cmd/lcrash/lib/libklib/arch/i386/kl_mem.c Wed Sep 20 13:38:28 2000 +++ linux/cmd/lcrash/lib/libklib/arch/i386/kl_mem.c Wed Sep 20 13:23:17 2000 @@ -86,6 +86,45 @@ return(paddr); } + +/* + * kl_virtop_nonident() + * + * Translate a virtual address into a physical address without + * assuming the identity mapping - works through page tables. + * + */ +#define PGDIR_BASE 0x00101000 +#define PTRS_PER_PTE 1024 +kaddr_t +kl_virtop_nonident(kaddr_t vaddr) +{ + kaddr_t dir_base, dir_off, dir_entry; + kaddr_t pte_base, pte, pte_val, paddr; + + dir_base = PGDIR_BASE; + dir_off = (vaddr >> 22) * 4; + dir_entry = dir_base + dir_off; + kl_readmem(dir_entry, 4, &pte_base); + if (KL_ERROR) { + return(0); + } + /* Take the top 20 bits of the pgd entry */ + pte_base &= 0xfffff000; + pte = pte_base + (((vaddr >> 12) & (PTRS_PER_PTE -1)) * 4); + kl_readmem(pte, 4, &pte_val); + if (KL_ERROR) { + return(0); + } + /* Take the top 20 bits of the pte entry */ + paddr = pte_val & 0xfffff000; + + /* Go to the desired offset in the page */ + paddr += (vaddr & (4096 -1)); + return paddr; +} + + /* * kl_virtop() * @@ -105,7 +144,15 @@ paddr = (KL_LOCORE_ADDR - KL_PAGE_OFFSET) + (vaddr - KL_LOCORE_START); } else if (vaddr >= KL_PAGE_OFFSET) { + static dump_header_t dh, *dhp = NULL; paddr = (vaddr - KL_PAGE_OFFSET); + if(!dhp) { + get_dump_header(&dh); + dhp = &dh; + } + if(paddr > dh.dh_memory_size * KL_PAGE_SIZE) { + paddr = kl_virtop_nonident(vaddr); + } } else { if (!mmp && deftask) { tsp = (struct task_struct*) --- linux1/cmd/lcrash/lib/libklib/arch/i386/kl_task.c Wed Sep 20 13:38:28 2000 +++ linux/cmd/lcrash/lib/libklib/arch/i386/kl_task.c Wed Sep 20 13:25:18 2000 @@ -153,7 +153,7 @@ /* * get_dump_header() */ -static int +int get_dump_header(dump_header_t *dump_header) { /* first, make sure this isn't a live system --------------------------------------------------------------------------- On Tue, 19 Sep 2000, Matt D. Robinson wrote: > Sushil wrote: > > Hi, > > > > I am using lkcd with 2.4.0-test7 kernel using the latest lkcd > > patch for 2.4.0-test7. > > > > Is it possible to use lkcd for debugging modules? Specifically, > > is it possible to - > > > > 1. get trace of a process which was executing a function from > > a dynamically loaded module at the time of crash? > > Currently there's no mechanism for dumping out stack traces into > modules. This is something that still has to be done. We realize > it is a big hole in lcrash at this point, but other priorities, > such as working with IA64, have taken precedence. > > > 2. get the disassembly of a function from a dynamically loaded > > module whose pages are in the lkcd dump? > > Same issue. Disassembly works if it knows where to read the > instructions from. > > > assuming that the virtual addresses of module symbols are available > > (using insmod -m) and are integrated with System.map and are > > supplied to lcrash. > > > > Using lcrash I am not able to do the above two things and > > to me it seems impossible because lcrash converts > > the virtual addresses to physical addresses by subtracting > > the PAGE_OFFSET (= 0xc0000000) from the virtual address > > > > (kl_virtop function in lib/libklib/arch/i386/kl_mem.c). > > > > kl_virtop(kaddr_t vaddr, void *m) > > { > > > > . . . > > > > } else if (vaddr >= KL_PAGE_OFFSET) { > > paddr = (vaddr - KL_PAGE_OFFSET); > > > > . . . > > > > } > > > > This works fine with statically compiled kernel symbols but > > does not work with modules because module symbols are assigned > > virtual addresses much above the (PAGE_OFFSET + total_ram) > > mark (using __vmalloc) and therefore virtual_address - PAGE_OFFSET > > will not give the correct physical addresses for the virtual > > addresses corresponding to module symbols. > > Right. > > > For example: > > In my case a module was assigned virtual addresses starting > > from 0xc8829060. I have 128 MB of ram. > > But (0xc8829060 - 0xc0000000) gives a starting physical address > > of 142774368 for the module which is around 136 MB which is greater > > than the total ram (128 MB). When lcrash tries to read this address > > in the saved crash dump or in the online /dev/mem, it gets error because > > that offset does not exist in the ram. > > > > Is there a way to use lkcd with modules? > > Again, not currently. It's something that we know we have to do, > but we're trying to finalize how to get our stuff into the kernel > (the right way this time) and then we can attack that problem. > Keith Owens has already spoken to us about helping to get this > to work (even if it is just a pointer to some code he's written). > > --Matt > From owner-lkcd@oss.sgi.com Thu Sep 21 10:44:04 2000 Received: by oss.sgi.com id ; Thu, 21 Sep 2000 10:43:54 -0700 Received: from smtp.alacritech.com ([209.10.208.82]:39951 "EHLO smtp.alacritech.com") by oss.sgi.com with ESMTP id ; Thu, 21 Sep 2000 10:43:41 -0700 Received: from [10.1.1.164] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id jsxhaaaa for ; Thu, 21 Sep 2000 10:42:19 -0700 Message-ID: <39CA492D.EFD240FD@alacritech.com> Date: Thu, 21 Sep 2000 10:45:17 -0700 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sushil CC: lkcd@oss.sgi.com Subject: Re: lkcd with modules 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 I'll patch this in, but I need to make sure that I add some of the fields into a new kernel struct -- dumpdata_t. There's the intention to now develop LKCD so that the kernel portion is minimal, but we build a kernel namelist object that has everything we need in it, so we can dynamically walk through structures. This will get us back to a more reasonable (and desirable) state of not having to re-compile 'lcrash' every time there's a new kernel build. --Matt Sushil wrote: > Hi Matt, > > I added a small code to the kl_mem.c which converts a virtual address > to physical address through the page tables. The patch is appended below. From owner-lkcd@oss.sgi.com Sun Sep 24 22:49:22 2000 Received: by oss.sgi.com id ; Sun, 24 Sep 2000 22:49:13 -0700 Received: from [204.177.156.25] ([204.177.156.25]:48809 "EHLO pallas.veritas.com") by oss.sgi.com with ESMTP id ; Sun, 24 Sep 2000 22:48:52 -0700 Received: from megami.veritas.com (megami.veritas.com [192.203.46.101]) by pallas.veritas.com (8.9.1a/8.9.1) with SMTP id WAA07367; Sun, 24 Sep 2000 22:48:57 -0700 (PDT) Received: from pelican.vxindia.veritas.com([172.16.5.31]) (1434 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Sun, 24 Sep 2000 22:48:44 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #4 built 1999-Aug-24) Date: Mon, 25 Sep 2000 01:28:04 +0530 (IST) From: Sushil X-Sender: sushil@linuxmp1.vxindia.veritas.com To: Keith Owens cc: linux-kernel@vger.kernel.org, lkcd@oss.sgi.com Subject: Re: kernel compiled with frame pointer In-Reply-To: <21480.969751664@ocs3.ocs-net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Content-Length: 778 Lines: 22 Hi Keith, Thanks for the useful information. > >What about CONFIG_KDB_FRAMEPTR? Is it correct to use this in a standard > >kernel to find whether the kernel is being compiled with frame pointer? > > I don't know which kernel you are looking at. CONFIG_KDB_FRAMEPTR is > part of an old kdb patch, not part of the standard kernel. It has been > removed from current kdb patches, kdb patches after May 9 2000 use > CONFIG_FRAME_POINTER. I saw CONFIG_KDB_FRAMEPTR being used in the LKCD patch for 2.4.0-test7 (arch/i386/kernel/vmdump.c). If I am correct then it is used there to find out if the kernel is being compiled with frame pointer (inorder to get the correct offset of the return address). I think CONFIG_FRAME_POINTER should be used instead. Regards, Sushil. From owner-lkcd@oss.sgi.com Tue Sep 26 04:46:42 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 04:46:33 -0700 Received: from ausmtp01.au.ibm.COM ([202.135.136.97]:2314 "EHLO ausmtp01.au.ibm.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 04:46:06 -0700 Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA59270 for ; Tue, 26 Sep 2000 21:34:43 +1000 From: rbharata@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m3/NCO v4.93) with SMTP id WAA51978 for ; Tue, 26 Sep 2000 22:45:27 +1100 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256966.0040933F ; Tue, 26 Sep 2000 22:45:19 +1100 X-Lotus-FromDomain: IBMIN@IBMAU To: lkcd@oss.sgi.com Message-ID: Date: Tue, 26 Sep 2000 11:16:42 +0530 Subject: esp value in dump header 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 Content-Length: 644 Lines: 27 Hi, While configuring the dump header when in kernel mode, the vaule of esp is got as dha->dha_regs.esp = (unsigned long) (regs + 1); (in __dump_configure_header() in arch/i386/vmdump.c) This doesn't give the true value of esp when crash occured, because of which the back trace will not show the correct result in lcrash. This will work correctly if esp is obtained as follows: dha->dha_regs.esp = (unsigned long) (®s->esp); Would you please check this? Regards, Bharata Bharata. B. Rao Linux Technology Center, IBM Global Services, Bangalore. E-mail : rbharata@in.ibm.com Phone : 91-80-5262355, Extn : 2534.