| |||||||||||||
|
| |||||||||||||
Kernel prepatch 2.6.27-rc5
2.6.27-rc5 is out. "The most
exciting (well, for me personally - my life is apparently too boring for
words) was how we had some stack overflows that totally corrupted some
basic thread data structures. That's exciting because we haven't had those
in a long time. The cause turned out to be a somewhat overly optimistic
increase in the maximum NR_CPUS value, but it also caused some
introspection about our stack usage in general." More excitement
can be found in the
full changelog.
(Log in to post comments)
Kernel prepatch 2.6.27-rc5 Posted Aug 29, 2008 2:11 UTC (Fri) by Oddscurity (subscriber, #46851) [Link]
ftrace: disable tracing for suspend to ram
Nice to see that fixed as that did indeed break resume for me after it having worked wonderfully for quite some time.
Kernel prepatch 2.6.27-rc5 Posted Aug 29, 2008 2:33 UTC (Fri) by MisterIO (subscriber, #36192) [Link]
"Some day we'll have allocation helpers that allocate large CPU masks
dynamically, but in the meantime we simply cannot allow cpumasks this large." It seems something which can be done easily for the 2.6.28 kernel.
Kernel prepatch 2.6.27-rc5 Posted Aug 29, 2008 16:30 UTC (Fri) by iabervon (subscriber, #722) [Link]
Depends somewhat on how well -next is working ahead of the merge window, I'd say. The issue is that new users of cpumask_t show up frequently, and these will show up using the API available when they were written. So if the API shows up in the 2.6.28 merge window, the other code showing up in the same merge window won't be using it, and will either have to be fixed afterwards or will have to push out supporting tons of CPUs to 2.6.29. If -next pushes developers to merge the API ahead of their particular changes, such that there aren't a ton of new users of the old style added in the 2.6.28 merge window, it should be possible to get done earlier.
|
|
||||||||||||