Hello, All!
Is it possible somehow to disable core dumping of mmaped device memory, in
global OS/dumper settings or via some undocumented mmap flag, doesn’t
matter.
It’s really annoying to wait while dumper finishes its job when driver
segfaults with one gigabyte of mmaped PCI aperture memory, in most cases -
it’s not important what device’s memory contain.
Thanks in advance …
… or thanks for ignorance 
With best regards, Mike Gorchak. E-mail: mike@malva.ua
How do you know what memory is ‘device’ memory. I guess we could come up with a scheme in which you
look at the asinfo entries, but that would be hard to enforce.
Right now it uses the heuristic that PROT_NOCACHE memory is device memory and should not be dumped,
although it’s somewhat stupid in that it still writes it to the logfile (as -1s) - it would be better
to put out a PT_LOAD segment with a zero filesz (or just omit it altogether)
You can checkout services/dumper from the repository and hack it to be aware of whatever method
you like for now - I’m willing to take suggestions/patches though.
Mike Gorchak wrote:
Hello, All!
Is it possible somehow to disable core dumping of mmaped device memory, in
global OS/dumper settings or via some undocumented mmap flag, doesn’t
matter.
It’s really annoying to wait while dumper finishes its job when driver
segfaults with one gigabyte of mmaped PCI aperture memory, in most cases -
it’s not important what device’s memory contain.Thanks in advance …
… or thanks for ignorance >With best regards, Mike Gorchak. E-mail: > mike@malva.ua
I’ve just committed a fix for this. I’ve made the default to not dump out memory that is marked
as being MAP_PHYS (but isn’t also MAP_ANON).
You can force them to be dumper out again by adding the -P option.
The change is in trunk/services/dumper/dumper.c repo version 154191 - it should be visible in a short
while.
Cheers,
Colin
Colin Burgess wrote:
How do you know what memory is ‘device’ memory. I guess we could come
up with a scheme in which you
look at the asinfo entries, but that would be hard to enforce.Right now it uses the heuristic that PROT_NOCACHE memory is device
memory and should not be dumped,
although it’s somewhat stupid in that it still writes it to the logfile
(as -1s) - it would be better
to put out a PT_LOAD segment with a zero filesz (or just omit it
altogether)You can checkout services/dumper from the repository and hack it to be
aware of whatever method
you like for now - I’m willing to take suggestions/patches though.Mike Gorchak wrote:
Hello, All!Is it possible somehow to disable core dumping of mmaped device
memory, in global OS/dumper settings or via some undocumented mmap
flag, doesn’t matter.
It’s really annoying to wait while dumper finishes its job when driver
segfaults with one gigabyte of mmaped PCI aperture memory, in most
cases - it’s not important what device’s memory contain.Thanks in advance …
… or thanks for ignorance >With best regards, Mike Gorchak. E-mail: > mike@malva.ua
Hello, Colin!
CB> I’ve just committed a fix for this. I’ve made the default to not dump
CB> out memory that is marked as being MAP_PHYS (but isn’t also MAP_ANON).
CB> You can force them to be dumper out again by adding the -P option.
CB> The change is in trunk/services/dumper/dumper.c repo version 154191 -
CB> it should be visible in a short while.
Wow, thank you !
Colin, do you have also any suggestions about wbinvd x86 cpu instruction
execution (problem was described by me in the previous newsletter in this
group) ? Does PROT_NOCACHE mmap option will act the same as continually
wbinvd execution after writings to that mmaped memory ?
With best regards, Mike Gorchak. E-mail: mike@malva.ua
“Mike Gorchak” <mike@malva.ua> wrote in message
news:fcsu5m$7fk$1@inn.qnx.com…
Hello, Colin!
CB> I’ve just committed a fix for this. I’ve made the default to not dump
CB> out memory that is marked as being MAP_PHYS (but isn’t also MAP_ANON).CB> You can force them to be dumper out again by adding the -P option.
CB> The change is in trunk/services/dumper/dumper.c repo version 154191 -
CB> it should be visible in a short while.Wow, thank you ! >
Who said this would be a non event 
Colin, do you have also any suggestions about wbinvd x86 cpu instruction
execution (problem was described by me in the previous newsletter in this
group) ? Does PROT_NOCACHE mmap option will act the same as continually
wbinvd execution after writings to that mmaped memory ?With best regards, Mike Gorchak. E-mail: > mike@malva.ua
Mario Charest wrote:
“Mike Gorchak” <> mike@malva.ua> > wrote in message
news:fcsu5m$7fk$> 1@inn.qnx.com> …
Hello, Colin!CB> I’ve just committed a fix for this. I’ve made the default to not dump
CB> out memory that is marked as being MAP_PHYS (but isn’t also MAP_ANON).CB> You can force them to be dumper out again by adding the -P option.
CB> The change is in trunk/services/dumper/dumper.c repo version 154191 -
CB> it should be visible in a short while.Wow, thank you ! >
Who said this would be a non event >
Oh, just some curmudgeon who’s always looking on the downside - apart from him, everyone
seems to be happy! 
Colin, do you have also any suggestions about wbinvd x86 cpu instruction
execution (problem was described by me in the previous newsletter in this
group) ? Does PROT_NOCACHE mmap option will act the same as continually
wbinvd execution after writings to that mmaped memory ?With best regards, Mike Gorchak. E-mail: > mike@malva.ua
\
Who said this would be a non event >
Oh, just some curmudgeon who’s always looking on the downside - apart from
him, everyone
seems to be happy!
I had two people in mind I had to look up curmudgeon…
Mario Charest wrote:
Who said this would be a non event >
Oh, just some curmudgeon who’s always looking on the downside - apart from
him, everyone
seems to be happy!
I had two people in mind >
Did I spell it correctly?
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:fcu2vu$o3i$1@inn.qnx.com…
Mario Charest wrote:
Who said this would be a non event >
Oh, just some curmudgeon who’s always looking on the downside - apart
from him, everyone
seems to be happy!
I had two people in mind >Did I spell it correctly? >
According to Webster yes :
http://www.m-w.com/cgi-bin/dictionary?va=curmudgeon
Hey, did anyone else notice that we just got a 1 day turn around on an
enhancement? Sounds like things are changing at QNX.
Mike Gorchak <mike@malva.ua> wrote:
Hello, Colin!
Wow, thank you ! >Colin, do you have also any suggestions about wbinvd x86 cpu instruction
execution (problem was described by me in the previous newsletter in this
group) ? Does PROT_NOCACHE mmap option will act the same as continually
wbinvd execution after writings to that mmaped memory ?
I posted elsewhere – cache control API.
cache_init(), CACHE_FLUSH().
But, yeah, PROT_NOCACHE is like continual flush/invalidate on the
cache for the region so marked.
David Gibbs
QNX Training Services
dagibbs@qnx.com