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