[00:22] <jono> hey jsalisbury
[00:22] <jono> I am now running 3.3
[00:22] <jono> and ran: sudo modprobe -r iwlagn;sudo modprobe iwlagn 11n_disable=1
[00:22] <jono> lsmod doesnt show iwlagn in there, is that normal?
[00:33] <RAOF> jono: Yeah; iwlagn got renamed to iwlwifi (somewhere between 3.0 and 3.2, I'm not sure where)
[00:33] <RAOF> jono: There's an alias of iwlagn → iwlwifi, though, so modprobing iwlagn should have (correctly) loaded iwlwifi.
[00:46] <jono> RAOF, cool
[09:06] <apw> cking, ohhh, network ?
[09:07] <cking> yep, now connected again, at last
[09:07] <smb> cking, \o/
[09:58] <soren> cking: I'm blown away by the battery life on my laptop in Precise. Thank you so much for all the work you've done on this.
[09:59] <cking> soren, well, a really big thanks goes to pitti for fixing a load of user space bugs that we discovered doing the original research
[10:04] <soren> cking: Well, still, you clearly did a lot of work on it, collected all the important data. The effect is astounding.
[10:04] <cking> soren, I also suspect a lot of fixes in the kernel that landed in 3.2 helped, so it's mainly kudos to upstream ;-)
[10:05] <cking> but at least we know what to expect for the next cycle ...
[10:07] <ohsix> what's this regarding? at least the research, is there a blag about it or something?
[10:07] <cking> ohsix, http://smackerelofopinion.blogspot.com/2012/01/improving-battery-life-in-ubuntu.html
[10:08] <ohsix> thanks
[10:09] <cking> ohsix, lots of data from the analysis can be found in: http://zinc.canonical.com/~cking/power-benchmarking/
[10:11] <ohsix> hm i thought the devices that could use low power states already did, except for ALPM which was disabled for stabilitysomethings; will digest tomorrow, thanks for the refs
[10:12] <cking> there is a lot of data there, so fee free to ask questions, I will see if I can answer them sensibly..
[10:13] <ohsix> will fwts get some related tests? or is there another test tool for people to check this stuff or is it manual investigation when things start exploding
[10:14] <ohsix> er i should mention i started reading the article before the one you posted, http://smackerelofopinion.blogspot.com/2011/12/improving-battery-life-in-ubuntu.html
[10:15] <ohsix> if some of them might have stability implications how will they be tested
[10:17] <ohsix> anyways, night :] will have more pointed questions tomorrow
[10:18] <cking> ohsix, I don't think we will put any more power management related tests into fwts.  An aspm check has been added to fwts, but that's about it really 
[10:19] <cking> as for tools for checking this stuff, it is a little tricky - the kit I used is expensive, so it's not a thing most users can do accurately
[10:20] <cking> but I did make a few tools and put them into a PPA: see https://launchpad.net/~colin-king/+archive/powermanagement
[10:20] <jwi> cking: do you expect your work to make a difference for bug 877560 ? any improvements in power.d/intel-audio-powersave ?
[10:20] <ubot2`> Launchpad bug 877560 in linux "Audio codec draining power when not in use" [Undecided,Confirmed] https://launchpad.net/bugs/877560
[10:22] <ohsix> cking: ah i didn't mean duplicating the results with the meter and whatnot, i meant aside from aspm; the other things mentioned in the list like quiesing usb/pci devices (presumably it's not done already for "stability") if in fact it's unstable on someones machine with it enabled, will there be some tools to assist with that
[10:22] <cking> jwi, I think we need to test this with some accurate power measuring tools - powertop needs to be run for quite a while before we can trust the data from it - and it could be that the battery info isn't accurate
[10:23] <cking> ohsix, no tools for this, that wasn't really in the project scope - my aim was to find the low-hanging fruit that could be easily fixed
[10:24] <ohsix> i looked into doing something like that in the past but the battery type in the machines i have access to just provide the battery level from the charge controller, not any wattage or accurate gas gauge type measurements
[10:24] <ohsix> and i couldn't gut my laptop to get a meter in there :>
[10:25] <cking> ohsix, yes, so I basically had to be a bit invasive - I bypassed the battery info altogether and measured current drawn from the machine 
[10:25] <ohsix> through the cable?
[10:25] <cking> yep,
[10:25] <ohsix> bah i could just read the article, no more silly questions
[10:26] <ohsix> if there is a sort of aggressively enable sleep even if it breaks stuff, and you want to have some people shake stuff out, i'd be interested in that as well
[10:26] <ohsix> night!
[10:26] <cking> ohsix, sure, night! :-)
[10:32] <cking> jwi, I've updated that bug with some advice to see if we can get more accurate idea of what's happening.
[11:21]  * ppisati -> back in 10mins
[12:02] <herton> ppisati, these arm bugs are waiting on verification: bug 912199 and 861296. The last one was already verified on other flavours, but to be on the safe side if it can be verified on normal omap kernel would be great, can you take a look at them?
[12:02] <ubot2`> Launchpad bug 912199 in linux "Wrong Beagle XM detection" [Undecided,Fix committed] https://launchpad.net/bugs/912199
[12:02] <ubot2`> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
[12:20]  * apw pops into the office, back in a bit
[12:46] <rbasak> ppisati: I just got this panic on the current precise armhf installer kernel: http://paste.ubuntu.com/826304/
[12:46] <rbasak> Does this mean anything to you?
[13:22]  * apw admires the view
[13:22] <ogra_> ppisati, you didnt by chance happen to stopwatch the boot with the PARTUUID parameter, did you (btw, you rock !)
[13:24] <apw> ppisati, what sort of uuid did you use here?
[13:55]  * ppisati just came back
[13:55] <ppisati> ogra_: nope, because there's a delay after mounting the fs... $something is waiting on $something else, that's why i didn't take any measure, but it was definitely faster
[13:55] <ppisati> herton: i'll have a look
[13:56] <ogra_> ah, thats alread good news at least
[13:56] <ogra_> i'm not sure how eas it is to redo our image build process to use GPT though, i need to research that 
[13:57] <ppisati> apw: GPT UUID, the one from the second partition
[13:57] <apw> ppisati, ahh so you put both down on the disk did you ?
[13:58] <ppisati> apw: what you mean?
[13:58] <apw> you put both a dos partition table and a gpt down on the same disk
[13:59] <ppisati> apw: right, it's called an hybrid-mbr (but it's actually a GPT)
[13:59] <ppisati> apw: so the old "bios" think it's a MBR, go ahead and boot it
[13:59] <apw> very cools, ogra_ does that give you waht you need to do the speed comparison ?
[13:59] <ppisati> apw: and once we have access to the first partition, we can chainload the loaders+kernel (that in turn can speak GPT)
[14:00] <ppisati> rbasak: never seen that, how did you got it?
[14:00] <ogra_> apw, well, after i found out how to roll GPT partitions (and if thats possible at all with the tools on the image build server) into our images
[14:00] <rbasak> ppisati: nothing different to what I've been doing
[14:00] <apw> ppisati, yeah thats most excellent
[14:00] <rbasak> ppisati: just an attempt to netinst
[14:04] <apw> ogra_, if you are careful yu may be able to add the gpt after installing, if the first partition is aligned correctly, there ought to be enough space
[14:04] <apw> ogra_, cirtianly worth checking
[14:04] <ogra_> thats the issue
[14:04] <ogra_> changing the first partition alignment might break the first stage bootloader
[14:04] <apw> normally we round up a bit for partition 1 .. to a cylinder boundary
[14:04] <ogra_> at least on the TI images ... the rom code on tehse chips is a bit silly
[14:04] <apw> so there ought to be a bit of space in there already without moving things
[14:05] <apw> ogra_, like on my laptop here there is 2048 sectors wasted at the front
[14:05] <apw> /dev/sda1   *        2048   150341631    75169792   83  Linux
[14:05] <apw> so you may have some space there by default too
[14:05] <ogra_> lucky you, for us its rather the opposite ;)
[14:06] <ppisati> ogra_: actually you don't have to add anything, you have to convert the MBR to a GPT
[14:06] <ogra_> anyway, i'll try to look into it asap
[14:06] <ppisati> ogra_: once you have an image installed, fire gdisk and it'll tell you what you have to do
[14:06] <ogra_> ppisati, with the size we currently use ?
[14:06] <ppisati> ogra_: yep
[14:06] <ogra_> oh, thats convenient
[14:06] <ogra_> !
[14:07] <apw> ogra_, i think there has to be enough space or something, i am sure its at least one track as i think grub hides in there
[14:07] <apw> ogra_, and the gpt steals one of those blocks, but grub has redundant copies or something odd
[14:07] <ogra_> ah, well, no grub for us yet :)
[14:08] <apw> ogra_, then you definatly have room :)
[14:09] <ppisati> herton: verification-done-oneiric? or was it verification-passed?
[14:09] <herton> ppisati, verification-done-oneiric
[14:10] <ppisati> herton: i passed 912199 but for 861296 some java madness must be done, prod GrueMaster for it
[14:12] <herton> ppisati, ok. There is a testcase there though, I think you could use it instead of playing with java stuff
[14:13] <ppisati> herton: ah right, i forgot about it
[14:13] <ppisati> herton: i'll do
[14:28] <apw> tgardner, no wired at the drop in desks, that would be tooo useful
[14:29] <tgardner> apw, bummer. maybe you should sit next to Michelle ?
[14:29] <smb> Bet he is
[14:35] <tgardner> ogasawara, should ubuntu-q master-next HEAD be set to the same as master ?
[14:35] <ogasawara> tgardner: yep.  I didn't even think to create a master-next yet.
[14:36] <tgardner> ogasawara, ok, I'll take care of it.
[14:36] <ogasawara> tgardner: great, thanks.
[14:37] <ogasawara> tgardner: there have been a good number of patches applied to Precise that haven't yet made it to Q.  I'll get that sorted today.
[14:38] <tgardner> ogasawara, good idea
[14:38] <tgardner> ogasawara, master-next created
[14:39] <ogasawara> ack
[15:26]  * ogasawara back in 20
[15:51] <GrueMaster> Prod me for what???
[15:51]  * GrueMaster is starting to feel like livestock.
[16:42] <ppisati> GrueMaster: will you do lp861296?
[16:43] <GrueMaster> ppisati: What needs testing?  I already have the mmap testcases in my SRU test suite.
[16:44] <ppisati> GrueMaster: ah, so you are automatically going to test it, cool
[16:46] <GrueMaster> Well, like i said, which kernels?  I'm currently only testing omap4, imx51, and dove SRU kernels (I don't get notifications for any other platforms).
[16:48] <ppisati> GrueMaster: omap3?
[16:49] <GrueMaster> Ok.  I'll look into it.  It will take some time, as I only have 1 platform.
[16:50] <ppisati> GrueMaster: k
[16:50] <GrueMaster> So, looking at the bug, Natty forward?
[16:51] <ppisati> GrueMaster: it seems there's even M to test
[16:51] <GrueMaster> That's omap4.
[16:51] <ppisati> ah ok then
[16:52] <GrueMaster> omap was Linux main from Natty forward iirc.  In Maverick, it was a separate kernel.
[16:52] <herton> testing is needed for linux-image-2.6.35-32-omap 2.6.35-32.65, linux-image-2.6.38-13-omap 2.6.38-13.55, linux-image-3.0.0-16-omap 3.0.0-16.27
[16:52] <herton> linux-image-2.6.35-32-omap 2.6.35-32.65 isn't omap4, or am I wrong?
[16:53] <herton> GrueMaster, ppisati ^
[16:53] <GrueMaster> herton: I show linux (Maverick) as invalid in the bug.  And omap4 kernels end in omap4 not omap.
[16:54] <GrueMaster> Separate trees.
[16:54] <herton> GrueMaster, ah, that status should be wrong, the fix went to omap kernel as well
[16:54] <GrueMaster> Ok.  You fix the bug, I'll run the tests.  :P
[17:03] <GrueMaster> ppisati: So this bug is in all the latest SRU kernels for omap, or do I need some private build?
[17:03] <GrueMaster> (just looking for clarification while I image).
[17:04] <ppisati> latest SRUs
[17:09] <GrueMaster> Cool.  Makes imaging and testing easier as I can just use my local mirror.
[17:13] <bjf> join #ubuntu-server
[17:29] <GrueMaster> ppisati: Not having a stable mac address on the beaglexm is going to slow me down some.  Just fyi.
[18:52]  * tgardner -> lunch
[19:22] <jono> jsalisbury, updated https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911059
[19:22] <ubot2`> Launchpad bug 911059 in linux "Intel wireless randomly drops connection" [Medium,Confirmed]
[19:22] <jono> the bug is definitely still present
[19:23] <jono> tgardner, ^
[19:23] <jsalisbury> jono, the bug is still present with N disabled?
[19:23] <jono> yep
[19:23] <jsalisbury> ok, looking at bug
[19:25] <jsalisbury> jono, thanks for testing.  Maybe the best thing is to bisect and try to find the commit that caused this.  What do you thing tgardner ?
[19:25] <jono> thanks jsalisbury - unfortunately it is making the current Precise kernel pretty much unusable on this machine
[19:26] <jono> jsalisbury, also, if you want further community testing, I can have the QA guy on my team get some further input
[19:26] <tgardner> jono, does it work pretty well with the oneiric kernel ?
[19:26] <jono> tgardner, perfectly
[19:26] <jono> although I didn't disableN
[19:26] <jono> although I didn't disable N
[19:26] <jono> just a regular boot of the kernel
[19:27] <tgardner> jono, didn't you say tha your AP didn't have N enabled anyways ?
[19:27] <jono> Linux forge2 3.0.0-15-generic-pae #25-Ubuntu SMP Mon Jan 2 19:40:15 UTC 2012 i686 i686 i386 GNU/Linux
[19:27] <jono> tgardner, I am not sure if it does
[19:27] <jono> it is the bog standard AT&T AP
[19:27] <tgardner> dunno what that is
[19:31] <jono> no idea what the AP is either
[19:31] <jono> let me know if I can help any more with this though
[19:31] <jono> such as if you need any log files
[19:32] <tgardner> jono, the failure cases aren't logging anything useful
[19:33] <jsalisbury> jono, would you be able to test some additional test kernels, if we bisect?  It may take several iterations.
[19:38] <jono> jsalisbury, sure!
[19:40] <jsalisbury> jono, cool, I'll post some links to kernels in the bug.
[19:43] <jono> jsalisbury, cool, thanks!
[20:01]  * cking --> EOD
[20:26] <bryceh> jsalisbury, bug #912992 has some gfx fixes identified for snb, so you probably want that bug on your radar.
[20:26] <ubot2`> Launchpad bug 912992 in xserver-xorg-video-intel "[snb-m-gt2+] Primary laptop display not working, external monitor works fine. [Fixed as of linux-image-3.3.0-994-generic_3.3.0-994.201201290428 from drm-intel-fixes branch]" [High,Fix released] https://launchpad.net/bugs/912992
[20:28] <bryceh> jsalisbury, do you want me to subscribe or assign these kinds of bugs to you, or just ping on irc?
[20:32] <jsalisbury> bryceh, pinging me would be great.
[20:33] <jsalisbury> bryceh, adding the kernel-da-key tag will also put them on my primary report.
[20:33] <bryceh> ok
[20:43] <ogasawara> tgardner: I'm gonna prep an upload now that Alpha-2 is out.  Anything else you want in before I pull the trigger?
[20:44] <tgardner> ogasawara, pick up sforshee's nvidia patches ?
[20:44] <ogasawara> tgardner: yep, just did.
[20:44] <tgardner> ogasawara, manoj bluetooth IDs ?
[20:45] <tgardner> nm
[20:45] <tgardner> ogasawara, hmm, can't think of anything else
[20:46] <sforshee> tgardner, ogasawara: I'll have some radeon patches shortly as well
[20:46] <jsalisbury> bryceh, do you happen to know the SHA1 for the upstream fix in bug 912992 ?
[20:46] <ubot2`> Launchpad bug 912992 in xserver-xorg-video-intel "[snb-m-gt2+] Primary laptop display not working, external monitor works fine. [Fixed as of linux-image-3.3.0-994-generic_3.3.0-994.201201290428 from drm-intel-fixes branch]" [High,Fix released] https://launchpad.net/bugs/912992
[20:46] <ogasawara> sforshee: shortly as in before EOD?
[20:46] <sforshee> ogasawara, yeah, probably within the next 30 minutes
[20:46] <jsalisbury> bryceh, if you don't know off hand, I can search for it.
[20:47] <ogasawara> sforshee: cool, I'll wait then and squeeze those in before I upload.
[20:54] <bryceh> jsalisbury, sorry, nope I don't know.  They alluded to snb work on the upstream bug but didn't specify patch(es).  I did see there's only a couple recent patches in the branch.
[20:56] <jsalisbury> bryceh, cool, thanks.  I'll do some searching.
[20:57] <jono> jsalisbury, will test the 3.1 kernel now and see how I get on
[20:58] <jsalisbury> jono, thanks
[20:58] <jono> :-)
[20:59] <njin> Great this message: Busy inodes after unmount of sda1. Self-destruct in 5 seconds. Have a nice day...
[21:05] <bryceh> jsalisbury, lp #915408 is also ripe and ready
[21:05] <ubot2`> Launchpad bug 915408 in xserver-xorg-driver-ati "Garbled display on external screen when using 1920x1080 instead of 1920x1200" [High,Confirmed] https://launchpad.net/bugs/915408
[21:05] <jsalisbury> bryceh, ok, thanks
[21:05] <jsalisbury> bryceh, do you always add the  kernel-handoff-graphics tag to these types of bugs?
[21:06] <jsalisbury> bryceh, if so, I recall we wanted to make a report to capture these.
[21:06] <bryceh> jsalisbury, yes
[21:06] <jsalisbury> bryceh, great.  I'm going to create a report based off that tag
[21:06] <sforshee> ogasawara, I just sent the radeon patches
[21:06] <bryceh> until now I had been assuming that was sufficient to get them on your todo list
[21:06] <ogasawara> sforshee: ack, thanks
[21:06] <jsalisbury> bryceh, adding that tag would really help :-)
[21:10]  * tgardner -> EOD
[21:10] <bryceh> jsalisbury, ok, I'll use both tags from now on, unless you tell me different
[21:12] <jsalisbury> bryceh, cool, thanks.  you can drop adding the kernel-da-key tag once I create the new report.  So may just add it till then end of tomorrow.
[21:14] <bryceh> alrighty
[21:19] <jono> jsalisbury, so the 3.1 kernel has the bug
[21:19] <jono> which narrows it down a little
[21:19] <jono> man...it is bad in the 3.1 kernel
[21:20] <jsalisbury> jono, him interesting.  I'll go back a little further and post an earlier kernel.
[21:20] <jono> thanks
[22:00] <jsalisbury> bryceh, New report is created: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_graphics_bugs_.html
[22:00] <jsalisbury> bryceh, can you take a look and see if it looks accurate to you?
[22:01] <jsalisbury> bryceh, it may not have the last two bugs you tagged for a half an hour or so.
[22:02] <jsalisbury> bjf, ^^^ This is the report that's been on the todo list
[22:02] <bryceh> jsalisbury, seems like about the right amount of bugs
[22:02] <jsalisbury> bryceh, cool.  So no need to add that kernel-da-key tag.  Just the one you've been using.
[22:03] <bryceh> ok, perfect
[22:03] <jsalisbury> bryceh, thanks for getting me to do this.  It's been on the todo list for a while ;-)
[22:04] <bryceh> it should be handy here on out.  I've got a backlog of upstreamed bugs I'm expecting to see kernel patches for down the pike.
[22:05] <jsalisbury> bryceh, cool