From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp2.wa.amnet.net.au ([203.161.124.51]:33180 "EHLO smtp2.wa.amnet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751115AbbJEOfX (ORCPT ); Mon, 5 Oct 2015 10:35:23 -0400 Subject: Re: Hauppauge WinTV-HVR2205 driver feedback To: Steven Toth References: <5610B12B.8090201@tresar-electronics.com.au> <5611D97B.9020101@tresar-electronics.com.au> Cc: Linux-Media From: Richard Tresidder Message-ID: <56128AA6.8010106@tresar-electronics.com.au> Date: Mon, 5 Oct 2015 22:35:18 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On 05/10/15 22:22, Steven Toth wrote: > On Sun, Oct 4, 2015 at 9:59 PM, Richard Tresidder > 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..