=== BenC__ is now known as BenC
[05:53] <ogasawara> Sarvatt: thanks for getting that RC6 test kernel put together
[05:54] <ogasawara> Sarvatt: I'll follow up with the release team first thing in the morning to see about an upload.  I do think it's a critical fix that we should have for Beta.
[05:55] <Sarvatt> ogasawara: nono thank you for doing absofrigginlutely everything else including the call for testing and listening to me when i whinged about how it should be fixed when it wasnt really :)
[05:56] <Sarvatt> 50% battery life is seriously important, i was getting a patch to blacklist samsung laptops from it ready, so glad it was easier
[05:56] <ogasawara> Sarvatt: on the bright side, crimsun said he's got positive test results with your kernel \o/
[05:57] <ogasawara> Sarvatt: I'm hoping the hard shutdown's we're seeing with the ASUS UX31's might also be fixed with it.  hopefully we'll have some test feedback by morning.
[05:57] <Sarvatt> i'm absolutely 100% sure they will be, hoping for testing proving it though
[05:58] <ogasawara> Sarvatt: yep
[05:59] <ogasawara> Sarvatt: anyways, I'm off to bed now.  I'll keep you posted about the upload and will update the call for testing email with further updates.
[05:59] <Sarvatt> that one person tested on eugeni's patch where rc6=1 really meant rc6 only in 3.4, would  be weird if rc6p only was fixed and i'm surprised the call for testing went so good when it was busted
[06:01] <Sarvatt> the call for testing kind of excluded desktop boards since it required power readings on battery though and desktop boards without bios upgrades is where the pain will be outsde of ux31's
[06:02] <Sarvatt> there were asus z68 motherboards where they fixed the rc6 problems via a bios upgrade that some people didnt apply i'm sure
[06:02] <Sarvatt> and the bios upgrades bumped the voltages used during rc6, we had bugs about that a year ago when they first came out
[06:04] <Sarvatt> really hope its fixed for the majority of people now :) the rc6p only graphics corruptions i've passed on to the x guys to spot in case bugs are filed against x drivers, https://launchpadlibrarian.net/93566331/Screenshot%20at%202012-02-21%2009%3A53%3A04.png is really noticable
[06:04] <Sarvatt> its always black with with the random corruption there
[06:05] <ogasawara> Sarvatt: we've gotten some fairly decent feedback, even with the borked patch, but indeed I want to make sure it's exactly what we want and expect it to do for when Beta ships and gets wider testing
[06:05] <ogasawara> Sarvatt: yah, I gave bryce a heads up to keep an eye out for any possible graphics corruptions from rc6 too
[06:05] <Sarvatt> ogasawara: do you think it has any chance of making the beta?
[06:06] <ogasawara> Sarvatt: I hope so.  Beta Freeze was today, but we don't ship Beta-1 until next Thurs.
[06:07] <ogasawara> Sarvatt: so there's time for an upload and respin of images, assuming I get the go ahead from the release team
[06:07] <ogasawara> Sarvatt: which is why I intend to catch skaet first thing in the morning
[06:08] <Sarvatt> ogasawara: really appreciate you doing that on a saturday, kicking myself for not noticing that problem with the original patch
[06:09] <Sarvatt> oh friday, same difference, its much appreciated
[06:09] <ogasawara> Sarvatt: no worries and I totally missed it too!
[06:12]  * ogasawara really stumbles off to bed.  Sarvatt, shouldn't you be sleeping right now?!  isn't it like 1am or something for you?
[06:12] <Sarvatt> yep, goodnight :)
[06:15] <Sarvatt> done uploading i386 kernels to the same place as the amd64 ones so i can disappear now, yay
=== smb` is now known as smb
[09:20] <krychek> hi, can anyone help me in opening an upstream kernel bug for this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/811464 ?
[09:20] <ubot2`> Launchpad bug 811464 in linux "Cannot mount media in DVD rom drive, Acer Timeline 4810TG." [Undecided,Triaged]
[09:20] <krychek> i dont know which category to choose
[10:29]  * smb reboots
[10:48]  * smb thinks to be back
[11:02] <smb> apw, bug 940198 if you are interested in subscribing
[11:02] <ubot2`> Launchpad bug 940198 in unity "Help screen activates when switching desktops" [Undecided,New] https://launchpad.net/bugs/940198
[11:08] <smb> hm, ok and enigmail feels incompatible with thunderbird 11...
[11:33] <herton> ppisati, did you saw the failure of latest linux-ti-omap4 update for maverick? (bug 932237) Not sure why it's failing, since nothing in that area changed in last update...
[11:33] <ubot2`> Launchpad bug 932237 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.35-903.31 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/932237
[11:51] <ppisati> herton: let me check
[13:31] <ppisati> herton: cool, it was actually broken even in the previous kernel
[13:31] <herton> ppisati, ouch
[13:32] <ppisati> herton: now i'm testing the first kernel that was supposed to fix that bug
[13:34] <herton> ppisati, ok. yes, weird that it "verified" on previous release
[13:36] <ppisati> herton: actuallu it was broken even in the previous kernel, so i'm stating to think that it has always been broken in M
[13:36] <ppisati> herton: i'm pretty sure i did the test by myself in O and it was ok there
[13:36] <ppisati> herton: so, i'm retesting all the releases now
[13:38] <herton> ppisati, ok, may be maverick has something else missing. but 861296 passed verification on M, so may be there is something different in tests, or something else
[13:38] <herton> 861296 == bug 861296
[13:38] <ubot2`> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
[13:39] <ppisati> herton: the fix for that went in .29
[13:39] <ppisati> herton: .30 and .31 are broken or, at least, the case attached to that lp bug doesn't work on these kernels
[13:41] <ppisati> herton: so, either we broke it after .29 ( and i'll know soon), or we never really fixed it in M and all the previus tests are moot
[13:41] <herton> ppisati, true. I don't see any change related to mmap after .29
[13:44] <ppisati> herton: ok, it's broken even for the kernel were the fix went it
[13:44] <ppisati> cool
[13:45] <ppisati> ok, i'll retest for N and O too now
[13:45] <herton> ouch, ok
[13:45] <ppisati> in the mean time /me -> lunch
[13:48] <brendand> herton - do you know how much longer Lucid -proposed kernels will be coming in for?
[13:49] <herton> brendand, do you mean how much time we have for testing? until end of next week
[13:50] <brendand> herton - no, i mean how much longer we'll be building new kernels for Lucid?
[13:54] <herton> brendand, I'm not sure. I think we have 5 year support on it
[13:59] <herton> that means until 2015
[14:04] <apw> brendand, another three years isn't it, though they do slow down in the last year ish
[14:05] <herton> apw, isn't server supported by 5 years? so I suppose it means kernel along with it
[14:05] <herton> but for certification may be 3 years indeed
[14:07] <herton> (as desktop == 3 years of support)
[14:10] <apw> herton, your numbers make sense, as to who is responsible for testing after that, and what they test on i suspect we should refer that to pete
[14:11] <apw> to start the discussion on any changes
[14:13] <brendand> i think our policy is to test the last LTS only
[14:13] <brendand> so once precise is released we might stop
[14:14] <brendand> not sure if it will be immediately or there will be a gap
[14:14] <apw> brendand, i am not sure its as cut-n-dried as that, there was no capacity for hardy at all originally, so only lucid was done
=== yofel_ is now known as yofel
[17:11] <jMCg> Hello happy people o/~
[17:13] <jMCg> I was wondering if someone here would like to assist me in hunting down a bug, or rather, finding a solution|workaround to a bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177
[17:13] <ubot2`> Launchpad bug 818177 in udev "boot failures as /dev is not transferred to /root (because 'udevadm exit' times out waiting for a deadlocked worker)" [High,Fix released]
[17:14] <jMCg> Even though my system is up-to-date, the VMs I'm trying to boot (which are just as up-to-date) are showing this exact behaviour.
[17:14] <jMCg> (And in the host, vgscan is hanging, yes)
[17:26] <jMCg> uhm... pretty please?
[17:27] <jMCg> I mean: I've also tried out an other kernel now, thinking that maybe with -virtual, when initramfs isn't too busy doing stuff it won't hang, of course it turned out to still run into the same issue.
[17:51] <jono> jsalisbury, looks like your test kernel fixed my bug
[17:51] <jono> no wireless issues at all now :-)
[18:01] <sforshee> tgardner, don't you have a linksys e3000?
[18:01] <tgardner> sforshee, hang on, lemme check
[18:03] <tgardner> sforshee, wndr3300, wrt310n, cisco-e3000
[18:03] <sforshee> tgardner, the cisco-e3000 is probably the same thing
[18:03] <sforshee> would you recommend it?
[18:04] <sforshee> refurbs are only $50, I was thinking about picking one up
[18:04] <tgardner> sforshee, I think so. I've not any problems with any of them to be honest. I'm using the wndr3300 as my firewall.
[18:06] <sforshee> tgardner, thanks. I'd be using this one behind my firewall anyway.
[18:07] <jMCg> I think I've mentioned this, but just in case it's unclear: The udev version I have installed is the one were but#818177 is fixed. -- But it the VMs I'm trying to boot don't get past init-bottom.
[18:10] <ogasawara> Sarvatt: I'm sure you've already seen, but I uploaded the RC6 fix this morning, ie 3.2.0-17.27
[18:10] <jsalisbury> jono, cool, thanks for testing
[18:11] <cking> ogasawara, are we going to get in touch with all the testers and ask them to re-test then?
[18:14] <ogasawara> cking: I'd like to.  I plan to respond to the call for testing email asking for anyone who has already tested to please re-test if possible.
[18:14] <ogasawara> cking: and for sure I'll make sure those who reported bugs to please re-test.
[18:14] <cking> cool, I'll retest once the kernel is ready ;-)
[18:15] <ogasawara> cking: the amd64 kernel has finished building.  I'll probably wait for i386 to finish and then post my email.
[18:15] <cking> ogasawara, I'll test tomorrow, got the H/W doing some other soak tests at the mo
=== bladernr_afk is now known as bladernr_
[18:40] <jMCg> is there a way for me to say in launchpad the released fix doesn't work? (re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177 )
[18:40] <ubot2`> Launchpad bug 818177 in udev "boot failures as /dev is not transferred to /root (because 'udevadm exit' times out waiting for a deadlocked worker)" [High,Fix released]
[18:44] <jMCg> I wish I was as invisible in real life, as I am on the internet, when hitting a technoligical dead-end.
[18:44] <jMCg> Or flying, flying would be a cool super power too.
[18:48] <pbuckley> jMCg: make a launchpad account
[18:48] <pbuckley> and put a comment
[18:49] <jMCg> pbuckley: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177/comments/127
[18:49] <ubot2`> Launchpad bug 818177 in udev "boot failures as /dev is not transferred to /root (because 'udevadm exit' times out waiting for a deadlocked worker)" [High,Fix released]
[18:50] <pbuckley> then you have done what you can :)
[18:50] <pbuckley> i unfortunately can not provide any direct assistance on this issue other then what i have already provided.. stick around though.. lots of smart people here ;)
[18:51] <jMCg> pbuckley: I haven't - as it still doesn't boot.
[18:51] <jMCg> pbuckley: I've been sticking around and asking (at very different times) for two days now.
[18:51] <pbuckley> :(
[18:51] <jMCg> Not sure if it's two days, because my sleep pattern is a bit b0rked.
[18:52] <pbuckley> have you tried offering free beer?
[18:53] <jMCg> I don't have any :-/
[18:53] <jMCg> And I just drank the last bit of wine I have.
[18:53] <jMCg> But I've got plenty of rakija.
[18:53] <pbuckley> rakija?
[18:54] <jMCg> pbuckley: that's schnapps made from plums
[18:54] <herton> jMCg, it seems you are hit by lvm2 issue discussed at bug 802626. 818177 was mostly about firmware loading and udev exiting problem I think, a different issue
[18:54] <ubot2`> Launchpad bug 802626 in udev "vgchange may deadlock in initramfs when VG present that's not used for rootfs" [High,Confirmed] https://launchpad.net/bugs/802626
[18:57] <jMCg> herton: but if I boot the kvm with init=/bin/sh I don't see vgchange running
[18:59] <jMCg> init-bottom then finishes: http://dpaste.com/707701/
[18:59] <jMCg> So what's next after that?
[19:01] <herton> jMCg, it's a "race" in udev exiting and vgchange invocation, you sometimes get vgchange stuck sometimes not, it doesn't matter what init you use
[19:03] <jMCg> herton: no, init=/bin/sh doens't lead to that. it just exits after init-bottom.
[19:05] <herton> basically udev while exiting in initramfs stops receiving/processing events, discards DM_COOKIE sent by the kernel, making vgchange stuck in a semaphore which never goes down (dmsetup udevcomplete doesn't run on receiving DM_COOKIE)
[19:05] <jMCg> hrm.. I could just remove the lvm udevs?
[19:05] <jMCg> I don't need them in the vm anyway.
[19:06] <herton> jMCg, just take a look at 802626, there are some solutions posted there
[19:07] <jMCg> herton: what I don't understand is why vgchange is invoked if vgscan doesn't deliver anything.
[19:07] <jMCg> oh. I could also just remove the lvm stuff from my image.
[19:08] <herton> vgchange is called from an udev rule. That's why also udev is stuck until timeout after udevadm exit
[19:08] <herton> and you get the boot delay because of that
[19:10] <jMCg> herton: it's not a delay, it's stuck. Forever.
[19:11] <ohsix> did you wait forever? or just a while? :]
[19:11] <jMCg> ohsix: I waited for a night (well, I slept).
[19:11] <ohsix> i see
[19:12] <herton> jMCg, if your problem is vgchange, may be the timeout workaround that was made isn't working in your case. still I would recommend you take a look at 802626
[19:13] <jMCg> herton: right now I'm uninstalling lvm2 and mdadm from the image for the VMs and trying again.
[19:13] <jMCg> In silent hope this fixes the issue.
[19:16] <jMCg> :-/
[19:17] <jMCg> Nope.
[19:22] <jMCg> So, no lvm2, means no /lib/udev/rules.d/85-lvm2.rules -- still the issue persists.
[19:24] <jMCg> hrm.. I think I should install grub and boot the VM's kernel, instead of booting the host's which uses the host's initrd.
[19:29] <herton> jMCg, well you said vgchange was freezing on the bug report, may be your initrd wasn't recreated and vgchange is still running? Or it's another problem. Also are you using lvm, what's the setup. Probably you will have to debug what's freezing really, rebuild the initrd with an udev with debug messages etc. to see what's going on.
[19:30] <jMCg> herton: no, what I said is, that even after the *host* was fully booted, vgchange was still running.
[19:31] <jMCg> I'm using lvm on the host, the VM is on an LVM partition, but it's unaware of that fact, for the VM it's just a disk.
[19:32] <herton> jMCg, ah, that's a problem on the host then. You should fix your host, the vm may be isn't finding the lvm partition
[19:32] <jMCg> herton: it is.
[19:32] <jMCg> What?
[19:32] <jMCg> I think that didn't make sense. Maybe.
[19:33] <jMCg> I pass the partition as /dev/mapper/vg0-web-root -- kvm finds the partition just fine.
[19:34] <jMCg> herton: how do I do that: rebuild the initrd with a debugging message ridden udev?
[19:35] <herton> jMCg, may be the vgchange stuck in your host is the root of your lvm issues, and it's probably the same problem discussed at 802626. I would suggest you solve the host issue first
[19:35] <jMCg> herton: oh.
[19:36] <jMCg> You mean, while it may be able to find it, it's unable to actually boot it, because vgchange blocks.
[19:36] <herton> yes, could be
[19:39] <jMCg> How can I dump the current grub menu?
[19:43] <jMCg> *sigh* wonder why it doesn't boot....
[19:48] <jMCg> Ima gonna go make some go make some foodz.
[19:49] <jMCg> I wanted to goto the movies today, I guess I'll have to stay in until I'm fucking done with this fucking piece of shit.
[19:50] <jMCg> whoops. Wrong channel. ~_~
[19:50]  * jMCg embraces the kick/ban to come.
[19:51] <pbuckley> lol
[20:53] <bryceh> jMCg, tsk
[20:54] <jMCg> sorry bryceh ._.
[20:54] <jMCg> But I'm now stuffed with pasta, and ready to tackle this.
[20:54] <bryceh> excellent
[20:58] <jMCg> it boots!
[20:58] <jMCg> The host, at least.
[20:59] <jMCg> And no vgchange running on the host, so I suppose that's good.
[21:02] <jMCg> Aaand, the vm hangs in the same spot.
[21:58] <jono> jsalisbury, I see a new kernel release in Precise...does this include the fix for my bug?
[21:58] <jono> if so, I can test
[21:58] <ohsix> you can view the changelog :> it should reference the bug if it does, it's good to be verbose about patches, and people usually are
[22:29] <ogasawara> jsalisbury: yo, just saw your email about 911059
[22:29] <ogasawara> jsalisbury: I'm not seeing that patch upstream yet
[22:30] <ogasawara> jsalisbury: but assuming it lands before kernel freeze, we can just cherry-pick is as pre-stable
[22:35] <jMCg> So, after a short de-tour to make traffic server compile with clang, I'm back to debugging our lovely vm boot issue.
[22:46] <BigglesPiP> Hello, I suspect there is a bug in 3.0.0-12 that means my NIC is always powered off before halt, want to go back to 3.0.0-9 and see if it works again there, but I can't find the old kernels...
[22:48] <jMCg> BigglesPiP: checkout the brz tag and build it?
[22:50] <BigglesPiP> really? I guess I'll find out in 45 minutes then, only have netbook chips available