| Rocket2DMn | bryce, changed package to xorg and attached 2 files. it looks like a backtrace of some sort was included in the error log from the gdm folder, do you still need a full backtrace? | 00:00 |
|---|---|---|
| Rocket2DMn | ill go ahead and start one, but feel free to interrupt if its not needed | 00:00 |
| jcristau | a full backtrace from gdb is a lot more useful for debugging than what's in the log | 00:02 |
| Rocket2DMn | righto, getting the packages now | 00:02 |
| jcristau | the log mostly helps narrow down the issue somewhat, and link multiple reports of the same bug together | 00:04 |
| bryce | you'll need the dbg or dbgsym packages for each of the things mentioned in the X backtrace - xserver, hal, dbus | 00:09 |
| bryce | so far is looking like something input device related | 00:10 |
| Rocket2DMn | ok, but how do i get the laptop to suspend when in gdb | 00:12 |
| Rocket2DMn | i have a remote connection over ssh open | 00:12 |
| Rocket2DMn | should i then go back to the laptop and suspend it? | 00:12 |
| jcristau | that should work | 00:13 |
| Rocket2DMn | hmm i froze up the box | 00:13 |
| bryce | look at gdb | 00:13 |
| Rocket2DMn | yeah it broke | 00:14 |
| jcristau | hrm. keeping an ssh connection over suspend/resume isn't going to be easy.. | 00:17 |
| Rocket2DMn | the machine wont go to sleep while my ssh session is open | 00:18 |
| jcristau | in that case getting X to dump core will probably be easier than getting the trace in gdb | 00:18 |
| Rocket2DMn | this is locking up the system | 00:20 |
| bryce | eh, I wish libc provided a full-backtrace printing capability | 00:21 |
| bryce | Rocket2DMn: by chance does anything get saved to /var/crash/ ? | 00:21 |
| Rocket2DMn | im about to check there actually | 00:21 |
| jcristau | bryce: you want a libgdb? :) | 00:22 |
| Rocket2DMn | do i really need to do this gdb remotely? | 00:22 |
| bryce | jcristau: that would be sweet :-) | 00:22 |
| bryce | Rocket2DMn: not necessarily; sometimes you can do it from a console | 00:22 |
| jcristau | Rocket2DMn: not if you get X to dump core when it crashes | 00:22 |
| Rocket2DMn | nothing in /var/crash, let me try from tty1 | 00:23 |
| bryce | you may need to load the X binary and pass in X's args by hand (actually for debugging purposes you probably can skip most or all of the args) | 00:23 |
| jcristau | if you try it from tty1, type 'handle SIGUSR1 nostop' at the gdb prompt, otherwise you won't be able to vt switch | 00:25 |
| Rocket2DMn | ok well i guess i cant do anything when i have gdb running, im stack at the blank screen again | 00:25 |
| Rocket2DMn | lol no you tell me | 00:25 |
| Rocket2DMn | now* | 00:25 |
| Rocket2DMn | jcristau, do i type that before cont | 00:26 |
| jcristau | yeah | 00:26 |
| jcristau | i think running 'X -core', getting it to crash, and then looking into the core dump would be easier tho | 00:27 |
| Rocket2DMn | we'll try that next | 00:28 |
| Rocket2DMn | ok well i got it to suspend, but its not pulling out of standby, the power came back but the screen is black and i cant switch back to tty1 | 00:32 |
| Rocket2DMn | i can ssh in, is my tty1 session recoverable? | 00:33 |
| Rocket2DMn | maybe i should retry the whole thing in screen? | 00:34 |
| bryce | don't think you can recover tty's from ssh sessions afaik | 00:35 |
| jcristau | try 'chvt 1' in the ssh session then | 00:36 |
| Rocket2DMn | didnt think so, should i restart, do it all over, but from tty start screen, run gdb, detach, then trigger suspend? then pull out of standby and ssh and attach to screen? | 00:36 |
| jcristau | although, if X is crashed, gdb probably stopped it, so you can't vt switch.. | 00:36 |
| Rocket2DMn | jcristau, no go on that, sorry | 00:36 |
| jcristau | hmm. the screen trick could work. | 00:37 |
| Rocket2DMn | alright, i gotta reboot the box again, give me a few | 00:37 |
| bryce | I've never seen that done before, but it's a slick idea | 00:37 |
| bryce | (if it works) | 00:37 |
| bryce | at this point I usually end up just slapping in print statements around where I think the crash is happening | 00:38 |
| Rocket2DMn | if this works, im getting a beer | 00:38 |
| bryce | brb (booting with new glib) | 00:40 |
| bryce | yay | 00:41 |
| Rocket2DMn | oh man im in | 00:42 |
| Rocket2DMn | we have a segfault kids | 00:43 |
| bryce | sweet | 00:43 |
| Rocket2DMn | how do i pull all this out now is the question | 00:44 |
| Rocket2DMn | i think it's going to take up more than the screen | 00:44 |
| jcristau | set logging, in gdb | 00:45 |
| bryce | you can dump it to a log | 00:45 |
| Rocket2DMn | how | 00:45 |
| jcristau | or use screen logging, or whatever. | 00:46 |
| Rocket2DMn | ok, well im already in a screen session with gdb open, x crashed, i ran "backtrace full" and there were about 3 screens of text | 00:46 |
| Rocket2DMn | how do i grab all that and dump it to a file | 00:46 |
| bryce | set logging -- Set logging options | 00:47 |
| bryce | set logging file -- Set the current logfile | 00:47 |
| bryce | set logging off -- Disable logging | 00:47 |
| bryce | set logging on -- Enable logging | 00:47 |
| bryce | set logging overwrite -- Set whether logging overwrites or appends to the log file | 00:47 |
| bryce | set logging redirect -- Set the logging output mode | 00:47 |
| jcristau | 'set logging on; bt full' | 00:47 |
| Rocket2DMn | so set a file first, right? | 00:47 |
| jcristau | will log everything to gdb.txt | 00:47 |
| Rocket2DMn | ah ok | 00:47 |
| Rocket2DMn | ok guys, here is what we have - http://paste.ubuntu.com/102471/ | 00:50 |
| bryce | hot damn | 00:51 |
| Rocket2DMn | is that what we need? | 00:51 |
| bryce | yep, that's exactly it | 00:51 |
| bryce | I think I'm going to document your screen trick and name it the Imes Technique ;-) | 00:52 |
| Rocket2DMn | ill attach it to the report | 00:52 |
| Rocket2DMn | bryce, =D. ill explain on the bug report how i obtained the trace, in case anybody runs across it and needs to do something similar | 00:52 |
| bryce | that'd be wonderful, I'll copy it into our backtracing docs | 00:54 |
| jcristau | prevSpriteWin = pSprite->win; | 00:54 |
| jcristau | pSprite is NULL, boom. | 00:54 |
| bryce | bingo | 00:54 |
| jcristau | bryce: fdo#19176 | 00:56 |
| jcristau | looks like the same issue. fixed by e1a3a1a0d85c9971aea65c2228b5fd4dbf3bf57a | 00:57 |
| bryce | jcristau: cool | 01:02 |
| bryce | heh, what difference a bracket makes | 01:03 |
| Rocket2DMn | almost done with my explanation, lol | 01:03 |
| Rocket2DMn | this bug has already been fixed upstream? is that what im gathering? | 01:03 |
| jcristau | Rocket2DMn: correct | 01:04 |
| bryce | yep | 01:04 |
| jcristau | with a one-liner | 01:04 |
| bryce | worse, just a set of brackets ;-) | 01:04 |
| jcristau | yeah. | 01:05 |
| Rocket2DMn | ah, ive made worse errors in coding | 01:05 |
| bryce | great, I'll pull that patch in once I'm done with this gnome bug | 01:05 |
| Rocket2DMn | ok, i attached my backtrace to the bug report, i guess it can be marked as Fix Committed. It would be cool if you can add the upstream report | 01:06 |
| bryce | Rocket2DMn: sure I'll take care of doing that, thanks for doing such a thorough job on triaging this! | 01:06 |
| Rocket2DMn | no prob, learned a bit in the process | 01:06 |
| bryce | and of course thanks jcristau for locating the patch | 01:06 |
| Rocket2DMn | indeed, thanks for helping out jcristau , and bryce :) | 01:07 |
| bryce | Rocket2DMn: then I hope you run into more X bugs :-) (ducks) | 01:07 |
| Rocket2DMn | haha, i used to be able to troubleshoot X decently from xorg.conf, then all this autodetection took over | 01:07 |
| bryce | Rocket2DMn: yeah, sometimes it can be a pain for troubleshooting issues, however on the other hand it eliminated having to help people figure out their h/v sync ranges, which was sort of a PITA (glad I mostly missed those days) | 01:33 |
| bryce | Rocket2DMn: btw if you're interested in helping in triaging X crash issues and walking people through the steps you've done, I think you could help us sort out a lot of X problems. | 01:35 |
| Rocket2DMn | sure bryce , holding down a real job limits my time to evenings | 01:49 |
| Rocket2DMn | wish i could do Ubuntu stuff all day though | 01:49 |
| Rocket2DMn | and i think youd all be glad to know, my beer glass here says "#include <beer.h>" on the side | 01:51 |
| bryce | :-) | 01:51 |
| bryce | cool, even sorting out just one or two of these crashes a week can make a big difference in stabilizing X | 01:51 |
| Rocket2DMn | yeah ill keep it in mind when i make my way through the new bug listings when i get to them a couple of times a week | 01:52 |
| Rocket2DMn | most of my time ends up going to the forums, and some wiki documentation ocassionally | 01:52 |
| * bryce nods | 01:53 | |
| bryce | just explaining to people how to get full backtraces can make a huge difference, whether in the bug tracker, forums, or whereever | 01:53 |
| bryce | as you saw, once we get a full backtrace, figuring out a solution often takes an X dev a few minutes | 01:54 |
| Rocket2DMn | yeah, people on the forums dont deal with bugs very much, except for the Development Testing area | 01:54 |
| Rocket2DMn | some of us are working to integrate bugs better into that part of the community, but tbh they are mostly beginners who want nothing to do with them | 01:54 |
| * bryce nods | 01:55 | |
| Rocket2DMn | i'm going to update my bug filing guide to include ubuntu-bug program at brian's request, http://ubuntuforums.org/showthread.php?t=1011078 | 01:55 |
| Rocket2DMn | forums were down a lot today, so i ended up doing the X thing instead of that | 01:55 |
| bryce | yeah even just reporting a bug requires some basic level of technical aptitude that not all users are ready to undergo | 01:55 |
| bryce | hehe | 01:55 |
| Rocket2DMn | X is even worse for beginners to handle because they don't ever want to see a terminal or tty, esp with no GUI behind it | 01:56 |
| Rocket2DMn | unfortunately the restricted drivers continue to be one of the major issues with new users, even almost 2 years now after i started with Ubuntu | 01:57 |
| Rocket2DMn | I have a silly question for you, what's the difference between xorg and xorg-server? should most bugs be against xorg-server? | 02:00 |
| jcristau | xorg is a set of metapackages, mostly | 02:01 |
| Rocket2DMn | thought that might be the case | 02:01 |
| jcristau | so yeah, most bugs should be against the server or one of the drivers | 02:01 |
| Rocket2DMn | i'll keep that in mind, thank you | 02:01 |
| bryce | it's okay to file against xorg; we routinely thumb through those and refile them to the appropriate product, but yeah nearly all bugs actually go against xorg-server or one of the drivers | 02:12 |
| * Rocket2DMn takes notes | 02:12 | |
| bryce | most people won't know what product to file against, so we don't make a big deal about it if someone just files against xorg (in fact we encourage doing so if there's ever any doubt), but it does add some delay to getting your bug reviewed | 02:13 |
| Rocket2DMn | i was looking at the bugs for ubuntu-x-swat, they are almost all being handled | 02:14 |
| Rocket2DMn | that's pretty impressive | 02:15 |
| bryce | well, actually we don't assign or subscribe bugs to ubuntu-x-swat anymore, so anything still there is going to be a fairly old bug | 02:16 |
| Rocket2DMn | yeah i noticed that, too | 02:16 |
| Rocket2DMn | is there another team that gets alerted of X bugs? | 02:16 |
| bryce | not really | 02:17 |
| bryce | joining ubuntu-x-swat gains you a feed of all the bugs | 02:18 |
| bryce | I've got several automated scripts that filter through new bugs, and bubble up ones ready for analysis (basically bugs set to Confirmed are ready to be investigated) | 02:20 |
| Rocket2DMn | bug 314838 looks pretty ripe for a backtrace | 02:21 |
| ubottu | Launchpad bug 314838 in xorg "crash of xorg after vlc starts to play some movie" [Undecided,New] https://launchpad.net/bugs/314838 | 02:21 |
| Rocket2DMn | ill bookmark it for later though, i'm really tired | 02:22 |
| Rocket2DMn | I'll see you guys later, thanks for your help tonight with my bug, glad to know a fix is already on the way! | 02:24 |
| bryce | cya! thanks again | 02:24 |
| bryce | tjaalton: help! | 02:36 |
| bryce | $ git add 155_no_checkmotion_for_disabled_devices.patch | 02:36 |
| bryce | The following paths are ignored by one of your .gitignore files: | 02:36 |
| bryce | debian/patches/155_no_checkmotion_for_disabled_devices.patch | 02:36 |
| bryce | Use -f if you really want to add them. | 02:36 |
| bryce | fatal: no files added | 02:36 |
| bryce | *.patch is listed in .gitignore ? | 02:36 |
| jcristau | likely. | 02:39 |
| jcristau | that makes sense upstream. not so much for us :) | 02:39 |
| bryce | hrm | 02:45 |
| bryce | jcristau: so should I -f it, or remove the *.patch from .gitignore in the ubuntu branch? | 02:45 |
| jcristau | i'd use -f | 02:46 |
| bryce | dpkg-source: error: cannot represent change to xorg-server-ubuntu-git/hw/xquartz/bundle/Resources/English.lproj/main.nib/keyedobjects.nib: binary file contents changed | 02:58 |
| bryce | hrm, seems ubuntu git maybe isn't in a buildable state at the moment | 03:00 |
| jcristau | yeah. timo mentioned that, apparently some binary files have been modified upstream, so they're not the same as in the tarball | 03:01 |
| bryce | okay | 03:01 |
| bryce | well, patch applies fine and I'd be surprised if there were any build issues; I've pushed it up | 03:02 |
| bryce | can't build locally either... | 03:02 |
| bryce | dpkg-checkbuilddeps: Unmet build dependencies: x11proto-dri2-dev (>= 1.99.3) libxv-dev | 03:02 |
| jcristau | that's just a matter of installing them, no? | 03:04 |
| bryce | ah, right | 05:50 |
| bryce | sweet, we're below 1900 bugs :-) | 06:12 |
| bryce | and that doesn't include about 100 -intel bugs with no response that probably could be expired but that I'll give another week or two for responses | 06:14 |
| tjaalton | bryce: yes, that's why we are still stuck with beta3 | 07:17 |
| bryce | heya tjaalton | 07:19 |
| tjaalton | bryce: howdy | 07:22 |
| bryce | ok no prob, I stuck a little cherrypick patch in there for when it's ready | 07:23 |
| tjaalton | hmm redhat hired a nouveau developer.. interesting | 07:29 |
| tjaalton | wonder if there'll be a release sometime :) | 07:30 |
| crevette | hello, good morning | 07:33 |
| bryce | heya crevette | 07:34 |
| === james_w` is now known as james_w | ||
| superm1 | bryce, i've got some hardware that I just got that again won't boot in vesa for intrepid, but does for hardy. NV doesn't yet support it yet. I can still make recommendations to that platform team for any enhancements necessary in the hardware, BIOS, or VBIOS to make it work, so can you look at the errors starting up with vesa to see if you had any suggestions that I could tell them? bug 315588 | 18:33 |
| ubottu | Launchpad bug 315588 in xserver-xorg-video-vesa "Hardware w/ 1600x900 LCD does not boot up using vesa" [Undecided,New] https://launchpad.net/bugs/315588 | 18:33 |
| superm1 | (also doesn't boot vesa in jaunty) | 18:33 |
| === ubott2 is now known as ubottu | ||
| bryce | superm1: looking | 19:58 |
| bryce | superm1: will comment on the bug | 19:58 |
| superm1 | bryce, thanks, i'll pass it on to the ODM then | 20:02 |
| bryce | (WW) VESA(0): Unknown vendor-specific block 0 | 20:05 |
| bryce | mm haven't seen that before | 20:05 |
| bryce | superm1: can you also post the xorg.conf you used for those logs? | 20:06 |
| bryce | (basically, I want to know if you specified any h/v sync ranges for either case) | 20:07 |
| superm1 | bryce, it's basic live cd xorg log | 20:10 |
| superm1 | bryce, so nothing special in terms of anything i specified | 20:10 |
| === halfline is now known as krh | ||
| === krh is now known as halfline | ||
| === halfline is now known as krh | ||
| === krh is now known as halfline | ||
| tjaalton | http://ubuntuforums.org/showthread.php?t=1034377 | 22:17 |
| tjaalton | an excellent thread, great fun :) | 22:17 |
| tjaalton | well, at least the sixth post | 22:18 |
| tjaalton | oh, gets better on the third page | 22:30 |
| bryce | he's complaining that the X api changed in the development release of jaunty?? | 22:39 |
| tjaalton | yep | 22:39 |
| superm1 | what happens in the event that the new API isn't stable by the time jaunty goes out though? I've got a bad feeling these vendors won't want to rev their drivers on an unstable api.. | 22:47 |
| tjaalton | what do you mean unstable? it hasn't changed in months | 22:48 |
| superm1 | well is there a formal X release with the new API though, or is it all operating off git snapshots right now? | 22:49 |
| tjaalton | 1.6 should be out soon, it should be finalized by then at least | 22:49 |
| tjaalton | xserver is all you need, not the whole stack | 22:49 |
| superm1 | right... but i'm saying in the hypothetical situation that 1.6 isn't released soon, and get delayed until say a month after jaunty releases | 22:50 |
| superm1 | you know release dates slip etc | 22:51 |
| tjaalton | in that case yes, they lose | 22:52 |
| tjaalton | but it's not likely | 22:52 |
| tjaalton | ..that the release is delayed that much | 22:52 |
| superm1 | ;) | 22:53 |
| bryce | I've a call with nVidia next week, I'll raise the issue | 22:53 |
| tjaalton | today there has been 34 commits to the 1.6-branch | 22:54 |
| tjaalton | so a new rc could be out next week | 22:54 |
| bryce | however I already notified them of the pending X version before christmas and encouraged adding support for it, and gave dates and such | 22:54 |
| tjaalton | nvidia should be well aware of the ABI changes, since aplattner is quite active in the community | 22:56 |
| superm1 | from my experience with them (at least the guys i've worked with), it's good to stay on top of things and ask for updates so they dont fall through the cracks | 22:56 |
| tjaalton | wonder why they had support for 1.5 for months before the release | 22:57 |
| tjaalton | superm1: did you notice bug 315632? | 23:12 |
| ubottu | Launchpad bug 315632 in nvidia-graphics-drivers-180 "upgrade from 180.11 broken (trying to overwrite `/usr/lib32/libvdpau.so.1', which is also in package nvidia-glx-180)" [Undecided,New] https://launchpad.net/bugs/315632 | 23:12 |
| superm1 | tjaalton, <shrug> no, but i think that means it needs replaces then doesn't it? | 23:18 |
| superm1 | not necessarily conflicts though | 23:18 |
| superm1 | it's still in NEW, which is probably why no other reports have been made of it yet | 23:19 |
| tjaalton | ah, that's good so it can be fixed | 23:20 |
| tjaalton | yes, replaces should be enough I guess | 23:20 |
| superm1 | okay i'll do a quick tweak to it then | 23:20 |
| tjaalton | great, thanks | 23:21 |
| bryce | too bad users can't mark their own bugs as Wishlist | 23:23 |
| bryce | most of the bugs where people are unhappy about the automated triaging tools are because they're wishlist things | 23:24 |
| bryce | which obviously don't require Xorg.0.log and the like, but hard to distinguish those from regular bugs mechanically | 23:24 |
| tjaalton | heh | 23:25 |
| bryce | however, out of 250 bugs or so changed last night, so far I've only seen 4 complaints of wrong triaging | 23:36 |
| bryce | "currently i don't have this problem except i think mesa, drm, and the | 23:41 |
| bryce | intel driver need some more work in general." | 23:41 |
| bryce | heh | 23:41 |
| tjaalton | clearly warrants a bug ;) | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!