Hauppauge WinTV-HVR2205 driver feedback

DISCUSSION Richard Tresidder 3 participants 14 messages Oct 4, 2015 – Oct 11, 2015 Media (V4L/DVB)

Share & tools

Richard Tresidder

author

2015-10-04 05:14 UTC #0 lore raw

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

Steven Toth

2015-10-04 14:03 UTC #1 lore raw

Quoted 3 lines

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?

Signature · 2 lines

Steven Toth - Kernel Labs
http://www.kernellabs.com

Richard Tresidder

author

2015-10-05 02:00 UTC #2 lore raw

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 0000:04:00.0, rev: 129, irq: 18, latency: 0, mmio: 0xf7800000
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 0312    05/26/2010
Oct  3 18:43:09 richos kernel: 000000000010c0d0 00000000a89d2ba5 ffff8801011d7810 ffffffff81604516
Oct  3 18:43:09 richos kernel: ffff8801011d78a0 ffffffff8115c5c0 0000000000000000 00000000ffffffff
Oct  3 18:43:09 richos kernel: ffff880117fd6000 ffffffff8115efa6 ffff8801011d7870 00000000a89d2ba5
Oct  3 18:43:09 richos kernel: Call Trace:
Oct  3 18:43:09 richos kernel: [<ffffffff81604516>] dump_stack+0x19/0x1b
Oct  3 18:43:09 richos kernel: [<ffffffff8115c5c0>] warn_alloc_failed+0x110/0x180
Oct  3 18:43:09 richos kernel: [<ffffffff8115efa6>] ? drain_local_pages+0x16/0x20
Oct  3 18:43:09 richos kernel: [<ffffffff81160d48>] __alloc_pages_nodemask+0x9a8/0xb90
Oct  3 18:43:09 richos kernel: [<ffffffff8119f3a9>] alloc_pages_current+0xa9/0x170
Oct  3 18:43:09 richos kernel: [<ffffffff8115b53e>] __get_free_pages+0xe/0x50
Oct  3 18:43:09 richos kernel: [<ffffffff811aa13e>] kmalloc_order_trace+0x2e/0xa0
Oct  3 18:43:09 richos kernel: [<ffffffffa082b3b1>] saa7164_downloadimage+0x9f/0x486 [saa7164]
Oct  3 18:43:09 richos kernel: [<ffffffffa0820212>] saa7164_downloadfirmware+0x882/0xbe0 [saa7164]
Oct  3 18:43:09 richos kernel: [<ffffffff8110d78c>] ? request_threaded_irq+0xcc/0x170
Oct  3 18:43:09 richos kernel: [<ffffffffa081d843>] saa7164_initdev+0x583/0xfd0 [saa7164]
Oct  3 18:43:09 richos kernel: [<ffffffff813087a5>] local_pci_probe+0x45/0xa0

*******************

Quoted 8 lines · Steven Toth

Quoted 3 lines
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?

Steven Toth

2015-10-05 14:22 UTC #3 lore raw

Quoted 3 lines · Richard Tresidder

Hi Steven
Nope standard x86_64
kernel 3.10.0-229.14.1.el7.x86_64

Hmm.

Quoted 5 lines

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.

Quoted 4 lines

There is mention of something similar against this card on www linuxtv org wiki index.php Hauppauge_WinTV-HVR-2200

Quoted 11 lines

********
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.

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.

Signature · 2 lines

Steven Toth - Kernel Labs
http://www.kernellabs.com

Richard Tresidder

author

2015-10-05 14:35 UTC #4 lore raw

Quoted 27 lines · Steven Toth

Quoted 3 lines · Richard Tresidder
Hi Steven
Nope standard x86_64
kernel 3.10.0-229.14.1.el7.x86_64
Hmm.
Quoted 4 lines
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.
Quoted 14 lines
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
********

Quoted 7 lines

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..

Quoted 8 lines

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..

Richard Tresidder

author

2015-10-05 14:39 UTC #5 lore raw

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

Quoted 55 lines · Richard Tresidder

Quoted 27 lines · Steven Toth
Quoted 3 lines · Richard Tresidder
Hi Steven
Nope standard x86_64
kernel 3.10.0-229.14.1.el7.x86_64
Hmm.
Quoted 4 lines
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.
Quoted 14 lines
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
********
Quoted 7 lines
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..
Quoted 8 lines
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..

Steven Toth

2015-10-05 14:43 UTC #6 lore raw

In reply to Richard Tresidder

Quoted 8 lines

Quoted 3 lines
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.

Quoted 4 lines

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.

Quoted 10 lines

Quoted 9 lines
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.

Quoted 5 lines

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.

Signature · 2 lines

Steven Toth - Kernel Labs
http://www.kernellabs.com

Richard Tresidder

author

2015-10-05 15:26 UTC #7 lore raw

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.c 2015-10-05 23:21:54.236082009 +0800 renamed from saa7164-fw.c 2015-10-05 23:05:31.279329924 +0800 +3 ~~-11~~

@@ -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;
 }
 *********************************************************************

Quoted 33 lines · Steven Toth

Quoted 7 lines
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
Quoted 8 lines
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.
Quoted 5 lines
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.

Steven Toth

2015-10-05 15:32 UTC #8 lore raw

Quoted 10 lines · Richard Tresidder

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..

Good, that's the patch I had in mind. Thanks.

Yes, you'd need to issue a complete PCIe reset (warm or cold boot) for the risc processor to reset, and for it to require a firmware to be loaded again. So, your comments make sense.

Signature · 2 lines

Steven Toth - Kernel Labs
http://www.kernellabs.com

Tycho Lürsen

2015-10-05 12:45 UTC #9 lore raw

In reply to Richard Tresidder

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:

Quoted 32 lines

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
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Richard Tresidder

author

2015-10-05 14:22 UTC #10 lore raw

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

Quoted 40 lines · Tycho Lürsen

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:
Quoted 32 lines
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
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Richard Tresidder

author

2015-10-05 16:03 UTC #11 lore raw

In reply to Tycho Lürsen

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

Quoted 40 lines · Tycho Lürsen

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:
Quoted 32 lines
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
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Richard Tresidder

author

2015-10-11 06:18 UTC #12 lore raw

In reply to Tycho Lürsen

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.. aaarrrrggghhhhh... 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

Quoted 40 lines · Tycho Lürsen

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:
Quoted 32 lines
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
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Tycho Lürsen

2015-10-11 07:33 UTC #13 lore raw

Op 11-10-15 om 08:18 schreef Richard Tresidder:

Quoted 9 lines

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!!

Bottoms up!

Quoted 7 lines

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.. aaarrrrggghhhhh... 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..

It's not that hard once you get the hang of it. I had to recompile anyway, as I need saa716x, dvbloopback and backported drivers for DVBSky T982, plus I need more then 8 dvb adapters. Semi-automated this of course:
https://github.com/bas-t/centos7-kernel

Quoted 8 lines

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.

Excellent idea. But as stated, I'll have to recompile anyway...

Quoted 56 lines

Regards
Richard Tresidder
Quoted 50 lines · Tycho Lürsen
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:
Quoted 42 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html