[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ALSA 1.0.15 update test kernels available



On Thu, 2007-10-25 at 17:33 -0400, Chuck Ebbert wrote:
> We are considering adding ALSA 1.0.15 to the Fedora 8 release. This
> would get us up-to-date with the latest audio drivers and fix many
> problems with audio drivers not working, or only partially working.
> 
> Test kernels for i686 and x86_64 are available at:
> 
>   http://people.redhat.com/cebbert/kernels/F8/
> 
> Also, kernel 2.6.23.1-36 has the update and is now building.
> 
> It would be very helpful if people would test these kernels and reply
> to this message with their experiences, so we can see if this update
> causes any problems.

It looks like you've introduced an unintentional side-effect in this
latest test kernel, that prevented testing, and means that I think it
shouldn't be considered as the final F8 candidate kernel (Jesse hinted
that this might be the case otherwise).

Specifically, either nash is unhappy, you changed the kernel config, or
some other module is busted - I'll start thinking about what - but you
end up with a modprobe fork bomb taking down my machine.

Audio is at best extremely dicey on my (Nvidia HDA) and certainly not
suitable for productive use as a Linux desktop ;-)

Jon.

--- begin quote ---

        /* If modprobe needs a service that is in a module, we get a
recursive
         * loop.  Limit the number of running kmod threads to
max_threads/2 or
         * MAX_KMOD_CONCURRENT, whichever is the smaller.  A cleaner
method
         * would be to run the parents of this process, counting how
many times
         * kmod was invoked.  That would mean accessing the internals of
the
         * process tables to get the command line, proc_pid_cmdline is
static
         * and it is not worth changing the proc code just to handle
this case. 
         * KAO.
         *
         * "trace the ppid" is simple, but will fail if someone's
         * parent exits.  I think this is as good as it gets. --RR
         */
        max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
        atomic_inc(&kmod_concurrent);
        if (atomic_read(&kmod_concurrent) > max_modprobes) {
                /* We may be blaming an innocent here, but unlikely */
                if (kmod_loop_msg++ < 5)
                        printk(KERN_ERR
                               "request_module: runaway loop modprobe %s
\n",
                               module_name);
                atomic_dec(&kmod_concurrent);
                return -ENOMEM;
        }

        ret = call_usermodehelper(modprobe_path, argv, envp, 1);
        atomic_dec(&kmod_concurrent);
        return ret;



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]