[07:38] <pekkari> Hi, any easy way to get the kernel config file used for linux-image packages of different series?
[07:39] <apw> pekkari, they are installed with the kernels in /boot, and are collected here
[07:46] <pekkari> apw: fine thanks!
[07:47] <apw> ppisati, http://kernel.ubuntu.com/~kernel-ppa/config/
[07:47] <apw> sorry got distracted getting the url
[07:48] <apw> pekkari, http://kernel.ubuntu.com/~kernel-ppa/config/
[07:48] <apw> even
[07:58] <apw> xnox, hey ... there is a kernel rebuild in ppa:canonical-kernel-team/ubuntu/unstable which looks to have the right bits in s390x .udebs are you able to confirm
[08:23] <xnox> apw, that looks good. However, I am wonder if performance will be degraded on x86_64 because:
[08:23] <xnox> x86 optimised .ko modules do not appear to be in the udeb.
[08:23] <xnox> ./lib/modules/4.8.0-13-generic/kernel/arch/x86/crypto/crc32-pclmul.ko
[08:23] <xnox> ./lib/modules/4.8.0-13-generic/kernel/arch/x86/crypto/crc32c-intel.ko
[08:24] <xnox> hopefully things fallback to generic crc32[c] modules instead.
[08:24] <xnox> looks good. obviously i'll need d-i to verify, but hopefully things are fine.
[08:48] <alkisg> Is it possible to install a 4.x kernel in ubuntu 12.04? I tried e.g. with the xenial kernel, but the "kmod" dependency isn't satisfied...
[08:48] <apw> xnox, yep, that we can fix
[08:48] <apw> (after beta) 
[08:49] <apw> alkisg, the newest kernel we offer there is lts-trusty 3.13
[08:50] <alkisg> apw, thanks, a user reports that he has sound in 16.04 but not in 12.04, even with the -trusty kernel there
[08:50] <alkisg> (12.04 is his normal installation, 16.04 a live cd)
[08:50] <alkisg> So I was trying to see if an even newer kernel in 12.04 would solve the issue
[08:52] <apw> i would guess that the modutils/kmod change is more about the transitional package for the old name going away
[08:52] <apw> so you might find forcing that on works just fine
[08:53] <alkisg> Thanks, trying even with broken dependencies...
[10:00] <alkisg> Nah the user said that the 4.x kernel didn't even boot
[16:48] <smoser> hey...  i just marked https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626158 as kernel related.
[16:48] <ubot5`> Ubuntu bug 1626158 in linux (Ubuntu) "image won't boot after upgrading to yakkety's 4.8 kernel because efi" [Critical,Confirmed]
[19:59] <chalbersma> Is this Ask Ubuntu Accurate (http://askubuntu.com/questions/804111/is-no-reboot-kernel-patching-enabled-in-16-04)? Is there now live kernel patching in Ubuntu 16.04? I asked on #ubuntu and they said they didn't think so but I should check with you guys.
[20:38] <dsmythies> Ever since mainline kernel 4.7-rc5, I have been observing sometimes extreme load averages and over 2000 kworker processes (8 CPUs and up to 258 threads per cpu, maybe more).
[20:38] <dsmythies> Particularly immediately after boot.
[20:38] <dsmythies> Eventually (5 minutes +- a few seconds) the kworker threads go away, but might return depending on what root activity is going on (it doesn't happen for user activities).
[20:38] <dsmythies> The issue is somehow related to the massive kernel configuration changes between 4.7-rc4 and 4.7-rc5, and if I compile say 4.8-rc7 using the old kernel configuration, the issue does not occur.
[20:38] <dsmythies> If I do "scripts/diffconfig .config-4.7.0-040700rc4-generic .config-4.7.0-040700rc5-generic" there are 2249 lines of changes.
[20:38] <dsmythies> I have compiled several kernels with my best guess at some configuration reversions, but so far have not been able to isolate the exact change that introduced the issue.
[20:39] <dsmythies> This work has all been on my main test computer, which is 16.04 server based. However today the same thing was observed on a 16.10 based Laptop test computer, after it upgraded to 4.8.0-11-generic.
[20:39] <dsmythies> It has two CPUs and I observe up to 516 koworker threads, when the issue occurs (used to be about 11 max).
[20:39] <dsmythies> Does anyone know which kernel configuration change is responsible? And if this is behaviour is actually O.K.?
[20:39] <dsmythies> To be clear the kworker processes are mostly idle, and the load average seems to be high only because the queue happened to be huge on a sample boundary. This is NOT a hogging the CPU issue.
[20:45] <rtg> dsmythies, try reducing CONFIG_NR_CPUS=8192 to 256 or something low like that.
[20:49] <dsmythies> rtg: O.K. that was a change between 4.7-rc4 and 4.7-rc5: "NR_CPUS 8192 -> 512", and it is one that I have not yet tried reverting.
[20:50] <rtg> dsmythies, it just seems like that is a lot of worker threads. What file system do you use ?
[20:58] <dsmythies> rtg: my main disk is ext4, on both computers.
[20:59] <rtg> huh, I've not observed that many threads, though I haven't looked recently
[21:00] <rtg> one of my 4-way servers does have 589 kworker threads
[21:01] <rtg> dsmythies, if that does turn out to have an impact, please start a bug and assign me to it (timg-tpi). I'm EOD for now
[21:02] <dsmythies> rtg: on my server, it occurs every half hour, when CRON runs the php clean up. i.e. /usr/lib/php/sessionclean. I also have now created a way to do it simply myself.
[21:02] <dsmythies> rtg: O.K.
[21:31] <dsmythies> does anyone know what rtg meant by "(timg-tpi)"? (3 lines above).
[21:32] <dsmythies> reverting CONFIG_NR_CPUS made no difference.
[21:33] <apw> dsmythies, that is his launchpad id
[21:43] <dsmythies> apw, aghh thanks.