weird behavior from kernel

weird behavior from kernel

[James Yu]

Hi folks,

I am modifying linux-2.4.18 for ARM (based on S3C2410), I enable only
the timer interrupt and disable all the others in "init" thread before
"execve("/sbin/init",argv_init,envp_init);" is taking place.
I also create two kernel threads by invoking "kernel_thread" right
after disbling the interrupts. This is how the kernel thread looks
like:

        923 void eos_1(void)
-       924 {
|       925     DECLARE_WAITQUEUE(wait, current);
|       926
|       927     while (1)
|-      928     {
||      929         printk("\n%s[%d], period:%d, deadline:%d, jiffies:%d.\n",
||      930                 current->comm, current->pid,
current->period, current->deadline, jiffies);
||      931         eos_tail();
||      932     }
|       933 }

        905 #define eos_tail() \
-       906 do { \
|       907     static int deadline = 0; \
|       908     if ((current->deadline - jiffies) > 0) \
|-      909     { \
||      910         deadline = current->deadline; \
||      911         current->deadline = deadline + current->period; \
||      912         sleep_on_timeout(&wait, (deadline - jiffies)); \
||      913     } \
|       914     else \
|-      915     { \
||      916         printk("\n!!! %s[%d] missed deadline !!!\n",
current->comm, current->pid); \
||      917         return (0); \
||      918     } \
|       919 } while(0)

Now I am trying to modify the "schedule" function. I insert the
following segment into schedule function after the part that
re-calculate counters --> if(unlikely(!c)).

|-      634         {
||      635             int latch = 0;
||      636
||      637             list_for_each(tmp, &runqueue_head)
||-     638             {
|||     639                 //p = list_entry(tmp, struct task_struct, run_list);
|||     640                 latch = latch + 1;
|||     641             }
||      642             printk("{%d}", latch);
||      643         }

This is where weird thing happens! If I uncomment line 639, kernel
complains that I am passing an illegal value into "sleep_on_timeout",
which is called in my kernel thread inside "eos_tail". I copy both
line 637 and 639 from schedule itself (they were used to pick next job
to run).

I am simply doing copy & paste inside "schedule", can someone please
tell me what is happening ?

Thanks a lot,
--
James
cyu021@gmail.com

Re: weird behavior from kernel

[Willy Tarreau]

On Sun, Mar 12, 2006 at 11:23:17AM +0800, James Yu wrote:
> Hi folks,
> 
> I am modifying linux-2.4.18 for ARM (based on S3C2410), I enable only
> the timer interrupt and disable all the others in "init" thread before
> "execve("/sbin/init",argv_init,envp_init);" is taking place.
> I also create two kernel threads by invoking "kernel_thread" right
> after disbling the interrupts. This is how the kernel thread looks
> like:
> 
>         923 void eos_1(void)
> -       924 {
> |       925     DECLARE_WAITQUEUE(wait, current);
> |       926
> |       927     while (1)
> |-      928     {
> ||      929         printk("\n%s[%d], period:%d, deadline:%d, jiffies:%d.\n",
> ||      930                 current->comm, current->pid,
> current->period, current->deadline, jiffies);
> ||      931         eos_tail();
> ||      932     }
> |       933 }
> 
>         905 #define eos_tail() \
> -       906 do { \
> |       907     static int deadline = 0; \
> |       908     if ((current->deadline - jiffies) > 0) \
> |-      909     { \
> ||      910         deadline = current->deadline; \
> ||      911         current->deadline = deadline + current->period; \
> ||      912         sleep_on_timeout(&wait, (deadline - jiffies)); \
> ||      913     } \
> |       914     else \
> |-      915     { \
> ||      916         printk("\n!!! %s[%d] missed deadline !!!\n",
> current->comm, current->pid); \
> ||      917         return (0); \
> ||      918     } \
> |       919 } while(0)
> 
> Now I am trying to modify the "schedule" function. I insert the
> following segment into schedule function after the part that
> re-calculate counters --> if(unlikely(!c)).
> 
> |-      634         {
> ||      635             int latch = 0;
> ||      636
> ||      637             list_for_each(tmp, &runqueue_head)
> ||-     638             {
> |||     639                 //p = list_entry(tmp, struct task_struct, run_list);
> |||     640                 latch = latch + 1;
> |||     641             }
> ||      642             printk("{%d}", latch);
> ||      643         }
> 
> This is where weird thing happens! If I uncomment line 639, kernel
> complains that I am passing an illegal value into "sleep_on_timeout",
> which is called in my kernel thread inside "eos_tail". I copy both
> line 637 and 639 from schedule itself (they were used to pick next job
> to run).
> 
> I am simply doing copy & paste inside "schedule", can someone please
> tell me what is happening ?

It might be a wrong gcc optimization which generates bad code. If you're
working on such an old kernel (about 5 years old), maybe you're using
and old, broken compiler too ? gcc-2.95[.1], gcc-2.96, 3.0 and 3.1 have
been known to produce bad code for a long time. Also ensure that you
pass the "-fno-strength-reduce" option to gcc.

Anyway, if you're starting a new dev, I would suggest using a more
recent kernel : 2.6.1[56] or 2.4.32 if you need 2.4.

> Thanks a lot,
> --
> James
> cyu021@gmail.com

regards,
Willy

Re: weird behavior from kernel

[James Yu]

The major reason to choose 2.4.18 as my dev base is that the dev is
ment to be carried out on a custom ARM board, and there isn't any
2.6's port available.

I'll try that "-fno-strength-reduce" option and see how it goes.
More comments are welcome.
cheers,

On 3/12/06, Willy Tarreau <willy@w.ods.org> wrote:
> It might be a wrong gcc optimization which generates bad code. If you're
> working on such an old kernel (about 5 years old), maybe you're using
> and old, broken compiler too ? gcc-2.95[.1], gcc-2.96, 3.0 and 3.1 have
> been known to produce bad code for a long time. Also ensure that you
> pass the "-fno-strength-reduce" option to gcc.
>
> Anyway, if you're starting a new dev, I would suggest using a more
> recent kernel : 2.6.1[56] or 2.4.32 if you need 2.4.
>
> regards,
> Willy
>
>


--
James
cyu021@gmail.com

Re: weird behavior from kernel

[Ben Dooks]

On Sun, Mar 12, 2006 at 05:25:11PM +0800, James Yu wrote:
> The major reason to choose 2.4.18 as my dev base is that the dev is
> ment to be carried out on a custom ARM board, and there isn't any
> 2.6's port available.

What functionality do you need which is not in the current
2.6 kernel series?

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: weird behavior from kernel

[James Yu]

It's a custom board I got, and the official 2.6 doesn't work on it. So
I have to use 2.4.

I tried -fno-strength-reduce option, and it doesn't seem to work though.
Still looking for solutions~


On 3/13/06, Ben Dooks <ben@fluff.org> wrote:
> On Sun, Mar 12, 2006 at 05:25:11PM +0800, James Yu wrote:
> > The major reason to choose 2.4.18 as my dev base is that the dev is
> > ment to be carried out on a custom ARM board, and there isn't any
> > 2.6's port available.
>
> What functionality do you need which is not in the current
> 2.6 kernel series?
>
> --
> Ben (ben@fluff.org, http://www.fluff.org/)
>
>   'a smiley only costs 4 bytes'
>


--
James
cyu021@gmail.com

Re: weird behavior from kernel

[Willy Tarreau]

On Mon, Mar 13, 2006 at 03:41:44PM +0800, James Yu wrote:
> It's a custom board I got, and the official 2.6 doesn't work on it. So
> I have to use 2.4.
> 
> I tried -fno-strength-reduce option, and it doesn't seem to work though.
> Still looking for solutions~

Other possibilities involve uninitialized variables which can get different
values depending on the code generated.

Regards,
Willy

Re: weird behavior from kernel

[Ben Dooks]

On Mon, Mar 13, 2006 at 03:41:44PM +0800, James Yu wrote:
> It's a custom board I got, and the official 2.6 doesn't work on it. So
> I have to use 2.4.

I assume that you had to alter 2.4 to work with your board, so why
is 2.6 so much more difficult?

We have 5 custom boards here, and we use 2.6. It does not take long
to add a board initialisation file into arch/arm/mach-s3c2410/
 
> I tried -fno-strength-reduce option, and it doesn't seem to work though.
> Still looking for solutions~
> 
> 
> On 3/13/06, Ben Dooks <ben@fluff.org> wrote:
> > On Sun, Mar 12, 2006 at 05:25:11PM +0800, James Yu wrote:
> > > The major reason to choose 2.4.18 as my dev base is that the dev is
> > > ment to be carried out on a custom ARM board, and there isn't any
> > > 2.6's port available.
> >
> > What functionality do you need which is not in the current
> > 2.6 kernel series?
> >
> > --
> > Ben (ben@fluff.org, http://www.fluff.org/)
> >
> >   'a smiley only costs 4 bytes'
> >
> 
> 
> --
> James
> cyu021@gmail.com
> -
> 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/

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'