public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Tim Drury <tdrury@siliconmotorsports.com>
To: ecos@navosha.com,
	NavEcos <ecos2@c1830598-a.siliconmotorsports.com>,
	<ecos-discuss@sources.redhat.com>
Subject: [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector)
Date: Mon, 22 Jul 2002 14:14:00 -0000	[thread overview]
Message-ID: <200207221712.21925.tdrury@siliconmotorsports.com> (raw)
In-Reply-To: <02072214052500.07447@c1830598-a>


In the email sent below, why does the From: line appear to be:

From: NavEcos <ecos2@c1830598-a.siliconmotorsports.com>

Which appears to be using my siliconmotorsports.com domain name
with a strange subdomain and an invalid user id?  Did everyone else
see this address or did they get something else munged to look like
it came from their address?

No other email from the ecos lists appears to have done this.  Did
the listserv software do this, or did the poster do this?

-tim drury

On Monday 22 July 2002 05:05 pm, NavEcos wrote:
> Doing it per task is a little more work, I don't see any way to
> determine which task I am in when I'm in the __default_exception_vsr
> routine (system tick interrupt - actually this is the interrupt
> for everything I think for the i386).  I don't think it should be
> hard to determine which task was executing when the interrupt
> happened, but I hadn't planned on doing it.  I bet it can be
> done with a global variables - does anybody know if this is true
> or not, and if it's true - how ?
>
> As to doing it with another interrupt with a higher frequency,
> I agree, but some embedded systems may not have a spare
> timer, so I think a "fall back" should be the system tick.  What
> would be ideal is an interrupt that has a bit of jitter with a
> frequency higher than the system tick.  I am pretty sure that
> vxWorks does it based off from the system tick, but I am not
> 100% certain.
>
> My version also requires : Linux, and a network connection and
> binutils (i.e. readelf and the sort command) since my version is
> a HACK and makes use of external programs.
>
> Many thanks,
> -Rich
>
> P.S. Does anybody know what is wrong with the ecos-devel list?
> Everything I send there is returned as a fatal error.
>
> On Monday 22 July 2002 02:14 pm, benny wrote:
> > I guess such tool (similar to VxWorks SPY) would be great.
> > It actually works "per task" so after a while one can get a list of
> > task CPU consumption. Just the timer needs to be with the higher
> > resolution (some spare timer?)
> > -Benny
> >
> > > -----Original Message-----
> > > From: ecos-discuss-owner@sources.redhat.com
> > > [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of NavEcos
> > > Sent: Monday, July 22, 2002 1:32 PM
> > > To: ecos-discuss@sources.redhat.com
> > > Subject: [ECOS] profiler & memory leak detector
> > >
> > >
> > > Try as I may, I cannot post this to the ecos-devel list, although I am
> > > signed up for it, so I'm going to post it here in the discussion list.
> > >
> > > Has or does anybody use vxWorks?
> > >
> > > If you have, you may have used their profiler.  I have a very simple
> > > profiler that I can make available for the x86 PC target.  I would like
> > > to know if there would be any interest in making such a beast
> > > available in the
> > > main tree?  It requires a modification in the kernel in vectors.S.
> > > Basically, I just detect interrupts with vector 0x20 (the 10 msec
> > > interrupt)
> > > and record the last function the program was in when the periodic
> > > system tick fired.  I know this has some problems, namely anything that
> > > has a delay
> > > is tied to the system tick, but for stressed systems it gives a pretty
> > > accurate view of what functions you have to streamline.
> > >
> > > VxWorks also has a tool called memtool.  It just detects which
> > > functions (and if memory serves tasks) allocate and dealloc memory and
> > > in which heap.
> > > This is useful for detecting memory leaks although not extremely
> > > useful.  I
> > > don't have a similar tool, but I can make one.
> > >
> > > Is there any interest in putting these into the main tree?
> > > Putting in HOOKS
> > > to do it is very easy, and I would like to do that if there is
> > > any interest
> > > in incorporating it into the main tree.
> > >
> > > The profiler is very architecture dependant so I need help making
> > > that work
> > > for other platforms than x86 PC.
> > >
> > > -Rich
> > >
> > >
> > > --
> > > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > > and search the list archive: http://sources.redhat.com/ml/ecos-discuss


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

  reply	other threads:[~2002-07-22 21:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-22 12:27 [ECOS] profiler & memory leak detector NavEcos
2002-07-22 13:15 ` benny
2002-07-22 14:01   ` NavEcos
2002-07-22 14:14     ` Tim Drury [this message]
2002-07-22 14:20       ` [ECOS] Re: OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector) NavEcos
2002-07-22 14:21       ` [ECOS] " Gary Thomas
2002-07-23  0:41     ` [ECOS] profiler & memory leak detector Martin Buck
2002-07-22 14:18 [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector) Dan Conti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200207221712.21925.tdrury@siliconmotorsports.com \
    --to=tdrury@siliconmotorsports.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=ecos2@c1830598-a.siliconmotorsports.com \
    --cc=ecos@navosha.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).