Re: mmap'ed memory in core files ?

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

>> On Wed, Jul 2, 2008 at 12:50 PM, Philippe De Muyter <phdm@macqel.be> wrote:
>>> Hi Michael,
>>>
>>> On Tue, Jul 01, 2008 at 08:16:11PM +0200, Michael Kerrisk wrote:
>>>> Have a look at the section "Controlling which mappings are written to
>>>> the core dump" in a recent core.5 man page:
>>>> http://www.kernel.org/doc/man-pages/online/pages/man5/core.5.html
>>> thanks for the info.  I didn't know about /proc/PID/coredump_filter.
>>>
>>> that part was promising :
>>>
>>>       bit 2  Dump file-backed private mappings.
>>>       bit 3  Dump file-backed shared mappings.
>>>
>>>    The default value of coredump_filter is 0x3; this reflects traditional
>>>    Linux behavior and means that only anonymous memory segments are dumped.
>>>
>>> Unfortunately, the part that applies to me (I have tested it) is the next one :
>>>
>>>    Memory-mapped I/O pages such as frame buffer are never dumped, [...],
>>>    regardless of the coredump_filter value.

This shouldn't be a problem to you as far as I understand.  I suppose 
"memory mapped I/O pages" means registers of PCI devices, mapped into 
the memory address space.

The DMA buffer which you would like to get included in the core file is 
normal RAM (I suppose: allocated by the kernel in the kernel's virtual 
address space, mapped into the application client's address space by 
mmap(), and also mapped into the FireWire controller's local bus address 
space for it to write received data into).

FireWire controllers also have memory-mapped I/O regions (per OHCI: at 
least one region of at least 2048 bytes size).  But your process never 
accesses them, only the kernel drivers do (to start and stop DMA 
programs and so on --- while the DMA programs and the DMA data buffers 
live in normal RAM).
-- 
Stefan Richter
-=====-==--- -=== ---=-
http://arcgraph.de/sr/