[linux-dvb] Re: Kernel oops with new DiB7000M driver (was: DiB7000M-driver released (Nova-T Stick, AverMedia and others))
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 driver, since it occurs specifically when I try to change something. I just tried to just watch TV, and it worked without oopsing; in particular, it survived several of these annoying but seemingly harmless "APIC error"s that I have since the beginning. It oopsed when I tried to change the channel (on the fourth time). On the other hand, I just tried to insert an USB hub in the chain, and now mplayer complains that: dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 1948 bytes and tzap shows a status of 1b instead of 1f. The status stays 1b even if I unplug the stick and re-plug it directly on the computer. It all seems quite mysterious. > > [ 1891.087915] usb 1-6: USB disconnect, address 2 > And the device disconnects. I assume while you are watching TV. That's why > the following Oops. The dvb-core is not hotpluggable so it cannot handle > suddenly disappearing devices. > > > [ 1896.963791] Unable to handle kernel NULL pointer dereference at > > 0021 RIP: > What is your USB controller? It seems to be an ATI SB400. Thanks for your efforts. -- Nicolas George 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI]) Subsystem: Acer Incorporated [ALI] Unknown device 007e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI]) Subsystem: Acer Incorporated [ALI] Unknown device 007e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (prog-if 20 [EHCI]) Subsystem: Acer Incorporated [ALI] Unknown device 007e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- signature.asc Description: Digital signature ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Kernel oops with new DiB7000M driver (was: DiB7000M-driver released (Nova-T Stick, AverMedia and others))
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. > > Thanks for your efforts. > > > Please load the dib7000m-driver with debug=1 in case it does not work and > > reply to this Email but change the subject (like: "Problem (was: DiB7000M > > ...") - success reports (Yes I want them as well) can be replied without > > changing the subject. > > I just tried a snapshot with my new generation WinTV Nova-T USB2 stick, and > got a kernel oops. But before that it worked. > > Here are the details: the host is Thurion64-based and runs a 2.6.17.8 kernel > from kernel.org. The first time I tried, scan made the kernel oops. The > second time (after reboot, and adding debug=1), scan worked (twice, the > first time with the small antenna in vain) and found channels, and mplayer > could show some trash television. > > It oopsed when I tried to change the channel. I put the kernel messages at > the end of my mail. I believe I still have the corresponding unstripped > kernel binary if it is necessary to exploit them. > > Anyway, this is an encouraging start. > > Regards, > > -- > Nicolas George > > [ 1469.124805] DiB7000M:-E- No valid AGC configuration found for band 0x08 Strange. But not related. > [ 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. > [ 1891.087915] usb 1-6: USB disconnect, address 2 And the device disconnects. I assume while you are watching TV. That's why the following Oops. The dvb-core is not hotpluggable so it cannot handle suddenly disappearing devices. > [ 1896.963791] Unable to handle kernel NULL pointer dereference at > 0021 RIP: What is your USB controller? Patrick.___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Kernel Oops with Hauppauge WinTV NOVA T USB2 & Remote Control
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 tried and the error occurs both while playing TV and while not playing.
The rest of the function works properly. Here is the output when I
block the null pointer dereference (with debug enabled).
Oct 7 14:02:33 thinkpad kernel: raw key code 0xfc, 0x1f, 0x00 to c:
1e d: 03 toggle: 1
Oct 7 14:02:33 thinkpad kernel: c: 0, d: 1e
Oct 7 14:02:33 thinkpad kernel: c: 1, d: 1e
Oct 7 14:02:33 thinkpad kernel: c: 2, d: 1e
Oct 7 14:02:33 thinkpad kernel: c: 3, d: 1e
Oct 7 14:02:33 thinkpad kernel: ERROR 2 3
"ERROR 2" is something I added to find where the null pointer occurs,
afterwards the function is forced to "return 0".
Does anybody know how this thing works? Who and when initialises d->priv?
static int nova_t_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
{
u8 key[5],cmd[2] = { DIBUSB_REQ_POLL_REMOTE, 0x35 }, data,toggle,custom;
u16 raw;
int i = 0;
struct dibusb_state *st = d->priv;
// st is NULL!!!
dvb_usb_generic_rw(d,cmd,2,key,5,0);
*state = REMOTE_NO_KEY_PRESSED;
switch (key[0]) {
case DIBUSB_RC_HAUPPAUGE_KEY_PRESSED:
raw = ((key[1] << 8) | key[2]) >> 3;
toggle = !!(raw & 0x800);
data = raw & 0x3f;
custom = (raw >> 6) & 0x1f;
deb_rc("raw key code 0x%02x, 0x%02x, 0x%02x to c: %02x
d: %02x
toggle: %d\n",key[1],key[2],key[3],custom,data,toggle);
for (i = 0; i < ARRAY_SIZE(haupp_rc_keys); i++) {
deb_rc("c: %x, d:
%x\n",haupp_rc_keys[i].data,haupp_rc_keys[i].custom);
if (haupp_rc_keys[i].data == data &&
haupp_rc_keys[i].custom == custom) {
*event = haupp_rc_keys[i].event;
*state = REMOTE_KEY_PRESSED;
if (st->old_toggle == toggle) {
if (st->last_repeat_count++ < 2)
*state =
REMOTE_NO_KEY_PRESSED;
} else {
st->last_repeat_count = 0;
st->old_toggle = toggle;
}
break;
}
}
break;
case DIBUSB_RC_HAUPPAUGE_KEY_EMPTY:
default:
break;
}
return 0;
}
Thanks
Mario
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Kernel oops on 2.6.6
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 kernel paging request at virtual address eaa1e7a8 > printing eip: > ca85cdcc > *pde = > Oops: 0002 [#1] > PREEMPT > CPU:0 > EIP:0060:[]Not tainted > EFLAGS: 00010202 (2.6.6) > EIP is at dvbdmx_release_ts_feed+0x9c/0xc0 [dvb_core] There seems to be a bug in error handling when DMX_SET_PES_FILTER is called with an invalid pes_type. So don't do that ;-/ I don't know how to fix this yet. Essentially, if dmx_ts_feed_set() fails because pes_type is invalid, dvbdmx_release_ts_feed() must not try to do the following: if (feed->ts_type & TS_DECODER) demux->pesfilter[feed->pes_type] = NULL; Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel-Oops with newest cvs and 2.6.6 kernel
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 afaik. Tom. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 because some people say "they have no future"... Noone said that anyone should throw anything away. I clearly stated the future-looking development should be focused on _current_ technologies. E.g. if you have to make a "hack" to expand function to other cards, make that hack for the _legacy_ cards, not for current technology. > I'd really like to see a new, full featured, DVB card come onto the > market that does away with all the shortcomings of the TT design, > has a better OSD and digital audio output. If such a new card > would work with the LinuxDVB driver I'd by several of them in a > heartbeat. Unfortunately, the hardware manufacturers don't seem > to like useful solutions... :-( They don't like making products that don't sell. STB cards are too expensive and to inflexible. A modern STB (aka "full-featured") card would have to feature: - HDTV MPEG-2 hardware decoding - H.264/AVC hardware decoding - WMV9 HD hardware decoding - DVI/HDMI/HDCP and YbPbCr video outputs - Dolby AC-3 hardware decoding - optical audio outputs - common interface Personally, I wouldn't want to pay for all this junk. Why? Because I already _have_ paid for most of it: I have a graphics card with DVI and MPEG-2 hardware decoding support, a sound card with S/PDIF, and a CPU with well enough power to handle the other stuff in software. All I need is a pure receiver card which gets me the digital data stream, and maybe a common interface slot or two to decrypt pay-TV channels. Why should I pay for any further capabilities, which I already have? Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 allow changing the voltage supplied to the > CAM? If I understand EN50221 right, the CAM may specify a supply voltage > other than 5V. However, the TT CI does not seem to allow controlling the > supply voltage, I assume it is fixed at 5V. Do all known CAMs use 5V supply > voltage? The KNC CI interface (at least the one I have) is fixed to 5V. I guess all the usual CAMs on the market currently use 5V. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 anyone can write a CSA descrambler under GPL. There already are plenty available under GPL. But you might get problems with the patent if you do not have enough money to defend yourself against (currently actually still) illegal software patents. right, some lawyers might run amok, but you should be able to win the lawsuit -- at time of patent application it was definitely not possible to protect software, mathematical formulas and algorithms by patents in europe. Well, any valunteers here who can spend millions of $ to find out? *g* If you always wait until somebody else safeguards what you're doing and everybody else behaves like you it would not be possible to watch DVDs under Linux at all. DVB probably too. Media playback in general. Don't let them ablate your brain, otherwise you even believe SCO one day that Linux is illegal due to license infringement. It's too easy to spread out uncertainity and doubts... Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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. I don't think that people are going to throw away their full featured cards just because some people say "they have no future"... And isnt it, that the tv-out quality of the ff-card is much better than the routed picture through the tv-out of the graphics card? So why should such a design have no future? Ciao, Mario smime.p7s Description: S/MIME Cryptographic Signature
[linux-dvb] Re: Kernel OOPS
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 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 because some people say "they have no future"... I'd really like to see a new, full featured, DVB card come onto the market that does away with all the shortcomings of the TT design, has a better OSD and digital audio output. If such a new card would work with the LinuxDVB driver I'd by several of them in a heartbeat. Unfortunately, the hardware manufacturers don't seem to like useful solutions... :-( Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 reasonable alternative > > > > > > Full-featured ack. ;-) > > > > Full-featured cards are "legacy hardware", they have no future. Thus, > > future looking development should be centered around _current_ hardware, > > and it has become quite obvious that so-called "budget" cards are a much > > better solution, because they are cheap and allow much more flexibility > > when it comes to handling the incoming data, simply because that's all done > > in software. > > Well, this has been discussed before. More than enough, imho. > Even 'current' hardware will be outdated soon... Maybe exactly this this the most important thing. Think about not supporting or fixing any kind of driver because the Hardware may be outdated soon. Ever thought of ISA Plug&Play support in the Linux Kernel? Why it is still there? Haven't seen a board with ISA slots for a long time now - but - there are still people using the Linux Kernel on machines which offer isa slots and isa plug'n'pray :) I upset about myself not to have enough knowledge for developing kernel driver and/or TS/PES conversions. Maybe i have to improve this someday :) cu mws -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 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? > > 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). Maybe some competitors could pay Andrew and Robert for _not_ writing a driver? SCNR. Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 programmers? > > Well, you kindly left something for Andrew and me to do. Thank you very > much :-) Yeah, most happy! :) > > 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 allow changing the voltage supplied to the > CAM? If I understand EN50221 right, the CAM may specify a supply voltage > other than 5V. However, the TT CI does not seem to allow controlling the > supply voltage, I assume it is fixed at 5V. Do all known CAMs use 5V supply > voltage? I have a CI card lying about here with a CiMax chip on it (no idea where it came from; it doesn't fit on any card I have!), and it has a jumper for 3V/5V. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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. Thank you very much :-) > 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 allow changing the voltage supplied to the CAM? If I understand EN50221 right, the CAM may specify a supply voltage other than 5V. However, the TT CI does not seem to allow controlling the supply voltage, I assume it is fixed at 5V. Do all known CAMs use 5V supply voltage? Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 is decrypted using CSA. The firmware > > could then write this key pair to the corresponding AV7110 registers and > > have it decrypt the transport stream _without_ any CAM! > > I see. That's why they called the av7110 'Integrated Set-top Box Decoder'. > It was designed for stand-alone set-top boxes... > > > But when you have a CAM, it will implement the CSA. > > 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 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? 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). Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 needs to implement CSA, the MPEG-2 transport > > > stream from the demodulator is physically routed through the CAM, which > > > implements CSA. Thus, it can be done in a perfectly legal way. > > > > 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. > > Pretty sure; by my reading (and Robert's I think) of CENELEC EN50221, you feed > an encrypted stream to the CAM module, and it outputs a decrypted stream. The > CAM is treated as a "black box"; you just send control signals at it to > choose which PIDs to decode etc... well, I'll find out if who is right in a > few days :) You are definitely right. E.g. KNC cards work fine by leaving the decoding to the CAMs and without any CSA in software. Also compare with the specs of "CI-CAM chip" suppliers like SIDSA which say they implement CSA. The CSA in the AV7110 or other "STB chips" is only for embedded software CAMs as many receivers offer them (mostly with VIACCESS). I think it is not even possible to get a software license from the patent holder (totally apart from the question if this kind of algorithm patent is really valid in Europe). The whole thing is of course silly since the weak point never ever was the CSA (and obscurity would not help secure that if there were any weakness) but stupid errors in the card programming or other leaks. On the other hand, CSA in software is slow and better left to special purpose hardware anyway. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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, not in the CAM. > > Maybe I'm wrong. > > 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 is decrypted using CSA. The firmware > could then write this key pair to the corresponding AV7110 registers and > have it decrypt the transport stream _without_ any CAM! I see. That's why they called the av7110 'Integrated Set-top Box Decoder'. It was designed for stand-alone set-top boxes... > But when you have a CAM, it will implement the CSA. 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. Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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, and the power information says: 0x55 <- Nom V : EXP=5 (1V),MNT=10 (x5) -> 5V 0x4D <- Min V : EXP=5 (1V),MNT=9 (x4.5) -> 4.5V 0x5D <- Max V : EXP=5 (1V),MNT=11 (x5.5) -> 5.5V 0x56 <- Avg I : EXP=6 (100mA), MNT=10 (x5) -> 500 mA 0x56 <- Peak I: EXP=6 (100mA), MNT=10 (x5) -> 500 mA I.e. the CAM is working at a nominal voltages of 5V (with a tolerance from 4.5V to 5.5V), and the average (and peak) current is 500mA, a nominal power consumption of 2.5 watts. This is a clear violation of EN50221, A5.5.10, which specifies: | Each module shall neither consume nor dissipate more than 1.5 watts. | Additionally the power supply current to each module (sum of Vcc current | and Vpp current) shall not exceed 300mA long term, and the short-term | peak current is limited to 500mA for no more than 1ms. So Neotion's CAMs are indeed outside the range specified in the CAM standard. Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 the power information says: 0x55 <- Nom V : EXP=5 (1V),MNT=10 (x5) -> 5V 0x4D <- Min V : EXP=5 (1V),MNT=9 (x4.5) -> 4.5V 0x5D <- Max V : EXP=5 (1V),MNT=11 (x5.5) -> 5.5V 0x56 <- Avg I : EXP=6 (100mA), MNT=10 (x5) -> 500 mA 0x56 <- Peak I: EXP=6 (100mA), MNT=10 (x5) -> 500 mA So the CAM is working at a nominal voltages of 5V (with a tolerance from 4.5V to 5.5V), but the average current is 500mA. This is a clear violation of EN50221, A5.5.10, which specifies: " Each module shall neither consume nor dissipate more than 1.5 watts. Additionally the power supply current to each module (sum of Vcc current and Vpp current) shall not exceed 300mA long term, and the short-term peak current is limited to 500mA for no more than 1ms." -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 via the COR also works. This does not work for me. The value is not written (stays the same as before writing) and I/O registers are all 0xff. Other modules (Viaccess, Cryptoworks, Alphacrypt) work fine at this point. Only Icecrypt, Magic and their clone modules make problems. > What doesn't work, though, it access to the I/O registers. I can read them > fine, but I cannot reset the I/O interface through the command/status > register (the status remains at 0x00, although it should go to 0x40 [FR] > after some time). When I skip resetting the I/O interface and start with > reading the CAM's buffer size by writing 0x04 to command/status, the LS/MS > registers correctly indicate a size of 2, but the data I read from the DATA > register is erroneous, and the command/status registers does not behave > like it should (it goes to 0x01 after the first read, but not back to 0x00 > after the second read, but rather remains at 0x01 for about 240 read > operations). The erroneous data read appears to match the attribute memory > contents. > > The response I got from TechnoTrend was that the CAM's I/O timings must be > incorrect somehow, and that they might have to use a different PLD > programming to fix this. > > However, your suggestion about the power supply actually sounds more > plausible to me. After all, I'm quite sure that there is some standard > PCCard interface chip in that CAM, and why should that use incompatible > timings? Well, the TT CI card does not use a standard chip like CIMAX (I guess for cost reasons). So, maybe they did something wrong with timing. The same might be true for those cheaper CI-CAMs. The KNC card also uses its own interface hardware. > Do you think it is possible that the misbehavior I have observed could be > due to the CAM not getting enough power? > > Also, do you know which pins of the CAM are not getting enough power? Maybe > I should look into a little "hardware hack" and solder an extra wire onto > the card to supply more current to a specific pin...? Sorry, no idea. 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. Hmm, I did not test the Twinhan card with those modules yet. Let's see how it reacts ... Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
> > > 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 > > stream from the demodulator is physically routed through the CAM, which > > implements CSA. Thus, it can be done in a perfectly legal way. > > 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. Pretty sure; by my reading (and Robert's I think) of CENELEC EN50221, you feed an encrypted stream to the CAM module, and it outputs a decrypted stream. The CAM is treated as a "black box"; you just send control signals at it to choose which PIDs to decode etc... well, I'll find out if who is right in a few days :) Incidentally (for those of us in the UK), I just found a company that is moving back into the encrypted DVB-T market: http://www.topuptv.com Specifically from their site: "IDTV â is an Integrated Digital Television that has the set top box already built in and that means the TV can receive the Freeview channels. Most of the IDTVâs do not have a viewing card slot but have a âCommon Interfaceâ slot for the special Top Up TV âCAMâ. The Top Up TV Viewing Card then fits into the âConditional Access Moduleâ (âCAMâ). There a few TVâs that have been made with a viewing card slot built in and so please check your instruction manual to see whether your TV has this feature or not." I wonder how long it'll be before we start seeing DVB-T cards with CI interfaces in the UK -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 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 is decrypted using CSA. The firmware could then write this key pair to the corresponding AV7110 registers and have it decrypt the transport stream _without_ any CAM! But when you have a CAM, it will implement the CSA. Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 supposedly draw more power than usual cards. I don't know > if they are actually outside the allowed range according to the CI specs. > Older versions of the KNC card CI interfaces also had problems with > those cards. The symptoms I have are that the card does not react to > setting the configuration register (the one indicated in the CIS) and > thus access to the IO ports does not work. 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 map its I/O registers when I write the configuration value to it (0x0F). CAM reset via the COR also works. What doesn't work, though, it access to the I/O registers. I can read them fine, but I cannot reset the I/O interface through the command/status register (the status remains at 0x00, although it should go to 0x40 [FR] after some time). When I skip resetting the I/O interface and start with reading the CAM's buffer size by writing 0x04 to command/status, the LS/MS registers correctly indicate a size of 2, but the data I read from the DATA register is erroneous, and the command/status registers does not behave like it should (it goes to 0x01 after the first read, but not back to 0x00 after the second read, but rather remains at 0x01 for about 240 read operations). The erroneous data read appears to match the attribute memory contents. The response I got from TechnoTrend was that the CAM's I/O timings must be incorrect somehow, and that they might have to use a different PLD programming to fix this. However, your suggestion about the power supply actually sounds more plausible to me. After all, I'm quite sure that there is some standard PCCard interface chip in that CAM, and why should that use incompatible timings? Do you think it is possible that the misbehavior I have observed could be due to the CAM not getting enough power? Also, do you know which pins of the CAM are not getting enough power? Maybe I should look into a little "hardware hack" and solder an extra wire onto the card to supply more current to a specific pin...? Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 descrambler under GPL. > > > >There already are plenty available under GPL. > >But you might get problems with the patent if you do not have enough money > >to defend yourself against (currently actually still) illegal software patents. > > right, some lawyers might run amok, but you should be able to win the > lawsuit -- at time of patent application it was definitely not possible > to protect software, mathematical formulas and algorithms by patents in > europe. Well, any valunteers here who can spend millions of $ to find out? Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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. ;-) > > Full-featured cards are "legacy hardware", they have no future. Thus, > future looking development should be centered around _current_ hardware, > and it has become quite obvious that so-called "budget" cards are a much > better solution, because they are cheap and allow much more flexibility > when it comes to handling the incoming data, simply because that's all done > in software. Well, this has been discussed before. More than enough, imho. Even 'current' hardware will be outdated soon... > > 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 > stream from the demodulator is physically routed through the CAM, which > implements CSA. Thus, it can be done in a perfectly legal way. 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. Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 purposes (ZetaCAM, Free-X > TV, IceCrypt) all happen to be incompatible with TechnoTrend's Budget-CI > (and a number of other receivers, so the fault appears to be with the > French manufacturer Neotion, who seems to have some trouble understanding > the PC Card specs). AFAIK, these are problems with the power supply for the CI module. They supposedly draw more power than usual cards. I don't know if they are actually outside the allowed range according to the CI specs. Older versions of the KNC card CI interfaces also had problems with those cards. The symptoms I have are that the card does not react to setting the configuration register (the one indicated in the CIS) and thus access to the IO ports does not work. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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, future looking development should be centered around _current_ hardware, and it has become quite obvious that so-called "budget" cards are a much better solution, because they are cheap and allow much more flexibility when it comes to handling the incoming data, simply because that's all done in software. > 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 purposes (ZetaCAM, Free-X TV, IceCrypt) all happen to be incompatible with TechnoTrend's Budget-CI (and a number of other receivers, so the fault appears to be with the French manufacturer Neotion, who seems to have some trouble understanding the PC Card specs). Not sure about Andrew's status, last I heard he still couldn't get his hands on any Budget-CI card. It's almost as if some higher power doesn't _want_ us to make progress on this :-( > 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 stream from the demodulator is physically routed through the CAM, which implements CSA. Thus, it can be done in a perfectly legal way. Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 Twinhan cards. > 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. There already are plenty available under GPL. But you might get problems with the patent if you do not have enough money to defend yourself against (currently actually still) illegal software patents. right, some lawyers might run amok, but you should be able to win the lawsuit -- at time of patent application it was definitely not possible to protect software, mathematical formulas and algorithms by patents in europe. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 that the av7110 still is > > probably the most widely used hardware! 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. ;-) > > > 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. Progress on this soon; my DVB-CI card has arrived :) -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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. > 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. There already are plenty available under GPL. But you might get problems with the patent if you do not have enough money to defend yourself against (currently actually still) illegal software patents. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 hardware! 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. ;-) > 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. 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. Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 device driver code and maybe also the API > has to be changed a lot to make that work properly. I am just saying > that it has nothing to do with the conversion as such. There is no > remuxing going on (at the most you can call it demuxing). The > conversion just cuts the TS in pieces to send it over the debi port. "it is actually demuxing and PES packaging" is what I said two mails ago. I acknowledge that the conversion as such is not the problem. IMHO the problem is the implementation of the conversion. I fail to see why an API change would be necessary to fix this. Well, maybe the problem would be simplified if one could write TS to the video device, but I think the root of the problem is in the implementation of av7110_ipack_instant_repack(), plus some locking bugs. My understanding of this code is very limited, but what I think is should do is - accept TS packets - write PES packets to the same ring buffer that would be used for PES playback so that the remainder of the driver wouldn't have to know the difference between TS and PES playback. I don't see the reason why the TS -> PES conversion cannot be made to work in non-blocking mode. (Another TS playback issue which indeed cannot be solved without API change is section filtering. But that's not what this discussion is about.) Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 driver version / hardware revision ect. and implemented > hardware dependend stuff into the application. > > In this special case an API is a kind of software stuff to simplify > coding and that a developer of an application must have understanding > in DVB / Linux but not Driver Coding So if you started someday somehow > a development of TS Playback capabilities via the dvr device without > having real support for this on the hardware side - you should fix > this. > Otherwise take this feature away, and be happy with postings and > claims over much applications no longer working. > > Am i totally wrong ? :) IMHO the situation is comparable to ALSA. I.e. there should be a standard library to handle format conversion in userspace according to hardware capabilites. IIRC there also have been similar discussions about format conversion in kernel space for v4l2. The purpose of an API is to make porting software easier. It doesn't matter if emulation of non-existant hardware features is done in kernel or userspace. What matters is that you don't have to write that code yourself, but can use a library. But like I already said, if someone fixes the driver properly it's OK with me. Let's not turn this into a religious debate. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 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 driver version / hardware revision ect. and implemented hardware dependend > stuff into the application. > > In this special case an API is a kind of software stuff to simplify coding and that > a developer of an application must have understanding in DVB / Linux but not Driver > Coding > So if you started someday somehow a development of TS Playback capabilities via the > dvr device without having real support for this on the hardware side - you should > fix this. > Otherwise take this feature away, and be happy with postings and claims over much > applications no longer working. > > Am i totally wrong ? :) > > cu > mws Add. I missed something - of course all it is depending on open source and nobody can be taken under pressure to fix it. But it would satisfy lots of people if it would be fixed, cu mws -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 code should be dropped rather > > > than attempted to fix. Remuxing should be done in user space. VDR > > > does the right thing. > > > > calling the PES unpacking process a 'remuxing' is kind of flattered, > > Right, it is actually demuxing and PES packaging. > > > not? Forcing everybody to misuse the lowlevel-API instead of highlevel > > access just because the av711x driver is broken has the unlovely side > > effect that on well-designed hardware that can eat PS and TS directly > > the code will still do all the protocol handling and bit-twiddling on > > the host processor, the dedicated hardware will run idle. > > I don't know what you mean. Usually you advocate tiny drivers that > just make the capabilites of the hardware available to userspace. > > 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. > > > The Avia processor and all modern STB CPUs can process multiplexed > > streams directly. > > Some of the cheaper variants of "modern" STB chips don't process > TS from RAM, just from the frontend inputs. > > > Johannes > > 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 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 driver version / hardware revision ect. and implemented hardware dependend stuff into the application. In this special case an API is a kind of software stuff to simplify coding and that a developer of an application must have understanding in DVB / Linux but not Driver Coding So if you started someday somehow a development of TS Playback capabilities via the dvr device without having real support for this on the hardware side - you should fix this. Otherwise take this feature away, and be happy with postings and claims over much applications no longer working. Am i totally wrong ? :) cu mws -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 the old AVPES conversion and it > is done either way whether you are using PES or TS for playback or > not. It is just the format that the is send via the debi interface and > is more restricted than normal PES. The only difference to AVPES is > that you don't need to change PES that have a certain size (<=2048 > bytes). For larger PES you will also get a conversion. For smaller PES > you will waste some space. The problem with TS playback is the dvr > interface which won't allow you a nonblocking write because you can`t > give the device a feedback via the various kernel layers. This is a > relic of the Nokia API. If you would allow TS input via the video > device there should be no problem, but then you don't have the section > filter mechanism and would have to add calls for setting PIDs. 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. If someone comes forward and fixes it so it is actually usable, I'll shut up. But I don't see the point of keeping a broken implementation around as a trap for someone to fall into. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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... 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 hardware! 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 And don't say "use a budget card and do replay over the graphics card" - the average user wants to insert *ONE* card into his PC and use that one for recording AND replay. Besides: replay over graphics card means MPEG decoding in software, which in turn requires more CPU power... Also: are there any budget cards already that have drivers that support CAMs? I have to admit that I don't know that. So, what about just fixing the av7110 driver? (nope, let's design cheap and cool hardware instead - evil things need to get changed, not worked around - ;) we'll keep you posted... Does this mean convergence(?) will be producing a DVB-S/C/T PCI card that we are right now in the process of founding a design house indepependent of convergence but will definitely cooperate whenever it makes sense. Prototypes of a terrestrial and satellite receiver are built and in the verification stage. Right now it's too early for details (but you know our claim - it's going to be the best and cheapest piece of hardware you can get for money now and tomorrow, trust us and be a little patient for a few more days - ;). Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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. The recording format of VDR _is_ PES (or is it PS - sometimes I'm confused with these terms, so if in doubt, just look at an actual VDR recording), and that's what it sends to the output device. It won't use two different formats or go to TS as recording format. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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, 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 hardware! 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 > > And don't say "use a budget card and do replay over the graphics card" > > - the > > average user wants to insert *ONE* card into his PC and use that one for > > recording AND replay. Besides: replay over graphics card means MPEG > > decoding > > in software, which in turn requires more CPU power... Also: are there any > > budget cards already that have drivers that support CAMs? I have to > > admit that > > I don't know that. > > > > So, what about just fixing the av7110 driver? > > (nope, let's design cheap and cool hardware instead - evil things need > to get changed, not worked around - ;) > we'll keep you posted... Does this mean convergence(?) will be producing a DVB-S/C/T PCI card that - can deliver the full TS - can do (PES-) MPEG decoding in hardware (the format VDR currently uses) - supports CAMs through the LL interface - has a fullscreen OSD with at least 256 colors - has a builtin AC3 output port - has A/V and RGB output (others?) - does not require any firmware (or at least no "closed source FW") - is _really_stable_ - did I forget anything? If so, I'd buy 3 right away! ;-) Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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. Remuxing should be done in user space. VDR > > does the right thing. > > calling the PES unpacking process a 'remuxing' is kind of flattered, Right, it is actually demuxing and PES packaging. > not? Forcing everybody to misuse the lowlevel-API instead of highlevel > access just because the av711x driver is broken has the unlovely side > effect that on well-designed hardware that can eat PS and TS directly > the code will still do all the protocol handling and bit-twiddling on > the host processor, the dedicated hardware will run idle. I don't know what you mean. Usually you advocate tiny drivers that just make the capabilites of the hardware available to userspace. 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. > The Avia processor and all modern STB CPUs can process multiplexed > streams directly. Some of the cheaper variants of "modern" STB chips don't process TS from RAM, just from the frontend inputs. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 for disaster -- the dvr playback code in the av7110 is seriously b0rked. Apart from the bug you found, the dvr device does not support non-blocking writes, and if you try to use multiple threads and do video ioctls from one thread while another thread blocks in dvr write() your machine will lock up... The output from dmesg after Oopsing is : bad: scheduling while atomic! Call Trace: Just for the record, this is not an Oops, just an indication that the driver is buggy. 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 dropped rather than attempted to fix. Remuxing should be done in user space. VDR does the right thing. 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, 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 hardware! 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 And don't say "use a budget card and do replay over the graphics card" - the average user wants to insert *ONE* card into his PC and use that one for recording AND replay. Besides: replay over graphics card means MPEG decoding in software, which in turn requires more CPU power... Also: are there any budget cards already that have drivers that support CAMs? I have to admit that I don't know that. So, what about just fixing the av7110 driver? (nope, let's design cheap and cool hardware instead - evil things need to get changed, not worked around - ;) we'll keep you posted... Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 for disaster -- the dvr playback code in the av7110 > > is seriously b0rked. Apart from the bug you found, the dvr device > > does not support non-blocking writes, and if you try to use multiple > > threads and do video ioctls from one thread while another thread > > blocks in dvr write() your machine will lock up... > > > > > The output from dmesg after Oopsing is : > > > > > > bad: scheduling while atomic! Call Trace: > > > > > > Just for the record, this is not an Oops, just an indication that the > > driver is buggy. > > > > > 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 dropped rather > > than attempted to fix. Remuxing should be done in user space. VDR > > does the right thing. > > 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, 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 hardware! 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 And don't say "use a budget card and do replay over the graphics card" - the average user wants to insert *ONE* card into his PC and use that one for recording AND replay. Besides: replay over graphics card means MPEG decoding in software, which in turn requires more CPU power... Also: are there any budget cards already that have drivers that support CAMs? I have to admit that I don't know that. So, what about just fixing the av7110 driver? SCNR Klaus > ...has the unlovely side > effect that on well-designed hardware that can eat PS and TS directly > the code will still do all the protocol handling and bit-twiddling on > the host processor, the dedicated hardware will run idle. > > The Avia processor and all modern STB CPUs can process multiplexed > streams directly. > > Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 av7110 is seriously b0rked. Apart from the bug you found, the dvr device does not support non-blocking writes, and if you try to use multiple threads and do video ioctls from one thread while another thread blocks in dvr write() your machine will lock up... > The output from dmesg after Oopsing is : > > bad: scheduling while atomic! Call Trace: Just for the record, this is not an Oops, just an indication that the driver is buggy. > 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 dropped rather than attempted to fix. Remuxing should be done in user space. VDR does the right thing. 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 has the unlovely side effect that on well-designed hardware that can eat PS and TS directly the code will still do all the protocol handling and bit-twiddling on the host processor, the dedicated hardware will run idle. The Avia processor and all modern STB CPUs can process multiplexed streams directly. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
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 dropped > rather than attempted to fix. > Remuxing should be done in user space. VDR does the right thing. > > Johannes > Thx for your fast answer. Maybe also just for your understanding the ts was recorded from the dvr device and it contains 1 VideoPES pid 0x00ff 1 AudioPES pid 0x0100 1 AC3 PES pid 0x0101 muxed as TS via demux with output DMX_OUT_TS_TAP. I was wondering about the fact that the av7110 hw is able to do a replay via the dvr device with test_dvr_play.c even i was told that av7110 isn't able to playback a ts. as my real program is mainly running on settop boxes i do not really care about the user space remuxing problem - it just would have been nice to be able to test features on pc first. thx again mws -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel OOPS
[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 from the bug you found, the dvr device does not support non-blocking writes, and if you try to use multiple threads and do video ioctls from one thread while another thread blocks in dvr write() your machine will lock up... > The output from dmesg after Oopsing is : > > bad: scheduling while atomic! > Call Trace: Just for the record, this is not an Oops, just an indication that the driver is buggy. > 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 dropped rather than attempted to fix. Remuxing should be done in user space. VDR does the right thing. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
> 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 exported where it surely should not. > Enabling CONFIG_MODVERSIONS causes even more troubles, just browse the > LinuxDVB mailing list archives, you'll find hundrets of mails where > people failed to install standalone drivers just because they/their > friends/their distributor didn't managed it to install matching kernel > source, kernel config and kernel image. It is _not possible_ to compile external modules without having installed a matching kernel source/image. Period. Perhaps they work sometimes or even most times, by accident. But in CIPE I've stumbled over structures which shift their members around depending on both obscure configuration options and compiler versions. Flip a certain config switch, or use a different version of gcc than the kernel was compiled with, and the module causes a 100% reproducible kernel panic - I've seen (and found the reason for) instances of both. Without at least the complete kernel include tree from _exactly the kernel build_ under which the module will be running, you have absolutely no chance of compiling a reliable module. I wonder how many of the OOPS reports found on this list are in fact due to this mismatch. Olaf -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
I forgot to thank you all for your help :) Rafael -- www.pinguin-and-knights.org 2003 by Lontro pgp0.pgp Description: signature
[linux-dvb] Re: Kernel oops with ttusb_dec
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 lot of compiler directives in the > > driver due to differences between kernels 2.4 and 2.6, and it's beginning > > to obfuscate things. Then again, I don't suppose it will make things > > much worse - let me know if it works ;) > > Yep, compiles fine with some small warnings and runs well: > > ttusb_dec.c:1246:10: Warnung: #warning "CRC disabled" > ttusb_dec.c: In function `ttusb_dec_boot_dsp': > ttusb_dec.c:1191: Warnung: unused variable `crc32_csum' > ttusb_dec.c:1191: Warnung: unused variable `crc32_check' > ttusb_dec.c:1191: Warnung: unused variable `tmp' Thanks. I've commited the change to cvs, with a little extra to remove those warnings. Cheers, Alex -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
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 between kernels 2.4 and 2.6, and it's beginning to obfuscate > things. Then again, I don't suppose it will make things much worse - let > me know if it works ;) Yep, compiles fine with some small warnings and runs well: ttusb_dec.c:1246:10: Warnung: #warning "CRC disabled" ttusb_dec.c: In function `ttusb_dec_boot_dsp': ttusb_dec.c:1191: Warnung: unused variable `crc32_csum' ttusb_dec.c:1191: Warnung: unused variable `crc32_check' ttusb_dec.c:1191: Warnung: unused variable `tmp' Rafael -- www.pinguin-and-knights.org 2003 by Lontro pgp0.pgp Description: signature
[linux-dvb] Re: Kernel oops with ttusb_dec
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 the availability of that function? I'm doing > > that in the latest development of CIPE (which could perhaps have > > avoided the error in the first place :-) > > > > If the checking is really optional, wrapping it in > > > > #if defined(CONFIG_CRC32) || defined(CONFIG_CRC32_MODULE) > > ... > > #else > > #warning "CRC checking not available" > > #endif > > Excuse me, I am not a programmer, where should I drop these lines? At line > 1235 or at the top? > > I will make test to see if it works. 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 between kernels 2.4 and 2.6, and it's beginning to obfuscate things. Then again, I don't suppose it will make things much worse - let me know if it works ;) Cheers, Alex -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
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 latest development of CIPE (which could perhaps have > avoided the error in the first place :-) > > If the checking is really optional, wrapping it in > > #if defined(CONFIG_CRC32) || defined(CONFIG_CRC32_MODULE) > ... > #else > #warning "CRC checking not available" > #endif Excuse me, I am not a programmer, where should I drop these lines? At line 1235 or at the top? I will make test to see if it works. Regards Rafael -- www.pinguin-and-knights.org 2003 by Lontro pgp0.pgp Description: signature
[linux-dvb] Re: Kernel oops with ttusb_dec
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> edx; dea0455f <[ttusb_dec]dec3000s_frontend_info+bf/c0> esi; ddcfde18 <[snd-mixer-oss].data.end+eaf2141/ec4c389> edi; ddcfde20 <[snd-mixer-oss].data.end+eaf2149/ec4c389> esp; ddcfcdb4 <[snd-mixer-oss].data.end+eaf10dd/ec4c389> No, cipcb isn't needed. It should be using the crc32 function from the main kernel. If it's trying to use the one in cipcb, which takes very different arguments, it's no wonder there is a problem. I'm unsure of the right way to fix this. Suggestions anyone? it's probably safer to use crc32_le() or crc32_be(), depends on which one exactly you need. 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 module was loaded by the modprobe dependency mechanism by virtue of it defining a symbol called "crc32". modprobe shouldn't know of that symbol in the CIPE module at all, because it's not meant to be exported. There are some definitions in the module subsystem which deal with the exporting of symbols. I suspect either CIPE or DVB (or both of them) needs a fix in this area. Anyone here knows more? Use a recent kernel, there crc32(), crc32_le() and crc32_be() are implemented as library functions. Another data point: crc32 isn't available in 2.4.21 at all, so it's apparently(?) not a kernel configuration problem. But shouldn't that mean that the ttusb_dec driver wouldn't run at all under that kernel? Ah, by the way, this could perhaps have been avoided completely if the kernel was compiled with CONFIG_MODVERSIONS enabled (because then the crc32 function, if properly exported, would have gotten a name which depends on its arguments). This not being on unconditionally is one of my pet peeves with Linux and distros, because of the many CIPE bugreports I get which are due to just version incompatibilities. Enabling CONFIG_MODVERSIONS causes even more troubles, just browse the LinuxDVB mailing list archives, you'll find hundrets of mails where people failed to install standalone drivers just because they/their friends/their distributor didn't managed it to install matching kernel source, kernel config and kernel image. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
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 module was loaded by the modprobe dependency mechanism by virtue > of it defining a symbol called "crc32". > > modprobe shouldn't know of that symbol in the CIPE module at all, > because it's not meant to be exported. There are some definitions in > the module subsystem which deal with the exporting of symbols. I > suspect either CIPE or DVB (or both of them) needs a fix in this area. > Anyone here knows more? Correct, I didn't load cipe manually, I load the modules by insmod normally and since ttusb_dec claimed for crc32 (I didn't know which module would sadisfy this) I gave this module to modprobes control. > Another data point: crc32 isn't available in 2.4.21 at all, so it's > apparently(?) not a kernel configuration problem. But shouldn't that > mean that the ttusb_dec driver wouldn't run at all under that kernel? > [*] unless SUSE has really screwed it up and started a CIPE process by > default, but this is rather implausible as it needs nontrivial > configuration, and loading the module without the ciped process just > wastes memory. No, they don't Rafael -- www.pinguin-and-knights.org 2003 by Lontro pgp0.pgp Description: signature
[linux-dvb] Re: Kernel oops with ttusb_dec
> 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 requirement > for the next tarball release of the drivers. Do a compile time test on the availability of that function? I'm doing that in the latest development of CIPE (which could perhaps have avoided the error in the first place :-) If the checking is really optional, wrapping it in #if defined(CONFIG_CRC32) || defined(CONFIG_CRC32_MODULE) ... #else #warning "CRC checking not available" #endif should be sufficient. Olaf -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
[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; dea0455f <[ttusb_dec]dec3000s_frontend_info+bf/c0> > > >>esi; ddcfde18 <[snd-mixer-oss].data.end+eaf2141/ec4c389> > > >>edi; ddcfde20 <[snd-mixer-oss].data.end+eaf2149/ec4c389> > > >>esp; ddcfcdb4 <[snd-mixer-oss].data.end+eaf10dd/ec4c389> > No, cipcb isn't needed. It should be using the crc32 function from the main > kernel. If it's trying to use the one in cipcb, which takes very different > arguments, it's no wonder there is a problem. > > I'm unsure of the right way to fix this. Suggestions anyone? 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 module was loaded by the modprobe dependency mechanism by virtue of it defining a symbol called "crc32". modprobe shouldn't know of that symbol in the CIPE module at all, because it's not meant to be exported. There are some definitions in the module subsystem which deal with the exporting of symbols. I suspect either CIPE or DVB (or both of them) needs a fix in this area. Anyone here knows more? Another data point: crc32 isn't available in 2.4.21 at all, so it's apparently(?) not a kernel configuration problem. But shouldn't that mean that the ttusb_dec driver wouldn't run at all under that kernel? Ah, by the way, this could perhaps have been avoided completely if the kernel was compiled with CONFIG_MODVERSIONS enabled (because then the crc32 function, if properly exported, would have gotten a name which depends on its arguments). This not being on unconditionally is one of my pet peeves with Linux and distros, because of the many CIPE bugreports I get which are due to just version incompatibilities. Olaf [*] unless SUSE has really screwed it up and started a CIPE process by default, but this is rather implausible as it needs nontrivial configuration, and loading the module without the ciped process just wastes memory. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
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 first appears in kernel 2.4.22.
> For a quick fix, cut these lines out of ttusb_dec.c:ttusb_dec_boot_dsp() :
>
> crc32_csum = crc32(~0L, firmware, 56) ^ ~0L;
> memcpy(&tmp, &firmware[56], 4);
> crc32_check = htonl(tmp);
> if (crc32_csum != crc32_check) {
> printk("%s: crc32 check of DSP code failed (calculated "
>"0x%08x != 0x%08x in file), file invalid.\n",
> __FUNCTION__, crc32_csum, crc32_check);
> return -1;
> }
>
>
> 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 requirement for the
> next tarball release of the drivers.
>
> Cheers,
> Alex
--
www.pinguin-and-knights.org
2003 by Lontro
pgp0.pgp
Description: signature
[linux-dvb] Re: Kernel oops with ttusb_dec
> 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 ttusb_dec.c:ttusb_dec_boot_dsp() :
crc32_csum = crc32(~0L, firmware, 56) ^ ~0L;
memcpy(&tmp, &firmware[56], 4);
crc32_check = htonl(tmp);
if (crc32_csum != crc32_check) {
printk("%s: crc32 check of DSP code failed (calculated "
"0x%08x != 0x%08x in file), file invalid.\n",
__FUNCTION__, crc32_csum, crc32_check);
return -1;
}
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 requirement for the next
tarball release of the drivers.
Cheers,
Alex
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
Am Sonntag, 18. Januar 2004 23:13 schrieb Alex Woods: > No, cipcb isn't needed. It should be using the crc32 function from the > main kernel. If it's trying to use the one in cipcb, which takes very > different arguments, it's no wonder there is a problem. > > I'm unsure of the right way to fix this. Suggestions anyone? Does this mean that the kernel from SuSE has no internal crc32 functions? As a hint I can give the output gcc and insmod give: gcc: gcc -I/data/videoediting/dvb/dvb-kernel/build-2.4/include -D__KERNEL__ -I/usr/ sr c/linux-2.4.21-166-include/athlon/include -Wall -Wstrict-prototypes -Wno-trigra phs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -fno-unit-at-a-tim e -pipe -msoft-float -mpreferred-stack-boundary=2 -march=athlon -DMODULE -DMODVE RSIONS -include /usr/src/linux-2.4.21-166-include/athlon/include/linux/ modversio ns.h -MD -I ../linux/include -I . -DCONFIG_DVB_AV7110_OSD -nostdinc -iwithprefix include -DKBUILD_BASENAME=ttusb_dec -c -o ttusb_dec.o ttusb_dec.c ttusb_dec.c: In function `ttusb_dec_boot_dsp': ttusb_dec.c:1235: Warnung: implicit declaration of function `crc32' < insmod: Thor:/data/videoediting/dvb/dvb-kernel/build-2.4 # insmod dvb-core.o Thor:/data/videoediting/dvb/dvb-kernel/build-2.4 # insmod ttusb_dec.o ttusb_dec.o: unresolved symbol crc32 The only module which fullfills the symbol crc32 is cipcb. -- www.pinguin-and-knights.org 2003 by Lontro pgp0.pgp Description: signature
[linux-dvb] Re: Kernel oops with ttusb_dec
> > 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 <[ttusb_dec]dsp_dec2000t+0/69100> > >>edx; dea0455f <[ttusb_dec]dec3000s_frontend_info+bf/c0> > >>esi; ddcfde18 <[snd-mixer-oss].data.end+eaf2141/ec4c389> > >>edi; ddcfde20 <[snd-mixer-oss].data.end+eaf2149/ec4c389> > >>esp; ddcfcdb4 <[snd-mixer-oss].data.end+eaf10dd/ec4c389> No, cipcb isn't needed. It should be using the crc32 function from the main kernel. If it's trying to use the one in cipcb, which takes very different arguments, it's no wonder there is a problem. I'm unsure of the right way to fix this. Suggestions anyone? Cheers, Alex -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
[linux-dvb] Re: Kernel oops with ttusb_dec
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) -k /proc/ksyms (default) -l /proc/modules (default) -o /data/videoediting/dvb/dvb-kernel/build-2.4 -o /lib/ modules/2.4.21-166-athlon (specified) -m /boot/System.map-2.4.21-166-athlon (default) Jan 18 21:27:55 Thor kernel: Unable to handle kernel paging request at virtual address Jan 18 21:27:55 Thor kernel: dde5ba82 Jan 18 21:27:55 Thor kernel: *pde = 4063 Jan 18 21:27:55 Thor kernel: Oops: 2.4.21-166-athlon #1 Thu Dec 18 18:24:05 UTC 2003 Jan 18 21:27:55 Thor kernel: CPU:0 Jan 18 21:27:55 Thor kernel: EIP:0010: [ieee1394:ieee1394_procfs_entry_R67e23c68+381082682/272800178]Tainted: PF Jan 18 21:27:55 Thor kernel: EIP:0010:[]Tainted: PF Using defaults from ksymoops -t elf32-i386 -a i386 Jan 18 21:27:55 Thor kernel: EFLAGS: 00010286 Jan 18 21:27:55 Thor kernel: eax: dea04560 ebx: ecx: edx: dea0455f Jan 18 21:27:55 Thor kernel: esi: ddcfde18 edi: ddcfde20 ebp: esp: ddcfcdb4 Jan 18 21:27:55 Thor kernel: ds: 0018 es: 0018 ss: 0018 Jan 18 21:27:55 Thor kernel: Process insmod.old (pid: 3413, stackpage=ddcfd000) Jan 18 21:27:55 Thor kernel: Stack: dd93 dea02091 dea04560 0038 61757165 6f74206c 73797320 Jan 18 21:27:55 Thor kernel:000690fc dea04560 230a2e73 4520230a 61686361 72657375 63657320 6e6f6974 Jan 18 21:27:55 Thor kernel:6e616320 65766f20 64697272 68742065 6f662065 776f6c6c 20676e69 61666564 Jan 18 21:27:55 Thor kernel: Call Trace: [ieee1394:ieee1394_procfs_entry_R67e23c68+393298505/260584355] (08) [ieee1394:ieee1394_procfs_entry_R67e23c68+393307928/260574932] (24) [ieee1394:ieee1394_procfs_entry_R67e23c68+393307928/260574932] (2628) Jan 18 21:27:55 Thor kernel: Call Trace: [] (08) [] (24) [] (2628) Jan 18 21:27:55 Thor kernel: [] (16) [] (32) [] (40) [] (52) Jan 18 21:27:55 Thor kernel: [] (40) [] (36) [] (08) [] (16) Jan 18 21:27:55 Thor kernel: [] (140) [] (32) [] (16) [] (16) Jan 18 21:27:55 Thor kernel: [] (12) [] (12) [] (12) [] (12) Jan 18 21:27:55 Thor kernel: [] (56) [] (04) [] (04) [] (12) Jan 18 21:27:55 Thor kernel: [] (08) [] (16) [] (20) [] (16) Jan 18 21:27:55 Thor kernel: [] (76) [] (68) [] (72) [] (16) Jan 18 21:27:55 Thor kernel: [] (72) [] (52) [] (24) [] (52) Jan 18 21:27:55 Thor kernel: [] (12) [] (40) [] (56) [] (72) Jan 18 21:27:55 Thor kernel: [] (64) [] (20) [] (180) [] (12) Jan 18 21:27:55 Thor kernel: [] (48) [] (40) [] (12) [] (04) Jan 18 21:27:55 Thor kernel: [] (08) [] (12) [] (12) [] (08) Jan 18 21:27:55 Thor kernel: [] (20) [] (20) [] (08) [] (08) Jan 18 21:27:55 Thor kernel: [] (04) [] (08) [] (08) [] (04) Jan 18 21:27:55 Thor kernel: [] (04) [] (24) [] (04) [] (16) Jan 18 21:27:55 Thor kernel: [] (04) [] (12) [] (48) [] (104) Jan 18 21:27:55 Thor kernel: [] (60) Jan 18 21:27:55 Thor kernel: Code: 8a 01 41 31 d8 c1 eb 08 25 ff 00 00 00 33 1c 85 40 dd e5 dd >>EIP; dde5ba82 <[cipcb]crc32+12/30> <= >>eax; dea04560 <[ttusb_dec]dsp_dec2000t+0/69100> >>edx; dea0455f <[ttusb_dec]dec3000s_frontend_info+bf/c0> >>esi; ddcfde18 <[snd-mixer-oss].data.end+eaf2141/ec4c389> >>edi; ddcfde20 <[snd-mixer-oss].data.end+eaf2149/ec4c389> >>esp; ddcfcdb4 <[snd-mixer-oss].data.end+eaf10dd/ec4c389> Trace; dea02091 <[ttusb_dec]ttusb_dec_boot_dsp+e1/3a0> Trace; dea04560 <[ttusb_dec]dsp_dec2000t+0/69100> Trace; dea04560 <[ttusb_dec]dsp_dec2000t+0/69100> Trace; ca82524a <[nvidia]__nvsym01580+3a/70> Trace; ca82524a <[nvidia]__nvsym01580+3a/70> Trace; ca844034 <[nvidia]__nvsym01575+28/34> Trace; ca8252c9 <[nvidia]__nvsym01540+49/90> Trace; ca8440fb <[nvidia]__nvsym01480+2b/34> Trace; ca824bf4 <[nvidia]__nvsym01583+58/68> Trace; ca824b3b <[nvidia]__nvsym01528+27/48> Trace; ca83ea77 <[nvidia]__nvsym02561+4f/6c> Trace; ca83ea28 <[nvidia]__nvsym02561+0/6c> Trace; ca83ea77 <[nvidia]__nvsym02561+4f/6c> Trace; ca84947a <[nvidia]__nvsym00803+16/1c> Trace; ca938bb1 <[nvidia]__nvsym05234+1d/278> Trace; ca833701 <[nvidia]__nvsym01822+19/f4> Trace; ca8493ea <[nvidia]__nvsym00830+12/18> Trace; ca830f45 <[nvidia]__nvsym00805+11/228> Trace; ca8493ea <[nvidia]__nvsym00830+12/18> Trace; ca939657 <[nvidia]__nvsym00479+503/530> Trace; ca818bdd <[nvidia]__nvsym00727+31/38> Trace; ca983ee0 <[nvidia]nv_linux_devices+0/5a0> Trace; ca983ee0 <[nvidia]nv_linux_devices+0/5a0> Trace; ca818b9e <[nvidia]__nvsym00714+86/94> Trace; ca983ee0 <[nvidia]nv_linux_devices+0/5a0> Trace; ca818add <[nvidia]__nvsym00795+31/50> Trace; ca81a194 <[nvidia]rm_isr+10/14> Trace; ca80193e <[nvidia]nv_kern_isr+1d/7d> Trace; c1b1c264 <[reiserfs]search_by_key+2f4/380> Trace; c1b1c4f6 <[reiserfs]search_for_position_by_key+206/480> Trace; ca82524a
[linux-dvb] Re: Kernel oops with ttusb_dec
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: cipcb: CIPE driver vers 1.5.4 (c) Olaf Titz > 1996-2000, 100 channels, debug=0 > Jan 18 20:12:39 Thor kernel: cipcb: rtnl_lock() at ../cipe/device.c:627 > Jan 18 20:12:39 Thor kernel: cipcb: rtnl_unlock() at ../cipe/device.c:629 > Jan 18 20:12:41 Thor kernel: usb.c: registered new driver ttusb-dec > Jan 18 20:12:41 Thor kernel: ttusb_dec: Firmware 1.11de > Jan 18 20:12:41 Thor kernel: Unable to handle kernel paging request at > virtual address > Jan 18 20:12:41 Thor kernel: printing eip: > Jan 18 20:12:41 Thor kernel: dc3b3a82 > Jan 18 20:12:41 Thor kernel: *pde = 4063 > Jan 18 20:12:41 Thor kernel: Oops: 2.4.21-166-athlon #1 Thu Dec 18 > 18:24:05 UTC 2003 > Jan 18 20:12:41 Thor kernel: CPU:0 > Jan 18 20:12:41 Thor kernel: EIP:0010: > [ieee1394:ieee1394_procfs_entry_R67e23c68+394026042/300751282]Tainted: > PF Jan 18 20:12:41 Thor kernel: EIP:0010:[]Tainted: PF > Jan 18 20:12:41 Thor kernel: EFLAGS: 00210282 > Jan 18 20:12:41 Thor kernel: eax: dca04520 ebx: ecx: > edx: dca0451f > Jan 18 20:12:41 Thor kernel: esi: db241e18 edi: db241e20 ebp: > esp: db240db8 > Jan 18 20:12:41 Thor kernel: ds: 0018 es: 0018 ss: 0018 > Jan 18 20:12:41 Thor kernel: Process insmod.old (pid: 4817, > stackpage=db241000) > Jan 18 20:12:41 Thor kernel: Stack: dc458000 dca02079 dca04520 > 0038 > Jan 18 20:12:41 Thor kernel:000690fc 6100 > > Jan 18 20:12:41 Thor kernel: > > Jan 18 20:12:41 Thor kernel: Call Trace: > [ieee1394:ieee1394_procfs_entry_R67e23c68+400638513/294138811] (08) > [ieee1394:ieee1394_procfs_entry_R67e23c6 > 8+400647896/294129428] (3276) [__alloc_pages+98/656] (16) > Jan 18 20:12:41 Thor kernel: Call Trace: [] (08) > [] (3276) [] (16) > Jan 18 20:12:41 Thor kernel: [filemap_nopage+487/528] (36) [lru_cache_add > +99/112] (40) [__alloc_pages+98/656] (16) [filemap_nopage+487/528] (36) > Jan 18 20:12:41 Thor kernel: [] (36) [] (40) > [] (16) [] (36) > Jan 18 20:12:41 Thor kernel: [lru_cache_add+99/112] (12) [do_no_page > +738/864] (20) [do_page_fault+435/1456] (44) [handle_mm_fault+218/512] (88) > Jan 18 20:12:41 Thor kernel: [] (12) [] (20) > [] (44) [] (88) > Jan 18 20:12:41 Thor kernel: [__vma_link+86/192] (48) > [keybdev:__insmod_keybdev_O/lib/modules/2.4.21-166-athlon/kernel/dri > +4289955292/96] (24) [keybdev:__i > nsmod_keybdev_O/lib/modules/2.4.21-166-athlon/kernel/dri+4289959821/96] > (24) [__switch_to+203/272] (28) > Jan 18 20:12:41 Thor kernel: [] (48) [] (24) > [] (24) [] (28) > Jan 18 20:12:41 Thor kernel: [do_schedule+357/752] (12) [do_schedule > +368/752] (40) [schedule_timeout+113/192] (56) > [usb-uhci:uhci_device_operations+3740297 > 6/21212104] (136) > Jan 18 20:12:41 Thor kernel: [] (12) [] (40) > [] (56) [] (136) > Jan 18 20:12:41 Thor kernel: [copy_data_to_cbuf+84/96] (20) [kwrite_buf > +92/144] (180) [vprintk+334/352] (12) > [ieee1394:ieee1394_procfs_entry_R67e23c68+4006 > 46587/294130737] (48) > Jan 18 20:12:41 Thor kernel: [] (20) [] (180) > [] (12) [] (48) > Jan 18 20:12:41 Thor kernel: [ieee1394:ieee1394_procfs_entry_R67e23c68 > +400639308/294138016] (40) [ieee1394:ieee1394_procfs_entry_R67e23c68 > +400643041/294134 > 283] (12) [ieee1394:ieee1394_procfs_entry_R67e23c68+401078252/293699072] > (04) [ieee1394:ieee1394_procfs_entry_R67e23c68+401078360/293698964] (08) > Jan 18 20:12:41 Thor kernel: [] (40) [] (12) > [] (04) [] (08) > Jan 18 20:12:41 Thor kernel: [usb-uhci:uhci_device_operations > +37400910/21214170] (12) [ieee1394:ieee1394_procfs_entry_R67e23c68 > +401078252/293699072] (12) [ > ieee1394:ieee1394_procfs_entry_R67e23c68+401078328/293698996] (08) > [usb-uhci:uhci_device_operations+37460136/21154944] (20) > Jan 18 20:12:41 Thor kernel: [] (12) [] (12) > [] (08) [] (20) > Jan 18 20:12:41 Thor kernel: [usb-uhci:uhci_device_operations > +37400131/21214949] (20) > [usb-uhci:uhci_device_operations+37400082/21214998] (08) [call_do_IRQ > +5/13] (08) [usb-uhci:uhci_device_operations+37461576/21153504] (04) > Jan 18 20:12:41 Thor kernel: [] (20) [] (08) > [] (08) [] (04) > Jan 18 20:12:41 Thor kernel: [usb-uhci:uhci_device_operations > +37397630/21217450] (08) [ieee1394:ieee1394_procfs_entry_R67e23c68 > +401078328/293698996] (08) [usb-uhci:uhci_device_operations > +37397537/21217543] (04) > [usb-uhci:uhci_device_operations+37447336/21167744] (04) > Jan 18 20:12:41 Thor kernel: [] (08) [] (08) > [] (04) [] (04) > Jan 18 20:12:41 Thor kernel: [ieee1394:ieee1394_procfs_entry_R67e23c68 > +40064552
[linux-dvb] Re: Kernel Oops after setting the same PID for PES and section filter
> 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 contents of the feed_list). It doesn't matter whether there is a section filter involved or not. Two or more pes filters on the same pid (e.g. with different output parameters) do trigger the same bug. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
