[00:56] <devin__> hey guys
[00:57] <devin__> can I get a hand 
[00:57] <devin__> I was working on a 9GB vm and building/compiling a kernel and ran out of disk space and got error no space left on device, I am going to ad some more space to my VM now, but when I go to restart the process do I have to start from the beginning or is it going to continue where it left off
[01:01] <lifeless> devin__: probably part way between the two
[01:02] <lifeless> devin__: the files written safely to disk should be ok, anything not flushed will have to be compiled new
[01:12] <devin__> lifeless: Im rebooting my VM now, sorry I am still here but my host machine only had a GB left also so I am trying to clear space
[01:14] <devin__> lifeless: any idea how much space I should allocate for??? I am loading kernel 3.2.2
[01:22] <lifeless> devin__: no idea sorry
[02:35] <devin__> hey Can I build my kernel to a different drive 
[02:46] <devin__> hey I am a newb and for some reason I cant connect to the #ubuntu channel
[02:46] <devin__> any ideas
[02:48] <ohsix> using web irc clients isn't going to work :]
[03:06] <devin__> hey guys, where is my kernel supposed to be saved too
[03:07] <devin__> sorry I mean, the build files, I was part way through a build and ran out of space and now I think I need to delete and start over
[03:07] <devin__> lifeless: you still there
[03:08] <lifeless> devin__: hi, whats up ?
[03:08] <devin__> lifeless: hey I was asking you about my kernel build crash earlier, can I just continue by retyping the build command I used or do I need to get rid of all the old files 
[03:09] <lifeless> should be able to continue; have you tried ?
[03:09] <devin__> lifeless: no not yet, some other people in the ##linux forum told me to start fresh
[03:09] <devin__> lifeless: this is the last command I used time fakeroot make-kpkg --initrd kernel-image kernel-headers
[03:09] <lifeless> sure, try it,s ee what happens.
[03:09] <devin__> it was taking like 4 hours, so they said to add -j >???
[03:10] <devin__> for multi core, I added a 2nd core to my VM setup
[03:14] <devin__> lifeless: Do I need to run these three again export CONCURRENCY_LEVEL=3          make-kpkg clean       time fakeroot make-kpkg --initrd kernel-image kernel-headers
[03:14] <lifeless> I don't know
[03:14] <lifeless> this should be documented somewhere
[06:41] <ppisati> moin
[07:40] <smb> tjaalton, Ok, so I think I know when my radeon issue was fixed. Not sure yet whether a suitable backport to 3.5 exists
[07:41] <tjaalton> smb: that's cool, got a sha?
[07:42] <smb> tjaalton, In the bug report, yes
[07:42] <smb> Seems there was a backport submitted to stable, but I do not see it in the queued mails
[07:43] <tjaalton> ah, ok
[07:43] <smb> Oh well, I should be able to pick it from the list and try it... :-P
[07:45] <tjaalton> :)
[07:45] <tjaalton> thanks
[09:05] <cking> bah, my laserprinter is playing up, need to look at the drum
[09:38] <ogra_> ppisati, have you ever looked at /etc/init.d/ondemand ? (re: bug 971091)
[09:38] <ubot2> Launchpad bug 971091 in linaro-ubuntu "Pandaboard ES freezes with the default CPU scaling governor ondemand" [Medium,Fix committed] https://launchpad.net/bugs/971091
[09:39] <ogra_> while we boot with preformance by default on all ubuntu systems to guarantee a fast boot, we force it to ondemand after boot
[09:39] <ogra_> (and that doesnt (and shouldnt) differ on arm)
[10:17] <ppisati> ogra_: so why are builders never experienced this problem so far?
[10:17] <ogra_> builders use a different userspace i think
[10:18] <ogra_> based on ubuntu-core or even something internal
[10:18] <ppisati> in Q is fixed
[10:18] <ogra_> (but likely similar to -core)
[10:18] <ppisati> in P is not (and it won't be)
[10:18] <ogra_> ppisati, i have never seen it in P either
[10:18] <ppisati> the only thing i can do is kill the ondemand module
[10:18] <ogra_> no, please dont
[10:18] <ogra_> boards might run hot etc
[10:19] <ppisati> and let's leave it as is, if someone else experience this problem again
[10:19] <ppisati> the'll tell
[10:19] <ogra_> just leave it as wontfix for precise 
[10:19] <ogra_> yeah
[10:19] <ppisati> according to the reported, moving from ondemand to perfomance fixed it
[10:20]  * ogra_ curses about alllwinner ... why does this damned thing not keep the MMC alive
[10:20] <ppisati> infinity: what governor do you use on builders?
[10:21] <ppisati> ogra_: while here
[10:21] <ogra_> the allwinner guys use something self invented that tires to be DT but isnt ... to initialize the HW ... and awesomely the few docs i can find about it are chinese pdfs
[10:22] <ppisati> lp 746137
[10:22] <ubot2> Launchpad bug 746137 in linux-ti-omap4 "Page allocation failure on Pandaboard and Beagle XM" [High,Confirmed] https://launchpad.net/bugs/746137
[10:22] <ogra_> ppisati, what do you mean ? i'm always here :)
[10:22] <ppisati> we had a discussion about it a couple of weeks ago
[10:22] <ogra_> yup
[10:22] <ogra_> omap4 has the patch already as i understood
[10:23] <ogra_> so at least for quantal omap4 it shopuld be closed
[10:23] <ppisati> \ok, i can backlport the stuff to P
[10:24] <ogra_> ah, well, we have the jasper hack in place there 
[10:24] <ppisati> so, so Invalid for P
[10:24] <ogra_> its not that critical for preinstalled images
[10:24] <ogra_> as they have a workaround
[10:24] <ppisati> to me
[10:25] <ppisati> lp 746137
[10:25] <ogra_> (it will still show up on netinst installations)
[10:25] <ubot2> Launchpad bug 746137 in linux-ti-omap4 "Page allocation failure on Pandaboard and Beagle XM" [High,Confirmed] https://launchpad.net/bugs/746137
[10:25] <ppisati> and
[10:25] <ppisati> lp 940309
[10:25] <ubot2> Launchpad bug 940309 in linux-ti-omap4 "numerous XX: page allocation failure: order:3, mode:0x4020 when under load" [Undecided,New] https://launchpad.net/bugs/940309
[10:25] <ppisati> are the same
[10:25] <ogra_> likely ... let me read the log
[10:26] <ogra_> grrr, why dont people attach the full dmesg is a myth to me 
[10:29] <ogra_> ppisati, commanted and set to incomplete 
[10:29] <ogra_> *commented
[10:39] <cking> bug 1056088, are we Windows or what?
[10:39] <ubot2> Launchpad bug 1056088 in update-manager "software updater asking me to restart my computer, no way of closing dialog" [Undecided,New] https://launchpad.net/bugs/1056088
[11:11]  * cking reboots :-(
[11:16] <slugslug> can anyone help with chipset driver? http://paste.ubuntu.com/1226368/ 
[12:08] <rtg> apw, what does a signed kernel buy us wrt ExitBootServices() ?
[12:16] <smb> rtg, He may be in a closet today (iow on site)
[12:17] <doko> apw, rtg: could you have a look at the ppp test build failure?
[12:17] <doko> In file included from plugin.c:53:0:
[12:17] <doko> /usr/include/linux/if_pppox.h:84:26: error: field 'pppol2tp' has incomplete type
[12:17] <doko> /usr/include/linux/if_pppox.h:99:28: error: field 'pppol2tp' has incomplete type
[12:17] <rtg> smb, oh, right. forgot about that.
[12:17] <doko> broke with the 3.5 kernel headers
[12:18] <rtg> doko, recently? or has it been broken for the whole dev cycle ?
[12:18] <doko> rtg, ENOCLUE
[12:18] <rtg> doko, ok, I'll have a look.
[12:31] <apw> rtg, nothing, to call with it not called we need to be signed
[12:32] <rtg> apw, you're on site somewhere ?
[12:36]  * henrix -> lunch
[12:38] <slugslug> can anyone help with chipset driver? http://paste.ubuntu.com/1226368/ 
[12:44] <mjg59> slugslug: Most smbus controllers are used by ACPI and so can't be bound by a Linux driver
[12:45] <slugslug> so that 'Unclaimed' is normal then?
[12:46] <mjg59> Yes
[12:47] <slugslug> ok thanks 
[13:01] <ppisati> ogra_: do you know that with the latest flash-kernel thing i cannot install any kernel before Q?
[13:01] <ogra_> oh?
[13:01] <ogra_> whats the error ? 
[13:02] <ppisati> hold on
[13:02] <ogra_> (honestly i never tried to install a precise kernel in quantal :) )
[13:09] <ppisati> ogra_: http://paste.ubuntu.com/1226568/
[13:10] <ogra_> hmm
[13:11] <ogra_> ppisati, oh, i think thats expected, you need to uninstall the newer one (another bad design in the new f-k)
[13:12] <ogra_> ppisati, file a bug, defining a version as f-k argument should definitely skip the check for newer kernels
[13:13] <ppisati> ogra_: i'll do
[13:13]  * ppisati grabs an espresso first
[13:13] <ogra_> lool, ^^^ any explanation why giving the kernel version does not force f-k to actually use it ?
[13:14] <ogra_> if i explicitly define $1 it shoudl take it (vs automatic upgrade calls where it should just use the highest ver available)
[13:16] <ogra_> ppisati, as a quick workaround you can just hack /usr/share/flash-kernel/functions ... grep for the error message and comment the exit 0 there
[13:17] <ogra_> i'll add somethin like a --force-version option that overrides the test so manual downgrades are still possible
[13:22] <lool> ogra_: IIRC, it's a workaround for the case where upgrades install an older linux package last
[13:23] <Daviey> smb: Hey.. nested virt seems broken again?? http://paste.ubuntu.com/1226574/
[13:23] <ogra_> hmm, i see we have no option parsing at all :/
[13:23] <ogra_> so it wont be trivial to just add a skip option for the check :(
[13:23] <lool> ogra_: basically kernel packages call "flash-kernel 3.2" and then "flash-kernel 3.0" because linux-image-3.0 is installed second, and this resulted in the older version being installed
[13:23] <ogra_> yeah
[13:24] <ogra_> i knew there was a reson behind it, thanks 
[13:24] <lool> ogra_: Maybe linux-version allows selecting a better version though
[13:24] <smb> Daviey, stop breaking things
[13:24] <lool> ogra_: I agree that a force flag is a good idea though
[13:24] <ogra_> well, for the case where i manually downgrade all i want to check is the existence ... 
[13:24] <lool> ogra_: Sorry, haven't looked at these things for a while; I think I need to lock myself in a room and work on f-k for a couple of days
[13:24] <lool> ogra_: Problem is distinguishing a manual downgrade with an unordered upgrade
[13:25] <ogra_> lool, well, i can do that for you at next UDS, you just have to give me your roomkey *g*
[13:25] <ogra_> (lock you into a room i mean ;) )
[13:25] <lool> In reality, it's useful to have a flash-kernel override, but the user experience needs a way to force a version in some config file rather than calling f-k by hand
[13:25] <ogra_> lool, yeah, i think a force options will be best
[13:25] <Daviey> smb: it's your crummy kernel :)
[13:28] <doko> Daviey, are you ready for sarcasm today? ;P
[13:29] <smb> Daviey, on what host are you running?
[13:32] <Daviey> smb: Canonistack :)
[13:33] <smb> Daviey, Wrong answer
[13:33] <Daviey> option B?
[13:33] <smb> Daviey, maybe C
[13:34] <smb> Daviey, Question is whether the host you run on is a) precise and b) updated enough to have the patch or c) is it broken again
[13:35] <smb> Daviey, Host must be at least Ubuntu-3.2.0-30.47
[13:38] <Daviey> smb: it did work..
[13:38] <Daviey> (after your fix)
[13:40] <smb> Daviey, Note that the fix went into the Precise kernel (as that is what the hosts supposedly run) and I got no clue how many hosts are behind canonistack and what kernel versions they are
[13:41] <ppisati> lp 1056206
[13:41] <ubot2> Launchpad bug 1056206 in flash-kernel "3.0~rc.4ubuntu23: cannot flash an old (previous Q) kernel" [Undecided,New] https://launchpad.net/bugs/1056206
[13:41] <ppisati> ogra_: ^
[13:41] <ppisati> lool: ^
[13:41] <ogra_> thx
[13:42] <Daviey> smb: so Ubuntu-3.2.0-30.47 was published on the 5th?
[13:42] <Daviey> Of this month
[13:46] <smb> Daviey, So says LP (and replaced by something newer on the 21st)
[13:47]  * smb does not trust cloud provides to be up-to-date... and that is _any_ cloud providers...
[13:48] <smb> Daviey, Of course upstream still may have decided to break it in a different way since then... though we only pick up supposedly stable changes on top of 3.5 in Q
[13:49] <ppisati> ogra_: actually it doesn't work even if i comment out that check because passing an argument is totally useless
[13:51] <ppisati> ogra_: http://paste.ubuntu.com/1226643/
[13:51] <ogra_> ppisati, you need to comment kver=$latest... too
[13:51] <ppisati> ogra_: no matter what you pass, kvers will always be overwritten
[13:51] <ogra_> else your arg gets overwritten
[13:51] <ppisati> ok, so way an argument is even taken in consideration?
[13:51] <ogra_> right below the check code
[13:51] <ppisati> i saw that
[13:52] <ogra_> the arg is currently used to check if its actually the latest
[13:52] <ogra_> nothing more
[13:52] <ppisati> so it can stop?
[13:52] <ppisati> i mean
[13:52] <ppisati> why simply don't you let accept any argument since if you take it:
[13:53] <ppisati> 1) you overwrite it
[13:53] <ppisati> 2) else if you don't like it, you bail out
[13:53] <ppisati> bah
[13:53] <ogra_> other way round
[13:54] <ogra_> 1) you compare it to the highest version available 
[13:54] <ogra_> 2) you overwrite it with the highest foound if they match
[13:54] <ogra_> 2 is actually nonsense 
[13:54] <ogra_> since 1 will exit if its not ture
[13:54] <ogra_> *true
[13:55] <ogra_> i wont touch the check, i'll only wrap a if around it and leave kvers="$1" intact in the case you use --force
[13:55] <lool> ppisati: current kernel scripts pass a version argument
[13:56] <lool> and I find it's a quite a good idea
[13:56] <ogra_> yeah, update-initramfs too iirc
[13:56] <lool> except we can't do anything useful with it anymore
[13:56] <ppisati> ok, but if we don't use it, simply ignore it
[13:56] <ogra_> kvers="$latest_version" is not useful though
[13:56] <ppisati> and flash the highest one
[13:57] <ppisati> taking an arg, comparing and then bailing if different is useless IMO
[13:57] <ogra_> if they arent identical we'll fail anyway
[13:57] <ppisati> that said
[13:57] <ppisati> i workarounded it
[13:57]  * ppisati is happy
[13:57] <ogra_> and if they are we can as well keep kvers="$1"
[13:58] <ogra_> (since they are identical :) )
[14:08] <rtg> smb, is there any downside to CONFIG_DRM_CIRRUS_QEMU=n ? what GPU does KVM and Xen choose to emulate if Cirrus is not there ?
[14:09] <smb> rtg, The downside is that llvm-pipe on the cirrus X driver still sometimes seems flakey. The cirrus _is_ emulated.
[14:10] <rtg> smb, agreed. I'm asking what is the downside if we _don't_ build Cirrus.
[14:11] <smb> Actually all GPUs would be emulated. Not sure there really is a choice with Xen, but with kvm you can select a few other emulations on kvm. If there is no cirrus drm for KVM it does not use a special framebuffer driver for plymouth and X uses the cirrus X driver, while with the module it has its own fb driver and X uses the modeset driver (feels new)
[14:12] <smb> On Xen nothing changes because the drm cirrus driver is made to only apply for the subvendor id used by KVM.
[14:12] <rtg> smb, ok, so not using Cirrus DRM is more stable without significant loss of features ?
[14:13] <smb> rtg, It is basically back to what was done in Precise
[14:13] <smb> The fallout we see is most likely due to the drop of unity2d and the use of llvm-pipe
[14:14] <rtg> smb, so, I think you need to respin your patch to add an annotation as to _why_ we're no gonna build CONFIG_DRM_CIRRUS_QEMU.
[14:14] <rtg> an annotation in the enforcer
[14:15] <smb> rtg, Feel free to make it more clear. Maybe. If we can wait that extra day I'd like to hear Andy's opinion on it, too
[14:16] <smb> rtg, From my feeling the modeset X driver (with the drm cirrus module) was a bit more stable in the crashing area, but would not always work, and had some issues of loosing your mouse or completely exploding when trying to change the resolution
[14:17] <smb> T'was a bit like deciding whether slapping your left cheek is better than slapping the right one
[14:18] <rtg> smb, I'm fine with disabling the module. I think we need something in the enforcer so that apw and ogasawara don't have to ask the question of _why_ CONFIG_DRM_CIRRUS_QEMU=n every time they review the configs.
[14:18] <doko> apw, is kmod targeted for q?
[14:19] <apw> doko, i believe infinity was trying to get it in indeed
[14:19] <rtg> I thought kmod was the default already
[14:19] <smb> rtg, Yeah or at least have a hint on why and to what end to review the decision. Maybe we fix the boot race at some point in the future and also allow it to be used from Xen...
[14:35] <hggdh> ogra_: another one on armhf+omap4 server: installation now completes, but MMC partition 1 is either empty or invalid, system does not reboot
[14:36] <hggdh> ogra_: I am opening a bug on it now
[14:37] <ogra_> hggdh, already fixed
[14:37] <ogra_> hggdh, bug 1055938
[14:37] <ubot2> Launchpad bug 1055938 in flash-kernel "uboot and mlo not in boot partition after install" [High,Fix released] https://launchpad.net/bugs/1055938
[14:38] <ogra_> there wasnt an image respin with the fix yet though
[14:38] <ogra_> (i think)
[14:39] <hggdh> ogra_: heh, this was fast :-)
[14:39] <ogra_> well, plars already had pinged me over night 
[14:39] <ogra_> so i could fix it right after getting up :)
[14:39] <hggdh> ogra_: wait -- this is a bit different. I just mounted the MMC on my laptop, and P1 is not being recognised as a kosher partition
[14:40] <ogra_> in what way ? 
[14:40] <hggdh> meaning I have P2 mounted, but not P1
[14:40] <ogra_> well, then at least that bit worked :)
[14:41] <hggdh> and the dash shows only one card (and we all know we can trust the dash)
[14:41] <ogra_> the code that sets it to be hidden is also the code that wiped it ;)
[14:41] <hggdh> LOL
[14:41] <ogra_> yeah, thats on purpose
[14:41] <ogra_> you can still manually mount it, udisks wont pick it up anymore though
[14:41] <ogra_> (so it doesnt end up automounted on your desktop after install
[14:41] <ogra_> )
[14:43] <hggdh> ah
[14:44] <hggdh> ogra_: OK, it is still the same issue as plars found, no respin
[14:44] <ogra_> yep
[14:44] <ogra_> would have surprised me 
[14:49]  * ogasawara back in 20
[15:56] <jsalisbury> **
[15:56] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:56] <jsalisbury> **
[16:07]  * cking wonders where the day is going
[16:14] <infinity> ppisati: Not sure which governor is being used, though I can't see IS deviating from the defaults.
[16:15] <infinity> lamont: ^
[16:21] <ppisati> so you should hit that problem is it exists 
[16:24] <rtg> doko, fixed ppp, shall I just upload it or send you the diff ?
[16:27] <doko> rtg, please upload
[16:27] <rtg> doko, is thea rebuild failure bug number ?
[16:27] <rtg> is there a*
[16:27] <doko> no, didn't file these yet
[16:27] <rtg> ok
[16:34] <rtg> doko, uploaded
[16:34] <doko> thanks!
[16:48] <lamont> infinity: pretty sure it's the default, but I truthfully haven't looked
[16:49] <ppisati> lamont: can't you ssh into an omap4 builder?
[16:49] <ppisati> lamont: or get to the serial console
[16:51] <lamont> ppisati: I can
[16:51] <lamont> what exactly do you want me to do once I'm there?
[16:53] <ppisati> lamont: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[16:54] <lamont> ondemand
[16:58] <ppisati> lamont: kernel version?
[16:59] <lamont> Linux nikusui 3.2.0-1418-omap4 #25-Ubuntu SMP PREEMPT Fri Aug 31 18:41:31 UTC 2012 armv7l armv7l armv7l GNU/Linux
[16:59] <ppisati> lamont: cool, thanks
[16:59] <ppisati> ogra_: the instability with the ondemand governor is no more
[17:00] <ppisati> ogra_: ^
[17:01] <cking> rtg, http://smackerelofopinion.blogspot.co.uk/2011/11/does-your-uefi-firmware-have-csm.html
[17:01] <rtg> cking, thanks
[17:13] <ogra_> ppisati, yeah, thats what i expected :) we would have heard about ti 
[17:13] <ogra_> *it
[17:31]  * rtg -> lunch
[17:44] <infinity> ppisati: I'm not sure one can assume that because it's running on the buildds, it's not unstable.  We kill buildds all the time.
[17:44] <infinity> ppisati: And, in fact, if flipping to performance would make things better, I'd be happy to have you instruct lamont on how. :P
[17:46] <lamont> infinity: actually, that probably just wants to be an RT with detailed instructions, and then losas even can do it
[17:46] <ppisati> infinity: no, on demand is good, performance could overheat the board&c
[17:47] <ppisati> infinity: but you can try to switch if you want and see if it makes such a big difference
[17:47] <ppisati> infinity: and if you didn't have any stability problem building the kernel/firefox/openoffice&c, then we are good
[17:48] <infinity> ppisati: We randomly kill buildds here and there, it's not an exact science. :)
[17:48] <infinity> ppisati: But if performance actually overheats, that's hardly a solution either.
[17:50] <lamont> overheating is bad.  let's not do that.
[17:50] <infinity> Indeed.
[17:51] <ppisati> infinity: well, it *could* overheat, we never tried to max it out for hours in a row
[17:52] <infinity> lamont: Bah.  Are we sure we don't still have occasional network hiccups between buildd-master and the pandas?
[17:52] <ppisati> infinity: if you want to sacrif^W^W^Wtry it out, that would be nice :)
[17:52] <infinity> lamont: shedir's offline with "no route to host", but it's clearly up now.
[17:52] <infinity> ppisati: Well, I'd assume that "performance" still does frequency scaling to cope with thermal issues?
[17:53] <infinity> ppisati: But if not, then it's definitely not going to be a good idea. :P
[17:54] <infinity> ppisati: Anyhow, the machines might be stable right now anyway.  All our problems could be network/drivers/swap/etc related.  I'll keep a closer count on how often they actually DIE.
[17:55] <ppisati> ack
[17:55]  * ppisati -> out for dinner
[18:01]  * smb -> offline
[18:29]  * cking --> EOD
[18:49] <skaet> ogasawara, rtg - still a fair amount of fix committed in http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html
[18:50] <ogasawara> skaet: a fair bit should have been cleaned up last week
[18:50] <ogasawara> skaet: I'll re-review
[18:50] <ogasawara> skaet: I suspect most are armada
[18:50] <skaet> thanks ogasawara 
[18:55] <ogasawara> skaet: indeed 26 are Fix Committed.  when broken down 3 are against linux, 21 against linux-armada, 1 is dkms, 1 is bcmwl.
[18:55] <ogasawara> skaet:  the dkms and bcmwl packages my team doesn't really look after
[18:56] <ogasawara> skaet: the linux-armada is actually ikepanhc's.  he's tied up with higher priority items at the moment but has promised me a review later.
[18:56] <ogasawara> skaet: he did do an initial scrub though, as it was a higher count previously
[18:56] <ogasawara> skaet: I'll fwd email about it
[18:57] <skaet> ogasawara, should the dkms and bcmwl packages get split out and associated with another team?   we put them there so there would be an overview,  but if we should have others tracking (and me pinging ;) ) them,  we can try that.
[19:01] <ogasawara> skaet: the bcmwl I think alberto looks after but I can't recall which team he belongs to.  dkms, not sure who really owns that one.  
[19:03] <infinity> ogasawara: dkms probably "belongs" to foundations, if it's anyone, though I can see a valid argument for making it your problem too (or a shared problem).
[19:04] <skaet> ogasawara,  hmm... if we sort clear owners and can come up with a logical grouping, for the parts your team doesn't look at,  splitting out will make sense.   Sort of like desktop and Dx.    However,  if its a person here, and a person there.   rather leave them grouped where they are.
[19:04] <rtg> infinity, I've spent a great deal of time over the last few years making dkms someone else's problem
[19:05] <infinity> rtg: How did that turn out? :)
[19:05] <rtg> infinity, well, not too bad really.
[19:06] <rtg> I haven't had to deal with fglrx or bcmwl in quite awhile.
[19:06] <ogasawara> which team is tseliot now days?
[19:06] <rtg> isn't he still hwe ?
[19:07] <ogasawara> I suppose I should just ask him, if only I could find him
[19:07] <rtg> ogasawara, the directory says he works for vanhoof
[19:10] <ogasawara> skaet: I'm fine to leave them grouped as is.  but just note that if it's not against linux*, I'm not likely watching them closely.  In those cases, it might be better to ping the assignee.
[19:41] <rtg> jsalisbury, have you sent upstream any emails about bug #1045027 ?
[19:41] <ubot2> Launchpad bug 1045027 in linux "[regression] iPXE kills kvm with KVM: entry failed, hardware error 0x80000021" [Critical,In progress] https://launchpad.net/bugs/1045027
[19:53] <jsalisbury> rtg, not yet.  I was planning on reviewing the git log for v3.5-rc3 first.  Then perform a reverse bisect if nothing stuck out.
[19:54] <rtg> jsalisbury, I just sent them an email
[19:54] <jsalisbury> rtg, saw that.  thanks
[19:55] <jsalisbury> rtg, woops, meant to say v3.6-rc3 not v3.5
[20:03] <jsalisbury> rtg, this may be the fix for bug 1045027 in mainline: b246dd5df139501b974bd6b28f7815e53b3a792f
[20:03] <ubot2> Launchpad bug 1045027 in linux "[regression] iPXE kills kvm with KVM: entry failed, hardware error 0x80000021" [Critical,In progress] https://launchpad.net/bugs/1045027
[20:05] <jsalisbury> rtg, I'll cherry-pick it into Quantal, build a test kernel and request that it be tested in the bug.
[20:05] <rtg> jsalisbury, isn't that the patch in v3.5.3 that is causing the problem ?
[20:07] <rtg> jsalisbury, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045027/comments/13
[20:07] <ubot2> Launchpad bug 1045027 in linux "[regression] iPXE kills kvm with KVM: entry failed, hardware error 0x80000021" [Critical,In progress]
[20:10] <jsalisbury> rtg, ahh, right.  And b246dd5df was added in 3.6-rc1, and they state the bug is fixed in v3.6-rc3.  I'll investigate further.
[20:18] <jsalisbury> rtg, It seems easiest for me to perform a reverse bisect, to be sure I narrow it down to the correct commit that fixes the bug in rc3.
[20:19] <rtg> jsalisbury, thats fine, but you've only got about a week left.
[20:20] <jsalisbury> rtg, ok, I'll stay on top of it.
[21:06] <vanhoof> ogasawara: http://ubuntuone.com/1ixNYtiizK1hI69Dfk3wY3
[21:06] <vanhoof> ogasawara: serious business
[21:07] <vanhoof> Sarvatt: ^^ hawk attack!
[21:07] <ogasawara> vanhoof: ahahaha
[21:08] <vanhoof> ogasawara: im sitting outside now with my pellet rifle
[21:08] <vanhoof> im sure Raleigh PD will love this
[21:08] <vanhoof> :D
[21:09]  * rtg -> EOD