=== gerald is now known as Guest7902
[10:15] <genkgo> apw: did you finish building the new kernels regarding the hyperv problem or did jsalisbury?
[11:05] <apw> genkgo, i don't know, i left that with him sorry
[11:09] <genkgo> apw: aight, then i will contact him when he returns here
[11:51] <Taloth> Is there a specific release planning for trusty 3.13.0-53 or just "when it's ready?". I'm anxious for -54 :)
[12:24] <henrix> Taloth: 3.13.0-53.89 has been released, right?
[12:25] <henrix> Taloth: at some point next week you should have the -54 in -proposed (a new SRU cycle begins next week)
[12:26] <Taloth> Yeah, didn't check the repo... oops there. Hopefully that means... Yup -54 is what I was after. 
[12:26] <Taloth> Tnx.
[12:27] <Taloth> Guess I can finally get some users to test those fixes next week.
[14:20] <cyking> Good morning!
[15:40] <mnaser> If I ran into a bug in the current Ubuntu Kernel, should I report that to upstream or report it Ubuntu?
[15:40] <mnaser> I have the full dmesg and dumps from linux-crashdump which I hope would help resolve it
[17:02] <LocutusOfBorg1> mnaser, can you reproduce with an upstream vanilla kernel?
[17:02] <LocutusOfBorg1> also testing debs from here http://kernel.ubuntu.com/~kernel-ppa/mainline/
[17:02] <LocutusOfBorg1> might be useful to understand if the bug is still there
[21:24] <smirnoff_> Hello. We’re hitting data corruption issues on ext4 under heavy load, introduced in 3.13.0-49 release, pinpointed it to 74fb93abc863b9ff5d1a28c3d9d729e29fd570af in ubuntu-trusty
[21:25] <smirnoff_> I saw bunch of ext4 commits going to 3.16 and 3.19 releases - are there any plans to merge them to 3.13?
[22:50] <ePirat> hello
[22:51] <ePirat> I have Linux 3.19.0-16-generic (shipped with ubuntu vivid vervet) installed, what would be a previous versions and other previous versions of that kernel and where to optain them?
[22:51] <ePirat> (doing kernel bisect and want to make sure to choose everything correct this time)
[22:51] <ePirat> unfortunately links on wiki are all not helpful at all
[23:15] <awreece> I'm trying to debug a perf issue in my application, so I'm trying to collect user space stack traces for calls to ftrace that take more than 10s. I've successfully managed to get ftrace to print a probe for calls to `SyS_futex` that take longer than 10s using `set_filter_function`, but this whole space is pretty confusing to me.
[23:15] <awreece> I see the `trace-cmd` sets `set_filter_function:stacktrace:unlimited` when it records kernel stack traces, but setting the equivalent for userstacktrace doesn't work
[23:16] <awreece> looking at `ftrace_trace_userstack` in ` kernel/trace/trace.c`, I see a couple of ways to abort early
[23:16] <awreece> is there a way to verify that the correct bits are set in `trace_flags`, or that this funciton is being called, etc?
[23:17] <awreece> (also -- hi -- if this is the wrong channel to be discussing in, I sincerely apologize -- could you point me in the right direction?)