[07:28] <zyga> :-)
[13:21] <lamont>  /usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
[13:21] <lamont> should that concern me>
[13:21]  * lamont gets 3 or 4 of those per image in kernel upgrades
[13:22] <apw> lamont, i think that is odd, but likely non-fatal, i'd say file a bug against grub2 for that though
[13:23] <lamont> will do
[15:19] <jsalisbury> **
[15:19] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:19] <jsalisbury> **
[16:31] <cking> bjf, I've lobbed my fs testing autotest stuff your way. 
[16:32] <bjf> cking, huh
[16:32] <cking> via email? not there yet?
[16:33] <bjf> cking, got it
[16:34] <cking> bjf, I've rigged up the tests to just run 2 tests for now.. so that we can pick up failures quicker than the full 20+ test run
[16:42] <bjf> cking, i may make some minor adjustments to your patch. for 1 the tests don't push results from the test systems back to the server. the server pulls the results from the test system back to itself. 
[16:42] <bjf> cking, but that's minor (i think)
[16:42] <cking> bjf, ok, where do the results end up?
[16:43] <cking> and how does it know where to copy them from?
[16:44] <bjf> cking, the autotest results all end up in the same location on the test system. if you have other results, that's easy to adjust
[16:46] <jsalisbury> ##
[16:46] <jsalisbury> ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting
[16:46] <jsalisbury> ##
[16:47] <cking> bjf, it creates a *lot* of raw data in the $srcdir/fs-test-proto/fio-tests/results directory, I'd like that data to be copied to the same place for each test run as this will give me a cumulative set of results that I can plot trends on
[16:48] <bjf> cking, ok
[16:48] <cking> (that's what that hack scp tries to do, which I did comment was a dirty hack ;-)
[16:56] <bjf> cking is there a way to run an abbreviated version of these tests so i can wring the bugs out of the jenkins jobs ?
[16:58] <cking> bjf, you could hack the python script to just do "-f ext4" rather than "-f ext2,ext3,ext4,xfs,btrfs"
[16:58] <cking> and also just run with iosched "deadline"
[16:59] <bjf> cking, ack, i see those lines
[16:59] <cking> that will reduce it down to a 30-40 minute run. I will hack my test repo to reduce the run time to a few minutes too
[17:01] <cking> bjf, OK, pushed the change, it will now just run 1 "test" job for 60 seconds
[17:02] <ferry_> I have installed Kubuntu on my Acer C720P Chromebook - which work perfect after building certain drivers manually
[17:02] <ferry_> Native support for touchpad, touch screen has now been added to linux 3.17, so I am testing this with 3.7-rc[1-6] from http://kernel.ubuntu.com/~kernel-ppa/mainline/
[17:02] <ferry_> The touchpad  atmel_mxt_ts appears to work but only after suspend/resume, there seems to be a possible initialization stuck until resume
[17:02] <ferry_> The bug is https://bugzilla.kernel.org/show_bug.cgi?id=83191
[17:03] <ferry_> The kernel developer is asking me to rebuild my kernel with CONFIG_I2C_DEBUG enabled to get the /dev/i2c-8 i2c debug interface.
[17:03] <ferry_> I can't seem to find the exact kernel sources for http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17-rc6-utopic/
[17:04] <ferry_> I did find various text on ubuntu.com that seem to contradict each other.
[17:04] <ferry_> Ideally what I would like is to pull the exact sources and build using the exact config as kernel-ppa, but only the one flag changed.
[17:04] <ferry_> Does anybody know how to do that?
[17:05] <bjf> cking, cool, will let you know when i've finished integration
[17:29] <apw> ferry_ (N,BFTL), the COMMIT file tells you what to base off, and the patches in that directory applied there are the delta to what was built
[19:27] <pkern> Could someone look into the cherry-pick in https://bugs.launchpad.net/bugs/1368444? I'm not sure how 3.13 stable maintenance works and if the generic stable@kernel.org is monitored. It hasn't been applied yet and the bug makes touchpads on recent HP ultrabooks quite unusable.
[19:30] <rtg> pkern, you could request that the 3.13 stable maintainer (kamal) add it to his queue
[19:44] <kamal> pkern, I'll make sure that the ForcePads fix gets queued up for the next 3.13-stable: 3.13.11.8.   (it would have arrived "eventually" regardless).  thanks for the heads-up!
[19:48] <pkern> kamal: Thanks! My priority is obviously getting it into the Ubuntu kernel, but it was stated that this is sort of a precondition. ;)
[19:50] <kamal> pkern, yes, it'll migrate from 3.13-stable into into the Trusty kernel too . . .  eventually.  ;-)
[19:51] <pkern> kamal: Do you have an estimate? Given the mail on -devel I guess we "just" missed this cycle so a kernel would be out at the beginning of November?
[19:51] <bjf> kamal, that makes it sound like it takes a really long time to get to trusty. if the patch hits the mailing list it will hit -proposed in about 3 weeks
[19:51] <pkern> We'll probably need to roll out own dkms module if so.
[19:52] <bjf> pkern, yes, just missed the window
[19:52] <pkern> *our
[19:53] <pkern> Is my estimate off or realistic? :)
[19:53] <bjf> pkern, we will turn the crank again in 3 weeks
[21:21] <apb1963>  About maybe twice a day my network stops responding - unable to ping router from the local machine at 192.168.0.12 (but another local machine can ping the router).  If I ifconfig up/down and add the default route back to the router everything works fine again ... until the next time it happens.
[21:24] <apb1963> The machine at .12 is ubuntu 12.04 - the other local machine is ubuntu 14.04.  The remote machine is centOS 5.
[21:25] <apb1963> I control all 3
[21:26] <apb1963>  I have an ssh connection to each machine from .12, that sits in place all day - unless I'm forced to restart the network as mentioned.
[21:28] <apb1963> syslog says: kernel: [1814573.567815] UDP: bad checksum. From 2xx.1xx.2xx.xx4:15380 to 192.168.0.12:5086 ulen 180  I'm seeing lots of these. 
[21:29] <apb1963> Which is why I'm here :) since the kernel seems to be complaining about it.