[mythtv-users] Can't open 3rd DVB device - malloc error?

Henry A Harper III hah at alumni.rice.edu
Fri Sep 22 16:13:13 UTC 2006

> -----Original Message-----
> From: Henry A Harper III [mailto:hah at alumni.rice.edu]
> Sent: Monday, September 18, 2006 11:51 AM
> To: Janne Grunau
> Cc: mythtv-users at mythv.org
> Subject: RE: [mythtv-users] Can't open 3rd DVB device - malloc error?
> > -----Original Message-----
> > From: Janne Grunau [mailto:janne-mythtvusers at grunau.be]
> > Sent: Thursday, September 14, 2006 10:10 AM
> > To: hah at alumni.rice.edu
> > Subject: Re: [mythtv-users] Can't open 3rd DVB device - malloc error?
> >
> > On Thursday 14 September 2006 17:06, Henry A Harper III wrote:
> >
> > > I uninstalelled the pchdtv.com v4l drivers by "modprobe -r
> > > "-ing the ko's I found with matching datestamps to the ones I
> > > compiled from pchdtv.com, but I have also disabled my sound in this
> > > way so it's probably not the recommended method. Full dmesg attached.
> >
> > The dmesg suggest that you're still using parts of the pchdtv.com
> > drivers. I was told that you should reinstall the following package
> > video4linux-kmdl-`uname -r`.
> >
> > A dvb developer suggested that the pchdtv.com tarball might not work
> > correctly with the fedora kernel.
> After trying a vmalloc kernel parameter which caused a kernel
> panic because the initrd wasn't set for that size of vmalloc, I
> did manage to succeed in installing the v4l package and
> discovered...a slightly different error message complaining about
> memory allocation, when I tried to start a third DVB recording.
> Then, reading some of the other recent discussions here about
> ringbuffers, a little light bulb popped on above my head. True, I
> have lots of RAM, but apparently the ringbuffer comes out of the
> kernel's fixed (at compile time) memory segment not out of "user"
> memory space. And I had raised the ringbuffer setting to 21MB or
> so trying to get all three tuners to work. So, I thought, how
> about cranking that back down to minimum? I did have to restart
> the backend since it's not set to release the DVB cards, but
> after that I was recording 3 HD DVB programs simultaneously.
> To sum up: when the next myth-noob asks about why the 3rd DVB
> won't record, tell him to put the ringbuffer setting back down
> where it belongs.
> But sound still doesn't work - I did pull the tuner cards and
> sound worked as before, but in all the in/un/re-stalling of the
> various DVB drivers something with the sound drivers/modules has
> gotten fubar-ed. I had a busy weekend so haven't had a chance to
> look at that just yet but I really need to get on it with new TV
> season starting tonight. I'll start a new thread about that.

I won't need to start a new thread because it's all somewhat related. In
hindsight, it was not the fact that the ringbuffer was set too large that
was preventing me from recording from all three cards, it was all the
modules I was loading. What allowed me to get all three going when I
installed the v4l RPM was the coincidence that a part of the v4l module was
keeping alsa from fully loading and therefore not taking up as much space as
it would when properly loaded. This I discovered by building the latest v4l
drivers from source, having sound functional, and again getting an error
message when trying to pull in the third tuner.

Taking a look at my lsmod usage, I turned off a couple things like Bluetooth
(which sounded cool but I won't really be using in on this box) but it still
wasn't enough. I could get all three cards going by switching to runlevel 3
and unloading the very large nvidia module. Progress?

But having to remember to init 3 on Sundays, Mondays, Tuesdays - the current
days of the week when I have 3 tuners scheduled - didn't sound that fun. So
I went back to trying to increase the vmalloc size without causing kernel
panic. Well, first I tried just using metacity (per wiki's sample .xsession
file) instead of gnome but that didn't seem to decrease Vmalloc memory usage
according to /proc/meminfo. It did fail to use XvMC though when I tried to
watch TV, apparently - another reboot for zombie Xorg reasons.

The kernel panic is caused by grub wanting to put the initrd at the top of
memory, then when you ask for more space in the kernel with vmalloc that
pushes the initrd out past the end of RAM which is a bad thing. Not using
the initrd didn't work for me either. So you tell grub that there is less
RAM than you actually have and it will put the initrd in a more satisfying

I added an "uppermem 524288" line before the kernel line in my
/etc/grub.conf and then was able to add "vmalloc=148m" (default is 128m,
148m is a random selection larger than 128m that happens to work for me) to
the end of the kernel line without causing any panic.

Now I can have three recordings going while watching something else, with
sound. I did a little happy dance when it all worked. And now, to watch some


More information about the mythtv-users mailing list