Re: [Kgdb-bugreport] Firewire debugging tools - firedump & fireproxy?
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. > -- 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
Re: [Kgdb-bugreport] Firewire debugging tools - firedump & fireproxy?
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. -- 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
Re: [Kgdb-bugreport] Firewire debugging tools - firedump & fireproxy?
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: > 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. 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 -- 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
Re: [Kgdb-bugreport] Firewire debugging tools - firedump & fireproxy?
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
