[03:06] <hans109h_> Re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981 what can I do to test why the mainline kernel wouldn't load?
[03:06] <ubot2> Launchpad bug 1313981 in linux (Ubuntu) "Kernel disabling serial port ttyS0 on boot" [Medium,Confirmed]
[07:05] <mlankhorst> regression testing? :P
[08:17] <Chainsaw> Good morning. Can you let me know if you have sufficient information on https://bugs.launchpad.net/ubuntu/+source/linux-lts-saucy/+bug/1314764 please.
[08:17] <ubot2> Launchpad bug 1314764 in linux-lts-saucy (Ubuntu) "[Fujitsu Lifebook E744/E754] i8042 without psmouse means no keyboard at decryption prompt" [Undecided,Confirmed]
[08:33] <apw> Chainsaw, looks pretty clear, it sounds like a bug in initramfs-tools not putting that module in
[08:34] <Chainsaw> apw: Yes, either putting it in the initramfs by default or building it into the kernel proper will solve it.
[08:34] <Chainsaw> apw: We will make the change in the initial build, but I work for a company of shall we say.... power users.
[08:34] <Chainsaw> apw: They want to install their own laptops, and then get confused and annoyed when it "don't work".
[08:34] <apw> yeah, they tend to do that indeed :)
[08:35] <apw> if initramfs-tools wasn't an utter mess this would be a trivial fix i am sure
[09:39] <apw> hans109h_ (N,BFTL), it looks like the device probe has failed; details in your bug
[11:02] <apw> Chainsaw (N,BFTL), I think i have fixed this in the packages I have pointed to in your bug, if you could test those and let us know on the bug pls.
[11:36] <soren> Do you guys run any benchmarks to see how kernel updates affect performance?
[11:39] <apw> there was a plan for that, and some work done, what sort of benchmarks were you looking at
[11:41] <soren> I was actually looking for inspiration in terms of picking some good benchmarks :)
[11:42] <apw> i guess it depends what you are trying to check on
[11:43] <soren> My intent is to try to compare various cloud providers. Nothing more specific than that.
[11:44] <soren> I imagine I want to test disk I/O, CPU speed, memory I/O and other stuff.
[11:44] <soren> ...and if you guys already had a ready-to-go test suite, that'd just make my life easier.
[11:45] <apw> stress is good for memory/cpu, xfstest is good for filesystems, but no i don't think we have anything specifici
[11:48] <soren> No worries. Thanks.
[11:53] <cking> soren, stress-ng in my ppa:white is also handy
[11:54] <soren> cking: Cool, thanks!
[11:55] <cking> soren, i've tried out fs tools such as bonnie++, tiobench but they all have their pros and cons
[11:56] <cking> iozone too
[11:57] <soren> cking: Phoronix has this huge test suite, but I get the impression that it's not very popular for some reason.
[11:58] <cking> soren, one needs to run a specific test multiple times and calculate std.dev. correctly
[14:20] <rtg> I'd sure like to upload 3.15-rc3 but I'm gonna have to figure out my resume issue first. 
[14:40] <rtg> apw, are you having any resume issues on your kit ?
[14:41] <apw> rtg, with 3.15 or with 3.13 ?
[14:41] <apw> though ... not so far is my answer either way
[14:41] <rtg> 3.15-rc3
[14:43] <apw> rtg, just did two s/r on my lappy her with 3.15-rc3 and nothing bad for me
[14:43] <rtg> grumble
[14:51] <trippeh> ya, -rc3 works ok here too. for suspend/resume.
[14:51] <trippeh> not tried to disk however.
[15:19] <xnox> smb: or rtg: (not sure who deals with xen) is grub1 still needed for xen in ubuntu?
[15:19] <xnox> or maybe apw ? ^
[15:20] <rtg> xnox, it would be smb, but I think he's out today.
[15:21] <apw> xnox, yeah it'd be smb, he is out till monday i think, and ... i don't personally know the answer, hallyn might
[15:21] <xnox> right, may day mayhem.
[15:21] <hallyn> sorry i have no idea.  zul might :)
[15:30] <zul> xnox:  it shouldnt
[17:13] <rtg> apw, ogasawara: www.decadent.org.uk/ben/tmp/linux-release-dates.svg - 3.17 might be really close.
[17:14] <ogasawara> rtg: yah, I was looking at http://phb-crystal-ball.org/ too
[17:14] <rtg> hmm, they differ by a month
[17:15] <rtg> oh, maybe not quite that much
[17:15] <apw> rtg, well it depends where the labelled line is, is that jan1 or jan31
[17:15] <ogasawara> rtg: I think what we've been saying that at the least it'll be 3.16 is the safe answer
[17:15] <apw> rtg, otherwise 3.17 is oct 16 or so by the graph
[17:15] <apw> which is release day
[17:15] <rtg> apw, yup, I agree
[17:16] <ogasawara> rtg: if we did 3.17, it would certainly go out the door with a later -rc
[17:16] <rtg> ogasawara, which we've done before
[17:16] <apw> we normally like to get a .N or two on though
[17:16] <ogasawara> rtg:  I guess it somewhat depends what we might be getting in 3.17 and if it's worth it
[17:16] <apw> given it goes back into the lts, is there enough time before the point release to get it lts stable
[17:17] <rtg> I guess we won't know until we get there
[17:17] <ogasawara> we'd have another 3mo before it'd go back into trusty
[17:17] <ogasawara> which really means like 2mo to get it lts stable
[17:18] <apw> yeah, so i guess we get .6 by then not toooo bad
[18:05] <sconklin> arges: to be clear, you're asking me to build my own kernel with lockdep debugging and test that? 
[18:17] <arges> sconklin: ugh sorry
[18:17] <arges> sconklin: i forgot to post the link 
[18:17] <arges> sconklin: ok updated