Re: remote debugging via FireWire * __fast__ firedump!
On Tue, 4 Dec 2007, Stefan Richter wrote: A quick note to this text from http://www.suse.de/~bk/firewire/ohci1394_dma_early.diff : + As all changes to the FireWire bus such as enabling and disabling + devices cause a bus reset and thereby disable remote DMA for all + devices, be sure to have FireWire enabled on the debug host (and + the cable plugged) before booting the debug target for debugging. Bus resets are also caused by bus managing software, which Linux' old and new FireWire stacks and the stacks of all other FireWire capable desktop OSs are to varying degrees. Yes, I can also trigger it raw1394_reset_bus() from libraw1394. I wonder if the following could happen: The two PCs are directly connected, only the PHY of the debugging PC is active, then the PHY of the debugged PC is activated, becomes root node, debugging PC examines the bus, then resets the bus to force its own PHY to become root node in order to get a working isochronous resource manager. This bus reset would switch remote DMA on the debugged PC off. Yes, that's the case. The PHY of the debugging PC must be active before the booting a kernel with the early OHCI-1394 initialisation on the debugged machine. I tried to to instruct users to do exactly that in that part of the help text, but changed the wording now in to hope to make it clearer: + [...] be sure to have the cable plugged and FireWire enabled on + the debugging host before booting the debug target for debugging. and I added new file, installed as Documentation/debugging-via-ohci1394.txt to give a more detailed HOWTO with links to all available tools and a step by step guide on how to create a setup for using firescope. ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diff I'll submit that patch for full review in my next mail. Bernhard -- 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/
Re: remote debugging via FireWire * __fast__ firedump!
On Tue, 4 Dec 2007, Andi Kleen wrote: I have just had the guts to explore __fast__ memory dumping over firewire for full-system dumps [...] Unfortunately it won't work for >3GB or so AFAIK. Yes we seem to be limited to 4GB mostly, with 3G mem hole, it's 3GB. Afterwards, the victim was dead (I excluded the low MB of memory, so something else must have caused this), at least the start of Did you run into the PCI memory hole below 4GB? Thanks, that was it most likely. I checked and haw that I did read a 32MB reserved area just below 2GB. I suppose the best way would be to require a System.map and then read e820.nr_map/e820.map[] and only dump real memory. Yes, good idea! Bernhard -- 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/
Re: remote debugging via FireWire * __fast__ firedump!
PPS: Today I had a brief look through your current sources. Look good so far, except for a curious hunk which patches drivers/Makefile. And I can't say anything to the x86 platform related and PCI related aspects of the driver. -- Stefan Richter -=-=-=== ==-- --=-- http://arcgraph.de/sr/ -- 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/
Re: remote debugging via FireWire * __fast__ firedump!
Stefan Richter wrote: > Bernhard Kaindl wrote: >> The biggest block size that worked here was 2048 bytes, which was >> enough to get nearly 10MB/s of data transfer rate from the remote >> memory to disk. > > The maximum payload size of block requests depends on three things: > 1. speed of the connection between the two nodes (debugged machine and > debugging machine), 2. link layer controllers of the two nodes, 3. > software on the debugging machine. > > 1.) S100: 512 bytes, S200: 1024 bytes, S400: 2048 bytes, S800 and more: > 4096 bytes. PS: If there are only 1394a nodes, you can read the connection speed from the speed map registers on the debugging machine. It becomes difficult for 1394b nodes and some mixtures of 1394a and b nodes. But consumer 1394b hardware is always S800 capable. Consumer 1394a hardware is always S400 capable. Except consumer camcorders which are AFAIK typically limited to S100, but they have only one port and will therefore never sit between debugging and debugged PC. So it's not as difficult in 99.9% of the cases: You can expect S400, some people might get S800. But you can't use the bigger S800 block size if the debugging machine runs ohci1394. > 2.) Controllers on CardBus cards are limited to 1024 bytes payload of > asynchronous packets, for reasons I don't know. The other available > controllers only have the above mentioned speed-dependent limit. This is relevant if the debugging or the debugged PC have a CardBus card. Actually this is the limit of all 1394a CardBus card I have seen; I don't know about 1394b CardBus cards, or Express cards. (I suppose Express cards have no limits of this kind, as they are just PCIe cards in a different formfactor.) This payload limitation of the link can be read from the bus info blocks of the debugged and the debugging machine. Though I am not entirely sure right now if the ohci1394_earlyinit driven machine will have its bus info block properly set up. -- Stefan Richter -=-=-=== ==-- --=-- http://arcgraph.de/sr/ -- 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/
Re: remote debugging via FireWire * __fast__ firedump!
Bernhard Kaindl wrote: > The biggest block size that worked here was 2048 bytes, which was > enough to get nearly 10MB/s of data transfer rate from the remote > memory to disk. The maximum payload size of block requests depends on three things: 1. speed of the connection between the two nodes (debugged machine and debugging machine), 2. link layer controllers of the two nodes, 3. software on the debugging machine. 1.) S100: 512 bytes, S200: 1024 bytes, S400: 2048 bytes, S800 and more: 4096 bytes. 2.) Controllers on CardBus cards are limited to 1024 bytes payload of asynchronous packets, for reasons I don't know. The other available controllers only have the above mentioned speed-dependent limit. 3.) The ohci1394 driver has an implementation limitation which requires that all packets including headers don't exceed PAGE_SIZE. This does not affect the packets which go through the physical response unit (which they do on the debugged machine) but it affects the debugging machine. A quick note to this text from http://www.suse.de/~bk/firewire/ohci1394_dma_early.diff : > + As all changes to the FireWire bus such as enabling and disabling > + devices cause a bus reset and thereby disable remote DMA for all > + devices, be sure to have FireWire enabled on the debug host (and > + the cable plugged) before booting the debug target for debugging. Bus resets are also caused by bus managing software, which Linux' old and new FireWire stacks and the stacks of all other FireWire capable desktop OSs are to varying degrees. I wonder if the following could happen: The two PCs are directly connected, only the PHY of the debugging PC is active, then the PHY of the debugged PC is activated, becomes root node, debugging PC examines the bus, then resets the bus to force its own PHY to become root node in order to get a working isochronous resource manager. This bus reset would switch remote DMA on the debugged PC off. -- Stefan Richter -=-=-=== ==-- --=-- http://arcgraph.de/sr/ -- 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/
Re: remote debugging via FireWire * __fast__ firedump!
On Tuesday 04 December 2007 04:45:22 am Bernhard Kaindl wrote: > I just wanted to let you know that I'll have picked up the early > firewire patch again and cleaned it up very much so that it should > be ready to submit it and but it on the patch-submission road. Nice. > I have just had the guts to explore __fast__ memory dumping over > firewire for full-system dumps (reading quadlets is __painfully__ > show if you want to read 2GB of memory over the bus, you only get > about some some kilobytes each second) using raw1394_start_read() > to allow also block reads instead of just quatlet reads. Unfortunately it won't work for >3GB or so AFAIK. > The biggest block size that worked here was 2048 bytes, which was > enough to get nearly 10MB/s of data transfer rate from the remote > memory to disk. Dumping 2GB of remote memory was just a matter of > about 3 few short minutes which quickly ran by. > > Afterwards, the victim was dead (I excluded the low MB of memory, > so something else must have caused this), at least the start of Did you run into the PCI memory hole below 4GB? I suppose the best way would be to require a System.map and then read e820.nr_map/e820.map[] and only dump real memory. -Andi -- 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/
Re: remote debugging via FireWire * __fast__ firedump!
Hi, I just wanted to let you know that I'll have picked up the early firewire patch again and cleaned it up very much so that it should be ready to submit it and but it on the patch-submission road. What's left to do is to write some HOWTO like Stefan describes below, but I'll try to get that done soon. I've also started working on the userspace tools and got firescope to work across the 32/64-bit machines (both directions), there is one hack (which I should do in a clean way insteat) in that patch of which I do not know if that works in ppc/ppc64 but I could look at it if needed or send the patch to Benjamin for adding support for ppc64, to do it properly, we'll probably need an target architecture option in firescope and as I do not know if it's needed by Benjamin, I left out ppc64 for now. I have just had the guts to explore __fast__ memory dumping over firewire for full-system dumps (reading quadlets is __painfully__ show if you want to read 2GB of memory over the bus, you only get about some some kilobytes each second) using raw1394_start_read() to allow also block reads instead of just quatlet reads. The biggest block size that worked here was 2048 bytes, which was enough to get nearly 10MB/s of data transfer rate from the remote memory to disk. Dumping 2GB of remote memory was just a matter of about 3 few short minutes which quickly ran by. Afterwards, the victim was dead (I excluded the low MB of memory, so something else must have caused this), at least the start of the dump looked well, but I haven't tested the error handling yet, but I'll send you the tool (I called it firedump) soon. Bernhard On Sat, 10 Feb 2007, Stefan Richter wrote: Andi Kleen wrote at LKML: ... Not likely to make .21: ... - Early firewire support for firescope at early boot ... Was it seen in canonical patch format on a mailinglist before? Is it Bernhard Kaindl's ohci1394_early? http://www.suse.de/~bk/firewire/ Would be good to put this on the usual patch-submission road in order to prep it for 2.6.22. Could be handled via linux1394-2.6.git, although a different channel where the actual users of this facility watch would IMO be more appropriate. I also have suggestions, at least WRT Bernhard's code: - The Kconfig option could go into the "Kernel hacking" submenu rather than the IEEE 1394 submenu. (The driver source should stay in drivers/ieee1394.) - Leave a note in the Kconfig help how it is typically used, i.e. what is required on the remote terminal side, where to find firescope, fireproxy etc. and assorted HOWTOs. - Indicate in the Kconfig help that only a 4GB address range is made visible this way. A mostly unrelated note: A simple to set up remote-dmesg utility would be nice to have on the terminal side. Maybe a small ieee1394 high-level driver which gives hints on the location of the dmesg buffer via configuration ROM would be warranted. Or is it feasible to find the dmesg buffer by plain memory analysis? -- Stefan Richter -=-=-=== --=- -=-=- http://arcgraph.de/sr/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linux1394-devel -- 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/
Re: remote debugging via FireWire
On Mon, 2007-02-12 at 07:49 +0100, Andi Kleen wrote: > On Sunday 11 February 2007 22:35, Benjamin Herrenschmidt wrote: > > > I'd like to have that on ppc as well, so I'd rather keep it in drivers/ > > This will need some abstraction at least -- there are some early mapping hacks > that are x86 specific right now. Either abstraction or ifdef's .. we have ioremap working very early on ppc :-) > > I agree that it doesn't need to be a module. If you can load modules, > > then you can load the full ohci driver. Thus, if it's an early thingy > > initialized by arch, it can export a special "takeover" hook that the > > proper ohci module can then call to override it (important if we start > > having an irq handler). > > > > Andi, also, how do you deal with iommu ? Not at all ? :-) > > Yes -- it's really early debugging hack mostly. It's reasonable to > let the iommu be disabled (or later a special bypass can be added for this) Ok. Ben. - 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/
Re: remote debugging via FireWire
On Sunday 11 February 2007 22:35, Benjamin Herrenschmidt wrote: > I'd like to have that on ppc as well, so I'd rather keep it in drivers/ This will need some abstraction at least -- there are some early mapping hacks that are x86 specific right now. > I agree that it doesn't need to be a module. If you can load modules, > then you can load the full ohci driver. Thus, if it's an early thingy > initialized by arch, it can export a special "takeover" hook that the > proper ohci module can then call to override it (important if we start > having an irq handler). > > Andi, also, how do you deal with iommu ? Not at all ? :-) Yes -- it's really early debugging hack mostly. It's reasonable to let the iommu be disabled (or later a special bypass can be added for this) -Andi - 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/
Re: remote debugging via FireWire
On Sat, 2007-02-10 at 20:16 +0100, Stefan Richter wrote:
> [ohci1394_early]
>
> Some remarks to the September 2006 version at
> http://www.suse.de/~bk/firewire/ :
>
> - Seems its .remove won't work properly if more than one OHCI-1394
> controller is installed. And it's .probe isn't reentrant, but that
> might be less of a problem.
> - Its functionality will be lost if there is a FireWire bus reset,
> e.g. when something is plugged in or out. To keep physical DMA
> alive, an interrupt handler had to be installed which writes ~0
> to OHCI1394_PhyReqFilter{Hi,Lo}Set. Can interrupt handlers be
> registered in an early setup stage?
> - There might be some register accesses in the setup which could be
> omitted; I'd have to look this up.
> - Could be optimized to not use ohci1394.h::struct ti_ohci.
> - PCI_CLASS_FIREWIRE_OHCI can be replaced by
> include/linux/pci_ids.h::PCI_CLASS_SERIAL_FIREWIRE_OHCI which
> was newly added in 2.6.20-git#.
> - I suppose .probe should check for PCI_CLASS_SERIAL_FIREWIRE_OHCI
> instead of PCI_CLASS_SERIAL_FIREWIRE.
> - How about dropping support for configuring this as module, to
> simplify the code? Unless this would interfere with ohci1394; and
> it probably would if there was an interrupt handler...
> - "depends on X86_64" is missing in Kconfig.
> - Maybe put it into arch/x86_64/drivers/ instead of drivers/ieee1394?
> - Plus what I mentioned earlier in the thread.
>
> I could send code to address some of this at next weekend or later.
I'd like to have that on ppc as well, so I'd rather keep it in drivers/
I agree that it doesn't need to be a module. If you can load modules,
then you can load the full ohci driver. Thus, if it's an early thingy
initialized by arch, it can export a special "takeover" hook that the
proper ohci module can then call to override it (important if we start
having an irq handler).
Andi, also, how do you deal with iommu ? Not at all ? :-)
Ben.
-
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/
Re: remote debugging via FireWire
[ohci1394_early]
Some remarks to the September 2006 version at
http://www.suse.de/~bk/firewire/ :
- Seems its .remove won't work properly if more than one OHCI-1394
controller is installed. And it's .probe isn't reentrant, but that
might be less of a problem.
- Its functionality will be lost if there is a FireWire bus reset,
e.g. when something is plugged in or out. To keep physical DMA
alive, an interrupt handler had to be installed which writes ~0
to OHCI1394_PhyReqFilter{Hi,Lo}Set. Can interrupt handlers be
registered in an early setup stage?
- There might be some register accesses in the setup which could be
omitted; I'd have to look this up.
- Could be optimized to not use ohci1394.h::struct ti_ohci.
- PCI_CLASS_FIREWIRE_OHCI can be replaced by
include/linux/pci_ids.h::PCI_CLASS_SERIAL_FIREWIRE_OHCI which
was newly added in 2.6.20-git#.
- I suppose .probe should check for PCI_CLASS_SERIAL_FIREWIRE_OHCI
instead of PCI_CLASS_SERIAL_FIREWIRE.
- How about dropping support for configuring this as module, to
simplify the code? Unless this would interfere with ohci1394; and
it probably would if there was an interrupt handler...
- "depends on X86_64" is missing in Kconfig.
- Maybe put it into arch/x86_64/drivers/ instead of drivers/ieee1394?
- Plus what I mentioned earlier in the thread.
I could send code to address some of this at next weekend or later.
--
Stefan Richter
-=-=-=== --=- -=-=-
http://arcgraph.de/sr/
-
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/
Re: remote debugging via FireWire
On Saturday 10 February 2007 16:14, Stefan Richter wrote: > Andi Kleen wrote: > > On Saturday 10 February 2007 14:51, Stefan Richter wrote: > >> Could be handled via linux1394-2.6.git, although a > >> different channel where the actual users of this facility watch would > >> IMO be more appropriate. > > > > It's more related to arch code than firewire, so I thought i would > > handle it. But you can too if you want. It definitely needs much > > more review anyways. > > It's better you do it. I don't know anything about the specifics of > early initialization. Just Cc linux1394-devel on submission so that we > can have a look at the OHCI-1394 related bits. Ok. I'm sure you know more about 1394 than me so I guess it will be shared review. -Andi - 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/
Re: remote debugging via FireWire
Andi Kleen wrote: > On Saturday 10 February 2007 14:51, Stefan Richter wrote: >> Could be handled via linux1394-2.6.git, although a >> different channel where the actual users of this facility watch would >> IMO be more appropriate. > > It's more related to arch code than firewire, so I thought i would > handle it. But you can too if you want. It definitely needs much > more review anyways. It's better you do it. I don't know anything about the specifics of early initialization. Just Cc linux1394-devel on submission so that we can have a look at the OHCI-1394 related bits. Using linux1394-2.6.git could only be helpful if more code sharing between ohci1394.c and ohci1394_early.c would be desired. That's questionable though, given the rather small size of ohci1394_early.c. >> A mostly unrelated note: A simple to set up remote-dmesg utility would >> be nice to have on the terminal side. > > ftp://ftp.firstfloor.org/pub/ak/firescope/ Thanks, I wasn't aware that firescope actually does fill this gap. -- Stefan Richter -=-=-=== --=- -=-=- http://arcgraph.de/sr/ - 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/
Re: remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge)
On Saturday 10 February 2007 14:51, Stefan Richter wrote: > Andi Kleen wrote at LKML: > ... > > Not likely to make .21: > ... > > - Early firewire support for firescope at early boot > ... > > Was it seen in canonical patch format on a mailinglist before? Don't know. > Is it Bernhard Kaindl's ohci1394_early? > http://www.suse.de/~bk/firewire/ Yes. > > Would be good to put this on the usual patch-submission road in order to > prep it for 2.6.22. Could be handled via linux1394-2.6.git, although a > different channel where the actual users of this facility watch would > IMO be more appropriate. It's more related to arch code than firewire, so I thought i would handle it. But you can too if you want. It definitely needs much more review anyways. > A mostly unrelated note: A simple to set up remote-dmesg utility would > be nice to have on the terminal side. ftp://ftp.firstfloor.org/pub/ak/firescope/ -Andi - 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/
