From owner-lkcd@oss.sgi.com Mon Jan 3 13:54:05 2000 Received: by oss.sgi.com id ; Mon, 3 Jan 2000 13:53:55 -0800 Received: from mailext02.compaq.com ([207.18.199.33]:55690 "HELO mailext02.compaq.com") by oss.sgi.com with SMTP id ; Mon, 3 Jan 2000 13:53:36 -0800 Received: by mailext02.compaq.com (Postfix, from userid 12345) id 00F149A80E; Mon, 3 Jan 2000 15:54:12 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id E20C690D84; Mon, 3 Jan 2000 15:54:12 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 8813B4FB01; Mon, 3 Jan 2000 15:54:05 -0600 (CST) Received: from cxo3ns.cxo.dec.com (cxo3ns.cxo.dec.com [16.63.0.10]) by mailint12.im.hou.compaq.com (Postfix) with SMTP id D3C2C4C901; Mon, 3 Jan 2000 15:54:04 -0600 (CST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA22647; Mon, 3 Jan 2000 14:54:11 -0700 Received: from dhcp128-112.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA09574; Mon, 3 Jan 2000 14:54:10 -0700 Received: by compaq.com (sSMTP sendmail emulation); Mon, 3 Jan 2000 14:53:43 -0700 Content-Length: 3541 Message-Id: X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: Date: Mon, 03 Jan 2000 14:53:43 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: Matt Robinson Subject: dump_header changes for Alpha Cc: lkcd@oss.sgi.com Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Since Intel & Alpha will be sharing the dump_header_t strucure, I thought there might be a problem with using 64 bit values on the Intel side, so I just added fields for Alpha matching Alpha's dh_regs. If this isn't a problem, I can just remove dh_esp and dh_eip from this structure. However, then the naming convention will match Alpha's dh_regs and not Intel's... Is there a reason we couldn't just store the pc & sp for either platform into the appropriate slot in pt_regs here? IOW, remove dh_esp, dh_eip, dh_pc, dh_ps, and pick the variable name based on the platform, i.e. in arch-alpha/vmdump.c: pt_regs->ps = sptr; pt_regs->pc = &&dump_here; Of course the code called after __dump_execute would need to refer to the registers this way also. Or will this not work because pt_regs gets overwritten? OK, here is my proposed change to dump_header_t.: typedef struct _dump_header_s { /* the dump magic number -- unique to verify dump is valid */ uint64_t dh_magic_number; /* the version number of this dump */ uint32_t dh_version; /* the size of this header (in case we can't read it) */ uint32_t dh_header_size; /* the level of this dump (just a header?) */ uint32_t dh_dump_level; /* the size of a Linux memory page (4K, 8K, 16K, etc.) */ uint32_t dh_page_size; /* the size of all physical memory */ uint64_t dh_memory_size; /* the start of physical memory */ uint64_t dh_memory_start; /* the end of physical memory */ uint64_t dh_memory_end; /* the esp for i386 systems -- MOVE LATER */ uint32_t dh_esp; /* the eip for i386 systems -- MOVE LATER */ uint32_t dh_eip; /* the program counter for Alpha systems -- ADDED */ uint64_t dh_pc; /* the stack pointer for Alpha systems -- ADDED */ uint64_t dh_ps; /* the number of pages in this dump specifically */ uint32_t dh_num_pages; /* the panic string, if available */ char dh_panic_string[DUMP_PANIC_LEN]; /* the time of the system crash */ struct timeval dh_time; /* the utsname (uname) information */ struct new_utsname dh_utsname; /* the dump registers */ struct pt_regs dh_regs; /* the address of the current task */ struct task_struct *dh_current_task; } dump_header_t; On 22-Dec-1999 Matt Robinson wrote: > On Fri, 24 Dec 1999, Brian Hall wrote: >|>That fixed the vmdump.h problem. Now it actually compiles, with warnings >|>(implied casts). I notice that dh_esp and dh_eip are 32 bits wide; they will >|>need to be 64 bit for Alpha; and the other uint32_t(s) in vmdump.c >|>(__dump_execute) will also need to be uint64_t(s), and the changes >|>propagated, correct? >|> >|>Now, should I go ahead and change dump_header_t to (choose one): >|>1) make dh_esp,etc uint64_t(s) in the header; > > I'd make them whatever the dh_esp and dh_eip equivalents are in the > pt_regs structure for SP and PC. > >|>2) add fields specifically for alpha; >|>3) do #1 and change them to dh_sp and dh_pc while I'm at it? > > Do the name change while you're at it. I'll change things in our patch. -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Mon Jan 3 15:07:55 2000 Received: by oss.sgi.com id ; Mon, 3 Jan 2000 15:07:45 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:28026 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 3 Jan 2000 15:07:29 -0800 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [150.166.9.10]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09313 for ; Mon, 3 Jan 2000 15:10:12 -0800 (PST) mail_from (yakker@engr.sgi.com) Received: from bubula.csd.sgi.com (bubula.csd.sgi.com [150.166.1.69]) by rock.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA85261; Mon, 3 Jan 2000 15:07:56 -0800 (PST) mail_from (yakker@engr.sgi.com) Received: from localhost by bubula.csd.sgi.com via SMTP (980427.SGI.8.8.8/910605.CSDSGI) id PAA78948; Mon, 3 Jan 2000 15:07:54 -0800 (PST) Date: Mon, 3 Jan 2000 15:07:53 -0800 (PST) From: Matt Robinson X-Sender: yakker@bubula.csd.sgi.com Reply-To: Matt Robinson To: Brian Hall cc: Matt Robinson , lkcd@oss.sgi.com Subject: Re: dump_header changes for Alpha In-Reply-To: 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 Well, what _really_ needs to happen, and I'll do this for 1.0.4, is to do the following (and I intended to do this from the beginning, but we were desperate to get something out the door): +-----------------------------------+ | generic dump header | +-----------------------------------+ | architecture specific dump header | +-----------------------------------+ | | | rest of dump | | | +-----------------------------------+ That way, we can differentiate the generic from the processor specific stuff. So what we do is stuff the dump header into the top of the dump_page_buf, then write the architecture specific header right after it. Then you can have whatever you want in there, and it doesn't matter as far as other architectures are concerned. We can also add an dh_arch_type flag to the base dump header so you know what architecture the dump is for. Your thoughts? If you agree, I'll do this and have it out by the end of this week. --Matt On Mon, 3 Jan 2000, Brian Hall wrote: |>Since Intel & Alpha will be sharing the dump_header_t strucure, I thought there |>might be a problem with using 64 bit values on the Intel side, so I just added |>fields for Alpha matching Alpha's dh_regs. If this isn't a problem, I can just |>remove dh_esp and dh_eip from this structure. However, then the naming |>convention will match Alpha's dh_regs and not Intel's... |> |>Is there a reason we couldn't just store the pc & sp for either |>platform into the appropriate slot in pt_regs here? |> |>IOW, remove dh_esp, dh_eip, dh_pc, dh_ps, and pick the variable name based on |>the platform, i.e. in arch-alpha/vmdump.c: |> |>pt_regs->ps = sptr; |>pt_regs->pc = &&dump_here; |> |>Of course the code called after __dump_execute would need to refer to the |>registers this way also. Or will this not work because pt_regs gets overwritten? |> |> |> |>OK, here is my proposed change to dump_header_t.: |> |> |>typedef struct _dump_header_s { |> /* the dump magic number -- unique to verify dump is valid */ |> uint64_t dh_magic_number; |> |> /* the version number of this dump */ |> uint32_t dh_version; |> |> /* the size of this header (in case we can't read it) */ |> uint32_t dh_header_size; |> |> /* the level of this dump (just a header?) */ |> uint32_t dh_dump_level; |> |> /* the size of a Linux memory page (4K, 8K, 16K, etc.) */ |> uint32_t dh_page_size; |> |> /* the size of all physical memory */ |> uint64_t dh_memory_size; |> |> /* the start of physical memory */ |> uint64_t dh_memory_start; |> |> /* the end of physical memory */ |> uint64_t dh_memory_end; |> |> /* the esp for i386 systems -- MOVE LATER */ |> uint32_t dh_esp; |> |> /* the eip for i386 systems -- MOVE LATER */ |> uint32_t dh_eip; |> |> /* the program counter for Alpha systems -- ADDED */ |> uint64_t dh_pc; |> |> /* the stack pointer for Alpha systems -- ADDED */ |> uint64_t dh_ps; |> |> /* the number of pages in this dump specifically */ |> uint32_t dh_num_pages; |> |> /* the panic string, if available */ |> char dh_panic_string[DUMP_PANIC_LEN]; |> |> /* the time of the system crash */ |> struct timeval dh_time; |> |> /* the utsname (uname) information */ |> struct new_utsname dh_utsname; |> |> /* the dump registers */ |> struct pt_regs dh_regs; |> |> /* the address of the current task */ |> struct task_struct *dh_current_task; |> |>} dump_header_t; |> |> |>On 22-Dec-1999 Matt Robinson wrote: |>> On Fri, 24 Dec 1999, Brian Hall wrote: |>>|>That fixed the vmdump.h problem. Now it actually compiles, with warnings |>>|>(implied casts). I notice that dh_esp and dh_eip are 32 bits wide; they will |>>|>need to be 64 bit for Alpha; and the other uint32_t(s) in vmdump.c |>>|>(__dump_execute) will also need to be uint64_t(s), and the changes |>>|>propagated, correct? |>>|> |>>|>Now, should I go ahead and change dump_header_t to (choose one): |>>|>1) make dh_esp,etc uint64_t(s) in the header; |>> |>> I'd make them whatever the dh_esp and dh_eip equivalents are in the |>> pt_regs structure for SP and PC. |>> |>>|>2) add fields specifically for alpha; |>>|>3) do #1 and change them to dh_sp and dh_pc while I'm at it? |>> |>> Do the name change while you're at it. I'll change things in our patch. |> |>-- |>Brian Hall |>http://www.bigfoot.com/~brihall |>Linux Consultant |> From owner-lkcd@oss.sgi.com Mon Jan 3 15:42:45 2000 Received: by oss.sgi.com id ; Mon, 3 Jan 2000 15:42:35 -0800 Received: from zmamail01.zma.compaq.com ([161.114.64.101]:56849 "HELO zmamail01.zma.compaq.com") by oss.sgi.com with SMTP id ; Mon, 3 Jan 2000 15:42:19 -0800 Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 78DC8232; Mon, 3 Jan 2000 18:42:50 -0500 (EST) Received: from cxo3ns.cxo.dec.com (cxo3ns.cxo.dec.com [16.63.0.10]) by zmamail01.zma.compaq.com (Postfix) with SMTP id 85434384; Mon, 3 Jan 2000 18:42:49 -0500 (EST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA22862; Mon, 3 Jan 2000 16:42:48 -0700 Received: from dhcp128-112.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA19997; Mon, 3 Jan 2000 16:42:48 -0700 Received: by compaq.com (sSMTP sendmail emulation); Mon, 3 Jan 2000 16:42:21 -0700 Content-Length: 5870 Message-Id: X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: Date: Mon, 03 Jan 2000 16:42:20 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: Matt Robinson Subject: Re: dump_header changes for Alpha Cc: lkcd@oss.sgi.com Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Sounds good. I think it might be convienent to have a pointer in the specific header to point back to the generic header, and vice versa. Also, maybe an #ifdeffed typedef in the arch-specific header to define the commonly-used register size, i.e. uint32_t for Intel, uint64_t for Alpha, but the code could just use the "standard" arch specific typesize, I dunno, "reg_size_t" or maybe "word_size_t" (this may already be defined somewhere?). We could also define some "standard" arch specific info (naming convention!), like dh_pc and dh_sp for the PC & SP. On 03-Jan-2000 Matt Robinson wrote: > Well, what _really_ needs to happen, and I'll do this for 1.0.4, > is to do the following (and I intended to do this from the beginning, > but we were desperate to get something out the door): > > +-----------------------------------+ > | generic dump header | > +-----------------------------------+ > | architecture specific dump header | > +-----------------------------------+ > | | > | rest of dump | > | | > +-----------------------------------+ > > That way, we can differentiate the generic from the processor > specific stuff. So what we do is stuff the dump header into the > top of the dump_page_buf, then write the architecture specific > header right after it. > > Then you can have whatever you want in there, and it doesn't > matter as far as other architectures are concerned. > > We can also add an dh_arch_type flag to the base dump header > so you know what architecture the dump is for. > > Your thoughts? If you agree, I'll do this and have it out by > the end of this week. > > --Matt > > On Mon, 3 Jan 2000, Brian Hall wrote: >|>Since Intel & Alpha will be sharing the dump_header_t strucure, I thought >|>there >|>might be a problem with using 64 bit values on the Intel side, so I just >|>added >|>fields for Alpha matching Alpha's dh_regs. If this isn't a problem, I can >|>just >|>remove dh_esp and dh_eip from this structure. However, then the naming >|>convention will match Alpha's dh_regs and not Intel's... >|> >|>Is there a reason we couldn't just store the pc & sp for either >|>platform into the appropriate slot in pt_regs here? >|> >|>IOW, remove dh_esp, dh_eip, dh_pc, dh_ps, and pick the variable name based >|>on >|>the platform, i.e. in arch-alpha/vmdump.c: >|> >|>pt_regs->ps = sptr; >|>pt_regs->pc = &&dump_here; >|> >|>Of course the code called after __dump_execute would need to refer to the >|>registers this way also. Or will this not work because pt_regs gets >|>overwritten? >|> >|> >|> >|>OK, here is my proposed change to dump_header_t.: >|> >|> >|>typedef struct _dump_header_s { >|> /* the dump magic number -- unique to verify dump is valid */ >|> uint64_t dh_magic_number; >|> >|> /* the version number of this dump */ >|> uint32_t dh_version; >|> >|> /* the size of this header (in case we can't read it) */ >|> uint32_t dh_header_size; >|> >|> /* the level of this dump (just a header?) */ >|> uint32_t dh_dump_level; >|> >|> /* the size of a Linux memory page (4K, 8K, 16K, etc.) */ >|> uint32_t dh_page_size; >|> >|> /* the size of all physical memory */ >|> uint64_t dh_memory_size; >|> >|> /* the start of physical memory */ >|> uint64_t dh_memory_start; >|> >|> /* the end of physical memory */ >|> uint64_t dh_memory_end; >|> >|> /* the esp for i386 systems -- MOVE LATER */ >|> uint32_t dh_esp; >|> >|> /* the eip for i386 systems -- MOVE LATER */ >|> uint32_t dh_eip; >|> >|> /* the program counter for Alpha systems -- ADDED */ >|> uint64_t dh_pc; >|> >|> /* the stack pointer for Alpha systems -- ADDED */ >|> uint64_t dh_ps; >|> >|> /* the number of pages in this dump specifically */ >|> uint32_t dh_num_pages; >|> >|> /* the panic string, if available */ >|> char dh_panic_string[DUMP_PANIC_LEN]; >|> >|> /* the time of the system crash */ >|> struct timeval dh_time; >|> >|> /* the utsname (uname) information */ >|> struct new_utsname dh_utsname; >|> >|> /* the dump registers */ >|> struct pt_regs dh_regs; >|> >|> /* the address of the current task */ >|> struct task_struct *dh_current_task; >|> >|>} dump_header_t; >|> >|> >|>On 22-Dec-1999 Matt Robinson wrote: >|>> On Fri, 24 Dec 1999, Brian Hall wrote: >|>>|>That fixed the vmdump.h problem. Now it actually compiles, with warnings >|>>|>(implied casts). I notice that dh_esp and dh_eip are 32 bits wide; they >|>>|>will >|>>|>need to be 64 bit for Alpha; and the other uint32_t(s) in vmdump.c >|>>|>(__dump_execute) will also need to be uint64_t(s), and the changes >|>>|>propagated, correct? >|>>|> >|>>|>Now, should I go ahead and change dump_header_t to (choose one): >|>>|>1) make dh_esp,etc uint64_t(s) in the header; >|>> >|>> I'd make them whatever the dh_esp and dh_eip equivalents are in the >|>> pt_regs structure for SP and PC. >|>> >|>>|>2) add fields specifically for alpha; >|>>|>3) do #1 and change them to dh_sp and dh_pc while I'm at it? >|>> >|>> Do the name change while you're at it. I'll change things in our patch. >|> >|>-- >|>Brian Hall >|>http://www.bigfoot.com/~brihall >|>Linux Consultant >|> -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Mon Jan 3 15:48:25 2000 Received: by oss.sgi.com id ; Mon, 3 Jan 2000 15:48:16 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:42822 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 3 Jan 2000 15:48:13 -0800 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [150.166.9.10]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA01160 for ; Mon, 3 Jan 2000 15:44:29 -0800 (PST) mail_from (yakker@engr.sgi.com) Received: from bubula.csd.sgi.com (bubula.csd.sgi.com [150.166.1.69]) by rock.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA12601; Mon, 3 Jan 2000 15:48:45 -0800 (PST) mail_from (yakker@engr.sgi.com) Received: from localhost by bubula.csd.sgi.com via SMTP (980427.SGI.8.8.8/910605.CSDSGI) id PAA57293; Mon, 3 Jan 2000 15:48:45 -0800 (PST) Date: Mon, 3 Jan 2000 15:48:44 -0800 (PST) From: Matt Robinson X-Sender: yakker@bubula.csd.sgi.com To: Brian Hall cc: Matt Robinson , lkcd@oss.sgi.com Subject: Re: dump_header changes for Alpha In-Reply-To: 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 I'm not sure the best way to accomplish that. If we are using the right uint32_t and uint64_t, then it wouldn't matter in the long run, as the right "size" type would be used. The nice thing about the architecture specific scheme is that anyone can do it however they want. The cmd/lcrash code is also set up to be able to port to different architectures easily enough. As for the pointers to different structures, it shouldn't be needed, since the generic would always be at (off32_t)0, and the architecture specific would always be at dump_header->dh_header_size. I'll work on this (along with our LinuxExpo slides) this week. Are any of you going to be there? We'd be interested in talking to all of the people who want to do development for this product, perhaps we can get a CVS tree set up so we can do co-operative work. Anything to make this product better for enterprise customers. --Matt On Mon, 3 Jan 2000, Brian Hall wrote: |>Sounds good. I think it might be convienent to have a pointer in the specific |>header to point back to the generic header, and vice versa. Also, maybe an |>#ifdeffed typedef in the arch-specific header to define the commonly-used |>register size, i.e. uint32_t for Intel, uint64_t for Alpha, but the code could |>just use the "standard" arch specific typesize, I dunno, "reg_size_t" or maybe |>"word_size_t" (this may already be defined somewhere?). We could also define |>some "standard" arch specific info (naming convention!), like dh_pc and dh_sp |>for the PC & SP. |> |>On 03-Jan-2000 Matt Robinson wrote: |>> Well, what _really_ needs to happen, and I'll do this for 1.0.4, |>> is to do the following (and I intended to do this from the beginning, |>> but we were desperate to get something out the door): |>> |>> +-----------------------------------+ |>> | generic dump header | |>> +-----------------------------------+ |>> | architecture specific dump header | |>> +-----------------------------------+ |>> | | |>> | rest of dump | |>> | | |>> +-----------------------------------+ |>> |>> That way, we can differentiate the generic from the processor |>> specific stuff. So what we do is stuff the dump header into the |>> top of the dump_page_buf, then write the architecture specific |>> header right after it. |>> |>> Then you can have whatever you want in there, and it doesn't |>> matter as far as other architectures are concerned. |>> |>> We can also add an dh_arch_type flag to the base dump header |>> so you know what architecture the dump is for. |>> |>> Your thoughts? If you agree, I'll do this and have it out by |>> the end of this week. |>> |>> --Matt From owner-lkcd@oss.sgi.com Mon Jan 3 15:50:35 2000 Received: by oss.sgi.com id ; Mon, 3 Jan 2000 15:50:26 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:53009 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Mon, 3 Jan 2000 15:50:21 -0800 Received: (qmail 22254 invoked by uid 502); 3 Jan 2000 23:50:48 -0000 Received: (qmail 22237 invoked from network); 3 Jan 2000 23:50:45 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 3 Jan 2000 23:50:45 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Brian Hall cc: Matt Robinson , lkcd@oss.sgi.com Subject: Re: dump_header changes for Alpha In-reply-to: Your message of "Mon, 03 Jan 2000 16:42:20 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jan 2000 10:50:45 +1100 Message-ID: <27490.946943445@ocs3.ocs-net> Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing On Mon, 03 Jan 2000 16:42:20 -0700 (MST), Brian Hall wrote: >Sounds good. I think it might be convienent to have a pointer in the specific >header to point back to the generic header, and vice versa. Also, maybe an >#ifdeffed typedef in the arch-specific header to define the commonly-used >register size, i.e. uint32_t for Intel, uint64_t for Alpha, but the code could >just use the "standard" arch specific typesize, I dunno, "reg_size_t" or maybe >"word_size_t" (this may already be defined somewhere?). If you ever plan to allow cross platform dump analysis then you should use explicit sizes i.e. uint32_t or uint64_t. "reg_size_t" is meaningless if the dump came from a 64 bit machine but you are debugging on a 32 bit machine. From owner-lkcd@oss.sgi.com Tue Jan 4 12:50:10 2000 Received: by oss.sgi.com id ; Tue, 4 Jan 2000 12:50:00 -0800 Received: from mailext04.compaq.com ([207.18.199.42]:12434 "HELO mailext04.compaq.com") by oss.sgi.com with SMTP id ; Tue, 4 Jan 2000 12:49:46 -0800 Received: by mailext04.compaq.com (Postfix, from userid 12345) id 2EAD9104C1C; Tue, 4 Jan 2000 14:50:27 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 2B375FB101 for ; Tue, 4 Jan 2000 14:50:27 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id C0EC14FB01; Tue, 4 Jan 2000 14:50:19 -0600 (CST) Received: from cxo3ns.cxo.dec.com (cxo3ns.cxo.dec.com [16.63.0.10]) by mailint12.im.hou.compaq.com (Postfix) with SMTP id 494B14C901 for ; Tue, 4 Jan 2000 14:50:19 -0600 (CST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA26718; Tue, 4 Jan 2000 13:50:25 -0700 Received: from dhcp128-112.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA27051; Tue, 4 Jan 2000 13:50:25 -0700 Received: by compaq.com (sSMTP sendmail emulation); Tue, 4 Jan 2000 13:49:52 -0700 Content-Length: 536 Message-Id: X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Date: Tue, 04 Jan 2000 13:49:52 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: lkcd@oss.sgi.com Subject: lkcd and 2.2.14 kernel Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing I am starting the process of testing lkcd-1.0.3 against the new 2.2.14 kernel. the first required patch, sgi+straw2.2.13.patch applied almost perfectly with only one reject, which I fixed up manually after looking at the .rej by adding "kiobuf_init();" at line 1277 of /usr/src/linux/init/main.c. The main lkcd patch, lkcd2.2.13-1.0.3.patch, applied cleanly with no rejects. I am still recompiling at the moment but I expect it to work as before. -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Tue Jan 4 14:03:09 2000 Received: by oss.sgi.com id ; Tue, 4 Jan 2000 14:02:59 -0800 Received: from zmamail01.zma.compaq.com ([161.114.64.101]:31240 "HELO zmamail01.zma.compaq.com") by oss.sgi.com with SMTP id ; Tue, 4 Jan 2000 14:02:42 -0800 Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 7082A3CF; Tue, 4 Jan 2000 17:03:18 -0500 (EST) Received: from cxo3ns.cxo.dec.com (cxo3ns.cxo.dec.com [16.63.0.10]) by zmamail01.zma.compaq.com (Postfix) with SMTP id C79DD413 for ; Tue, 4 Jan 2000 17:03:17 -0500 (EST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA28404; Tue, 4 Jan 2000 15:03:16 -0700 Received: from dhcp32-129.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA06117; Tue, 4 Jan 2000 15:03:16 -0700 Received: by compaq.com (sSMTP sendmail emulation); Tue, 4 Jan 2000 15:03:16 -0700 Content-Length: 683 Message-Id: X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: Date: Tue, 04 Jan 2000 15:03:16 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: lkcd@oss.sgi.com Subject: RE: lkcd and 2.2.14 kernel Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing After the modification below, I tested lkcd as per the FAQ. Works perfectly with the 2.2.14 kernel. On 04-Jan-2000 Brian Hall wrote: > I am starting the process of testing lkcd-1.0.3 against the new 2.2.14 kernel. > The first required patch, sgi+straw2.2.13.patch applied almost perfectly with > only one reject, which I fixed up manually after looking at the .rej by > adding "kiobuf_init();" at line 1277 of /usr/src/linux/init/main.c. The main > lkcd patch, lkcd2.2.13-1.0.3.patch, applied cleanly with no rejects. I > am still recompiling at the moment but I expect it to work as before. -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Tue Jan 4 16:41:49 2000 Received: by oss.sgi.com id ; Tue, 4 Jan 2000 16:41:40 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:15679 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 4 Jan 2000 16:41:29 -0800 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [150.166.9.10]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA18336 for ; Tue, 4 Jan 2000 16:37:49 -0800 (PST) mail_from (yakker@engr.sgi.com) Received: from bubula.csd.sgi.com (bubula.csd.sgi.com [150.166.1.69]) by rock.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA73841; Tue, 4 Jan 2000 16:42:10 -0800 (PST) mail_from (yakker@engr.sgi.com) Received: from localhost by bubula.csd.sgi.com via SMTP (980427.SGI.8.8.8/910605.CSDSGI) id QAA83046; Tue, 4 Jan 2000 16:42:10 -0800 (PST) Date: Tue, 4 Jan 2000 16:42:09 -0800 (PST) From: Matt Robinson X-Sender: yakker@bubula.csd.sgi.com Reply-To: Matt Robinson To: Brian Hall cc: lkcd@oss.sgi.com Subject: Re: lkcd and 2.2.14 kernel In-Reply-To: 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 I have to get the 2.2.14 straw patch, re-apply the SGI patch to that, then I'll have a full patch. Either way, it's close enough. My guess is that Stephen got rid of the kiobuf_init() code, but I'd have to make sure that it gets called somewhere else (otherwise, you'll have a problem). He probably moved the call to somewhere else. --Matt On Tue, 4 Jan 2000, Brian Hall wrote: |>I am starting the process of testing lkcd-1.0.3 against the new 2.2.14 kernel. |>the first required patch, sgi+straw2.2.13.patch applied almost perfectly with |>only one reject, which I fixed up manually after looking at the .rej by adding |>"kiobuf_init();" at line 1277 of /usr/src/linux/init/main.c. The main lkcd |>patch, lkcd2.2.13-1.0.3.patch, applied cleanly with no rejects. I am still |>recompiling at the moment but I expect it to work as before. From owner-lkcd@oss.sgi.com Thu Jan 13 16:58:29 2000 Received: by oss.sgi.com id ; Thu, 13 Jan 2000 16:58:19 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:58698 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 13 Jan 2000 16:58:00 -0800 Received: from awesome.engr.sgi.com ([163.154.5.50]) 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 QAA02154 for ; Thu, 13 Jan 2000 16:59:26 -0800 (PST) mail_from (yakker@cthulhu.engr.sgi.com) Received: from localhost (yakker@localhost) by awesome.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id QAA29305 for ; Thu, 13 Jan 2000 16:57:48 -0800 (PST) Date: Thu, 13 Jan 2000 16:57:48 -0800 (PST) From: Matt Robinson To: lkcd@oss.sgi.com Subject: LKCD 1.0.4 Released 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 Just an FYI to those on the group alias, I've put the 1.0.4 source code out for use. It has a few changes -- review the README file in the download directory. You can get the code from: http://oss.sgi.com/projects/lkcd/download/1.0.4/ Let me know if you have any problems with it. I've also updated the News page with what's been going on lately. Thanks! --Matt P.S. Do people want the rc.sysinit changes put into a patch format, or is the current mechanism sufficient? I know that the file isn't as compatible with the RedHat 6.1 rc.sysinit version or the SuSe release ... From owner-lkcd@oss.sgi.com Fri Jan 14 13:13:24 2000 Received: by oss.sgi.com id ; Fri, 14 Jan 2000 13:13:14 -0800 Received: from mailext04.compaq.com ([207.18.199.42]:46309 "HELO mailext04.compaq.com") by oss.sgi.com with SMTP id ; Fri, 14 Jan 2000 13:12:52 -0800 Received: by mailext04.compaq.com (Postfix, from userid 12345) id 27D8B104B9E; Fri, 14 Jan 2000 15:14:19 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 210F0FB101; Fri, 14 Jan 2000 15:14:19 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id A704A4FB01; Fri, 14 Jan 2000 15:14:11 -0600 (CST) Received: from cxo3ns.cxo.dec.com (cxo3ns.cxo.dec.com [16.63.0.10]) by mailint12.im.hou.compaq.com (Postfix) with SMTP id 1488A4C901; Fri, 14 Jan 2000 15:14:11 -0600 (CST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA06081; Fri, 14 Jan 2000 14:14:17 -0700 Received: from dhcp128-150.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA13542; Fri, 14 Jan 2000 14:14:16 -0700 Received: by compaq.com (sSMTP sendmail emulation); Fri, 14 Jan 2000 14:14:12 -0700 Content-Length: 458 Message-Id: X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: Date: Fri, 14 Jan 2000 14:14:12 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: Matt Robinson Subject: RE: LKCD 1.0.4 Released Cc: lkcd@oss.sgi.com Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing The patch format for rc.sysint is probably better, since it is smaller and more adaptable. On 14-Jan-2000 Matt Robinson wrote: > P.S. Do people want the rc.sysinit changes put into a patch format, > or is the current mechanism sufficient? I know that the file > isn't as compatible with the RedHat 6.1 rc.sysinit version or > the SuSe release ... -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Fri Jan 14 13:30:53 2000 Received: by oss.sgi.com id ; Fri, 14 Jan 2000 13:30:44 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:51217 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 14 Jan 2000 13:30:27 -0800 Received: from awesome.engr.sgi.com (awesome.engr.sgi.com [163.154.5.50]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA20849 for ; Fri, 14 Jan 2000 13:27:34 -0800 (PST) mail_from (yakker@cthulhu.engr.sgi.com) Received: from localhost (yakker@localhost) by awesome.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id NAA30144; Fri, 14 Jan 2000 13:30:19 -0800 (PST) Date: Fri, 14 Jan 2000 13:30:19 -0800 (PST) From: Matt Robinson To: Brian Hall cc: Matt Robinson , lkcd@oss.sgi.com Subject: RE: LKCD 1.0.4 Released In-Reply-To: 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 Okee, I'll do that instead. Any problems with the patch? --Matt On Fri, 14 Jan 2000, Brian Hall wrote: |>The patch format for rc.sysint is probably better, since it is smaller and more |>adaptable. |> |>On 14-Jan-2000 Matt Robinson wrote: |>> P.S. Do people want the rc.sysinit changes put into a patch format, |>> or is the current mechanism sufficient? I know that the file |>> isn't as compatible with the RedHat 6.1 rc.sysinit version or |>> the SuSe release ... |> |> |>-- |>Brian Hall |>http://www.bigfoot.com/~brihall |>Linux Consultant |> From owner-lkcd@oss.sgi.com Fri Jan 14 13:47:43 2000 Received: by oss.sgi.com id ; Fri, 14 Jan 2000 13:47:34 -0800 Received: from mailext03.compaq.com ([207.18.199.41]:26109 "HELO mailext03.compaq.com") by oss.sgi.com with SMTP id ; Fri, 14 Jan 2000 13:47:12 -0800 Received: by mailext03.compaq.com (Postfix, from userid 12345) id 3991815214C; Fri, 14 Jan 2000 15:48:43 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 31FDF148507; Fri, 14 Jan 2000 15:48:43 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 8544CBC4D3; Fri, 14 Jan 2000 15:48:35 -0600 (CST) Received: from cxo3ns.cxo.dec.com (cxo3ns.cxo.dec.com [16.63.0.10]) by mailint02.im.hou.compaq.com (Postfix) with SMTP id E4BCCB2A42; Fri, 14 Jan 2000 15:48:34 -0600 (CST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA06082; Fri, 14 Jan 2000 14:48:41 -0700 Received: from dhcp128-150.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA28057; Fri, 14 Jan 2000 14:48:41 -0700 Received: by compaq.com (sSMTP sendmail emulation); Fri, 14 Jan 2000 14:48:36 -0700 Content-Length: 1136 Message-Id: X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: Date: Fri, 14 Jan 2000 14:48:36 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: Matt Robinson Subject: RE: LKCD 1.0.4 Released Cc: lkcd@oss.sgi.com Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing No, it applied cleanly against the i386 branch. I edited the patch for i386/vmdump.c and applied it against my modified Alpha version, which resulted in me having to hand resolve one or two things (no big surprise, and not a problem). Getting close to actually testing the dumping mechanism on Alpha, I think. I hope to try it via the method in the FAQ on Monday or Tuesday next week. If that part works I'll release it to the list (danger! pre-patch!), hopefully someone else here with an Alpha can try it and/or see if it is correct. Then, I'll start working on the lcrash tools. Unless there is some reason to do otherwise, I'll plan on providing the Alpha (testing) version as a patch against lkcd-1.0.4 (i.e. apply the lkcd & sgi+straw patches to the 2.2.13 tree, then the Alpha patch). On 14-Jan-2000 Matt Robinson wrote: > Okee, I'll do that instead. Any problems with the patch? > > --Matt > > On Fri, 14 Jan 2000, Brian Hall wrote: >|>The patch format for rc.sysint is probably better, since it is smaller and >|>more >|>adaptable. -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Mon Jan 17 20:39:49 2000 Received: by oss.sgi.com id ; Mon, 17 Jan 2000 20:39:40 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:48710 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 17 Jan 2000 20:39:16 -0800 Received: from awesome.engr.sgi.com (awesome.engr.sgi.com [163.154.5.50]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA23915 for ; Mon, 17 Jan 2000 20:36:35 -0800 (PST) mail_from (yakker@cthulhu.engr.sgi.com) Received: from localhost (yakker@localhost) by awesome.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id UAA38718; Mon, 17 Jan 2000 20:39:21 -0800 (PST) Date: Mon, 17 Jan 2000 20:39:21 -0800 (PST) From: Matt Robinson Reply-To: Matt Robinson To: Brian Hall cc: Matt Robinson , lkcd@oss.sgi.com Subject: RE: LKCD 1.0.4 Released In-Reply-To: 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 On Fri, 14 Jan 2000, Brian Hall wrote: |>No, it applied cleanly against the i386 branch. I edited the patch for |>i386/vmdump.c and applied it against my modified Alpha version, which resulted |>in me having to hand resolve one or two things (no big surprise, and not a |>problem). |> |>Getting close to actually testing the dumping mechanism on Alpha, I |>think. I hope to try it via the method in the FAQ on Monday or Tuesday next |>week. If that part works I'll release it to the list (danger! pre-patch!), |>hopefully someone else here with an Alpha can try it and/or see if it is |>correct. Then, I'll start working on the lcrash tools. |> |>Unless there is some reason to do otherwise, I'll plan on providing the |>Alpha (testing) version as a patch against lkcd-1.0.4 (i.e. apply the lkcd & |>sgi+straw patches to the 2.2.13 tree, then the Alpha patch). Sounds cool, we can provide the patch either as part of the main patch, or on our web site. Let me know what you'd like to do. Also, I'm a bit closer on the IDE stuff, once I got through to some people about what I was trying to do to the drive. There are other problems, however. I'd like to write out to disk without ever having to hit a lock. This requires writing my own interface for dumping. If I'm going to bother doing this, I might as well write one function with a switch() case based on drive type, so then it won't matter what happens to the file_operations[] and block/char driver changes. Any thoughts? --Matt P.S. I'll try to get to the rc.sysinit stuff next week. |>On 14-Jan-2000 Matt Robinson wrote: |>> Okee, I'll do that instead. Any problems with the patch? |>> |>> --Matt |>> |>> On Fri, 14 Jan 2000, Brian Hall wrote: |>>|>The patch format for rc.sysint is probably better, since it is smaller and |>>|>more |>>|>adaptable. From owner-lkcd@oss.sgi.com Tue Jan 18 07:45:30 2000 Received: by oss.sgi.com id ; Tue, 18 Jan 2000 07:45:11 -0800 Received: from zmamail01.zma.compaq.com ([161.114.64.101]:32774 "HELO zmamail01.zma.compaq.com") by oss.sgi.com with SMTP id ; Tue, 18 Jan 2000 07:44:41 -0800 Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id DA5D5291; Tue, 18 Jan 2000 10:46:24 -0500 (EST) Received: from cxo3ns.cxo.dec.com (cxo3ns.cxo.dec.com [16.63.0.10]) by zmamail01.zma.compaq.com (Postfix) with SMTP id 2C2DB22A; Tue, 18 Jan 2000 10:46:24 -0500 (EST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA16966; Tue, 18 Jan 2000 08:46:23 -0700 Received: from dhcp128-150.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA29057; Tue, 18 Jan 2000 08:46:22 -0700 Received: by compaq.com (sSMTP sendmail emulation); Tue, 18 Jan 2000 08:46:19 -0700 Content-Length: 2270 Message-Id: X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: Date: Tue, 18 Jan 2000 08:46:19 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: Matt Robinson Subject: RE: LKCD 1.0.4 Released Cc: lkcd@oss.sgi.com Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing On 18-Jan-2000 Matt Robinson wrote: > On Fri, 14 Jan 2000, Brian Hall wrote: >|>No, it applied cleanly against the i386 branch. I edited the patch for >|>i386/vmdump.c and applied it against my modified Alpha version, which >|>resulted >|>in me having to hand resolve one or two things (no big surprise, and not a >|>problem). >|> >|>Getting close to actually testing the dumping mechanism on Alpha, I >|>think. I hope to try it via the method in the FAQ on Monday or Tuesday next >|>week. If that part works I'll release it to the list (danger! pre-patch!), >|>hopefully someone else here with an Alpha can try it and/or see if it is >|>correct. Then, I'll start working on the lcrash tools. >|> >|>Unless there is some reason to do otherwise, I'll plan on providing the >|>Alpha (testing) version as a patch against lkcd-1.0.4 (i.e. apply the lkcd & >|>sgi+straw patches to the 2.2.13 tree, then the Alpha patch). > > Sounds cool, we can provide the patch either as part of the main patch, > or on our web site. Let me know what you'd like to do. Well, eventually I'd like it to be part of the main patch. I was just speaking of the initial method of "submitting" my changes. A patch against lkcd1.04 seems like the easiest way to do that. > > Also, I'm a bit closer on the IDE stuff, once I got through to some > people about what I was trying to do to the drive. There are other > problems, however. I'd like to write out to disk without ever having > to hit a lock. This requires writing my own interface for dumping. > If I'm going to bother doing this, I might as well write one function > with a switch() case based on drive type, so then it won't matter > what happens to the file_operations[] and block/char driver changes. Sounds fine. I don't have an Alpha at the moment that uses an IDE drive, so for my initial testing I'm only using SCSI. If you implement IDE dumping and have another release, I will probably not update to that version until after I have v1.04 working completely on Alpha SCSI. > > Any thoughts? > > --Matt > > P.S. I'll try to get to the rc.sysinit stuff next week. OK, no big hurry on that; just seems like the better way to go. -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Thu Jan 20 08:39:48 2000 Received: by oss.sgi.com id ; Thu, 20 Jan 2000 08:39:38 -0800 Received: from mail.missioncriticallinux.com ([63.211.176.148]:52753 "EHLO mail.mclinux.com") by oss.sgi.com with ESMTP id ; Thu, 20 Jan 2000 08:39:20 -0800 Received: from mclinux.com (IDENT:winchell@winchell.mclinux.com [192.168.1.103]) by mail.mclinux.com (8.9.3/8.9.3) with ESMTP id LAA07331; Thu, 20 Jan 2000 11:40:37 -0500 Message-ID: <38873A7C.44D4FF8A@mclinux.com> Date: Thu, 20 Jan 2000 10:40:28 -0600 From: David Winchell Organization: Mission Critical Linux X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-alpha@vger.rutgers.edu CC: linux-kernel@vger.rutgers.edu, David Winchell , lkcd@oss.sgi.com, anderson@mclinux.com Subject: In memory core dump facility available for Alpha 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 An "in memory" kernel core dump facility and analysis tool for alpha systems is available. This facility produces reliable dumps in a variety of circumstances including hung systems (via sysrq key) and faults or panics in thread, interrupt and exception context. The analyzer, which is now layered on gdb, provides a rich set of commands for debugging core files and live systems. For example stack traces for all kernel threads including the ones executing at crash time can be obtained. Exception frames are provided in the stack traces and parameter values will be added in the future. The analyzer is designed to facilitate the addition of custom commands. We are working on the following items: 1. Support for other architectures. A few Intel systems (HP, Compaq laptops) will work with this package, but others (Dell) do not. The issue is whether the BIOS allows a reboot without clearing memory. We are working on this problem. Soon we will port to architectures other than Intel and Alpha. 2. Make this code available for the latest development release. 3. Tie the "crash" srm console command into the core dump code. This will be useful for machines with halt buttons (Compaq boxes) that are hung, even at interrupt level. The code and instructions are available at http://www.missioncriticallinux.com/download. The core dump facility is called "Kernel Core Dump v2.0" and the analysis tool "Core Analysis Suite v2.0." While we are working on in-memory dumps for Intel, the following options exist for Intel today. 1. One can use v1.0 of the Kernel Core Dump (which is disk based) with v2.0 of the analysis tool. This version will produce core dumps when the processor calling panic is at thread level. 2. One can try the v2.0 Kernel Core Dump. Forcing a crash with "sysrq c" will result in a core file for BIOS's that preserve memory. 3. A core dump facility is available from SGI at http://oss.sgi.com/projects/lkcd/download. The analysis tool from Mission Critical Linux can read SGI V1.0 core files. The ability to read V2.0 SGI files is under test. -Dave Winchell -Dave Anderson