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?
Thanks,
J
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?
>
> Thanks,
> J
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Me having the same question. I have just bought everything for firewire
debugging.
Jason Wessel, what the fate of kgdbom ?
(and kgdboe btw ....)
Best regards,
Maxim Levitsky
On Thu, Jul 30, 2009 at 2:36 PM, Maxim Levitsky<[email protected]> 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 ....)
>
These URLs are provided in Documentation/debugging-via-ohci1394.txt,
and not available now. So that should be fixed, or removed, at least.
Thanks,
J
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:
[email protected].
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.
Jun Koi <[email protected]> writes:
> 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
I have a copy of Bernd's website on http://halobates.de/firewire
firescope is also on my servers (I did the original x86 version)
-Andi
--
[email protected] -- Speaking for myself only.
On Thu, 2009-07-30 at 11:43 +0200, Andi Kleen wrote:
> Jun Koi <[email protected]> writes:
>
> > 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
>
> I have a copy of Bernd's website on http://halobates.de/firewire
>
> firescope is also on my servers (I did the original x86 version)
>
> -Andi
>
>
Thanks a lot.
Don't know what to say about what I could do to help...
I could help to make this tool better, don't know how much time will
permit me, or at least I think that kgdbom can be merged almost as is
already.
As it stands from the source, it just creates a ring buffer in memory
for commands as if there were send over gdb. Dead simple it seems.
Thus, fireproxy could be reduced (if it isn't...) to simple "read string
from memory over firewire and hand over to gdb via tcp and vise versa.
This should give back all power kgdb has for free (currently fireproxy
states that only very basic support is implemented)
Could some of you put these tools on kernel.org?
Debugging over firewire seems to be the best of the best.
BTW, it is almost always possible to take over the CPU even without help
of kgdbom (if system got in state even it doesn't work)
Say CPU is in protected mode, and you know where the IDT lives.
You could program some device to trigger an IRQ (HPET seems to be the
best), set up the APIC to route it, and then trigger, and now the CPU
should enter the IRQ handler. (Of course this needs that firewire device
be able to access HPET and IOAPIC which are nowadays located on
southbridge)
And probably the only device that can't be debugged, is the firewire
driver itself that is standard compliant, and well tested...
Best regards,
Maxim Levitsky
> Don't know what to say about what I could do to help...
> I could help to make this tool better, don't know how much time will
> permit me, or at least I think that kgdbom can be merged almost as is
> already.
Cleaning up the patch and submitting it would be great yes.
One problem with firewire as it stands is that it doesn't support
more 4GB of memory and doesn't work with IOMMUs. But for limited
situations it's quite good.
-Andi
--
[email protected] -- Speaking for myself only.
On Thu, 2009-07-30 at 03:31 -0500, Jason Wessel wrote:
> 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:
> [email protected].
>
> 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.
Or, even better, to make in possible to switch between a normal, and exclusive mode?
Maybe this cab be done without (or with slight) modifications to network drivers.
Why not to make kgdb own the network device (use it exclusively), but use same interfaces as regular kernel does?
Thanks for the info,
Best regards,
Maxim Levitsky
Maxim Levitsky wrote:
> On Thu, 2009-07-30 at 03:31 -0500, Jason Wessel wrote:
>>
>> 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.
> Or, even better, to make in possible to switch between a normal, and
> exclusive mode? Maybe this cab be done without (or with slight)
> modifications to network drivers. Why not to make kgdb own the
> network device (use it exclusively), but use same interfaces as
> regular kernel does?
The key problem is how such a switch is governed between normal and
exclusive mode works. If it involves locks kgdboe is not going to
work reliably from the exception context.
Having kgdboe directly own an interface and use the same kernel API as
the network stack won't work out of the box because there is probing,
interrupt control and lots of other tidbits. This is a case where the
polling API needs some work or a dedicated API is needed, because this
is a case where you really don't want the whole network stack
involved. IE it would be nice to be able to debug the networking
stack with kgdboe.
Patches which implement new functionality, ideas and discussion about
any aspect of kernel debugging are always welcome on the kgdb mailing
list. :-)
Cheers,
Jason.
On Thu, 2009-07-30 at 16:10 -0500, Jason Wessel wrote:
> Maxim Levitsky wrote:
> > On Thu, 2009-07-30 at 03:31 -0500, Jason Wessel wrote:
> >>
> >> 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.
>
> > Or, even better, to make in possible to switch between a normal, and
> > exclusive mode? Maybe this cab be done without (or with slight)
> > modifications to network drivers. Why not to make kgdb own the
> > network device (use it exclusively), but use same interfaces as
> > regular kernel does?
>
> The key problem is how such a switch is governed between normal and
> exclusive mode works. If it involves locks kgdboe is not going to
> work reliably from the exception context.
I mean the switch should happen just once, when kgdboe is loaded, and
back when unloaded.
>
> Having kgdboe directly own an interface and use the same kernel API as
> the network stack won't work out of the box because there is probing,
> interrupt control and lots of other tidbits. This is a case where the
> polling API needs some work or a dedicated API is needed, because this
> is a case where you really don't want the whole network stack
> involved. IE it would be nice to be able to debug the networking
> stack with kgdboe.
Sure, but I feel that doing any significant changes to _all_ ethernet
drivers is a huge job.
>
> Patches which implement new functionality, ideas and discussion about
> any aspect of kernel debugging are always welcome on the kgdb mailing
> list. :-)
Best regards,
Maxim Levitsky
>
> Cheers,
> Jason.
>