I really appreciate your feedback but you seem to prefer writing mails instead of trying what I wrote. [Mika]
Because 2.6.21 is not going to help us even if it works; I need more data; it's not the only test; and Linux ++ fixes anything but is not a distro. My users need grml repos, 0.9 or 1.0. They can't function with 2.6.21. Communication & research is all that's possible anyway. Memorial Day vacation - I'm packing now. (Incidentally: verified as kernel regression under Ubuntu 7.04; same problems.)
During beta I would have done as requested to improve 1.0 final. Grml gave me no task, no suspect kernel config flags to isolate, etc. Radio silence made me hungry for info-crumbs...
But a broken (from our standpoint) final release makes me ask how grml beta cycles are supposed to work. I just need to know what grml does/thinks so I can work with, or around the philosophy & constraints involved.
Beta cycles are meant to catch bugs before release. Kernel regression is just another bug category. A kernel regression which, for instance, broke your laptop, would prevent a grml release. And that is how it should be.
Re bisect: Other people do that coordinated by -stable. My job is sysadmin, not kernel dev. The whole point of Linux for us, rather than BSD or Open Solaris or Nexenta or whatever, is hardware support. If we have to become kernel devs too, supporting/debugging our own hardware, then we would consider other kernels to develop, with possibly more rational code. Note about USB in Linux, "the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem" (Greg Kroah-Hartman). Anyway it's not my call. The last thing my boss will allow is debugging Linux hardware drivers.
What I'm asking is, do you inspect a grml bug report, and then talk to -stable to see if they have anything related in their pipeline, and then decide whether grml should wait for a patch?
Looking at -stable patch-2.6.20.12, I see USB fixes relating to mutexes, IRQs, etc. - the big stuff.
What -stable version is 2.6.20-grml in grml 1.0 final?
Next, how does Debian fit into all this? Grml tracks Debian unstable. But grml releases are tied to Linus's kernel releases, not Debian kernel work, right? Correct me on anything.
Does grml kernel customization include the possibility of using a -stable release that is not yet incorporated into Debian? Or is Debian a limiting factor?
Dumb question maybe, but if I compile my own 2.6.20-x using grml source and patched from -stable, will it work with grml 2.6.20-grml repos? I'm willing to compile a kernel but if I start having to build repos too, I've already become a custom distro, and I'd rather not.
Thanks - see you a week from now.
Mark