From vamsi@in.ibm.com Tue Apr 1 00:08:44 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 01 Apr 2003 00:08:54 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31884q9032182 for ; Tue, 1 Apr 2003 00:08:43 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3187QYY115002; Tue, 1 Apr 2003 03:07:26 -0500 Received: from vamsiks.in.ibm.com (vamsiks.in.ibm.com [9.182.12.245]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3187LE5173404; Tue, 1 Apr 2003 03:07:22 -0500 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h318RCu23565; Tue, 1 Apr 2003 13:57:12 +0530 Date: Tue, 1 Apr 2003 13:57:12 +0530 From: "Vamsi Krishna S ." To: "Zhang, Sonic" Cc: Keith Owens , Hua Qin , kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Message-ID: <20030401135712.A23538@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <37FBBA5F3A361C41AB7CE44558C3448E350B30@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <37FBBA5F3A361C41AB7CE44558C3448E350B30@pdsmsx403.ccr.corp.intel.com>; from sonic.zhang@intel.com on Tue, Apr 01, 2003 at 09:47:02AM +0800 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 298 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb smphdr patch does two things AFAICS: - s/kdb_bp_*_local/kdb_bp_*_dbreg and s/kdb_bp_*_global/kdb_bp_*_dbinst - keep the state of debug registers per-cpu, so that you could implement per-cpu breakpoints, as probably intended in bph and bpha commands. I think these patches are okay, but unrelated to my patch. Regarding the smphdr patches, in my opinion, they are not really needed.. I don't see how cpu-local breakpoints are useful.. how can one tell on which particular CPU alone a given piece of code executes. Sonic Zhang, can you please explain why this is needed and correct me if I am wrong about the smphdr patch. BTW: my patch is useful to detect and handle conditions in which multiple cpus hit breakpoints at about the same time, one of them wins the race to enter into kdb, and at the kdb prompt, the user removes all breakpoints.. so we won't be able to find KDB breakpoints on other cpus when they eventually enter KDB thereby causing unhandled trap3/trap1 in kernel -> oops. My patch is needed for both instruction-replacement breakpoints and debug-reg assisted breakpoints. I will post an updated patch. Thanks, Vamsi. On Tue, Apr 01, 2003 at 09:47:02AM +0800, Zhang, Sonic wrote: > Hi, > > The "smphdr" patch only deal with the hardware breakpoints. It doesn't affect the logic of "int3" instruction breakpoint in the formal KDB patch. So if this problem occurs in the formal KDB patch, it is very possible that it still exists after applying the "smphdr" patch. > > Thanks. > > Sonic Zhang > > > -----Original Message----- > From: Keith Owens [mailto:kaos@sgi.com] > Sent: 2003?3?31? 19:02 > To: vamsi@in.ibm.com > Cc: Hua Qin; kdb@oss.sgi.com > Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) > > > On Mon, 31 Mar 2003 15:40:16 +0530, > "Vamsi Krishna S ." wrote: > >Here is a simple way to handle this situation. Before deciding that > >this trap is not due to one of KDB's breakpoints, check if this > >is a breakpoint that was recently removed. > > Sonic Zhang has cleaned up the breakpoint handling. I am waiting for > feedback on these patches before including them in kdb. > ftp://oss.sgi.com/projects/kdb/download/v4.0/kdb-smphdr-v4.0-2.4.20* > -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From kaos@sgi.com Tue Apr 1 00:20:52 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 01 Apr 2003 00:20:55 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h318Klq9032282 for ; Tue, 1 Apr 2003 00:20:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h318KfnH003007 for ; Tue, 1 Apr 2003 00:20:41 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA07223; Tue, 1 Apr 2003 18:19:23 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 80727300087; Tue, 1 Apr 2003 18:19:22 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 0468F8F; Tue, 1 Apr 2003 18:19:21 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "S Vamsikrishna" Cc: lkcd-general@lists.sourceforge.net, kdb@oss.sgi.com Subject: Re: Converting lkcd from a pull to a push model In-reply-to: Your message of "Tue, 01 Apr 2003 13:09:15 +0530." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Apr 2003 18:19:16 +1000 Message-ID: <12139.1049185156@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 299 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Tue, 1 Apr 2003 13:09:15 +0530, "S Vamsikrishna" wrote: >As far as I can tell, in kdb v4.0, you call kdb_save_running() / >kdb_unsave_running() around kdb_main_loop() in kdba_main_loop(). We will >execute kdba_main_loop() on all processors only if the KDB IPI (NMI class) >to stop other processors works. > >Current lkcd does something similiar: it sends an NMI class IPI to capture >register state of other processors. I agree that timing out the IPI is a >bug (I thought I removed it, may be never submitted the patch for >inclusion), but this method will capture the state of all CPUs as long as >the IPI goes to all CPUs. > >So, how is the push model any better, when the push itself relies on the >IPI to be delivered and handled on all cpus? Did I miss something? Can you >please explain? What you see in kdb v4.0 is only part of the change, I am working on the next bit for kdb v4.1. IPI will not be the only mechanism for getting the attention of the other cpus, there are also flag tests in common code paths to detect that a debug event has occurred, even if the IPI does not get through. kdb is not relying on a single method for flagging a debug event, it uses a graduated set of attempts to get data from the other cpus. This is an additional method of getting other cpus into kdb, it does not replace the use of interrupts. The kdb logic will be :- if (safe_to_send_interrupts) { send_kdb_ipi(normal_interrupt); if (!all_cpus_in_kdb && arch_supports_nmi) send_kdb_ipi(nmi); if (!all_cpus_in_kdb && arch_supports_pmi) send_kdb_ipi(pmi); } if (!all_cpus_in_kdb) kdb_enter_debugger = 1; // flag to trip spin_locks and scheduler into kdb if (!all_cpus_in_kdb && arch_supports_init && (user_requested_destructive_ipi || destructive_kernel_error_detected)) send_kdb_ipi(init); if (!all_cpus_in_kdb) kdb_printf("not all cpus entered the debugger"); On IA64 there are classes of interrupt even more important than NMI, those interrupts are triggered by the PROM code. But the PROM requires that the cpus save their state and reenter PROM, which makes it impossible for the controlling cpu to ask the other cpus to save their state later. IOW, relying on the controlling cpu getting a response from all cpus (pull model) does not work. kdb v4.0 saves state on the failing cpus as they go through the interrupt handlers, the state is then available for the controlling cpu to read at its leisure (push model). BTW, timing out the lkcd IPI introduces its own race condition. I have seen this error several times on IA64 :- * The lkcd IPI did not get through because interrupts were masked on a target cpu (remember that IA64 masks the NMI). The IPI was pending but could not be delivered to the OS because the cpu was in a disabled spinloop on a lock that lkcd had obtained. * The IPI timed out and was "cancelled". * lkcd ended its processing, released the lock. * The cpu that was spinning got its lock, re-enabled interrupts, the pending IPI was now delivered, but the IPI data pointer was NULL ("cancelled"). * Result is an oops during lkcd shutdown. From vamsi@in.ibm.com Tue Apr 1 00:38:46 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 01 Apr 2003 00:38:50 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h318c5q9000408 for ; Tue, 1 Apr 2003 00:38:45 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h318bmdA157700; Tue, 1 Apr 2003 03:37:49 -0500 Received: from vamsiks.in.ibm.com (vamsiks.in.ibm.com [9.182.12.245]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h318biE5209824; Tue, 1 Apr 2003 03:37:45 -0500 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h318vZn23623; Tue, 1 Apr 2003 14:27:35 +0530 Date: Tue, 1 Apr 2003 14:27:35 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: S Vamsikrishna , lkcd-general@lists.sourceforge.net, kdb@oss.sgi.com Subject: Re: Converting lkcd from a pull to a push model Message-ID: <20030401142735.A23606@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <12139.1049185156@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <12139.1049185156@kao2.melbourne.sgi.com>; from kaos@sgi.com on Tue, Apr 01, 2003 at 06:19:16PM +1000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 300 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Tue, Apr 01, 2003 at 06:19:16PM +1000, Keith Owens wrote: > On Tue, 1 Apr 2003 13:09:15 +0530, > "S Vamsikrishna" wrote: > >As far as I can tell, in kdb v4.0, you call kdb_save_running() / > >kdb_unsave_running() around kdb_main_loop() in kdba_main_loop(). We will > >execute kdba_main_loop() on all processors only if the KDB IPI (NMI class) > >to stop other processors works. > > > >Current lkcd does something similiar: it sends an NMI class IPI to capture > >register state of other processors. I agree that timing out the IPI is a > >bug (I thought I removed it, may be never submitted the patch for > >inclusion), but this method will capture the state of all CPUs as long as > >the IPI goes to all CPUs. > > > >So, how is the push model any better, when the push itself relies on the > >IPI to be delivered and handled on all cpus? Did I miss something? Can you > >please explain? > > What you see in kdb v4.0 is only part of the change, I am working on > the next bit for kdb v4.1. IPI will not be the only mechanism for > getting the attention of the other cpus, there are also flag tests in > common code paths to detect that a debug event has occurred, even if > the IPI does not get through. kdb is not relying on a single method > for flagging a debug event, it uses a graduated set of attempts to get > data from the other cpus. This is an additional method of getting > other cpus into kdb, it does not replace the use of interrupts. The > kdb logic will be :- > > if (safe_to_send_interrupts) { > send_kdb_ipi(normal_interrupt); > if (!all_cpus_in_kdb && arch_supports_nmi) > send_kdb_ipi(nmi); > if (!all_cpus_in_kdb && arch_supports_pmi) > send_kdb_ipi(pmi); > } > if (!all_cpus_in_kdb) > kdb_enter_debugger = 1; // flag to trip spin_locks and scheduler into kdb This makes a lot of sense to me.. if you test for this flag and save state in some critical routines (say in spinlock's spin loop), we will be sure to get the state of all cpus. good. > BTW, timing out the lkcd IPI introduces its own race condition. I have > seen this error several times on IA64 :- > > * The lkcd IPI did not get through because interrupts were masked on a > target cpu (remember that IA64 masks the NMI). The IPI was pending > but could not be delivered to the OS because the cpu was in a > disabled spinloop on a lock that lkcd had obtained. > * The IPI timed out and was "cancelled". > * lkcd ended its processing, released the lock. > * The cpu that was spinning got its lock, re-enabled interrupts, the > pending IPI was now delivered, but the IPI data pointer was NULL > ("cancelled"). > * Result is an oops during lkcd shutdown. > > Of course. I have seen this too. In the absence of any mechanism to cancel all pending IPIs, timing out and returning from smp_send_ipi is silly. Should never have been done. We have had patches to remove the timeout logic all together, send the IPI to capture state and if it fails on some CPUs, just accept the fact that we dont have state of all cpus and move on. Capturing the state in spin loops when a flag say kdb_enter_debugger is set seems like a good idea. There doesn't seem to be much point in doing it at other places as if a cpu is not in a tight spin loop, it would have got the (NMI class) IPI. But, adding test for a flag and call to save register state within spinlock's code may be considered 'bloat' and unacceptable by many people :-(. Thanks for clarifying this, Vamsi. -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From kaos@sgi.com Tue Apr 1 15:25:01 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 01 Apr 2003 15:25:15 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h31NOwrX004664 for ; Tue, 1 Apr 2003 15:25:00 -0800 Received: (qmail 30563 invoked from network); 1 Apr 2003 23:24:56 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 1 Apr 2003 23:24:56 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 490C4300087; Wed, 2 Apr 2003 09:24:54 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3286B8F; Wed, 2 Apr 2003 09:24:54 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: vamsi@in.ibm.com Cc: S Vamsikrishna , lkcd-general@lists.sourceforge.net, kdb@oss.sgi.com Subject: Re: Converting lkcd from a pull to a push model In-reply-to: Your message of "Tue, 01 Apr 2003 14:27:35 +0530." <20030401142735.A23606@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 2003 09:24:49 +1000 Message-ID: <17769.1049239489@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 301 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Tue, 1 Apr 2003 14:27:35 +0530, "Vamsi Krishna S ." wrote: >Capturing the state in spin loops when a flag say kdb_enter_debugger >is set seems like a good idea. There doesn't seem to be much point >in doing it at other places as if a cpu is not in a tight spin loop, >it would have got the (NMI class) IPI. But, adding test for a flag >and call to save register state within spinlock's code may >be considered 'bloat' and unacceptable by many people :-(. kdb v4.1 does not test a flag in i386 spinlocks because the NMI "alwasy" gets through on i386, the test is only done on ia64. I have rewritten the spinlock code on ia64[*] to put only the uncontended path inline. There is a single copy of the code for the contended path, so adding a kdb test to that single copy is not an issue. [*] The current ia64 spinlock code uses 5 bundles for each spinlock() call. By moving the contended code out of line I got the spinlock() code down to 3 bundles for McKinley, 4 bundles for Itanium. The new spinlock code is smaller, it is measurably faster for uncontended locks and it gives better debugging for contended locks. From sonic.zhang@intel.com Wed Apr 2 00:03:59 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 02 Apr 2003 00:04:04 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h3283wrX016164 for ; Wed, 2 Apr 2003 00:03:59 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h327xMj08827 for ; Wed, 2 Apr 2003 07:59:22 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h327xtN01445 for ; Wed, 2 Apr 2003 07:59:55 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040216034927058 ; Wed, 02 Apr 2003 16:03:49 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 16:03:49 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 2 Apr 2003 16:03:49 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E350F4A@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Thread-Index: AcL4Jc+Nfoh7R94/RrCokntmaiuO5AAtW5EQ From: "Zhang, Sonic" To: Cc: "Keith Owens" , "Hua Qin" , X-OriginalArrivalTime: 02 Apr 2003 08:03:49.0538 (UTC) FILETIME=[64B67820:01C2F8EE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h3283wrX016164 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 302 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb Hi, In the formal KDB patch, the user can create both local and global hardware breakpoints. But the code within kdb_bp_install_global() doesn't install the global hardware breakpoint into each CPU. Because kdb_bp_install_global() is only executed by the initial CPU, while other CPUs only install its local breakpoints in kdb_bp_install_local(). That means the only way to create a global hardware break point is to create one local hardware breakpoint in one CPU, then switch to another CPU and create a new local hardware breakpoint at the same address. In KDB v4.0 patch, there is no way to create 2 breakpoints for one address. So smphdr patch is helpful especially for KDB v4.0. What I did in smphdr patch is to move the installation of both local and global hardware breakpoints into function kdb_bp_install_local(), while keep the instruction ones in the function kdb_bp_install_global(). I also renamed the two functions according to their logic. In this way, command "bpha" takes effect. In addition, some kernel patches support cpu affinity. A process can be confined to a specific subset of CPUs, even a specific CPU. With the support of different hardware breakpoints on different CPUs, you can create at most 4*2 hardware breakpoints when debug bugs caused by running 2 processes concurrently, 4 for each process. This feature is not commonly used, but it also do no harm. Do you have more advices? Thanks. Sonic Zhang -----Original Message----- From: Vamsi Krishna S . [mailto:vamsi@in.ibm.com] Sent: 2003?4?1? 16:27 To: Zhang, Sonic Cc: Keith Owens; Hua Qin; kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) smphdr patch does two things AFAICS: - s/kdb_bp_*_local/kdb_bp_*_dbreg and s/kdb_bp_*_global/kdb_bp_*_dbinst - keep the state of debug registers per-cpu, so that you could implement per-cpu breakpoints, as probably intended in bph and bpha commands. I think these patches are okay, but unrelated to my patch. Regarding the smphdr patches, in my opinion, they are not really needed.. I don't see how cpu-local breakpoints are useful.. how can one tell on which particular CPU alone a given piece of code executes. Sonic Zhang, can you please explain why this is needed and correct me if I am wrong about the smphdr patch. BTW: my patch is useful to detect and handle conditions in which multiple cpus hit breakpoints at about the same time, one of them wins the race to enter into kdb, and at the kdb prompt, the user removes all breakpoints.. so we won't be able to find KDB breakpoints on other cpus when they eventually enter KDB thereby causing unhandled trap3/trap1 in kernel -> oops. My patch is needed for both instruction-replacement breakpoints and debug-reg assisted breakpoints. I will post an updated patch. Thanks, Vamsi. On Tue, Apr 01, 2003 at 09:47:02AM +0800, Zhang, Sonic wrote: > Hi, > > The "smphdr" patch only deal with the hardware breakpoints. It doesn't affect the logic of "int3" instruction breakpoint in the formal KDB patch. So if this problem occurs in the formal KDB patch, it is very possible that it still exists after applying the "smphdr" patch. > > Thanks. > > Sonic Zhang > > > -----Original Message----- > From: Keith Owens [mailto:kaos@sgi.com] > Sent: 2003?3?31? 19:02 > To: vamsi@in.ibm.com > Cc: Hua Qin; kdb@oss.sgi.com > Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) > > > On Mon, 31 Mar 2003 15:40:16 +0530, > "Vamsi Krishna S ." wrote: > >Here is a simple way to handle this situation. Before deciding that > >this trap is not due to one of KDB's breakpoints, check if this > >is a breakpoint that was recently removed. > > Sonic Zhang has cleaned up the breakpoint handling. I am waiting for > feedback on these patches before including them in kdb. > ftp://oss.sgi.com/projects/kdb/download/v4.0/kdb-smphdr-v4.0-2.4.20* > -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From kaos@sgi.com Wed Apr 2 03:07:24 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 02 Apr 2003 03:07:28 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32B7MrX030146 for ; Wed, 2 Apr 2003 03:07:23 -0800 Received: (qmail 2521 invoked from network); 2 Apr 2003 11:07:20 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Apr 2003 11:07:20 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 99335300087; Wed, 2 Apr 2003 21:07:19 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 716B48F for ; Wed, 2 Apr 2003 21:07:19 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: kdb@oss.sgi.com Subject: kdb v4.0 for xscale Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 2003 21:07:14 +1000 Message-ID: <25634.1049281634@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 303 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb Eddie Dong at intel has supplied an xscale patch for kdb v4.0. I have not tested it, xscale testers can get the patch from ftp://oss.sgi.com/projects/kdb/download/v4.0/kdb-v4.0-2.4.19-xscale-0.2.bz2 From sonic.zhang@intel.com Wed Apr 2 17:21:29 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 02 Apr 2003 17:21:32 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h331LTDH027257 for ; Wed, 2 Apr 2003 17:21:29 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h331JPb04396 for ; Thu, 3 Apr 2003 01:19:25 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h331HPJ01896 for ; Thu, 3 Apr 2003 01:17:26 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040309212229696 ; Thu, 03 Apr 2003 09:21:22 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 09:21:22 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2F97F.56469F1B" Subject: new patch for KDB command "kill" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 3 Apr 2003 09:21:22 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E488BB7@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: new patch for KDB command "kill" Thread-Index: AcL5fzk+KZroeAQrR6+OGJ7Am5IrhA== From: "Zhang, Sonic" To: "KeithOwens (E-mail)" Cc: "KDB (E-mail)" X-OriginalArrivalTime: 03 Apr 2003 01:21:22.0681 (UTC) FILETIME=[567A3E90:01C2F97F] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 304 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F97F.56469F1B Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, The attachment is the patch for KDB command "kill". usage: kill <-signal> This patch is based on KDB v4.0 with kernel 2.4.20. Thanks. Sonic Zhang ************************************* Sonic Zhang =20 Software Engineer Intel China Software Lab Tel: 021-52574545-1667=20 iNet: 8-752-1667=20 ************************************* =20 ------_=_NextPart_001_01C2F97F.56469F1B Content-Type: application/octet-stream; name="kdb-kill-v4.0-2.4.20-common-1.patch" Content-Transfer-Encoding: base64 Content-Description: kdb-kill-v4.0-2.4.20-common-1.patch Content-Disposition: attachment; filename="kdb-kill-v4.0-2.4.20-common-1.patch" LS0tIGxpbnV4LWtkYi9rZGIva2RibWFpbi5jCVNhdCBNYXIgMjkgMTA6MTY6MDYgMjAwMworKysg bGludXgta2RiLWtpbGwva2RiL2tkYm1haW4uYwlNb24gTWFyIDMxIDE2OjMxOjE5IDIwMDMKQEAg LTI5NDcsNiArMjk0NywxMTQgQEAKIAlyZXR1cm4gMDsKIH0KIAorZXh0ZXJuIGludCBrZGJfd2Fr ZV91cF9wcm9jZXNzKHN0cnVjdCB0YXNrX3N0cnVjdCAqIHApOworCisvKgorICoga2RiX2tpbGwK KyAqCisgKglUaGlzIGZ1bmN0aW9uIGltcGxlbWVudHMgdGhlICdraWxsJyBjb21tYW5kcy4KKyAq CisgKiBJbnB1dHM6CisgKglhcmdjCWFyZ3VtZW50IGNvdW50CisgKglhcmd2CWFyZ3VtZW50IHZl Y3RvcgorICoJZW52cAllbnZpcm9ubWVudCB2ZWN0b3IKKyAqCXJlZ3MJcmVnaXN0ZXJzIGF0IHRp bWUga2RiIHdhcyBlbnRlcmVkLgorICogT3V0cHV0czoKKyAqCU5vbmUuCisgKiBSZXR1cm5zOgor ICoJemVybyBmb3Igc3VjY2VzcywgYSBrZGIgZGlhZ25vc3RpYyBpZiBlcnJvcgorICogTG9ja2lu ZzoKKyAqCW5vbmUuCisgKiBSZW1hcmtzOgorICovCitpbnQKK2tkYl9raWxsKGludCBhcmdjLCBj b25zdCBjaGFyICoqYXJndiwgY29uc3QgY2hhciAqKmVudnAsIHN0cnVjdCBwdF9yZWdzICpyZWdz KQoreworCWxvbmcgc2lnLCBwaWQ7CisJY2hhciAqZW5kcDsKKwlzdHJ1Y3QgdGFza19zdHJ1Y3Qg KnAsICp0ZzsKKwlpbnQgZmluZDsKKworCXNpZyA9IHNpbXBsZV9zdHJ0b2woYXJndlsxXSwgJmVu ZHAsIDApOworCWlmIChlbmRwID09IGFyZ3ZbMV0pCisJCXJldHVybiBLREJfQkFESU5UOworCWlm IChzaWcgPj0gMCApIHsKKwkJa2RiX3ByaW50ZigiSW52YWxpZCBzaWduYWwgcGFyYW1ldGVyLjwt c2lnbmFsPlxuIik7CisJCXJldHVybiAwOworCX0KKwlzaWc9LXNpZzsKKworCXBpZCA9IHNpbXBs ZV9zdHJ0b2woYXJndlsyXSwgJmVuZHAsIDApOworCWlmIChlbmRwID09IGFyZ3ZbMl0pCisJCXJl dHVybiBLREJfQkFESU5UOworCWlmIChwaWQgPD0wICkgeworCQlrZGJfcHJpbnRmKCJQcm9jZXNz IElEIG11c3QgYmUgbGFyZ2UgdGhhbiAwLlxuIik7CisJCXJldHVybiAwOworCX0KKworCS8qIEZp bmQgdGhlIHByb2Nlc3MuICovCisJZmluZCA9IDA7CisJZm9yX2VhY2hfdGFzayhwKSB7CisJCWlm KHAtPnBpZCA9PSBwaWQpIHsKKwkJCWZpbmQgPSAxOworCQkJYnJlYWs7CisJCX0KKwl9CisJaWYg KGZpbmQpIHsKKwkJLyogSW4gY2FzZSB0aGUgcHJvY2VzcyBpcyBub3QgYSB0aHJlYWQgZ3JvdXAg bGVhZGVyLCBmaW5kIHRoZSBsZWFkZXIuICovCisJCWlmICggcC0+dGdpZCAhPSBwLT5waWQpIHsK KwkJCWZvcl9lYWNoX3Rhc2sodGcpIHsKKwkJCQlpZih0Zy0+cGlkID09IHAtPnRnaWQpIHsKKwkJ CQkJcCA9IHRnOworCQkJCQlicmVhazsKKwkJCQl9CisJCQl9CisJCX0KKwkJaWYgKHNpZyA+MCAm JiBzaWcgPD0gX05TSUcpIHsKKwkJCWludCBzaWdpc21lbWJlcjsKKwkJCXNpZ3NldF90ICpzZXQ7 CisKKwkJCS8qIEhhbmRsZSBUQVNLX1NUT1BQRUQgY2FzZXMuICovCisJCQlpZiAoc2lnID09IFNJ R0tJTEwgfHwgc2lnID09IFNJR0NPTlQpIHsKKwkJCQkvKiBXYWtlIHVwIHRoZSBwcm9jZXNzIGlm IGl0IGlzIHN0b3BwZWQuICovCisJCQkJaWYgKHAtPnN0YXRlICYgVEFTS19TVE9QUEVEKSB7CisJ CQkJCWtkYl93YWtlX3VwX3Byb2Nlc3MocCk7CisJCQkJfQorCQkJCXAtPmV4aXRfY29kZSA9IDA7 CisJCQl9CisKKwkJCXNpZy0tOworCisJCQkvKiBTZXQgdGhlIHNpZ25hbCB0byB0aGUgc3BlY2lm aWVkIHByb2Nlc3MncyB0YXNrIHN0cnVjdHVyZS4gKi8KKwkJCXNldD0mKHAtPnBlbmRpbmcuc2ln bmFsKTsKKwkJCWlmIChfTlNJR19XT1JEUyA9PSAxKQorCQkJCXNldC0+c2lnWzBdIHw9IDFVTCA8 PCBzaWc7CisJCQllbHNlCisJCQkJc2V0LT5zaWdbc2lnIC8gX05TSUdfQlBXXSB8PSAxVUwgPDwg KHNpZyAlIF9OU0lHX0JQVyk7CisKKwkJCS8qIENoZWNrIGlmIHNwZWNpZmllZCBwcm9jZXNzIGlz IGJsb2NrZWQgYnkgdGhlIGdpdmVuIHNpZ25hbC4gKi8KKwkJCXNldD0mKHAtPmJsb2NrZWQpOwor CQkJaWYgKF9OU0lHX1dPUkRTID09IDEpCisJCQkJc2lnaXNtZW1iZXIgPSAxICYgKHNldC0+c2ln WzBdID4+IHNpZyk7CisJCQllbHNlCisJCQkJc2lnaXNtZW1iZXIgPSAxICYgKHNldC0+c2lnW3Np ZyAvIF9OU0lHX0JQV10gPj4gKHNpZyAlIF9OU0lHX0JQVykpOworCisJCQlpZiAoIXNpZ2lzbWVt YmVyKSB7CisJCQkJLyogV2FrZSB1cCB0aGUgcHJvY2VzcyBpZiBpdCBpcyBpbnRlcnJ1cHRhYmxl LiAqLworCQkJCXAtPnNpZ3BlbmRpbmc9MTsKKwkJCQlpZihwLT5zdGF0ZSAmIFRBU0tfSU5URVJS VVBUSUJMRSkKKwkJCQkJa2RiX3dha2VfdXBfcHJvY2VzcyhwKTsKKwkJCQlrZGJfcHJpbnRmKCJT aWduYWwgJWQgaXMgc2VudCB0byBwcm9jZXNzICVkLlxuIiwgKytzaWcsIHBpZCk7CisJCQl9CisJ CX0KKwl9CisJZWxzZSB7CisJCWtkYl9wcmludGYoIlRoZSBzcGVjaWZpZWQgcHJvY2VzcyBpc24n dCBmb3VuZC5cbiIpOworCX0KKworCXJldHVybiAwOworfQorCiAvKgogICoga2RiX3JlZ2lzdGVy X3JlcGVhdAogICoKQEAgLTMxNjIsNiArMzI3MCw3IEBACiAjZW5kaWYKIAlrZGJfcmVnaXN0ZXJf cmVwZWF0KCJkbWVzZyIsIGtkYl9kbWVzZywgIltsaW5lc10iLAkiRGlzcGxheSBzeXNsb2cgYnVm ZmVyIiwgMCwgS0RCX1JFUEVBVF9OT05FKTsKIAlrZGJfcmVnaXN0ZXJfcmVwZWF0KCJkZWZjbWQi LCBrZGJfZGVmY21kLCAibmFtZSBcInVzYWdlXCIgXCJoZWxwXCIiLCAiRGVmaW5lIGEgc2V0IG9m IGNvbW1hbmRzLCBkb3duIHRvIGVuZGVmY21kIiwgMCwgS0RCX1JFUEVBVF9OT05FKTsKKwlrZGJf cmVnaXN0ZXJfcmVwZWF0KCJraWxsIiwga2RiX2tpbGwsICI8LXNpZ25hbD4gPHBpZD4iLCAiU2Vu ZCBhIHNpZ25hbCB0byBhIHByb2Nlc3MiLCAwLCBLREJfUkVQRUFUX05PTkUpOwogCiAJLyogQW55 IGtkYiBjb21tYW5kcyB0aGF0IGFyZSBub3QgaW4gdGhlIGJhc2UgY29kZSBidXQgYXJlIHJlcXVp cmVkCiAJICogZWFybGllciB0aGFuIG5vcm1hbCBpbml0Y2FsbCBwcm9jZXNzaW5nLgoKCi0tLSBs aW51eC1rZGIva2VybmVsL3NjaGVkLmMJTW9uIE1hciAzMSAxNjoyMzo1OCAyMDAzCisrKyBsaW51 eC1rZGIta2lsbC9rZXJuZWwvc2NoZWQuYwlNb24gTWFyIDMxIDE2OjIxOjUwIDIwMDMKQEAgLTMz OCw2ICszMzgsMTkgQEAKIAlsaXN0X2FkZF90YWlsKCZwLT5ydW5fbGlzdCwgJnJ1bnF1ZXVlX2hl YWQpOwogfQogCisjaWZkZWYgQ09ORklHX0tEQgoraW50IGtkYl93YWtlX3VwX3Byb2Nlc3Moc3Ry dWN0IHRhc2tfc3RydWN0ICogcCkKK3sKKwlwLT5zdGF0ZSA9IFRBU0tfUlVOTklORzsKKwlpZiAo IXRhc2tfb25fcnVucXVldWUocCkpIHsKKwkJYWRkX3RvX3J1bnF1ZXVlKHApOworCQlyZXNjaGVk dWxlX2lkbGUocCk7CisJCXJldHVybiAxOworCX0KKwlyZXR1cm4gMDsKK30KKyNlbmRpZiAvKiBD T05GSUdfS0RCICovCisKIC8qCiAgKiBXYWtlIHVwIGEgcHJvY2Vzcy4gUHV0IGl0IG9uIHRoZSBy dW4tcXVldWUgaWYgaXQncyBub3QKICAqIGFscmVhZHkgdGhlcmUuICBUaGUgImN1cnJlbnQiIHBy b2Nlc3MgaXMgYWx3YXlzIG9uIHRoZQo= ------_=_NextPart_001_01C2F97F.56469F1B-- From eddie.dong@intel.com Wed Apr 2 21:31:27 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 02 Apr 2003 21:31:32 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h335VQDH000779 for ; Wed, 2 Apr 2003 21:31:27 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h335RmP22094 for ; Thu, 3 Apr 2003 05:27:48 GMT Received: from ydong-dev2 (ydong-dev2.sh.intel.com [172.16.219.182]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with ESMTP id h335PTi04602 for ; Thu, 3 Apr 2003 05:25:29 GMT Content-Type: text/plain; charset="us-ascii" From: edie Organization: Intel To: kdb@oss.sgi.com Subject: XScale patch for KDB4.0 is ready now. Date: Thu, 3 Apr 2003 10:56:12 +0800 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200304031056.12418.eddie.dong@intel.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h335VQDH000779 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 305 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: eddie.dong@intel.com Precedence: bulk X-list: kdb WIth the help from Keith, the XScale patch for KDB4.0 is ready now. I have tested it on lubbock board. From vamsi@in.ibm.com Wed Apr 2 22:39:58 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 02 Apr 2003 22:40:05 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h336dtDH001157 for ; Wed, 2 Apr 2003 22:39:58 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h336dHs5086870; Thu, 3 Apr 2003 01:39:18 -0500 Received: from vamsiks.in.ibm.com (vamsiks.in.ibm.com [9.182.12.245]) by westrelay03.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h336dCGJ081030; Wed, 2 Apr 2003 23:39:13 -0700 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h336x5a27685; Thu, 3 Apr 2003 12:29:05 +0530 Date: Thu, 3 Apr 2003 12:29:05 +0530 From: "Vamsi Krishna S ." To: "Zhang, Sonic" Cc: Keith Owens , Hua Qin , kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Message-ID: <20030403122905.A27647@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <37FBBA5F3A361C41AB7CE44558C3448E350F4A@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <37FBBA5F3A361C41AB7CE44558C3448E350F4A@pdsmsx403.ccr.corp.intel.com>; from sonic.zhang@intel.com on Wed, Apr 02, 2003 at 04:03:49PM +0800 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 306 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb Hi, Thanks for the clarification. I thought from my quick glance through that currently all hard breakpoints are global, whereas your patches enabled per-cpu breakpoints. On second look, you are right, the current code allows only per-cpu debugreg-breakpoints, global ones are much more generally useful, which your patch enables. I also agree with the name changes and the fact that per-cpu breakpoints may be useful for debugging certain paths (processes) bound to a specific cpu. smphdr* patches are very much needed. Thanks, Vamsi. BTW: Can you think about what happens if two debugreg breakpoints are triggered at about the same time on different cpus? One of them wins the race to enter the kdb, and then the user clears all breakpoints.. will kdb be able still recognise this as one of its breakpoints? I think not, but can you give it a thought? -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From sonic.zhang@intel.com Wed Apr 2 23:20:09 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 02 Apr 2003 23:20:14 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h337K8DH001843 for ; Wed, 2 Apr 2003 23:20:08 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h337FWa11297 for ; Thu, 3 Apr 2003 07:15:32 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h336sYc20005 for ; Thu, 3 Apr 2003 06:54:34 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040315200121231 ; Thu, 03 Apr 2003 15:20:01 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 15:20:01 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 3 Apr 2003 15:20:01 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E488CEB@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Thread-Index: AcL5q9PHderUUAJSSCmtTVrTaTVNsAABEkMg From: "Zhang, Sonic" To: Cc: "Keith Owens" , "Hua Qin" , X-OriginalArrivalTime: 03 Apr 2003 07:20:01.0469 (UTC) FILETIME=[70ACB6D0:01C2F9B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h337K8DH001843 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 307 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb Hi, Yes, the case you mentioned is possible in current KDB. I remember some related instructions in the KDB man pages. It is said that don't remove any break point when you enter KDB through DEBUG trap or Int3 trap, disable it instead and remove it safely later when you enter KDB via keyboard trap or serial port trap. Maybe your patch can clean up these comments in the man pages? Regards. Sonic Zhang -----Original Message----- From: Vamsi Krishna S . [mailto:vamsi@in.ibm.com] Sent: 2003?4?3? 14:59 To: Zhang, Sonic Cc: Keith Owens; Hua Qin; kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Hi, Thanks for the clarification. I thought from my quick glance through that currently all hard breakpoints are global, whereas your patches enabled per-cpu breakpoints. On second look, you are right, the current code allows only per-cpu debugreg-breakpoints, global ones are much more generally useful, which your patch enables. I also agree with the name changes and the fact that per-cpu breakpoints may be useful for debugging certain paths (processes) bound to a specific cpu. smphdr* patches are very much needed. Thanks, Vamsi. BTW: Can you think about what happens if two debugreg breakpoints are triggered at about the same time on different cpus? One of them wins the race to enter the kdb, and then the user clears all breakpoints.. will kdb be able still recognise this as one of its breakpoints? I think not, but can you give it a thought? -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From kaos@sgi.com Thu Apr 3 00:17:52 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 03 Apr 2003 00:17:58 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h338HoDH002274 for ; Thu, 3 Apr 2003 00:17:51 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h338TvVe015211 for ; Thu, 3 Apr 2003 02:29:58 -0600 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21634; Thu, 3 Apr 2003 18:16:26 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id BC1D43000B8; Thu, 3 Apr 2003 18:16:25 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 8612D8F; Thu, 3 Apr 2003 18:16:25 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Zhang, Sonic" Cc: "KDB (E-mail)" Subject: Re: new patch for KDB command "kill" In-reply-to: Your message of "Thu, 03 Apr 2003 09:21:22 +0800." <37FBBA5F3A361C41AB7CE44558C3448E488BB7@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Apr 2003 18:16:20 +1000 Message-ID: <5499.1049357780@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 308 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Thu, 3 Apr 2003 09:21:22 +0800, "Zhang, Sonic" wrote: > The attachment is the patch for KDB command "kill". > usage: > kill <-signal> You need to check the argument count in kdb_kill, otherwise kill with no arguments will kill kdb :). The test for valid numbers is wrong, you do not test endp against the argument, you test is *endp is NUL. See simple_strtol in kdb_md(). kdbgetularg() uses a different test because it has to handle expressions. Instead of coding all the signal handling yourself, can you use kernel/signal.c:send_sig_info()? send_sig_info handles all the cases for stopped processes, run queues etc., using that routine means that kdb is not sensitive to changes in signal code. Do trylock on t->sigmask_lock in kdb to see if you can get the process mask lock before calling send_sig_info(), to avoid deadlock. From vamsi@in.ibm.com Thu Apr 3 00:26:55 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 03 Apr 2003 00:27:01 -0800 (PST) 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.5) with SMTP id h338QsDH002370 for ; Thu, 3 Apr 2003 00:26:54 -0800 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h338PMgJ171298; Thu, 3 Apr 2003 03:25:22 -0500 Received: from vamsiks.in.ibm.com (vamsiks.in.ibm.com [9.182.12.245]) by westrelay05.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h338QDhQ042570; Thu, 3 Apr 2003 01:26:14 -0700 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h338k7g27904; Thu, 3 Apr 2003 14:16:07 +0530 Date: Thu, 3 Apr 2003 14:16:07 +0530 From: "Vamsi Krishna S ." To: "Zhang, Sonic" Cc: Keith Owens , Hua Qin , kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Message-ID: <20030403141606.A27891@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <37FBBA5F3A361C41AB7CE44558C3448E488CEB@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <37FBBA5F3A361C41AB7CE44558C3448E488CEB@pdsmsx403.ccr.corp.intel.com>; from sonic.zhang@intel.com on Thu, Apr 03, 2003 at 03:20:01PM +0800 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 309 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb Yes, that is what I thought. My earlier patch fixed only the int3 points. I will do similar fix for debugreg breakpoints too and update the man pages and code comments accordingly. Thanks, Vamsi. On Thu, Apr 03, 2003 at 03:20:01PM +0800, Zhang, Sonic wrote: > Hi, > > Yes, the case you mentioned is possible in current KDB. I remember some related instructions in the KDB man pages. It is said that don't remove any break point when you enter KDB through DEBUG trap or Int3 trap, disable it instead and remove it safely later when you enter KDB via keyboard trap or serial port trap. > > Maybe your patch can clean up these comments in the man pages? > > Regards. > > Sonic Zhang > > -----Original Message----- > From: Vamsi Krishna S . [mailto:vamsi@in.ibm.com] > Sent: 2003?4?3? 14:59 > To: Zhang, Sonic > Cc: Keith Owens; Hua Qin; kdb@oss.sgi.com > Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) > > > Hi, > > Thanks for the clarification. I thought from my quick > glance through that currently all hard breakpoints > are global, whereas your patches enabled per-cpu > breakpoints. On second look, you are right, the current > code allows only per-cpu debugreg-breakpoints, global > ones are much more generally useful, which your patch > enables. > > I also agree with the name changes and the fact that > per-cpu breakpoints may be useful for debugging certain > paths (processes) bound to a specific cpu. > > smphdr* patches are very much needed. > > Thanks, > Vamsi. > > BTW: Can you think about what happens if two debugreg > breakpoints are triggered at about the same time on > different cpus? One of them wins the race to enter > the kdb, and then the user clears all breakpoints.. > will kdb be able still recognise this as one of its > breakpoints? I think not, but can you give it a thought? > > -- > Vamsi Krishna S. > Linux Technology Center, > IBM Software Lab, Bangalore. > Ph: +91 80 5044959 > Internet: vamsi@in.ibm.com -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From kaos@sgi.com Thu Apr 3 05:55:53 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 03 Apr 2003 05:55:57 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h33DtoDH011311 for ; Thu, 3 Apr 2003 05:55:51 -0800 Received: (qmail 26550 invoked from network); 3 Apr 2003 13:55:47 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 3 Apr 2003 13:55:47 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 62A653000B8; Thu, 3 Apr 2003 23:55:43 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 2C8878F; Thu, 3 Apr 2003 23:55:43 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: vamsi@in.ibm.com Cc: "Zhang, Sonic" , Hua Qin , kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) In-reply-to: Your message of "Thu, 03 Apr 2003 14:16:07 +0530." <20030403141606.A27891@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Apr 2003 23:55:37 +1000 Message-ID: <7843.1049378137@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 310 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Thu, 3 Apr 2003 14:16:07 +0530, "Vamsi Krishna S ." wrote: >Yes, that is what I thought. My earlier patch fixed only the int3 >points. I will do similar fix for debugreg breakpoints too >and update the man pages and code comments accordingly. I suggest you wait a bit. A lot of the breakpoint problems come from the fact that kdb tries to control who can enter kdb, in particular the way kdb tries to avoid two cpus entering kdb at the same time. I have concluded that this design was wrong, there are some situations where kdb cannot prevent concurrent entry, e.g. external debugging interrupts that are sent to all cpus and cannot be blocked. As usual, ia64 is a special case :(. The answer is not to try to prevent concurrent entry to kdb but to accept that it occurs and work with it. That means the breakpoint state must become per-cpu, as in the smphdr* patches. Concurrent software breakpoints will be allowed. From sonic.zhang@intel.com Thu Apr 3 20:34:13 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 03 Apr 2003 20:34:24 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h344YDDH006586 for ; Thu, 3 Apr 2003 20:34:13 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h344W9h15083 for ; Fri, 4 Apr 2003 04:32:09 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h344U8A18563 for ; Fri, 4 Apr 2003 04:30:09 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040412340506692 ; Fri, 04 Apr 2003 12:34:05 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Apr 2003 12:34:05 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2FA63.6CC53AAE" Subject: RE: new patch for KDB command "kill" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Fri, 4 Apr 2003 12:34:05 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E488F3D@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: new patch for KDB command "kill" Thread-Index: AcL5uVRHqKDrquk6SpiJ3CDYlNTEBwAn0TJg From: "Zhang, Sonic" To: "Keith Owens" Cc: "KDB (E-mail)" X-OriginalArrivalTime: 04 Apr 2003 04:34:05.0743 (UTC) FILETIME=[6D033BF0:01C2FA63] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 311 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FA63.6CC53AAE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, OK, I fixed the first 2 problems you mentioned. As for the way to send signal in KDB, I have some concerns. If I use = send_sig_info() in KDB, there are 2 possible dead locks within the code = scale under send_sig_info(). Both are in file kernel/signal.c. One is what you mentioned: spin_lock_irqsave(&t->sigmask_lock, flags); The other is: #ifdef CONFIG_SMP /* * If the task is running on a different CPU=20 * force a reschedule on the other CPU to make * it notice the new signal quickly. * * The code below is a tad loose and might occasionally * kick the wrong CPU if we catch the process in the * process of changing - but no harm is done by that * other than doing an extra (lightweight) IPI interrupt. */ spin_lock(&runqueue_lock); if (task_has_cpu(t) && t->processor !=3D smp_processor_id()) smp_send_reschedule(t->processor); spin_unlock(&runqueue_lock); #endif /* CONFIG_SMP */=09 In order to skip these unnecessary lock code, I write the signal = handling code myself.=20 I attached 2 patches, one uses send_sig_info(), the other keeps my own = handling. Thanks. Sonic Zhang -----Original Message----- From: Keith Owens [mailto:kaos@sgi.com] Sent: 2003?4?3? 16:16 To: Zhang, Sonic Cc: KDB (E-mail) Subject: Re: new patch for KDB command "kill"=20 On Thu, 3 Apr 2003 09:21:22 +0800,=20 "Zhang, Sonic" wrote: > The attachment is the patch for KDB command "kill". > usage: > kill <-signal> You need to check the argument count in kdb_kill, otherwise kill with no arguments will kill kdb :). The test for valid numbers is wrong, you do not test endp against the argument, you test is *endp is NUL. See simple_strtol in kdb_md(). kdbgetularg() uses a different test because it has to handle expressions. Instead of coding all the signal handling yourself, can you use kernel/signal.c:send_sig_info()? send_sig_info handles all the cases for stopped processes, run queues etc., using that routine means that kdb is not sensitive to changes in signal code. Do trylock on t->sigmask_lock in kdb to see if you can get the process mask lock before calling send_sig_info(), to avoid deadlock. ------_=_NextPart_001_01C2FA63.6CC53AAE Content-Type: application/octet-stream; name="kdb-kill-v4.0-2.4.20-common-2.patch" Content-Transfer-Encoding: base64 Content-Description: kdb-kill-v4.0-2.4.20-common-2.patch Content-Disposition: attachment; filename="kdb-kill-v4.0-2.4.20-common-2.patch" LS0tIGtkYm1haW4uYy5vcmlnCVNhdCBNYXIgMjkgMTA6MTY6MDYgMjAwMworKysga2RibWFpbi5j CUZyaSBBcHIgIDQgMTI6MjA6NDUgMjAwMwpAQCAtMjk0Nyw2ICsyOTQ3LDEwOCBAQAogCXJldHVy biAwOwogfQogCitleHRlcm4gaW50IGtkYl93YWtlX3VwX3Byb2Nlc3Moc3RydWN0IHRhc2tfc3Ry dWN0ICogcCk7CisKKy8qCisgKiBrZGJfa2lsbAorICoKKyAqCVRoaXMgZnVuY3Rpb24gaW1wbGVt ZW50cyB0aGUgJ2tpbGwnIGNvbW1hbmRzLgorICoKKyAqIElucHV0czoKKyAqCWFyZ2MJYXJndW1l bnQgY291bnQKKyAqCWFyZ3YJYXJndW1lbnQgdmVjdG9yCisgKgllbnZwCWVudmlyb25tZW50IHZl Y3RvcgorICoJcmVncwlyZWdpc3RlcnMgYXQgdGltZSBrZGIgd2FzIGVudGVyZWQuCisgKiBPdXRw dXRzOgorICoJTm9uZS4KKyAqIFJldHVybnM6CisgKgl6ZXJvIGZvciBzdWNjZXNzLCBhIGtkYiBk aWFnbm9zdGljIGlmIGVycm9yCisgKiBMb2NraW5nOgorICoJbm9uZS4KKyAqIFJlbWFya3M6Cisg Ki8KK2ludAora2RiX2tpbGwoaW50IGFyZ2MsIGNvbnN0IGNoYXIgKiphcmd2LCBjb25zdCBjaGFy ICoqZW52cCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MpCit7CisJbG9uZyBzaWcsIHBpZDsKKwljaGFy ICplbmRwOworCXN0cnVjdCB0YXNrX3N0cnVjdCAqcCwgKnRnOworCWludCBmaW5kOworCXN0cnVj dCBzaWdpbmZvIGluZm87CisKKwlpZiAoYXJnYyE9MikgeworCQlrZGJfcHJpbnRmKCJJbnZhbGlk IHBhcmFtZXRlciBudW1iZXIuXG4iKTsKKwkJcmV0dXJuIDA7CisJfQorCisJc2lnID0gc2ltcGxl X3N0cnRvbChhcmd2WzFdLCAmZW5kcCwgMCk7CisJaWYgKCplbmRwKQorCQlyZXR1cm4gS0RCX0JB RElOVDsKKwlpZiAoc2lnID49IDAgKSB7CisJCWtkYl9wcmludGYoIkludmFsaWQgc2lnbmFsIHBh cmFtZXRlci48LXNpZ25hbD5cbiIpOworCQlyZXR1cm4gMDsKKwl9CisJc2lnPS1zaWc7CisKKwlw aWQgPSBzaW1wbGVfc3RydG9sKGFyZ3ZbMl0sICZlbmRwLCAwKTsKKwlpZiAoKmVuZHApCisJCXJl dHVybiBLREJfQkFESU5UOworCWlmIChwaWQgPD0wICkgeworCQlrZGJfcHJpbnRmKCJQcm9jZXNz IElEIG11c3QgYmUgbGFyZ2UgdGhhbiAwLlxuIik7CisJCXJldHVybiAwOworCX0KKworCS8qIEZp bmQgdGhlIHByb2Nlc3MuICovCisJZmluZCA9IDA7CisJZm9yX2VhY2hfdGFzayhwKSB7CisJCWlm KHAtPnBpZCA9PSBwaWQpIHsKKwkJCWZpbmQgPSAxOworCQkJYnJlYWs7CisJCX0KKwl9CisJaWYg KGZpbmQpIHsKKwkJLyogSW4gY2FzZSB0aGUgcHJvY2VzcyBpcyBub3QgYSB0aHJlYWQgZ3JvdXAg bGVhZGVyLCBmaW5kIHRoZSBsZWFkZXIuICovCisJCWlmICggcC0+dGdpZCAhPSBwLT5waWQpIHsK KwkJCWZvcl9lYWNoX3Rhc2sodGcpIHsKKwkJCQlpZih0Zy0+cGlkID09IHAtPnRnaWQpIHsKKwkJ CQkJcCA9IHRnOworCQkJCQlicmVhazsKKwkJCQl9CisJCQl9CisJCX0KKwkJaWYoc3Bpbl90cnls b2NrKCZwLT5zaWdtYXNrX2xvY2spKSB7CisJCQlzcGluX3VubG9jaygmcC0+c2lnbWFza19sb2Nr KTsKKwkJCWlmKHNwaW5fdHJ5bG9jaygmcnVucXVldWVfbG9jaykpIHsKKwkJCQlzcGluX3VubG9j aygmcnVucXVldWVfbG9jayk7CisJCQkJaW5mby5zaV9zaWdubyA9IHNpZzsKKwkJCQlpbmZvLnNp X2Vycm5vID0gMDsKKwkJCQlpbmZvLnNpX2NvZGUgPSBTSV9VU0VSOworCQkJCWluZm8uc2lfcGlk ID0gY3VycmVudC0+cGlkOworCQkJCWluZm8uc2lfdWlkID0gY3VycmVudC0+dWlkOworCQkJCWlm KHNlbmRfc2lnX2luZm8oc2lnLCAmaW5mbywgcCkpCisJCQkJCWtkYl9wcmludGYoIkZhaWwgdG8g ZGVsaXZlciBTaWduYWwgJWQgdG8gcHJvY2VzcyAlZC5cbiIsIHNpZywgcGlkKTsKKwkJCQllbHNl CisJCQkJCWtkYl9wcmludGYoIlNpZ25hbCAlZCBpcyBzZW50IHRvIHByb2Nlc3MgJWQuXG4iLCBz aWcsIHBpZCk7CisJCQl9CisJCQllbHNlIHsKKwkJCQlrZGJfcHJpbnRmKCJDYW4ndCBkbyBraWxs IGNvbW1hbmQgbm93LlxuXAorCQkJCVRoZSBydW5xdWV1ZSBsb2NrIGlzIGhlbGQgc29tZXdoZXJl IGVsc2UgaW4ga2VybmVsLlxuXAorCQkJCVRyeSBpdCBsYXRlci4iKTsKKwkJCX0KKwkJfQorCQll bHNlIHsKKwkJCWtkYl9wcmludGYoIkNhbid0IGRvIGtpbGwgY29tbWFuZCBub3cuXG5cCisJCQlU aGUgc2lnbWFzayBsb2NrIGlzIGhlbGQgc29tZXdoZXJlIGVsc2UgaW4ga2VybmVsLlxuXAorCQkJ VHJ5IGl0IGxhdGVyLiIpOworCQl9CisJfQorCWVsc2UgeworCQlrZGJfcHJpbnRmKCJUaGUgc3Bl Y2lmaWVkIHByb2Nlc3MgaXNuJ3QgZm91bmQuXG4iKTsKKwl9CisKKwlyZXR1cm4gMDsKK30KKwog LyoKICAqIGtkYl9yZWdpc3Rlcl9yZXBlYXQKICAqCkBAIC0zMTYyLDYgKzMyNjQsNyBAQAogI2Vu ZGlmCiAJa2RiX3JlZ2lzdGVyX3JlcGVhdCgiZG1lc2ciLCBrZGJfZG1lc2csICJbbGluZXNdIiwJ IkRpc3BsYXkgc3lzbG9nIGJ1ZmZlciIsIDAsIEtEQl9SRVBFQVRfTk9ORSk7CiAJa2RiX3JlZ2lz dGVyX3JlcGVhdCgiZGVmY21kIiwga2RiX2RlZmNtZCwgIm5hbWUgXCJ1c2FnZVwiIFwiaGVscFwi IiwgIkRlZmluZSBhIHNldCBvZiBjb21tYW5kcywgZG93biB0byBlbmRlZmNtZCIsIDAsIEtEQl9S RVBFQVRfTk9ORSk7CisJa2RiX3JlZ2lzdGVyX3JlcGVhdCgia2lsbCIsIGtkYl9raWxsLCAiPC1z aWduYWw+IDxwaWQ+IiwgIlNlbmQgYSBzaWduYWwgdG8gYSBwcm9jZXNzIiwgMCwgS0RCX1JFUEVB VF9OT05FKTsKIAogCS8qIEFueSBrZGIgY29tbWFuZHMgdGhhdCBhcmUgbm90IGluIHRoZSBiYXNl IGNvZGUgYnV0IGFyZSByZXF1aXJlZAogCSAqIGVhcmxpZXIgdGhhbiBub3JtYWwgaW5pdGNhbGwg cHJvY2Vzc2luZy4K ------_=_NextPart_001_01C2FA63.6CC53AAE Content-Type: application/octet-stream; name="kdb-kill-v4.0-2.4.20-common-2-myhandling.patch" Content-Transfer-Encoding: base64 Content-Description: kdb-kill-v4.0-2.4.20-common-2-myhandling.patch Content-Disposition: attachment; filename="kdb-kill-v4.0-2.4.20-common-2-myhandling.patch" LS0tIGxpbnV4LWtkYi9rZGIva2RibWFpbi5jCVNhdCBNYXIgMjkgMTA6MTY6MDYgMjAwMworKysg bGludXgta2RiLWtpbGwva2RiL2tkYm1haW4uYwlNb24gTWFyIDMxIDE2OjMxOjE5IDIwMDMKQEAg LTI5NDcsNiArMjk0NywxMjkgQEAKIAlyZXR1cm4gMDsKIH0KCitleHRlcm4gaW50IGtkYl93YWtl X3VwX3Byb2Nlc3Moc3RydWN0IHRhc2tfc3RydWN0ICogcCk7CisKKy8qCisgKiBrZGJfa2lsbAor ICoKKyAqCVRoaXMgZnVuY3Rpb24gaW1wbGVtZW50cyB0aGUgJ2tpbGwnIGNvbW1hbmRzLgorICoK KyAqIElucHV0czoKKyAqCWFyZ2MJYXJndW1lbnQgY291bnQKKyAqCWFyZ3YJYXJndW1lbnQgdmVj dG9yCisgKgllbnZwCWVudmlyb25tZW50IHZlY3RvcgorICoJcmVncwlyZWdpc3RlcnMgYXQgdGlt ZSBrZGIgd2FzIGVudGVyZWQuCisgKiBPdXRwdXRzOgorICoJTm9uZS4KKyAqIFJldHVybnM6Cisg Kgl6ZXJvIGZvciBzdWNjZXNzLCBhIGtkYiBkaWFnbm9zdGljIGlmIGVycm9yCisgKiBMb2NraW5n OgorICoJbm9uZS4KKyAqIFJlbWFya3M6CisgKi8KK2ludAora2RiX2tpbGwoaW50IGFyZ2MsIGNv bnN0IGNoYXIgKiphcmd2LCBjb25zdCBjaGFyICoqZW52cCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3Mp Cit7CisJbG9uZyBzaWcsIHBpZDsKKwljaGFyICplbmRwOworCXN0cnVjdCB0YXNrX3N0cnVjdCAq cCwgKnRnOworCWludCBmaW5kOworCisJaWYgKGFyZ2MhPTIpIHsKKwkJa2RiX3ByaW50ZigiSW52 YWxpZCBwYXJhbWV0ZXIgbnVtYmVyLlxuIik7CisJCXJldHVybiAwOworCX0KKworCXNpZyA9IHNp bXBsZV9zdHJ0b2woYXJndlsxXSwgJmVuZHAsIDApOworCWlmICgqZW5kcCkKKwkJcmV0dXJuIEtE Ql9CQURJTlQ7CisJaWYgKHNpZyA+PSAwICkgeworCQlrZGJfcHJpbnRmKCJJbnZhbGlkIHNpZ25h bCBwYXJhbWV0ZXIuPC1zaWduYWw+XG4iKTsKKwkJcmV0dXJuIDA7CisJfQorCXNpZz0tc2lnOwor CisJcGlkID0gc2ltcGxlX3N0cnRvbChhcmd2WzJdLCAmZW5kcCwgMCk7CisJaWYgKCplbmRwKQor CQlyZXR1cm4gS0RCX0JBRElOVDsKKwlpZiAocGlkIDw9MCApIHsKKwkJa2RiX3ByaW50ZigiUHJv Y2VzcyBJRCBtdXN0IGJlIGxhcmdlIHRoYW4gMC5cbiIpOworCQlyZXR1cm4gMDsKKwl9CisKKwkv KiBGaW5kIHRoZSBwcm9jZXNzLiAqLworCWZpbmQgPSAwOworCWZvcl9lYWNoX3Rhc2socCkgewor CQlpZihwLT5waWQgPT0gcGlkKSB7CisJCQlmaW5kID0gMTsKKwkJCWJyZWFrOworCQl9CisJfQor CWlmIChmaW5kKSB7CisJCS8qIEluIGNhc2UgdGhlIHByb2Nlc3MgaXMgbm90IGEgdGhyZWFkIGdy b3VwIGxlYWRlciwgZmluZCB0aGUgbGVhZGVyLiAqLworCQlpZiAoIHAtPnRnaWQgIT0gcC0+cGlk KSB7CisJCQlmb3JfZWFjaF90YXNrKHRnKSB7CisJCQkJaWYodGctPnBpZCA9PSBwLT50Z2lkKSB7 CisJCQkJCXAgPSB0ZzsKKwkJCQkJYnJlYWs7CisJCQkJfQorCQkJfQorCQl9CisJCWlmIChzaWcg PjAgJiYgc2lnIDw9IF9OU0lHKSB7CisJCQlpbnQgc2lnaXNtZW1iZXI7CisJCQlzaWdzZXRfdCAq c2V0OworCisJCQkvKiBIYW5kbGUgVEFTS19TVE9QUEVEIGNhc2VzLiAqLworCQkJaWYgKHNpZyA9 PSBTSUdLSUxMIHx8IHNpZyA9PSBTSUdDT05UKSB7CisJCQkJLyogV2FrZSB1cCB0aGUgcHJvY2Vz cyBpZiBpdCBpcyBzdG9wcGVkLiAqLworCQkJCWlmIChwLT5zdGF0ZSAmIFRBU0tfU1RPUFBFRCkg eworCQkJCQlpZigha2RiX3dha2VfdXBfcHJvY2VzcyhwKSkgeworCQkJCQkJa2RiX3ByaW50Zigi Q2FuJ3QgZG8ga2lsbCBjb21tYW5kIG5vdy5cblwKKwkJCQkJCVRoZSBydW5xdWV1ZSBsb2NrIGlz IGhlbGQgc29tZXdoZXJlIGVsc2UgaW4ga2VybmVsLlxuXAorCQkJCQkJVHJ5IGl0IGxhdGVyLiIp OworCQkJCQkJcmV0dXJuIDA7CisJCQkJCX0KKwkJCQl9CisJCQkJcC0+ZXhpdF9jb2RlID0gMDsK KwkJCX0KKworCQkJc2lnLS07CisKKwkJCS8qIFNldCB0aGUgc2lnbmFsIHRvIHRoZSBzcGVjaWZp ZWQgcHJvY2VzcydzIHRhc2sgc3RydWN0dXJlLiAqLworCQkJc2V0PSYocC0+cGVuZGluZy5zaWdu YWwpOworCQkJaWYgKF9OU0lHX1dPUkRTID09IDEpCisJCQkJc2V0LT5zaWdbMF0gfD0gMVVMIDw8 IHNpZzsKKwkJCWVsc2UKKwkJCQlzZXQtPnNpZ1tzaWcgLyBfTlNJR19CUFddIHw9IDFVTCA8PCAo c2lnICUgX05TSUdfQlBXKTsKKworCQkJLyogQ2hlY2sgaWYgc3BlY2lmaWVkIHByb2Nlc3MgaXMg YmxvY2tlZCBieSB0aGUgZ2l2ZW4gc2lnbmFsLiAqLworCQkJc2V0PSYocC0+YmxvY2tlZCk7CisJ CQlpZiAoX05TSUdfV09SRFMgPT0gMSkKKwkJCQlzaWdpc21lbWJlciA9IDEgJiAoc2V0LT5zaWdb MF0gPj4gc2lnKTsKKwkJCWVsc2UKKwkJCQlzaWdpc21lbWJlciA9IDEgJiAoc2V0LT5zaWdbc2ln IC8gX05TSUdfQlBXXSA+PiAoc2lnICUgX05TSUdfQlBXKSk7CisKKwkJCWlmICghc2lnaXNtZW1i ZXIpIHsKKwkJCQkvKiBXYWtlIHVwIHRoZSBwcm9jZXNzIGlmIGl0IGlzIGludGVycnVwdGFibGUu ICovCisJCQkJcC0+c2lncGVuZGluZz0xOworCQkJCWlmKHAtPnN0YXRlICYgVEFTS19JTlRFUlJV UFRJQkxFKQorCQkJCQlpZiAoIWtkYl93YWtlX3VwX3Byb2Nlc3MocCkpIHsKKwkJCQkJCWtkYl9w cmludGYoIkNhbid0IGRvIGtpbGwgY29tbWFuZCBub3cuXG5cCisJCQkJCQlUaGUgcnVucXVldWUg bG9jayBpcyBoZWxkIHNvbWV3aGVyZSBlbHNlIGluIGtlcm5lbC5cblwKKwkJCQkJCVRyeSBpdCBs YXRlci4iKTsKKwkJCQkJCXJldHVybiAwOworCQkJCQl9CisJCQkJa2RiX3ByaW50ZigiU2lnbmFs ICVkIGlzIHNlbnQgdG8gcHJvY2VzcyAlZC5cbiIsICsrc2lnLCBwaWQpOworCQkJfQorCQl9CisJ fQorCWVsc2UgeworCQlrZGJfcHJpbnRmKCJUaGUgc3BlY2lmaWVkIHByb2Nlc3MgaXNuJ3QgZm91 bmQuXG4iKTsKKwl9CisKKwlyZXR1cm4gMDsKK30KKwogLyoKICAqIGtkYl9yZWdpc3Rlcl9yZXBl YXQKICAqCkBAIC0zMTYyLDYgKzMyODUsNyBAQAogI2VuZGlmCiAJa2RiX3JlZ2lzdGVyX3JlcGVh dCgiZG1lc2ciLCBrZGJfZG1lc2csICJbbGluZXNdIiwJIkRpc3BsYXkgc3lzbG9nIGJ1ZmZlciIs IDAsIEtEQl9SRVBFQVRfTk9ORSk7CiAJa2RiX3JlZ2lzdGVyX3JlcGVhdCgiZGVmY21kIiwga2Ri X2RlZmNtZCwgIm5hbWUgXCJ1c2FnZVwiIFwiaGVscFwiIiwgIkRlZmluZSBhIHNldCBvZiBjb21t YW5kcywgZG93biB0byBlbmRlZmNtZCIsIDAsIEtEQl9SRVBFQVRfTk9ORSk7CisJa2RiX3JlZ2lz dGVyX3JlcGVhdCgia2lsbCIsIGtkYl9raWxsLCAiPC1zaWduYWw+IDxwaWQ+IiwgIlNlbmQgYSBz aWduYWwgdG8gYSBwcm9jZXNzIiwgMCwgS0RCX1JFUEVBVF9OT05FKTsKCiAJLyogQW55IGtkYiBj b21tYW5kcyB0aGF0IGFyZSBub3QgaW4gdGhlIGJhc2UgY29kZSBidXQgYXJlIHJlcXVpcmVkCiAJ ICogZWFybGllciB0aGFuIG5vcm1hbCBpbml0Y2FsbCBwcm9jZXNzaW5nLgoKCi0tLSBsaW51eC1r ZGIva2VybmVsL3NjaGVkLmMJTW9uIE1hciAzMSAxNjoyMzo1OCAyMDAzCisrKyBsaW51eC1rZGIt a2lsbC9rZXJuZWwvc2NoZWQuYwlNb24gTWFyIDMxIDE2OjIxOjUwIDIwMDMKQEAgLTMzOCw2ICsz MzgsMTkgQEAKIAlsaXN0X2FkZF90YWlsKCZwLT5ydW5fbGlzdCwgJnJ1bnF1ZXVlX2hlYWQpOwog fQoKKyNpZmRlZiBDT05GSUdfS0RCCisvKiBSZXR1cm4gMSBmb3Igc3VjY2VzcywgMCBmb3IgZmFp bHVyZS4gKi8KK2ludCBrZGJfd2FrZV91cF9wcm9jZXNzKHN0cnVjdCB0YXNrX3N0cnVjdCAqIHAp Cit7CisJaWYoc3Bpbl90cnlsb2NrKCZydW5xdWV1ZV9sb2NrKSkgeworCQlwLT5zdGF0ZSA9IFRB U0tfUlVOTklORzsKKwkJaWYgKCF0YXNrX29uX3J1bnF1ZXVlKHApKSB7CisJCQlhZGRfdG9fcnVu cXVldWUocCk7CisJCQlyZXNjaGVkdWxlX2lkbGUocCk7CisJCX0KKwkJc3Bpbl91bmxvY2soJnJ1 bnF1ZXVlX2xvY2spOworCQlyZXR1cm4gMTsKKwl9CisJcmV0dXJuIDA7Cit9CisjZW5kaWYgLyog Q09ORklHX0tEQiAqLworCiAvKgogICogV2FrZSB1cCBhIHByb2Nlc3MuIFB1dCBpdCBvbiB0aGUg cnVuLXF1ZXVlIGlmIGl0J3Mgbm90CiAgKiBhbHJlYWR5IHRoZXJlLiAgVGhlICJjdXJyZW50IiBw cm9jZXNzIGlzIGFsd2F5cyBvbiB0aGUK ------_=_NextPart_001_01C2FA63.6CC53AAE-- From kaos@sgi.com Thu Apr 3 21:38:45 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 03 Apr 2003 21:38:48 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h345ciDH008109 for ; Thu, 3 Apr 2003 21:38:45 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h345ccVV005065 for ; Thu, 3 Apr 2003 21:38:39 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04183; Fri, 4 Apr 2003 15:37:18 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 72A00300087; Fri, 4 Apr 2003 15:37:17 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 4996C178; Fri, 4 Apr 2003 15:37:17 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Zhang, Sonic" Cc: "KDB (E-mail)" Subject: Re: new patch for KDB command "kill" In-reply-to: Your message of "Fri, 04 Apr 2003 12:34:05 +0800." <37FBBA5F3A361C41AB7CE44558C3448E488F3D@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Apr 2003 15:37:11 +1000 Message-ID: <16360.1049434631@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 312 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Fri, 4 Apr 2003 12:34:05 +0800, "Zhang, Sonic" wrote: > OK, I fixed the first 2 problems you mentioned. > In order to skip these unnecessary lock code, I write the signal >handling code myself. I attached 2 patches, one uses send_sig_info(), >the other keeps my own handling. Applying the send_sig_info() version, with some cleanup. Thanks. kdb v4.1 will be out later today including the kill command. From vamsi@in.ibm.com Fri Apr 4 00:16:26 2003 Received: with ECARTIS (v1.0.0; list kdb); Fri, 04 Apr 2003 00:16:30 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h348GPDH012382 for ; Fri, 4 Apr 2003 00:16:26 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h348Fms5108382; Fri, 4 Apr 2003 03:15:48 -0500 Received: from vamsiks.in.ibm.com (vamsiks.in.ibm.com [9.182.12.245]) by westrelay03.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h348FWZL100366; Fri, 4 Apr 2003 01:15:36 -0700 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h348WBh30084; Fri, 4 Apr 2003 14:02:11 +0530 Date: Fri, 4 Apr 2003 14:02:10 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: "Zhang, Sonic" , Hua Qin , kdb@oss.sgi.com Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) Message-ID: <20030404140210.A30074@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <20030403141606.A27891@in.ibm.com> <7843.1049378137@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7843.1049378137@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Thu, Apr 03, 2003 at 11:55:37PM +1000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 313 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Thu, Apr 03, 2003 at 11:55:37PM +1000, Keith Owens wrote: > On Thu, 3 Apr 2003 14:16:07 +0530, > "Vamsi Krishna S ." wrote: > >Yes, that is what I thought. My earlier patch fixed only the int3 > >points. I will do similar fix for debugreg breakpoints too > >and update the man pages and code comments accordingly. > > I suggest you wait a bit. A lot of the breakpoint problems come from > the fact that kdb tries to control who can enter kdb, in particular the > way kdb tries to avoid two cpus entering kdb at the same time. I have > concluded that this design was wrong, there are some situations where > kdb cannot prevent concurrent entry, e.g. external debugging interrupts > that are sent to all cpus and cannot be blocked. As usual, ia64 is a > special case :(. > > The answer is not to try to prevent concurrent entry to kdb but to > accept that it occurs and work with it. That means the breakpoint > state must become per-cpu, as in the smphdr* patches. Concurrent > software breakpoints will be allowed. > Ok. For software breakpoints, when user types "bc *", this means you have to remove the INT3 instruction from the last CPU that is leaving KDB. I will take a look at the next release. Thanks, Vamsi. -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From kaos@sgi.com Sun Apr 6 06:07:45 2003 Received: with ECARTIS (v1.0.0; list kdb); Sun, 06 Apr 2003 06:07:56 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h36D7fDH019006 for ; Sun, 6 Apr 2003 06:07:43 -0700 Received: (qmail 12907 invoked from network); 6 Apr 2003 13:07:38 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Apr 2003 13:07:38 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id AFDC0300087; Sun, 6 Apr 2003 23:07:32 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 2EE3919A; Sun, 6 Apr 2003 23:07:32 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: kdb@oss.sgi.com Cc: linux-kernel@vger.kernel.org, linux-ia64@linuxia64.org Subject: Announce: kdb v4.1 is available for kernels 2.4.19, 2.4.20, i386 and ia64 Date: Sun, 06 Apr 2003 23:07:26 +1000 Message-ID: <14958.1049634446@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 314 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/kdb/download/v4.1/ kdb-v4.1-2.4.19-common-1.bz2 kdb-v4.1-2.4.19-i386-1.bz2 kdb-v4.1-2.4.19-ia64-020821-1.bz2 kdb-v4.1-2.4.20-common-1.bz2 kdb-v4.1-2.4.20-i386-1.bz2 kdb-v4.1-2.4.20-ia64-021210-1.bz2 Changelog extracts since v4.0. 2.4.{19,20}-common-1 2003-04-04 Keith Owens * Remove one kallsyms pass. * Automatic detection of O(1) scheduler. * Rename cpu_online to cpu_is_online. * Workarounds for scheduler bugs. * Tweak algorithm for detecting if cpu process data is available. * Add 'kill' command. Sonic Zhang, Keith Owens. 2.4.{19,20}-i386-1 2003-04-04 Keith Owens * Workarounds for scheduler bugs. 2.4.{19,20}-ia64-*-1 2003-04-04 Keith Owens * Add support for INIT slave interrupts. * Tell SAL to always rendezvous on MCA. * No lock on SAL rendezvous call. * Include unwind.c from 2.4.21-pre5. * Rename cpu_online to cpu_is_online. * Workarounds for scheduler bugs. v4.1/README Starting with kdb v2.0 there is a common patch against each kernel which contains all the architecture independent code plus separate architecture dependent patches. Apply the common patch for your kernel plus at least one architecture dependent patch, the architecture patches activate kdb. The naming convention for kdb patches is :- vx.y The version of kdb. x.y is updated as new features are added to kdb. -v.p.s The kernel version that the patch applies to. 's' may include -pre, -rc or whatever numbering system the kernel keepers have thought up this week. -common The common kdb code. Everybody needs this. -i386 Architecture dependent code for i386. -ia64 Architecture dependent code for ia64, etc. -n If there are multiple kdb patches against the same kernel version then the last number is incremented. To build kdb for your kernel, apply the common kdb patch which is less than or equal to the kernel v.p.s, taking the highest value of '-n' if there is more than one. Apply the relevant arch dependent patch with the same value of 'vx.y-v.p.s-', taking the highest value of '-n' if there is more than one. For example, to use kdb for i386 on kernel 2.4.20, apply kdb-v4.1-2.4.20-common- (use highest value of ) kdb-v4.1-2.4.20-i386- (use highest value of ) in that order. To use kdb for ia64-021210 on kernel 2.4.20, apply kdb-v4.1-2.4.20-common- (use highest value of ) kdb-v4.1-2.4.20-ia64-021210- (use highest value of ) in that order. Use patch -p1 for all patches. I do not have any time to work on 2.5, so there are no patches available for 2.5 kernels. If somebody wants to port the latest kdb patches to 2.5 kernels and send patches to kaos@sgi.com then I will put them up in this directory. The kdb-smphdr* patches in the v4.0 directory are Sonic Zhang's changes to improve hardware breakpoint handling on i386 and ia64. They are not official kdb patches yet, they are available for review. They will probably fit v4.1. The next step is to integrate Sonic Zhang's breakpoint changes into kdb and to change the kdb entry logic to cope with multiple cpus doing concurrent entry into kdb. At the moment kdb tries to serialize so it only processes one event at a time. The bad news is that this does not work well with IA64 SAL interrupts so kdb has to change. The good news is that the change will remove the deadlock when two cpus hit a breakpoint at the same time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE+kCaJi4UHNye0ZOoRAvSZAKC/aXyVRPjaho5/RY+JbhUF8xNGlwCeKtUv BBrDAhSon5J4woF3+65q+sY= =VZPB -----END PGP SIGNATURE----- From eddie.dong@intel.com Mon Apr 7 19:41:53 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 07 Apr 2003 19:41:59 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h382fqFu027923 for ; Mon, 7 Apr 2003 19:41:53 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h382cAL28987 for ; Tue, 8 Apr 2003 02:38:10 GMT Received: from ydong-dev2 (ydong-dev2.sh.intel.com [172.16.219.182]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with ESMTP id h382h4O25036 for ; Tue, 8 Apr 2003 02:43:05 GMT Content-Type: text/plain; charset="us-ascii" From: edie Organization: Intel To: kdb@oss.sgi.com Subject: cross kallsyms on different endian platform Date: Tue, 8 Apr 2003 08:06:01 +0800 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200304080806.01526.eddie.dong@intel.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h382fqFu027923 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 315 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: eddie.dong@intel.com Precedence: bulk X-list: kdb I want to build a cross kallsyms tool that works on IA32 host(little endian) but parses arm big endian target files, I met problems to make this tool work correctly, all the WORDs stored in target big endian format file are treated as little endian datas by host, so either I need to make bunch of source changes for cross endian platform or I need to use a same endian environment. Can anybody give me some hints? eddie From kaos@sgi.com Mon Apr 7 21:45:41 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 07 Apr 2003 21:45:45 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h384jfFu028931 for ; Mon, 7 Apr 2003 21:45:41 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h384w5Ve004292 for ; Mon, 7 Apr 2003 23:58:06 -0500 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA05830; Tue, 8 Apr 2003 14:44:15 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id BBD85300087; Tue, 8 Apr 2003 14:44:14 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 3910019A; Tue, 8 Apr 2003 14:44:14 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: edie Cc: kdb@oss.sgi.com Subject: Re: cross kallsyms on different endian platform In-reply-to: Your message of "Tue, 08 Apr 2003 08:06:01 +0800." <200304080806.01526.eddie.dong@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Apr 2003 14:44:08 +1000 Message-ID: <12203.1049777048@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 316 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Tue, 8 Apr 2003 08:06:01 +0800, edie wrote: >I want to build a cross kallsyms tool that works on IA32 host(little endian) >but parses arm big endian target files, I met problems to make this tool work >correctly, all the WORDs stored in target big endian format file are treated >as little endian datas by host, so either I need to make bunch of source >changes for cross endian platform or I need to use a same endian environment. >Can anybody give me some hints? >eddie kallsyms does not support cross compilation. Google for kallsyms i386 ia64 for a hard coded version that handles ia64 kernels on i386. For different endianess, you have to swap all fields as they are read in and written out. I have told the linux-kernel mailing list that I am willing to make modutils work in cross compile mode, with any combination of word size and endianess. But only after there is a demonstrated need for it, such as adding the kksymoops patch to the 2.4 kernel tree. At the moment, the "need" for cross compile modutils does not justify me doing a complete rewrite on modutils to support cross build. As long as debuggers are second class citizens in the kernel, they will get poor support. From vamsi@in.ibm.com Wed Apr 16 04:41:22 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 04:41:33 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GBfLFu015079 for ; Wed, 16 Apr 2003 04:41:21 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3GBfEE2188324; Wed, 16 Apr 2003 07:41:15 -0400 Received: from vamsiks.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3GBfAYJ075158; Wed, 16 Apr 2003 07:41:11 -0400 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h3GC1XL25512; Wed, 16 Apr 2003 17:31:33 +0530 Date: Wed, 16 Apr 2003 17:31:33 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: kdb Subject: [PATCH] access user space addresses/switch process context Message-ID: <20030416173132.A25486@in.ibm.com> Reply-To: vamsi@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 317 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb Hi, Here is a patch to implement a command to switch the current user process context whilst inside KDB to look at the stack, disassemble code, display memory etc. of different processes. Presently, KDB refuses to access user space addresses. A few developers requested for a way to access process memory and switch process contexts from within KDB. What it is required for are those occasions where the system is hung and there is no kernel panic. During hardware development it is not uncommon for test to just stop and the server to be hung. When this is caused by a process waiting for a resource to be freed, it is essential to be able to see who is holding the resource. Additionally, in a hang situation, the process that is causing the problem may not be the current process when you enter the debugger. This patch (against 2.4.20 + KDB v4.1) provides: - a way to switch the current process ("pid" command) - a way to look at user space registers of the current process ("rd u" command) - a way to access user space addresses in the context of a given process (normal md/mdr/id commands with user space addresses) Note that "bt" can be made to work unreliably in user contexts too, but I have left it out for now. Please comment/apply. Thanks, Vamsi. -- Vamsi Krishna S. IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com -- diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/arch/i386/kdb/kdbasupport.c 2420-kdb4.1/arch/i386/kdb/kdbasupport.c --- 2420-kdb4.1-pure/arch/i386/kdb/kdbasupport.c 2003-04-16 11:38:24.000000000 +0530 +++ 2420-kdb4.1/arch/i386/kdb/kdbasupport.c 2003-04-16 12:52:47.000000000 +0530 @@ -723,7 +723,7 @@ /* User registers: %%e[a-c]x, etc */ regname++; regs = (struct pt_regs *) - (current->thread.esp0 - sizeof(struct pt_regs)); + (kdb_current_task->thread.esp0 - sizeof(struct pt_regs)); } for (i=0; ithread.esp0 - sizeof(struct pt_regs)); + (kdb_current_task->thread.esp0 - sizeof(struct pt_regs)); } for (i=0; ithread.esp0 - sizeof(struct pt_regs)); + (kdb_current_task->thread.esp0 - sizeof(struct pt_regs)); } if (type == NULL) { diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/include/asm-i386/kdb.h 2420-kdb4.1/include/asm-i386/kdb.h --- 2420-kdb4.1-pure/include/asm-i386/kdb.h 2003-04-16 11:38:24.000000000 +0530 +++ 2420-kdb4.1/include/asm-i386/kdb.h 2003-04-16 12:58:42.000000000 +0530 @@ -92,6 +92,8 @@ return r; } +extern int kdb_getuserarea_size(void *, unsigned long, size_t); + static inline int __kdba_getarea_size(void *to, unsigned long from_xxx, size_t size) { @@ -99,6 +101,11 @@ int r; *((volatile char *)to) = '\0'; *((volatile char *)to + size - 1) = '\0'; + + if (from_xxx < PAGE_OFFSET) { + return kdb_getuserarea_size(to, from_xxx, size); + } + set_fs(KERNEL_DS); switch (size) { case 1: diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/include/linux/kdb.h 2420-kdb4.1/include/linux/kdb.h --- 2420-kdb4.1-pure/include/linux/kdb.h 2003-04-16 11:38:14.000000000 +0530 +++ 2420-kdb4.1/include/linux/kdb.h 2003-04-16 12:58:55.000000000 +0530 @@ -333,4 +333,6 @@ #endif } +extern struct task_struct *kdb_current_task; + #endif /* !_KDB_H */ diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/kdb/kdbmain.c 2420-kdb4.1/kdb/kdbmain.c --- 2420-kdb4.1-pure/kdb/kdbmain.c 2003-04-16 11:38:14.000000000 +0530 +++ 2420-kdb4.1/kdb/kdbmain.c 2003-04-16 11:47:59.000000000 +0530 @@ -76,6 +76,8 @@ volatile int kdb_state[NR_CPUS]; /* Per cpu state */ +struct task_struct *kdb_current_task; + #ifdef CONFIG_KDB_OFF int kdb_on = 0; /* Default is off */ #else @@ -1067,6 +1069,8 @@ kdba_local_arch_setup(); + kdb_current_task = current; + while (1) { /* * Initialize pager context. @@ -2781,6 +2785,59 @@ } /* + * kdb_pid + * + * This function implements the 'pid' command which switches + * the currently active process. + * + * pid [] + * + * Inputs: + * argc argument count + * argv argument vector + * envp environment vector + * regs registers at time kdb was entered. + * Outputs: + * None. + * Returns: + * zero for success, a kdb diagnostic if error + * Locking: + * none. + * Remarks: + */ + + +int +kdb_pid(int argc, const char **argv, const char **envp, struct pt_regs *regs) +{ + struct task_struct *p; + unsigned long val; + int diag; + + if (argc > 1) + return KDB_ARGCOUNT; + + if (argc) { + diag = kdbgetularg(argv[1], &val); + if (diag) + return KDB_BADINT; + + p = find_task_by_pid((pid_t)val); + if (!p) { + kdb_printf("No task with pid=%d\n", (pid_t)val); + return 0; + } + + kdb_current_task = p; + } + + kdb_printf("KDB current process is %s(pid=%d)\n", kdb_current_task->comm, + kdb_current_task->pid); + + return 0; +} + +/* * kdb_ll * * This function implements the 'll' command which follows a linked @@ -3245,6 +3302,7 @@ kdb_register_repeat("?", kdb_help, "", "Display Help Message", 0, KDB_REPEAT_NONE); kdb_register_repeat("cpu", kdb_cpu, "","Switch to new cpu", 0, KDB_REPEAT_NONE); kdb_register_repeat("ps", kdb_ps, "", "Display active task list", 0, KDB_REPEAT_NONE); + kdb_register_repeat("pid", kdb_pid, "", "Switch to another task", 0, KDB_REPEAT_NONE); kdb_register_repeat("reboot", kdb_reboot, "", "Reboot the machine immediately", 0, KDB_REPEAT_NONE); kdb_register_repeat("sections", kdb_sections, "", "List kernel and module sections", 0, KDB_REPEAT_NONE); #if defined(CONFIG_MODULES) diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/kdb/kdbsupport.c 2420-kdb4.1/kdb/kdbsupport.c --- 2420-kdb4.1-pure/kdb/kdbsupport.c 2003-04-16 11:38:14.000000000 +0530 +++ 2420-kdb4.1/kdb/kdbsupport.c 2003-04-16 12:56:42.000000000 +0530 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -800,3 +801,81 @@ else kdb_printf("0x%lx\n", val); } + +/* + * from mm/memory.c, adapted to run without any locks to work within kdb + */ +static struct page * kdb_follow_page(struct mm_struct *mm, unsigned long address, int write) +{ + pgd_t *pgd; + pmd_t *pmd; + pte_t *ptep, pte; + + pgd = pgd_offset(mm, address); + if (pgd_none(*pgd) || pgd_bad(*pgd)) + goto out; + + pmd = pmd_offset(pgd, address); + if (pmd_none(*pmd) || pmd_bad(*pmd)) + goto out; + + ptep = pte_offset(pmd, address); + if (!ptep) + goto out; + + pte = *ptep; + if (pte_present(pte)) { + if (!write || + (pte_write(pte) && pte_dirty(pte))) + return pte_page(pte); + } +out: + return 0; +} + +static struct page * kdb_get_one_user_page(struct task_struct *tsk, unsigned long start, + int len, int write) +{ + struct mm_struct *mm = tsk->mm; + unsigned int flags; + struct vm_area_struct * vma; + struct page *map; + + flags = write ? (VM_WRITE | VM_MAYWRITE) : (VM_READ | VM_MAYREAD); + + vma = find_extend_vma(mm, start); + + /* may be we can allow access to VM_IO pages inside KDB? */ + if (!vma || (vma->vm_flags & VM_IO) || !(flags & vma->vm_flags)) + return NULL; + + map = kdb_follow_page(mm, start, write); + if (!map || !VALID_PAGE(map)) + return NULL; + + return map; +} + +int kdb_getuserarea_size(void *to, unsigned long from, size_t size) +{ + struct page *page; + void * vaddr; + int ret; + + /* shouldn't cross a page boundary. temporary restriction. */ + if ((from & PAGE_MASK) != ((from+size) & PAGE_MASK)) { + kdb_printf("%s: crosses page boundary: from=%08lx, size=%d\n", + __FUNCTION__, from, size); + return size; + } + + page = kdb_get_one_user_page(kdb_current_task, PAGE_ALIGN(from), size, 0); + if (!page) + return size; + + vaddr = kmap_atomic(page, KM_KDB); + memcpy(to, vaddr+ (from & (PAGE_SIZE - 1)), size); + kunmap_atomic(vaddr, KM_KDB); + + return 0; +} From kaos@sgi.com Wed Apr 16 05:33:04 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 05:33:08 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GCX1Fu018392 for ; Wed, 16 Apr 2003 05:33:03 -0700 Received: (qmail 4510 invoked from network); 16 Apr 2003 12:32:59 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Apr 2003 12:32:59 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 00EF8300087; Wed, 16 Apr 2003 22:32:56 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id E706D19B; Wed, 16 Apr 2003 22:32:56 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: vamsi@in.ibm.com Cc: kdb Subject: Re: [PATCH] access user space addresses/switch process context In-reply-to: Your message of "Wed, 16 Apr 2003 17:31:33 +0530." <20030416173132.A25486@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Apr 2003 22:32:51 +1000 Message-ID: <28524.1050496371@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 318 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Wed, 16 Apr 2003 17:31:33 +0530, "Vamsi Krishna S ." wrote: >Here is a patch to implement a command to switch the current >user process context whilst inside KDB to look at the stack, >disassemble code, display memory etc. of different processes. It looks good for i386 but, before I put it into kdb, what about ia64 or ppc? I do not like patches that only work for one architecture. If a command works on ia64 then it tends to work anywhere, ia64 is _perverse_! From vamsi@in.ibm.com Wed Apr 16 05:44:29 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 05:44:33 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GCiSFu018487 for ; Wed, 16 Apr 2003 05:44:29 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3GCiM9X106174; Wed, 16 Apr 2003 08:44:22 -0400 Received: from vamsiks.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3GCiFYJ016686; Wed, 16 Apr 2003 08:44:18 -0400 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h3GD4fe25629; Wed, 16 Apr 2003 18:34:41 +0530 Date: Wed, 16 Apr 2003 18:34:41 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: kdb Subject: Re: [PATCH] access user space addresses/switch process context Message-ID: <20030416183441.A25625@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <20030416173132.A25486@in.ibm.com> <28524.1050496371@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <28524.1050496371@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Wed, Apr 16, 2003 at 10:32:51PM +1000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 319 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Wed, Apr 16, 2003 at 10:32:51PM +1000, Keith Owens wrote: > On Wed, 16 Apr 2003 17:31:33 +0530, > "Vamsi Krishna S ." wrote: > >Here is a patch to implement a command to switch the current > >user process context whilst inside KDB to look at the stack, > >disassemble code, display memory etc. of different processes. > > It looks good for i386 but, before I put it into kdb, what about ia64 > or ppc? I do not like patches that only work for one architecture. If > a command works on ia64 then it tends to work anywhere, ia64 is > _perverse_! > Most of the code here is arch-independent (in kdb/kdbsupport.c). The actual call to this function is from include/asm-i386/kdb.h. It will work just fine on any architecture, just that I didn't add the call in archs that I can't compile. Will send out an updated patch soon. Thanks, Vamsi -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From kaos@sgi.com Wed Apr 16 06:01:32 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 06:01:39 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GD1TFu019669 for ; Wed, 16 Apr 2003 06:01:30 -0700 Received: (qmail 4725 invoked from network); 16 Apr 2003 13:01:27 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Apr 2003 13:01:27 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 96B01300087; Wed, 16 Apr 2003 23:01:25 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3446919B; Wed, 16 Apr 2003 23:01:25 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: vamsi@in.ibm.com Cc: kdb Subject: Re: [PATCH] access user space addresses/switch process context In-reply-to: Your message of "Wed, 16 Apr 2003 17:31:33 +0530." <20030416173132.A25486@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Apr 2003 23:01:19 +1000 Message-ID: <28953.1050498079@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 320 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Wed, 16 Apr 2003 17:31:33 +0530, "Vamsi Krishna S ." wrote: >diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/kdb/kdbsupport.c 2420-kdb4.1/kdb/kdbsupport.c >--- 2420-kdb4.1-pure/kdb/kdbsupport.c 2003-04-16 11:38:14.000000000 +0530 >+++ 2420-kdb4.1/kdb/kdbsupport.c 2003-04-16 12:56:42.000000000 +0530 >+/* >+ * from mm/memory.c, adapted to run without any locks to work within kdb >+ */ >+static struct page * kdb_follow_page(struct mm_struct *mm, unsigned long address, int write) AFAICT this function is identical to follow_page(). Instead of duplicating that code and possibly getting out of sync with the real follow_page(), change follow_page() so it is extern for CONFIG_KDB=y, otherwise it is static. >+static struct page * kdb_get_one_user_page(struct task_struct *tsk, unsigned long start, >+ int len, int write) Why have a write flag? KDB will only read user pages, or are you planning more changes that will require write access? >+ /* shouldn't cross a page boundary. temporary restriction. */ >+ if ((from & PAGE_MASK) != ((from+size) & PAGE_MASK)) { >+ kdb_printf("%s: crosses page boundary: from=%08lx, size=%d\n", >+ __FUNCTION__, from, size); >+ return size; >+ } 'return size' changes the semantics of __kdba_getarea_size. Currently it returns 0 or a negative error code, now you are returning a positive value on an error. Why? Any failure to get a user page should return -EFAULT, the same as a kernel page. From kaos@sgi.com Wed Apr 16 06:11:37 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 06:11:44 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GDBYFu019989 for ; Wed, 16 Apr 2003 06:11:35 -0700 Received: (qmail 4872 invoked from network); 16 Apr 2003 13:11:32 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Apr 2003 13:11:32 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 74E60300087; Wed, 16 Apr 2003 23:11:30 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 65E4E19B; Wed, 16 Apr 2003 23:11:30 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: vamsi@in.ibm.com, kdb Subject: Re: [PATCH] access user space addresses/switch process context In-reply-to: Your message of "Wed, 16 Apr 2003 23:01:19 +1000." <28953.1050498079@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Apr 2003 23:11:25 +1000 Message-ID: <29493.1050498685@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 321 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Wed, 16 Apr 2003 23:01:19 +1000, Keith Owens wrote: >On Wed, 16 Apr 2003 17:31:33 +0530, >"Vamsi Krishna S ." wrote: >>diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/kdb/kdbsupport.c 2420-kdb4.1/kdb/kdbsupport.c >>--- 2420-kdb4.1-pure/kdb/kdbsupport.c 2003-04-16 11:38:14.000000000 +0530 >>+++ 2420-kdb4.1/kdb/kdbsupport.c 2003-04-16 12:56:42.000000000 +0530 >>+/* >>+ * from mm/memory.c, adapted to run without any locks to work within kdb >>+ */ >>+static struct page * kdb_follow_page(struct mm_struct *mm, unsigned long address, int write) > >AFAICT this function is identical to follow_page(). Instead of >duplicating that code and possibly getting out of sync with the real >follow_page(), change follow_page() so it is extern for CONFIG_KDB=y, >otherwise it is static. Sorry for the scattered mails, things are a bit hectic at the moment. Forget about making follow_page() extern. Instead add kdb_get_one_user_page to the end of mm/memory.c so it can access the private mm data and functions. Also kdb_getuserarea_size() needs to be exported, any module that does kdb_getarea() will end up with a call to kdb_getuserarea_size(). From vamsi@in.ibm.com Wed Apr 16 06:43:20 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 06:43:57 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GDhJFu020803 for ; Wed, 16 Apr 2003 06:43:20 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3GDhDuT102074; Wed, 16 Apr 2003 09:43:13 -0400 Received: from vamsiks.in.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3GDh6QS063282; Wed, 16 Apr 2003 07:43:09 -0600 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h3GE3Vt25749; Wed, 16 Apr 2003 19:33:31 +0530 Date: Wed, 16 Apr 2003 19:33:31 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: kdb Subject: Re: [PATCH] access user space addresses/switch process context Message-ID: <20030416193331.A25725@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <20030416173132.A25486@in.ibm.com> <28953.1050498079@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <28953.1050498079@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Wed, Apr 16, 2003 at 11:01:19PM +1000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 322 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Wed, Apr 16, 2003 at 11:01:19PM +1000, Keith Owens wrote: > On Wed, 16 Apr 2003 17:31:33 +0530, > "Vamsi Krishna S ." wrote: > >diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/kdb/kdbsupport.c 2420-kdb4.1/kdb/kdbsupport.c > >--- 2420-kdb4.1-pure/kdb/kdbsupport.c 2003-04-16 11:38:14.000000000 +0530 > >+++ 2420-kdb4.1/kdb/kdbsupport.c 2003-04-16 12:56:42.000000000 +0530 > >+/* > >+ * from mm/memory.c, adapted to run without any locks to work within kdb > >+ */ > >+static struct page * kdb_follow_page(struct mm_struct *mm, unsigned long address, int write) > > AFAICT this function is identical to follow_page(). Instead of > duplicating that code and possibly getting out of sync with the real > follow_page(), change follow_page() so it is extern for CONFIG_KDB=y, > otherwise it is static. > Yes, it is exactly the same as that in mm/memory.c. The reasons for copying it to kdb/kdbsupport.c were: - I thought you would like to not touch too many files. - some kernels have calls to BUG() in follow_page(), we may not want to BUG out when called from KDB. On second thoughts, these BUGs are very very unlikely to hit in practise and what is much more important is to keep it in sync with the mainline version.. I already spent a few hours debugging the panic that occured on United Linux kernel with this patch, before realising that UL kernel can keep page tables in high memory. So, yes, in my next patch, I will use the function from mm/memory.c and remove the copy from kdb/kdbsupport.c > >+static struct page * kdb_get_one_user_page(struct task_struct *tsk, unsigned long start, > >+ int len, int write) > > Why have a write flag? KDB will only read user pages, or are you > planning more changes that will require write access? > Yes, I wanted to add support for "mm" into user space addresses, if you are willing to accept the patch. I will now send out another patch which will use the write too. > >+ /* shouldn't cross a page boundary. temporary restriction. */ > >+ if ((from & PAGE_MASK) != ((from+size) & PAGE_MASK)) { > >+ kdb_printf("%s: crosses page boundary: from=%08lx, size=%d\n", > >+ __FUNCTION__, from, size); > >+ return size; > >+ } > > 'return size' changes the semantics of __kdba_getarea_size. Currently > it returns 0 or a negative error code, now you are returning a positive > value on an error. Why? Any failure to get a user page should return > -EFAULT, the same as a kernel page. > No. __kdba_getarea_size returns what it gets from __copy_from_user. __copy_from_user always returns the number of bytes that are still not copied (== size when you don't copy anything due to faults). Which is why you see at many places all over the kernel constructs like: if (copy_from_user(.. )) return -EFAULT; So, I think this is okay. I will send you an updated patch with - use follow_page() from mm/memory.c - support for "mm" to user pages - ia64 support too. Thanks, Vamsi. -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From vamsi@in.ibm.com Wed Apr 16 08:03:59 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 08:04:06 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GF3wFu021466 for ; Wed, 16 Apr 2003 08:03:58 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3GF3qft133576; Wed, 16 Apr 2003 11:03:52 -0400 Received: from vamsiks.in.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3GF3lQS127878; Wed, 16 Apr 2003 09:03:50 -0600 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h3GFODu25890; Wed, 16 Apr 2003 20:54:13 +0530 Date: Wed, 16 Apr 2003 20:54:13 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: kdb Subject: [PATCH-updated] access user space addresses/switch process context Message-ID: <20030416205413.A25851@in.ibm.com> Reply-To: vamsi@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 323 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb Hi, Here is the updated patch. Changes from the previous version: - implement kdb_follow_page in mm/memory.c itself to be able to use follow_page() directly. - support for writing into ("mm") user space addresses - export kdb_get[put]userarea_size so that kdb modules will be able to use kdb_get[put]word. - implement this for ia64 along with i386. Please apply. Thanks, Vamsi. -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com -- description from previous mail -- Here is a patch to implement a command to switch the current user process context whilst inside KDB to look at the stack, disassemble code, display memory etc. of different processes. Presently, KDB refuses to access user space addresses. A few developers requested for a way to access process memory and switch process contexts from within KDB. What it is required for are those occasions where the system is hung and there is no kernel panic. During hardware development it is not uncommon for test to just stop and the server to be hung. When this is caused by a process waiting for a resource to be freed, it is essential to be able to see who is holding the resource. Additionally, in a hang situation, the process that is causing the problem may not be the current process when you enter the debugger. This patch (against 2.4.20 + KDB v4.1) provides: - a way to switch the current process ("pid" command) - a way to look at user space registers of the current process ("rd u" command) - a way to access user space addresses in the context of a given process (normal md/mdr/id commands with user space addresses) Note that "bt" can be made to work unreliably in user contexts too, but I have left it out for now. -- diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/arch/i386/kdb/kdbasupport.c 2420-kdb4.1/arch/i386/kdb/kdbasupport.c --- 2420-kdb4.1-pure/arch/i386/kdb/kdbasupport.c 2003-04-16 18:00:58.000000000 +0530 +++ 2420-kdb4.1/arch/i386/kdb/kdbasupport.c 2003-04-16 18:02:14.000000000 +0530 @@ -723,7 +723,7 @@ /* User registers: %%e[a-c]x, etc */ regname++; regs = (struct pt_regs *) - (current->thread.esp0 - sizeof(struct pt_regs)); + (kdb_current_task->thread.esp0 - sizeof(struct pt_regs)); } for (i=0; ithread.esp0 - sizeof(struct pt_regs)); + (kdb_current_task->thread.esp0 - sizeof(struct pt_regs)); } for (i=0; ithread.esp0 - sizeof(struct pt_regs)); + (kdb_current_task->thread.esp0 - sizeof(struct pt_regs)); } if (type == NULL) { diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/arch/ia64/kdb/kdbasupport.c 2420-kdb4.1/arch/ia64/kdb/kdbasupport.c --- 2420-kdb4.1-pure/arch/ia64/kdb/kdbasupport.c 2003-04-16 18:01:01.000000000 +0530 +++ 2420-kdb4.1/arch/ia64/kdb/kdbasupport.c 2003-04-16 18:02:18.000000000 +0530 @@ -672,7 +672,7 @@ if (regname[0] == '%') { regname++; regs = (struct pt_regs *) - (current->thread.ksp - sizeof(struct pt_regs)); + (kdb_current_task->thread.ksp - sizeof(struct pt_regs)); } if (!regs) { @@ -779,7 +779,7 @@ && (type[0] == 'u')) { type = NULL; regs = (struct pt_regs *) - (current->thread.ksp - sizeof(struct pt_regs)); + (kdb_current_task->thread.ksp - sizeof(struct pt_regs)); } if (type == NULL) { diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/include/asm-i386/kdb.h 2420-kdb4.1/include/asm-i386/kdb.h --- 2420-kdb4.1-pure/include/asm-i386/kdb.h 2003-04-16 18:00:58.000000000 +0530 +++ 2420-kdb4.1/include/asm-i386/kdb.h 2003-04-16 19:06:49.000000000 +0530 @@ -78,6 +78,9 @@ #include +extern int kdb_getuserarea_size(void *, unsigned long, size_t); +extern int kdb_putuserarea_size(unsigned long, void *, size_t); + static inline int __kdba_putarea_size(unsigned long to_xxx, void *from, size_t size) { @@ -86,6 +89,11 @@ char c; c = *((volatile char *)from); c = *((volatile char *)from + size - 1); + + if (to_xxx < PAGE_OFFSET) { + return kdb_putuserarea_size(to_xxx, from, size); + } + set_fs(KERNEL_DS); r = __copy_to_user((void *)to_xxx, from, size); set_fs(oldfs); @@ -99,6 +107,11 @@ int r; *((volatile char *)to) = '\0'; *((volatile char *)to + size - 1) = '\0'; + + if (from_xxx < PAGE_OFFSET) { + return kdb_getuserarea_size(to, from_xxx, size); + } + set_fs(KERNEL_DS); switch (size) { case 1: diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/include/asm-i386/kmap_types.h 2420-kdb4.1/include/asm-i386/kmap_types.h --- 2420-kdb4.1-pure/include/asm-i386/kmap_types.h 2003-04-16 18:35:03.000000000 +0530 +++ 2420-kdb4.1/include/asm-i386/kmap_types.h 2003-04-16 18:34:32.000000000 +0530 @@ -8,6 +8,7 @@ KM_USER0, KM_USER1, KM_BH_IRQ, + KM_KDB, KM_TYPE_NR }; diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/include/asm-ia64/kdb.h 2420-kdb4.1/include/asm-ia64/kdb.h --- 2420-kdb4.1-pure/include/asm-ia64/kdb.h 2003-04-16 18:01:01.000000000 +0530 +++ 2420-kdb4.1/include/asm-ia64/kdb.h 2003-04-16 18:57:58.000000000 +0530 @@ -76,6 +76,9 @@ #include +extern int kdb_getuserarea_size(void *, unsigned long, size_t); +extern int kdb_putuserarea_size(void *, unsigned long, size_t); + static inline int __kdba_putarea_size(unsigned long to_xxx, void *from, size_t size) { @@ -84,6 +87,11 @@ char c; c = *((volatile char *)from); c = *((volatile char *)from + size - 1); + + if (to_xxx < PAGE_OFFSET) { + return kdb_putuserarea_size(to_xxx, from, size); + } + #ifdef VPERNODE_BASE /* if present, the new CONFIG_NUMA code */ if (to_xxx >= VPERNODE_BASE && to_xxx < VGLOBAL_BASE) { to_xxx = __imva(to_xxx); @@ -102,6 +110,11 @@ int r; *((volatile char *)to) = '\0'; *((volatile char *)to + size - 1) = '\0'; + + if (from_xxx < PAGE_OFFSET) { + return kdb_getuserarea_size(to, from_xxx, size); + } + set_fs(KERNEL_DS); switch (size) { case 1: diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/include/linux/kdb.h 2420-kdb4.1/include/linux/kdb.h --- 2420-kdb4.1-pure/include/linux/kdb.h 2003-04-16 18:00:50.000000000 +0530 +++ 2420-kdb4.1/include/linux/kdb.h 2003-04-16 19:07:42.000000000 +0530 @@ -333,4 +333,7 @@ #endif } +extern struct task_struct *kdb_current_task; +extern struct page * kdb_follow_page(struct mm_struct *, unsigned long, int); /* from mm/memory.c */ + #endif /* !_KDB_H */ diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/kdb/kdbmain.c 2420-kdb4.1/kdb/kdbmain.c --- 2420-kdb4.1-pure/kdb/kdbmain.c 2003-04-16 18:00:50.000000000 +0530 +++ 2420-kdb4.1/kdb/kdbmain.c 2003-04-16 18:27:44.000000000 +0530 @@ -76,6 +76,8 @@ volatile int kdb_state[NR_CPUS]; /* Per cpu state */ +struct task_struct *kdb_current_task; + #ifdef CONFIG_KDB_OFF int kdb_on = 0; /* Default is off */ #else @@ -1067,6 +1069,8 @@ kdba_local_arch_setup(); + kdb_current_task = current; + while (1) { /* * Initialize pager context. @@ -2781,6 +2785,59 @@ } /* + * kdb_pid + * + * This function implements the 'pid' command which switches + * the currently active process. + * + * pid [] + * + * Inputs: + * argc argument count + * argv argument vector + * envp environment vector + * regs registers at time kdb was entered. + * Outputs: + * None. + * Returns: + * zero for success, a kdb diagnostic if error + * Locking: + * none. + * Remarks: + */ + + +int +kdb_pid(int argc, const char **argv, const char **envp, struct pt_regs *regs) +{ + struct task_struct *p; + unsigned long val; + int diag; + + if (argc > 1) + return KDB_ARGCOUNT; + + if (argc) { + diag = kdbgetularg(argv[1], &val); + if (diag) + return KDB_BADINT; + + p = find_task_by_pid((pid_t)val); + if (!p) { + kdb_printf("No task with pid=%d\n", (pid_t)val); + return 0; + } + + kdb_current_task = p; + } + + kdb_printf("KDB current process is %s(pid=%d)\n", kdb_current_task->comm, + kdb_current_task->pid); + + return 0; +} + +/* * kdb_ll * * This function implements the 'll' command which follows a linked @@ -3245,6 +3302,7 @@ kdb_register_repeat("?", kdb_help, "", "Display Help Message", 0, KDB_REPEAT_NONE); kdb_register_repeat("cpu", kdb_cpu, "","Switch to new cpu", 0, KDB_REPEAT_NONE); kdb_register_repeat("ps", kdb_ps, "", "Display active task list", 0, KDB_REPEAT_NONE); + kdb_register_repeat("pid", kdb_pid, "", "Switch to another task", 0, KDB_REPEAT_NONE); kdb_register_repeat("reboot", kdb_reboot, "", "Reboot the machine immediately", 0, KDB_REPEAT_NONE); kdb_register_repeat("sections", kdb_sections, "", "List kernel and module sections", 0, KDB_REPEAT_NONE); #if defined(CONFIG_MODULES) @@ -3376,6 +3434,8 @@ EXPORT_SYMBOL(kdb_unregister); EXPORT_SYMBOL(kdb_getarea_size); EXPORT_SYMBOL(kdb_putarea_size); +EXPORT_SYMBOL(kdb_getuserarea_size); +EXPORT_SYMBOL(kdb_putuserarea_size); EXPORT_SYMBOL(kdb_getword); EXPORT_SYMBOL(kdb_putword); EXPORT_SYMBOL(kdbgetularg); diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/kdb/kdbsupport.c 2420-kdb4.1/kdb/kdbsupport.c --- 2420-kdb4.1-pure/kdb/kdbsupport.c 2003-04-16 18:00:50.000000000 +0530 +++ 2420-kdb4.1/kdb/kdbsupport.c 2003-04-16 19:11:44.000000000 +0530 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -800,3 +801,61 @@ else kdb_printf("0x%lx\n", val); } + +static struct page * kdb_get_one_user_page(struct task_struct *tsk, unsigned long start, + int len, int write) +{ + struct mm_struct *mm = tsk->mm; + unsigned int flags; + struct vm_area_struct * vma; + + /* shouldn't cross a page boundary. temporary restriction. */ + if ((start & PAGE_MASK) != ((start+len) & PAGE_MASK)) { + kdb_printf("%s: crosses page boundary: addr=%08lx, len=%d\n", + __FUNCTION__, start, len); + return NULL; + } + + start = PAGE_ALIGN(start); + flags = write ? (VM_WRITE | VM_MAYWRITE) : (VM_READ | VM_MAYREAD); + + vma = find_extend_vma(mm, start); + + /* may be we can allow access to VM_IO pages inside KDB? */ + if (!vma || (vma->vm_flags & VM_IO) || !(flags & vma->vm_flags)) + return NULL; + + return kdb_follow_page(mm, start, write); +} + +int kdb_getuserarea_size(void *to, unsigned long from, size_t size) +{ + struct page *page; + void * vaddr; + + page = kdb_get_one_user_page(kdb_current_task, from, size, 0); + if (!page) + return size; + + vaddr = kmap_atomic(page, KM_KDB); + memcpy(to, vaddr+ (from & (PAGE_SIZE - 1)), size); + kunmap_atomic(vaddr, KM_KDB); + + return 0; +} + +int kdb_putuserarea_size(unsigned long to, void *from, size_t size) +{ + struct page *page; + void * vaddr; + + page = kdb_get_one_user_page(kdb_current_task, to, size, 1); + if (!page) + return size; + + vaddr = kmap_atomic(page, KM_KDB); + memcpy(vaddr+ (to & (PAGE_SIZE - 1)), from, size); + kunmap_atomic(vaddr, KM_KDB); + + return 0; +} diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/mm/memory.c 2420-kdb4.1/mm/memory.c --- 2420-kdb4.1-pure/mm/memory.c 2003-04-16 18:23:53.000000000 +0530 +++ 2420-kdb4.1/mm/memory.c 2003-04-16 18:44:28.000000000 +0530 @@ -1494,3 +1494,15 @@ } return page; } + +#ifdef CONFIG_KDB +struct page * kdb_follow_page(struct mm_struct *mm, unsigned long address, int write) +{ + struct page *page = follow_page(mm, address, write); + + if (!page) + return get_page_map(page); + + return page; +} +#endif From vamsi@in.ibm.com Wed Apr 16 08:13:19 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 08:13:22 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GFDHFu021561 for ; Wed, 16 Apr 2003 08:13:18 -0700 Received: from e35.co.us.ibm.com (e35.esmtp.ibm.com [9.14.4.133]) by pokfb.esmtp.ibm.com (8.12.9/8.12.2) with ESMTP id h3GDvev2062710 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Wed, 16 Apr 2003 09:57:40 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3GDlEuT103852; Wed, 16 Apr 2003 09:47:14 -0400 Received: from vamsiks.in.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3GDl9QS153750; Wed, 16 Apr 2003 07:47:12 -0600 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h3GE7Zr25756; Wed, 16 Apr 2003 19:37:35 +0530 Date: Wed, 16 Apr 2003 19:37:35 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: kdb Subject: Re: [PATCH] access user space addresses/switch process context Message-ID: <20030416193735.B25725@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <28953.1050498079@ocs3.intra.ocs.com.au> <29493.1050498685@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <29493.1050498685@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Wed, Apr 16, 2003 at 11:11:25PM +1000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 324 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Wed, Apr 16, 2003 at 11:11:25PM +1000, Keith Owens wrote: > On Wed, 16 Apr 2003 23:01:19 +1000, > Keith Owens wrote: > >On Wed, 16 Apr 2003 17:31:33 +0530, > >"Vamsi Krishna S ." wrote: > >>diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/kdb/kdbsupport.c 2420-kdb4.1/kdb/kdbsupport.c > >>--- 2420-kdb4.1-pure/kdb/kdbsupport.c 2003-04-16 11:38:14.000000000 +0530 > >>+++ 2420-kdb4.1/kdb/kdbsupport.c 2003-04-16 12:56:42.000000000 +0530 > >>+/* > >>+ * from mm/memory.c, adapted to run without any locks to work within kdb > >>+ */ > >>+static struct page * kdb_follow_page(struct mm_struct *mm, unsigned long address, int write) > > > >AFAICT this function is identical to follow_page(). Instead of > >duplicating that code and possibly getting out of sync with the real > >follow_page(), change follow_page() so it is extern for CONFIG_KDB=y, > >otherwise it is static. > > Sorry for the scattered mails, things are a bit hectic at the moment. > No problems. Thanks for taking the time to look into it :-) > Forget about making follow_page() extern. Instead add > kdb_get_one_user_page to the end of mm/memory.c so it can access the > private mm data and functions. > Ok.. will do. > Also kdb_getuserarea_size() needs to be exported, any module that does > kdb_getarea() will end up with a call to kdb_getuserarea_size(). > Right. I will export it. -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From eddie.dong@intel.com Wed Apr 16 17:51:39 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 17:51:47 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3H0pcFu004921 for ; Wed, 16 Apr 2003 17:51:39 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h3H0nXq10192 for ; Thu, 17 Apr 2003 00:49:33 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h3H0lSI22541 for ; Thu, 17 Apr 2003 00:47:28 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003041708513027954 ; Thu, 17 Apr 2003 08:51:30 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Apr 2003 08:51:31 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] access user space addresses/switch process context Date: Thu, 17 Apr 2003 08:51:30 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E6E583C@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] access user space addresses/switch process context Thread-Index: AcMEKwpWL8+NgeywTpywmaL6ijP58QAT+k5w From: "Dong, Eddie" To: Cc: "kdb" X-OriginalArrivalTime: 17 Apr 2003 00:51:31.0290 (UTC) FILETIME=[7C822BA0:01C3047B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id h3H0pcFu004921 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 325 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: eddie.dong@intel.com Precedence: bulk X-list: kdb Do you have any interests in applying this feature to XScale architecture? The xscale patch is under KDB4.0 folder. > -----Original Message----- > From: Vamsi Krishna S . [mailto:vamsi@in.ibm.com] > Sent: 2003年4月16日 22:08 > To: Keith Owens > Cc: kdb > Subject: Re: [PATCH] access user space addresses/switch > process context > > > On Wed, Apr 16, 2003 at 11:11:25PM +1000, Keith Owens wrote: > > On Wed, 16 Apr 2003 23:01:19 +1000, > > Keith Owens wrote: > > >On Wed, 16 Apr 2003 17:31:33 +0530, > > >"Vamsi Krishna S ." wrote: > > >>diff -urN -X /home/vamsi/.dontdiff > 2420-kdb4.1-pure/kdb/kdbsupport.c 2420-kdb4.1/kdb/kdbsupport.c > > >>--- 2420-kdb4.1-pure/kdb/kdbsupport.c 2003-04-16 > 11:38:14.000000000 +0530 > > >>+++ 2420-kdb4.1/kdb/kdbsupport.c 2003-04-16 > 12:56:42.000000000 +0530 > > >>+/* > > >>+ * from mm/memory.c, adapted to run without any locks to > work within kdb > > >>+ */ > > >>+static struct page * kdb_follow_page(struct mm_struct > *mm, unsigned long address, int write) > > > > > >AFAICT this function is identical to follow_page(). Instead of > > >duplicating that code and possibly getting out of sync > with the real > > >follow_page(), change follow_page() so it is extern for > CONFIG_KDB=y, > > >otherwise it is static. > > > > Sorry for the scattered mails, things are a bit hectic at > the moment. > > > No problems. Thanks for taking the time to look into it :-) > > > Forget about making follow_page() extern. Instead add > > kdb_get_one_user_page to the end of mm/memory.c so it can access the > > private mm data and functions. > > > Ok.. will do. > > > Also kdb_getuserarea_size() needs to be exported, any > module that does > > kdb_getarea() will end up with a call to kdb_getuserarea_size(). > > > Right. I will export it. > > -- > Vamsi Krishna S. > Linux Technology Center, > IBM Software Lab, Bangalore. > Ph: +91 80 5044959 > Internet: vamsi@in.ibm.com > > From ginaisha@swbell.net Wed Apr 16 14:43:22 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 19:18:40 -0700 (PDT) Received: from localhost [127.0.0.1] by oss.sgi.com with SpamAssassin (2.50 1.173-2003-02-20-exp); Wed, 16 Apr 2003 14:43:57 -0700 From: Gina and Steve Williamson To: kdb@oss.sgi.com Subject: Saving KDB Session Dump Date: Tue, 15 Apr 2003 22:13:04 -0500 Message-Id: <001401c303c6$190a01c0$0200a8c0@ginacasa> X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.50 1.173-2003-02-20-exp MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_3E9DCE9D.B453720D" X-archive-position: 326 X-Approved-By: kaos@sgi.com X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: ginaisha@swbell.net Precedence: bulk X-list: kdb This is a multi-part message in MIME format. ------------=_3E9DCE9D.B453720D Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit This mail is probably spam. The original message has been attached along with this report, so you can recognize or block similar unwanted mail in future. See http://spamassassin.org/tag/ for more details. Content preview: Hi. I am new to kernel debugging in Linux. I have KDB setup and running on the system that I am debugging. I am trying to save the output of the debug session to a text file (register dumps, unassemble data, single step data), but have been challenged in determing how to do this. Any help would be appreciated. [...] Content analysis details: (5.70 points, 5 required) HTML_30_40 (0.8 points) BODY: Message is 30% to 40% HTML HTML_MESSAGE (3.0 points) BODY: HTML included in message DATE_IN_PAST_12_24 (0.2 points) Date: is 12 to 24 hours before Received: date RCVD_IN_MULTIHOP_DSBL (1.0 points) RBL: Received via a relay in multihop.dsbl.org [RBL check: found 240.28.13.206.multihop.dsbl.org.] RCVD_IN_UNCONFIRMED_DSBL (0.7 points) RBL: Received via a relay in unconfirmed.dsbl.org [RBL check: found 240.28.13.206.unconfirmed.dsbl.org.] The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. ------------=_3E9DCE9D.B453720D Content-Type: message/rfc822 Content-Description: original message before SpamAssassin Content-Disposition: attachment Content-Transfer-Encoding: 8bit Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3GLhMFu031844 for ; Wed, 16 Apr 2003 14:43:22 -0700 Received: from ginacasa ([64.123.205.159]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HDF0081S29RM4@mta6.snfc21.pbi.net> for kdb@oss.sgi.com; Tue, 15 Apr 2003 20:13:04 -0700 (PDT) Date: Tue, 15 Apr 2003 22:13:04 -0500 From: Gina and Steve Williamson Subject: Saving KDB Session Dump To: kdb@oss.sgi.com Message-id: <001401c303c6$190a01c0$0200a8c0@ginacasa> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: multipart/alternative; boundary="----=_NextPart_000_0015_01C3039C.3033F9C0" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C3039C.3033F9C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi. I am new to kernel debugging in Linux. I have KDB setup and running on the system that I am debugging. I am trying to save the output of the debug session to a text file (register dumps, unassemble data, single step data), but have been challenged in determing how to do this. Any help would be appreciated. Thanks in advance, Steve Williamson ------=_NextPart_000_0015_01C3039C.3033F9C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Saving KDB Session Dump

Hi.

I am new to kernel debugging in = Linux.  I have KDB setup and running on the system that I am = debugging.  I am trying to save the output of the debug session to = a text file (register dumps, unassemble data, single step data), but = have been challenged in determing how to do this.  Any help would = be appreciated.

Thanks in advance,
Steve Williamson

------=_NextPart_000_0015_01C3039C.3033F9C0-- ------------=_3E9DCE9D.B453720D-- From kaos@sgi.com Wed Apr 16 19:38:13 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 19:38:23 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3H2cAFu006125 for ; Wed, 16 Apr 2003 19:38:13 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h3H2c3E0027735 for ; Wed, 16 Apr 2003 19:38:04 -0700 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA21511; Thu, 17 Apr 2003 12:36:43 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 9C5553000B8; Thu, 17 Apr 2003 12:15:38 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 4212419B; Thu, 17 Apr 2003 12:15:38 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: vamsi@in.ibm.com Cc: kdb Subject: Re: [PATCH-updated] access user space addresses/switch process context In-reply-to: Your message of "Wed, 16 Apr 2003 20:54:13 +0530." <20030416205413.A25851@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 2003 12:15:32 +1000 Message-ID: <5225.1050545732@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 327 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Wed, 16 Apr 2003 20:54:13 +0530, "Vamsi Krishna S ." wrote: >Here is the updated patch. Changes from the previous version: >- implement kdb_follow_page in mm/memory.c itself to be able to > use follow_page() directly. >- support for writing into ("mm") user space addresses >- export kdb_get[put]userarea_size so that kdb modules will > be able to use kdb_get[put]word. >- implement this for ia64 along with i386. On ia64, PAGE_OFFSET is 0xe000000000000000, testing against that excludes I/O space (0xc) and modules/vmalloc (0xa). The correct test for user regions on ia64 is if (address >> 61 <= 4) Applied to my tree with that correction. To be released as kdb v4.2 next week, after we finish moving offices :( From eddie.dong@intel.com Wed Apr 16 19:44:28 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 19:44:31 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3H2iSFu006168 for ; Wed, 16 Apr 2003 19:44:28 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h3H2gNq27250 for ; Thu, 17 Apr 2003 02:42:23 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h3H2eHa14182 for ; Thu, 17 Apr 2003 02:40:18 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003041710442027841 ; Thu, 17 Apr 2003 10:44:20 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Apr 2003 10:44:21 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Saving KDB Session Dump Date: Thu, 17 Apr 2003 10:44:20 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E6E58C5@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Saving KDB Session Dump Thread-Index: AcMEh/YbqZvl1Sc9SHCB+dF6ygQZewAAxGVA From: "Dong, Eddie" To: "Gina and Steve Williamson" Cc: X-OriginalArrivalTime: 17 Apr 2003 02:44:21.0353 (UTC) FILETIME=[3FC7CD90:01C3048B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h3H2iSFu006168 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 328 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: eddie.dong@intel.com Precedence: bulk X-list: kdb If you use the windows hyperterminal as ttyS0 console input/output, you can save all the intermediate results locally. -----Original Message----- From: Gina and Steve Williamson [mailto:ginaisha@swbell.net] Sent: 2003Äê4ÔÂ16ÈÕ 11:13 To: kdb@oss.sgi.com Subject: Saving KDB Session Dump Hi. I am new to kernel debugging in Linux. I have KDB setup and running on the system that I am debugging. I am trying to save the output of the debug session to a text file (register dumps, unassemble data, single step data), but have been challenged in determing how to do this. Any help would be appreciated. Thanks in advance, Steve Williamson From kaos@sgi.com Wed Apr 16 20:10:24 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 20:10:36 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3H3AOFu006324 for ; Wed, 16 Apr 2003 20:10:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h3H3NKVe003799 for ; Wed, 16 Apr 2003 22:23:21 -0500 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01011; Thu, 17 Apr 2003 13:09:01 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 8C61E3000B8; Thu, 17 Apr 2003 13:09:00 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 27BDF19B; Thu, 17 Apr 2003 13:08:59 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Gina and Steve Williamson Cc: kdb@oss.sgi.com Subject: Re: Saving KDB Session Dump In-reply-to: Your message of "Tue, 15 Apr 2003 22:13:04 EST." <001401c303c6$190a01c0$0200a8c0@ginacasa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 2003 13:08:54 +1000 Message-ID: <5664.1050548934@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 329 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Tue, 15 Apr 2003 22:13:04 -0500, Gina and Steve Williamson wrote: >This is a multi-part message in MIME format. Please use plain text. The HTML you sent looked like spam. >I am new to kernel debugging in Linux. I have KDB setup and running on >the system that I am debugging. I am trying to save the output of the >debug session to a text file (register dumps, unassemble data, single >step data), but have been challenged in determing how to do this. Any >help would be appreciated. If the system is still usable when you type 'go' and the amount of data is smaller than the kernel log buffer then set LOGGING=1. The data will be written to the kernel log and then to syslog after you type 'go'. In most cases, a debug session has no working I/O so the kernel log is not written to disk and is lost. Then you have to use a serial console (Documentation/serial-console.txt), debug over the serial line and capture the output on a second machine. From vamsi@in.ibm.com Wed Apr 16 22:18:47 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 22:18:53 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3H5IkFu009700 for ; Wed, 16 Apr 2003 22:18:47 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3H5Gnve024426; Thu, 17 Apr 2003 01:16:49 -0400 Received: from vamsiks.in.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3H5IYYt081866; Wed, 16 Apr 2003 23:18:37 -0600 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h3H5d0q27163; Thu, 17 Apr 2003 11:09:00 +0530 Date: Thu, 17 Apr 2003 11:09:00 +0530 From: "Vamsi Krishna S ." To: "Dong, Eddie" Cc: kdb Subject: Re: [PATCH] access user space addresses/switch process context Message-ID: <20030417110900.A27153@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <37FBBA5F3A361C41AB7CE44558C3448E6E583C@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <37FBBA5F3A361C41AB7CE44558C3448E6E583C@pdsmsx403.ccr.corp.intel.com>; from eddie.dong@intel.com on Thu, Apr 17, 2003 at 08:51:30AM +0800 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 330 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Thu, Apr 17, 2003 at 08:51:30AM +0800, Dong, Eddie wrote: > Do you have any interests in applying this feature to XScale architecture? > The xscale patch is under KDB4.0 folder. > Sure.. here it is. I think (addr < PAGE_OFFSET) is the correct test to determine user space addresses in arm arch too. Please verify this. This patch should be applied on top of my earlier patch + kdb 4.0 xscale. Thanks, Vamsi. -- Vamsi Krishna S. IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com -- diff -urN -X /home/vamsi/.dontdiff 2420-kdb4.1-pure/arch/arm/kdb/kdbasupport.c 2420-kdb4.1/arch/arm/kdb/kdbasupport.c --- 2420-kdb4.1-pure/arch/arm/kdb/kdbasupport.c 2003-04-17 09:39:34.000000000 +0530 +++ 2420-kdb4.1/arch/arm/kdb/kdbasupport.c 2003-04-17 09:39:25.000000000 +0530 @@ -694,9 +694,9 @@ && (type[0] == 'u')) { struct context_save_struct *pSave; type = NULL; - pSave = current->thread.save; + pSave = kdb_current_task->thread.save; if ( !pSave ) { - kdb_printf("Uninitialized current->thread.save!!!\n"); + kdb_printf("Uninitialized current->thread.save (pid=%d)!!!\n", kdb_current_task->pid); return 0; } for (i=0; i +extern int kdb_getuserarea_size(void *, unsigned long, size_t); +extern int kdb_putuserarea_size(unsigned long, void *, size_t); + static inline int __kdba_putarea_size(unsigned long to_xxx, void *from, size_t size) { @@ -92,6 +95,11 @@ char c; c = *((volatile char *)from); c = *((volatile char *)from + size - 1); + + if (to_xxx < PAGE_OFFSET) { + return kdb_putuserarea_size(to_xxx, from, size); + } + #ifdef VPERNODE_BASE /* if present, the new CONFIG_NUMA code */ if (to_xxx >= VPERNODE_BASE && to_xxx < VGLOBAL_BASE) { to_xxx = __imva(to_xxx); @@ -110,6 +118,11 @@ int r; *((volatile char *)to) = '\0'; *((volatile char *)to + size - 1) = '\0'; + + if (from_xxx < PAGE_OFFSET) { + return kdb_getuserarea_size(to, from_xxx, size); + } + set_fs(KERNEL_DS); switch (size) { case 1: From vamsi@in.ibm.com Wed Apr 16 22:20:48 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 22:20:51 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3H5KmFu009719 for ; Wed, 16 Apr 2003 22:20:48 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3H5JFQs119804; Thu, 17 Apr 2003 01:19:15 -0400 Received: from vamsiks.in.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3H5KZYt080014; Wed, 16 Apr 2003 23:20:39 -0600 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h3H5f2s27169; Thu, 17 Apr 2003 11:11:02 +0530 Date: Thu, 17 Apr 2003 11:11:02 +0530 From: "Vamsi Krishna S ." To: Keith Owens Cc: kdb Subject: Re: [PATCH-updated] access user space addresses/switch process context Message-ID: <20030417111102.B27153@in.ibm.com> Reply-To: vamsi@in.ibm.com References: <20030416205413.A25851@in.ibm.com> <5225.1050545732@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5225.1050545732@kao2.melbourne.sgi.com>; from kaos@sgi.com on Thu, Apr 17, 2003 at 12:15:32PM +1000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 331 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Thu, Apr 17, 2003 at 12:15:32PM +1000, Keith Owens wrote: > On Wed, 16 Apr 2003 20:54:13 +0530, > "Vamsi Krishna S ." wrote: > >Here is the updated patch. Changes from the previous version: > >- implement kdb_follow_page in mm/memory.c itself to be able to > > use follow_page() directly. > >- support for writing into ("mm") user space addresses > >- export kdb_get[put]userarea_size so that kdb modules will > > be able to use kdb_get[put]word. > >- implement this for ia64 along with i386. > > On ia64, PAGE_OFFSET is 0xe000000000000000, testing against that > excludes I/O space (0xc) and modules/vmalloc (0xa). The correct test > for user regions on ia64 is > > if (address >> 61 <= 4) > > Applied to my tree with that correction. To be released as kdb v4.2 > next week, after we finish moving offices :( > > I wasn't quite cetain about that test's correctness on ia64. Thanks very much for correcting it. Regards, Vamsi. -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From eddie.dong@intel.com Wed Apr 16 22:48:40 2003 Received: with ECARTIS (v1.0.0; list kdb); Wed, 16 Apr 2003 22:48:43 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3H5mdFu010168 for ; Wed, 16 Apr 2003 22:48:40 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h3H5kYq12097 for ; Thu, 17 Apr 2003 05:46:34 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h3H5iTa02395 for ; Thu, 17 Apr 2003 05:44:29 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003041713483104201 ; Thu, 17 Apr 2003 13:48:31 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Apr 2003 13:48:32 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] access user space addresses/switch process context Date: Thu, 17 Apr 2003 13:48:31 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E6E594C@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] access user space addresses/switch process context Thread-Index: AcMEoOfpYcRo6JSNTcm0kWM4P/YVbAAA8BWw From: "Dong, Eddie" To: Cc: "kdb" X-OriginalArrivalTime: 17 Apr 2003 05:48:32.0282 (UTC) FILETIME=[FAA5BFA0:01C304A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id h3H5mdFu010168 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 332 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: eddie.dong@intel.com Precedence: bulk X-list: kdb Will integrate it to xscale patch after Keith releases KDB4.2 thanks. > -----Original Message----- > From: Vamsi Krishna S . [mailto:vamsi@in.ibm.com] > Sent: 2003å¹´4月17æ—¥ 13:39 > To: Dong, Eddie > Cc: kdb > Subject: Re: [PATCH] access user space addresses/switch > process context > > > On Thu, Apr 17, 2003 at 08:51:30AM +0800, Dong, Eddie wrote: > > Do you have any interests in applying this feature to > XScale architecture? > > The xscale patch is under KDB4.0 folder. > > > Sure.. here it is. I think (addr < PAGE_OFFSET) is the correct test > to determine user space addresses in arm arch too. Please verify > this. > > This patch should be applied on top of my earlier patch + kdb > 4.0 xscale. > > Thanks, > Vamsi. > -- > Vamsi Krishna S. > IBM Software Lab, Bangalore. > Ph: +91 80 5044959 > Internet: vamsi@in.ibm.com > -- > diff -urN -X /home/vamsi/.dontdiff > 2420-kdb4.1-pure/arch/arm/kdb/kdbasupport.c > 2420-kdb4.1/arch/arm/kdb/kdbasupport.c > --- 2420-kdb4.1-pure/arch/arm/kdb/kdbasupport.c > 2003-04-17 09:39:34.000000000 +0530 > +++ 2420-kdb4.1/arch/arm/kdb/kdbasupport.c 2003-04-17 > 09:39:25.000000000 +0530 > @@ -694,9 +694,9 @@ > && (type[0] == 'u')) { > struct context_save_struct *pSave; > type = NULL; > - pSave = current->thread.save; > + pSave = kdb_current_task->thread.save; > if ( !pSave ) { > - kdb_printf("Uninitialized > current->thread.save!!!\n"); > + kdb_printf("Uninitialized > current->thread.save (pid=%d)!!!\n", kdb_current_task->pid); > return 0; > } > for (i=0; i diff -urN -X /home/vamsi/.dontdiff > 2420-kdb4.1-pure/include/asm-arm/kdb.h > 2420-kdb4.1/include/asm-arm/kdb.h > --- 2420-kdb4.1-pure/include/asm-arm/kdb.h 2003-04-17 > 09:37:53.000000000 +0530 > +++ 2420-kdb4.1/include/asm-arm/kdb.h 2003-04-17 > 09:38:08.000000000 +0530 > @@ -84,6 +84,9 @@ > > #include > > +extern int kdb_getuserarea_size(void *, unsigned long, size_t); > +extern int kdb_putuserarea_size(unsigned long, void *, size_t); > + > static inline int > __kdba_putarea_size(unsigned long to_xxx, void *from, size_t size) > { > @@ -92,6 +95,11 @@ > char c; > c = *((volatile char *)from); > c = *((volatile char *)from + size - 1); > + > + if (to_xxx < PAGE_OFFSET) { > + return kdb_putuserarea_size(to_xxx, from, size); > + } > + > #ifdef VPERNODE_BASE /* if present, the new CONFIG_NUMA code */ > if (to_xxx >= VPERNODE_BASE && to_xxx < VGLOBAL_BASE) { > to_xxx = __imva(to_xxx); > @@ -110,6 +118,11 @@ > int r; > *((volatile char *)to) = '\0'; > *((volatile char *)to + size - 1) = '\0'; > + > + if (from_xxx < PAGE_OFFSET) { > + return kdb_getuserarea_size(to, from_xxx, size); > + } > + > set_fs(KERNEL_DS); > switch (size) { > case 1: > From damon.fleury@voxpath.com Fri Apr 18 03:24:51 2003 Received: with ECARTIS (v1.0.0; list kdb); Fri, 18 Apr 2003 03:24:59 -0700 (PDT) Received: from MAILSERVER.voxpath.com ([216.85.31.67]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3IAOpFu010270 for ; Fri, 18 Apr 2003 03:24:51 -0700 Received: by mailserver.voxpath.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Apr 2003 05:24:46 -0500 Message-ID: <5A670681489CBD43B17A6ABCB8AEC4315E1A0B@mailserver.voxpath.com> From: Damon Fleury To: "'kdb@oss.sgi.com'" Subject: ARM support? Date: Fri, 18 Apr 2003 05:24:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 333 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: damon.fleury@voxpath.com Precedence: bulk X-list: kdb Does anyone know whether KDB has been ported to an ARM-based processor? I'm specifically looking for XScale support. Thanks in advance, Damon Damon Fleury Voxpath Networks, Inc. (512)615-3928 From damon.fleury@voxpath.com Fri Apr 18 03:36:15 2003 Received: with ECARTIS (v1.0.0; list kdb); Fri, 18 Apr 2003 03:36:21 -0700 (PDT) Received: from MAILSERVER.voxpath.com ([216.85.31.67]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3IAaEFu010335 for ; Fri, 18 Apr 2003 03:36:14 -0700 Received: by mailserver.voxpath.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Apr 2003 05:36:05 -0500 Message-ID: <5A670681489CBD43B17A6ABCB8AEC4315E1A0D@mailserver.voxpath.com> From: Damon Fleury To: "'kdb@oss.sgi.com'" Subject: RE: ARM support? Date: Fri, 18 Apr 2003 05:36:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 334 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: damon.fleury@voxpath.com Precedence: bulk X-list: kdb Finally came across it. Sorry to bother... In case anyone else is interested: ftp://oss.sgi.com/projects/kdb/download/v4.0/kdb-v4.0-2.4.19-xscale-0.2.bz2 -----Original Message----- From: Damon Fleury [mailto:damon.fleury@voxpath.com] Sent: Friday, April 18, 2003 5:25 AM To: 'kdb@oss.sgi.com' Subject: ARM support? Does anyone know whether KDB has been ported to an ARM-based processor? I'm specifically looking for XScale support. Thanks in advance, Damon Damon Fleury Voxpath Networks, Inc. (512)615-3928 From thomas.mey@web.de Sat Apr 19 07:28:17 2003 Received: with ECARTIS (v1.0.0; list kdb); Sat, 19 Apr 2003 07:28:23 -0700 (PDT) Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3JESFFu001862 for ; Sat, 19 Apr 2003 07:28:17 -0700 Received: from dialin-145-254-205-096.arcor-ip.net ([145.254.205.96] helo=web.de) by smtp.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE(Exim) 4.97 #53) id 196tK5-0002Rb-00 for kdb@oss.sgi.com; Sat, 19 Apr 2003 16:28:09 +0200 Message-ID: <3EA15CF5.5090905@web.de> Date: Sat, 19 Apr 2003 16:28:05 +0200 From: Thomas Meyer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kdb@oss.sgi.com Subject: USB keyboard support - kdb v4.1 - i386 - 2.4.20 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 335 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: thomas.mey@web.de Precedence: bulk X-list: kdb Hello, USB keyboard support in kdb v4.1 doesn´t compile. compile process ends in error: kdba_io.c: In function `get_usb_char': kdba_io.c:93: `urb_t' undeclared (first use in this function) kdba_io.c:93: (Each undeclared identifier is reported only once kdba_io.c:93: for each function it appears in.) kdba_io.c:93: parse error before `)' make[2]: *** [kdba_io.o] Error 1 make[1]: *** [first_rule] Error 2 make: *** [_dir_arch/i386/kdb] Error 2 Has someone ever did some testing in this version ? pleas fix in next release ... with kind regards thomas From kaos@sgi.com Sat Apr 19 16:54:20 2003 Received: with ECARTIS (v1.0.0; list kdb); Sat, 19 Apr 2003 16:54:23 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3JNsGFu007264 for ; Sat, 19 Apr 2003 16:54:18 -0700 Received: (qmail 20132 invoked from network); 19 Apr 2003 23:54:14 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Apr 2003 23:54:14 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 7268B300087; Sun, 20 Apr 2003 09:54:12 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 59DAF19B; Sun, 20 Apr 2003 09:54:12 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Thomas Meyer Cc: kdb@oss.sgi.com Subject: Re: USB keyboard support - kdb v4.1 - i386 - 2.4.20 In-reply-to: Your message of "Sat, 19 Apr 2003 16:28:05 +0200." <3EA15CF5.5090905@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 09:54:07 +1000 Message-ID: <4953.1050796447@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 336 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Sat, 19 Apr 2003 16:28:05 +0200, Thomas Meyer wrote: >USB keyboard support in kdb v4.1 doesn4t compile. compile process ends >in error: I do not have access to USB keyboards and have asked several times for somebody to volunteer to fix the USB support in kdb, but nobody has done it. I am going to drop USB keyboard support in kdb v4.2. From eddie.dong@intel.com Mon Apr 21 00:44:37 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 00:44:46 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3L7iaFu032145 for ; Mon, 21 Apr 2003 00:44:36 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h3L7dkp26529 for ; Mon, 21 Apr 2003 07:39:46 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h3L7HO627741 for ; Mon, 21 Apr 2003 07:17:24 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003042115442824623 ; Mon, 21 Apr 2003 15:44:28 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Apr 2003 15:44:28 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: ARM support? X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 21 Apr 2003 15:44:28 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E087BC6@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARM support? Thread-Index: AcMFlqP/49zcVpDsR8eJ8wn7BaaQ4gCQquPQ From: "Dong, Eddie" To: "Damon Fleury" Cc: X-OriginalArrivalTime: 21 Apr 2003 07:44:28.0726 (UTC) FILETIME=[D6A9DD60:01C307D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id h3L7iaFu032145 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 337 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: eddie.dong@intel.com Precedence: bulk X-list: kdb If you are using cross compiler, kallsyms may need to be changed in source to let IA32 host tool support ARM little endian object parsing, native compiler has no such problem. > -----Original Message----- > From: Damon Fleury [mailto:damon.fleury@voxpath.com] > Sent: 2003å¹´4月18æ—¥ 18:36 > To: kdb@oss.sgi.com > Subject: RE: ARM support? > > > Finally came across it. Sorry to bother... > > In case anyone else is interested: > ftp://oss.sgi.com/projects/kdb/download/v4.0/kdb-v4.0-2.4.19-x > scale-0.2.bz2 > > -----Original Message----- > From: Damon Fleury [mailto:damon.fleury@voxpath.com] > Sent: Friday, April 18, 2003 5:25 AM > To: 'kdb@oss.sgi.com' > Subject: ARM support? > > > Does anyone know whether KDB has been ported to an ARM-based > processor? I'm > specifically looking for XScale support. > > Thanks in advance, > Damon > > Damon Fleury > Voxpath Networks, Inc. > (512)615-3928 > > From mrinal@vxindia.veritas.com Mon Apr 21 02:22:59 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 02:23:06 -0700 (PDT) Received: from mtvmime02.veritas.com (bay-bridge.veritas.com [143.127.3.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3L9MwFu002193 for ; Mon, 21 Apr 2003 02:22:59 -0700 Received: from vxindia.veritas.com (unverified) by mtvmime02.veritas.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Mon , 21 Apr 2003 02:24:30 -0700 Received: from localhost (mrinal@localhost) by vxindia.veritas.com (8.11.6+Sun/8.9.3) with ESMTP id h3L9MoM06722; Mon, 21 Apr 2003 14:52:50 +0530 (IST) Date: Mon, 21 Apr 2003 14:52:50 +0530 (IST) From: Mrinal Shanker X-X-Sender: mrinal@revati To: KDB Subject: need patch for rh adv. serv Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 338 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: mrinal@vxindia.veritas.com Precedence: bulk X-list: kdb Hi, I was looking out for a kdb patch for my rh adv. server kernel, i.e 2.4.9-e3 or even for 2.4.7-10. Is it possible for me to patch these kernels with ftp://oss.sgi.com/www/projects/kdb/download/v4.1/kdb-v4.1-2.4.19-common-1.bz2 or does this work only with 2.4.19...?? Thanks in advance. Regards, Mrinal From kaos@sgi.com Mon Apr 21 03:44:35 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 03:44:44 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3LAiWFu004614 for ; Mon, 21 Apr 2003 03:44:34 -0700 Received: (qmail 10967 invoked from network); 21 Apr 2003 10:44:30 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 21 Apr 2003 10:44:30 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 1DB3A3000B8; Mon, 21 Apr 2003 20:11:49 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id BCE63266; Mon, 21 Apr 2003 20:11:49 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Mrinal Shanker Cc: KDB Subject: Re: need patch for rh adv. serv In-reply-to: Your message of "Mon, 21 Apr 2003 14:52:50 +0530." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Apr 2003 20:11:44 +1000 Message-ID: <20473.1050919904@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 339 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Mon, 21 Apr 2003 14:52:50 +0530 (IST), Mrinal Shanker wrote: >I was looking out for a kdb patch for my rh adv. server >kernel, i.e 2.4.9-e3 or even for 2.4.7-10. > >Is it possible for me to patch these kernels with >ftp://oss.sgi.com/www/projects/kdb/download/v4.1/kdb-v4.1-2.4.19-common-1.bz2 kdb patches are only against standard kernels, not against distributions. If you want to use a distributor's kernel, you have to ask that distributor for help. From thomas.mey@web.de Mon Apr 21 04:12:31 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 04:13:13 -0700 (PDT) Received: from smtp.web.de (smtp01.web.de [217.72.192.180]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3LBCTFu005149 for ; Mon, 21 Apr 2003 04:12:30 -0700 Received: from dialin-145-254-207-183.arcor-ip.net ([145.254.207.183] helo=web.de) by smtp.web.de with asmtp (WEB.DE(Exim) 4.97 #53) id 197ZDk-0001qe-00 for kdb@oss.sgi.com; Mon, 21 Apr 2003 13:12:24 +0200 Message-ID: <3EA3D21E.6050302@web.de> Date: Mon, 21 Apr 2003 13:12:30 +0200 From: Thomas Meyer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kdb@oss.sgi.com Subject: kdb 4.1 - compile error - 2.4.20 UP kernel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 340 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: thomas.mey@web.de Precedence: bulk X-list: kdb Hello. another thing i noticed with kdb 4.1 - kernel 2.4.20. when you want to compile a kernel with no smp support then the compile ends abnormaly. with kind regards Thomas Meyer From mrinal@vxindia.veritas.com Mon Apr 21 04:25:54 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 04:26:01 -0700 (PDT) Received: from mtvmime02.veritas.com (bay-bridge.veritas.com [143.127.3.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3LBPsFu005293 for ; Mon, 21 Apr 2003 04:25:54 -0700 Received: from vxindia.veritas.com (unverified) by mtvmime02.veritas.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Mon, 21 Apr 2003 04:27:26 -0700 Received: from localhost (mrinal@localhost) by vxindia.veritas.com (8.11.6+Sun/8.9.3) with ESMTP id h3LBPjm03469; Mon, 21 Apr 2003 16:55:45 +0530 (IST) Date: Mon, 21 Apr 2003 16:55:45 +0530 (IST) From: Mrinal Shanker X-X-Sender: mrinal@revati To: Keith Owens cc: KDB Subject: Re: need patch for rh adv. serv In-Reply-To: <20473.1050919904@ocs3.intra.ocs.com.au> Message-ID: References: <20473.1050919904@ocs3.intra.ocs.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 341 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: mrinal@vxindia.veritas.com Precedence: bulk X-list: kdb On Mon, 21 Apr 2003, Keith Owens wrote: > On Mon, 21 Apr 2003 14:52:50 +0530 (IST), > Mrinal Shanker wrote: > >I was looking out for a kdb patch for my rh adv. server > >kernel, i.e 2.4.9-e3 or even for 2.4.7-10. > > > >Is it possible for me to patch these kernels with > >ftp://oss.sgi.com/www/projects/kdb/download/v4.1/kdb-v4.1-2.4.19-common-1.bz2 > > kdb patches are only against standard kernels, not against > distributions. If you want to use a distributor's kernel, you have to > ask that distributor for help. What about older standard kernel versions like say 2.4.9? Can i patch it with the 4.1 patches? Or would i need to use the "old" patches at ftp://oss.sgi.com/projects/kdb/download/ix86/old/ Regards, Mrinal From kaos@sgi.com Mon Apr 21 05:36:45 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 05:36:56 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3LCagFu005723 for ; Mon, 21 Apr 2003 05:36:44 -0700 Received: (qmail 11575 invoked from network); 21 Apr 2003 12:36:40 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 21 Apr 2003 12:36:40 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 4A2563000B8; Mon, 21 Apr 2003 22:36:37 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id E5E2E266; Mon, 21 Apr 2003 22:36:37 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Mrinal Shanker Cc: KDB Subject: Re: need patch for rh adv. serv In-reply-to: Your message of "Mon, 21 Apr 2003 16:55:45 +0530." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Apr 2003 22:36:32 +1000 Message-ID: <21377.1050928592@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 342 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Mon, 21 Apr 2003 16:55:45 +0530 (IST), Mrinal Shanker wrote: >What about older standard kernel versions like say 2.4.9? Can i >patch it with the 4.1 patches? kdb v4.1 is against 2.4.19 and 2.4.20 kernels. 2.4.9 is a lot different, especially after adding the RH patches. >Or would i need to use the "old" patches at >ftp://oss.sgi.com/projects/kdb/download/ix86/old/ You could try the old patches. They are not supported and there have been a lot of kdb enhancements since kdb v1.8. You have to ask yourself, if you are debugging a kernel, why stick with a distribution kernel, especially one that is so old? From mort@bork.org Mon Apr 21 07:35:30 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 07:35:39 -0700 (PDT) Received: from galileo.bork.org (qmailr@galileo.bork.org [66.11.174.148]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3LEZTFu006947 for ; Mon, 21 Apr 2003 07:35:30 -0700 Received: (qmail 12198 invoked from network); 21 Apr 2003 14:35:28 -0000 Received: from unknown (HELO localhost) (192.168.69.2) by 0 with SMTP; 21 Apr 2003 14:35:28 -0000 Received: from mort by localhost with local (Exim 3.36 #1 (Debian)) id 197cOG-0002Pa-00 for ; Mon, 21 Apr 2003 10:35:28 -0400 Date: Mon, 21 Apr 2003 10:35:28 -0400 From: Martin Hicks To: kdb@oss.sgi.com Subject: change cpu_is_online() to cpu_online() Message-ID: <20030421143528.GP543@bork.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 343 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: mort@wildopensource.com Precedence: bulk X-list: kdb Hello, Here is a patch to change all kdb-related instances of cpu_is_online() to cpu_online(). The 2.5 kernel uses cpu_online() so this is really just a patch to remain consistent between the two kernel versions. mh -- Wild Open Source Inc. mort@wildopensource.com diff -X /home/mort/diffex -uNr linux-2.4.20.pristine/arch/ia64/kdb/kdbasupport.c linux-2.4.20/arch/ia64/kdb/kdbasupport.c --- linux-2.4.20.pristine/arch/ia64/kdb/kdbasupport.c 2003-04-21 09:17:04.000000000 -0400 +++ linux-2.4.20/arch/ia64/kdb/kdbasupport.c 2003-04-21 10:12:58.000000000 -0400 @@ -1137,7 +1137,7 @@ if (diag) return diag; - if ((cpunum > NR_CPUS) || !cpu_is_online(cpunum)) + if ((cpunum > NR_CPUS) || !cpu_online(cpunum)) return KDB_BADCPUNUM; platform_send_ipi(cpunum, 0, IA64_IPI_DM_INIT, 0); diff -X /home/mort/diffex -uNr linux-2.4.20.pristine/include/linux/kdbprivate.h linux-2.4.20/include/linux/kdbprivate.h --- linux-2.4.20.pristine/include/linux/kdbprivate.h 2003-04-21 09:16:48.000000000 -0400 +++ linux-2.4.20/include/linux/kdbprivate.h 2003-04-21 10:12:34.000000000 -0400 @@ -349,14 +349,14 @@ */ extern int kdb_seqno; -/* Compatibility code until cpu_is_online() is in the standard kernel */ -#ifndef cpu_is_online +/* Compatibility code until cpu_online() is in the standard kernel */ +#ifndef cpu_online #ifdef CONFIG_SMP -#define cpu_is_online(cpu) test_bit(cpu, &cpu_online_map) +#define cpu_online(cpu) test_bit(cpu, &cpu_online_map) #else /* !SMP */ -#define cpu_is_online(cpu) ({ BUG_ON((cpu) != 0); 1; }) +#define cpu_online(cpu) ({ BUG_ON((cpu) != 0); 1; }) #endif /* SMP */ -#endif /* cpu_is_online */ +#endif /* cpu_online */ /* kdb needs to know if a task owns the cpu. Due to bugs in the scheduling code * the initial tasks on each cpu do not decode correctly, uni-processor also has diff -X /home/mort/diffex -uNr linux-2.4.20.pristine/kdb/kdbmain.c linux-2.4.20/kdb/kdbmain.c --- linux-2.4.20.pristine/kdb/kdbmain.c 2003-04-21 09:16:48.000000000 -0400 +++ linux-2.4.20/kdb/kdbmain.c 2003-04-21 10:13:36.000000000 -0400 @@ -1595,7 +1595,7 @@ if (smp_num_cpus > 1 && !KDB_FLAG(CATASTROPHIC)) { int i; for (i = 0; i < NR_CPUS; ++i) { - if (!cpu_is_online(i)) + if (!cpu_online(i)) continue; if (i != kdb_initial_cpu) { KDB_STATE_SET_CPU(HOLD_CPU, i); @@ -2651,7 +2651,7 @@ /* ask the other cpus if they are still active */ for (i=0; i NR_CPUS) - || !cpu_is_online(cpunum) + || !cpu_online(cpunum) || !KDB_STATE_CPU(KDB, cpunum)) return KDB_BADCPUNUM; From kaos@sgi.com Mon Apr 21 16:05:30 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 16:05:37 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3LN5RFu014501 for ; Mon, 21 Apr 2003 16:05:28 -0700 Received: (qmail 29502 invoked from network); 21 Apr 2003 23:05:25 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 21 Apr 2003 23:05:25 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 21A0B300087; Tue, 22 Apr 2003 09:05:20 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id E6EB8266; Tue, 22 Apr 2003 09:05:20 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Martin Hicks Cc: kdb@oss.sgi.com Subject: Re: change cpu_is_online() to cpu_online() In-reply-to: Your message of "Mon, 21 Apr 2003 10:35:28 -0400." <20030421143528.GP543@bork.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Apr 2003 09:05:15 +1000 Message-ID: <27099.1050966315@ocs3.intra.ocs.com.au> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 344 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Mon, 21 Apr 2003 10:35:28 -0400, Martin Hicks wrote: >Here is a patch to change all kdb-related instances of cpu_is_online() >to cpu_online(). The 2.5 kernel uses cpu_online() so this is really >just a patch to remain consistent between the two kernel versions. Thanks, I saw the change in 2.5 and I have already changed my development tree to match. From eddie.dong@intel.com Mon Apr 21 17:45:15 2003 Received: with ECARTIS (v1.0.0; list kdb); Mon, 21 Apr 2003 17:45:48 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3M0jEFu015132 for ; Mon, 21 Apr 2003 17:45:14 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h3M0eME27160 for ; Tue, 22 Apr 2003 00:40:23 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h3M0Hvs07122 for ; Tue, 22 Apr 2003 00:17:57 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003042208450312695 ; Tue, 22 Apr 2003 08:45:03 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Apr 2003 08:45:03 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: kdb 4.1 - compile error - 2.4.20 UP kernel X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Tue, 22 Apr 2003 08:45:03 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E087BC7@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: kdb 4.1 - compile error - 2.4.20 UP kernel Thread-Index: AcMH90ppagbFO8WEQCmK2nc3RVSkaAAcPl7g From: "Dong, Eddie" To: "Thomas Meyer" Cc: X-OriginalArrivalTime: 22 Apr 2003 00:45:03.0937 (UTC) FILETIME=[69B18B10:01C30868] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id h3M0jEFu015132 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 345 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: eddie.dong@intel.com Precedence: bulk X-list: kdb I also met this one in 2.4.19, but you can enable SMP even you have only 1 CPU. > -----Original Message----- > From: Thomas Meyer [mailto:thomas.mey@web.de] > Sent: 2003å¹´4月21æ—¥ 19:13 > To: kdb@oss.sgi.com > Subject: kdb 4.1 - compile error - 2.4.20 UP kernel > > > Hello. > > another thing i noticed with kdb 4.1 - kernel 2.4.20. > > when you want to compile a kernel with no smp support then > the compile > ends abnormaly. > > with kind regards > Thomas Meyer > > > From sachinsant@hotmail.com Tue Apr 22 04:26:45 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 22 Apr 2003 04:26:51 -0700 (PDT) Received: from hotmail.com (bay1-f130.bay1.hotmail.com [65.54.245.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3MBQiFu028644 for ; Tue, 22 Apr 2003 04:26:45 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 22 Apr 2003 04:26:39 -0700 Received: from 32.97.110.67 by by1fd.bay1.hotmail.msn.com with HTTP; Tue, 22 Apr 2003 11:26:39 GMT X-Originating-IP: [32.97.110.67] X-Originating-Email: [sachinsant@hotmail.com] From: "sachin sant" To: kdb@oss.sgi.com Subject: KDB for 2.5 kernels. Date: Tue, 22 Apr 2003 11:26:39 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 22 Apr 2003 11:26:39.0550 (UTC) FILETIME=[0ADDEDE0:01C308C2] X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 346 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sachinsant@hotmail.com Precedence: bulk X-list: kdb
Hi , is there a kdb version 4.1 for latest 2.5 kernels.I can see that there is KDB v2.4 for 2.5.45 kernel , but not the latest one's. Also if i try to create a patch for latest kernels.. there seems to be the problem with kernel in module interface routines. The Kernel in module interface has been rewritten in latest kernels. The module structure in module.h has also been changed drastically. If one ports the 4.1 version to latest 2.5 kernels , a major chunk of KDB needs to be rewritten to use the new module structure / kallsyms routines.
      Does any one has an idea on how to go about changing KDB code to make it in sync with the latest kernel-in module code / or vice versa...
 
Thanks

Celebrate Easter. Eggs, bunnies et al. Send e-cards. From vamsi@in.ibm.com Tue Apr 22 04:45:17 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 22 Apr 2003 04:45:25 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3MBjGFu028861 for ; Tue, 22 Apr 2003 04:45:16 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3MBj89X057982; Tue, 22 Apr 2003 07:45:09 -0400 Received: from vamsiks.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3MBj4uO025390; Tue, 22 Apr 2003 07:45:05 -0400 Received: (from vamsi@localhost) by vamsiks.in.ibm.com (8.11.6/8.11.2) id h3MC5ib05420; Tue, 22 Apr 2003 17:35:44 +0530 Date: Tue, 22 Apr 2003 17:35:43 +0530 From: "Vamsi Krishna S ." To: sachin sant Cc: kdb@oss.sgi.com Subject: Re: KDB for 2.5 kernels. Message-ID: <20030422173543.A5390@in.ibm.com> Reply-To: vamsi@in.ibm.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sachinsant@hotmail.com on Tue, Apr 22, 2003 at 11:26:39AM +0000 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 347 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: vamsi@in.ibm.com Precedence: bulk X-list: kdb On Tue, Apr 22, 2003 at 11:26:39AM +0000, sachin sant wrote: Please do not post HTML messages to this list, most people won't even look at them. 2.5 version of KDB patch is not done yet. If you want to port, we can help you. In-kernel module loader and the loss of some information in the symbols is only one of problems. See keith's earlier posts on lkml on the subject. We should be able to get potentially unreliable backtraces without depending on the symbols. Let us know if you intend to do this, what specific problems you faced. -- Vamsi Krishna S. IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From ssant@in.ibm.com Thu Apr 24 01:40:03 2003 Received: with ECARTIS (v1.0.0; list kdb); Thu, 24 Apr 2003 01:40:09 -0700 (PDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3O8e1Fu004803 for ; Thu, 24 Apr 2003 01:40:02 -0700 Received: from d23rh901.au.ibm.com (d23rh901.au.ibm.com [9.185.167.100]) by ausmtp01.au.ibm.com (8.12.9/8.12.9) with ESMTP id h3O8ccWP256238 for ; Thu, 24 Apr 2003 18:38:39 +1000 Received: from d23m0067.in.ibm.com (d23av02.au.ibm.com [9.185.167.107]) by d23rh901.au.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3O8di1f075232; Thu, 24 Apr 2003 18:39:48 +1000 Subject: Re: KDB for 2.5 kernels. To: vamsi@in.ibm.com Cc: kdb@oss.sgi.com, vamsi@in.ibm.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Sachin P Sant" Date: Thu, 24 Apr 2003 13:57:40 +0530 X-MIMETrack: Serialize by Router on d23m0067/23/M/IBM(Release 5.0.9a |January 7, 2002) at 24/04/2003 01:57:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 348 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: ssant@in.ibm.com Precedence: bulk X-list: kdb One other problem is the pc_keyb.h header file which has keyboard/led related macros and routines.This header file does not exist in the existing kernel tree. Is there a replacement for this header file , or the KDB IO related code [ kdb_io.c file ] needs to be changed.Any suggestions about this is welcome . Thanks -Sachin vamsi@in.ltcfwd.li nux.ibm.com To: sachin sant Sent by: cc: kdb@oss.sgi.com kdb-bounce@oss.sgi Subject: Re: KDB for 2.5 kernels. .com 04/22/2003 05:35 PM Please respond to vamsi On Tue, Apr 22, 2003 at 11:26:39AM +0000, sachin sant wrote: Please do not post HTML messages to this list, most people won't even look at them. 2.5 version of KDB patch is not done yet. If you want to port, we can help you. In-kernel module loader and the loss of some information in the symbols is only one of problems. See keith's earlier posts on lkml on the subject. We should be able to get potentially unreliable backtraces without depending on the symbols. Let us know if you intend to do this, what specific problems you faced. -- Vamsi Krishna S. IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: vamsi@in.ibm.com From sdake@mvista.com Tue Apr 29 17:57:12 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 29 Apr 2003 17:57:16 -0700 (PDT) Received: from zipcode.az.mvista.com (fw-az.mvista.com [65.200.49.158]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3U0vBFu016791 for ; Tue, 29 Apr 2003 17:57:11 -0700 Received: from mvista.com (persist.az.mvista.com [10.50.1.246]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id SAA12518 for ; Tue, 29 Apr 2003 18:10:49 -0700 Message-ID: <3EAF1F7A.9040102@mvista.com> Date: Tue, 29 Apr 2003 17:57:30 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kdb@oss.sgi.com Subject: KDB 4.1 USB keyboard fix Content-Type: multipart/mixed; boundary="------------030900060101080501070706" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 349 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sdake@mvista.com Precedence: bulk X-list: kdb This is a multi-part message in MIME format. --------------030900060101080501070706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit KDB 4.1 on the project page for 2.4.20 will not compile against 2.4.20 with USB keyboard enabled. Some types were changed (urb_t removed in favor of just struct urb) and it looks like functions were moved, creating implicit declarations and all the badness that follows. There are also three unused variables that were removed. The attached patch gets it to compile. Thanks -steve --------------030900060101080501070706 Content-Type: text/plain; name="kdb_4.1_usb_keyboard_fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kdb_4.1_usb_keyboard_fix.patch" diff -uNr linux-2.4.20-kdb-applied/arch/i386/kdb/kdba_io.c linux-2.4.20-kdb-keyboardfix/arch/i386/kdb/kdba_io.c --- linux-2.4.20-kdb-applied/arch/i386/kdb/kdba_io.c Tue Apr 29 16:40:59 2003 +++ linux-2.4.20-kdb-keyboardfix/arch/i386/kdb/kdba_io.c Tue Apr 29 17:46:34 2003 @@ -90,7 +90,7 @@ return -1; /* Transfer char if they are present */ - (*kdb_usb_infos.poll_func)(kdb_usb_infos.uhci, (urb_t *)kdb_usb_infos.urb); + (*kdb_usb_infos.poll_func)(kdb_usb_infos.uhci, (struct urb *)kdb_usb_infos.urb); spec = kdb_usb_infos.buffer[0]; keycode = kdb_usb_infos.buffer[2]; diff -uNr linux-2.4.20-kdb-applied/drivers/usb/usb-uhci.c linux-2.4.20-kdb-keyboardfix/drivers/usb/usb-uhci.c --- linux-2.4.20-kdb-applied/drivers/usb/usb-uhci.c Tue Apr 29 16:40:52 2003 +++ linux-2.4.20-kdb-keyboardfix/drivers/usb/usb-uhci.c Tue Apr 29 17:40:46 2003 @@ -137,114 +137,6 @@ /* used by userspace UHCI data structure dumper */ uhci_t **uhci_devices = &devs; -/* ------------------------------------------------------------------ */ -/* KDB part */ - -#if defined(CONFIG_KDB_USB) -/* -* The part of the code of UHCI controller that -* process the interrupt transfer -*/ - -void uhci_process_kdb_interrupt (uhci_t *s, urb_t *urb) -{ - int i, ret = -EINPROGRESS; - urb_priv_t *urb_priv = urb->hcpriv; - struct list_head *p = urb_priv->desc_list.next; - uhci_desc_t *desc = list_entry (urb_priv->desc_list.prev, uhci_desc_t, desc_list); - - int actual_length; - int status = 0; - - for (i = 0; p != &urb_priv->desc_list; p = p->next, i++) // Maybe we allow more than one TD later ;-) - { - desc = list_entry (p, uhci_desc_t, desc_list); - - if (is_td_active(desc)) { - // do not process active TDs - //dbg("TD ACT Status @%p %08x",desc,le32_to_cpu(desc->hw.td.status)); - break; - } - - if (!(desc->hw.td.status & cpu_to_le32(TD_CTRL_IOC))) { - // do not process one-shot TDs, no recycling - break; - } - // extract transfer parameters from TD - - actual_length = uhci_actual_length(le32_to_cpu(desc->hw.td.status)); - status = uhci_map_status (uhci_status_bits (le32_to_cpu(desc->hw.td.status)), usb_pipeout (urb->pipe)); - - // see if EP is stalled - if (status == -EPIPE) { - // set up stalled condition - usb_endpoint_halt (urb->dev, usb_pipeendpoint (urb->pipe), usb_pipeout (urb->pipe)); - } - - // if any error occurred: ignore this td, and continue - if (status != 0) { - //uhci_show_td (desc); - urb->error_count++; - goto recycle; - } - else - urb->actual_length = actual_length; - -recycle: - uhci_urb_dma_sync(s, urb, urb->hcpriv); - - if ((urb->status != -ECONNABORTED) && (urb->status != ECONNRESET) && - (urb->status != -ENOENT)) { - - urb->status = -EINPROGRESS; - - // Recycle INT-TD if interval!=0, else mark TD as one-shot - if (urb->interval) { - - desc->hw.td.info &= cpu_to_le32(~(1 << TD_TOKEN_TOGGLE)); - if (status==0) { - desc->hw.td.info |= cpu_to_le32((usb_gettoggle (urb->dev, usb_pipeendpoint (urb->pipe), - usb_pipeout (urb->pipe)) << TD_TOKEN_TOGGLE)); - usb_dotoggle (urb->dev, usb_pipeendpoint (urb->pipe), usb_pipeout (urb->pipe)); - } else { - desc->hw.td.info |= cpu_to_le32((!usb_gettoggle (urb->dev, usb_pipeendpoint (urb->pipe), - usb_pipeout (urb->pipe)) << TD_TOKEN_TOGGLE)); - } - desc->hw.td.status= cpu_to_le32((urb->pipe & TD_CTRL_LS) | TD_CTRL_ACTIVE | TD_CTRL_IOC | - (urb->transfer_flags & USB_DISABLE_SPD ? 0 : TD_CTRL_SPD) | (3 << 27)); - mb(); - } else { - uhci_unlink_urb_async(s, urb, UNLINK_ASYNC_STORE_URB); - // correct toggle after unlink - usb_dotoggle (urb->dev, usb_pipeendpoint (urb->pipe), usb_pipeout (urb->pipe)); - clr_td_ioc(desc); // inactivate TD - } - } - } -} - -/* uhci_kdb_poll - * This function is a minimalist version of the - * controller interrupt handler - */ -void uhci_kdb_poll (void *__uhci, urb_t *urb) -{ - uhci_t *s = __uhci; - unsigned int io_addr = s->io_addr; - unsigned short status; - - /* Reset input timer to be able to quit KDB */ - (*kdb_usb_infos.reset_timer)(); - - s->unlink_urb_done=0; - uhci_process_kdb_interrupt (s, urb); - - clean_descs(s, CLEAN_NOT_FORCED); - uhci_cleanup_unlink(s, CLEAN_NOT_FORCED); - uhci_switch_timer_int(s); -} -#endif -/*-------------------------------------------------------------------*/ // Cleans up collected QHs, but not more than 100 in one go void clean_descs(uhci_t *s, int force) { @@ -3026,6 +2918,112 @@ } #endif +/* ------------------------------------------------------------------ */ +/* KDB part */ + +#if defined(CONFIG_KDB_USB) +/* +* The part of the code of UHCI controller that +* process the interrupt transfer +*/ + +void uhci_process_kdb_interrupt (uhci_t *s, struct urb *urb) +{ + int i; + urb_priv_t *urb_priv = urb->hcpriv; + struct list_head *p = urb_priv->desc_list.next; + uhci_desc_t *desc = list_entry (urb_priv->desc_list.prev, uhci_desc_t, desc_list); + + int actual_length; + int status = 0; + + for (i = 0; p != &urb_priv->desc_list; p = p->next, i++) // Maybe we allow more than one TD later ;-) + { + desc = list_entry (p, uhci_desc_t, desc_list); + + if (is_td_active(desc)) { + // do not process active TDs + //dbg("TD ACT Status @%p %08x",desc,le32_to_cpu(desc->hw.td.status)); + break; + } + + if (!(desc->hw.td.status & cpu_to_le32(TD_CTRL_IOC))) { + // do not process one-shot TDs, no recycling + break; + } + // extract transfer parameters from TD + + actual_length = uhci_actual_length(le32_to_cpu(desc->hw.td.status)); + status = uhci_map_status (uhci_status_bits (le32_to_cpu(desc->hw.td.status)), usb_pipeout (urb->pipe)); + + // see if EP is stalled + if (status == -EPIPE) { + // set up stalled condition + usb_endpoint_halt (urb->dev, usb_pipeendpoint (urb->pipe), usb_pipeout (urb->pipe)); + } + + // if any error occurred: ignore this td, and continue + if (status != 0) { + //uhci_show_td (desc); + urb->error_count++; + goto recycle; + } + else + urb->actual_length = actual_length; + +recycle: + uhci_urb_dma_sync(s, urb, urb->hcpriv); + + if ((urb->status != -ECONNABORTED) && (urb->status != ECONNRESET) && + (urb->status != -ENOENT)) { + + urb->status = -EINPROGRESS; + + // Recycle INT-TD if interval!=0, else mark TD as one-shot + if (urb->interval) { + + desc->hw.td.info &= cpu_to_le32(~(1 << TD_TOKEN_TOGGLE)); + if (status==0) { + desc->hw.td.info |= cpu_to_le32((usb_gettoggle (urb->dev, usb_pipeendpoint (urb->pipe), + usb_pipeout (urb->pipe)) << TD_TOKEN_TOGGLE)); + usb_dotoggle (urb->dev, usb_pipeendpoint (urb->pipe), usb_pipeout (urb->pipe)); + } else { + desc->hw.td.info |= cpu_to_le32((!usb_gettoggle (urb->dev, usb_pipeendpoint (urb->pipe), + usb_pipeout (urb->pipe)) << TD_TOKEN_TOGGLE)); + } + desc->hw.td.status= cpu_to_le32((urb->pipe & TD_CTRL_LS) | TD_CTRL_ACTIVE | TD_CTRL_IOC | + (urb->transfer_flags & USB_DISABLE_SPD ? 0 : TD_CTRL_SPD) | (3 << 27)); + mb(); + } else { + uhci_unlink_urb_async(s, urb, UNLINK_ASYNC_STORE_URB); + // correct toggle after unlink + usb_dotoggle (urb->dev, usb_pipeendpoint (urb->pipe), usb_pipeout (urb->pipe)); + clr_td_ioc(desc); // inactivate TD + } + } + } +} + +/* uhci_kdb_poll + * This function is a minimalist version of the + * controller interrupt handler + */ +void uhci_kdb_poll (void *__uhci, struct urb *urb) +{ + uhci_t *s = __uhci; + + /* Reset input timer to be able to quit KDB */ + (*kdb_usb_infos.reset_timer)(); + + s->unlink_urb_done=0; + uhci_process_kdb_interrupt (s, urb); + + clean_descs(s, CLEAN_NOT_FORCED); + uhci_cleanup_unlink(s, CLEAN_NOT_FORCED); + uhci_switch_timer_int(s); +} +#endif +/*-------------------------------------------------------------------*/ _static int __devinit alloc_uhci (struct pci_dev *dev, int irq, unsigned int io_addr, unsigned int io_size) { uhci_t *s; --------------030900060101080501070706-- From kaos@sgi.com Tue Apr 29 18:20:34 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 29 Apr 2003 18:20:39 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3U1KXFu017043 for ; Tue, 29 Apr 2003 18:20:33 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h3U1YGVe000795 for ; Tue, 29 Apr 2003 20:34:17 -0500 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA05054; Wed, 30 Apr 2003 11:19:08 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 3256C3000B8; Wed, 30 Apr 2003 11:19:08 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 08960178; Wed, 30 Apr 2003 11:19:07 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Steven Dake Cc: kdb@oss.sgi.com Subject: Re: KDB 4.1 USB keyboard fix In-reply-to: Your message of "Tue, 29 Apr 2003 17:57:30 MST." <3EAF1F7A.9040102@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Apr 2003 11:19:02 +1000 Message-ID: <8279.1051665542@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 350 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Tue, 29 Apr 2003 17:57:30 -0700, Steven Dake wrote: >KDB 4.1 on the project page for 2.4.20 will not compile against 2.4.20 >with USB keyboard enabled. > >Some types were changed (urb_t removed in favor of just struct urb) and >it looks like functions were moved, creating implicit declarations and >all the badness that follows. There are also three unused variables >that were removed. > >The attached patch gets it to compile. I am removing USB keyboard support from kdb in v4.2. The USB code for 2.5 kernels is useless, I have neither the hardware nor the time to support USB keyboard for kdb and nobody has volunteered to keep the kdb USB code up to date. From sonic.zhang@intel.com Tue Apr 29 18:56:23 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 29 Apr 2003 18:56:29 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3U1uNFu018691 for ; Tue, 29 Apr 2003 18:56:23 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h3U1pRo00509 for ; Wed, 30 Apr 2003 01:51:27 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h3U1SOP06603 for ; Wed, 30 Apr 2003 01:28:24 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003043009561506323 ; Wed, 30 Apr 2003 09:56:15 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Apr 2003 09:56:15 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: KDB 4.1 USB keyboard fix X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 30 Apr 2003 09:56:15 +0800 Message-ID: <37FBBA5F3A361C41AB7CE44558C3448E846DFE@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KDB 4.1 USB keyboard fix Thread-Index: AcMOthOS2mJORfCgQny2OHVjQhWzpgABU88w From: "Zhang, Sonic" To: "Keith Owens" , "Steven Dake" Cc: X-OriginalArrivalTime: 30 Apr 2003 01:56:15.0410 (UTC) FILETIME=[AEFE9920:01C30EBB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h3U1uNFu018691 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 351 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: sonic.zhang@intel.com Precedence: bulk X-list: kdb Hi, Some Itanium 2 platforms don't have PS/2 port. So, the only way to connect a keyboard to these machine is via a USB port. How can we use the KDB patch without USB support in this case? Thank you. Sonic -----Original Message----- From: Keith Owens [mailto:kaos@sgi.com] Sent: 2003?4?30? 9:19 To: Steven Dake Cc: kdb@oss.sgi.com Subject: Re: KDB 4.1 USB keyboard fix On Tue, 29 Apr 2003 17:57:30 -0700, Steven Dake wrote: >KDB 4.1 on the project page for 2.4.20 will not compile against 2.4.20 >with USB keyboard enabled. > >Some types were changed (urb_t removed in favor of just struct urb) and >it looks like functions were moved, creating implicit declarations and >all the badness that follows. There are also three unused variables >that were removed. > >The attached patch gets it to compile. I am removing USB keyboard support from kdb in v4.2. The USB code for 2.5 kernels is useless, I have neither the hardware nor the time to support USB keyboard for kdb and nobody has volunteered to keep the kdb USB code up to date. From kaos@sgi.com Tue Apr 29 19:06:12 2003 Received: with ECARTIS (v1.0.0; list kdb); Tue, 29 Apr 2003 19:06:20 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h3U26BFu018801 for ; Tue, 29 Apr 2003 19:06:12 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h3U264E0013396 for ; Tue, 29 Apr 2003 19:06:05 -0700 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA05464; Wed, 30 Apr 2003 12:04:47 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 457D63000B8; Wed, 30 Apr 2003 12:04:45 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id E0D44178; Wed, 30 Apr 2003 12:04:45 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Zhang, Sonic" Cc: kdb@oss.sgi.com Subject: Re: KDB 4.1 USB keyboard fix In-reply-to: Your message of "Wed, 30 Apr 2003 09:56:15 +0800." <37FBBA5F3A361C41AB7CE44558C3448E846DFE@pdsmsx403.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Apr 2003 12:04:39 +1000 Message-ID: <8963.1051668279@kao2.melbourne.sgi.com> X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 352 X-ecartis-version: Ecartis v1.0.0 Sender: kdb-bounce@oss.sgi.com Errors-to: kdb-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: kdb On Wed, 30 Apr 2003 09:56:15 +0800, "Zhang, Sonic" wrote: > Some Itanium 2 platforms don't have PS/2 port. So, the only way to >connect a keyboard to these machine is via a USB port. How can we use >the KDB patch without USB support in this case? I know, but those systems are getting a free ride off KDB at the moment. They expect SGI to maintain the USB code for KDB, even though SGI IA64 boxes do not need USB support. I have asked several times for people to support the USB code in KDB, especially for 2.5 kernels and nobody has volunteered. Steven Dake has offered to help with USB for KDB on 2.4 kernels, but not for 2.5 kernels. Bottom line, if there is no community help to support this code then it gets dropped.