[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b1675090904071352x513510ecm8b2574859b088275@mail.gmail.com>
Date: Tue, 7 Apr 2009 14:52:59 -0600
From: "Trenton D. Adams" <trenton.d.adams@...il.com>
To: Stefan Richter <stefanr@...6.in-berlin.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Adrian Bunk <bunk@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Natalie Protasevich <protasnb@...il.com>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
Linux ACPI <linux-acpi@...r.kernel.org>,
Linux PM List <linux-pm@...ts.linux-foundation.org>,
Linux SCSI List <linux-scsi@...r.kernel.org>,
Takashi Iwai <tiwai@...e.de>
Subject: Re: 2.6.29 on MacBook 2,1 fails to reboot (was Re: 2.6.29-git13:
Reported regressions from 2.6.28)
On Tue, Apr 7, 2009 at 1:23 PM, Stefan Richter
<stefanr@...6.in-berlin.de> wrote:
> Trenton D. Adams wrote:
>> On Tue, Apr 7, 2009 at 11:10 AM, Stefan Richter
>> <stefanr@...6.in-berlin.de> wrote:
>>>>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>>> Interdependencies between ALSA modules have changed. The Gentoo init
>>> scripts attempted to unload them in an order which deadlocked modprobe
>>> due to dependencies. The fix for Gentoo is to just not unload the
>>> modules on system shutdown. My Gentoo/amd64 Mac mini was affected by
>>> this too; fixed by userland update.
>>>
>>
>> While that is interesting, I am not seeing that problem on my Gentoo
>> box (the macbook), which is completely up-to-date. 2.6.28 works, and
>> 2.6.29 doesn't. Same init scripts, different kernels.
>
> Note that the respective update changed /etc/conf.d/alsasound (a local
> configuration file) to include
> UNLOAD_ON_STOP="no"
> KILLPROC_ON_STOP="no"
> This change by update is not activated by a mere emerge; one needs to
> incorporate that change with dispatch-conf or an equivalent method.
> (Or simply edit the file to have these variables set to "no".)
I run dispatch-conf every time I update. It did not set it to no by
default. I do see the option though.
>
>> And sure, I could put a comment on the rmmod, in the init script, but
>> IMO that would be a hack around a _bug_. Which is fine for me. But,
>> is it worth leaving the issue in the kernel?
>
> Is it a kernel issue if a script attempts to unload a busy module, then
> fails to proceed? I wouldn't think so.
I don't know really. It worked before, now it doesn't. But, now I'm
recalling something you said earlier. They are being done in the
wrong order. The gentoo bug mentions the correct order. I hadn't
realized that.
>
> But more importantly, is this init scripts related bug really what's
> happening at your system? Or do you actually experience an entirely
> different bug?
It could be. I will try it out when I get home from work, and get
back to you. That would be cool if it was a simple init script
problem. Cause then I don't have to do anymore git bisects. ;)
> --
> Stefan Richter
> -=====-=-=== -=-= -==-=
> http://arcgraph.de/sr/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists