On Tue, 12 Feb 2008 19:20:24 +0100 Andi Kleen <andi@firstfloor.org> wrote:Yes. A stopped CPU is very visible and hence can change the behaviour of the system which is being tested. I don't think you'd want to be poking around in kernel internals while some of the CPUs are continuing to run. It sounds rather creepy. You want everything to stop. Including time-related things. Bear in mind that one of the things you do with kgdb is to modify kernel memory - I'd do things like int foo; ... if (foo == 1) special_stuff(); ... to trigger a particular behaviour at a particular time. If you're making multiple changes, you want them "atomic" wrt all CPUs. (Of course, if you happeed to breakpoint one CPU while it was partway through reading multiple locations, you lose. But that's a teeny window). OT: another thing you can do with kgdb is error-path testing: foo = kmalloc(...) BP-> if (!foo) recover(); put a breakpoint on the !foo test and set foo to zero by hand. --
| Mark Lord | Re: Linux 2.6.24-rc7 |
| Kentaro Takeda | [TOMOYO 05/15](repost) Domain transition handler functions. |
| Willy Tarreau | Re: Linux v2.6.24-rc1 |
| Al Boldi | [RFD] Incremental fsck |
| drew | Re: SVGA-alphanum. modes |
| Kevin Cummings | VESA video support during boot. |
| Raymond Nijssen | Re: What the 17" monitor reviews never tell you |
| Michael Haardt | GNU shell utils 1.7: date(1) dumps core (with easy solution:) |
git: | |
| David Woodhouse | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG] New Kernel Bugs |
