Bug #1184


cxm WinTV PVR-250/350 driver

Added by vince.dragonfly about 13 years ago. Updated over 12 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Hey Sascha.

We finally booted our TV server on HEAD with that cxm driver patch.
Tried loading the cxm modules. Here are the errors.

  1. kldload cxm
    link_elf: symbol iicbus_start undefined
    kldload: can't load cxm: Exec format error
  1. kldload cxm_iic
    link_elf: symbol iicbb_callback_desc undefined
    kldload: can't load cxm_iic.ko: Exec format error

At least the system didn't crash :-).
This machine has two TV cards.

Actions #1

Updated by swildner about 13 years ago

Yeh, you need iicbus support in the kernel. Try adding 'device iicbus'.
Not sure if more is needed (refer to LINT and the iicbus(4) manual page).


Actions #2

Updated by vince.dragonfly about 13 years ago

Ok. I added

device smbus
device iicbus
device iicbb

to the GENERIC config file. No more unresolved symbols. I can load the cxm
module and it sees the two tv cards but I do not seem to be able to read the
device. The error messages say it cannot attach cxm_iic. cxm_iic seems to be
in the kernel from the output of "kldstat -v".

Looking at the sources, it appeared that the major device number is 92. I was
unsure of the minor. I assumed 0 and did a mknod. I hope this is right.

  1. ll /dev/cxm0
    crw-r--r-- 1 root wheel - 92, 0x00000000 Dec 19 04:15 /dev/cxm0
  1. cat /dev/cxm0
    cat: /dev/cxm0: Device not configured

Here are the system messages.

Dec 19 04:12:15 New-Install kernel: cxm0: <Conexant iTVC16 MPEG Coder> mem 0xd4000000-0xd7ffffff irq 11 at device 8.0 on pci0
Dec 19 04:12:15 New-Install kernel: cxm0: could not attach cxm_iic
Dec 19 04:12:15 New-Install kernel: device_probe_and_attach: cxm0 attach returned 6
Dec 19 04:12:15 New-Install kernel: cxm1: <Conexant iTVC16 MPEG Coder> mem 0xd8000000-0xdbffffff irq 10 at device 9.0 on pci0
Dec 19 04:12:15 New-Install kernel: cxm1: could not attach cxm_iic
Dec 19 04:12:15 New-Install kernel: device_probe_and_attach: cxm1 attach returned 6
Actions #3

Updated by vince.dragonfly about 13 years ago

Hi Sascha.

As you know, I recompiled with the cxm driver built in and it crashed.

You asked about the lines preceding the
"cmx0: could not initialize video decoder"
line. I copied down a bunch more of the messages and combined them here
with the original ones I gave you. There could be typos, but I hope
I got it all correct.

Messages prior to the debugger prompt:

pci1: <NVidia Ultra Vanta TNT2 graphics accelerator> at 0.0 irq 11
cxm0: <Conexant iTVc16 MPEG Coder> mem 0xd4000000-0xd7ffffff irq 11 at device 8.0 on pci0
cxm_iic0: <Conexant iTVc15 / iTVc16 I2C controller> on cxm0
iicbb0: <I2C bit-banging driver> on cxm_iic0
iicbus0: <Philips I2C bus> on iicbb0 master-only
cxm0:LG Innotek TAPE-H001F tuner
cmx0: could not initialize video decoder
iicbus0: detached
Fatal trap 12: page fault while in kernel mode
Fault virtual address = 0xdeadc0f6
fault code = supervisor read, page not present
... more stuff ...
processor flags = interrupt enabled, resume, IOPL=0
current process = 0 (swapper)
current thread = pri 12
... Then a bunch of register and address info...
Stopped at device_delete_child+0xa: movl 0x18(%ebx)%eax

Hmm.. Could the on board NVidia being at the same irq as the MPEG Coder
be a problem?

I ran "trace" as you suggested. There was a lot of output. Here are the last
couple lines, which I am guessing is the last thing it did before the panic.

mi_startup(91b000,c033ec71,c07562c4,c091e674,c091e65c) at mi_startup+0x99
begin() at begin+0x42

I could not get a crash dump. It reported there was no crash dump when
rebooting on the other kernel. I had set dumpdev in /etc/rc.conf. I am
guessing it is because it never got far enough to to run any of the init
scripts which define the crash device. Since it had already panic'd it did not
seem to make a difference running "panic" from the DB prompt. It just gave me
the same register/address information dump that had already been printed.

Well, that's all I have for now.

Actions #4

Updated by corecode about 13 years ago

Vincent Stemen wrote:

The first line(s) are the most important. This is a stack backtrace, with
the upmost frame first.

Yes, you'll have to set it from loader.conf.


Actions #5

Updated by vince.dragonfly about 13 years ago

Thanks Simon.

I set the dump device to the swap partition in /boot/loader.conf but still did
not get a crash dump. After rebooting, on the other kernel, the startup
messages still said there was no core file (or something like that). The swap
partition is about twice the size of the amount of RAM, so that should not be
a problem.

However, I typed in the first 7 lines this time from the trace command in
the debugger. It's tedious typing those in manually, so hopefully this is
enough to be useful. I went back to where it did the cxm_attach(). Let me
know if more is needed.

device_delete_child(c1544788,deadc0de,c14e15e8,c08bfa7c,c02d2c69) at device_delete_child+0xa
device_delete_child(c1544738,c1544788,c1544738,c1544738,c08bfa9c) at device_delete_child+0x1d
iicbb_detach(c1544738,c9b52e78,c06c6180,c1544738,c9d864c8) at iicbb_detach+0x34
device_detach(c1544738,c1544788,c15446e8,c08bfac4,c033e0cc) at device_detach+0x6a
device_delete_child(c15446e8,c1544738,32,c08bfb14,c044fe80) at device_delete_child+0x30
device_delete_child(c1544328,c15446e8,0,0,ffffffff) at device_delete_child+0x1d
cxm_attach(c1544328,c9b47174,c06c6170,c1544328,c1544328) at cxm_attach+0x8b6
Actions #6

Updated by swildner over 12 years ago

Fixed in 1792c605f0db62548a16a94103e6cba81513e1be


Also available in: Atom PDF