=== Azelphur is now known as zz_Azelphur
=== zz_Azelphur is now known as Azelphur
=== kklimonda1 is now known as kklimonda
=== Azelphur is now known as zz_Azelphur
=== zz_Azelphur is now known as Azelphur
=== Azelphur is now known as zz_Azelphur
=== zz_Azelphur is now known as Azelphur
=== Azelphur is now known as zz_Azelphur
=== zz_Azelphur is now known as Azelphur
=== Azelphur is now known as zz_Azelphur
=== zz_Azelphur is now known as Azelphur
[04:32] <vish> !away > zz_Azelphur, Azelphur 
[05:52] <RAOF> Does anyone happen to have a sandybridge system lying around to test the new mesa on?
=== soren_ is now known as soren
[09:56] <bryceh_> Oneiric Ocelot
[10:03] <RAOF> ?
[10:06] <vish> ha! the naming has begun!
[12:45] <brobostigon>  http://paste.ubuntu.com/576959/ https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/730099
[12:45] <ubot4`> Launchpad bug 730099 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup 0c40b170 (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 1) (heat: 6)" [Undecided,New]
[12:46] <brobostigon> hi, i wrote that bug up yesterday, after experiencing it, for a few days, any ideas as to how this canbe resolved,please.
[13:06] <cnd> tjaalton, if you're around, would you be interested in uploading a package for me?
[13:07] <cnd> it's a new package that I have rights to upload to, but the rights can't be managed untill it's in the archive :(
[13:08] <tjaalton> cnd: sure
[13:10] <cnd> tjaalton, http://people.canonical.com/~cndougla/utouch/
[13:10] <cnd> the package is "libgrip"
[13:14] <tjaalton> cnd: ok, uploaded
[13:17] <cnd> thanks!
[13:51] <brobostigon> hi,it justhappened again under natty while running unity. 730099
[14:02] <brobostigon> i have just updated that bug, with info about the lockup that haoened a few minutes ago.
[14:41] <brobostigon> anyone got a eeepc 900 ssd, with the gpu in 730099, with natty, with all recent updates,who can confirm such a bug exists please.
[14:52] <lag> cnd: Hey buddy
[14:52] <lag> cnd: Did you manage to have a look into my little problem?
[14:53] <cnd> lag, not yet :(
[14:53] <cnd> I'll try to get to it today though
[14:53] <lag> cnd: Okay, I'll not nag :)
[14:53] <lag> That would be awesome
[14:53] <lag> If you have the time
[15:32] <stefanlsd> hihi. i have a macbook pro running natty and im trying to stop syndaemon (i think) from disabling my usb external mouse when i type. under mouse touchpad you can untick -      │ tito
[15:32] <stefanlsd>                    | disable touchpad while typing - any idea how i do this for my mouse also?
[15:32] <stefanlsd> bleh, sorry for bad paste
[15:43] <soreau> There is a bug that causes xv video playback to have strange colors on rv350. I went to bisect ddx but now I see that the bug is somehow related to xorg-edgers repo because I installed master xf86-video-ati to /opt/xorg and if I point X to load these modules, video playback is fine. However even after ppa-purging and reinstalling xorg-edgers, the problem persists. I also have confirmed at least one other person had this issue using xorg-edgers
[15:46] <soreau> The question is, how can I figure out what's wrong when using xorg-edgers? Old stuff lying around? (I haven't installed anything other than xorg-edgers and ddx to /opt/xorg so far and it's a relatively clean install) or ubuntu patches? (where can I find the patch list xorg-edgers uses on top of master git component?) or any other random oddity? Really not sure how to diagnose it further
[15:47] <soreau> This wasn't happening up until about a month and a half ago
[15:48] <codemagician> Hi guys.  My 10.10 desktop machine X process regularly hits 100% and hangs my machine. I'm using Nvidia chipset card with 270.29 drivers.   Can anybody help suggest an approach to diagnose the issue?
[15:48] <codemagician> The card is Asus EN210 Silent (GeForce 210)
[15:48] <lag> What do you guys know about CMAPs?
[16:01] <hrw> hi
[16:02] <hrw> [15765.380030] radeon 0000:01:00.0: GPU lockup CP stall for more than 10020msec
[16:02] <hrw> does someone has idea how to get rid of it?
[16:03] <brobostigon> i am getting lockup errors here aswell,but on intel i915gm.
[16:03] <hrw> my gfx card is stuck now spitting this ,essage each 10s
[16:03] <hrw> thats on up-to-date natty with xfce
[16:05] <codemagician> Any takers on the 100% CPU Xorg?  By the way, its a i7 3GHz core processor so a little greedy for a single 1920x1080 display :-)
[16:07] <hrw> ok, time to reboot
[16:13] <stefanlsd> if anyone was interested, found solution - bug #219487
[16:13] <ubot4`> Launchpad bug 219487 in mouseemu (Ubuntu) "Typing blocks external mouse (affects: 4) (dups: 1) (heat: 26)" [Wishlist,Confirmed] https://launchpad.net/bugs/219487
[16:20] <brobostigon> anyone here have an eeepc or other machine with natty, who can confirm 730099, please.
[16:22] <hrw> bug 730099
[16:22] <ubot4`> Launchpad bug 730099 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup 0c40b170 (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/730099
[16:24] <hrw> would have to dig out my intel based laptop
[16:25] <brobostigon> hrw: a confirmation i am not alone would be good, because then it would give some impatus for it to be fixed, for everyones benefit.
[16:26] <brobostigon> hrw: if you could, that woukd be good, please, :)
[16:29] <hrw> sure, powerting up
[16:30] <brobostigon> thank you, :)
[16:30] <hrw> and ugrading
[16:30] <hrw> cause with system updated around 25th Feb I did not had problems
[16:31] <brobostigon> hrw: it is entirly random as to when it happens, i didnt have any problems, untill 3 days ago.
[16:32] <hrw> 715MB of updates to fetch
[16:32] <brobostigon> wow.
[16:32] <hrw> should not take more then 15-20 minutes
[16:32] <codemagician> With regards to the 100% CPU usage for xorg, somebody suggest to add "UseEvents True" to my xorg.conf file to potentially fix what they considered was a known problem in the community.  May I ask if this could be the issue?
[16:33] <brobostigon> hrw: does it have the same gpu as specified in the bug?
[16:34] <brobostigon> hrw: and by chance, do you know someone who ould fix it.?
[16:35] <hrw> mine has newer one 8086:2a43 (gm45)
[16:35] <hrw> brobostigon: no idea who
[16:35] <brobostigon> oh, ok.
[17:12] <bjsnider> codemagician, have you eliminated every other possible cause of this issue, ie. firefox or something else running?
[17:12] <codemagician> codemagician, i only had shell windows running
[17:13] <codemagician> bjsnider, i only had shell windows running
[17:13] <codemagician> bjsnider, also the screen pixelates before it crashes
[17:14] <bjsnider> is it possible this is a broken graphics card?
[17:15] <codemagician> bjsnider, another point (not sure how relevant it is) but this seems to happen within the first 10mins of startup.  If I manage to survive longer then the machine holds up.  I switch my machine off each night
[17:16] <codemagician> bjsnider, no.  I tried it in a windows box
[17:16] <codemagician> bjsnider, im not proud of that btw
[17:16] <codemagician> ;-)
[17:16] <bjsnider> codemagician, have you tried with and without compositing?
[17:17] <codemagician> bjsnider,  is that the System->Preferences->Appearance->Visual Effects ?
[17:17] <bjsnider> yes
[17:18] <codemagician> bjsnider, yes, it crashed in all 3 modes
[17:18] <codemagician> bjsnider, and often crashes especially when attempting to switch between them
[17:19] <bjsnider> did you check /var/log/Xorg.0.log?
[17:30] <codemagician> bjsnider, shall I check this after a crash?
[17:31] <bjsnider> the info is saved there, so it can be checked anytime
[17:31] <bjsnider> there are quite a few xorg logs in there too
[17:33] <codemagician> http://pastebin.com/vQDFnkxH
[17:37] <codemagician> any clues in that ?
[17:38] <bjsnider> pastebin the older logs too
[17:40] <codemagician> http://pastebin.com/YDHhx1GS
[17:41] <codemagician> line above is Xorg.0.log.old
[17:42] <codemagician> http://pastebin.com/SQQaNSiZ
[17:42] <codemagician> line above Xorg.1.log
[17:42] <codemagician> this one has fatal error line
[17:44] <codemagician> that file is referring to itself btw
[17:49] <codemagician> also, I noticed the kernel version at the top of that log doesn't match uname -a
[17:49] <codemagician> Linux reddwarf 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC 2011 i686 GNU/Linux
[17:50] <codemagician> whereas the log says "[  1279.434] Build Operating System: Linux 2.6.24-28-server i686 Ubuntu"
[17:50] <codemagician> maybe this isn't important
[18:26] <andypiper> hi folks... I have a weird Natty alpha 3 issue which may be X related
[18:27] <andypiper> I installed a fresh Natty Alpha 3 on a netbook (AAO)
[18:27] <andypiper> but on boot, no input buttons / clicks work
[18:27] <andypiper> same applies for both synaptics touchpad... and USB mouse
[18:27] <andypiper> if I go out to console a rmmod/modprobe psmouse it sometimes gets better
[18:28] <andypiper> but even then only tap-to-click works, the trackpad buttons don't
[18:28] <andypiper> should I file this against X in lp?
[18:31] <bryceh_> andypiper, the rmmod/modprobe workaround sort of suggests it's a kernel bug
[18:31] <andypiper> yes... I thought that might be the case. Hrm.
[18:31] <andypiper> okies.
[18:31] <bryceh_> andypiper, to 'linux' might be the better package.  But if you're unsure, file 'ubuntu-bug xorg' and we can take a look before sending it to the kernel queue
[18:32] <andypiper> do you mean file against both? sorry I'm confused by that statement :-)
[18:32] <andypiper> or tag it with those fields?
[18:32] <bryceh_> andypiper, a standard diagnosis method would be to try booting older or newer kernels and see if the functionality comes back
[18:33] <andypiper> right - but at the moment this is just a stock new Natty alpha 3 install... would need to hunt out older kernels I guess
[18:33] <bryceh_> 'ubuntu-bug xorg' is a command to run which will file the bug for you (and attach a mess of files we like to have)
[18:33] <andypiper> oh! cool
[18:33]  * andypiper goes off to try it
[18:33] <bryceh_> 'ubuntu-bug linux' works equally well too
[18:34] <andypiper> ok I'm going to reboot that machine to get it in the right "state" and then VNC over to run that.
[18:35] <andypiper> since currently the tap-to-click is in a working state at least (trackpad buttons not though)
[18:35] <andypiper> did wonder if it was an xorg.conf setting I'd missed on the trackpad, but so far I've not messed with the config files
[18:35] <bjsnider> codemagician, bug 441653
[18:35] <ubot4`> Launchpad bug 441653 in xorg-server (Ubuntu) "radeon graphics mode and console does not start - xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call (affects: 51) (dups: 1) (heat: 270)" [Undecided,Confirmed] https://launchpad.net/bugs/441653
[18:38] <andypiper> curiouser and curiouser... on reboot, login to gdm (via keyboard) and VNC over, right-click works, left-click doesn't (from remote system)
[18:40] <codemagician> bjsnider, this doesn't fit the symptoms 
[18:42] <bjsnider> i think it does
[18:42] <bjsnider> it's not a graphics driver bug
[18:43] <codemagician> seems strange so many people link the two
[18:45] <andypiper> ok logged my weird netbook issue as bug 730823
[18:45] <ubot4`> Launchpad bug 730823 in xorg (Ubuntu) "Input device button/click not working on fresh Natty Alpha 3 install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/730823
[18:46] <andypiper> thanks for your help bryceh_ and understand if it's eventually deemed "not an X issue" :-)
[18:46] <Sarvatt> cnd: have you already refreshed this monster 500_xi2.1.patch for xserver 1.10 final?
[18:47] <cnd> Sarvatt, no, I haven't
[18:47] <cnd> has 1.10 final been released/
[18:47] <cnd> ?
[18:48] <Sarvatt> yeah was going to throw in in xorg-edgers but this is a hell of a patch to fail on :)
[18:48] <jcristau> 10 days ago?
[18:48] <cnd> oh, I figured rc3 was going to be out for a while
[18:49] <cnd> didn't realize final would be released 24 hours later
[18:49] <cnd> Sarvatt, have you tried it to see if the patch still applies?
[18:49] <Sarvatt> http://paste.ubuntu.com/577118/
[18:50] <Sarvatt> haven't even looked at the hunks yet, just saw it failed and asked right away in case you already knew about it
[18:50] <cnd> ahh, not bad
[18:50] <cnd> Sarvatt, I can clean it up if you need
[18:50] <codemagician> bjsnider, this fits my problem https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/617994
[18:50] <ubot4`> Launchpad bug 617994 in nvidia-graphics-drivers-180 (Ubuntu) "Slow performance and high CPU usage on Maverick (dup-of: 629910)" [Undecided,Confirmed]
[18:50] <ubot4`> Launchpad bug 629910 in nvidia-graphics-drivers (Ubuntu Maverick) (and 1 other project) "nvidia 256.53 xorg-server 1.9.0 performance regression with antialiased text (affects: 73) (dups: 2) (heat: 310)" [High,Fix released]
[18:50] <cnd> Sarvatt, but I would think it should be straightforward to fix it
[18:51] <cnd> Sarvatt, in fact, I'm guessing wiggle --replace will probably take care of the failures by itself
[18:51] <cnd> configure.ac and xf86Module.h changes are trivial
[18:51] <Sarvatt> okie i'll fix it up
[18:52] <cnd> the failure in test/input.c is interesting cause I wouldn't think it would fail
[18:52] <cnd> so that could be more challenging
[18:52] <cnd> but it shouldn't be hard
[18:53] <bjsnider> codemagician, that bug was fixed, and everyone had that bug. all nvidia users
[18:53] <cnd> Sarvatt, are the binary blob drivers fixed for 1.10 abi again?
[18:53] <Sarvatt> cnd: yep since last week
[18:53] <cnd> cool
[18:54] <bjsnider> well, nvidia is
[18:57] <codemagician> bjsnider, not sure what to say.  it happens and there is nothing running only shell windows
[19:02] <Azelphur> Trying to help the nouveau people with an mmio trace for my gtx 570, in order to do so I need to reload the nvidia module. I can rmmod it fine but when I try to modprobe it it says that the module doesn't exist.
[19:02] <Azelphur> Anyone know how to solve that one?
[19:06] <Sarvatt> cnd: yeah that wasnt a big deal at all, it was just http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.10-branch&id=93a73993708b1345c86ec3ec06b02ed236595673 and the abi bumps
[19:06] <cnd> ahh
[19:06] <cnd> Sarvatt, thanks for doing that for me :)
[19:12] <Sarvatt> http://sarvatt.com/downloads/patches/500_xi2.1.patch in case it comes up again when i'm not around
[19:14] <Sarvatt> ugh, amd64 buildds are backed up a few hours but i386 isn't, why does that always happen when I need to rebuild the world for a new xserver abi transition? :D
[19:15] <Sarvatt> (ppa's dont autoretry dep waits so uploading before xserver builds on all arches is a PITA)
[19:16] <cnd> Sarvatt, are you pushing your changes to git?
[19:16] <cnd> I actually have some bug fixes for that patch
[19:16] <cnd> so either I merge my fixes into that refreshed patch
[19:16] <cnd> or we remerge the patch with my fixes
[19:16] <cnd> remerging would be easiest I think
[19:20] <Sarvatt> Successfully uploaded packages.
[19:20] <Sarvatt> xorg-server (2:1.10.0+git20110307+server-1.10-branch.35503964-0ubuntu0sarvatt) natty; urgency=low
[19:20]  * Sarvatt groans at automated scripts uploading when he wanted to wait
[20:15] <trinikrono> hey guys i found a bug 721080 and i was wondering if it was a dupe of 702090?
[20:15] <ubot4`> Launchpad bug 721080 in ubuntu "[arrandale] GPU lockup a5cb7103 (IPEHR: 0x01800002) (affects: 1) (heat: 254)" [Undecided,New] https://launchpad.net/bugs/721080
[20:20] <bryceh_> hi trinikrono
[20:20] <trinikrono> o/
[20:20] <bryceh_> trinikrono, the error codes there look different than the prototypical 702090 crash
[20:21] <bryceh_> trinikrono, however the thing to check is to look in the CurrentDmesg and BootDmesg for where the "GPU hang" message is
[20:21] <bryceh_> typically with 702090 this will be during boot, towards the end of the boot sequence
[20:21] <bryceh_> so like either at the end of BootDmesg or the top of CurrentDmesg
[20:22] <trinikrono> ok
[20:22] <bryceh_> also, oftentimes there'll be more dmesg spew following the error, because it resets the GPU and keeps on truckin'
[20:22] <trinikrono> because the i915errorstate makes no sense to me as yet
[20:22] <trinikrono> bryceh_: so i can still mark it against xserver-xorg-video-intel right
[20:22] <bryceh_> trinikrono, if you're curious to learn, there is a tool available which converts the error codes into actual messages
[20:22] <bryceh_> trinikrono, yes
[20:23] <trinikrono> well i am curious, i seem to be finding xorg bugs everywhere i go
[20:23] <trinikrono> i use savage though if that makes a difference
[20:24] <bryceh_> trinikrono, yeah it does; the GPU dumps and i915errorstate stuff is particular to the -intel driver, but savage uses the -savage driver
[20:24] <bryceh_> trinikrono, here's a doc with a higher level explanation of the gpu dump stuff:  https://wiki.ubuntu.com/X/InterpretingIntelGpuDump
[20:25] <bryceh_> trinikrono, I think part of the problem with -savage is that since the userbase for it is much smaller than other video drivers, us ubuntu-x guys don't pay that much attention to it
[20:25] <bryceh_> trinikrono, however if you'd be interested in doing bug triage or other work on the driver, it could help a lot, and we'd certainly be able to give you tips and pointers
[20:27] <trinikrono> yes i spoke to tormod a few weeks ago about some of the savage bugs , so if i can help i will
[20:27] <bryceh_> cool, yes he keeps an eye on -savage and is a great resource
[20:31] <trinikrono> bryceh_: in your x org bugs do we look for upstream bugreports in freedesktop or is it different?
[20:35] <bryceh_> trinikrono, sometimes yes, however I tend to just forward the bugs upstream and let upstream decide whether they're dupes.  Often it's difficult for us at the distro level to know for sure
[20:36] <bryceh_> trinikrono, but I do always at least google around to see if the bug has been reported anywhere outside ubuntu (and sometimes this turns up dupes inside ubuntu too)
[21:49] <Sarvatt> looks like 116_xi2_1.patch in synaptics is going to be the painful one to maintain
[21:58] <RAOF> Sarvatt: Fortunately, we have someone to blame! :)
[21:58] <Sarvatt> RAOF: eh, our synaptics patches have always been hell to carry forward in git, not really anything new :D
[21:59] <Sarvatt> all of xserver 1.10 is up in xorg-edgers now, hopefully the rest builds fine
[21:59]  * Sarvatt is so sick of updating the mesa build system
[22:00] <Sarvatt> had to disable nouveau-vieux in there, after about 6 hours of messing with it I got fed up and started pushing the xserver 1.10 stuff
[22:00] <Sarvatt> gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mapi -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/libdrm    -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS 
[22:00] <Sarvatt> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DUSE_DRICORE  nouveau_screen.c -o nouveau_screen.o
[22:00] <Sarvatt> In file included from nouveau_screen.c:27:0:
[22:00] <Sarvatt> nouveau_driver.h:40:28: fatal error: nouveau_device.h: No such file or directory
[22:00] <Sarvatt> compilation terminated.
[22:00] <Sarvatt> make[7]: *** [nouveau_screen.o] Error 1
[22:03] <Sarvatt> need to figure out whats needed for this mesa wayland stuff ricotz pointed out still
[22:04] <bryceh_> thanks Sarvatt
[22:04]  * bryceh_ patch pilots
[22:04] <bryceh_> Sarvatt, wayland?  I have some notes that Darxus provided on what mesa patches would be required in order for doing newer wayland snapshots
[22:05] <RAOF> From memory, you need the wayland protocol stuff built first, then build mesa against that, then you can build the wayland demos with EGL support.
[22:05] <Sarvatt> the patches are upstream, there's a new wayland egl platform to use but need to figure out where all the deps go
[22:05] <RAOF> That sounds like a job for Super bryceh_, though :)
[22:06] <bryceh_> ick :-)
[22:06] <Sarvatt> also I was a bit confused about the wayland packaging, wayland-client.pc is in libwayland-client-dev, but both the library and protocol headers are in wayland-dev and there's no dependency on either of them for the other?
[22:07] <RAOF> libwayland-client isn't a dependency of libwayland-client-dev?
[22:07] <Sarvatt> nope
[22:07] <Sarvatt> unless i'm missing something
[22:07] <bryceh_> it's entirely possible I did not do that right
[22:07] <RAOF> That seems unlikely to be correct.
[22:07] <RAOF> Not that anyone's going to notice for a while :)
[22:08] <bryceh_> splitting out the client and server bits was pretty recent, and I don't think I did much testing of the -dev packages (certainly not on a clean machine)
[22:08] <Sarvatt> sudo apt-get install libwayland-client-dev
[22:08] <Sarvatt> The following NEW packages will be installed:
[22:08] <Sarvatt>   libwayland-client-dev
[22:08] <Sarvatt> sudo apt-get install libwayland-client0
[22:08] <Sarvatt> The following NEW packages will be installed:
[22:08] <Sarvatt>   libwayland-client0
[22:10] <Sarvatt> should wayland-client.h should be in libwayland-client-dev where the .pc is and wayland-client-protocol.h in the wayland-dev one?
[22:11] <ricotz> Sarvatt, bryceh_ http://people.ubuntu.com/~ricotz/wayland/
[22:11] <ricotz> moving the headers might be useful for a nicer organization
[22:14] <bryceh_> sure
[22:15] <RAOF> Do clients need wayland-client-protocol.h?
[22:18] <bryceh_> RAOF, looks like clients don't include it directly, but instead include wayland-client.h, but then that has this:
[22:18] <bryceh_> ./wayland/wayland-client.h:#include "wayland-client-protocol.h"
[22:18] <bryceh_> so... yes
[22:19] <RAOF> I guess this would be more obvious were we packaging a more recent snapshot where these things are actually in different tarballs.
[22:19] <bryceh_> yep
[22:20] <bryceh_> in fact that's one reason I didn't worry too much about the packaging at this point; I think it's going to need a pretty heavy revamp due to the split up of the repo
[22:21] <bryceh_> also, it seems debian is moving away from using xsfbs, so that needs to be dropped and a more pure dh approach used instead (which I think ricotz proposed before and looks suitable)
[22:21] <bryceh_> I think there's also been some changes to licensing in recent snapshots, so copyright needs to be reviewed 
[22:23] <RAOF> It was certainly moving to... MIT?  Or from MIT to LGPL?
[22:23] <RAOF> One of the two :)
[22:23] <Sarvatt> wow, that looks to be the most painless transition ever - https://launchpad.net/~xorg-edgers/+archive/ppa/+builds?build_text=&build_state=all
[22:23] <bryceh_> the latter
[22:24] <RAOF> Sarvatt: Yeah, the API change from 1.10RC2 to 1.10 isn't big :)
[22:25] <Sarvatt> the packaging changes were though, I figured something would break at least
[22:26] <Sarvatt> I didn't change where I was syncing drivers from expecting things to break and fix it after, guess unstable worked fine
[22:26] <Sarvatt> KiBi rocks :)
[22:31] <jcastro> Hi! I am pretty sure I found an upstream bug related to this bug report: https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/715330
[22:31] <ubot4`> Launchpad bug 715330 in xserver-xorg-video-ati (Ubuntu) (and 2 other projects) "Freeze after login with KMS enabled on Radeon HD6310 (affects: 2) (heat: 14)" [High,Confirmed]
[22:31] <jcastro> however in the upstream bug report it mentions putting an option in xorg.conf
[22:31] <jcastro> do I need to just have a blank file with the Option line or do I need some sort of skeleton for the file?
[22:32] <bryceh_> you'll need a skeleton
[22:32] <RAOF> You can get a skeleton by running “X -configure”; I think you'll need at least a Device section to hang that Option line on.
[22:32] <jcastro> ah awesome
[22:33] <Sarvatt> jcastro: http://paste.ubuntu.com/577213/
[22:33] <RAOF> I take it that the fusion netbook isn't a bundle of Just Works™ then?
[22:33] <jcastro> RAOF: I am close! 
[22:33] <jcastro> I think it's just an option that's hosing it
[22:36] <jcastro> Sarvatt: that totally works!
[22:36] <Sarvatt> need to disable pageflip on fusion then?
[22:37] <jcastro> yeah, let me update the bug
[22:37] <jcastro> and confirm with the OP
[22:37] <jcastro> there are only 2 fusions shipping right now, I have one and he has the other
[22:37] <Sarvatt> its a kernel bug but we could flip it over as the default option in the X driver easily until its fixed
[22:45] <Sarvatt> I think i915g wants to be in dri-alternates now with 7.11 :P
[22:45] <RAOF> Yeah, I think so too.
[22:46] <brobostigon> !bug 730099
[22:46] <ubot4`> Launchpad bug 730099 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup 0c40b170 (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/730099
[22:47] <brobostigon> isuffer from that, it not nice, that bug sucks. :(
[22:49] <RAOF> Hm.  That's not going to be the gen2 relaxed alignment stuff.
[22:49]  * RAOF has a browse.
[22:50] <brobostigon> i need a clever man or women to explain to me, whay a gpu lockup is to start, so i know what it is.
[22:51] <bryceh_> RAOF, yeah it's that i915/i945 freeze bug that ickle thought the relaxed fence patch would fix
[22:51] <bryceh_> brobostigon, it's when the display stops updating, but usually you can still move the mouse and ssh in
[22:51] <RAOF> 915 isn't gen2, is it?
[22:51] <bryceh_> dunno
[22:51] <RAOF> Oh, bah.  Yes it is :)
[22:52] <Sarvatt> nope first of the gen3
[22:52] <brobostigon> bryceh_: ah, i see. yes, i canstill move the mouse and ssh in, yes.
[22:52] <bryceh_> brobostigon, if you want a lot more technical details, see https://wiki.ubuntu.com/X/InterpretingIntelGpuDump
[22:53] <bryceh_> or for just troubleshooting directions (mostly out of date and not relevant for your case) there is https://wiki.ubuntu.com/X/Troubleshooting/Freeze
[22:53] <brobostigon> bryceh_: thank you, how would this be fixed, what can i add onto the bug, to help it get fixed?
[22:54] <bryceh_> I think we have a large surplus of debug info at this point ; the next action for this particular bug is blocked waiting on upstream to provide a patch
[22:55] <RAOF> If it were gen2 I'd be tempted to try libdrm 2.4.24, but I don't think that codepath will apply here.
[22:55] <bryceh_> RAOF, do you have ideas on other next actions for this?
[22:55] <brobostigon> bryceh_: would it be possible to talk to them, to get it moving alittle,?
[22:55] <bryceh_> brobostigon, I've already been poking at them, but no response (I think ickle might have been on vacation last week)
[22:56] <brobostigon> bryceh_: ok, that is something atleast isnt it, thank you. :)
[22:56] <bryceh_> also, since this is like 99% likely to be a bug in kernel drm code rather than X itself, it might be appropriate to try to get kernel team attention onto it
[22:57] <bryceh_> brobostigon, one thing to test that might turn up some useful info would be to try reproducing the bug on a non-Ubuntu distro (debian, redhat, etc.)
[22:57] <bryceh_> one that also has the 2.6.38 kernel ideally
[22:57] <brobostigon> should i try a new kernel, for example  from http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
[22:57] <bryceh_> that would demonstrate the bug is or is not due to something particular to the Ubuntu kernel or plumbing layer
[22:57] <RAOF> It might be worth trying the new libdrm anyway.
[22:57] <RAOF> I'll throw it up in aubergine.
[22:58] <bryceh_> brobostigon, yes, although others have already tested the latest kernel and found it didn't change anything
[22:58] <bryceh_> brobostigon, there is also the drm-next builds that the kernel team provides, which may be a better thing to test
[22:58] <bryceh_> "I'll throw it up in aubergine."  If I had a sig I'd put that in it.
[22:58] <brobostigon> bryceh_: i could try a debian sid, from sd, on this machine. it will take ait of work, but it could be done.
[22:59] <brobostigon> installing from live usb, too sdhc.
[22:59] <brobostigon> anf then booting of sdhc.
[22:59] <bryceh_> brobostigon, it could help in case the kernel team isn't looking at it on the assumption that it's an upstream bug, and upstream isn't looking at it on assumption it's a ubuntu-specific issue ;-)
[23:00] <bryceh_> fwiw, I have a 945 and have not seen this freeze myself
[23:00] <bryceh_> however this i945 seems to be magical and is immune to half the bugs that *should* be affecting it
[23:00] <brobostigon> bryceh_: would debiantesting be new enough, and then pulling the kernel from experimental?
[23:01] <bryceh_> brobostigon, that seems a reasonable base for testing
[23:01] <bryceh_> I don't know what kernel is in experimental, but anything 2.6.38-ish should do the trick
[23:01] <brobostigon> bryceh_: ok, i will try that tommrow, and report back, 
[23:01] <bryceh_> brobostigon, great, thank you
[23:02] <brobostigon> its definatly, the newest stablekernel release.
[23:02] <Sarvatt> its a dupe of  bug #715096
[23:02] <ubot4`> Launchpad bug 715096 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i945gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 10) (dups: 8) (heat: 185)" [High,Incomplete] https://launchpad.net/bugs/715096
[23:02] <brobostigon> different ESR and IPEHR.
[23:02] <Sarvatt> kees: didn't you have that bug too? I thought I remembered you and ickle talking about it
[23:03] <Sarvatt> 730099 is a dupe of 715096, 730099 isn't your bug?
[23:03] <brobostigon> i filed 730099 myself.
[23:04] <kees> Sarvatt: yeah, I just hit it once ever though
[23:04] <bryceh_> fwiw, I suspect ALL of the i915 and i945 lockups are the same bug, even though they differ in ESRs and IPEHRs
[23:04] <kees> Sarvatt: my really annoying bug is the i915 corruption
[23:04] <bryceh_> I think it is a bit hw-specific and maybe conditional-specific as to what error code actually pops up, but my gut says they probably have the same underlying root cause
[23:05] <brobostigon> what are ESR's and IPEHR's ?
[23:05] <bryceh_> brobostigon, see https://wiki.ubuntu.com/X/InterpretingIntelGpuDump
[23:05] <brobostigon> bryceh_: is that the same page you pointed me at earlier? i havent managed torread it yet,
[23:06] <bryceh_> brobostigon, it is
[23:06] <brobostigon> bryceh_: ok, i will read it, for bed time reading. :)
[23:06] <Sarvatt> kees: ahh ok, wasn't sure if he tossed a magic patch at you that got lost or something maybe, sorry to bug ya :P
[23:11] <brobostigon> thank you for you help and explanation everyone, really appreciated.
[23:11] <brobostigon> good night everyone.
[23:11] <bryceh_> night
[23:12] <brobostigon> night bryceh_ 
[23:38] <kees> Sarvatt: I just wish the corruption bug would get attention :(
[23:38] <Sarvatt> kees: which?
[23:38] <kees> bug 717114
[23:38] <ubot4`> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 14) (dups: 2) (heat: 70)" [Medium,Triaged] https://launchpad.net/bugs/717114
[23:50] <Sarvatt> time to force myself to use the netbook for a day to reproduce these gen3 problems