* Mark <bts@bts.grml.org> [20070706 00:15]:

[...]

Bug isolation as in "let's see whether the regression is still
present"....

[...]
> 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.

*grml* You shouldn't use the "stand-alone kernel" for production use
but just boot it once and see whether the USB issue got fixed.  But
I wrote that too many times already...

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

No. Not "no matter what", but I don't want to disable a usefull
feature just because there's one single regression in the kernel.
Instead of disabling that feature, the right way would be to find
the real source of the problem. And if the bug is still present in
2.6.21 we could test the current version of 2.6.22-rc to make sure
it can be fixed for final 2.6.22. But I wrote that as well too many
times already...

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

You could try
http://bugzilla.kernel.org/attachment.cgi?id=10313&action=view
if you plan to recompile 2.6.20 *with* CONFIG_USB_SUSPEND=y.

Anyway, according to some googling around the kernels behind
2.6.21-rc4 should bring updated code in regard to USB suspend...
But as you insist on wasting your time with 2.6.20 instead...

regards,
-mika-