Re: [linux-dvb] modprobe mantis stalls/hangs/freezes (Twinhan VP-1034 and ivtv)
Manu Abraham schreef: Michel Verbraak wrote: I have a Twinhan VP-1034 and I use the the latest hg, today, and http://jusst.de/manu/mantis-v4l-dvb.tar.bz2 with kernel 2.6.22.1. When I do a 'modprobe mantis' my prompt never returns. The machine still is working. [snip] Address=[0x25] W[ 00 3mantis_ack_wait (0): Waiting for Slave RACK Aug 25 17:53:33 recorder kernel: mantis_ack_wait (0): Waiting for Slave RACK Aug 25 17:53:42 recorder last message repeated 499 times Aug 25 17:53:42 recorder kernel: mantis_ack_wait (0): Slave RACK Fail ! Aug 25 17:53:42 recorder kernel: mantis_i2c_write (0): ACK failedW I must say I also have a Hauppauge PVR-150 and a PVR-350 in this machine, using ivtv from hg, and when I remove both I do not have this problem. The modules load without any problems. with ivtv modules loaded somebody else mentioned of issues with regards to DMA transfers on the 878 based cards. I don't really understand why ivtv modules causes those problems. (IIRC it was Sigmund, i think) lspci -vv gives: 02:09.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: Twinhan Technology Co. Ltd Unknown device 0014 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2000ns min, 63750ns max) Interrupt: pin A routed to IRQ 22 Region 0: Memory at f7eff000 (32-bit, prefetchable) [size=4K] 02:0b.0 Multimedia video controller: Internext Compression Inc iTVC15 MPEG-2 Encoder (rev 01) Subsystem: Hauppauge computer works Inc. WinTV PVR-350 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (32000ns min, 2000ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at f000 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:0d.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) Subsystem: Hauppauge computer works Inc. WinTV PVR 150 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (32000ns min, 2000ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 5 Region 0: Memory at ec00 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- If more verbose messages are needed from othe modules please let me know. I do not have this problem with kernel versions 2.6.20 and below. Something changed in 2.6.21 and I do not know what. Without any any driver loaded for the ivtv hardware, do you still experience the same problems ? When I do not load the ivtv modules or any other modules needed bu ivtv, but the cards are still in the computer, and I load the mantis and mb86a16 module following is in the message log: Aug 26 09:47:30 recorder kernel: ACPI: PCI Interrupt :02:09.0[A] - GSI 21 (level, low) - IRQ 22 Aug 26 09:47:30 recorder kernel: Aug 26 09:47:30 recorder kernel: gpif status: 6000 irqcfg: Aug 26 09:47:30 recorder kernel: mantis_set_direction (0): TS direction setup Aug 26 09:47:30 recorder kernel: irq: 22, latency: 64 Aug 26 09:47:30 recorder kernel: memory: 0xf7eff000, mmio: 0xf88de000 Aug 26 09:47:30 recorder kernel: found a VP-1034 PCI DVB-S/DSS device on (02:09.0), Aug 26 09:47:30 recorder kernel: Mantis Rev 1 [1822:0014], irq: 22, latency: 64 Aug 26 09:47:30 recorder kernel: memory: 0xf7eff000, mmio: 0xf88de000 Aug 26 09:47:30 recorder kernel: mantis_i2c_init (0): Initializing I2C .. Aug 26 09:47:30 recorder kernel: mantis_i2c_init (0): [0x0401/] Aug 26 09:47:30 recorder kernel: mantis_i2c_write: Address=[0x50] W[ 08 === Interrupts[401/0001]= [* I2C R-ACK ** I2C DONE *] === Aug 26 09:47:30 recorder kernel: ] Aug 26 09:47:30 recorder kernel: mantis_i2c_read: Address=[0x50] R[ === Interrupts[401/0001]= [* I2C R-ACK ** I2C DONE *] === Aug 26 09:47:30 recorder kernel: 00 === Interrupts[401/0001]= [* I2C R-ACK ** I2C DONE *] === Aug 26 09:47:30 recorder kernel: 08 === Interrupts[401/0001]= [* I2C R-ACK ** I2C DONE *] === Aug 26 09:47:30 recorder kernel: ca === Interrupts[401/0001]= [* I2C R-ACK ** I2C
Re: [linux-dvb] modprobe mantis stalls/hangs/freezes (Twinhan VP-1034 and ivtv)
Michel Verbraak wrote: Aug 26 11:08:32 recorder kernel: ivtv0 i2c: i2c client attach Aug 26 11:08:32 recorder kernel: mantis_i2c_write: Address=[0x25] W[ ] Aug 26 11:08:32 recorder kernel: mantis_i2c_write: Address=[0x25] W[ 00 00 ] Aug 26 11:08:32 recorder kernel: mantis_i2c_write: Address=[0x25] W[ 00 ] Aug 26 11:08:32 recorder kernel: mantis_i2c_read: Address=[0x25] R[ 00 ] Aug 26 11:08:32 recorder kernel: mantis_i2c_write: Address=[0x25] W[ 00 01 === Interrupts[0001/0001]= [* I2C DONE *] === Aug 26 11:08:32 recorder kernel: ] Aug 26 11:08:32 recorder kernel: mantis_i2c_write: Address=[0x25] W[ 00 3mantis_ack_wait (0): Waiting for Slave RACK Aug 26 11:08:32 recorder kernel: === Interrupts[0001/0001]= [* I2C DONE *] === Aug 26 11:08:32 recorder kernel: mantis_ack_wait (0): Waiting for Slave RACK Aug 26 11:08:38 recorder last message repeated 499 times Aug 26 11:08:38 recorder kernel: mantis_ack_wait (0): Slave RACK Fail ! Aug 26 11:08:38 recorder kernel: mantis_i2c_write (0): ACK failedW This means the Mantis happily transferred the message (I2CDONE) to the MB86A16 and waited for the MB86A16 to ACK. The MB86A16 did not ACK. (Slave RACK failed) Something that i have seen while working on the MB86A16 and the STV0299 based devices, If someone writes junk to the MB86A16, it will just freeze, similar to the STV0299. I guess most demodulators behave the same. The STB0899 also exhibits similar properties. The vp-1034 is unusable, scan does not work. IVTV is unusable. Is the ivtv hardware sharing interrupts with the Mantis ? My guess would be that the ivtv drivers grab a lot of IRQ time on the CPU leaving little shared IRQ time for other devices. Can you verify this ? I CCed the ivtv-devel list because it is something between the mantis and ivtv driver. When I first load the ivtv modules and then the mantis ivtv is still working and mantis is not working. Possibly looks like some bug with I2C probes ? Don't know for sure. Cc added to Hans, since the list might be subscriber only. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] modprobe mantis stalls/hangs/freezes (Twinhan VP-1034 and ivtv)
On Sunday 26 August 2007 11:18:56 Michel Verbraak wrote:
Manu Abraham schreef:
Michel Verbraak wrote:
I have a Twinhan VP-1034 and I use the the latest hg, today, and
http://jusst.de/manu/mantis-v4l-dvb.tar.bz2 with kernel 2.6.22.1.
When I do a 'modprobe mantis' my prompt never returns. The machine
still is working.
Aug 26 11:08:32 recorder kernel: ivtv0: Autodetected Hauppauge WinTV
PVR-350 Aug 26 11:08:32 recorder kernel: tuner 2-0061: chip found @
0xc2 (ivtv i2c driver #0)
Aug 26 11:08:32 recorder kernel: ivtv0 i2c: i2c client attach
Aug 26 11:08:32 recorder kernel: mantis_i2c_write:
Address=[0x25] W[ ]
Aug 26 11:08:32 recorder kernel: mantis_i2c_write:
Address=[0x25] W[ 00 00 ]
Aug 26 11:08:32 recorder kernel: mantis_i2c_write:
Address=[0x25] W[ 00 ]
Aug 26 11:08:32 recorder kernel: mantis_i2c_read:
Address=[0x25] R[ 00 ]
Aug 26 11:08:32 recorder kernel: mantis_i2c_write:
Address=[0x25] W[ 00 01 === Interrupts[0001/0001]= [* I2C DONE *]
Ah, ivtv is probing for the saa7115 device. The saa7115 driver probes
among others i2c address 0x25, which is also used by the mantis.
And what's changed is that in kernel 2.6.21 the following change was
made to the saa7115.c driver:
static int saa711x_probe(struct i2c_adapter *adapter)
{
if (adapter-class I2C_CLASS_TV_ANALOG || adapter-class
I2C_CLASS_TV_DIGITAL)
return i2c_probe(adapter, addr_data, saa711x_attach);
return 0;
}
The TV_DIGITAL check was added, so now it is also suddenly used by the
mantis. Apparently added to support the Nexus CA.
The only solution at this time is to add the following module option to
saa7115: ignore=-1,0x25
This should ensure it that it ignores i2c address 0x25. Work is being
done to make probing unnecessary or at least much smarter, but that
will be quite a long transition period, most likely. For the time being
this is probably your only solution.
Regards,
Hans
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] modprobe mantis stalls/hangs/freezes (Twinhan VP-1034 and ivtv)
I have a Twinhan VP-1034 and I use the the latest hg, today, and http://jusst.de/manu/mantis-v4l-dvb.tar.bz2 with kernel 2.6.22.1. When I do a 'modprobe mantis' my prompt never returns. The machine still is working. Following is in my log with option verbose=255 for mantis module: Aug 25 17:53:32 recorder kernel: ACPI: PCI Interrupt :02:09.0[A] - GSI 21 (level, low) - IRQ 22 Aug 25 17:53:32 recorder kernel: Aug 25 17:53:32 recorder kernel: gpif status: 6000 irqcfg: Aug 25 17:53:32 recorder kernel: mantis_set_direction (0): TS direction setup Aug 25 17:53:32 recorder kernel: irq: 22, latency: 64 Aug 25 17:53:32 recorder kernel: memory: 0xf7eff000, mmio: 0xf88fe000 Aug 25 17:53:32 recorder kernel: found a VP-1034 PCI DVB-S/DSS device on (02:09.0), Aug 25 17:53:32 recorder kernel: Mantis Rev 1 [1822:0014], irq: 22, latency: 64 Aug 25 17:53:32 recorder kernel: memory: 0xf7eff000, mmio: 0xf88fe000 Aug 25 17:53:32 recorder kernel: mantis_i2c_write: Address=[0x25] W[ ] Aug 25 17:53:33 recorder kernel: mantis_i2c_write: Address=[0x25] W[ 00 3mantis_ack_wait (0): Waiting for Slave RACK Aug 25 17:53:33 recorder kernel: mantis_ack_wait (0): Waiting for Slave RACK Aug 25 17:53:42 recorder last message repeated 499 times Aug 25 17:53:42 recorder kernel: mantis_ack_wait (0): Slave RACK Fail ! Aug 25 17:53:42 recorder kernel: mantis_i2c_write (0): ACK failedW I must say I also have a Hauppauge PVR-150 and a PVR-350 in this machine, using ivtv from hg, and when I remove both I do not have this problem. The modules load without any problems. If more verbose messages are needed from othe modules please let me know. I do not have this problem with kernel versions 2.6.20 and below. Something changed in 2.6.21 and I do not know what. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] modprobe mantis stalls/hangs/freezes (Twinhan VP-1034 and ivtv)
Michel Verbraak wrote: I have a Twinhan VP-1034 and I use the the latest hg, today, and http://jusst.de/manu/mantis-v4l-dvb.tar.bz2 with kernel 2.6.22.1. When I do a 'modprobe mantis' my prompt never returns. The machine still is working. [snip] Address=[0x25] W[ 00 3mantis_ack_wait (0): Waiting for Slave RACK Aug 25 17:53:33 recorder kernel: mantis_ack_wait (0): Waiting for Slave RACK Aug 25 17:53:42 recorder last message repeated 499 times Aug 25 17:53:42 recorder kernel: mantis_ack_wait (0): Slave RACK Fail ! Aug 25 17:53:42 recorder kernel: mantis_i2c_write (0): ACK failedW I must say I also have a Hauppauge PVR-150 and a PVR-350 in this machine, using ivtv from hg, and when I remove both I do not have this problem. The modules load without any problems. with ivtv modules loaded somebody else mentioned of issues with regards to DMA transfers on the 878 based cards. I don't really understand why ivtv modules causes those problems. (IIRC it was Sigmund, i think) If more verbose messages are needed from othe modules please let me know. I do not have this problem with kernel versions 2.6.20 and below. Something changed in 2.6.21 and I do not know what. Without any any driver loaded for the ivtv hardware, do you still experience the same problems ? Is the ivtv hardware sharing interrupts with the Mantis ? My guess would be that the ivtv drivers grab a lot of IRQ time on the CPU leaving little shared IRQ time for other devices. Can you verify this ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
