[00:06] <jg> bryceh: beta 2 wouldn't even boot at all on that Latitude XT I've got.  Sigh.
[00:19] <bryceh> jcristau, what do you think of this patch - http://launchpadlibrarian.net/32728179/xserver-xorg-backclear.patch
[00:19] <bryceh> jcristau, it's from the fglrx folks and solves a rather longstanding issue for fglrx users, but I'm uncertain how it'd affect !fglrx folks
[00:44] <bryceh> jcristau, anyway my guess is the patch just pushes issues to other use cases
[01:59] <Sarvatt> bryceh: that bug makes my head hurt
[02:00] <Sarvatt> read probably 200 comments on it just now, i'd say 90% of them are people giving *really* bad advice people might actually try :)
[02:02] <Sarvatt> ahhh darnit, the new git-core update we got made me think my packaging repos were messed up and I started over, but the huge warnings are happening everywhere now after all
[02:04] <bryceh> Sarvatt, yeah there's a lengthy blog post I did a while back on all the evils of me-too storms
[02:04] <Sarvatt> oops, looks like it was an actual change in git functionality that broke how I use it, crap
[02:06] <Sarvatt> no, i'm just an idiot and was updating the wrong package. need sleep :)
[02:07] <Sarvatt> bryceh: yeah I remember that, almost makes me wish we could tag bug comments as inappropriate and have a filter for them :)
[02:08] <bryceh> yep
[02:08] <RAOF> That's an interesting idea.  Allow maintainers to flag comments as “The maintainer thinks that taking this advice is a BAD IDEA” or somesuch.
[02:08] <bryceh> I still think we need launchpad to require > N karma in order to comment on someone else's bug, especially once it's gotten more than a dozen comments
[02:12] <RAOF> That would probably work, particularly if it encouraged people with insufficient karma to file a new bug.
[02:12] <bryceh> (or just click 'affects me too')
[02:13] <RAOF> That too.
[02:13] <RAOF> Although we'd miss bugs that way.
[02:13] <Sarvatt> is affects me too even useful? if it affects someone I want to see their system info
[02:13] <RAOF> Because there's a significantly higher than 0 chance that this particular bug does *not* affect them too, and they've got a different one.
[02:14] <Sarvatt> specifically if its a bug requiring a hardware specific quirk to be added
[02:14] <bryceh> Sarvatt, it's useful in making the reporter feel they have done their part, without cluttering our bug tracker with useless 'me-too' comments ;-)
[02:15] <RAOF> That could have a technological solution - if apport-collect didn't laboriously attach everything as an individual comment, but instead just added a link with “here's the data of another person who thinks they've got this bug” we could make that happen.
[02:16] <RAOF> Making apport-collect less intrusive would be a worthwhile goal regardless, I tihnk.
[02:16] <bryceh> yep
[02:18] <RAOF> Launchpad just isn't sufficiently awesome.  It'd be useful to be able to issue queries like “what hardware has been reported affected by this bug”, and suchlike...
[02:20] <bryceh> or the inverse... "Show me what bug reports have been reported against this hardware"
[02:20] <RAOF> Hell, yes.
[02:20] <bryceh> imagine if launchpad had the ability to show you a list of bugs that excluded ones that aren't applicable to it
[02:21] <bryceh> er applicable to the hardware you are on
[02:21] <bryceh> would eliminate many false-positives
[02:21] <bryceh> well, one day we'll have that, in time for debugging our flying cars
[02:27]  * bryceh > dinner
[02:32] <Sarvatt> part of me wants to drop a huge number of patches in edgers packages just so things are closer to upstream for people asked to test on bug reports, but then the other part wants to do things like backporting EXA from master to 1.7 branch :D
[02:32] <KiBi> at 3:30am? Crazy guy
[02:32] <KiBi> Sarvatt: please backport EXA stuff; that'll spare me some work :)
[02:33] <KiBi> (the other part here needs to sleep, sucky one..)
[02:33] <RAOF> Sarvatt: Dropping patches in edgers seems reasonable to me; upstream bug testing is one of its purposes.
[02:33] <Sarvatt> KiBi: I've been doing it for a month or so already - http://sarvatt.com/downloads/patches/exa_backport_to_1.7.6.patch
[02:33] <KiBi> ah, fat huge patch :)
[02:34] <KiBi> (thanks for the pointer anyway)
[02:35] <Sarvatt> haven't heard any complaints, i've been doing it that way because i dont have time to bring in xserver 1.8 and rebuild the world and its supposed to be a significant speed up
[02:38] <Sarvatt> (plus it fixes the xfig crashing the server bug)
[02:41] <Sarvatt> thats just a git diff xserver-1.7.6..master exa/ btw
[02:52] <KiBi> Sarvatt: what I wanted to do would be more like cherry-picking targeted fixes so I guess I'm going to sleep later :)
[03:02] <Sarvatt> oh nice, http://cgit.freedesktop.org/xorg/xserver/commit/?id=1760d2bef9f5b248cb2332f6ebf0220eb02bab42 applies to our 1.7.6 too, can finally test out chromium webgl :)
[04:44] <Amaranth> Sarvatt: But then programs will start trying to use it and almost certainly run in to some sort of bugs
[04:49] <Sarvatt> I'm not suggesting using it ubuntu or anything, i'll be glad if I do find something broken by it so I can report it :)
[06:14] <Amaranth> Well I can't say bug 562773 was unexpected but I was rather surprised to see it filed against compiz
[06:14] <ubottu> Launchpad bug 562773 in xorg "Enable automatic graphics switching (between integrated and discrete graphics) similar to OSX" [Undecided,New] https://launchpad.net/bugs/562773
[06:18] <RAOF> Don't you know?  Compiz *is* OSX.
[09:26] <Ng> hrm, disabling DRI on 855
[09:26] <Ng> is that going to have a nasty effect on compiz performance?
[09:28] <jcristau> it's going to make compiz not work.
[09:38] <Ng> jcristau: that's unfortunate. my old X40 which sees ~1hr usage a day has been doing really well on Lucid, I don't think it's crashed at all, but I guess people with crappier laptops, or heavier usage, are having problems
[09:38] <Ng> why oh why doesn't everyone buy a nice laptop? ;(
=== |thade| is now known as Alexia_Death_
=== ricotz is now known as ricotz_
=== ricotz_ is now known as ricotz
[15:15] <rye> is font rendering applied here?
[15:15] <rye> Terminus font on http://wiki.openvz.org/Download/template/precreated looks scaaary
[15:58] <apw> anyone aware of bug#546743
[15:58] <apw> anyone aware of bug #546743
[15:58] <ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed] https://launchpad.net/bugs/546743
[15:59] <apw> bryceh, was it you who was looking after ATI
[16:06] <tseliot> apw: does booting with radeon.modeset=0 solve the problem?
[16:07] <apw> tseliot, booting with nomodeset seems to sort it out yes
[16:07] <apw> seems to be a boot panic, flashing caps locks with it
[16:08] <tseliot> apw: [drm:radeon_i2c_sw_put_byte] *ERROR* i2c 0x08  -> it looks like the i2c functions are not working correctly
[16:09] <apw> ouch
[16:09] <tseliot> apw: maybe disabling kms for this chip wouldn't be such a bad idea at this point in the release cycle
[16:10] <tseliot> unless there's a fix somewhere
[16:25] <apw> tseliot, so many exclusions
[16:25] <tseliot> apw: I wish we could fix every bug but, unfortunately we can't :-/
[16:27] <apw> indeed, i am wondering however if the blacklists should really be done in userspace somehow
[16:27] <apw> so the list can be updated
[16:28] <tseliot> apw: but then we would have to blacklist radeon in the initramfs too, which we can't do on per card model basis
[16:29] <tseliot> I guess. I may be wrong though
[16:30] <Sarvatt> hmm apw thats a new one, I've seen at least 5 confirmations ES1000 was working fine
[16:31] <apw> Sarvatt, hrm, beep
[16:31] <Sarvatt> those logs dont really help, they are on the old drm kernel and its probably totally different now
[16:31] <Sarvatt> asked him for more recent ones
[16:34] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=2739d49cd7f1f44876cad614b072da698967b370 is the only rn50 specific we dont have already
[16:45] <rickspencer3> apw hi
[16:52] <apw> rickspencer3, ...
[16:52] <rickspencer3> apw, same discussion
[16:52] <apw> Sarvatt, thanks for poking that hornets nest
[16:52] <rickspencer3> we sadly got out of sync regarding the 845, 855 instabilities
[16:52] <rickspencer3> trying to rectify that now
[16:53] <rickspencer3> apw, sadly, I am not really a good technical resource for helping you understand the work around
[16:53] <rickspencer3> bryceh is, of course, bu tI don't expect him online for a bit
[16:56] <Sarvatt> heres a dmesg from someone on rn50 thats working fine, they only have one connector listed - http://launchpadlibrarian.net/41443377/BootDmesg.txt
[17:29] <bryceh> heya
[17:52] <Dr_Jakob> Hmm it looks like xserver-xorg-core-dbg is broken in Lucid.
[17:52] <Sarvatt> Dr_Jakob: sudo apt-get purge xserver-xorg-core-dbg, reboot and install xserver-xorg-core-dbg after?
[17:52] <Sarvatt> works for me
[17:53] <Dr_Jakob> Ok I'll try
[17:54] <Sarvatt> upgrading doesn't work, CRC errors, it's not specific to xserver-xorg-core-dbg for me and it happens to any dbg packages for things currently in use when I  upgrade
[17:54] <Dr_Jakob> ah ok
[17:55] <Dr_Jakob> Still get the CRC error tho...
[17:55] <Sarvatt> apw: sorry looking into it in 20 minute chunks between jobs so its taking awhile, really need to find out the panic message when it panics for him but it seems related to the external tmds on there
[17:56] <Dr_Jakob> this is 64bit btw...
[17:57] <Sarvatt> odd, i've been having that problem for months and that routine works for me every time
[17:58] <Sarvatt> does it load it if you manually load the symbols in gdb?
[17:58] <Dr_Jakob> Hmm my gdb-fu isn't that good?
[18:00] <Sarvatt> symbols /usr/lib/debug/usr/bin/Xorg
[18:00] <Sarvatt> (or is it just symbol..)
[18:05] <Dr_Jakob> hmm that worked...
[18:16] <Sarvatt> i dont know what the deal is there, been a problem for months though. Dr_Jakob try enabling the ddeb repo and install -dbgsym instead of -dbg?
[18:16] <Sarvatt> add deb http://ddebs.ubuntu.com lucid main restricted universe multiverse #debugging ddebs to your /etc/apt/sources.list and update then install xserver-xorg-core-dbgsym
[18:20] <Dr_Jakob> Reading symbols from /usr/lib/debug/usr/lib/xorg/modules/libshadowfb.so...(no debugging symbols found)...done.
[18:20] <Dr_Jakob> hmm the package was only 160kb..
[18:21] <Sarvatt> ugh, tried manually loading those symbols too? thats annoying, wonder why I dont hit that
[18:22] <Sarvatt> the dbgsym was only 160k?
[18:22] <Dr_Jakob> Get: 1 http://ddebs.ubuntu.com/ lucid/main xserver-xorg-core-dbgsym 2:1.7.6-2ubuntu3 [8,612B]
[18:22] <Dr_Jakob> Fetched 8,612B in 0s (231kB/s) 
[18:23] <jcristau> probably because the -dbg already exists so there's nothing to put in dbgsym
[18:24] <bryceh> yeah you don't want both -dbg and -dbgsym
[18:25] <Sarvatt> i just installed xserver-xorg-core-dbg and its working fine, go figure :(
[18:26] <Sarvatt> the crc's match when i compare them
[18:26] <Dr_Jakob> Sarvatt: 64bit?
[18:26] <Dr_Jakob> can you md5sum Xorg and debug Xorg?
[18:26] <Sarvatt> nope 32
[18:27] <Dr_Jakob> Hmm :-/
[18:28] <Dr_Jakob> Well I head home now, I'll try a 32bit VM tomorrow: I'm currently trying to solve https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-vmmouse/+bug/545298
[18:28] <ubottu> Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [Undecided,Incomplete]
[18:29] <vish> hmm , anyone noticed that there is a problem when running flash video? memory is used enormously  , even swap gets used
[18:30] <Dr_Jakob> Sarvatt: thanks for all the info.
=== apachelogger is now known as starshiptrooper
[19:02] <apw> bryceh, about?
[19:07] <bryceh> yeah
[19:27] <apw> bryceh, rickspencer3 says you have some machines which have 'serious i915 issues'
[19:27] <apw> and so i am wondering what the issues are, as the kernel is uploaded
[19:31] <bryceh> apw, ??
[19:31] <bryceh> apw, afaik the only thing we're really worrying about at this stage are a few 8xx cards
[19:31] <apw> bryceh, hrm if you don't know then i guess they don't exist
[19:32] <bryceh> but we shut off dri in them the other day in ums
[19:32] <apw> then perhaps its all nothing
[19:32] <bryceh> we might ask you to do a couple more kms blacklists, but testing so far isn't indicating it solves the freezes anyway
[19:33] <bryceh> apw, do you need to roll a kernel rev to add blacklists?
[19:33] <apw> yep blacklists are a full kernel upload
[19:33] <apw> do you think you have a few you need?
[19:33] <apw> if so we might want to plan on getting one upload like late friday with the accumulation
[19:34] <apw> and start asking for permission
[19:34] <bryceh> well like I said we have been considering it for a few 8xx chips, but so far testing with i915.modeset=0 on those cards hasn't shown it improves things, so maybe not
[19:34] <apw> i have a bad dell bug outstanding which i need to get fixed, which if i do i suspect will be allowed past freeze too
[19:34] <bryceh> let me check the state of the bug reports in question
[19:37] <bryceh> apw, lp #542208
[19:37] <ubottu> Launchpad bug 542208 in linux "Please blacklist i830 from Kernel mode-setting" [Critical,In progress] https://launchpad.net/bugs/542208
[19:38] <bryceh> apw, maybe you already did that one?
[19:38] <apw> crap i have patches for it but they arn't in
[19:39] <bryceh> the other two we're considering are 541492 (i845) and 541511 (i855)
[19:40] <Sarvatt> ah crap, everything I said earlier didn't go through
[19:40] <apw> ok so i may as well hold this one till the decisiion is made on the other two ?
[19:40] <Sarvatt> <Sarvatt> anyone seen a bug report for these rs600 failures to start? inspiron xt is the most common model
[19:40] <Sarvatt> <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32b3c2abaf8c61c80a8b02071c73f05252122ffe is the fix but I dont have a bug report handy to link it to
[19:40] <Sarvatt> <Sarvatt> jg was complaining about it earlier
[19:42] <apw> bryceh, or should i shove it in now ... 
[19:43] <bryceh> 2 minutes... reviewing recent bug report comments
[19:44] <Sarvatt> <Sarvatt> Keybuk had the problem originally but he worked with upstream for the fix, dont think he filed a bug on LP
[19:44] <Sarvatt> <Sarvatt> vish: yeah I'm experiencing the same problem with intel right now, disabling BO reuse in driconf fixes it
[19:44]  * Sarvatt grumbles at the crappy signal
[19:45] <bryceh> apw, I think we should go ahead with blacklisting i830, i845, and i855
[19:45] <bryceh> apw, want me to dig up the pci ids?
[19:45] <apw> sure ...
[19:46] <apw> mvo, is testing the i830  blacklist 'now-ish'
[19:46] <bryceh> i830: 8086:3577, i845:  8086:2562, i855: 8086:3582
[19:47] <bryceh> apw, want it in the form of a bug report?
[19:47] <apw> it'll need one yeah at this stage
[19:47] <apw> but i'll get the kernel building, you got any h/w to test it?
[19:47] <bryceh> no, I don't have any 8xx hardware
[19:48] <apw> damn
[19:48] <bryceh> the jerry guy seems pretty responsive though and has two of the three chips
[19:48] <apw> whats hit irc nic?
[19:48] <bryceh> don't think he's on irc
[19:48] <apw> oh
[19:48] <Sarvatt> sorry thats latitude XT that has the RS600 that can't boot lucid
[19:49] <bryceh> lp id is jerrylamos
[19:51] <Sarvatt> got one - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/544590
[19:51] <ubottu> Launchpad bug 544590 in linux "[RS600] video freeze with KMS (X and plymouth)" [High,Confirmed]
[19:52] <bryceh> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/563277
[19:52] <ubottu> Launchpad bug 563277 in linux "Please blacklist older 8xx cards from using KMS" [Undecided,New]
[20:01] <vish> Sarvatt: hmm , where do i have to disable it?  I'm using ATI , btw , also heard the same complaint from another lucid user on a mac hardware
[20:01] <vish> the " disabling BO reuse in driconf"
[20:02] <bryceh> Sarvatt, what are your thoughts vis-a-vis blacklisting 830, 845, 855 from kms?
[20:10]  * vish brb
[20:11] <apw> bryceh, are you asking for more than those 3 ID above to be blacklisted on that bug ?
[20:12] <bryceh> apw, yeah, while we're at it we may as well do the earlier chips.  I don't think anyone has been testing them but if these three dont' work, those older ones won't either
[20:13] <bryceh> apw, those earlier ones aren't even supported upstream any longer in the newer -intel so we're going to have to drop them down to -vesa 
[20:14] <bryceh> apw, what do you think?
[20:14] <apw> i am really in your hands ... that sounds plausible
[20:14] <bryceh> apw, fwiw, blacklisting kms is going to give us only marginal benefits as near as I can tell, so I'm a bit on the fence
[20:15] <apw> bryceh, as in they are as bad on UMS as well?
[20:15] <apw> bryceh, these older ids don't seem to be in the driver, so i don't think it will attach to i915
[20:15] <bryceh> apw, yeah the testers say the freezes still happen, just less often
[20:15] <bryceh> alright
[20:16] <bryceh> ok cool, wasn't sure.  Like I said they're no longer supported by upstream, so no surprise they're not even in i915 anymore
[20:16] <apw> yeah not there at all
[20:17]  * bryceh removes them from bug report
[20:19] <apw> ok .. i am building test kernels with those blacklists in
[20:20] <apw> we should get some feedback on i830 from mvo when he's done testing
[20:20] <bryceh> ok great
[20:20] <apw> and we should get as many of us as possible to boot test it on non-affected h/w
[20:20] <apw> if that passes i can upload it later tonig
[20:20] <apw> as it seems we cna only fix the dell thing before release if we can upload tommorrow
[20:21] <apw> so we should upload this before freeze ...
[20:21] <apw> i'm off to the s/m will check the builds when i get back
[20:43] <komputes> bryceh: Any PPA that may workaround this bug: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/301958
[20:43] <ubottu> Launchpad bug 301958 in xorg-server "[needs-packaging] no working driver for sis 671/771 video cards" [Unknown,Confirmed]
[20:44] <komputes> Djalma B. Martins  wrote on 2009-07-04 that extracting the driver from the RPM (linked in the bug) works. Could this be packagd/
[21:22] <Sarvatt> komputes: none that I'm aware of, that "needs-packaging" bug refers to a fork of the sis driver from a *very* long time ago that no longer works with xserver 1.7, the other distro that was shipping it has also dropped it in the latest release
[21:23] <komputes> Sarvatt: thanks for the update - is the guy who does the SIS driver for linux still active. I remember emailing him a year ago but never getting a response
[21:23] <Sarvatt> nope, he stopped working on that driver 4 or 5 years ago I believe
[21:27] <bjsnider> won't vesa work with it?
[21:29] <vish> Sarvatt: how do i disable the BO reuse?
[21:35] <Sarvatt> komputes: try looking into using sisfb and manually picking your resolution and using fbdev for the server if its just a resolution problem you have
[21:35] <Sarvatt> vish: driconf
[21:36] <vish> thanks ..
[21:36]  * vish  installs driconf
[21:37] <Sarvatt> vish: do you have a bug or know of a bug about it already? might end up having to default BO reuse to off
[21:37] <komputes> Sarvatt: by "using sisfb" I assume you mean adding "sisfb" to /etc/modules - not too sure what you mean by fbdev
[21:37] <Sarvatt> vish: or are you using edgers?
[21:38] <vish> Sarvatt: nope , i reverted from edgers a couple of weeks ago , i dont think there is a bug
[21:38]  * vish files one
[21:38] <vish> Sarvatt: bug should be in which , btw?
[21:39] <Sarvatt> mesa or xserver-xorg-video-intel
[21:40] <Sarvatt> vish: cat /sys/kernel/debug/dri/0/gem_objects will show you the crazy memory usage
[21:41] <vish> hmm , let me play flash again , just restarted session to clear swap
[21:47] <BUGabundo> evening 'p
[21:49] <BUGabundo> great... now I'm left with an artifact on my screen... from a mouse over tooltip. how can I remove this ?
[21:59] <vish> anyone seen this >  http://www.youtube.com/watch?v=C_ozjS55mW8
[22:00] <vish> err , not a spam youtube link , but rather a capture of and X error ^ ;)
[22:01] <vish> of a*
[22:10] <BUGabundo> lol
[22:21] <vish> BUGabundo: i mentioned it since there was spam running on several channels , "Have you seen my boobs or are my boobs small" with a link :s
[22:22] <vish> but that link is bug I'm facing ;p
[22:23] <BUGabundo> vish: reminds me of yesterday apache.org shortlink atack
[22:33] <vish> Sarvatt: weird , i dont have an option for "BO reuse" in driconf :(
[22:33] <tormod> did anyone find out about the CRC mismatch in gdb? I get it with /usr/lib/dri/savage_dri.so
[22:41] <bryceh> tormod, haven't heard anything
[22:57] <Sarvatt> tormod: manually load the symbols with symbol /usr/lib/debug/usr/lib/dri/savage_dri.so
[22:57] <tormod> Sarvatt, I tried but it did not help
[23:24] <Sarvatt> tormod can ya paste the output of objdump -s -j .gnu_debuglink /usr/lib/dri/savage_dri.so ?
[23:33] <tormod> sarvatt:  0000 73617661 67655f64 72692e73 6f000000  savage_dri.so...
[23:33] <tormod>  0010 090b30b4                             ..0.            
[23:46] <Sarvatt> strange, it works here, that with the lucid mesa?
[23:46] <Sarvatt> debug_file: /usr/lib/debug/usr/lib/dri/savage_dri.so has CRC of 929AF169
[23:46] <Sarvatt> actual_file: /usr/lib/dri/savage_dri.so thinks CRC should be 929AF169
[23:47] <Sarvatt> i have edgers at the moment, switching back to lucid mesa to check it
[23:50] <Sarvatt> your CRC should be b4300b09 so you definitely aren't using edgers, silly question
[23:51] <Sarvatt> vish: oh, you aren't using intel?
[23:53] <Sarvatt> tormod: yeah the lucid archive ones are screwed up here too
[23:53] <Sarvatt> debug_file: /usr/lib/debug/usr/lib/dri/savage_dri.so has CRC of 72419D41
[23:53] <Sarvatt> actual_file: /usr/lib/dri/savage_dri.so thinks CRC should be B4300B09
[23:54] <Sarvatt> all the xserver ones are screwed up too, hmm
[23:54] <jcristau> binutils fuckage?
[23:56] <Sarvatt> sounds like it
[23:56] <jcristau> sounds like a great time in the release cycle for that
[23:57] <Sarvatt> or pkg-create-dbgsym since PPA packages are fine