Comment 47 for bug 121653

"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.