[07:32] <ppisati> yo
[08:25] <apw> yogeut
[08:25] <ppisati> yogurt!
[08:36] <apw> that indeed
[08:37] <smb> May the Schwartz be with you
[08:38] <apw> heh
[08:39] <smb> Hm... schwarz == German for black... black --> coffee 
[08:39]  * smb has a cup
[08:47] <apw> tea for me
[09:48]  * apw reboots to test some kernels
[09:55] <apw> hmmmm, oddneess
[12:00] <ppisati> bloody hdmi codec... #$@#%%^...
[12:08] <ogra_> use VGA then 
[13:21] <rtg> apw, have you followed this lowlatency issue in trusty at all ?
[13:32] <apw> rtg, yeah am following jsalisbury's work loosly
[13:32] <apw> and indeed i am running one of those on here right now, so i know its not 100% borked
[13:33] <apw> i did have one bad boot, the first one, which might indicate a timeing race, instigated by the ureadahead cache
[13:33] <apw> jsalisbury, it looked like your bug "turning off PREEMPT" made the world ok, but ... 
[13:33] <apw> i struggle to believe it is that borken given i am up and running it now
[13:34] <apw> jsalisbury, does your machine hang with it or only testers ?
[13:35]  * apw found first boot was bad, i booted with debug instead of splash and it came up, and then subsequent boots seem to work
[13:35] <apw> it also dies just when the framebuffer would be initialising, so i am wondering if we are seeing some of 'smb's issue in here
[13:35] <apw> $ cat /proc/version_signature 
[13:35] <apw> Ubuntu 3.13.0-8.27-lowlatency 3.13.2
[13:37] <smb> apw, would you happen to have you udev log (to see which of the manyfold fbs your boot gets)?
[13:37] <apw> smb, coming up
[13:37] <smb> apw, no rush :)
[13:38] <apw> smb, $ cat /proc/version_signature 
[13:38] <apw> Ubuntu 3.13.0-8.27-lowlatency 3.13.2
[13:38] <apw> dammit
[13:38] <smb> hehehe
[13:38] <apw> smb, http://paste.ubuntu.com/6909166/
[13:39] <smb> ok efi-framebuffer... that should be handled by what we added to the rules...
[13:39] <apw> yeah it should
[13:39]  * apw goes for a couple of boots to confirm
[13:40] <smb> apw, heck how many times does this cover...?
[13:40] <smb> Meh forget it... browser changed to tell me that it wrapped in slightly darker gay on top of light gray
[13:47] <apw> ok i've done 10 boots, 5 with pack and 5 without, onto this -lowlatency kernel (-8) and no issues
[13:47] <apw> i wonder if the .2 update fixed things, jsalisbury we should get them to retest
[13:50] <smb> apw, Might have been something else then. Otherwise it would be independant of the kernel more or less
[13:50] <smb> (except for with or without simplefb)
[13:56] <jsalisbury> apw, ack.  I'll ask for testing
[13:56] <apw> jsalisbury, have you tried this thing, did it work for yo?
[13:57] <jsalisbury> apw, I've been running the lowlatency kernel on a few machines and have not had any issues.
[13:57] <apw> damn, so "specific" to something, arse
[13:58] <jsalisbury> apw, yeah, It may be load related, but my "normal" use has not reproduced it.  
[13:59] <psivaa> I am trying to findout a package that broke dialer app tests on mako and see http://pastebin.ubuntu.com/6909262/ every time the test fails. i could not find the package that's causing this. 
[13:59] <apw> boot is pretty loady, but the bug is "doesn't boot" isn't it
[13:59] <psivaa> do you see any clue in that?
[13:59] <psivaa> apw: jsalisbury: if you could ^ :)
[13:59] <jsalisbury> apw, Yeah, one bug reporter can't even boot.
[14:00] <apw> jsalisbury, has that one tried to "remove quiet splash and add debug"
[14:01] <apw> psivaa, nothing jumps out no, i dont recall us changing anything in the rt area, best to check if they are there in the older good tests; they may well be
[14:01] <jsalisbury> apw, yea, I did ask for that, but we didn't seem to get it.  I'll request again.
[14:04] <apw> jsalisbury, great, thanks.  do you have a feel for "how many" people are not working, obviously we have "two" works for us
[14:04] <jsalisbury> apw, only three that I know of
[14:04] <apw> zequence, have you tried booting the trusty lowlatency kernel on anything?  1) does it work we have some people who think not, and 2) does it do what it is meant to :)
[14:04] <apw> jsalisbury, maybe we need to get some of our collegues to add to the testing pool
[14:05] <zequence> apw: It booted for me, but haven't yet looked more closely at it
[14:05] <psivaa> apw: ack, the messages rt messages are present in the logs only when the tests are failing which happen only with new images. but i'll try to find an old install to see if they are logged. thx. 
[14:05] <apw> jsalisbury, ok so that is at least 3 all
[14:05] <zequence> Let me do that now..
[14:05] <apw> zequence, thanks
[14:06] <apw> psivaa, try and get the kernle versions on those good and bad ones
[14:06] <psivaa> apw: ack
[14:10] <jsalisbury> apw, two of the bug reporters, state they get lockups.  One of the bug reporters is unable to boot at all.  I requested testing of 3.13.2 and ask for more info from the guy that can't boot.
[14:11] <apw> jsalisbury, YATM
[14:11] <smb> yet another tragic moment?
[14:12] <jsalisbury> yet another terrible monkey?
[14:12] <apw> you are the man
[14:12] <apw> sheesh
[14:12] <jsalisbury> haha
[14:15] <smb> -ETOOMANYFLAS :-P
[14:32] <soren> Hey peeps. I'm running Precise on some HP servers. They have a P420i controller managing a bunch of disks. When trying to configure them for our needs we ran into problems and have been in touch with HP support. When they couldn't give us useful answers themselves, they said to ask Canonical for "the right drivers".
[14:32] <soren> Am I right to assume that the right drivers are whatever is shipped by default in Ubuntu?
[14:33] <soren> Or are there special drivers for HP smart array controllers that I have to ask for?
[14:33] <soren> Note: I'm not expecting this to be the case, but I promised to ask.
[14:34] <apw> soren, classically hardware enablement has been via the lts-hwe kernels so that might be what they are meaning
[14:35] <soren> You mean the backported drivers from q, r and s?
[14:35] <soren> s/drivers/kernel packages/
[14:35] <apw> yeah, /me asks about as well
[14:35] <soren> I think what they are meaning is "we have no idea, so we're just passing the buck"
[14:35] <apw> heh ... 
[14:36] <soren> I wish I were being snarky.
[14:36] <apw> soren, what failure modes are you seeing
[14:36] <soren> apw: Not failures. We just want only a few disks to be RAIDed and the rest to be exposed as individual drivers.
[14:36] <soren> *drives.
[14:37] <soren> And that doesn't seem supported.
[14:38] <apw> so 'hardware' raid for a few and the rest jbod, that doens't sound like something the OS would control indeed
[14:39] <apw> soren, i'll see what i can find out, and let you know if i find anything exciting
[14:39] <soren> Nope. The driver ignores all the ones that don't have a RAID configuration.
[14:39] <soren> apw: Cool. I appreciate it.
[14:41] <xnox> soren: hp, also on some servers ships with driver-injection-disk, a what appears as a usb-drive with precompiled binary kernel modules for a given ubuntu kernels
[14:41] <xnox> soren: (not dkms based)
[14:41] <xnox> soren: so depending what you are after, you might need those...
[14:41] <soren> xnox: I guess it's possible.
[14:42] <xnox> chiluk: ^ are you familiar with raid / HP + missing kernel drivers.
[14:42] <xnox> soren: i didn't see HP servers personally, but chiluk might have dealt with those.
[14:44] <chiluk> soren... typically you have to define a jbod array for each disk in your raid firmware.
[14:44] <chiluk> otherwise the controller will reserve the disks as spares for future use.
[14:45] <zequence> apw: Coudln't boot with a nvidia driver
[14:45] <zequence> apw: Going to try with the free one later
[14:45] <chiluk> soren it sounds like you have the correct drivers installed, as you are able to see the drives you have in a raid configuration. ... Now you just need to define a jbod for each disk you want visible to the OS, in a 1 jbod for 1 disk scheme
[14:46] <soren> chiluk: Is there an actual JBOD setting? My ops guys suggested they could set up a RAID-0 for each drive and that was about it.
[14:47] <chiluk> soren, most controllers have a jbod option, for expressly this purpose.
[14:47] <soren> chiluk: That's great info. thanks.
[14:47] <chiluk> soren... this is not a software raid card right?
[14:48] <chiluk> soren... it has ram, and a controller, and possibly battery backup right?
[14:48] <soren> chiluk: No, it's an HP P420i. It's pretty pricey and supposed quite good.
[14:48] <soren> *supposedly
[14:48] <chiluk> soren... then yeah you need to define jbods for each disk you want exposed to the OS.
[14:49] <chiluk> soren... keep in mind you may want to leave one as a hot-spare in case of failure in the raid itself.
[14:50] <chiluk> soren... also I don't have any explicit experience with the HP p420i, but that's how every other hardware raid device I've ever played with operates.
[14:50] <chiluk> and I played with quite a few.
[14:53] <chiluk> soren if that doesn't work, look into installing the linux-generic-lts-saucy package
[14:54] <soren> chiluk: How do you fiddle with the config on these things? Some sort of BIOS-like thing or a userspace utility after boot?
[14:54] <chiluk> soren... let me know how you fare, and more importantly if I was right... I do like being right.
[14:55] <chiluk> soren... you can usually configure the drives via a bios configuration utility.
[14:55] <soren> chiluk: I need to be pretty specific with my ops guys. If I just say "look for the JBOD setting in the config tool", they'll be all like "which config tool?".
[14:55] <chiluk> soren...  Sometimes, if you're lucky, you can get a userspace utility.
[14:56] <chiluk> soren... I almost guarantee you that there is a bios level configuration utility.. So I'd start there.
[14:56] <chiluk> once your ops guys have it set up and accessible, then you can contact HP for the userspace utility.
[14:57] <chiluk> soren ... most of these hardware raid cards are just rebranded LSI megaraid cards, and they have a java utility that is relatively functional...
[14:57] <soren> chiluk: I'm looking at screenshots from ACU which seems like some sort of user space utility. It shows the following options: "RAID 0", "RAID 0+1", "RAID 5" and "RAID 6".
[14:57] <soren> I guess with hardware raid, RAID 0 is the same as JBOD, isn't it?
[14:58] <chiluk> yeah.
[14:58] <chiluk> raid 0 with one drive is essentially a jbod..
[14:58] <soren> With software RAID, you add a superblock and probably go through devmapper in the kernel, but that doesn't really apply with hw raid, I suppose.
[14:59] <soren> Sorry, gotta run.
[14:59] <soren> chiluk: Thanks for your help.
[14:59] <chiluk> soren let me know how it goes.
[15:27] <hvn2> Hi, I got redirected here, but not sure if anyone here can help me. I have patched, configured and cross-compiled a vanilla kernel using make-kpkg for Ubuntu12.04 xenomai/armhf/omap and on the target dpkg tells me that although it is an armhf kernel, it is not an omap kernel. Is there anything special I should do for omap ?
[15:52] <pkern> apw: Where was the kexec fix for precise/lts-backport-saucy pushed to? Because I don't see an update to that branch in ubuntu-precise.git.
[15:53] <rtg> pkern, it won't ripple down until mainline saucy isuploaded
[15:54] <bjf> brendand, will you be testing SRU kernels this week?
[15:54] <pkern> rtg: Oh I see. Thanks. :)
[15:56] <brendand> bjf, yeah should be in progress now
[15:56] <bjf> brendand, thanks
[16:11] <brendand> bjf, i guess there is no raring -proposed kernel being published as it's EOL?
[16:11] <bjf> brendand, correct, there *is* a lts-hwe-raring still though
[16:12] <brendand> bjf, yep got that one
[16:19] <pkern> So I guess that's what confused me. That the raring one was updated as next in the precise repo.
[16:29] <zequence> apw: Wasn't able too boot on saucy, using this one PC (nvidia, if that makes a difference). Worked fine on a trusty install, another machinge
[16:30] <henrix> smb: cking: re. your replies to ktml, i suppose you're suggesting i should *not* take those pstate commits. is this correct?
[16:30] <bjf> infinity, do we have a release schedule that shows the Trusty point release dates?
[16:30] <smb> henrix, Actually cking replied too
[16:30] <smb> Basically the driver seems to be disabled
[16:31] <rtg> smb, pstate is disabled by default in the Ubuntu kernel, but not upstream stable
[16:31] <henrix> yeah, i understand that -- i thought only on a stable prespective. so, the saucy kernel could keep that disabled
[16:31] <smb> rtg, Ah
[16:32] <smb> henrix, If it is enabled upstream then I think it only improves things (though it is a kind of add support for thing which you can decide on taking or not)
[16:33] <cking> indeed
[16:34] <henrix> smb: cking: yep, and looking at the patch it seems to meet the usual stable requirments. that's why i had it already queued even before seeing the ktml email (it had been requested already in the stable mailing list)
[16:35] <henrix> of course the request on ktml was for it to be included on S and R, which is a different story... :)
[16:35] <cking> henrix, yup 
[16:35] <henrix> cool, thanks
[16:35] <smb> henrix, So you would be ok. For anyone using the upstream kernel they have to get things right
[16:36] <smb> I mean to have the user-space side or not
[16:36] <cking> with the latter, 'cos we've turned it off, if it was included in S and R it won't make a jot of difference for user's who left it off by default
[16:37] <henrix> ok, got it. thanks for the clarifications.  i'll just keep it on 3.11 (and probably kamal will pick it for 3.8 as well)
[16:42] <kamal> I haven't looked at the commits yet, but yes, my intention is to pick them up for 3.8-stable
[17:08] <infinity> bjf: Not yet.  I can whip something up later today, after I've had an "argh, I'm sick, but also need to be at work" nap-battle with a cold this morning.
[17:09] <bjf> infinity, no rush. just with the discussion of 12.04.5 and how it lines up with 14.04.x i thought it would be helpful
[17:25] <hallyn> hm.  3.11 kernel on precise, kvm-in-kvm hung taking up 200% cpu.  no msgs in dmesg though.  finally killed it.  shoulda gdb'd i guess, i'll see if it happens again
[17:38] <hallyn> hm, crashed at the exact same place
[17:38] <hallyn> s/crashed/hung/
[17:39] <hallyn> holy cow nested kvm is just b0rked
[17:45] <hallyn> trusty guest works just fine.
[17:46] <hallyn> smb: ^ not sure where to go with this :)  do you have any precise host you can try to reproduce on?
[17:47] <bjf> jsalisbury, i pushed your quantal update
[17:52] <jsalisbury> bjf, cool, thanks
[17:54] <jsalisbury> bjf, It looks like Precise has the latest upstream commits, so 3.11.10.4 is next up for Saucy when it's released.
[17:54] <bjf> jsalisbury, ack
[18:11] <kamal> henrix, cking, smb:  correction to my statement above.  I will _not_ be applying those intel_pstate commits to 3.8-stable, because 3.8 doesn't even include the intel_pstate driver.
[18:15] <apw> heh
[18:18] <smb> hallyn, I probably can find something but right now still trying to figure out i386 hang (non-nested). Nested has been a bit of a mess with 3.11 though I had the feeling more when using as host. But maybe the stack of P-S-something also suffers
[18:19] <hallyn> smb: that's jodh's hang?
[18:19] <smb> hallyn, Hm, no I think jamespage reported that one
[18:19] <hallyn> smb: ok, so should I be filing a kernel bug, or is that basically a waste of time?
[18:20] <hallyn> smb: jodh showed me a bug (which i then reproduced) with i386 kvm (non-nested actually) on trusty hanging.  non-nsted -  nm, not same :)
[18:20] <smb> hallyn, The i386 not even able to run anyguest reliably. The nested bug basically would be jodh 's
[18:21] <hallyn> all right well maybe i'll try a trusty kernel on precise.  i do need nesting to work
[18:21] <smb> The i386 seems something new with 3.12/3.13. The nested borkage seems to involve kernels between 3.9 .. 3.13 
[18:22]  * hallyn shakes his head
[18:22] <smb> hallyn, yeah, sforshee seemed at least unable to reporoduce with 3,13 
[18:23] <hallyn> smb: do you know offhand where i'd find the best trusty backport kernel for precise?
[18:24] <smb> hallyn, Optionally use an amd cpu, those had at least no nested issues... :-P
[18:24] <smb> hallyn, I would just go to the archive and download the latest trusty debs...
[18:24] <hallyn> oh, linux-lts-trusty in canonical-ekrnel-team
[18:24] <hallyn> hm.
[18:25] <hallyn> smb: heh, i can't just switch to amd, this is my fast remote box that i do all my testing on :)
[18:25] <hallyn> i fear trusty kernel debs on precise will hit some precise shortcomign in postinst or something...
[18:26] <hallyn> It IS NOT RECOMMENDED that you subscribe to this PPA.   <- you guys can be scary
[18:26] <smb> hallyn, Too bad. :) Unfortunately upstream implemented that feature (nested page tables) in so many steps there is no real hope for a backport
[18:26] <hallyn> smb: funny thing though, a trusty guest on my precise host (with saucy kernel) works just fine
[18:26] <smb> hallyn, Well just don't blame us if things horribly go wrong :)
[18:26] <hallyn> only saucy guest hangs
[18:27] <hallyn> "I've got backups"
[18:28] <apw> hallyn, hehe if you go quiet for a long time, we'll know you are availing yourself of them :)
[18:28] <hallyn> surely subscribing to the ppa which will get updates would be safer than taking the debs and never getting an update, right?
[18:28] <hallyn> apw: yup, my irc client is on that box too
[18:28] <smb> hallyn, Apparently there is a lot of fun of how things are mixed. shadow on nested or nested on shadow or shadow on shadow ...
[18:28] <hallyn> smb: oh ffs, fine, i'll test on ec2 :)
[18:29] <smb> heh, sure we got different problems there ... :-P
[18:30] <smb> Not even sure whether ec2 would allow accelerated nested
[18:30] <hallyn> smb: oh i don't care about that.
[18:30] <hallyn> i'm just tryign to get the libvirt qrt to complete.
[18:31] <smb> ah...
[18:31] <hallyn> but it keeps hanging the first-level kvm guest
[18:31] <smb> hallyn, I probably should have a look on that
[18:32] <smb> hallyn, So if you got time, file a bug and subscribe me and sforshee 
[18:32] <smb> just that we won't forget
[18:33] <hallyn> smb: ok
[18:36] <hallyn> smb: opened bug 1278531
[18:36] <ubot2> Launchpad bug 1278531 in linux (Ubuntu) "nested kvm on saucy kernel hangs" [Undecided,New] https://launchpad.net/bugs/1278531
[18:38] <smb> hallyn, ok thanks. might be some variant of the known bug bug at least I would like to be sure
[18:54] <apw> rtg, that cve you applied (CVE-2014-1874) did you apply it to lucid ?
[18:57] <rtg> apw, I have now. ooops.
[18:57] <rtg> forgot to push
[18:58] <apw> rtg, heh great thanks, my ocd was whining about the orange square
[19:33] <hallyn> apw: hi, any thoughts on the possibility of unprivileged overlayfs in trusty/
[19:42] <apw> hallyn, i am not entirly against it, have you discussed it upstream?
[19:43] <apw> hallyn, i did get an early take from security, who at least didn't throw their hands in the air
[19:43] <hallyn> no, not at all.  Who would be upstream, sinc eoverlayfs is not upstream?
[19:43] <hallyn> I could ping Eric for his opinion,
[19:43] <apw> oh good point, hrm, i am a pint in so i'll think about your email tomororw
[19:43] <hallyn> and cc: lkml just for giggles
[19:44] <apw> yeah we should do that indeed
[19:44] <hallyn> ok, I'll do that now so we have that info tomorrow (maybe)
[19:44] <hallyn> apw: thanks, drink up :)
[19:50]  * smb hopes apw _drinks_ a pint and _is_ not one
[19:51] <hallyn> email sent
[20:01] <ogasawara> infinity: I'm probably going crazy, but I swear I thought we had daily netboot images for trusty?  But I am failing to find them...
[20:01] <ogasawara> infinity: do you have a pointer by chance?
[20:02] <infinity> ogasawara: Same place as all netboot images? :)
[20:02] <ogasawara> infinity: ah, I just had to hand edit then for trusty
[20:02] <rtg> http://cdimage.ubuntu.com/netboot/ ? 
[20:02] <infinity> ogasawara: http://cdimage.ubuntu.com/netboot/trusty/
[20:03] <bjf> ogasawara, http://archive.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/current/images/netboot/
[20:03] <ogasawara> infinity: yep, got it.  it wasn't listed by default
[20:03] <ogasawara> thanks dudes
[20:03] <infinity> Yeah, we don't add it to the parent until release, generally.
[20:03] <infinity> Though, I guess I could add a section for the development release there, with big flashing lights and Geocities-style under construction GIFs.
[23:32] <antarus> stgraber: hey, were you the fellow working on secureboot?