Phillipe, Can you tell me how exactly unexpected cloberring take place, what is effect on timers and scheduler. Also I would like to know during the course of returning from __ipipe_handle_irq/__ipipe_grab_irq, if it is a root_domain and root domains is stalled, what will be the effect of this on my scheduler or entire system.
Regards Subbu On 1/17/07, Philippe Gerum <[EMAIL PROTECTED]> wrote:
On Wed, 2007-01-17 at 20:30 +0530, Subramani Venkatesh wrote: > Phillipe, > I will surely look into this, so far local_irq_enable/disable i.e > unstall and stall routines did not cause problem in my assembly code. > But I was facing this particular system call issue due to use of stack > as arguments to the __ipipe_syscall_root and also in my case the > venilla kernel is using the same register for syscall number and > return value, during this case when Iam trying to save intial system > call number on stack and once __ipipe_syscall_root is done I am > reading it back, this may be corrupting stack, so I think I need to > put more effort to resolve this and oragnize it. > BTW phillipe at this stage can I go testing timer interrupts using by > other domain, which registers as priority domain than linux ? If the interrupt exit path does not suffer from unexpected register cloberring, yes. > > Regards > Subbu > > > On 1/17/07, Philippe Gerum <[EMAIL PROTECTED]> wrote: > On Wed, 2007-01-17 at 16:23 +0530, Subramani Venkatesh wrote: > > Hello Philippe, > > I would like to thank you once again for the HINT. > > Now I avoided changes to system call calling > __ipipe_syscall_root from > > my assembly code and tested the same, well it not giving any > errors as > > sent you yesterday, this concludes there is a problem in a > way of > > calling __ipipe_syscall_root, I guess my stack is getting > corrupted, i > > will make sure my stack is saved before calling > __ipipe_syscall_root > > and resolve the issues. > > You should also check whether substituting inline code from > asmmacro.h > like local_irq_enable/disable with the I-pipe stall/unstall > calls had > any bad side-effect on the register set. Maybe t0 is not the > only > register affected by such operations anymore. > > > I thank you once again. > > > > Cheers > > Subbu > > > > On 1/16/07, Philippe Gerum < [EMAIL PROTECTED]> wrote: > > On Tue, 2007-01-16 at 15:49 +0530, Subramani > Venkatesh wrote: > > > Hello All, > > > I am currently porting Adeos-ipipe on one of my > MIPS > > architecture. I > > > am using I-Pipe 1.5-01, X86 as reference to my > porting. So > > Far I did > > > relevant changes in > > > 1.Interrupts handlers > > > 2. System calls > > > 3. Pagefault Handler > > > Except Exception handling, I mean critcial bug > events. > > > With this changes I am able to Boot Linux kernel > and also > > able to > > > mount Ramdisk successfully. > > > > > > > [...] > > > > > Opening console is successfull and > executing /sbin/init > > > Algorithmics/MIPS FPU Emulator v1.5 > > > INIT: version 2.85 booting > > > grep: error while loading shared libraries: > libc.so.6: > > failed to map > > > segment from shared object: Error 4090 > > > > There is likely something fishy in the syscall > interception > > path from > > arch/mips/kernel/entry.S; all the syscalls seem to > return > > error values > > mistakenly once the pipelining is in effect. You may > want to > > check your > > changes in this area. > > > > Btw, it would be nice to work in an open manner and > post your > > code on > > this list if you want to ask for help about it > here. > > Contribution has to > > work both ways. TIA, > > > > -- > > Philippe. > > > > > > > -- > Philippe. > > > -- Philippe.
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
