[00:01] <ernstp> Sarvatt, nope, radeon 4770, desktop
[00:01] <ernstp> Sarvatt, goes something like this:
[00:02] <ernstp> blinking vga cursor for a while, then some error message 
[00:02] <Sarvatt> flickering as in, brightness changing while the ubuntu logo is on the screen?
[00:02] <ernstp> then plymouth boot
[00:02] <ernstp> then vga again, then plymouth boot
[00:02] <ernstp> then black, then gdm
[00:03] <ernstp> no, only between vga+black and plymouth/gdm
[00:03] <ernstp> 2/3 times depending on how you count
[00:04] <Sarvatt> bryceh: did you include the bgnr patch with the latest ati upload?
[00:04] <ernstp> kms works fine generally
[00:04] <Sarvatt> ernstp: you're using stock lucid packages?
[00:04] <ernstp> but there's nothing smooth about my boot
[00:04] <Sarvatt> (because I dont have the splash integration stuff on xorg-edgers)
[00:05] <ernstp> Sarvatt, yes! I've actually made a point of that, usually don't :-)
[00:05] <bryceh> Sarvatt, yep, why, is there a problem?
[00:05] <Sarvatt> yeah 100_radeon-6.9.0-bgnr-enable.patch is there so its not that
[00:06] <ernstp> bryceh, plymouth problems...
[00:06] <Sarvatt> bryceh: just ernstp saying thats not working for him and that was my first idea :D
[00:06] <ernstp> it's switching to vga two times during boot
[00:06] <Sarvatt> ernstp: pastebin your dmesg?
[00:06] <ernstp> no smooth transition between plymouth and gdm
[00:07] <ernstp> http://paste.ubuntu.com/407302/
[00:08] <ernstp> kms generally working very well etc
[00:08] <ernstp> Sarvatt, bryceh, plymouth-log-viewer: http://paste.ubuntu.com/407303/
[00:11] <Sarvatt> nothing there showing what you're saying happening of course, do you have multiple monitors or anything?
[00:11] <ernstp> nope
[00:11] <ernstp> 1650x1080
[00:12] <Sarvatt> been happening for awhile or just recently?
[00:12] <ernstp> awhile
[00:12] <ernstp> quite consistent between the different plymouth updates I would say actually
[00:12] <ernstp> not sure about that though
[00:13] <ernstp> let me reboot and note exactly what happens
[00:13] <Sarvatt> try echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash and then sudo update-initramfs -u and see if its any different?
[00:13] <ernstp> oki
[00:16] <ernstp> Sarvatt, ok, that was one flicker less
[00:16] <Sarvatt> transition work?
[00:17] <ernstp> Grub -> vga 3 seconds -> 2 sec monitor off pause -> plymouth 6-7 secs -> vga 1 sec -> gdm no transition
[00:18] <Sarvatt> by gdm no transition you mean you see a black screen for awhile right?
[00:19] <ernstp> yeah, black vga 1 secs between plymouth and gdm
[00:19] <Sarvatt> it'd be way more than 1 second if it wasn't working, you never have a mouse cursor over the ubuntu logo?
[00:20] <ernstp> oops
 it'd be way more than 1 second if it wasn't working, you never have a mouse cursor over the ubuntu logo?
[00:20] <ernstp> did I miss anything?
[00:20] <ernstp> before your change I usually had a mouse cursor on plymouth really quickly, then black, then gdm
[00:21] <ernstp> didn't see one now
[00:21] <Sarvatt> if you have a mouse cursor ever with the ubuntu logo on the screen the transition is working
[00:21] <ernstp> except it get's interrupted by a black vga screen
[00:21] <ernstp> so it's not a nice transition
[00:22] <Sarvatt> its kind of delayed now too since gdm doesn't show the cursor initially either, but plymouth is long since quit by the time a cursor is shown
[00:23] <Sarvatt> ernstp: /var/log/Xorg.0.log now please :D
[00:24] <ernstp> pastebin commandlinetool?
[00:24] <Sarvatt> it's something setting a new mode after gdm startup probably, your xrandr config maybe?
[00:24] <Sarvatt> cat /var/log/Xorg.0.log | pastebinit
[00:24] <ernstp> can I have a xrandr config in gdm?
[00:24] <RAOF> You don't happen to have a second monitor plugged in, do you?
[00:25] <ernstp> http://pastebin.com/rTs5WFm9
[00:25] <ernstp> nope
[00:25] <RAOF> Sarvatt: UUOC :) - that can be accomplished more simply by “pastebinit /var/log/Xorg.0.log” :)
[00:26] <ernstp> let me write down exactly what happens wiht FRAMEBUFFER=n
[00:26] <Sarvatt> ernstp: open gconf-editor, go to apps/gdm/simple-greeter/settings-manager-plugin
[00:26] <Sarvatt> xrandr, uncheck the enable box
[00:27] <ernstp> done
[00:27] <ernstp> ok, try again
[00:33] <Sarvatt> RAOF: huh, that works? it didn't used to and I use it so much hence my overuse of cat | grep :D
[00:33] <ernstp_> hmm, that helped a bit I guess
[00:34] <ernstp_> now set FRAMEBUFFER=n
[00:34] <Sarvatt> just delete that file and update-initramfs -u
[00:35] <ernstp_> vga 10 seconds, then plymouth, then gdm, no transitions
[00:35] <Sarvatt> i'd leave it in the initrd though if you dont want things to be ugly :D
[00:36] <ernstp_> that was with FRAMEBUFFER=n
[00:36] <ernstp_> now with =y again
[00:36] <Sarvatt> ernstp_: i'm 100% positive the transition is working for you, it's something changing the mode after startup
[00:37] <Azelphur> don't suppose there is a command I can use to make X clean up leaked memory?
[00:37] <ernstp> now I don't get any hint of transition at all..
[00:37] <Sarvatt> sudo jockey-text -d xorg:nvidia_current works :D
[00:37] <ernstp> with FRAMEBUFFER=y its:
[00:37] <Azelphur> 47.1% of 8GB for Xorg is fun :P
[00:38] <ernstp> 1 sec vga, 10 sec plymouth, black screen, then gdm all loaded and complete
[00:38] <ernstp> well have to got to bed now, hope that gave something :-)
[00:38] <ernstp> thanks Sarvatt, cya!
[00:40] <Sarvatt> ernstp: I dont think you've ever booted without the transition patches to -ati, you wouldn't see the ubuntu logo for more than a second without them :D
[01:07] <Sarvatt> so apparently the x segfaults when closing clutter apps only happen with libclutter-1.0-0_1.2.4-0ubuntu1 and go away with libclutter-1.0-0_1.0.6-0ubuntu1
[01:08] <Sarvatt> which is odd since i thought debian had clutter 0.8.x still and they were getting it too
[01:19] <Sarvatt> seems like a problem not really specific to upstream because the glx bump to 1.4 on xserver 1.7 branch isn't upstream
[01:22] <jcristau> debian has clutter 1.0.8 in sid and 1.2.4 in experimental fwiw
[01:42] <superm1> Sarvatt, you were right, moving the mouse to the top of the screen when gnome terminal goes all wonky fixes it. how bizarre
[02:32] <Sarvatt> oh superm1? same darn bug then
[02:44] <bryceh> new intel-gpu-tools git snapshot uploaded
[02:44] <desrt> Sarvatt: hey.  got that xorg driver update you wanted me to try?
[02:45] <ScottK> Is Intel 865 expected to work on Lucid after the latest uploads get built?
[02:46] <Sarvatt> desrt: https://edge.launchpad.net/~sarvatt/+archive/bugs/+sourcepub/1013559/+listing-archive-extra
[02:46] <desrt> cheers
[02:47] <bryceh> ScottK, "expected" is such a strong word
[02:48] <bryceh> ScottK, it's worth re-testing but don't hold your breath
[02:48] <ScottK> OK.
[02:48] <ScottK> Is 865 on the list of things you want to get working?
[02:49] <bryceh> everything is on that list ;-)
[02:49] <bryceh> but no, I have no additional 8xx enablement work planned in my todo list
[02:49] <desrt> Sarvatt: ok.  i've installed.  i'm going to reboot and try to login and out a few times to see if i can get the crash
[02:49] <desrt> bbiab.
[02:50] <bryceh> actually I have one other potential todo which is to do kms blacklists of any 8xx chips that we find work with ums but not kms
[02:50] <ScottK> OK.  Sounds like time to find that stack of CD-Rs.
[02:50] <ScottK> Thanks.
[02:50] <bryceh> but I need testing feedback from 8xx owners in order to do that
[02:51] <ScottK> Right, I would be one of those, thus finding the CD-Rs.
[02:52] <ScottK> How's 945 looking?
[02:53] <bryceh> I've backported most of the 8xx changes that looked safe and easy.  There's some more which are harder to backport due to massive refactoring upstream, but which might help - I think those can be tested via xorg-edgers.  If xorg-edgers is found to solve the issues then I guess we could take a deeper look into those patches
[02:53] <bryceh> but so much of upstream's changes are "Remove..." "Kill..." "Drop..." that it's a bit scary to wade through
[02:53] <ScottK> OK.  I'll try to do some testing this weekend.
[02:53] <bryceh> 945 should be fine, and afaik what issues remain need kernel fixes
[02:54] <bryceh> the issues were lid and suspend/resume and plymouth/boot-prettiness related things
[02:55] <desrt> Sarvatt: ok... after one bootup, no crash
[02:55] <desrt> but osmething odd happened on logout
[02:55] <ScottK> Worse comes to worse I guess I do a chassis swap.  I have a 945 box I'm using as a server and an 865 box as a desktop.  I also have 945 desktops too.
[02:56] <desrt> Sarvatt: now i'm getting these instead: (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: No space left on device.
[02:56] <desrt> Sarvatt: but to be honest with you, i was experiencing some random display corruption even on karmic
[02:57] <desrt> Sarvatt: i wouldn't be surprised if that message was appearing in the log before and i just didn't notice it because i wasn't really looking
[02:58] <desrt> ok.  corruption is actually much worse now than it was under karmic
[02:58] <desrt> so i'm actually not sure if it's related
[03:00] <Sarvatt> desrt: can ya give me the xorg log?
[03:00] <desrt> Sarvatt: also: i think i've determine that when the crashes happen they're not taking out all of userspace
[03:00] <desrt> rather, they appear to be taking out the *harddrive*
[03:01] <desrt> i can do anything that was already in cache
[03:01] <desrt> when i try to access something not in cache ,the process goes into D-state
[03:02] <desrt> i wonder if maybe the harddrive and the graphics share an irq or something
[03:02] <Sarvatt> i want to see the framebuffer adjustment line with the patch
[03:02] <Sarvatt> just before the batchbuffer error
[03:03] <bryceh> new radeontool 1.6.1 uploaded
[03:04] <desrt> (II) intel(0): Allocate new frame buffer 2400x1920 stride 9728
[03:04] <desrt> that one?
[03:04] <desrt> note: no errors so far
[03:04] <desrt> i'll just paste the hold lot.  just a sec.
[03:05] <desrt> http://pastebin.org/130005
[03:06] <desrt> all those lines except for the very last one happen up to the login scren
[03:06] <desrt> the very last one happens when i login
[03:07] <desrt> gonna do the glaringly obvious thing and try to go into the bios and max out the amount of shared memory allocated to the graphics.
[03:08] <desrt> i'm getting graphics corruption this time in the form of the cursor in gnome-terminal being corrupted when it moves
[03:08] <desrt> but no message about it in the log
[03:14] <Sarvatt> desrt: wait, so you have *3* monitors running?
[03:14] <desrt> only 2, really
[03:14] <desrt> it's a laptop with 3 external display ports
[03:14] <desrt> i am using 2 of them
[03:14] <desrt> and i have the laptop LCD disabled
[03:15] <desrt> the laptop itself has a VGA out
[03:15] <desrt> which i am not using
[03:16] <desrt> it's sitting on a docking station ('ultrabase') that has VGA and DisplayPort out, both of which i have connected to 1920x1200 dell 24" flatpanels xrandr'd sideways
[03:16] <Sarvatt> try forcing off LVDS
[03:16] <Sarvatt> i think its video=LVDS-1:off
[03:17] <desrt> kernel commandline option?
[03:17] <Sarvatt> yeah
[03:17] <desrt> LVDS-1 or LVDS1?
[03:17] <desrt> xrandr lists it as the latter
[03:17] <Sarvatt> not sure
[03:17] <Sarvatt> lessee
[03:17] <desrt> btw: your patch has stopped the crash-on-login thing, it seems
[03:17] <desrt> 4 boots now, without a crash
[03:17] <desrt> but it introduced the corruption
[03:18] <desrt> i never had corruption like this before your patch
[03:19] <desrt> i'd almost prefer the crash since it only happens half the time :)
[03:19] <Sarvatt> yeah thats because they downgraded batchbuffer errors to not take the server down post 2.9.1
[03:19] <desrt> ahh
[03:19] <Sarvatt> i think your setup is pushing the little laptop way too hard with all those screens :D
[03:19] <desrt> worked fine on karmic :p
[03:20] <desrt> but maybe you're right.  it might do me good to downgrade my setup a bit for the time being
[03:20] <Sarvatt> just disabling the LVDS should fix it
[03:20] <Sarvatt> trying to find the kernel parameter now
[03:20] <desrt> xrandr has it turned off...
[03:20] <desrt> but i guess it should be dead from the start
[03:20] <Sarvatt> it *should* be video=LVDS-1:off
[03:21] <desrt> i'm surprised LVDS is even getting DCC
[03:21] <Sarvatt> if :off is the right way
[03:21] <desrt> k.  i'll try that.
[03:21] <desrt> i know it works if the output disappears from xrandr?
[03:21] <desrt> DCC -> DDC?
[03:21] <desrt> the panel is currently sitting at the other end of my desk :p
[03:24] <desrt> new grub is a trip :)
[03:25] <desrt> lvds1 is still listed in xrandr and the corruption remains
[03:25] <desrt> i'm gonna try going down to just one screen
[03:26] <desrt> still have corruption issues ,even on one screen with low resolution
[03:26] <desrt> i think that's just how your driver is.....
[03:30] <desrt> i'm just gonna go back to stock using the normal driver
[03:30] <desrt> i think you're right -- i'm just driving this thing too hard
[03:30] <desrt> i got away with it in karmic, but probably just barely
[03:31] <Sarvatt> 1 extra *should* be fine, i just think there might be problems with 3 huge displays running at the same time, still haven't found the proper way to disable LVDS yet
[03:35] <desrt> i can deal with this for now
[03:35] <desrt> i have a new laptop on the way soon
[03:35] <desrt> well, in a couple of weeks anyway
[03:36] <desrt> also: i can't really afford to waste more time on this issue, sorry :/
[03:37] <desrt> but definitely note that there is something nasty in that driver you had me install.  even with a modest screen configuration it has corruption
[03:40] <bryceh> beta2 has reached freeze
[03:40] <Sarvatt> no worries desrt, sorry I couldn't help ya more
[03:43] <desrt> Sarvatt: you tried lots.  thanks :)
[03:43] <desrt> see you in brussels?
[03:43] <Sarvatt> hopefully, no word on sponsorship yet :D
[03:43] <desrt> best of luck :)
[03:43] <desrt> cheers
[03:44] <Sarvatt> anyone not using intel that wouldn't mind running a little program that'll probably crash your X? :D
[03:45] <RAOF> Sarvatt: Of course!
[03:45] <RAOF> Let me fire up my sacrificial netbook
[03:45] <Sarvatt> http://bugs.freedesktop.org/attachment.cgi?id=34041
[03:45] <Sarvatt> \o/ thanks RAOF
[03:46] <Sarvatt> trying to dig into this clutter crashing bug more, seems when swrast is used the app just segfaults instead of crashing the whole xserver like it does when intel is
[03:47] <bryceh> wow, I sure snuck in a lot of stuff just under the wire
[03:47] <bryceh> just two bits didn't make it (but both are new packages for universe so maybe can still do them)
[03:47] <Sarvatt> RAOF: can you do it with edgers 3D support? :D
[03:48]  * Sarvatt is a pain in the butt, sorry
[03:48] <RAOF> Sarvatt: Yup.  Assuming this netbook will boot.
[03:48] <RAOF> And it might need a little updating first...
[03:49] <RAOF> Universe doesn't get frozen for beta 2, does it?
[03:51] <bryceh> slangasek's email indicated the packages need archive admins to put them in, but no approvals are needed
[03:51] <bryceh> or something like that
[03:51] <bryceh> I didn't get to xorg-server, however most everything I want to go into that are regular bugs and probably acceptable under freeze rules
[03:52] <RAOF> Oooh.  This poor little netbook is all manner of messed up.  How did that happen?  It hasn't been turned on for a couple of days!
[03:59]  * bryceh uploads newly repackaged xserver-xorg-video-displaylink
[04:06] <Sarvatt> ok well maybe debugging more into why it segfaults with swrast will help me figure out why with dri2 it's is taking down the server :D
[05:03] <Sarvatt> bryceh: WHOOPS - http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=bc93395b3eb5e3511c1b62af90693269f4fa6e13
[05:04] <bryceh> Sarvatt, mm, do we have a LP# for this issue?
[05:04] <bryceh> (I ask because now that we're in freeze, we're gonna need paperwork to get bug fixes in)
[05:06] <Sarvatt> just keep an eye out for bugs about the system being unbearably slow after a few hours uptime on r600-r700 :D
[05:07] <Sarvatt> darnit, forgot to --disable-gallium in this mesa debug build, going to take forever
[05:08] <bryceh> I just checked through the source code, we don't have anything matching that stanza of code
[05:08] <bryceh> so perhaps that's a regression they introduced in code newer than ours
[05:08]  * bryceh "Ha! Take that phoronix peanut gallery!  Saved by the not-shipping-bleeding-edge-crap."
[05:09] <Sarvatt> oh i thought we had a post 6.12.192
[05:10] <bryceh> we do, but doesn't look like we have this code
[05:10] <bryceh> what we have now is basically Debian's 6.12.192-2
[05:11] <bryceh> which is 192 plus up to commit 5c256808
[05:11] <Sarvatt> ahhh ok i thought that part was added in the post 192 commit that was fixing the problem in 192 but it was r6xx+ EXA/Xv: add a R600SetAccelState function that added it
[05:11] <bryceh> plus our bgnr patch and the manpage fix I just stuck in (but it's not gone through yet)
[05:12] <Sarvatt> phew
[05:12] <bryceh> :-)
[05:12] <bryceh> btw with freeze in effect I'm hacking on arsenal a bit
[05:12] <bryceh> and I've just posted a new report:
[05:13] <bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/upstream-fixed.html
[05:13] <bryceh> these are bugs that have been marked as fixed upstream
[05:13] <bryceh> there's a surprising amount
[05:13] <bryceh> (44)
[05:13] <virtuald> can someone help me with this, or point me somewhere: [    1.333067] [drm] MTRR allocation failed.  Graphics performance may suffer.
[05:15] <Sarvatt> virtuald: boot with enable_mtrr_cleanup mtrr_spare_reg_nr=1 
[05:15] <Sarvatt> virtuald: let me guess, acer aspire one?
[05:15] <virtuald> yes
[05:15] <Sarvatt> :D
[05:15] <bryceh> smokin' sarvatt
[05:15] <Sarvatt> these things have buggy bioses
[05:15] <virtuald> :>
[05:15] <virtuald> ok
[05:16] <virtuald> i thought about trying a bios upgrade
[05:16] <Sarvatt> theres no bios upgrade that fixes it for these :(
[05:16] <virtuald> ok
[05:16] <Sarvatt> you have a AOA110 or AOA150 model?
[05:17] <virtuald> AOA150
[05:17] <virtuald> ZG5
[05:17] <Sarvatt> i just added it to /etc/default/grub on this line GRUB_CMDLINE_LINUX_DEFAULT="quiet splash enable_mtrr_cleanup mtrr_spare_reg_nr=1"
[05:18] <virtuald> and that fixed it?
[05:18] <Sarvatt> yepyep update-grub after
[05:18] <virtuald> of course
[05:19] <Sarvatt> yeah no fixed bioses for AOA150, thats what I have too
[05:19] <virtuald> i also have usbcore.autosuspend=1 in there, i hope it does something
[05:20] <Sarvatt> did you know there's a gateway bios you can use for your machine that'll most likely add a *ton* more backlight brightness levels?
[05:20] <virtuald> no hehe
[05:20] <virtuald> sounds like black magic
[05:21] <Sarvatt> grep -m 1 AUO /var/log/Xorg.0.log
[05:21] <Sarvatt> whats that say?
[05:21] <virtuald> (II) intel(0): Manufacturer: AUO  Model: 11c2  Serial#: 0
[05:22] <Sarvatt> acer disabled the lower brightness levels on some of the AUO panels in AOA150's because they flicker during hdd accesses
[05:22] <Sarvatt> i get over an hour longer on battery if i put up with the flicker :D
[05:23] <Sarvatt> how many brightness levels do you have now?
[05:23] <virtuald> :-O
[05:23] <virtuald> let's see
[05:23] <Sarvatt> there should be 9 steps if you go slow
[05:23] <Sarvatt> thats what i get with the gateway bios
[05:23] <virtuald> yes it's 9
[05:23] <Sarvatt> ah ok your LCD isn't blacklisted then
[05:24] <virtuald> :)
[05:24] <Sarvatt> i had 2 before
[05:29] <Sarvatt> bryceh: wow 44?
[05:30] <RAOF> Some are false-positive
[05:32] <RAOF> But that does seem a lot.
[05:33] <Sarvatt> one day this netbook will finish compiling mesa so I can move on to xserver.. :D
[05:34] <virtuald> hehe 
[05:38] <Sarvatt> virtuald: how big a battery do you have with yours? i get about 10 hours battery life with this 9 cell, definitely worth picking up :D
[05:39] <virtuald> the small one that came with it..
[05:40] <Sarvatt> think i paid around 40 bucks on ebay for the 9 cell, made this thing a billion times more useful
[05:40]  * RAOF has just got a 9 cell for his x200s in preparation for UDS travel.
[05:41] <virtuald> i can't find how long it takes to empty in gnome-power-statistics
[05:41] <virtuald> 8]
[05:42] <Sarvatt> i'm not sure i'll be going to UDS, thought I was supposed to hear something by the 26th about it
[05:42] <ScottK> Sarvatt: AFAIK no one has heard yet.  I think the 25th was the application deadline.
[05:43] <Sarvatt> RAOF: x200s is what you bought? thats not a netbook!
[05:43] <virtuald> is it the manic manatee?
[05:43] <virtuald> :>
[05:43] <Sarvatt> ahh thanks for the info ScottK, I must have misread it
[05:44] <RAOF> Sarvatt: No, the x200s is not a netbook.  It's too useful to be a netbook :)
[05:45] <Sarvatt> oh thats right, you did say the netbook had an atom :D
[05:45] <RAOF> Right. N270, where the 'N' stands for Not fast enough :)
[05:45] <Sarvatt> RAOF: do you have problems with that x200s? i've seen a lot of intel issues with them
[05:46] <RAOF> My hardware *always* magically avoids all the problems I'd like to debug.
[05:46] <Sarvatt> hey, it's only taken 30 minutes to compile dri with just swrast and i915 drivers!
[05:47] <Sarvatt> mklib: Making Linux shared library:  libEGL.so.1.0
[05:47] <Sarvatt> yay thanks for avoiding my explicit --disable-egl mesa!
[05:48] <virtuald> 8]
[11:29] <tjaalton> tseliot: good news, mesa 7.7.1 merged and will upload once it's accepted
[11:30] <tseliot> tjaalton: fantastic news, please let me know when it's uploaded so that I can refresh ia32-libs from canonical's computers
[11:30] <tjaalton> tseliot: sure thing
[11:31] <tseliot> thanks
[11:31] <AtomicSpark> Seems that ATI drivers are now out. They don't seem to support KMS. Less shiny plymouth splash is :(
[11:32] <tseliot> -ati does, fglrx doesn't
[11:33] <AtomicSpark> Does -ati support multiple displays?
[11:34] <tseliot> yes, of course
[11:43] <AtomicSpark> Oh great I broke it. Apparently display rotation makes fglrx flip out a bit.
[11:59] <AtomicSpark> Okay, now it's not doing it. Sillyness.
[12:38] <tjaalton> tseliot: no mesa tarball available yet, so I'll push it to the queue once it is
[13:23] <tseliot> tjaalton: ok, thanks
[16:58] <Sarvatt> huh.. #2  0x00ff6bf9 in DRI2GetScreen (pScreen=0xffffffff) at ../../../../hw/xfree86/dri2/dri2.c:78
[17:24] <jcristau> tjaalton: you can probably ask brice for the mesa tarball.  it's not world-readable in the upload queue.
[18:56] <apparle> hi guys plz help me with this https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/475466
[19:02] <Sarvatt> apparle: attach your dmesg output to the bug please
[19:03] <apparle> Sarvatt: I will have to make a bootable USB for it... I formatted the other one...
[19:04] <apparle> Sarvatt: the code seems alright... so why am I getting this problem.. 
[19:04] <Sarvatt> drm isn't loading right, need to see your dmesg
[19:07] <apparle> Sarvatt: no... the card is being detected as AGP.. where as it should be seen as PCI
[19:13] <Sarvatt> bryceh: ok so I fixed *clutter* apps closing crashing the server, but i'm still able to take down the server with the testcase. this commit stops quadrapassel from crashing the server on our 1.7.6 - http://sarvatt.com/downloads/patches/dri2-no-blit.patch
[19:14] <bryceh> Sarvatt, cool, where'd you find that?
[19:20] <apparle> what all cards come under CHIP_FAMILY_RS400 in radeon driver?
[19:21] <Sarvatt> apparle: you're using KMS on lucid, that xorg.conf option has no effect afaik. you need to pass radeon.agpmode=-1 for the same effect now and we'd really need to see your dmesg to see whats wrong in the first place
[19:21] <Sarvatt> apparle: or just boot with radeon.modeset=0
[19:22] <apparle> Sarvatt: you missed the point..... the bug was fixed and I didn't need the setting at all
[19:22] <Sarvatt> ok
[19:23] <apparle> Sarvatt: see here
[19:23] <apparle> Sarvatt: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/radeon_driver.c
[19:24] <apparle> Sarvatt: see the line no 2037,2038,2039
[19:25] <bryceh> Sarvatt, I'm adding the patch to xserver, but would like to know a bit more about how this solves the issue if you have any more info?
[19:28] <apparle> Sarvatt: so what all cards come under CHIP_FAMILY_RS400 in radeon driver?
[19:30] <bryceh> Sarvatt, I wonder if that patch doesn't stop the crashes but just avoids it or race-conditions it away
[19:45] <apparle> what's the nick of Tormod Volden
[20:33] <Sarvatt> bryceh: I wouldn't apply it just yet, no idea if it is sane.. sorry I have been testing it out between jobs and haven't been around to answer you or note it on the bug but I just commented on the fdo bug about it
[21:36] <BUG_vacations> evening