> end of discussion now

Well then, for the record only:

Mika said on grml-list that 2.6.21 was for BUG ISOLATION only.  For BUG
ISOLATION, 2.6.20/n is MORE VALID than 2.6.21/y because ONLY ONE THING HAS
CHANGED.  That is how to perform bug isolation - change one thing at a time.  In
this case, a compile flag.

If grml needs such testing, please respond during beta cycle.

> No. What would you gain from CONFIG_USB_SUSPEND=n on 2.6.20?

BUG ISOLATION.  And, a known workaround, as reviewed by Ubuntu.
http://usbsuspendbackport.wikispaces.com/

We need kernel modules - nVidia, kqemu, truecrypt, etc.  A stand-alone kernel is
useless.  So we have to compile no matter what, and 2.6.20/n was/is safest right
now.  We'll see about 2.6.22.

But regardless...grml will keep USB suspend no matter what.  So 2.6.21 TEST IS
USELESS FOR GRML BECAUSE IT HAS NO EFFECT ON GRML DESIGN.  No matter what
happens with 2.6.21 or 2.6.22 or 2.7.0 or even 3.0.0, grml will keep USB suspend
and grml will use the latest kernel.org.  There is no use in any kernel++ test.

About the flag.  Correct, it is 2.6.20 code - which means the flag is broken. 
Newer suspend code in the kernel is breaking things.  The compile flag just
switches it on/off.  Saying the flag has always worked is misleading, because
the code that it switches has changed.  So sure, it's 2.6.20 regression.  And
that means the flag is now switching bad code on/off.  We plan to turn off the
bad code.

USB devices have worked since ages, and new suspend code is breaking drivers. 
The kernel devs say that, not me.  But we acknowledge grml design choices, and
that's fine, we can recompile.

It's definitely end of discussion for us, too.  Let's hope 2.6.22 brings some
good news.