Re: Firewire debugging tools - firedump & fireproxy?

[Jason Wessel <jason.wessel@windriver.com>]

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-bugreport@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.