memory_sync_page errors on N900
Ивайло Димитров
Running latest upstream gst-dsp, branch next on N900 with stock socket
nodes (DSP_API=1 SN_API=0) results in the following messages in system
log:
[117991.250488] memory_sync_page: no page for 4471c000
[117991.250518] proc_memory_sync: InValid address parameters 4471b000
2000
[118007.838531] kb_lock (GPIO 113) is now closed
[118008.197753] kb_lock (GPIO 113) is now open
[118008.726257] memory_sync_page: no page for 4471c000
[118008.726257] proc_memory_sync: InValid address parameters 4471b000
2000
[118008.740600] memory_sync_page: no page for 4471c000
[118008.740631] proc_memory_sync: InValid address parameters 4471b000
2000
The messages appear randomly, with visible glitches on the video
output. The video played was H264. bridgedriver is the one from
harmattan kernel 2.6.32-20112910 backported to Maemo5 kernel-power
(2.6.28 with lots of upstream backports). The above messages never
appear when using stock gstreamer dsp/openmax codecs (I could give the
versions if needed).
Is there anything else I could provide to help investigation?
Felipe Contreras
> Hi,
> Running latest upstream gst-dsp, branch next on N900 with stock socket
> nodes (DSP_API=1 SN_API=0) results in the following messages in system
> log:
What exactly do you mean by "stock socket nodes"? Either you use the
Fremantle ones, or the Harmattan ones, you shouldn't mix them. For
Fremantle, use SN_API=0, for Harmattan, use SN_API=2.
> [117991.250488] memory_sync_page: no page for 4471c000
> [117991.250518] proc_memory_sync: InValid address parameters 4471b000
> 2000
> [118007.838531] kb_lock (GPIO 113) is now closed
> [118008.197753] kb_lock (GPIO 113) is now open
> [118008.726257] memory_sync_page: no page for 4471c000
> [118008.726257] proc_memory_sync: InValid address parameters 4471b000
> 2000
> [118008.740600] memory_sync_page: no page for 4471c000
> [118008.740631] proc_memory_sync: InValid address parameters 4471b000
> 2000
>
> The messages appear randomly, with visible glitches on the video
> output. The video played was H264. bridgedriver is the one from
> harmattan kernel 2.6.32-20112910 backported to Maemo5 kernel-power
> (2.6.28 with lots of upstream backports). The above messages never
> appear when using stock gstreamer dsp/openmax codecs (I could give the
> versions if needed).
>
> Is there anything else I could provide to help investigation?
I'm not sure. What kernel config did you use?
Cheers.
--
Felipe Contreras
Ивайло Димитров
>
> What exactly do you mean by "stock socket nodes"? Either you use the
> Fremantle ones, or the Harmattan ones, you shouldn't mix them. For
> Fremantle, use SN_API=0, for Harmattan, use SN_API=2.
>
DSP codecs as well(more on that later).
> I'm not sure. What kernel config did you use?
CONFIG_BRIDGE_DVFS=y
CONFIG_BRIDGE_MEMPOOL_SIZE=0x600000
# CONFIG_BRIDGE_DEBUG is not set
# CONFIG_BRIDGE_CACHE_LINE_CHECK is not set
I was trying to find the reason for those message for the last few
days without much of success :). Anyway the those error appear with
both Harmattan and Fremantle DSP codecs, so i did the following
experiment:
Harmattan codecs, maemo6-patches branch (backported to maemo5) ,
recording video 1280x720@25, some additional debug messages in both
kernel and gst-dsp. I also enabled CONFIG_BRIDGE_CACHE_LINE_CHECK
The result:
Feb 9 13:54:00 Nokia-N900 camera-ui[1332]: dmm_buffer_new 0x307bf0
Feb 9 13:54:00 Nokia-N900 camera-ui[1332]: dmm_buffer_allocate
0x307bf0
Feb 9 13:54:00 Nokia-N900 camera-ui[1332]: dmm_buffer_map 0x307bf0
.
.
.
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: waiting for
events
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: got dsp
message: 0x601 0x20a1dd80 0x2c
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: got output
buffer
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_end 0x361b20
128 0x20a1d000 0x20a1dd80 0 0 data 0x2d8d80
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsp_invalidate
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_end 0x307bf0
32245 0x20c0f000 0x20c0f080 0 2 data 0x46dbd080
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsp_invalidate
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_end 0x28e750
128 0x20a01000 0x20a01300 0 0 data 0x2e1300
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsp_invalidate
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: got dsp
message: 0x600 0x20a11680 0x2c
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: got input
buffer
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_end 0x35cb50
128 0x20a11000 0x20a11680 0 0 data 0x1d0680
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsp_invalidate
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_unmap 0x3bef78
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_end 0x28ebf0
128 0x209f5000 0x209f5180 0 0 data 0x3c2180
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsp_invalidate
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: in ts
0:00:00.546395834
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: pushing
buffer 0:00:00.546395834
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.372344] proc_memory_sync
002d8d80 128 0
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.372406] memory_sync_page
2d8d80
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.372955] proc_memory_sync
46dbd080 32245 0
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.372985] memory_sync_page
46dbd080
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.373016] memory_sync_page
46dbe000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.373016] memory_sync_page
46dbf000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.373046] memory_sync_page
46dc0000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.373046] memory_sync_page
46dc1000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.373077] memory_sync_page: no
page for 46dc1000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.373077] proc_memory_sync:
InValid address parameters 46dbd080 7df5
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.373718] proc_memory_sync
002e1300 128 0
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.373718] memory_sync_page
2e1300
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.375213] proc_memory_sync
001d0680 128 0
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.375213] memory_sync_page
1d0680
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.376708] proc_memory_sync
003c2180 128 0
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.376708] memory_sync_page
3c2180
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: sending
output buffer
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_begin 0x28e750
128 0x20a01000 0x20a01300 0 0 data 0x2e1300
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsp_flush
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_begin 0x307bf0
32245 0x20c0f000 0x20c0f080 0 2 data 0x46dbd080
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsp_invalidate
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dmm_buffer_begin 0x361b20
68 0x20a1d000 0x20a1dd80 0 0 data 0x2d8d80
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsp_flush
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.391906] proc_memory_sync
002e1300 128 1
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.391937] memory_sync_page
2e1300
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392517] proc_memory_sync
46dbd080 32245 0
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392517] memory_sync_page
46dbd080
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392547] memory_sync_page
46dbe000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392547] memory_sync_page
46dbf000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392578] memory_sync_page
46dc0000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392578] memory_sync_page
46dc1000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392608] memory_sync_page
46dc2000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392608] memory_sync_page
46dc3000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.392639] memory_sync_page
46dc4000
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.393157] proc_memory_sync
002d8d80 68 1
Feb 9 13:54:01 Nokia-N900 kernel: [ 5652.393157] memory_sync_page
2d8d80
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: end
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: begin
Feb 9 13:54:01 Nokia-N900 camera-ui[1332]: dsphdmp4venc0: waiting for
events
dmm_buffer(begin/end) have an additional log at function entry:
pr_debug(NULL, "%s %p %d %p %p %d %d data %p",__func__,b,len,b-
>reserve,b->map,b->need_copy,b->dir,b->data,);
So, the ioctl that results in these errors is INVALIDATE_MEM. The
issue is very hard to recreate and it seems it is related to memory
pressure and/or CPU load.
It might be as well a problem in bridgedriver itself, as the actual
reason for those errors seems to be follow_page failing for page
0x46dc1000, but next time it does not fail for the same page. And it
is known that using follow_page in bridgedriver is a hack :). Could it
be that the page in question is swapped? Or there is still DMA going
on? I am lost.
This is just a small part of the log, I can provide the full one if
needed. The error messages appeared only 3-4 times while capturing
(about 15 seconds). And the page for which follow_page fails is
different every time.
Is it a good idea to backport bridgedriver DMA API support? Having in
mind that used kernel is 2.6.28 based. I saw some notes while reading
through mailing lists that it could bring problems.
BTW I saw those error messages in other threads in this mailing list
too, produced with much newer kernels, so it is either bridgedriver
itself or gst-dsp.
Ivo
Felipe Contreras
>
>
>>
>> What exactly do you mean by "stock socket nodes"? Either you use the
>> Fremantle ones, or the Harmattan ones, you shouldn't mix them. For
>> Fremantle, use SN_API=0, for Harmattan, use SN_API=2.
>>
>
> Fremantle PR1.3 DSP codecs. Anyway the issue appears with Harmattan
> DSP codecs as well(more on that later).
>
>> I'm not sure. What kernel config did you use?
>
> CONFIG_MPU_BRIDGE=m
> CONFIG_BRIDGE_DVFS=y
> CONFIG_BRIDGE_MEMPOOL_SIZE=0x600000
> # CONFIG_BRIDGE_DEBUG is not set
> # CONFIG_BRIDGE_CACHE_LINE_CHECK is not set
>
> I was trying to find the reason for those message for the last few
> days without much of success :). Anyway the those error appear with
> both Harmattan and Fremantle DSP codecs, so i did the following
> experiment:
>
> Harmattan codecs, maemo6-patches branch (backported to maemo5) ,
> recording video 1280x720@25, some additional debug messages in both
> kernel and gst-dsp. I also enabled CONFIG_BRIDGE_CACHE_LINE_CHECK
Don't enable CONFIG_BRIDGE_CACHE_LINE_CHECK, support for that is relatively new.
> dmm_buffer(begin/end) have an additional log at function entry:
>
> pr_debug(NULL, "%s %p %d %p %p %d %d data %p",__func__,b,len,b-
>>reserve,b->map,b->need_copy,b->dir,b->data,);
>
>
> So, the ioctl that results in these errors is INVALIDATE_MEM. The
> issue is very hard to recreate and it seems it is related to memory
> pressure and/or CPU load.
>
> It might be as well a problem in bridgedriver itself, as the actual
> reason for those errors seems to be follow_page failing for page
> 0x46dc1000, but next time it does not fail for the same page. And it
> is known that using follow_page in bridgedriver is a hack :). Could it
> be that the page in question is swapped? Or there is still DMA going
> on? I am lost.
>
> This is just a small part of the log, I can provide the full one if
> needed. The error messages appeared only 3-4 times while capturing
> (about 15 seconds). And the page for which follow_page fails is
> different every time.
>
> Is it a good idea to backport bridgedriver DMA API support? Having in
> mind that used kernel is 2.6.28 based. I saw some notes while reading
> through mailing lists that it could bring problems.
>
> BTW I saw those error messages in other threads in this mailing list
> too, produced with much newer kernels, so it is either bridgedriver
> itself or gst-dsp.
I don't know what kernel you are using, but smells a lot like this issue:
From 8b566269cb267dccd7a8ff211f1f502c8262e0b9 Mon Sep 17 00:00:00 2001
From: Felipe Contreras <felipe.c...@gmail.com>
Date: Sun, 25 Jul 2010 20:02:46 +0300
Subject: [PATCH] tidspbridge: proc: fix wrong flushes
When the area to flush spans multiple vma's, we might not want to flush
the last one completely, therefore the total length to flush should not
be used, but instead, the remaining one.
Flushing more than specified can cause memory corruption on user-space.
Signed-off-by: Felipe Contreras <felipe.c...@gmail.com>
---
drivers/dsp/bridge/rmgr/proc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 7631ff7..d1bbfa3 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -750,6 +750,7 @@ static int memory_sync_vma(unsigned long start, u32 len,
break;
start = vma->vm_end;
+ len -= size;
}
if (!vma)
--
1.7.9
Cheers.
--
Felipe Contreras