[03:34] <sconklin> sforshee: you around?
[05:44] <Gerald> hi
[05:45] <Gerald> ohsix, are u here?
[08:56] <smb> morning
[09:30] <Kano> hi apw , why is CONFIG_INTEL_IOMMU_DEFAULT_ON=y on by default? the option before renaming was NEVER on by default
[09:31] <Kano> DMAR_DEFAULT_ON was definitely always off
[09:31] <Kano> same option, just renamed
[09:31] <apw> policy got applied to new options so it moved on
[09:32] <Kano> but is is no new option
[09:32] <apw> renamed items look like new options
[09:33] <Kano> on one system i have to use intel_iommu=off in order to boot with nv card
[09:33] <Kano> because of that new default
[09:34] <apw> yep there are a few systems with problems as a result
[09:34] <Kano> funnly phoronix mentioned that as regression in 3.2 kernel
[09:34] <Kano> but it was caused just by that config change
[09:35] <apw> yeah well well all know how phoronix strive for accuracy
[09:35] <cking> 'cos phoronix knows best ™
[09:36] <Kano> most likely it never worked
[09:36] <Kano> on those systems
[09:36] <apw> yep most likely those systems are broken
[09:37] <apw> we have all sorts of issues with iommus right now, and all sorts of issues with rc6, in some cases related
[09:38] <cking> still unsure if rc6 + iommu are totally the root cause for some rc6 failures
[09:38] <Kano> did you see a solution for rt2800pci problems with 3.2?
[09:38] <apw> unless you enable things in devel you don't find out why they might be off, and what needs fixing
[09:38] <Kano> i googled but did not found anything
[09:38] <cking> it's hard to substantiate facts when facts are rumours
[09:39] <apw> perhaps we should check on wikipedia [irony]
[09:39] <cking> LOL
[09:39] <apw> Kano, anyhow, i see what you are saying about the rename, and will discuss it with leann
[09:54] <Kano> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=d3f138106b4b40640dc667f0222fd9f137387b32
[10:38] <_ruben> gotta love all them tweets about kids not being able to do their homework due to wikipedia
[10:38] <Kano> _ruben: it is not offline, just disable java script on that page
[10:38] <Kano> it also works when you disable css
[10:39] <Kano> thats a block for noobs
[10:39] <_ruben> i hardly use wp myself .. so couldnt care less really :)
[11:28] <brendand> that's hardly making a stand
[11:29] <ppisati> brb
[11:30] <apw> brendand, i'd say its blatant self-advertisment
[11:37] <ogra_> and its the english page only apparently
[11:37] <ogra_> who speaks that anyway 
[11:37] <ogra_> :P
[11:38] <apw> ahh perfect i can redirect all my wp needs via ogra_ 
[11:38] <ogra_> only if you also read the pages in german ... i get it as soon as i click on the english version
[11:39] <apw> i am using you as translator, you read .de and type it in here for me, purfec
[11:39] <ogra_> haha
[11:50] <brendand> you can also just press ESC before the message flashes up. does the same trick as disabling javascript
[12:28] <pgraner> apw, ping
[12:28] <apw> pgraner, pong
[12:29] <pgraner> apw, so the -9 is broke on my box, after every suspend I lock up within seconds
[12:29] <pgraner> apw, -8 works fine
[12:29] <apw> pgraner, which 8 have you got?  14 or 15 ?
[12:30] <apw> someone else was mentioning 8s after resume before they hung, hmmm
[12:31] <pgraner> apw, pgraner@x220:~$ uname -a
[12:31] <pgraner> Linux x220 3.2.0-8-generic #15-Ubuntu SMP Wed Jan 11 13:57:44 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[12:31] <apw> 15 then
[12:35] <apw> pgraner, can you test the 3.2.1 mainline kernel and see if that exhibits the same behaviour ... -9 pulled in .1
[12:38] <apw> not that i can see anything either way whch would make this occur, hrm
[12:40] <pgraner> apw, will do need to send a few emails first
[12:45] <pgraner> apw, does this help, this is the what happened during the resume
[12:45] <pgraner> http://pastebin.ubuntu.com/808528/
[12:51] <apw> pgraner, thats just a slower resume, just over the 10s boundary, so probabally not related
[12:51] <apw> you have that disk thats as slow as snot i think
[12:51] <pgraner> apw, is an Intel SSD
[12:52] <apw> pgraner, as slow as snot when resuming
[12:52] <cking> but for some reason we get an -EBUSY on the reset, which is peculiar
[12:52] <apw> cking, didn't you mention ^^
[12:53] <cking> apw, there were a bunch of issues, including a 3 second delay on that touch screen thingy too
[12:53] <apw> yeah, so just hitting the 10s warnign isn't supprising
[12:55] <pgraner> apw, I rmmod the touch driver and reinsert via pm-utils
[12:58] <cking> pgraner, did you try the "ahci.ignore_sss=1" tweak?
[12:59] <pgraner> cking, not yet, I'm battling two issues, this suspend resume hang and the slow ssd, any suggestions on which should go first?
[13:00] <cking> ah, I missed the earlier comment that S3 resume now fails :-(
[13:05] <cking> pgraner, well I'd sanity check you box with a few S3 tests with a previously known good kernel to see if its a kernel issue first
[13:11] <pgraner> cking, you mean the fwts tests?
[13:12] <cking> pgraner, just do your normal suspend/resume a coupla times with a previous kernel - if that fails we know it's not necessarily a kernel update issue
[13:14] <pgraner> cking, I've done that with the -8 kernel and it works fine
[13:15] <cking> lemme see if I can reproduce on my X220i
[13:22] <cking> working fine with 3.2.0-9-generic #16-Ubuntu SMP Fri Jan 13 20:46:38 UTC 2011 x86_64...
[13:23]  * apw boggles
[13:27] <cking> pgraner, does it behave differently when running on AC or battery?
[13:28] <pgraner> cking, don't know I'll check that 
[14:15] <apw> well this isn't very damn helpful: MARC is participating in SOPA Blackout Day. marc.info and lists.kde.org will be dark from midnight US/Eastern January 18th, 2012, until midnight US/Pacific the following day.
[14:15] <apw> so one cannot look at mail list archives today either ...
[14:15] <apw> all they are doing is pissing me off, and well, frankly, i have no say
[14:17] <egon> CALL SENATORS
[14:17]  * apw has no senators, well other than the car and those don't respond to calling
[14:18] <apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/917211 <-- smb do you have the h/w to test that ?
[14:18] <ubot2> Launchpad bug 917211 in linux "Xen + nouveau + modeset = corrupted console" [Undecided,Confirmed]
[14:18] <egon> I like what torbit has done.. popup that you can dismiss
[14:19] <smb> apw, by reinstallting my build box maybe... 
[14:19] <smb> apw, It has at least a nvidia card in...
[14:19] <apw> smb, bah thats more effort than i wanted expended
[14:20] <smb> apw, Also what is this. using pci passthrough to have the card in the guest... Probably in the bug... should have a look
[14:21] <apw> yeah ... difficult to say
[14:30] <jsalisbury> smb, apw, Is there someone familiar with lxc containers: bug 917660
[14:30] <ubot2> Launchpad bug 917660 in linux "Installing qemu-user-static on an i386 lxc container will hose your amd64 host" [Medium,Confirmed] https://launchpad.net/bugs/917660
[14:31] <apw> jsalisbury, it is unclear to me that that is a kernel issue
[14:31] <smb> Feels like another problem comming from lxc not being a real vm
[14:31] <apw> jsalisbury, it feels like the container is not correctly 'closed' and the contents are escaping
[14:32] <smb> If you access proc / sys or what you look at the host ones
[14:32] <jsalisbury> apw, smb, could be a qemu issue: qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[14:32] <apw> whether its possible to make it closed or not i am unsure, but i think i'd add a task to lxc for this
[14:32] <jsalisbury> apw, will do
[14:32] <apw> jsalisbury, i think the complaint is that the request to use qemu for binaries has leaked out into the host
[14:34] <jsalisbury> apw, hmm. leaks don't sound good
[14:34] <smb> Not sure how the binfmts are updated. Maybe another syscall the containter needs to prevent..?
[14:35] <apw> jsalisbury, the kernel does not have a container mechanism, they are faking things by using 100 different bits of protection ... but ... its never been intended for this use so it doesn't work well
[14:35]  * smb tries asking on #server
[14:35] <apw> smb, via /proc, which i am sure is not containerised, it may be possible to remove it though in the container
[14:35] <smb> Hm, think hallyn is not around yet
[14:35]  * apw hasn't seen hallyn for days
[14:36] <smb> right, though that probably completely fails install then
[14:36] <smb> proc is not ocntainerized afaik
[14:36] <smb> apw, he was on the kernel-team meeting yesteraay
[14:37] <smb> but I think it is too early on that side of the world
[14:37] <apw> smb, then he is hiding from me
[14:37] <apw> swine
[15:17] <tgardner> apw, did you tell me I don't have to update CVE tracker states? IIRC you said the shank bot (or its equivalent) will get them set to the right state automatically based on git repo contents ?
[15:18] <apw> tgardner, tracker or bug states ?  but in the main both are handled from the trees yes
[15:18] <tgardner> apw, bug states, e.g., fix committed
[15:18] <apw> tgardner, there is hourly updates of the tracker from the repo contents, and daily updates of the bugs when jjohansen does his processing
[15:19] <apw> tgardner, so yes if you don't fix commit things that will get handled later by jjohansen's scripting
[15:19] <tgardner> apw, cool
[15:19] <tgardner> automation is king
[15:19] <smb> darn handy
[15:19] <apw> avoids me making 100s of errors
[15:51]  * ogasawara back in 20
[16:26] <jsalisbury> ogasawara, Figured I'd send a heads up.  Lots of duplicates of bug 917962 this morning.
[16:26] <ubot2> Launchpad bug 917962 in linux "BUG: scheduling while atomic: swapper/3/0/0x10000100" [High,Confirmed] https://launchpad.net/bugs/917962
[16:31] <ogasawara> jsalisbury: you been able to skim through them and determine if it's a recent regression?
[16:32] <jsalisbury> ogasawara, It appears they are all with 3.2.0-9 and they all were reported today.
[16:33] <ogasawara> jsalisbury: would also be good to know if it's easily reproducible
[16:33] <ogasawara> jsalisbury: didn't apport kerneloops get turned back on recently?
[16:33] <jsalisbury> ogasawara, One reporter says it happens every three minutes.
[16:33] <jsalisbury> ogasawara, I don't think so.  I asked for it to be turned on, but kerneloops.org is still down.
[16:34] <ogasawara> jsalisbury: I though bdmurray mentioned he could disable sending it on to kerneloops but still get the reports filed in lp
[16:34] <ogasawara> jsalisbury: regardless, might be good to work with the reporter who triggers it every 3 minutes to narrow down the window of regression
[16:34] <jsalisbury> ogasawara, Ahh, right, he did mention that.  I think he commented out that code in apport.
[16:35] <jsalisbury> ogasawara, will do.  I'll work on getting the version it was introduced then bisect.
[16:35] <bdmurray> jsalisbury, ogasawara: yes apport and kerneloops have both been uploaded
[16:36] <bdmurray> jsalisbury: that'd be a good bug to write a pattern for ;-)
[16:36] <jsalisbury> bdmurray, yes indeed.  I'll write one up for this.
[16:57] <apw> ogasawara, there?  i want to push up an overlayfs update, that ok ?
[16:57] <ogasawara> apw: yep go for it.
[16:58] <ogasawara> apw: also saw your conversation this morning about iommu configs, I've got them fixed up and pending some testing from bug reporters before I push them.
[16:58] <apw> as in copying the pre-rename values forward ?
[16:58] <ogasawara> apw: yep
[16:59] <ogasawara> apw: which results in INTEL_IOMMU_DEFAULT_ON to be disabled and will likely resolve a lot of the iommu bugs we're seeing
[16:59] <apw> yeah
[16:59] <apw> ogasawara, sounds good to me
[16:59] <ogasawara> apw: for anyone who really wants it enabled, they can boot with "intel_iommu=on"
[17:00] <ogasawara> apw: I just want to get confirmation on some of the bugs first so I can shove the BugLinks in the commit
[17:00] <apw> very reasonable
[17:23] <doctormon> I'm trying to trace a critical bug in 12.04 kernel, but I admit I'm not very good at kernel stuff. Can someone give me a walk through?
[17:35] <apw> doctormon, some background would help
[17:39] <apw> ogasawara, oh did i mention the new script for adding teh 'rebased to' in the changelog which also finds any LP references?
[17:40] <ogasawara> apw: no, what's it called?
[17:40] <apw> debian/scripts/misc/insert-mainline-changes
[17:40] <apw> which makes sure we detect and close bugs which come back from upstream
[17:41] <ogasawara> apw: nice, I'll have to use it after the next rebase
[17:43] <doctormon> apw: An error in the kernel is causing the pci bus to fail, this causes the video to fail on any driver (vga/nouvou/nvidia) and a black screen to apear.
[17:43] <doctormon> Sorry for the delay, meeting :-)
[17:43] <apw> and we know its the pci bug how ?
[17:43] <apw> pci bus
[17:45] <apw> doctormon, and is there a bug open for this behavior
[17:46] <SpamapS> So, I'm on the upstream kernel (3.2.1-030201) on precise, and bcmwl doesn't seem to be working
[17:46] <apw> SpamapS, have you installed the headers?  so that the modules get built ?
[17:47] <SpamapS> apw: indeed, if I dpkg-reconfigure bcmwl-kernel-source the module is built
[17:47] <apw> and how does it fail ?
[17:47] <apw> oh i bet it fails to laod
[17:47] <SpamapS> -rw-r--r-- 1 root root 3155008 Jan 18 09:39 /lib/modules/3.2.1-030201-generic/updates/dkms/wl.ko
[17:47] <apw> if you modprobe wl, what happens, what do you get in dmesg ?
[17:48] <SpamapS> wl                   2568210  4294967295 [permanent]
[17:48] <SpamapS> [    8.586967] wl: module license 'MIXED/Proprietary' taints kernel.
[17:48] <apw> ahh so that says, you build wl with the wrong compiler
[17:48] <apw> wh
[17:48] <apw> which is true, as we don't build in precise
[17:48] <apw> so i am not supprised it doesn't work
[17:48] <SpamapS> wasn't this supposed to be open sourced / upstreamed at some point like.. a year ago?
[17:48] <apw> we really don't expect you to be using kernels in tis way
[17:49] <apw> yep they are working on it, there is brcmsmac now which works for my cards
[17:49] <apw> what device do you have ?
[17:50] <SpamapS> 02:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n (rev 01)
[17:50] <SpamapS> mac book air 4,1
[17:50] <apw> heh mac, you lose ;)
[17:50]  * SpamapS melts like the witch doused with water
[17:50] <apw> why the heck are you using an upstream kernel anyhow?
[17:50] <SpamapS> Because the precise kernel is unusable for me on this one
[17:50] <apw> why so?
[17:50] <SpamapS> keyboard cuts in and out, touchpad does not work
[17:51] <apw> and 3.2.1 works ?
[17:51] <SpamapS> Figured I'd try 3.2.1 before going into bug filing mode
[17:51] <apw> tgardner-afk, isn't that one of the ones you have ?
[17:52] <apw> ENOseth
[17:52] <apw> SpamapS, ok to build wl right you need to make a lucid chroot and install the dkms package in there
[17:52] <apw> let it build the modules, and use the result
[17:52] <apw> (all very painful)
[17:53] <SpamapS> oh *awesome*
[17:53] <apw> they arn't meant for anthying other than a quick test
[17:53] <apw> and well binary stuff is always a HUGE pain in the ass, and this is just one example
[17:54] <SpamapS> ok, well in this case, my quick test is, whatever is wrong with the keyboard and touchpad in the precise kernel is fixed in the upstream kernel
[17:54] <apw> this is why one should not buy machines which need binary stuff ever
[17:54] <apw> you don't need wireless to test that
[17:54] <SpamapS> apw: I failed .. the shiny... it sparklezzzz
[17:54] <apw> magpie
[17:55]  * apw suggests the ethernet socket :)
[17:55] <SpamapS> apw: so should I make sure to report the bug or just hope that whatever these fixes are will land in the next precise kernel?
[17:55] <apw> i'd file something, we won't notice if its on a mac and not one of the 4 we bought
[17:56] <apw> SpamapS, specially as we're now onto stable kernel updates so much less will get fixed without action
[17:58] <SpamapS> apw: alright, will do... hopefully I can coax the keyboard enough to get a decent report typed in. :-P
[18:00] <apw> SpamapS, and go figure out the latest ernel which did work, as i assume it worked in O
[18:00] <apw> they are all in the launchpad librarian for your enjoyment
[18:01]  * SpamapS looks around for the SpamapS-bisect tool that will automatically reboot his machine with each version since 3.0.0-12
[18:04] <doctormon> apw: Because going into the root shell mode, lspci shows all the bus ids to be 0000, which is unlikely to happen.
[18:04] <doctormon> I've dug up an older bug report
[18:05] <apw> doctormon, and which kernel is exhibiting this behaviour
[18:05] <doctormon> https://bugs.launchpad.net/bugs/661248
[18:05] <ubot2> Launchpad bug 661248 in nvidia-graphics-drivers "PCI Race Condition with COMPAL FL90" [High,Incomplete]
[18:05] <doctormon> Linux delen 3.2.0-9-generic #16-Ubuntu SMP Fri Jan 13 22:16:32 UTC 2012 i686 i686 i386 GNU/Linux
[18:07] <apw> ogasawara, what was the symptoms of that MMCONFIG change that you just applied ?
[18:08] <ogasawara> apw: frequent system hangs/pauses and repeated spewing of error messages to dmesg
[18:08] <apw> doctormon, and is that the old report or your bug ?
[18:08] <ogasawara> apw: bah, I take that back, /me confused my bugs
[18:09] <ogasawara> apw:  the MMCONFIG one is busted usb ports
[18:09] <doctormon> apw: it's an old report, and my bug
[18:09] <apw> doctormon, when did this issue appear for you
[18:09] <doctormon> want a new one?
[18:10] <apw> i want a bug report from the machine with the issue when it has the issue yes
[18:10] <doctormon> Kernel 2.6.35, Maverick
[18:10] <apw> so it last worked in maverick ?
[18:11] <doctormon> apw: No it first appeared in maverick, it work in 2.6.32 lucid.
[18:11] <doctormon> worked*
[18:12] <apw> ok so do file a bug from the machine when running precise if you can
[18:12] <apw> as thats a valid update L -> P
[18:13] <doctormon> apw: When it's working or when it's failed? I presume failed.
[18:13] <apw> if you can when its failed indeed
[18:13] <apw> as the pci stuff will be right then
[18:14] <doctormon> OK, command line bug tool, that doesn't need a browser right?
[18:14] <doctormon> Why do I get the feeling I might have to do this manually...
[18:14] <apw> if it can work then also get a dmesg froma working boot and an lscpi)
[18:14] <apw> well if it can work sometimes you could make the bug in a working moment (and say so)
[18:14] <apw> and add the two files above from the broken one manually
[18:15] <apw> as in if precise will work sometimes
[18:15] <amitk> apw: any of you showing up for ELC in ~1month?
[18:17] <apw> unsure as yet
[18:24] <doctormon> apw: thanks for your help
[18:26] <apw> cking, do we have AGP on arm, i assume not ?
[18:27] <cking> apw, not to my knowledge
[18:32] <apw> cking, config seems to agree, good, thanks
[18:32] <cking> sanity exists
[19:03]  * tgardner --> lunch
[19:17] <doctormon> apw: Bad news, I went to collect the dmesg/lspci, the recover mode doesn't boot
[19:20] <doctormon> Stops just after doing ACPI, a message that says to use "pci=usr_crs" which I will try a few times.
[21:22] <thomi> Hi - Can anyone help give me an update on lp:901386 ? It's turned my brand new laptop into an unusable brick, which isn't so good for work productivity ;)
[22:27] <hallyn> apw: what's the process you followed to get your kernel.org account back?  did you jsut send an email to hpa?
[22:28] <BenC> thomi: running alpha releases isn't so good for work productivity either :)
[22:28] <BenC> thomi: if it's too much of an issue, I see there are plenty of working alternatives until it gets fixed
[22:33] <hallyn> hm, guess i'll try following this old email's instructions
[22:35] <thomi> BenC: none of the alternatives seem to work for me (I assume you're referring to acpi=off or intel_iommu=off). Because of that, is it worth filing a new bug?
[22:35] <BenC> No, I mean running a 3.1 kernel (e.g. not running precise, but oneiric)
[22:36] <BenC> Or use nouveau(sp?)
[22:37] <thomi> ahh ok.
[22:37] <thomi> Thanks
[23:17] <apw> hallyn, yeah i followed the original email from hpa
[23:52] <hallyn> cool, thanks.  lessee what kind of response i get, if that' still the procedure :)