Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Is Intrepid going to ship with 2.6.26?
By October that kernel is going to feel quite old.
On the other hand it will have had 3+ months to collect -STABLE fixes.
Which kernel is targeted?
Posted Jun 28, 2008 15:20 UTC (Sat) by cpeltz (guest, #50565)
I think it is more likely that they'll use 2.6.27 later, after all this is the first release
after a LTS one and they said this one would get more experimental technology.
Posted Jun 29, 2008 10:06 UTC (Sun) by callegar (guest, #16148)
Unfortunately, while focus is on the intrepid kernel, hardy that is meant to be long term
support after more than 2 months still is shipped with a kernel that causes random
lockups/hard freezes and consequent data loss on a few systems.
The solution is known (custom compiled kernels from kernel.org such as 22.214.171.124 do not show
the issue, as the system from which I am writing this message proves) and the bug has now been
marked as fix-released on the bug database for about 1 month.
But no release of fixed kernel packages has been made for hardy, because since hardy has
started with 2.6.24 it is forbidden to ship a 2.6.25 for it and - the other way round - no
backport of the fix has been made from 2.6.25 to 2.6.24.
Bug report number for "causes random lockups"
Posted Jun 29, 2008 12:32 UTC (Sun) by sladen (subscriber, #27402)
[..] after more than 2 months still is shipped with a kernel that causes random lockups/hard freezes [..]
Posted Jun 29, 2008 13:41 UTC (Sun) by callegar (guest, #16148)
Gutsy work good, hardy freezes (13/4/08)
Hardy freezes (forum, 24/4/08 19 pages thread, often suggesting causes having nothing to do
with the real bug)
Hardy freezes at random without debugging messages (31/3/2008)
date indicates that bug was know during beta testing
Hardy is BY FAR the worst Ubuntu version yet. LOCKUP WARNING!!!
(forum 26/4/2008. I am not contributing to it, as I do not like the too aggressive general
attitude. 65 pages anyway !)
Linux kernel 2.6.24-12 lockup (22/3/2008)
Date indicates that bug is well known since before release that happened anyway.
This is an important one. It is marked as "fix-released" since it illustrates how:
- it was found out that kernels 2.6.25 fix the issues
- ubuntu for a certain time provided working 2.6.25 kernels via the ppa channel (that were
- Fix release was set on 22/5/2008: since then no actual fix was released for hardy
System randomly freezes / locks up possibly due to prism54
Prism has nothing to do with it. I am experiencing the bug on a system with no wireless.
Apparently, wireless and anything using lots of interrupts is just making it more frequent.
hardy random freeze (07/05/2008)
Here it is noticed how fedora kernels do not have the problem
And I am sure that I am missing tens of these, since just googling hardy and freeze or hardy
and lockups returns lots of pages.
But also look at
stating that hardy _will not_ ship a 2.6.25 notwithstanding the known problems with 2.6.24
where bug 204996 is marked as fixed for intrepid and the comments timidly suggest that maybe
something could be done for hardy too
Please backport kernel 2.6.25
that again states that there won't be a non-freezing kernel for hardy until someone finds out
how to backport the solution to 2.6.24.
Posted Jun 30, 2008 7:14 UTC (Mon) by tajyrink (subscriber, #2750)
It's still very much a generalization. If there is a regression for a person and the person is
a blogger / forum active, it's common that she'll yell about how the release is absolutely the
worst ever. I think I've seen this happening with every Ubuntu release so far, starting with
5.04 which was absolutely a step backwards from 4.10 for some. And also the other way around -
it was commonly accepted by the developers that edgy (6.10, following the first LTS release)
with its four-month release schedule was a sub-par release with many bugs. Still, I've also
seen many posts like the 6.10 was the last great Ubuntu release and it's been downhill from
there (7.04, 7.10, ...).
Regressions shouldn't happen, but I don't think there is more regressions with hardy than
earlier releases. Of course I don't have any definitive data either. There are probably more
discussions on the forums about the problems now, but there are also again millions of new
If you think the greatest source of problems are in the kernel, you can only hope there will
be more people joining either the upstream kernel QA or Ubuntu's Kernel Team. There is always
more work to be done.
To be not just on the defensive side, I do think Ubuntu developers are in a greater lack of
resources than eg. Red Hat's or Novell's. The community might be a bit more vibrant also on
the developer side for Ubuntu, but there are simply so much less paid developers. On the other
hand being based on Debian means many things are top-notch without that much of resources, but
still the hardware-specific problems would simply need more co-operation from manufacturers
and more testers/fixers. Some of this is happening as eg. Dell is feeding Ubuntu with some
quirks that Ubuntu is then feeding upstream, but it's only a beginning.
Posted Jun 30, 2008 7:36 UTC (Mon) by rsidd (subscriber, #2582)
This is still anecdotal, but I have been seeing frequent freezes on my laptop (though not the
desktop), and only after reading this thread does it occur to me that the hardy kernel could
be responsible. There were occasional freezes earlier, related to the wireless card, but it's
far more frequent now.
Posted Jun 30, 2008 12:16 UTC (Mon) by Cato (subscriber, #7643)
I agree that the Ubuntu kernel developers need some more resource. I struggled for quite a
long time with a different freeze problem on Gutsy and Hardy kernels (2.6.22 and 2.6.24) which
involved a "nobody cared" message on a shared IRQ, followed by a lockup of the devices using
that IRQ. I bypassed this by the kernel boot parameters "all_generic_ide irqpoll" which
doesn't seem to have hit performance noticeably, but it wasted quite a lot of time when I was
setting up a new PC built specifically for Ubuntu.
Also, suspend/hibernate took some time to get working, but that's due to lack of a really good
configuration wizard that will figure out the various options required to make it work. And
it's broken again for some reason that I can't figure out...
I really like Ubuntu but I hope that stability and bug-fixing can be given more attention over
new features. I don't really need new features but would like a few things to work better.
Posted Jun 30, 2008 12:54 UTC (Mon) by callegar (guest, #16148)
I realise that it is still a generalisation and that to count the actual number of systems
showing a the random lockups would be extremely difficult. And I agree that it is wrong to try
to compute the goodness of a distribution from the loudness of the yells or the prises.
Also I do not want to diminish ubuntu in any way, since it has generally done an excellent
However, the bug reports surely tell us that the number of affected systems is > 0 and that
the regression exists.
It is clear that regressions can happen. But in some sense you might get a subtle feeling that
there is regression and regression and that one causing the system to suddendly lock and some
of your data to disappear (because you had a virtual machine on at that moment and that didn't
know anything of how to deal with the freeze) is particularly nasty. Also, and more
annoyingly, having linux doing this sort of things tends to rise a sense of revenge in all
your friends who were getting blue screens of death on ME.
But in my opinion the real point here is how to solve the issue as fast as possible and create
conditions so that similar situations do not happen again. Because the problem is not the
bug, but the management:
1) The bug was known since before hardy release
2) A solution has been known for more than 1 months, but not delivered to anybody
3) The bug appears to be marked as "fix-released". And this is a full acknowledgement of the
bug existence, but is also a funny wording, because the fix was not released
4) And most important, there are many users, like myself, that are now in need to run on
custom kernels that won't likely get any security fix because it takes hours to compile a
So, I am only underlining the fact that the policies are not working well here and that the
most notable consequence is a hard-to-quantify but surely non-null rise in the number of
people running unsupported custom kernels on the long term support distro, which is sort of
If 2.6.25 is known to fix issues to some, why not just releasing it in addition (if not in
substitution) to 2.6.24 and why not doing so early?
As a final consideration, understand that there can surely be a rise in the number of people
involved in the ubuntu kernel. But that it will always be extremely difficult to find people
willing to x-ray the differences between 2.6.x and the ubuntu 2.6.(x-k) to confine the changes
to backport to ununtu's 2.6.(x-k) to fix it. Accept that this will always be seen as a most
boring thing to do. And that most people would just prefer concentrating on making 2.6.x
Posted Jun 30, 2008 18:35 UTC (Mon) by Los__D (guest, #15263)
"3) The bug appears to be marked as "fix-released". And this is a full acknowledgement of the
bug existence, but is also a funny wording, because the fix was not released"
The (original) bug is for Intrepid, and indeed a fix has been released for Intrepid.
Posted Jun 30, 2008 21:46 UTC (Mon) by callegar (guest, #16148)
The original bug is for hardy
Hardy freezes at random without debugging messages
Bug #209830, first reported on 2008-03-31
and even before
Linux kernel 2.6.24-12 lockup
Bug #204996, first reported on 2008-03-22
The intrepid ibex was opened for development on May 2, so those bugs were opened for hardy not
for ibex. At that time hardy was not even yet released.
Also, the original bug report clearly indicates that the bug is against hardy:
> Description: Ubuntu hardy (development branch)
> Release: 8.04
But they got tagged as intrepid ibex and then marked as fix-released completely forgetting
that they were originally filed against hardy as also this message proves.
Which is another bit that does not go too well in bug management. If a bug is clearly opened
for a certain distro version, it shouldn't be tagged for another one and closed with
"fix-released" just because the fix is made available for the other version.
Posted Jul 1, 2008 10:04 UTC (Tue) by yodermk (subscriber, #3803)
My anecdotal evidence is that when my printer (an HP all in one) is connected to my laptop
(USB) *while booting*, it will often freeze within the first half hour of booting. When it's
not plugged in at book, it will work just fine, even when I plug it in later.
Posted Jun 30, 2008 0:58 UTC (Mon) by qg6te2 (guest, #52587)
because since hardy has
started with 2.6.24 it is forbidden to ship a 2.6.25 for it
This is a somewhat curious policy on the part of Ubuntu -- hasn't there been a recent push to considerably reduce regressions for each new kernel release, thereby making freezes to a particular kernel version not as useful as before ?
Posted Jun 30, 2008 14:21 UTC (Mon) by nhippi (subscriber, #34640)
The solution is known (custom compiled kernels from kernel.org such as 126.96.36.199 do not show the issue, as the system from which I am writing this message proves)
Since only hardy users with problems upgrade to 188.8.131.52, it very much possible 184.108.40.206 has regressions for *other* users. You can't just blindly upgrade to a new kernel version when you have a very wide userbase with lots of different hardware...
Since you are competent enough to compile your own kernel, you might help and use "git bisect" to find the change in kernel that makes it work again.
Posted Jun 30, 2008 16:11 UTC (Mon) by callegar (guest, #16148)
Following this reasoning to an extreme, since there were already bug reports about 2.6.24
showing freezing regressions for some users, why have I been encouraged by the same distro to
blindly upgrade from the 2.6.22 that gusty had without any warning in the release notes?
On the other hand, given that 2.6.25 is at .9 I would say that it should have received some
testing by now. Maybe it has a larger userbase than 2.6.24. And anyway: I am not suggesting
that all hardy users are forced to upgrade to 220.127.116.11. I am just suggesting that in one way
or another some kernel that does not freeze is provided. Maybe 2.6.25 can be provided through
a dedicated channel (e.g. ppa or whatever) with as many scaring warnings as needed.
For what concerns bisecting, I will not do it. Compiling a kernel takes a night on my slow
host. Bisecting and testing a bug that causes a freeze every few hours could take a fortnight
or more. It is just not an option and IMHO is a waste of time since the bug has anyway been
fixed upstream and the kernel developers have moved over. And even assuming that I can
identify the spot to be changed, where is the guarantee that the backported changes do not
cause regressions to other users? Personally, I feel better using a pristine, vastly tested
18.104.22.168 than a 2.6.24 patched by myself with stuff taken from 22.214.171.124.
But if someone wants host them, I am more than willing to share my kernel image and headers
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds