Anyone with access to external USB disks should test grml 1.0rc2. At our site USB has worked fine with all previous grmls but rc2 USB seems broken. A bug report #203 has been filed. File your own if you discover problems.
Mika's close to a final release. Please perform tests with rc2 if you have time, both of us would appreciate it very much.
Mark
* Mark 27e3kk302@sneakemail.com [20070518 20:21]:
Anyone with access to external USB disks should test grml 1.0rc2. At our site USB has worked fine with all previous grmls but rc2 USB seems broken. A bug report #203 has been filed. File your own if you discover problems.
I think it's just a problem of CONFIG_USB_SUSPEND on a few boxes (just google for it - it's hardware specific), 2.6.21 hopefully fixes it.
An unofficial build is already available if you want to give it a try: http://dufo.tugraz.at/~prokop/grml-kernel/2.6.21-grml/
Mika's close to a final release. Please perform tests with rc2 if you have time, both of us would appreciate it very much.
JFYI: We are releasing the final stable release in these minutes.
regards, -mika-
Mika - the 1.0 release might be too important to allow such a bug through? nVidia hardware could be common? The motherboard is years old, not the latest thing at all, can we really blame hardware?
Anyway, if so, grml needs more usb testers if the bug(s) is(are) specific to hardware that grml doesn't have lying around. So I'm glad this went to the mailing list.
Thanks for the tip on 2.6.21. Our experience has been that we have too many problems trying to integrate external/upgraded stuff after a grml2hd operation. We may just stick to 0.9 and wait for 1.1. (But I'll try one-off experiments to isolate these problem(s).)
Mark
* Mark 27e3kk302@sneakemail.com [20070518 21:15]:
Mika - the 1.0 release might be too important to allow such a bug through? nVidia hardware could be common? The motherboard is years old, not the latest thing at all, can we really blame hardware?
A release without any errors isn't possible, sorry. :) Changing a kernel configuration causing a kernel rebuild for at least 3 flavours including tons of external modules might bring us many more problems than this single one, which affects only specific hardware.
Thanks for the tip on 2.6.21. Our experience has been that we have too many problems trying to integrate external/upgraded stuff after a grml2hd operation. We may just stick to 0.9 and wait for 1.1. (But I'll try one-off experiments to isolate these problem(s).)
wget $KERNEL.deb dpkg -i $KERNEL.deb update-initramfs -c -t -k $NEW_KERNELVERSION update-grub or $EDITOR /etc/lilo.conf && lilo
regards, -mika-
A release without any errors isn't possible, sorry. :)
Of course. But this is 1.0. The bug was reported under 0.9-7 some while ago and re-tested under 1.0rc2. Furthermore it has been reported in the distant past (similar behavior in old grml dev releases). So, I did my part as a grml beta tester.
which affects only specific hardware
Evidence of that claim would be welome, hence my call for testers. It's seriously doubtful. Kernel guys were having problems not long ago with various other hardware over the same config flag you mentioned. http://lkml.org/lkml/2007/1/11/146 The flag is still considered experimental among the Linux devs? Yesterday/today was the first time grml mentioned it to us...too bad, we might have helped debug a little more.
wget $KERNEL.deb
Sure, but then grml repo .debs don't match the kernel version, etc. These very same headaches are just pushed to users:
Changing a kernel configuration causing a kernel rebuild for at least 3 flavours including tons of external modules might bring us many more problems than this single one
If the one config flag is the cause, still TBD, then the fix means changing one experimental/broken flag from Y to N. Since other linuxes are using 'N' that seems a safer setting. If only grml is using 'Y' then what are grml linux folks doing that needs 'Y' while the other linuxes manage with 'N'?
Thanks, Mark
* Mark 27e3kk302@sneakemail.com [20070518 23:14]:
A release without any errors isn't possible, sorry. :)
Of course. But this is 1.0. The bug was reported under 0.9-7 some while ago and re-tested under 1.0rc2. Furthermore it has been reported in the distant past (similar behavior in old grml dev releases). So, I did my part as a grml beta tester.
[...]
The idea with CONFIG_USB_SUSPEND came into my direction behind our kernel freeze date. Your feedback as a grml beta tester was great and we will debug it behind 1.0 of course. If kernel 2.6.21 solves the issue for you we can continue in using CONFIG_USB_SUSPEND (which brings great benefity in general, especially on laptops). If it still causes problems we can contact kernel upstream, and if that still fails in resolving the problem we can deactivate the option at all. So stay tuned and wait a few more days until 1.0-1 is available providing kernel 2.6.21 for you. :)
regards, -mika-
OK. Generally I feel like this person: https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/85488/comments/... via https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/85488
I'm worried that we're looking at a driver issue, meaning, the bug infects all kinds of hardware, not just scanners and disks. If a device driver doesn't handle USB kernel suspend calls, then it breaks. That means a kernel upgrade alone won't solve the problem(s) but only upgrades to all affected drivers. (In our case the USB controller isn't even detected.)
So grml 1.0 is taking a high-risk move for rather low yield. It would have been better to push laptop goodies out to 2.6.21 and keep known-good functionality for "everything else."
I have to go now; I hope people will test USB hardware with 1.0 and/or that kernel upgrade you've posted.
Thanks. M.
* Mark 27e3kk302@sneakemail.com [20070519 00:13]:
I'm worried that we're looking at a driver issue, meaning, the bug infects all kinds of hardware, not just scanners and disks. If a device driver doesn't handle USB kernel suspend calls, then it breaks. That means a kernel upgrade alone won't solve the problem(s) but only upgrades to all affected drivers. (In our case the USB controller isn't even detected.)
You've been the only one reporting this problem to us and we couldn't reproduce it on any piece of our own "hardware zoo". So it didn't become a release blocker behind kernel freeze date. Sorry for that, Mark - but I'm sure you'll get an updated grml version soon. ;)
So grml 1.0 is taking a high-risk move for rather low yield. It would have been better to push laptop goodies out to 2.6.21 and keep known-good functionality for "everything else."
See above.
I have to go now; I hope people will test USB hardware with 1.0 and/or that kernel upgrade you've posted.
ACK :)
regards, -mika-
You've been the only one reporting this problem
Google turned up many reports, from Ubuntu, LKML, etc., on various hardware (previous links). Grml beta pool is far too small and sporadic to expect multiple corroborations. I myself only tested 1.0rc2 on a whim, thinking the bug was already fixed, planning other work.
The test hardware from my 0.9-7 bug report is completely documented there, all normal and common (Asian MSI board using nVidia chips). Grml could document its own test hardware on the wiki to give an idea of coverage.
Laptop users also need USB devices. A bug that hurts USB is going to hurt them too.
It may be a grml judgment call, no problem, but please do not discard valid bug reports as "unusual" - it's too easy to blame strange user hardware/behavior which ultimately defeats the purpose of a beta pool.
Anyway, great work in general on 1.0, and congratulations.
Mark
participants (2)
-
Mark -
Michael Prokop