=== hughhalf is now known as hugh_afk === hugh_afk is now known as hughhalf === lifelike is now known as jonalmeida [07:28] :-) === _ruben_ is now known as _ruben [13:21] /usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image.. [13:21] should that concern me> [13:21] * lamont gets 3 or 4 of those per image in kernel upgrades [13:22] lamont, i think that is odd, but likely non-fatal, i'd say file a bug against grub2 for that though [13:23] will do [15:19] ** [15:19] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [15:19] ** === zyga is now known as tarman [16:31] bjf, I've lobbed my fs testing autotest stuff your way. [16:32] cking, huh [16:32] via email? not there yet? [16:33] cking, got it [16:34] 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] 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] cking, but that's minor (i think) [16:42] bjf, ok, where do the results end up? [16:43] and how does it know where to copy them from? [16:44] 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] ## [16:46] ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting [16:46] ## [16:47] 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] cking, ok [16:48] (that's what that hack scp tries to do, which I did comment was a dirty hack ;-) [16:56] 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] bjf, you could hack the python script to just do "-f ext4" rather than "-f ext2,ext3,ext4,xfs,btrfs" [16:58] and also just run with iosched "deadline" [16:59] cking, ack, i see those lines [16:59] 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] bjf, OK, pushed the change, it will now just run 1 "test" job for 60 seconds [17:02] I have installed Kubuntu on my Acer C720P Chromebook - which work perfect after building certain drivers manually [17:02] 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] 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] The bug is https://bugzilla.kernel.org/show_bug.cgi?id=83191 [17:03] bugzilla.kernel.org bug 83191 in Input Devices "atmel_mxt_ts does not work until suspend/resume" [Normal,New] [17:03] 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] I can't seem to find the exact kernel sources for http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17-rc6-utopic/ [17:04] I did find various text on ubuntu.com that seem to contradict each other. [17:04] 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] Does anybody know how to do that? [17:05] cking, cool, will let you know when i've finished integration === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues September 30th, 2014 - 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. [17:29] 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] 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:27] Launchpad bug 1368444 in linux (Ubuntu) "Add support for ForcePads found on HP EliteBook Folio 1040" [High,Triaged] [19:30] pkern, you could request that the 3.13 stable maintainer (kamal) add it to his queue [19:44] 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] 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] pkern, yes, it'll migrate from 3.13-stable into into the Trusty kernel too . . . eventually. ;-) [19:51] 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] 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] We'll probably need to roll out own dkms module if so. [19:52] pkern, yes, just missed the window [19:52] *our [19:53] Is my estimate off or realistic? :) [19:53] pkern, we will turn the crank again in 3 weeks === manjo` is now known as manjo [21:21] 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] The machine at .12 is ubuntu 12.04 - the other local machine is ubuntu 14.04. The remote machine is centOS 5. [21:25] I control all 3 [21:26] 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] 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] Which is why I'm here :) since the kernel seems to be complaining about it.