[lkml]   [2006]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectLinux porting issue/question...
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

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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-05-16 00:21    [W:0.065 / U:5.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site