Re: [Xenomai-help] SH4 port

Re: [Xenomai-help] SH4 port

[Kiichi Kameda]

[-- Attachment #1: Type: text/plain, Size: 3743 bytes --]


Thank you for your effort.

> Jan Kiszka wrote:
> > Kiichi Kameda wrote:
> >> ...
> >> After tough investigation, I think I found some clues such as:
> >> While in.ftpd runs hard, a "write" system call was issued and Linux
> >> kernel was processing its request.
> >>  But weird __ipipe_dispatch_event and __ipipe_sync_stage was recorded.
> >>
> >> I think the problem originates from a Xenomai context switch(which
> >> overwrites "current"), while Linux is processing  system call.
> >
> > If I interpret linux/include/asm-sh/current.h correctly, current is
> > derived from the stack on your platform (like on most archs) and cannot
>
> That's nonsense as I realised later by following the code down to
> include/asm-sh/thread_info.h: current_thread_info seems to get
> referenced by some register.

In original SH-Linux ,"current" is based on r7_bank register in SH CPU
 which is set only at context switch.  "current" macro which is
referenced everywhere(including page fault handling and stack pointer
setting
at interrupt from userspace), depends on this special register.
r7_bank register has nothing to do with stack.

So, I created modified version of  SH-Linux code , where "current" macro
uses
the stack pointer(SP & ~(THREAD_SIZE) -1).
After that, although Linux seems to work well, the Xenomai thread still
causes system panic, if I once run the Xenomai program that uses POSIX skin.

The panic messsage:
==========================================
Unable to handle kernel paging request. at virtual address 00100104
pc = 8c010658 <--requeue_task
*pde = 00000000
Oops: 0001 [#1]

Pid : 948, Comm:              in.ftpd
PC  : 8c010658 SP  : 8debfab0 SR  : 40008101 .TEA : c0198044    .Not
tainted
R0  : 8c19e958 R1  : 8c19ed10 R2  : 00100100 R3  : 00200200
R4  : 8c2769a0 R5  : 8c19e958 R6  : 00000050 R7  : 8c2769c0
R8  : 8c2769a0 R9  : 00000000 R10 : 00000050 R11 : 8c2769a0
R12 : 8c2769e0 R13 : 8c19e928 R14 : 8debfab0
MACH: 0000027e MACL: b851edb4 GBR : 29568be0 PR  : 8c0112b6.
Call trace:
== top
[<8c0112b6>] scheduler_tick
[<8c0d4d88>] smc_hard_start_xmit
[<8c00eb38>] __do_page_fault
[<8c01f828>] update_process_time
[<8c009988>] handle_timer_tick
[<8c00bd72>] tmu_timer_interrupt
[<8c03303a>] handle_IRQ_event
[<8c0330fa>] __do_IRQ
[<8c00d0f6>] __ipipe_do_IRQ
[<8c0342e4>] __ipipe_sync_stage
[<8c00d146>] __ipipe_grab_timer
[<8c010582>] dequeue_task
[<8c010876>] deactivate_task
[<8c1505d6>] schedule
[<8c15134c>] io_schedule
[<8c036406>] sync_page
[<8c151736>] __wait_on_bit_lock
[<8c036d90>] __lock_page
[<8c038050>] file_map_nopage
[<8c0444aa>] __handle_mm_fault
[<8c00e7f0>] do_page_fault
[<8c0af240>] csum_partial_copy_generic
[<8c125b64>] tcp_sendmsg
[<8c141c14>] inet_sendmsg
[<8c0f97f6>] do_sock_write
[<8c0f98ec>] sock_aio_write
[<8c01f74c>] run_timer_softirq
[<8c04e6ba>] do_sync_write
[<8c0343f6>] __ipipe_dispatch_event
[<8c04e78a>] vfs_write
[<8c04e8f4>] sys_write
[<8c0062c4>] syscall_call
== bottom
Kernel panic - not syncing: Aiee, killing interrupt handler!..
==========================================

Is it right that, while in.ftpd tries to send TCP packet,
scheduler_tick is called and requeue_task the "current" task?

Or, is threre any lack of code at returning to Linux.

>
> Still the question remains for me why this should be a general Xenomai
> problem. Xenomai may overwrite the content on switch_to (but I don't
> know your patch, how you realised context switches between RT tasks on
> SH4), but then it should definitely also restore it again on returning
> to Linux.
>
> Jan
>

Attached is some SH-related code.

xenomai-2.2.0/ksrc/arch/sh/*
xenomai-2.2.0/include/asm-sh/*
linux-2.6.17.7/arch/sh/kernel/*
linux-2.6.17.7/arch/sh/mm/*
linux-2.6.17.7/include/asm-sh/*

Thanks,
Kiichi Kameda

[-- Attachment #2: linux-sh.tar.gz --]
[-- Type: application/x-gzip, Size: 321734 bytes --]

[-- Attachment #3: xenomai-sh.tar.gz --]
[-- Type: application/x-gzip, Size: 17928 bytes --]

Re: [Xenomai-help] SH4 port

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4964 bytes --]

Kiichi Kameda wrote:
> Thank you for your effort.
> 
>> Jan Kiszka wrote:
>>> Kiichi Kameda wrote:
>>>> ...
>>>> After tough investigation, I think I found some clues such as:
>>>> While in.ftpd runs hard, a "write" system call was issued and Linux
>>>> kernel was processing its request.
>>>>  But weird __ipipe_dispatch_event and __ipipe_sync_stage was recorded.
>>>>
>>>> I think the problem originates from a Xenomai context switch(which
>>>> overwrites "current"), while Linux is processing  system call.
>>> If I interpret linux/include/asm-sh/current.h correctly, current is
>>> derived from the stack on your platform (like on most archs) and cannot
>> That's nonsense as I realised later by following the code down to
>> include/asm-sh/thread_info.h: current_thread_info seems to get
>> referenced by some register.
> 
> In original SH-Linux ,"current" is based on r7_bank register in SH CPU
>  which is set only at context switch.  "current" macro which is
> referenced everywhere(including page fault handling and stack pointer
> setting
> at interrupt from userspace), depends on this special register.
> r7_bank register has nothing to do with stack.

Yep, that's what I understood as well meanwhile.

> 
> So, I created modified version of  SH-Linux code , where "current" macro
> uses
> the stack pointer(SP & ~(THREAD_SIZE) -1).
> After that, although Linux seems to work well, the Xenomai thread still
> causes system panic, if I once run the Xenomai program that uses POSIX skin.

And that's something I do not understand. What was your idea behind this
step?

> 
> The panic messsage:
> ==========================================
> Unable to handle kernel paging request. at virtual address 00100104
> pc = 8c010658 <--requeue_task
> *pde = 00000000
> Oops: 0001 [#1]
> 
> Pid : 948, Comm:              in.ftpd
> PC  : 8c010658 SP  : 8debfab0 SR  : 40008101 .TEA : c0198044    .Not
> tainted
> R0  : 8c19e958 R1  : 8c19ed10 R2  : 00100100 R3  : 00200200
> R4  : 8c2769a0 R5  : 8c19e958 R6  : 00000050 R7  : 8c2769c0
> R8  : 8c2769a0 R9  : 00000000 R10 : 00000050 R11 : 8c2769a0
> R12 : 8c2769e0 R13 : 8c19e928 R14 : 8debfab0
> MACH: 0000027e MACL: b851edb4 GBR : 29568be0 PR  : 8c0112b6.
> Call trace:
> == top
> [<8c0112b6>] scheduler_tick
> [<8c0d4d88>] smc_hard_start_xmit
> [<8c00eb38>] __do_page_fault
> [<8c01f828>] update_process_time
> [<8c009988>] handle_timer_tick
> [<8c00bd72>] tmu_timer_interrupt
> [<8c03303a>] handle_IRQ_event
> [<8c0330fa>] __do_IRQ
> [<8c00d0f6>] __ipipe_do_IRQ
> [<8c0342e4>] __ipipe_sync_stage
> [<8c00d146>] __ipipe_grab_timer
> [<8c010582>] dequeue_task
> [<8c010876>] deactivate_task
> [<8c1505d6>] schedule
> [<8c15134c>] io_schedule
> [<8c036406>] sync_page
> [<8c151736>] __wait_on_bit_lock
> [<8c036d90>] __lock_page
> [<8c038050>] file_map_nopage
> [<8c0444aa>] __handle_mm_fault
> [<8c00e7f0>] do_page_fault
> [<8c0af240>] csum_partial_copy_generic
> [<8c125b64>] tcp_sendmsg
> [<8c141c14>] inet_sendmsg
> [<8c0f97f6>] do_sock_write
> [<8c0f98ec>] sock_aio_write
> [<8c01f74c>] run_timer_softirq
> [<8c04e6ba>] do_sync_write
> [<8c0343f6>] __ipipe_dispatch_event
> [<8c04e78a>] vfs_write
> [<8c04e8f4>] sys_write
> [<8c0062c4>] syscall_call
> == bottom
> Kernel panic - not syncing: Aiee, killing interrupt handler!..
> ==========================================
> 
> Is it right that, while in.ftpd tries to send TCP packet,
> scheduler_tick is called and requeue_task the "current" task?
> 
> Or, is threre any lack of code at returning to Linux.
> 
>> Still the question remains for me why this should be a general Xenomai
>> problem. Xenomai may overwrite the content on switch_to (but I don't
>> know your patch, how you realised context switches between RT tasks on
>> SH4), but then it should definitely also restore it again on returning
>> to Linux.
>>
>> Jan
>>
> 
> Attached is some SH-related code.
> 
> xenomai-2.2.0/ksrc/arch/sh/*
> xenomai-2.2.0/include/asm-sh/*
> linux-2.6.17.7/arch/sh/kernel/*
> linux-2.6.17.7/arch/sh/mm/*
> linux-2.6.17.7/include/asm-sh/*

Hmm, not very handy for a review. Also the ipipe patch is missing.
Please post future revisions as real patches (one for ipipe against the
vanilla kernel, one for Xenomai against SVN, preferably trunk).

Anyway, poking into (probably) the heart of the problem I stumbled over
this:

[ksrc/arch/sh/switch.c]

void rthal_switch_to(xnarchtcb_t *prev, xnarchtcb_t *next)
{
...
        /*
         * Restore the kernel mode register
         *      k7 (r7_bank1)
         */
	if(next->user_task) {

            asm volatile("ldc       %0, r5_bank"
                     : /* no output */
                     : "r" (next->user_task->thread_info));
	}

Is there a particular reason why comment and reality diverge regarding
the thread_info register? Could this cause your troubles?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] SH4 port

[Kiichi Kameda]

> >
> > So, I created modified version of  SH-Linux code , where "current" macro
> > uses
> > the stack pointer(SP & ~(THREAD_SIZE) -1).
> > After that, although Linux seems to work well, the Xenomai thread still
> > causes system panic, if I once run the Xenomai program that uses POSIX
> skin.
>
> And that's something I do not understand. What was your idea behind this
> step?
>

Just a try , because I realized overwriting "current" may not be right way.


>
> [ksrc/arch/sh/switch.c]
>
> void rthal_switch_to(xnarchtcb_t *prev, xnarchtcb_t *next)
> {
> ...
>         /*
>          * Restore the kernel mode register
>          *      k7 (r7_bank1)
>          */
>  if(next->user_task) {
>
>             asm volatile("ldc       %0, r5_bank"
>                      : /* no output */
>                      : "r" (next->user_task->thread_info));
>  }
>
> Is there a particular reason why comment and reality diverge regarding
> the thread_info register? Could this cause your troubles?
>

I'm sorry, the comment is wrong.
The code that uses r7_bank  results in overwriting "current".
To avoid this,  I changed  from r7_bank to r5_bank for Xenomai context
switch .
Also, I added to the Linux context switch code  so that thread_info is set
in r5_bank register  as well as in r7_bank regsiter.
r5_bank register is referenced in the page fault handling code.

Kiichi Kameda

Re: [Xenomai-help] SH4 port

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

Kiichi Kameda wrote:
>> [ksrc/arch/sh/switch.c]
>>
>> void rthal_switch_to(xnarchtcb_t *prev, xnarchtcb_t *next)
>> {
>> ...
>>         /*
>>          * Restore the kernel mode register
>>          *      k7 (r7_bank1)
>>          */
>>  if(next->user_task) {
>>
>>             asm volatile("ldc       %0, r5_bank"
>>                      : /* no output */
>>                      : "r" (next->user_task->thread_info));
>>  }
>>
>> Is there a particular reason why comment and reality diverge regarding
>> the thread_info register? Could this cause your troubles?
>>
> 
> I'm sorry, the comment is wrong.
> The code that uses r7_bank  results in overwriting "current".

What code is it?

> To avoid this,  I changed  from r7_bank to r5_bank for Xenomai context
> switch .

Wouldn't it be better to avoid that overwriting in the first place
instead of escaping from it? You may not be safe from code running on
behalf of a Xenomai user-space thread that assumes current is still in
r7_bank.

> Also, I added to the Linux context switch code  so that thread_info is set
> in r5_bank register  as well as in r7_bank regsiter.
> r5_bank register is referenced in the page fault handling code.

The handling code of Xenomai or Linux?

The goal must be that the environment for a shadowed Xenomai thread
looks (almost) like that of a normal Linux thread. If there is Xenomai
code that messes this up on SH4, this has to be fixed. Patching Linux
Linux outside the I-pipe context indicates that something is wrong with
the design. This is what I can say from my distant POV without knowing
the specific issues of SH4.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] SH4 port

[Kiichi Kameda]

> Kiichi Kameda wrote:
> >> [ksrc/arch/sh/switch.c]
> >>
> >> void rthal_switch_to(xnarchtcb_t *prev, xnarchtcb_t *next)
> >> {
> >> ...
> >>         /*
> >>          * Restore the kernel mode register
> >>          *      k7 (r7_bank1)
> >>          */
> >>  if(next->user_task) {
> >>
> >>             asm volatile("ldc       %0, r5_bank"
> >>                      : /* no output */
> >>                      : "r" (next->user_task->thread_info));
> >>  }
> >>
> >> Is there a particular reason why comment and reality diverge regarding
> >> the thread_info register? Could this cause your troubles?
> >>
> >
> > I'm sorry, the comment is wrong.
> > The code that uses r7_bank  results in overwriting "current".
>
> What code is it?

Above code(rthal_switch_to) is derived from Linux, which uses r7_bank.
At first I used r7_bank  in rthal_switch_to , but this code caused panic.

>
> > To avoid this,  I changed  from r7_bank to r5_bank for Xenomai context
> > switch .
>
> Wouldn't it be better to avoid that overwriting in the first place
> instead of escaping from it? You may not be safe from code running on
> behalf of a Xenomai user-space thread that assumes current is still in
> r7_bank.
>
> > Also, I added to the Linux context switch code  so that thread_info is
set
> > in r5_bank register  as well as in r7_bank regsiter.
> > r5_bank register is referenced in the page fault handling code.
>
> The handling code of Xenomai or Linux?

There exists only one page fault handling code for both Xenomai and Linux.
Is this a problem?

>
> The goal must be that the environment for a shadowed Xenomai thread
> looks (almost) like that of a normal Linux thread. If there is Xenomai
> code that messes this up on SH4, this has to be fixed. Patching Linux
> Linux outside the I-pipe context indicates that something is wrong with
> the design. This is what I can say from my distant POV without knowing
> the specific issues of SH4.
>

Yes I think so too.

Re: [Xenomai-help] SH4 port

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]

Kiichi Kameda wrote:
>> Kiichi Kameda wrote:
>>>> [ksrc/arch/sh/switch.c]
>>>>
>>>> void rthal_switch_to(xnarchtcb_t *prev, xnarchtcb_t *next)
>>>> {
>>>> ...
>>>>         /*
>>>>          * Restore the kernel mode register
>>>>          *      k7 (r7_bank1)
>>>>          */
>>>>  if(next->user_task) {
>>>>
>>>>             asm volatile("ldc       %0, r5_bank"
>>>>                      : /* no output */
>>>>                      : "r" (next->user_task->thread_info));
>>>>  }
>>>>
>>>> Is there a particular reason why comment and reality diverge regarding
>>>> the thread_info register? Could this cause your troubles?
>>>>
>>> I'm sorry, the comment is wrong.
>>> The code that uses r7_bank  results in overwriting "current".
>> What code is it?
> 
> Above code(rthal_switch_to) is derived from Linux, which uses r7_bank.
> At first I used r7_bank  in rthal_switch_to , but this code caused panic.

Why? Rhetorical questions. The point is you need to understand the
mechanisms preventing this to work because it looks to me like this is
the way to go.

Was there anything else that denies invoking the original Linux
__switch_to directly? That should be preferred if feasible.

> 
>>> To avoid this,  I changed  from r7_bank to r5_bank for Xenomai context
>>> switch .
>> Wouldn't it be better to avoid that overwriting in the first place
>> instead of escaping from it? You may not be safe from code running on
>> behalf of a Xenomai user-space thread that assumes current is still in
>> r7_bank.
>>
>>> Also, I added to the Linux context switch code  so that thread_info is
> set
>>> in r5_bank register  as well as in r7_bank regsiter.
>>> r5_bank register is referenced in the page fault handling code.
>> The handling code of Xenomai or Linux?
> 
> There exists only one page fault handling code for both Xenomai and Linux.
> Is this a problem?

Xenomai normally only has a hook here to suspend RT threads on faults
and/or migrate them to Linux. I just didn't know if you had to develop
something special for SH4.

> 
>> The goal must be that the environment for a shadowed Xenomai thread
>> looks (almost) like that of a normal Linux thread. If there is Xenomai
>> code that messes this up on SH4, this has to be fixed. Patching Linux
>> Linux outside the I-pipe context indicates that something is wrong with
>> the design. This is what I can say from my distant POV without knowing
>> the specific issues of SH4.
>>
> 
> Yes I think so too.
> 
> 
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Xenomai-help] SH4 port

[Kiichi Kameda]

After long break, I started testing SH4 port of Xenomai based on Xenomai
2.2.0

My realtime test program is a user space program using POSIX skin , and
runs periodically (1ms interval)

It works well when the load is light.
But with very heavy load such as continuous FTP, the system hangs in several
minutes,
due to panic.

the stack trace shows as follows

======================================================
Unable to handle kernel NULL pointer dereference. at virtual address
00000000
pc = 8c0104a6 <-- dequeue_task
*pde = 00000000
Oops: 0000 [#1]

Pid : 944, Comm:              in.ftpd
PC  : 8c0104a6 SP  : 8d631c00 SR  : 40008101 .TEA : c0198044    .Not
tainted
R0  : 8c19a928 R1  : 8c0104a0 R2  : 00000000 R3  : 8d5db680
R4  : 8d5db680 R5  : 00000000 R6  : 00000000 R7  : 8d5db788
R8  : 8d5db680 R9  : fffffffb R10 : 8d631c9c R11 : 8d5db680
R12 : e9bbfd00 R13 : 000f422e R14 : 8d631c08
MACH: 0000027f MACL: 5c28f7f2 GBR : 29568be0 PR  : 8c0107b6.
Call trace:
===top of stack(8d631c00)
[<8c0107b6>] deactivate_task
[<8c14d616>] schedule
[<8c14e38c>] io_schedule
[<8c035106>] sync_page
[<8c14e776>] __wait_on_bit_lock
[<8c035a64>] __lock_page
[<8c036d10>] filemap_nopage
[<8c04306a>] __handle_mm_fault
[<8c0d98ee>] ide_set_handler
[<8c00e750>] do_page_fault
[<8c0ac7dc>] csum_partial_copy_generic
[<8c122d04>] tcp_sendmsg
[<8c0d79f2>] ide_do_request
[<8c13ed74>] inet_sendmsg
[<8c0f69f6>] do_sock_write
[<8c04cc00>] wait_on_retry_sync_kiocb
[<8c0f6aec>] sock_aio_write
[<8c04cf1a>] do_sync_write
[<8c033024>] __ipipe_sync_stage
[<8c02a320>] autoremove_wake_function
[<8c033136>] __ipipe_dispatch_event
[<8c04cfea>] vfs_write
[<8c04d134>] sys_write
[<8c0062bc>] syscall_call
[<8c04d100>] sys_write
===bottom of stack
======================================================

After tough investigation, I think I found some clues such as:
While in.ftpd runs hard, a "write" system call was issued and Linux
kernel was processing its request.
 But weird __ipipe_dispatch_event and __ipipe_sync_stage was recorded.

I think the problem originates from a Xenomai context switch(which
overwrites "current"), while Linux is processing  system call.
and I am sure that some tricks (preventing such case) must be included
on other platforms.

Any suggestions on preventing such panic?

thank you,
Kiichi Kameda

Re: [Xenomai-help] SH4 port

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

Kiichi Kameda wrote:
> After long break, I started testing SH4 port of Xenomai based on Xenomai
> 2.2.0

Nice to hear.

> 
> My realtime test program is a user space program using POSIX skin , and
> runs periodically (1ms interval)
> 
> It works well when the load is light.
> But with very heavy load such as continuous FTP, the system hangs in several
> minutes,
> due to panic.
> 
> the stack trace shows as follows
> 
> ======================================================
> Unable to handle kernel NULL pointer dereference. at virtual address
> 00000000
> pc = 8c0104a6 <-- dequeue_task
> *pde = 00000000
> Oops: 0000 [#1]
> 
> Pid : 944, Comm:              in.ftpd
> PC  : 8c0104a6 SP  : 8d631c00 SR  : 40008101 .TEA : c0198044    .Not
> tainted
> R0  : 8c19a928 R1  : 8c0104a0 R2  : 00000000 R3  : 8d5db680
> R4  : 8d5db680 R5  : 00000000 R6  : 00000000 R7  : 8d5db788
> R8  : 8d5db680 R9  : fffffffb R10 : 8d631c9c R11 : 8d5db680
> R12 : e9bbfd00 R13 : 000f422e R14 : 8d631c08
> MACH: 0000027f MACL: 5c28f7f2 GBR : 29568be0 PR  : 8c0107b6.
> Call trace:
> ===top of stack(8d631c00)
> [<8c0107b6>] deactivate_task
> [<8c14d616>] schedule
> [<8c14e38c>] io_schedule
> [<8c035106>] sync_page
> [<8c14e776>] __wait_on_bit_lock
> [<8c035a64>] __lock_page
> [<8c036d10>] filemap_nopage
> [<8c04306a>] __handle_mm_fault
> [<8c0d98ee>] ide_set_handler
> [<8c00e750>] do_page_fault
> [<8c0ac7dc>] csum_partial_copy_generic
> [<8c122d04>] tcp_sendmsg
> [<8c0d79f2>] ide_do_request
> [<8c13ed74>] inet_sendmsg
> [<8c0f69f6>] do_sock_write
> [<8c04cc00>] wait_on_retry_sync_kiocb
> [<8c0f6aec>] sock_aio_write
> [<8c04cf1a>] do_sync_write
> [<8c033024>] __ipipe_sync_stage
> [<8c02a320>] autoremove_wake_function
> [<8c033136>] __ipipe_dispatch_event
> [<8c04cfea>] vfs_write
> [<8c04d134>] sys_write
> [<8c0062bc>] syscall_call
> [<8c04d100>] sys_write
> ===bottom of stack
> ======================================================
> 
> After tough investigation, I think I found some clues such as:
> While in.ftpd runs hard, a "write" system call was issued and Linux
> kernel was processing its request.
>  But weird __ipipe_dispatch_event and __ipipe_sync_stage was recorded.
> 
> I think the problem originates from a Xenomai context switch(which
> overwrites "current"), while Linux is processing  system call.

If I interpret linux/include/asm-sh/current.h correctly, current is
derived from the stack on your platform (like on most archs) and cannot
be "overwritten". True is that the stack may change, making current
invalid, when running a Xenomai kernel-space task. But this is something
both I-pipe and Xenomai has to take into account (and do so on other archs).

> and I am sure that some tricks (preventing such case) must be included
> on other platforms.
> 
> Any suggestions on preventing such panic?

I guess you have to understand it more thoroughly first - or I'm not yet
getting the generic part of your problem.

However, did you try the switchtest already? It performs all kind of
switches to trigger potential issues with saving/restoring contexts.

And finally: Do we have a chance to see your patch soon? Even if it's
not mature yet, it helps to look at the code when we shall help you
analysing the issues. Don't forget good open source is based on peer
review, and I can only recommend to make use of this mechanism early
(the many-eyes principle...).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] SH4 port

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

Jan Kiszka wrote:
> Kiichi Kameda wrote:
>> ...
>> After tough investigation, I think I found some clues such as:
>> While in.ftpd runs hard, a "write" system call was issued and Linux
>> kernel was processing its request.
>>  But weird __ipipe_dispatch_event and __ipipe_sync_stage was recorded.
>>
>> I think the problem originates from a Xenomai context switch(which
>> overwrites "current"), while Linux is processing  system call.
> 
> If I interpret linux/include/asm-sh/current.h correctly, current is
> derived from the stack on your platform (like on most archs) and cannot

That's nonsense as I realised later by following the code down to
include/asm-sh/thread_info.h: current_thread_info seems to get
referenced by some register.

Still the question remains for me why this should be a general Xenomai
problem. Xenomai may overwrite the content on switch_to (but I don't
know your patch, how you realised context switches between RT tasks on
SH4), but then it should definitely also restore it again on returning
to Linux.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]