[08:28] <popey> seems we have a regression in trusty kernel -66 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1508787
[08:29] <popey> This caused us some fun on wednesday when trying to record a podcast over mumble. One person was on trusty and couldn't sustain a mumble connection at all.
[08:48] <smb> popey, it might be but sounds like limited to certain audio (as I use mumble fine with that kernel)
[08:48] <popey> smb: how do you mean "certain audio"?
[08:48] <popey> oh, certain audio chipsets?
[08:49] <smb> Oops, yeah that
[08:49] <smb> Need to get back to that report and ask for info with old kernel so we may see differences
[08:50] <popey> I have had a couple of other people tell me they have the same issue, dunno what hardware they're on.
[08:51] <smb> Yeah. The description sounds like pmumble/pulsaudio is somewhat struggeling to send audio to the spreaker sink/stream
[08:51] <smb> But I have not had yet much tim eto look into details
[08:55] <smb> henrix, eeerm ^ sooorry 
[08:57] <henrix> smb: smb aka "the bearer of the bad news" :-)
[08:57] <smb> it wasn't me
[08:58] <smb> it was popey 
[08:58] <henrix> heh
[08:58] <henrix> i was looking at the bug but couldn't find any really useful info.  i'll have a look at the commits in that release to see if something pops up
[09:27] <smb> henrix, Yeah I think we need to figure out more about what codec is used there. XPS13 might be unfortunate to be wider spread but ... fright now only mild panic. It's not like data is in danger
[09:27] <smb> fright -> right... though close to Halloween maybe fright is true too
[09:53] <henrix> smb: popey: ok, i just can't find anything obvious in the last release for causing that (sorry, got distracted with other stuff)
[09:53] <henrix> so, i guess a bisect is the obvious option here
[09:53] <henrix> as it seems to be easily reproducible in that hw
[09:54] <popey> Ok, will have a chat with the reporter later on.
[09:57] <smb> henrix, popey Yeah seems no change under sound... 
[09:57] <popey> hmmm
[09:57] <smb> popey, maybe trying to strace mumble/pulseaudio leads to some hints
[12:58] <rtg> bjf, a definite regression here (if you haven't already seen it): https://bugs.launchpad.net/bugs/1508510
[12:59] <bjf> rtg, yes, smb and henrix are looking at it
[12:59] <smb> yes, not really sure about this yet. For Trusty there is a commit that looks a bit odd
[13:00] <henrix> smb: yeah, i'm building a test kernel with that commit reverted.  will post a link in the bug soon
[13:00] <smb> Though that is a cherry-pick for lts-u and that has been reported having the same issue
[13:00] <henrix> smb: and btw, here's a shot in the dark: commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61
[13:00] <henrix> :)
[13:01] <henrix> (just found it and caught my attention... may be completely unrelated ;) )
[13:02] <smb> henrix, yeah. at least that plays around with the checksumming type flag as well and that seems to be triggering things ... maybe
[13:05] <smb> henrix, did you see that being fixed up upstream? 31b33dfb0a144469dd805514c9e63f4993729a48
[13:06] <henrix> smb: heh, yeah.  i was looking at that too :)
[13:06] <henrix> ugh, what a mess
[13:08] <smb> henrix, hmm... but was that initial one in either lts-u or t? I fail to see it in the log... 
[13:10] <henrix> smb: oh, no.  i found these accidentally upstream, that's why i said "a shot in the dark".  davem's sent these to be include in next stable releases
[13:10] <smb> henrix, ah 
[13:10] <henrix> smb: so, sorry for the distraction ;)
[13:20] <henrix> smb: ok, posted a request for test with a kernel reverting commit 89c22d8c3b27 ("net: Fix skb csum races when peeking")
[13:20] <smb> henrix, ok cool... so lets see what happens
[13:35] <bananapie> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1507150
[13:36] <bananapie> The guy doing traige told me to refile the bug using 'ubuntu-bug linux'. He didn't say if I should report the bug using the normal kernel package or the upstream package. Which should I file the report with ?
[13:43] <bjf> bananapie, should be using the normal kernel package
[13:43] <bananapie> ok. Thanks.
[14:27] <smb> henrix, ah and btw, just figured I can reproduce this. just not immediately on mount (at least if the mounted folder is relatively empty) and for me the nfs-server gets this when I copy stuff there
[14:30] <henrix> smb: ah, cool!  so... maybe you want to run the test kernel? :-)
[14:32] <smb> henrix, I thought but not that simple... that is my NAS box and that user 32bit ... :-P But I got other hw... just needs a minute longer... ;)
[14:34] <henrix> smb: oh, ok.  i can give you a 32-bits version too... but i guess you don't want to mess with your NAS system :)
[14:34] <smb> henrix, not that deliberately
[14:34] <smb> :)
[14:34] <henrix> heh
[15:31] <smb> henrix, Of course no luck in reproducing with any kernel on that other machine... though it even would have the same variant of NICs
[15:32] <henrix> smb: heh, ok.  i'm also working on trying to reproduce here
[15:52] <henrix> smb: how exactly were you reproducing the issue?  just remote mount and copy a file into the server?  or more complex than that?
[15:53] <smb> henrix, yeah, well using -overs=3,udp as being told in the report on the mount command
[15:53] <smb> and copy a subdir to the server (about 2G)
[15:54] <henrix> smb: oh, ok.  let me try that
[16:02] <henrix> smb: aha! success!
[16:02] <smb> henrix, oh... that sounds good... I seem to be doing something wrong now 
[16:24] <smb> henrix, So were you able to prove anything?
[18:01] <henrix> smb: sorry, missed your message
[18:02] <henrix> smb: yes, i was able to reproduce.  reverting the commit fixes it
[18:02] <henrix> (took me a while to run the test kernel due to linux-signed stuff... yuk)
[18:04] <henrix> smb: ahh! and someone else commented on the bug confirming that
[18:05] <henrix> bjf: looks like we have a trusty respin in the horizont ^
[18:05] <henrix> smb: i'm still waiting to see if the original reporter can confirm this
[18:11] <bjf> henrix, ack ... looking forward to it
[18:12] <henrix> bjf: heh, me too
[18:12] <henrix> not
[18:27] <smoser> hey. 
[18:27] <smoser> so say i follow https://wiki.ubuntu.com/Kernel/LTSEnablementStack
[18:27] <smoser> and apt-get install linux-generic-lts-vivid
[18:28] <smoser> whath happens to me in 14.04.5 ?
[18:28] <smoser> will apt-get dist-upgrade install me a supported kernel?
[18:29] <apw> smoser, you never get upgraded to a newer lts-X, but you will be told you should update to it
[18:29] <apw> to lts-x
[18:29] <smoser> ok. thanks.
[18:30] <rtg> smoser, we support lts-vivid for the life of 14.04
[18:30] <smoser> oh?
[18:31] <rtg> smoser, utopic is already in that phase
[18:31] <rtg> lts-utopic that is
[18:31] <smoser> you're sure about that ?
[18:31] <apw> rtg, i don't think that is correct, at .5 we only support lts-x
[18:31] <apw> ogasawara, ^
[18:31] <smoser> yeah. i dont think you are right :)
[18:31] <rtg> smoser, would I lie to you ?
[18:31] <smoser> *someone* is lying to me
[18:31] <smoser> https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BAC8-Support.A14.04.x_Ubuntu_Kernel_Support
[18:31] <smoser> you or that picutre
[18:31] <rtg> oh, thats right. what apw said.
[18:32] <apw> smoser, that picture is correct as far as i know
[18:32] <apw> smoser, just the drop isn't automatic
[18:32] <smoser> it'd be nice if that picture labelled (hwe-u == 3.16, hwe-v == 3.19 , hwe-w == 4.2 )
[18:32] <smoser> as the picture is very handy. 
[18:32] <ogasawara> indeed, what apw says is correct
[18:32] <smoser> but missing that bit of data useful for mere kernel mortals
[18:33] <ogasawara> smoser: I'll add that to the diagrams
[18:33] <smoser> thank you all.