[Bug kprobes/2387] system crash on ppc64/2.6.15.4

["zanussi at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From zanussi at us dot ibm dot com  2006-03-02 06:13 -------
(In reply to comment #11)
> > Hmm, where did you put the #define?
> > 
> > I get these warnings if I put it at the bottom of relayfs.h, but putting it at
> > the top, just above 
> > 
> > #ifdef RELAYFS_VERSION_GE_4
> > #include <linux/relayfs_fs.h>
> > ...
> > 
> > it works fine for me...
> 
> the file I used:
> 
> #ifndef _TRANSPORT_RELAYFS_H_ /* -*- linux-c -*- */
> #define _TRANSPORT_RELAYFS_H_
> #define RELAYFS_VERSION_GE_4 
> 
> /** @file relayfs.h
>  * @brief Header file for relayfs transport
>  */
> 
> #ifdef RELAYFS_VERSION_GE_4
> #include <linux/relayfs_fs.h>
> #else
> #include "../relayfs/linux/relayfs_fs.h"
> #endif /* RELAYFS_VERSION_GE_4 */
> 
> struct rchan *_stp_relayfs_open(unsigned n_subbufs,
>                                 unsigned subbuf_size,
>                                 int pid,
>                                 struct dentry **outdir);
> void _stp_relayfs_close(struct rchan *chan, struct dentry *dir);
> 
> #endif /* _TRANSPORT_RELAYFS_H_ */
> 
> So is it due to the gcc version? My gcc is:
> gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
> I checked the codes, and it is just a warning of the assignment:
> int *ptr <--- static int *ptr
> 

I'm using gcc 4.1.0

> But I met another problem, I use my testcase to stress test systemtap:
> 
> -bash-3.00# ./test.sh -f  lgl.cfg  -I tapsets/tapsets1/           
> The tapsets is tapsets/tapsets1/
> don't probe app : dbench
> TIMES : 1
> TIMES : 2
> probe app : dbench
> TIMES : 1
> TIMES : 2
> error opening file stpd_cpu0.
> ERROR: couldn't unlink percpu file stpd_cpu0: errcode = No such file or directory
> 
> Do you have any ideas of such errors? I never met it before.
> I raise the MAXDSKIPPED when running my testcases

No, I haven't seen that before either.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2387

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.