Even though they have a lot in common, I'm convinced these issues have two different root causes, but I'm also hopeful that the change for bug 126140 will also avoid ours (bug 274995).
Bug 126140 is about certain PCs that remain powered up at the end of their shutdown sequence. Anyone remember the Windows "It is now safe to turn off your computer" screen? That's essentially the behavior of bug 126140, minus the cheery-souding Microsoft comforting. Both that problem and ours ... can be avoided by rmmod -f snd_hda_intel (the sound driver) ... generally involved Alsa ... interrupted normal shutdown But ... 274995 is not actually a hang ... 126140 actually is a hang ... 274995 has a networking workaround ... 126140 seems to have a power-management workaround The "fix" for bug 126140 isn't r-e-a-l-l-y a fix because it doesn't address the root cause (which certainly could be a BIOS oddness), but it does avoid it. Before the hang, the code will now respond to a system reboot signal by releasing the interrupts. It was tested against the problem in 126140. If the net effect of releasing the interrupts is the same as "rmmod -f snd_hda_intel" then it should also avoid our problem as well. We should test it. If it does, we should also make sure that nothing else broke in the process -- for example, does the shutdown in /etc/init.d/alsa-tools still save and zero mixer settings like it was written to do? My suggestion is that we don't call these duplicate bugs until such testing is complete, even though we are hopeful that this one change avoids both issues. -- MASTER storing ALSA mixer element values during shutdown hangs nondeterministically if non-loopback network interfaces are still up https://bugs.launchpad.net/bugs/274995 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
