Hi,
On Tue, 24 Oct 2006, Nicolas George wrote:
Le sextidi 26 vendémiaire, an CCXV, Patrick Boettcher a écrit :
in my repository (http://linuxtv.org/hg/~pb/v4l-dvb) I just committed a
first working version of the dib7000m/p-driver along with some
modifications in the dib0700-driver.
Le quartidi 4 brumaire, an CCXV, Patrick Boettcher a écrit :
[ 1880.948479] APIC error on CPU0: 40(40)
[ 1891.087908] hub 1-0:1.0: port 6 disabled by hub (EMI?), re-enabling...
Here the problem starts. The USB-Port is dying.
It seems so. Yet, it is something caused by the DVB device or
I've found where is the problem in the Kernel oops while using the
remote control with WinTV NOVA T USB2.
In the following function
(linux/drivers/media/dvb/dvb-usb/nova-t-usb2.c) I added a debug print
for all pointers involved and the one that is NULL is st meaning
that d-priv is NULL.
I've
Hi,
Christian Fraenkel wrote:
I am writing a small dvr software for my nova-ci, and noticed that I was
unable (after some time) to open /dev/adapter0/demux0. (open() blocks)
my dmesg shows the following oops:
dvb_demux_feed_del: feed not in list (type=0 state=0 pid=)
Unable to handle
Am 14.05.2004 um 00:45 schrieb Christian Gmeiner:
A friend of me is using a TechnoTrend Budget DVB-S (like Nova-CI) with
a
2.6.6 Kernel and the current cvs. But he gets this Ooops:
I'm getting the same with Kernel 2.6.5.
This is an bug wich is introduced between CVS 2004-05-05 and 2004-05-09
On Tuesday 09 March 2004 00:54, Oliver Endriss wrote:
On Monday 08 March 2004 22:36, Robert Schlabbach wrote:
From: Oliver Endriss [EMAIL PROTECTED]
People have invested real money into these full featured DVB cards
and just don't want to throw them away.
Plus, there just isn't any
Robert Schlabbach wrote:
From: Oliver Endriss [EMAIL PROTECTED]
People have invested real money into these full featured DVB cards
and just don't want to throw them away.
Plus, there just isn't any reasonable alternative
Full-featured ack. ;-)
Full-featured cards are legacy
People have invested real money into these full featured DVB cards
and just don't want to throw them away.
Plus, there just isn't any reasonable alternative
Full-featured ack. ;-)
Full-featured cards are "legacy hardware", they have
Oliver Endriss wrote:
On Monday 08 March 2004 21:34, Holger Waechtler wrote:
Ralph Metzler wrote:
Oliver Endriss writes:
And, unless there is a hardware or firmware CSA descrambler on the card, you
will never be able to decrypt pay-tv in a legal way.
IANAL, but I don't think that
Robert Schlabbach writes:
KNC released the specs (no begging and/or disassembling necessary ...)
but the code we wrote is currently bound to a commercial project. It
works since almost a year (at least with the modules without hardware
problems).
One question: Does the KNC CI
From: Klaus Schmidinger [EMAIL PROTECTED]
Robert Schlabbach wrote:
Full-featured cards are legacy hardware, they have no future.
But they are very widely used _now_, and will be as long as they
physically live. I don't think that people are going to throw away their
full featured cards just
On Friday 05 March 2004 11:17, Klaus Schmidinger wrote:
Well, Holger, you keep repeating over and over that the av7110 driver
is broken and that this is ancient hardware and how great modern
hardware ist - but IMHO you totally neglect that the av7110 still is probably
the most widely used
Oliver Endriss writes:
Also: are there any
budget cards already that have drivers that support CAMs? I have to admit that
I don't know that.
AFAIK there is _no_ budget card driver with CI support under linux.
No public and GPLed ones.
There are drivers for KNC and Twinhan cards.
On Saturday 06 March 2004 15:04, Oliver Endriss wrote:
On Friday 05 March 2004 11:17, Klaus Schmidinger wrote:
Well, Holger, you keep repeating over and over that the av7110 driver
is broken and that this is ancient hardware and how great modern
hardware ist - but IMHO you totally neglect
Ralph Metzler wrote:
Oliver Endriss writes:
Also: are there any
budget cards already that have drivers that support CAMs? I have to admit that
I don't know that.
AFAIK there is _no_ budget card driver with CI support under linux.
No public and GPLed ones.
There are drivers for KNC and
From: Oliver Endriss [EMAIL PROTECTED]
People have invested real money into these full featured DVB cards
and just don't want to throw them away.
Plus, there just isn't any reasonable alternative
Full-featured ack. ;-)
Full-featured cards are legacy hardware, they have no future. Thus,
Robert Schlabbach writes:
AFAIK there is _no_ budget card driver with CI support under linux.
Not yet, although Andrew and I have pretty much figured out how the
hardware works. However, I am out of it for the foreseeable time, because
the only type of CAM I can afford for development
On Monday 08 March 2004 22:36, Robert Schlabbach wrote:
From: Oliver Endriss [EMAIL PROTECTED]
People have invested real money into these full featured DVB cards
and just don't want to throw them away.
Plus, there just isn't any reasonable alternative
Full-featured ack. ;-)
On Monday 08 March 2004 21:34, Holger Waechtler wrote:
Ralph Metzler wrote:
Oliver Endriss writes:
And, unless there is a hardware or firmware CSA descrambler on the card, you
will never be able to decrypt pay-tv in a legal way.
IANAL, but I don't think that anyone can write a CSA
From: Ralph Metzler [EMAIL PROTECTED]
Robert Schlabbach writes:
the only type of CAM I can afford for development purposes (ZetaCAM,
Free-X TV, IceCrypt) all happen to be incompatible with TechnoTrend's
Budget-CI
AFAIK, these are problems with the power supply for the CI
module. They
From: Oliver Endriss [EMAIL PROTECTED]
Hm, interesting. Are you sure? Afaik the CSA is implemented in the AV7110
of the full-featured cards. So I would have expected that CSA has to be
implemented in the driver of the budget cards, not in the CAM.
Maybe I'm wrong.
These are two different
And, unless there is a hardware or firmware CSA descrambler on the
card, you will never be able to decrypt pay-tv in a legal way.
IANAL, but I don't think that anyone can write a CSA descrambler under
GPL.
That's incorrect. You don't needs to implement CSA, the MPEG-2 transport
Robert Schlabbach writes:
Aha, that's interesting! My symptoms are a bit different, though: Access to
the attribute memory and to the COR is fine, and the CAM _does_ correctly
That also works fine for me.
map its I/O registers when I write the configuration value to it (0x0F).
CAM reset
From: Ralph Metzler [EMAIL PROTECTED]
I also cannot say for 100% that the power supply explanation is
correct. That's only what I heard indirectly. Maybe there really is
more to it.
There is definitely something to it - I just bothered to take a real look
at the CIS from my yellow ZetaCAM, and
From: Ralph Metzler [EMAIL PROTECTED]
I also cannot say for 100% that the power supply explanation is
correct. That's only what I heard indirectly. Maybe there really is
more to it.
There is definitely something to this - I just bothered to take a real look
at the CIS from my yellow ZetaCAM,
On Tuesday 09 March 2004 01:15, Robert Schlabbach wrote:
From: Oliver Endriss [EMAIL PROTECTED]
Hm, interesting. Are you sure? Afaik the CSA is implemented in the AV7110
of the full-featured cards. So I would have expected that CSA has to be
implemented in the driver of the budget cards,
Andrew de Quincey writes:
And, unless there is a hardware or firmware CSA descrambler on the
card, you will never be able to decrypt pay-tv in a legal way.
IANAL, but I don't think that anyone can write a CSA descrambler under
GPL.
That's incorrect. You don't
Oliver Endriss writes:
These are two different things. Remember that some receivers only come with
a smart card slot, i.e. they have a builtin CAM. In those, the firmware
implements the algorithm which generates the key pairs (64 bits = 8 bytes),
with which the MPEG-2 transport stream
From: Ralph Metzler [EMAIL PROTECTED]
I thought about supporting the Nova CI a year ago, even disassembled
the CI interface routines at the time, but then thought: why bother
supporting TT if they make it so hard for Linux programmers?
Well, you kindly left something for Andrew and me to do.
On Tuesday 09 March 2004 01:43, Robert Schlabbach wrote:
From: Ralph Metzler [EMAIL PROTECTED]
I thought about supporting the Nova CI a year ago, even disassembled
the CI interface routines at the time, but then thought: why bother
supporting TT if they make it so hard for Linux
On Tuesday 09 March 2004 02:25, Ralph Metzler wrote:
Oliver Endriss writes:
Great. So there are no license/patent issues which might prevent writing
an open-source driver. I wonder why nobody has done this before.
The hardware has been available for some time.
I thought about
Johannes Stezenbach wrote:
[EMAIL PROTECTED] wrote:
i am playing around with the DVR device for playing back a TS which
was recorded from the DVR device.
...
The kernel is configured a an SMP Kernel and Preemptible feature.
That's a recipe for disaster -- the dvr playback code in the
Holger Waechtler wrote:
Johannes Stezenbach wrote:
[EMAIL PROTECTED] wrote:
i am playing around with the DVR device for playing back a TS which
was recorded from the DVR device.
...
The kernel is configured a an SMP Kernel and Preemptible feature.
That's a recipe
Klaus Schmidinger wrote:
Holger Waechtler wrote:
Johannes Stezenbach wrote:
[EMAIL PROTECTED] wrote:
i am playing around with the DVR device for playing back a TS which
was recorded from the DVR device.
...
The kernel is configured a an SMP Kernel and Preemptible feature.
That's a recipe
Holger Waechtler wrote:
Johannes Stezenbach wrote:
The problem is that the av7110 hardware does not support TS playback.
The driver tries to work around this by remuxing the TS into PES and
feeding PES to the hardware. IMHO this code should be dropped rather
than attempted to fix.
Holger Waechtler wrote:
Klaus Schmidinger wrote:
Holger Waechtler wrote:
...
calling the PES unpacking process a 'remuxing' is kind of flattered,
not? Forcing everybody to misuse the lowlevel-API instead of highlevel
access just because the av711x driver is broken...
Well,
Johannes Stezenbach wrote:
...
Sure, it would be cool if VDR would be changed so it supports
other hardware just as good as the av7110 cards. But IMHO VDR
should use PES playback on av7110 cards, and TS playback on hardware
that support it. Doing TS-PES conversion in the driver is wrong.
Klaus Schmidinger wrote:
Holger Waechtler wrote:
Klaus Schmidinger wrote:
Holger Waechtler wrote:
...
calling the PES unpacking process a 'remuxing' is kind of flattered,
not? Forcing everybody to misuse the lowlevel-API instead of highlevel
access just because the av711x driver is broken...
Marcus Metzler wrote:
Johannes Stezenbach writes:
other hardware just as good as the av7110 cards. But IMHO VDR
should use PES playback on av7110 cards, and TS playback on hardware
that support it. Doing TS-PES conversion in the driver is wrong.
The TS-PES conversion is the same as
On Friday 05 March 2004 12:36, Johannes Stezenbach wrote:
Holger Waechtler wrote:
Johannes Stezenbach wrote:
The problem is that the av7110 hardware does not support TS playback.
The driver tries to work around this by remuxing the TS into PES and
feeding PES to the hardware. IMHO this
On Friday 05 March 2004 13:43, you wrote:
Ok i am able to understand this situation and all of the problems.
Please take the next sentences as my thinkin of the whole situation :)
why is there a need for any kind of a dvb api when you have to implement driver
missing features in
Marcel Siegert wrote:
why is there a need for any kind of a dvb api when you have to
implement driver missing features in your software?
on my point of view it looks like - if my application runs e.g. on a
DBOX2/Dreambox/Whatever Linux running STB do nothing, if it runs on a
PC check for
Marcus Metzler wrote:
Johannes Stezenbach writes:
The problem is not only with nonblocking, but there are also
locking bugs between video and demux device access. Just try
to write TS to dvr and then VIDEO_SLOWMOTION or VIDEO_FREEZE
- deadlock.
It`s the same cause. The dvr
[EMAIL PROTECTED] wrote:
i am playing around with the DVR device for playing back a TS which was recorded
from the DVR device.
...
The kernel is configured a an SMP Kernel and Preemptible feature.
That's a recipe for disaster -- the dvr playback code in the av7110
is seriously b0rked. Apart
On Thursday 04 March 2004 21:01, Johannes Stezenbach wrote:
anybody you can help me out of this?
The problem is that the av7110 hardware does not support TS playback.
The driver tries to work around this by remuxing the TS into PES
and feeding PES to the hardware. IMHO this code should be
it's probably safer to use crc32_le() or crc32_be(), depends on which
one exactly you need.
Good idea.
Use a recent kernel, there crc32(), crc32_le() and crc32_be() are
implemented as library functions.
Right, but the first cause of the problem was that modprobe sees
CIPE's crc32 definition
Does this mean that the kernel from SuSE has no internal crc32 functions?
Sod's law, really. After digging around in various kernels, it seems that the
crc32 function that the ttusb_dec uses first appears in kernel 2.4.22. For a
quick fix, cut these lines out of
Thanks alot, now it works!
Regards
Rafael
Am Montag, 19. Januar 2004 18:05 schrieb Alex Woods:
Does this mean that the kernel from SuSE has no internal crc32 functions?
Sod's law, really. After digging around in various kernels, it seems that
the crc32 function that the ttusb_dec uses
[CCd to linux-kernel and dvb lists. Context: SuSE 9.0, kernel 2.4.21,
ttusb_dec module fails]
Is cipcb really needed in Release 1.36? It is the only modules which gives
crc32 as a symbol.
EIP; dde5ba82 [cipcb]crc32+12/30 =
eax; dea04560 [ttusb_dec]dsp_dec2000t+0/69100
edx;
Sod's law, really. After digging around in various kernels, it seems
that the crc32 function that the ttusb_dec uses first appears in
kernel 2.4.22.
correct.
As for something more long term I'm not too sure. I guess it depends
on what version of the kernel is considered the minimum
Am Montag, 19. Januar 2004 21:34 schrieb Olaf Titz:
[CCd to linux-kernel and dvb lists. Context: SuSE 9.0, kernel 2.4.21,
ttusb_dec module fails]
Eeek. If the OP didn't even know if he needed the cipcb module, this
should mean he didn't knowingly start the CIPE driver, and[*] thus the
cipcb
Olaf Titz wrote:
[CCd to linux-kernel and dvb lists. Context: SuSE 9.0, kernel 2.4.21,
ttusb_dec module fails]
Is cipcb really needed in Release 1.36? It is the only modules which gives
crc32 as a symbol.
EIP; dde5ba82 [cipcb]crc32+12/30 =
eax; dea04560 [ttusb_dec]dsp_dec2000t+0/69100
Am Montag, 19. Januar 2004 21:39 schrieb Olaf Titz:
Sod's law, really. After digging around in various kernels, it seems
that the crc32 function that the ttusb_dec uses first appears in
kernel 2.4.22.
Do a compile time test on the availability of that function? I'm doing
that in the
On Monday 19 January 2004 9:04 pm, Rafael Kolless wrote:
Am Montag, 19. Januar 2004 21:39 schrieb Olaf Titz:
Sod's law, really. After digging around in various kernels, it seems
that the crc32 function that the ttusb_dec uses first appears in
kernel 2.4.22.
Do a compile time test on
Am Montag, 19. Januar 2004 22:18 schrieb Alex Woods:
Just around those lines I told you to remove. It should work just fine, and
checking really is optional. The reason I was considering not doing it, is
that there are already of a lot of compiler directives in the driver due to
differences
On Monday 19 January 2004 9:23 pm, Rafael Kolless wrote:
Am Montag, 19. Januar 2004 22:18 schrieb Alex Woods:
Just around those lines I told you to remove. It should work just fine,
and checking really is optional. The reason I was considering not doing
it, is that there are already of a
I forgot to thank you all for your help :)
Rafael
--
www.pinguin-and-knights.org
2003 by Lontro
pgp0.pgp
Description: signature
On Sunday 18 January 2004 7:47 pm, Rafael Kolless wrote:
Hi,
I compiled the last release of the ttusb_dec-Modul (1.36)
I use SuSE 9.0 with the current kernel-source 2.4.21-166 optimized for
Athlon. Each time I load the modul i get an oops like this:
--
Jan 18 20:12:39 Thor kernel:
Hi,
Not sure. Could you pipe this oops through ksymoops please?
I hope I did it right, was my first try with ksymoops.
Is cipcb really needed in Release 1.36? It is the only modules which gives
crc32 as a symbol.
ksymoops 2.4.9 on i686 2.4.21-166-athlon. Options used
-V (default)
Not sure. Could you pipe this oops through ksymoops please?
I hope I did it right, was my first try with ksymoops.
Is cipcb really needed in Release 1.36? It is the only modules which gives
crc32 as a symbol.
EIP; dde5ba82 [cipcb]crc32+12/30 =
eax; dea04560
I was able to reproduce and trace it, found out it occured in the
dvb_demux.c and following this I tried to get the relations of the
different structures but failed in some parts. I've attached a simple
code that will trigger the crash on our platform sooner or later
(depending on the
61 matches
Mail list logo
