Hi
Just for clarification
I forgot to add that I had already got past that little bump by chunking
the allocation to src_buf in the same loop as the memcpy_toio
But I'll rebuild the module with the memcpy_toio directly accessing src
and see how it goes.
Regards
Richard Tresidder
On 05/10/15 22:35, Richard Tresidder wrote:
On 05/10/15 22:22, Steven Toth wrote:
On Sun, Oct 4, 2015 at 9:59 PM, Richard Tresidder
<rtresidd@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Steven
Nope standard x86_64
kernel 3.10.0-229.14.1.el7.x86_64
Hmm.
Was rather surprised as all my quick reading indicates that the kernel
should quite happily do this...
Though looks like its the largest chunk you can request? I'm not
well enough
up to speed with the nitty gritty..
Yeah, 4MB is the upper limit IIRC.
There is mention of something similar against this card on www
linuxtv org
wiki index.php Hauppauge_WinTV-HVR-2200
********
Note: Some kernels will not have enough free memory available for the
driver. The dmesg error will start with a message like this:
] modprobe: page allocation failure: order:10, mode:0x2000d0
followed by a stack trace and other debugging information. While the
driver
will load, no devices will be registered.
The simple workaround is to allocate more memory for the kernel:
sudo /bin/echo 16384 > /proc/sys/vm/min_free_kbytes
sudo rmmod saa7164
sudo modprobe saa7164
********
Hmm. I wasn't aware people in the past has seen the issue either. I
assume you've tried the above and its not helping, or in fact growing
that number for experimentation purposes.
Do you have a large number of other devices / drivers loaded? I
suspect another driver is burning through kernel memory before the
saa7164 has a chance to be initialized.
Nope nothing I can see Its actually the only addon card I have in this
system..
I'd be buggered If 4GB of RAM is fragmented enough early on in the
boot stage...?
I've hunted but can't find a nice way to determine what contiguous
blocks are available..
Noted there was a simple module that could be compiled in to test such
things, I'll play with that and see what it turns up..
I took a quick look at saa7164-fw.c this morning, I see no reason why
the allocation is required at all. With a small patch the function
could be made to memcpy from 'src' directly, dropping the need to
allocate srcbuf what-so-ever. This would remove the need for the 4MB
temporary allocation, and might get you past this issue, likely on to
the next (user buffer allocations are also large - as I recall). Note
that the 4MB allocation is temporary, so its not a long term saving,
but it might get you past the hump.
That was my thoughts exactly.. but I took a minimal fiddling approach
to begin with..
I wasn't sure if there was some requirement for the memcpy_toio
requiring a specially allocated source..? can't see why..
Was going to dig into that next as a side job..
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
