[00:19] <bryce> jbarnes: "current sequence" does not seem to be incrementnig
[00:19] <jbarnes> bryce: ok just wanted to make extra sure the gpu was hung
[00:19] <jbarnes> albert23's last dump shows that we started executing junk
[00:21] <bryce> I've waited a couple hours since the freeze, and no files in /sys/kernel/debug/dri/0 have changed
[04:12] <pwnguin> bryce_: what's the purpose exactly, of adding lspci entries to the bug descrption?
[04:34] <bryce_> pwnguin: needed for upstreaming the bug
[05:53] <tjaalton> Caesar: yes?
[06:42] <Caesar> tjaalton: libxcb
[06:42] <Caesar> We're seeing problems with it in Hardy
[06:43] <Caesar> On amd64
[06:43] <Caesar> Both the 64-bit version and what's in ia32-libs
[06:44] <Caesar> Apparently the problems went away when I rebuilt the ia32-libs version without optimisation
[06:44] <Caesar> Make of that what you will
[06:44] <Caesar> I haven't tried making a non-optimised 64-bit version yet to see if that solves the other problems
[06:44] <Caesar> I was wondering if you had any thoughts on the whole situation? There's been one or two libxcb-related bugs bouncing around I think
[06:49] <tjaalton> Caesar: which ones?
[06:49] <tjaalton> and what problems?
[06:51] <Caesar> tjaalton: various crashes
[06:51] <Caesar> I'm not VPNed into work at the moment, so I can't check our bug tracking system
[06:52] <tjaalton> ok, are they on lp too?
[06:53] <tjaalton> I'd be interested to know if they happen on jaunty too
[06:53] <tjaalton> since we're going to be fully 64bit in a few months ;)
[06:53] <tjaalton> I know that there used to be some java issues
[06:53] <tjaalton> but java was fixed since
[06:54] <tjaalton> and so was libxcb, so that it can't fail the same way anymore
[06:54] <Caesar> java was one of the problematic things
[06:55] <Caesar> Let me see which lp bugs we're subscribed to
[06:58] <Caesar> So there's #220628
[06:58] <Caesar> and #232364 is less pressing
[06:59] <Caesar> I'd have to doublecheck what we've got internally tomorrow
[06:59] <tjaalton> sure
[07:00] <tjaalton> so there's a patch for the former.. have you tried backporting it?
[07:01] <Caesar> Not yet
[07:01] <Caesar> I've still been trying to wrap my head around all of the issues
[07:01] <tjaalton> think I've seen this bug myself, good to know there's a fix :)
[07:01] <Caesar> Actually, let me search my email, that should turn up something useful
[07:03] <tjaalton> I'll be moving the next week or so, which means I'm unable to work on it before early May perhaps, but I'll keep an eye on it because it seems important
[07:04] <Caesar> Yeah, it seems to be fairly important
[07:05] <Caesar> I think we did a backport of that patch for a single user to see how it worked out for them
[07:05] <Caesar> Firefox still seemed to crash, just less
[07:05] <tjaalton> I'll assign myself to the bug
[07:06] <Caesar> I had someone look at some other crashes, and he said:
[07:06] <Caesar> I can't see how $EBX is meant to be maintained.  The generated code looks optimised (non static functions have been inlined).  This feels like an optimization bug.
[07:06] <Caesar> (that was for the ia32-libs version)
[07:06] <Caesar> So I went and rebuilt it without optimisation
[07:06] <Caesar> and that seemed to fix the problem
[07:07] <Caesar> So something's very wrong if just changing the optimisation level fixes the problem
[07:07] <tjaalton> that was some other bug?
[07:12] <Caesar> Yeah
[07:12] <Caesar> It's very internal, so it's hard to file a meaningful lp bug
[07:13] <tjaalton> heh, ok
[07:14] <tjaalton> could that be a compiler bug?
[07:14] <Caesar> I guess it could be
[07:14] <tjaalton> talk to doko about it
[07:14] <tjaalton> he might have ideas
[07:14] <Caesar> ok
[10:03] <Le-Chuck_ITA> Hi there, I have Xorg crashing on "first reboot" after installing jaunty. It worked for months, but the latest version of X works only on first boot, that's very strange. Perhaps related to kernel. It's bug #364488
[10:23] <mnemo> tjaalton: i switched the package to xorg on this bug (not wacom) --> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/364488
[10:23] <mnemo> tjaalton: or why did you set wacom-tools on it?
[10:24] <tjaalton> mnemo: because it's likely a dupe of another bug (can't find it now)
[10:25] <mnemo> aaah ok
[10:26] <mnemo> does wacom-tools request xorg.log etc just like xorg does when you run the apport-collect thing?
[10:26] <tjaalton> not necessarily a wacom bug, could be in the xserver
[10:26] <tjaalton> yes
[10:26] <mnemo> ok would you like me to change it back to wacom-tools then?
[10:26] <tjaalton> yes
[10:26] <mnemo> will do
[10:26] <tjaalton> thanks
[10:27] <mnemo> tjaalton: btw, I have wacom HW
[10:30] <tjaalton> mnemo: ok, you could check bug 358643 and see if you can reproduce the issues
[10:30] <mnemo> sure
[10:31] <tjaalton> there are also proposed fixes, and I've yet to grok the reply from gomyhr
[10:34] <mnemo> its my gf's wacom actually so I never tried it in ubuntu before.... anyway now when I connected it, things just worked out of the box...
[10:34] <mnemo> like I got this in dmesg --> http://pastebin.com/m1124224
[10:34] <mnemo> and I can move around the mouse cursor at least
[10:34] <mnemo> no special xorg.conf
[10:35] <tjaalton> right, it works if you _don't_ have anything in the conffile
[10:35] <tjaalton> but I'm worried about the people upgrading :)
[10:36] <tjaalton> it'll be mentioned on the release notes though
[10:36] <tjaalton> but an SRU would be nice
[10:36] <mnemo> right..
[10:36] <tjaalton> anyway, lunch ->
[10:36] <mnemo> yea
[10:36] <mnemo> cya
[11:12] <tjaalton> tseliot: have you had time to prepare the new stable nvidia for testing?
[11:12] <tseliot> tjaalton: I prepared and I'm using 180.51 but I think it's still a prerelease
[11:13] <tseliot> http://www.nvnews.net/vbulletin/showthread.php?t=122606
[11:13] <tseliot> Current official release: 180.44 (x86 / x86_64)
[11:13] <tseliot> Current prerelease: 180.51
[11:13] <tseliot> Current beta release: 185.19
[11:14] <tjaalton> ah
[11:14] <tjaalton> ok
[11:14] <tseliot> no regressions so far
[11:15] <tseliot> we might do an SRU when the stable version is released
[11:15] <tjaalton> right
[11:15] <tjaalton> I should probably test the gf9600gt's a bit more
[11:15] <tjaalton> we'll be getting a 100 of those :/
[11:16] <tseliot> unfortunately I don't own one
[11:45] <apw> jbarnes, hi ... trying to get a handle on the tiling performance issues associated with MCHBAR, and wondering what happened with the patch 'allocate MCHBAR space & enable if necessary', i think i remember there being a replacement proposed  but cannot find it
[13:18] <Ng> hmm, x hung
[13:19] <Ng> i shouldnt have hacked out the blacklist ;)
[13:19] <Ng> is there anything i can quickly do to get debugging before i have to reboot?
[13:21] <Ng> i have a quick gdb bt
[13:21] <tjaalton> Ng: do you have all the bits (2.6.30 + patched i915.ko, the reg-dumper=
[13:22] <Ng> no, stock jaunty
[13:22] <tjaalton> ok
[13:23] <Ng> gah. i have to reboot npw
[13:39] <Ng> so obviously I'm behind on all the debugging/testing things I should be doing
[14:07] <soren> An acquaintance of mine just ran update-manager to do the intrepid->jaunty upgrade and it told him that there wasn't an fglrx driver for his card. It's an x1400. Is that accurate?
[14:09] <soren> If it is, he'll be moved to the free driver, right? I'm told they don't support 3D acceleration.
[14:09] <soren> If that's indeed the case, the upgrade will mean he'll lose 3D capabilities. However, I don't see any mention of anything like this in the release notes?
[14:09] <mvo> soren: what is the pci id of this card (the x1400) ?
[14:09] <soren> mvo: I'll check.
[14:10] <mvo> soren: I doN't think he will loose 3d acceleration, but it may be less well supported, iirc the x1400 is a r500 based card and the 3d support for the free driver is pretty solid there
[14:10] <mvo> (compiz should run just fine, not sure about more advanced stuff like real games)
[14:16] <soren> mvo: 1002:7145
[14:20] <mvo> soren: from the modaliases it looks like this is indeed just r600+ support now
[14:20] <soren> fglrx, you mean?
[14:21] <soren> So he'll be automatically switched to the free driver? That's the one called "radeon", is it?
[14:21] <mvo> soren: yes - and http://www.x.org/wiki/RadeonFeature looks pretty good for the r500
[14:21] <soren> mvo: Fantastic. Thank you.
[14:21] <mvo> soren: let me know how the upgrade goes and if everything works as expected please
[14:22] <soren> mvo: Still... I understand why he was startled by that message. Losing 3D would be a showstopper for lots of people, I think.
[14:22] <soren> mvo: Will do.
[14:23] <Ng> are we could to put in such a message for i965?
[14:24] <mvo> soren: right. I understand. I'm not familiar enough with the free ati driver to judge how well the individual chips are supported, so I decided to go with the "conservative" message
[14:24] <mvo> Ng: only in a sru at this point
[14:24] <tjaalton> soren: the r5xx series has free 3D support
[14:25] <tjaalton> since intrepid
[14:25] <soren> tjaalton: Cool.
[14:26] <soren> I'm just passing the message on... He was rather concerned by the message, and the release notes don't mention anything about this.
[14:26] <Ng> mvo: fair enough
[14:26] <jcristau> and r6/7xx will probably get it for the next release
[14:27] <soren> Perhaps it's worth mentioning the transition in the release notes.
[14:27] <soren> mvo: He's doing the upgrade later today and promised he'd get back to me with the results. I'll keep you posted :)
[14:35] <mvo> jcristau, tjaalton: is it "good enough" to not show a warning at all for all r5xx chips?
[14:35] <tjaalton> mvo: where's the full text?
[14:36] <mvo> http://paste.ubuntu.com/155350/
[14:39] <tjaalton> I guess it could only worry people
[14:40] <tjaalton> although the text is technically correct :)
[14:56] <Shappie__> Hello, is there a way to disable the RandR extension of Xorg?
[14:56] <Shappie__> It conflicts with my fglrx driver from ATi (9.4)
[14:56] <Mirv> mvo: for basic desktop (3D) usage it should be enough, and largely at least there is zero reduction in desktop effects. games do suffer until radeon-rewrite comes for karmic.
[14:57] <Mirv> I've played stuff like Neverwinter Nights on my (former) Radeon X800 without problems, but things like Doom 3 do not work (yet)
[14:58] <mvo> Mirv: thanks! that is valauble information, so the warning is probably a good idea
[14:58] <Mirv> mvo: warning, or just a release note about decreased game performance on R500
[14:58] <jcristau> Shappie__: that doesn't make sense
[14:59] <Mirv> of course, there might indeed be a bunch of gamers using something like X1650-X1950, for them it's an important piece of information
[14:59] <Shappie__> jcristau: What you mean? When i type in terminal the command with sudo aticonfig to make dualscreen setup its says error due to RandR 1.2 enabled
[14:59] <Shappie__> You need the exact error? I have it somewhere...
[15:00] <Mirv> but if using the warning message, just remove the "desktop effects, and "
[15:00] <jcristau> Shappie__: shrug.  i don't know what aticonfig is, so i probably couldn't help with it anyway.
[16:19] <jbarnes> apw: it's under "pnp: add PNP resource range checking function" on intel-gfx
[16:19] <jbarnes> apw: I split it in two because the pnp part needed to be generic
[16:29] <apw> jbarnes, ahh thanks will look at it
[17:02] <apw> jbarnes, i see that bjorn came back with an alternative generic check, did that get tested yet?
[17:03] <jbarnes> apw: no, do you have a test platform you could try it with?
[17:03] <jbarnes> you'd need to add an EXPORT_SYMBOL for it and a prototype
[17:03] <apw> i have users who are upset its not working
[17:03] <jbarnes> should be easy to do though
[17:03] <apw> so i suspect they would be willing to test anything, as their performance sucks without your fix
[17:04] <jbarnes> would be great to get some test results so we could push it upstream soon
[17:11] <bryce> morning
[17:17] <jbarnes> morning
[17:31] <jbarnes> bryce: did you see my last update to imad?
[17:31] <jbarnes> my mailer is giving me trouble, just want to make sure it went out
[17:31] <jbarnes> was in reply to mdz's comment
[17:32] <bryce> jbarnes: no emails from you for today in my inbox
[17:33] <jbarnes> just sent again...
[17:45] <bryce> jbarnes: anything else I could do to help you guys?
[17:46] <jbarnes> not atm I think
[17:46] <jbarnes> looking at albert's dumps now
[20:28] <bryce> tjaalton: I've updated https://wiki.ubuntu.com/X/Drivers to indicate the latest info for our main drivers, can you please review it when you get a chance, and add any other information that's worth including?
[20:37] <tormod> bryce: ^ beta version of xserver?
[20:38] <tjaalton> bryce: the -intel entry has a wrong version
[20:38] <bryce> good catches... updated
[20:39] <tjaalton> bryce: I'm a bit lost about wacom actually, there are some bugs suggesting that xsetwacom/wacomcpl doesn't work, but actually they do if the correct device name is used
[20:39] <tjaalton> but I've yet to confirm that
[20:40] <bryce> ok
[20:40] <bryce> tjaalton: don't forget to update the release notes if this is a known issue, esp. if there's a workaround people can use
[20:41] <jbarnes> bryce: I thought the sony panel problem was fixed?
[20:42] <bryce> jbarnes: might be, this known issue list is old (2.6.1-ish)
[20:42] <jbarnes> at least the linked bug is fixed :)
[20:42]  * jbarnes checks the commit id
[20:43] <tjaalton> bryce: I will take the crappy oem tablet with me tomorrow, so I can play with the patches
[20:43] <tjaalton> and update relnotes accordingly
[20:43] <jbarnes> bryce: yeah 2.6.3 has the sony panel fix so you can remove that bit
[20:43] <bryce> okies
[20:44] <bryce> tjaalton: awesome thanks
[20:45] <jbarnes> bryce: also, tv out properties and the sdvo tv stuff should be pretty easy to backport, you could ping yingying about getting that done maybe
[20:52] <tormod> bryce: re wiki: the link to fd.o 19274 is wrong
[20:53] <bryce> jbarnes: is that strictly -intel stuff or does it require kernel changes?
[20:53] <jbarnes> for non-kms they're just 2d driver updates
[20:54] <bryce> tormod: ok thanks, what should it be linked to?
[20:54]  * bryce hmms @ sru-ability of tv stuff
[20:55] <jbarnes> don't know how much user demand you have for it
[20:55] <jbarnes> anyway just a thought since upstream has those bits
[20:55] <bryce> yeah
[20:57] <bryce> we've got one TV out properties related bug, but it's medium priority
[20:59] <bryce> looks like we don't have a lot of user demand for it; guess we'll just snag it for karmic when we merge
[21:10] <tormod> bryce: I googled for "frontbuffer rendering broken" and found 19174 :)
[21:11] <tormod> I will fix it in the wiki
[21:11] <bryce> yikes
[21:11] <bryce> thanks
[21:13] <tormod> bryce: you had a lock on the page, any pending changes in your browser?
[21:13] <bryce> none
[21:14] <tormod> saved
[22:18] <RichardWolfVI> hey I'm on Jaunty and playing video crashes X on most cases
[22:20] <tormod> on intel, of anyone wondered
[22:20] <tormod> s/of/if
[22:21] <tormod> do you have specified a Virtual size?
[22:22] <RichardWolfVI> tormod: I don't know about that.
[22:23] <tormod> your xorg.conf is the default one?
[22:24] <tormod> well actually the Display Preferences GUI will rewrite it if you play with dual screen
[22:24] <RichardWolfVI> Well, I'm using a single one
[22:26] <RichardWolfVI> http://paste.ubuntu.com/155570/ my xorg.conf
[22:27] <tormod> hmm how come you have that "greedy" in there if you never touched it?
[22:27] <RichardWolfVI> I didn¿t said I never touched it
[22:27] <RichardWolfVI> *didn't
[22:28] <RichardWolfVI> I just added that line in hopes the graphics performance increased
[22:28] <RichardWolfVI> at least compiz isn't hanging now
[22:50] <JanC> is there a reason why Ubuntu patches Xorg to allow only 20 input-devices instead of the default 128?
[23:00] <bdmurray> bryce: is there somewhere compiz isn't running anymore on my intel card bugs should go?
[23:01] <jbarnes> bdmurray: it's currently disabled
[23:01] <jbarnes> due to 359392
[23:01] <bdmurray> jbarnes: right, I realize that I was wondering if there was some master bug they should be made a duplicate of
[23:01] <jbarnes> ubottu: that's bug 359392 btw
[23:02] <jbarnes> bdmurray: maybe that one
[23:16] <bryce> ah, let's not dupe to that one; it's long enough as is, and we still need it for working on
[23:16]  * bryce looks for better one to dupe to
[23:17] <bryce> yikes, >300 bugs on intel
[23:19] <bryce> bdmurray: 363821 looks suitable to dupe against
[23:19] <bryce> I'll update that one
[23:24] <jbarnes> bryce: yeah don't remind me
[23:24] <jbarnes> bryce: we've got >300 open at fdo also
[23:24] <jbarnes> and I seriously doubt all the ubuntu ones have fdo analogs :/
[23:25] <bryce> likely not
[23:59] <JanC> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/364895 --> feature request for karmic  ツ