From: Olaf Titz <olaf@bigred.inka.de>
To: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org
Subject: Re: [linux-dvb] Re: Kernel oops with ttusb_dec
Date: Mon, 19 Jan 2004 21:34:36 +0100 [thread overview]
Message-ID: <E1Aig6W-0006m8-00@bigred.inka.de> (raw)
In-Reply-To: <200401182213.37387.linux-dvb@giblets.org>
[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.
next parent reply other threads:[~2004-01-19 20:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ecartis-01182004203937.22827.1@mail.convergence2.de>
[not found] ` <200401182002.18784.linux-dvb@giblets.org>
[not found] ` <200401182134.12598.rafael@mondoria.de>
[not found] ` <200401182213.37387.linux-dvb@giblets.org>
2004-01-19 20:34 ` Olaf Titz [this message]
2004-01-19 21:01 ` Holger Waechtler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1Aig6W-0006m8-00@bigred.inka.de \
--to=olaf@bigred.inka.de \
--cc=linux-dvb@linuxtv.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®