=== _dejuren_ is now known as dejuran
=== dejuran is now known as dejuren
=== amitk_ is now known as amitk
=== Kiall is now known as zz_Kiall
=== ming is now known as Guest64607
=== zz_Kiall is now known as Kiall
=== henrix_ is now known as henrix
=== Kiall is now known as zz_Kiall
=== zz_Kiall is now known as Kiall
[09:39] <cking> apw, https://wiki.ubuntu.com/Kernel/Debugging/USBearlyprintk
[09:47] <apw> cking, god that is a disaster till you have figured out the physical port, the port N you need to use, and the orientation of the unkeyed device
[09:48] <cking> apw, yep,  makes debugging so much fun fun fun
[09:48] <apw> cking, we should have a wiki for which holes and which numbers to use you know
[09:49] <cking> apw, what? for all models?
[09:49] <apw> for models where someone figures it out, perhaps
[09:49] <cking> I suppose that makes sense - as long as they don't get moved around on different revisions
[09:50] <apw> nnng, please no
[09:50]  * cking has a motto: "if they can change it, they *will* change it"
[09:50] <apw> you missed *randomly*
[09:51] <cking> they do it in a  systematically randomized way just to keep us on our toes
[10:16]  * henrix -> (early) lunch
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[12:27]  * cking -> late lunch
[12:50] <rtg> jsalisbury, re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1041883/comments/66, keep a lazer like focus on the original reporter as long as you can hold his attention. The other dudes need to file separate bugs.
[12:50] <ubot2> Launchpad bug 1041883 in linux "Recent patch to asus-wmi module makes system unbootable" [High,In progress]
[12:51] <jsalisbury> rtg, ack.  Allot of noise in that bug, but I'll focus on the original bug reporter
[12:54] <rtg> jsalisbury, yeah, I think the other noise _is_ likely about asus-wmi, but I think the original reportwer is going to have a different problem. I'm betting its gonna bisect to CONFIG_X86_X32.
[12:57] <jsalisbury> rtg, (quantal-amd64)jsalisbury@tangerine:~/bugs/lp1041883/ubuntu-quantal$ git bisect visualize | grep commit
[12:57] <jsalisbury> commit d3a67dbe37d32ba10da0de2f14151d606856e5d2
[12:57] <jsalisbury> commit 41d572a1eb382b033a93f80e01450425d641dc05
[12:57] <jsalisbury> commit 2d3e1c176760c110a6237be229a19f61bcc2156d
[12:57] <jsalisbury> commit c7f240a0b0ea5c489aabf65b3399f192a6f6fc53
[12:57] <jsalisbury> commit 9e907a96efa9a7f497f1943590e18c5c39d61750
[12:57] <jsalisbury> rtg, yup, that is 9e907a96 :-)
[12:57] <jsalisbury> rtg, we should know today
[12:58] <rtg> jsalisbury, cool
[12:58] <rtg> jsalisbury, you can blame apw for CONFIG_X86_X32
[12:58] <jsalisbury> rtg, heh
[13:05] <smb> sforshee, Errm, was it you playing with (beside other things) dualgfx (optimus)?
[13:07] <sforshee> smb, not recently. A while back I think I backported something to allow us to turn off the discrete GPU since we can't use it anyway, that's about it.
[13:07] <sforshee> smb, I've been messing with hybrid graphics on Macbooks recently tho
[13:08] <apw> rtg, thanks :)
[13:08] <smb> sforshee, Hm ok. Asking cause someone came up with a black screen bug on #ubuntu-devel and I guess cjwatson and I struggle not to be responsible... :-P bug 1053269
[13:08] <ubot2> Launchpad bug 1053269 in grub2 "black boot" [Undecided,Confirmed] https://launchpad.net/bugs/1053269
[13:09] <rtg> apw, anytime.
[13:20] <sforshee> smb, just read through the backscroll. Usually on optimus the integrated GPU always drivers displays and discrete is just intended to be used for processing power, so it seems right that i915 is the primary device. Although sometimes dGPU is used for some outputs.
[13:21] <sforshee> smb, not really sure about using nvidia binary module with optimus, I never tried it
[13:23] <smb> sforshee, Hm, yes. I guess I am confused as to how vt_handoff (or its removal) changes things... And something seems to cause the discrete card to get activated...
[13:24]  * apw pops out for a couple
[13:24] <sforshee> smb, the discrete card is probably turned on at boot and will show up on the PCI bus, so it's not surprising that the nvidia module gets loaded. That's fine as long as whatever is trying to display stuff uses the integrated card.
[13:25] <sforshee> smb, assuming that nvidia binary driver behaves well in dual-graphics setups, which I'm unsure about. But it likely won't detect any attached displays.
[13:26] <smb> sforshee, There is that bbswitch command fiddling around with things. Whatever that does
[13:28] <sforshee> smb, I think it's trying to turn off the discrete card
[13:28] <smb> sforshee, off and on
[13:28] <smb> [   18.060525] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
[13:28] <smb> [   18.062519] bbswitch: disabling discrete graphics
[13:28] <smb> [   18.062773] bbswitch: Result of Optimus _DSM call: 11000059
[13:28] <smb> [ 1437.177242] bbswitch: enabling discrete graphics
[13:28] <sforshee> smb, so it does
[13:28] <smb> (ok much later...)
[13:29] <sforshee> smb, bah and it changes the vga decodes
[13:29] <smb> sforshee, Though I realized that there is a long time in between...
[13:30] <sforshee> smb, yeah seems that's probably too late to be causing the problem as described
[13:30] <smb> Right
[13:32] <deffrag> Hi! I have a code prepared and compiled on x86_64 architecture which I moved to and compiled on ARM(Beagleboard XM). And, it worked without errors exactly as it would on x86_64. Same commands were executed to compile and run, natively compiled. I'm curious to know what is the difference? What changes in gcc in arm (?) made it possible?
[13:34] <sforshee> smb, although it seems vga decodes are switch to the discrete GPU about 1.7 seconds in
[13:37] <smb> sforshee, *sigh* You could as well have told me about nomudflap as I have as much idea what this is/does as I had with the other before looking into the man page. :)
=== skaet_ is now known as skaet
=== Kiall is now known as zz_Kiall
[14:34] <smb> kamal, I hear you may be "interested" to have a look at bug 1053269
[14:35] <ubot2> Launchpad bug 1053269 in linux "black boot" [Medium,Confirmed] https://launchpad.net/bugs/1053269
[15:13] <vanhoof> jsalisbury: yo
[15:14] <vanhoof> jsalisbury: weren't you bisecting some odd Intel wifi bug a month or so back, random drops/hangs?
[15:14] <herton> jjohansen, would you need a respinned ti-omap4 kernel with the changelog fixed? (re: bug 1047347)
[15:14] <ubot2> Launchpad bug 1047347 in kernel-sru-workflow/security-signoff "linux-ti-omap4: 2.6.38-1209.26 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1047347
[15:14] <herton> ppisati, ^
[15:14] <vanhoof> jsalisbury: I seem to remember seeing that on a bug list, or maybe it just flew by me in bug mail
[15:21] <ppisati> herton: that's what the commit says
[15:22] <ppisati> herton: and it says it's a cherry-pick
[15:22] <ppisati> (cherry picked from commit 06b6a1cf6e776426766298d055bb3991957d90a7)
[15:22] <ppisati> i wonder if the original commit is wrong too at this point
[15:22] <ppisati> jjohansen: ^
[15:24] <herton> ppisati, natty master is ok, I think the mistake came when it was applied on ti-omap4
[15:24] <ppisati> yes
[15:24] <ppisati> no
[15:24] <ppisati> wait a sec
[15:25] <ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-natty.git;a=commit;h=e172e91df99f8841287b02d27b43d85801bc2f4d
[15:25] <ppisati> it's wrong in natty master too
[15:25] <ppisati> CVE-2012-3340
[15:25] <ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3340)
[15:26] <ppisati> while jj says:
[15:26] <ppisati> "CVE-2012-3340 is incorrect, it should be CVE-2012-3430"
[15:26] <ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3340)
[15:26] <ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3430)
[15:31] <jsalisbury> vanhoof, Let me double check 
[15:31] <jsalisbury> vanhoof, here's a list of the bugs I'm bisecting: https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=performing-bisect
[15:32] <jsalisbury> vanhoof, could you be thinking of bug 1050573 ?
[15:32] <ubot2> Launchpad bug 1050573 in linux "No WIFI network activity after resume" [Medium,Incomplete] https://launchpad.net/bugs/1050573
[15:33] <henrix> ppisati: i can't see that problem in ubuntu-natty/master...
[15:33] <herton> ppisati, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=b449827c669916b39ee91b55d26f74ca55cd5fa5 (origin/master)
[15:34] <vanhoof> jsalisbury: might be, let me take a peek
[15:35] <vanhoof> jsalisbury: thanks man
[15:38] <ppisati> bah
[15:38] <ppisati> they probably flipped the numbers during the cherrypick
[15:39] <kamal> smb: thanks for the heads-up about bug 1053269.   *sigh*
[15:39] <ubot2> Launchpad bug 1053269 in linux "black boot" [Medium,Confirmed] https://launchpad.net/bugs/1053269
[15:39] <smb> kamal, Always glad to get rid of... err be of service. :)
[15:39] <kamal> smb: grrrr!  ;-)
[15:41] <ppisati> herton: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4
[15:41] <ppisati> herton: done
[15:41] <rtg> smb, since you've got the reproducer, any chance you can bisect ?
[15:42] <smb> rtg, for what?
[15:42] <rtg> bug #1053269 ?
[15:42] <ubot2> Launchpad bug 1053269 in linux "black boot" [Medium,Confirmed] https://launchpad.net/bugs/1053269
[15:42] <smb> rtg, no optimus machine in my home
[15:43] <rtg> smb, oh, I guess I thought you'd run into this one yourself
[15:44] <smb> No, that someone who came to #ubuntu-devel and I just happened to be on cjwatsons radar because I was inquiring about bug 1038055
[15:44] <ubot2> Launchpad bug 1038055 in linux "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [High,Confirmed] https://launchpad.net/bugs/1038055
[15:44] <rtg> smb, ah, wrong place at the wrong time
[15:44] <smb> rtg, Yeah, and no deed goes unpunished. :)
[15:45] <herton> ppisati, we will need an upload number bump to fix this one. But lets wait if jjohansen needs the respin
[15:45] <rtg> smb, no _good_ deed
[15:45] <ppisati> herton: ack
[15:46] <smb> rtg, I would not dare to call the patch I came up with for that bug "good"
[15:46]  * ppisati rush out -> gym, sushi and Talisker (it's friday night)
[15:47]  * smb already went to cider
[15:47] <ogra_> gah, i missed him
[15:49] <henrix> ppisati: hmm... talisker
[15:49]  * henrix assumes he's talking about the scotch
[15:51] <ogra_> is there any other talisker ? 
[15:51] <henrix> ogra_: not that i'm aware of :)
[15:53] <smb> Well probably only Talisker, the settlement... :-P
[15:54] <henrix> heh
[15:58] <cking> 316 packages can be updated. - turn your back a few days and that's what happens on your dev boxes
[16:04] <skaet> rtg,  is there any chance that we can get fixes for: https://launchpad.net/bugs/1050855 and https://launchpad.net/bugs/1049088 for Beta 2?
[16:04] <ubot2> Launchpad bug 1050855 in linux "External USB keyboard stops working when d-i starts on mac mini" [High,Confirmed]
[16:09] <rtg> skaet, I doubt we'll find a fix for bug 1050855 in time. I also don't think bug 1049088 is a kernel problem given Marc's comment #8.
[16:09] <ubot2> Launchpad bug 1050855 in linux "External USB keyboard stops working when d-i starts on mac mini" [High,Confirmed] https://launchpad.net/bugs/1050855
[16:09] <ubot2> Launchpad bug 1049088 in linux "Unity crashes at login with nouveau driver" [Medium,Confirmed] https://launchpad.net/bugs/1049088
=== yofel_ is now known as yofel
[16:18] <deffrag> Why in the image used - http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-server-armhf+omap.img.gz - for Beagleboard xm, it is not possible to have DSP working? Why 12.04 has no dsp bridge?
[16:19] <infinity> deffrag: People in #ubuntu-arm are probably more likely to have interesting answers to that.
[16:20] <deffrag> Ok
[16:21] <kamal> rtg: I'm looking at bug 1053269 now -- its clearly the fault of one of the two additional backlight patches we crammed in for 15.22 (the reporter says that 15.21 -- my original set of backlight patches -- works okay for him)
[16:21] <ubot2> Launchpad bug 1053269 in linux "black boot" [Critical,Confirmed] https://launchpad.net/bugs/1053269
[16:21] <rtg> kamal, ok, thats good to know
[16:21] <rtg> kamal, the bisect ought to be easy :)
[16:21] <kamal> rtg: :-)
[16:21] <kamal> is it "A", or is it "B"?
[16:23] <cking> or both?
[16:28]  * cking --> EOW
[16:30] <henrix> rtg: re the patch you just sent for CVE-2012-3412
[16:30] <ubot2> henrix: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3412)
[16:30] <henrix> rtg: i guess you also want to revert the previous 5 commits, right?
[16:31] <rtg> henrix, which 5 ? I thought we gave up on the core networking patches ?
[16:31] <henrix> rtg: no, they have been applied (and released)
[16:31]  * henrix goes double-check
[16:31] <rtg> henrix, oh, shit. I guess we didn't.
[16:32] <henrix> rtg: yep, they've been released this cycle
[16:32] <henrix> rtg: so, we;ll need to revert them first
[16:33] <rtg> henrix, lemme think about it for a bit. I'll resend.
[16:33] <rtg> too damn many kernels....
[16:33] <henrix> rtg: ack. in the mean time, i'll try to have the bug reporter testing ben's patch with the previous 5 commits reverted
[16:33] <rtg> henrix, has the USN been published ?
[16:34] <rtg> henrix, we didn't actually have a reproducer for that one, did we ?
[16:34] <henrix> rtg: not sure. maybe jjohansen...?
[16:35] <henrix> rtg: i'm just looking at this because of a regression (bug #1052861)
[16:35] <ubot2> Launchpad bug 1052861 in linux "After upgrade to new kernel version, machine crashes after a few hours of uptime" [High,Confirmed] https://launchpad.net/bugs/1052861
[16:36] <rtg> henrix, well, as Ben pointed out, the core net patches likely weren't suitable for a stable update. In retrospect I agree. herton and I must have been on drugs that day.
[16:37] <henrix> heh :)
[16:37] <herton> rtg, ack sent
[16:38] <herton> and yes, needs the reverts, as being released already
[16:40]  * smb -> EOW
[16:44] <herton> rtg, I think in retrospect we are just making sure to have things fixed, we are not sure always if we will get flamed/ignored when asking upstream about backporting :P
[16:44] <rtg> herton, pull request in a few minutes....
[17:02] <hggdh> ogra_: there still?
[17:07] <jjohansen> rtg, henrix: yep USNs have been published for CVE-2012-3412 in lucid, natty and oneiric
[17:07] <ubot2> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3412)
[17:07] <rtg> jjohansen, do you have a procedure to re-issue a USN ?
[17:08] <infinity> jjohansen: Oh hey, you're around.
[17:08] <rtg> jjohansen, we're only re-working Lucid.
[17:08] <jjohansen> rtg: yes we can edit USNs
[17:08] <infinity> jjohansen: Respinning for the typo in https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1047347 seems unlikely.  Are you happy to update bug tasks and let it be released despite the typo?
[17:08] <ubot2> Launchpad bug 1047347 in kernel-sru-workflow/security-signoff "linux-ti-omap4: 2.6.38-1209.26 -proposed tracker" [Undecided,In progress]
[17:10] <jjohansen> infinity: hrmmm, that one is problematic as it breaks the tooling give me a few minutes to figure out whether we can/should get around it
[17:10] <infinity> jjohansen: Mmkay.
[17:14] <jjohansen> infinity: okay, I'll clear it through and fix it up manually on our side
=== pedro_junior_ is now known as pedrinho
[17:18] <infinity> jjohansen: Alright, cool.  Thanks.
[17:20] <deffrag> infinity: Seems like engaging DSP on arm platforms is rare topic. I asked in #beagle then, as you suggested,  in #ubuntu-arm
[17:23] <deffrag> or maybe I'm not asking it right.
[17:26]  * rtg -> lunch
=== zz_Kiall is now known as Kiall
[18:21]  * henrix -> EOW
=== henrix is now known as henrix_
[19:47]  * ogasawara lunch
[19:48]  * pedrinho home
[19:59] <jjohansen> bjf, sconklin: err what happened to the shank bot not working to get uploads promoted on friday
[20:04] <infinity> jjohansen: Friday morning was considered vaguely Thursday night.  Or something.
[20:05] <jjohansen> infinity: hrmmm okay /me needs to go back and look at what was agreed on
[20:06] <herton> jjohansen, it was agreed until 18:00 UTC on Friday
[20:07] <jjohansen> herton: hrmm okay thanks, I think we may need to revisit that at UDS, but for now I'll stop whining
[20:09] <infinity> I think as long as we still have people around in some timezone who can fix things (so, the Americas, in this case), we're probably okay.
[20:09] <infinity> But Friday afternoon in the US is right out, since we won't see problems until everyone goes home.
[20:10] <infinity> But it's all a bit wishy-washy and hand-wavy, as we can't reliably predict when the world will explode from a bad update, we can only assume it's "probably an hour or two after it's released".
[20:13] <bjf> jjohansen, i'd could live with not doing any on friday but we need to light a fire under regression testing, specifically cert. testing.
[20:14] <bjf> jjohansen, they consistently wait too long to get started. the other "option" is to not wait for cert. testing.
[20:14] <jjohansen> bjf: yeah I remember that being an issue, we can live with it now and re-eval how it is going at UDS
[20:14]  * rtg bugs out for the week
[20:14] <infinity> Things seem to be going vaguely smoothly right now, except for the occasional hiccup.
[20:15] <infinity> But always making sure things are ready by Thursday afternoon would be swell.
[20:15] <jjohansen> infinity: yep
[20:15] <infinity> Or just changing the initial cadence, so we start the whole process a day earlier.
[20:15]  * jjohansen recalls that had problems too
[20:15] <infinity> If you shift the PPA upload earlier, then the release might land in the middle of the week, profit?
[20:16] <bjf> infinity, we do the ppa upload as soon as we have the kernels ready
[20:16] <infinity> (Assuming it really does take an exact number of days to go through all the steps)
[20:17]  * jjohansen thinks pokes the staffing for the weekend beast :)
[20:17] <bjf> infinity, people understand monday-friday. running thursday to thursday was confusing for everyone
[20:17] <infinity> bjf: Yeah, that's a fair point.
[20:17] <infinity> bjf: It's why I tend to find things like progress meetings mid-week disjointing too.
[20:18] <bjf> ack
[20:18] <infinity> "Wait, I had  half a week before, and half a week after, the previous half week doesn't register as a thing".
[20:18] <jjohansen> infinity: but then you have the whole weekend to work on things and make progress :)
[20:19] <infinity> Anyhow, the current process seems to be running mostly smoothly.  It may be worth hallway conversations to see if we can tweak it, I'm not sure it's worth a bikeshedding session.
[20:21]  * bjf is going to driver over and smack jjohansen
[20:21] <jjohansen> infinity: oh no, didn't mean a session, just a quick out out of band hallway conversation
[20:21] <jjohansen> hehe
[20:21] <infinity> Yeahp, totally down for that.  Grab me in CPH. ;)
=== Kiall is now known as zz_Kiall
=== zz_Kiall is now known as Kiall
=== davi_ is now known as davi
=== Kiall is now known as zz_Kiall