On Wed, Nov 15, 2000 at 09:37:03AM +0000, Thomas Graichen wrote:
> "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > hi Thomas,
> > On Nov 13, 8:11am, Thomas Graichen wrote:
> >> Subject: Re: stress test on ppc
> >> ...
> >> > ah - I think I see whats happened - there's two -ne tests like
> >> > this & last time I only fixed one ... hopefully its fixed now
> >> > (as of two minutes ago).
> >> ok - reran the tests with your fixes - the current results (with all
> >> the failed .out and .out.bad files) can be found at
> >> http://innominate.org/~graichen/projects/xfs/ppc/ppc.13-11-2000.tgz
> > ok, some progress - looks like the scratch device problem is
> > resolved and test 002 is fixed - great!
> > 004 - this looks like a 32 bit number overflow in the xfs_db
> > "freesp" command, i'll need to investigate a bit more.
> > 018 - ??? no idea - looks like theres a bunch of unexpected
> > records in the log for some reason? bizarre.
> > 020 - attribute syscall code not there in ppc?
> > 026/027/028/046/047 - a reoccurence of the dump/restore problems
> > from Marcelo, Tim/Ivan? or new ones?
> > also group "nobody" assumed to exist, but doesn't. can we change
> > the way the test works, Tim? or exit cleanly if no "nobody" grp?
> > or use numeric gids instead of named groups perhaps?
> > 032 - hmmm... could be a problem in mount(8) code which we use
> > for mkfs.xfs so that it doesn't overwrite other filesystems -
> > can you see whether mount on ppc can autodetect (i.e. mount
> > without "-t" a filesystem created by mkfs.minix on ppc? thanks)
> will try that
> the current results (with fresh kernel and fresh cmd) are at
> but they are at a rough view not really different - by maybe you
> find something in them
> i'm also not really shure about the syscall thing: i added sys_attrctl
> to arch/ppc/kernel/misc.S (where the sys_call_table on ppc is - it's
> not in entry.S here) also as nr 250 (padded with sys_ni_syscall's)
> and also added it to unistd.h and recompiled and installed
> everything and still get things like
> attr_set: Bad address
> which looks like it does still not work - is there any other place i
> have to add an entry for this new syscall?
> a lot of thanks in advance
Could you put a printk at the start of the sys_attrctl function defined
in linux/fs/stat.c, and rerun the QA test 020, or drive the attribute code
directly using xfs_attr, and check whether the printk actually gets called.
If it doesn't then we know for sure it's the syscall that isn't hooked up
correctly. unistd.h and entry.S looked like the only places which needed
to be changed but I may have missed something. If it does hit the the attribute
syscall, then there's a more serious problem somewhere else in the code.
ie can you update sys_attrctl with something like the following:
asmlinkage long sys_attrctl(attr_obj_t obj, int type, attr_op_t *ops, int count)
int error = 0;
struct inode *inode;
struct dentry *dentry;
struct file *f = NULL;
struct nameidata nd;
+ /* PUT PRINTK HERE */
+ printk("sys_attrctl: attribute system call reached\n");
if (count <= 0)
Andrew Gildfind - R&D Software Engineer - SGI PTG Melbourne Australia
email: ajag@xxxxxxxxxxxxxxxxx - work: +61.3.9834.8200 home: +61.3.9421.5335