The 3.10 kernel is out

[Posted June 30, 2013 by corbet]

Linus has released the 3.10 kernel. "In the bigger picture (ie since 3.9) this release has been pretty typical and not particularly prone to problems, despite my waffling about the exact release date. As usual, the bulk patch-wise is all drivers (pretty much exactly two thirds), while the rest is evenly split between arch updates and 'misc'. No major new subsystems this time around, although there are individual new features." Some of those new features include a number of Ftrace enhancements, the memory pressure notification mechanism, tickless operation, ARM multi-cluster power management support (part of the big.LITTLE solution), the bcache block caching layer, and much more. See the (still in-construction) KernelNewbies 3.10 page for lots of details.

(Log in to post comments)

procfs changes

Posted Jul 1, 2013 3:59 UTC (Mon) by proski (guest, #104) [Link]

Changing procfs code in external modules will take some time. Especially when backward compatibility is desired.

procfs changes

Posted Jul 1, 2013 9:19 UTC (Mon) by bmork (subscriber, #88411) [Link]

Perfect time to move the modules into mainline then :)

procfs changes

Posted Jul 1, 2013 9:38 UTC (Mon) by johill (subscriber, #25196) [Link]

Which would probably mean removing proc support anyway ;-)

The 3.10 kernel is out

Posted Jul 1, 2013 8:29 UTC (Mon) by burki99 (subscriber, #17149) [Link]

Now we are all anxious about Linux 3.11. Let's hope we get a release on August 11, 2013 to celebrate the 20th anniversary of that famous other 3.11 release.

The 3.10 kernel is out

Posted Jul 1, 2013 11:34 UTC (Mon) by dgm (subscriber, #49227) [Link]

I don't get what you mean. According to The Internet, that's all that happened that day (august 11, 1993):

- Director Oliver Stone files for divorce from Elizabeth
- NY Islander Brian Mullen, 31, suffers a mild stroke
- Pope John Paul II visits Mexico
- Red Sox Roger Clemens pitches 2,000th strike out (Danny Tartabul-NY)

Nothing really memorable. :-P

The 3.10 kernel is out

Posted Jul 1, 2013 13:47 UTC (Mon) by burki99 (subscriber, #17149) [Link]

On August 11, 1993, Microsoft released an update for Windows 3.1 known as Windows 3.11
http://en.wikipedia.org/wiki/Windows_3.1x#Windows_3.11

The 3.10 kernel is out

Posted Jul 1, 2013 14:09 UTC (Mon) by Quazatron (guest, #4368) [Link]

Some of us are still actively trying to forget that. Thanks.

The 3.11 kernel is due soon

Posted Jul 1, 2013 15:41 UTC (Mon) by Felix.Braun (guest, #3032) [Link]

Where can we sign a petition to change the codename of the 3.11 kernel to "Linux for Workgroups"?

The 3.11 kernel is due soon

Posted Jul 1, 2013 16:27 UTC (Mon) by jzbiciak (subscriber, #5246) [Link]

I remember when Windows introduced its compatibility layer to allow older apps to run on newer kernels. They called it WOW for "Windows on Windows." If Linux did something similar, ie. "Linux on Linux", well... LOL.

;-) ;-) ;-)

The 3.11 kernel is due soon

Posted Jul 1, 2013 16:40 UTC (Mon) by SEJeff (subscriber, #51588) [Link]

Linux on Linux? You mean KVM? :)

The 3.11 kernel is due soon

Posted Jul 1, 2013 17:58 UTC (Mon) by jzbiciak (subscriber, #5246) [Link]

Not exactly the same thing. Really, the ability to load 32-bit ABI binaries on a 64-bit kernel is closer to what WoW does. Not that it really matters. Just trying to make a silly joke.

The 3.11 kernel is due soon

Posted Jul 1, 2013 20:55 UTC (Mon) by yann.morin.1998 (subscriber, #54333) [Link]

> Linux on Linux? You mean KVM? :)

Or even more ancient: UML, User-Mode Linux. ;-)

Regards,
Yann E. MORIN.

The 3.11 kernel is due soon

Posted Jul 1, 2013 17:48 UTC (Mon) by hmh (subscriber, #3838) [Link]

Meh, we do have it.

But we did it in two stages: 1. a kernel/userspace ABI that is stable enough where it matters (mostly the syscalls), and 2. process personalities/execution domains (refer to personality(2)). Heck, we can still run libc5+a.out crap from the past millenium.

So we will have to call 3.11 "The Defenestrating War Hamster" or something like that :p

The 3.11 kernel is due soon

Posted Jul 1, 2013 18:00 UTC (Mon) by jzbiciak (subscriber, #5246) [Link]

Which raises the almost koan-like question: How do you defenestrate Windows?

The 3.10 kernel is out

Posted Jul 1, 2013 12:37 UTC (Mon) by meuh (subscriber, #22042) [Link]

Microsoft Windows 8.11 is not yet released !

The 3.10 kernel is out

Posted Jul 1, 2013 15:38 UTC (Mon) by pr1268 (subscriber, #24648) [Link]

I dunno... It's likely all the Microsoft fanboys will start shooting their mouths off claiming that Linux is 20 years behind Microsoft in release version.

Of course, being a "Microsoft fanboy" isn't something to brag about these days. And besides, they're a dying breed—they're all becoming Apple fanboys (sigh...).

bcache

Posted Jul 1, 2013 8:40 UTC (Mon) by epa (subscriber, #39769) [Link]

Good to see bcache included in the kernel. Now let's see which distributions start making use of it - e.g. if installing on a machine with one spinning disk and one SSD.

bcache

Posted Jul 2, 2013 8:18 UTC (Tue) by jezuch (subscriber, #52988) [Link]

Regarding bcache, I still don't know how it relates to the other thing - was it dm-cache? - and why I should use one or the other?...

SysV IPC scalability improvements

Posted Jul 1, 2013 10:20 UTC (Mon) by sickpig (subscriber, #28685) [Link]

I'm quite eager to test this one:

http://kernelnewbies.org/Linux_3.10#head-5c725e42ba8f05ed...

from the performance numbers outlined in lkml original thread (*) it seems that databases as Postgres will greatly benefit in terms of tps increase

Andrea

(*) http://thread.gmane.org/gmane.linux.kernel/1460761

The 3.10 kernel is out

Posted Jul 1, 2013 16:33 UTC (Mon) by mgross (subscriber, #38112) [Link]

Will 3.9 or 3.10 be this years LTS kernel?

The 3.10 kernel is out

Posted Jul 1, 2013 17:54 UTC (Mon) by hmh (subscriber, #3838) [Link]

I hope 3.11 will be the one:

1. Endless jokes possibilities due to WfW;

2. First release to support early microcode updates for both Intel (3.9) and AMD (3.11) processors on x86, although you could backport this to 3.9/3.10 as it is self-contained;

3. Non-joke support for AMD Radeon power management (too bad it only targets R600 and up, I'd like to see it also working on R300).

The 3.10 kernel is out

Posted Jul 1, 2013 18:41 UTC (Mon) by Thalience (subscriber, #4217) [Link]

Regarding Radeon power management: Pre-r600 chips do not have the power management hardware (clock gating, etc) that is enabled in 3.11.

The 3.10 kernel is out

Posted Jul 2, 2013 13:22 UTC (Tue) by hmh (subscriber, #3838) [Link]

Even the Mobility Radeons like the X300 and X600? The proprietary driver knows something we don't about these chips. Although this is well in the diminishing returns area (except maybe because of thinkpads).

The 3.10 kernel is out

Posted Jul 18, 2013 13:12 UTC (Thu) by nix (subscriber, #2304) [Link]

Early microcode updates for Intel are very nice, but... did we ever get any way to translate the microcode updates that Intel actually releases into something the kernel can support? Last I looked (a couple of years ago, admittedly) Intel had been releasing microcode updates for about five years in a form the kernel simply couldn't use, and nobody had written a converter...

Early microcode update on distros

Posted Jul 18, 2013 23:02 UTC (Thu) by hmh (subscriber, #3838) [Link]

Yes. Debian supports early updates on Debian Jessie (testing) and Sid (unstable), and also on Debian Wheezy (current Debian stable) through the use of the wheezy-backports archive).

[1] as long as you install the firmware-nonfree package (which will bring in the intel-microcode package), which are technically not part of Debian proper and thus never installed by default, but they're included in non-free.

Take a look at the iucode-tool and intel-microcode packages in Debian, or alternatively at:

http://anonscm.debian.org/gitweb/?p=users/hmh/iucode-tool...
http://anonscm.debian.org/gitweb/?p=users/hmh/intel-micro...

Which Ubuntu also uses.

I will add support for AMD early updates to Debian in time for the 3.11 kernel release.

Fedora and SuSE likely do their own thing to support early updates as well (they've been using binary microcode containers for a longer time than Debian, FWIW).

Maybe I did something wrong

Posted Jul 1, 2013 16:54 UTC (Mon) by dskoll (subscriber, #1630) [Link]

... but 3.10 won't even boot for me. I copied a working 3.9.5 .config file over and did "make oldconfig" and then built a Debian package.

I got an error about missing i8042 controller and then the kernel complained it couldn't find init and dropped me into busybox.

Maybe I did something wrong

Posted Jul 9, 2013 0:21 UTC (Tue) by theophrastus (guest, #80847) [Link]

yep - you and me both.

i've tried minimal tweaks (via make oldconfig and menuconfig) off a
.config from working 3.10.0-rc1 and it won't mount my root (which has never given me trouble before). so is it something ext4? or SATA? it's the correct UUID and it mounts just fine under 3.10.0-rc1, but 3.10.0 no luck. and there's very little google/search presence on this problem (yet...) frustrating, isn't it? i'm stuck at 3.10.0-rc1 and i really don't know what to report bug-wise "Gave up waiting ... root device" -sigh-

Maybe I did something wrong

Posted Jul 17, 2013 17:23 UTC (Wed) by cosmoecho (guest, #68970) [Link]

Same thing with Debian starting 3.10 release, 3.11.0-rc1+. 3.10.0-rc4+ works for me.

Maybe I did something wrong

Posted Jul 17, 2013 20:57 UTC (Wed) by theophrastus (guest, #80847) [Link]

i've a new theory (for what it's worth) changes to how initrd.img files are constructed and interpreted between initramfs-tools (version 0.113) and the scripts associated with make-kpkg (--initrd) have resulted in these jam-ups.

for instance there's a change in the format of initrd.img files at least as far as the utility "file" sees them. for initrd.img files built with versions prior to 0.113, i see: "gzip compressed data..." and since, i see: "ASCII cpio archive (SVR4 with no CRC)". if one goes ahead and either runs "lsinitramfs" or "cpio -t" on these latter files, despite them being rather large (>5Mb), one sees *no modules*; just a small intel microcode.bin file is listed. none of the latter "xz"-ish compression utilities accept them as their own.

i suspect this is a very niche problem. but it sure is annoying. my system is very generic 64bit intel, but i am using debian kernel builds... hmm.

Maybe I did something wrong

Posted Jul 18, 2013 0:31 UTC (Thu) by jimparis (subscriber, #38647) [Link]

If you're using prebuilt kernels, I don't think make-kpkg is involved. Maybe "update-initramfs -v -u -k all" will show why the initrds are different?

Maybe I did something wrong

Posted Jul 18, 2013 3:10 UTC (Thu) by theophrastus (guest, #80847) [Link]

i am compiling kernels so i'm not using "pre-built". at your kind suggestion, i ran "update-initramfs -v -u -k all" (even-though it shouldn't be necessary as part of using make-kpkg); an impressive number of screens scrolled by as all my initrd.img were rebuilt (no errors). but unfortunately the result remains the same:

3.10.0-rc1 boots up just fine (finding the usual root)
and
3.10.0 declares it can't find the very same root (same UUID) and drops to busybox.

as much the same .config file was used to build both of these as possible (result of performing "make oldconfig" on one to get the other) ...so there has to have been some change between 3.10.0-rc1 and 3.10.0 that affects initrd.img files... i think.

the one difference as a result of running "update-initramfs -v -u -k all" being that now "file" sees only one of my kernel's associated initrd.img as being gzip, now the rest appear as: "ASCII cpio archive (SVR4 with no CRC)" ...hnnnn.

Maybe I did something wrong

Posted Jul 18, 2013 23:09 UTC (Thu) by hmh (subscriber, #3838) [Link]

You're using an hybrid initramfs image that has an early initramfs image prepended to it. We do not have userspace tools that are compatible with the kernel initramfs loading process (which will load any number of properly concatenated initramfs images one after the other, regardless of compression type, using the cpio EOF markers as hardlink barriers).

Purge intel-microcode (which should generate a microcode-less initramfs. If it doesn't, re-run update-initramfs), reboot, and if, and *only if* that fixes the problem, please file a severity grave bug post-haste on package intel-microcode will _all_ the relevant data. The bug isn't likely to be in intel-microcode, but I will track down and reassign to whatever can't handle hybrid initramfs images.

Maybe I did something wrong

Posted Jul 19, 2013 0:52 UTC (Fri) by theophrastus (guest, #80847) [Link]

I wasn't sure what you meant by "purge intel-microcode", but, i did both "dpkg --purge intel-microcode" and built a new 3.11.0-rc1 (now) with:
# CONFIG_MICROCODE is not set
# CONFIG_MICROCODE_INTEL_EARLY is not set

but no luck. it still hangs with "Gave up waiting for root device ...<correct UUID> ...does not exist" and drops to busybox. whereas 3.10.0-rc1 finds the same root device no problem.

purging intel-microcode and re-(re-re-)running "update-initramfs -v -u -k all" did have one apparently positive effect, now the "file" utility reports all my initrd.img files as: "gzip compressed data..." which certainly appears more normal.

thank you very much for the suggestion! i really have come to hate the whole initramfs system; it offers so little in terms of diagnostic messages. and (dammit) the same .config file that generated a functional 3.10.0-rc1 fails via "make oldconfig" to make a functional kernel for 3.11.0-rc1

Maybe I did something wrong

Posted Jul 19, 2013 2:30 UTC (Fri) by jimparis (subscriber, #38647) [Link]

I think initramfs is actually pretty great for debugging. Remove the quiet parameter from the kernel command line and you can often see the problem and try to fix it. I upgraded from 3.6 to 3.9 on one of my systems recently and had a similar error. Turns out the lvm detection ran before the disk showed up for some reason -- I just had to run /scripts/local-top/lvm2 then exit the busybox shell to get the system to boot up right.

(If I remember correctly, updating initramfs-tools to the latest version and rebuilding the initrd fixed that problem, although I was in a hurry and don't remember exactly what the cause was)

Maybe I did something wrong

Posted Jul 19, 2013 3:20 UTC (Fri) by theophrastus (guest, #80847) [Link]

helpful suggestions all, thank you. i never run a "quiet" kernel parameter because *normally* i find the boot up process very edifying. but in this case -all- i get for error messages is (sorry for repeating myself) "Gave up waiting for root device ...<correct UUID> ...does not exist" then busybox. no hint as to why this kernel compile can't find the root device when all those previous to 3.10.0-rc1 can.

currently i'm trying to tweak just about every CONFIG_... that was introduced between 3.10.0-rc1 and 3.10 to see if that allows for a initrd.img root device mount -sigh-

CONFIG_ACPI_VIDEO CONFIG_ARCH_WANT_GENERAL_HUGETLB CONFIG_ARCH_WANT_HUGE_PMD_SHARE CONFIG_CRYPTO_CRCT10DIF CONFIG_DECOMPRESS_LZ4 CONFIG_DOUBLEFAULT CONFIG_FONT_SUPPORT CONFIG_GENERIC_NET_UTILS CONFIG_HAVE_ARCH_SOFT_DIRTY CONFIG_HAVE_DEBUG_STACKOVERFLOW CONFIG_HAVE_KERNEL_LZ4 CONFIG_LZ4_DECOMPRESS CONFIG_NET_FLOW_LIMIT CONFIG_NET_LL_RX_POLL CONFIG_NET_VENDOR_ARC CONFIG_RD_LZ4 CONFIG_RTC_HCTOSYS CONFIG_RTC_HCTOSYS_DEVICE CONFIG_RTC_SYSTOHC CONFIG_SND_MAX_CARDS CONFIG_THERMAL CONFIG_THERMAL_GOV_USER_SPACE CONFIG_USB_OHCI_HCD CONFIG_USB_OHCI_HCD_PCI CONFIG_USB_OHCI_HCD_PLATFORM CONFIG_USB_OHCI_LITTLE_ENDIAN CONFIG_VIDEO_OUTPUT_CONTROL CONFIG_X86_PKG_TEMP_THERMAL

Maybe I did something wrong

Posted Jul 19, 2013 3:36 UTC (Fri) by jimparis (subscriber, #38647) [Link]

> i never run a "quiet" kernel parameter because *normally* i find the boot up process very edifying. but in this case -all- i get for error messages is (sorry for repeating myself) "Gave up waiting for root device ...<correct UUID> ...does not exist" then busybox. no hint as to why this kernel compile can't find the root device when all those previous to 3.10.0-rc1 can.

It's hard to debug without more information (even non-error output). Without anything more specific, some other suggestions would be: From busybox, check dmesg to see if/when the HDD showed up, check whether the device actually exists in /dev, check whether LVM or RAID volumes were set up (if you're using them). Compare the complete exact boot output from the working kernel and the nonworking, see where they differ (either with netconsole, or just a digital camera). Extract the initrds and see if they differ.

> no hint as to why this kernel compile can't find the root device when all those previous to 3.10.0-rc1 can.

It could be something as hidden as a timing difference in when the disks get detected, for example. If it's really a kernel issue then a bisect is the more surefire way to find it.

Maybe I did something wrong

Posted Jul 19, 2013 5:00 UTC (Fri) by theophrastus (guest, #80847) [Link]

I will certainly check though dmesg via busybox; that's an excellent suggestion. i can say that an "ls /dev" via busybox shows *no* "sda" (normally the root device), nor any "sd*". would this indicate some failure to include SATA/SCSI module in the initrd.img? and yet a "lsinitramfs -l initrd.img..." shows many scsi and ata related *.ko files.

no LVM no raid (no btrfs) with this system. it's quite plain-jane; hence some of my surprise.

doing a kernel (i'm presuming git-) bisect is intriguing; and i admit i have trouble wrapping my head around it. i have a working 3.10.0-rc1 and a version at 3.11.0-rc1 that hangs. do i then "git checkout <kernel-version>" in a bisection, compile, and see if each one hangs?

thank you to all you folks that have commented for me! it's all be helpful towards a solution (...i'm sure)

Maybe I did something wrong

Posted Jul 19, 2013 12:07 UTC (Fri) by cortana (subscriber, #24596) [Link]

$ git bisect start
$ git bisect bad badversion
$ git bisect good goodversion

Git will then choose a revision half way between badversion and goodversion. Test it, and then run git bisect bad or git bisect good as appropriate. Repeat until git spits out the first bad commit.

Maybe I did something wrong

Posted Jul 19, 2013 18:05 UTC (Fri) by theophrastus (guest, #80847) [Link]

git rev-list v3.10-rc1 v3.10 | wc -l => 377485
log2(377485) : 18.52

so 19 compiles at 15 minutes a compile.... *sigh*

but i'm getting to that point. because all else is failing me.

for instance, if something is "compiled in" as opposed to called for as a module ("y" as opposed to "m" in "make menuconfig") will that somehow leave out that functionality from the initrd.img?