From owner-lkcd@oss.sgi.com Tue Feb 1 09:25:17 2000 Received: by oss.sgi.com id ; Tue, 1 Feb 2000 09:25:07 -0800 Received: from zmamail01.zma.compaq.com ([161.114.64.101]:10514 "HELO zmamail01.zma.compaq.com") by oss.sgi.com with SMTP id ; Tue, 1 Feb 2000 09:24:47 -0800 Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 6F8DD42A; Tue, 1 Feb 2000 12:27:41 -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 C45B15C8 for ; Tue, 1 Feb 2000 12:27:40 -0500 (EST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA14484; Tue, 1 Feb 2000 10:27:39 -0700 Received: from dhcp192-48.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA11270; Tue, 1 Feb 2000 10:27:39 -0700 Received: by compaq.com (sSMTP sendmail emulation); Tue, 1 Feb 2000 10:27:32 -0700 Content-Length: 1229 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, 01 Feb 2000 10:27:32 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: lkcd@oss.sgi.com Subject: successful Alpha crash header dump Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing I finally got a successful generation and read of a Linux Alpha crash dump header. This is not the complete crash dump implementation, that will require porting over several other items, including an Alpha disassembler for the code trace. The final "gotcha" was that the code to read and parse the dump header from the swapfile on reboot needed to be adjusted for the Alpha page size, instead of Intel. Below is the output from my test code, automatically generated after initiating a crash dump and reboot. This is not representative of what the final crash dump output will look like. Yes, the date looks odd, but that is what the clock on the AS200 reads. Next will be testing the writing of the rest of the dump pages, and then the porting of the lcrash toolset which will generate a useful footprint, the layout of which will be identical to the Intel version. ========= Dump Header (version 2): Magic number: 0xa8190173618f23ed PAGE_SIZE = 8192 Dump header size: 728 Physical memory: Start: 0x0 End: 0x6000000 Size: 95346688 Number of pages in dump: 0 Time of dump: Thu Feb 1 10:13:06 2052 ========= -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Tue Feb 1 09:42:26 2000 Received: by oss.sgi.com id ; Tue, 1 Feb 2000 09:42:17 -0800 Received: from zmamail01.zma.compaq.com ([161.114.64.101]:26633 "HELO zmamail01.zma.compaq.com") by oss.sgi.com with SMTP id ; Tue, 1 Feb 2000 09:41:57 -0800 Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 2C21469D; Tue, 1 Feb 2000 12:44:52 -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 2E4E3660; Tue, 1 Feb 2000 12:44:51 -0500 (EST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA14524; Tue, 1 Feb 2000 10:44:50 -0700 Received: from dhcp192-48.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA04312; Tue, 1 Feb 2000 10:44:49 -0700 Received: by compaq.com (sSMTP sendmail emulation); Tue, 1 Feb 2000 10:44:42 -0700 Content-Length: 1463 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, 01 Feb 2000 10:44:41 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: lkcd@oss.sgi.com Subject: more cross-platform "crash dump header reader" Cc: Matt Robinson Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing #include #include #define CONFIG_VMDUMP #include #include #include dump_header_t dump_header; int main(int argc, char **argv) { FILE *fp; if (argc != 2) { fprintf(stderr, "Usage: %s \n", argv[0]); return (1); } if ((fp = fopen(argv[1], "r")) == (FILE *)NULL) { perror("fopen"); return (1); } fseek(fp, PAGE_SIZE, SEEK_SET); if (fread((char *)&dump_header, sizeof(dump_header_t), 1, fp) < 0) { perror("fread"); return (1); } fclose(fp); printf("Dump Header (version %d):\n", dump_header.dh_version); printf("Magic number: 0x%llx\n", dump_header.dh_magic_number); printf("PAGE_SIZE = %d\n", dump_header.dh_page_size); printf("Dump header size: %d\n", dump_header.dh_header_size); printf("Physical memory:\n"); printf("\tStart: 0x%x\n", dump_header.dh_memory_start); printf("\t End: 0x%x\n", dump_header.dh_memory_end); printf("\t Size: %d\n", dump_header.dh_memory_size); printf("Number of pages in dump: %d\n", dump_header.dh_num_pages); printf("Time of dump: %s\n", ctime(&(dump_header.dh_time.tv_sec))); return (0); } -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Tue Feb 1 16:20:32 2000 Received: by oss.sgi.com id ; Tue, 1 Feb 2000 16:20:22 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:56142 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Feb 2000 16:20:04 -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 QAA22090 for ; Tue, 1 Feb 2000 16:18:37 -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 QAA72122; Tue, 1 Feb 2000 16:21:30 -0800 (PST) Date: Tue, 1 Feb 2000 16:21:29 -0800 (PST) From: Matt Robinson To: Brian Hall cc: lkcd@oss.sgi.com Subject: Re: successful Alpha crash header dump 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 Tue, 1 Feb 2000, Brian Hall wrote: |>I finally got a successful generation and read of a Linux Alpha crash dump |>header. This is not the complete crash dump implementation, that will require |>porting over several other items, including an Alpha disassembler for the code |>trace. The final "gotcha" was that the code to read and parse the dump header |>from the swapfile on reboot needed to be adjusted for the Alpha page size, |>instead of Intel. Hmmm... didn't it just use dh_page_size, or ... ? I didn't think I had a hard-coded limit. If it is hard-coded somewhere, I'll change it over. |>Below is the output from my test code, automatically generated after |>initiating a crash dump and reboot. This is not representative of what the |>final crash dump output will look like. Yes, the date looks odd, but that is |>what the clock on the AS200 reads. Awesome! Great job, Brian. |>Next will be testing the writing of the rest of the dump pages, and then the |>porting of the lcrash toolset which will generate a useful footprint, the |>layout of which will be identical to the Intel version. Just some hints ... there are only a couple of files to change to get the reading of the dumps to work. The real trick will be the disassembly and stack trace code. Now, most of the disassembler stuff you'll be able to leverage off of the GNU 'gdb' disassembler. The only reason why we didn't use that for 'lcrash' on x86 is because we want to work without frame pointers. For architectures that don't have frame pointers, you're free to use what GNU provides for both stack traces and disassembly. Note that the only key is "how" you read the memory pages from the crash dump (which is automatic with the compression library) and how you implement stack traces on the memory pages. Shouldn't be too difficult -- let GNU do the work for you. Great job, Brian! --Matt P.S. I'm going to make one more change to __dump_execute(), to not write out the dump header as often as we do ... I changed it from writing it out at the beginning and the end, to writing it out all the time. I need to find the happy medium ... It won't change the dh_version, however. |>========= |> |>Dump Header (version 2): |>Magic number: 0xa8190173618f23ed |>PAGE_SIZE = 8192 |>Dump header size: 728 |>Physical memory: |> Start: 0x0 |> End: 0x6000000 |> Size: 95346688 |>Number of pages in dump: 0 |>Time of dump: Thu Feb 1 10:13:06 2052 |> |> |>========= |> |>-- |>Brian Hall |>http://www.bigfoot.com/~brihall |>Linux Consultant From owner-lkcd@oss.sgi.com Thu Feb 3 14:05:51 2000 Received: by oss.sgi.com id ; Thu, 3 Feb 2000 14:05:42 -0800 Received: from mail.missioncriticallinux.com ([63.211.176.148]:57351 "EHLO mail.mclinux.com") by oss.sgi.com with ESMTP id ; Thu, 3 Feb 2000 14:05:16 -0800 Received: from mclinux.com (IDENT:anderson@anderson.mclinux.com [192.168.1.104]) by mail.mclinux.com (8.9.3/8.9.3) with ESMTP id IAA17887; Wed, 2 Feb 2000 08:59:24 -0500 Message-ID: <389837CF.74C5CD9C@mclinux.com> Date: Wed, 02 Feb 2000 08:57:35 -0500 From: Dave Anderson Organization: Mission Critical Linux X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15smp2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-alpha@vger.rutgers.edu, linux-kernel@vger.rutgers.edu, lkcd@oss.sgi.com Subject: Core dump facility for 2.3.41 Content-Type: multipart/alternative; boundary="------------52AB000BDEE017FB8ECA627E" Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing --------------52AB000BDEE017FB8ECA627E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The in-memory core dump facility, Kernel Core Dump v2.0, is available for kernel version 2.3.41 for Alpha. An updated Core Analysis Suite is also available. Attached is a sample stack trace for a (forced) memory fault in the tulip interrupt handler on processor 0, and an idle processor 1. These tools may be found at http://www.missioncriticallinux.com/download. Dave Winchell Dave Anderson # crash /var/dumps/lcore.cr.96 /var/dumps/vmlinux.96 crash 2.1 Copyright (C) 1999, 2000 Mission Critical Linux, LLC This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alphaev6-unknown-linux-gnu"... KERNEL: /var/dumps/vmlinux.96 DUMPFILE: /var/dumps/lcore.cr.96 CPUS: 2 DATE: Tue Feb 1 04:57:25 2000 UPTIME: 00:02:26 LOAD AVERAGE: 0.50, 0.33, 0.12 TASKS: 36 NODENAME: lab2.mclinux.com RELEASE: 2.3.41 VERSION: #13 SMP Tue Feb 1 04:50:24 EST 2000 MACHINE: alpha (500 MHz) MEMORY: 512 MB PANIC: "die_if_kernel" PID: 0 COMMAND: "swapper" TASK: fffffc00004d0000 (1 of 2) CPU: 0 STATE: TASK_RUNNING (PANIC) crash> bt -a PID: 0 TASK: fffffc00004d0000 CPU: 0 COMMAND: "swapper" #0 [fffffc00004d3be8] crash_save_current_state at fffffc0000333a9c #1 [fffffc00004d3bf8] panic at fffffc0000324718 #2 [fffffc00004d3c98] die_if_kernel at fffffc00003113d0 #3 [fffffc00004d3cc8] do_page_fault at fffffc000031d550 #4 [fffffc00004d3d08] entMM at fffffc000031055c EFRAME: fffffc00004d3d40 R24: fffffc000050dc00 R0: 0000000000000000 R25: 000000000000006e R1: 0000000000000001 R26: fffffc0000316c54 R2: 0000000000000002 R27: fffffc0000442a00 R3: 0000000000000002 R28: 0000000000000001 R4: 000000000000002b HAE: 0000000000000000 R5: 0000000000000000 TRAP_A0: 0000000000000000 R6: 0000000000000001 TRAP_A1: 0000000000000001 R7: fffffc00005e8a00 TRAP_A2: 0000000000000001 R8: fffffc00004d0000 PS: 0000000000000004 R19: fffffc000050dad8 PC: fffffc0000442a70 R20: fffffc000050dc00 GP: fffffc000053b1a0 R21: 7fffffffffffffff R16: 000000000000002b R22: 0000000000000004 R17: fffffc0001495000 R23: fffffffffffffc18 R18: fffffc00004d3ee8 #5 [fffffc00004d3e28] tulip_interrupt at fffffc0000442a70 #6 [fffffc00004d3e88] handle_irq at fffffc0000316c54 #7 [fffffc00004d3ec8] dp264_srm_device_interrupt at fffffc000031b1d8 #8 [fffffc00004d3ed8] do_entInt at fffffc0000316f58 EFRAME: fffffc00004d3ee8 R24: fffffc000050dc00 R0: 0000000000000000 R25: 000000000000006e R1: 0000000000000000 R26: fffffc0000312120 R2: 0000000000000001 R27: fffffc000031c780 R3: 0000000000000000 R28: 0000000000000001 R4: fffffc00005e8a20 HAE: 0000000000000000 R5: fffffc001dcee9a0 TRAP_A0: 0000000000000003 R6: 0000000000000000 TRAP_A1: 0000000000000bb0 R7: fffffc000050dc00 TRAP_A2: 0000000000000001 R8: fffffc00004d0000 PS: 0000000000000000 R19: fffffc000050dad8 PC: fffffc0000312100 R20: fffffc000050dc00 GP: fffffc000053b1a0 R21: 7fffffffffffffff R16: 0000000000000019 R22: 0000000000000004 R17: 0000000000000032 R23: fffffffffffffc18 R18: 00000000000001d9 #9 [fffffc00004d3fd0] cpu_idle at fffffc0000312100 #10 [fffffc00004d3fe0] start_kernel at fffffc000049497c PID: 0 TASK: fffffc000149c000 CPU: 1 COMMAND: "swapper" #0 [fffffc000149fc70] crash_save_current_state at fffffc0000333a9c #1 [fffffc000149fc80] handle_ipi at fffffc000031b9a0 #2 [fffffc000149fcb0] do_entInt at fffffc0000316f04 EFRAME: fffffc000149fcc0 R24: 0000000000000000 R0: 0000000000000000 R25: 0000000000000001 R1: 0000000000000000 R26: fffffc0000312120 R2: 0000000000000001 R27: fffffc000031c780 R3: 0000000000000001 R28: fffffc0000367f3c R4: fffffc00005e8a20 HAE: 0000000000000000 R5: fffffc00004cc020 TRAP_A0: 0000000000000000 R6: 0000000000000000 TRAP_A1: 0000000000000001 R7: fffffc000050dc00 TRAP_A2: 0000000000000000 R8: fffffc000149c000 PS: 0000000000000000 R19: fffffc000050dad8 PC: fffffc0000312100 R20: fffffc000050dc00 GP: fffffc000053b1a0 R21: 0000000000000001 R16: 0000000000000019 R22: 7fffffffffffffff R17: 0000000000000032 R23: fffffffffffffc18 R18: 00000000000001d9 #3 [fffffc000149fda8] cpu_idle at fffffc0000312100 #4 [fffffc000149fdb8] smp_callin at fffffc0000497820 crash> --------------52AB000BDEE017FB8ECA627E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The in-memory core dump facility, Kernel Core Dump v2.0, is available for
kernel version 2.3.41 for Alpha.  An updated Core Analysis Suite is also available.
Attached is a sample stack trace for a (forced) memory fault in the tulip interrupt
handler on processor 0, and an idle processor 1.  These tools may be found at
http://www.missioncriticallinux.com/download.

Dave Winchell
Dave Anderson
 
 

# crash /var/dumps/lcore.cr.96  /var/dumps/vmlinux.96

crash 2.1
Copyright (C) 1999, 2000  Mission Critical Linux, LLC
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
 
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "alphaev6-unknown-linux-gnu"...

      KERNEL: /var/dumps/vmlinux.96
    DUMPFILE: /var/dumps/lcore.cr.96
        CPUS: 2
        DATE: Tue Feb  1 04:57:25 2000
      UPTIME: 00:02:26
LOAD AVERAGE: 0.50, 0.33, 0.12
       TASKS: 36
    NODENAME: lab2.mclinux.com
     RELEASE: 2.3.41
     VERSION: #13 SMP Tue Feb 1 04:50:24 EST 2000
     MACHINE: alpha  (500 MHz)
      MEMORY: 512 MB
       PANIC: "die_if_kernel"
         PID: 0
     COMMAND: "swapper"
        TASK: fffffc00004d0000  (1 of 2)
         CPU: 0
       STATE: TASK_RUNNING (PANIC)

crash> bt -a
PID: 0  TASK: fffffc00004d0000  CPU: 0  COMMAND: "swapper"
 #0 [fffffc00004d3be8] crash_save_current_state at fffffc0000333a9c
 #1 [fffffc00004d3bf8] panic at fffffc0000324718
 #2 [fffffc00004d3c98] die_if_kernel at fffffc00003113d0
 #3 [fffffc00004d3cc8] do_page_fault at fffffc000031d550
 #4 [fffffc00004d3d08] entMM at fffffc000031055c
 EFRAME: fffffc00004d3d40      R24: fffffc000050dc00
     R0: 0000000000000000      R25: 000000000000006e
     R1: 0000000000000001      R26: fffffc0000316c54  <handle_irq+0x174>
     R2: 0000000000000002      R27: fffffc0000442a00
     R3: 0000000000000002      R28: 0000000000000001
     R4: 000000000000002b      HAE: 0000000000000000
     R5: 0000000000000000  TRAP_A0: 0000000000000000
     R6: 0000000000000001  TRAP_A1: 0000000000000001
     R7: fffffc00005e8a00  TRAP_A2: 0000000000000001
     R8: fffffc00004d0000       PS: 0000000000000004
    R19: fffffc000050dad8       PC: fffffc0000442a70  <tulip_interrupt+0x70>
    R20: fffffc000050dc00       GP: fffffc000053b1a0
    R21: 7fffffffffffffff      R16: 000000000000002b
    R22: 0000000000000004      R17: fffffc0001495000
    R23: fffffffffffffc18      R18: fffffc00004d3ee8
 #5 [fffffc00004d3e28] tulip_interrupt at fffffc0000442a70
 #6 [fffffc00004d3e88] handle_irq at fffffc0000316c54
 #7 [fffffc00004d3ec8] dp264_srm_device_interrupt at fffffc000031b1d8
 #8 [fffffc00004d3ed8] do_entInt at fffffc0000316f58
 EFRAME: fffffc00004d3ee8      R24: fffffc000050dc00
     R0: 0000000000000000      R25: 000000000000006e
     R1: 0000000000000000      R26: fffffc0000312120  <cpu_idle+0x40>
     R2: 0000000000000001      R27: fffffc000031c780
     R3: 0000000000000000      R28: 0000000000000001
     R4: fffffc00005e8a20      HAE: 0000000000000000
     R5: fffffc001dcee9a0  TRAP_A0: 0000000000000003
     R6: 0000000000000000  TRAP_A1: 0000000000000bb0
     R7: fffffc000050dc00  TRAP_A2: 0000000000000001
     R8: fffffc00004d0000       PS: 0000000000000000
    R19: fffffc000050dad8       PC: fffffc0000312100  <cpu_idle+0x20>
    R20: fffffc000050dc00       GP: fffffc000053b1a0
    R21: 7fffffffffffffff      R16: 0000000000000019
    R22: 0000000000000004      R17: 0000000000000032
    R23: fffffffffffffc18      R18: 00000000000001d9
 #9 [fffffc00004d3fd0] cpu_idle at fffffc0000312100
#10 [fffffc00004d3fe0] start_kernel at fffffc000049497c

PID: 0  TASK: fffffc000149c000  CPU: 1  COMMAND: "swapper"
 #0 [fffffc000149fc70] crash_save_current_state at fffffc0000333a9c
 #1 [fffffc000149fc80] handle_ipi at fffffc000031b9a0
 #2 [fffffc000149fcb0] do_entInt at fffffc0000316f04
 EFRAME: fffffc000149fcc0      R24: 0000000000000000
     R0: 0000000000000000      R25: 0000000000000001
     R1: 0000000000000000      R26: fffffc0000312120  <cpu_idle+0x40>
     R2: 0000000000000001      R27: fffffc000031c780
     R3: 0000000000000001      R28: fffffc0000367f3c
     R4: fffffc00005e8a20      HAE: 0000000000000000
     R5: fffffc00004cc020  TRAP_A0: 0000000000000000
     R6: 0000000000000000  TRAP_A1: 0000000000000001
     R7: fffffc000050dc00  TRAP_A2: 0000000000000000
     R8: fffffc000149c000       PS: 0000000000000000
    R19: fffffc000050dad8       PC: fffffc0000312100  <cpu_idle+0x20>
    R20: fffffc000050dc00       GP: fffffc000053b1a0
    R21: 0000000000000001      R16: 0000000000000019
    R22: 7fffffffffffffff      R17: 0000000000000032
    R23: fffffffffffffc18      R18: 00000000000001d9
 #3 [fffffc000149fda8] cpu_idle at fffffc0000312100
 #4 [fffffc000149fdb8] smp_callin at fffffc0000497820
crash>
 
 
  --------------52AB000BDEE017FB8ECA627E-- From owner-lkcd@oss.sgi.com Thu Feb 10 15:41:17 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 15:41:07 -0800 Received: from zmamail01.zma.compaq.com ([161.114.64.101]:3601 "HELO zmamail01.zma.compaq.com") by oss.sgi.com with SMTP id ; Thu, 10 Feb 2000 15:40:56 -0800 Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id C96CC5A8; Thu, 10 Feb 2000 15:12:04 -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 0342646E; Thu, 10 Feb 2000 15:12:03 -0500 (EST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA01096; Thu, 10 Feb 2000 13:12:03 -0700 Received: from dhcp63-244-196.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA17345; Thu, 10 Feb 2000 13:11:57 -0700 Received: by compaq.com (sSMTP sendmail emulation); Thu, 10 Feb 2000 13:11:56 -0700 Content-Length: 937 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: Thu, 10 Feb 2000 13:11:56 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: Matt Robinson , lkcd@oss.sgi.com Subject: Alpha arch crash dump status Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing OK, I can now dump header and pages to the swapfile. DUMP_LEVEL = 0,1,2,3,4 and compression are tested and "working" (defined as not crashing or causing an oops; at least the header is verified correct; and something is being written out to the swap device besides just the header). I see a note in __dump_compress that it needs fixing for >32bit systems, what needs to be done there ? I don't see an obvious need to change the return value type, it'll be much less than needs a 64 bit field, and the rest of the fxn is only relative to the current page being compressed. There is a similar note about fixing for >32bit systems in __dump_execute, but I think I covered that by switching to 64 bit variables. P.S. My testing has gone a lot faster since I started using the SysRq keys to sync and remount the disk R/O to avoid the fsck on reboot! -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Thu Feb 10 20:21:29 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 20:21:19 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:51223 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 20:20:54 -0800 Received: from awesome.engr.sgi.com (awesome.engr.sgi.com [163.154.5.50]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA08131 for ; Thu, 10 Feb 2000 20:23:41 -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 UAA90357; Thu, 10 Feb 2000 20:19:09 -0800 (PST) Date: Thu, 10 Feb 2000 20:19:08 -0800 (PST) From: Matt Robinson To: Brian Hall cc: Matt Robinson , lkcd@oss.sgi.com Subject: Re: Alpha arch crash dump status 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 made the code pretty much 64-bit safe ... if the comment is there, it's probably because I haven't tested it. :) --Matt P.S. I'll be back in the office on Monday, and I can start integrating your code into the patch ASAP. On Thu, 10 Feb 2000, Brian Hall wrote: |>OK, I can now dump header and pages to the swapfile. DUMP_LEVEL = 0,1,2,3,4 |>and compression are tested and "working" (defined as not crashing or causing an |>oops; at least the header is verified correct; and something is being written |>out to the swap device besides just the header). |> |>I see a note in __dump_compress that it needs fixing for >32bit systems, what |>needs to be done there ? I don't see an obvious need to change the return value |>type, it'll be much less than needs a 64 bit field, and the rest of the fxn is |>only relative to the current page being compressed. There is a similar note |>about fixing for >32bit systems in __dump_execute, but I think I covered that by |>switching to 64 bit variables. |> |> |>P.S. My testing has gone a lot faster since I started using the SysRq keys to |>sync and remount the disk R/O to avoid the fsck on reboot! |> |>-- |>Brian Hall |>http://www.bigfoot.com/~brihall |>Linux Consultant |> From owner-lkcd@oss.sgi.com Thu Feb 10 21:16:58 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 21:16:39 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:2070 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 21:16:12 -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 VAA09594 for ; Thu, 10 Feb 2000 21:16:08 -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 VAA90942; Thu, 10 Feb 2000 21:14:32 -0800 (PST) Date: Thu, 10 Feb 2000 21:14:32 -0800 (PST) From: Matt Robinson To: Matt Robinson cc: lkcd@oss.sgi.com, Laura Crawford Subject: Re: Linux Crash Dumps for external use 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 Okay, I haven't created the links yet, but the paper and slides are up on the web site, at: http://oss.sgi.com/projects/lkcd/download/doc/linuxworld2000/ I'll put up a link when I get back from vacation. Thanks! :) --Matt On Thu, 10 Feb 2000, Matt Robinson wrote: |>Hi, Laura. I haven't uploaded them yet, as I'm still not back |>in the office. They'll be up on Monday. Sorry for the delay! |> |>--Matt |> |>On Thu, 10 Feb 2000, Laura Crawford wrote: |>|>Hi Matt, |>|> |>|>How's the white paper /slides coming along? I checked the site and don't |>|>see a reference. |>|> |>|>Thanks. |>|> |>|> |>|>-- |>|>Laura Crawford |>|>Crimson Consulting |>|>e-commerce and internet marketing |>|> |>|>408.356.4202 phone & fax |>|>laura.crawford@mindspring.com |>|> |>|> |>|>---------- |>|>>From: Matt Robinson |>|>>To: Laura Crawford |>|>>Subject: Re: Linux Crash Dumps for external use |>|>>Date: Sun, Jan 30, 2000, 10:08 PM |>|>> |>|> |>|>>On Fri, 28 Jan 2000, Laura Crawford wrote: |>|>>|>Hi Matt, |>|>>|> |>|>>|>Got your name from Nancy Bigham. She mentioned you may be working on or |>|>>|>have completed a white paper on Linux Crash Dumps. |>|>>|> |>|>>|>I am a contractor working with Lynn Crilley who runs the Developer Group and |>|>>|>we are creating a new developer home page launching on Monday 1/31 that is |>|>>|>basically a site map that leads developers to technical information they |>|>>|>need/want. |>|>>|> |>|>>|>Am I barking up the right tree? Are you/have you written a white paper or |>|>>|>any code that can be placed in the toolbox for exteranal use? Is this tool |>|>>|>due to be shipped with future distributions? |>|>>|> |>|>>|>Basically my charter is to seek deliverables and news for developers to post |>|>>|>on our site. If not now, when? Can you give me the status? |>|>> |>|>>Most of the stuff is already on our open source web site. Check out: |>|>> |>|>> http://oss.sgi.com/projects/lkcd/ |>|>> |>|>>We're in SGI Linux 1.1, SGI Linux 1.2, and we have a patch for 2.2.13 |>|>>kernels. |>|>> |>|>>We'll be releasing our white paper this week to the web site, including |>|>>our LinuxWorld slides. The intention is to put both out at the same |>|>>time. If you have questions about the product, please review the web |>|>>site first, _including_ the FAQ, and let me know if I can help fill in |>|>>any gaps for you. Thanks! :) |>|>> |>|>>--Matt |>|>> |>|>>|>Thanks, |>|>>|> |>|>>|>Laura |>|>>|> |>|>>|>-- |>|>>|>Laura Crawford |>|>>|>Crimson Consulting |>|>>|>e-commerce and internet marketing |>|>>|> |>|>>|>408.356.4202 phone & fax |>|>>|>laura.crawford@mindspring.com |>|>> |>|>> |>|> |> From owner-lkcd@oss.sgi.com Tue Feb 15 09:29:02 2000 Received: by oss.sgi.com id ; Tue, 15 Feb 2000 09:28:42 -0800 Received: from mailext12.compaq.com ([207.18.199.188]:62954 "HELO mailext12.compaq.com") by oss.sgi.com with SMTP id ; Tue, 15 Feb 2000 09:28:27 -0800 Received: by mailext12.compaq.com (Postfix, from userid 12345) id 5925757864; Tue, 15 Feb 2000 11:28:26 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 480E054602 for ; Tue, 15 Feb 2000 11:28:26 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 1D8074FB03; Tue, 15 Feb 2000 11:28: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 A63874C901 for ; Tue, 15 Feb 2000 11:28:18 -0600 (CST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA20358; Tue, 15 Feb 2000 10:28:25 -0700 Received: from dhcp63-244-196.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA00921; Tue, 15 Feb 2000 10:28:24 -0700 Received: by compaq.com (sSMTP sendmail emulation); Tue, 15 Feb 2000 10:27:45 -0700 Content-Length: 1634 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, 15 Feb 2000 10:27:44 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: lkcd@oss.sgi.com Subject: Alpha lcrash compile problems Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Working on porting lcrash over to Alpha, I've hit a roadblock. To get started, I simply copied all lcrash/*/arch/i386 over to lcrash/*/arch/alpha, knowing that it would require modification. Problem is, I can't get anywhere trying to build it for Alpha. Since there is no fixmap.h for Alpha, I removed the reference to that include. Now I get a include problem I have not been able to resolve. I've tried building the whole kernel, and the problem also occurs with almost the exact same errors just building lib/libklib. (cd include ; /bin/ln -s asm-alpha asm; cd ..) cc -gstabs -D__KERNEL__ -I/usr/src/linux/include -I. -Iinclude -c -o klib.o klib.c In file included from /usr/src/linux/include/asm/semaphore.h:11, from /usr/src/linux/include/linux/fs.h:164, from /usr/src/linux/include/linux/capability.h:13, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:8, from /usr/src/linux/include/linux/mm.h:4, from include/asm/kl_kernel.h:10, from include/klib.h:12, from klib.c:4: /usr/src/linux/include/asm/current.h:4: global register variable follows a function definition /usr/src/linux/include/asm/current.h:4: warning: call-clobbered register used for global register variable This makes it look like the problem is in current.h, but it can't be; current.h is happy with the rest of the Alpha tree. How do I resolve this apparent conflict with the lcrash source? -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant From owner-lkcd@oss.sgi.com Tue Feb 15 09:45:32 2000 Received: by oss.sgi.com id ; Tue, 15 Feb 2000 09:45:12 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:7965 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Feb 2000 09:44:45 -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 JAA03910 for ; Tue, 15 Feb 2000 09:40:14 -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 JAA98644; Tue, 15 Feb 2000 09:43:10 -0800 (PST) Date: Tue, 15 Feb 2000 09:43:09 -0800 (PST) From: Matt Robinson To: Brian Hall cc: lkcd@oss.sgi.com Subject: Re: Alpha lcrash compile problems 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 The cmd/lcrash/lib/libklib/include/asm/kl_kernel.h should really be based on cmd/lcrash/lib/libklib/include/asm-alpha/kl_kernel.h. You may need to make modifications to those files in order to get it to compile correctly. That file has been setup to deal with header file inconsistencies. For example, in your case, it's doing a #include , which eventually does a #include , and from there, it doesn't compile correctly, because the global register variable isn't allowed. Just purely speculating (if I had an Alpha system, I could probably work on it ... do you have a login? :D), you might want to check your $(CFLAGS) and make sure one of the standard flags is being used to compile for alpha platforms ... also, make sure to look at any files that #include in arch/alpha/kernel and see what header files may also be needed (the ones that preclude the #include definition). Finally, remove #include , and find out what happens. My first guess is it is the $(CFLAGS), but without having a system, I can't know for sure. --Matt On Tue, 15 Feb 2000, Brian Hall wrote: |>Working on porting lcrash over to Alpha, I've hit a roadblock. To get started, |>I simply copied all lcrash/*/arch/i386 over to lcrash/*/arch/alpha, knowing that |>it would require modification. Problem is, I can't get anywhere trying to build |>it for Alpha. Since there is no fixmap.h for Alpha, I removed the reference to |>that include. Now I get a include problem I have not been able to resolve. I've |>tried building the whole kernel, and the problem also occurs with almost the |>exact same errors just building lib/libklib. |> |>(cd include ; /bin/ln -s asm-alpha asm; cd ..) |>cc -gstabs -D__KERNEL__ -I/usr/src/linux/include -I. -Iinclude -c -o klib.o |>klib.c |>In file included from /usr/src/linux/include/asm/semaphore.h:11, |> from /usr/src/linux/include/linux/fs.h:164, |> from /usr/src/linux/include/linux/capability.h:13, |> from /usr/src/linux/include/linux/binfmts.h:5, |> from /usr/src/linux/include/linux/sched.h:8, |> from /usr/src/linux/include/linux/mm.h:4, |> from include/asm/kl_kernel.h:10, |> from include/klib.h:12, |> from klib.c:4: |>/usr/src/linux/include/asm/current.h:4: global register variable follows a |>function definition |>/usr/src/linux/include/asm/current.h:4: warning: call-clobbered register used |>for global register variable |> |>This makes it look like the problem is in current.h, but it can't be; current.h |>is happy with the rest of the Alpha tree. How do I resolve this apparent |>conflict with the lcrash source? |> |>-- |>Brian Hall |>http://www.bigfoot.com/~brihall |>Linux Consultant |> From owner-lkcd@oss.sgi.com Tue Feb 15 10:29:52 2000 Received: by oss.sgi.com id ; Tue, 15 Feb 2000 10:29:42 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:13874 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 15 Feb 2000 10:29:25 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA10734 for ; Tue, 15 Feb 2000 10:24:54 -0800 (PST) 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 KAA50728 for ; Tue, 15 Feb 2000 10:29:24 -0800 (PST) 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 KAA11252; Tue, 15 Feb 2000 10:27:58 -0800 (PST) Message-ID: <38A99AAD.734FD150@sgi.com> Date: Tue, 15 Feb 2000 10:27:57 -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: Brian Hall CC: lkcd@oss.sgi.com, tjm@sgi.com Subject: Re: Alpha lcrash compile problems 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 Brian Hall wrote: > > Working on porting lcrash over to Alpha, I've hit a roadblock. To get started, > I simply copied all lcrash/*/arch/i386 over to lcrash/*/arch/alpha, knowing that Brian, The real problem results from including kernel header files in applications source with __KERNEL__ set. I found that there were conflicts between kernel header files and standard header files that I could only resolve by undef'ing certain kernel macros (see lib/libklib/include/asm-i386/kl_kernel.h). It's REALLY ugly, but since all I wanted was the type definitions, it was OK. I wish there was an easy solution. The bottom line is, make whatever changes are necessary to get lcrash to compile -- as long as you have access to the key kernel type definitions, you will be all right. Tom > it would require modification. Problem is, I can't get anywhere trying to build > it for Alpha. Since there is no fixmap.h for Alpha, I removed the reference to > that include. Now I get a include problem I have not been able to resolve. I've > tried building the whole kernel, and the problem also occurs with almost the > exact same errors just building lib/libklib. > > (cd include ; /bin/ln -s asm-alpha asm; cd ..) > cc -gstabs -D__KERNEL__ -I/usr/src/linux/include -I. -Iinclude -c -o klib.o > klib.c > In file included from /usr/src/linux/include/asm/semaphore.h:11, > from /usr/src/linux/include/linux/fs.h:164, > from /usr/src/linux/include/linux/capability.h:13, > from /usr/src/linux/include/linux/binfmts.h:5, > from /usr/src/linux/include/linux/sched.h:8, > from /usr/src/linux/include/linux/mm.h:4, > from include/asm/kl_kernel.h:10, > from include/klib.h:12, > from klib.c:4: > /usr/src/linux/include/asm/current.h:4: global register variable follows a > function definition > /usr/src/linux/include/asm/current.h:4: warning: call-clobbered register used > for global register variable > > This makes it look like the problem is in current.h, but it can't be; current.h > is happy with the rest of the Alpha tree. How do I resolve this apparent > conflict with the lcrash source? > > -- > Brian Hall > http://www.bigfoot.com/~brihall > Linux Consultant From owner-lkcd@oss.sgi.com Tue Feb 15 11:37:54 2000 Received: by oss.sgi.com id ; Tue, 15 Feb 2000 11:37:44 -0800 Received: from mailext12.compaq.com ([207.18.199.188]:52216 "HELO mailext12.compaq.com") by oss.sgi.com with SMTP id ; Tue, 15 Feb 2000 11:37:22 -0800 Received: by mailext12.compaq.com (Postfix, from userid 12345) id 30F3E57807; Tue, 15 Feb 2000 13:37:21 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 224DD54601; Tue, 15 Feb 2000 13:37:21 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id DEBB7BC4C9; Tue, 15 Feb 2000 13:37:13 -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 4E2DCB2A42; Tue, 15 Feb 2000 13:37:13 -0600 (CST) Received: from brownfur.cxo.dec.com by cxo3ns.cxo.dec.com; (5.65v4.0/1.1.8.2/11Apr96-1001AM) id AA20747; Tue, 15 Feb 2000 12:37:19 -0700 Received: from dhcp63-248-72.cxo.dec.com by brownfur.cxo.dec.com (5.65v4.0/1.1.10.5/17Feb98-0753AM) id AA14349; Tue, 15 Feb 2000 12:37:18 -0700 Received: by compaq.com (sSMTP sendmail emulation); Tue, 15 Feb 2000 12:37:18 -0700 Content-Length: 3326 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, 15 Feb 2000 12:37:18 -0700 (MST) Reply-To: Brian Hall From: Brian Hall To: Matt Robinson Subject: Re: Alpha lcrash compile problems Cc: lkcd@oss.sgi.com Sender: owner-lkcd@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;lkcd-outgoing Everything here is blocked by the firewall, so I can't get you a login to the AS200 I've been working on. However, you can get access to an Alpha running Linux at the below URL. I created an account for myself, but I can't telnet to the machine because I'm blocked by the firewall! (I'm inside the firewall) http://www.testdrive.compaq.com/register.shtml On 15-Feb-2000 Matt Robinson wrote: > The cmd/lcrash/lib/libklib/include/asm/kl_kernel.h should really be > based on cmd/lcrash/lib/libklib/include/asm-alpha/kl_kernel.h. You > may need to make modifications to those files in order to get it to > compile correctly. That file has been setup to deal with header file > inconsistencies. > > For example, in your case, it's doing a #include , which > eventually does a #include , and from there, it doesn't > compile correctly, because the global register variable isn't allowed. > > Just purely speculating (if I had an Alpha system, I could probably > work on it ... do you have a login? :D), you might want to check your > $(CFLAGS) and make sure one of the standard flags is being used to > compile for alpha platforms ... also, make sure to look at any files > that #include in arch/alpha/kernel and see what header > files may also be needed (the ones that preclude the #include > definition). Finally, remove #include , and find out what > happens. > > My first guess is it is the $(CFLAGS), but without having a system, I > can't know for sure. > > --Matt > > On Tue, 15 Feb 2000, Brian Hall wrote: >|>Working on porting lcrash over to Alpha, I've hit a roadblock. To get >|>started, >|>I simply copied all lcrash/*/arch/i386 over to lcrash/*/arch/alpha, knowing >|>that >|>it would require modification. Problem is, I can't get anywhere trying to >|>build >|>it for Alpha. Since there is no fixmap.h for Alpha, I removed the reference >|>to >|>that include. Now I get a include problem I have not been able to resolve. >|>I've >|>tried building the whole kernel, and the problem also occurs with almost the >|>exact same errors just building lib/libklib. >|> >|>(cd include ; /bin/ln -s asm-alpha asm; cd ..) >|>cc -gstabs -D__KERNEL__ -I/usr/src/linux/include -I. -Iinclude -c -o >|>klib.o >|>klib.c >|>In file included from /usr/src/linux/include/asm/semaphore.h:11, >|> from /usr/src/linux/include/linux/fs.h:164, >|> from /usr/src/linux/include/linux/capability.h:13, >|> from /usr/src/linux/include/linux/binfmts.h:5, >|> from /usr/src/linux/include/linux/sched.h:8, >|> from /usr/src/linux/include/linux/mm.h:4, >|> from include/asm/kl_kernel.h:10, >|> from include/klib.h:12, >|> from klib.c:4: >|>/usr/src/linux/include/asm/current.h:4: global register variable follows a >|>function definition >|>/usr/src/linux/include/asm/current.h:4: warning: call-clobbered register >|>used >|>for global register variable >|> >|>This makes it look like the problem is in current.h, but it can't be; >|>current.h >|>is happy with the rest of the Alpha tree. How do I resolve this apparent >|>conflict with the lcrash source? -- Brian Hall http://www.bigfoot.com/~brihall Linux Consultant