=== smb` is now known as smb
[09:06]  * cking on 3G again, my ISP is doing network infrastructure changes, i.e. providing lame service
=== chrisccoulson_ is now known as chrisccoulson
[09:21] <smb> cking, The change the infrastructure to make you buy the full product. 
[09:21] <cking> if it carries on like this I will move to a different ISP
[09:21] <cking> well, 3G seems to work well enough for irc and email and they hope to get it fixed by 1pm
[09:22]  * cking notes they didn't say which day though
[09:22] <smb> Prepare for the worst... Well on the other hand. Distractionlesser day
[09:23] <cking> well, less mumble traffic today ;-)
[09:23] <apw> cking, testing your 3G ?
[09:23] <smb> cking, Right, which can be a big source of distraction
[09:24] <cking> apw, 3G seems to work quite well from my loft .. not bad really
[09:24] <smb> cking, while you are still there, have you had luck catching panics with netconsole before?
[09:25] <cking> smb, I believe not, but I haven't used it much
[09:25]  * cking can't recall 
[09:26] <cking> the plus side is that it isn't too tricky to rig up
[09:26] <smb> cking, Ah ok. Could not remember whether you had been using that at all
[09:26] <smb> Thought I had something... though did not see any message which may say I did not
[09:26] <cking> I've used it for debugging - but I'm not sure if I got any panics captured using it 
[09:28] <smb> cking, <hope>is there a setup rune on your blog?</hope>
[09:28] <cking> afraid not :-(
[09:29] <smb> cking, Oh well. Now I have to use my own brain... ;-P
[09:29] <cking> steady on
[11:56] <ppisati> ok, i sent two patches to the kernel ml but the cover letter doesn't show up WTF???
[11:58] <cking> ppisati, they show in my mailbox
[11:59] <cking> with cover letter
[12:03]  * cking switches network provider ..
[12:04] <smb> ppisati, Oh, now it does
[12:04] <smb> Seems to have taken a detour
[12:15] <cking> apw, inotify test in your inbox
[12:15] <apw> cking, ok
=== dduffey_afk is now known as dduffey
[13:23] <herton> ppisati, do you have a panda a4 board?
[13:26] <ppisati> herton: uhmm... i think i've an a2
[13:26] <ppisati> herton: why?
[13:26] <ppisati> herton: actually i've an A1
[13:27] <herton> ppisati, just thinking if you could test the fix of bug 917264, but that requires this a4 board and hdmi. Anyway, as that bug is tested on previous release with the patch on top, I may well mark that as verified
[13:27] <ubot2`> Launchpad bug 917264 in linux-ti-omap4 "HDMI resolutions are not detected on Pandaboard A4 (Omap 4430 ES2.3 silicon)" [Undecided,Fix committed] https://launchpad.net/bugs/917264
[13:28] <ppisati> herton: ah! pandaES, that's even more rare than a real Panda :)
[13:44] <apw> http://www.theregister.co.uk/2012/02/03/bt_vision_upgrade/
=== bladernr_afk is now known as bladernr_
[14:46] <brendand> can anyone think of a good reason why the first cpu core would be offlines by default on say a 16 core system?
[14:48] <brendand> i've seen it on two systems. two different models of processor, the common thread being they are both 16 core
[15:11] <hallyn> apw: bug 925028, is there any chance you'll have time for that?  do you have any idea what the problem is offhand?
[15:11] <ubot2`> Launchpad bug 925028 in lxc "apparmor breaks lxc-start-ephemeral (apparmor+overlayfs returns -EINVAL)" [High,Confirmed] https://launchpad.net/bugs/925028
[15:17] <brendand> Daviey - i'm seeing a couple of servers here running Alpha 2 which have one of their 16 cores offline by default. seems a bit strange - does it make any sense to you?
[15:20] <skaet> hiya,  anyone know if bjf will be around today?
[15:20] <apw> hallyn, another issue ?
[15:20] <hallyn> apw: apparmor returns -EINVAL on any overlayfs file
[15:21] <hallyn> apw: it's possible this is purely apparmor's problem and I should hit up jjohansen again, but I wasn't sure
[15:21] <apw> hallyn, cirtainly we should get jj involved yes
[15:27] <apw> hallyn, gawd what does this drivel even mean ...
[15:28] <hallyn> the code, or my report?
[15:29] <apw> hallyn, this is a case of it making sense to the reader, if they get lxc and apparmor i suspect
[15:29] <apw> hallyn, so #3 does that say that you don't need a container here
[15:30] <hallyn> right
[15:30] <hallyn> just mount an overlayfs, have an enforcing apparmor policy, boom
[15:30] <hallyn> which means, i'd expect libvirt to fail on livecd
[15:30] <hallyn> (untested)
[15:31] <apw> i'd not expect you to want to use libvirt on a live cd, but hey
[15:31] <apw> hallyn, anyhow i'll poke jj and see what this means
[15:32] <hallyn> apw: tahnks.  sorry, yesterday i was pretty sure it was just another missing hook, but now i'm thinking not...
[15:33]  * ogasawara back in 20
[15:39] <jjohansen> hallyn: hrmm, that sounds wrong, give /me needs to get kids off to school and then I can look at it
[15:40] <apw> hallyn, what does this capabilities list even say ?  is that essentially "allow all" ?  the one in #3 ?
[15:41] <apw> jjohansen, lets talks when you get back
[15:41] <jjohansen> apw: sure.
[15:42] <apw> jjohansen, you can teach me what this gibberish in dmesg means
[15:42] <jjohansen> apw, hallyn: apparmor only return EINVAL in a few places
[15:43] <hallyn> i see, the gibberish is my policy :)
[15:43] <hallyn> anyway we don't want to allow all - we'll want to deny cap_mac_admin and cap-mac_override in final policy
[15:48] <apw> hallyn, yeah i was trying to work out if the policy there was actually essentially a noop
[15:54] <hallyn> apw: the one in the example was meant to be a noop
[15:54] <apw> hallyn, ok cool ... thanks thats what it looks like
[15:54] <hallyn> changing locales - biab
[16:37] <skaet> ogasawara, did you ever hear back from bjf (from last week) about the rls-mgr-p-tracking report, and why its not updating?
[16:37] <bjf> skaet: i just updated it this am, is it not correct?
[16:37] <ogasawara> skaet: he fixed it
[16:37] <bjf> skaet: it should have been working just fine
[16:40] <skaet> Friday, 20. January 2012 02:01 UTC 	  Themes:   DARK   LIGHT
[16:40]  * skaet trying again
[16:41] <skaet> yeah,  cache reload still showing that to me. 
[16:41] <bjf> one sec
[16:44] <bjf> skaet, mine says "Friday, 03"
[16:45] <ogasawara> looks up to date -> http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
[16:45] <bjf> skaet, i also looked at the timestamp on the file on cranberry and it is this am
[16:45] <ogasawara> out of date -> http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-bugs.html
[16:46] <bjf> ogasawara: yes, the second is out of date
[16:47] <skaet> bjf,  its the second one (rls-mgr-p-tracking) I'm trying to get working again.  :)
[16:48] <bjf> skaet: ok, that wasn't clean. fixing now
[16:48]  * skaet thinks we need to rename those reports and the tags....  later though.  :P
[16:48] <bjf> skaet: it was turned off several weeks ago, i've re-enabled it and it's running
[16:49] <skaet> bjf - any idea why it was turned off?
[16:49] <bjf> skaet: didn't think anyone was looking at that one, just the other and it was sucking cycles
[16:49] <bjf> skaet, it will now run with all the rest
[16:50] <bjf> skaet: or maybe i turned it off last week when debugging that issue, and just forgot to re-enable it
[16:50] <bjf> skaet: anyway, it should be fixed now
[16:50] <skaet> bjf,  thank you.   the rls-mgr-p-tracking one is where folks are tagging things that should be considered.   rls-p-tracking is only those things that teams COMMIT to fix. 
[16:50] <bjf> skaet: (as soon it regenerates)
[16:51] <skaet> there's a delta between the consider and the commit - both are useful.
[16:51] <skaet> however - the tags do seem to be causing confusion.
[16:52] <skaet> maybe a transition to something like consider-p-tracking,  commited-p-tracking at some point in the future?
[16:52] <bjf> skaet: feel free, it's in bzr :-)
[16:52] <skaet> bjf,  heh,  A2 is out the door - time for a new learning curve for me I guess...
[16:54] <jjohansen> apw: alright I am back
[16:54] <apw> jjohansen, hiya, balcony ?
[16:55] <jjohansen> sure
[16:55] <jjohansen> apw: sure
[17:05] <apw> [ 4184.672209] type=1400 audit(1328288723.893:35): apparmor="DENIED" operation="getattr" info="Failed name lookup" error=-22 parent=2619 profile="/bin/bash2" name="" pid=2634 comm="ls" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[17:08]  * jsalisbury see pulseaudio crash, then mumble freak out and consume 100% cpu, spinning on sched_yield()
[17:08] <hallyn> maybe thats what used to happen to my banshee
[17:09] <jsalisbury> hallyn, yeah, could be.  I have issues with banshee once and a while as well.  Now I know what to look at :-)
[17:09] <ohsix> doom to he who uses sched_yield
[17:09] <bjf> skaet: all reports should be updated now
[17:09] <ohsix> why can't they just sleep :[
[17:11] <skaet> Thanks bjf!   Yup,  now I can see all the new packages that need to be sorted into teams too.  :)   
[17:22] <ohsix> jsalisbury: that looks like a pulse bug (the _yield thing, it's done a lot to wait on async queues, something has to go really wrong though)
[17:22] <ohsix> i guess pulse crashing is wrong enough, but it should be getting a sigpipe or something in the client when it happens
[17:23] <jsalisbury> ohsix, hmm, maybe mumble likes to do things really wrong 
[17:23] <ohsix> how pulse exited is probably interesting too, killed by rtkit, killed by its own rttime quanta or killed by a crash
[17:23] <jsalisbury> ohsix, yeah, I plan on digging deeper
[17:23] <bjf> skaet: ok, i just updated the packate->teams matrix (this has to be done by hand)
[17:23] <ohsix> src/pulsecore/shmasyncq.c:#define _Y pa_thread_yield()
[17:24] <ohsix> :[
=== yofel_ is now known as yofel
[17:24] <ohsix> wait a minute, it only does that during debugging
[17:24] <skaet> bjf - thanks.  I'll be making more changes to the package-team spreadsheet later today (lots of lovely new packages this release showing up)  do you want to teach me to fish,  so I can do the update for you in future?
[17:25] <ohsix> i dunno what else could be calling _yield then, mumble only does in some speex performance test, not in the program proper
[17:25] <bjf> skaet, bdmurray: i just regenerated all reports, they are now as up-to-date as i can make them
[17:25] <bjf> skaet: can do
[17:25] <skaet> bjf,  ok,  as soon as I get the next round of changes in,  I'll ping you and you can walk me through it.
[17:26] <jsalisbury> ohsix, interesting.  I better check all my mumble settings again.  If I can get it to startup again :-/
[17:26]  * ogasawara back in a bit
[17:44] <GrueMaster> ppisati, herton:  linux-omap meta for maverick needs to be updated.  It only installs linux-image-2.6.35-24-omap. 
[17:46] <herton> GrueMaster, indeed they were removed from linux-meta previously, I'll look into fixing it
[17:49] <GrueMaster> Testcases pass once I got the right kernel installed.  Running the rest of the SRU gammit now.
[17:52] <jono> jsalisbury, hey
[17:53] <jsalisbury> jono, howdy
[17:53] <jono> jsalisbury, just updated the bug
[17:53] <jsalisbury> jono, cool, I'll take a look
[17:53] <jono> I think that is all the testing I can do on the available kernels
[17:53] <jono> thanks
[17:53] <jono> the bug occurs between 3.0 and 3.1rc2
[17:54] <jsalisbury> jono, thanks for testing. 
[17:54] <jono> thanks
[17:57] <jsalisbury> jono, I'll check what changed between  3.0 and 3.1rc2.  Would you be able to test some additional test kernels if I bisect?
[17:57] <jono> jsalisbury, sure
[17:57] <jsalisbury> jono, awesome!  I'll update the bug
[18:08] <tgardner> apw, I'm wondering how you use debian/scripts/misc/insert-mainline-changes ?
[18:09] <apw> insert-mainline-changes debian.master/changelog v3.2.3 v3.2.2..v3.2.3
[18:09] <apw> tgardner, something like that
[18:10] <apw> it allows you to specify the range in case you don't have the tags, so you can use sha1s if you need to
[18:10] <apw> tgardner, then you'll find git diff shows what its done to changelog
[18:10] <tgardner> and you've documented this where ?
[18:10] <apw> :))
[18:11] <apw> tgardner, if there is somewhere you'd recommend, i can add it
[18:11] <tgardner> how abiout just getting it in the help message with a quick example
[18:11] <apw> yeah that would have made sense
[18:12] <apw> tgardner, i'll do it now and push it up, you can cherry it onto your rebase before you push
[18:13] <tgardner> apw, so all I got from that was '* rebase to v3.2.3'. does that mean there were no buglinks ?
[18:13] <apw> tgardner, thats the implication if i didn't mess up the incantation :)
[18:13]  * apw checks
[18:14] <apw> tgardner, indeed no buglinks so ... it did nothing, but thats not always the case
[18:15] <apw> and i assume ogasawara used it for the 33-rc1 rebase, which would have had a bunch i bet
[18:16] <apw> ogasawara, which reminds me, we probabally need to include -v when we upload the first one into Q if we want those buglinks to work
[18:17] <ohsix> anyone know offhand of any of the ld_preload hacks to lessen the impact on the file cache for cron jobs and such? akpm had something on userweb.kernel.org but it's not there anymore
[18:19] <ohsix> oh neat i think i found a descendent of it on google code
[18:26] <cking> ohsix, is this what you are referring to? http://smackerelofopinion.blogspot.com/2009/06/does-prelinking-speed-up-boot-times.html
[18:28] <ohsix> cking: not unless it uses an LD_PRELOAD hack to keep read pages out of the page cache (i'm trying to get a duplicity cron job that's run hourly to not completely destroy interactivity for most of the hour between runs)
[18:28] <cking> ohsix, in which case, it's not what you're looking for
[18:29] <ohsix> there was a flag added a while ago but it was wired up to a no-op, dunno if this got in http://lwn.net/Articles/449420/
[18:30] <ohsix> looks like they made rsync use it already too, librsync doesn't (or can't, don't think it deals with files directly)
[18:32] <tgardner> apw, have you pushed? vanilla 3.3 don't build anyways. working on figuring out the missing dependency
[18:32] <tgardner> 3.2.3*
[18:33] <apw> tgardner, waiting on atime wrappage update time disk hell
[18:33] <cking> apw, that always seems to coincide with beer time doesn't it?
[18:35] <apw> i think there is a cirtain alignment :/
[18:37] <ohsix> bummer, _NOREUSE is still a no-op
[18:39]  * cking -> EOD
[18:39] <apw> tgardner, pushed
[18:45] <ohsix> heh posix_fadvise DONTNEED on linux trashes all the file pages no matter who has it open, that seems fun
[19:03] <vanhoof> ogasawara: heya
[19:06] <bryceh> bjf, you might adjust your kernel bot to not bug reporters if the kernel-handoff-graphics tag is present; generally we only add that when we pretty much already know the bug's disposition (and usually have found a fix)
[19:07] <bjf> bryceh: can do
[19:10] <bjf> bryceh: you have an example bug?
[19:13] <tgardner> ogasawara, pushed precise master-next with v3.2.3 stable. there is likely more carnage yet to come as I expect Greg will release v3.2.4 shortly due to compile issues.
[19:13]  * tgardner -> lunch
[19:20] <ogasawara> tgardner: ack, thanks.
[19:20] <ogasawara> vanhoof: hi
[19:20] <bryceh> bjf, yeah hang on
[19:27] <bryceh> bjf, 912992 854986 
[19:27] <bryceh> bjf, seems like there was another one I saw the other day but am not putting my finger on it
[19:28] <vanhoof> ogasawara: quick question on the cw-3.2 lbm update for oneiric
[19:28] <vanhoof> ogasawara: will what's in -proposed now have to land before we see the fix in 923900 land?
[19:29]  * vanhoof is not exactly sure how the lbm cadence works
[19:31] <ogasawara> vanhoof: hrm, it could go up separately, but I suspect bjf/herton will just want up coordinate it with the kernel in -proposed.
[19:34] <herton> ogasawara, vanhoof: I't not sure how it was done previously, may be we could shove this new version into current -proposed
[19:34] <bjf> herton, i'm fine with pushing it
[19:34] <ogasawara> herton, vanhoof: it looks like https://launchpad.net/ubuntu/+source/linux-backports-modules-3.0.0/3.0.0-16.8 has already been uploaded to -proposed
[19:34] <vanhoof> herton: yeah this is the first time i've encountered a bug like this 
[19:35] <ogasawara> herton, vanhoof: so I suspect it'll move to -updates at the same time as the kernel
[19:36] <vanhoof> ogasawara: and then the next upload would be another update to lbm to factor in bug 923900 ?
[19:36] <ubot2`> Launchpad bug 923900 in linux-backports-modules-3.0.0 "Enable iwlwifi drivers for compat-wireless v3.2 backports" [Undecided,In progress] https://launchpad.net/bugs/923900
[19:36] <herton> yes, 3.0.0-16.8 is the current one in -proposed, as it didn't move yet to -updates (and I think it will wait for more 1 week for it), I think a new lbm could be copied so it gets along when -proposed moves
[19:37] <herton> we just would have to ask an archive admin to copy a new lbm over proposed again
[19:37] <ogasawara> vanhoof: yep, sorry.  we would need another upload LBM to resolve 923900.  but as herton just mentioned, they should be able to shove that up now.
[19:38] <vanhoof> ogasawara: no worries, and thanks for the info :)
[19:39] <ogasawara> herton, bjf: I assume LBM is not under as strict a QA schedule as the kernel since it's an elective install.  and I'm sure vanhoof is willing to give you immediate testing feedback.
[19:39] <vanhoof> and beer
[19:39] <bjf> ogasawara: i don't think QA knows LBM exists
[19:40] <herton> yeah, never saw anyone mentioning QA of lbm. I'll prepare a new lbm, and ask it to be copied then to -proposed. I already have to ask for a new linux-meta copy for maverick also, because of the missing omap/versatile metas
[19:50] <vanhoof> herton: bjf: just poke me and I can get some widespread testing done quickly
[19:50] <herton> ack
[19:51] <bjf> vanhoof: ack, i'd expect monday actually before it hits -proposed
[19:51] <vanhoof> bjf: good deal
[19:52] <vanhoof> thanks guys :)
[20:05] <tgardner> ogasawara, v3.2.3 boots, ship it!
[20:06] <ogasawara> damn, we still gotta get 3.2.0-13.22 out.  /me checks if arm is finished building
[20:07] <tgardner> ogasawara, I was thinking we might oughta skip -13
[20:07] <ogasawara> tgardner: works for me
[20:09] <tgardner> ogasawara, if you upload today, it should be done by monday.
[20:09] <ogasawara> tgardner: ack, prepping the upload now
[20:10]  * ogasawara gets ready to hammer on gomeisa
[20:12] <tgardner> ogasawara, are the chroots on gomeisa behaving normally? I'm still having issues with resolvconf in the precise chroot.
[20:13] <ogasawara> tgardner: i was doing test builds yesterday and all seemed fine
[20:13] <ogasawara> tgardner: but I didn't look closely at the logs to see if anything was amiss
[20:13] <tgardner> ogasawara, I need to make sure that the resolvconf issues aren't preventing package updates.
[20:14] <tgardner> guess I should build a lucid host on one of my local boxes and make sure.
[20:16] <tgardner> that sounds like a good weekend project.
[20:37] <Beret> so, I just filed a fatal usb bug and a bot told me I was running an old kernel 
[20:37] <Beret> which is not true :)
[20:38] <Beret> anyone seen "HC died" messages?
[20:38] <ohsix> what type of host controller?
[20:38] <ohsix> and the bot checks the packages available vs. what's installed as a gentle reminder to update and try the latest
[20:38] <ohsix> or you're running a kernel that doesn't match the regular version pattern
[20:39] <Beret> I believe intel
[20:39] <Beret> no
[20:39] <Beret> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926310
[20:39] <ubot2`> Launchpad bug 926310 in linux "USB failing" [Undecided,Incomplete]
[20:39] <Beret> I'm running the latest kernel in precise
[20:39] <Beret> but that bug happened occasionally in oneiric and all the time in precise
[20:39] <Beret> never in natty
[20:40] <Beret> I thought my little kvm switcher was to blame
[20:41] <Beret> so I plugged the keyboard/mouse in direct, and I get the same behavior
[20:41] <Beret> doesn't matter what's plugged in
[20:41] <Beret> given a little time, it dies
[21:04] <tgardner> ogasawara, you've likely got precise tied up in a bow and ribbon and are ready to upload ?
[21:04] <ogasawara> tgardner: I've got it ready, just waiting for powerpc test build to finish up
[21:05] <tgardner> ogasawara, greg released 3.2.4 with the 2 reverts I suggested, but since they are already reverted from our tree we can just skip it
[21:05] <ogasawara> tgardner: ack
[21:08] <tgardner> ogasawara, so I just re-installed the precise chroots on a lucid host which seemed to work OK. I guess I'll re-install gomeisa one more time. you done for now ?
[21:09] <ogasawara> tgardner: can you gimme 10min?  just kicked off a build.
[21:09] <tgardner> ogasawara, no problem. I can do it later this weekend
[21:09] <tgardner> I'm about EOD
[21:09] <tgardner> it _is_ friday, the sun is shining, and I find myself in need of a beer
[21:10] <ogasawara> I've purposely lowered the blinds to not be distracted by that giant fireball in the sky
[21:11] <bdmurray> heh
[21:13]  * tgardner is outta here
[21:13] <bdmurray> jsalisbury: I just ran across bug 924455 (a ubiquity bug) which has an oops in it
[21:13] <ubot2`> Launchpad bug 924455 in linux "kernel oops running installer" [Undecided,New] https://launchpad.net/bugs/924455
=== panda is now known as Guest88129
[21:28] <jsalisbury> bdmurray, thanks, I'll take a look
[21:33] <hallyn> tgardner: I'm looking at bug 898003.  Do you think it'd be reasonable to build usbip from the kernel package (as it all now ships under drivers/staging)?
[21:33] <ubot2`> Launchpad bug 898003 in linux "usbip source is maintained in kernel tree now" [Low,Confirmed] https://launchpad.net/bugs/898003
=== dduffey is now known as dduffey_afk
[21:40] <mjg59>  /win 34
[21:57] <bjf> bryceh: the bot should not bother bugs tagged kernel-handoff-graphics any longer
[22:06] <bryceh> bjf, awesome thanks
[22:20] <htorque> bryceh: hi! about to test if bug 899159 is still a problem → mesa 8.0~rc2-0ubuntu4 is the right version?
[22:20] <ubot2`> Launchpad bug 899159 in xserver-xorg-video-intel "[snb-gt2] GPU lockup render.IPEHR: 0x7b009004 [Needs mesa 7.11+git]" [High,In progress] https://launchpad.net/bugs/899159
[22:23] <bryceh>   htorque sounds good
[22:26] <Sarvatt> htorque: please please please dont test unigine benchmarks for it, they have an application bug and its not expected to work with whats up currently 
[22:26] <Sarvatt> oilrush is the only unigine using app thats been updated to work right
[22:27] <ohsix> what's the bug?
[22:29] <Sarvatt> ohsix: https://bugs.freedesktop.org/show_bug.cgi?id=45238 it's fixed in mesa master by adding application specific hacks so it works but not on 8.0 branch yet
[22:29] <ubot2`> Freedesktop bug 45238 in Mesa core "[regression] Unigine Heaven, OilRush broken in git" [Normal,Resolved: notourbug]
[22:30] <ohsix> Sarvatt: thanks for the ref
=== zz_bigbashi is now known as bigbash
[22:32] <htorque> bryceh: didn't went well, immediately got a 0x7a000002 hang (no apport crash file)
[22:32] <htorque> bryceh: unity somehow acted up (everything was running but no window manager/launcher/panel was showing), restarting unity fails with "intel_do_flush_locked failed: Input/output error"
[22:36] <Sarvatt> bryceh: https://bugs.freedesktop.org/show_bug.cgi?id=42538
[22:37] <ubot2`> Freedesktop bug 42538 in Drivers/DRI/i965 "Sandybridge GPU hang + reset while running OpenGL application" [Normal,Reopened: ]
[22:37] <bryceh> htorque, ok, then the bug report should get forwarded upstream now
[22:37] <bryceh> htorque, thanks for testing
[22:49] <bryceh> Sarvatt, yeah looks like that is htorque's bug
[22:52] <htorque> bryceh: not seeing those "[drm:pch_irq_handler] *ERROR* PCH poison interrupt" messages in dmesg, but else sounds similar to what i see.
[22:52] <Sarvatt> those have nothing to do with the bug
[22:53] <htorque> bryceh: what can i do with this apitrace.log to reproduce it?
[22:53] <Sarvatt> those usually show up with a dock or kvm in use
[22:54] <htorque> ok, ignored. :-)
[22:54] <bryceh> htorque, not sure
[22:55] <Sarvatt> its not packaged but you can replay the .trace with apitrace https://github.com/apitrace/apitrace its definitely a mesa bug
[22:58] <htorque> Sarvatt: thanks, will try
[23:05] <htorque> bryceh: Sarvatt: yes, that produces the same 0x7a000002 hangs for me
[23:09] <Sarvatt> htorque: kinda odd is every reporter of the same bug I can find is using a desktop K series sandybridge CPU
[23:09] <Sarvatt> 8086:0112
[23:09] <Sarvatt> mobiles don't seem to be affected, no wonder I can't reproduce it
[23:10] <Sarvatt> i only have desktop non-K series (8086:0102) and all the mobiles handy
=== yofel_ is now known as yofel
[23:14] <htorque> i only got a thinkpad with an arrandale with a hd 2000 :-(
=== bigbash is now known as zz_bigbash
=== rsalveti` is now known as rsalveti