* Mark <bts@bts.grml.org> [20070705 04:15]:

> Closing.  The problem is the scanner and CONFIG_USB_SUSPEND as reported in
> Ubuntu 2.6.20.

> https://launchpad.net/ubuntu/+source/sane-backends/+bug/85488

> It's not the modules, it's not the hub, it's not the PC hardware, it's Linus
> getting too excited about laptop features.

> Linus should not have released this buggy flag.  These scanners all worked fine
> for a long time in Linux.  Vendor hardware is buggy to an extent, but as Linus
> likes to say about his kernels, perfection is impossible and that's the real
> world, so deal with it.

Again: we are using CONFIG_USB_SUSPEND since ages and it never
caused serious failures until 2.6.20. It's a *regression* in 2.6.20.

> Testing 2.6.21 was never useful to us at all.  The right test was to recompile
> 2.6.20 with the flag off.  That's been my focus as time allows.  But GCC keeps
> segfaulting even with 1.5 GB of RAM.  We're still running grml 0.9.

No. What would you gain from CONFIG_USB_SUSPEND=n on 2.6.20?
Nothing grml related. Because grml will continue in using
CONFIG_USB_SUSPEND=y.  So testing a newer kernel (to see whether the
regression is fixed or not) is what's important. That's what I said
more than once and I offered you a ready-to-go Debian package of
2.6.21-grml.  But feel free to do whatever you think is right for
you, for me it's end of discussion now.

regards,
-mika-