Linus Torvalds :
"For example, look at suspend/resume bugs. Do you realize that 99% of them are device driver issues, but how the heck do you connect a "my laptop does't resume" to the _right_ device driver maintainer?"
http://lkml.org/lkml/2007/4/28/438
(So USB_CONFIG_SUSPEND may cause issues with hardware devices, which kernel upgrades alone won't fix, only driver upgrades, one per device.)
* Mark 27e3kk302@sneakemail.com [20070521 23:15]:
Linus Torvalds :
"For example, look at suspend/resume bugs. Do you realize that 99% of them are device driver issues, but how the heck do you connect a "my laptop does't resume" to the _right_ device driver maintainer?"
And what's the news?
(So USB_CONFIG_SUSPEND may cause issues with hardware devices, which kernel upgrades alone won't fix, only driver upgrades, one per device.)
Sure, and CONFIG_ACPI "may cause issues with hardware devices" too. ...
regards, -mika-
And what's the news?
I gave it:
(So USB_CONFIG_SUSPEND may cause issues with hardware devices, which kernel upgrades alone won't fix, only driver upgrades, one per device.)
The news is, grml should probably stop advising kernel upgrades to chase suspend/resume problems. As Linus says, they are 99% driver bugs. Unless the kernel upgrade incorporates new drivers, it won't do much, and will probably add bugs of its own.
Sure, and CONFIG_ACPI "may cause issues with hardware devices" too.
But CONFIG_ACPI is not considered experimental by the kernel devs like USB_CONFIG_SUSPEND.
We're more likely to recompile grml 2.6.20 with our own flags, than upgrade the kernel to 2.6.21. If we do that I'll let everyone know whether it worked.
Mark
* Mark 27e3kk302@sneakemail.com [20070521 23:41]:
And what's the news?
I gave it:
(So USB_CONFIG_SUSPEND may cause issues with hardware devices, which kernel upgrades alone won't fix, only driver upgrades, one per device.)
The news is, grml should probably stop advising kernel upgrades to chase suspend/resume problems. As Linus says, they are 99% driver bugs.
Sure, and those driver bugfixes are part of kernel upgrades.
Unless the kernel upgrade incorporates new drivers, it won't do much, and will probably add bugs of its own.
New drivers? We are talking about bugfixes....
Sure, and CONFIG_ACPI "may cause issues with hardware devices" too.
But CONFIG_ACPI is not considered experimental by the kernel devs like USB_CONFIG_SUSPEND.
We're more likely to recompile grml 2.6.20 with our own flags, than upgrade the kernel to 2.6.21. If we do that I'll let everyone know whether it worked.
If CONFIG_USB_SUSPEND causes problems on specific hardware (what's the case) there's a bug somewhere. The fix for grml/upstream (what *you* do is your very own choice) is not disabling an option but to locate and fix the bug. Disabling such an important configuration option in general is the very last option.
regards, -mika-
The news is, grml should probably stop advising kernel upgrades to chase suspend/resume problems. As Linus says, they are 99% driver bugs.
Sure, and those driver bugfixes are part of kernel upgrades.
The point is, there are N drivers and 1 kernel. Linus says these suspend/resume interactions are nasty bugs. When a compile flag multiplies nasty bugs throughout the drivers in the kernel tree, then you have a nightmare of multiplying bugs.
The long-term fix is to correct all the drivers.
The short-term fix is to turn the flag off.
One day all Linux drivers will be operational with experimental suspend/resume. That day is not today. Even kernel devs are saying this recent kernel series is too rushed - the bug triage expert resigned in disgust.
New drivers? We are talking about bugfixes....
I should have said "upgraded bug-fixed" driver.
If CONFIG_USB_SUSPEND causes problems on specific hardware (what's the case) there's a bug somewhere.
Absolutely. There are USB bugs hitting lots of people with 2.6.20: http://ubuntuforums.org/showthread.php?t=406893
The fix for grml/upstream ...not disabling an option but to locate and fix the bug.
Well, I filed a report. If you want to work on it, compile a 2.6.20 without the suspend flag, just to verify that's the issue. Otherwise I'll put that on my list.
2.6.21 is probably not an answer. We can give it a test for you. The hardware worked with previous grmls and we can stay at 0.9 in the worst case.
Thanks again, Mark
* Mark 27e3kk302@sneakemail.com [20070522 07:15]:
The fix for grml/upstream ...not disabling an option but to locate and fix the bug.
Well, I filed a report. If you want to work on it, compile a 2.6.20 without the suspend flag, just to verify that's the issue. Otherwise I'll put that on my list.
2.6.21 is probably not an answer. We can give it a test for you. The hardware worked with previous grmls and we can stay at 0.9 in the worst case.
Mark, are you aware of the fact, that we are using enabled CONFIG_USB_SUSPEND since at least 2.6.11-grml?
regards, -mika-
Mark, are you aware of the fact, that we are using enabled CONFIG_USB_SUSPEND since at least 2.6.11-grml?
I did not suggest it; you did. So I am pursuing that.
My suggestion was a grml/Debian/Linux design flaw, based on similar USB behavior observed in old grml dev versions. A bug which crops up across versions says to me "design issues." It's not our test hardware that is changing. Windows handles it just fine. I can also plug the test USB disks into Mac OS X, zero problems. Even grml 0.9 works fine.
With kernel 2.6.20 I'm not sure what to think; is it grml/Debian or Linux? (a) Linux kernel timer code has undergone revision and (b) non-grml users are reporting USB trouble with 2.6.20.
I am all in favor of laptop feature creep - just not at the expense of major subsystems like USB. Whether there's a real conflict is TBD. But for sure grml needs more USB testers.
Mark
* Mark 27e3kk302@sneakemail.com [20070522 09:15]:
Mark, are you aware of the fact, that we are using enabled CONFIG_USB_SUSPEND since at least 2.6.11-grml?
My suggestion was a grml/Debian/Linux design flaw, based on similar USB behavior observed in old grml dev versions. A bug which crops up across versions says to me "design issues." It's not our test hardware that is changing. Windows handles it just fine. I can also plug the test USB disks into Mac OS X, zero problems. Even grml 0.9 works fine.
It's an excellent example of a kernel regression. Stop complaining and "git bisect" if you are really interested in seeing it fixed.
regards, -mika-
It's an excellent example of a kernel regression. Stop complaining and "git bisect" if you are really interested in seeing it fixed.
If discussing bugs is complaining then I give up...Calling for grml testers seems more logical.
Nothing yet has been shown; there is just a waterfall of assumptions, user-bad -> hardware-bad -> kernel-bad. The missing concourse is grml-bad. Do you want users and testers, or just developers?
Generally grml is very high quality and bug reports can only make it better. Stop complaining about them! :-)
Mark
* Mark 27e3kk302@sneakemail.com [20070523 01:15]:
It's an excellent example of a kernel regression. Stop complaining and "git bisect" if you are really interested in seeing it fixed.
If discussing bugs is complaining then I give up...Calling for grml testers seems more logical.
You don't get it.
Nothing yet has been shown; there is just a waterfall of assumptions, user-bad -> hardware-bad -> kernel-bad. The missing concourse is grml-bad. Do you want users and testers, or just developers?
Generally grml is very high quality and bug reports can only make it better. Stop complaining about them! :-)
Once again:
CONFIG_USB_SUSPEND is used at grml's kernel since ages, nothing new - no surprises, just what you used so far as well. And it worked for you in the same configuration until 2.6.20. 2.6.20 causes problems with an external usbdisk on your system. -> It's a regression inside the kernel.
Deactivating an important kernel option because it causes problems on one out of several hundreds/thousands boxes is not a real option. Especially as it's a regression and not because of a new and never tested driver/feature.
I offered you a ready-to-go kernel package you just have to install and run it once. If it works we know it was a regression which has been fixed already. If it still does not work we have to bisect the problem and inform upstream about it.
If you don't want to contribute but prefer complaining feel free to do so, but then let me feel free to ignore you.
regards, -mika-
Have a sense of humor! A better response would have been - "touche."
Yes, it may be a kernel problem. It's never wise to *assume* so. That's all I meant. There needs to be data.
The data shows others having USB 2.6.20 problems, supporting a kernel diagnosis, but contradicting claims of "one out of several hundreds/thousands boxes."
"If you don't want to contribute but prefer complaining"
This is silly. I'm contributing valid bug reports with complete hardware data sheets. Not to mention the various ideas and articles and other tests contributed over time.
If you can explain what makes the test hardware weird or unusual, I'm all ears. It's as average and normal as a PC can get. (That's why we test with it.)
M.
* Mark 27e3kk302@sneakemail.com [20070524 20:15]:
"If you don't want to contribute but prefer complaining"
This is silly. I'm contributing valid bug reports with complete hardware data sheets. Not to mention the various ideas and articles and other tests contributed over time.
I really appreciate your feedback but you seem to prefer writing mails instead of trying what I wrote.
If you can explain what makes the test hardware weird or unusual, I'm all ears. It's as average and normal as a PC can get. (That's why we test with it.)
Again: it's a kernel regression. Neither a hardware bug nor a problem you or I can fix. So once more: test newer kernel(s) and if that still does not fix the problem, we have to find the patch that caused the regression (via using git bisect) so we can contact kernel upstream and tell them "look, that patch caused problems".
regards, -mika-
Teilnehmer (2)
-
Mark -
Michael Prokop