Mailing List Archive

cx18 module causes freeze after kernel upgrade
I'm having trouble getting drivers installed for my Hauppauge HVR-1600 in recent kernels. In Mythbuntu 12.04, I first tried upgrading to 3.4 kernel or 3.3 kernel. After installing each of these, I booted into the new kernel, then downloaded and built a fresh copy of media_build from the git server. On reboot, for both kernels, the system would hang. A bunch of trace information would scroll by and a hard reboot was required. (I'm not really sure how to retrieve that info). I thought the issue might have been related to using a newer kernel than the Ubuntu 12.04 repositories gave me.
So I upgraded to Ubuntu 12.10 (and kernel 3.5.0-21). Unfortunately, I'm having the same experience. If I install the media_build tree and try "sudo modprobe cx18", the system immediately hangs with no log output (that I know how to retrieve - I had tail -f /var/log/messages running in a separate terminal window) and again the system hangs during boot. The last good working kernel I have with v4l-dvb drivers is 3.2.0-32.
Any help would be greatly appreciated. Please let me know if there is any additional info I can provide (or if there is a different list I should be sending to).
Thanks,Kyle
Re: cx18 module causes freeze after kernel upgrade [ In reply to ]
On Fri, 2013-01-18 at 14:23 -0500, Kyle Lil wrote:
> I'm having trouble getting drivers installed for my Hauppauge HVR-1600
> in recent kernels. In Mythbuntu 12.04, I first tried upgrading to 3.4
> kernel or 3.3 kernel. After installing each of these, I booted into
> the new kernel, then downloaded and built a fresh copy of media_build
> from the git server.

Why? What is wrong with the cx18 module (and supporting modules) in the
stock 3.4 or 3.3 kernel?

FYI, the ^media_build^ is only a partial rebuild of the sources for the
latest ^media_tree^ kernel, with some backward compatability patches so
things at least compile. No guarantee that things are going to work.

If you rebuild and install the ^media_tree^ kernel and all the modules,
then you will have the bleeding edge V4L-DVB modules with a vanilla
kernel. You will not have any security or valued added patches from
Cannonical, but you will have the bleeding edge V4L-DVB modules with
their intended kernel and they shouldn't crash.

> On reboot, for both kernels, the system would hang. A bunch of trace
> information would scroll by and a hard reboot was required. (I'm not
> really sure how to retrieve that info).

Take a picture with a digital camera and email direct to me:
awalls@md.metrocast.net . If the "Code" bytes in the photo are not
readable, please transcribe them by hand (there are only 64 of them) and
send them as well.


> I thought the issue might have been related to using a newer kernel
> than the Ubuntu 12.04 repositories gave me.

Maybe. I don't know from where media_build is picking up the kernel
headers.

>
> So I upgraded to Ubuntu 12.10 (and kernel 3.5.0-21). Unfortunately,
> I'm having the same experience. If I install the media_build tree and
> try "sudo modprobe cx18", the system immediately hangs with no log
> output (that I know how to retrieve - I had tail -f /var/log/messages
> running in a separate terminal window) and again the system hangs
> during boot.

During your experimentation blacklist the cx18 driver
in /etc/modprobe.d/blacklist.conf . That way on reboot, you get to
decide when your machine hangs by typing modprobe cx18 manually.


> The last good working kernel I have with v4l-dvb drivers is 3.2.0-32.
>
>
> Any help would be greatly appreciated. Please let me know if there is
> any additional info I can provide (or if there is a different list I
> should be sending to).

Certainly, questions related to media_build should be directed to the
Linux media list: linux-media@vger.kernel.org . I don't use the
media_build backward-compatability build system, myself.

Regards,
Andy
>
> Thanks,
> Kyle




_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 module causes freeze after kernel upgrade [ In reply to ]
> From: awalls@md.metrocast.net
> To: ivtv-users@ivtvdriver.org
> Date: Sat, 19 Jan 2013 17:17:53 -0500
> CC: linux-media@vger.kernel.org
> Subject: Re: [ivtv-users] cx18 module causes freeze after kernel upgrade
>
> On Fri, 2013-01-18 at 14:23 -0500, Kyle Lil wrote:
> > I'm having trouble getting drivers installed for my Hauppauge HVR-1600
> > in recent kernels. In Mythbuntu 12.04, I first tried upgrading to 3.4
> > kernel or 3.3 kernel. After installing each of these, I booted into
> > the new kernel, then downloaded and built a fresh copy of media_build
> > from the git server.
>
> Why? What is wrong with the cx18 module (and supporting modules) in the
> stock 3.4 or 3.3 kernel?
For some reason, my HVR-1600 performs better with .qam_gain in cx18-dvb.c set to 0x01 instead of 0x02. See this thread (http://www.gossamer-threads.com/lists/ivtv/users/40784?do=post_view_flat#40784 thnaks to you and Devin Heitmueller for helping me troubleshoot that). Maybe things have improved with the driver and/or error handling in the mpeg players I'm using since then. I should really have given the stock kernel a try before attempting to patch it.
>
> FYI, the ^media_build^ is only a partial rebuild of the sources for the
> latest ^media_tree^ kernel, with some backward compatability patches so
> things at least compile. No guarantee that things are going to work.
>
> If you rebuild and install the ^media_tree^ kernel and all the modules,
> then you will have the bleeding edge V4L-DVB modules with a vanilla
> kernel. You will not have any security or valued added patches from
> Cannonical, but you will have the bleeding edge V4L-DVB modules with
> their intended kernel and they shouldn't crash.
>
Thanks for taking the time to explain this to me. For some reason, I assumed these modules would work with any kernel as long as they compiled. As luck would have it, a new Canonical kernel arrived today (3.5.0-22). I installed it and *did not* patch it. So far things look pretty good.

> > On reboot, for both kernels, the system would hang. A bunch of trace
> > information would scroll by and a hard reboot was required. (I'm not
> > really sure how to retrieve that info).
>
> Take a picture with a digital camera and email direct to me:
> awalls@md.metrocast.net . If the "Code" bytes in the photo are not
> readable, please transcribe them by hand (there are only 64 of them) and
> send them as well.
>>
> > I thought the issue might have been related to using a newer kernel
> > than the Ubuntu 12.04 repositories gave me.
>
> Maybe. I don't know from where media_build is picking up the kernel
> headers.
>
> >
> > So I upgraded to Ubuntu 12.10 (and kernel 3.5.0-21). Unfortunately,
> > I'm having the same experience. If I install the media_build tree and
> > try "sudo modprobe cx18", the system immediately hangs with no log
> > output (that I know how to retrieve - I had tail -f /var/log/messages
> > running in a separate terminal window) and again the system hangs
> > during boot.
>
> During your experimentation blacklist the cx18 driver
> in /etc/modprobe.d/blacklist.conf . That way on reboot, you get to
> decide when your machine hangs by typing modprobe cx18 manually.
>
>
> > The last good working kernel I have with v4l-dvb drivers is 3.2.0-32.
> >
> >
> > Any help would be greatly appreciated. Please let me know if there is
> > any additional info I can provide (or if there is a different list I
> > should be sending to).
>
> Certainly, questions related to media_build should be directed to the
> Linux media list: linux-media@vger.kernel.org . I don't use the
> media_build backward-compatability build system, myself.
>
> Regards,
> Andy
> >
Thanks again, Andy. I'll see how things look in the next few days and email the Linux media list if it looks like I still need that custom .qam_gain setting and I run into trouble installing the media tree kernel.
Best, Kyle
> > Thanks,
> > Kyle
>
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 module causes freeze after kernel upgrade [ In reply to ]
From: kpl388@msn.com
To: ivtv-users@ivtvdriver.org
Date: Sat, 19 Jan 2013 19:26:58 -0500
CC: linux-media@vger.kernel.org
Subject: Re: [ivtv-users] cx18 module causes freeze after kernel upgrade







> From: awalls@md.metrocast.net
> To: ivtv-users@ivtvdriver.org
> Date: Sat, 19 Jan 2013 17:17:53 -0500
> CC: linux-media@vger.kernel.org
> Subject: Re: [ivtv-users] cx18 module causes freeze after kernel upgrade
>
> On Fri, 2013-01-18 at 14:23 -0500, Kyle Lil wrote:
> > I'm having trouble getting drivers installed for my Hauppauge HVR-1600
> > in recent kernels. In Mythbuntu 12.04, I first tried upgrading to 3.4
> > kernel or 3.3 kernel. After installing each of these, I booted into
> > the new kernel, then downloaded and built a fresh copy of media_build
> > from the git server.
>
> Why? What is wrong with the cx18 module (and supporting modules) in the
> stock 3.4 or 3.3 kernel?
For some reason, my HVR-1600 performs better with .qam_gain in cx18-dvb.c set to 0x01 instead of 0x02. See this thread (http://www.gossamer-threads.com/lists/ivtv/users/40784?do=post_view_flat#40784 thnaks to you and Devin Heitmueller for helping me troubleshoot that). Maybe things have improved with the driver and/or error handling in the mpeg players I'm using since then. I should really have given the stock kernel a try before attempting to patch it.
>
> FYI, the ^media_build^ is only a partial rebuild of the sources for the
> latest ^media_tree^ kernel, with some backward compatability patches so
> things at least compile. No guarantee that things are going to work.
>
> If you rebuild and install the ^media_tree^ kernel and all the modules,
> then you will have the bleeding edge V4L-DVB modules with a vanilla
> kernel. You will not have any security or valued added patches from
> Cannonical, but you will have the bleeding edge V4L-DVB modules with
> their intended kernel and they shouldn't crash.
>
Thanks for taking the time to explain this to me. For some reason, I assumed these modules would work with any kernel as long as they compiled. As luck would have it, a new Canonical kernel arrived today (3.5.0-22). I installed it and *did not* patch it. So far things look pretty good.

> > On reboot, for both kernels, the system would hang. A bunch of trace
> > information would scroll by and a hard reboot was required. (I'm not
> > really sure how to retrieve that info).
>
> Take a picture with a digital camera and email direct to me:
> awalls@md.metrocast.net . If the "Code" bytes in the photo are not
> readable, please transcribe them by hand (there are only 64 of them) and
> send them as well.
>>
> > I thought the issue might have been related to using a newer kernel
> > than the Ubuntu 12.04 repositories gave me.
>
> Maybe. I don't know from where media_build is picking up the kernel
> headers.
>
> >
> > So I upgraded to Ubuntu 12.10 (and kernel 3.5.0-21). Unfortunately,
> > I'm having the same experience. If I install the media_build tree and
> > try "sudo modprobe cx18", the system immediately hangs with no log
> > output (that I know how to retrieve - I had tail -f /var/log/messages
> > running in a separate terminal window) and again the system hangs
> > during boot.
>
> During your experimentation blacklist the cx18 driver
> in /etc/modprobe.d/blacklist.conf . That way on reboot, you get to
> decide when your machine hangs by typing modprobe cx18 manually.
>
>
> > The last good working kernel I have with v4l-dvb drivers is 3.2.0-32.
> >
> >
> > Any help would be greatly appreciated. Please let me know if there is
> > any additional info I can provide (or if there is a different list I
> > should be sending to).
>
> Certainly, questions related to media_build should be directed to the
> Linux media list: linux-media@vger.kernel.org . I don't use the
> media_build backward-compatability build system, myself.
>
> Regards,
> Andy
> >
Thanks again, Andy. I'll see how things look in the next few days and email the Linux media list if it looks like I still need that custom .qam_gain setting and I run into trouble installing the media tree kernel.
Best, Kyle
> > Thanks,
> > Kyle
>
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users


So, unfortunately, I am getting a ton of errors as previously described in this thread (http://www.gossamer-threads.com/lists/ivtv/users/40784?do=post_view_flat#40784) with the stock kernel driver. Just to be sure I'm not overdoing things here, is there a way I can set the .qam_gain parameter without hard coding a new value in cx18-dvb.c and building a custom media-tree kernel?
Best, Kyle
Re: cx18 module causes freeze after kernel upgrade [ In reply to ]
On Fri, 2013-01-25 at 15:17 -0500, Kyle Lil wrote:


> So, unfortunately, I am getting a ton of errors as previously
> described in this thread
> (http://www.gossamer-threads.com/lists/ivtv/users/40784?do=post_view_flat#40784) with the stock kernel driver. Just to be sure I'm not overdoing things here, is there a way I can set the .qam_gain parameter without hard coding a new value in cx18-dvb.c and building a custom media-tree kernel?

You have at least two options (but first make a backup copy of your
stock cx18.ko module):

1. Download the Ubuntu source package for the exact Ubuntu kernel you
are running, make the needed edit in cx18-dvb.c, follow Ubuntu's
instructions for rebuilding the kernel package from souce, and use the
cx18.ko module from the newly built kernel source.

or

2. Edit the cx18.ko oject with a binary editor:

a. Make a backup!

$ su - root

# cd /lib/modules/.../kernel/drivers/media/.../cx18

# cp cx18.ko cx18.ko.stock

b. Figure out where .qam_gain is stored in the file

# objdump -h -j .data cx18.ko
cx18.ko: file format elf64-x86-64

Sections:
Idx Name Size VMA LMA File off Algn
16 .data 0000051c 0000000000000000 0000000000000000 0002a580 2**5
CONTENTS, ALLOC, LOAD, RELOC, DATA
File offset of initialized .data section ---------------------------^^^^^^^^

# objdump -t -j .data cx18.ko | grep hauppauge_hvr1600_tuner
00000000000003a0 l O .data 0000000000000020 hauppauge_hvr1600_tuner
Offset in .data ^^^
Length in .data ---------------------------------^^


c. Do some hexadecimal number math to convert everything to file offsets:

# echo "obase=16; ibase=16; 2A580 + 3A0" | bc
2A920

# echo "obase=16; ibase=16; 2A580 + 3A0 + 20" | bc
2A940


d. Display the data bytes in the structure using cx18.ko file offsets:

# objdump -s -j .data --start-address=0x2a920 --stop-address=0x2a940 --adjust-vma=0x2a580 cx18.ko

cx18.ko: file format elf64-x86-64

Contents of section .data:
2a920 63000000 a0175200 0024f400 01030101 c.....R..$......
2a930 01000000 c8000000 fc000000 01000200 ................
For me, .qam_gain is at offset 0x2a93e ---^^

e. Compare with source code in cx18-dvb.c:

# vim -R /blah/blah/blah/cx18-dvb.c
...
static struct mxl5005s_config hauppauge_hvr1600_tuner = {
.i2c_address = 0xC6 >> 1, /* 0x63 */
.if_freq = IF_FREQ_5380000HZ, /* 0x5217a0 */
.xtal_freq = CRYSTAL_FREQ_16000000HZ,/* 0xf42400 */
.agc_mode = MXL_SINGLE_AGC,
.tracking_filter = MXL_TF_C_H,
.rssi_enable = MXL_RSSI_ENABLE,
.cap_select = MXL_CAP_SEL_ENABLE,
.div_out = MXL_DIV_OUT_4,
.clock_out = MXL_CLOCK_OUT_DISABLE,
.output_load = MXL5005S_IF_OUTPUT_LOAD_200_OHM, /*0xc8*/
.top = MXL5005S_TOP_25P2, /* 0xfc */
.mod_mode = MXL_DIGITAL_MODE,
.if_mode = MXL_ZERO_IF,
.qam_gain = 0x02,
.AgcMasterByte = 0x00,
};
...

f. Patch the .qma_gain byte and inspect that the patch was correct:

# echo "2a93e: 01" | xxd -r - cx18.ko

# objdump -s -j .data --start-address=0x2a920 --stop-address=0x2a940 --adjust-vma=0x2a580 cx18.ko

cx18.ko: file format elf64-x86-64

Contents of section .data:
2a920 63000000 a0175200 0024f400 01030101 c.....R..$......
2a930 01000000 c8000000 fc000000 01000100 ................
Changed .qam_gain at offset 0x2a93e -----^^


The above is really a pain, but it takes less time then recompiling a
kernel. I'm sure you could write a Perl script to do all of the above,
if you think you will have to do this often.

Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 module causes freeze after kernel upgrade [ In reply to ]
> Subject: Re: [ivtv-users] cx18 module causes freeze after kernel upgrade
> From: awalls@md.metrocast.net
> To: ivtv-users@ivtvdriver.org
> CC: kpl388@msn.com
> Date: Sat, 26 Jan 2013 09:40:29 -0500
>
> On Fri, 2013-01-25 at 15:17 -0500, Kyle Lil wrote:
>
>
> > So, unfortunately, I am getting a ton of errors as previously
> > described in this thread
> > (http://www.gossamer-threads.com/lists/ivtv/users/40784?do=post_view_flat#40784) with the stock kernel driver. Just to be sure I'm not overdoing things here, is there a way I can set the .qam_gain parameter without hard coding a new value in cx18-dvb.c and building a custom media-tree kernel?
>
> You have at least two options (but first make a backup copy of your
> stock cx18.ko module):
>
> 1. Download the Ubuntu source package for the exact Ubuntu kernel you
> are running, make the needed edit in cx18-dvb.c, follow Ubuntu's
> instructions for rebuilding the kernel package from souce, and use the
> cx18.ko module from the newly built kernel source.
>
> or
>
> 2. Edit the cx18.ko oject with a binary editor:
>
> a. Make a backup!
>
> $ su - root
>
> # cd /lib/modules/.../kernel/drivers/media/.../cx18
>
> # cp cx18.ko cx18.ko.stock
>
> b. Figure out where .qam_gain is stored in the file
>
> # objdump -h -j .data cx18.ko
> cx18.ko: file format elf64-x86-64
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 16 .data 0000051c 0000000000000000 0000000000000000 0002a580 2**5
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> File offset of initialized .data section ---------------------------^^^^^^^^
>
> # objdump -t -j .data cx18.ko | grep hauppauge_hvr1600_tuner
> 00000000000003a0 l O .data 0000000000000020 hauppauge_hvr1600_tuner
> Offset in .data ^^^
> Length in .data ---------------------------------^^
>
>
> c. Do some hexadecimal number math to convert everything to file offsets:
>
> # echo "obase=16; ibase=16; 2A580 + 3A0" | bc
> 2A920
>
> # echo "obase=16; ibase=16; 2A580 + 3A0 + 20" | bc
> 2A940
>
>
> d. Display the data bytes in the structure using cx18.ko file offsets:
>
> # objdump -s -j .data --start-address=0x2a920 --stop-address=0x2a940 --adjust-vma=0x2a580 cx18.ko
>
> cx18.ko: file format elf64-x86-64
>
> Contents of section .data:
> 2a920 63000000 a0175200 0024f400 01030101 c.....R..$......
> 2a930 01000000 c8000000 fc000000 01000200 ................
> For me, .qam_gain is at offset 0x2a93e ---^^
>
> e. Compare with source code in cx18-dvb.c:
>
> # vim -R /blah/blah/blah/cx18-dvb.c
> ...
> static struct mxl5005s_config hauppauge_hvr1600_tuner = {
> .i2c_address = 0xC6 >> 1, /* 0x63 */
> .if_freq = IF_FREQ_5380000HZ, /* 0x5217a0 */
> .xtal_freq = CRYSTAL_FREQ_16000000HZ,/* 0xf42400 */
> .agc_mode = MXL_SINGLE_AGC,
> .tracking_filter = MXL_TF_C_H,
> .rssi_enable = MXL_RSSI_ENABLE,
> .cap_select = MXL_CAP_SEL_ENABLE,
> .div_out = MXL_DIV_OUT_4,
> .clock_out = MXL_CLOCK_OUT_DISABLE,
> .output_load = MXL5005S_IF_OUTPUT_LOAD_200_OHM, /*0xc8*/
> .top = MXL5005S_TOP_25P2, /* 0xfc */
> .mod_mode = MXL_DIGITAL_MODE,
> .if_mode = MXL_ZERO_IF,
> .qam_gain = 0x02,
> .AgcMasterByte = 0x00,
> };
> ...
>
> f. Patch the .qma_gain byte and inspect that the patch was correct:
>
> # echo "2a93e: 01" | xxd -r - cx18.ko
>
> # objdump -s -j .data --start-address=0x2a920 --stop-address=0x2a940 --adjust-vma=0x2a580 cx18.ko
>
> cx18.ko: file format elf64-x86-64
>
> Contents of section .data:
> 2a920 63000000 a0175200 0024f400 01030101 c.....R..$......
> 2a930 01000000 c8000000 fc000000 01000100 ................
> Changed .qam_gain at offset 0x2a93e -----^^
>
>
> The above is really a pain, but it takes less time then recompiling a
> kernel. I'm sure you could write a Perl script to do all of the above,
> if you think you will have to do this often.
>
> Regards,
> Andy
>

Thanks, Andy. It looked a little daunting, but I ended up going with option 2. Thanks to your instructions, everything actually went quite smoothly and I was able to get the binary modified in just a few minutes. Not sure if I'll have to do it often, but I guess every time I update the kernel? Maybe I'll avoid doing that when possible...
Thanks again for the help,
Kyle