=== amitk is now known as amitk-afk
[06:50] <Tehdastehdas> apw, I didn't get the part about the machine not being representative of its kind, as many machines in the original slow fan bug report comments are claimed to run their fans faster and CPUs cooler in the fan control disengaged mode. I haven't tried tweaking thermald, as reading this https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues , my thermal-conf.xml and its manual page I can't understand how to redefine fan 
[06:50] <Tehdastehdas> speeds so that 'disengaged' mode would be the new highest speed.
[07:07] <Tehdastehdas> "Currently, the Linux kernel thermal ACPI module implements these controls. So, based on the validity of configuration data, this can be a very efficient method for thermal controls. But, it was observed that many systems don’t have this configuration data or have invalid data, preventing the kernel module from taking timely action." https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon
[07:17] <Tehdastehdas>  Which channel should I go to for thermald support?
[09:36] <rbasak> Is smb on holiday? Any idea when he's back?
[10:19] <apw> rbasak, yes, and err ...
[10:19] <apw> rbasak, is this about dpdk, if so arges may be in the loop
[10:30] <Tehdastehdas> I wrote about the Lenovo slow fan bug to the thermal_daemon (thermald) mailing list.
[10:40] <rbasak> apw: yeah, dpdk. Thanks. I wanted to clarify some bits about upstream's build system that smb would know, but I can look or wait until next week.
[10:40] <apw> Tehdastehdas, sound like a plan
[10:41] <apw> rbasak, arges was involved in deep review so if you have queries, do ask 
[11:35] <jpds> apw: You seen https://askubuntu.com/questions/670106/igb-detected-tx-unit-hang ?
[11:37] <apw> jpds, nope, kamal henrix a nice regression in stable for you ...
[12:19] <henrix> apw: looking
[12:21] <henrix> oh joy
[12:54] <henrix> jpds: are you able to reproduce this igb bug?
[12:56] <jpds> henrix: Nope, I saw some people in #ubuntu-server complaining about it
[12:58] <henrix> jpds: ah, thanks.  i'll try to get a test kernel built (still looking at the bug).  i'll just add a link to that kernel in the bug (bug #1492146)
[12:58] <ubot5> bug 1492146 in linux-lts-utopic (Ubuntu) "igb Detected Tx Unit Hang" [Undecided,Confirmed] https://launchpad.net/bugs/1492146
[12:59] <jpds> henrix: Asked the person to join here
[12:59] <henrix> jpds: cook, thanks
[13:02] <bananapie> Is there a page somewhere that lists the differences between Ubuntu's kernel and vanilla kernel?
[13:05] <rozie> I was hit by kernel bug http://askubuntu.com/questions/670106/igb-detected-tx-unit-hang can I expect it to be fixed in next kernel release?
[13:06] <rozie> right now I downgraded to 3.16.0-46-generic (Ubuntu 14.04 LTS). have spare machine for tests.
[13:07] <henrix> rozie: i'm looking at that bug (bug #1492146), and i'll try to have a test kernel built in a bit
[13:07] <ubot5> bug 1492146 in linux-lts-utopic (Ubuntu) "igb Detected Tx Unit Hang" [Undecided,Confirmed] https://launchpad.net/bugs/1492146
[13:07] <henrix> rozie: would you be able to test it, to see if it actually fixes the issue?
[13:11] <rozie> henrix: which solution exactly?
[13:12] <henrix> rozie: looks like a bad backport in one of the patches in the 3.16.0-48.64 kernel
[13:13] <henrix> rozie: there were a bunch of hyper-v related patches in this kernel; the test kernel will simply revert them, as i suspect that one of these patches is incorrect
[13:13] <henrix> (incorrect = bad backport)
[13:26] <henrix> rozie: i've uploaded a test kernel here: http://people.canonical.com/~henrix/lp1492146/v1/amd64/
[13:26] <henrix> rozie: i've also included in that URL the patches i'm reverting.  i believe the 'bad' one is the first one, so i had to revert them all :-/
[13:27] <henrix> rozie: if you could give it a spin would be great
[13:27] <henrix> rozie: i'll also add this URL (and request for testing) in the bug
[13:29] <rozie> OK, installing http://people.canonical.com/~henrix/lp1492146/v1/amd64/linux-image-3.16.0-48-generic_3.16.0-48.64~14.04.1~lp1492146v1_amd64.deb and http://people.canonical.com/~henrix/lp1492146/v1/amd64/linux-image-extra-3.16.0-48-generic_3.16.0-48.64~14.04.1~lp1492146v1_amd64.deb right now
[13:30] <henrix> rozie: awesome, thanks!
[13:36] <rozie> booting... I have about 1 hour left, so it would be great if we manage to fix/test it in this time
[13:37] <rozie> henrix: booted. looks stable
[13:40] <henrix> rozie: awesome, thanks.  if you're not able to reproduce the issue with this kernel, then i guess you're done for now ;)
[13:40] <henrix> rozie: we'll eventually respin this kernel again (probably today), and i'll eventually ask in the bug for people to re-test again before releasing
[13:41] <henrix> (2 'eventually' in the same sentence...)
[13:41] <rozie> I'll be probably available tomorrow around 9AM UTC
[13:43] <rozie> feel free to give specific version to test. the good thing is I have spare machine and independent access ;-)
[13:43] <rozie> if you need anything, I'm available for 45 min more today
[13:45] <henrix> rozie: awesome, thanks.  i'll ping you if i have a final version ready tomorrow
[13:58] <rozie> :-)
[14:27] <jpds> rozie: Do you have an askubuntu account to update the page?
[14:29] <rozie> jpds: I have lauhchpad, but noscript blocks CSS for askubuntu. works fine for ask.openstack
[14:30] <jpds> Hmm
[14:31] <rozie> I know, it's another channel thing ;)
[14:33] <rozie> used another browser
[14:33] <rozie> jpds: can you tak a look? any other info needed?
[14:34] <jpds> rozie: I think henrix has an eye on the ball
[15:21] <jsalisbury> **
[15:21] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:21] <jsalisbury> **
=== dgadomski_ is now known as dgadomski
[16:12] <willcooke> hi mjg59 - I was reading this the other day:  http://mjg59.dreamwidth.org/34868.html  -  did your patches get in to the kernel?
[16:45] <mjg59> willcooke: Still working on reverse engineering the Intel driver so I can figure out the blacklisting
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[16:57] <cristian_c> jsalisbury: hi
[16:59] <jsalisbury> cristian_c, hi, I never got a response from upstream.  I'll ping them again and cc the bug
[16:59] <cristian_c> jsalisbury: ok
=== henrix_ is now known as henrix
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Sep 15th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
[17:11] <rtg> henrix, kamal: ad1ed2a9dd4c435d6a3ce470211db9a8d107c3e0 should be added to the 3.19 stable kernel
[17:12] <henrix> rtg: wow! that patch has enough context to see the bug :)
[17:13] <rtg> henrix, yeah, it seems like a no brainer
[17:14] <kamal> rtg, henrix: jesus you're not kidding!  ack, I'll pick it up
[17:14] <kamal> rtg, do we know when it got broken?
[17:15] <rtg> kamal, the driver was added in 3.19, the locking fix came in 4.0
[17:15] <kamal> rtg, good.  thanks.
[17:18] <psivaa> cking: hello,
[17:18] <psivaa> Not sure if you're still interested in health-check results in http://ci.ubuntu.com/smokeng/trusty/desktop/i386/20150908/13806/health-check/
[17:18] <cking> psivaa, i'll just have a look...
[17:19] <cking> psivaa, \o/, excellent!
[17:19] <psivaa> cking: There were a couple of failures in the last couple of days and since we moved the hosts the VM installation takes place, we're wondering if the failures have anything to do with the VM host migration
[17:20] <psivaa> cking: one of such failures is https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-amd64-smoke-health-check/321/artifact/utah-810-trusty-amd64_master.run_2015-09-07_12-09-29.yaml/*view*/
[17:20] <cking> psivaa, are the failures still occurring?
[17:20] <psivaa> cking: they appear to be 'flaky'. i.e a rerun passes
[17:21] <cking> hrm, yep, the failure on the URL shown above is probably a sporadic memory allocation that skewed the rates
[17:22] <psivaa> the failed ones on https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-amd64-smoke-health-check/ have all the same test failure, but as i said they pass on reruns
[17:23] <cking> i'll eyeball those in a while, I've got some food waiting for me to be eaten..
[17:23] <psivaa> cking: sure, we'll be happy to leave that to see if that settles down. Please feel free to ping us back if you think that the host migration being any reason
[17:40] <cking> psivaa, let's see if it settles down, if not, then lets dig into it deeper
[17:41] <psivaa> cking: sounds good
=== bjf_ is now known as bjf
=== brendand_ is now known as brendand