autovideosink element is not working

[Ionut Nicu]

Hi,

I tried following the steps from the following post from Felipe's
blog:

http://felipec.wordpress.com/2009/12/21/gstreamer-development-in-embedded-with-sbox2/

to build a gstreamer with gst-dsp support.

When I try to play a file I get the following error:

[root@buildroot ~]# gst-launch playbin2 uri=file:///root/test.avi

(gst-launch-0.10:684): GLib-WARNING **: g_set_prgname() called
multiple times
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPlayBin2:playbin20/GstPlaySink:playsink0: The
autovideosink element is not working.
Additional debug info:
gstplaysink.c(1088): gen_video_chain (): /GstPlayBin2:playbin20/
GstPlaySink:playsink0
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

In addition to the packages mentioned in Felipe's post I also cross
compiled gst-omapfb from git://github.com/felipec/gst-omapfb.git.

I have the omapfbsink installed and I can see the test patterns on the
screen if I test with: gst-launch -v -m videotestsrc ! omapfbsink

However, if I try with autovideosink i get the following error, which
I think it may be the same problem as in the playbin2 case:

[root@buildroot ~]# gst-launch -v -m videotestsrc ! autovideosink

(gst-launch-0.10:691): GLib-WARNING **: g_set_prgname() called
multiple times
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
Got message #3 from element "autovideosink0-actual-sink-v4l2" (error):
GstMessageError, gerror=(GstGError)NULL, debug=(string)"v4l2_calls.c
\(488\):\ gst_v4l2_open\ \(\):\ /GstV4l2Sink:autovideosink0-actual-
sink-v4l2:\012system\ error:\ No\ such\ file\ or\ directory";
ERROR: from element /GstV4l2Sink:autovideosink0-actual-sink-v4l2:
Cannot identify device '/dev/video1'.
Additional debug info:
v4l2_calls.c(488): gst_v4l2_open (): /GstV4l2Sink:autovideosink0-
actual-sink-v4l2:
system error: No such file or directory
Setting pipeline to NULL ...
Freeing pipeline ...


Any hint? Sorry for the newbie question. I'm pretty new to gstreamer /
gst-dsp.

Thanks,
Ionut.

[marco.b...@nokia.com]

Hi,

if you want to know a little more about why the autovideosink is not working in your case you could contact the gstreamer-devel mailing list (http://gstreamer.freedesktop.org/lists/).

In the meanwhile, you may try using decodebin:

gst-launch filesrc location=path/to/file ! decodebin ! omapfbsink

if you want to test with audio:

gst-launch filesrc location=path/to/file ! decodebin name=d ! omapfbsink d. ! alsasink

you may try and replace omapfbsink with xvimagesink (if you've X) or alsasink with pulsesink (if you've pulseaudio).

Regards


--
Sent from my N900.

----- Messaggio originale -----

[Mark Nauwelaerts]

It is probably the same problem. That is, playbin2 uses autovidesink, and that
one seems to fail to find a working video sink (in the former case with a not so
informative error message).

As for autovideosink not finding a working one;
- the latter message is clear (no video4linux sink setup in the (scratchbox?)
environment)
- probably xvimagesink fails because there is no DISPLAY set
- is omapfbsink tried by autovidesink (needs a properly set class description
and plugin rank?)

Mark.

[Ionut Nicu]

Hi,

On Sat, May 1, 2010 at 11:25 PM, <marco.b...@nokia.com> wrote:

Hi,

if you want to know a little more about why the autovideosink is not working in your case you could contact the gstreamer-devel mailing list (http://gstreamer.freedesktop.org/lists/).

In the meanwhile, you may try using decodebin:

gst-launch filesrc location=path/to/file ! decodebin ! omapfbsink

When I run the pipeline above I get a kernel crash:
 

[root@buildroot ~]# gst-launch filesrc location="test.avi" ! decodebin ! omapfbsink

(gst-launch-0.10:684): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

[  266.075378] BUG: Bad page state in process gst-launch-0.10  pfn:80f48
[  266.083282] page:c0663900 flags:00000410 count:0 mapcount:0 mapping:(null) index:0
[  266.091339] [<c0035a18>] (unwind_backtrace+0x0/0xd4) from [<c00aab18>] (bad_page+0x100/0x134)
[  266.100280] [<c00aab18>] (bad_page+0x100/0x134) from [<bf063504>] (WMD_BRD_MemUnMap+0x1b0/0x54c [bridgedriver])
[  266.111358] [<bf063504>] (WMD_BRD_MemUnMap+0x1b0/0x54c [bridgedriver]) from [<bf07f984>] (PROC_UnMap+0xcc/0x180 [bridgedriver])
[  266.123535] [<bf07f984>] (PROC_UnMap+0xcc/0x180 [bridgedriver]) from [<bf06bbb8>] (WCD_CallDevIOCtl+0x2c/0x44 [bridgedriver])
[  266.135986] [<bf06bbb8>] (WCD_CallDevIOCtl+0x2c/0x44 [bridgedriver]) from [<bf0878d0>] (bridge_ioctl+0x158/0x1e0 [bridgedriver])
[  266.148590] [<bf0878d0>] (bridge_ioctl+0x158/0x1e0 [bridgedriver]) from [<c00df70c>] (vfs_ioctl+0x2c/0x8c)
[  266.158813] [<c00df70c>] (vfs_ioctl+0x2c/0x8c) from [<c00dfdbc>] (do_vfs_ioctl+0x560/0x5a8)
[  266.167541] [<c00dfdbc>] (do_vfs_ioctl+0x560/0x5a8) from [<c00dfe38>] (sys_ioctl+0x34/0x54)
[  266.176513] [<c00dfe38>] (sys_ioctl+0x34/0x54) from [<c0030f00>] (ret_fast_syscall+0x0/0x2c)
[  266.185363] Disabling lock debugging due to kernel taint


This BUG() backtrace repeats a lot of times, and after that I get:

dsp_thread: failed waiting for events
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
[  268.581390] DSPBRIDGE: UNMAP function: COUNT 0 FOR PA 0x80f48000, size = 0x3c000
New clock: GstSystemClock
[  268.603881] DSPBRIDGE: MAP function: COUNT 0 FOR PA 0x80f48000
[  268.617401] Bad page state in process 'gst-launch-0.10'
[  268.617431] page:c0663900 flags:0x00000410 mapping:(null) mapcount:0 count:0
[  268.617431] Backtrace:
[  268.638061] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  268.646606] pgd = c7138000
[  268.649566] [00000000] *pgd=8713d031, *pte=00000000, *ppte=00000000
[  268.656280] Internal error: Oops: 817 [#1] PREEMPT
[  268.661071] Modules linked in: bridgedriver dspbridge ipv6
[  268.666656] CPU: 0    Tainted: G    B       (2.6.32-felipec1 #4)
[  268.672882] PC is at bad_page_dump+0x68/0x78 [bridgedriver]
[  268.678588] LR is at bad_page_dump+0x64/0x78 [bridgedriver]
[  268.684204] pc : [<bf063344>]    lr : [<bf063340>]    psr: 60000013
[  268.684204] sp : c7bede08  ip : 00000000  fp : 0003c000
[  268.695770] r10: 21c94000  r9 : 00000000  r8 : 80f48000
[  268.701019] r7 : c0663900  r6 : c0663900  r5 : 00000410  r4 : 00000000
[  268.707580] r3 : 00000000  r2 : c7beddfc  r1 : bf090442  r0 : 000000b1
[  268.714141] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  268.721343] Control: 10c5387d  Table: 87138019  DAC: 00000015
[  268.727111] Process gst-launch-0.10 (pid: 689, stack limit = 0xc7bec2f0)
[  268.733856] Stack: (0xc7bede08 to 0xc7bee000)
[  268.738250] de00:                   00000410 00000000 00000000 00000000 00001000 c0645000
[  268.746643] de20: 00000f48 bf0634cc cb403250 0003c000 c7136800 0000003c cb403250 cb400000
[  268.755004] de40: 0003c000 c7b25818 0003c000 0003c000 80f49000 cb400870 21c94000 c7b421d8
[  268.763397] de60: 00002000 00000001 00008000 c7018458 21c94000 c7bf4f58 00008000 21c94000
[  268.771789] de80: c7bec000 40565000 00000000 bf07f984 c7018458 21c94000 0003c000 c701c918
[  268.780181] dea0: c7bedeec 00000000 4344cc94 c7832e40 c0031084 bf06bbb8 00000013 bf0878d0
[  268.788574] dec0: c7018458 00000000 21c94000 00000080 4168e2c8 0003c000 c78daa80 4009d4a4
[  268.796966] dee0: c7bedfb0 c00369f4 4009d4a4 00008000 00000007 c7832e40 bf087778 4344cc94
[  268.805358] df00: 00000014 c0031084 40565000 c00df70c 00002000 4344cc94 c7832e40 c75c9928
[  268.813751] df20: 00000007 c00dfdbc 00000f72 00000f72 00000000 00000001 00000000 00000081
[  268.822143] df40: 00065d98 c0031084 c7bec000 402f56a0 00000001 c0083d60 c05fb5a0 c007c11c
[  268.830535] df60: ffffffff 00000000 00000000 c7832e40 4344cc94 00000014 00000007 c0031084
[  268.838928] df80: c7bec000 c00dfe38 00000007 00000001 4344cc94 0008fb90 00085030 00088c70
[  268.847320] dfa0: 00000036 c0030f00 0008fb90 00085030 00000007 00000014 4344cc94 4344cc98
[  268.855712] dfc0: 0008fb90 00085030 00088c70 00000036 40529000 00014748 40565000 00000000
[  268.864105] dfe0: 0003c000 4344cc90 4169191c 403f6c3c 20000010 00000007 e59f100c e8bd4010
[  268.872497] [<bf063344>] (bad_page_dump+0x68/0x78 [bridgedriver]) from [<bf0634cc>] (WMD_BRD_MemUnMap+0x178/0x54c [bridgedriver])
[  268.884460] [<bf0634cc>] (WMD_BRD_MemUnMap+0x178/0x54c [bridgedriver]) from [<bf07f984>] (PROC_UnMap+0xcc/0x180 [bridgedriver])
[  268.896301] [<bf07f984>] (PROC_UnMap+0xcc/0x180 [bridgedriver]) from [<bf06bbb8>] (WCD_CallDevIOCtl+0x2c/0x44 [bridgedriver])
[  268.907989] [<bf06bbb8>] (WCD_CallDevIOCtl+0x2c/0x44 [bridgedriver]) from [<bf0878d0>] (bridge_ioctl+0x158/0x1e0 [bridgedriver])
[  268.919952] [<bf0878d0>] (bridge_ioctl+0x158/0x1e0 [bridgedriver]) from [<c00df70c>] (vfs_ioctl+0x2c/0x8c)
[  268.929840] [<c00df70c>] (vfs_ioctl+0x2c/0x8c) from [<c00dfdbc>] (do_vfs_ioctl+0x560/0x5a8)
[  268.938293] [<c00dfdbc>] (do_vfs_ioctl+0x560/0x5a8) from [<c00dfe38>] (sys_ioctl+0x34/0x54)
[  268.946716] [<c00dfe38>] (sys_ioctl+0x34/0x54) from [<c0030f00>] (ret_fast_syscall+0x0/0x2c)
[  268.955261] Code: e58d5000 e98d5010 eb4f1ae3 e3a03000 (e5833000)
[  268.965881] ---[ end trace dd3a50f173a5e17e ]---
dsp_thread: failed waiting for events

After this, the first frame of the video gets displayed on the framebuffer, but the dsp is stuck.

My kernel version is 2.6.32-felipec1 (from git://gitorious.org/~felipec/linux-omap/felipec.git, tag v2.6.32-felipec1). It works ok with the binaries from http://people.freedesktop.org/~felipec/beagle-2.6.32-rc3/.

Could there be an incompatibility between the gst-dsp version I'm trying to use (v0.6.0) and the dspbridge driver from 2.6.32-felipec1? Are the package versions from the demo the same with the ones from the blog post I mentioned in my previous e-mail?

Thanks,
Ionut.

[Ionut Nicu]

Hi,

On Sun, May 2, 2010 at 11:31 AM, Mark Nauwelaerts <mark.nau...@collabora.co.uk> wrote:

It is probably the same problem.  That is, playbin2 uses autovidesink, and that one seems to fail to find a working video sink (in the former case with a not so informative error message).

As for autovideosink not finding a working one;
- the latter message is clear (no video4linux sink setup in the (scratchbox?) environment)

I have a target rootfs compiled with buidroot and copied the gstreamer binaries compiled with sb2 to /opt/gst on the target rootfs.

Yeah, the error was in the v4l2sink. I disabled v4l support in gst-plugins-base (--disable-gst_v4l configure flag). Even after this, when I tried running "gst-launch -v -m videotestsrc ! autovideosink" it selected the fake video sink instead of the omapfbsink.
 

- probably xvimagesink fails because there is no DISPLAY set
- is omapfbsink tried by autovidesink (needs a properly set class description and plugin rank?)

I'm not running X, I'm just trying to render things into the framebuffer. It's not very clear to me how autovideosink selects the proper sink when there are multiple choices in the gst registry.

Btw, how do you guys compile gst-omapfb? I had to hack my way around in the Makefile and omapfb.h in order to make it compile. My steps to make it compile:

- I set CC := arm-none-linux-gnueabi-gcc instead of arm-linux-gcc (I use the CS 2009q3 toolchain)
- #include <mach/omapfb.h> doesn't work since in my kernel tree ompafb.h is only in include/linux/omapfb.h. I couldn't include it directly from the kernel tree because I would get into other header dependency problems so I just added the required struct, enum and ioctl defines directly into omapfb.h. Is there another nicer way to compile this project?

Regards,
Ionut.

[Felipe Contreras]

On Sun, May 2, 2010 at 1:41 PM, Ionut Nicu <ionut...@gmail.com> wrote:
> On Sun, May 2, 2010 at 11:31 AM, Mark Nauwelaerts
> <mark.nau...@collabora.co.uk> wrote:
>> - is omapfbsink tried by autovidesink (needs a properly set class
>> description and plugin rank?)
>
> I'm not running X, I'm just trying to render things into the framebuffer.
> It's not very clear to me how autovideosink selects the proper sink when
> there are multiple choices in the gst registry.

Each element has a rank, so the one with higher rank gets selected.
omapfbsink has rank 0, so it never gets selected, you would need to do
something like:
-gst_element_register(plugin, "omapfbsink", GST_RANK_NONE,
GST_OMAPFB_SINK_TYPE))
+gst_element_register(plugin, "omapfbsink", GST_RANK_PRIMARY,
GST_OMAPFB_SINK_TYPE))

> Btw, how do you guys compile gst-omapfb? I had to hack my way around in the
> Makefile and omapfb.h in order to make it compile. My steps to make it
> compile:
>
> - I set CC := arm-none-linux-gnueabi-gcc instead of arm-linux-gcc (I use the
> CS 2009q3 toolchain)
> - #include <mach/omapfb.h> doesn't work since in my kernel tree ompafb.h is
> only in include/linux/omapfb.h. I couldn't include it directly from the
> kernel tree because I would get into other header dependency problems so I
> just added the required struct, enum and ioctl defines directly into
> omapfb.h. Is there another nicer way to compile this project?

Try this:
-#include <mach/omapfb.h>
+#include <linux/omapfb.h>

I have a bunch of patches in my queue, and I'll try to push them, but
what's already pushed should work (mostly).

Cheers.

--
Felipe Contreras

[Felipe Contreras]

> After this, the first frame of the video gets displayed on the framebuffer,
> but the dsp is stuck.
>
> My kernel version is 2.6.32-felipec1 (from
> git://gitorious.org/~felipec/linux-omap/felipec.git, tag v2.6.32-felipec1).
> It works ok with the binaries from
> http://people.freedesktop.org/~felipec/beagle-2.6.32-rc3/.
>
> Could there be an incompatibility between the gst-dsp version I'm trying to
> use (v0.6.0) and the dspbridge driver from 2.6.32-felipec1? Are the package
> versions from the demo the same with the ones from the blog post I mentioned
> in my previous e-mail?

I don't think there's such incompatibility, but it's hart to tell
since those versions are very old. I think first you need to narrow
down your problem:

Is it in omapfb?
% gst-launch videotestsrc ! omapfbsink

Is it in dsp?
% gst-launch filesrc location=video.avi ! avidemux ! dspvdec ! fakesink -v

Ahd then perhaps try the latest and greatest stuff:

* dspbridge branch from l-o (based on 2.6.33):
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

* DSS2 patch for beagleboard (I assume that's what you are using):
http://article.gmane.org/gmane.linux.ports.arm.omap/34364

After this patch you can use fancier kernel options:
omapfb.mode=dvi:1024x768MR-24@60 omapfb.vram=0:2M,1:4M

This is the config I use:
---
#
# Frame buffer hardware drivers
#
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
CONFIG_OMAP2_VRAM=y
CONFIG_OMAP2_VRFB=y
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_VRAM_SIZE=6
CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
# CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set
# CONFIG_OMAP2_DSS_RFBI is not set
CONFIG_OMAP2_DSS_VENC=y
# CONFIG_OMAP2_DSS_SDI is not set
# CONFIG_OMAP2_DSS_DSI is not set
# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
CONFIG_FB_OMAP2=y
CONFIG_FB_OMAP2_DEBUG_SUPPORT=y
# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
CONFIG_FB_OMAP2_NUM_FBS=3

#
# OMAP2/3 Display Device Drivers
#
CONFIG_PANEL_GENERIC=y
# CONFIG_PANEL_SHARP_LS037V7DW01 is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
---

* latest gst-dsp (v0.7.1 or 'master')
git://github.com/felipec/gst-dsp.git

* L23.i3.3 DSP firmware:
https://gforge.ti.com/gf/download/frsrelease/285/3260/DSPbinaries-3.09-Linux-x86-Install

If you use the new DSP firmware then you need to use a patched gst-dsp
for now; 'next-l23-i3-3'.

I just tried all this and everything works fine although I haven't
tried to recompile gst-omapfb (used the one in my demo image).

Cheers.

--
Felipe Contreras

[Ionut Nicu]

Hi,

On Sun, May 2, 2010 at 7:43 PM, Felipe Contreras <felipe.c...@gmail.com> wrote:

I don't think there's such incompatibility, but it's hart to tell
since those versions are very old. I think first you need to narrow
down your problem:

Is it in omapfb?
% gst-launch videotestsrc ! omapfbsink

It's not in omapfb. I can see the test pattern on the screen when running the above pattern. I also changed omapfb's rank to primary, disabled v4l and now it works also through the autovideosink.

 

Is it in dsp?
% gst-launch filesrc location=video.avi ! avidemux ! dspvdec ! fakesink -v

Strangely in the old kernel outputting to the fakesink worked (it didn't hit the kernel BUG()), but when going through the omapfbsink it crashed.

 

Ahd then perhaps try the latest and greatest stuff:

* dspbridge branch from l-o (based on 2.6.33):
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

* DSS2 patch for beagleboard (I assume that's what you are using):
http://article.gmane.org/gmane.linux.ports.arm.omap/34364

After this patch you can use fancier kernel options:
omapfb.mode=dvi:1024x768MR-24@60 omapfb.vram=0:2M,1:4M

Right now I'm running on the Technexion Thunder Board: http://www.technexion.com/index.php/thunder. I had to port the board support patches on to the new kernel. I don't know why they're not included yet in the linux-omap tree...

Anyway, I just built the new kernel and tried it together with the L23.i3.3 DSP firmware and the gst-dsp from branch next-l23-i3-3.
I also had to compile gst-dsp with NEW=1, otherwise it stops with "wcd_call_dev_io_ctl: Incompatible dspbridge ioctl number".

Now, when running gst-launch filesrc location=test.avi ! avidemux ! dspvdec ! fakesink -v I get:

(gst-launch-0.10:724): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...[ 1620.703491] proc_map: not aligned: 0x93c00 (68)

[ 1620.709655] proc_map: not aligned: 0x93d00 (68)
[ 1620.715148] proc_map: not aligned: 0x93e00 (68)
[ 1620.720184] proc_map: not aligned: 0x93f00 (68)
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstDspVDec:dspvdec0.GstPad:sink: caps = video/mpeg, mpegversion=(int)4, framerate=(fraction)25/1, width=(int)256, height=(int)480
/GstPipeline:pipeline0/GstDspVDec:dspvdec0.GstPad:sink: caps = video/mpeg, mpegversion=(int)4, framerate=(fraction)25/1, width=(int)256, height=(int)480
/GstPipeline:pipeline0/GstDspVDec:dspvdec0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)UYVY, width=(int)256, height=(int)480, framerate=(fraction)25/1
[ 1620.940795] proc_map: not aligned: 0x98d80 (16)
[ 1620.945922] proc_map: not aligned: 0x9e480 (16)
[ 1620.950622] proc_map: not aligned: 0xa6c00 (8120)
[ 1620.955963] proc_map: not aligned: 0xa8c80 (8120)
map_buffer: buffer not aligned: [ 1620.967254] memory_sync_page: no page for 000a7000
0x4235b008-0x42397008
[ 1620.973266] proc_memory_sync: InValid address parameters 000a6c00 1fb8
[ 1620.983856] memory_sync_page: no page for 000a9000
[ 1620.988708] proc_memory_sync: InValid address parameters 000a8c80 1fb8
[ 1620.996093] proc_map: not aligned: 0xa2b48 (15495)
[ 1621.001770] proc_map: not aligned: 0x9ce00 (403)
got_message: error: cmd=3584, arg1=2, arg2=3846

dsp_thread: failed waiting for events
dsp_thread: failed waiting for events
dsp_thread: failed waiting for events
dsp_thread: failed waiting for events

Caught interrupt -- handling interrupt.
Interrupt: Stopping pipeline ...

ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...

/GstPipeline:pipeline0/GstDspVDec:dspvdec0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstDspVDec:dspvdec0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstAviDem[ 1626.392547] procwrap_detach: deprecated dspbridge ioctl
ux:avidemux0.GstPad:video_00: caps = NULL
Freeing pipeline ...

Do you have any hint on how to debug this further? I can try tomorrow running on BeagleBoard, but I don't think it's going to make a difference.

Regards,
Ionut

[Ionut Nicu]

Hi,

On Sun, May 2, 2010 at 10:04 PM, Ionut Nicu <ionut...@gmail.com> wrote:

Now, when running gst-launch filesrc location=test.avi ! avidemux ! dspvdec ! fakesink -v I get:

(gst-launch-0.10:724): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...[ 1620.703491] proc_map: not aligned: 0x93c00 (68)

[ 1620.709655] proc_map: not aligned: 0x93d00 (68)
[ 1620.715148] proc_map: not aligned: 0x93e00 (68)
[ 1620.720184] proc_map: not aligned: 0x93f00 (68)

I disabled the CONFIG_BRIDGE_CACHE_LINE_CHECK option in my kernel config, and gst-dsp is now working with the new firmware. Btw, did TI remove its watermark in the L23.i3.3 release? The older codecs had a TI logo in the upper right corner ...

Regarding the alignment check, the kernel config help message says that if the start and end address of the dmm buffer are not 128 byte aligned it can lead to heap corruption because the DSP loads and writes data back in 128-byte chunks. From the output above I see that the start address is ok, it's just the size of the buffers (i.e. end address) that fails the alignment check.

Regards,
Ionut.

[Felipe Contreras]

On Mon, May 3, 2010 at 8:40 AM, Ionut Nicu <ionut...@gmail.com> wrote:
> On Sun, May 2, 2010 at 10:04 PM, Ionut Nicu <ionut...@gmail.com> wrote:
>>
>> Now, when running gst-launch filesrc location=test.avi ! avidemux !
>> dspvdec ! fakesink -v I get:
>>
>> (gst-launch-0.10:724): GLib-WARNING **: g_set_prgname() called multiple
>> times
>> Setting pipeline to PAUSED ...[ 1620.703491] proc_map: not aligned:
>> 0x93c00 (68)
>>
>> [ 1620.709655] proc_map: not aligned: 0x93d00 (68)
>> [ 1620.715148] proc_map: not aligned: 0x93e00 (68)
>> [ 1620.720184] proc_map: not aligned: 0x93f00 (68)
>
>
> I disabled the CONFIG_BRIDGE_CACHE_LINE_CHECK option in my kernel config,
> and gst-dsp is now working with the new firmware. Btw, did TI remove its
> watermark in the L23.i3.3 release? The older codecs had a TI logo in the
> upper right corner ...

Indeed, you need to disable that check.

> Regarding the alignment check, the kernel config help message says that if
> the start and end address of the dmm buffer are not 128 byte aligned it can
> lead to heap corruption because the DSP loads and writes data back in
> 128-byte chunks. From the output above I see that the start address is ok,
> it's just the size of the buffers (i.e. end address) that fails the
> alignment check.

Also, if you could fine-tune, you'll see that it's only the input
buffers that are failing that check; that's because the situation is
not so clear cut:

1) reading from a buffer that's not aligned is ok
2) writing to a buffer that's not ok causes memory corruption

We asked TI to use an extra field to distinguish between input and
output buffers, but we are not using that in gst-dsp yet. The API is
going to change very soon anyway.

I can provide more information about the cause of the memory
corruption if you want.

Cheers.

--
Felipe Contreras