[PlanetCCRMA] alsa unresolved symbol PDE

[Steve Arnold]

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_ptolemy-31809-1066587964-0001-2
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On 20 Sep 2003 19:04:33 -0700
Fernando Pablo Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> Steve Arnold wrote:
> > I've added a planet-ccrma kernel source ebuild to Gentoo's
> > portage tree, and it seems to build fine (I'm running it now).
> 
> I assume you do not get unresolved symbols from the kernel
> itself...
> 
> > However, I can't load the alsa drivers (alsa-driver-0.9.6),
> 
> Is this stock 0.9.6 or the Planet CCRMA 0.9.6? Not that it should
> make a difference. 
> 
> > even though they appeared to build fine as well.  I get these
> > errors on pretty much all the sound drivers:
> > 
> > insmod foo failed
> > unresolved symbol PDE
> 
[snip]

Ok, this turned out to be a kernel version issue, or more like a
"too many kernels with back-ported patches" coupled with slightly
broken detection logic in alsa's configure.in (which is now patched
in gentoo alsa ebuilds 0.9.6 and later).

The alsa devs have a bug or two on the kernel version stuff, and
they've been informed of the configure.in issue (but I'm not sure
when or how they'll handle it).

> I don't know why the acpi headers are missing, probably a problem
> in my build. 

The only thing I can think of is that somehow the rpm logic adds
that patch after the fact (so to speak).  The spec file has a
butt-load of patches in it, and I assumed that building from source
rpm (ie, => the kernel-source...i386.rpm binary package) was correct
(which I still think is valid logic), and should have produced a
complete set of kernel source.

> I guess the proper way would be to grab the kernel source rpm
> (.src.rpm, not kernel-source-xxx.i386.rpm), install it (but you
> need a redhat system for that, I guess) and execute an "rpmbuild
> -bp kernel-xxx.spec which will leave a patched and ready to build
> (sort of) kernel tree in/usr/src/redhat/BUILD/kernel-*.
> Configuration files will be in the configs directory. That could
> be tarred, I guess. 

Well, the intent of my ebuild (and this is normally the way they
work) is to grab the specified version of your kernel source:

SRC_URI="http://ccrma-www.stanford.edu/planetccrma/mirror/redhat/li
nux/planetcore/9/en/os/i386/kernel-source-${KV}.i386.rpm

The ebuild requires rpm2tgz to convert the rpm file, but I can't
really process any rpm stuff (since it's not redhat).  So it works
for now (with my acpi patch) - I'll try updating to your newer
kernel soon.  There might be a way to change your spec file to put
the acpi stuff in the source tree a little sooner, but don't sweat
it.

I do have a patch request for you though; the i2c part in your acpi
kernel is somewhat old, and doesn't include the sensor patch.  I was
wondering if you could update i2c and add the lm_sensors patches
(like the WOLK kernel does).  The latest rpm of lm_sensors in apt is
2.6.5, and recent kernels appear to need at least 2.7.0 or better.

Since the versions of i2c and lm_sensors must match, and be built
against the kernel source, this would make it simple for the users
to enable and use, rather then try and build/patch their own kernel.
You should be able to enable both as modules in the standard
binary kernel package just like anything else, or maybe build them
as rpms (like the alsa drivers).

Anyway, thanks for listening.

Steve

PS. Another really cool patch would be the frame-buffer boot logo
and/or bootsplash support.  It makes for a very distinctive boot
screen...  :)  Check out the Gentoo LiveCD for an example; I think
Knoppix does it too.

-- 
Steve Arnold    http://arnolds.dhs.org    http://www.gentoo.org

with Std.Disclaimer;                      use Std.Disclaimer;


--=_ptolemy-31809-1066587964-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/ktc7YF7AH0fUbWERAnKkAJ9gbNDuEUSV6SWtCF2WHgbCmPxKzQCfY7rQ
mLUTNNPCBwf4M/IcJ3vSRos=
=WE/x
-----END PGP SIGNATURE-----

--=_ptolemy-31809-1066587964-0001-2--