syscall adressing problem

syscall adressing problem

[Rene Pachernegg]

Hi,
I ve been debugging for more then 1 week now and I hope somebody can
help me with my problem.
Kernel: 2.2.14
Hardware: custom ppc740 board, 16MB RAM, flash card slot
                console via custom bus -> rs485 interface card --> pc
Cross-Compiler:
    binutils 2.9.5.0.37
    gcc-core 2.95.2
    glibc 2.1.3
    glibc-2.1.3-ctype-patch
    glibc-crypt-2.1
    glibc-linuxthreads-2.1.3

I cross-compiled the kernel, sysvinit, agetty, login, sash
Everthing works fine with static linking.
Dynamic linking causes the login to be impossible (Executing the dynamic
linked programs is working fine too). The reason is the following:
login calls getpwnam from glibc to read the passwd file into the
passwd-structure. The glibc its is calling a fopen("/etc/passwd"), which
invokes the syscall sys_open in open.c in the kernel.
When I printk the filename parameter in sys_open (even with
get_from_user) it reads just nonsense. So I checked the adress of the
parameter filename in the kernel and in the glibc, where filename
(/etc/passwd) is a const char. The are identical.

Further searching leaded to the following:
    Sometimes fopen or open syscall work well
    Whenever they dont work they are call from the libc.so and the
filename paramter adresses are 0x0fxxxxxx.

It seems to be something with the dynamic linker, but I have no idea
what exactly. I even changed my cross-compile utilities from
    glibc-2.1.2 --> glibc-2.1.3
    binutils-2.9.5.0.24 -> 2.9.5.0.37

regards,
    Rene


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: syscall adressing problem

[Rene Pachernegg]

Wolfgang Denk wrote:

> In message <3992D331.21C3BD9C@apus.co.at> you wrote:
> >
> > Further searching leaded to the following:
> >     Sometimes fopen or open syscall work well
> >     Whenever they dont work they are call from the libc.so and the
> > filename paramter adresses are 0x0fxxxxxx.
>
> I've seen very similar problems,  but  on  MPC8xx  system  with  more
> current  kernels.  The  reason  was a change in arch/ppc/lib/string.S
> which completely f*cked up the caches (ok - the  MPC8xx  have  smalle
> cache line sizes).
>

Thanks for the quick answer.

My cache line size is the standard 32 byte. As I found in older messages
from the mailing list, these string.S problems concern only unusual cache
line sizes.
Anyway I got the 2.2.6 and the 2.2.13 kernel sources and gave it a try
--> no success.
Then I tried to replace the copy_from_user in sys_open with my own
read_through (flushes cache first, then reads memory) function.  --> no
success.
Actually the strings to be passed to the syscall are readable from
everywhere in user space, but in kernel space it reads just trash at the
same adress.
There are (just my opinion) only two possibilities:
    an adress translation problem in the kernel for adresses < 0x10000000

   something is overwriting the memory space of the string - parameters
for sys_open

regards
    Rene


>
> Try (1) disabling caches; and (2) arch/ppc/lib/string.S from an older
> (2.2.13) kernel version.
>
> It's just a guess, but maybe worth a try.
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> In an infinite universe all things are possible, including the possi-
> bility that the universe does not exist.
>                         - Terry Pratchett, _The Dark Side of the Sun_


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/