[mythtv] LFireDev Error: Starting A/V streaming: Cannot allocate memory

Kelly Campbell kelly.a.campbell at gmail.com
Thu Oct 4 19:30:49 UTC 2007

Cool, good to hear that fix worked for you. I haven't compiled a
kernel with the patch yet mostly because I want to build using the
ubuntu/debian kernel build process and haven't figured that bit out
yet. It would be cool if you could followup with that info on the bug
at ubuntu launchpad. Maybe they can get the patch in there before the
7.10 release or if not at least in one of the first kernel updates.

I've found I don't need any of the special test firewire or channel
change scripts anymore with the new firewire code in mythtv trunk. I
have a motorola DCT-6200 (comcast) which is really really flakey, but
I finally had good luck other than the vmalloc_32 errors when I
switched to using broadcast mode. For some reason it only wants to
send video on channel 63, not channel 0 which  the p2p mode uses.


On 10/4/07, Bruce Markey <bjm at lvcm.com> wrote:
> Kelly Campbell wrote:
> > I think I found the cause but haven't been able to confirm the fix yet.
> >
> > https://bugs.launchpad.net/bugs/148854
> Yeah, this seems to be headed in the right direction.
> I've been using firewire captures for awhile. Having had a
> leaning curve to overcome or workaround a lot of gotchas,
> my impression was it is just a little too flaky to be
> trusted for day to day use.
> I don't recall "eno: Cannot allocate memory (12)" as being
> a problem when I first started but this has been a common
> occurrence over the past several weeks. Also, I had an earlier
> impression that I needed to run "firewire_tester -p -n 0 -R"
> after rebooting and after the connection was reset once, the
> connection would remain good until the next reboot. This too
> has not been true over the past several weeks but I was unaware
> how or if these were related.
> In some brief stabs at looking through the code, it appeared
> that the errno 12 wasn't from myth or libiec61883 but from
> libraw1394 where it was sizing the reads relative to the vm
> page size. However, it didn't make sense why it would throw
> this error. What I hadn't looked for was the very conspicuous
> "dma_region_alloc: vmalloc_32() failed" messages in syslog.
> These were enlightening.
> Not only did I find these at times when recordings failed with
> errno 12 but there were also clusters of errors grouped together
> every two seconds. There were the result of this:
> #!/bin/sh
> #
> # fw: script to attempt to reset firewire connections
> firewire_tester -p -n 0 -r 3
> if [ $? == 1 ]
> then
>     firewire_tester -p -n 0 -R
>     firewire_tester -p -n 0 -r 3
> fi
> I'd found that running "-R" when the connection was good would
> result in breaking it again so this just resets and retests if
> it fails. I wasn't aware, however, that firewire_tester could
> fail due to the exact same vmalloc issue. These failures are not
> a network issue with the STB but false negatives due to the
> kernel bug.
> Oct  3 22:42:26 bigboy kernel: dma_region_alloc: vmalloc_32() failed
> Oct  3 22:42:28 bigboy kernel: dma_region_alloc: vmalloc_32() failed
> Oct  3 22:42:30 bigboy kernel: dma_region_alloc: vmalloc_32() failed
> Oct  3 22:42:32 bigboy kernel: dma_region_alloc: vmalloc_32() failed
> Oct  3 22:42:34 bigboy kernel: dma_region_alloc: vmalloc_32() failed
> Oct  3 22:42:36 bigboy kernel: dma_region_alloc: vmalloc_32() failed
> These were the result of my firewire_tester script failing.
> Oct  3 22:59:56 bigboy kernel: dma_region_alloc: vmalloc_32() failed
> This was mythbackend trying to start SportsCenter
> Oct  3 23:00:59 bigboy kernel: dma_region_alloc: vmalloc_32() failed
> This was my restart of mythbackend and it failed to record a
> second time. I restarted again and the recording worked on the
> third attempt.
> So, I rebooted a kernel last night with this patch from the
> original author at " http://lkml.org/lkml/2007/7/18/34 ". I
> have done several firewire captures including back to back
> recordings without fail. I've also run my "fw" many times
> and it never throws a vmalloc error.
> : root at bigboy \# ; grep -c dma_region_alloc /var/log/syslog.0
> 28
> : root at bigboy \# ; grep -c dma_region_alloc /var/log/syslog
> 0
> --  bjm
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

More information about the mythtv-dev mailing list