[00:04] <Sarvatt> bryceh: where is the codename attachment to the bug title done in your scripts? it would be a lot more useful to have chipset codenames like RV515 instead of say M64P
[00:07] <Sarvatt> ah fix-titles.py found it
[00:15] <Sarvatt> bryceh: extending fix-titles to have all ati pci ids and use the chipset codename if you dont mind
[00:16] <Sarvatt> helps a lot more tracking down bugs if i know the codename like RV515 and there are a *ton* missing in here
[00:20] <bryceh> Sarvatt, great thanks
[00:20] <bryceh> yeah the nvidia chipsets are missing there too if you feel ambitious
[00:21] <bryceh> I run fix-titles.py on -intel manually from time to time, and run it less frequently on -ati
[00:21] <bryceh> once you've got your changes in I can re-run it on both (unless you'd rather do it)
[00:21] <bryceh> I figure eventually we'll want it for nouveau too
[00:22] <RAOF> Yeah, that'd be useful.
[00:23] <RAOF> (Although it's not always obvious which set of codenames to use; many nvidia chips have at least 2 :/)
[00:23] <Sarvatt> yup will do, 1/4 the way through ati and will do nvidia after
[00:23] <Sarvatt> nvidia is easy, theres a nice wiki document having them all
[00:24] <Sarvatt> http://nouveau.freedesktop.org/wiki/CodeNames
[00:24] <Sarvatt> i've got a list of all pci ids somewhere around here to map that to
[00:44] <Sarvatt> phew, gonna take a break at R500 generation :D
[00:54] <libv> Sarvatt: check radeonhd code, i spent several days in july 2007 doing the same thing
[01:30] <Sarvatt> ok got everything except cypress hemlock juniper cedar and redwood, not sure on those codenames
[01:32] <Sarvatt> bryceh: anything special I should do running this? already changed it to dryrun
[01:35] <Sarvatt> hmm   ---------> Renamed to [RV530] [X1600] jaunty: X session (radeon) slows down, crashes
[01:48] <hyperair> Sarvatt: i still get my artifacts =\
[02:37] <Sarvatt> there we go, all ati bug titles with proper logs tagged with the gpu chipset name, kind of throws off incomplete bugs running this though since it resets expiration time
[02:39] <Sarvatt> ahh darn, things originally filed against xorg dont have PciDisplay: in the description
[02:56] <Sarvatt> pushed it here but it needs handling for already tagged bugs like cleanup_intel has http://bazaar.launchpad.net/~sarvatt/arsenal/working/revision/491
[04:08] <vish> hi.. i'm noticing my screen being badly corrupted with artifacts > and the xorg log is showing :
[04:08] <vish> (II) RADEON(0): Printing DDC gathered Modelines:
[04:08] <vish> (II) RADEON(0): Modeline "1280x800"x0.0   68.90  1280 1301 1333 1408  800 804 808 816 -hsync -vsync (48.9 kHz)
[04:08] <vish> (II) RADEON(0): EDID vendor "QDS", prod id 65
[04:08] <vish> but i'v selected 60kHz in the display settings [which is the default]
[04:08] <vish> this is in Lucid^
[04:10] <vish> 60*Hz
[04:10] <vish> brb , the screen looks horribly disfigured :(
[04:14] <vish> if i take a screenshot , its doesnt show these problems..
[04:15] <RAOF> Which suggests that the problem is in how radeon is driving your screen, as you suspected.
[04:17] <RAOF> Has this issue arisen recently?
[04:20] <vish> RAOF: hmm , that Xorg log entry might not be the error , but there is no error/message recorded other than those lines..  but yes , this has started recently , i notice the screen corrupted and a restart is the only thing that fixes it and screenshots dont catch the problem :(
[04:21] <RAOF> But a restart fixes it?  It wouldn't seem to be mode-related then.
[04:21] <vish> yeah , the restart restores the screen to normal ,  i have never had such bad display , I'v been using Ubuntu for on this system for nearly 2.5yrs
[04:22] <vish> laptop*
[04:22] <RAOF> Is there a particular action that you've discovered which triggers the corruption?  Is it only after leaving the computer for a while?  Is it while doing a lot of 3D stuff?  Is it just anytime?
[04:23] <vish> i have notice the problems when i return from screensaver[rather after the screen has been switched off during idle].. not while any other usage/3D
[04:24] <RAOF> Always after the return from screensaver?
[04:24] <vish> it has been random .. i'm not sure what triggers it.. but i have noticed the problem only after i return from screensaver
[04:26] <vish> no errors in the Xorg/sys logs . no messages , nothing is recorded :s
[04:28] <vish> i could take foto of the error , but i dont think it would be helpful , not sure where/how i can debug this :(
[04:28] <RAOF> A photograph of the problem can be surprisingly useful.
[04:29] <vish> ok , i'll take one the next time it happens
[04:29] <RAOF> This only happens after a return from screensaver, though?  Is it a particular screensaver?
[04:30] <vish> i use the GLXMatrix.. i could try switching to a different screensaver
[04:30] <RAOF> Might be worth checking, yeah.
[04:32]  * vish switches screensaver
[04:35] <vish> there has also been another similar error , but it is "fine black noise"[1px black horizontal lines] which also doesnt get caught when using a screenshot as well.. but this started happening several times *while* i was using the system , no fancy 3D stuff , or anything.. this too is solved only by a restart
[04:36] <vish> same no errors/messages :(  
[04:36]  * vish thinks the new drm from .33 kernel might be the cause of these problems 
[04:37] <RAOF> If you think that's the case then you could try booting into the old -15 kernel
[04:39] <vish> yeah i should, i didnt notice them earlier , its been happening only for the last couple of weeks.  These random errors are quite bugging :s  if it is something i can reproduce it can be pinned down
[04:44] <vish> RAOF: if the bug happens again , anything else i need to log? to narrow down the bug? [other than a foto , which might help the first bug,  but i'm not sure it would help the black noise]
[04:45] <RAOF> dmesg & xorg.0.log are the obvious candidates; I'm not aware of anything else for radeon.
[04:47] <vish> neat.. thanks [but hope they log errors the next time ;-)]
[04:48] <RAOF> It's quite possible that you can pass some debug parameters to the kernel module, but I'm unfamiliar with them.
[04:49] <RAOF> And they're likely to be *hugely* verbose.
[04:53] <vish> whom/where can i ask about those debug parameters? [#u-kernel?]
[04:57] <RAOF> I'd just wait for the moment.
[04:57] <vish> k.. thanks :)
[04:59] <Sarvatt> vish: in /sys/module/radeon/parameters/ can you tell me what the values for dynclks and new_pll are?
[05:01] <vish> Sarvatt:  dynclks is -1   and new_pll   is 1
[05:01] <Sarvatt> try booting with radeon.new_pll=0
[05:02]  * Sarvatt thought that was the default...
[05:03] <vish> Sarvatt: so the  new_pll one i just change to 0   right?
[05:03] <vish> or   > radeon.new_pll=0
[05:03] <vish> ah , got it.. you want me to edit the kernel line :)
[05:05] <Sarvatt> yeah, sorry
[05:05] <Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=26358
[05:06] <Sarvatt> weird refresh bugs and quirks abound because of new_pll=1..
[05:07] <Sarvatt> you're like the third person in here today to say they have a weird undescribable corruption they cant screenshot on radeon, sheesh
[05:08] <vish> \o/ i'm not alone ;p  
[05:09] <vish> btw , this is the Xorg.0.log > http://paste.ubuntu.com/399115/
[05:09] <vish> Xorg.1.log > http://paste.ubuntu.com/399114/
[05:12] <Sarvatt> you're the second with an RV515 today too
[05:12] <Sarvatt> other guy couldn't file a bug because of some KDE problem :(
 [18:03:35] +Sarvatt: flickery, snowy or like that ...
[05:14] <Sarvatt> whatever that meant :)
[05:16] <vish> Sarvatt: you want a bug logged for this? 
[05:17] <vish> [to switch the default new_pll=0]
[05:18] <Sarvatt> doubt thats a good idea globally, probably need to make a quirk for your machine and the hundreds of others that need them too
[05:18] <libv> heh, i cannot believe deucher is still struggling with that, i had that fixed before he even started writing his driver.
[05:42] <Sarvatt> yuck, all the odd flickering bugs the past few days in -ati are all rv515 and rv530 :D
[05:43] <libv> m52 or rv515/530?
[05:46] <Sarvatt> 2xM56P and a x1300 RV515 on this page
[05:46] <Sarvatt> at least yours doesnt look like this vish - http://launchpadlibrarian.net/41493534/543265_bug_P04.jpg 
[05:47] <libv> that's not a pll issue
[05:47] <libv> or...
[05:47] <vish> ;p 
[05:48] <libv> hrm...
[05:48] <RAOF> Whee!  I like my framebuffer well sliced!
[05:48] <Sarvatt> Everytime I start Ubuntu 10.04 from Live CD, after few minutes screen start to shaking and i cant do anything (Ctrl+Fn is working, but screen is shaking too).
[05:48] <Sarvatt> (description for that last one)
[05:49] <Sarvatt> with the screenshot
[05:49] <libv> ctrl-fn on kms no doubt
[05:49] <superm1> Sarvatt, i've seen something similar to that on my netbook too
[05:50] <superm1> but i can't come up with a reproducible scenario for it, it's quite random
[05:52] <libv> i fear that this photo is that messed up because of the camera
[05:53] <RAOF> And that the true state of affairs would not include duplicate pieces of screen?
[05:54] <libv> not for a modesetting issues indeed.
[09:14] <Ng> interestingly enough, I think I've found a couple of other people seeing similar weird random flickery events on G45s in Lucid
[09:18] <Sarvatt> tell them to boot with i915.powersave=0 and mention in the bug if that fixes it :)
[09:18] <Sarvatt> that was default in -15 but not anymore in -16
[09:20] <tseliot> Sarvatt: unfortunately I experienced some weird corruptions with nouveau (and I had to update libdrm too)
[09:20] <Sarvatt> tseliot: i told ya in the email you have to update *everything* in the ppa, not just xserver-xorg-video-nouveau too :D
[09:20]  * tseliot nods
[09:21] <Sarvatt> got it running though? didn't work? :(
[09:22] <tseliot> well, it depends on what you mean by "work" ;)
[09:23] <Sarvatt> what kinds of corruptions?
[09:25] <tseliot> first of all plymouth didn't work (and it used to work) but I got mode setting. Then I could enter the desktop but the menus and the indicator were blank
[09:26] <Ng> Sarvatt: interesting. the problem is that it's *really* intermittent, so all I'd be able to say is that it's not happened for a few days ;)
[09:27] <freeflying> hi all, does xserver-xorg-video-ati works well with xrandr in karmic
[09:28] <tseliot> Sarvatt: http://albertomilone.com/2010-03-21 19.08.04.jpg
[09:28] <tseliot> :-/
[09:28] <tseliot> err... http://albertomilone.com/2010-03-21%2019.08.04.jpg
[09:28] <freeflying> a 17" crt monitor has been recoganized as 16" 
[09:28] <Sarvatt> i haven't seen any flickering bugs on 965+ recently, looked like they ironed them all out but powersave=0 for sure should get rid of them Ng
[09:28] <freeflying> using xserver-xorg-video-ati in karmic
[09:29] <Ng> Sarvatt: ok, I've passed it on to the other folks and we'll try to start keeping track. Would anything else have changed between -15 and -16 wrt intel? I probably only rebooted into -16 fairly recently
[09:29] <Sarvatt> yeah *tons*, the entire 2.6.32-2.6.33 drm backport
[09:30] <Ng> oh hrm, I rebooted longer ago than I thought
[09:30] <Ng> 17th I think
[09:30] <Ng> ok well we'll keep an eye on it and see how it goes :)
[10:17] <tseliot> Sarvatt: can you add this, please? http://0x04.net/~mwk/0001-drm-nv50-Add-NVA3-support-in-ctxprog-ctxvals-generat.patch
[10:50] <Ng> ok, I was just using another intel laptop in the office that just had a fresh install of beta1 and it was doing the screen flickering thing just like mind, so I'll reboot wit powersave=0 and see if it goes away
[12:31] <bjsnider> tseliot, i noticed last night that nvidia-settings control file still says build on lpia in lucid
[12:32] <tseliot> bjsnider: as the rest of the nvidia packages
[12:32] <bjsnider> why doesn't the build system complain about it?
[12:34] <tseliot> I don't know
[12:34] <bjsnider> i find it easier and safer to just put "any" int he architecture
[12:38] <tseliot> no, why should we?
[12:39] <tjaalton> just drop lpia
[12:39] <tjaalton> "any" doesn't work
[12:39] <tjaalton> no reason to build it on ia64 or sparc
[12:40] <bjsnider> well, when you use the ppa build system, and tell it to build on lpia/lucid, it errors out. the ppa system doesn't build on ia64 or sparc
[12:41] <tjaalton> but the main buildd's do
[12:41] <bjsnider> ia64 is the intel itanium?
[12:41] <tjaalton> yep
[12:41] <bjsnider> i thoughtt hat was an experiment?
[12:42] <bjsnider> are there ia64 production systems out there?
[12:42] <tjaalton> "amd64 armel i386 ia64 powerpc sparc", those are the archs that "any" would make it build on
[12:42] <tjaalton> ask HP
[12:43] <tjaalton> i guess there are, don't know about ubuntu on them
[12:43] <tjaalton> but that's besides the point
[12:43] <tjaalton> even though _your_ ppa packages build fine with "any", there's no need to change the main package to do the same
[14:21] <marcus___> hello
[14:21] <marcus___> i was curious if it is possible to have the gallium3d nouveau drivers in lucid via the xorg swat/edgers ppa
[14:22] <marcus___> can someone offer some insight into this? :)
[15:46] <ara> bryceh, ping
[15:53] <superm1> tseliot, re https://edge.launchpad.net/ubuntu/+source/fglrx-installer/2:8.721-0ubuntu5 , that shouldn't have been necessary once the binaries were deleted from the archive should it?
[15:55] <Sarvatt> tseliot: uploaded now, sorry had to sleep a bit there :)
[15:55] <tseliot> superm1: you might want to discuss this with pitti (who requested transitional packages)
[15:55] <Sarvatt> it's linux-backports-modules-2.6.32_2.6.32-16.999~git20100321.4d950853~xorgedgers
[15:55] <superm1> tseliot, ah i'll take a look at bt 
[15:55] <tseliot> Sarvatt: thanks a lot. Getting some sleep can help from time to time ;)
[15:55] <superm1> tseliot, but then those changes just need to be local, and not in the amd phorogit stuff, right?
[15:56] <superm1> i'm guessing they help dist-upgrader's is the particular reason
[15:56] <tseliot> superm1: right
[15:57] <superm1> ara, with your proprietary driver testing, is one of your test cases hardy fglrx->lucid fglrx now too?  hardy still had LRM if i'm remembering correctly, i'm wondering how well that would go over
[15:59] <tseliot> oh, and BTW suspend/resume works with nvidia now (even here!)
[16:00] <ara> tseliot, \o/
[16:01] <tseliot> :-)
[16:27] <ricotz> Sarvatt, hello could you please upload a lbm package for 2.6.32-17 as well?
[16:28] <Sarvatt> is it the default already?
[16:28] <ricotz> not yet
[16:29] <Sarvatt> i dont see a -17 linux-meta
[16:29] <Sarvatt> yeah not yet sorry, can only have one in there at a time
[16:29] <ricotz> Sarvatt, ok
[16:29] <Sarvatt> might need to update 16 again for tseliot here
[16:30] <ricotz> Sarvatt, perhaps you can look at this patch http://repo.or.cz/w/mesa/mesa-lb.git/commit/432b8cc477344fc7fcbb24b747d56ab087403d09
[16:30] <ricotz> which might solves the crash on my nv49
[16:31] <tjaalton> lbm doesn't have nouveau anymore aiui
[16:51] <Sarvatt> i'm added it back to lbm on edgers since its alot easier to update that
[16:53] <tjaalton> ah, k
[17:00] <Sarvatt> one day i'll work out how to properly create a PPA kernel :D
[17:27] <technoviking> My nvidia driver goes into safe mode when I boot into Lucid. restarting gdm will make the nvidia and X load properly. Anyideas what is causing the problem. https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/532436
[17:38] <tseliot> technoviking: can you reproduce the problem if you uninstall (with --purge) plymouth?
[19:20] <Sarvatt> looks like a regression with ati 6.12.192 https://bugs.freedesktop.org/show_bug.cgi?id=27186
[19:22] <Consul_Falx> hello folks
[19:45] <Sarvatt> radeon.new_pll=0 quirk needed here https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/543045
[19:46] <Sarvatt> i'm thinking it should be the default for all RV515 and RV530 mobiles
[19:59] <Sarvatt> i'm just going to tag them needs-pll-quirk to start making a list to give to the kernel guys to selectively use that option. having the generation in the title sure does help spot these
[20:26] <Consul_Falx> ey folks
[20:27] <Consul_Falx> any progress in ati radeon open driver support in lucid?
[20:29] <bryceh> Sarvatt, sounds good
[20:58] <tormod> anyone who can sponsor bug #287475 please?
[21:00] <jcristau> i can sponsor it to sid :)
[21:10] <tormod> jcristau, very well, would you like a debdiff or would you just copy in that patch yourself?
[21:11] <tormod> or let me commit it to git :)
[21:19] <vish> i'm having a weird problem , the system slows down and everything is slow to react[random]. the mouse pointer has no lag though... earlier i used to SAK and return to session and everything would be fine.. ..  now , i seem to have a workaround of sorts.. when i switch to a guest session and return , everything is normal and works fine... nothing in the logs or .xsession-errors .. where do i need to look to file a bug?
[21:21] <jcristau> tormod: i'd say just push it to git.d.o.  you have commit access, right?
[21:21] <tormod> jcristau, no not to the x packages
[21:22] <vish> not sure if this means anything > [ 5291.324934] __ratelimit: 3 callbacks suppressed  kern.log > http://paste.ubuntu.com/399544/
[21:23] <jcristau> tormod: should we fix that? :)
[21:23] <tormod> jcristau, thanks could be handy :)
[21:29] <jcristau> tormod: should be done now.  or whenever that thing gets updated.
[21:31] <tormod> jcristau, should I keep it "unreleased" or "unstable" ?
[21:33] <jcristau> i don't think there'll be any more changes so unstable should be fine.  iirc there's a debian bug that this could fix, too.
[21:33] <tormod> thanks, I'll look for it
[21:34] <tjaalton> just got seven packages synced from unstable
[21:41] <tormod> jcristau, actually do you usually add a debian/patches/foo or use git cherrypick there?
[21:42] <jcristau> tormod: usually cherry-pick -x.  and keep debian/patches/ for not-yet-upstream stuff.  but i don't really mind, debian/patches/ works for this too if you prefer.
[21:42] <bryceh> hi tormod, do you still plan to update debian's intel-gpu-tools package to latest?
[21:44] <tormod> hi bryce, I was thinking to wait for a release.
[21:52] <RAOF> Man.  You watch the nouveau bug lists, and note that people hardly ever ask for mmiotraces.  Then we turn nouveau on by default, and all the bugs we send up are “oh, yeah, could you get an mmiotrace of that?  We've never had one for that card before” :X
[21:53] <bryceh> hehe
[21:53] <alkisg> Is Intel 82852/855GM ok with xorg in Lucid? Or I'd better keep running Karmic?
[22:16] <bryceh> Sarvatt, yeah with that pll quirk, as you verify bugs are resolved with that, repoint those bugs to linux for the kernel team.
[22:17] <bryceh> Sarvatt, might be good to also set a milestone and target them to lucid
[22:19] <alkisg> Ah ok, I was lacking xv and I was afraid that 855GM wasn't working at all in Lucid, but it's just a kms combination problem: https://wiki.edubuntu.org/LucidLynx/ReleaseNotes#No%20Xv%20support%20for%20Intel%2082852/855GM%20video%20chips%20with%20KMS
[22:21] <tormod> jcristau, I pushed the cherry-pick. I hope I got that right.
[22:23] <tormod> hmm maybe I got the version wrong :(
[22:23] <jcristau> ah yeah the changelog entry should be merged with the previous one
[22:23] <jcristau> DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts helps with that
[22:23] <jcristau> (if you're using dch)
[22:25] <jcristau> tormod: didn't you want to close the lp bug in the changelog too?
[22:25] <tormod> I thought at the time that 1:0.10.2-2 was already released...
[22:25] <jcristau> it says UNRELEASED ;)
[22:25] <tormod> jcristau, oh yes, I will add it
[22:26] <tormod> jcristau, I was not sure if it was so consistent :) but of course it was
[22:27] <tormod> un-goofing it now
[22:32] <tormod> jcristau, getting there :) pushed
[22:35] <jcristau> looks good
[22:36] <tormod> jcristau, not sure how I update upstream-unstable The Right Way
[22:36] <tormod> git push origin upstream-unstable tells me Everything up-to-date
[22:36] <jcristau> yeah upstream-unstable stays on the 0.10.2 tag
[22:37] <tormod> yes, it was upstream-experimental I had updated ! time for sleep maybe
[22:38] <jcristau> thanks, and good night!
[22:39] <tormod> good night! btw, will you release soon so we can sync in ubuntu instead of patching?
[22:39] <jcristau> yes
[22:40] <jcristau> either now, or tomorrow morning when i get to the office.
[22:56] <Sarvatt> http://lists.x.org/archives/xorg-devel/2010-March/006436.html \o/ we have so many bugs about that
[23:04] <jcristau> ok, tormod's sis fix is in incoming now.
[23:11] <stgraber> hey there !
[23:12] <stgraber> I have a few thin clients (Netbook like hardware) with Intel 945GM (8086:27a6) showing a LVDS1 output since a few days on Lucid. It used to be a problem back in Jaunty if I remember well where I had to make a few scripts to automatically blacklist that output on non-netbook but it was fixed in karmic/early-lucid.
[23:12] <stgraber> I quickly went through a few bugs on LP and it's not very clear if it's a known issue or not and if it's something that we plan on fixing for lucid or not (if we don't, I'll restore the old hack in the ltsp package and upload it to Lucid to fix the issue immediately)
[23:15] <jcristau> so the bios pretends there's an lvds?
[23:15] <stgraber> might be, yep. A few thin clients seem to have BIOS reporting LVDS output
[23:16] <stgraber> though usually they are blacklist (in the driver IIRC) because the Chassis type and some other info report that it's desktop hardware and not laptop
[23:17] <RAOF> Do they have ACPI lid switches?  i915.ko shouldn't attempt to bring up LVDS screens without a lid-switch, I think.
[23:18] <stgraber> RAOF: no /proc/acpi/button/lid (only button/power is there)
[23:19] <RAOF> Hm.  Maybe that commit isn't in our kernel?
[23:20] <stgraber> I'd certainly love to see that check in as it'll solve a lot of issues I have with Atom-based thin clients (exact same hardware as netbooks but used as desktop with a single DVI-I output usually)
[23:23] <jcristau> RAOF: 11ba159288f1bfc1a475c994e598f5fe423fde9d reverted that
[23:24] <RAOF> jcristau: Ah, ok.
[23:24] <jcristau> apparently there's stuff with a lid switch but no lvds
[23:24] <jcristau> so the driver trusts the bios.
[23:25] <stgraber> hmm, if the issue is stuff with a lid switch and no lvds, how can it hurt to disable LVDS if it's reported by the BIOS and no lid switch is found ?
[23:25] <stgraber> I'd guess the issue is for stuff with LVDS but no lid switch
[23:25] <RAOF> Right.
[23:26] <jcristau> stgraber: there's a quirk list in drivers/gpu/drm/i915/intel_lvds.c where your stuff could be added
[23:26] <jcristau> static const struct dmi_system_id intel_no_lvds[] = {
[23:26] <jcristau> "These systems claim to have LVDS, but really don't"
[23:26] <stgraber> good, only issue is to make a rule that matches my hardware but not a generic netbook then
[23:27] <jcristau> with mac minis, aopen something, and dell studio hybrid in there already.
[23:30]  * stgraber updates his copy of ubuntu-lucid.git
[23:36] <stgraber> jcristau: http://paste.ubuntu.com/399595/
[23:37] <stgraber> Is that something you can commit yourself or should I open a bug on LP + poke the kernel team about it ?
[23:38] <jcristau> should probably poke your kernel team, or send it upstream to eric@anholt.net, dri-devel@lists.sf.net
[23:40] <stgraber> jcristau: ok, I'll open a bug on LP and e-mail the patch to these two e-mails as well