Re: Hauppauge WinTV-HVR2205 driver feedback
Hi Again Yep that fixed pulling in the saa7164: si2168 frontends: [ 6778.591548] i2c i2c-15: Added multiplexed i2c bus 16 [ 6778.591556] si2168 15-0064: Silicon Labs Si2168 successfully attached [ 6778.596252] si2157 13-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 6778.597229] DVB: registering new adapter (saa7164) YAY!! What a painful process... first time I built the kernel from the rpm source I must have stuffed something up and the resultant installed rpm didn't have the module turned on.. aaagggh... Trying to rebuild the srpm again after tweaking the .config file and copying it around to the various locations again just didn't work.. Eventually gave up and had to rip it all out and start afresh.. Well spotted on that one.. What a pain that the call to the i2c mux create didn't result in a error :/ Now I just need to shutoff kernel updates.. Really need to push this up into the centos config.. I've noted that it has been turned back on in other releases.. Will submit a bug. Regards Richard Tresidder On 05/10/15 20:45, Tycho Lürsen wrote: Hi, not sure if this is related. I had to recompile the centos7 stock kernel with: CONFIG_I2C_MUX=m It was not enabled in the kernel config. Op 04-10-15 om 06:55 schreef Richard Tresidder: Sorry If I've posted this to the wrong section my first attempt.. Hi I'm attempting to get an HVR2205 up and going. CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 [card=13,autodetected] Distribution is CentOS7 so I've pulled the v4l from media_build.git Had to change a couple of things.. and another macro issue regarding clamp() .. Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was failing.. kept getting: kernel: modprobe: page allocation failure: order:10, mode:0x10c0d0 Have plenty of RAM free so surprised about that one.. tried some of the tricks re increasing the vm.min_free_kbytes etc.. Any way I modified the routine to only allocate a single chunk buffer based on dstsize and tweaked the chunk handling code.. seemed to fix that one.. fw downloaded and seemed to boot ok.. Next I'm running into a problem with the saa7164_dvb_register() stage... saa7164[1]: Hauppauge eeprom: model=151609 saa7164_dvb_register() Frontend/I2C initialization failed saa7164_initdev() Failed to register dvb adapters on porta I added some extra debug and identified that client_demod->dev.driver is null.. However I'm now stuck as to what to tackle next.. I can provide more info, just didn't want to spam the list for my first email.. Regards Richard Tresidder -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
On 05/10/15 22:22, Steven Toth wrote: On Sun, Oct 4, 2015 at 9:59 PM, Richard Tresidder <rtres...@tresar-electronics.com.au> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
Hmm indeed... I see that the 2168 wants a mux i2c adapter.. and yep my /boot/config-3.10.0-229.14.1.el7.x86_64/ is indeed showing that CONFIG_I2C_MUX is commented out.. sigh.. Rebuilding the kernel with that setting on... Why this is disabled rather than just a module is beyond me.. Curious that an error doesn't pop up about that.. Is there a debug level that can be turned on that would show that up? Well spotted Tycho Will let you know how things go Regards Richard Tresidder On 05/10/15 20:45, Tycho Lürsen wrote: Hi, not sure if this is related. I had to recompile the centos7 stock kernel with: CONFIG_I2C_MUX=m It was not enabled in the kernel config. Op 04-10-15 om 06:55 schreef Richard Tresidder: Sorry If I've posted this to the wrong section my first attempt.. Hi I'm attempting to get an HVR2205 up and going. CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 [card=13,autodetected] Distribution is CentOS7 so I've pulled the v4l from media_build.git Had to change a couple of things.. and another macro issue regarding clamp() .. Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was failing.. kept getting: kernel: modprobe: page allocation failure: order:10, mode:0x10c0d0 Have plenty of RAM free so surprised about that one.. tried some of the tricks re increasing the vm.min_free_kbytes etc.. Any way I modified the routine to only allocate a single chunk buffer based on dstsize and tweaked the chunk handling code.. seemed to fix that one.. fw downloaded and seemed to boot ok.. Next I'm running into a problem with the saa7164_dvb_register() stage... saa7164[1]: Hauppauge eeprom: model=151609 saa7164_dvb_register() Frontend/I2C initialization failed saa7164_initdev() Failed to register dvb adapters on porta I added some extra debug and identified that client_demod->dev.driver is null.. However I'm now stuck as to what to tackle next.. I can provide more info, just didn't want to spam the list for my first email.. Regards Richard Tresidder -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
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 <rtres...@tresar-electronics.com.au> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
stage 1..
Yep it works with accessing src directly.. had to reboot to verify that one.
Well at least the download says it worked and the image booted successfully.
excuse my manual diff method..
git and I don't agree... not sure how to get it to diff the media_build
repo I pulled the code from..
my brain is stuck in subversion mode..
Still rebuilding the kernel to check the i2c Mux issue..
Regards
Richard
saa7164-fw.c.patch
**
--- saa7164-fw.c2015-10-05 23:05:31.279329924 +0800
+++ saa7164-fw.c2015-10-05 23:21:54.236082009 +0800
@@ -75,7 +75,6 @@ static int saa7164_downloadimage(struct
u32 dlflags, u8 __iomem *dst, u32 dstsize)
{
u32 reg, timeout, offset;
-u8 *srcbuf = NULL;
int ret;
u32 dlflag = dlflags;
@@ -93,17 +92,10 @@ static int saa7164_downloadimage(struct
goto out;
}
-srcbuf = kzalloc(4 * 1048576, GFP_KERNEL);
-if (NULL == srcbuf) {
-ret = -ENOMEM;
-goto out;
-}
-
if (srcsize > (4*1048576)) {
ret = -ENOMEM;
goto out;
}
-memcpy(srcbuf, src, srcsize);
dprintk(DBGLVL_FW, "%s() dlflag = 0x%x\n", __func__, dlflag);
dprintk(DBGLVL_FW, "%s() dlflag_ack = 0x%x\n", __func__, dlflag_ack);
@@ -134,8 +126,9 @@ static int saa7164_downloadimage(struct
for (offset = 0; srcsize > dstsize;
srcsize -= dstsize, offset += dstsize) {
+
dprintk(DBGLVL_FW, "%s() memcpy %d\n", __func__, dstsize);
-memcpy_toio(dst, srcbuf + offset, dstsize);
+memcpy_toio(dst, src+offset, dstsize);
/* Flag the data as ready */
saa7164_writel(drflag, 1);
@@ -153,7 +146,7 @@ static int saa7164_downloadimage(struct
dprintk(DBGLVL_FW, "%s() memcpy(l) %d\n", __func__, dstsize);
/* Write last block to the device */
-memcpy_toio(dst, srcbuf+offset, srcsize);
+memcpy_toio(dst, src+offset, srcsize);
/* Flag the data as ready */
saa7164_writel(drflag, 1);
@@ -192,7 +185,6 @@ static int saa7164_downloadimage(struct
ret = 0;
out:
-kfree(srcbuf);
return ret;
}
*
On 05/10/15 22:43, Steven Toth wrote:
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 agree.
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..
Let us know how that goes.
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..
At this stage the code is 7-8 years old, so I don't recall the
rationale for why I did that back in 2008(?) - but looking at it
today, I think its needless and its a fairly trivial thing to
remove and test.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
Sigh again Did a module only build for the i2c-mux and got it into the currently running kernel with a force to bypass the no symbol version for module_layout error.. figured it was safe enough given it was the identical kernel config etc from the centos vault... Anyway still failed.. though the module seemed to install and is showing with lsmod no dmesg barfs.. I'll try a full kernel build tomorrow.. Regards Richard Tresidder On 05/10/15 20:45, Tycho Lürsen wrote: Hi, not sure if this is related. I had to recompile the centos7 stock kernel with: CONFIG_I2C_MUX=m It was not enabled in the kernel config. Op 04-10-15 om 06:55 schreef Richard Tresidder: Sorry If I've posted this to the wrong section my first attempt.. Hi I'm attempting to get an HVR2205 up and going. CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 [card=13,autodetected] Distribution is CentOS7 so I've pulled the v4l from media_build.git Had to change a couple of things.. and another macro issue regarding clamp() .. Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was failing.. kept getting: kernel: modprobe: page allocation failure: order:10, mode:0x10c0d0 Have plenty of RAM free so surprised about that one.. tried some of the tricks re increasing the vm.min_free_kbytes etc.. Any way I modified the routine to only allocate a single chunk buffer based on dstsize and tweaked the chunk handling code.. seemed to fix that one.. fw downloaded and seemed to boot ok.. Next I'm running into a problem with the saa7164_dvb_register() stage... saa7164[1]: Hauppauge eeprom: model=151609 saa7164_dvb_register() Frontend/I2C initialization failed saa7164_initdev() Failed to register dvb adapters on porta I added some extra debug and identified that client_demod->dev.driver is null.. However I'm now stuck as to what to tackle next.. I can provide more info, just didn't want to spam the list for my first email.. Regards Richard Tresidder -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
Hi Steven Nope standard x86_64 kernel 3.10.0-229.14.1.el7.x86_64 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.. 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 log snippet and trace from my system before the path I made... *** Oct 3 18:43:09 richos kernel: CORE saa7164[0]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 [card=13,autodetected] Oct 3 18:43:09 richos kernel: saa7164[0]/0: found at :04:00.0, rev: 129, irq: 18, latency: 0, mmio: 0xf780 Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() no first image Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() Waiting for firmware upload (NXP7164-2010-03-10.1.fw) Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() firmware read 4019072 bytes. Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() firmware loaded. Oct 3 18:43:09 richos kernel: Firmware file header part 1: Oct 3 18:43:09 richos kernel: .FirmwareSize = 0x0 Oct 3 18:43:09 richos kernel: .BSLSize = 0x0 Oct 3 18:43:09 richos kernel: .Reserved = 0x3d538 Oct 3 18:43:09 richos kernel: .Version = 0x3 Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() SecBootLoader.FileSize = 4019072 Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() FirmwareSize = 0x1fd6 Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() BSLSize = 0x0 Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() Reserved = 0x0 Oct 3 18:43:09 richos kernel: saa7164_downloadfirmware() Version = 0x1661c00 Oct 3 18:43:09 richos kernel: modprobe: page allocation failure: order:10, mode:0x10c0d0 Oct 3 18:43:09 richos kernel: CPU: 1 PID: 23702 Comm: modprobe Tainted: GF O-- 3.10.0-229.14.1.el7.x86_64 #1 Oct 3 18:43:09 richos kernel: Hardware name: System manufacturer System Product Name/P7H55-M/USB3, BIOS 031205/26/2010 Oct 3 18:43:09 richos kernel: 0010c0d0 a89d2ba5 8801011d7810 81604516 Oct 3 18:43:09 richos kernel: 8801011d78a0 8115c5c0 Oct 3 18:43:09 richos kernel: 880117fd6000 8115efa6 8801011d7870 a89d2ba5 Oct 3 18:43:09 richos kernel: Call Trace: Oct 3 18:43:09 richos kernel: [] dump_stack+0x19/0x1b Oct 3 18:43:09 richos kernel: [] warn_alloc_failed+0x110/0x180 Oct 3 18:43:09 richos kernel: [] ? drain_local_pages+0x16/0x20 Oct 3 18:43:09 richos kernel: [] __alloc_pages_nodemask+0x9a8/0xb90 Oct 3 18:43:09 richos kernel: [] alloc_pages_current+0xa9/0x170 Oct 3 18:43:09 richos kernel: [] __get_free_pages+0xe/0x50 Oct 3 18:43:09 richos kernel: [] kmalloc_order_trace+0x2e/0xa0 Oct 3 18:43:09 richos kernel: [] saa7164_downloadimage+0x9f/0x486 [saa7164] Oct 3 18:43:09 richos kernel: [] saa7164_downloadfirmware+0x882/0xbe0 [saa7164] Oct 3 18:43:09 richos kernel: [] ? request_threaded_irq+0xcc/0x170 Oct 3 18:43:09 richos kernel: [] saa7164_initdev+0x583/0xfd0 [saa7164] Oct 3 18:43:09 richos kernel: [] local_pci_probe+0x45/0xa0 *** On 4/10/2015 10:03 PM, Steven Toth wrote: Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was failing.. kept getting: kernel: modprobe: page allocation failure: order:10, mode:0x10c0d0 I don't think I've ever seen or heard of that in the entire history of the driver. Are you running on traditional x86/x86 hardware, or something embedded/custom? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
Sorry If I've posted this to the wrong section my first attempt.. Hi I'm attempting to get an HVR2205 up and going. CORE saa7164[1]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 [card=13,autodetected] Distribution is CentOS7 so I've pulled the v4l from media_build.git Had to change a couple of things.. and another macro issue regarding clamp() .. Seems the kzalloc(4 * 1048576, GFP_KERNEL) in saa7164-fw.c was failing.. kept getting: kernel: modprobe: page allocation failure: order:10, mode:0x10c0d0 Have plenty of RAM free so surprised about that one.. tried some of the tricks re increasing the vm.min_free_kbytes etc.. Any way I modified the routine to only allocate a single chunk buffer based on dstsize and tweaked the chunk handling code.. seemed to fix that one.. fw downloaded and seemed to boot ok.. Next I'm running into a problem with the saa7164_dvb_register() stage... saa7164[1]: Hauppauge eeprom: model=151609 saa7164_dvb_register() Frontend/I2C initialization failed saa7164_initdev() Failed to register dvb adapters on porta I added some extra debug and identified that client_demod->dev.driver is null.. However I'm now stuck as to what to tackle next.. I can provide more info, just didn't want to spam the list for my first email.. Regards Richard Tresidder -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
