I know it's a little offtopic, but i think that the problem is based on
some structural details of linux kernel, so i hope someone will have any
idea..
--I have a strange problem. I'm using a special own-designed hardware with i960CF cpu, and with uClinux 2.0.35 i960 port.
previously i've changed some mail with a guy working with an i960 port, but unfortunately i've lost his email address due to a HD crash. If you are reading this, please answer :)
So my questions (the description of my scenario) :
the kernel seems to boot up properly, with scsi initialization (reads the partition table well) and initrd mounting.
the problem begins with the execve syscall. in the original entry.S at the syscall there was no flushreg, so i placed on there, to save the register contents to memory, but it did not help..
so loading the flat binary is ok, i've dumped the memory and it seems good. calling start_thread fills the pfp of the calling thread to a newly created stack frame, and it seems ok too, according to the dump.
but cpu does not start to execute the code at the new IP, even if the IP is in bios, so the code can't be altered. The curiosity is that it sometimes works - and i don't know why. My idea is that it has something to do with interrupt stack / supervisor stack - but i'm not sure. But when it does not execute the code at the new IP, the CPU hangs, it does not accept IRQ requests, nothing.
previously i had a strange error (now fixed) that bdflush hanged randomly, depending on if the size of the gzipped kernel was odd or even (!) i inserted a code to clear the contents of the whole memory to 0, and now it works stable. strange for me.
Any ideas for solving the 'syscall problem' are welcome, also anything about to previous error mentioned above could be good for me, as it could help me understanding the cause of my problem.
Thanks in advance..
robymus
- 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/