=== hughhalf is now known as hugh_afk | ||
=== hugh_afk is now known as hughhalf | ||
=== lifelike is now known as jonalmeida | ||
zyga | :-) | 07:28 |
---|---|---|
=== _ruben_ is now known as _ruben | ||
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:21 | |
apw | lamont, i think that is odd, but likely non-fatal, i'd say file a bug against grub2 for that though | 13:22 |
lamont | will do | 13:23 |
jsalisbury | ** | 15:19 |
jsalisbury | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 15:19 |
jsalisbury | ** | 15:19 |
=== zyga is now known as tarman | ||
cking | bjf, I've lobbed my fs testing autotest stuff your way. | 16:31 |
bjf | cking, huh | 16:32 |
cking | via email? not there yet? | 16:32 |
bjf | cking, got it | 16:33 |
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:34 |
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:42 |
cking | and how does it know where to copy them from? | 16:43 |
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:44 |
jsalisbury | ## | 16:46 |
jsalisbury | ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting | 16:46 |
jsalisbury | ## | 16:46 |
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:47 |
bjf | cking, ok | 16:48 |
cking | (that's what that hack scp tries to do, which I did comment was a dirty hack ;-) | 16:48 |
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:56 |
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:58 |
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 | 16:59 |
cking | bjf, OK, pushed the change, it will now just run 1 "test" job for 60 seconds | 17:01 |
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:02 |
ubot5 | bugzilla.kernel.org bug 83191 in Input Devices "atmel_mxt_ts does not work until suspend/resume" [Normal,New] | 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:03 |
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:04 |
bjf | cking, cool, will let you know when i've finished integration | 17:05 |
=== 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. | ||
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 | 17:29 |
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:27 |
ubot5 | Launchpad bug 1368444 in linux (Ubuntu) "Add support for ForcePads found on HP EliteBook Folio 1040" [High,Triaged] | 19:27 |
rtg | pkern, you could request that the 3.13 stable maintainer (kamal) add it to his queue | 19:30 |
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:44 |
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:48 |
kamal | pkern, yes, it'll migrate from 3.13-stable into into the Trusty kernel too . . . eventually. ;-) | 19:50 |
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:51 |
bjf | pkern, yes, just missed the window | 19:52 |
pkern | *our | 19:52 |
pkern | Is my estimate off or realistic? :) | 19:53 |
bjf | pkern, we will turn the crank again in 3 weeks | 19:53 |
=== manjo` is now known as manjo | ||
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:21 |
apb1963 | The machine at .12 is ubuntu 12.04 - the other local machine is ubuntu 14.04. The remote machine is centOS 5. | 21:24 |
apb1963 | I control all 3 | 21:25 |
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:26 |
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:28 |
apb1963 | Which is why I'm here :) since the kernel seems to be complaining about it. | 21:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!