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
[email protected]
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
> [email protected]
regards,
Willy
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 <[email protected]> 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
[email protected]
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 ([email protected], http://www.fluff.org/)
'a smiley only costs 4 bytes'
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 <[email protected]> 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 ([email protected], http://www.fluff.org/)
>
> 'a smiley only costs 4 bytes'
>
--
James
[email protected]
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
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 <[email protected]> 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 ([email protected], http://www.fluff.org/)
> >
> > 'a smiley only costs 4 bytes'
> >
>
>
> --
> James
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ben ([email protected], http://www.fluff.org/)
'a smiley only costs 4 bytes'