I'm in the process of porting the linux kernel to a totally new h/w, and have
gotten most of the stuff to work.
However, I've run into a porting issue, and don't know where else to turn.
There is no gdb, no ICE, not much of anything available at the moment
on this h/w...
Attempting to run a standard 'ls' on a file or device node works fine, even
'ls -al' dumps good values.
However, running 'ls {somedir}' on a directory, any directory, always
returns the error code for "EFAULT" (Bad address), at the user level.
I've been able to trace the code execution into the 'vfs_stat()' kernel call,
but it gets a bit tricky trying to trace the __user_path_walk() function, and
there are some indirect function calls as well, dealing with pulling the inode
information from the fs, etc...BTW, the parameters passed into vfs_stat() do appear
correct.
The one thing that I did fix earlier was the 'struct stat64' structure that the
kernel was using from its 'asm/stat.h' file was grotesquely mismatched with
the 'struct stat64' structure in the glibc-2.3.6's bits/stat.h file, and once I fixed that
mismatch, the major/minor numbers of an 'ls -al /dev/{somedev}' started showing
up correctly. I had hoped that this would have fixed the EFAULT on 'ls {somedir}
as well, but it did not make any difference. I've also verified that the 'struct stat'
in the kernel's asm/stat.h is also synonymous with its counterpart in glibc.
Could anyone point me in a direction that might help debug this somewhat difficult
issue?
Thanks,
John
On Mon, 2006-05-15 at 15:18 -0700, John Z. Bohach wrote:
> However, running 'ls {somedir}' on a directory, any directory, always
> returns the error code for "EFAULT" (Bad address), at the user level.
Hack your copy_to_user() to printk and/or backtrace when it faults.
If that doesn't catch it, find any _other_ place where that call path
can return -EFAULT.
--
dwmw2