Maxim Levitsky wrote: > On Sun, 2009-07-05 at 14:42 +0900, Jun Koi wrote: > >> Hi, >> >> I am doing some debugging via firewire. I found some references to >> some tools named firedump & fireproxy, made by Bernhard Kaindl, >> supposed put at following addresses: >> >> ftp://ftp.suse.de/private/bk/firewire/tools/firedump-0.1.tar.bz2 >> ftp://ftp.suse.de/private/bk/firewire/tools/fireproxy-0.33.tar.bz2 >> >> However, these URLs are nolonger available. I am wondering if they >> have been moved to somewhere else? Anybody know? >> >> > Me having the same question. I have just bought everything for firewire > debugging. > > Jason Wessel, what the fate of kgdbom ? > (and kgdboe btw ....) > >
kgdbom ? I had heard of it in regard to fireproxy, but I have never received any patches specific to a kgdbom implementation. Should you or anyone else create patches for kgdbom, please cc: kgdb-bugrep...@lists.sourceforge.net. As for kgdboe, I do not find it to be extremely reliable. It does exist however in the kgdb development tree. You can pick a kernel from 2.6.21-> latest. http://git.kernel.org/?p=linux/kernel/git/jwessel/linux-2.6-kgdb.git;a=heads In order to make kgdboe reliable it must get altered in one of several ways before it would be robust enough for mainline kernel consideration. 1) The key problem is that preemption of irq code causes locks to be held which prevent operation of the polled ethernet driver. This could be be solved at the ethernet driver level by creating a polled interface that has no requirement on any kind of locking. I have yet to see an ethernet driver with such an implementation. Most if not all the polled ethernet implementations make use of disable_irq() which is 1/2 the battle, the other 1/2 being the spin locks or mutexs which can deadlock. 2) A possible (but not practical or desirable) solution would be to change the kernel mechanism for synchronizing a driver or running a thread to free a lock so as to safely use the ethernet driver for another purpose. This solution is not worth the time because the possibility for deadlock is far too high. 3) Develop a low level dedicated ethernet debug interface. If you have more than one ethernet, or an ethernet device that has multiple hardware queues, it is plausible to have a dedicated way to talk to a device which has no restrictions on getting preempted, or used by another part of the kernel. This lends itself to an ideal medium for kgdb communications. Jason. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
