Your logs show, the incriminated address occurs very regularely.

In my kernel version line 541 number suggests, that the address
is trapped after the sprintf().

  pipe.c
  514  trap_bit31_cache_tag(__LINE__,"do_pipe",name);
       ...
  539  trap_bit31_cache_tag(__LINE__,"do_pipe",name);
  540      sprintf(name, "[%lu]", inode->i_ino);
  541  trap_bit31_cache_tag(__LINE__,"do_pipe",name);
  542      this.name = name;
  543      this.len = strlen(name);
  544      this.hash = inode->i_ino; /* will go */
  545  trap_bit31_cache_tag(__LINE__,"do_pipe",name);
  546      dentry = d_alloc(pipe_mnt->mnt_sb->s_root, &this);
       ...

Line 594 in dcache.c is the location of the 1st trap in d_alloc().
Are these the same trap_... in your version ?

If so, the address may be generated in vsprintf (&buf[0x7fffffff]).
But then: how does it go from register $17 to $13 ? Couldn't find
any place for that.  (And how can one of these registers cause the
exception in memcpy, while neither is used there ?)

I expected, that trapping the address would cause an Oops (by the
i = *(int*)0; statement), what obviously doesn't happen.  So either
each trap (of the thousands) silently aborts a process or it simply
returns ?  But in the latter case there should be more different
line numbers (e.g. sequence 541,545,594).
In the 1st case the invalid address also shows up in d_alloc, when
d_alloc is called from somewhere else than do_pipe.

Guess, i better give up hunting for these addresses and concentrate
on studying the gcc sources instead...
(But some preventive cache barriers in vsprintf and memcpy would be
good anyway)


Thank You for your patience !

pf


On Sat, 7 Aug 2004, Kumba wrote:

> > Date: Sat, 07 Aug 2004 03:59:58 -0400
> > From: Kumba <kumba@gentoo.org>
> > To: pf@net.alphadv.de
> > Subject: Re: IP28 Patch
> > 
> > ...
> > I included data in the attached file up to the first merge of the 
> > ...