"Perhaps the suspend script can check for the presence of the fglrx module and refuse to suspend in that case... (with a comment documenting this)"
That's a pretty drastic solution to the problem, considering that it's caused by premature commitment to a brand new kernel feature (the SLUB allocator), particularly for a distribution with a reputation for "it just works" and "user friendliness". It's been confirmed both here and in the several duplicate bug reports that restoring the expected behavior (normally functioning suspend/hibernate/resume) is a simple as switching back to the SLAB allocator. Everything works again, and nothing seems to break. I haven't found a compelling argument for SLUB over SLAB yet other than "the simplified code is attractive" and a *claimed* "5-10% performance increase" (Emphasis mine - where are the benchmarks?). Given that defaulting to SLAB until SLUB has been more widely tested is unlikely, it seems that a solution that doesn't put undue burden on the user would be preferable to the workarounds mentioned so far. Something like having the fglrx package depend on a SLAB version of the kernel (installed alongside the default SLUB version) along with a note to the user to boot into the SLAB kernel if they need suspend/resume to work with fglrx. Once it's been confirmed that a future version of fglrx is compatible, the extra dependency can be quietly eliminated. -- [gutsy] Suspend to Ram does not work on Z61m https://bugs.launchpad.net/bugs/121653 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
