public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
* Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)
@ 2009-08-26 13:53 Magnus Nilsson
  2009-08-26 16:21 ` Magnus Nilsson
  0 siblings, 1 reply; 6+ messages in thread
From: Magnus Nilsson @ 2009-08-26 13:53 UTC (permalink / raw)
  To: linux-media

Hello,

I've two identical cards of this model, with the sticker on the tuner 
saying:
3139 147 24321G#
CU1216LS/AGIGH-3
SW21 0717
MADE IN INDONESIA

I've been trying as few different kernels, with the current one being 
2.6.30-5.
As far as I can understand these cards have the tda10023 frontend. 
However, when trying s2-liplianin through opensascng (using cardsharing, 
which I can't do without) the machine completely locks up. If I try 
without sasc, and just point mythtv to devices 0 and 1, it doesn't seem 
to hang but then I can only watch FTA channels.

I've also tried mantis-v4l, which for some strange reason detects the 
tda10021 frontend instead of tda10023, hence it doesn't achieve a lock 
at all.

Any ideas?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)
  2009-08-26 13:53 Azurewave AD-CP400 (Twinhan VP-2040 DVB-C) Magnus Nilsson
@ 2009-08-26 16:21 ` Magnus Nilsson
  2009-09-06 20:52   ` MartinG
  0 siblings, 1 reply; 6+ messages in thread
From: Magnus Nilsson @ 2009-08-26 16:21 UTC (permalink / raw)
  To: linux-media

Magnus Nilsson wrote:
> Hello,
> 
> I've two identical cards of this model, with the sticker on the tuner 
> saying:
> 3139 147 24321G#
> CU1216LS/AGIGH-3
> SW21 0717
> MADE IN INDONESIA
> 
> I've been trying as few different kernels, with the current one being 
> 2.6.30-5.
> As far as I can understand these cards have the tda10023 frontend. 
> However, when trying s2-liplianin through opensascng (using cardsharing, 
> which I can't do without) the machine completely locks up. If I try 
> without sasc, and just point mythtv to devices 0 and 1, it doesn't seem 
> to hang but then I can only watch FTA channels.
> 
> I've also tried mantis-v4l, which for some strange reason detects the 
> tda10021 frontend instead of tda10023, hence it doesn't achieve a lock 
> at all.
> 
> Any ideas?

Nevermind this for the time being...all is pointing to open-sasc-ng 
being the culprit here...

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)
  2009-08-26 16:21 ` Magnus Nilsson
@ 2009-09-06 20:52   ` MartinG
  2009-09-07  9:40     ` Magnus Nilsson
  0 siblings, 1 reply; 6+ messages in thread
From: MartinG @ 2009-09-06 20:52 UTC (permalink / raw)
  To: Magnus Nilsson; +Cc: linux-media

On Wed, Aug 26, 2009 at 6:21 PM, Magnus Nilsson<magnus@upcore.net> wrote:
> Nevermind this for the time being...all is pointing to open-sasc-ng being
> the culprit here...

Just to add a datapoint - I have the same problem: I can't seem to
successfully scan for channels. I've taken open-sasc-ng out of the
equation by simply not loading the loopback device and scan directly
on the true frontend.
These are my bits:
Terratec Cinergy C HD PCI
kernel 2.6.29.6-217.2.16.fc11.x86_64
s2-liplianin from http://mercurial.intuxication.org/hg/s2-liplianin
Currently:
changeset:   12465:096aa4559b71
tag:         tip
user:        Igor M. Liplianin <liplianin@me.by>
date:        Sat Sep 05 20:26:33 2009 +0300

dmesg when "modprobe mantis"
Sep  6 22:33:52 localhost kernel: Mantis 0000:04:00.0: PCI INT A ->
GSI 16 (level, low) -> IRQ 16
Sep  6 22:33:52 localhost kernel: irq: 16, latency: 64
Sep  6 22:33:52 localhost kernel: memory: 0xfdfff000, mmio: 0xffffc20023906000
Sep  6 22:33:52 localhost kernel: found a VP-2040 PCI DVB-C device on (04:00.0),
Sep  6 22:33:52 localhost kernel:    Mantis Rev 1 [153b:1178], irq:
16, latency: 64
Sep  6 22:33:52 localhost kernel:    memory: 0xfdfff000, mmio:
0xffffc20023906000
Sep  6 22:33:52 localhost kernel:    MAC Address=[00:08:ca:1d:bd:a6]
Sep  6 22:33:52 localhost kernel: mantis_alloc_buffers (0):
DMA=0xcc0d0000 cpu=0xffff8800cc0d0000 size=65536
Sep  6 22:33:52 localhost kernel: mantis_alloc_buffers (0):
RISC=0xa85ce000 cpu=0xffff8800a85ce000 size=1000
Sep  6 22:33:52 localhost kernel: DVB: registering new adapter (Mantis
dvb adapter)
Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): Probing
for CU1216 (DVB-C)
Sep  6 22:33:52 localhost kernel: TDA10023: i2c-addr = 0x0c, id = 0x7d
Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): found
Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c
Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): Mantis
DVB-C Philips CU1216 frontend attach success
Sep  6 22:33:52 localhost kernel: DVB: registering adapter 0 frontend
0 (Philips TDA10023 DVB-C)...
Sep  6 22:33:52 localhost kernel: mantis_ca_init (0): Registering EN50221 device
Sep  6 22:33:52 localhost kernel: mantis_ca_init (0): Registered EN50221 device
Sep  6 22:33:52 localhost kernel: mantis_hif_init (0): Adapter(0)
Initializing Mantis Host Interface
Sep  6 22:33:52 localhost kernel: input: Mantis VP-2040 IR Receiver as
/devices/virtual/input/input11
Sep  6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown
key: key=0x00 raw=0x00 down=1
Sep  6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown
key: key=0x00 raw=0x00 down=0

lspci -v
04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV
PCI Bridge Controller [Ver 1.0] (rev 01)
        Subsystem: TERRATEC Electronic GmbH Device 1178
        Flags: bus master, medium devsel, latency 64, IRQ 16
        Memory at fdfff000 (32-bit, prefetchable) [size=4K]
        Kernel driver in use: Mantis
        Kernel modules: mantis

I have also tried the mantis module from v4l-dvb without success. The
card is then recognized as TDA10021 instead of TDA10023, just as you
describe.

Typically, I have to do "modprobe -r mantis;modprobe mantis" right
before I try to scan (with w_scan, scandvb og mythtv) in order to get
any channels at all. But the joy doesn't last for long, and I get
stuff like
kernel: mantis_ack_wait (0): Slave RACK Fail !
in /var/log/messages.

I guess the problems mentioned in the following post are related:
 Subject: Terratec Cinergy C HD tuning problems
 Date: 2009-08-19 21:10:56 GMT

Hope we can find a solution to this!

best,
MartinG

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)
  2009-09-06 20:52   ` MartinG
@ 2009-09-07  9:40     ` Magnus Nilsson
  2009-09-11  5:46       ` Claes Lindblom
  0 siblings, 1 reply; 6+ messages in thread
From: Magnus Nilsson @ 2009-09-07  9:40 UTC (permalink / raw)
  To: MartinG; +Cc: linux-media

MartinG wrote:
> On Wed, Aug 26, 2009 at 6:21 PM, Magnus Nilsson<magnus@upcore.net> wrote:
>> Nevermind this for the time being...all is pointing to open-sasc-ng being
>> the culprit here...
> 
> Just to add a datapoint - I have the same problem: I can't seem to
> successfully scan for channels. I've taken open-sasc-ng out of the
> equation by simply not loading the loopback device and scan directly
> on the true frontend.
> These are my bits:
> Terratec Cinergy C HD PCI
> kernel 2.6.29.6-217.2.16.fc11.x86_64
> s2-liplianin from http://mercurial.intuxication.org/hg/s2-liplianin
> Currently:
> changeset:   12465:096aa4559b71
> tag:         tip
> user:        Igor M. Liplianin <liplianin@me.by>
> date:        Sat Sep 05 20:26:33 2009 +0300
> 
> dmesg when "modprobe mantis"
> Sep  6 22:33:52 localhost kernel: Mantis 0000:04:00.0: PCI INT A ->
> GSI 16 (level, low) -> IRQ 16
> Sep  6 22:33:52 localhost kernel: irq: 16, latency: 64
> Sep  6 22:33:52 localhost kernel: memory: 0xfdfff000, mmio: 0xffffc20023906000
> Sep  6 22:33:52 localhost kernel: found a VP-2040 PCI DVB-C device on (04:00.0),
> Sep  6 22:33:52 localhost kernel:    Mantis Rev 1 [153b:1178], irq:
> 16, latency: 64
> Sep  6 22:33:52 localhost kernel:    memory: 0xfdfff000, mmio:
> 0xffffc20023906000
> Sep  6 22:33:52 localhost kernel:    MAC Address=[00:08:ca:1d:bd:a6]
> Sep  6 22:33:52 localhost kernel: mantis_alloc_buffers (0):
> DMA=0xcc0d0000 cpu=0xffff8800cc0d0000 size=65536
> Sep  6 22:33:52 localhost kernel: mantis_alloc_buffers (0):
> RISC=0xa85ce000 cpu=0xffff8800a85ce000 size=1000
> Sep  6 22:33:52 localhost kernel: DVB: registering new adapter (Mantis
> dvb adapter)
> Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): Probing
> for CU1216 (DVB-C)
> Sep  6 22:33:52 localhost kernel: TDA10023: i2c-addr = 0x0c, id = 0x7d
> Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): found
> Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c
> Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): Mantis
> DVB-C Philips CU1216 frontend attach success
> Sep  6 22:33:52 localhost kernel: DVB: registering adapter 0 frontend
> 0 (Philips TDA10023 DVB-C)...
> Sep  6 22:33:52 localhost kernel: mantis_ca_init (0): Registering EN50221 device
> Sep  6 22:33:52 localhost kernel: mantis_ca_init (0): Registered EN50221 device
> Sep  6 22:33:52 localhost kernel: mantis_hif_init (0): Adapter(0)
> Initializing Mantis Host Interface
> Sep  6 22:33:52 localhost kernel: input: Mantis VP-2040 IR Receiver as
> /devices/virtual/input/input11
> Sep  6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown
> key: key=0x00 raw=0x00 down=1
> Sep  6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown
> key: key=0x00 raw=0x00 down=0
> 
> lspci -v
> 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV
> PCI Bridge Controller [Ver 1.0] (rev 01)
>         Subsystem: TERRATEC Electronic GmbH Device 1178
>         Flags: bus master, medium devsel, latency 64, IRQ 16
>         Memory at fdfff000 (32-bit, prefetchable) [size=4K]
>         Kernel driver in use: Mantis
>         Kernel modules: mantis
> 
> I have also tried the mantis module from v4l-dvb without success. The
> card is then recognized as TDA10021 instead of TDA10023, just as you
> describe.
> 
> Typically, I have to do "modprobe -r mantis;modprobe mantis" right
> before I try to scan (with w_scan, scandvb og mythtv) in order to get
> any channels at all. But the joy doesn't last for long, and I get
> stuff like
> kernel: mantis_ack_wait (0): Slave RACK Fail !
> in /var/log/messages.
> 
> I guess the problems mentioned in the following post are related:
>  Subject: Terratec Cinergy C HD tuning problems
>  Date: 2009-08-19 21:10:56 GMT
> 
> Hope we can find a solution to this!
> 
> best,
> MartinG

I actually found what my problem was. It seems that open-sasc-ng has a 
weird bug, which means you can't tell it to log to a logfile by using 
the --log argument.

If I remove the '--log /var/log/open-sasc-ng.log' argument and instead 
lets it log directly to syslog, it works fine. I'm using syslog-ng, so 
it's not a problem directing all open-sasc-ng log traffic to a specific 
logfile anyway.

//Magnus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)
  2009-09-07  9:40     ` Magnus Nilsson
@ 2009-09-11  5:46       ` Claes Lindblom
  2009-09-11  8:31         ` Magnus Nilsson
  0 siblings, 1 reply; 6+ messages in thread
From: Claes Lindblom @ 2009-09-11  5:46 UTC (permalink / raw)
  To: Magnus Nilsson; +Cc: MartinG, linux-media

Magnus Nilsson wrote:
> MartinG wrote:
>> On Wed, Aug 26, 2009 at 6:21 PM, Magnus Nilsson<magnus@upcore.net> 
>> wrote:
>>> Nevermind this for the time being...all is pointing to open-sasc-ng 
>>> being
>>> the culprit here...
>>
>> Just to add a datapoint - I have the same problem: I can't seem to
>> successfully scan for channels. I've taken open-sasc-ng out of the
>> equation by simply not loading the loopback device and scan directly
>> on the true frontend.
>> These are my bits:
>> Terratec Cinergy C HD PCI
>> kernel 2.6.29.6-217.2.16.fc11.x86_64
>> s2-liplianin from http://mercurial.intuxication.org/hg/s2-liplianin
>> Currently:
>> changeset:   12465:096aa4559b71
>> tag:         tip
>> user:        Igor M. Liplianin <liplianin@me.by>
>> date:        Sat Sep 05 20:26:33 2009 +0300
>>
>> dmesg when "modprobe mantis"
>> Sep  6 22:33:52 localhost kernel: Mantis 0000:04:00.0: PCI INT A ->
>> GSI 16 (level, low) -> IRQ 16
>> Sep  6 22:33:52 localhost kernel: irq: 16, latency: 64
>> Sep  6 22:33:52 localhost kernel: memory: 0xfdfff000, mmio: 
>> 0xffffc20023906000
>> Sep  6 22:33:52 localhost kernel: found a VP-2040 PCI DVB-C device on 
>> (04:00.0),
>> Sep  6 22:33:52 localhost kernel:    Mantis Rev 1 [153b:1178], irq:
>> 16, latency: 64
>> Sep  6 22:33:52 localhost kernel:    memory: 0xfdfff000, mmio:
>> 0xffffc20023906000
>> Sep  6 22:33:52 localhost kernel:    MAC Address=[00:08:ca:1d:bd:a6]
>> Sep  6 22:33:52 localhost kernel: mantis_alloc_buffers (0):
>> DMA=0xcc0d0000 cpu=0xffff8800cc0d0000 size=65536
>> Sep  6 22:33:52 localhost kernel: mantis_alloc_buffers (0):
>> RISC=0xa85ce000 cpu=0xffff8800a85ce000 size=1000
>> Sep  6 22:33:52 localhost kernel: DVB: registering new adapter (Mantis
>> dvb adapter)
>> Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): Probing
>> for CU1216 (DVB-C)
>> Sep  6 22:33:52 localhost kernel: TDA10023: i2c-addr = 0x0c, id = 0x7d
>> Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): found
>> Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c
>> Sep  6 22:33:52 localhost kernel: mantis_frontend_init (0): Mantis
>> DVB-C Philips CU1216 frontend attach success
>> Sep  6 22:33:52 localhost kernel: DVB: registering adapter 0 frontend
>> 0 (Philips TDA10023 DVB-C)...
>> Sep  6 22:33:52 localhost kernel: mantis_ca_init (0): Registering 
>> EN50221 device
>> Sep  6 22:33:52 localhost kernel: mantis_ca_init (0): Registered 
>> EN50221 device
>> Sep  6 22:33:52 localhost kernel: mantis_hif_init (0): Adapter(0)
>> Initializing Mantis Host Interface
>> Sep  6 22:33:52 localhost kernel: input: Mantis VP-2040 IR Receiver as
>> /devices/virtual/input/input11
>> Sep  6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown
>> key: key=0x00 raw=0x00 down=1
>> Sep  6 22:33:53 localhost kernel: Mantis VP-2040 IR Receiver: unknown
>> key: key=0x00 raw=0x00 down=0
>>
>> lspci -v
>> 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV
>> PCI Bridge Controller [Ver 1.0] (rev 01)
>>         Subsystem: TERRATEC Electronic GmbH Device 1178
>>         Flags: bus master, medium devsel, latency 64, IRQ 16
>>         Memory at fdfff000 (32-bit, prefetchable) [size=4K]
>>         Kernel driver in use: Mantis
>>         Kernel modules: mantis
>>
>> I have also tried the mantis module from v4l-dvb without success. The
>> card is then recognized as TDA10021 instead of TDA10023, just as you
>> describe.
>>
>> Typically, I have to do "modprobe -r mantis;modprobe mantis" right
>> before I try to scan (with w_scan, scandvb og mythtv) in order to get
>> any channels at all. But the joy doesn't last for long, and I get
>> stuff like
>> kernel: mantis_ack_wait (0): Slave RACK Fail !
>> in /var/log/messages.
>>
>> I guess the problems mentioned in the following post are related:
>>  Subject: Terratec Cinergy C HD tuning problems
>>  Date: 2009-08-19 21:10:56 GMT
>>
>> Hope we can find a solution to this!
>>
>> best,
>> MartinG
>
> I actually found what my problem was. It seems that open-sasc-ng has a 
> weird bug, which means you can't tell it to log to a logfile by using 
> the --log argument.
>
> If I remove the '--log /var/log/open-sasc-ng.log' argument and instead 
> lets it log directly to syslog, it works fine. I'm using syslog-ng, so 
> it's not a problem directing all open-sasc-ng log traffic to a 
> specific logfile anyway.
>
> //Magnus
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hi, I have the same problem with Slave RACK Fail on my Azurewave 
AP-SP400 (VP-1041).
Do you really mean that to don't get theese problems when turning off 
the log from open-sasc-ng or was the problem on open-sasc-ng?
I have turned off the log completely for a long time since it was 
problems in open-sasc-ng but I still have problems with Slave RACK Fail.
I'm using the same drivers with  Ubuntu server x86_64 2.6.28-13-generic 
kernel.

Have you done anything else to work properly, like patching open-sasc-ng 
or the driver?
 From my experience it really starts to fail when using MythTV, 
otherwise I can tune channels for several days straight without any 
problems.
But when doing a complete channels scan it can make the driver fail so I 
would not blame mythtv to much but it's feels like something messes
it up.
Maybe it's getting better in Mythtv 0.22...

I'm almost about to sell my tv-card if it does not start to work 
properly. :(

Best regards
/Claes


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Azurewave AD-CP400 (Twinhan VP-2040 DVB-C)
  2009-09-11  5:46       ` Claes Lindblom
@ 2009-09-11  8:31         ` Magnus Nilsson
  0 siblings, 0 replies; 6+ messages in thread
From: Magnus Nilsson @ 2009-09-11  8:31 UTC (permalink / raw)
  To: Claes Lindblom; +Cc: linux-media

Claes Lindblom wrote:
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Hi, I have the same problem with Slave RACK Fail on my Azurewave
> AP-SP400 (VP-1041).
> Do you really mean that to don't get theese problems when turning off
> the log from open-sasc-ng or was the problem on open-sasc-ng?
> I have turned off the log completely for a long time since it was
> problems in open-sasc-ng but I still have problems with Slave RACK Fail.
> I'm using the same drivers with  Ubuntu server x86_64 2.6.28-13-generic
> kernel.
> 
> Have you done anything else to work properly, like patching open-sasc-ng
> or the driver?
> From my experience it really starts to fail when using MythTV, otherwise
> I can tune channels for several days straight without any problems.
> But when doing a complete channels scan it can make the driver fail so I
> would not blame mythtv to much but it's feels like something messes
> it up.
> Maybe it's getting better in Mythtv 0.22...
> 
> I'm almost about to sell my tv-card if it does not start to work
> properly. :(
> 
> Best regards
> /Claes
> 

If you read the entire thread it was MartinG that had the problem with
"Slave RACK Fail". My machine just completely locked up before I removed
the logging in open-sasc-ng. I'm currently using a vanilla 2.6.30.5
kernel, with open-sasc-ng r77 and s2-liplianin-16e3dc6f2758, on a Debian
system with MythTV 0.21 from the vanilla sources.
The only thing I've had to do to get open-sasc-ng to compile was comment
out the lines containing "owner", specifically lines 175,187,196,221 in
dvbloopback/module/dvblb_proc.c

I can remember seeing Slave RACK Fail errors when using the older mantis
driver from Manu (not the mantis-v4l one). That was however only when
booting up, since it paused for a few seconds while displaying 4 of
those errors. I don't see it now with the newer drivers though.

Keep in mind that we don't even have the same card, since I have the
AD-CP400 (DVB-C version).

Thanks,
Magnus

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-09-11  8:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-26 13:53 Azurewave AD-CP400 (Twinhan VP-2040 DVB-C) Magnus Nilsson
2009-08-26 16:21 ` Magnus Nilsson
2009-09-06 20:52   ` MartinG
2009-09-07  9:40     ` Magnus Nilsson
2009-09-11  5:46       ` Claes Lindblom
2009-09-11  8:31         ` Magnus Nilsson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox