Hello, marco wrote:
> Ryan Shaw wrote: > > > > > I appreciate you contributing your system information. Since you and > > the other people who have working SMP systems are using RedHat, it > > would seem that the crucial difference is RedHat's ac kernel vs. > > Debian's stock kernel. (It is not the Debian source package, since I > > also had lockups with the ALSA CVS sources.) > > > what about the kernel sources? are you using a stock kernel or did you > compile one yourself? I compiled it myself from the Debian packaged kernel source, which is just vanilla kernel.org sources organized so you can compile custom kernel image packages. > I am not using Redhat's kernel but the kernel.org sources, and I make > sure that I have a link /usr/src/linux which points to the exact kernel > sources which I want to compile the modules for. > > When building kernel modules it is essential, that the correct sources > are in place, otherwise the module doesn't know what it is linking to > and you may get random freezes crashes etc. Because the module was > built improperly. I never had random freezes, I had perfectly reproduceable freezes that in fact happened on the same line in the code every time I ran aplay. > This is why having packages for kernel modules is a dangerous kludge, > they probably only work with the debian stock kernel they were compiled > against not the smp one. You are correct, the Debian module binary packages only work with the matching precompiled kernel binary packages. But I don't use either of these. I compile my own kernels and modules, using the Debian *source packages*. Again, these are just the upsteam sources organized in such a way to make it simple to build custom Debian images. When I ran into problems with the released code as packaged in the Debian source package, I checked out the ALSA CVS sources and compiled those, again compiling against my configured kernel source tree, but had the same problems. > But if you built your own kernel and compiled the alsa sources against > this kernel, there is no reason why the driver would not work just as it > does on my machine, unless you have a hardware conflict or something > which you be interesting to debug. In fact, I reached this same conclusion two months ago, and wasted a few weeks troubleshooting all my hardware, but found no problems. > There is no reason for the developers to waste valueable time on > possible user errors instead of fixing real bugs, for which they need > to know that the user has done a ceratin number of things, such as build > the modules properly. You are convinced that there is a bug, others > probably think there is a problem with the way you are building the > modules. I don't deny that building and installing the ALSA modules is complex, and I'm sure that the majority of problems that people have are due to improper building/installation. But considering that Takashi just posted a patch which seems to have solved Andrew's problem, it seems this was a bug. I intend to try this patch myself this weekend and I will report on its results. Ryan _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
