I would also like to point out that the free() after the loop ( end of program ) is not necessary. Modern Linux versions deal with this automatically. I do not suppose it'll hurt, but figured I'd point that out.
On Tue, Mar 8, 2016 at 6:23 PM, William Hermans <[email protected]> wrote: > *Because it's not calling malloc() over and over...* >> > > Yeap, you're right it's calling memset() every loop. Not sure why I was > thinking it was calling malloc() every loop. But the point is, it does not > matter what is being called in the loop. any system / API call in the loop, > without some form of a sleep() will eat up a lot of CPU cycles. Again, as > much as the system will allow it to, which is usually in the mid to high > 90%'s . . . > > I'm surprised that code would compile at all without a compiler error. As >> &variable[0] probably is not what you think it is. >> > I see no issue here. Can you elaborate? > > So, &variable <- beginning of an array, equivalent to variable[0], but > what is &variable[0] ? A multi dimensional array ? that's not what was > defined . . . to be 100% honest I'm not sure what it does, but the first > thing that comes to mind is "undefined behavior". > > > On Tue, Mar 8, 2016 at 5:39 PM, <[email protected]> wrote: > >> I'm surprised that code would compile at all without a compiler error. As >>> &variable[0] probably is not what you think it is. >>> >> I see no issue here. Can you elaborate? >> >> >>> Also, for the record, infinitely allocating an arbitrary amount of >>> dynamic memory, in a loop, without any kind of a pause is going to eat up >>> an incredible amount of CPU cycles. As in that code will very likely use as >>> close to 100% CPU as the system will allow it. Which again, is no wonder >>> you're "flickering" . . . >>> >> The code is not allocating anything in a loop. >> >> >>> You lucky your program does not randomly crash for using malloc() on the >>> same dynamic memory over, and over, without using free(), or instead using >>> realloc() . . . >>> >> Because it's not calling malloc() over and over... >> >> >> The issue here is that if you run memset() in a tight loop (which at >> least one gstreamer1.6 audio decoder plugins does), it seems to clog up the >> data bus enough for the DMA to fail. >> >> >> >>> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál <[email protected]> wrote: >>> >>>> Hi Michael, >>>> >>>> we had very similar issue, which we encountered when updating to >>>> gstreamer 1.6. Using git bisect we were able to find a root cause and >>>> prepare simple test program, which reliably reproduces the issue: >>>> >>>> #include <string.h> >>>> #include <stdint.h> >>>> #include <stdlib.h> >>>> >>>> int main(int argc, char **argv) >>>> { >>>> int size; >>>> uint8_t *memblock; >>>> >>>> if (argc < 2) >>>> return -1; >>>> >>>> size = atoi(argv[1]); >>>> >>>> memblock = malloc(size); >>>> >>>> while (1) >>>> { >>>> memset(&memblock[0], 0, size); >>>> } >>>> >>>> free(memblock); >>>> >>>> return 0; >>>> } >>>> >>>> starting this program will cause crazy flickering, ... >>>> >>>> We were able to reproduce the issue with >>>> >>>> 1) debian originally provided on beaglebone using memtest utility for >>>> carlos. Kernel version was: >>>> >>>> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version >>>> 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015 >>>> >>>> 2) latest version of debian from beaglebone website Kernel version was: >>>> >>>> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc >>>> version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC >>>> 2016 >>>> >>>> so it seems to be existing for ages. >>>> >>>> Did you in the mean time managed to find a solution for your problem? >>>> >>>> Thanks, >>>> Radek >>>> >>>> On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg >>>> wrote: >>>>> >>>>> Hi there, >>>>> >>>>> >>>>> i was able to get my 10.1 custom Display to work with the RGB Pins on >>>>> the beaglebone black. >>>>> >>>>> I am using the latest Debian Jessie image from beagleboard.org and >>>>> the X11 Desktop has the right colors and the right size. >>>>> >>>>> So i assume that the Timings from my display are correct. >>>>> >>>>> >>>>> panel { >>>>> >>>>> status = "okay"; >>>>> >>>>> compatible = "ti,tilcdc,panel"; >>>>> >>>>> pinctrl-names = "default"; >>>>> >>>>> pinctrl-0 = <&bb_lcd_lcd_pins>; >>>>> >>>>> panel-info { >>>>> >>>>> ac-bias = <255>; >>>>> >>>>> ac-bias-intrpt = <0>; >>>>> >>>>> dma-burst-sz = <16>; >>>>> >>>>> bpp = <32>; >>>>> >>>>> fdd = <0x80>; >>>>> >>>>> tft-alt-mode = <0>; >>>>> >>>>> stn-565-mode = <0>; >>>>> >>>>> mono-8bit-mode = <0>; >>>>> >>>>> sync-edge = <0>; >>>>> >>>>> sync-ctrl = <1>; >>>>> >>>>> raster-order = <0>; >>>>> >>>>> fifo-th = <0>; >>>>> >>>>> }; >>>>> >>>>> display-timings { >>>>> >>>>> native-mode = <&timing0>; >>>>> >>>>> timing0: 1280x800 { >>>>> >>>>> clock-frequency = >>>>> <70000000>; >>>>> >>>>> hactive = <1280>; >>>>> >>>>> vactive = <800>; >>>>> >>>>> hfront-porch = <80>; >>>>> >>>>> hback-porch = <60>; >>>>> >>>>> hsync-len = <20>; >>>>> >>>>> vback-porch = <12>; >>>>> >>>>> vfront-porch = <8>; >>>>> >>>>> vsync-len = <3>; >>>>> >>>>> hsync-active = <0>; >>>>> >>>>> vsync-active = <0>; >>>>> >>>>> }; >>>>> >>>>> }; >>>>> >>>>> }; >>>>> >>>>> >>>>> But when i play a video or when i have many frames on the display i >>>>> get some screen flickers. >>>>> >>>>> >>>>> On the log via UART i see the following: >>>>> >>>>> >>>>> 1- When booting up: of_graph_get_next_endpoint(): no port node found >>>>> in /ocp/lcdc@4830e000 >>>>> >>>>> 2- When video or many frames are displayed: >>>>> >>>>> tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO underflow >>>>> >>>>> tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost >>>>> >>>>> >>>>> Any idea? >>>>> >>>>> >>>>> Is the DDR flash rate to slow? Or the DMA buffer not big enougth? >>>>> >>>>> >>>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "BeagleBoard" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
