Patchwork linux-imx-3.10.9 with preempt-rt patch

login
register
mail settings
Submitter Jacob Kroon
Date March 24, 2014, 2:27 p.m.
Message ID <CAPbeDC=ENW4pqgy-gHwDr8Z60F=p1SCBu42AiRnwje3TUCiN1g@mail.gmail.com>
Download mbox | patch
Permalink /patch/69057/
State Not Applicable
Delegated to: Otavio Salvador
Headers show

Comments

Jacob Kroon - March 24, 2014, 2:27 p.m.
Hi,
Some further progress on the RT-patch support that I forgot.
The oops seemed to be caused by a comparison mixup of NULL or -1.
See attached patch. Comments would be appreciated.
Regards Jacob


On Sat, Jan 25, 2014 at 9:29 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:

> Hi,
>
> So with this mail I hope I can start get the ball rolling with enabling
> the Freescale kernel to build with the PREEMPT RT patch.
> What I have sofar is Freescales 3.10.9 kernel + official 3.10.9-rt-patch
> (See [1]) + minor fixes. I also had to set NR_CPUS to be less than the
> default 4 in the default kernel config, otherwise I ran into some spin lock
> NULL pointer dereferences in the Vivante physical-to-virtual memory
> location conversion.
>
> The attached patch was necessary in order to get the Vivante GPU kernel
> driver to build.
>
> I'm using a Wandboard Solo + an Qt5.2 QtQuick application.
> While ping-flooing the Solo and running hackbench on the target,
> cyclictest gives me an average of ~30 us, ~150 us max latency.
>
> However, occasionally I get a kernel oops, and need to restart the board.
> Oops mesage is also attached.
>
>   -- Jacob
>
> [1]
> https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/patch-3.10.9-rt5.patch.xz
>
Otavio Salvador - March 24, 2014, 3:08 p.m.
Hello,

On Mon, Mar 24, 2014 at 11:27 AM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
> Some further progress on the RT-patch support that I forgot.
> The oops seemed to be caused by a comparison mixup of NULL or -1.
> See attached patch. Comments would be appreciated.

I don't use the RT patch but for your best profit of it, would be good
if you could focus the 3.10.17 kernel in git.freescale.com as this is
the basis of the upcoming 3.10.17-1.0.0 GA release. This would allow
for people to easily use your patch :D
Jacob Kroon - March 24, 2014, 3:37 p.m.
Hi Otavio,

On Mon, 24 Mar 2014, Otavio Salvador wrote:

> Hello,
>
> On Mon, Mar 24, 2014 at 11:27 AM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>> Some further progress on the RT-patch support that I forgot.
>> The oops seemed to be caused by a comparison mixup of NULL or -1.
>> See attached patch. Comments would be appreciated.
>
> I don't use the RT patch but for your best profit of it, would be good
> if you could focus the 3.10.17 kernel in git.freescale.com as this is
> the basis of the upcoming 3.10.17-1.0.0 GA release. This would allow
> for people to easily use your patch :D
>

Right, I forgot to mention, I've been applying this on top of linux-imx 
3.10.17 (ec1af9f898d234001d8fc7d720382de34cb6580f) + patch-3.10.17-rt12.patch.

/Jacob
Otavio Salvador - March 24, 2014, 4:12 p.m.
Hello Jacob,

On Mon, Mar 24, 2014 at 12:37 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
> On Mon, 24 Mar 2014, Otavio Salvador wrote:
>> On Mon, Mar 24, 2014 at 11:27 AM, Jacob Kroon <jacob.kroon@gmail.com>
>> wrote:
>>>
>>> Some further progress on the RT-patch support that I forgot.
>>> The oops seemed to be caused by a comparison mixup of NULL or -1.
>>> See attached patch. Comments would be appreciated.
>>
>>
>> I don't use the RT patch but for your best profit of it, would be good
>> if you could focus the 3.10.17 kernel in git.freescale.com as this is
>> the basis of the upcoming 3.10.17-1.0.0 GA release. This would allow
>> for people to easily use your patch :D
>>
>
> Right, I forgot to mention, I've been applying this on top of linux-imx
> 3.10.17 (ec1af9f898d234001d8fc7d720382de34cb6580f) +
> patch-3.10.17-rt12.patch.

Have you did and measurement test with and without those patches? I
think this would be of great help.
Jacob Kroon - March 24, 2014, 4:48 p.m.
Hi Otavio,

On Mon, 24 Mar 2014, Otavio Salvador wrote:

> Hello Jacob,
>
> On Mon, Mar 24, 2014 at 12:37 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>> On Mon, 24 Mar 2014, Otavio Salvador wrote:
>>> On Mon, Mar 24, 2014 at 11:27 AM, Jacob Kroon <jacob.kroon@gmail.com>
>>> wrote:
>>>>
>>>> Some further progress on the RT-patch support that I forgot.
>>>> The oops seemed to be caused by a comparison mixup of NULL or -1.
>>>> See attached patch. Comments would be appreciated.
>>>
>>>
>>> I don't use the RT patch but for your best profit of it, would be good
>>> if you could focus the 3.10.17 kernel in git.freescale.com as this is
>>> the basis of the upcoming 3.10.17-1.0.0 GA release. This would allow
>>> for people to easily use your patch :D
>>>
>>
>> Right, I forgot to mention, I've been applying this on top of linux-imx
>> 3.10.17 (ec1af9f898d234001d8fc7d720382de34cb6580f) +
>> patch-3.10.17-rt12.patch.
>
> Have you did and measurement test with and without those patches? I
> think this would be of great help.
>

I have done some testing using various tools from "rt-tests" package.
The patch does show a big improvement when looking at the numbers from
"cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
realtime thread (compared to milliseconds even with a PREEMPT kernel), 
while loading the system in all the possible ways I could think of,
including utilizing the GPU. This was on a Wandboard Solo.

/Jacob
Fabio Estevam - March 24, 2014, 4:52 p.m.
Hi Jacob/Otavio,

On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:

> I have done some testing using various tools from "rt-tests" package.
> The patch does show a big improvement when looking at the numbers from
> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
> realtime thread (compared to milliseconds even with a PREEMPT kernel), while
> loading the system in all the possible ways I could think of,
> including utilizing the GPU. This was on a Wandboard Solo.

What about creating a recipe for rt kernels, so that folks interested
in real-time kernel could easily test it under meta-fsl-arm?

Regards,

Fabio Estevam
Otavio Salvador - March 24, 2014, 4:58 p.m.
On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Jacob/Otavio,
>
> On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>
>> I have done some testing using various tools from "rt-tests" package.
>> The patch does show a big improvement when looking at the numbers from
>> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
>> realtime thread (compared to milliseconds even with a PREEMPT kernel), while
>> loading the system in all the possible ways I could think of,
>> including utilizing the GPU. This was on a Wandboard Solo.
>
> What about creating a recipe for rt kernels, so that folks interested
> in real-time kernel could easily test it under meta-fsl-arm?

I like this idea. Jacob, are you up for the task? I can help if you want.
John Weber - March 24, 2014, 5:04 p.m.
On 3/24/14, 11:52 AM, Fabio Estevam wrote:
> Hi Jacob/Otavio,
>
> On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>
>> I have done some testing using various tools from "rt-tests" package.
>> The patch does show a big improvement when looking at the numbers from
>> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
>> realtime thread (compared to milliseconds even with a PREEMPT kernel), while
>> loading the system in all the possible ways I could think of,
>> including utilizing the GPU. This was on a Wandboard Solo.
> What about creating a recipe for rt kernels, so that folks interested
> in real-time kernel could easily test it under meta-fsl-arm?
+1 to this.  It would be great to have for all boards, not just Wandboard.  But, 
I'm willing to test it on Wandboard as well.
>
> Regards,
>
> Fabio Estevam
Jacob Kroon - March 24, 2014, 5:10 p.m.
On Mon, 24 Mar 2014, Otavio Salvador wrote:

> On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> Hi Jacob/Otavio,
>>
>> On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>>
>>> I have done some testing using various tools from "rt-tests" package.
>>> The patch does show a big improvement when looking at the numbers from
>>> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
>>> realtime thread (compared to milliseconds even with a PREEMPT kernel), while
>>> loading the system in all the possible ways I could think of,
>>> including utilizing the GPU. This was on a Wandboard Solo.
>>
>> What about creating a recipe for rt kernels, so that folks interested
>> in real-time kernel could easily test it under meta-fsl-arm?
>
> I like this idea. Jacob, are you up for the task? I can help if you want.
>

Yes, it sounds like a good idea. I'll come up with a
patch for a linux-imx-rt recipe and post it for review here.

/Jacob
Jacob Kroon - March 25, 2014, 10:49 a.m.
Hi Otavio,

On Mon, Mar 24, 2014 at 6:10 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:

> On Mon, 24 Mar 2014, Otavio Salvador wrote:
>
>  On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com>
>> wrote:
>>
>>> Hi Jacob/Otavio,
>>>
>>> On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com>
>>> wrote:
>>>
>>>  I have done some testing using various tools from "rt-tests" package.
>>>> The patch does show a big improvement when looking at the numbers from
>>>> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
>>>> realtime thread (compared to milliseconds even with a PREEMPT kernel),
>>>> while
>>>> loading the system in all the possible ways I could think of,
>>>> including utilizing the GPU. This was on a Wandboard Solo.
>>>>
>>>
>>> What about creating a recipe for rt kernels, so that folks interested
>>> in real-time kernel could easily test it under meta-fsl-arm?
>>>
>>
>> I like this idea. Jacob, are you up for the task? I can help if you want.
>>
>>
> Yes, it sounds like a good idea. I'll come up with a
> patch for a linux-imx-rt recipe and post it for review here.
>
> /Jacob
>

So, the local patches I have are very light-weight, and the RT-patch can be
downloaded externally, but I wonder about the defconfig. Preempt-RT
switches the config parameters quite a lot, is there a tool or trick to use
in order to "cleanup" the defconfig to make it as minimal as possible ?
Right now I just use linux-imx defconfig as a start, turn on preempt-rt,
and save the resulting .config file.

  -- Jacob
Otavio Salvador - March 25, 2014, 11:43 a.m.
Hello Jacob,

On Tue, Mar 25, 2014 at 7:49 AM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
> On Mon, Mar 24, 2014 at 6:10 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>> On Mon, 24 Mar 2014, Otavio Salvador wrote:
>>> On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com>
>>> wrote:
>>>> What about creating a recipe for rt kernels, so that folks interested
>>>> in real-time kernel could easily test it under meta-fsl-arm?
>>>
>>>
>>> I like this idea. Jacob, are you up for the task? I can help if you want.
>>>
>>
>> Yes, it sounds like a good idea. I'll come up with a
>> patch for a linux-imx-rt recipe and post it for review here.
>
> So, the local patches I have are very light-weight, and the RT-patch can be
> downloaded externally, but I wonder about the defconfig. Preempt-RT switches
> the config parameters quite a lot, is there a tool or trick to use in order
> to "cleanup" the defconfig to make it as minimal as possible ? Right now I
> just use linux-imx defconfig as a start, turn on preempt-rt, and save the
> resulting .config file.

So in this case please *download* the RT-patch. Check the 'name' param
for the SRC_URI so you can add the md5sum and sha256sum for it.

For the defconfig, yes. You should do:

make ARCH=arm savedefconfig

after doing the required changes.
Jacob Kroon - March 25, 2014, 1:15 p.m.
On Tue, Mar 25, 2014 at 12:43 PM, Otavio Salvador
<otavio@ossystems.com.br>wrote:

> Hello Jacob,
>
> On Tue, Mar 25, 2014 at 7:49 AM, Jacob Kroon <jacob.kroon@gmail.com>
> wrote:
> > On Mon, Mar 24, 2014 at 6:10 PM, Jacob Kroon <jacob.kroon@gmail.com>
> wrote:
> >> On Mon, 24 Mar 2014, Otavio Salvador wrote:
> >>> On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com>
> >>> wrote:
> >>>> What about creating a recipe for rt kernels, so that folks interested
> >>>> in real-time kernel could easily test it under meta-fsl-arm?
> >>>
> >>>
> >>> I like this idea. Jacob, are you up for the task? I can help if you
> want.
> >>>
> >>
> >> Yes, it sounds like a good idea. I'll come up with a
> >> patch for a linux-imx-rt recipe and post it for review here.
> >
> > So, the local patches I have are very light-weight, and the RT-patch can
> be
> > downloaded externally, but I wonder about the defconfig. Preempt-RT
> switches
> > the config parameters quite a lot, is there a tool or trick to use in
> order
> > to "cleanup" the defconfig to make it as minimal as possible ? Right now
> I
> > just use linux-imx defconfig as a start, turn on preempt-rt, and save the
> > resulting .config file.
>
> So in this case please *download* the RT-patch. Check the 'name' param
> for the SRC_URI so you can add the md5sum and sha256sum for it.
>
> For the defconfig, yes. You should do:
>
> make ARCH=arm savedefconfig
>
> after doing the required changes.
>
>
Thanks, that shrank the defconfig _considerably_ :-)

/Jacob

Patch

Index: git/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
===================================================================
--- git.orig/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
+++ git/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
@@ -2959,7 +2959,7 @@  gckOS_CreateMutex(
     gcmkONERROR(gckOS_Allocate(Os, gcmSIZEOF(struct mutex), Mutex));
 
     /* Initialize the mutex. */
-    mutex_init(*Mutex);
+    mutex_init((struct mutex*)*Mutex);
 
     /* Return status. */
     gcmkFOOTER_ARG("*Mutex=0x%X", *Mutex);
@@ -3004,7 +3004,7 @@  gckOS_DeleteMutex(
     gcmkVERIFY_ARGUMENT(Mutex != gcvNULL);
 
     /* Destroy the mutex. */
-    mutex_destroy(Mutex);
+    mutex_destroy((struct mutex*)Mutex);
 
     /* Free the mutex structure. */
     gcmkONERROR(gckOS_Free(Os, Mutex));
@@ -7730,7 +7730,7 @@  gckOS_WaitSignal(
 
     might_sleep();
 
-    spin_lock_irq(&signal->obj.wait.lock);
+    raw_spin_lock_irq(&signal->obj.wait.lock);
 
     if (signal->obj.done)
     {
@@ -7760,9 +7760,8 @@  gckOS_WaitSignal(
             : Wait * HZ / 1000;
 #endif
 
-        DECLARE_WAITQUEUE(wait, current);
-        wait.flags |= WQ_FLAG_EXCLUSIVE;
-        __add_wait_queue_tail(&signal->obj.wait, &wait);
+        DEFINE_SWAITER(wait);
+        swait_prepare_locked(&signal->obj.wait, &wait);
 
         while (gcvTRUE)
         {
@@ -7774,9 +7773,9 @@  gckOS_WaitSignal(
             }
 
             __set_current_state(TASK_INTERRUPTIBLE);
-            spin_unlock_irq(&signal->obj.wait.lock);
+            raw_spin_unlock_irq(&signal->obj.wait.lock);
             timeout = schedule_timeout(timeout);
-            spin_lock_irq(&signal->obj.wait.lock);
+            raw_spin_lock_irq(&signal->obj.wait.lock);
 
             if (signal->obj.done)
             {
@@ -7840,7 +7839,7 @@  gckOS_WaitSignal(
             }
         }
 
-        __remove_wait_queue(&signal->obj.wait, &wait);
+        swait_finish_locked(&signal->obj.wait, &wait);
 
 #if gcdDETECT_TIMEOUT
         if (complained)
@@ -7853,7 +7852,7 @@  gckOS_WaitSignal(
 #endif
     }
 
-    spin_unlock_irq(&signal->obj.wait.lock);
+    raw_spin_unlock_irq(&signal->obj.wait.lock);
 
 OnError:
     /* Return status. */
Index: git/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c
===================================================================
--- git.orig/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c
+++ git/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c
@@ -1068,6 +1068,7 @@  OnError:
 **
 **      Nothing.
 */
+#include <linux/printk.h>
 gceSTATUS
 gckCOMMAND_Commit(
     IN gckCOMMAND Command,
@@ -1265,8 +1266,13 @@  gckCOMMAND_Commit(
     waitLinkPhysical = (gctUINT8_PTR) Command->physical + offset;
     waitLinkLogical  = (gctUINT8_PTR) Command->logical  + offset;
 
+    if ( (int)Context == 0xffffffff )
+    {
+        printk("crash?");
+    }
+
     /* Context switch required? */
-    if (Context == gcvNULL)
+    if (Context == gcvNULL || (int)Context == 0xffffffff )
     {
         /* See if we have to switch pipes for the command buffer. */
         if (commandBufferObject->entryPipe == Command->pipeSelect)