Updated GPU firmware


309 posts   Page 8 of 13   1 ... 5, 6, 7, 8, 9, 10, 11 ... 13
by JerryPi » Tue Dec 11, 2012 5:48 pm
My two Pis (256MB and 512MB) wont survive a hard reboot (unplugging and replugging the power) on the latest next branch (c6b0066396723a86f390f8330a679bbce8e99b9b). They both hang about 20lines after the rainbow screen (something about vchiq). The only way to get them back up is to restore /boot from master branch. However if I do a soft reboot (sudo reboot) after rpi-update to latest next branch, both work fine and the dynamic memory allocation is working. I power cycled one today because of some wifi trouble and noticed this and then proceeded to power cycle the other one and the same happened.
Anyone observed the same?
Don't grow up, it's a trap!
Posts: 16
Joined: Tue Nov 20, 2012 8:25 am
by mahjongg » Tue Dec 11, 2012 5:50 pm
This probably meant the PI (or the card itself) didn't have time to flush its write buffers to the SD-card, causing corruptions.

Tip of the day today happens to be "Tip of the day: Always shut your PI down cleanly with sudo halt" see frontpage.
User avatar
Forum Moderator
Forum Moderator
Posts: 5339
Joined: Sun Mar 11, 2012 12:19 am
by teh_orph » Tue Dec 11, 2012 8:09 pm
JerryPi wrote:<snip>
Yes, I'm seeing the same vchiq errors. Most power cycles it won't come up but it sometimes does (I am however using a non-stock kernel).

The data's definitely on the SD card and I did a sync before shutdown...plus diffing the files against what should be there gives no differences...?
User avatar
Posts: 345
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
by JerryPi » Tue Dec 11, 2012 8:43 pm
There was no corruption of my SD cards and I did it with a clean shut down (sudo halt).
I managed to get it up and running after around 10 power cycles like teh_orph said, and after that it would not hang anymore. But then if I did a sudo reboot and then a sudo halt it would hang after power cycling.
Last few lines at boot
Code: Select all
...
[    1.462326] brd:module loaded
[    1.470701] loop: module loaded
[    1.474432] vchiq: vchiq_init_state: slot_zero=0xc7000000, is_master =0
[    1.482365] vchiq_get_state:g_state.remote->initialised != 1 (0)
and then it hangs.
When it's up and running I get all sorts of allocation failures (that's where my wifi trouble came from)
Code: Select all
Dec 11 21:47:17 raspberrypi kernel: [  120.768348] swapper: page allocation failure: order:0, mode:0x20
Dec 11 21:47:17 raspberrypi kernel: [  120.768421] [<c0013a7c>] (unwind_backtrace+0x0/0xf0) from [<c0092638>] (warn_alloc_failed+0xc4/0x11c)
Dec 11 21:47:17 raspberrypi kernel: [  120.768454] [<c0092638>] (warn_alloc_failed+0xc4/0x11c) from [<c0094948>] (__alloc_pages_nodemask+0x3e0/0x63c)
Dec 11 21:47:17 raspberrypi kernel: [  120.768488] [<c0094948>] (__alloc_pages_nodemask+0x3e0/0x63c) from [<c02e67c8>] (__netdev_alloc_frag+0xc4/0xe4)
Dec 11 21:47:17 raspberrypi kernel: [  120.768518] [<c02e67c8>] (__netdev_alloc_frag+0xc4/0xe4) from [<c02ea8d0>] (__netdev_alloc_skb+0x40/0xd0)
Dec 11 21:47:17 raspberrypi kernel: [  120.768824] [<c02ea8d0>] (__netdev_alloc_skb+0x40/0xd0) from [<bf016708>] (recv_tasklet+0x2a0/0x334 [r8712u])
Dec 11 21:47:17 raspberrypi kernel: [  120.769040] [<bf016708>] (recv_tasklet+0x2a0/0x334 [r8712u]) from [<c002567c>] (tasklet_hi_action+0x60/0xb4)
Dec 11 21:47:17 raspberrypi kernel: [  120.769076] [<c002567c>] (tasklet_hi_action+0x60/0xb4) from [<c0025860>] (__do_softirq+0xa0/0x154)
Dec 11 21:47:17 raspberrypi kernel: [  120.769105] [<c0025860>] (__do_softirq+0xa0/0x154) from [<c0025d28>] (irq_exit+0x8c/0x94)
Dec 11 21:47:17 raspberrypi kernel: [  120.769141] [<c0025d28>] (irq_exit+0x8c/0x94) from [<c000e920>] (handle_IRQ+0x34/0x84)
Dec 11 21:47:17 raspberrypi kernel: [  120.769169] [<c000e920>] (handle_IRQ+0x34/0x84) from [<c039b934>] (__irq_svc+0x34/0xc8)
Dec 11 21:47:17 raspberrypi kernel: [  120.769195] [<c039b934>] (__irq_svc+0x34/0xc8) from [<c000ea60>] (default_idle+0x28/0x30)
Dec 11 21:47:17 raspberrypi kernel: [  120.769220] [<c000ea60>] (default_idle+0x28/0x30) from [<c000ec10>] (cpu_idle+0x90/0xb8)
Dec 11 21:47:17 raspberrypi kernel: [  120.769250] [<c000ec10>] (cpu_idle+0x90/0xb8) from [<c04e873c>] (start_kernel+0x28c/0x2d4)
Dec 11 21:47:17 raspberrypi kernel: [  120.769258] Mem-info:
Dec 11 21:47:17 raspberrypi kernel: [  120.769266] Normal per-cpu:
Dec 11 21:47:17 raspberrypi kernel: [  120.769277] CPU    0: hi:  186, btch:  31 usd:  48
Dec 11 21:47:17 raspberrypi kernel: [  120.769301] active_anon:4084 inactive_anon:4055 isolated_anon:0
Dec 11 21:47:17 raspberrypi kernel: [  120.769301]  active_file:5546 inactive_file:13670 isolated_file:0
Dec 11 21:47:17 raspberrypi kernel: [  120.769301]  unevictable:0 dirty:1704 writeback:0 unstable:0
Dec 11 21:47:17 raspberrypi kernel: [  120.769301]  free:83924 slab_reclaimable:704 slab_unreclaimable:1177
Dec 11 21:47:17 raspberrypi kernel: [  120.769301]  mapped:5100 shmem:111 pagetables:298 bounce:0
Dec 11 21:47:17 raspberrypi kernel: [  120.769354] Normal free:335696kB min:8192kB low:10240kB high:12288kB active_anon:16336kB inactive_anon:16220kB active_file:22184kB inactive_file:54680kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:483488kB mlocked:0kB dirty:6816kB writeback:0kB mapped:20400kB shmem:444kB slab_reclaimable:2816kB slab_unreclaimable:4708kB kernel_stack:1264kB pagetables:1192kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Dec 11 21:47:17 raspberrypi kernel: [  120.769366] lowmem_reserve[]: 0 0
Dec 11 21:47:17 raspberrypi kernel: [  120.769385] Normal: 12776*4kB 12776*8kB 11399*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 335696kB
Dec 11 21:47:17 raspberrypi kernel: [  120.769427] 19327 total pagecache pages
Dec 11 21:47:17 raspberrypi kernel: [  120.769434] 0 pages in swap cache
Dec 11 21:47:17 raspberrypi kernel: [  120.769443] Swap cache stats: add 0, delete 0, find 0/0
Dec 11 21:47:17 raspberrypi kernel: [  120.769449] Free swap  = 102396kB
Dec 11 21:47:17 raspberrypi kernel: [  120.769456] Total swap = 102396kB
Dec 11 21:47:17 raspberrypi kernel: [  120.794572] 121856 pages of RAM
Dec 11 21:47:17 raspberrypi kernel: [  120.794583] 84265 free pages
Dec 11 21:47:17 raspberrypi kernel: [  120.794589] 2742 reserved pages
Dec 11 21:47:17 raspberrypi kernel: [  120.794596] 1881 slab pages
Dec 11 21:47:17 raspberrypi kernel: [  120.794603] 20183 pages shared
Dec 11 21:47:17 raspberrypi kernel: [  120.794610] 0 pages swap cached

I don't know if this is vchiq/cma based or due to kernel being bumped to 3.6.9+
Don't grow up, it's a trap!
Posts: 16
Joined: Tue Nov 20, 2012 8:25 am
by dom » Wed Dec 12, 2012 1:32 pm
JerryPi wrote:There was no corruption of my SD cards and I did it with a clean shut down (sudo halt).
I managed to get it up and running after around 10 power cycles like teh_orph said, and after that it would not hang anymore. But then if I did a sudo reboot and then a sudo halt it would hang after power cycling.

Does boot_delay=1 (or higher) make a difference?
JerryPi wrote:I don't know if this is vchiq/cma based or due to kernel being bumped to 3.6.9+

I assume you have cma_lwm/cma_hwm in config.txt ? Can you remove those - that disables cma, and should show if problem is cma or new-kernel related.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by JerryPi » Wed Dec 12, 2012 2:15 pm
Yes cma_lwm/cma_hwm/cma_offline_start is in the config.txt as per your example.
I don't have physical access to any of my Pis at the moment. Will try it in the evening. However, I did try the next commit of 4.12. (d77ec8c482df21ac8eba5e2906bdb5ca8fdf892d) yesterday and got the same results.
Don't grow up, it's a trap!
Posts: 16
Joined: Tue Nov 20, 2012 8:25 am
by Max » Wed Dec 12, 2012 8:27 pm
Following patch lowered the number of network related page_alloc errors during my testing: http://git.kernel.org/?p=linux/kernel/g ... a6fffb78db

(Note that it is mitigation, rather than a full fix.
It requests memory in chunks of 32k, instead of 4k at a time.
Reducing the number of calls to page_alloc, and therefore times it can fail).
by dom » Wed Dec 12, 2012 8:51 pm
Max wrote:Following patch lowered the number of network related page_alloc errors during my testing: http://git.kernel.org/?p=linux/kernel/g ... a6fffb78db

(Note that it is mitigation, rather than a full fix.
It requests memory in chunks of 32k, instead of 4k at a time.
Reducing the number of calls to page_alloc, and therefore times it can fail).

Interesting. I'll give it a try.

Any thoughts why the cma enabled case has more allocation failures than the cma disabled case?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by JerryPi » Wed Dec 12, 2012 9:28 pm
All of today's test were done on a next 11.12. (788cddf57e1c9650f34b2cdea8c74410626805a9) commit.
dom wrote:Does boot_delay=1 (or higher) make a difference?

I think boot_delay has no effect on a successful boot. If anything, I had more luck setting boot_delay to 1 than to 5, which seem to have made it worse, but I didn't do it enough times to have any meaningful statistics. I tried this on rev 15 and rev 2 boards however, I was using the same SD card.
dom wrote:I assume you have cma_lwm/cma_hwm in config.txt ? Can you remove those - that disables cma, and should show if problem is cma or new-kernel related.

As soon as I commented out cma settings, boot didn't hang and I couldn't reproduce any allocation errors.
FYI, on this commit, rsyslogd is always forcefully killed at halt/reboot.
Don't grow up, it's a trap!
Posts: 16
Joined: Tue Nov 20, 2012 8:25 am
by Max » Thu Dec 13, 2012 2:16 am
dom wrote:Any thoughts why the cma enabled case has more allocation failures than the cma disabled case?


Am afraid I have no idea.
Haven't found a place yet where the CMA memory wasn't seen as normal memory. It is even counted as part of zone "normal" in /proc/zoneinfo instead of a separate zone.

==

Image

Another issue I'm having is that OpenELEC hangs at this point if CMA is enabled (gpu_mem=368, cma_lwm=16, cma_hwm=32, cma_offline_start=16) while it does work properly with static split (gpu_mem=128).
Only displays its wallpaper, mouse cursor doesn't move, no changes after several minutes.
Believe you mentioned you got XBMC to work. Did you use any special CMA settings, code changes or compile options for that?
by JerryPi » Thu Dec 13, 2012 6:59 am
Max wrote:Believe you mentioned you got XBMC to work. Did you use any special CMA settings, code changes or compile options for that?

I just recompiled it with latest hardfp libs, you can try my build http://goo.gl/jqCoC.
Don't grow up, it's a trap!
Posts: 16
Joined: Tue Nov 20, 2012 8:25 am
by dom » Thu Dec 13, 2012 2:00 pm
Max wrote:Another issue I'm having is that OpenELEC hangs at this point if CMA is enabled (gpu_mem=368, cma_lwm=16, cma_hwm=32, cma_offline_start=16) while it does work properly with static split (gpu_mem=128).
Only displays its wallpaper, mouse cursor doesn't move, no changes after several minutes.
Believe you mentioned you got XBMC to work. Did you use any special CMA settings, code changes or compile options for that?


With latest firmware (788cddf57e1c9650f34b2cdea8c74410626805a9) and cmdline.txt
Code: Select all
smsc95xx.turbo_mode=N console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 nfsroot=10.177.12.207:/home/dc4/rootfs ip=dhcp rootwait

and config.txt
Code: Select all
boot_delay=1
disable_overscan=1
hdmi_ignore_cec_init=1
arm_freq=1000
over_voltage=6
core_freq=350
sdram_freq=500
force_turbo=1
gpu_mem=368
cma_lwm=16
cma_hwm=32
cma_offline_start=16

and top of tree xbmc (https://github.com/xbmc/xbmc/commits/master) and it works very well. Can browse library and play 1080p movies. No errors in dmesg log.

(BTW: I couldn't see your image link)
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Max » Thu Dec 13, 2012 3:09 pm
dom wrote:
Max wrote:Another issue I'm having is that OpenELEC hangs at this point if CMA is enabled (gpu_mem=368, cma_lwm=16, cma_hwm=32, cma_offline_start=16) while it does work properly with static split (gpu_mem=128).
Only displays its wallpaper, mouse cursor doesn't move, no changes after several minutes.
Believe you mentioned you got XBMC to work. Did you use any special CMA settings, code changes or compile options for that?


With latest firmware (788cddf57e1c9650f34b2cdea8c74410626805a9) and cmdline.txt
Code: Select all
smsc95xx.turbo_mode=N console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 nfsroot=10.177.12.207:/home/dc4/rootfs ip=dhcp rootwait



Did some more testing.

And it seems that if I have CMA enabled and serial console enabled ("console=ttyAMA0,115200") it does work ok.
If I have CMA enabled but do not have a console= option or only have "console=tty1" OpenELEC hangs.
With CMA disabled, and a static split it works ok regardless of console option.

Is there anything in the CMA code that depends on the UART being initialized?
by dom » Thu Dec 13, 2012 3:53 pm
Max wrote:Did some more testing.

And it seems that if I have CMA enabled and serial console enabled ("console=ttyAMA0,115200") it does work ok.
If I have CMA enabled but do not have a console= option or only have "console=tty1" OpenELEC hangs.
With CMA disabled, and a static split it works ok regardless of console option.

Is there anything in the CMA code that depends on the UART being initialized?

No. I can't imagine any connection between CMA and UART. Best guess is there is some subtle timing effect when serial console is enabled.

Does underclocking arm make it work without serial enabled?
(e.g.
arm_freq=500
arm_freq_min=500
in config.tyt)
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Max » Thu Dec 13, 2012 5:28 pm
I just recompiled it with latest hardfp libs, you can try my build http://goo.gl/jqCoC.


Same problem with that one.

With "console=ttyAMA0,115200" in cmdline.txt it starts.
Without it, it does not work.

With the difference that it does not hang, but exits cleanly with an error after 6 seconds.

Code: Select all
pi@raspberrypi ~ $ time sudo /usr/lib/xbmc/xbmc.bin
ERROR: Unable to create GUI. Exiting

real    0m6.648s
user    0m1.500s
sys     0m0.680s



dom wrote:Does underclocking arm make it work without serial enabled?
(e.g.
arm_freq=500
arm_freq_min=500
in config.tyt)


No, doesn't help.
Doesn't show CMA being used either.
If I login using SSH, and do "cat /proc/vc-cma" repeately during the 6 seconds startup of XBMC it keeps showing used: 0.

Code: Select all
$ cat /proc/vc-cma
Videocore CMA:
   Base       : 0a000000
   Length     : 14c00000
   Initial    : 00000000
   Chunk size : 00040000
   Chunks     : 1328 (348127232 bytes)
   Used       :    0 (0 bytes)
   Reserved   :    0 (0 bytes)


No kernel messages during XBMC startup.
CMA messages during boot:

Code: Select all
dmesg |grep -i cma
[    0.000000] early_vc_cma_mem(0/0x14c00000@0xa000000)
[    0.000000]  -> initial 0, size 14c00000, base a000000<6>[    0.000000] cma: CMA: reserved 332 MiB at 0a000000
[    0.000000] cma: CMA: reserved 16 MiB at 08000000
[    0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1080 bcm2708.boardrev=0xf bcm2708.serial=0xee34d94 smsc95xx.macaddr=B8:27:EB:E3:4D:94 sdhci-bcm2708.emmc_clock_freq=100000000 vc-cma-mem=0/0x14c00000@0xa000000 mem=0x9000000@0x0 mem=0x14c00000@0xa000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  coherent_pool=6M smsc95xx.turbo_mode=N  bootmenutimeout=10 datadev=mmcblk0p2 console=tty1
[    1.952707] vc-cma: Videocore CMA driver
[    1.952864] vc-cma: vc_cma_base      = 0x0a000000
[    1.953003] vc-cma: vc_cma_size      = 0x14c00000 (332 MiB)
[    1.953157] vc-cma: vc_cma_initial   = 0x00000000 (0 MiB)


==

With console=ttyAMA0 it shows CMA does work, and it uses 27 MB while being in the first screen of the XBMC menu:

Code: Select all
$ cat /proc/vc-cma
Videocore CMA:
   Base       : 0a000000
   Length     : 14c00000
   Initial    : 00000000
   Chunk size : 00040000
   Chunks     : 1328 (348127232 bytes)
   Used       :  104 (27262976 bytes)
   Reserved   :    0 (0 bytes)
by Max » Thu Dec 13, 2012 11:37 pm
dom wrote:Best guess is there is some subtle timing effect when serial console is enabled.

Does underclocking arm make it work without serial enabled?


Although it didn't show up with underclocking to 500 and 250, you are right and it is indeed a timing problem in the vchiq code.

Overlooked an obvious kernel message earlier.
With serial console:

Code: Select all
[    3.718682] vchiq: vchiq_init_state: slot_zero = 0xca000000, is_master = 0
[    3.720095] vchiq_get_state: g_state.remote->initialised != 1 (0)


Without serial console:

Code: Select all
[    3.690331] vchiq: vchiq_init_state: slot_zero = 0xca000000, is_master = 0
[    3.691608] vchiq_get_state: g_state.remote->initialised != 1 (0)
[    3.692097] vchiq: vchiq_initialise: videocore not initialized



vchiq_initialise() in vchiq_kern_lib.c looks like this:

Code: Select all
VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instanceOut)
{
   VCHIQ_STATUS_T status = VCHIQ_ERROR;
   VCHIQ_STATE_T *state;
   VCHIQ_INSTANCE_T instance = NULL;

   vchiq_log_trace(vchiq_core_log_level, "%s called", __func__);

   state = vchiq_get_state();
   if (!state) {
      vchiq_log_error(vchiq_core_log_level,
         "%s: videocore not initialized\n", __func__);
      goto failed;
   }


vchiq_get_state()

Code: Select all
VCHIQ_STATE_T *
vchiq_get_state(void)
{

   if (g_state.remote == NULL)
      printk(KERN_ERR "%s: g_state.remote == NULL\n", __func__);
   else if (g_state.remote->initialised != 1)
      printk(KERN_ERR "%s: g_state.remote->initialised != 1 (%d)\n",
         __func__, g_state.remote->initialised);

   return ((g_state.remote != NULL) &&
      (g_state.remote->initialised == 1)) ? &g_state : NULL;
}


In the time that it takes to print "vchiq_get_state: g_state.remote->initialised != 1 (0)" to serial console, g_state.remote->initialised becomes true.
So then it returns true at the end of function after all.
Without having to write messages to a slow serial console it returns false.


For testing purposes I changed the code to:

Code: Select all
VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instanceOut)
{
   VCHIQ_STATUS_T status = VCHIQ_ERROR;
   VCHIQ_STATE_T *state;
   VCHIQ_INSTANCE_T instance = NULL;

   vchiq_log_trace(vchiq_core_log_level, "%s called", __func__);

   state = vchiq_get_state();
   if (!state) {
      vchiq_log_error(vchiq_core_log_level, "%s: videocore not ready yet. Waiting 500 us", __func__);
      udelay(500);

      state = vchiq_get_state();
      if (!state) {
         vchiq_log_error(vchiq_core_log_level,
            "%s: videocore not initialized\n", __func__);
         goto failed;
      } else {
         vchiq_log_error(vchiq_core_log_level, "%s: videocore ready now", __func__);   
      }
   }


And that indeed prints out:

Code: Select all
[    3.834229] vchiq: vchiq_init_state: slot_zero = 0xca000000, is_master = 0
[    3.835555] vchiq_get_state: g_state.remote->initialised != 1 (0)
[    3.836051] vchiq: vchiq_initialise: videocore not ready yet. Waiting 500 us
[    3.836596] vchiq: vchiq_initialise: videocore ready now


Confirming that theory. And XBMC works properly now.
by dom » Fri Dec 14, 2012 2:19 pm
Max wrote:Confirming that theory. And XBMC works properly now.


Thanks Max. I agree with your analysis. I don't see the problem (even with serial disabled), but I'm using nfs boot, which probably adds enough delays to make this safe.
I think this is safe when CMA is not in use as nothing else requires VCHIQ during boot.

I'll have a think about what the best fix is. The solid fix is to do a mailbox_read after the mailbox write, which could guarantee GPU is initialised.
That has the disadvantage of killing linux booting when the message isn't responded to (e.g. a mismatched ARM and GPU code).

A sleepy retry mechanism like yours may be a better compromise.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Max » Fri Dec 14, 2012 11:45 pm
dom wrote:I'll have a think about what the best fix is. The solid fix is to do a mailbox_read after the mailbox write, which could guarantee GPU is initialised.
That has the disadvantage of killing linux booting when the message isn't responded to (e.g. a mismatched ARM and GPU code).


Option would be to add a timeout to that function.

Code: Select all
static int mbox_read(struct vc_mailbox *mbox, unsigned chan, uint32_t *data28)
{
   int rc;

   if (mbox->magic != MBOX_MAGIC)
      rc = -EINVAL;
   else {
      down(&mbox->sema[chan]);
      *data28 = MBOX_DATA28(mbox->msg[chan]);
      mbox->msg[chan] = 0;
      rc = 0;
   }
   return rc;
}


Think you should be able to wait for the semaphore with a timeout like this:

Code: Select all
static int mbox_read_timeout(struct vc_mailbox *mbox, unsigned chan, uint32_t *data28, long timeout_in_jiffies)
{
   int rc;

   if (mbox->magic != MBOX_MAGIC)
      rc = -EINVAL;
   else {
      if (down_timeout(&mbox->sema[chan], timeout_in_jiffies) == 0) {
         *data28 = MBOX_DATA28(mbox->msg[chan]);
         mbox->msg[chan] = 0;
         rc = 0;
      } else {
         rc = -ETIME; /* timed out */
      }
   }
   return rc;
}


Haven't tested it though.
by mcgyver83 » Fri Dec 21, 2012 2:23 pm
So seems that with "console=ttyAMA0,115200" in cmdline.txt CMA works fine, without no; the "solution" is to add this property to the cmdline.txt and everything is fine?
Posts: 309
Joined: Fri Oct 05, 2012 11:49 am
by Vulpes » Sun Dec 23, 2012 10:57 am
dom wrote:With latest firmware (788cddf57e1c9650f34b2cdea8c74410626805a9) and cmdline.txt
Code: Select all
smsc95xx.turbo_mode=N console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 nfsroot=10.177.12.207:/home/dc4/rootfs ip=dhcp rootwait

and config.txt
Code: Select all
boot_delay=1
disable_overscan=1
hdmi_ignore_cec_init=1
arm_freq=1000
over_voltage=6
core_freq=350
sdram_freq=500
force_turbo=1
gpu_mem=368
cma_lwm=16
cma_hwm=32
cma_offline_start=16

and top of tree xbmc (https://github.com/xbmc/xbmc/commits/master) and it works very well. Can browse library and play 1080p movies. No errors in dmesg log.

(BTW: I couldn't see your image link)

With these options (without OC and nfs stuff) and firmware and kernel built yesterday on Arch, Pi hangs on boot with this:
Image
It boots fine with static split.
Posts: 12
Joined: Sat Nov 03, 2012 2:41 pm
by dom » Sun Dec 23, 2012 2:25 pm
Vulpes wrote:With these options (without OC and nfs stuff) and firmware and kernel built yesterday on Arch, Pi hangs on boot with this:
It boots fine with static split.


Do you have "console=ttyAMA0,115200" in cmdline.txt ?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Vulpes » Sun Dec 23, 2012 2:28 pm
Yes.
Posts: 12
Joined: Sat Nov 03, 2012 2:41 pm
by Max » Wed Dec 26, 2012 6:20 pm
With the latest firmware I'm also having a problem connecting to vchiq even without cma and with console=ttyAMA0,115200.

[ 4.867359] vchiq_get_state: g_state.remote->initialised != 1 (0)
[ 4.867389] vchiq: vchiq has no connection to VideoCore


(It tries to connect straight after boot, because my boot menu has CEC support, which now doesn't work anymore.
Latest next firmware. Latest next userland libraries compiled from source, latest next kernel compiled from source)
by dom » Wed Dec 26, 2012 6:51 pm
Max wrote:With the latest firmware I'm also having a problem connecting to vchiq even without cma and with console=ttyAMA0,115200.

[ 4.867359] vchiq_get_state: g_state.remote->initialised != 1 (0)
[ 4.867389] vchiq: vchiq has no connection to VideoCore


(It tries to connect straight after boot, because my boot menu has CEC support, which now doesn't work anymore.
Latest next firmware. Latest next userland libraries compiled from source, latest next kernel compiled from source)


Does the retry hack fix this? I am sitting on a variant of retry hack and will push it out if this is the solution to your problem.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4013
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Max » Wed Dec 26, 2012 8:01 pm
dom wrote:
Max wrote:With the latest firmware I'm also having a problem connecting to vchiq even without cma and with console=ttyAMA0,115200.

[ 4.867359] vchiq_get_state: g_state.remote->initialised != 1 (0)
[ 4.867389] vchiq: vchiq has no connection to VideoCore


(It tries to connect straight after boot, because my boot menu has CEC support, which now doesn't work anymore.
Latest next firmware. Latest next userland libraries compiled from source, latest next kernel compiled from source)


Does the retry hack fix this? I am sitting on a variant of retry hack and will push it out if this is the solution to your problem.


Yes, retry hack still works.
Delay needs to be more then the 500 us I had first though, now have 750.