Messages in this thread | | | From | "John Z. Bohach" <> | Subject | Linux porting issue/question... | Date | Mon, 15 May 2006 15:18:53 -0700 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |