From aysen@yahoo.com Fri Mar 7 04:23:01 2003 Received: with ECARTIS (v1.0.0; list kdb); Fri, 07 Mar 2003 04:23:05 -0800 (PST) Received: from ommo.net ([212.253.174.22]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h27CMGq9020327 for ; Fri, 7 Mar 2003 04:22:59 -0800 Message-Id: <200303071222.h27CMGq9020327@oss.sgi.com> From: "MARAMARA Erotik Market" Reply-To: aysen@yahoo.com To: kdb@oss.sgi.com Date: Fri, 7 Mar 2003 14:23:42 +0200 Subject: BU FIRSATTAN RARARLANIN. X-Mailer: Microsoft Outlook Express 5.00.2919.7000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h27CMGq9020327 X-archive-position: 266 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: aysen@yahoo.com Precedence: bulk X-list: kdb DIKKAT VIDEO CD : Iddia ediyoruz.. Hic bir yerden temin edemeyeceginiz ses ve göruntu kalitesi ile yuzlerce porno video CD. arSivimiz yenilenmistir. istemis oldugunuz video CD.ler bire bir yollanir kesinlikle isteginiz harici alakasiz baSka video CD.ler yollanmaz. Anal. Oral. Vajinal. Grup. Zenci. FethiS. Ayak fethiS. Gay. Zenci gay. Trans. Transexual. Lezbiyen ve daha bircok ceSit .... ZENGIN URUN CESITLERIMIZ : Sisme Bebekler ..... (Erkek & Bayan) Kesinlikle size hayir demeyecek. Vibratörler ........ Istediginiz boy ve ebatlarda (Vajinal/Anal/catal.Pilli.Motorlu.TitreSimli) Suni Vajinalar ..... Asla gerceginden ayirt edemeyeceksiniz (Gercek ten hassasiyetinde) Reailistik Penisler. Gercek ten hassasiyetinde ve dokusunda (Vantuzlu/Deri kemer kilotlu) Vakum Pompalari .... Ereksiyonu kolaylastirici ve duzenli kullanimlarda peniste irilesme saglar. Geciktiriciler ..... Erken boSalmayi dert etmeyin (Sprey ceSitleri/Kremler) Kremler ............ Anal ve Vajinal iliSkilerde kullanabileceginiz kayganlaStirici krem ceSitleri Uyandiricilar ...... Cinsel istek uyandirici haplar ve damlalar. Yapmaniz gereken tek Sey TIKLAMAK .. NOT : BU MAIL REKLAM AMAcLI OLUP HIcBIR SEKILDE TARAFIMIZDA KAYDINIZ BULUNMAMAKTADIR. ILGI ALANINIZIN DISINDA ISE EGER LUTFEN DIKKATE ALMAYINIZ TESEKKURLER.. From enigma@yahoo.com Mon Mar 10 07:57:15 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 10 Mar 2003 07:57:17 -0800 (PST) Received: from r-ew5pbu5v19xo8 (user-112vc7a.biz.mindspring.com [66.47.176.234]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2AFtxq9027717 for ; Mon, 10 Mar 2003 07:56:53 -0800 Received: from User ([66.47.176.234]) by r-ew5pbu5v19xo8 with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 10:38:08 -0500 From: "Sara Wilson" Subject: Wondering what your spouse and children are doing online? Date: Mon, 10 Mar 2003 10:38:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Bcc: Message-ID: X-OriginalArrivalTime: 10 Mar 2003 15:38:08.0812 (UTC) FILETIME=[0D0156C0:01C2E71B] X-archive-position: 267 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: enigma@yahoo.com Precedence: bulk X-list: kdb Spy on a cheating spouse Monitor a naughty child Keep an eye on rebellious employees Gather information, discover secretes, and find out the truth about your spouse, children, or employees. Message recording (Chat rooms, Instant messengers) Email monitoring keystroke logging (password logging) and much more. Visit our site below for more information: http://www.havocmarketing.com/enigma Spying software that runs completely undetectable!! To unsubscribe: http://www.havocmarketing.com/remove.htm From sonic.zhang@intel.com Wed Mar 12 22:32:01 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 12 Mar 2003 22:32:03 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2D6W0q9017571 for ; Wed, 12 Mar 2003 22:32:01 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2D6RcB22978 for ; Thu, 13 Mar 2003 06:27:38 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2D6S5Q06633 for ; Thu, 13 Mar 2003 06:28:05 GMT Received: from pdsmsx17.pd.intel.com ([172.16.12.121]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003031314314206179 ; Thu, 13 Mar 2003 14:31:42 +0800 Received: by pdsmsx17.pd.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 14:30:17 +0800 Message-ID: <957BD1C2BF3CD411B6C500A0C944CA26033AFF88@pdsmsx32.pd.intel.com> From: "Zhang, Sonic" To: "KeithOwens (E-mail)" Cc: "KDB (E-mail)" Subject: I add a new patch to support hardware debug registers for IA64. Date: Thu, 13 Mar 2003 14:29:23 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2E929.E32EA0D0" X-archive-position: 268 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2E929.E32EA0D0 Content-Type: text/plain; charset="gb2312" Hi, In the latest KDB v3.0 patch, I can't find any way to use a hardware debug register under Itanium platform. Could you please tell me why you don't add that feature for IA64 as what you do for IA32? I investigated the IA64 System Architecture Specification and decided to changed some of the IA64 related code in KDB to support hardware debugging. Now, the patch is finished. Please take a look at the attachment. This patch is based on KDB v3.0 with Linux Kernel 2.4.20. I have tested it on an Itanium machine. Hardware Instruction breakpoint works well, but a little problem related to hardware data breakpoint still exists. The dd(disable data debug fault) bit in PSR(Processor Status Register) is defined to disable the data debug fault on the first IA64 restart instruction after KDB exit from a data debug fault. But it doesn't work, the same hardware data breakpoint is triggered again and again. That means you cann't exit KDB unless this data breakpoint is disabled. Any suggestions? I also plan to enhance this feature to support different hardware breakpoints on different CPUs as I did for IA32. I may submit a full patch for both IA32 and IA64 in the future. Thank you. ************************************* Sonic Zhang Software Engineer Intel China Software Lab Tel: 021-52574545-1667 iNet: 8-752-1667 ************************************* ------_=_NextPart_000_01C2E929.E32EA0D0 Content-Type: application/octet-stream; name="kdb-hdr-v3.0-2.4.20-ia64-1.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="kdb-hdr-v3.0-2.4.20-ia64-1.patch" --- linux-kdb/arch/ia64/kernel/ivt.S Wed Mar 12 14:24:05 2003=0A= +++ linux-kdb-hdr/arch/ia64/kernel/ivt.S Wed Mar 12 13:50:23 2003=0A= @@ -631,6 +631,16 @@=0A= =0A= SAVE_MIN // uses r31; defines r2:=0A= =0A= +#ifdef CONFIG_KDB=0A= + mov r16=3Dpsr=0A= + movl r17=3DIA64_PSR_DB=0A= + ;;=0A= + or r18=3Dr16, r17=0A= + ;;=0A= + mov psr.l=3Dr18=0A= + ;;=0A= +#endif=0A= +=0A= ssm psr.ic | PSR_DEFAULT_BITS=0A= ;;=0A= srlz.i // guarantee that interruption collection is on=0A= =0A= =0A= --- linux-kdb/include/asm-ia64/kdbprivate.h Fri Feb 28 17:17:00 2003=0A= +++ linux-kdb-hdr/include/asm-ia64/kdbprivate.h Thu Mar 13 16:59:56 = 2003=0A= @@ -65,6 +65,11 @@=0A= */=0A= #define KDB_STACK_DIRECTION (-1) /* Stack grows down */=0A= =0A= +=0A= +#define KDB_ISR_INST 0x100000000=0A= +#define KDB_ISR_DATAW 0x200000000=0A= +#define KDB_ISR_DATAR 0x400000000=0A= +=0A= /*=0A= * Support for IA64 debug registers=0A= */=0A= @@ -72,14 +77,13 @@=0A= kdb_machreg_t bph_reg; /* Register this breakpoint uses */=0A= =0A= unsigned int bph_free:1; /* Register available for use */=0A= - unsigned int bph_data:1; /* Data Access breakpoint */=0A= -=0A= - unsigned int bph_write:1; /* Write Data breakpoint */=0A= - unsigned int bph_mode:2; /* 0=3Dinst, 1=3Dwrite, 2=3Dio, 3=3Dread = */=0A= - unsigned int bph_length:2; /* 0=3D1, 1=3D2, 2=3DBAD, 3=3D4 (bytes) = */=0A= + unsigned int bph_mode:2; /* 00=3Dinst, 01=3Dread, 10=3Dwrite , = 11=3Dread or write*/=0A= + unsigned int bph_plm:4; /* 0001=3Dlevel 0, 0010=3Dlevel 1, = 0100=3Dlevel 2, 1000=3Dlevel 3 */=0A= + kdb_machreg_t bph_mask; /* 56 bits at max */=0A= } kdbhard_bp_t;=0A= =0A= -extern kdbhard_bp_t kdb_hardbreaks[/* KDB_MAXHARDBPT */];=0A= +extern kdbhard_bp_t kdb_hardbreak_i[/* KDB_MAXHARDBPT */];=0A= +extern kdbhard_bp_t kdb_hardbreak_d[/* KDB_MAXHARDBPT */];=0A= =0A= #define getprsregs(regs) ((struct switch_stack *)regs -1)=0A= =0A= @@ -87,14 +91,19 @@=0A= =0A= /* bkpt support using break inst instead of IBP reg */=0A= =0A= +extern kdb_machreg_t kdba_getidr(unsigned long);=0A= +extern void kdba_putidr(unsigned long, kdb_machreg_t);=0A= +extern kdb_machreg_t kdba_getddr(unsigned long);=0A= +extern void kdba_putddr(unsigned long, kdb_machreg_t);=0A= +=0A= /*=0A= * Define certain specific instructions=0A= */=0A= #define BREAK_INSTR (long)(KDB_BREAK_BREAK << (5+6))=0A= #define INST_SLOT0_MASK (0x1ffffffffffL << 5)=0A= =0A= -#define BKPTMODE_DATAR 3=0A= -#define BKPTMODE_IO 2=0A= +#define BKPTMODE_IO 3=0A= +#define BKPTMODE_DATAR 2=0A= #define BKPTMODE_DATAW 1=0A= #define BKPTMODE_INST 0=0A= =0A= =0A= --- linux-kdb/arch/ia64/kdb/kdbasupport.c Fri Feb 28 17:17:00 2003=0A= +++ linux-kdb/arch/ia64/kdb/kdbasupport.c Fri Mar 14 12:42:20 2003=0A= @@ -339,39 +339,79 @@=0A= void=0A= kdba_installdbreg(kdb_bp_t *bp)=0A= {=0A= - /* FIXME: code this */=0A= + kdb_machreg_t mask;=0A= +=0A= + if(bp->bp_hard->bph_mode){=0A= + mask =3D bp->bp_hard->bph_mode;=0A= + mask <<=3D 6;=0A= + mask |=3D bp->bp_hard->bph_plm;=0A= + mask <<=3D 56;=0A= + mask |=3D bp->bp_hard->bph_mask;=0A= + kdba_putddr(bp->bp_hard->bph_reg<<1, bp->bp_addr);=0A= + kdba_putddr((bp->bp_hard->bph_reg<<1)+1, mask);=0A= + ia64_srlz_d();=0A= + }=0A= + else {=0A= + mask =3D bp->bp_hard->bph_plm;=0A= + mask <<=3D 56;=0A= + mask |=3D 0x8000000000000000;=0A= + mask |=3D bp->bp_hard->bph_mask;=0A= + kdba_putidr(bp->bp_hard->bph_reg<<1, bp->bp_addr);=0A= + kdba_putidr((bp->bp_hard->bph_reg<<1)+1, mask);=0A= + ia64_srlz_i();=0A= + }=0A= +=0A= + return;=0A= }=0A= =0A= void=0A= kdba_removedbreg(kdb_bp_t *bp)=0A= {=0A= - /* FIXME: code this */=0A= + if (!bp->bp_hard)=0A= + return;=0A= +=0A= + if(bp->bp_hard->bph_mode){=0A= + kdba_putddr(bp->bp_hard->bph_reg<<1, 0);=0A= + kdba_putddr((bp->bp_hard->bph_reg<<1)+1, 0);=0A= + ia64_srlz_d();=0A= + }=0A= + else {=0A= + kdba_putidr(bp->bp_hard->bph_reg<<1, 0);=0A= + kdba_putidr((bp->bp_hard->bph_reg<<1)+1, 0);=0A= + ia64_srlz_i();=0A= + }=0A= }=0A= =0A= kdb_machreg_t=0A= -kdba_getdr(int regnum)=0A= +kdba_getidr(unsigned long regnum)=0A= {=0A= kdb_machreg_t contents =3D 0;=0A= - unsigned long reg =3D (unsigned long)regnum;=0A= =0A= - __asm__ ("mov %0=3Dibr[%1]"::"r"(contents),"r"(reg));=0A= -// __asm__ ("mov ibr[%0]=3D%1"::"r"(dbreg_cond),"r"(value));=0A= + __asm__ ("mov %0=3Dibr[%1]":"=3Dr"(contents):"r"(regnum));=0A= =0A= return contents;=0A= }=0A= =0A= -=0A= kdb_machreg_t=0A= -kdb_getcr(int regnum)=0A= +kdba_getddr(unsigned long regnum)=0A= {=0A= kdb_machreg_t contents =3D 0;=0A= +=0A= + __asm__ ("mov %0=3Ddbr[%1]":"=3Dr"(contents):"r"(regnum));=0A= +=0A= return contents;=0A= }=0A= =0A= void=0A= -kdba_putdr(int regnum, kdb_machreg_t contents)=0A= +kdba_putidr(unsigned long regnum, kdb_machreg_t contents)=0A= {=0A= - /* FIXME: code this */=0A= + __asm__ ("mov ibr[%0]=3D%1"::"r"(regnum),"r"(contents));=0A= +}=0A= +=0A= +void=0A= +kdba_putddr(unsigned long regnum, kdb_machreg_t contents)=0A= +{=0A= + __asm__ ("mov dbr[%0]=3D%1"::"r"(regnum),"r"(contents));=0A= }=0A= =0A= static void=0A= @@ -443,7 +483,7 @@=0A= }=0A= =0A= static int=0A= -show_cur_stack_frame(struct pt_regs *regs, int regno, unsigned long = *contents)=0A= +show_cur_stack_frame(struct pt_regs *regs, int regno, kdb_machreg_t = *contents)=0A= {=0A= unsigned long sof, i, cfm, val, sp, *bsp;=0A= struct unw_frame_info info;=0A= @@ -597,7 +637,7 @@=0A= static const int nkdbreglist =3D sizeof(kdbreglist) / sizeof(struct = kdbregs);=0A= =0A= int=0A= -kdba_getregcontents(const char *regname, struct pt_regs *regs, = unsigned long *contents)=0A= +kdba_getregcontents(const char *regname, struct pt_regs *regs, = kdb_machreg_t *contents)=0A= {=0A= int i;=0A= =0A= @@ -608,6 +648,13 @@=0A= return 0 ;=0A= }=0A= =0A= + if (strcmp(regname, "ifa") =3D=3D 0) {=0A= + fault_regs_t fr ;=0A= + get_fault_regs(&fr) ;=0A= + *contents =3D fr.ifa ;=0A= + return 0 ;=0A= + }=0A= +=0A= if (!regs) {=0A= kdb_printf("%s: pt_regs not available\n", __FUNCTION__);=0A= return KDB_BADREG;=0A= @@ -673,7 +720,7 @@=0A= int=0A= kdba_setregcontents(const char *regname,=0A= struct pt_regs *regs,=0A= - unsigned long contents)=0A= + kdb_machreg_t contents)=0A= {=0A= int i, ret =3D 0, fixed =3D 0;=0A= char *endp;=0A= @@ -815,9 +862,14 @@=0A= switch (type[0]) {=0A= case 'd':=0A= {=0A= - for(i=3D0; i<8; i+=3D2) {=0A= - kdb_printf("idr%d: 0x%16.16lx idr%d: 0x%16.16lx\n", i,=0A= - kdba_getdr(i), i+1, kdba_getdr(i+1));=0A= + for(i=3D0; ibp_free)=0A= + && (bp->bp_global || bp->bp_cpu =3D=3D smp_processor_id())=0A= + && (bp->bp_hard)=0A= + && (bp->bp_addr =3D=3D ifa)=0A= + && (isr&(KDB_ISR_INST|KDB_ISR_DATAR|KDB_ISR_DATAW))) {=0A= + kdb_printf("%s breakpoint #%d at " kdb_bfd_vma_fmt "\n",=0A= + kdba_rwtypes[bp->bp_hard->bph_mode],=0A= + i, bp->bp_addr);=0A= +=0A= + if(isr&KDB_ISR_INST)=0A= + kdb_id1(regs->cr_iip);=0A= + rv=3DKDB_DB_BPT;=0A= + if(!bp->bp_hard->bph_mode)=0A= + ia64_psr(regs)->id =3D 1;=0A= + else=0A= + ia64_psr(regs)->dd =3D 1;=0A= + break;=0A= + }=0A= + }=0A= + }=0A= +=0A= + if(rv =3D=3D KDB_DB_NOBPT) {=0A= + ia64_psr(regs)->id =3D 1;=0A= + ia64_psr(regs)->dd =3D 1;=0A= + }=0A= =0A= return(rv);=0A= }=0A= @@ -347,7 +379,10 @@=0A= void=0A= kdba_printbpreg(kdbhard_bp_t *bph)=0A= {=0A= - kdb_printf(" in dr%ld", bph->bph_reg);=0A= + if(bph->bph_mode)=0A= + kdb_printf(" in data dr%ld", bph->bph_reg);=0A= + else=0A= + kdb_printf(" in inst dr%ld", bph->bph_reg);=0A= }=0A= =0A= /*=0A= @@ -373,8 +408,8 @@=0A= if (bp->bp_hardtype) {=0A= kdba_printbpreg(bp->bp_hard);=0A= if (bp->bp_hard->bph_mode !=3D 0) {=0A= - kdb_printf(" for %d bytes",=0A= - bp->bp_hard->bph_length+1);=0A= + kdb_printf(" for mask %lx",=0A= + bp->bp_hard->bph_mask);=0A= }=0A= }=0A= }=0A= @@ -398,7 +433,7 @@=0A= * I/O breakpoints are supported in addition to instruction=0A= * breakpoints.=0A= *=0A= - * {datar|dataw|io|inst} [length]=0A= + * {inst|datar|dataw|datarw} [address mask]=0A= */=0A= =0A= int=0A= @@ -407,40 +442,39 @@=0A= int nextarg =3D *nextargp;=0A= int diag;=0A= kdbhard_bp_t *bph =3D &bp->bp_template;=0A= + kdb_bp_t *bp_check;=0A= + int i;=0A= =0A= bph->bph_mode =3D 0; /* Default to instruction breakpoint */=0A= - bph->bph_length =3D 0; /* Length must be zero for insn bp */=0A= + bph->bph_plm =3D 0xf;=0A= + bph->bph_mask =3D 0xffffffffffffff; /* Default to match all bit in = addr */=0A= if ((argc + 1) !=3D nextarg) {=0A= - if (strnicmp(argv[nextarg], "datar", sizeof("datar")) =3D=3D 0) {=0A= - bph->bph_mode =3D 3;=0A= + if (strnicmp(argv[nextarg], "inst", sizeof("inst")) =3D=3D 0) {=0A= + bph->bph_mode =3D 0;=0A= } else if (strnicmp(argv[nextarg], "dataw", sizeof("dataw")) =3D=3D = 0) {=0A= bph->bph_mode =3D 1;=0A= - } else if (strnicmp(argv[nextarg], "io", sizeof("io")) =3D=3D 0) = {=0A= + } else if (strnicmp(argv[nextarg], "datar", sizeof("datar")) =3D=3D = 0) {=0A= bph->bph_mode =3D 2;=0A= - } else if (strnicmp(argv[nextarg], "inst", sizeof("inst")) =3D=3D 0) = {=0A= - bph->bph_mode =3D 0;=0A= + } else if (strnicmp(argv[nextarg], "datarw", sizeof("datarw")) = =3D=3D 0) {=0A= + bph->bph_mode =3D 3;=0A= } else {=0A= return KDB_ARGCOUNT;=0A= }=0A= =0A= - bph->bph_length =3D 3; /* Default to 4 byte */=0A= -=0A= nextarg++;=0A= =0A= if ((argc + 1) !=3D nextarg) {=0A= - unsigned long len;=0A= + unsigned long mask;=0A= =0A= diag =3D kdbgetularg((char *)argv[nextarg],=0A= - &len);=0A= + &mask);=0A= if (diag)=0A= return diag;=0A= =0A= -=0A= - if ((len > 4) || (len =3D=3D 3))=0A= + if(mask&0xffffffffffffff)=0A= return KDB_BADLENGTH;=0A= =0A= - bph->bph_length =3D len;=0A= - bph->bph_length--; /* Normalize for debug register */=0A= + bph->bph_mask =3D mask;=0A= nextarg++;=0A= }=0A= =0A= @@ -474,17 +508,24 @@=0A= bp->bp_adjust =3D 0; /* software, break is fault, not trap */=0A= }=0A= }=0A= +=0A= + /* check instruction address*/=0A= + if(!bph->bph_mode)=0A= + kdba_check_pc(&(bp->bp_addr));=0A= + for(i=3D0,bp_check=3Dkdb_breakpoints; ibp_free && bp_check!=3Dbp=0A= + && bp_check->bp_addr =3D=3D bp->bp_addr) {=0A= + kdb_printf("You already have a breakpoint at " kdb_bfd_vma_fmt0 = "\n", bp->bp_addr);=0A= + return KDB_TOOMANYBPT;=0A= + }=0A= + }=0A= =0A= - if (bph->bph_mode =3D=3D 0 && kdba_verify_rw(bp->bp_addr, = bph->bph_length+1)) {=0A= + if (bph->bph_mode !=3D 0 && kdba_verify_rw(bp->bp_addr, 16)) {=0A= kdb_printf("Invalid address for breakpoint, ignoring bp = command\n");=0A= return KDB_BADADDR;=0A= }=0A= =0A= *nextargp =3D nextarg;=0A= - if (!bph->bph_free) {=0A= - kdb_printf("kdba_parsebp hardware breakpoints are not supported = yet\n");=0A= - return KDB_NOTIMP;=0A= - }=0A= return 0;=0A= }=0A= =0A= @@ -509,11 +550,22 @@=0A= kdba_allocbp(kdbhard_bp_t *bph, int *diagp)=0A= {=0A= int i;=0A= - kdbhard_bp_t *newbph;=0A= + kdbhard_bp_t *newbph=3DNULL;=0A= =0A= - for(i=3D0,newbph=3Dkdb_hardbreaks; i < KDB_MAXHARDBPT; i++, newbph++) = {=0A= - if (newbph->bph_free) {=0A= - break;=0A= + if(bph->bph_mode) {=0A= + for(i=3D0; i < KDB_MAXHARDBPT; i++) {=0A= + if (kdb_hardbreaks_d[i].bph_free) {=0A= + newbph=3D&kdb_hardbreaks_d[i];=0A= + break;=0A= + }=0A= + }=0A= + }=0A= + else {=0A= + for(i=3D0; i < KDB_MAXHARDBPT; i++) {=0A= + if (kdb_hardbreaks_i[i].bph_free) {=0A= + newbph=3D&kdb_hardbreaks_i[i];=0A= + break;=0A= + }=0A= }=0A= }=0A= =0A= @@ -529,10 +581,9 @@=0A= * here because the register number in kdb_hardbreaks must be=0A= * preserved.=0A= */=0A= - newbph->bph_data =3D bph->bph_data;=0A= - newbph->bph_write =3D bph->bph_write;=0A= newbph->bph_mode =3D bph->bph_mode;=0A= - newbph->bph_length =3D bph->bph_length;=0A= + newbph->bph_plm =3D bph->bph_plm;=0A= + newbph->bph_mask =3D bph->bph_mask;=0A= =0A= /*=0A= * Mark entry allocated.=0A= @@ -589,17 +640,20 @@=0A= kdba_initbp(void)=0A= {=0A= int i;=0A= - kdbhard_bp_t *bph;=0A= =0A= /*=0A= * Clear the hardware breakpoint table=0A= */=0A= =0A= - memset(kdb_hardbreaks, '\0', sizeof(kdb_hardbreaks));=0A= + memset(kdb_hardbreaks_i, '\0', sizeof(kdb_hardbreaks_i));=0A= + memset(kdb_hardbreaks_d, '\0', sizeof(kdb_hardbreaks_d));=0A= +=0A= + for(i=3D0; ibph_reg =3D i;=0A= - bph->bph_free =3D 1;=0A= + kdb_hardbreaks_d[i].bph_reg =3D i;=0A= + kdb_hardbreaks_d[i].bph_free =3D 1;=0A= }=0A= }=0A= =0A= @@ -642,6 +696,7 @@=0A= }=0A= if (!KDB_STATE(SSBPT))=0A= bp->bp_delay =3D 0;=0A= +=0A= if (!bp->bp_installed) {=0A= if (bp->bp_hardtype) {=0A= kdba_installdbreg(bp);=0A= @@ -719,9 +774,9 @@=0A= bp->bp_inst.inst[0], bp->bp_inst.inst[1], bp->bp_addr);=0A= if (kdba_putarea_size(bp->bp_addr, bp->bp_inst.inst, = sizeof(bp->bp_inst.inst)))=0A= return(1);=0A= + flush_icache_range(bp->bp_addr, bp->bp_addr+16);=0A= }=0A= bp->bp_installed =3D 0;=0A= - flush_icache_range(bp->bp_addr, bp->bp_addr+16);=0A= }=0A= return(0);=0A= }=0A= =0A= --- linux-kdb/kdb/kdb_bp.c Thu Mar 13 15:33:15 2003=0A= +++ linux-kdb-hdr/kdb/kdb_bp.c Thu Mar 13 15:56:26 2003=0A= /*=0A= * Allocate a new bp structure=0A= */=0A= @@ -317,13 +317,6 @@=0A= return KDB_TOOMANYBPT;=0A= =0A= memset(bp, 0, sizeof(*bp));=0A= - kdba_check_pc(&addr);=0A= - for(i=3D0,bp_check=3Dkdb_breakpoints; ibp_free && bp_check->bp_addr =3D=3D addr) {=0A= - kdb_printf("You already have a breakpoint at " kdb_bfd_vma_fmt0 = "\n", addr);=0A= - return KDB_TOOMANYBPT;=0A= - }=0A= - }=0A= bp->bp_addr =3D addr;=0A= =0A= bp->bp_forcehw =3D hardware;=0A= =0A= =0A= --- linux-kdb/arch/i386/kdb/kdba_bp.c Fri Mar 14 13:15:33 2003=0A= +++ linux-kdb-hdr/arch/i386/kdb/kdba_bp.c Fri Mar 14 13:18:55 2003=0A= @@ -500,6 +500,8 @@=0A= int nextarg =3D *nextargp;=0A= int diag;=0A= kdbhard_bp_t *bph =3D &bp->bp_template;=0A= + kdb_bp_t *bp_check;=0A= + int i;=0A= =0A= bph->bph_mode =3D 0; /* Default to instruction breakpoint */=0A= bph->bph_length =3D 0; /* Length must be zero for insn bp */=0A= @@ -565,6 +567,16 @@=0A= */=0A= bph->bph_free =3D 1;=0A= bp->bp_adjust =3D 1; /* software, int 3 is one byte */=0A= + }=0A= + }=0A= +=0A= + /* check instruction address*/=0A= + kdba_check_pc(&(bp->bp_addr));=0A= + for(i=3D0,bp_check=3Dkdb_breakpoints; ibp_free && bp_check!=3Dbp=0A= + && bp_check->bp_addr =3D=3D bp->bp_addr) {=0A= + kdb_printf("You already have a breakpoint at " kdb_bfd_vma_fmt0 = "\n", bp->bp_addr);=0A= + return KDB_TOOMANYBPT;=0A= }=0A= }=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ------_=_NextPart_000_01C2E929.E32EA0D0-- From kaos@sgi.com Wed Mar 12 22:46:05 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 12 Mar 2003 22:46:11 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2D6k4q9017664 for ; Wed, 12 Mar 2003 22:46:05 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2D6junH014816 for ; Wed, 12 Mar 2003 22:45:57 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA24726; Thu, 13 Mar 2003 17:44:38 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 4C9383000B8; Thu, 13 Mar 2003 17:44:36 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id A954B8F; Thu, 13 Mar 2003 17:44:36 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Zhang, Sonic" Cc: "KDB (E-mail)" Subject: Re: I add a new patch to support hardware debug registers for IA64. In-reply-to: Your message of "Thu, 13 Mar 2003 14:29:23 +0800." <957BD1C2BF3CD411B6C500A0C944CA26033AFF88@pdsmsx32.pd.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Mar 2003 17:44:31 +1100 Message-ID: <7294.1047537871@kao2.melbourne.sgi.com> X-archive-position: 269 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Thu, 13 Mar 2003 14:29:23 +0800, "Zhang, Sonic" wrote: > In the latest KDB v3.0 patch, I can't find any way to use a hardware >debug register under Itanium platform. Could you please tell me why you >don't add that feature for IA64 as what you do for IA32? Lack of time/interest. > I investigated the IA64 System Architecture Specification and >decided to changed some of the IA64 related code in KDB to support hardware >debugging. Now, the patch is finished. Please take a look at the attachment. >This patch is based on KDB v3.0 with Linux Kernel 2.4.20. I am close to releasing kdb v4.0 which has significant changes to catch MCA and INIT problems on ia64. Can you wait until kdb v4.0 is out, then we can look at hardware breakpoints for ia64? From sonic.zhang@intel.com Wed Mar 12 22:57:11 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 12 Mar 2003 22:57:14 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2D6vAq9017700 for ; Wed, 12 Mar 2003 22:57:11 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2D6t7921674 for ; Thu, 13 Mar 2003 06:55:07 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2D6rFQ16942 for ; Thu, 13 Mar 2003 06:53:16 GMT Received: from pdsmsx17.pd.intel.com ([172.16.12.121]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003031314565815056 ; Thu, 13 Mar 2003 14:56:58 +0800 Received: by pdsmsx17.pd.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 14:55:34 +0800 Message-ID: <957BD1C2BF3CD411B6C500A0C944CA26033AFF94@pdsmsx32.pd.intel.com> From: "Zhang, Sonic" To: Keith Owens , "Zhang, Sonic" Cc: "KDB (E-mail)" Subject: RE: I add a new patch to support hardware debug registers for IA6 4. Date: Thu, 13 Mar 2003 14:54:41 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-archive-position: 270 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb Hi, OK, I am now waiting for your new version. And I will port my patch to KDB v4.0 after you release it in the near future. By the way, have you ever encountered the problem caused by psr.dd? If you have time, could you please give some explanation? Thank you. Sonic Zhang -----Original Message----- From: Keith Owens [mailto:kaos@sgi.com] Sent: 2003?3?13? 14:45 To: Zhang, Sonic Cc: KDB (E-mail) Subject: Re: I add a new patch to support hardware debug registers for IA64. On Thu, 13 Mar 2003 14:29:23 +0800, "Zhang, Sonic" wrote: > In the latest KDB v3.0 patch, I can't find any way to use a hardware >debug register under Itanium platform. Could you please tell me why you >don't add that feature for IA64 as what you do for IA32? Lack of time/interest. > I investigated the IA64 System Architecture Specification and >decided to changed some of the IA64 related code in KDB to support hardware >debugging. Now, the patch is finished. Please take a look at the attachment. >This patch is based on KDB v3.0 with Linux Kernel 2.4.20. I am close to releasing kdb v4.0 which has significant changes to catch MCA and INIT problems on ia64. Can you wait until kdb v4.0 is out, then we can look at hardware breakpoints for ia64? From ornella@hotma.il.co.sgi.com Thu Mar 13 02:46:47 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 13 Mar 2003 02:46:49 -0800 (PST) Received: from ommo.net ([194.54.51.136]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2DAkgq9024015 for ; Thu, 13 Mar 2003 02:46:45 -0800 Message-Id: <200303131046.h2DAkgq9024015@oss.sgi.com> From: "Anna Ornella" To: kdb@oss.sgi.com Date: Thu, 13 Mar 2003 12:46:48 +0200 Subject: X-Mailer: Microsoft Outlook Express 5.00.2919.7000 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-archive-position: 271 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: ornella@hotma.il.co.sgi.com Precedence: bulk X-list: kdb =3Chtml=3E =3Chead=3E =3Ctitle=3E=2E=3C=2Ftitle=3E =3C=2Fhead=3E =3Cbody bgcolor=3D=22#000000=22 link=3D=22#000000=22 vlink=3D=22#0000FF=22 background=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2F99=2Egif=22=3E =3Cp align=3D=22center=22=3E=3Cimg src=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2Fnnnn=2Egif=22=3E=3Cimg src=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2Fnn=2Egif=22 alt=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2Fnn=2Egif =28135 bytes=29=22=3E=3Cimg src=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2Fnnn=2Egif=22=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Ca href=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=22=3E=3Cfont color=3D=22#808080=22=3E=3Cimg src=3D=22amy=2EJPG=22=3E=3C=2Ffont=3E=3C=2Fa=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont color=3D=22#808080=22=3E=3Cem=3E=3Cstrong=3E=3Csmall=3EUta Girl=3C=2Fsmall=3E=3C=2Fstrong=3E=3C=2Fem=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Ca href=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=22=3E=3Cem=3E=3Cfont face=3D=22Arial=22 color=3D=22#808040=22=3E=3Cu=3EENTER=3C=2Fu=3E=3C=2Ffont=3E=3C=2Fem=3E=3C=2Fa=3E=3C=2Fp=3E =3C=2Fbody=3E =3C=2Fhtml=3E From ornella@hotma.il.co.sgi.com Sun Mar 16 02:03:35 2003 Received: with ECARTIS (v1.0.0; list kdb); Sun, 16 Mar 2003 02:03:43 -0800 (PST) Received: from ommo.net ([194.54.51.136]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2GA2uq9012564 for ; Sun, 16 Mar 2003 02:03:34 -0800 Message-Id: <200303161003.h2GA2uq9012564@oss.sgi.com> From: "Anna Ornella" To: kdb@oss.sgi.com Date: Sun, 16 Mar 2003 12:03:39 +0200 Subject: X-Mailer: Microsoft Outlook Express 5.00.2919.7000 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-archive-position: 272 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: ornella@hotma.il.co.sgi.com Precedence: bulk X-list: kdb =3Chtml=3E =3Chead=3E =3Ctitle=3E=2E=3C=2Ftitle=3E =3C=2Fhead=3E =3Cbody bgcolor=3D=22#000000=22 link=3D=22#000000=22 vlink=3D=22#0000FF=22 background=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2F99=2Egif=22=3E =3Cp align=3D=22center=22=3E=3Cimg src=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2Fnnnn=2Egif=22=3E=3Cimg src=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2Fnn=2Egif=22 alt=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2Fnn=2Egif =28135 bytes=29=22=3E=3Cimg src=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=2Fnnn=2Egif=22=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Ca href=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=22=3E=3Cfont color=3D=22#808080=22=3E=3Cimg src=3D=22amy=2EJPG=22=3E=3C=2Ffont=3E=3C=2Fa=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont color=3D=22#808080=22=3E=3Cem=3E=3Cstrong=3E=3Csmall=3EUta Girl=3C=2Fsmall=3E=3C=2Fstrong=3E=3C=2Fem=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Ca href=3D=22http=3A=2F=2Fgeocities=2Ecom=2Fneden627=2Fs=22=3E=3Cem=3E=3Cfont face=3D=22Arial=22 color=3D=22#808040=22=3E=3Cu=3EENTER=3C=2Fu=3E=3C=2Ffont=3E=3C=2Fem=3E=3C=2Fa=3E=3C=2Fp=3E =3C=2Fbody=3E =3C=2Fhtml=3E From kaos@sgi.com Sun Mar 16 21:42:19 2003 Received: with ECARTIS (v1.0.0; list kdb); Sun, 16 Mar 2003 21:42:23 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2H5gIq9003886 for ; Sun, 16 Mar 2003 21:42:19 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2H5rMkq031166 for ; Sun, 16 Mar 2003 23:53:23 -0600 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA29104; Mon, 17 Mar 2003 16:40:51 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 4317A3000B8; Mon, 17 Mar 2003 16:40:49 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id B4BE48F; Mon, 17 Mar 2003 16:40:49 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: kdb@oss.sgi.com Cc: linux-kernel@vger.kernel.org, linux-ia64@linuxia64.org Subject: Announce: kdb v4.0 is available for kernels 2.4.19, 2.4.20, i386 and ia64 Date: Mon, 17 Mar 2003 16:40:44 +1100 Message-ID: <24691.1047879644@kao2.melbourne.sgi.com> X-archive-position: 273 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/kdb/download/v4.0/ kdb-v4.0-2.4.19-common-1.bz2 kdb-v4.0-2.4.19-i386-1.bz2 kdb-v4.0-2.4.19-ia64-020821-1.bz2 kdb-v4.0-2.4.20-common-1.bz2 kdb-v4.0-2.4.20-i386-1.bz2 kdb-v4.0-2.4.20-ia64-021210-1.bz2 <=== You know what they say about .0 releases. Caveat emptor. ===> The biggest change is this release in the way that kdb captures data from each cpu. Prior to v4.0, the controlling cpu (first to get into kdb) would try to pull the other cpus into kdb by sending them an IPI. Doing a backtrace on the active tasks required that kdb switch its context into each cpu in turn. This works in most cases, but when the system is really wedged, it is difficult to get data from the other cpus. Of course this is precisely the case when we want data from the other cpus. This problem is particularly noticeable on ia64, when machine checks (MCA) or INIT interrupts can disable normal IPI or dive down into SAL, taking control away from the OS. Also on IA64 the non-maskable interrupt is actually masked[1]. In kdb v4.0, each cpu pushes its state via a global array. This allows any cpu to do a backtrace on any other cpu, from a known starting point. It even handles the cases when IA64 requires that cpus rendezvous and spin in SAL. The push model also makes it easier to detect when a cpu is dead, an event which would often hang the old kdb pull model. On ia64, kdb v4.0 gives decent backtraces from MCA callback, MCA rendezvous and the INIT monarch event. The next step in kdb v4.1 is to detect hung spinloops and break out of them, and to support INIT slave events. The detection and debugging of hung spinloops is waiting on acceptance of my new spinlock code for IA64[2]. [1] http://external-lists.valinux.com/archives//linux-ia64/2001-May/subject.html, look for 'Replacements for local_irq_xxx'. [2] http://external-lists.valinux.com/archives//linux-ia64/2003-March/004976.html Changelog extracts since v3.0. 2.4.{19,20}-common-1 2003-03-16 Keith Owens * Each cpu saves its state as it enters kdb or before it enters code which cannot call kdb. * Allow btp on process 0 for a specified cpu. * Add btt command, backtrace given a struct task address. * btc command no longer switches cpus, instead it uses the saved data. * bta shows the idle task on each cpu as well as real tasks, the idle task could be handling an interrupt. * ps command shows the idle task on each cpu. * ps checks that the saved data for a cpu matches the process running on that cpu and warns about stale saved data or no saved data at all. * Remove special cases for i386 backtrace from common code and simplify common bt code. * Clean up kdb interaction with CONFIG_SERIAL_CONSOLE. * Do not automatically repeat commands after the user typed 'q'. * O(1) scheduler patch changes the process cpu field but does not set any indicator that O(1) is being used. Adjust kdb_process_cpu() by hand after applying O(1). * Add kdb_print_nameval() to common code. * Convert tests of cpu_online_map to cpu_online() macro. * module.h needs errno.h when compiling with CONFIG_MODULES=n. * Correct duplicate breakpoint handling. * Do not try to send IPI during a catastrophic error, send_ipi can hang and take kdb with it. * kdb memmap command is i386 only, restrict it. * Add large block device (LBD) support from XFS tree. Eric Sandeen. 2.4.{19,20}-i386-1 2003-03-16 Keith Owens * Each cpu saves its state as it enters kdb or before it enters code which cannot call kdb, converting kdb from a pull to a push model. * Clean up kdb interaction with CONFIG_SERIAL_CONSOLE. * Removal of special cases for i386 backtrace from common code simplifies the architecture code. * Add command to dump i386 struct pt_regs. 2.4.{19,20}-ia64-*-1 2003-03-16 Keith Owens * Each cpu saves its state as it enters kdb or before it enters code which cannot call kdb, converting kdb from a pull to a push model. * Clean up kdb interaction with CONFIG_SERIAL_CONSOLE. * Removal of special cases for i386 backtrace from common code simplifies the architecture code. * Add support for MCA events (both main and rendezvous) plus INIT monarch event. * Correct decode of brl. * Move kdba_print_nameval to common code. * Generalize kdba unwind handlers. * Fix decode of sal records (fix included in later ia64 kernels). * Handle multiple pt_regs in stack (fix included in later ia64 kernels). * Clean up debug code in unwind (fix included in later ia64 kernels). * Move kdb break numbers to their own file so it can be used in asm. v4.0/README Starting with kdb v2.0 there is a common patch against each kernel which contains all the architecture independent code plus separate architecture dependent patches. Apply the common patch for your kernel plus at least one architecture dependent patch, the architecture patches activate kdb. The naming convention for kdb patches is :- vx.y The version of kdb. x.y is updated as new features are added to kdb. -v.p.s The kernel version that the patch applies to. 's' may include -pre, -rc or whatever numbering system the kernel keepers have thought up this week. -common The common kdb code. Everybody needs this. -i386 Architecture dependent code for i386. -ia64 Architecture dependent code for ia64, etc. -n If there are multiple kdb patches against the same kernel version then the last number is incremented. To build kdb for your kernel, apply the common kdb patch which is less than or equal to the kernel v.p.s, taking the highest value of '-n' if there is more than one. Apply the relevant arch dependent patch with the same value of 'vx.y-v.p.s-', taking the highest value of '-n' if there is more than one. For example, to use kdb for i386 on kernel 2.4.20, apply kdb-v4.0-2.4.20-common- (use highest value of ) kdb-v4.0-2.4.20-i386- (use highest value of ) in that order. To use kdb for ia64-021210 on kernel 2.4.20, apply kdb-v4.0-2.4.20-common- (use highest value of ) kdb-v4.0-2.4.20-ia64-021210- (use highest value of ) in that order. Use patch -p1 for all patches. I do not have any time to work on 2.5, so there are no patches available for 2.5 kernels. If somebody wants to port the latest kdb patches to 2.5 kernels and send patches to kaos@sgi.com then I will put them up in this directory. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE+dV/Zi4UHNye0ZOoRAnClAJ9w5o2dFH1PiacptvwX1uGJRWb1lACdEcpH 3F9mS5NCPrM91Nt1WuYEm+s= =dlxz -----END PGP SIGNATURE----- From kaos@sgi.com Mon Mar 17 20:46:18 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 17 Mar 2003 20:46:23 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2I4kEq9019101 for ; Mon, 17 Mar 2003 20:46:17 -0800 Received: (qmail 13899 invoked from network); 18 Mar 2003 04:46:08 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 18 Mar 2003 04:46:07 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 55C8C300210; Tue, 18 Mar 2003 15:17:07 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3F5448F for ; Tue, 18 Mar 2003 15:17:07 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: kdb@oss.sgi.com Subject: A complete patch for hardware breakpoint support based on KDB v4.0 (ia64 and i386) (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 2003 15:17:02 +1100 Message-ID: <1849.1047961022@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 274 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb Sonic Zhang's patches are too big for the mailing list so I have stored them in ftp://oss.sgi.com//projects/kdb/download/v4.0/kdb-smphdr* and extracted the start of the mail for the list. From: "Zhang, Sonic" Hi, I have enhanced my last patch for hardware debug register on ia64 to support different hard breakpoints on different CPU. And I also integrated this patch with former patch on i386 to generate a complete version. With this patch, you can: 1. Create, delete and use hardware instruction and data breakpoints on ia64 architecture, such as Itanium / Itanium 2. 2. Create local and global hardware breakpoints concurrent. 3. Create different local hardware breakpoints on different CPUs. All debug registers of each CPU can be fully utilized, no waste. Sample: CPU1 CPU2 -------------------------------------------- dr0 (local) bp1 bp5 dr1 (global) bp2 bp2 dr2 (global) bp3 bp3 dr3 (local) bp4 bp6 Current known issues in my patch: 1. The IP and instruction debug registers on ia64 always point to a bundle of 3 instructions, while the psr.id bit is defined to resume 1 instruction in a bundle. That means the instruction stream traps into the same hardware breakpoint continuously for 3 times before the IP changes to a large address. 2. I have trouble to let the psr.dd bit work for ia64 hardware data breakpoint. This problem is under investigation. Could you give me some ideas? Please take a look at the attachment. It is based on the latest KDB v4.0. Thank you. ************************************* Sonic Zhang Software Engineer Intel China Software Lab Tel: 021-52574545-1667 iNet: 8-752-1667 ************************************* From terje.eggestad@scali.com Tue Mar 18 02:33:34 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 18 Mar 2003 02:33:43 -0800 (PST) Received: from elin.scali.no (elin.scali.no [62.70.89.10]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IAXVq9011964 for ; Tue, 18 Mar 2003 02:33:33 -0800 Received: from pc-16.office.scali.no (pc-16.office.scali.no [172.16.0.116]) by elin.scali.no (8.12.8/8.12.5) with ESMTP id h2IAXSJO017624; Tue, 18 Mar 2003 11:33:28 +0100 Subject: Re: Announce: kdb v4.0 is available for kernels 2.4.19, 2.4.20, i386 and ia64 From: Terje Eggestad To: Keith Owens Cc: kdb@oss.sgi.com, linux-kernel In-Reply-To: <24691.1047879644@kao2.melbourne.sgi.com> References: <24691.1047879644@kao2.melbourne.sgi.com> Content-Type: multipart/alternative; boundary="=-J/GyprhR03KiVy5KrO/p" Organization: Scali AS Message-Id: <1047983607.15586.6.camel@pc-16.office.scali.no> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Mar 2003 11:33:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 275 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: terje.eggestad@scali.com Precedence: bulk X-list: kdb --=-J/GyprhR03KiVy5KrO/p Content-Type: text/plain Content-Transfer-Encoding: 7bit Do you know if anybody is working on a x86-64 port? -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ --=-J/GyprhR03KiVy5KrO/p Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Do you know if anybody is working on a x86-64 port?






-- 
_________________________________________________________________________

Terje Eggestad                  mailto:terje.eggestad@scali.no
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________
--=-J/GyprhR03KiVy5KrO/p-- From kaos@sgi.com Tue Mar 18 03:26:27 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 18 Mar 2003 03:26:31 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IBQNq9014782 for ; Tue, 18 Mar 2003 03:26:25 -0800 Received: (qmail 16910 invoked from network); 18 Mar 2003 11:26:20 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 18 Mar 2003 11:26:20 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id A3B203000B8; Tue, 18 Mar 2003 22:26:16 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 590268F; Tue, 18 Mar 2003 22:26:16 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Terje Eggestad Cc: kdb@oss.sgi.com, linux-kernel Subject: Re: Announce: kdb v4.0 is available for kernels 2.4.19, 2.4.20, i386 and ia64 In-reply-to: Your message of "18 Mar 2003 11:33:28 BST." <1047983607.15586.6.camel@pc-16.office.scali.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 2003 22:26:10 +1100 Message-ID: <6364.1047986770@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 276 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On 18 Mar 2003 11:33:28 +0100, Terje Eggestad wrote: >Do you know if anybody is working on a x86-64 port? Not that I know about. From Thomas.Duffy.99@alumni.brown.edu Tue Mar 18 10:59:37 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 18 Mar 2003 10:59:41 -0800 (PST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2IIxaq9002895 for ; Tue, 18 Mar 2003 10:59:37 -0800 Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18900; Tue, 18 Mar 2003 10:59:29 -0800 (PST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IIxTcU012947; Tue, 18 Mar 2003 10:59:29 -0800 (PST) Received: from biznatch (biznatch.Eng.Sun.COM [129.144.24.170]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HBY00G58KR5F5@ha1sun-mail1.eng.sun.com>; Tue, 18 Mar 2003 10:59:29 -0800 (PST) Date: Tue, 18 Mar 2003 10:59:23 -0800 From: Thomas Duffy Subject: Re: Announce: kdb v4.0 is available for kernels 2.4.19, 2.4.20, i386 and ia64 In-reply-to: <24691.1047879644@kao2.melbourne.sgi.com> To: Keith Owens Cc: kdb@oss.sgi.com Message-id: <1048013963.22735.25.camel@biznatch> Organization: MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-3) Content-type: multipart/mixed; boundary="Boundary_(ID_SZJJhelGQZIgzFTz8i3ixQ)" References: <24691.1047879644@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 277 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: Thomas.Duffy.99@alumni.brown.edu Precedence: bulk X-list: kdb --Boundary_(ID_SZJJhelGQZIgzFTz8i3ixQ) Content-type: text/plain Content-transfer-encoding: 7BIT On Sun, 2003-03-16 at 21:40, Keith Owens wrote: > 2.4.{19,20}-common-1 The attached patch is needeed to kdb common to build on sparc64. * include/linux/kdb.h references task_struct, needs to include sched.h * kdb/kdbmain.c #define's WRAP already defined in include/asm-sparc64/termbits.h -- Thomas Duffy --Boundary_(ID_SZJJhelGQZIgzFTz8i3ixQ) Content-type: text/plain; name=kdb-v4.0-2.4.20-sparc-build-fix.patch; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=kdb-v4.0-2.4.20-sparc-build-fix.patch --- linux-2.4.20+kdb/include/linux/kdb.h 2003-03-18 09:28:44.000000000 -0800 +++ linux-2.4.20+kdb+sparc64/include/linux/kdb.h 2003-03-18 10:08:19.000000000 -0800 @@ -38,6 +38,7 @@ #include #include +#include #include #define KDB_MAJOR_VERSION 4 --- linux-2.4.20+kdb/kdb/kdbmain.c 2003-03-18 09:28:44.000000000 -0800 +++ linux-2.4.20+kdb+sparc64/kdb/kdbmain.c 2003-03-18 10:36:28.000000000 -0800 @@ -2567,17 +2567,17 @@ logsize = syslog_data[1] - syslog_data[0]; start = syslog_data[0] + (syslog_data[2] - syslog_data[0]) % logsize; end = syslog_data[0] + (syslog_data[3] - syslog_data[0]) % logsize; -#define WRAP(p) if (p < syslog_data[0]) p = syslog_data[1]-1; else if (p >= syslog_data[1]) p = syslog_data[0] +#define KDB_WRAP(p) if (p < syslog_data[0]) p = syslog_data[1]-1; else if (p >= syslog_data[1]) p = syslog_data[0] if (lines) { char *p = end; ++lines; do { --p; - WRAP(p); + KDB_WRAP(p); if (*p == '\n') { if (--lines == 0) { ++p; - WRAP(p); + KDB_WRAP(p); break; } } @@ -2592,7 +2592,7 @@ if (!*start) { while (!*start) { ++start; - WRAP(start); + KDB_WRAP(start); if (start == end) break; } @@ -2604,7 +2604,7 @@ c = *start; ++chars; ++start; - WRAP(start); + KDB_WRAP(start); if (start == end || c == '\n') break; } --Boundary_(ID_SZJJhelGQZIgzFTz8i3ixQ)-- From edie.dong@intel.com Thu Mar 20 04:04:20 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 20 Mar 2003 04:04:23 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KC4Iq9016675 for ; Thu, 20 Mar 2003 04:04:19 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2KBxqZ25195 for ; Thu, 20 Mar 2003 11:59:52 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by talaria.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2KBdx402041 for ; Thu, 20 Mar 2003 11:39:59 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003032020041100054 for ; Thu, 20 Mar 2003 20:04:11 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Mar 2003 20:04:11 +0800 content-class: urn:content-classes:message Subject: KDB test case MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Thu, 20 Mar 2003 20:04:11 +0800 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E1C5218@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KDB test case Thread-Index: AcLu2MqJE4szF4g+Rr6yferoG3kqLA== From: "Dong, Edie" To: X-OriginalArrivalTime: 20 Mar 2003 12:04:11.0924 (UTC) FILETIME=[D1C12D40:01C2EED8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2KC4Iq9016675 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 278 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: edie.dong@intel.com Precedence: bulk X-list: kdb Who have set of KDB test case? I want to use them to fully test my xscale support patch. thanks,eddie From kaos@sgi.com Thu Mar 20 04:30:41 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 20 Mar 2003 04:30:49 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2KCUbq9017506 for ; Thu, 20 Mar 2003 04:30:40 -0800 Received: (qmail 727 invoked from network); 20 Mar 2003 12:30:34 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 20 Mar 2003 12:30:34 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id C3E503000B8; Thu, 20 Mar 2003 23:30:32 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B60C08F; Thu, 20 Mar 2003 23:30:32 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Dong, Edie" Cc: kdb@oss.sgi.com Subject: Re: KDB test case In-reply-to: Your message of "Thu, 20 Mar 2003 20:04:11 +0800." <37FBBA5F3A361C41AB7CE44558C3448E1C5218@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Mar 2003 23:30:27 +1100 Message-ID: <953.1048163427@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 279 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Thu, 20 Mar 2003 20:04:11 +0800, "Dong, Edie" wrote: >Who have set of KDB test case? I want to use them to fully test my >xscale support patch. Sonic Zhang (also of intel) mailed some test cases back in January. They need to be updated slightly for kdb v4.0. Which reminds me, I must find out what happened to the list archive:( From sonic.zhang@intel.com Thu Mar 20 16:47:05 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 20 Mar 2003 16:47:08 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2L0l4q9003714 for ; Thu, 20 Mar 2003 16:47:05 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2L0j1229061 for ; Fri, 21 Mar 2003 00:45:01 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2L0h5B22551 for ; Fri, 21 Mar 2003 00:43:06 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003032108465600636 ; Fri, 21 Mar 2003 08:46:56 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Mar 2003 08:46:56 +0800 content-class: urn:content-classes:message Subject: RE: KDB test case MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2EF43.5F84E096" Date: Fri, 21 Mar 2003 08:46:56 +0800 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E1C526D@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: KDB test case Thread-Index: AcLu3i2ZBfnvO+VQTZmOuTORnX+2sQAZOR6A From: "Zhang, Sonic" To: "Keith Owens" , "Dong, Edie" Cc: X-OriginalArrivalTime: 21 Mar 2003 00:46:56.0849 (UTC) FILETIME=[5FC68C10:01C2EF43] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 280 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EF43.5F84E096 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please refer to the attachments. This document is for KDB version before 3.0. Sonic Zhang -----Original Message----- From: Keith Owens [mailto:kaos@sgi.com] Sent: 2003?3?20? 20:30 To: Dong, Edie Cc: kdb@oss.sgi.com Subject: Re: KDB test case=20 On Thu, 20 Mar 2003 20:04:11 +0800,=20 "Dong, Edie" wrote: >Who have set of KDB test case? I want to use them to fully test my=20 >xscale support patch. Sonic Zhang (also of intel) mailed some test cases back in January. They need to be updated slightly for kdb v4.0. Which reminds me, I must find out what happened to the list archive:( ------_=_NextPart_001_01C2EF43.5F84E096 Content-Type: application/x-gzip; name="kdbtesttools.tar.gz" Content-Transfer-Encoding: base64 Content-Description: kdbtesttools.tar.gz Content-Disposition: attachment; filename="kdbtesttools.tar.gz" H4sIAEHJXT4AA+1aeW/bNhTvvyKQ7/DqdJuvxDqdNq4HDEmPYGk3LBk6oAsyWaIq1rJkSHKODvnu e0+HLXlO0g2us4M/uBFFPpKP7+Kj2LE7SnmSplEUJL1HXwaqaqp7loXPDMvPvLzX19Q9wzQNLGu6 oVqPwPpC/NQwS1I7BngUR1F6F9197f9SjKv6d2I78ddvBZ+pf53Ub/ZJ/4apSf1vBCv0n/3dddY3 h6qpd+lf062K/i0D6c1+X3sE6vpYuB3/c/1vCy90uQfn59+/+Onti+Pz8y22jRUi5PU6HrrCw+ec /s0Phz8fv6jTV+oK+i3Wa8OpzyHkDk8SO74Gn9suj8ETAU+g3StoTlI7dO3YBRHCmMchD2ASubOS ZluETjBzOTwPRDi76uUku/63AIC93/FvYg5uJMIPZe/LKB6v7JoPO+96MuWO8IRjB8F1F+xi1oKx grmjUKTCDsQnDimupUIiwhQ5Ful5XtdsbbHftxhAVj+g0jTG8rjZeM2DIOoSW4ELOziOSAB/NF7B cTLl9hhX8GvYaA0yUZOkC5n++N3bowPYYoqAIWjYrEztUDjNxim6L2TliuiciMQxm0zLsXiQcOxz 6aPUoakhm8p8pIWuAGKezuIQVKy+mS//IOB2OJsi1zOkdOHSt1N+gTqsrByogSRyEWHByXssS6WU xYkfxWm5+kB4HCIPRV/Te8H5Da4Zfw/tJ/9VrIj/b+wxJ+dc2xz3xH/VMPcw/lsmZn248yOdZqm4 Jcj4vwFsQ6lu8KIYfXBkJxhJap7I2MHB8IPjMAxFBy+Pv3t1AvtD2HmHERN2DvP4hIXFdoEvx0dv f/6FIcW+ouQJRcSK535R4UBvlsS9Ijr38uCMUSURUbjrY3x60jw4aMGT5nza1ny6IhzuOFCOtRNB OQ/Los8+jhBPYMeD9m700GL+x6Lm/664EC5X130C+Cv5v6HqlP/3DVPm/5vASv3nz088jtZyDLgv /qt7ahb/VUO3+gbuBVpfw21Axv8NgPLUiS3CZov9jrklZa3djwOmMOXjUB0U2Sb0AOuYMk8O2c1D 8y2xHqz0/zVngPf5v2Us8j/dpPO/pe/p0v83gSKzOz4cBu5SfocJ3cmbH7NsDp+VBK+S9B1h2jYq TtRJ77dZaE847MS/9UYzEbhlblfmij/ojL1Eu8qohrDYZliWKWKqV7a2mLLNHT+qZX+MVQhq1Jj0 YbZ4fIgJYkyZYKWpTqbUxsBctNbsKGxl0unUqRYJZp5f3job/POPrTX/L14eMv/T+7T/G/gm879N YKX+Nx7/zaX8zzK1voz/m8BDxn+yNTQ5GfwfECv9v1DMuu6A7vF/U+0bi/hvZd//rL70/43g1nuV 269NGGO99vB2sOxLYhAwALC9lGM5st3KxUmXWkR4EY05oJl1wQ5dYApGiMl1dBkGIknB0vowcYkw jSDxo0ugCJKNkXygaiIoLhAiz0t4ug+J+MQjr4mH2FaHyk3Ht+NW29J0dge7w2G7xxhaQSocoB7t nA2628C53p8NFTwZN06L+5oo5I1u5T29jOrvfsyXKJBFHroNdjOYz5Ok8cxJF+tNr6dcKQ7g4WyC B2/ihNb6Htk/GygYnFb1gTZMQ36VDu4bfPH23jwb1NYL7cLfcTaMyo3qzRRWPX78uLHoQAyOUmQR KdXBnZbAMgFM7TjNDIImgdG0i//8O/RByqBJCp6QeLD0rv+NaW1nnMa2wz9jYs8ovoV40MxW+q3a ItUo5bLz5w5oqCWFqPF5A3TBRmS9NqAx4iLB5zEn6804IGGOUsBJlgbqdKh77eMKuyk40RdfZa6u rnKJK3mJ/nYyFgoO5gNgy2A+gtbMOs+HSbErDTtYkHfSjPwuiZIrVPz3M4RYvRKlC0FioPi8hOtj SnkR+FXya9joLuyvlbVmV8alEskSK0IM6HJzMqGQQcIkFTfFUB2I5+ZAdDqkKhTxwtrF2W4ubUHq SrKJvWatHeftArLS6NYcX5y1BgoNRpZgDIcC85KlkTPfK/SikAXcSvF1dcqOdkYaUEjxtFiMDnQB SsvLRF2UMe6OgXqQVKsf3+7WVnH3+vkKW3VjWygNWVw4Hi30yjANUye5kJL+bNylbVtkmVpTy0yT LTkFKQ/nEd51GWRQp2HK0TxI4C9Rp/zKnkxxqwCRy8J23ZgnSSmaSsRC+1CvXPXp3jPNtckPJpNK BRbxePHMfGqZSy0dE190Onw809XltqdZm2mt6qfpCjZq5h52PVRoRuKoXIBvJzDiPKTQGn7gLhlv 4/T10Qng7/T1C3hz8upxAy59JLnkEPNJdFH9XwW7jMR4p3/02krmHqPYDh2fBEBeMKu5SZKMIDOb eRiD4RBMMuFy7Or+lA+VXbmzqsr1RZqeRWKKTQ+dskhISEhISEhISEhISEhISEhISEhISEhISEhI SEhISEhISEhISEhI/O/xB9ZNjagAUAAA ------_=_NextPart_001_01C2EF43.5F84E096 Content-Type: text/plain; name="KDB_testcases.txt" Content-Transfer-Encoding: base64 Content-Description: KDB_testcases.txt Content-Disposition: attachment; filename="KDB_testcases.txt" KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KKgkJS0RCIGJhc2ljIHRlc3QgY2FzZXMNCioNCioJCXZlcnNp b24gMC41DQoqDQoqCQlTb25pYyBaaGFuZyAoc29uaWMuemhhbmdAaW50ZWwuY29tKQ0KKg0KKgkJ MDIvMTQvMjAwMg0KKg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KQ2FzZSAwMDE6DQpLREIgY29tZXMgdXAgYXQga2VybmVsIGJvb3Qgd2l0aCAia2RiPWVhcmx5 IiAJDQoNClN0ZXBzOg0KMS4gQWRkIGFwcGVuZD0ia2RiPWVhcmx5IiBpbiB0aGUgbGlsby5jb25m CQ0KMi4gUmVib290IHRoZSBPUy4NCg0KRXhwZWN0ZWQgUmVzdWx0Og0KRW50ZXIgS0RCIHdoZW4g a2VybmVsIHN0YXJ0cyB1cC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNhc2UgMDAyOg0KRW5h YmxlL2Rpc2FibGUgS0RCIGJ5ICIvcHJvYy9zeXMva2VybmVsL2tkYiINCg0KU3RlcHM6DQoxLiBl Y2hvICIxfDAiID4gL3Byb2Mvc3lzL2tlcm5lbC9rZGInIA0KMi4gS2V5ZG93biAiUGF1c2UiIGFm dGVyIGVjaG8gdGhlIHBhcmFtZXRlci4JDQoNCkV4cGVjdGVkIFJlc3VsdDoNCkVudGVyIEtEQiBh ZnRlciBlY2hvICIxIiwgbm8gcmVzcG9uc2UgYWZ0ZXIgZWNobyAiMCIuDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpDYXNlIDAwMzoNCk9wZXJhdGUgaW4gS0RCIHZpYSBzZXJpYWwgY29uc29sZSBw b3J0DQoNClN0ZXBzOg0KMS4gQWRkICdzZXJpYWwgPSAwLDk2MDBuOCcgaW4gZmlsZSAvZXRjL2xp bG8uY29uZg0KMi4gQWRkICdhcHBlbmQ9ImNvbnNvbGU9dHR5UzAsOTYwMCInIGluIGZpbGUgL2V0 Yy9saWxvLmNvbmYNCjMuIEFkZCAnUzE6MjM6cmVzcGF3bjovc2Jpbi9nZXR0eSAtTCB0dHlTMSA5 NjAwIHZ0MTAwJyBpbiBmaWxlIC9ldGMvaW5pdHRhYg0KNC4gQ29ubmVjdCB0aGUgc2VyaWFsIHBv cnQgdG8gdGhlIG90aGVyIGNvbXB1dGVyIHZpYSBhIHNlcmlhbCBjYWJsZS4NCjUuIFJ1biBhIHRl cm1pbmF0ZSB0b29sIG9uIHRoZSBvdGhlciBjb21wdXRlciBhbmQgc3RhcnQgdGhlIGNvbm5lY3Rp b24uDQo2LiByZWJvb3QgdGhlIGNvbXB1dGVyIHdpdGggS0RCDQo3LiBFbnRlciBLREIgYnkgIkN0 cmwtQSIgb24gdGhlIGNvbnNvbGUgb2YgdGhlIHRlcm1pbmF0ZSB0b29sLg0KOC4gUnVuIHNvbWUg S0RCIGNvbW1hbmRzLg0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpFbnRlciBLREIgc3VjY2Vzc2Z1bGx5 IHZpYSB0aGUgc2VyaWFsIHBvcnQuIA0KQ2FuIHJ1biBLREIgY29tbWFuZHMgdmlhIHRoZSBzZXJp YWwgcG9ydC4NCkNvcnJlY3QgcmVzdWx0cyB3aWxsIGJlIGRpc3BsYXllZC4NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkNhc2UgMDA0Og0KS0RCIGNvbWVzIHVwIHRocm91Z2ggS2V5Ym9hcmQuDQoN ClN0ZXBzOg0KMS4gQWN0aXZhdGUgS0RCLg0KMi4gS2V5ZG93biAiUGF1c2UiLg0KMy4gUnVuIGNv bW1hbmQgImdvIiB0byByZXR1cm4gdG8gY29uc29sZS4NCg0KRXhwZWN0ZWQgUmVzdWx0Og0KRW50 ZXIgS0RCLCByZXR1cm4gdG8gY29uc29sZSBhZnRlciBleGl0aW5nIEtEQi4NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkNhc2UgMDA1Og0KS0RCIGNvbWVzIHVwIGJlZm9yZSBrZXJuZWwgcGFuaWMu DQoNClN0ZXBzOg0KMS4gQ29tcGlsZSB0ZXN0IG1vZHVsZSBjcmFzaC5jLg0KMi4gQWN0aXZhdGUg S0RCLg0KMy4gSW5zZXJ0ICJjcmFzaC5vIiBtb2R1bGUgaW50byB0aGUga2VybmVsLCB3aGljaCBi cmluZ3MgdGhlIE9TIGludG8gcGFuaWMuDQo0LiBSdW4gY29tbWFuZCAiZ28iIHRvIHJldHVybiB0 byBrZXJuZWwgcGFuaWMuDQoNCkV4cGVjdGVkIFJlc3VsdDoNCkVudGVyIEtEQiwgcmV0dXJuIHRv IGtlcm5lbCBwYW5pYyBhZnRlciBleGl0aW5nIEtEQi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkNhc2UgMDA2Og0KS0RCIGNvbWVzIHVwIGJlZm9yZSBrZXJuZWwgZHVtcC4NCg0KU3RlcHM6DQox LiBUdXJuIG9uL29mZiB0aGUgRHVtcCBvcHRpb24gKGluIHRoZSAvZXRjL3N5c2NvbmZpZy92bWR1 bXApLg0KMi4gQ29tcGlsZSB0ZXN0IG1vZHVsZSAiY3Jhc2guYyIuDQozLiBBY3RpdmF0ZSBLREIu DQo0LiBJbnNlcnQgImNyYXNoLm8iIG1vZHVsZSBpbnRvIHRoZSBrZXJuZWwsIHdoaWNoIHdpbGwg Y2F1c2Uga2VybmVsIGR1bXAuDQo1LiBSdW4gY29tbWFuZCAiZ28iIHRvIHJldHVybiB0byBrZXJu ZWwgZHVtcC4JDQogDQpFeHBlY3RlZCBSZXN1bHQ6DQpFbnRlciBLREIgYmVmb3JlIGtlcm5lbCBk dW1wLCB0aGVuIHJldHVybiB0byBrZXJuZWwgZHVtcCBhZnRlciBleGl0aW5nIEtEQi4NCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkNhc2UgMDA3Og0KQ29tbWFuZCBkaXNwbGF5IGJyZWFrcG9pbnQg IChibCkJCQ0KDQpTdGVwczogKFNhbXBsZSkNCjEuIGJwIHByaW50aw0KMi4gYnBoIHNjaGVkDQoz LiBibA0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpTaG93IGFsbCBicmVha3BvaW50cy4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkNhc2UgMDA4Og0KQ29tbWFuZCBlbmFibGUgYnJlYWtwb2ludCAgKGJl KQkJDQoNClN0ZXBzOiAoU2FtcGxlKQ0KMS4gYnAgcHJpbnRrDQoyLiBiZCAwDQozLiBibA0KNC4g YmUgMA0KNS4gYmwNCjYuIGJkICoNCjcuIGJsDQo4LiBiZSAqDQo5LiBibA0KDQpFeHBlY3RlZCBS ZXN1bHQ6DQpUaGUgc3BlY2lmaWVkIGJyZWFrcG9pbnQgaXMgYWN0aXZhdGVkLg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KQ2FzZSAwMDk6DQpDb21tYW5kIGRpc2FibGUgYnJlYWtwb2ludCAoYmQp CQkNCg0KU3RlcHM6IChTYW1wbGUpDQoxLiBicCBwcmludGsNCjIuIGJlIDANCjMuIGJsDQo0LiBi ZCAwDQo1LiBibA0KNi4gYmUgKg0KNy4gYmwNCjguIGJkICoNCjkuIGJsDQoNCkV4cGVjdGVkIFJl c3VsdDoNClRoZSBzcGVjaWZpZWQgYnJlYWtwb2ludCBpcyBkZWFjdGl2YXRlZC4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkNhc2UgMDEwOg0KQ29tbWFuZCBjbGVhciBicmVha3BvaW50ICAgICAg KGJjKQkJDQoNClN0ZXBzOiAoU2FtcGxlKQ0KMS4gYnAgcHJpbnRrDQoyLiBicCBzY2hlZA0KMy4g YmwNCjQuIGJjIDANCjUuIGJsDQo2LiBicCBwcmludGsNCjcuIGJsDQo4LiBiYyAqDQo5LiBibA0K DQpFeHBlY3RlZCBSZXN1bHQ6DQpSZW1vdmUgc3BlY2lmaWVkIGJyZWFrcG9pbnRzLg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KQ2FzZSAwMTE6DQpDb21tYW5kIHNldCBvciBkaXNwbGF5IGJyZWFr cG9pbnQgKGJwKSAJDQoNClN0ZXBzOiANCihTYW1wbGUgMSkNCjEuIEVudGVyIEtEQiBtb2RlLiAg DQoyLiBicFtoXVthXSBwcmludGtbKzB4MjBdICANCjMuIGdvICAgICAgIA0KNC4gaW5zbW9kIHRl c3RrZGIubyAgDQoNCihTYW1wbGUgMikNCjEuIEVudGVyIEtEQiBtb2RlICANCjIuIGJwaFthXSB0 ZXN0a2RiYnBoIChkYXRhcnxkYXRhd3xpbykgWzR8MnwxXQ0KMy4gZ28gIA0KNC4gcm1tb2QgdGVz dGtkYiAgDQoNCkV4cGVjdGVkIFJlc3VsdDoNCklmIGluc3RydWN0aW9uIHBvaW50ZXIgZXF1YWxz IHRoZSBicmVhayBwb2ludCBhZGRyZXNzIG9yDQp0aGlzIGFkZHJlc3MgaXMgcmVhZCBvciB3cml0 dGVuLCBzeXN0ZW0gdHJhcHMgaW50byBLREIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNl IDAxMjoNCkNvbW1hbmQgc2V0IG9yIGRpc3BsYXkgZ2xvYmFsIGJyZWFrcG9pbnQgKGJwYSkJCQ0K UmVmZXIgdG8gY29tbWFuZCBicC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNhc2UgMDEzOg0K Q29tbWFuZCBzZXQgb3IgZGlzcGxheSBoYXJkd2FyZSBicmVha3BvaW50IChicGgpCQkNClJlZmVy IHRvIGNvbW1hbmQgYnAuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAxNDoNCkNvbW1h bmQgc2V0IG9yIGRpc3BsYXkgZ2xvYmFsIGhhcmR3YXJlIGJyZWFrcG9pbnQgKGJwaGEpCQkNClJl ZmVyIHRvIGNvbW1hbmQgYnAuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAxNToNCkNv bW1hbmQgc3RhY2sgYmFjayB0cmFjZSAoYnQpCQ0KDQpTdGVwczogKFNhbXBsZSkNCjEuIENvbXBp bGUgdGVzdCBtb2R1bGUgInRlc3RrZGIuYyIuDQoyLiBJbnNlcnQgdGVzdCBtb2R1bGUgInRlc3Rr ZGIubyIgaW50byB0aGUga2VybmVsLg0KMy4gRW50ZXIgdGhlIEtEQiBhbmQgc2V0IGEgYnJlYWtw b2ludCBhdCBmdW5jdGlvbiBmMygpLiAgDQoNCmtkYj4gaWQgZjMNCjB4ZDA4NWIwNjAgZjNtb3Yg ICAgMHhkMDg1YjIxYywlZWF4DQoweGQwODViMDY1IGYzKzB4NXB1c2ggICAlZWJwDQoweGQwODVi MDY2IGYzKzB4NnRlc3QgICAlZWF4LCVlYXgNCjB4ZDA4NWIwNjggZjMrMHg4bW92ICAgICVlc3As JWVicA0KMHhkMDg1YjA2YSBmMysweGFqbGUgICAgDQoweGQwODViMDdjIGYzKzB4MWMNCjB4ZDA4 NWIwNmMgZjMrMHhjZGVjICAgICVlYXgNCjB4ZDA4NWIwNmQgZjMrMHhkbW92ICAgICVlYXgsMHhk MDg1YjIxYw0KMHhkMDg1YjA3MiBmMysweDEyY2FsbCAgIDB4ZDA4NWIwNjAgZjMNCjB4ZDA4NWIw NzcgZjMrMHgxN2ptcCAgICAweGQwODViMDdmIGYzKzB4MWYNCjB4ZDA4NWIwNzkgZjMrMHgxOWxl YSAgICAweDAoJWVzaSksJWVzaQ0KMHhkMDg1YjA3YyBmMysweDFjbm9wDQoweGQwODViMDdkIGYz KzB4MWRub3ANCjB4ZDA4NWIwN2UgZjMrMHgxZW5vcA0KMHhkMDg1YjA3ZiBmMysweDFmeG9yICAg ICVlYXgsJWVheA0KMHhkMDg1YjA4MSBmMysweDIxcG9wICAgICVlYnANCjB4ZDA4NWIwODIgZjMr MHgyMnJldA0Ka2RiPiBicCAweGQwODViMDdlDQpJbnN0cnVjdGlvbihpKSBCUCAjMSBhdCAweGQw ODViMDdlIChbdGVzdGtkYl1mMysweDFlKSBpcyBlbmFibGVkIGdsb2JhbGx5IGFkanVzdCAxDQpr ZGI+IGdvDQoNCjQuIFJlbW92ZSB0aGUgbW9kdWxlIGZyb20gdGhlIGtlcm5lbC4gVGhhdCB3aWxs IHJlc3VsdCBpbiBhIGJyZWFrcG9pbnQuDQo1LiBOb3cgd2UgY2FuIHRlc3QgdGhlIGJ0IGNvbW1h bmQuDQpFbnRlcmluZyBLREIgKGN1cnJlbnQ9MHhjNmIxNDAwMCwgcGlkIDEzNDIpIGR1ZSB0byBC cmVha3BvaW50IEAgMHhkMDg1YjA3ZA0Ka2RiPiBidCAlZXNwCQ0KDQpFeHBlY3RlZCBSZXN1bHQ6 DQpEaXNwbGF5IGNhbGwgc3RhY2sgZGV0YWlsIGluZm9ybWF0aW9uLg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KQ2FzZSAwMTY6DQpDb21tYW5kIHN0YWNrIGJhY2t0cmFjZSBmb3IgcHJvY2VzcyAo YnRwKQkNCg0KU3RlcHM6IChTYW1wbGUpDQprZGI+IHBzDQpUYXNrIEFkZHIgIFBpZCAgICAgIFBh cmVudCAgIFsqXSBjcHUgIFN0YXRlIFRocmVhZCAgICAgQ29tbWFuZA0KMHhjMTRmZTAwMCAwMDAw MDAwMSAwMDAwMDAwMCAgMCAgMDAwICBzdG9wICAweGMxNGZlMjYwIGluaXQNCjB4YzE0ZjAwMDAg MDAwMDAwMDIgMDAwMDAwMDEgIDAgIDAwMCAgc3RvcCAgMHhjMTRmMDI2MCBrZXZlbnRkDQoweGMx NGVjMDAwIDAwMDAwMDAzIDAwMDAwMDAxICAwICAwMDAgIHN0b3AgIDB4YzE0ZWMyNjAga2FwbS1p ZGxlZA0KLi4uDQprZGI+IGJ0cCAxCQ0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpEaXNwbGF5IGNhbGwg c3RhY2sgZGV0YWlsIGluZm9ybWF0aW9uIG9mIGEgc3BlY2lmaWVkIHByb2Nlc3MuDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAxNzoNCkNvbW1hbmQgc3RhY2sgYmFja3RyYWNlIGZvciBh bGwgcHJvY2Vzc2VzIChidGEpCQkNCg0KU3RlcHM6IChTYW1wbGUpDQprZGI+IHBzDQpUYXNrIEFk ZHIgIFBpZCAgICAgIFBhcmVudCAgIFsqXSBjcHUgIFN0YXRlIFRocmVhZCAgICAgQ29tbWFuZA0K MHhjMTRmZTAwMCAwMDAwMDAwMSAwMDAwMDAwMCAgMCAgMDAwICBzdG9wICAweGMxNGZlMjYwIGlu aXQNCjB4YzE0ZjAwMDAgMDAwMDAwMDIgMDAwMDAwMDEgIDAgIDAwMCAgc3RvcCAgMHhjMTRmMDI2 MCBrZXZlbnRkDQoweGMxNGVjMDAwIDAwMDAwMDAzIDAwMDAwMDAxICAwICAwMDAgIHN0b3AgIDB4 YzE0ZWMyNjAga2FwbS1pZGxlZA0KLi4uDQprZGI+IGJ0YQ0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpE aXNwbGF5IGNhbGwgc3RhY2sgZGV0YWlsIGluZm9ybWF0aW9uIG9mIGFsbCBwcm9jZXNzZXMuDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAxODoNCkNvbW1hbmQgZGlzcGxheSBhbmQgc3dp dGNoIENQVXMgKGNwdSkJCQ0KDQpTdGVwczogKFNhbXBsZSkNCjEuIEVudGVyIEtEQg0KMi4gY3B1 DQozLiBjcHUgMQ0KNC4gZ28NCjUuIEVudGVyIEtEQiBhZ2Fpbg0KNi4gY3B1DQo3LiBjcHUgMA0K OC4gZ28NCjkuIEVudGVyIEtEQiBhZ2Fpbg0KMTAuIGNwdQ0KMTEuIGNwdSAxMjMgKDEyMyBpcyBh IGludmFsaWQgQ1BVIElEKQ0KMTIuIGNwdQ0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpMaXN0IGFsbCBh dmFpbGFibGUgQ1BVcyB3aXRoIG5vIHBhcmFtZXRlcnMgb3Igc3dpdGNoIHRvIHRoZSBzcGVjaWZp ZWQgQ1BVLiANCklmIHRoZSBnaXZlbiBDUFUgaWQgaXMgaW52YWxpZCwgc2hvdyBlcnJvciBpbmZv cm1hdGlvbi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNhc2UgMDE5Og0KQ29tbWFuZCBkaXNw bGF5IHN5c3RlbSBtZXNzYWdlIChkbWVzZykJCQ0KDQpTdGVwczogKFNhbXBsZSkNCjEuIGRtZXNn DQoyLiBkbWVzZyA1DQoNCkV4cGVjdGVkIFJlc3VsdDoNCkRpc3BsYXkgbGFzdCBzZXQgb2Ygc3lz dGVtIG1lc3NhZ2UgZnJvbSB0aGUga2VybmVsIGJ1ZmZlci4NCklmIGxpbmVzIGlzIHNwZWNpZmll ZCwgb25seSBkdW1wIHRoZSBsYXN0IGxpbmVzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2Fz ZSAwMjA6DQpDb21tYW5kIGRlZmluZSAgc3lzdGVtIG1lc3NhZ2UgKGRlZmNtZCkJCQ0KDQpTdGVw czogKFNhbXBsZSkNCjEuIGRlZmNtZCBkaWFnICIiICJTdGFuZGFyZCBkaWFnbm9zdGljcyINCjIu IHNldCBMSU5FUyAyMDANCjMuIGNwdQ0KNC4gcHMNCjUuIGRtZXNnDQo2LiBlbmRlZmNtZA0KNy4g ZGlhZw0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpEZWZpbmVzIGEgbmV3IGNvbW1hbmQgYXMgYSBzZXQg b2Ygb3RoZXIgY29tbWFuZHMuDQpBbGwgaW5wdXQgdW50aWwgZW5kZWZjbWQgaXMgc2F2ZWQgYW5k IGV4ZWN1dGVkIGFzIGEgbmV3IGNvbW1hbmQuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2Fz ZSAwMjE6DQpDb21tYW5kIHByaW50IGV4Y2VwdGlvbiBmcmFtZSAoZWYpCQ0KDQpTdGVwczogKFNh bXBsZSkNCjEuIEhlcmUgd2UgY2hvb3NlIHRoZSBkaXZpZGVfemVybyBleGNlcHRpb24gYXMgYW4g ZXhhbXBsZS4NCjIuIEFmdGVyIGVudGVyIHRoZSBLREIsIGFkZCBicmVha3BvaW50IGF0IGRvX2Rp dmlkZV9lcnJvci4NCg0Ka2RiPiBicCBkb19kaXZpZGVfZXJyb3INCmtkYj4gZ28NCg0KMy4gUnVu IHRoZSBwcm9ncmFtICJkaXZpZGV6ZXJvIiwgd2hpY2ggdHJhcHMgaW50byBhIGRpdmlkZV96ZXJv IGV4Y2VwdGlvbi4gDQo0LiBUaGUgc3lzdGVtIGVudGVycyBLREIgYWdhaW4gYW5kIHN0b3AgYXQg dGhlIGJyZWFrcG9pbnQuIA0KNS4gd2UgZHVtcCB0aGUgc3RhY2ssIHRoZSBmaXJzdCBkd29yZCBp cyB0aGUgcmV0dXJuIGFkZHJlc3MsIHRoZSBzZWNvbmQgDQpvbmUgaXMgdGhlIGV4Y2VwdGlvbiBm cmFtZSBhZGRyZXNzLg0Ka2RiPiByZA0KZWF4ID0gMHhmZmZmZmZmZiBlYnggPSAweGNlMDQ0MDAw IGVjeCA9IDB4MDAwMDAwMmIgZWR4ID0gMHgwMDAwMDAxOA0KZXNpID0gMHgwMDAwMDAwMCBlZGkg PSAweGMwMTA5ODkwIGVzcCA9IDB4Y2UwNDVmYjggZWlwID0gMHhjMDEwOTg5MA0KLi4uDQprZGI+ IG1kICVlc3ANCjB4Y2UwNDVmYjggYzAxMDkyYTggY2UwNDVmYzQgMDAwMDAwMDAgNDAxNTE5ZTQg IKGnLi6opD9fLj8uLi4uPy4uQA0KMHhjZTA0NWZkOCBiZmZmZmEzOCAwMDAwMDAwMSBiZmZmMDAy YiAwMDAwMDAyYiAgOKiyPz8uLi4uKy4gPysuLi4/DQoweGNlMDQ1ZmU4IGZmZmZmZmZmIDA4MDQ4 NDRlIDAwMDAwMDIzIDAwMDEwMjkyICAgICAgTi4uLiMuLi4uLi4uDQouLi4NCmtkYj4gZWYgMHhj ZTA0NWZjNA0KZWF4ID0gMHgwMDAwMDAwMSBlYnggPSAweDQwMTUxOWU0IGVjeCA9IDB4YmZmZmZh MzAgZWR4ID0gMHgwMDAwMDAwMA0KZXNpID0gMHg0MDAxNmI2NCBlZGkgPSAweGJmZmZmYWFjIGVz cCA9IDB4YmZmZmZhMmMgZWlwID0gMHgwODA0ODQ0ZQ0KZWJwID0gMHhiZmZmZmEzOCB4c3MgPSAw eDAwMDAwMDJiIHhjcyA9IDB4MDAwMDAwMjMgZWZsYWdzID0gMHgwMDAxMDI5Mg0KeGRzID0gMHhi ZmZmMDAyYiB4ZXMgPSAweDAwMDAwMDJiIG9yaWdlYXggPSAweGZmZmZmZmZmICZyZWdzID0gMHhj ZTA0NWZjNA0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpQcmludCBleGNlcHRpb24gZnJhbWUgb24gdGhl IHNjcmVlbiwgYWZ0ZXIgdHJhcCBpbnRvIGFuIGV4Y2VwdGlvaW4uDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpDYXNlIDAyMjoNCkNvbW1hbmQgc2hvdyBlbnZpcm9ubWVudCAoZW52KQkJDQoNClN0 ZXBzOiAoU2FtcGxlKQ0KMS4gZW52DQoNCkV4cGVjdGVkIFJlc3VsdDoNClNob3cgZW52aXJvbm1l bnQgcGFyYW1ldGVycyBvbiB0aGUgc2NyZWVuLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2Fz ZSAwMjM6DQpDb21tYW5kIHJlc3RhcnQgZXhlY3V0aW9uIChnbykJCQ0KDQpTdGVwczogKFNhbXBs ZSkNCjEuIGJwIHByaW50aw0KMi4gZ28NCg0KRXhwZWN0ZWQgUmVzdWx0Og0KUmVzdGFydCBleGVj dXRpb24uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAyNDoNCkNvbW1hbmQgaGVscCAo aGVscC8/KQkJDQoNClN0ZXBzOiAoU2FtcGxlKQ0KMS4gaGVscA0KMi4gPw0KDQpFeHBlY3RlZCBS ZXN1bHQ6DQpEaXNwbGF5IGhlbHAgbWVzc2FnZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNh c2UgMDI1Og0KQ29tbWFuZCBkaXNhc3NlbWJsZSBpbnN0cnVjdGlvbnMgKGlkKQkJDQoNClN0ZXBz OiAoU2FtcGxlKQ0KaWQgcHJpbnRrDQoNCkV4cGVjdGVkIFJlc3VsdDoNCkRpc2Fzc2VtYmxlIGlu c3RydWN0aW9ucyBmcm9tIHNwZWNpZmllZCBhZGRyZXNzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KQ2FzZSAwMjY6DQpDb21tYW5kIGZvbGxvdyBsaW5rZWQgbGlzdHMgKGxsKQkNCg0KU3RlcHM6 IChTYW1wbGUpDQpJbiB0aGUgInRlc3RrZGIubyIgbW9kdWxlLCB3ZSBkZWZpbmUgYSBzaW1wbGUg bGluayBsaXN0IHR5cGUgbXlvd25saXN0dHlwZSANCmFuZCB1c2UgaXQgdG8gdGVzdCB0aGUgbGwg Y29tbWFuZC4NCjEuIEluc2VydCB0ZXN0IG1vZHVsZSAidGVzdGtkYi5vIiBpbnRvIHRoZSBrZXJu ZWwuDQoyLiBFbnRlciBLREIuDQozLiBsbCBteW93bmxpc3QgNTE2IG1kDQpOdW1iZXIgNTE2IGlz IHRoZSBvZmZzZXQgb2YgcG9pbnRlciBwbmV4dCBpbiBzdHJ1Y3QgbXlvd25saXN0dHlwZS4JDQoN CkV4cGVjdGVkIFJlc3VsdDoNCkRpc3BsYXkgYWxsIGl0ZW1zIGluIGEgbGlua2VkIGxpc3QgaW4g bWVtb3J5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2FzZSAwMjc6DQpDb21tYW5kIGxpc3Qg bG9hZGVkIG1vZHVsZXMgKGxzbW9kKQkJDQoNClN0ZXBzOiAoU2FtcGxlKQ0KbHNtb2QNCg0KRXhw ZWN0ZWQgUmVzdWx0Og0KRGlzcGxheSBpbmZvcm1hdGlvbiBvZiBhbGwgbG9hZGVkIG1vZHVsZXMu DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAyODoNCkNvbW1hbmQgZGlzcGxheSBtZW1v cnkgY29udGVudHMgKG1kKQkNCg0KU3RlcHM6IChTYW1wbGUpDQpJbnNtb2QgdGVzdCBtb2R1bGUg InRlc3RrZGIubyIgaW50byB0aGUga2VybmVsLg0KRW50ZXJpbmcgS0RCLg0KDQprZGI+IHNlY3Rp b25zDQp0ZXN0a2RiIC50ZXh0IDB4ZDA4NWIwNjAgMHhkMDg1YjFhNCAweDYgDQoucm9kYXRhIDB4 ZDA4NWIxYTQgMHhkMDg1YjIwOCAweDIgDQouZGF0YTB4ZDA4NWIyMDggMHhkMDg1YjIyMCAweDMg DQouYnNzIDB4ZDA4NWIzMjAgMHhkMDg1YmI0OCAweDMgDQoudGhpcyAweGQwODViMDAwIDB4ZDA4 NWIwNjAgMHgzIA0KLmtzdHJ0YWIgMHhkMDg1YjIyMCAweGQwODViMzAxIDB4MyANCi4uLi4uLg0K a2RiPiBtZFsyYzVdIC5yb2RhdGEgWzRdDQprZGI+IG1kWzJjNV0gMHhkMDg1YjFhNA0Ka2RiPiBt ZFsyYzVdIC5yb2RhdGErOA0Ka2RiPiBtZFsyYzVdICVlYXgNCmtkYj4gc2V0IERBVEFIRUFEPTB4 ZDA4NWIxYTQNCmtkYj4gbWRbMmM1XSAlREFUQUhFQUQNCmtkYj4gbWRbMmM1XQ0KDQpFeHBlY3Rl ZCBSZXN1bHQ6DQpEaXNwbGF5IGNvbnRlbnQgb2YgbWVtb3J5IGZyb20gc3BlY2lmaWVkIGFkZHJl c3MuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAyOToNCkNvbW1hbmQgZGlzcGxheSBt ZW1vcnkgY29udGVudHMgd2l0aCB3aWR0aCBhbmQgY291bnQgKG1kV2NOKQkNClJlZmVyIHRvIGNv bW1hbmQgbWQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNhc2UgMDMwOg0KQ29tbWFuZCBkaXNw bGF5IHJhdyBtZW1vcnkgY29udGVudHMgKG1kcikJDQoNCkluc21vZCB0ZXN0IG1vZHVsZSAidGVz dGtkYi5vIiBpbnRvIHRoZSBrZXJuZWwuDQpFbnRlcmluZyBLREIuDQoNClN0ZXBzOiAoU2FtcGxl KQ0Ka2RiPiBzZWN0aW9ucw0KdGVzdGtkYiAudGV4dCAweGQwODViMDYwIDB4ZDA4NWIxYTQgMHg2 IA0KLnJvZGF0YSAweGQwODViMWE0IDB4ZDA4NWIyMDggMHgyIA0KLmRhdGEweGQwODViMjA4IDB4 ZDA4NWIyMjAgMHgzIA0KLmJzcyAweGQwODViMzIwIDB4ZDA4NWJiNDggMHgzIA0KLnRoaXMgMHhk MDg1YjAwMCAweGQwODViMDYwIDB4MyANCi5rc3RydGFiIDB4ZDA4NWIyMjAgMHhkMDg1YjMwMSAw eDMgDQouLi4uLi4NCmtkYj4gbWRyIC5yb2RhdGEgNA0KNTQ2ODY5NzMJDQoNCkV4cGVjdGVkIFJl c3VsdDoNCkRpc3BsYXkgdGhlIHJhdyBjb250ZW50cyBvZiBtZW1vcnkgZnJvbSBzcGVjaWZpZWQg YWRkcmVzcw0KZm9yIHNwZWNpZmllZCBudW1iZXIgb2YgYnl0ZXMuDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpDYXNlIDAzMToNCkNvbW1hbmQgZGlzcGxheSBtZW1vcnkgY29udGVudHMgc3ltYm9s aWNhbGx5IChtZHMpCQ0KUmVmZXIgdG8gY29tbWFuZCBtZA0KDQpTdGVwczogKFNhbXBsZSkNCklu c21vZCB0ZXN0IG1vZHVsZSAidGVzdGtkYi5vIiBpbnRvIHRoZSBrZXJuZWwuDQpFbnRlcmluZyBL REIuDQoNCmtkYj4gbWRzIHRlc3RrZGJtc2cNCjB4ZDA4NzkyMTggZDA4NzkxZGEgW3Rlc3RrZGJd LnJvZGF0YSsweDM2ICAgICAgICAgICAgICAgDQogICAgICAgICAgIHRlc3RrZGIgLnJvZGF0YSAw eGQwODc5MWE0IA0KMHhkMDg3OTFhNCAweGQwODc5MjA4DQoweGQwODc5MjFjIDAwMDAwMDAwICAN Ci4uLi4NCjB4ZDA4NzkyMjAgNzQ3MzY1NzQgIHRlc3QNCjB4ZDA4NzkyMjQgMDA2MjY0NmIgIGtk Yi4JDQoNCkV4cGVjdGVkIFJlc3VsdDoNCkRpc3BsYXkgdGhlIGNvbnRlbnRzIG9mIG1lbW9yeS4g T25lIHdvcmQgcGVyIGxpbmUgYW5kIHJlbGF0ZSBlYWNoIHdvcmQgDQp3aXRoIGEgc3ltYm9sIGlu IHRoZSBzeW1ib2wgdGFibGUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAzMjoNCkNv bW1hbmQgbW9kaWZ5IG1lbW9yeSBjb250ZW50cywgd29yZHMgKG1tKQkNCg0KU3RlcHM6IChTYW1w bGUpDQpJbnNtb2QgdGVzdCBtb2R1bGUgInRlc3RrZGIubyIgaW50byB0aGUga2VybmVsLg0KRW50 ZXJpbmcgS0RCLg0KDQprZGI+IG1kIHRlc3RrZGJtc2cNCjB4ZDA4NzkyMTggZDA4NzkxZGEgMDAw MDAwMDAgNzQ3MzY1NzQgMDA2MjY0NmIgIKiyLi5ELi4uLnRlc3RrZGIuDQoweGQwODc5MjI4IDZl Njk1ZjVmIDY0NmY2ZDczIDczNjU3NDVmIDYyNjQ2Yjc0ICBfX2luc21vZF90ZXN0a2RiDQouLi4N CmtkYj4gbWQgMHhkMDg3OTFkYQ0KMHhkMDg3OTFkOCA2ODc0MDA2NSA2OTIwNzM2OSA2ODc0MjA3 MyA3MzZkMjA2NSAgZS50aGlzIGlzIHRoZSBtcw0KMHhkMDg3OTFlOCAyMTIxMjE2NyAwYTczMjUw MCAwMDczMjUwMCA3MzY5Njg1NCAgZyEhIS4lcy4uJXMuVGhpcw0KMHhkMDg3OTFmOCAyMDczNjky MCAyMDY1Njg3NCA2ZTYxNzI2MiAwMDBhNjg2MyAgIGlzIHRoZSBicmFuY2guLg0KLi4uDQprZGI+ IG1tIDB4ZDA4NzkxZGEgMHg1MzQ5NDg1NA0KMHhkMDg3OTFkYSA9IDB4NTM0OTQ4NTQNCmtkYj4g bW0gMHhkMDg3OTFkYSs0IDB4MjA1MzQ5MjANCjB4ZDA4NzkxZGUgPSAweDIwNTM0OTIwDQprZGI+ IG1tIDB4ZDA4NzkxZGErOCAweDIwNDU0ODU0DQoweGQwODc5MWUyID0gMHgyMDQ1NDg1NA0Ka2Ri PiBtbVcgMHhkMDg3OTFkYSsxMiAweDUzNEQNCjB4ZDA4NzkxZTYgPSAweDUzNGQNCmtkYj4gbW1X IDB4ZDA4NzkxZGErMTQgMHgyMTQ3DQoweGQwODc5MWU4ID0gMHgyMTQ3DQoNCldoZW4gcmVtb3Zp bmcgdGhlIG1vZHVsZSwgeW91IHdpbGwgc2VlIHRoZSBvdXRwdXQgbXNnIA0KIlRISVMgSVMgVEhF IE1TRyEhISIgaW5zdGVhZCBvZiAidGhpcyBpcyB0aGUgbXNnISEhIg0KDQpFeHBlY3RlZCBSZXN1 bHQ6DQpUaGUgY29udGVudCBvZiB0aGUgc3BlY2lmaWVkIG1lbW9yeSBpcyByZXBsYWNlZCB3aXRo IGEgbmV3IHZhbHVlLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2FzZSAwMzM6DQpDb21tYW5k IG1vZGlmeSBtZW1vcnkgY29udGVudHMgb2YgYSBnaXZlbiB3aWR0aCAobW1XKQkNClJlZmVyIHRo ZSBjb21tYW5kIG1tDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAzNDoNCkNvbW1hbmQg ZGlzcGxheSBwcm9jZXNzIHN0YXR1cyAocHMpCQkNCg0KU3RlcHM6IChTYW1wbGUpDQpwcw0KDQpF eHBlY3RlZCBSZXN1bHQ6DQpEaXNwbGF5IGFsbCBwcm9jZXNzZXMuDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpDYXNlIDAzNToNCkNvbW1hbmQgcmVib290IHRoZSBtYWNoaW5lIChyZWJvb3QpCQkN Cg0KU3RlcHM6IChTYW1wbGUpDQpyZWJvb3QNCg0KRXhwZWN0ZWQgUmVzdWx0Og0KQ29tcHV0ZXIg cmVzdGFydHMuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDAzNjoNCkNvbW1hbmQgZGlz cGxheSByZWdpc3RlciBjb250ZW50cyAocmQpCQkNCg0KU3RlcHM6IChTYW1wbGUpDQoxLiByZCAo ZW50cnkgcG9pbnQpDQplYXggPSAweGZmZmZmZmZmIGVieCA9IDB4Y2UwNDQwMDAgZWN4ID0gMHgw MDAwMDAyYiBlZHggPSAweDAwMDAwMDE4DQplc2kgPSAweDAwMDAwMDAwIGVkaSA9IDB4YzAxMDk4 OTAgZXNwID0gMHhjZTA0NWZiOCBlaXAgPSAweGMwMTA5ODkwDQoyLiByZCBjIChlbnRyeSBwb2lu dCkNCjMuIHJkIGQgKGVudHJ5IHBvaW50KQ0KNC4gcmQgdSAobGFzdCB0aW1lIHRoZSBjdXJyZW50 IHRhc2sgZW50ZXIgdGhlIGtlcm5lbCkNCg0KRXhwZWN0ZWQgUmVzdWx0Og0KU2hvdyBhbGwgcmVn aXN0ZXIgY29udGVudHMgb24gc2NyZWVuLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2FzZSAw Mzc6DQpDb21tYW5kIG1vZGlmeSByZWdpc3RlciBjb250ZW50cyAocm0pCQkNCg0KU3RlcHM6IChT YW1wbGUpDQoxLiBybSAlZWF4IDANCjIuIHJkDQozLiBybSAlZXNpIDB4MjM0NTkxMjMNCjQuIHJk DQo1LiBybSAlZHIwIDB4MjM0NTkxMjMNCjYuIHJkIGQNCjcuIHJtICUlZWF4IDIwDQo4LiByZCB1 DQo5LiByZA0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpUaGUgY29udGVudCBvZiB0aGUgc3BlY2lmaWVk IHJlZ2lzdGVyIGlzIHJlcGxhY2VkIHdpdGggYSBuZXcgdmFsdWUuDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpDYXNlIDAzODoNCkNvbW1hbmQgcmVtb3ZlIG1vZHVsZSAocm1tb2QpDQoNClN0ZXBz OiAoU2FtcGxlKQ0KMS4gSW5zZXJ0IHRlc3QgbW9kdWxlICJ0ZXN0a2RiLm8iIGludG8gdGhlIGtl cm5lbC4NCjIuIEVudGVyIEtEQi4NCjMuIHJtbW9kIHRlc3RrZGINCjQuIGdvDQo1LiBsc21vZA0K DQpFeHBlY3RlZCBSZXN1bHQ6DQpBIG1vZHVsZSBpcyB1bmxvYWRlZC4NCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCkNhc2UgMDM5Og0KQ29tbWFuZCBsaXN0IHNlY3Rpb25zIChzZWN0aW9ucykJCQ0K DQpTdGVwczogKFNhbXBsZSkNCnNlY3Rpb25zDQoNCkV4cGVjdGVkIFJlc3VsdDoNCkxpc3QgaW5m b3JtYXRpb24gZm9yIGFsbCBrbm93biBzZWN0aW9ucy4NClRoZSBvdXRwdXQgaXMgb25lIGxpbmUg cGVyIG1vZHVsZSwgc3RhcnRpbmcgd2l0aCB0aGUgbW9kdWxlIG5hbWUuDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpDYXNlIDA0MDoNCkNvbW1hbmQgYWRkL2NoYW5nZSBlbnZpcm9ubWVudCB2YXJp YWJsZSAoc2V0KQkNCg0KU3RlcHM6IChTYW1wbGUpDQoxLiBzZXQgTElORVM9MjANCjIuIGVudg0K DQpFeHBlY3RlZCBSZXN1bHQ6DQpOZXcgdmFsdWUgaXMgc2V0IGludG8gYSBlbnZpcm9ubWVudCBw YXJhbWV0ZXIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYXNlIDA0MToNCkNvbW1hbmQgaW52 b2tlIFN5c1JlcSBjb21tYW5kIChzcikJDQoNClN0ZXBzOiAoU2FtcGxlKQ0KMS4gZWNobyAiMSIg PiAvcHJvYy9zeXMva2VybmVsL3N5c3JxDQoyLiBzciBwDQpTeXNScTogU2hvdyBSZWdzDQpFSVA6 IDAwMTA6WzxjMDEwNzI2Nj5dIENQVTogMCBFRkxBR1M6IDAwMDAwMjQ2DQpFQVg6IDAwMDAwMDAw IEVCWDogYzAxMDcyNDAgRUNYOiBjZWI0MDAwMCBFRFg6IDAwMDAwMDMyDQpFU0k6IGMwMzA0MDAw IEVESTogYzAzMDQwMDAgRUJQOiBjMDMwNWZkNCBEUzogMDAxOCBFUzogMDAxOA0KQ1IwOiA4MDA1 MDAzYiBDUjI6IDA4MGQ0YTBjIENSMzogMGViN2IwMDAgQ1I0OiAwMDAwMDZkMA0KQ2FsbCBUcmFj ZTogWzxjMDEwNzJmMj5dIFs8YzAxMDUwMDA+XSBbPGMwMTAwMTkxPl0NCg0KRXhwZWN0ZWQgUmVz dWx0Og0KRXhlY3V0ZSB0aGUgc3BlY2lmaWVkIGNvbW1hbmQgY29ycmVjdGx5Lg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KQ2FzZSAwNDI6DQpDb21tYW5kIHNpbmdsZSBzdGVwIENQVSAoc3MpCQ0K DQpTdGVwczogKFNhbXBsZSkNCjEuIEVudGVyIEtEQg0KMi4gYnAgcHJpbnRrDQozLiBnbw0KNC4g SW5zZXJ0IHRlc3QgbW9kdWxlICJ0ZXN0a2RiLm8iIGludG8gdGhlIGtlcm5lbC4NCjUuIEV4ZWN1 dGUgc3MgY29tbWFuZCBmb3IgMTAgdGltZXMuCQ0KDQpFeHBlY3RlZCBSZXN1bHQ6DQpFeGVjdXRl IGEgc2luZ2xlIGluc3RydWN0aW9uIGFuZCBlbnRlciBLREIgYWdhaW4uDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpDYXNlIDA0MzoNCkNvbW1hbmQgc2luZ2xlIHN0ZXAgQ1BVIHVudGlsIGJyYW5j aCAoc3NiKQkNCg0KU3RlcHM6IChTYW1wbGUpDQoxLiBFbnRlciBLREINCjIuIGJwIHByaW50aw0K My4gZ28NCjQuIEluc2VydCB0ZXN0IG1vZHVsZSAidGVzdGtkYi5vIiBpbnRvIHRoZSBrZXJuZWwu DQo1LiBFeGVjdXRlIHNzYiBjb21tYW5kIGZvciAxMCB0aW1lcy4JDQoNCkV4cGVjdGVkIFJlc3Vs dDoNCkV4ZWN1dGUgaW5zdHJ1Y3Rpb25zIGZyb20gY3VycmVudCBpbnN0cnVjdGlvbiBwb2ludGVy IHRvIHRoZSBmaXJzdCBicmFuY2ggDQppbnN0cnVjdGlvbiBhbmQgZW50ZXIgS0RCIGFnYWluLg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2FzZSAwNDQ6DQpDYXRjaCBpbnZhbGlkIGFkZHJlc3Mv cmVmZXJlbmNlIGNvbW1hbmRzIGNvcnJlY3RseS4NCg0KU3Rlb3BzOg0KRm9yIGV4YW1wbGUsIHRl c3QgdGhlIGVmIGNvbW1hbmQgd2l0aCBhIG5vbi1zdWl0YWJsZS4gDQprZGI+IG1kIDAweDAwMDAw MDAwIA0Ka2RiOiBCYWQgdXNlciBhZGRyZXNzIA0KMHgwa2RiPiBlZiAwDQplYXggPSBVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBOVUxMIHBvaW50ZXIgZGVyZWZlcmVuY2UgYXQgdmlydHVhbCBhZGRy ZXNzIDAwMDAwMDJjIA0KcHJpbnRpbmcgDQplaXA6YzAyMGQ5OWMNCnBnZCBlbnRyeSBjZWI3YjAw MDogMDAwMDAwMDAwMDAwMDAwMA0KcG1kIGVudHJ5IGNlYjdiMDAwOiAwMDAwMDAwMDAwMDAwMDAw Li4uIA0KcG1kIG5vdCBwcmVzZW50IQ0Ka2RiOiBEZWJ1Z2dlciByZS1lbnRlcmVkIG9uIGNwdSAw LCBuZXcgcmVhc29uID0gNSAgICAgDQpBdHRlbXB0aW5nIHRvIGFib3J0IGNvbW1hbmQgYW5kIHJl Y292ZXIJDQoNCkV4cGVjdGVkIFJlc3VsdDoNCklmIGEgS0RCIGNvbW1hbmQgYnJlYWtzIGFuZCBL REIgaGFzIGVub3VnaCBvZiBhIHJlY292ZXJ5IGVudmlyb25tZW50LA0KS0RCIHNob3VsZCBhYm9y dCB0aGUgY29tbWFuZCBhbmQgZHJvcCBiYWNrIGludG8gS0RCIGVudmlyb25tZW50Lg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0K ------_=_NextPart_001_01C2EF43.5F84E096-- From qinhua@networks.ecse.rpi.edu Fri Mar 21 13:35:10 2003 Received: with ECARTIS (v1.0.0; list kdb); Fri, 21 Mar 2003 13:35:21 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2LLZ9q9001656 for ; Fri, 21 Mar 2003 13:35:10 -0800 Received: from poisson.ecse.rpi.edu (networks.ecse.rpi.edu [128.113.50.30]) by smtp3.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h2LLZ3Q9021381 for ; Fri, 21 Mar 2003 16:35:03 -0500 Received: from localhost (qinhua@localhost) by poisson.ecse.rpi.edu (8.9.1/8.9.1) with ESMTP id QAA17819 for ; Fri, 21 Mar 2003 16:35:02 -0500 (EST) Date: Fri, 21 Mar 2003 16:35:02 -0500 (EST) From: Hua Qin To: kdb@oss.sgi.com Subject: kdb on SMP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.28 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 281 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: qinhua@networks.ecse.rpi.edu Precedence: bulk X-list: kdb Hello, I downloaded 2.4.20 kernel from kernel.org, and patch kdb-v3.0-2.4.10-common and kdb-v3.0-2.4.20-i386 into the kernel. Then, I put this kernel (compiled by gcc-.2.96) to a SMP machine. set a break point by using bp, after the machine hit the break point, I use bt and cpu commands to check the status. Then I type bc 0 to clear that break point, and go to trying to leave kdb. But I never can go out, it always hit "Oops int3 ". I think it is the problem only happen on SMP machine, because another UP (unit processor) never has this problem. Today, I try v4.0 and other two patches kdb-smphdr-v4.0, same problem happened. Doese someone has some solutions about this. Thanks! Hua From kaos@sgi.com Fri Mar 21 17:03:07 2003 Received: with ECARTIS (v1.0.0; list kdb); Fri, 21 Mar 2003 17:03:12 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2M134q9009844 for ; Fri, 21 Mar 2003 17:03:06 -0800 Received: (qmail 14236 invoked from network); 22 Mar 2003 01:03:02 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Mar 2003 01:03:02 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id C9169300087; Sat, 22 Mar 2003 12:02:59 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id C50398F; Sat, 22 Mar 2003 12:02:59 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Hua Qin Cc: kdb@oss.sgi.com Subject: Re: kdb on SMP In-reply-to: Your message of "Fri, 21 Mar 2003 16:35:02 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Mar 2003 12:02:54 +1100 Message-ID: <20839.1048294974@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 282 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Fri, 21 Mar 2003 16:35:02 -0500 (EST), Hua Qin wrote: >I downloaded 2.4.20 kernel from kernel.org, and patch >kdb-v3.0-2.4.10-common and kdb-v3.0-2.4.20-i386 into the kernel. >Then, I put this kernel (compiled by gcc-.2.96) to a SMP machine. set a >break point by using bp, >after the machine hit the break point, I use bt and cpu commands to check >the status. Then I type bc 0 to clear that break point, and go to trying >to leave kdb. But I never can go out, it always hit "Oops int3 ". I think >it is the problem only happen on SMP machine, because another UP (unit >processor) never has this problem. > >Today, I try v4.0 and other two patches kdb-smphdr-v4.0, same problem >happened. > >Doese someone has some solutions about this. Known race condition with no solution yet. man Documentation/kdb/kdb_bp.man and look for 'SMP'. From qinhua@networks.ecse.rpi.edu Sat Mar 22 06:26:32 2003 Received: with ECARTIS (v1.0.0; list kdb); Sat, 22 Mar 2003 06:26:36 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2MEPpq9024821 for ; Sat, 22 Mar 2003 06:26:31 -0800 Received: from poisson.ecse.rpi.edu (networks.ecse.rpi.edu [128.113.50.30]) by smtp2.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h2MEPin5009370; Sat, 22 Mar 2003 09:25:44 -0500 Received: from localhost (qinhua@localhost) by poisson.ecse.rpi.edu (8.9.1/8.9.1) with ESMTP id JAA18962; Sat, 22 Mar 2003 09:25:43 -0500 (EST) Date: Sat, 22 Mar 2003 09:25:43 -0500 (EST) From: Hua Qin To: Keith Owens cc: kdb@oss.sgi.com Subject: Re: kdb on SMP In-Reply-To: <20839.1048294974@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.28 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 283 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: qinhua@networks.ecse.rpi.edu Precedence: bulk X-list: kdb Thanks, Keith, I noticed that later too. So "bpa" will have the same problem? How about "bph" and "bpha", since they are using Pentium debug registers other that int3 mechanism, they don't have these problem. Thanks! Hua On Sat, 22 Mar 2003, Keith Owens wrote: > On Fri, 21 Mar 2003 16:35:02 -0500 (EST), > Hua Qin wrote: > >I downloaded 2.4.20 kernel from kernel.org, and patch > >kdb-v3.0-2.4.10-common and kdb-v3.0-2.4.20-i386 into the kernel. > >Then, I put this kernel (compiled by gcc-.2.96) to a SMP machine. set a > >break point by using bp, > >after the machine hit the break point, I use bt and cpu commands to check > >the status. Then I type bc 0 to clear that break point, and go to trying > >to leave kdb. But I never can go out, it always hit "Oops int3 ". I think > >it is the problem only happen on SMP machine, because another UP (unit > >processor) never has this problem. > > > >Today, I try v4.0 and other two patches kdb-smphdr-v4.0, same problem > >happened. > > > >Doese someone has some solutions about this. > > Known race condition with no solution yet. man Documentation/kdb/kdb_bp.man > and look for 'SMP'. > > > From kaos@sgi.com Sat Mar 22 07:30:37 2003 Received: with ECARTIS (v1.0.0; list kdb); Sat, 22 Mar 2003 07:30:42 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2MFUYq9029055 for ; Sat, 22 Mar 2003 07:30:36 -0800 Received: (qmail 2021 invoked from network); 22 Mar 2003 15:30:31 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Mar 2003 15:30:31 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 78330300087; Sun, 23 Mar 2003 02:30:27 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id ED37A8F; Sun, 23 Mar 2003 02:30:27 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Hua Qin Cc: kdb@oss.sgi.com Subject: Re: kdb on SMP In-reply-to: Your message of "Sat, 22 Mar 2003 09:25:43 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Mar 2003 02:30:22 +1100 Message-ID: <27517.1048347022@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 284 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Sat, 22 Mar 2003 09:25:43 -0500 (EST), Hua Qin wrote: >So "bpa" will have the same problem? bp and bpa are the same for software breakpoints. >How about "bph" and "bpha", since they are >using Pentium debug registers other that int3 mechanism, they don't have >these problem. bpha installs the hardware breakpoint on all cpus, bph only installs on one cpu but is not much use when you do not know which cpu you will be executing on. The current kdb code for handling two cpus dropping into kdb at the same time has races. Sonic Zhang mailed some test patches recently, see ftp://oss.sgi.com//projects/kdb/download/v4.0/kdb-smphdr*. I have not had time to try them yet. From qinhua@networks.ecse.rpi.edu Tue Mar 25 06:36:14 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 25 Mar 2003 06:36:20 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PEaDq9029491 for ; Tue, 25 Mar 2003 06:36:13 -0800 Received: from poisson.ecse.rpi.edu (networks.ecse.rpi.edu [128.113.50.30]) by smtp1.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h2PEa6Bf006876; Tue, 25 Mar 2003 09:36:06 -0500 Received: from localhost (qinhua@localhost) by poisson.ecse.rpi.edu (8.9.1/8.9.1) with ESMTP id JAA23830; Tue, 25 Mar 2003 09:36:06 -0500 (EST) Date: Tue, 25 Mar 2003 09:36:05 -0500 (EST) From: Hua Qin To: Keith Owens cc: kdb@oss.sgi.com Subject: Re: kdb on SMP In-Reply-To: <27517.1048347022@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.28 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 285 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: qinhua@networks.ecse.rpi.edu Precedence: bulk X-list: kdb Keith, I have to go back to "bp" and "bpa". You said "bp" and "bpa" are same. Meaning the current "bp" is a global breakpoint for all cpus? I did some tests, set a break point on cpu 4 by using "bp", then "go". later, when the break point were hit, it was on cpu 3. Is that correct way for "bp"? Thanks! Hua On Sun, 23 Mar 2003, Keith Owens wrote: > On Sat, 22 Mar 2003 09:25:43 -0500 (EST), > Hua Qin wrote: > >So "bpa" will have the same problem? > > bp and bpa are the same for software breakpoints. > > >How about "bph" and "bpha", since they are > >using Pentium debug registers other that int3 mechanism, they don't have > >these problem. > > bpha installs the hardware breakpoint on all cpus, bph only installs on > one cpu but is not much use when you do not know which cpu you will be > executing on. > > The current kdb code for handling two cpus dropping into kdb at the > same time has races. Sonic Zhang mailed some test patches recently, > see ftp://oss.sgi.com//projects/kdb/download/v4.0/kdb-smphdr*. I have > not had time to try them yet. > > > From kaos@sgi.com Tue Mar 25 13:03:12 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 25 Mar 2003 13:03:14 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2PL38q9017146 for ; Tue, 25 Mar 2003 13:03:10 -0800 Received: (qmail 4915 invoked from network); 25 Mar 2003 21:03:06 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 25 Mar 2003 21:03:06 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 116B4300087; Wed, 26 Mar 2003 08:03:02 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 8309A8F; Wed, 26 Mar 2003 08:03:02 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Hua Qin Cc: kdb@oss.sgi.com Subject: Re: kdb on SMP In-reply-to: Your message of "Tue, 25 Mar 2003 09:36:05 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Mar 2003 08:02:56 +1100 Message-ID: <24982.1048626176@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 286 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Tue, 25 Mar 2003 09:36:05 -0500 (EST), Hua Qin wrote: >I have to go back to "bp" and "bpa". >You said "bp" and "bpa" are same. Meaning the current "bp" is a global >breakpoint for all cpus? > >I did some tests, set a break point on cpu 4 by using "bp", then "go". >later, when the break point were hit, it was on cpu 3. > >Is that correct way for "bp"? Yes. bp uses software breakpoints, changing the code. There is only one copy of the code which can be executed on any cpu. From edie.dong@intel.com Tue Mar 25 19:50:55 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 25 Mar 2003 19:51:00 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q3oqq9013740 for ; Tue, 25 Mar 2003 19:50:55 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2Q3mnI13166 for ; Wed, 26 Mar 2003 03:48:49 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2Q3kqO26631 for ; Wed, 26 Mar 2003 03:46:53 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003032611504509559 ; Wed, 26 Mar 2003 11:50:45 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Mar 2003 11:50:45 +0800 content-class: urn:content-classes:message Subject: Backtrae before smp_init. MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 26 Mar 2003 11:50:45 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E1C5C01@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Backtrae before smp_init. Thread-Index: AcLzStxXR1cQ+neRQnyTOkCGbLHGzw== From: "Dong, Edie" To: "Keith Owens" Cc: X-OriginalArrivalTime: 26 Mar 2003 03:50:45.0523 (UTC) FILETIME=[E1716630:01C2F34A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2Q3oqq9013740 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 287 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: edie.dong@intel.com Precedence: bulk X-list: kdb Keith: It seems the KDBV4.0 backtrace will no longer function before smp_init but it is OK in KDB2.5. Do you have any special considerations? It is a good feature no matter for I386 or XScale architecture. eddie From kaos@sgi.com Tue Mar 25 20:23:30 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 25 Mar 2003 20:23:38 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q4Mnq9013987 for ; Tue, 25 Mar 2003 20:23:30 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2Q4MguY028485 for ; Tue, 25 Mar 2003 20:22:43 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02026; Wed, 26 Mar 2003 15:21:24 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 345BE300087; Wed, 26 Mar 2003 15:21:22 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 97E918F; Wed, 26 Mar 2003 15:21:22 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Dong, Edie" Cc: kdb@oss.sgi.com Subject: Re: Backtrae before smp_init. In-reply-to: Your message of "Wed, 26 Mar 2003 11:50:45 +0800." <37FBBA5F3A361C41AB7CE44558C3448E1C5C01@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Mar 2003 15:21:16 +1100 Message-ID: <31016.1048652476@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 288 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Wed, 26 Mar 2003 11:50:45 +0800, "Dong, Edie" wrote: >Keith: > It seems the KDBV4.0 backtrace will no longer function before = >smp_init but it is > OK in KDB2.5. Do you have any special considerations? It is a good = >feature no > matter for I386 or XScale architecture. Works for me, booting with kdb=early Entering kdb (current=0xe00000000470c000, pid 0) on processor 0 due to KDB_ENTER() [0]kdb> bt Stack traceback for pid 0 0xe00000000470c000 0 0 1 0 R 0xe00000000470c5d0 *swapper 0xe0020000006d1060 start_kernel+0x440 args (0xe0020000005fd4b0, 0x13, 0x1, 0x1, 0x3f0d2208) kernel .text.init 0xe0020000006d0000 0xe0020000006d0c20 0xe0020000006d1200 0xe002000000008510 start_ap+0x2f0 args (0xe0020000005fd4b0, 0x13) kernel .text 0xe002000000000000 0xe002000000008220 0xe002000000008530 [0]kdb> cpu Currently on cpu 0 Available cpus: From kaos@sgi.com Tue Mar 25 22:16:06 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 25 Mar 2003 22:16:11 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2Q6G5q9015420 for ; Tue, 25 Mar 2003 22:16:06 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2Q6Rbkq008040 for ; Wed, 26 Mar 2003 00:27:43 -0600 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02937; Wed, 26 Mar 2003 17:14:24 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 9A6D7300087; Wed, 26 Mar 2003 17:14:15 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 6AAC38F; Wed, 26 Mar 2003 17:14:15 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Dong, Edie" Cc: kdb@oss.sgi.com Subject: Re: Backtrae before smp_init. In-reply-to: Your message of "Wed, 26 Mar 2003 14:00:10 +0800." <37FBBA5F3A361C41AB7CE44558C3448E1C5C65@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Mar 2003 17:14:09 +1100 Message-ID: <31999.1048659249@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 289 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Wed, 26 Mar 2003 14:00:10 +0800, "Dong, Edie" wrote: >VGhhdCBpcyBzdHJhbmdlciwgSSBnb3QgdGhlIHByb2dyYW0gdG8gIlN0YWNrIGlzIG5vdCBpbiB0 Ugh, please use plain text. >That is stranger, I got the program to "Stack is not in task_struct, backtrace not available", >(in kdba_bt_stack), I checked the macro task_has_cpu(p) is false beacuse the initial task is >not switched yet, and the memory in &p->thread are all 0. (md &p->thread). >Any hints? You should have included that information in your original mail, instead of making us guess what error you were getting. This is a kernel bug where it incorrectly sets scheduling fields on the idle tasks. diff -ur 2.4.20-pristine/arch/i386/kernel/smpboot.c 2.4.20-sched/arch/i386/kernel/smpboot.c --- 2.4.20-pristine/arch/i386/kernel/smpboot.c Fri Nov 29 11:38:59 2002 +++ 2.4.20-sched/arch/i386/kernel/smpboot.c Wed Mar 26 16:22:49 2003 @@ -803,8 +803,7 @@ if (!idle) panic("No idle process for CPU %d", cpu); - idle->processor = cpu; - idle->cpus_runnable = 1 << cpu; /* we schedule the first task manually */ + task_set_cpu_only(idle, cpu); /* we schedule the first task manually */ map_cpu_to_boot_apicid(cpu, apicid); diff -ur 2.4.20-pristine/include/linux/sched.h 2.4.20-sched/include/linux/sched.h --- 2.4.20-pristine/include/linux/sched.h Mon Mar 17 15:35:32 2003 +++ 2.4.20-sched/include/linux/sched.h Wed Mar 26 16:14:40 2003 @@ -568,6 +568,12 @@ tsk->cpus_runnable = 1UL << cpu; } +static inline void task_set_cpu_only(struct task_struct *tsk, unsigned int cpu) +{ + task_set_cpu(tsk, cpu); + tsk->cpus_allowed = 1UL << cpu; +} + static inline void task_release_cpu(struct task_struct *tsk) { tsk->cpus_runnable = ~0UL; diff -ur 2.4.20-pristine/init/main.c 2.4.20-sched/init/main.c --- 2.4.20-pristine/init/main.c Wed May 29 14:00:22 2002 +++ 2.4.20-sched/init/main.c Wed Mar 26 16:30:23 2003 @@ -354,6 +354,7 @@ * enable them */ lock_kernel(); + task_set_cpu_only(current, 0); printk(linux_banner); setup_arch(&command_line); printk("Kernel command line: %s\n", saved_command_line); diff -ur 2.4.20-pristine/kernel/sched.c 2.4.20-sched/kernel/sched.c --- 2.4.20-pristine/kernel/sched.c Fri Aug 30 13:51:40 2002 +++ 2.4.20-sched/kernel/sched.c Wed Mar 26 16:27:35 2003 @@ -525,6 +525,7 @@ goto out_unlock; } #else + task_release_cpu(prev); prev->policy &= ~SCHED_YIELD; #endif /* CONFIG_SMP */ } From qinhua@networks.ecse.rpi.edu Wed Mar 26 15:06:55 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 26 Mar 2003 15:06:59 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2QN6Eq9023139 for ; Wed, 26 Mar 2003 15:06:55 -0800 Received: from poisson.ecse.rpi.edu (networks.ecse.rpi.edu [128.113.50.30]) by smtp2.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h2QN67n5009702; Wed, 26 Mar 2003 18:06:07 -0500 Received: from localhost (qinhua@localhost) by poisson.ecse.rpi.edu (8.9.1/8.9.1) with ESMTP id SAA27791; Wed, 26 Mar 2003 18:06:06 -0500 (EST) Date: Wed, 26 Mar 2003 18:06:06 -0500 (EST) From: Hua Qin To: Keith Owens cc: kdb@oss.sgi.com Subject: debug bpha In-Reply-To: <24982.1048626176@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.28 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 290 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: qinhua@networks.ecse.rpi.edu Precedence: bulk X-list: kdb The "bpha" command is not working properly on my building kernel. so I just want to know where is the code I should look at. The problem is I set breakpoint "ip_defrag" by using bpha, and then send bigger packets to this machine. The ip_defrag should be caught and the machine should drop to kdb, but nothing happened. If I use "bp" command, it can drop to the kdb on the break point. I did some debug, it seems "do_debug" (traps.c) was not be called by using "bpha". Does someone know a little bit deeper, how "do_debug" be called ? Thanks! Hua From sonic.zhang@intel.com Wed Mar 26 17:41:52 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 26 Mar 2003 17:42:00 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2R1fAq9000458 for ; Wed, 26 Mar 2003 17:41:52 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2R1adn06419 for ; Thu, 27 Mar 2003 01:36:39 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by talaria.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2R1GF005811 for ; Thu, 27 Mar 2003 01:16:16 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003032709410310109 ; Thu, 27 Mar 2003 09:41:03 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 27 Mar 2003 09:41:03 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: debug bpha Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2F401.ED7CB0A8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 27 Mar 2003 09:41:03 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E350140@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: debug bpha Thread-Index: AcLz7Q4ZrMBgkvNQSzG+nh5YIVs6CAAFAZng From: "Zhang, Sonic" To: "Hua Qin" , "Keith Owens" Cc: X-OriginalArrivalTime: 27 Mar 2003 01:41:03.0677 (UTC) FILETIME=[ED83AED0:01C2F401] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 291 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F401.ED7CB0A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please apply patches "kdb-smphdr-v4.0-2.4.20-*" on sgi's ftp site. If you build your kernel for i386 architecture, please also apply the = patch in the attachment. Regards. Sonic -----Original Message----- From: Hua Qin [mailto:qinhua@networks.ecse.rpi.edu] Sent: 2003?3?27? 7:06 To: Keith Owens Cc: kdb@oss.sgi.com Subject: debug bpha The "bpha" command is not working properly on my building kernel. so I just want to know where is the code I should look at. The problem is I set breakpoint "ip_defrag" by using bpha, and then send bigger packets to this machine. The ip_defrag should be caught and the machine should drop to kdb, but nothing happened. If I use "bp" command, it can drop to the kdb on the break point. I did some debug, it seems "do_debug" (traps.c) was not be called by = using "bpha". Does someone know a little bit deeper, how "do_debug" be called ? Thanks! Hua ------_=_NextPart_001_01C2F401.ED7CB0A8 Content-Type: application/octet-stream; name="kdb-signal-v3.0-2.4.20-i386-1" Content-Transfer-Encoding: base64 Content-Description: kdb-signal-v3.0-2.4.20-i386-1 Content-Disposition: attachment; filename="kdb-signal-v3.0-2.4.20-i386-1" LS0tIGxpbnV4LWtkYi10bXAvYXJjaC9pMzg2L2tlcm5lbC9zaWduYWwuYwlUaHUgRmViIDEzIDE2 OjE3OjM3IDIwMDMKKysrIGxpbnV4LWtkYi9hcmNoL2kzODYva2VybmVsL3NpZ25hbC5jCVRodSBG ZWIgMTMgMTY6MTY6MjkgMjAwMwpAQCAtMjAsNiArMjAsMTEgQEAKICNpbmNsdWRlIDxsaW51eC9z dGRkZWYuaD4KICNpbmNsdWRlIDxsaW51eC90dHkuaD4KICNpbmNsdWRlIDxsaW51eC9wZXJzb25h bGl0eS5oPgorCisjaWZkZWYgQ09ORklHX0tEQgorI2luY2x1ZGUgPGxpbnV4L2tkYi5oPgorI2Vu ZGlmIC8qIENPTkZJR19LREIgKi8KKwogI2luY2x1ZGUgPGFzbS91Y29udGV4dC5oPgogI2luY2x1 ZGUgPGFzbS91YWNjZXNzLmg+CiAjaW5jbHVkZSA8YXNtL2kzODcuaD4KQEAgLTY5NSw3ICs3MDAs MTIgQEAKIAkJICogaGF2ZSBiZWVuIGNsZWFyZWQgaWYgdGhlIHdhdGNocG9pbnQgdHJpZ2dlcmVk CiAJCSAqIGluc2lkZSB0aGUga2VybmVsLgogCQkgKi8KKyNpZmRlZiBDT05GSUdfS0RCCisJCWlm KCFrZGJfb24pCisJCQlfX2FzbV9fKCJtb3ZsICUwLCUlZGI3Igk6IDogInIiIChjdXJyZW50LT50 aHJlYWQuZGVidWdyZWdbN10pKTsKKyNlbHNlIC8qIENPTkZJR19LREIqLwogCQlfX2FzbV9fKCJt b3ZsICUwLCUlZGI3Igk6IDogInIiIChjdXJyZW50LT50aHJlYWQuZGVidWdyZWdbN10pKTsKKyNl bmRpZiAvKiBDT05GSUdfS0RCKi8KIAogCQkvKiBXaGVlISAgQWN0dWFsbHkgZGVsaXZlciB0aGUg c2lnbmFsLiAgKi8KIAkJaGFuZGxlX3NpZ25hbChzaWduciwga2EsICZpbmZvLCBvbGRzZXQsIHJl Z3MpOwo= ------_=_NextPart_001_01C2F401.ED7CB0A8-- From sonic.zhang@intel.com Thu Mar 27 17:34:14 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 27 Mar 2003 17:34:18 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S1YDq9028815 for ; Thu, 27 Mar 2003 17:34:14 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2S1TfP15944 for ; Fri, 28 Mar 2003 01:29:41 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2S1UC214694 for ; Fri, 28 Mar 2003 01:30:12 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003032809340508387 for ; Fri, 28 Mar 2003 09:34:05 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 28 Mar 2003 09:34:06 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: How about add a new KDB command "kill SIG PID" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Fri, 28 Mar 2003 09:34:06 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E3503EE@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How about add a new KDB command "kill SIG PID" Thread-Index: AcL0yhYf+05JLkDuRWGHi4jxcOfQKQ== From: "Zhang, Sonic" To: "KDB (E-mail)" X-OriginalArrivalTime: 28 Mar 2003 01:34:06.0257 (UTC) FILETIME=[1F203210:01C2F4CA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h2S1YDq9028815 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 292 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb Hi, I found a KDB command "kill SIG PID" is helpful in some cases. For example, one process cause the system doesn't response to any keyboard input, while the KDB can still be activated. I'd like to add this new command to KDB code. Do you agree with my consideration? Here. SIG is the signal number. PID is the process ID. A signal is send to the specific process in this KDB command. Thanks. Sonic ************************************* Sonic Zhang Software Engineer Intel China Software Lab Tel: 021-52574545-1667 iNet: 8-752-1667 ************************************* From kaos@sgi.com Thu Mar 27 17:46:16 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 27 Mar 2003 17:46:21 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2S1kFq9028894 for ; Thu, 27 Mar 2003 17:46:16 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h2S1k8uY027577 for ; Thu, 27 Mar 2003 17:46:09 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA28707; Fri, 28 Mar 2003 12:44:51 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 91D27300087; Fri, 28 Mar 2003 12:44:50 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 830538F; Fri, 28 Mar 2003 12:44:50 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Zhang, Sonic" Cc: "KDB (E-mail)" Subject: Re: How about add a new KDB command "kill SIG PID" In-reply-to: Your message of "Fri, 28 Mar 2003 09:34:06 +0800." <37FBBA5F3A361C41AB7CE44558C3448E3503EE@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Mar 2003 12:44:45 +1100 Message-ID: <23699.1048815885@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 293 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Fri, 28 Mar 2003 09:34:06 +0800, "Zhang, Sonic" wrote: >Hi, > > I found a KDB command "kill SIG PID" is helpful in some cases. For example, one process cause the system doesn't response to any keyboard input, while the KDB can still be activated. > > I'd like to add this new command to KDB code. Do you agree with my consideration? Yes please, it has been on my TODO list for a while. From vamsi@in.ibm.com Mon Mar 31 01:51:51 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 31 Mar 2003 01:52:00 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2V9pAq9028678 for ; Mon, 31 Mar 2003 01:51:51 -0800 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h2V9oXmL102050; Mon, 31 Mar 2003 04:50:33 -0500 Received: from vamsiks.in.ibm.com (vamsiks.in.ibm.com [9.182.12.245]) by northrelay03.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2V9oT3O112682; Mon, 31 Mar 2003 04:50:30 -0500 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h2VAAHn21585; Mon, 31 Mar 2003 15:40:17 +0530 Date: Mon, 31 Mar 2003 15:40:16 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: Hua Qin , kdb@oss.sgi.com Subject: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Message-ID: <20030331154016.A21567@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <20839.1048294974@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20839.1048294974@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Sat, Mar 22, 2003 at 12:02:54PM +1100 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 294 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Sat, Mar 22, 2003 at 12:02:54PM +1100, Keith Owens wrote: > On Fri, 21 Mar 2003 16:35:02 -0500 (EST), > Hua Qin wrote: > >I downloaded 2.4.20 kernel from kernel.org, and patch > >kdb-v3.0-2.4.10-common and kdb-v3.0-2.4.20-i386 into the kernel. > >Then, I put this kernel (compiled by gcc-.2.96) to a SMP machine. set a > >break point by using bp, > >after the machine hit the break point, I use bt and cpu commands to check > >the status. Then I type bc 0 to clear that break point, and go to trying > >to leave kdb. But I never can go out, it always hit "Oops int3 ". I think > >it is the problem only happen on SMP machine, because another UP (unit > >processor) never has this problem. > > > >Today, I try v4.0 and other two patches kdb-smphdr-v4.0, same problem > >happened. > > > >Doese someone has some solutions about this. > > Known race condition with no solution yet. man Documentation/kdb/kdb_bp.man > and look for 'SMP'. > > Here is a simple way to handle this situation. Before deciding that this trap is not due to one of KDB's breakpoints, check if this is a breakpoint that was recently removed. You can do this by looking for the INT3 instruction at the trap location and if it is not found, we can conclude that this is a recently removed breakpoint. I use a similar technique in dynamic probes too. Comments? Hua: can you give this a try and see if it helps? -- Vamsi Krishna S. IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi_krishna@in.ibm.com -- diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.0-pure/arch/i386/kdb/kdba_bp.c 2420-kdb4.0/arch/i386/kdb/kdba_bp.c --- 2420-kdb4.0-pure/arch/i386/kdb/kdba_bp.c 2003-03-31 14:32:47.000000000 +0530 +++ 2420-kdb4.0/arch/i386/kdb/kdba_bp.c 2003-03-31 14:27:50.000000000 +0530 @@ -294,13 +294,9 @@ * If multiple processors receive debug exceptions simultaneously, * one may be waiting at the kdb fence in kdb() while the user * issues a 'bc' command to clear the breakpoint the processor which - * is waiting has already encountered. If this is the case, the - * debug registers will no longer match any entry in the breakpoint - * table, and we'll return the value '3'. This can cause a panic - * in die_if_kernel(). It is safer to disable the breakpoint (bd), - * 'go' until all processors are past the breakpoint then clear the - * breakpoint (bc). This code recognises a breakpoint even when - * disabled but not when it has been cleared. + * is waiting has already encountered. To handle this case, + * check if we are here due to a breakpoint that is recently + * removed and if so, simply ignore this hit. * * WARNING: This routine resets the eip. It should be called * once per breakpoint and the result cached. @@ -312,6 +308,7 @@ int i; kdb_dbtrap_t rv; kdb_bp_t *bp; + unsigned char opcode; if (KDB_NULL_REGS(regs)) return KDB_DB_NOBPT; @@ -350,6 +347,21 @@ } } + /* + * This doesn't seem to be one of our breakpoints. Before deciding + * that this is one of ours, make sure that this is not one of our + * breakpoints that was recently removed. If the breakpoint + * instruction is not present at the trap location, we assume it + * is our breakpoint that was recently removed and consider it + * handled (return !0 from kdb()) so that we don't cause any + * unhandled int3's in kernel which results in kernel panic. + */ + if (!kdb_getword(&opcode, regs->eip, 1)) { + if (opcode != IA32_BREAKPOINT_INSTRUCTION) { + rv = KDB_DB_REMOVED_BPT; + } + } + return rv; } diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.0-pure/Documentation/kdb/kdb_bp.man 2420-kdb4.0/Documentation/kdb/kdb_bp.man --- 2420-kdb4.0-pure/Documentation/kdb/kdb_bp.man 2003-03-31 14:32:42.000000000 +0530 +++ 2420-kdb4.0/Documentation/kdb/kdb_bp.man 2003-03-31 14:28:57.000000000 +0530 @@ -121,23 +121,6 @@ The breakpoint subsystem does not currently use any environment variables. .SH SMP CONSIDERATIONS -Using -.B bc -is risky on SMP systems. -If you clear a breakpoint when another cpu has hit that breakpoint but -has not been processed then it may not be recognised as a kdb -breakpoint, usually resulting in incorrect program counters and kernel -panics. -It is safer to disable the breakpoint with -.BR bd , -then -.B go -to let any other processors that are waiting on the breakpoint to -clear. -After all processors are clear of the disabled breakpoint then it is -safe to clear it using -.BR bc . -.P Breakpoints which use the processor breakpoint registers are only established on the processor which is currently active. If you wish breakpoints to be universal diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.0-pure/include/linux/kdbprivate.h 2420-kdb4.0/include/linux/kdbprivate.h --- 2420-kdb4.0-pure/include/linux/kdbprivate.h 2003-03-31 14:32:41.000000000 +0530 +++ 2420-kdb4.0/include/linux/kdbprivate.h 2003-03-31 14:14:40.000000000 +0530 @@ -265,7 +265,8 @@ KDB_DB_SS, /* Single-step trap */ KDB_DB_SSB, /* Single step to branch */ KDB_DB_SSBPT, /* Single step over breakpoint */ - KDB_DB_NOBPT /* Spurious breakpoint */ + KDB_DB_NOBPT, /* Spurious breakpoint */ + KDB_DB_REMOVED_BPT /* Recently removed breakpoint */ } kdb_dbtrap_t; extern kdb_dbtrap_t kdba_db_trap(struct pt_regs *, int); /* DEBUG trap/fault handler */ diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.0-pure/kdb/kdbmain.c 2420-kdb4.0/kdb/kdbmain.c --- 2420-kdb4.0-pure/kdb/kdbmain.c 2003-03-31 14:32:41.000000000 +0530 +++ 2420-kdb4.0/kdb/kdbmain.c 2003-03-31 14:13:42.000000000 +0530 @@ -1435,10 +1435,14 @@ db_result = kdba_db_trap(regs, error); /* Only call this once */ } - if ((reason == KDB_REASON_BREAK || reason == KDB_REASON_DEBUG) - && db_result == KDB_DB_NOBPT) { - KDB_DEBUG_STATE("kdb 2", reason); - return 0; /* Not one of mine */ + if ((reason == KDB_REASON_BREAK || reason == KDB_REASON_DEBUG)) { + if (db_result == KDB_DB_NOBPT) { + KDB_DEBUG_STATE("kdb 2", reason); + return 0; /* Not one of mine */ + } else if (db_result == KDB_DB_REMOVED_BPT) { + KDB_DEBUG_STATE("kdb 2a", reason); + return 1; + } } /* Turn off single step if it was being used */ From kaos@sgi.com Mon Mar 31 03:02:49 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 31 Mar 2003 03:02:53 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h2VB26q9010252 for ; Mon, 31 Mar 2003 03:02:48 -0800 Received: (qmail 21818 invoked from network); 31 Mar 2003 11:02:02 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 31 Mar 2003 11:02:02 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 1395B3000B8; Mon, 31 Mar 2003 21:01:59 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id F09AB8F; Mon, 31 Mar 2003 21:01:59 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: vamsi@in.ibm.com Cc: Hua Qin , kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) In-reply-to: Your message of "Mon, 31 Mar 2003 15:40:16 +0530." <20030331154016.A21567@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Mar 2003 21:01:54 +1000 Message-ID: <31662.1049108514@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 295 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Mon, 31 Mar 2003 15:40:16 +0530, "Vamsi Krishna S ." wrote: >Here is a simple way to handle this situation. Before deciding that >this trap is not due to one of KDB's breakpoints, check if this >is a breakpoint that was recently removed. Sonic Zhang has cleaned up the breakpoint handling. I am waiting for feedback on these patches before including them in kdb. ftp://oss.sgi.com/projects/kdb/download/v4.0/kdb-smphdr-v4.0-2.4.20* From sonic.zhang@intel.com Mon Mar 31 17:47:10 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 31 Mar 2003 17:47:18 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h311l9q9022943 for ; Mon, 31 Mar 2003 17:47:10 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h311j5i05304 for ; Tue, 1 Apr 2003 01:45:06 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h311Llt27098 for ; Tue, 1 Apr 2003 01:21:48 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040109470320379 ; Tue, 01 Apr 2003 09:47:03 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Apr 2003 09:47:03 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Tue, 1 Apr 2003 09:47:02 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E350B30@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Thread-Index: AcL3dYnuRO828e4QQA2lB81pSvycXwAehMPQ From: "Zhang, Sonic" To: "Keith Owens" , Cc: "Hua Qin" , X-OriginalArrivalTime: 01 Apr 2003 01:47:03.0499 (UTC) FILETIME=[980CE9B0:01C2F7F0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h311l9q9022943 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 296 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb Hi, The "smphdr" patch only deal with the hardware breakpoints. It doesn't affect the logic of "int3" instruction breakpoint in the formal KDB patch. So if this problem occurs in the formal KDB patch, it is very possible that it still exists after applying the "smphdr" patch. Thanks. Sonic Zhang -----Original Message----- From: Keith Owens [mailto:kaos@sgi.com] Sent: 2003?3?31? 19:02 To: vamsi@in.ibm.com Cc: Hua Qin; kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) On Mon, 31 Mar 2003 15:40:16 +0530, "Vamsi Krishna S ." wrote: >Here is a simple way to handle this situation. Before deciding that >this trap is not due to one of KDB's breakpoints, check if this >is a breakpoint that was recently removed. Sonic Zhang has cleaned up the breakpoint handling. I am waiting for feedback on these patches before including them in kdb. ftp://oss.sgi.com/projects/kdb/download/v4.0/kdb-smphdr-v4.0-2.4.20* From vamsi_krishna@in.ibm.com Mon Mar 31 23:49:35 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 31 Mar 2003 23:49:39 -0800 (PST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h317nXq9031961 for ; Mon, 31 Mar 2003 23:49:34 -0800 Received: from d23rh902.au.ibm.com (d23rh902.au.ibm.com [9.185.167.101]) by ausmtp01.au.ibm.com (8.12.8/8.12.8) with ESMTP id h317mbTS064010; Tue, 1 Apr 2003 17:48:37 +1000 Received: from d23m0067.in.ibm.com (d23av02.au.ibm.com [9.185.167.107]) by d23rh902.au.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h317mrZf057876; Tue, 1 Apr 2003 17:49:16 +1000 Subject: Re: [lkcd-general] Converting lkcd from a pull to a push model To: Keith Owens Cc: lkcd-general@lists.sourceforge.net, kdb@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: From: "S Vamsikrishna" Date: Tue, 1 Apr 2003 13:09:15 +0530 X-MIMETrack: Serialize by Router on d23m0067/23/M/IBM(Release 5.0.9a |January 7, 2002) at 01/04/2003 01:07:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 297 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi_krishna@in.ibm.com Precedence: bulk X-list: kdb Hello Keith, I am not familiar with IA64, so what I say may only apply to IA32. As far as I can tell, in kdb v4.0, you call kdb_save_running() / kdb_unsave_running() around kdb_main_loop() in kdba_main_loop(). We will execute kdba_main_loop() on all processors only if the KDB IPI (NMI class) to stop other processors works. Current lkcd does something similiar: it sends an NMI class IPI to capture register state of other processors. I agree that timing out the IPI is a bug (I thought I removed it, may be never submitted the patch for inclusion), but this method will capture the state of all CPUs as long as the IPI goes to all CPUs. So, how is the push model any better, when the push itself relies on the IPI to be delivered and handled on all cpus? Did I miss something? Can you please explain? --Vamsi Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi_krishna@in.ibm.com |---------+----------------------------------------> | | Keith Owens | | | Sent by: | | | lkcd-general-admin@lists.sour| | | ceforge.net | | | | | | | | | 03/19/03 07:41 PM | | | | |---------+----------------------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: lkcd-general@lists.sourceforge.net | | cc: | | Subject: [lkcd-general] Converting lkcd from a pull to a push model | | | | | >------------------------------------------------------------------------------------------------------------------------------| This a heads up about an alternative (and hopefully much more reliable) method of capturing per cpu data for debugging. Obviously I would like to feed this back to lkcd for inclusion eventually. You may have seen my announcement on l-k[1] about kdb v4.0, where the big change is converting from a "pull the other cpus into kdb" model to a "push this cpu's state to a known place" model. Although that announcement was only for kdb, I will be changing lkcd in SGI kernels to use a push instead of a pull mode. [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=104787987626450&w=2 The pull model works as long as inter processor interrupts (IPI) are working and the other cpus are responding to interrupts. It fails badly when cpus are hung and are not responding to interrupts, of course this is precisely the case when you want debug data. lkcd 2.4 hangs solid if any one cpu is not responding. lkcd 2.5 will time out the hung cpus and continue, with two nasty side effects :- (1) You get no data for the hung cpus, which makes the crash dump almost useless. (2) The timeout code can result in corrupt IPI data, especially when lkcd releases the other cpus at the end of the dump. I have seen several oops at the end of dumping as handle_IPI() is allowed to proceed but its data no longer exists (it was deleted during the time out). kdb v4.1 (maybe v4.2) will attempt to get the attention of the other cpus via a graduated set of probes. The pseudo code is :- if (safe_to_send_interrupts) { send_kdb_ipi(normal_interrupt); if (!all_cpus_in_kdb && arch_supports_nmi) send_kdb_ipi(nmi); if (!all_cpus_in_kdb && arch_supports_pmi) send_kdb_ipi(pmi); } if (!all_cpus_in_kdb) kdb_enter_debugger = 1; // trip spin_locks and scheduler into kdb if (!all_cpus_in_kdb && arch_supports_init && (user_requested_destructive_ipi || destructive_kernel_error_detected)) send_kdb_ipi(init); if (!all_cpus_in_kdb) kdb_printf("not all cpus entered the debugger"); pmi and init are ia64 specific interrupts, even harder to mask than nmi. A big problem with ia64 is that nmi is masked :( An even bigger problem is the ia64 that MCA and INIT interrupts have mandated requirements which can prevent the OS from getting full control. A pull model requires that the OS be in control on each cpu, a push model lets each cpu save its state before the OS surrenders control. The next part of the kdb patch is changing the ia64 spinlock model to be faster in the uncontended path with a single bit of out of line code to handle the contended path. Debuggers like kdb can enhance the out of line code to detect hung spin locks or kdb_enter_debugger == 1 and enter the debugger, even when interrupts are disabled. Obviously the data that kdb captures is generic debugging data and can be used to get the state of each cpu for any debugging tool, not just kdb. Once I finish the spinlock and init slave handlers on ia64 and implement the above pseudo code, I will hook lkcd into the data that kdb has already captured. This will go a long way to improving the reliablity of both kdb and lkcd, to the extent that lkcd should be usable from anywhere, including panic, oops, interrupt context, nmi, pmi, init etc. Have a look at the kdb patches in [1] above. Think about what additional data lkcd needs, if any. kdb v4.0 already captures all application registers at the time of error from most cpus, v4.[12] will reduce the window of lost cpus to almost zero. ------------------------------------------------------- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ Lkcd-general mailing list Lkcd-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lkcd-general