From owner-kdb@oss.sgi.com Wed May 1 09:07:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41G70wJ024374 for ; Wed, 1 May 2002 09:07:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41G70KO024373 for kdb-outgoing; Wed, 1 May 2002 09:07:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41G6wwJ024370 for ; Wed, 1 May 2002 09:06:58 -0700 Received: from linux ([12.224.214.127]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020501160749.ZYBB5896.rwcrmhc53.attbi.com@linux> for ; Wed, 1 May 2002 16:07:49 +0000 Content-Type: text/plain; charset="iso-8859-15" From: Charles Johnson Reply-To: cjnaj1@attbi.com To: kdb@oss.sgi.com Subject: Another kdb question Date: Wed, 1 May 2002 09:08:02 -0700 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02050109080200.00851@linux> Content-Transfer-Encoding: 8bit Sender: owner-kdb@oss.sgi.com Precedence: bulk I've gotten kdb patch installed with kernel 2.4.18. However I'm having trouble getting output when I press the Pause key which should break me into the debugger. Something is obviously alive because the keyboard leds are flashing and if I type go then everything is back where I started. So my question, what assumptions does kdb make about the console for output ?? Any hints would be appreciated. --Charlie cjnaj1@attbi.com From owner-kdb@oss.sgi.com Wed May 1 09:51:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41GpHwJ026219 for ; Wed, 1 May 2002 09:51:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41GpGZZ026218 for kdb-outgoing; Wed, 1 May 2002 09:51:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41GpEwJ026215 for ; Wed, 1 May 2002 09:51:14 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g41Gm3815376; Wed, 1 May 2002 09:48:03 -0700 (PDT) Received: from slurndal-lnx.verisign.com ([10.25.27.123]) by vhqpostal-gw2.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JW9NZPFJ; Wed, 1 May 2002 09:53:35 -0700 From: Received: by slurndal-lnx.verisign.com; Wed, 1 May 2002 09:43:56 -0700 Message-Id: <200205011643.JAA22024@slurndal-lnx.verisign.com> Subject: Re: Another kdb question To: cjnaj1@attbi.com Date: Wed, 1 May 2002 09:43:56 -0700 (PDT) Cc: kdb@oss.sgi.com In-Reply-To: <02050109080200.00851@linux> from "Charles Johnson" at May 01, 2002 09:08:02 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk > > I've gotten kdb patch installed with kernel 2.4.18. However I'm having > trouble getting output when I press the Pause key which should break me into > the debugger. Something is obviously alive because the keyboard leds are > flashing and if I type go then everything is back where I started. > > So my question, what assumptions does kdb make about the console for output You must be in the primary virtual terminal when you hit pause. You cannot be in the X VT or any secondary virtual terminal. Use CTRL-ALT-F1 to get the primary VT. scott From owner-kdb@oss.sgi.com Wed May 1 12:38:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41JcFwJ032590 for ; Wed, 1 May 2002 12:38:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41JcFbR032589 for kdb-outgoing; Wed, 1 May 2002 12:38:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41JcDwJ032586 for ; Wed, 1 May 2002 12:38:13 -0700 Received: from linux ([12.224.214.127]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020501193905.HTJE9799.rwcrmhc51.attbi.com@linux>; Wed, 1 May 2002 19:39:05 +0000 Content-Type: text/plain; charset="iso-8859-1" From: Charles Johnson Reply-To: cjnaj1@attbi.com To: Subject: Re: Another kdb question Date: Wed, 1 May 2002 12:39:11 -0700 X-Mailer: KMail [version 1.2] References: <200205011643.JAA22024@slurndal-lnx.verisign.com> In-Reply-To: <200205011643.JAA22024@slurndal-lnx.verisign.com> Cc: kdb@oss.sgi.com MIME-Version: 1.0 Message-Id: <02050112391100.01296@linux> Content-Transfer-Encoding: 8bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Tried CTRL-ALT-F1 and still get no output. Screen output stops, but if I type "go" at the keyboard, then eveything is running again. I'm running kernel 2.4.18 and kdb version 2.1 on a PII based PC. Thanks for you help. --Charlie cjnaj1@attbi.com From owner-kdb@oss.sgi.com Wed May 1 15:02:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41M2rwJ020415 for ; Wed, 1 May 2002 15:02:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41M2rCW020414 for kdb-outgoing; Wed, 1 May 2002 15:02:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41M2lwJ020411 for ; Wed, 1 May 2002 15:02:49 -0700 Received: (qmail 1467 invoked from network); 1 May 2002 22:03:38 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 1 May 2002 22:03:38 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 623273000B8; Thu, 2 May 2002 08:03:36 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 23239A0; Thu, 2 May 2002 08:03:36 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: cjnaj1@attbi.com Cc: kdb@oss.sgi.com Subject: Re: Another kdb question In-reply-to: Your message of "Wed, 01 May 2002 12:39:11 MST." <02050112391100.01296@linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 May 2002 08:03:30 +1000 Message-ID: <22512.1020290610@ocs3.intra.ocs.com.au> Sender: owner-kdb@oss.sgi.com Precedence: bulk On Wed, 1 May 2002 12:39:11 -0700, Charles Johnson wrote: >Tried CTRL-ALT-F1 and still get no output. Screen output stops, but if I >type "go" at the keyboard, then eveything is running again. >I'm running kernel 2.4.18 and kdb version 2.1 on a PII based PC. You have to switch to the text console before entering kdb. Once kdb is in control the kernel is stopped, VT switching will not work after kdb trips. From owner-kdb@oss.sgi.com Thu May 2 00:42:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g427gpwJ001578 for ; Thu, 2 May 2002 00:42:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g427gpux001577 for kdb-outgoing; Thu, 2 May 2002 00:42:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g427gLwJ001572 for ; Thu, 2 May 2002 00:42:21 -0700 Received: from cs.columbia.edu ([12.234.195.52]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020502074314.KZYG4412.rwcrmhc52.attbi.com@cs.columbia.edu> for ; Thu, 2 May 2002 07:43:14 +0000 Message-ID: <3CD0EE13.BA524553@cs.columbia.edu> Date: Thu, 02 May 2002 00:43:15 -0700 From: Ethan Solomita X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kdb@oss.sgi.com Subject: SMP patches for kdb Content-Type: multipart/mixed; boundary="------------1E9C7A1D72A7A74CB3F88EB0" Sender: owner-kdb@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------1E9C7A1D72A7A74CB3F88EB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It took a little longer than I'd thought, but I think I've got a reasonable shot at a patch that fixes SMP stuff. The catch -- I haven't made the i386-specific changes, just the sparc64 changes, but I don't think they'll be devastatingly complicated or anything. I've attached a .tar.bz2 (<10K) with three text files. One is a patch to the common code relative to kdb-v2.1-2.4.18-common-3. One is a diff to sparc64's kdba_bp.c relative to sparc64-common-2. The third is kdba_bp.c in its entirety, to make it easier to see what needs to change in i386. I've put these together in a bit of a hurry before a short vacation, so I hope I haven't messed up the patches. The changes aren't small, so let me try to explain/justify. I wouldn't say that kdb() has been rewritten, since I didn't write much new code. But it has been heavily reordered to make sure that no state (eg. KDB_STATE) is modified until someone has won the race to kdb_initial_cpu. This'll make it hard to follow the changes to kdb() from the diffs. I spent a lot of time getting the breakpoints to work correctly -- it was more involved than I'd expected. Most importantly, after hitting a breakpoint and then saying "go", I had to make sure that the other CPUs aren't released from kdb until kdb_initial_cpu has finished single-stepping and restoring the breakpoints. To do this, I changed kdb to treat this as a variant on a standard single-step request. I eliminated the complicated thing with breakpoints having a "delay" and "delayed" field to mark this progress. If we need to do the single-step game after a "go", I set a state flag "NEED_SSBPT" instead of setting the "delay" field of a breakpoint. If we then say "go" with that state set, I set DOING_SS and DOING_SSBPT in combination. It then proceeds to do a standard single-step, ie. it doesn't release the other CPUs. I had to change kdb_main_loop() so that it doesn't actually release the other CPUs (that's moved into kdb()), and also that a "go" is always handled by kdb_initial_cpu, even if you've switched to another cpu. So if you say "go", it will magically switch to kdb_initial_cpu and then do the "go". For whoever wants to tackle i386, some notes: The sparc64 kdba_db_trap() is simpler than the i386 version, because sparc64 doesn't have hardware watchpoint or breakpoint support. It also doesn't have hardware single-step support, although that's another story. So the i386 kdba_db_trap() should change similarly to the sparc64 version, but you just have to ignore all of its code that doesn't exist in sparc64. Most of the other changes in the file are simple. I hope that this all makes sense -- and that it works. 8-) I tested with a breakpoint that is hit in parallel on two processors, I tested single-stepping and going after switching the processor, etc. But I'm sure it's not perfect, so the more people that take a whack at this the better. I should also say that I didn't tackle the issue of user breakpoints hitting into kdb, and thus slowing things down. With my changes, on i386, a user breakpoint is the same as a kdb breakpoint and so kdb will first be entered, and now it'll assemble all the CPUs before it decides that the breakpoint isn't a match. I guess this could be a nuisance for some users, but you can always turn kdb off (ie. set kdb_on to 0). Problem solved. If this is really critical to someone, we can deal with it, but no one has really argued for this. Thanks, -- Ethan --------------1E9C7A1D72A7A74CB3F88EB0 Content-Type: application/octet-stream; name="kdb_smp.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kdb_smp.tar.bz2" QlpoOTFBWSZTWWzobaUAOCn/gfgwQAh7///////f//////8BAQgIYDK+++fAAfZgoSMXzc2a 1Xn3p7rife7n0Plm2IiEoiJ7wtb5uAAcEPHT7x6+7vIqL693ye0Pgb7b7B6dC7k7XcmdduuX r731x867nN3L3Qxfd16+7170WK7m7tz292udNuXZ73vL2263bjt0S5fXldFnvV3dHlS91tuP QpC9e7sJTSCACGI0mQjCaTTaIPU0U/TKm1P1JtRo9IMjIGhkAJTRNAgmk0Cp+k9I2o0mm1Ey fpCfqh5AjGpgIw0BDTJgJBIk1T0im9Qg9TNE9NTJo0DIMTQ00NDagA0aDQNACTUSEJpkKZqb JqantCm9RqfqnlPRPJNP0KYQ0GgBoGgA0CJJApgmgEY1CeRqnsU1PTFPKGamTeqMmCNqNqae hAAeoIkiExAaImQZTU9TyU8p6g9R+pPUPU0D1DTT0gyPUAaAB7fw+n1cjd9rnqREJiAjd01o EK7vP3t1MT1VZs87Xu95Vw0MdRqmHsgVEYxWyKRWr5ygGDLGCxjCoCBkhYQJGcPfXwFU2C0s sKKpBgqtLUEoKGBVMkskrHCFISDFff/n+n++Gzhja4ccIEgUlpISxsoOEkTsbg5AdbblGyVE kUGMIDdVCMfT4vRYoCNmPbIxoIMHI9+lxNjG08NOn0zJJxhm/d9rYbZ0nPRWsZFnSK44YBbE 3r4fNoccPi+ewMZgmjOjdP3soWGtSPMwskZBgwltbg5Qg3bgZbLlMqjJarbcMszFaZbbTG22 7WEMI3cFAwwix2jdwLYobiZlyaB6CsqVLVDRMTHyPBpVLZsJgDljGWhAxIHgrgo2SYZSKJsD aiRlBDMIakQ2q8zMCZhckyky0smYgxxyZlmO5mOIkxQxVtuE3LqJsTbQyYyalLDs13TIONjb dbKtk5Sgk8Q9u1xp8lJKe1qxEUhPd5iZjCNnr9Pp9j5/xfN8f47+LPi0eAUYxgn0pzD0xDtp lQoiztM7SHbq7LusLVGFWqgNURcjxJANfQWVHzfT7+GGvUGMcCjDr3KNi8AsWFSINJdyIpLr scelEaMGMiy6CiLmOV2kKXK7YzMyoMMChlDCgrMZmCIMbG6OEwoVpsuSYNkQyPAw05keNWqm ib2R0NamUbcjCyJNoHnUhCsKqjWGKLAVu7wtUGQZ4tuGNMa1ByDhCIeWgqxzzquNRa1Bwbe6 weaMWm8RGZmVligJpjEsTSY8kDGNhQY1RZkmP2L63rgxi+I88b0MPmJyW7+4soP4J/pnHpwv ZEznsoctli105Vx2aGrBhMkSIqI0VUqDVYqrZNIjsrDSttMT7oyHFDZyf19UNe7XtL4VKZez FWg4+xwx60Yylet6pZGPbGbKOGpXmoatoMdyGnTZ3bGg22xkUI45CNif37GukiUgEepAfafh H2ua55CuMmSZJs4pEVmigHeyI8X/9n9zdDgxi2CNCOXD0TGSoP3XmGRJuow7oRMONZEqEw/Y SamqFT0Ljr7ZDlRXNk6stBaxQ5U3UfOewRaGjgFQSUKivYmmdr1ptzTQ0rFOsI1WY/kTOkmI jIxpGzdtrq2bJlRWiSBVljqvr8vN5tb56D3JSdwvQ4AIPsE7T+vZBk30OznZ1d12koxR5RLk FK7VRGMKQxUQkcbnptT39JqUTuZ3d0JEJo4d6O1GYYQYSvY14RFVOc5ubY7ng77fez6M7Q0J ikxYKLOgDxe33Dp0UQQsLgVVBdiinWhxlemaHfVs0nnpWLtmPu3QoquuW9yAr83gnmozKSwg SSbomCE0b4PDj2tfVSTUFjvNdVtQIrMPuy3993V2kaqZ6omHV07q8EIhNy+Zb6ySYerxBd+y Tg2t4u/Jgyg83PYWZLv0Uu0ShB2O//zl6aVKlolUbknlJhS7lH2kdCQijoZsz2eqJkZLh38u XfG7GdPlxbbN0mxQjayIu67oQlumP4zNmoIqQrO0DJpE3vIZ4SRd56tfLpxHKqo6EIobZ4Cr 4qy7uGZ+uGzGGdkN8ifN75TMc3h5RsqoR3UrNzfekcUb0oy6h0IQlGNdIcSUIbDM1GG83b4o OAqBugGcWVQDUFDhfjYLkQL1QFTjFwJAOTEVN8YnLy8LA/InBoDOReJowuPSF6aCxaBISzRQ EoXMw+PhgZg/cArCsYxkMxkONCJ2ncHfshyDdfzEj3yLbDthXTgUu8ZvdtC4N8h73A5Webby 3le2chqC85gKDwJCwUQ9NmixDmhm3lPmibeqckjn4OOkc/Cuf6Zqqq0qPeyYy9tMFfs3A9G0 zv4qGEDTCW3CXPKqbXSkEqeUU9cX5/+cSAzW8WfZ7ufV7PKbBlgzlvnHGazNx0BM9IvOB4qo gLAhwpPNdQlsWCwS6hJVw5NWJzoIMEhklBMlSQWQaohVSUkiWzNwkwDdEnFpOY1Si0xv6dmN +d3v6jWi8+6orb9NlTmqiKeF/g4N2TtP9q6I9WDRv/Gb7qYJ/jwl1aFPruJV+l4LV3tuhim0 +/GiNdDj/M8bVylTR6ZUcucJWCBdR+czQesvte59Hs965Pty6+dkzGM8c1Xsj9R68D8Lp+I+ EE1xHqDd6Ddde39Gu7n8lJ+XuR0qeaScpEVIqzj5xkldePGCCg++a/51nIy7qVVFlwHoeHg8 Gb48fDtlahIGncuzh5/O554uBaxXVSVRi8CObBePFRJPNOl85+8HYa/DqPZwNmuLt3fMq+iE Besedmvit73SiiKP/8F+kNqjWi1RYozYmrE51CkPF3QwUhfsYbvqJJIMXA931HNu5dKPV1Q+ d0oyXhOZGO6eTkJEq2MkzarciC9fvwlv1o7qT7cnG39x9JzMCy6gtsdm/Dse1MYCiuZBwupI QpRcnTSEw5e+ym9dp2IBwm/6oODdyGr9N/izuw1qJPw5lAxhnwAo23urhuwC06QA4QHsTaK5 kUpxXwsFz0U8PO9t5K8PvW2YdTaufv5PP/cwKilLbkkkFWjCcub/c3wDB3y0yIaR0IEGjcbo yc7CmLeFi1b/BLx5iptqskIyiy2mr1+x7ZNbz2nDwPl4U1zIsrazVUv/KMcj5ATPydJJJJKz aPHHPTU3M3NN5d0uUdvxmOhqBqOfMPTFPQRoYtBrUDddLPyODjk5hjC+ErcvORabIh7OyMTJ Bw0zenbbnHNPR4KydnMk58ObPMS1tDyfa/S4Xj3Mb06ij356l2jdHAFH5ZdVyfGye5z4OnJt yLZOR6KFSj7CEKNBbY3IO5YSmhmaHFO7vL50Gzpz57Ebozc8xwK6a1g9dRxaZk1GXZ6744iJ HGJxWiN1g2QIbeVJtGURuAhxHSZfoG0wxsWOpRGGkyM62Jg4szTrEbK2sJ1pfa0rhswRZKyB RAnIK77ztd9j5wROCTuzlqlNGo3jS2+0C909ojCNdCoo8ue0XkzdXmZeftPr4qwqv7A7xkCC ntEDtCB2Jm3xpq7C9m/X3X0Hv0OuMTIeiAOopS+oyLehstVFnezlCFVyZySaHGDQY5Qe4ZRf IouRc71E8OHw13TwauuuA9X4w6Pjzn8jq3bLO92RF1XeuahMIGsBENrWDqqiBVS45WcKvf1r iknpKunBJJLo7cwsIN6GRzBA444kKDnoCvbntiSIWbXIxYq8MIKRIRYokEQegQGOzzd3sWdh ji/ecZrnz4jwtXoWUxCWeeO/BHhjovKjTtngrGxSr9exZblDNgvw4jjzels4PqFwyO+64nJz wpPnu0NHbG0WxkrDbcZwLie7J0Y0C/6qOWOKxUgmG0a6s7UI76imYtuYuYK956l4tFWArStI L48OTrYx1YwSVxDfSo9OLE8WrwyJbPn9noLKsjV4S0ysbnqVzOsH0DPRZKZ19W0EO1Kizaw/ yJR2iuoefrxbQmRQm4s7FVwG0xB2TFpQWInnjbXz34kMzQjXZeN34M440nZoNxciMoKJjWUF Oy3mZjkwDYYUZFVp0kWg3fx3vHspditT4V1avPWr79VORfKtaLdErzWdDkWwqQZihaZtpipF H1wXvrjF64rR84MBitjHPScbdfftUoswIVUW2mgb1v57tEx6ijURekxnLx5ummPX51g8CmOw ocvDZvDsE3V2V0xRkFcTDhgcCcC4qIabr62qkFk8PUUFwts7ysSwI/MQs3u83qnur2l5lRzW ltUqma1DCTNmCAJEKgyA0wCiei/y8Xg7WDiTpifxbsyd3nBPzCwERPjRrw90wXBURBOChSVD kOXcXg72KDlO7SRYsJ2tlSAZpBPL6vV8nsXj1Yu8j1+uteeMqsOThnEAgxIooJJAUYep7qHo Y9VInPINnzJVrVUpEC2Qh6ojkfYUr5gS5CQkYoRBLmEZJBhmV693vibJh2LZyX4o91slmyHA bxBj8wAgYQRQOIhYxe9mOc+JhebQQWLG89MOy/eC7GoWmiX5XqsW0opreR11DQkCob8Agv5e 442mMccTnqqQlLTgNpIXBpaNk2WORQkTJqhKwwxHeY/UU8brPIDqiI8DN6JumuBInLBs+Xoe C2rJKDQeTp7nT931nZ8lxktXRyGdo0TKaYVM0oydTdkmss9u3REwzcDOA3WAmOrtl9GbyYzE zVJs0STNaI16AvCJEIBAHPPg5Ot67PLu+p+lWQcErkMY/KEY783Nn+b4KabKmH1Wl/4NCxoi MO7up+yUOu+/7fU+CD0KCNE16YjOUJoZ/Ry1urTtyshB4On19vDOcvcZ9vIqpeUf5fWjT4+i O6lmLOPJ/yuZmKyYHTGHPdA2KdXHrhT5uThd1608PuTt5kddD+P8zi2uYRcL8I95E1QRTbLq 4MSvb3n5TlLs2Q5L1INu126Os6jWOr+MNb6IpAdWlFE5TUXcPqiOb5Of2vODE91PZ04zH8iN UQsos/yVGkbo0BOH11Rbg3BMXEW2axaA0cMPMGbUygL5DmJxeBWoPPCL5BwDNEa/63tMd6hi p/e9NH5+32yjfSdf37J8uelSWulsHxD7KrzTaFSI1VGWPTXaJcsqLKn22YU2QznBdEYcOWnX fTbvojv3p/QKjbHpohwBYTyuoqso2Qvp6Q53Qjr0UxjLnWR3nA3E6sT27ie3bQWWT2whGMcy t99k50Rq6Nu3LCWVVWEcrbZ1cSlQFuOePxNvsnJ2z4JIE/VIIoAsIkiggqMEYIsUWAowYxkF BBVFVYRFgsGSChFUAZFIKgigkYyAoirIxGApJhBYGjCElMnwoKkUjD5JIQjOsGpKAyOcsEi0 SDjAJ2wGN4LX1uW0hiEA93W8EEhM3DDUdvN+juI8fgkklXjdcdVHJ4djWg4cYdNpAwNC/beO 6WjZbNbSTYll5CRWZ7Zm7SgtWOV1BtomkVFA315en0LwegOjY+7zAfd6sLmzpc01NoahLPHG qIkkYTc5LVHZz+CwbJmJs4051aTzNLeI2ghkypsvNtfPydPhnf6PV1fd9aR6PY0R9P4pd/9P LaE8WIs7wf6zbCxa81o8oti8VvFJm6tN3pCt07/hYGGb1Mf5DOyGc9whikTykR5lV752kQ7R 3YMh6MpyIVZDIJg8/h8jv4nt3VOqnpep8M2tSAtMlUGohhuLc409/J5aXUK0RZURZXSgmLuv pqny61NUbGk9Xl7aR9QZeB3EJCTf4vy8DUkk2JU4SuW79Trj3uv6Cqv0sO99XQEs95nKqIrI npqEoQwyKQpCmkkfW1SsoaoqhVr2T3Pd57rx/Yxymnn0+LC++eQu1iqI3O6cxkdBjAn1vB4y 8jbOMm5kDrvsjGKGylW1BGExJePcv5yY04O6F9o7Jj8TQq4GYVGQFNlVu3UQlVhPBWWDjljD yvtKrEV6A0DW16vme8YfCuFEjeoEXAytVOYvJuyL0CRgkIhCK94sAZls78b37sbnOolDgfIa Vd0YeDO1ejpiiXXZp9xdKP7Mz+qN7dpQHf4LDvA6eLNy7O/NyxEqISQkKpSSKJIRRqZvNaco tH3CpvM4rDatSjEDjliW+brfUDh0FnYZHizMHM1ox43gUtXNb2O5J4tRfAQCzm9dEfNVymkr FreQLeWmujcenGoW4BVaUWM8gP9eEtIKNB0XTqIybOMCMuUJSeaFxGYM71ZJ1IF5RAxnVvsu Fc1tmIq/PxdscdkFtOj6d5R7YtrrLNLaEs7y0ObwGNa5bemD0HMx11uNlFE73aqwdpwx2tLJ naeT0tsaIwjpZzVrwuvGYbN9dStIsoti+Js+ddZNEaonDtZo6iqmpm+J2nXEZMU9fvH/Aict Zq+4MazRc9LNrqcBVHCBJh+haeLq+bZKvDQ4Qq2V8XlnebtAraNT77arcjTS4qs/eIxW3HGH 6k+BjBpQ3qODtTVNzG4wKoyC27ftXYcHTzx8yvnUgp7sW137rF853oPzufSI+DuS+h4CBMqG +l8du3d6j4eVMjRm7Eq/zfD8DXtjVfQ8SoX6TLz5vG0rkeHFnmZVyNa6RYMVV5q0E7qz/4QR B8tr4oB8X2XbjDl0GIBwvrG2NE2O5medTRfmqYbqocSRZxs40XanDWuyLOhC3UzNCk4Gs99r mwMZUflSG1IZMHTMX3djCNkxmysoITDGFmXAuIYhGE2MOUQYTNTk416O11VLHP5bYqfdVjht z4q9NSx1XdIQKzn3PfDWxH0kfUVRFPwpBpajQKFddQpuIjCUVVFUxGQYVUFBohSRZ6sD7SGz bO0dhtGQiwny8ORgdo6kc4FxiB5BQfsvCJZ6yg9ggFkA+ZAOXqn0c/rPUT5w5k/n7p81hShL y+wDO+orh67hMV6Q21M/YdXrIEYyQkfqFCgPGdlK1KIUcoSWChN3CaFk3bwQIqi3wjrOhqnQ X8qnQNFG8TcxoIn1zcMEJGGoE5w1gFs/zO33CZ/dWhBRIEEgEFIkRBiqH299aJwQKopKiUdX ODA3pwuL39TZRaeUbEnNM1GKEE7AgUBjmmSWW8YFl92dwzAMcgE/PAHDVkZuhxmYJQYHufQZ EQkFSLsxdmYaTcXJAwDDkqUfk2ipS2gWzmxrud2mWEB21BFGWxptFnRUMBMonYY+p9AX4QGS Q749DLBLGScUVIwQU8aFSELCFUeWsH8ZRIe9gNDYwsUBskCKNNtbSPztJZUiCPMheWSTkmwe kMiyHgo4Nl6ekOU6mdTFXxM8FzHu9J+cmRx99KYvkJm458glgsLCKhxNXyz5OQm52u7hMM02 W6aWUK4kgAQ/2npDgB6QE4p8iG7ovcRNlDy6gORnMKTVQ7zPaJ+IUNApCEQvmWE+AuIdg5gy UTOq8xfjcJM4O/aSPblQ4RSjUUpwskBPEYQa4HAMDZNjt4GIGbguKdnTiicCKf1cxXwmjAQ4 AagGYmihsOYmDhaYeBhLGKShAseFjGAiAE3MEdZZjk4HCcYBCLInkToOosReEA5KK7niCtQA Dx7b8gcz/zQzC2+SDIG7UR7gB0gJmmvVvwD1niBufLX1WKzUnk7dzzrV2xDwYYARwNy1lIRY ySBGQJB5SVxYYipx6B2Q9HoogDwcVvhPJ5/OasYvyeUo9zwdDnr+t+2QUaOgpAIvrswsRWsn TxrzfYB2ysK8TxnJDzmNud5w/WPIlyjcmDE8exu6iirIU3GIRHEgCQYCbSZDix6zIL7rDWFD QuQypjSdiCYAuB1ILX4kwCnCSGMCdJJBuxuEYkMECulJ1w/IeR7TmesU+w73qQMW1MkqhDxY sSwPtCwIUIezEIMkIBGRaUsNKU0DKVLg0FH1kKLoUphlJJKRuE9ohlMsFQD5fzoqKrGZyBgg MkwaQ757eo8TeQbelCEniIvDyUKhETDUSiEg3yILUBTZiDEf7B6A0O0SoF/IDWueaJux4mrC ZBMqNAM5MrM1FWMRESZXN4b0RQRRiKqKqqqKpEkmwdT6HT+V76KB77JaIyAH5L/f5pQifAnM QfUEAW7uPf4VqG1rVYgsIDCt51OqYJ8mcQwM4T37YGRs0ufeFLj3rm4sGgp3BoaOh7BN/A4A Q+t+2TUHC9CI+HRSTf07X6mAxgxlWlYMKwaFUBEdfvd4w7nabigQlBSjIJIB56oCTYab3gI0 wMmFatKQnLDX4c5QXMBL3IrlUoYCiHB2ZwWsDt21YjvS9UMG9NBqa8QO0mWX8iF/BBdEW3eJ GLlHUDVh6sKP8bjzBx8WxxzaAMnDQIzOVCu7p2HIJDJP4A6lgU+jUzIeU1LIMgbzbWZlwjn4 6wtS6hvokWzEKKysGxIcBR16bjD2EB+gCwMEK1Ow0gzMGBnQAoKnvsBADwkRF0mY/eIHs2Fw JnJ2gsBHa1GgRggTAxdOUCY6umnHDj6aAfXQ05MLuy5ijKrvPHehnD0JvFYowZsYlI57I4oS JpVEpV+Xql1Ta6GHV3xgKHwKM2NFtoNhYFlAoNpZuESisSFOKEyQuaUtYBlUBTkkLGl3B4Rw DMmQUETFSLIsgH0kEkFbChgPdNIF0B6KXhjqSoXjvhPDFtdUDvyxYpDxW67hkBxh85ses+Og YAb7gkF2GVvjKKPf8168viG8KYTSmgysdWzfemhtlAggcdSY5yVQlZXVRo5593lcXv9II6Bx AOYQUTaXJziHoAKFpMOwUpoRfOOyR+CQycoFas0oiJGKIolRlCj9DKEQZ5YUdBDWmo4jSfVX CF2ihgVSppJRYqMJNO1nOYhTC9AzGVUB94UjRIRtFN+ikGMbeeEXXCiTEWIiTzHUqzE1pmho NDSMJI4jbIbIRtmQjQmNec+NkBoEkcF0Cw7zAthowpFxNKNSZRDID1hkGry+oUPMgoIeAXCU HJSCqwdJoROzkN9GXQyEyi6PYI0d+BmZJCQgR1BUnPrdqyHQX1H6+Z9uHFrxDObdFbTuhAPl NjcYgcS6JUtbwu0jk+Rrj4fR+q/AltweN6PvFdhNnKTE+vFqV+BVcScoNdhlyINLtFmk1RkL +1O86Gr6tdDq1Pfx6NRyb9RtVQVUGq5ED86vUVU0jrNnfiGklOt9AiAym2uz7TqYzirIV6TG h1EnUUamHNFFnzBYRDo1ZCFJSqlDsBw5rqUtpuRmgKwcs4Cx1EnLZue7bS26rfHuuf78Oq9C C9qMxLAo3Z0wzZ7rDdckkb4YkIwe2Y5udNDfYHMEA+yBgoEBSGp1y4RkqtEcoSOXIz04F1IH uqwRcJvfRKvSn9seHPCcC+MMYyu4DIqxdkkNjGhdcVrSdiDmmozWdxjTtjMSTkrg1liZcHBU SKXKUDoHQ1KFwSeFE/GY6CkLNWLYjHNujlSe/46ZIxBCMQ8f26tRFFM4gd3bqQDU9oO28F+8 8jAsX/Lpg5njA0R1iefs0Tqc3Zx7RWMbOffRqCbg1yS4ZczVUlVTDvMqOvfRzsU7tJj3A63s 8bfu4aQzG/zkkvJZuIRVURE3H2TU1KpKhp1Ac2whAObZNYNQeWjw78t4d1elhb5UVDIRqDDw Fr4O/pcPO/UsSF3KStLTGwfgzoDy9KdP+n2PeDiOUFhtFbff6Ik/seaFh4UsdZvLBtWQwGcO iW9mGgzpRQNVDkBzMD0mgPxfp+GTm5g1P2JYQ1IIEU2X59HfIwCEO5iMUsJ0kpddBqnBunTO r3GEgFhdjdDD52ilmCqiM6ISBQH6sAmzx2cYDlFRqHdLZ1LR+Ho4Qvxv8hRYNBWfaoz/dMME 0U7Q4oBE8WwfAj2w2X2YIwbGBx3JQNhoDSNtsNC9V5x4QwguUE3EQYhuYSokEYGDFa0FgSwN Rg3GBgewkCtQN/x9mV9QN6cmOfBHURcTKIwgBgKct4XTQPwh91vLkBWJzNXeWGGl/hs/EKIQ 5y3k1tGpgQaiXGNkYFGt14OQLMifE9AGMBDOIhJ8rAFWQyHzXRTCB9UpTDCt4Nx1IBcTLBhG RSUHNlGbB4TiAsGJlQcgr7gbfA3oYPyRAmwEQhkxS4YfCIG7X4x0InFNVOsJw969SQwro1j1 9ZRyibCFuQQojiaLjczXR2zuCMgoQiBICN/vlk3VgnQnRD06onR4nuOYFlkyOgC9v6zILvUm 9MJEnQIPGc04oTkvPxHGGV5Y8GaOUbUn9usIZOt5mNQm3PDi8UidLQwL87GJj5mhsWzJNzaf EGzYhPQ4MgA9x6TcCIGVCcCLYGdlJYinCB72r37lG+MiQCDJdSLxjAN9zRo62UEIWhngXjWA 4A1GJsmSOMFyTLpwYKnU3BWG4UihLWVTPsvVHCleRFT4jbC24659wyhzhyalIybfDfAmIxBR YxZMdhydezzkXTrmTlyo+TYXUcZSVLfBdZboT3DI7yawurkn0SpgKbni55eGEHx3eJRR4bF1 Oj0NNYR+A4aaX56UsF4cIBFA/3H8w7CgogXAT+EShV32nYKEXhbh756AYi4EEvPGjzzPqvWN tBAYNQGpEEaNqgTuNNnIdMVzwBpJBRRRQBEFEQjMFAVirHFz/7sKryEPRvJguFy1vWQUYUHH N5ccFisS0Zbha9Td1oxwTJCE5DOpyI7fRl2u53wdiXiI8RsBrjYp6JXTnKsdyVeQogp5EMWF RyQqMWFpCgpCDGAUESJbAxC/mBxs4GShkIcUzW7GZlGGthnm+dDne4Bao0hRcLPJFxHUs6kE QiIGTmRtYkYCLiitJCajGRwzTNr3kHaHOgPX7s7DlQ90c0MIGMIxINJoCRWo8BA1Oavq8AsN u6B1Z0DCLRIGDrmwGaiBqS/UW7ngHt7HcD/RifiAexoYsXCZ1vK+65tdHalMWPNCCCPWGRkA K4HDf6xMgb0s+TMHBAbrwjQMNJoBq5XQe2MgMqYNKO2GsvQNczzY4a+pDYiA7AIRAMWPYyUL FTcyLI75lW2rhsLUbThR1ZlWQjxldMMLeECDyjW0ljfAAIMVCMEVI6nUGVTrMxcxktsha9fj FzxchhP7tVG1k3/YWG/6daI7ZC4NFArowQ+qkC8RbWAMxCTBptiAZuCCGsHQmXmmmQeMDbR0 u84JsIIhBQIxjCRBMygpUdwW0sT1sYa78MFTTNQ7YZkpL00DiH4qHNE8MbzwFehO8hfLReHP eBzU5cUC9ArcICYMBQkUC1SMEBEkisGSMQREFgwRpMaGJiowImGRjMqARViUGsBoSRFN4bjB sLvO80PCPOQh+aOc/BxoLwpiVELqpwhZiYwTfhkRtQFc4gZQFgIXUPrB8Ie5Pr+A5t5TfAjs ZmXHN0C7hvPUqvyMAG7W+GjM/nu+Az18cGmaCuyCauUEGJJQ0GvbVDIInXiAUL3aCojiTF6F bR9YAWL6gF0xAsusAuHmHqeOCRfJ7DmKtRlZbA+VHlMUINmNA5BUUEI3sfOLg5BYi0ysU7/Q dcyBsh9s2ItvIoLQ1hEsh0SZeYlk6j67Ynujj5i5PhBrT0MTnp7ZRUSU0hRPAON6LtxqxTEK ehfqZEw5JR0DGbdNKIIGwaiiguGHDHYmWJJLKvIqW8QkEWBFAh03TvI3IoGAxAHEQglmSAwi lh7zXE7mxsnXkcY62eEqiF9NEQlU0sjq8S5j0hyGkMuDzGsHcN/ach29oI3Q2jqEkUhBJAWR VOFFoYIW9xu0c8TqEIBIihAzjpjwTDjAmFfOKjSZJ0EG1rBYPBj3YqvXspvR9SetN9O+Qj1e hTaye3CxfcNPaZaxRWMQVBGMTcDQogwRFioMZoJQiAj2G+FksQzklJRGg9jCwhix7GfvJfDy VoHMG6oe45XTXEOtFK5GCgUAz4CiTiC1KIsKDzUsqwYBcUENRIum+wlnY6RT44LIMYEC5u9q jpFIqosgfDd3vE+DKsdlBzDZphs3cKq9slmWrOi52p7oFQMM2g8jCiR6IRhmwuCbUc63VgMY oSKg9JiokYSX0hIyC1gOnUs7rueboTU4Dc1xGJLHhzPaQUTQ/docwc8zMUgREIMsEUoLohmz vA9vZA0O7n4JojoP7RFeDnK4EpoWq2mDAGobC4qQndEgzojqjyg/RS9WZJg9Ns5+h2Nb0muI w5hQzpNdPas0lhBdNWW0vJDvc9Hzvp0cOJjq6D5rg2lRijEkWc8rlZsXRy9lJuWqugvHkxmh R0yFVzG20KiaJbHgqz0yo5JQlrNhoSqvzXkMzQgcXILGoQeVhJ1LMfKJQHlsnuDdkPCqKsEo 4FjVI9jDhptb5nk7mjtBm2gk6pFvDt/G6bgcENQ60RAoqHAvVFgGD0GSDIRhhajRoDgmm7Ow 3OcMCJ8jE/i0BWjacImRuBSyrvLtyHJ0xtzIfL42SzWJjZorEccQZmhzAmc6mSTQDWIawo8Q y0Z66KBGRHEoKBG6KiII2J2FllvYMu7QnVqqtRaFgOgQS/KgVu2yDvCSKZFUUkX3i0XzNBnO +VhnKVNRLgkZAasihTAaLEhK3o9QlztiDvGyd/AK6SQuAxw6U6BYFtYMXI+nIWztQFVVDEe5 G4Hmq19uFGXgYppv4XLhp6c5DBoPAATbLO1B2EIFTtH7pIalSeiSXa4ORqQc5i5xde5CAnpo 1z15Gy4Ac1e1Tnrl21KojBA7OrniaRRM9sXrUeuG5coMIyCK+i+9DV6m9cVjcJWhjbZgRZDY BlKd6hTTYXZYnVQmjKNaGiyEcyBDfkru87c4c4cfEuCgdvpOXGeGyBk1bQ7O2fULkXJgGZqa u8gNgpwSAJhrkSOJraQI84AeqKcopngFZ1ut1KIVcwzKK2O8OBcOEVhFVexoFBXIo1tdsQdD IKSzYHjZFDgln5iGlDdiSASAJrEvoQkgpkGtDJhxw6bGTl3G2a09EI40jiaVeWhtA0/pOMr1 HxtYh0aBOkHgRpIgRnJXACopjGualx4dtjDvIkQ5UlAeA5donBgoTiRMYFR0NiUloUQN4MBC ymZwyKKGHsL9ac5mrLgjwARACg7a0aEejUaiHVBUkRPDmdA8RQ7hf65tDd89hxD0H1xE6w6U D9WIYh1iMiyQj8hwub+mZ8KD04psloQnnKZpab3lbrbMU6AzuCzfKVPORVt+hoHYKcdGkvLW LBn32O67tDaYgy/4vh4Gj2se3fEgyehTSg6Ed5OXh0FjiUXbLJzLRGEjDMLVF/MoXMi3Sh3M QxDkHkDRcY4vXAJkek9EGQIyFDoQAxLUdIgchil/YlBUMiTM6gT6SEEh9eBQAiELtBRgFi2/ 5mdrFA5RH19gO5hJMzwhOlw7XSyFaesZxmNVEkBwF6b7V3Eu+iop3PZ7yHm3w4CAyTjVpU+W SFogF0E+8GQATxIB2QZMoBoxJGT0MAtFiMIaIiukQkf/F3JFOFCQbOhtpQ== --------------1E9C7A1D72A7A74CB3F88EB0-- From owner-kdb@oss.sgi.com Thu May 2 05:30:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42CU9wJ005428 for ; Thu, 2 May 2002 05:30:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42CU8eP005427 for kdb-outgoing; Thu, 2 May 2002 05:30:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42CU3wJ005424 for ; Thu, 2 May 2002 05:30:04 -0700 Received: (qmail 24606 invoked from network); 2 May 2002 12:31:02 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 May 2002 12:31:02 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 839593000B8; Thu, 2 May 2002 22:31:00 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 5C38AA0; Thu, 2 May 2002 22:31:00 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ethan Solomita Cc: kdb@oss.sgi.com Subject: Re: SMP patches for kdb In-reply-to: Your message of "Thu, 02 May 2002 00:43:15 MST." <3CD0EE13.BA524553@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 May 2002 22:30:55 +1000 Message-ID: <29099.1020342655@ocs3.intra.ocs.com.au> Sender: owner-kdb@oss.sgi.com Precedence: bulk On Thu, 02 May 2002 00:43:15 -0700, Ethan Solomita wrote: > I should also say that I didn't tackle the issue of user breakpoints >hitting into kdb, and thus slowing things down. With my changes, on >i386, a user breakpoint is the same as a kdb breakpoint and so kdb will >first be entered, and now it'll assemble all the CPUs before it decides >that the breakpoint isn't a match. I guess this could be a nuisance for >some users, but you can always turn kdb off (ie. set kdb_on to 0). >Problem solved. If this is really critical to someone, we can deal with >it, but no one has really argued for this. Thanks for the rework, I will look at it over the weekend. However I know that the kdb/gdb interaction on breakpoints is a problem, it is why I rewrote that section. The original implementation entered kdb and grabbed all cpus then found it was not a kdb breakpoint (i.e. user space), then it released all cpus and continued with user space. Using gdb on a machine with kdb active was horribly slow. We have to find a way for kdb to quickly decide if the breakpoint is kdb or gdb. From owner-kdb@oss.sgi.com Thu May 2 20:46:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g433kCwJ026680 for ; Thu, 2 May 2002 20:46:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g433kCmW026679 for kdb-outgoing; Thu, 2 May 2002 20:46:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from linux.local (h00e098094f32.ne.client2.attbi.com [24.60.61.209]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g433jrwJ026675 for ; Thu, 2 May 2002 20:45:53 -0700 Received: (from jhouston2@localhost) by linux.local (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id g433oHe01117; Thu, 2 May 2002 23:50:17 -0400 Date: Thu, 2 May 2002 23:50:17 -0400 Message-Id: <200205030350.g433oHe01117@linux.local> From: Jim Houston To: jim.houston@attbi.com, kdb@oss.sgi.com, ethan@cs.columbia.edu Subject: SMP patche i386 Sender: owner-kdb@oss.sgi.com Precedence: bulk Hi! I picked up Ethan Solomita's changes and did the first cut at getting it to work on the i386. I have attached the patch for kdba_bp.c. There are still a few rough edges but I ran it through a bunch several breakpoints on my old dual Pentium Pro and it kept going. I still worry about access to kdb_state. I was thinking it would be nice to separate the flags that are used for synchronization from those that are only of interest to the local processor. This would make it clearer where we need to have to have spinlocks or other magic. Jim Houston - Concurrent Computer Corp. -- diff -urN old/arch/i386/kdb/kdba_bp.c new/arch/i386/kdb/kdba_bp.c --- old/arch/i386/kdb/kdba_bp.c Thu May 2 22:23:52 2002 +++ new/arch/i386/kdb/kdba_bp.c Thu May 2 22:23:42 2002 @@ -95,43 +95,6 @@ if (KDB_DEBUG(BP)) kdb_printf("kdb: dr6 0x%lx dr7 0x%lx\n", dr6, dr7); if (dr6 & DR6_BS) { - if (KDB_STATE(SSBPT)) { - if (KDB_DEBUG(BP)) - kdb_printf("ssbpt\n"); - KDB_STATE_CLEAR(SSBPT); - for(i=0,bp=kdb_breakpoints; - i < KDB_MAXBPT; - i++, bp++) { - if (KDB_DEBUG(BP)) - kdb_printf("bp 0x%p enabled %d delayed %d global %d cpu %d\n", - bp, bp->bp_enabled, bp->bp_delayed, bp->bp_global, bp->bp_cpu); - if (!bp->bp_enabled) - continue; - if (!bp->bp_global && bp->bp_cpu != smp_processor_id()) - continue; - if (KDB_DEBUG(BP)) - kdb_printf("bp for this cpu\n"); - if (bp->bp_delayed) { - bp->bp_delayed = 0; - if (KDB_DEBUG(BP)) - kdb_printf("kdba_installbp\n"); - kdba_installbp(ef, bp); - if (!KDB_STATE(DOING_SS)) { - ef->eflags &= ~EF_TF; - return(KDB_DB_SSBPT); - } - break; - } - } - if (i == KDB_MAXBPT) { - kdb_printf("kdb: Unable to find delayed breakpoint\n"); - } - if (!KDB_STATE(DOING_SS)) { - ef->eflags &= ~EF_TF; - return(KDB_DB_NOBPT); - } - /* FALLTHROUGH */ - } /* * KDB_STATE_DOING_SS is set when the kernel debugger is using @@ -143,6 +106,16 @@ if (!KDB_STATE(DOING_SS)) goto unknown; + if (KDB_STATE(DOING_SSBPT)) { + if (KDB_DEBUG(BP)) + kdb_printf("ssbpt\n"); + KDB_STATE_CLEAR(DOING_SS); + KDB_STATE_CLEAR(DOING_SSBPT); + /* do we need to restore EF_IE? */ + ef->eflags &= ~EF_TF; + return(KDB_DB_SSBPT); + } + /* single step */ rv = KDB_DB_SS; /* Indicate single step */ if (KDB_STATE(DOING_SSB)) { @@ -321,7 +294,7 @@ i, ef->eip); kdb_id1(ef->eip); rv = KDB_DB_BPT; - bp->bp_delay = 1; + KDB_STATE_SET(NEED_SSBPT); break; } } @@ -330,56 +303,6 @@ } /* - * kdba_handle_bp - * - * Handle an instruction-breakpoint trap. Called when re-installing - * an enabled breakpoint which has has the bp_delay bit set. - * - * Parameters: - * Returns: - * Locking: - * Remarks: - * - * Ok, we really need to: - * 1) Restore the original instruction byte - * 2) Single Step - * 3) Restore breakpoint instruction - * 4) Continue. - * - * - */ - -static void -kdba_handle_bp(kdb_eframe_t ef, kdb_bp_t *bp) -{ - if (!ef) { - kdb_printf("kdba_handle_bp: ef == NULL\n"); - return; - } - - if (KDB_DEBUG(BP)) - kdb_printf("ef->eip = 0x%lx\n", ef->eip); - - /* - * Setup single step - */ - kdba_setsinglestep(ef); - - /* KDB_STATE_SSBPT is set when the kernel debugger must single step - * a task in order to re-establish an instruction breakpoint which - * uses the instruction replacement mechanism. - */ - KDB_STATE_SET(SSBPT); - - /* - * Reset delay attribute - */ - bp->bp_delay = 0; - bp->bp_delayed = 1; -} - - -/* * kdba_bptype * * Return a string describing type of breakpoint. @@ -714,10 +637,6 @@ kdb_printf("kdba_installbp hardware reg %ld at " kdb_bfd_vma_fmt "\n", bp->bp_hard->bph_reg, bp->bp_addr); } - } else if (bp->bp_delay) { - if (KDB_DEBUG(BP)) - kdb_printf("kdba_installbp delayed bp\n"); - kdba_handle_bp(ef, bp); } else { if (kdb_getarea_size(&(bp->bp_inst), bp->bp_addr, 1) || kdb_putword(bp->bp_addr, IA32_BREAKPOINT_INSTRUCTION, 1)) { From owner-kdb@oss.sgi.com Mon May 6 07:49:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46EnDwJ019119 for ; Mon, 6 May 2002 07:49:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46EnD2m019118 for kdb-outgoing; Mon, 6 May 2002 07:49:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46En9wJ019099 for ; Mon, 6 May 2002 07:49:10 -0700 Received: from attbi.com ([24.60.61.209]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020506145022.HGMQ2627.rwcrmhc54.attbi.com@attbi.com>; Mon, 6 May 2002 14:50:22 +0000 Message-ID: <3CD69913.8DF9A523@attbi.com> Date: Mon, 06 May 2002 10:54:11 -0400 From: Jim Houston Reply-To: jim.houston@attbi.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: kdb@oss.sgi.com CC: jim.houston@attbi.com, ethan@cs.columbia.edu Subject: Re: SMP patche i386 References: <200205030350.g433oHe01117@linux.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Hi Ethan, Keith, I played some more with Ethan's MP patch over the weekend. I still have major problems on the i386. It's been an interesting tour of the code. The real problem is the non-maskable part of the non- maskable IPI. When there are multiple processors hitting breakpoints at the same time, you never know how much of the initial entry code the slave processor got to execute before it was hit by the NMI. I have a couple of ideas in the works. First, I wonder about having the kdb_ipi() check if it has interrupted a breakpoint entry. If it has, it could just set a flag and return. I might do this with a stack trace back or by setting a flag early in the breakpoint handling (e.g. entry.S). I also wonder about using a normal interrupt rather than the NMI. Ethan, I'm curious if you're using an NMI on the Sparc. Jim Houston - Concurrent Computer Corp. From owner-kdb@oss.sgi.com Mon May 6 12:45:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46JixwJ028514 for ; Mon, 6 May 2002 12:45:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46Jix65028513 for kdb-outgoing; Mon, 6 May 2002 12:44:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46JiqwJ028509 for ; Mon, 6 May 2002 12:44:52 -0700 Received: from cs.columbia.edu ([12.234.195.52]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020506194606.UQIE2627.rwcrmhc54.attbi.com@cs.columbia.edu>; Mon, 6 May 2002 19:46:06 +0000 Message-ID: <3CD6DD85.CA1314E1@cs.columbia.edu> Date: Mon, 06 May 2002 12:46:13 -0700 From: Ethan Solomita X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jim.houston@attbi.com CC: kdb@oss.sgi.com Subject: Re: SMP patche i386 References: <200205030350.g433oHe01117@linux.local> <3CD69913.8DF9A523@attbi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Jim Houston wrote: > > The real problem is the non-maskable part of the non- > maskable IPI. When there are multiple processors hitting > breakpoints at the same time, you never know how much of > the initial entry code the slave processor got to execute > before it was hit by the NMI. > This is what I explicitly considered fixed by these changes. In kdb(), line 1342 is the beginning of the code where kdb_initial_cpu is grabbed. After this block, you either are the kdb_initial_cpu, or you entered kdb because of the IPI. So the future-slave-proecssor could not have gotten past this if () clause before it was hit by the NMI. Looking back before this, there are very few lines of code that examine global state, and none that modify global state. The few references to KDB_STATE before line 1342 can, I believe all be justified. Either the code knows that it is kdb_initial_cpu, or it is DOING_SS in which case we cannot have received an IPI from KDB, or it is HOLD_CPU. HOlD_CPU is used to generate "reentry", and I'm not sure why, but it seems harmless. Can you suggest a code path through kdb() which could lead to harm for a CPU which hits a breakpoint, fails to win the race for kdb_initial_cpu, and gets an IPI? > I have a couple of ideas in the works. First, I wonder about > having the kdb_ipi() check if it has interrupted a > breakpoint entry. If it has, it could just set a flag and > return. I might do this with a stack trace back or by > setting a flag early in the breakpoint handling (e.g. entry.S). I don't see how this helps -- whoever won the race for kdb_initial_cpu is expecting all the CPUs to gather up and enter kdb. I would expect that everyone who hits a breakpoint should enter kdb. > Ethan, I'm curious if you're using an NMI on the Sparc. > Sparc doesn't have an NMI, but the interrupt I use (an IPI) is rarely blocked in the kernel. Certainly not blocked by local_irq_save() and family. -- Ethan From owner-kdb@oss.sgi.com Mon May 6 15:11:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46MBXwJ029866 for ; Mon, 6 May 2002 15:11:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46MBXcO029865 for kdb-outgoing; Mon, 6 May 2002 15:11:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46MBOwJ029861 for ; Mon, 6 May 2002 15:11:24 -0700 Received: from attbi.com ([24.60.61.209]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020506221219.DOJC9799.rwcrmhc51.attbi.com@attbi.com>; Mon, 6 May 2002 22:12:19 +0000 Message-ID: <3CD700A5.1A6F8E85@attbi.com> Date: Mon, 06 May 2002 18:16:05 -0400 From: Jim Houston Reply-To: jim.houston@attbi.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ethan Solomita CC: kdb@oss.sgi.com Subject: Re: SMP patche i386 References: <200205030350.g433oHe01117@linux.local> <3CD69913.8DF9A523@attbi.com> <3CD6DD85.CA1314E1@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Ethan Solomita wrote: > > Jim Houston wrote: > > > > The real problem is the non-maskable part of the non- > > maskable IPI. When there are multiple processors hitting > > breakpoints at the same time, you never know how much of > > the initial entry code the slave processor got to execute > > before it was hit by the NMI. > > > This is what I explicitly considered fixed by these changes. In kdb(), > line 1342 is the beginning of the code where kdb_initial_cpu is grabbed. > After this block, you either are the kdb_initial_cpu, or you entered kdb > because of the IPI. So the future-slave-proecssor could not have gotten > past this if () clause before it was hit by the NMI. > > Looking back before this, there are very few lines of code that examine > global state, and none that modify global state. The few references to > KDB_STATE before line 1342 can, I believe all be justified. Either the > code knows that it is kdb_initial_cpu, or it is DOING_SS in which case > we cannot have received an IPI from KDB, or it is HOLD_CPU. HOlD_CPU is > used to generate "reentry", and I'm not sure why, but it seems harmless. > > Can you suggest a code path through kdb() which could lead to harm for > a CPU which hits a breakpoint, fails to win the race for > kdb_initial_cpu, and gets an IPI? > > > I have a couple of ideas in the works. First, I wonder about > > having the kdb_ipi() check if it has interrupted a > > breakpoint entry. If it has, it could just set a flag and > > return. I might do this with a stack trace back or by > > setting a flag early in the breakpoint handling (e.g. entry.S). > > I don't see how this helps -- whoever won the race for kdb_initial_cpu > is expecting all the CPUs to gather up and enter kdb. I would expect > that everyone who hits a breakpoint should enter kdb. > > > Ethan, I'm curious if you're using an NMI on the Sparc. > > > Sparc doesn't have an NMI, but the interrupt I use (an IPI) is rarely > blocked in the kernel. Certainly not blocked by local_irq_save() and > family. > -- Ethan Hi Ethan, I have been in hack mode, and I probably have some self inflicted problems. Your analysis seems correct, but I still had problems with the combination of your patch + the version kdba_bp.c that I sent out on Friday. I did not mean to impugn your patch and appologize if I have. The initial enthusiasm wore off once I started putting breakpoints at places like do_schedule or sys_open. More often than not, it hung. I also ran into the panic processing breakpoints that have been removed. They are described in the comment before kdba_db_trap(). It still hung even doing bd instead of bc. I went on to experiment with splitting the kdb_state into separate variables for the per-cpu-private vs inter-cpu synchronization. I was hoping that I could simplify the problem by eliminating the interactions between most of the flags. I was worried about interactions between processors leaving kdb and new arrivals. Regards NMI racing with normal breakpoints - I want to solve a larger problem. If I can avoid the extra layer of nesting, I will solve the deleted breakpoint problem. It seems ugly to switch to the other cpu, do a stack trace and see part of kdb rather than what that cpu was doing. I would also like to switch to the other cpu and then single step. I also worry about what happens if the NMI interupts the spinlock which protects kdb_initial_cpu. I have some changes maybe 50% done. I'm using a flag set in entry.s to detect that the NMI has interrupted the breakpoint entry. Hopefully I will have something useful in another day or so. Jim Houston - Concurrent Computer Corp. From owner-kdb@oss.sgi.com Mon May 6 17:45:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g470jiwJ031216 for ; Mon, 6 May 2002 17:45:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g470jiC4031215 for kdb-outgoing; Mon, 6 May 2002 17:45:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g470jZwJ031203 for ; Mon, 6 May 2002 17:45:35 -0700 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 6 May 2002 17:46:50 -0700 Received: from cs.columbia.edu ([10.2.4.63]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 6 May 2002 17:46:49 -0700 Message-ID: <3CD723F6.476CD789@cs.columbia.edu> Date: Mon, 06 May 2002 17:46:46 -0700 From: Ethan Solomita X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: jim.houston@attbi.com CC: kdb@oss.sgi.com Subject: Re: SMP patche i386 References: <200205030350.g433oHe01117@linux.local> <3CD69913.8DF9A523@attbi.com> <3CD6DD85.CA1314E1@cs.columbia.edu> <3CD700A5.1A6F8E85@attbi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2002 00:46:49.0832 (UTC) FILETIME=[AC3B5680:01C1F560] Sender: owner-kdb@oss.sgi.com Precedence: bulk Jim Houston wrote: > > I have been in hack mode, and I probably have some self inflicted > problems. Your analysis seems correct, but I still had problems > with the combination of your patch + the version kdba_bp.c that > I sent out on Friday. I did not mean to impugn your patch and > appologize if I have. > I wasn't upset that you were impugning the integrity of my patch 8), I was just concerned that I'd rush out something that didn't work, and was anxious to find the cause. After your email I did find a dumb bug. At line 1374 of kdbmain.c (with my changes) you need to add: kdb_initial_cpu = -1; KDB_STATE_CLEAR(RECURSE); In the early exit case: "hit a breakpoint but can't find a match", this code was previously before kdb_initial_cpu and I didn't change things to ensure that kdb_initial_cpu is cleared again before exiting. At this point, my 2p system is stable, but my 8p is still seeing some issues, which I'm still looking into. > The initial enthusiasm wore off once I started putting breakpoints > at places like do_schedule or sys_open. More often than not, it hung. > I also ran into the panic processing breakpoints that have been > removed. They are described in the comment before kdba_db_trap(). > It still hung even doing bd instead of bc. > My fix above may help with this, although it's not the only issue. Setting a breakpoint at cpu_idle+0x20 (which is inside the main loop, ie. an idle system will hit this constantly) I have no problems on 2p. On 8p I have no problems with "go" after the breakpoint, but after I delete the breakpoint and "go", I still have some unreliability with re-entering kdb. > I went on to experiment with splitting the kdb_state into separate > variables for the per-cpu-private vs inter-cpu synchronization. > I was hoping that I could simplify the problem by eliminating the > interactions between most of the flags. I was worried > about interactions between processors leaving kdb and new > arrivals. > It is true that a lot of these flags may not need to be this way. I took REENTRY and just turned it into a local variable within kdb(), since the value isn't carried over between calls into kdb() and isn't used outside of kdb(). There may be other such "opportunities". But as to interactions, no one should set anyone else's state until all CPUs are under kdb control in kdb_main_loop(), and no one should set one's own state until you either own kdb_initial_cpu or you are in kdb() due to an IPI. If this isn't the case somewhere, then I missed it. > Regards NMI racing with normal breakpoints - I want to > solve a larger problem. If I can avoid the extra layer of nesting, > I will solve the deleted breakpoint problem. It seems ugly to > switch to the other cpu, do a stack trace and see part of kdb > rather than what that cpu was doing. I would also like to switch > to the other cpu and then single step. I also worry about what > happens if the NMI interupts the spinlock which protects > kdb_initial_cpu. > My only concern is that this hides the truth of the situation -- the truth being that, when this CPU entered kdb, the other CPU was really in kdb too. But there are benefits to this, too. Perhaps the best idea is to try to avoid setting breakpoints where you are *likely* to hit it on a second processor before the first has managed to send the IPIs. -- Ethan From owner-kdb@oss.sgi.com Mon May 6 19:23:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g472NdwJ032107 for ; Mon, 6 May 2002 19:23:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g472NdU0032106 for kdb-outgoing; Mon, 6 May 2002 19:23:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g472NcwJ032098 for ; Mon, 6 May 2002 19:23:38 -0700 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 6 May 2002 19:24:53 -0700 Received: from cs.columbia.edu ([10.2.4.63]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 6 May 2002 19:24:52 -0700 Message-ID: <3CD73AF4.28AAC77@cs.columbia.edu> Date: Mon, 06 May 2002 19:24:52 -0700 From: Ethan Solomita X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-SGI_XFS_1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: jim.houston@attbi.com CC: kdb@oss.sgi.com Subject: Re: SMP patche i386 References: <200205030350.g433oHe01117@linux.local> <3CD69913.8DF9A523@attbi.com> <3CD6DD85.CA1314E1@cs.columbia.edu> <3CD700A5.1A6F8E85@attbi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2002 02:24:52.0886 (UTC) FILETIME=[5ECE2360:01C1F56E] Sender: owner-kdb@oss.sgi.com Precedence: bulk As an update -- the other problem I was having with my sparc64 8p system was an I/O driver related issue, not a kdb thing. With the two-line fix I just emailed, I can't reproduce a problem on my sparc64 8p anymore. Jim -- do you have any specific sequences of kdb commands that typically make things go wrong? Do the problems still occur when you set kdb_flags to 0xffff0000 to get all the debugging info? -- Ethan From owner-kdb@oss.sgi.com Mon May 6 21:54:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g474snwJ001604 for ; Mon, 6 May 2002 21:54:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g474sn54001603 for kdb-outgoing; Mon, 6 May 2002 21:54:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g474siwJ001600 for ; Mon, 6 May 2002 21:54:44 -0700 Received: from attbi.com ([24.60.61.209]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020507045559.UQHK2627.rwcrmhc54.attbi.com@attbi.com>; Tue, 7 May 2002 04:55:59 +0000 Message-ID: <3CD75F3F.5B5A6E0F@attbi.com> Date: Tue, 07 May 2002 00:59:43 -0400 From: Jim Houston Reply-To: jim.houston@attbi.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ethan Solomita CC: kdb@oss.sgi.com Subject: Re: SMP patche i386 References: <200205030350.g433oHe01117@linux.local> <3CD69913.8DF9A523@attbi.com> <3CD6DD85.CA1314E1@cs.columbia.edu> <3CD700A5.1A6F8E85@attbi.com> <3CD73AF4.28AAC77@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Ethan Solomita wrote: > > As an update -- the other problem I was having with my sparc64 8p > system was an I/O driver related issue, not a kdb thing. With the > two-line fix I just emailed, I can't reproduce a problem on my sparc64 > 8p anymore. Jim -- do you have any specific sequences of kdb commands > that typically make things go wrong? Do the problems still occur when > you set kdb_flags to 0xffff0000 to get all the debugging info? > -- Ethan Hi Ethan, I just built a kernel with your SMP patch + my patch to the arch/i386/kdb/kdba_bp.c + your 2 line fix. On the first boot I let the system come up to multi-user When I hit pause key it hung. On the next boot I hit pause while the system was still booting. I got in to kdb o.k. I set the kdb_flag to 0x420000. I let the system continue and start X. I got back in with the pause key. I set a breakpoint at sys_open and continued several times. I disabled the breakpoint and did a go. Hit pause re-enabled the breakpoint. I repeated these steps a few more times. It seemed to be working. I changed kdb_flags to 0x20000. Still working. I disabled the breakpoint, did a go, pause again, cleared the breakpoint. then I cleared kdb_flags and did a go. Another pause and it was hung. Any idea why it hangs with the debug turned off aside from Murphy's law? Jim Houston - Concurrent Computer Corp. From owner-kdb@oss.sgi.com Tue May 7 02:05:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4795NwJ004914 for ; Tue, 7 May 2002 02:05:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4795NkR004913 for kdb-outgoing; Tue, 7 May 2002 02:05:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4795JwJ004906 for ; Tue, 7 May 2002 02:05:19 -0700 Received: from cs.columbia.edu ([12.234.195.52]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020507090635.CJJD9799.rwcrmhc51.attbi.com@cs.columbia.edu>; Tue, 7 May 2002 09:06:35 +0000 Message-ID: <3CD79922.2070900@cs.columbia.edu> Date: Tue, 07 May 2002 02:06:42 -0700 From: Ethan Solomita User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jim.houston@attbi.com CC: kdb@oss.sgi.com Subject: Re: SMP patche i386 References: <200205030350.g433oHe01117@linux.local> <3CD69913.8DF9A523@attbi.com> <3CD6DD85.CA1314E1@cs.columbia.edu> <3CD700A5.1A6F8E85@attbi.com> <3CD73AF4.28AAC77@cs.columbia.edu> <3CD75F3F.5B5A6E0F@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Jim Houston wrote: > On the first boot I let the system come up to multi-user > When I hit pause key it hung. > Bummer! 8) > more times. It seemed to be working. > > I changed kdb_flags to 0x20000. Still working. > > I disabled the breakpoint, did a go, pause again, cleared the > breakpoint. > then I cleared kdb_flags and did a go. Another pause and it was hung. > > Any idea why it hangs with the debug turned off aside from Murphy's law? > It's gotta be a race condition (obviously), and so by printing more stuff you significantly change the timings. You might try turning off the official debugging and adding some extremely terse limited messages. You might also look for some of the various while() loops in kdb() and kdb_main_loop() which wait for state to be set, and add a counter. If the loops run more than a certain amount of times, print out a message. Maybe take things one step at a time, and put a single print out at first entry in kdb_ipi, and then remove it and put another one further in. etc. Just some thoughts that come to mind. This can be quite a pain. -- Ethan From owner-kdb@oss.sgi.com Wed May 8 20:12:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g493CiwJ021782 for ; Wed, 8 May 2002 20:12:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g493CiUN021781 for kdb-outgoing; Wed, 8 May 2002 20:12:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g493C0wJ021777 for ; Wed, 8 May 2002 20:12:00 -0700 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 May 2002 20:13:23 -0700 Received: from cs.columbia.edu ([10.2.4.63]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 May 2002 20:13:23 -0700 Message-ID: <3CD9E953.20801@cs.columbia.edu> Date: Wed, 08 May 2002 20:13:23 -0700 From: Ethan Solomita User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kdb@oss.sgi.com Subject: one more try (at SMP) Content-Type: multipart/mixed; boundary="------------080904050705090001060600" X-OriginalArrivalTime: 09 May 2002 03:13:23.0727 (UTC) FILETIME=[7AA0B9F0:01C1F707] Sender: owner-kdb@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------080904050705090001060600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I decided to get my hands on an SMP i386 so I could play with it too. I believe I've got something that works. There were a few issues with setting and clearing of the single-step flags. kdba_clearsinglestep() for some reason wasn't actually clearing EF_TF. It was being cleared automagically in the kdba_db_trap() code, which I hadn't anticipated. So I cleaned up a few things. Here's the summary: kdb_bp.c: redundantly setting DOING_SS and DOING_SSB. removed. kdb_io.c: kdb_printf didn't handle recursion correctly. Also fixed sparc64 issues. kdbmain.c: call kdba_setsinglestep in exactly one place: before exiting kdb() if DOING_SS. kdba_bp.c: fixes as discussed already. do not clear single-step EF_TF flag manually. kdbasupport.c: have setsinglestep and clearsinglestep check whether EF_TF is already set/clear. Make clearsinglestep actually do what it's name implies. Diffs are attached. They are on top of everything already sent out, including the two line fix I emailed out. Once this all seems good and solid, I'll make a single diff. -- Ethan --------------080904050705090001060600 Content-Type: text/plain; name="diffs.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs.txt" ==== //depot/software/kernel/linux2.4/linux_kdb/kdb/kdb_bp.c#3 (ktext) - //depot/software/kernel/linux2.4/linux_kdb/kdb/kdb_bp.c#4 (ktext) ==== content @@ -557,15 +557,6 @@ if (argc != 0) return KDB_ARGCOUNT; - /* - * Set trace flag and go. - */ - KDB_STATE_SET(DOING_SS); - if (ssb) - KDB_STATE_SET(DOING_SSB); - - kdba_setsinglestep(ef); /* Enable single step */ - if (ssb) return KDB_CMD_SSB; return KDB_CMD_SS; ==== //depot/software/kernel/linux2.4/linux_kdb/kdb/kdb_io.c#5 (text) - //depot/software/kernel/linux2.4/linux_kdb/kdb/kdb_io.c#7 (text) ==== content @@ -158,17 +158,22 @@ int linecount; int logging, saved_loglevel = 0; int do_longjmp = 0; +#ifndef CONFIG_SPARC64 struct console *c = console_drivers; +#endif static spinlock_t kdb_printf_lock = SPIN_LOCK_UNLOCKED; + static int kdb_printf_count; /* Serialize kdb_printf if multiple cpus try to write at once. * But if any cpu goes recursive in kdb, just print the output, * even if it is interleaved with any other text. */ if (!KDB_STATE(PRINTF_LOCK)) { + spin_lock(&kdb_printf_lock); KDB_STATE_SET(PRINTF_LOCK); - spin_lock(&kdb_printf_lock); - } + kdb_printf_count = 1; + } else + kdb_printf_count++; diag = kdbgetintenv("LINES", &linecount); if (diag) @@ -186,14 +191,13 @@ * Write to all consoles. */ #ifdef CONFIG_SPARC64 - if (c == NULL) - prom_printf("%s", buffer); - else -#endif + prom_printf("%s",buffer); +#else while (c) { c->write(c, buffer, strlen(buffer)); c = c->next; } +#endif if (logging) { saved_loglevel = console_loglevel; console_loglevel = 0; @@ -233,16 +237,16 @@ } #endif +#ifdef CONFIG_SPARC64 + prom_printf("%s", moreprompt); + +#else c = console_drivers; -#ifdef CONFIG_SPARC64 - if (c == NULL) - prom_printf("%s", moreprompt); - else -#endif while (c) { c->write(c, moreprompt, strlen(moreprompt)); c = c->next; } +#endif if (logging) printk("%s", moreprompt); @@ -259,9 +263,11 @@ if (logging) { console_loglevel = saved_loglevel; } - if (KDB_STATE(PRINTF_LOCK)) { + if (!KDB_STATE(PRINTF_LOCK)) + kdb_printf("kdb_printf panic: lock not set!\n"); + else if (--kdb_printf_count == 0) { + KDB_STATE_CLEAR(PRINTF_LOCK); spin_unlock(&kdb_printf_lock); - KDB_STATE_CLEAR(PRINTF_LOCK); } if (do_longjmp) #ifdef KDB_HAVE_LONGJMP ==== //depot/software/kernel/linux2.4/linux_kdb/kdb/kdbmain.c#9 (ktext) - //depot/software/kernel/linux2.4/linux_kdb/kdb/kdbmain.c#12 (ktext) ==== content @@ -1085,7 +1085,6 @@ KDB_DEBUG_STATE("kdb_main_loop 4a", reason); KDB_STATE_SET(DOING_SS); KDB_STATE_SET(DOING_SSBPT); - kdba_setsinglestep(ef); break; } @@ -1453,6 +1452,9 @@ KDB_STATE_CLEAR(KDB); /* Main kdb state has been cleared */ KDB_STATE_CLEAR(LEAVING); /* Elvis has left the building ... */ KDB_STATE_CLEAR(NEED_SSBPT); + if (KDB_STATE(DOING_SS)) + kdba_setsinglestep(ef); + KDB_DEBUG_STATE("kdb 14", result); if (cpu == kdb_initial_cpu && ==== //depot/software/kernel/linux2.4/linux_kdb/arch/i386/kdb/kdba_bp.c#2 (ktext) - //depot/software/kernel/linux2.4/linux_kdb/arch/i386/kdb/kdba_bp.c#3 (ktext) ==== content @@ -95,44 +95,22 @@ if (KDB_DEBUG(BP)) kdb_printf("kdb: dr6 0x%lx dr7 0x%lx\n", dr6, dr7); if (dr6 & DR6_BS) { - if (KDB_STATE(SSBPT)) { - if (KDB_DEBUG(BP)) - kdb_printf("ssbpt\n"); - KDB_STATE_CLEAR(SSBPT); - for(i=0,bp=kdb_breakpoints; - i < KDB_MAXBPT; - i++, bp++) { - if (KDB_DEBUG(BP)) - kdb_printf("bp 0x%p enabled %d delayed %d global %d cpu %d\n", - bp, bp->bp_enabled, bp->bp_delayed, bp->bp_global, bp->bp_cpu); - if (!bp->bp_enabled) - continue; - if (!bp->bp_global && bp->bp_cpu != smp_processor_id()) - continue; - if (KDB_DEBUG(BP)) - kdb_printf("bp for this cpu\n"); - if (bp->bp_delayed) { - bp->bp_delayed = 0; - if (KDB_DEBUG(BP)) - kdb_printf("kdba_installbp\n"); - kdba_installbp(ef, bp); - if (!KDB_STATE(DOING_SS)) { - ef->eflags &= ~EF_TF; - return(KDB_DB_SSBPT); - } - break; - } - } - if (i == KDB_MAXBPT) { - kdb_printf("kdb: Unable to find delayed breakpoint\n"); - } - if (!KDB_STATE(DOING_SS)) { - ef->eflags &= ~EF_TF; - return(KDB_DB_NOBPT); - } - /* FALLTHROUGH */ - } + if (!KDB_STATE(DOING_SS)) + goto unknown; + + KDB_STATE_CLEAR(DOING_SS); + + if (!KDB_STATE(DOING_SSBPT)) + goto not_ssbpt; + + KDB_STATE_CLEAR(DOING_SSBPT); + + if (KDB_DEBUG(BP)) + kdb_printf("ssbpt\n"); + + return (KDB_DB_SSBPT); +not_ssbpt: /* * KDB_STATE_DOING_SS is set when the kernel debugger is using * the processor trap flag to single-step a processor. If a @@ -140,8 +118,6 @@ * will be ignored by KDB and the kernel will be allowed to deal * with it as necessary (e.g. for ptrace). */ - if (!KDB_STATE(DOING_SS)) - goto unknown; /* single step */ rv = KDB_DB_SS; /* Indicate single step */ @@ -162,8 +138,8 @@ * End the ssb command here. */ KDB_STATE_CLEAR(DOING_SSB); - KDB_STATE_CLEAR(DOING_SS); } else { + KDB_STATE_SET(DOING_SS); /* still need to step */ rv = KDB_DB_SSB; /* Indicate ssb - dismiss immediately */ } } else { @@ -173,11 +149,7 @@ kdb_printf("SS trap at "); kdb_symbol_print(ef->eip, NULL, KDB_SP_DEFAULT|KDB_SP_NEWLINE); kdb_id1(ef->eip); - KDB_STATE_CLEAR(DOING_SS); } - - if (rv != KDB_DB_SSB) - ef->eflags &= ~EF_TF; } if (dr6 & DR6_B0) { @@ -244,6 +216,7 @@ unknown: ef->eflags |= EF_RF; /* Supress further faults */ + kdb_printf("kdb: debug trap, unknown cause\n"); rv = KDB_DB_NOBPT; /* Cause kdb() to return */ handled: @@ -307,6 +280,9 @@ "eflags=0x%lx ef=0x%p esp=0x%lx\n", ef->eip, ef->eflags, ef, ef->esp); + if (KDB_STATE(DOING_SS)) + kdb_printf("kdba_bp_trap: ??? should be single stepping!\n"); + rv = KDB_DB_NOBPT; /* Cause kdb() to return */ for(i=0, bp=kdb_breakpoints; ieip); kdb_id1(ef->eip); rv = KDB_DB_BPT; - bp->bp_delay = 1; + KDB_STATE_SET(NEED_SSBPT); break; } } @@ -330,56 +306,6 @@ } /* - * kdba_handle_bp - * - * Handle an instruction-breakpoint trap. Called when re-installing - * an enabled breakpoint which has has the bp_delay bit set. - * - * Parameters: - * Returns: - * Locking: - * Remarks: - * - * Ok, we really need to: - * 1) Restore the original instruction byte - * 2) Single Step - * 3) Restore breakpoint instruction - * 4) Continue. - * - * - */ - -static void -kdba_handle_bp(kdb_eframe_t ef, kdb_bp_t *bp) -{ - if (!ef) { - kdb_printf("kdba_handle_bp: ef == NULL\n"); - return; - } - - if (KDB_DEBUG(BP)) - kdb_printf("ef->eip = 0x%lx\n", ef->eip); - - /* - * Setup single step - */ - kdba_setsinglestep(ef); - - /* KDB_STATE_SSBPT is set when the kernel debugger must single step - * a task in order to re-establish an instruction breakpoint which - * uses the instruction replacement mechanism. - */ - KDB_STATE_SET(SSBPT); - - /* - * Reset delay attribute - */ - bp->bp_delay = 0; - bp->bp_delayed = 1; -} - - -/* * kdba_bptype * * Return a string describing type of breakpoint. @@ -714,10 +640,6 @@ kdb_printf("kdba_installbp hardware reg %ld at " kdb_bfd_vma_fmt "\n", bp->bp_hard->bph_reg, bp->bp_addr); } - } else if (bp->bp_delay) { - if (KDB_DEBUG(BP)) - kdb_printf("kdba_installbp delayed bp\n"); - kdba_handle_bp(ef, bp); } else { if (kdb_getarea_size(&(bp->bp_inst), bp->bp_addr, 1) || kdb_putword(bp->bp_addr, IA32_BREAKPOINT_INSTRUCTION, 1)) { ==== //depot/software/kernel/linux2.4/linux_kdb/arch/i386/kdb/kdbasupport.c#2 (ktext) - //depot/software/kernel/linux2.4/linux_kdb/arch/i386/kdb/kdbasupport.c#3 (ktext) ==== content @@ -1001,6 +1001,9 @@ void kdba_setsinglestep(struct pt_regs *regs) { + if (regs->eflags & EF_TF) + return; + if (regs->eflags & EF_IE) KDB_STATE_SET(A_IF); else @@ -1011,10 +1014,14 @@ void kdba_clearsinglestep(struct pt_regs *regs) { + if ((regs->eflags & EF_TF) == 0) + return; + if (KDB_STATE(A_IF)) regs->eflags |= EF_IE; else regs->eflags &= ~EF_IE; + regs->eflags &= ~EF_TF; } int --------------080904050705090001060600-- From owner-kdb@oss.sgi.com Wed May 8 22:29:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g495T2wJ022753 for ; Wed, 8 May 2002 22:29:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g495T2VP022752 for kdb-outgoing; Wed, 8 May 2002 22:29:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from linux.local (h00e098094f32.ne.client2.attbi.com [24.60.61.209]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g495RGwJ022620 for ; Wed, 8 May 2002 22:27:17 -0700 Received: (from jhouston2@localhost) by linux.local (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id g495VtN04617; Thu, 9 May 2002 01:31:55 -0400 Date: Thu, 9 May 2002 01:31:55 -0400 Message-Id: <200205090531.g495VtN04617@linux.local> X-Authentication-Warning: linux.local: jhouston2 set sender to jim.houston@attbi.com using -f From: Jim Houston To: kdb@oss.sgi.com, ethan@cs.columbia.edu, jim.houston@attbi.com Subject: New SMP patch Reply-to: jim.houston@attbi.com Sender: owner-kdb@oss.sgi.com Precedence: bulk Hi Everyone, The attached patch attacks the SMP problems that Ethan Solomita described but takes a different approach than his patch. I just got this working today so it may have some rough edges. I'm looking for buy in from Keith and Ethan. I have split the kdb_state variable in two. The new kdb_st is used for inter-processor synchronization while the existing kdb_state is only modified by the local cpu. This allows the non-kdb breakpoints to be handled without the overhead of synchronizing the processors. The patch also changes the behavior when multiple processors hit breakpoints at the same time. The previous behavior was to only to process one breakpoint at a time. This patch lets them all play as equals. This means that you can switch between them with the cpu command and see useful state. Previously you saw a stack trace of the breakpoint entry code. It fixes the bug described in the comment before Most of the changes are portable except for the addition of the kdb_in_bp[cpu] flag which needs to be set early in the breakpoint entry code in entry.S. This flag is used by kdb_ipi to tell if it has nested on top of a breakpoint entry. If it finds this flag set it returns and lets the breakpoint proceed. This change is about 10 lines on the i386. I adopted Ethan's simplified code for single stepping past breakpoints. The description of his patch will be helpful if some one else has to make this work on ia64. Jim Houston - Concurrent Computer Corp. diff -urN -X /home/jim/dontdiff linux.old/arch/i386/kdb/kdba_bp.c linux/arch/i386/kdb/kdba_bp.c --- linux.old/arch/i386/kdb/kdba_bp.c Wed May 8 17:55:04 2002 +++ linux/arch/i386/kdb/kdba_bp.c Mon May 6 22:41:04 2002 @@ -95,43 +95,6 @@ if (KDB_DEBUG(BP)) kdb_printf("kdb: dr6 0x%lx dr7 0x%lx\n", dr6, dr7); if (dr6 & DR6_BS) { - if (KDB_STATE(SSBPT)) { - if (KDB_DEBUG(BP)) - kdb_printf("ssbpt\n"); - KDB_STATE_CLEAR(SSBPT); - for(i=0,bp=kdb_breakpoints; - i < KDB_MAXBPT; - i++, bp++) { - if (KDB_DEBUG(BP)) - kdb_printf("bp 0x%p enabled %d delayed %d global %d cpu %d\n", - bp, bp->bp_enabled, bp->bp_delayed, bp->bp_global, bp->bp_cpu); - if (!bp->bp_enabled) - continue; - if (!bp->bp_global && bp->bp_cpu != smp_processor_id()) - continue; - if (KDB_DEBUG(BP)) - kdb_printf("bp for this cpu\n"); - if (bp->bp_delayed) { - bp->bp_delayed = 0; - if (KDB_DEBUG(BP)) - kdb_printf("kdba_installbp\n"); - kdba_installbp(ef, bp); - if (!KDB_STATE(DOING_SS)) { - ef->eflags &= ~EF_TF; - return(KDB_DB_SSBPT); - } - break; - } - } - if (i == KDB_MAXBPT) { - kdb_printf("kdb: Unable to find delayed breakpoint\n"); - } - if (!KDB_STATE(DOING_SS)) { - ef->eflags &= ~EF_TF; - return(KDB_DB_NOBPT); - } - /* FALLTHROUGH */ - } /* * KDB_STATE_DOING_SS is set when the kernel debugger is using @@ -143,6 +106,16 @@ if (!KDB_STATE(DOING_SS)) goto unknown; + if (KDB_STATE(DOING_SSBPT)) { + if (KDB_DEBUG(BP)) + kdb_printf("ssbpt\n"); + KDB_STATE_CLEAR(DOING_SS); + KDB_STATE_CLEAR(DOING_SSBPT); + /* do we need to restore EF_IE? */ + ef->eflags &= ~EF_TF; + return(KDB_DB_SSBPT); + } + /* single step */ rv = KDB_DB_SS; /* Indicate single step */ if (KDB_STATE(DOING_SSB)) { @@ -321,7 +294,7 @@ i, ef->eip); kdb_id1(ef->eip); rv = KDB_DB_BPT; - bp->bp_delay = 1; + KDB_STATE_SET(NEED_SSBPT); break; } } @@ -330,56 +303,6 @@ } /* - * kdba_handle_bp - * - * Handle an instruction-breakpoint trap. Called when re-installing - * an enabled breakpoint which has has the bp_delay bit set. - * - * Parameters: - * Returns: - * Locking: - * Remarks: - * - * Ok, we really need to: - * 1) Restore the original instruction byte - * 2) Single Step - * 3) Restore breakpoint instruction - * 4) Continue. - * - * - */ - -static void -kdba_handle_bp(kdb_eframe_t ef, kdb_bp_t *bp) -{ - if (!ef) { - kdb_printf("kdba_handle_bp: ef == NULL\n"); - return; - } - - if (KDB_DEBUG(BP)) - kdb_printf("ef->eip = 0x%lx\n", ef->eip); - - /* - * Setup single step - */ - kdba_setsinglestep(ef); - - /* KDB_STATE_SSBPT is set when the kernel debugger must single step - * a task in order to re-establish an instruction breakpoint which - * uses the instruction replacement mechanism. - */ - KDB_STATE_SET(SSBPT); - - /* - * Reset delay attribute - */ - bp->bp_delay = 0; - bp->bp_delayed = 1; -} - - -/* * kdba_bptype * * Return a string describing type of breakpoint. @@ -714,10 +637,6 @@ kdb_printf("kdba_installbp hardware reg %ld at " kdb_bfd_vma_fmt "\n", bp->bp_hard->bph_reg, bp->bp_addr); } - } else if (bp->bp_delay) { - if (KDB_DEBUG(BP)) - kdb_printf("kdba_installbp delayed bp\n"); - kdba_handle_bp(ef, bp); } else { if (kdb_getarea_size(&(bp->bp_inst), bp->bp_addr, 1) || kdb_putword(bp->bp_addr, IA32_BREAKPOINT_INSTRUCTION, 1)) { diff -urN -X /home/jim/dontdiff linux.old/arch/i386/kernel/entry.S linux/arch/i386/kernel/entry.S --- linux.old/arch/i386/kernel/entry.S Wed May 8 17:55:04 2002 +++ linux/arch/i386/kernel/entry.S Wed May 8 13:56:06 2002 @@ -78,6 +78,7 @@ need_resched = 20 tsk_ptrace = 24 processor = 52 +cpu = 48 ENOSYS = 38 @@ -344,6 +345,14 @@ RESTORE_ALL ENTRY(int3) +#if defined(CONFIG_KDB) + pushl %eax # kdb_in_bp[smp_processor_id] = 1; + GET_CURRENT(%eax) + movl cpu(%eax),%eax + sall $2,%eax + movl $1,kdb_in_bp(%eax) + popl %eax +#endif pushl $0 pushl $ SYMBOL_NAME(do_int3) jmp error_code diff -urN -X /home/jim/dontdiff linux.old/include/linux/kdb.h linux/include/linux/kdb.h --- linux.old/include/linux/kdb.h Wed May 8 17:54:43 2002 +++ linux/include/linux/kdb.h Thu May 9 00:09:20 2002 @@ -113,8 +113,8 @@ #define KDB_STATE_HOLD_CPU 0x00000010 /* Hold this cpu inside kdb */ #define KDB_STATE_DOING_SS 0x00000020 /* Doing ss command */ #define KDB_STATE_DOING_SSB 0x00000040 /* Doing ssb command, DOING_SS is also set */ -#define KDB_STATE_SSBPT 0x00000080 /* Install breakpoint after one ss, independent of DOING_SS */ -#define KDB_STATE_REENTRY 0x00000100 /* Valid re-entry into kdb */ +#define KDB_STATE_DOING_SSBPT 0x00000080 /* Doing go after breakpoint, DOING_SS set */ +#define KDB_STATE_NEED_SSBPT 0x00000100 /* If users says "go", need to do "ss" */ #define KDB_STATE_SUPPRESS 0x00000200 /* Suppress error messages */ #define KDB_STATE_LONGJMP 0x00000400 /* longjmp() data is available */ /* Spare, was NO_WATCHDOG 0x00000800 */ @@ -122,7 +122,7 @@ #define KDB_STATE_WAIT_IPI 0x00002000 /* Waiting for kdb_ipi() NMI */ #define KDB_STATE_RECURSE 0x00004000 /* Recursive entry to kdb */ #define KDB_STATE_IP_ADJUSTED 0x00008000 /* Restart IP has been adjusted */ -#define KDB_STATE_NO_BP_DELAY 0x00010000 /* No need to delay breakpoints */ +#define KDB_STATE_REENTRY 0x00010000 #define KDB_STATE_ARCH 0xff000000 /* Reserved for arch specific use */ #define KDB_STATE_CPU(flag,cpu) (kdb_state[cpu] & KDB_STATE_##flag) @@ -133,6 +133,24 @@ #define KDB_STATE_SET(flag) KDB_STATE_SET_CPU(flag,smp_processor_id()) #define KDB_STATE_CLEAR(flag) KDB_STATE_CLEAR_CPU(flag,smp_processor_id()) +/* + * kdb_st state/command used for MP interactions. + */ +typedef enum { + KDB_ST_RUNNING, /* Not in kbd. */ + KDB_ST_LEAVING, + KDB_ST_WAIT_IPI, /* Waiting for kdb_ipi() NMI */ + KDB_ST_HOLD_CPU, /* Slave waiting kdb_main_loop */ + KDB_ST_MASTER, /* Master executing debugger */ + KDB_ST_SLAVE, + KDB_ST_SSBPT, /* Single step past breakpoint */ + KDB_ST_NULL, /* invalid/unknown state */ +} kdb_st_t; + +/* kdb_st - kdb state that is modified by other processors. */ +volatile extern kdb_st_t kdb_st[ /*NR_CPUS*/ ]; +volatile extern int kdb_in_bp[ /*NR_CPUS*/ ]; + /* * External entry point for the kernel debugger. The pt_regs * at the time of entry are supplied along with the reason for diff -urN -X /home/jim/dontdiff linux.old/include/linux/kdbprivate.h linux/include/linux/kdbprivate.h --- linux.old/include/linux/kdbprivate.h Wed May 8 17:54:43 2002 +++ linux/include/linux/kdbprivate.h Wed May 8 13:48:26 2002 @@ -90,8 +90,6 @@ unsigned int bp_hardtype:1; /* Uses hardware register */ unsigned int bp_forcehw:1; /* Force hardware register */ unsigned int bp_installed:1; /* Breakpoint is installed */ - unsigned int bp_delay:1; /* Do delayed bp handling */ - unsigned int bp_delayed:1; /* Delayed breakpoint */ int bp_cpu; /* Cpu # (if bp_global == 0) */ kdbhard_bp_t bp_template; /* Hardware breakpoint template */ @@ -168,6 +166,7 @@ unsigned long setup; /* Bytes allocated for setup data */ } kdb_ar_t; +#if defined(CONFIG_X86) || defined(CONFIG_IA64) /* * General Stack Traceback functions. */ @@ -176,6 +175,7 @@ kdb_machreg_t, kdb_machreg_t, kdb_machreg_t, kdb_ar_t *, kdb_symtab_t *); +#endif /* * Architecture specific Stack Traceback functions. @@ -186,9 +186,11 @@ extern int kdba_bt_stack(struct pt_regs *, kdb_machreg_t *, int, struct task_struct *); extern int kdba_bt_process(struct task_struct *, int); +#if defined(CONFIG_X86) || defined(CONFIG_IA64) extern int kdba_prologue(const kdb_symtab_t *, kdb_machreg_t, kdb_machreg_t, kdb_machreg_t, kdb_machreg_t, int, kdb_ar_t *); +#endif /* * KDB Command Table */ diff -urN -X /home/jim/dontdiff linux.old/kdb/kdb_bp.c linux/kdb/kdb_bp.c --- linux.old/kdb/kdb_bp.c Wed May 8 17:54:43 2002 +++ linux/kdb/kdb_bp.c Mon May 6 22:40:11 2002 @@ -50,13 +50,18 @@ { int i; + if (KDB_DEBUG(BP)) + kdb_printf("kdb_bp_install_global cpu %d\n", smp_processor_id()); + for(i=0; i=0; i--) { - if (KDB_DEBUG(BP)) { - kdb_printf("kdb_bp_remove_global bp %d bp_enabled %d bp_global %d\n", - i, kdb_breakpoints[i].bp_enabled, kdb_breakpoints[i].bp_global); - } if (kdb_breakpoints[i].bp_enabled && kdb_breakpoints[i].bp_global) { + if (KDB_DEBUG(BP)) { + kdb_printf("kdb_bp_remove_global bp %d bp_enabled %d " + "bp_global %d\n", i, + kdb_breakpoints[i].bp_enabled, + kdb_breakpoints[i].bp_global); + } kdba_removebp(&kdb_breakpoints[i]); } } @@ -158,17 +171,21 @@ void kdb_bp_remove_local(void) { - int i; + int i, cpu = smp_processor_id(); + + if (KDB_DEBUG(BP)) + kdb_printf("kdb_bp_remove_local cpu %d\n", cpu); for(i=KDB_MAXBPT-1; i>=0; i--) { - if (KDB_DEBUG(BP)) { - kdb_printf("kdb_bp_remove_local bp %d bp_enabled %d bp_global %d cpu %d bp_cpu %d\n", - i, kdb_breakpoints[i].bp_enabled, kdb_breakpoints[i].bp_global, - smp_processor_id(), kdb_breakpoints[i].bp_cpu); - } if (kdb_breakpoints[i].bp_enabled && kdb_breakpoints[i].bp_cpu == smp_processor_id() && !kdb_breakpoints[i].bp_global){ + if (KDB_DEBUG(BP)) { + kdb_printf("kdb_bp_remove_local bp %d bp_enabled %d " + "bp_global %d cpu %d\n", i, + kdb_breakpoints[i].bp_enabled, + kdb_breakpoints[i].bp_global, cpu); + } kdba_removebp(&kdb_breakpoints[i]); } } diff -urN -X /home/jim/dontdiff linux.old/kdb/kdbmain.c linux/kdb/kdbmain.c --- linux.old/kdb/kdbmain.c Wed May 8 17:54:43 2002 +++ linux/kdb/kdbmain.c Thu May 9 00:12:17 2002 @@ -34,6 +34,14 @@ * KDB v1.4 * kdb=on/off/early at boot, /proc/sys/kernel/kdb. * Env BTAPROMPT. + * + * Jim Houston 2002/05/08 + * Hacking at SMP handling. If multiple processors + * hit breakpoints at the same time they now present + * useful state. Before this change if you switched + * to another processor with the cpu command you were + * likely to see the breakpoint entry code on the stack. + * The TBR (to be revisited) comments are mine. */ #include @@ -49,6 +57,7 @@ #include #include #include +#include #include @@ -61,17 +70,26 @@ */ volatile int kdb_flags; - /* - * kdb_lock protects updates to kdb_initial_cpu. Used to - * single thread processors through the kernel debugger. - */ -spinlock_t kdb_lock = SPIN_LOCK_UNLOCKED; volatile int kdb_initial_cpu = -1; /* cpu number that owns kdb */ volatile int kdb_nextline = 1; static volatile int kdb_new_cpu; /* Which cpu to switch to */ +/* + * Some of the flags that were in kdb_state are now in kdb_st + * so that kdb_state is only accessed by the local cpu. + * I imagine kdb_st as an enumerated state rather than a colection + * of flags. + */ volatile int kdb_state[NR_CPUS]; /* Per cpu state */ +volatile kdb_st_t kdb_st[NR_CPUS]; /* Per cpu state */ +volatile int kdb_in_bp[NR_CPUS]; /* Per cpu state */ + +/* descriptions for kdb_st values. */ +char *kdb_st_desc[] = { + "running", "leaving", "wait_ipi", "hold_cpu", + "master", "slave", "ssbpt", "" }; + #ifdef CONFIG_KDB_OFF int kdb_on = 0; /* Default is off */ @@ -957,10 +975,13 @@ void kdb_print_state(const char *text, int value) { - kdb_printf("state: %s cpu %d value %d initial %d state %x\n", - text, smp_processor_id(), value, kdb_initial_cpu, kdb_state[smp_processor_id()]); + kdb_printf("state: %s cpu %d value %d initial %d st %x state %x\n", + text, smp_processor_id(), value, kdb_initial_cpu, \ + kdb_st[smp_processor_id()], kdb_state[smp_processor_id()]); } +#if 0 +/* TBR - I'm not convinced this is useful. */ /* * kdb_previous_event * @@ -982,11 +1003,12 @@ { int i, leaving = 0; for (i = 0; i < NR_CPUS; ++i) { - if (KDB_STATE_CPU(LEAVING, i)) + if (kdb_st[i] == KDB_ST_LEAVING) ++leaving; } return(leaving); } +#endif /* * kdb_main_loop @@ -1019,67 +1041,120 @@ * none */ +int kdb_boring; + int kdb_main_loop(kdb_reason_t reason, kdb_reason_t reason2, int error, - kdb_dbtrap_t db_result, kdb_eframe_t ef) +kdb_dbtrap_t db_result, kdb_eframe_t ef) { int result = 1; - /* Stay in kdb() until 'go', 'ss[b]' or an error */ + int cpu = smp_processor_id(); + int i; + kdb_st_t st, old_st; + + old_st = KDB_ST_NULL; while (1) { - int i; - /* - * All processors except the one that is in control - * will spin here. - */ - KDB_DEBUG_STATE("kdb_main_loop 1", reason); - while (KDB_STATE(HOLD_CPU)) - ; - KDB_STATE_CLEAR(SUPPRESS); - KDB_DEBUG_STATE("kdb_main_loop 2", reason); - if (KDB_STATE(LEAVING)) - break; /* Another cpu said 'go' */ - - /* Still using kdb, this processor is in control */ - result = kdb_local(reason2, error, ef, db_result); - KDB_DEBUG_STATE("kdb_main_loop 3", result); - - if (result == KDB_CMD_CPU) { - /* Cpu switch, hold the current cpu, release the target one. */ - reason2 = KDB_REASON_SWITCH; - KDB_STATE_SET(HOLD_CPU); - KDB_STATE_CLEAR_CPU(HOLD_CPU, kdb_new_cpu); - continue; + st = kdb_st[cpu]; + if (KDB_DEBUG(STATE)) { + kdb_printf("cpu %d st %s -> %s master %d\n", cpu, + kdb_st_desc[old_st], kdb_st_desc[st], kdb_initial_cpu); + old_st = st; } - - if (result == KDB_CMD_SS) { + switch (st) { + + case KDB_ST_HOLD_CPU: + while (kdb_st[cpu] == KDB_ST_HOLD_CPU) ; + continue; + + case KDB_ST_LEAVING: + return(1); + + case KDB_ST_SSBPT: KDB_STATE_SET(DOING_SS); + KDB_STATE_SET(DOING_SSBPT); + kdba_setsinglestep(ef); + kdb_st[cpu] = KDB_ST_MASTER; + return(1); + + case KDB_ST_MASTER: + result = kdb_local(reason2, error, ef, db_result); + switch (result) { + + case KDB_CMD_SS: + case KDB_CMD_SSB: + return(1); + + case KDB_CMD_CPU: + reason2 = KDB_REASON_SWITCH; + kdb_st[cpu] = KDB_ST_HOLD_CPU; + kdb_st[kdb_new_cpu] = KDB_ST_MASTER; + kdb_initial_cpu = kdb_new_cpu; + break; + + case KDB_CMD_GO: + default: + /* + * If there are cpus that need to single + * step off of breakpoints let them go + * individually. + */ + for (i = 0; i < NR_CPUS; i++) { + if (KDB_STATE_CPU(NEED_SSBPT, i)) { + kdb_st[cpu] = KDB_ST_HOLD_CPU; + kdb_st[i] = KDB_ST_SSBPT; + kdb_initial_cpu = i; + break; + } + } + if (i == NR_CPUS) { + /* Were ready to leave. */ + kdb_bp_install_global(ef); + for (i = 0; i < NR_CPUS; i++) + kdb_st[i] = KDB_ST_LEAVING; + } + } break; - } - if (result == KDB_CMD_SSB) { - KDB_STATE_SET(DOING_SS); - KDB_STATE_SET(DOING_SSB); + default: + if (kdb_boring < 5) { + kdb_printf("kdb_main_loop: cpu %d st %s\n", + cpu, kdb_st_desc[st]); + kdb_boring++; + } break; } + } +} - if (result && result != 1 && result != KDB_CMD_GO) - kdb_printf("\nUnexpected kdb_local return code %d\n", result); +/* + * kdb_smp_wait() + * + * After we hit the other processors with an NMI we want to + * wait and give the dust a chance to settle before we remove + * the global breakpoints. + */ +#define KDB_TIMEOUT 10000 - /* - * All other return codes (including KDB_CMD_GO) from - * kdb_local will end kdb(). Release all other cpus - * which will see KDB_STATE(LEAVING) is set. - */ - for (i = 0; i < NR_CPUS; ++i) { - if (KDB_STATE_CPU(KDB, i)) - KDB_STATE_SET_CPU(LEAVING, i); - KDB_STATE_CLEAR_CPU(WAIT_IPI, i); - KDB_STATE_CLEAR_CPU(HOLD_CPU, i); +kdb_smp_wait() +{ + int wait_cnt, i, n; + + for (n = 0; n < KDB_TIMEOUT; n++) { + wait_cnt = 0; + for (i = 0; i < smp_num_cpus; i++) { + if (kdb_st[i] == KDB_ST_WAIT_IPI) + wait_cnt++; } - KDB_DEBUG_STATE("kdb_main_loop 4", reason); - break; + if (!wait_cnt) + break; + udelay(10); + } + if (n == KDB_TIMEOUT) { + kdb_printf("No response from cpu - "); + for (i = 0; i < smp_num_cpus; i++) + kdb_printf(" %d", i); + kdb_printf("\n"); } - return(result != 0); } /* @@ -1110,6 +1185,8 @@ * the cpu is allowed to do one instruction which causes a trap * into kdb with KDB_REASON_DEBUG. * + * [Note: sparc64 leaves interrupts disabled while single-stepping] + * * Inputs: * reason The reason KDB was invoked * error The hardware-defined error code @@ -1147,11 +1224,22 @@ * * Two cpus hit debug points at the same time. * - * kdb_lock and kdb_initial_cpu ensure that only one cpu gets - * control of kdb. The others spin on kdb_initial_cpu until - * they are driven through NMI into kdb_ipi. When the initial - * cpu releases the others from NMI, they resume trying to get - * kdb_initial_cpu to start a new event. + * The tricky bit here is getting all of the other processors + * to stop without ending up with an extra layer of nesting. + * The variable kdb_in_bp[cpu] is set early in entry.S. If + * kdb_ipi() finds this flag set it simply returns from the + * NMI allowing the processor to enter kdb and process the + * the breakpoint entry. The processors arbitrate racing + * to set kdb_initial_cpu to their processor number. + * The winning processor becomes the master cpu and does the + * kdb command processing. They all call into kdb_main_loop. + * + * TBR- There are still some holes I plan to fix. I plan to have + * kdb_ipi check the eip value to see if its in the code that + * sets kdb_in_bp. There is also the case where a gdb + * breakpoint happens at the sametime as the kdb_ipi() call. + * In this case it will currently return from the NMI and + * not stop. * * A cpu is released from kdb and starts a new event before the * original event has completely ended. @@ -1200,7 +1288,6 @@ * */ -int kdb(kdb_reason_t reason, int error, kdb_eframe_t ef) { kdb_intstate_t int_state; /* Interrupt state */ @@ -1208,9 +1295,13 @@ int result = 1; /* Default is kdb handled it */ int ss_event; kdb_dbtrap_t db_result=KDB_DB_NOBPT; + int cpu = smp_processor_id(); + int i; - if (!kdb_on) + if (!kdb_on) { + kdb_in_bp[cpu] = 0; return 0; + } KDB_DEBUG_STATE("kdb 1", reason); KDB_STATE_CLEAR(SUPPRESS); @@ -1219,7 +1310,7 @@ * the kdb smp fiddling when it is really a gdb trap. * Save the single step status first, kdba_db_trap clears ss status. */ - ss_event = reason != KDB_REASON_PANIC && (KDB_STATE(DOING_SS) || KDB_STATE(SSBPT)); + ss_event = reason != KDB_REASON_PANIC && KDB_STATE(DOING_SS); if (reason == KDB_REASON_BREAK) db_result = kdba_bp_trap(ef, error); /* Only call this once */ if (reason == KDB_REASON_DEBUG) @@ -1228,33 +1319,40 @@ if ((reason == KDB_REASON_BREAK || reason == KDB_REASON_DEBUG) && db_result == KDB_DB_NOBPT) { KDB_DEBUG_STATE("kdb 2", reason); + kdb_in_bp[cpu] = 0; return 0; /* Not one of mine */ } /* Turn off single step if it was being used */ - if (ss_event) { + if (ss_event) kdba_clearsinglestep(ef); - /* Single step after a breakpoint removes the need for a delayed reinstall */ - if (reason == KDB_REASON_BREAK || reason == KDB_REASON_DEBUG) { - KDB_STATE_SET(NO_BP_DELAY); - } - } /* kdb can validly reenter but only for certain well defined conditions */ if (reason == KDB_REASON_DEBUG - && !KDB_STATE(HOLD_CPU) + && (kdb_st[cpu] != KDB_ST_HOLD_CPU) && ss_event) KDB_STATE_SET(REENTRY); else KDB_STATE_CLEAR(REENTRY); +#if 0 + /* + * TBR - Its broken and I don't think its needed. + * Non existant processors get stuck in LEAVING state. + */ /* Wait for previous kdb event to completely exit before starting * a new event. */ while (kdb_previous_event()) ; +#endif KDB_DEBUG_STATE("kdb 3", reason); - +#if 0 + /* + * TBR - Its broken because the state information has changed + * to allow multiple processors to enter kdb for breakpoints + * at the same time. + */ /* * If kdb is already active, print a message and try to recover. * If recovery is not possible and recursion is allowed or @@ -1269,7 +1367,7 @@ kdb_printf("kdb: Debugger re-entered on cpu %d, new reason = %d\n", smp_processor_id(), reason); /* Should only re-enter from released cpu */ - if (KDB_STATE(HOLD_CPU)) { + if (kdb_st[cpu] == KDB_ST_HOLD_CPU) { kdb_printf(" Strange, cpu %d should not be running\n", smp_processor_id()); recover = 0; } @@ -1312,6 +1410,7 @@ kdb_printf("kdb: CPU switch without kdb running, I'm confused\n"); return(0); } +#endif /* * Disable interrupts, breakpoints etc. on this processor @@ -1343,31 +1442,34 @@ ; /* drop through */ else { KDB_DEBUG_STATE("kdb 4", reason); - spin_lock(&kdb_lock); - - while (KDB_IS_RUNNING() || kdb_previous_event()) { - spin_unlock(&kdb_lock); - - while (KDB_IS_RUNNING() || kdb_previous_event()) + /* + * cover case where there is an old master in the + * process of leaving. + */ + while ((i = kdb_initial_cpu) != -1 && kdb_st[i] == KDB_ST_LEAVING); + /* + * TBR - Is portable? + */ + if (cmpxchg(&kdb_initial_cpu, -1, cpu) == -1) { + /* + * We won become master. + */ + kdb_st[cpu] = KDB_ST_MASTER; +#if 0 + } else { + /* + * TBR - Is this needed? + */ + while (kdb_in_bp[cpu] == 1) ; - - spin_lock(&kdb_lock); +#endif } KDB_DEBUG_STATE("kdb 5", reason); - - kdb_initial_cpu = smp_processor_id(); - spin_unlock(&kdb_lock); } if (smp_processor_id() == kdb_initial_cpu && !KDB_STATE(REENTRY)) { - KDB_STATE_CLEAR(HOLD_CPU); - KDB_STATE_CLEAR(WAIT_IPI); - /* - * Remove the global breakpoints. This is only done - * once from the initial processor on initial entry. - */ - kdb_bp_remove_global(); + kdb_st[cpu] = KDB_ST_MASTER; /* * If SMP, stop other processors. The other processors @@ -1379,14 +1481,19 @@ int i; for (i = 0; i < NR_CPUS; ++i) { if (i != kdb_initial_cpu) { - KDB_STATE_SET_CPU(HOLD_CPU, i); - KDB_STATE_SET_CPU(WAIT_IPI, i); + kdb_st[i] = KDB_ST_WAIT_IPI; } } KDB_DEBUG_STATE("kdb 7", reason); smp_kdb_stop(); KDB_DEBUG_STATE("kdb 8", reason); + kdb_smp_wait(); } + /* + * Remove the global breakpoints. This is only done + * once from the initial processor on initial entry. + */ + kdb_bp_remove_global(); } /* Set up a consistent set of process stacks before talking to the user */ @@ -1400,38 +1507,28 @@ /* No breakpoints installed for SS */ if (!KDB_STATE(DOING_SS) && - !KDB_STATE(SSBPT) && !KDB_STATE(RECURSE)) { KDB_DEBUG_STATE("kdb 12", result); kdba_enable_lbr(); kdb_bp_install_local(ef); - KDB_STATE_CLEAR(NO_BP_DELAY); KDB_STATE_CLEAR(KDB_CONTROL); } KDB_DEBUG_STATE("kdb 13", result); kdba_restoreint(&int_state); + KDB_STATE_CLEAR(NEED_SSBPT); KDB_STATE_CLEAR(KDB); /* Main kdb state has been cleared */ - KDB_STATE_CLEAR(LEAVING); /* Elvis has left the building ... */ KDB_DEBUG_STATE("kdb 14", result); - if (smp_processor_id() == kdb_initial_cpu && - !KDB_STATE(DOING_SS) && - !KDB_STATE(RECURSE)) { - /* - * (Re)install the global breakpoints. This is only done - * once from the initial processor on final exit. - */ - KDB_DEBUG_STATE("kdb 15", reason); - kdb_bp_install_global(ef); - /* Wait until all the other processors leave kdb */ - while (kdb_previous_event()) - ; - kdb_initial_cpu = -1; /* release kdb control */ + if (kdb_st[cpu] == KDB_ST_LEAVING) { + if (cpu == kdb_initial_cpu) + kdb_initial_cpu = -1; /* release kdb control */ + kdb_st[cpu] = KDB_ST_RUNNING; KDB_DEBUG_STATE("kdb 16", reason); } + kdb_in_bp[cpu] = 0; KDB_STATE_CLEAR(RECURSE); KDB_DEBUG_STATE("kdb 17", reason); return(result != 0); diff -urN -X /home/jim/dontdiff linux.old/kdb/kdbsupport.c linux/kdb/kdbsupport.c --- linux.old/kdb/kdbsupport.c Wed May 8 17:54:43 2002 +++ linux/kdb/kdbsupport.c Wed May 8 13:46:41 2002 @@ -141,13 +141,23 @@ /* Do not print before checking and clearing WAIT_IPI, IPIs are * going all the time. */ - if (KDB_STATE(WAIT_IPI)) { + if (kdb_st[smp_processor_id()] == KDB_ST_WAIT_IPI) { /* * Stopping other processors via smp_kdb_stop(). */ if (ack_interrupt) (*ack_interrupt)(); /* Acknowledge the interrupt */ - KDB_STATE_CLEAR(WAIT_IPI); + /* + * Avoid an extra layer of nesting if we have + * already entered kdb for some other reason. + */ + if (kdb_in_bp[smp_processor_id()] == 1) { + kdb_in_bp[smp_processor_id()] = 2; + kdb_st[smp_processor_id()] = KDB_ST_HOLD_CPU; + return(1); + } + + kdb_st[smp_processor_id()] = KDB_ST_HOLD_CPU; KDB_DEBUG_STATE("kdb_ipi 1", 0); kdb(KDB_REASON_SWITCH, 0, ef); /* Spin in kdb() */ KDB_DEBUG_STATE("kdb_ipi 2", 0); From owner-kdb@oss.sgi.com Fri May 10 18:34:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4B1YnwJ017615 for ; Fri, 10 May 2002 18:34:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4B1YmwB017614 for kdb-outgoing; Fri, 10 May 2002 18:34:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from kahkaha.com ([210.241.50.226]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4B1YMwJ017610 for ; Fri, 10 May 2002 18:34:24 -0700 Received: from unknown (HELO da001d2020.loxi.pianstvu.net) (75.252.7.193) by sparc.zubilam.net with SMTP; 10 May 2002 10:46:08 +0600 Received: from unknown (38.233.198.6) by smtp-server1.cflrr.com with smtp; Fri, 10 May 2002 16:39:34 +0400 Received: from 47.83.160.47 ([47.83.160.47]) by q4.quickslow.com with smtp; Fri, 10 May 2002 20:33:00 +0500 Reply-To: Message-ID: <022b06c36c3c$8826d3c3$3aa81ee5@mmukgu> From: To: Target@oss.sgi.com Subject: Sinirsiz porno Date: Fri, 10 May 2002 20:20:00 +0500 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B0_51A78C4D.D2034A36" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 Importance: Normal Sender: owner-kdb@oss.sgi.com Precedence: bulk ------=_NextPart_000_00B0_51A78C4D.D2034A36 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LUxhbmd1 YWdlIiBjb250ZW50PSJ0ciI+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEy NTQiPg0KPHRpdGxlPlZpZGVvIGZlM3JmYyA8L3RpdGxlPjwvaGVhZD4NCjxi b2R5IHRvcG1hcmdpbj0iMCIgbGVmdG1hcmdpbj0iMCIgYmdjb2xvcj0iI0ZG QzlBRSIgbGluaz0iIzgwMDAwMCIgdmxpbms9IiM4MDAwMDAiIGFsaW5rPSIj ODAwMDAwIj48QlI+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KICA8Y2VudGVy Pg0KICA8dGFibGUgYm9yZGVyPSIwIiB3aWR0aD0iNjQ5IiBjZWxsc3BhY2lu Zz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgIDx0cj4NCiAgICAgIDx0ZD48 L3RkPg0KICAgICAgPHRkPjwvdGQ+DQogICAgICA8dGQ+PC90ZD4NCiAgICA8 L3RyPg0KICAgIDx0cj4NCiAgICAgIDx0ZD4mbmJzcDs8L3RkPg0KICAgICAg PHRkIGJnY29sb3I9IiNGRkZGRkYiIHZhbGlnbj0idG9wIj4NCjxESVYgQUxJ R049ImNlbnRlciI+PEEgSFJFRj0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbSIg dGFyZ2V0PSJmaW1sZXIiPjxGT05UIENPCQlMT1I9IiNiYjY2YmIiPjxGT05U IEZBQ0U9IlZlcmRhbmEsIEFyaWFsIiBTSVpFPTU+PEI+SmV0U2VrcyBGaWxt IEFyc2l2aTwvQj48L0ZPTlQ+PC9GT05UPjwvQT48L0RJVj4NCjxCUj48RElW IEFMSUdOPSJjZW50ZXIiPjxGT05UIEZBQ0U9IlZlcmRhbmEsIEFyaWFsIiBT SVpFPTI+PEI+VXp1biB6YW1hbmRpciBiZWtsZW5lbiB5ZW5pIHZpZGVvbGFy IHZlIHRhbSBtZXRyYWpsaSBmaWxtbGVybGUgeWF5aW5hIGRldmFtIGVkaXlv cnV6LiBTaXRlbWl6aSBaaXlhcmV0IGVkZXJlayB6ZXZraW5pemUgdXlndW4g aWNlcmlnaSBoZW1lbiBpbmRpcmluLiBJeWkgZWdsZW5jZWxlcjwvQj48L0ZP TlQ+PC9ESVY+DQoJPHRhYmxlIGJvcmRlcj0iMCIgd2lkdGg9IjEwMCUiIGNl bGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImZvbnQtZmFt aWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEwcHgiPg0KICAgICAgICAgIDx0 cj4NCiAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTAwJSI+DQogICAgICAgICAg ICA8L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAgIDwvdGFibGU+DQog ICAgICAgIDx0YWJsZSBib3JkZXI9IjAiIHdpZHRoPSIxMDAlIj4NCiAgICAg ICAgICA8dHI+DQogICAgICAgICAgICA8dGQgd2lkdGg9IjIyNSIgdmFsaWdu PSJ0b3AiPiA8dGFibGUgYm9yZGVyPSIwIiB3aWR0aD0iMjI1IiBzdHlsZT0i Zm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTBweCIgY2VsbHNw YWNpbmc9IjYiIGNlbGxwYWRkaW5nPSIyIiBiZ2NvbG9yPSIjRkZGRkZGIj4N CiAgICAgICAgICA8dHI+DQogICAgICAgICAgICA8dGQgYmdjb2xvcj0iI0ZG OTg2OCI+DQogICAgICAgICAgICAgIDxiPjxmb250IGNvbG9yPSIjRkZGRkZG Ij4gRElSRUNUIERPV05MT0FEIHwgVElLTEENCiAgICAgICAgICAgICAgSU5E SVI8L2ZvbnQ+PC9iPjwvdGQ+DQogICAgICAgICAgPC90cj4NCiAgICAgICAg ICA8dHI+DQogICAgICAgICAgICA8dGQgYmdjb2xvcj0iI0U4QTA2MCI+PERJ ViBBTElHTj0iY2VudGVyIj48QSBIUkVGPSJodHRwOi8vd3d3LmpldHNla3Mu Y29tIiB0YXJnZXQ9ImZpbWxlciI+PElNRyBTUkM9Imh0dHA6Ly93d3cuamV0 c2Vrcy5jb20vdjAwNzcuanBnIiBCT1JERVI9MD48L0E+PC9ESVY+PC90ZD4N CiAgICAgICAgICA8L3RyPg0KICAgICAgICAgIDx0cj4NCiAgICAgICAgICAg IDx0ZCBiZ2NvbG9yPSIjRkZFQ0UwIj48YSBocmVmPSJodHRwOi8vd3d3Lmpl dHNla3MuY29tIiB0YXJnZXQ9ImZpbWxlciI+RA0KICAgICAgICAgICAgICBP IFcgTiBMIE8gQSBEPC9hPiZuYnNwOyB8IDxiPlNpemU6IDwvYj4yLjYgTUI8 L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAgICAgPHRyPg0KICAgICAg ICAgICAgPHRkIGJnY29sb3I9IiNFOEEwNjAiPjxESVYgQUxJR049ImNlbnRl ciI+PEEgSFJFRj0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbSIgdGFyZ2V0PSJm aW1sZXIiPjxJTUcgU1JDPSJodHRwOi8vd3d3LmpldHNla3MuY29tL3YwMTIz LmpwZyIgQk9SREVSPTA+PC9BPjwvRElWPjwvdGQ+DQogICAgICAgICAgPC90 cj4NCiAgICAgICAgICA8dHI+DQogICAgICAgICAgICA8dGQgYmdjb2xvcj0i I0ZGRUNFMCI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbSIgdGFy Z2V0PSJmaW1sZXIiPkQNCiAgICAgICAgICAgICAgTyBXIE4gTCBPIEEgRDwv YT4mbmJzcDsgfCA8Yj5TaXplOiA8L2I+NC4wIE1CPC90ZD4NCiAgICAgICAg ICA8L3RyPg0KICAgICAgICA8L3RhYmxlPjwvdGQ+DQogICAgICAgICAgICA8 dGQgdmFsaWduPSJ0b3AiPg0KPGRpdiBhbGlnbj0icmlnaHQiPg0KICAgICAg ICAgICAgICA8dGFibGUgYm9yZGVyPSIwIiBzdHlsZT0iZm9udC1mYW1pbHk6 IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTBweCIgY2VsbHNwYWNpbmc9IjYiIGNl bGxwYWRkaW5nPSIyIiBiZ2NvbG9yPSIjRkZGRkZGIiB3aWR0aD0iMTAwJSI+ DQogICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgICAgPHRk IGJnY29sb3I9IiNGRjk4NjgiPjxmb250IGNvbG9yPSIjRkZGRkZGIj48Yj4g SEVSIEFOIEdVTkNFTExFTkVOJm5ic3A7IExJTktMRVI8L2I+PC9mb250Pjwv dGQ+DQogICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgICA8 Y2VudGVyPg0KPHRyPjx0ZCBiZ2NvbG9yPSIjRkZEM0I5IiBub3dyYXA+IDxh IGhyZWY9Imh0dHA6Ly93d3cuamV0c2Vrcy5jb20iIHRhcmdldD0iZmltbGVy Ij5BY2lrbGFtYTogQ3Vtc2hvdCB8IGFkZXQgOiA2IHwgdPxyOiBtcGc8L2E+ PC90ZD48L3RyPjx0cj48dGQgYmdjb2xvcj0iI0ZGRUNFMCIgbm93cmFwPiA8 YSAgaHJlZj0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbSIgdGFyZ2V0PSJmaW1s ZXIiPkFjaWtsYW1hOiBIYXJkY29yZSB8IGFkZXQgOiAxMCB8IHT8cjogbXBn PC9hPjwvdGQ+PC90cj48dHI+PHRkIGJnY29sb3I9IiNGRkQzQjkiIG5vd3Jh cD4gPGEgIGhyZWY9Imh0dHA6Ly93d3cuamV0c2Vrcy5jb20iIHRhcmdldD0i ZmltbGVyIj5BY2lrbGFtYTogQW5hbCB8IGFkZXQgOiAxIHwgdPxyOiBhdmk8 L2E+PC90ZD48L3RyPjx0cj48dGQgYmdjb2xvcj0iI0ZGRUNFMCIgbm93cmFw PiA8YSAgaHJlZj0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbSIgdGFyZ2V0PSJm aW1sZXIiPkFjaWtsYW1hOiBUZWVuIHwgYWRldCA6IDEwIHwgdPxyOiBtcGc8 L2E+PC90ZD48L3RyPjx0cj48dGQgYmdjb2xvcj0iI0ZGRDNCOSIgbm93cmFw PiA8YSAgaHJlZj0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbSIgdGFyZ2V0PSJm aW1sZXIiPkFjaWtsYW1hOiBIYXJkY29yZSB8IGFkZXQgOiAxNCB8IHT8cjog YXZpPC9hPjwvdGQ+PC90cj48dHI+PHRkIGJnY29sb3I9IiNGRkVDRTAiIG5v d3JhcD4gPGEgIGhyZWY9Imh0dHA6Ly93d3cuamV0c2Vrcy5jb20iIHRhcmdl dD0iZmltbGVyIj5BY2lrbGFtYTogVGVlbiB8IGFkZXQgOiA0IHwgdPxyOiBh dmk8L2E+PC90ZD48L3RyPjx0cj48dGQgYmdjb2xvcj0iI0ZGRDNCOSIgbm93 cmFwPiA8YSAgaHJlZj0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbSIgdGFyZ2V0 PSJmaW1sZXIiPkFjaWtsYW1hOiBJbnRlcnJhY2lhbCB8IGFkZXQgOiAxMiB8 IHT8cjogbXBnPC9hPjwvdGQ+PC90cj48dHI+PHRkIGJnY29sb3I9IiNGRkVD RTAiIG5vd3JhcD4gPGEgIGhyZWY9Imh0dHA6Ly93d3cuamV0c2Vrcy5jb20i IHRhcmdldD0iZmltbGVyIj5BY2lrbGFtYTogTW9uc3RlcmNvY2sgfCBhZGV0 IDogMyB8IHT8cjogYXZpPC9hPjwvdGQ+PC90cj48dHI+PHRkIGJnY29sb3I9 IiNGRkQzQjkiIG5vd3JhcD4gPGEgIGhyZWY9Imh0dHA6Ly93d3cuamV0c2Vr cy5jb20iIHRhcmdldD0iZmltbGVyIj5BY2lrbGFtYTogVGVlbiB8IGFkZXQg OiAzIHwgdPxyOiBhdmk8L2E+PC90ZD48L3RyPjx0cj48dGQgYmdjb2xvcj0i I0ZGRUNFMCIgbm93cmFwPiA8YSAgaHJlZj0iaHR0cDovL3d3dy5qZXRzZWtz LmNvbSIgdGFyZ2V0PSJmaW1sZXIiPkFjaWtsYW1hOiBIYXJkY29yZSB8IGFk ZXQgOiAxMCB8IHT8cjogbXBnPC9hPjwvdGQ+PC90cj48dHI+PHRkIGJnY29s b3I9IiNGRkQzQjkiIG5vd3JhcD4gPGEgIGhyZWY9Imh0dHA6Ly93d3cuamV0 c2Vrcy5jb20iIHRhcmdldD0iZmltbGVyIj5BY2lrbGFtYTogVGVlbiB8IGFk ZXQgOiAzIHwgdPxyOiBtcGVnPC9hPjwvdGQ+PC90cj48dHI+PHRkIGJnY29s b3I9IiNGRkVDRTAiIG5vd3JhcD4gPGEgIGhyZWY9Imh0dHA6Ly93d3cuamV0 c2Vrcy5jb20iIHRhcmdldD0iZmltbGVyIj5BY2lrbGFtYTogSGFyZGNvcmUg fCBhZGV0IDogMTAgfCB0/HI6IG1wZzwvYT48L3RkPjwvdHI+PHRyPjx0ZCBi Z2NvbG9yPSIjRkZEM0I5IiBub3dyYXA+IDxhICBocmVmPSJodHRwOi8vd3d3 LmpldHNla3MuY29tIiB0YXJnZXQ9ImZpbWxlciI+QWNpa2xhbWE6IEhhcmRj b3JlIHwgYWRldCA6IDEgfCB0/HI6IGF2aTwvYT48L3RkPjwvdHI+PHRyPjx0 ZCBiZ2NvbG9yPSIjRkZFQ0UwIiBub3dyYXA+IDxhICBocmVmPSJodHRwOi8v d3d3LmpldHNla3MuY29tIiB0YXJnZXQ9ImZpbWxlciI+QWNpa2xhbWE6IFB1 c3N5IExpY2tpbmcgfCBhZGV0IDogNiB8IHT8cjogbXBnPC9hPjwvdGQ+PC90 cj4JDQo8L3RhYmxlPg0KPC9kaXY+DQo8L2NlbnRlcj4NCjwvdGQ+DQogICAg ICAgICAgPC90cj4NCiAgICAgICAgPC90YWJsZT4NCiAgICAgIDx0YWJsZSBi b3JkZXI9IjAiIHdpZHRoPSIxMDAlIiBjZWxsc3BhY2luZz0iNiIgY2VsbHBh ZGRpbmc9IjIiIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYTsgZm9udC1z aXplOiAxMHB4Ij4NCiAgICAgICAgPHRyPg0KICAgICAgICAgIDx0ZCB3aWR0 aD0iMTAwJSIgYmdjb2xvcj0iI0ZGOTg2OCI+PGZvbnQgY29sb3I9IiNGRkZG RkYiPjxiPiZuYnNwOyBBUlNJVkRFTg0KICAgICAgICAgICAgU0XHTUVMRVI8 L2I+PC9mb250PjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxl PiAgICAgIDx0YWJsZSBib3JkZXI9IjAiIHN0eWxlPSJmb250LWZhbWlseTog VmVyZGFuYTsgZm9udC1zaXplOiAxMHB4IiBjZWxsc3BhY2luZz0iNiIgY2Vs bHBhZGRpbmc9IjIiIGJnY29sb3I9IiNGRkZGRkYiPg0KICAgIDx0cj4NCiAg ICAgIDx0ZCBiZ2NvbG9yPSIjRThBMDYwIj48RElWIEFMSUdOPSJjZW50ZXIi PjxhIGhyZWY9Imh0dHA6Ly93d3cuamV0c2Vrcy5jb20iIHRhcmdldD0iZmlt bGVyIj4NCiAgICAgIDxJTUcgU1JDPSJodHRwOi8vd3d3LmpldHNla3MuY29t L3YwMTA2LmpwZyIgQk9SREVSPTA+PC9hPjwvRElWPjwvdGQ+DQogICAgICA8 dGQgYmdjb2xvcj0iI0U4QTA2MCI+PERJViBBTElHTj0iY2VudGVyIj48YSBo cmVmPSJodHRwOi8vd3d3LmpldHNla3MuY29tIiB0YXJnZXQ9ImZpbWxlciI+ DQogICAgICA8SU1HIFNSQz0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbS92MDAw Ny5qcGciIEJPUkRFUj0wPjwvYT48L0RJVj48L3RkPg0KICAgICAgPHRkIGJn Y29sb3I9IiNFOEEwNjAiPjxESVYgQUxJR049ImNlbnRlciI+PGEgaHJlZj0i aHR0cDovL3d3dy5qZXRzZWtzLmNvbSIgdGFyZ2V0PSJmaW1sZXIiPg0KICAg ICAgPElNRyBTUkM9Imh0dHA6Ly93d3cuamV0c2Vrcy5jb20vdjAwNDguanBn IiBCT1JERVI9MD48L2E+PC9ESVY+PC90ZD4NCiAgICA8L3RyPg0KICAgIDx0 cj4NCiAgICAgIDx0ZCBiZ2NvbG9yPSIjRkZFQ0UwIj48YSBocmVmPSJodHRw Oi8vd3d3LmpldHNla3MuY29tIiB0YXJnZXQ9ImZpbWxlciI+RA0KICAgICAg ICBPIFcgTiBMIE8gQSBEPC9hPiZuYnNwOyB8IDxiPlNpemU6IDwvYj4yLjgg TUI8L3RkPg0KICAgICAgPHRkIGJnY29sb3I9IiNGRkVDRTAiPjxhIGhyZWY9 Imh0dHA6Ly93d3cuamV0c2Vrcy5jb20iIHRhcmdldD0iZmltbGVyIj5EDQog ICAgICAgIE8gVyBOIEwgTyBBIEQ8L2E+Jm5ic3A7IHwgPGI+U2l6ZTogPC9i PjMuMyBNQjwvdGQ+DQogICAgICA8dGQgYmdjb2xvcj0iI0ZGRUNFMCI+PGEg aHJlZj0iaHR0cDovL3d3dy5qZXRzZWtzLmNvbSIgdGFyZ2V0PSJmaW1sZXIi PkQNCiAgICAgICAgTyBXIE4gTCBPIEEgRDwvYT4mbmJzcDsgfCA8Yj5TaXpl OiA8L2I+Mi45IE1CPC90ZD4NCiAgICA8L3RyPg0KICAgICAgPC90YWJsZT4g ICAgICA8dGFibGUgYm9yZGVyPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9ImZv bnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEycHgiIGNlbGxzcGFj aW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQogICAgICAgIDx0cj4NCiAgICAg ICAgICA8dGQgd2lkdGg9IjEwMCUiPg0KICAgICAgICAgICAgPHAgYWxpZ249 ImNlbnRlciI+PGJyPg0KICAgICAgICAgIDwvdGQ+DQogICAgICAgIDwvdHI+ DQogICAgICA8L3RhYmxlPiAgICAgIA0KICAgICAgPHRkPiZuYnNwOzwvdGQ+ DQogICAgPC90cj4NCiAgICA8dHI+DQogICAgICA8dGQ+Jm5ic3A7PC90ZD4N CiAgICAgIDx0ZD4gICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjwvcD48L3Rk Pg0KICAgICAgPHRkPiZuYnNwOzwvdGQ+DQogICAgPC90cj4NCiAgPC90YWJs ZT4NCiAgPC9kaXY+DQo8L2NlbnRlcj4NCjxicj48L2ZvbnQ+PC9ib2R5Pjwv aHRtbD4= From owner-kdb@oss.sgi.com Sat May 11 06:55:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4BDtPwJ024507 for ; Sat, 11 May 2002 06:55:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4BDtPYh024506 for kdb-outgoing; Sat, 11 May 2002 06:55:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4BDtNwJ024500 for ; Sat, 11 May 2002 06:55:23 -0700 Message-ID: <20020511135702.75921.qmail@web13709.mail.yahoo.com> Received: from [203.200.72.12] by web13709.mail.yahoo.com via HTTP; Sat, 11 May 2002 06:57:02 PDT Date: Sat, 11 May 2002 06:57:02 -0700 (PDT) From: Mohit Jain Subject: installation query To: kdb@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-kdb@oss.sgi.com Precedence: bulk I am not able to load kdb working in my system although i have installed the modutils and applied two patches common and i386 successfully ,kdb doesn't seem to be working for me. kindly send me detailed instructions step by step so that i could make it work. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-kdb@oss.sgi.com Tue May 14 12:10:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EJAanC009835 for ; Tue, 14 May 2002 12:10:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EJAa6V009834 for kdb-outgoing; Tue, 14 May 2002 12:10:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EJAWnC009827 for ; Tue, 14 May 2002 12:10:33 -0700 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id DE72E9214 for ; Tue, 14 May 2002 15:10:55 -0400 (EDT) Received: from minbar.zko.dec.com (minbar.zko.dec.com [16.31.224.10]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 65EDC190E for ; Tue, 14 May 2002 15:10:55 -0400 (EDT) Received: by minbar.zko.dec.com (8.8.8/1.1.20.8/29Jan01-1009AM) id PAA0000013282; Tue, 14 May 2002 15:10:54 -0400 (EDT) Date: Tue, 14 May 2002 15:10:54 -0400 (EDT) From: Daniel Christians Message-Id: <200205141910.PAA0000013282@minbar.zko.dec.com> To: kdb@oss.sgi.com Subject: kdb tar ball for alpha? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: iAONeVKu2r0JC5tmNm8l6Q== Sender: owner-kdb@oss.sgi.com Precedence: bulk Hi, I would like to use kdb to help me debug a problem on my alpha smp system. It is running a RedHat kernel version 2.4.9-32smp. I read that kdb comes in two patches, one containing common arch independent code and another arch dependent code. I have searched but only found patches for ia64 and i386. Is there an alpha arch dependent patch? Please note I am not on the kdb mailing list, so you'll need to email me directly if you can help me out. Thanks much! Dan (daniel.christians@hp.com) From owner-kdb@oss.sgi.com Tue May 14 12:20:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EJKZnC010009 for ; Tue, 14 May 2002 12:20:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EJKYGS010008 for kdb-outgoing; Tue, 14 May 2002 12:20:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EJKTnC010004 for ; Tue, 14 May 2002 12:20:30 -0700 Received: from linux ([12.224.214.127]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020514190155.CUDJ25765.rwcrmhc54.attbi.com@linux>; Tue, 14 May 2002 19:01:55 +0000 Content-Type: text/plain; charset="iso-8859-15" From: Charles Johnson Reply-To: cjnaj1@attbi.com To: kernelnewbies@nl.linux.org, kdb@oss.sgi.com Subject: Question about kdb output Date: Tue, 14 May 2002 12:00:38 -0700 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02051412003800.01043@linux> Content-Transfer-Encoding: 8bit Sender: owner-kdb@oss.sgi.com Precedence: bulk I've build 2.4.18 kernel with the kdb patch. However when I break into the debugger by pressing the key, the output is not coming out at VT1. I have to hit to prior to hitting to see it. I thought the default for keb was to use VT1, so now I'm confused. Is this the normal behavior ?? Thanks. --Charles Johnson cjnaj1@attbi.com From owner-kdb@oss.sgi.com Wed May 15 04:20:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FBKZnC025781 for ; Wed, 15 May 2002 04:20:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FBKZYJ025780 for kdb-outgoing; Wed, 15 May 2002 04:20:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FBKUnC025777 for ; Wed, 15 May 2002 04:20:31 -0700 Received: (qmail 27909 invoked from network); 15 May 2002 11:20:54 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 15 May 2002 11:20:54 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 55C5A3000BA; Wed, 15 May 2002 21:20:52 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3F30898; Wed, 15 May 2002 21:20:52 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: cjnaj1@attbi.com Cc: kernelnewbies@nl.linux.org, kdb@oss.sgi.com Subject: Re: Question about kdb output In-reply-to: Your message of "Tue, 14 May 2002 12:00:38 MST." <02051412003800.01043@linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 21:20:47 +1000 Message-ID: <21592.1021461647@ocs3.intra.ocs.com.au> Sender: owner-kdb@oss.sgi.com Precedence: bulk On Tue, 14 May 2002 12:00:38 -0700, Charles Johnson wrote: >I've build 2.4.18 kernel with the kdb patch. However when I break into the >debugger by pressing the key, the output is not coming out at VT1. I >have to hit to prior to hitting to see it. I thought >the default for keb was to use VT1, so now I'm confused. Is this the normal >behavior ?? kdb output comes out on the kernel console. Some distributions redirect the console, change your boot parameters. From owner-kdb@oss.sgi.com Wed May 15 04:22:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FBMVnC025873 for ; Wed, 15 May 2002 04:22:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FBMV3F025872 for kdb-outgoing; Wed, 15 May 2002 04:22:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FBMRnC025868 for ; Wed, 15 May 2002 04:22:28 -0700 Received: (qmail 27918 invoked from network); 15 May 2002 11:22:52 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 15 May 2002 11:22:52 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 017643000BA; Wed, 15 May 2002 21:22:50 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id C341198; Wed, 15 May 2002 21:22:50 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Daniel Christians Cc: kdb@oss.sgi.com Subject: Re: kdb tar ball for alpha? In-reply-to: Your message of "Tue, 14 May 2002 15:10:54 -0400." <200205141910.PAA0000013282@minbar.zko.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 21:22:45 +1000 Message-ID: <21619.1021461765@ocs3.intra.ocs.com.au> Sender: owner-kdb@oss.sgi.com Precedence: bulk On Tue, 14 May 2002 15:10:54 -0400 (EDT), Daniel Christians wrote: >I read that kdb comes in two patches, one containing >common arch independent code and another arch dependent >code. I have searched but only found patches for ia64 >and i386. Is there an alpha arch dependent patch? A couple of people expressed interest in doing one but I never saw any results. Sorry, you are out of luck here. From owner-kdb@oss.sgi.com Wed May 15 18:06:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G16NnC011301 for ; Wed, 15 May 2002 18:06:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G16M6a011300 for kdb-outgoing; Wed, 15 May 2002 18:06:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G16InC011297 for ; Wed, 15 May 2002 18:06:18 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4G16kFD152622 for ; Wed, 15 May 2002 21:06:46 -0400 Received: from w-gaughen.des.beaverton.ibm.com (w-gaughen.des.beaverton.ibm.com [9.47.17.17]) by westrelay03.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4G16jN77690; Wed, 15 May 2002 19:06:45 -0600 Received: from w-gaughen.des.beaverton.ibm.com (gaughen@localhost) by w-gaughen.des.beaverton.ibm.com (8.11.6/8.11.6) with ESMTP id g4G13Tt03790; Wed, 15 May 2002 18:03:29 -0700 Message-Id: <200205160103.g4G13Tt03790@w-gaughen.des.beaverton.ibm.com> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Reply-to: gone@us.ibm.com From: Patricia Gaughen To: kdb@oss.sgi.com cc: colpatch@us.ibm.com Subject: having trouble with kdb on smp (kernel 2.5.9) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 18:03:29 -0700 Sender: owner-kdb@oss.sgi.com Precedence: bulk Hi, Matt Dobson and myself are trying to use kdb to debug a hang during boot on 2.5.9 on an 8 proc numaq box. I saw the recent patch from Ethan Solomita and I'll give it a try tonight or tomorrow. But we've ran into a couple of issues: - when the system hangs we enter kdb but using bt, bta and btp do not produce stacks for any of the processes. We're able to get the stacks manually, but this is not much fun :-) - Also we're not able to switch cpus. Are these known issues? Should I expect Ethan's patch to help with this? and finally, where would you suggest I go from here (in terms of getting either of the issues above fixed). Thanks, Pat -- Patricia Gaughen (gone@us.ibm.com) IBM Linux Technology Center http://www.ibm.com/linux/ltc/ From owner-kdb@oss.sgi.com Wed May 15 18:13:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G1DFnC011356 for ; Wed, 15 May 2002 18:13:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G1DFbV011355 for kdb-outgoing; Wed, 15 May 2002 18:13:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G1DBnC011352 for ; Wed, 15 May 2002 18:13:11 -0700 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 18:13:34 -0700 Received: from cs.columbia.edu ([10.2.4.63]) by afara-ex.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 18:13:34 -0700 Message-ID: <3CE307BE.70305@cs.columbia.edu> Date: Wed, 15 May 2002 18:13:34 -0700 From: Ethan Solomita User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gone@us.ibm.com CC: kdb@oss.sgi.com, colpatch@us.ibm.com Subject: Re: having trouble with kdb on smp (kernel 2.5.9) References: <200205160103.g4G13Tt03790@w-gaughen.des.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2002 01:13:34.0331 (UTC) FILETIME=[E64E34B0:01C1FC76] Sender: owner-kdb@oss.sgi.com Precedence: bulk Patricia Gaughen wrote: > > Matt Dobson and myself are trying to use kdb to debug a hang during boot on > 2.5.9 on an 8 proc numaq box. I saw the recent patch from Ethan Solomita and > I'll give it a try tonight or tomorrow. But we've ran into a couple of issues: > There have been a few -- there was a 3-line fix I sent out after that, and then the i386 patch in a third email. Sorry if that's confusing. > - when the system hangs we enter kdb but using bt, bta and btp do not produce > stacks for any of the processes. We're able to get the stacks manually, but > this is not much fun :-) > > - Also we're not able to switch cpus. > > Are these known issues? Should I expect Ethan's patch to help with this? and > finally, where would you suggest I go from here (in terms of getting either of > the issues above fixed). > Those are wierd. I know that, on sparc64 at least, I cannot use btp to backtrace a process which was running on a CPU when kdb was entered. I need to switch to that CPU first. But the symptoms you're describing sound like things hung so badly that kdb isn't coping. If your problem involves memory corruption, it is possible that it has damaged kdb's ability to work. -- Ethan From owner-kdb@oss.sgi.com Thu May 16 17:51:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H0p7nC019804 for ; Thu, 16 May 2002 17:51:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H0p71C019803 for kdb-outgoing; Thu, 16 May 2002 17:51:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H0odnC019799 for ; Thu, 16 May 2002 17:50:39 -0700 Received: from trex.ccur.com (users.ccur.com [208.248.32.211]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA03939 for ; Thu, 16 May 2002 17:51:05 -0700 (PDT) mail_from (jim.houston@ccur.com) Received: from ccur.com (IDENT:JNkyYM+42ZAsgdH6OfxHPP3l418RyYI7@localhost [127.0.0.1]) by trex.ccur.com (8.11.6/8.11.6) with ESMTP id g4H0Y8M05978; Thu, 16 May 2002 20:34:08 -0400 Message-ID: <3CE44FFF.F4A3EBB2@ccur.com> Date: Thu, 16 May 2002 20:34:07 -0400 From: Jim Houston Reply-To: jim.houston@ccur.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: kdb@oss.sgi.com, kaos@sgi.com, ethan@cs.columbia.edu CC: jim.houston@attbi.com Subject: [PATCH] - SMP fixes for i386 kdb Content-Type: multipart/mixed; boundary="------------903DC280C9398BFCFEE46CAD" Sender: owner-kdb@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------903DC280C9398BFCFEE46CAD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Everyone, The attached patch is an update of my earlier patch to fix smp problems in kdb. I started with Ethan Solomita's patch but I have change a lot of code since then. I have been exchanging private email with Ethan over the last week and he has helped find some of my bugs. Thanks again. There are always more bugs but I think this patch has reached the useful stage. The changes are: - Splitting up the kdb_state variable to decouple data used for inter-processor synchronization from local flags. - Avoid having an extra layer of nesting if a processor is already in kdb when the kdb inter-processor interrupt is delivered. - When several processors enter kdb at the same time treat them more as equals. My test is to be able to switch to another cpu and see useful state and be able to single step. With the released code or Ethans patch the inter-processor NMI interrupt may interrupt the kdb entry code. This shows up as a confusing backtrace when you switch to another processor. Jim Houston - Concurrent COmputer Corp. --------------903DC280C9398BFCFEE46CAD Content-Type: application/octet-stream; name="kdb-smp-jim-0516.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kdb-smp-jim-0516.bz2" QlpoOTFBWSZTWawbLaUAMjffgHgwf///////3+6/////YDb/eAeIkXbodce7Y27tS5q673yh 496u773o59ccoUrph1qkSlPu724+6beD6DfEwc21e8zet99gqDvfaTbDAxNXs0DOc+W8rb3O dnT03Mq8rzXDwBex7nV1i8t7bUtWt473Nt5jrz3exl92fC9fe5OVWne7Pecretc3g0ts2eg4 AHu2rSGmiBDQBNACaAhqaGNCemo0m9UbRBoGQPSNASmhNBE00gjRE8Kan5GqeBRjKDamh6QB iAAAEgihIp6pp6npBo9NT1A0PSNGgDCaAA0ADQDQSaSRJoTEKe0U9GpmnqT1NoyEMnpM1NMg HqA0AAARJEJNqYI1GSeamhT0YKfomptTaBpommEZMJ6g0GgESQgQTTI0CaKepP00T1NR6nlN MmjTag0GmjQNBo0NOrhXMYFMGoEIKEgyAhSUhQMGQURggqFUjKhAJGB3APG95BVGQYYhSKwb awUQVVjRKIVIUBEYILFFRQUSlWAiIMpe8Vx+q4ME1ZQqVRlKCgVC0RCogqi1LLaMaWCpawSV LSiNYpC2oqsi2rFBu6MaLiMoYtuK4ZcSZjQq1tSWplmQSmDV69f4zvs2jNBdxOJqI8c7TXJj kw3R+17F5yL3+9dF2Djm2ttstKFTskHY7UwK4ymf28M99rhoOQ3mpN3YR7CLnLXsg2m5EtCu y0bbsrEaDQRMSqtBG225tmtKq1FpQpFXVplW41VUxCgqjlzLUMy4lVxlEHa602tZoFLcZYua dZdiuyGEcSYOog7WgjiRCxwHZYvKwCf+kNJ0Vce92DhU7ICa2c5ENgqmUpUrbRctozMzMarW 5mDbMamW21wuWrFqJaW45glYOFAoWyZKIqWFwsDAZLBhkMnRM/ayK+NSscG5rqnpWtPnZ8ac 84HEmPjdyZCEYszN9Hs9mj4eP2eH6290KYg4gkFBrz/i2p+lGyLA5HQrFUFrAqSoViqCysPs JMSNYA/yP8R5TPTRqy3wYdMpPQYgZzSIVCRXRtS6ox0DJjFLaOWOVaCYhUmMFMZiK5LWRWJF tty2NSRMclRkVi2mGI3bbNSChoZUgF2tylVAUxBYRVMeOjZzfMMHYcyY0uGjBoNKWVE/hEGW GJhw468KEg40FhEtJcaoTARllokmZQqBQpRmYDkPqLyB+jbg3/aB6NFgiJc/hSo6ZxhGAVDB AQT1P1pNJ6jjTTUab1GNSusOtnEyeloEHJxezyEDynzwFVdqlSDZ+erTbWIPKBrtW4TmZKLi HNaQz95iPdYs6pRL3JiHh/ALLMPJeu8n2TRWEqiLCNFS5GSMo+73a9Xt/n6N51o69C3Dz0o6 ZUSwPu1Ju+Ls+KxZfyYbZIFea7btLCgoSbwG0aFg5eyp3Q6vDESyt5nL/zv3R1hfozne0bS+ 0iEIIdBJyf8dux3+nPlljLvKITkphOR7HKSU0/3B7GDCh29ThShO1dD3Loe3htGstnTrXEDd rNTcOGZd5FjuSmQCMZ01wysOGDePbOmlb1S+20V8D+HUricNea9l+jLrnAdWpZoMQ7bq1uVV OtVIJyoXwM02lnPvLsmh2XNa1baKzrC0Nf4OWVJquhyFfl+ijZxsJmIRTu7uD69GdeKQF2Gj IF5bRlqKYW6J4cMp4jICRoGUWBohFGChz1bUYSlrODgrRGn1H26pLVWayY0mNIVOxeHQkEga FDjFwHZZfyVJ1gti22GkfjIWwi1EApJJJXVL/Ji8Oi1MVkEsA9FVtwKkOKlEVlzxWg4iLMvl PwGLGVaw6897VJQQJCqEnsuq8WfyLzcUkjJwiLwTMp4emGEbbAp9WixMMb40pSEDLapkpIis brVCnDhXFlgNnLzOVSgcdpnpQafjpGsfHWMqBM22Wg2qHBWVGKGIlheOB7jMkzilJkFfh7cY Nrn5hrPuer4uopWurpk+b+nHT6eWTpxPhQA8pgScVKlVVFxVScnv1LbhqV2bLRYoVqLBVRdZ 3+/3e3fLZZsfc10C5SCCKU9Y9ZxBAs3+qDZb8hhz4WulDRti3TlabV5LOt9tsZSU7O9r4krL qe+YWtTecRkYD+JhUqMisIoknGCAesLEVNLTnavHh33DP0cNnH28R4yJxRdYIHgHtwPML6Gh 9QZHqouZ0BWBoD5tKDogeelMJ9sqBzRKeqlNBIWZx2KLRCBKofr8fo+vk2nmODGL/rLa/TIv qGB4eetscQ2Xe1Di68TsgB5AzDA8gFBZIcC7YgcIdqxRUfBYowhR4dO48NGJ6eby/X0BnOnz S1qfvk10Ns8rc7zDvyr3FHZAiQRh00VAe9PREeypE4aaExhzlFaKoDGInjgEnwY6D4lFh4xU WKIVtG0hRRsGgvUpFWCgfZcYaYisUNIKI6aqKAsBbSmkaOsMZBdNZFFFAvxQkWFOuWjs5SJj fIwvD3B0u0jqZpmjx6bKf9Pv2l3ZGvzPumyn2ju57b3H05381UffbbUwIdR7InlGE5NHJ87o JtvVGIPZ9+xnzh32rwLqnEkeoDwj5V/gv7/Iq98ufqJIQ6a6pJFlD1Ul1e1aPL3nq/IP1El8 rHkfmRKCAOPd9gnZE6PeDx/mGnASaSEkhykL6IkFJDozrztPo9vMPjFOIaPq/Ftgf8IMLBEC CXXVv8Q9QX4/MLyvzQRwc9SRz6EPCwDu8+yzMogo5AIw5JyX3fLDaInsSm5zAaQ6aIKZSEYx i5os6zHw/7PFthSDUm4P08vDrrYhNuicY5pgs+vAP/RzwKaAgZEK8qBJCjEEdeIOVnLnO47m XiWxC+V/FVaEIc0YKxlEAspKsIQh4BOsk7VVBj3j3q5w9eah3YPCIcEGfaFQD6/Vztsr3lKr YrxsnQHRVCChRYKcnl2fXtVZwH3UnBPjQESce5w/SWhzIRTaKBbVAWC8mcz5GUh2EObrHkl9 9FZd22w8KuOkCEGRdScuwwcD/PC5Qfn+iuhBYcvu2gjCJ4B8LidaFVRi9P5g8Jbjt4fKfE81 x9D4bA/jvHN5nKrRVBkra2Z1Xc+Wjg/PtO9pUHoR1VRhWmr29O/h9ejPH8JPBm3PXv5nmUOa dx326bFohHctrvbjByJT31OCeMTnE6zvQQJRewoiKRDEAVXJoKcdvBgHPSsgJl7xZudOccDQ ZAtDCiktRaZjAQmBEvpvyqbraYri+Vd1UYQz0hWes3F+0mxRjmj6U9ifPOZ6QPmBPp9Ft29K bibb7+3JbVm1ldQOmNUM50zFXCIpR2gEEGyoCJS228YUr+Vt8BnXTULgYEBnReMdonTHFa0a jO7bWA8RO6QkhQpZgvQN4Ea8zYuuqm6yKNebxTRbxNyfmEC7avEsKcgUWm2KgQJCEEfVqgPv CZcMtV1PHNwdueNZ3AzgtLMGZ5PPtzZDdHg7/y5W3gOeJXwwRvz1WqGgRIPu/b0zro3v7nvK ZSyAJrxDxgI7cHCOTlcLjRdKUBi03JvDYDAOwduo1s8MCBt6MYZRpvFeVeOP7iINKwM9Rk3Q 9S7HbOiumxjHg4/ifHmP0MxAwmBB6tJPA4eZDOA/mKCfB8637NxTW3ONuuiGIwDNU0q25me8 ZSzJyoixqUny9d+jMdMiuEDRPfW4sYtEvtRgxPGTz9d+QwF9973h2IhdojGW2/JfbMcTmTHY oFpdSi0Uc4p7+VYsJ3U2als3xsxLXSBpxdvOx9EKm1g0amD6Rs1CIqupJwbTbhQdraUHQzfa ah88ftT+kXqJ+ZkZBA444kKHMK3yCOd3OTpXH9HXIXxu+0hhuaHrJs/hVeGDRURksIsjsmK4 5zNYRn4Fa34o7kz5c78yqXNja5VXezSya32LE7e6J5WhvOE8a58yPy7+bwsaz4NlVVVVVfm8 ivstfKrVVeAdL0dM6Tb1E+/i90TzaxGT0dS7FrXJLfAijd3K9vlnO6bYEhfNn8YCM9Vc+uk2 DkX0HGnEsGkiwBe/s4KcJ9F4o01aj8DO7euddzmDOYwCNZX4eYxfns4erA/ccPTuH3qLKwoj pWzYLhSKVlZEdvGeeURBRfgLAKhOAtanuYlxIT6iC7s4g7nlWORxWK35tlHtOx7iCuzMxvpx 7sgnRzRyYJbaNxdOxTU5v8eMnxX6VVsD1BzUBEmpwoVtiq1nmrdWUFGFb/pmw12RDh0vjksA wBI5mttxg5yndbnpVTZjt6wMkDghQDOqWMx52q43iGNfVDQ5drRSdj4DIq/5TDbpv0Bz1+65 3WNc5gDIoec63tt4cVa/xlz9hldqUnBvg2o2XYkuh0ah4Ty7u9pk9nxrqXm/4ozL5s/pv5FC tr5JvM8P1WujSXLjFniqwLvr0ULEmTTmzq1nGxQ+u3QIQiEqsuCtOvJhTYSlP2fUZRDpX7dH 1oixjtjtNoGwa6wdRTzZyF0fFLRkL9oqC8YJfq8d8LQkRZX7/Xj0Sr5rqofjW8Y1+eCRoWPC T6lnFRpybT9GYhIQ1V3AvhQcOJghoWKLCutd3TNyPPW1q7avi2p+KPDWu/tB31gh1r6SiPCT Iel9zM68w/m1Xbji22u2cXju1sXQx4syaiKdXTReC3gBIjRCTInfif3LgebQ+xJD+kFiw9VW DZRIIMk6rNnHuwFCINhCDX7cdN6834j9XjQg0kDN32eJ9vix+dWoc5Wg9/vhD8/5r56bssYy mWWQdROrGBGERWe0jQQqfsZPSx+SttSkRIKD81kKjBYjJKRU6mKEYJCfrJoZ6C5GuqL+0Qkk UgrhHGgqSJIjHm+WUcDxNbWCPiUPpkIh2xWIEGeciHr83g0+APMe4dZxBRAs8aPVOPvHdV51 x3WmLTjAbfQ7RHOndv2N31i0m1AamLmLyqE+5veia00B+J4InQzGL/dJ0I3JE599MhCkrfK6 BLxMA6ODeSEOXbLCSIcbgpGbVbsKzTTpnkkXo+IgZ6KM9piQg8nu9PuPJs3bXNHGJq3pR2PZ Sa9hsLJcib42v+OwHhNou6DkGpQ3IkiG32UZQ0weijRt2jc7ZpoLd3nZn6PH5PPAYtZMWLwK 9ET2twcbPtWxwtOBAcC6GrzB0MRXh4XsSkACUT4lMrNI5nY+bKv2v6FFyOygGTWRhn6vM7G1 QMTgUnbqSnYWvOTBUHdjotxeBzDfbBwvpUKZkSsgjbuaUXVwixJK1V1CT0lVkw1bre11NCoB Mekc10IQHEiws/1jYMU8HN0EGlR2sBRMqB03c/b55vOjy9/00Gnxz/l3V/nVbKY9vaK5tOrl BJ7UtPXo2OFHYowITylInQvDGVnl7jKGnrrAyV8OjK7vjQMp9F1VFG+uLdPFzXdlEcXX1GZG UL3GWcFcapyuoAeHt1gulxlvtpq1yljnzLYuLg0Tv4CQqw1YQjZWwaCixUrYLLA4RVwGpyqd Q7ICriMpbxNbrayEzjFtuOVzocx3VRthKtzZiN82qnQAQ9Yg73LPcDRuvqtq2kUbbyonufar c+7bKbV5d3u3+PluE9Ne8+kRPzoRIgQIAMFEYIigooiMESKKokERGLGIxQVVGIqKKgoKKMis iosIoghFBQWCyDEFQ2Cgysz7KkfyIqAfJSKhFNIJ7V7+lGBJz5yaB9emSFkUoKUgQQkAieTq 067+XTMDq6EXO4DUA5Oc7yOaxQIgpwfuZAFGlU+2jmNfF9oPbV+DhdHc/HOybhwFw2yz7NFd J9QspjiMZEZViwUO8/U6okil8fQOgEfq8m88tcuYK9gJ20VVu4n2F2oXAaQHJt36x8zDUMxO IJxZ8gXvp3UhcJh7mRKyCQEpFChEl6RewEh8gLDPGyoTvybZ7/Z6UX08SfrPPFX/di0UQau+ ausTNERGMRjIspTfKxGMCIfD4vmptlWyVakjNr4mYi68aR9LMwMH1IBIA+qqVIJ+ESU0D6lC Yl0A+BAHEPoFOPQiIwQc2kITIAsECpu0l26hgzdI3P6nifKPwW8rqjjXzQZF66zrv6fDPurn +RbbuPsls7zLj2kin18O7F3o8stlevKQ0kLpesXW4KhnKm7I4xC/d4A7eFyDAIiZ+/jmF/4p TzLRDzMwpeZnv3SSSwejpxY81QvH0Ax40VffQ8/L3vSXBuXjQlSQS0ASoloh/BKwXSaDzefw 8oiIiI89nR6we0AbaERwKpKiI+UBoiPcCFIhgHc5APPvXh4mY+AwfPz9XrmUNk/UikNH101/ qdv4CgSBxwcXmNWt9hj8NDBKNnfbDjA7zLdAPJMPDEuifYtF4iS1tNerYJhWA1YEMwg9AB7q u6rNJLNHRw2MuZayVCAVRDs5aTy1rdv+j2fS5vGaO8bbya+85JY58sDCYOBTaSMLO+4jiLE2 QSScTIlNqCuaKikMJEQoaDEYni224Z2viS3rphIDYm0zRHpsR3dXyIMxMjFGGT0GGWqUhTjT hzqAgqwrvFLXOcAQpUK8UzGp7DFt01J5gruxTofLg10vfUCc28MXW9zMa2F+ubEvMQ6fu6P0 d/pAH2Qx5uoH0xxc41poHOXm1Pqh358OfDw14M0uJPgfKddInukPHaiEeXTrm8XvbHjnRvOb X5QhjAw/2XZ0zeKGcYh3RutoS+Isumds5mZ4pgMT0/H6CDq1sr7uo64TOQAbSS1trVyxFtzR NMbzG+2mD0c42sqicZRQhC1HBvO+ulZz5hebza/WXLAHUx26lupw4jiqmMPF1BDKHudU5fX2 bvp+r2fB2z6IeqQ9Jh8o+YDuJe2KJx0hMyB2ju90XhA9ACeenvy7+9q29ygKaQskIb5Dp+ly J7NSiJFBQnedOSpMpZF5z+sq9O82n0nuVSZDczBigf8FSBA0Qe2QPjiv7DyLS0UdLnpAoKfM oC+VUQPn/dtZAJECAMik9OpGS1VD8sWQNHHyVSdVERClQKyhN44QMIzo375cJA4Q1Ek0mqvt 3dGeWDudNefHIzu5zznKPpV7ORNpusVNYUPaQeulJyh6S+7nZnct7acE50qzKTqZFCZy02Zg kOlPhQbxO6GCkzk3QzLhiSukA4yA/nD7/y+W7C4JSkAa5nU95CURNtkxWFYlLVWglsGJBixP E3CytbC1SosCBVKfc9T1+0dk8PLs1kOIFLUXy+gHViOBQodPX8Ofb8fsEU4kU+tFOx1v4foD oCu/932nbwVMEVf2AZ3RELZ/Z9BZHIbBwD7SJAnx+TERQdvyQhYfL9FIVlEt6EQ7UnKNhxma gGkVQLJuPPiDxAZKOZ/WkKN5oqqpstMUGeisxbffupKltxD8kcYqpGKsYgoQBD6d9YkmkGoS NZciSASDF0BYHe7VEL0VHngfpDfvDiUYo9qkeqgFhdORvDYLo43/taDFr6Fi34yhLcXGwGtB wVP5LXvAE7CABt4T0s1u89FPK2AjjyMsGQwBkYSLIGlUvV3d6FgG4IUafreMQzJHwkCRg8DY yTw5slQhVBSSiUFCVKwbiclOZo9DpkkGQZ2gOfaFbGe2IEUkH1B8wbIHpMoc18e3J6Bq5ab3 SWAkR+G0hNAT0KwMMD7d2H7pwpIbIbv9eENMylRLaKiLUlqmiQUKFhKE5PWtty45kiwFiyKq MJA2N0K69Bj4ewNi6hko5cLyEIR9Dz69d/sZMg8yJoHG837sC/7cAdeDsj/68tJQQ5bXAdwn iEtx8U2NVZSgSLAHMzXYcSMXJ2mj3Y/UEH5l2zYG4aVrTElriXIgWepN8oiZdLqewBp6UHh1 D7ah9da+0poWDzqN7dq7mdjqHyBlGgBJIEHBUgGRe/ya3VvIPLZ2gJIvYAuu1gm8KXJUhvnO ltYNwL1NyFG+FCcqs+njpYOgzv5q2zWK4DeIadimmbT8GPbhUN0c5uilBz4WLDEHcLxEdZDg owo1lEDnEbEU4SEGEVQkQQ0yAvxuqGCKZ8817ksCec7gvNNVCirVUAa5cURDIDRTeihZCIIb nQPLFnwywMiu5KErANAuendJFkQkYJEmu9EO3eAHZAQ2DTgYXZ4K6Ke2Lq7/yy0NQCahzZVF Gqk5XDpFP3xiS43RJgSYRc+/b8v2/Z+R5/vqa8/7Jvaw4EVeZE0JnUOBLMAinmGo/Bnix15+ a9bi+2J/Pa1nsfLpc8X08To/jdqkUiMPnRTL6edTTwGOWRGedKsyztuQzmy+plwt0STv+1nd wRFK4dUPJ3+8Gh+r8fLko4q13vLLtSVUqwJQhV1yIAxICGlMQxbFYCdZ6KRtdLpZbhyaqBov lXqqYTTmJCyjJ6KNKkjCbowOzQOSMeuRxjpkZQQUSEGak4mz5y+Ka5kcF/M7POsj1MtISSoK dEsRgCajBDx+oOEYDEN2F9dKDSv8ycDQMKaDYPhtpkJcwGQp/e3fhIpJBwfdxa1CZ6SSMKRs EP9+KoZM/NUYClwcC/uwDQw5xik5CnuwhvOUxF0iuxSylQxD5RoZutUkIgc8TbczMTAhYhux EkaTEMxpDSYlAAZ3AS2NwNRFPqxKG8huXjzBhkBxlhKMUJFA26oUoyYMiYvtuOdZ3TqLITNR Q5ccVyExCbO5lmEmAL6l3HzKyFwgnxgZqncQR2yfDte4030YlSAkgkK1X4zcmcJ13g2yN7Dz /F4bGHFsMjzoW0XAp2cawjNZuJquteZt8RqoXh8hEITMG7egENOtIQdnIUQg4UUfrbDGFMRF YMJZCWj9POaJxO0nVulQooEn4qNrrfz4PhcDYTUOKk+wv7p+CIUbHeSi28IEhGKRPG55YU2h yMzkd5iygblUwOst9HavQv9ACm3QQ2kdEOyKffYU99uyPles5kJrpimoyFEhqBiEYRMOn85Y VDSx6R8w01YsGQMqqDCV7jVO+D3TfBRnoiax1imXU8RiFOujD54c1Ydl6/RF5kLkDAReHEEy GjLantuuIgY4IpIKp+CCoD8zBR1NvI+ICXD23/DFDg5GA9kkeEtosmGYyoC5e7SycD7eE77i JS90h95nkQ7C+m3PoVLwgfy469QCfRKnI0xxBwMAygoZh2hE1dSFXTwkKwi3qJ4NtBw/pj/T DjNlftihmoENQogfB536IEHwgdiJezSwMe08Ty7Q11uIQHgBA0y+CT34jE5KVLRLouefbsNg RRAIcOYIwzlRoAwG21Hl/XS81nHSBw4JtQOzJzwKM56YHm0Y4wEZWskrKFKEtvzUYaUz2imy 2xq4WkU4iL1xCqpL4NNDzFLhIpCA7qySPTBoiwhBgEJk0UWArHxNiCrEETk3OTNRBJ2QqyKF URIHKbkzhAjqgSbKljhk0KbYhvYo8/6FEVZAG1IQuOFZBJpRxDcIIyWW0iRI6WkgZHBvx6HO xZHdGLWm65rLiEpoqluoYgCMVJMXpcbhkgRSERGLTYqz1uQRwFD5zwQzFL55XNCZWD5G49ND 4/wRVZBEB78LKVA5kEQgezLena8wbUSDQEDQA4ceDUK+5vP1omX3YPBkmzXqS0IEdjp04XDB v3ewmgJ+gTmJpbXeVsG0JRzGIcpzuBvkVJgLMQ7EImxw8GiHBMYA9vpjf6PLUKPqVr9cNNlY eaK5OcLFDyZYanqLkM5koGsWRGHDvkYHBQ2ldVH/wVB9VHxRC2X4ni2WsKpZy6l3DSinGt+5 67RIbvRiW0upJLtZEglYjldKYz142jLNxuA4iCVtjpxzUl8CXOogZIbotrg/DR2tc6PtdmdB pdqHQtkzXM6IbENEMcCYsqt0xMSMJxCRsTUal+X4dHPqtG0EHEPvvKTdxO1rzFFWO7eQ425n bcq7hTnbJz0KJh13O5/KtHa5g1ID88nM2WOo5iibXvDNcBO+OYGtJcKTNIkGJbhqJsoDcPZ1 KUsKhpKB7i6jSZr85APDnWg3i85v5NQDY7cIhhvBMbNmzed3GPssajBIj49OiGlTa2w6Vj09 rbWsUAp0iGc9PebWv6Jc2akxk24DYapzpOw6C2J7ibK+TGRzraQszYWwjozT3M7c060PeofB 7NGIxVBFPa8/v6x8zsxHkvt+Isq/U8E+2YE6HI5C3gHOiryTNNiLv8vA7gCcBDjE9uoHn4cH Pp94ONESYPXg8rbu3fRBbPQsCTGnOhkN4hmwSRnRqQJU+SVj2Ym0J7+m8ugb/loEI5wKg2I/ AJoQz7Tddsrt4s5bdqruR7ttilmWrl9MOO5dkZk1cGxGSK8+1UPI30XHU04QR8XX06Zkm+CA s3AfmdtRA6D1xGuHMjQOjdxVbWb708m7mvjnWPWU8lqwfp67B4pDhXkQ4plE2YgJY09mX8/k cmC5XIonacT5RaPHOFi7Eu95g4Fm7GQmUzHSKs97mGlJBiEI3Q2D2QbrwiYbcRsH7IwjC1By Bs7jFOaJPqoVqCo5qQRhSQwgUYOvtQmNvRDLYDLFI7RwawBLQRBgKPRnxVUQPUNRvbqgkevR YvM6dCLEPEe3GrMNgY15O4+9VDYRiTGSBSO1H1v8NF3ePSNoOIplAqAqFYVkBTQUKpNJYycy VgZgyGJcv1Q6bRGFznjnvlBRmrykdOZo4mxlpQc3UtAYEUJ+nRGj6f+ik7TXcEm0KC+06PkD sTw06bFPZchotjpoLAMCe3kw7YaDTCAV0lhbh8oDQRT7YqSDICxWLBiKoQWJv86KAYHm3VQs IblpuOYyWYzaGjZgGaVikQYHc3MocGHdtVvjm5Ax0E5+07D11UsgWHrX7gXUMIsCBgeUA2WR xSHwgp5OfqDWiFJJ2z5rMhf3p78eo+2IfRPFUIBVBma7eGMt9Y2DJA17R78TeROwwbwCxehL EEtD0Qu61YGWrIW0kxITyEKHeoUIw5AhrJWfIG0HHWb3ldu9GwkkhwQkZ9mVCaDw6eZgYQoi 1Fr4QPJEutCQC3GePIH0A8M0hfQdzswYQ8JwOnHh4xZKPG3RERMH1L46g1NeI5SWJbM+vu16 5MFzrp5Pr6Dnv6b9dt9rj6eSXlE241erUEcV8iGSSG8vAYTMN8T2Ozk8fndgMj79k9iCQ73Y NSdIupPDbgaGWHjSU4MSbTadrG9jeFh3BhhWmn26YFxfSGfPNciJhACN45ADfCHeItywdtwg QkE7gNy3IBBLGtvULh6ncaoQBRR5GFBBQSIA/EeGTn28GeLXjOk9c5Tx5313y0wZHnum0Zjm tqI8iR4+b2xC8BILPDXXMiY0HQd3dY07XiOTk9Ym52Mx94usEyzoOYnGRV+ibAYIYsObSvjF YDzwQkHZTTeNUK3SrwW/glo9PbrIMnHGmF6YNMh73lCIvQQS9kaL5vPuDB1mO98ODZmae7gQ yB06MKNTe/tLiDhr6j5skJngHgVI0ZjWiYSwg0Q7RSRaDG1yznHZUOO68KKqxgUSVUUUUUTu ZDDsFnKZ7bN6ZPCxsshxnfpJCYlu509BJZf+0PZDvYhZVAkxCOWmcSM5wDkG19oqwhkL30zk u+kWRKB0YB3bhoGbwb8Hj1rMcIY6vtIeZZUCj0qVrbT7h82l1LferGRs+4aNIGmChwboiFgr U2ZkGLD4ItCMq4lgWyQg3MXI76BAyuj5NvEA8h1HzHdp+XWiIu/5vjSNWvf43+PZmWIBCSUT ClqIWLVgM6DOqDoPFDindD09te3TRHnIzdVKSvnyLu8y4N+JTXNtXs5+fs4cAyBf6GA+IEoF Ch0eDnCd/rY2iegs9AhgLJA7YEOfgTmSHVlnShpS/lzMqqI41ALRCnwtZ7qdbURk4RKIlGg3 TgVZWwugIiDYEQMEHw3BHz3ECQZWUqM9eswhbPJdBepKKgF7cJCh7hyA5Y84WE37MfMjpuHV F0vvHXfvJGdQxQUJlpfXDWWHIjjjdWw/PDRA9D9oZRICMbGhmbFgdyQ3/BjsYmRWs5VuNsUD IvI0J9TWI8nefN64uhSj8T5MWuQjBkr11YYKBmAWyNt5GPBmXjZhqentSFxbw1mGwfwJIUWI BsGgXeyjFw9BpE2NbCbA0SBpMD9vKSW1+wwmpLKm5stRygtoFMqNcpffcsoZawhagkgiiIIv YjIJNc5DlALR5MgQgQYG+ZuSKQgJII6QjQDsAl7Awphhg1u6EgEYv0Q0SFGtAvNqpcybsSj0 ujVnsmzkoKmvEGiosMYCyGMJFFBSddlBQHlshRCLCCNQoy1SkEEZjvhmWoUYRjA3IbWySDEx gFyKri0hReLSUKUSALNg5tYXEX9VmsZodWzu80O9GqotPih6yNclfBAG7WVg75eBpBhFuwho 7gtZyD4AJ3yRQiokEX9HZ1U94SO2nedIqfLUfgg47pDwIoZ5Yak9wpG3lPh9YJXcL+m3M8ta ReS9/roo+2K+NvJgHvgv9onrwwQPWYtRAkgSpmzIsC1wqvjoBxHMwybIWPaRpch57oYEhxgv n2aA+NHksOhApkNad1+DX0I2QqY4lgwrQYjgkqsMgUCD+q0J0xWRH3EqEPL78xv6Q0K5bwS5 wBuHVYnbytyL7EiMjg+ku7vMo3mXUD19+ReiHd2RW7Aybc8wC8lQl7u2UgywIfchwfKPlLVI y8exhFyccuD4cLZhoRXVgcjzgZxaNFUZIa0NArvqhJDaARCbCiWYPH1p4b0Y8A2Kb7/JpnEE OtbjF22QBQjpfCNy+ycLo+cawjhDiYBIGYz6aAlCtoRNOlCoXMZGYw7gwICB75rG3gg3j8MT oglgEgJOtbcpIcJrGFhuWoO3OzjyX7sSRAecagCnJ8N+mycAN9g59GdkhGQIxaDIfXyVgxGA iIsUZlCoxj03qySUEYMGCKvUSwuyF3FKUd9CWSZiQugmGYTUPkTB90TLEgPunObb8dzjBgHv Wi8El3BaMtWUEWbZRGoYXqSFzEaCurR1LhrAfrii0zf37HxUQpzQrbJBCg2PPZelMGGpFWIu vD1SUB2YWD4yhNRre4tgz2A0UM2kQpI8Zaw2qynEo9oqY5LlGpFkYMwIEdUJBk+SLaExAmbm nT2DjS9dgwbkmT/URUDPwofMwa5xrRbEYhJIwRiBajCCmqTyRzO0Wxzc+GvoBu3NhGhkBm1I UwMQWFSaMNCCAurLzSTf5VtA3Jfw+vxwxKGBC+cv06TA/SYmJ+amuva9N+3kiGunHYWO+Nfm 9lw1Yu3wNPtIzw/vh5EXUuaqcQndY3fOC8GEIVrOFsVFYp8wTCe7wgbCJTMiSldzO8z7uMzf MCTpnus2KtjVFYhwypwSU63IWV00YPupojWebcZrSnYILogYDXsxhiQOCEe/viFBkp2JlsHI Sr78JdwvOiAgMXxZ0jsiWEZQ4J1EjqSUDeCQjbemjG7DOOQJ2Y42SGsU42PTW103ldxSe7f5 Fhj9pS3LylPNTc8LHOSmnYVDsRQodSG/EVlpVPLncRnQyodLX08JnUXUizP4oAY8NWZFLZdO AuSSLSnGDerIGbkWkCxAqYc0HIva6QCRkYkd5Q9Lbzsp+/tozzNjCl3LsuRL3FypNmNk/Ja0 Nq5SdAF3gQfc4iq3TuMDgd5nQZsSYHClb45eITR67WnAJ29TOXafkpkm5LGfxqYL5xB2elZC RI7h56iSFmM+Uyqso1h4kwa2zlmMmNodS40wTNhOznezGC3ybTeJx6Fc57OGgVZQJCGpzcWF QtrWIuyjRGY9Kkqr6HJEdUaKqtrTfb67llvtwmrO15Zpq3SimKQ9Go2Sq2L3KJw4OgQmXWIZ 5auubcF7yTKsBLuwIgK2iJH4h4E7XJINJ3fTp4WtAOzGDbEZHdO77VUAzXyKoCNMzhIyHgk8 LCccO0h2utvqIFdEpR1qhIxEL2NlLaCb/LZcQR5RCFZThfdep0lYq2u/cXrl5pZxA4xTjHuL 0SRoooDoARHXlwfG/l5HGwAHJSkEtAROihnQUQBuQIKFkwxHdx3ZDyeeHkds2LToFywmm5Do hvzzsHUmDTpXADlzoHtjdjJCCEiVHhIp2xOPZWocMZPaw6hyz43rekVilEEl91mnnVQ2hULy jlzwXDjFAyNKx9IXCtqNo6xULmm22x8Pq7vnwKPziQXvgSAIe3P49OSvkCbMXBMR7kJXeKbP 8qV6nfd0Nx1QO8gpCe13iVurjs6mnZ3eQGQV7OaUxzpxDMnGqvvE9NQbe8TPPKihPqiLzFNe oaXqo2tQWGw7duuwcsxYZ5+rfF0nYnu1UYaJU1ssahF3DDv8q8FaC9QVOWQkiIRRkQuIuEY0 DcUrFN5VsrrgDzmR1PHQ9WeR7q1jCwE2wXkkO1QaswzkhDhawY8bzebw38EDtJH24oZsAM4Q SC0z0UiNL7a9sThzDqeB9/9SXb39sRbq2wIcr0JAvlSr8kSlTA3W45nffXZKvk2hy18uV+Z5 SD4V6ZxzhphrV3IcS8sEKgFONFCE5R3Ga3s6NOW5DIUPnkggdKQVOEA/FDs0hc5xnRSNRsyV Sp9qEYgwyCxiMaS5aMGldL8BA/+LuSKcKEhWDZbSgA== --------------903DC280C9398BFCFEE46CAD-- From owner-kdb@oss.sgi.com Fri May 17 11:26:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HIQ4nC012938 for ; Fri, 17 May 2002 11:26:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HIQ4kk012937 for kdb-outgoing; Fri, 17 May 2002 11:26:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HIQ2nC012934 for ; Fri, 17 May 2002 11:26:02 -0700 Received: from mainserver.surfnetusa.com (mail.santacruzinternet.com [208.201.152.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA07447 for ; Fri, 17 May 2002 11:26:34 -0700 (PDT) mail_from (jackc@imageintegration.com) Received: from mail.imageintegration.com (mail.imageintegration.com [208.229.251.50]) by mainserver.surfnetusa.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id alnubcaa for kdb@oss.sgi.com; Fri, 17 May 2002 11:25:02 -0700 Message-ID: <3CE54B14.DFB47F4E@imageintegration.com> Date: Fri, 17 May 2002 11:25:24 -0700 From: jack craig Organization: ImageIntegration X-Mailer: Mozilla 4.7 [en] (X11; I; SCO_SV 3.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: kdb@oss.sgi.com Subject: is this addr for posting? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk hi kdb folks, i'd like to get a source distribution for kdb for use on ly linux host. looking at the download section i seem to see only patch files, where is the code src tarball to start with? tia, jackc... -- ------------------------------------------------------------------------------- Jack Craig ImageIntegration 831-684-1375 jackc@imageintegration.com From owner-kdb@oss.sgi.com Fri May 17 15:03:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HM3bnC017081 for ; Fri, 17 May 2002 15:03:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HM3bW6017080 for kdb-outgoing; Fri, 17 May 2002 15:03:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HM3WnC017077 for ; Fri, 17 May 2002 15:03:33 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4HM43g5148914; Fri, 17 May 2002 18:04:04 -0400 Received: from us.ibm.com (dyn9-47-17-243.des.beaverton.ibm.com [9.47.17.243]) by westrelay01.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4HM433122284; Fri, 17 May 2002 16:04:03 -0600 Message-ID: <3CE57DA3.21374246@us.ibm.com> Date: Fri, 17 May 2002 15:01:07 -0700 From: Matthew Dobson X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: gone@us.ibm.com, kdb@oss.sgi.com Subject: Re: having trouble with kdb on smp (kernel 2.5.9) References: <28759.1021512339@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Wed, 15 May 2002 18:03:29 -0700, > Patricia Gaughen wrote: > >2.5.9 on an 8 proc numaq box. I saw the recent patch from Ethan Solomita and > >I'll give it a try tonight or tomorrow. But we've ran into a couple of issues: > > > > - when the system hangs we enter kdb but using bt, bta and btp do not produce > >stacks for any of the processes. We're able to get the stacks manually, but > >this is not much fun :-) > > Which version of gcc? Newer versions of gcc produce stack frame code > that kdb cannot backtrace without CONFIG_FRAME_POINTER=y. I'm currently using gcc version 3.0.2. And I definitely do have CONFIG_FRAME_POINTER turned on. > > > - Also we're not able to switch cpus. > > If the cpu command only displays one cpu then the others have been shut > down. By the time that kdb is called from the panic() routine, the > panic code has already disabled all the other cpus. The kernel isn't panicing. It is only stuck in a deadlock somewhere. It is spinning in a poll_idle loop looking for something to run, but all the tasks are in a TASK_INTERRUPTIBLE state. TIA for the help! -Matt From owner-kdb@oss.sgi.com Fri May 17 16:10:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HNAnnC018060 for ; Fri, 17 May 2002 16:10:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HNAn4C018059 for kdb-outgoing; Fri, 17 May 2002 16:10:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HNAjnC018056 for ; Fri, 17 May 2002 16:10:45 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4HNBLFD136646; Fri, 17 May 2002 19:11:21 -0400 Received: from us.ibm.com (dyn9-47-17-243.des.beaverton.ibm.com [9.47.17.243]) by westrelay01.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4HNBK357334; Fri, 17 May 2002 17:11:20 -0600 Message-ID: <3CE58D68.8B4C1674@us.ibm.com> Date: Fri, 17 May 2002 16:08:24 -0700 From: Matthew Dobson X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: gone@us.ibm.com, kdb@oss.sgi.com Subject: Re: having trouble with kdb on smp (kernel 2.5.9) References: <28759.1021512339@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk I should mention also, that kdb ALWAYS shows the same CPU: 1. It never ends up on 0, or 2-7. I thought this was curious... is this some sort of default behavior? Or does this possibly help indicate the problem? TIA, -Matt Keith Owens wrote: > > On Wed, 15 May 2002 18:03:29 -0700, > Patricia Gaughen wrote: > >2.5.9 on an 8 proc numaq box. I saw the recent patch from Ethan Solomita and > >I'll give it a try tonight or tomorrow. But we've ran into a couple of issues: > > > > - when the system hangs we enter kdb but using bt, bta and btp do not produce > >stacks for any of the processes. We're able to get the stacks manually, but > >this is not much fun :-) > > Which version of gcc? Newer versions of gcc produce stack frame code > that kdb cannot backtrace without CONFIG_FRAME_POINTER=y. > > > - Also we're not able to switch cpus. > > If the cpu command only displays one cpu then the others have been shut > down. By the time that kdb is called from the panic() routine, the > panic code has already disabled all the other cpus. From owner-kdb@oss.sgi.com Fri May 17 19:37:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4I2btnC022008 for ; Fri, 17 May 2002 19:37:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4I2btq4022007 for kdb-outgoing; Fri, 17 May 2002 19:37:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4I2bpnC022004 for ; Fri, 17 May 2002 19:37:52 -0700 Received: (qmail 20291 invoked from network); 18 May 2002 02:38:27 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 18 May 2002 02:38:26 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 9A4FC3000B8; Sat, 18 May 2002 12:38:24 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 761C798; Sat, 18 May 2002 12:38:24 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: jack craig Cc: kdb@oss.sgi.com Subject: Re: is this addr for posting? In-reply-to: Your message of "Fri, 17 May 2002 11:25:24 MST." <3CE54B14.DFB47F4E@imageintegration.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 May 2002 12:38:19 +1000 Message-ID: <15808.1021689499@ocs3.intra.ocs.com.au> Sender: owner-kdb@oss.sgi.com Precedence: bulk On Fri, 17 May 2002 11:25:24 -0700, jack craig wrote: >hi kdb folks, > >i'd like to get a source distribution for kdb for use on ly linux host. > >looking at the download section i seem to see only patch files, >where is the code src tarball to start with? kdb patches are against the base Linux kernel. From owner-kdb@oss.sgi.com Sun May 19 20:24:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K3O6nC021570 for ; Sun, 19 May 2002 20:24:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K3O65m021569 for kdb-outgoing; Sun, 19 May 2002 20:24:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K3O1nC021547 for ; Sun, 19 May 2002 20:24:01 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA05087 for ; Sun, 19 May 2002 20:24:32 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4K3NUPF7000841; Sun, 19 May 2002 20:23:31 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id B6A633000B8; Mon, 20 May 2002 13:23:29 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 5DCEE94; Mon, 20 May 2002 13:23:29 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Matthew Dobson Cc: gone@us.ibm.com, kdb@oss.sgi.com Subject: Re: having trouble with kdb on smp (kernel 2.5.9) In-reply-to: Your message of "Fri, 17 May 2002 15:01:07 MST." <3CE57DA3.21374246@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 May 2002 13:23:24 +1000 Message-ID: <2934.1021865004@kao2.melbourne.sgi.com> Sender: owner-kdb@oss.sgi.com Precedence: bulk On Fri, 17 May 2002 15:01:07 -0700, Matthew Dobson wrote: >Keith Owens wrote: >> >> On Wed, 15 May 2002 18:03:29 -0700, >> Patricia Gaughen wrote: >> >2.5.9 on an 8 proc numaq box. I saw the recent patch from Ethan Solomita and >> >I'll give it a try tonight or tomorrow. But we've ran into a couple of issues: >> > >> > - when the system hangs we enter kdb but using bt, bta and btp do not produce >> >stacks for any of the processes. We're able to get the stacks manually, but >> >this is not much fun :-) >> >> Which version of gcc? Newer versions of gcc produce stack frame code >> that kdb cannot backtrace without CONFIG_FRAME_POINTER=y. >I'm currently using gcc version 3.0.2. And I definitely do have >CONFIG_FRAME_POINTER turned on. Any error messages? I am guessing that it says "Stack is not in task_struct, backtrace not available". task_struct data has been moved around in recent 2.5 kernels and kdb has not been changed to validate the new layout yet. From owner-kdb@oss.sgi.com Sun May 19 23:47:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K6lEnC024337 for ; Sun, 19 May 2002 23:47:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K6lEYg024334 for kdb-outgoing; Sun, 19 May 2002 23:47:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K6l8nC024311 for ; Sun, 19 May 2002 23:47:08 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA08094 for ; Sun, 19 May 2002 23:47:53 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g4K6kpPF7008425; Sun, 19 May 2002 23:46:53 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 156193000B8; Mon, 20 May 2002 16:46:50 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id C20DA94; Mon, 20 May 2002 16:46:50 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: jim.houston@ccur.com Cc: kdb@oss.sgi.com, ethan@cs.columbia.edu, jim.houston@attbi.com Subject: Re: [PATCH] - SMP fixes for i386 kdb In-reply-to: Your message of "Thu, 16 May 2002 20:34:07 -0400." <3CE44FFF.F4A3EBB2@ccur.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 May 2002 16:46:45 +1000 Message-ID: <4235.1021877205@kao2.melbourne.sgi.com> Sender: owner-kdb@oss.sgi.com Precedence: bulk On Thu, 16 May 2002 20:34:07 -0400, Jim Houston wrote: >The attached patch is an update of my earlier patch >to fix smp problems in kdb. I started with Ethan >Solomita's patch but I have change a lot of code >since then. I have been exchanging private email with >Ethan over the last week and he has helped find some >of my bugs. Thanks again. There are always more bugs >but I think this patch has reached the useful stage. I finally got time to spend on kdb, my apologies for not answering these patches sooner. Jim, Ethan, is this a common patch or do you still have differences of approach? >The changes are: > > - Splitting up the kdb_state variable to > decouple data used for inter-processor > synchronization from local flags. Good idea. > - Avoid having an extra layer of nesting > if a processor is already in kdb when the > kdb inter-processor interrupt is delivered. I agree with the aim but am a bit unhappy with putting the code in entry.S. Patching the assembler closes the window between int3 and NMI to a few instructions, at the cost of extra asm. Moving the kdb_in_kdb setting to do_int3 will use C instead of asm. It is a trade off, a slightly larger window for easier to maintain code. From owner-kdb@oss.sgi.com Mon May 20 08:21:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KFL9nC031466 for ; Mon, 20 May 2002 08:21:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KFL9jP031465 for kdb-outgoing; Mon, 20 May 2002 08:21:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from exchange.ccur.com (mail.ccur.com [208.248.32.212]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KFL1nC031419 for ; Mon, 20 May 2002 08:21:01 -0700 Received: from ccur.com (129.134.166.110 [129.134.166.110]) by exchange.ccur.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LH39ZXYK; Mon, 20 May 2002 11:17:49 -0400 Message-ID: <3CE91598.F023CA35@ccur.com> Date: Mon, 20 May 2002 11:26:16 -0400 From: Jim Houston Reply-To: jim.houston@ccur.com Organization: Concurrent Computer Corp. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: kdb@oss.sgi.com, ethan@cs.columbia.edu, jim.houston@attbi.com Subject: Re: [PATCH] - SMP fixes for i386 kdb References: <4235.1021877205@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Keith Owens wrote: > > On Thu, 16 May 2002 20:34:07 -0400, > Jim Houston wrote: > >The attached patch is an update of my earlier patch > >to fix smp problems in kdb. I started with Ethan > >Solomita's patch, but I have change a lot of code > >since then. I have been exchanging private email with > >Ethan over the last week, and he has helped find some > >of my bugs. Thanks again. There are always more bugs, > >but I think this patch has reached the useful stage. > > I finally got time to spend on kdb, my apologies for not answering > these patches sooner. > > Jim, Ethan, is this a common patch, or do you still have differences of > approach? > > >The changes are: > > > > - Splitting up the kdb_state variable to > > decouple data used for inter-processor > > synchronization from local flags. > > Good idea. > > > - Avoid having an extra layer of nesting > > if a processor is already in kdb when the > > kdb inter-processor interrupt is delivered. > > I agree with the aim but am a bit unhappy with putting the code in > entry.S. Patching the assembler closes the window between int3 and NMI > to a few instructions, at the cost of extra asm. Moving the kdb_in_kdb > setting to do_int3 will use C instead of asm. It is a trade off, a > slightly larger window for easier to maintain code. Hi Keith, Ehtan The thought behind the entry.S change was to close the window completely. I believe the combination of setting kdb_in_kdb as early as possible and also doing the eip range check in kdba_check_in_kdb() accomplishes this. Another solution I considered was to do a stack walk back from kdb_ipi to see if it had interrupted the int3 entry. I also wondered about changing the kdb inter-processor interrupt to a normal interrupt and changing the breakpoint gate setup to mask the interrupts. On other architectures this may be the prefered solution. After considering these alternatives, the few lines in entry.S didn't seem that painful. I mentioned in earlier email that this fix also avoids the problem described in the comments before kdba_db_trap(). This is a panic which may happen if the user clears an interrupt which has not been processed yet because the kdb inter-processor interrupt has preempted the breakpoint processing. I willing to put more work into this patch and help get it working on the other platforms. Jim Houston - Concurrent Computer Corp. From owner-kdb@oss.sgi.com Mon May 20 11:20:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KIKHnC005712 for ; Mon, 20 May 2002 11:20:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KIKHsO005711 for kdb-outgoing; Mon, 20 May 2002 11:20:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KIKCnC005682 for ; Mon, 20 May 2002 11:20:12 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4KIKjg5252972; Mon, 20 May 2002 14:20:48 -0400 Received: from us.ibm.com (dyn9-47-17-243.des.beaverton.ibm.com [9.47.17.243]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4KIKiJ182438; Mon, 20 May 2002 12:20:44 -0600 Message-ID: <3CE93DCF.40304@us.ibm.com> Date: Mon, 20 May 2002 11:17:51 -0700 From: Matthew C Dobson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Owens CC: gone@us.ibm.com, kdb@oss.sgi.com Subject: Re: having trouble with kdb on smp (kernel 2.5.9) References: <2934.1021865004@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Keith Owens wrote: >On Fri, 17 May 2002 15:01:07 -0700, >Matthew Dobson wrote: > >>Keith Owens wrote: >> >>>On Wed, 15 May 2002 18:03:29 -0700, >>>Patricia Gaughen wrote: >>> >>>>2.5.9 on an 8 proc numaq box. I saw the recent patch from Ethan Solomita and >>>>I'll give it a try tonight or tomorrow. But we've ran into a couple of issues: >>>> >>>> - when the system hangs we enter kdb but using bt, bta and btp do not produce >>>>stacks for any of the processes. We're able to get the stacks manually, but >>>>this is not much fun :-) >>>> >>>Which version of gcc? Newer versions of gcc produce stack frame code >>>that kdb cannot backtrace without CONFIG_FRAME_POINTER=y. >>> >>I'm currently using gcc version 3.0.2. And I definitely do have >>CONFIG_FRAME_POINTER turned on. >> > >Any error messages? I am guessing that it says "Stack is not in >task_struct, backtrace not available". task_struct data has been moved >around in recent 2.5 kernels and kdb has not been changed to validate >the new layout yet. > Yep... That the error message that I get... The latest kdb on the oss.sgi site is based on 2.5.7 which has the new task_struct changes, so I figured it would know how to find the stack... Like I said, we've been able to do it manually, by locating the thread_info in task_struct, and then manually dumping the 2 pages of memory sitting there... The back-trace functionality would be nice, but isn't strictly necessary... What would be really helpful is if I could look at what other cpus are doing... Thanks! -Matt From owner-kdb@oss.sgi.com Mon May 20 11:23:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KIN2nC006147 for ; Mon, 20 May 2002 11:23:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KIN10p006146 for kdb-outgoing; Mon, 20 May 2002 11:23:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KIMtnC006124 for ; Mon, 20 May 2002 11:22:56 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4KINiWo032148; Mon, 20 May 2002 14:23:44 -0400 Received: from us.ibm.com (dyn9-47-17-243.des.beaverton.ibm.com [9.47.17.243]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4KINhJ49376; Mon, 20 May 2002 12:23:43 -0600 Message-ID: <3CE93E82.9050909@us.ibm.com> Date: Mon, 20 May 2002 11:20:50 -0700 From: Matthew C Dobson Reply-To: colpatch@us.ibm.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Owens CC: gone@us.ibm.com, kdb@oss.sgi.com Subject: Re: having trouble with kdb on smp (kernel 2.5.9) References: <2934.1021865004@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Keith Owens wrote: > On Fri, 17 May 2002 15:01:07 -0700, > Matthew Dobson wrote: > >>Keith Owens wrote: >> >>>On Wed, 15 May 2002 18:03:29 -0700, >>>Patricia Gaughen wrote: >>> >>>>2.5.9 on an 8 proc numaq box. I saw the recent patch from Ethan Solomita and >>>>I'll give it a try tonight or tomorrow. But we've ran into a couple of issues: >>>> >>>> - when the system hangs we enter kdb but using bt, bta and btp do not produce >>>>stacks for any of the processes. We're able to get the stacks manually, but >>>>this is not much fun :-) >>> >>>Which version of gcc? Newer versions of gcc produce stack frame code >>>that kdb cannot backtrace without CONFIG_FRAME_POINTER=y. >> >>I'm currently using gcc version 3.0.2. And I definitely do have >>CONFIG_FRAME_POINTER turned on. > > > Any error messages? I am guessing that it says "Stack is not in > task_struct, backtrace not available". task_struct data has been moved > around in recent 2.5 kernels and kdb has not been changed to validate > the new layout yet. > Yep... That is the error message that I get... The latest kdb on the oss.sgi site is based on 2.5.7 which has the new task_struct changes, so I figured it would know how to find the stack... Like I said, we've been able to do it manually, by locating the thread_info in task_struct, and then manually dumping the 2 pages of memory sitting there... The back-trace functionality would be nice, but isn't strictly necessary... What would be really helpful is if I could look at what other cpus are doing... Thanks! -Matt From owner-kdb@oss.sgi.com Mon May 20 13:25:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKPHnC024813 for ; Mon, 20 May 2002 13:25:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKPHcw024812 for kdb-outgoing; Mon, 20 May 2002 13:25:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-kdb@oss.sgi.com using -f Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKPFnC024806 for ; Mon, 20 May 2002 13:25:15 -0700 Received: from JuTan ([12.234.102.105]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020520202559.BOLX12519.rwcrmhc53.attbi.com@JuTan> for ; Mon, 20 May 2002 20:25:59 +0000 From: JuTan Computer Services To: kdb@oss.sgi.com Subject: Simplified,Affordable,Knowledgeable,Fast,Friendly Computer Technical Support - 10% off first call with this ad Reply-To: jutan@attbi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20020520202559.BOLX12519.rwcrmhc53.attbi.com@JuTan> Date: Mon, 20 May 2002 20:26:00 +0000 Sender: owner-kdb@oss.sgi.com Precedence: bulk If you want to solve your computer issues and not wait hours for a response, not pay high hourly fees, not speak with inexperienced people, not pay membership or support contract fees. Then contact JuTan Computer Services where you call or e-mail your issue, receive immediate response and pay only for that issue. If it sounds to good to be true then it usually is. In this case it's not because JuTan Computer Service is the simplified, affordable solution to Computer Technical Support. www.jutan.com 1-800-343-0114