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