| Sarvatt | tormod: the -dbgsym package works -dbg has the wrong CRC | 00:09 |
|---|---|---|
| Sarvatt | debug_file: /usr/lib/debug/usr/lib/dri/savage_dri.so has CRC of B4300B09 | 00:09 |
| Sarvatt | actual_file: /usr/lib/dri/savage_dri.so thinks CRC should be B4300B09 | 00:09 |
| Sarvatt | (after purging dbg and installing dbgsym) | 00:09 |
| Sarvatt | bryceh: has this been the craziest week for bugs or what? :D | 00:35 |
| Sarvatt | wowsa, my VPS moved to a new datacenter and they put me on a 8 core xeon instead of the slow dual core opteron I had before, time to build some kernels! | 00:38 |
| bryceh | Sarvatt, has it? sadly it seems rather pedestrian compared with some releases | 00:38 |
| bryceh | always the last few weeks before release get kind of crazy | 00:38 |
| bryceh | I'm actually a bit optimistic that 8xx is our only big worry at the moment | 00:38 |
| Sarvatt | ati and nouveau are in nasty shape, we've got <NV50 nouveau's reporting phantom TV connectors a lot of the time coupled with the fact plymouth is broken on nouveau with >1 output, there are quite a few ati generations with issues like rn50 with a tdms hooked up that refuses to start that i just found out about this morning (nasty because thats a *very* popular server chipset), and tons of reports about screwed up multihead issues on other ati. K | 00:56 |
| Sarvatt | MS should have been disabled on the server kernels for sure. then there's the flickering lenovo and people with switchable GPU's using the intel side are getting, I wasn't able to work out a way to use failsafe easily because the initramfs-tools blacklists were getting ignored after a certain point in the boot and KMS was loading anyway. clutter 1.2 is HORRIBLY slow on intel without xserver 1.8 because of the GLX swap method its using | 00:56 |
| * bryceh holds hands over ears, shuts eyes, and 'lalalala's | 01:00 | |
| bryceh | honestly though, all those issues seem bad but we've had releases that were much worse | 01:01 |
| bryceh | or at least seemed much worse | 01:01 |
| bryceh | I'm sure jcristau is sitting over there laughing at us for sucking so bad ;-) | 01:02 |
| Sarvatt | i think we're going to set a record for the number of complaints that the livecd wont even start up this release :) | 01:05 |
| bryceh | Sarvatt, I dunno | 01:07 |
| bryceh | I can see that possibly with -nouveau, but even -nv tended to suck pretty hard in that regard | 01:07 |
| bryceh | -ati and -intel seem to be pretty solid in my own testing | 01:07 |
| bjsnider | but clutter isn't going to be used as much because gnome-shell isn't the default yet, so that intel issue isn't too bad | 01:20 |
| RAOF | Sarvatt: I thought I was pretty on top of the nouveau bugs, and I can't recall a lot of phantom TV problems. We could pick up Fedora's patch to quirk that off if there's a widespread problem. | 01:34 |
| RAOF | Sarvatt: I think the problem where the blacklist gets ignored is that the blacklist only prevents the module being autoloaded, which it does, but then X starts up and the DDX specifically requests it's kernel module, which exists, and so gets loaded. | 01:36 |
| Sarvatt | wish it was that easy, it was getting loaded by plymouth :( | 01:41 |
| Sarvatt | https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/539655 | 01:41 |
| ubottu | Launchpad bug 539655 in linux "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini" [High,Triaged] | 01:41 |
| Sarvatt | https://bugs.edge.launchpad.net/bugs/533135 | 01:41 |
| ubottu | Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged] | 01:41 |
| RAOF | Oh, balls. Because plymouth has a drm backend, which will be doing the same thing. | 01:41 |
| Sarvatt | yeah i tried adding a new check in plymouth for the extra command line option i added to not load but didnt have any luck | 01:42 |
| Sarvatt | ahhh that second bug wasnt filed against nouveau, no wonder | 01:44 |
| RAOF | Neither was the first bug. I'm well aware of the plymouth bug, though, because I've been duping lots of nouveau bugs against in. | 01:45 |
| RAOF | s/in./it./ | 01:45 |
| Sarvatt | oh nice - http://lists.freedesktop.org/archives/nouveau/2010-April/005576.html | 01:51 |
| RAOF | A little bit late, but yeah. I've been watching that. | 01:55 |
| RAOF | HURRAY! At least the macbook pro noaccel quirk seems to be working as planned. | 02:29 |
| bryceh | RAOF, Sarvatt, hey this is probably the last chance we have to toss in patches without doing paperwork... are there any patches on your radars that you'd like to have me upload? | 02:38 |
| bryceh | I'm about to head over to my mom's to help with some stuff but have a few minutes | 02:39 |
| RAOF | Are you taking care of vesa-on-855-845? That's the change on my current radar. | 02:40 |
| bryceh | that one I think will be worth doing the paperwork on, so I'm ok waiting a couple days there | 02:43 |
| bryceh | should be an easy patch, but I want to see how the no-kms / no-dri changes shake out before going that route | 02:43 |
| RAOF | That's reasonable. | 02:43 |
| Sarvatt | bryceh: none that I can think of unfortunately | 02:45 |
| bryceh | Sarvatt, I still have on my todo list to look at that redhat patch to rejigger how lvds modesetting works, just haven't had time to dig into it | 02:45 |
| bryceh | might look at it when I get back tonight or tomorrow morning if there's time | 02:46 |
| Sarvatt | bryceh: OpenBSD backported quite alot to intel 2.9.1 since they have GEM but no KMS now but I haven't been able to dig up a link yet | 02:47 |
| Sarvatt | might be worth looking over | 02:47 |
| Sarvatt | yeah looks like its not public yet, darn | 02:48 |
| Sarvatt | i was asking if it'd be possible to push it straight to 2.9 branch so everyone could collaborate and send along the commits we are backporting on it but didn't get a response | 02:50 |
| bryceh | mm | 02:51 |
| Sarvatt | ahh found a tarball at least - http://old.nabble.com/New-intel-X-driver-requires-testing.-td28210444.html | 02:52 |
| bryceh | alright, I have a few minor cherrypicks from xserver upstream which I'll upload later tonight | 02:56 |
| Sarvatt | going to take a year to compare it from the tarball :D | 02:56 |
| bryceh | heh, yeah | 02:57 |
| Sarvatt | http://sarvatt.com/downloads/patches/openbsd2.9.1.patch | 03:33 |
| Sarvatt | thats a huge patch | 03:33 |
| RAOF | You're sure that's not just an entirely new driver which happens to share some filenames? :) | 03:35 |
| vish | Sarvatt: nope , I'm using ATI , and another mac Lucid user also has same problem | 05:39 |
| RAOF | Has anyone figured out why Xorg seems to prefer vesa over any of the other fallback drivers we've got set? | 07:35 |
| bryceh | RAOF, don't think so | 07:39 |
| bryceh | RAOF, worth studying for meerkat tho | 07:39 |
| RAOF | Man, I wish evolution wasn't such a memory hog. | 07:44 |
| tjaalton | RAOF: got a logfile? | 07:49 |
| RAOF | tjaalton: Of Xorg picking the wrong fallback? Yeah, many. http://launchpadlibrarian.net/43695726/XorgLog.txt is a fine example. | 07:51 |
| tjaalton | right, should use fbdev | 07:51 |
| RAOF | nouveau loads, nv loads, vesa loads, fbdev loads... nouveau bails, vesa picks it up. | 07:51 |
| tjaalton | but how did that work before? that part was not changed aiui | 07:51 |
| tjaalton | i mean, how should it know to load fbdev instead of vesa? | 07:52 |
| RAOF | No, it should try nv before vesa. | 07:52 |
| tjaalton | oh | 07:52 |
| RAOF | I don't think we've ever really tested “I'd like driver A, then if driver A fails try driver B, then fallback to vesa or whatever” before. | 07:53 |
| RAOF | As far as I know, it's always been “try the driver that should work, or vesa if it doesn't” | 07:53 |
| tjaalton | does this case have xorg.conf? | 07:54 |
| RAOF | No. | 07:54 |
| tjaalton | ok | 07:54 |
| RAOF | If it had xorg.conf X wouldn't be trying to fallback at all, would it? | 07:54 |
| tjaalton | not true anymore | 07:54 |
| RAOF | It'd try the driver specified, then bail? That's the behaviour I remember? | 07:54 |
| tjaalton | since -2u1 | 07:55 |
| RAOF | Ah. With xorg.conf.d? | 07:55 |
| tjaalton | no, the patch from suse (merged in 1.8) | 07:55 |
| tjaalton | which allows us to use xorg.conf.d & inputclass.. | 07:55 |
| RAOF | Ok. That seems a better behaviour, yes. | 07:56 |
| tjaalton | maybe something to ask rüdiger.. | 07:59 |
| tjaalton | RAOF: seeing what happens with beta1 would be interesting too, to confirm if this is a regression or a bug in nv | 08:05 |
| RAOF | I *think* this has been consistent throughout lucid… I wonder if I've got a beta 1 livecd handy? | 08:06 |
| tjaalton | hm, cdimage.u.c doesn't have it | 08:07 |
| tjaalton | though it should be enough to build the previous xserver version and start with that | 08:08 |
| tjaalton | or comment out the patches | 08:08 |
| RAOF | Of course. Hurray for packaging-in-vcs. | 08:08 |
| tjaalton | indeed :) | 08:08 |
| tjaalton | speaking of which, bryceh: please push mesa to git | 08:10 |
| bryceh | tjaalton, done | 08:26 |
| tjaalton | bryceh: thanks | 08:27 |
| tjaalton | fyi, I'm merging a couple of patches from upstream to allow adding stuff in /etc/X11/xorg.conf.d as well | 08:28 |
| tjaalton | first in debian | 08:28 |
| tjaalton | now if you do that the system dir is bypassed, breaking things.. | 08:28 |
| tjaalton | the downside is that the conf snippets would move to /usr/share/X11/xorg.conf.d, but that can be done with Breaks and bumping the serverminver | 08:29 |
| bryceh | tjaalton, getting a bit late for such changes, no? | 08:36 |
| tjaalton | bryceh: yes | 08:36 |
| tjaalton | but it's basically a bugfix | 08:36 |
| tjaalton | pointed out on the ffe | 08:36 |
| bryceh | looks like uploads are now being blocked and require archive admin approval to get in | 08:36 |
| tjaalton | already? | 08:37 |
| tjaalton | well, that doesn't mateer | 08:37 |
| tjaalton | *matter | 08:37 |
| bryceh | subject: [ubuntu/lucid] xorg-server 2:1.7.6-2ubuntu4 (Waiting for approval) | 08:37 |
| tjaalton | ok | 08:38 |
| bryceh | hi seb128 | 08:39 |
| seb128 | hey bryceh | 08:39 |
| bryceh | tjaalton, any thoughts on these two patches? | 08:40 |
| bryceh | make lvds modesetting more robust (upstreamed for 2.11, still applies to 2.9.1) | 08:40 |
| bryceh | http://cvs.fedoraproject.org/viewvc/F-12/xorg-x11-drv-intel/lvds-modes.patch?revision=1.2&content-type=text%2Fplain&view=co | 08:40 |
| bryceh | ati: | 08:40 |
| bryceh | Fix default mode setup for invalid edid's | 08:40 |
| bryceh | http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-drv-ati/radeon-6.12.2-lvds-default-modes.patch?view=markup | 08:40 |
| tjaalton | bryceh: 2.11.0 is released, does it have that? | 08:44 |
| tjaalton | looks like it | 08:45 |
| tjaalton | http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=7d0e6ff4dadcf243b1006ce6f85bd06c5f4e4908 | 08:45 |
| tjaalton | surprised that the ati one isn't upstream | 08:46 |
| RAOF | That looks like sound reasoning on the ati patch. | 08:46 |
| tjaalton | heh | 08:46 |
| tjaalton | maybe it's less useful with ati kms | 08:46 |
| tjaalton | ? | 08:46 |
| RAOF | Maybe. IIUC the DDX should be able to bend kms to its will - adding modes, etc. | 08:48 |
| RAOF | So while your boot -> X experience would be of an undriven display, once X started you'd get a suboptimal mode, but at least you'd get something. | 08:49 |
| tjaalton | ok | 08:51 |
| RAOF | I'm not sure if that's what the patch would *do*, but it's certainly possible. Userspace can definitely add modes (at least for nouveau; I haven't tested radeon). I can do so via xrandr. | 08:53 |
| tjaalton | right, different from setting the initial mode | 08:56 |
| tjaalton | bryceh: err, patch 115 is garbage | 09:07 |
| tjaalton | html | 09:07 |
| tjaalton | well, all of the new ones are | 09:08 |
| tjaalton | git show ftw | 09:08 |
| tjaalton | and having the upstream remote to make that work | 09:08 |
| bryceh | bleah, I fixed that in the upload | 09:20 |
| tjaalton | ah, good :) | 09:21 |
| bryceh | this whole thing of using git for maintaining the packaging is like the most irritating thing to me | 09:21 |
| tjaalton | bzr is no different | 09:22 |
| tjaalton | or any other dvcs | 09:22 |
| bryceh | well it's not like we actually *use* the vcs | 09:23 |
| bryceh | we still have each of the patches done in quilt, so it's sort of like we're using one vcs inside another | 09:23 |
| RAOF | I think that's silly, yes. | 09:23 |
| seb128 | how would you want to do it otherwise? | 09:24 |
| tjaalton | it would quickly become a mess | 09:24 |
| bryceh | I mean it's like washing the dishes before putting them in the dishwasher | 09:24 |
| tjaalton | though upstream patches from the branch we're following should be fine to cherry-pick as is | 09:25 |
| seb128 | the only issue is quilt, would be much nicer if dpatch or simple-patchsys was used ;-) | 09:27 |
| tjaalton | bah | 09:27 |
| tjaalton | quilt is fine | 09:27 |
| seb128 | I hate it | 09:27 |
| tjaalton | i hate dpatch, so here we go :) | 09:27 |
| seb128 | it's so annoying to use and slow and getting in your way | 09:27 |
| seb128 | I always forget to quilt add | 09:27 |
| seb128 | do my changes | 09:28 |
| RAOF | Yeah. That part is weird. | 09:28 |
| seb128 | and go "ups", need to scratch the whole dir and start again | 09:28 |
| seb128 | I'm probably too stupid to use it | 09:28 |
| tjaalton | or just do your stuff, git diff > foo.diff and add it to series | 09:28 |
| seb128 | that's what I tend to do | 09:28 |
| seb128 | so you don't use quilt :-p | 09:28 |
| tjaalton | unless it interferes with other patches, of course | 09:28 |
| seb128 | I can do that with simple-patchsys too | 09:28 |
| bryceh | seb128, that's pretty much what I do too. | 09:29 |
| seb128 | I tend to quilt push the change before the one I want to edit | 09:29 |
| seb128 | and then copy the dir | 09:29 |
| seb128 | do my change | 09:29 |
| seb128 | and diff | 09:29 |
| seb128 | not to mention you have to export QUILT_PATCHES to be able to edit a patch | 09:31 |
| tjaalton | that's in .quiltrc already ;) | 09:31 |
| seb128 | it shows how much the thing is meant to be used to do packaging, if you don't export environment variables you need to know about it doesn't work | 09:31 |
| seb128 | way to lower the work to start contributing | 09:32 |
| seb128 | anyway enough rant on quilt ;-) | 09:32 |
| tjaalton | bryceh: funny how your commits show as merges while there were no changes to be merged, it should've been a direct push | 09:36 |
| tjaalton | and conflicts in changelog | 09:36 |
| bryceh | it's because of asac's commit | 09:37 |
| tjaalton | no I already had that | 09:38 |
| bryceh | I didn't | 09:38 |
| tjaalton | these were after your latest push | 09:38 |
| tjaalton | oh | 09:38 |
| tjaalton | well always git pull before you start :) | 09:38 |
| bryceh | see, now... | 09:38 |
| bryceh | #insert git rant #14 | 09:39 |
| tjaalton | s/git/$DVCS/? | 09:39 |
| bryceh | tools should *save* you work, not add extra steps for no real value | 09:39 |
| tjaalton | oh there's valuea | 09:40 |
| tjaalton | -a | 09:40 |
| Ng | rebase \o/ | 09:40 |
| tjaalton | now I should get that release from the queue to work on it | 09:40 |
| tjaalton | if it wasn't behind dvcs | 09:40 |
| bryceh | tjaalton, you'd have to remind me what the value was | 09:42 |
| bryceh | for me it's mostly just making me feel like an asshole for not pulling and pushing all the time | 09:43 |
| tjaalton | bryceh: it's a team effort, no other way around it | 09:43 |
| bryceh | tjaalton, yeah and I suck it up and do the git stuff, I still see no value in it | 09:45 |
| tjaalton | so it would be better to just have the archive as the version storage? | 09:45 |
| tjaalton | and do apt-get source; <stuff>; dput? | 09:46 |
| bryceh | yep | 09:46 |
| tjaalton | hrm :) | 09:46 |
| tjaalton | that's probably fine for a one-man-team :) | 09:46 |
| bryceh | well it's not like we do a huge amount of development on the packages | 09:46 |
| RAOF | If we replace that with $VCS $BRANCH ; <stuff> ; $VCS $PUSH (as source-package-branches is moving to?) | 09:47 |
| bryceh | tjaalton, well a lot of packages are basically just that | 09:47 |
| bryceh | tjaalton, or maybe one person does the merge, and another person does most of the patch work until the next merge | 09:48 |
| tjaalton | and I'd rather not do a merge by hand | 09:48 |
| tjaalton | anymore | 09:48 |
| bryceh | and doesn't it seem like on the packages where we *do* work together that we're constantly having to either bug someone to push a commit, or doing it for them? | 09:48 |
| tjaalton | things just move too fast | 09:49 |
| tjaalton | like having several uploads of the same package on the same day... | 09:50 |
| tjaalton | having to merge the changes of an upload or a few per release is a price i'm willing to pay | 09:51 |
| tjaalton | it's only a few minutes of work | 09:52 |
| mvo | seb128: edit-patch! | 09:56 |
| seb128 | mvo, ;-) | 09:57 |
| seb128 | I need to try that one day | 09:57 |
| mvo | if you hate quilt, try it next time you need to do somethingwith quilt | 09:57 |
| mvo | it should just work | 09:57 |
| mvo | (unless there are bugs of course ;) | 09:57 |
| seb128 | cool | 09:57 |
| seb128 | I know who to bug about bugs :p | 09:57 |
| mvo | hehehe | 10:00 |
| mvo | and it inegrates with $vcs of choice, so no more "ups, forget to bzr/git add that one" | 10:00 |
| Dr_Jakob | Anyway I can get the Lucid installer to either not try to update itself or get it to use a proxy to do it. | 10:51 |
| bryceh | Dr_Jakob, sure you have the right channel? | 10:56 |
| Dr_Jakob | Heh, sorry. | 10:56 |
| mvo | tseliot: hm, I got three warnings via debconf that I should install nvidia-current on my system (lucid -> lucid upgrade) | 14:06 |
| tseliot | mvo: one for nvidia-common, one for the kernel and one for the headers, I guess | 14:07 |
| mvo | probably | 14:07 |
| mvo | I assume the releae upgrader will deal with that automatically via the nvidia-common import and the nvidia.old_drivers check? | 14:08 |
| mvo | tseliot: or is there additional code needed? | 14:08 |
| tseliot | mvo: yes, update-manager should deal with that, therefore we should not get those warnings in a dist-upgrade from u-m. You would still be bugged if you updated from the command line though | 14:09 |
| tseliot | mvo: assuming that what I remember about update-manager is correct | 14:10 |
| Sarvatt | Dr_Jakob: you were right btw, archive -dbg packages for mesa and xserver are screwed up, the -dbgsym packages all work though | 14:28 |
| Dr_Jakob | Sarvatt: ah ok | 14:29 |
| Sarvatt | I was using everything from a PPA and they strip them differently there so they worked | 14:29 |
| Dr_Jakob | Heh okay | 14:30 |
| Dr_Jakob | Do I need to switch to PPA or have never versions been uploaded? | 14:30 |
| Dr_Jakob | well for me me the dbgsym packages where empty.. | 14:30 |
| Sarvatt | just purge the -dbg and -dbgsym packages you might have installed and reinstall just the -dbgsym | 14:30 |
| Sarvatt | no reboots or anything needed that I was saying before | 14:31 |
| Sarvatt | its just X related packages it looks like | 14:32 |
| Sarvatt | http://sarvatt.com/downloads/dbgsym.py -- if you run that with say ./dbgsym.py /usr/bin/Xorg it'll tell you every dbg package with wrong CRC's | 14:34 |
| seb128 | Sarvatt, oh, handy | 14:35 |
| Sarvatt | well every file in /usr/lib/debug/ with wrong CRC's that is | 14:35 |
| Sarvatt | i need to file a bug about this, trying to find packages that have -dbg that work right to compare the build rules | 14:36 |
| seb128 | Sarvatt, it assumes rpm though?! | 14:36 |
| seb128 | dpkg_output = commands.getoutput("rpm -qf "+debug_file) | 14:36 |
| Dr_Jakob | Reading symbols from /usr/lib/xorg/modules/libvgahw.so...Reading symbols from /usr/lib/debug/usr/lib/xorg/modules/libvgahw.so...(no debugging symbols found)...done. | 14:37 |
| Sarvatt | thats just for one of the command line options | 14:37 |
| Dr_Jakob | Need to get 7,972B of archives. | 14:37 |
| Dr_Jakob | After this operation, 164kB of additional disk space will be used. | 14:37 |
| Dr_Jakob | dbgsym is still "empty" | 14:37 |
| Sarvatt | you did a sudo apt-get purge xserver-xorg-core-dbg xserver-xorg-core-dbgsym first? | 14:38 |
| Dr_Jakob | dbgsym wasn't installed | 14:38 |
| Dr_Jakob | and I removed -dbg before. | 14:38 |
| Sarvatt | ok I'm sorry, I swear I tested that last night | 14:38 |
| Sarvatt | dh_strip -pxserver-xorg-core --dbg-package=xserver-xorg-core-dbg | 14:39 |
| Sarvatt | dh_strip -s --remaining-packages | 14:39 |
| Sarvatt | hmm | 14:39 |
| === starshiptrooper is now known as apachelogger | ||
| Dr_Jakob | Sarvatt: sorry to ask this but do you have a ETA on when the issue would be resolved? | 15:19 |
| Dr_Jakob | Or should I just compile X by hand or switch to PPA? | 15:19 |
| herman_ | hi how can I adjust the contrast of my lcd notebook, my video is an intel X4500 | 15:28 |
| herman_ | is there some software that i can do that? | 15:31 |
| Sarvatt | bryceh: did you see xorg-server 2:1.7.6-2ubuntu4 failed to build because of 115 still? | 16:04 |
| Sarvatt | Dr_Jakob: no idea on an ETA unfortunately, compiling by hand will definitely work for now, just apt-get source xorg-server, cd xorg-server-foo, sudo apt-get build-dep xorg-server then debuild -uc -us -b | 16:06 |
| Dr_Jakob | ok thanks | 16:07 |
| Sarvatt | sorry about that :( i'll let you know as soon as its fixed | 16:12 |
| Dr_Jakob | Right thanks. | 16:13 |
| Dr_Jakob | I can image things are hectic right now. | 16:13 |
| Dr_Jakob | Errm, it doesn't build due to what I assume is patch 115? | 16:14 |
| Dr_Jakob | "Patch 115_xext_fix_cursor_ref_counting.patch does not apply (enforce with -f)" | 16:14 |
| jcristau | kill it from debian/patches/series | 16:14 |
| Dr_Jakob | jcristau: thanks | 16:15 |
| Sarvatt | something in the build changes since 1.6.x screwed up the debug symbol extraction with pkg-create-dbgsym that creates the ddeb's - http://ddebs.ubuntu.com/pool/main/x/xorg-server/ | 16:17 |
| jcristau | Sarvatt: would that explain that the -dbg themselves get screwed up? | 16:18 |
| Sarvatt | yeah it has to be pkg-create-dbgsym I believe because it works fine on PPA (where pkg-create-dbgsym is skipped) and self built packages without it installed, archive packages get run through pkg-create-dbgsym to make the ddebs and i dont think its handling the dh_strip rules right | 16:20 |
| Sarvatt | -dbg works fine when not run through pkg-create-dbgsym I mean | 16:21 |
| jcristau | ah right | 16:21 |
| Dr_Jakob | Sarvatt: 115, 116, 117, 118 where all broken. | 16:22 |
| Sarvatt | plus -dbg is screwed up in mesa as well but the ddeb from pkg-create-dbgsym work in that case, just not xorg-server | 16:22 |
| Sarvatt | Dr_Jakob: sorry about that, you grabbed the source for a screwed up upload thats waiting for approval to be fixed I believe | 16:23 |
| Dr_Jakob | ah ok | 16:24 |
| Sarvatt | sorry for all of the pain :) | 16:25 |
| Dr_Jakob | Well I still have to fix bug 545298 | 16:26 |
| ubottu | Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [Undecided,Incomplete] https://launchpad.net/bugs/545298 | 16:26 |
| Sarvatt | ok got a bug here about the -dbg problems https://bugs.edge.launchpad.net/ubuntu/+source/pkg-create-dbgsym/+bug/562418 | 16:33 |
| ubottu | Launchpad bug 562418 in xorg-server "xserver-xorg-core-dbg debug symbols mismatch" [Undecided,Incomplete] | 16:33 |
| Dr_Jakob | ok thanks | 16:36 |
| === apachelogger is now known as starshiptrooper | ||
| === Amaranth_ is now known as Amaranth | ||
| === starshiptrooper is now known as apachelogger | ||
| jcristau | bryceh: your xorg-server commit seems to have changed nothing but changelog | 19:37 |
| jcristau | the "Update patches in previous upload to fix FTBS issue" one | 19:37 |
| bryceh | jcristau, commit b1bebad6 was the one that fixed the patches | 19:42 |
| jcristau | heh ok | 19:44 |
| jcristau | was confused when seeing that commit mail :) | 19:44 |
| bryceh | jcristau, yeah for as simple as the patches were I totally fucked up the upload. Dunno why, I've been cherrypicking patches all month. | 19:49 |
| bdmurray | bryceh: I have had my system lock up on me 2 times today and I found this in my Xorg.1.log - http://pastebin.osuosl.org/32447 | 19:53 |
| bryceh | bdmurray, hmm, were you able to find any other bug reports reporting that error message? | 19:55 |
| bdmurray | bryceh: I haven't looked in the hopes you'd had them all memorized | 19:56 |
| bryceh | bdmurray, it's nothing I recognize offhand | 19:56 |
| bdmurray | bryceh: cool, cause I was looking at the wrong log. sorry about that | 19:57 |
| bryceh | if (ioctl(xf86Info.consoleFd, VT_WAITACTIVE, xf86Info.vtno) < 0) | 19:58 |
| bryceh | FatalError("xf86OpenConsole: VT_WAITACTIVE failed: %s\n", | 19:58 |
| bryceh | strerror(errno)); | 19:58 |
| bryceh | that's the code producing the error, it's in lnx_init.c in the xserver | 19:58 |
| bryceh | pretty sure we've not done any changes on the X side which would affect that code path | 19:58 |
| bryceh | my guess is it's something lower level than X, since it's just trying to open a VT | 19:59 |
| bdmurray | bryceh: that was really really old | 20:00 |
| bdmurray | the log I was looking at | 20:00 |
| bryceh | oh | 20:00 |
| bryceh | huh, you've got me confused. I need coffee. | 20:00 |
| bdmurray | My system has exploded a couple of times today but not related to that error message | 20:01 |
| bryceh | ok, well see the troubleshooting docs to narrow the problem down | 20:02 |
| bdmurray | right its a full system lock up though I have to power cycle it | 20:02 |
| bryceh | kernel panic? | 20:03 |
| bryceh | no ssh? | 20:03 |
| bdmurray | yeah, no ssh and not able to ping so really probably the kernel | 20:03 |
| bryceh | yep | 20:03 |
| bryceh | X failures don't take down the network | 20:04 |
| tormod | bdmurray, just in general, netconsole can sometimes show some messages which otherwise do not reach the filesystem before crashes | 20:20 |
| bdmurray | tormod: How can I set that up? | 20:21 |
| tormod | bdmurray, https://wiki.ubuntu.com/KernelTeam/Netconsole | 20:22 |
| jcristau | Documentation/networking/netconsole.txt in the kernel source has instructions | 20:22 |
| bdmurray | okay this is happening right now - http://pastebin.osuosl.org/32450 | 20:25 |
| bdmurray | I was able to ssh in this time | 20:25 |
| jcristau | heh, gpu reset every .04s | 20:26 |
| bdmurray | yeah the monitors are cycling through some garbage | 20:26 |
| bdmurray | Is there anything I should get before rebooting? | 20:27 |
| jcristau | i'd take it to #radeon | 20:30 |
| jcristau | they might have a clue what's going on | 20:30 |
| stanley_ | Hi guys I am in some serious trouble here...my cursor won;t work it just froze and even after a restart won't do anything once I log into my profile...at the login screen it does, but once I log into my profile it just stops working | 20:47 |
| kklimonda | hey, is installation of NVIDIA X drivers from their .pkg installer supported in 10.04 yet? | 20:50 |
| bjsnider | no, and it won't be | 20:51 |
| kklimonda | thanks | 20:51 |
| bjsnider | that would pooch the xorg/mesa system | 20:51 |
| tormod | stanley_, try log in with Failsafe Terminal / session / xterm or whatever they call it | 20:53 |
| stanley_ | ok...then do what? | 20:54 |
| tormod | stanley_, is your cursor fine there? | 21:09 |
| stanley_ | yes it is | 21:09 |
| stanley_ | works great everywhere except when i log into my profile | 21:09 |
| tormod | stanley_, what graphics card and driver? | 21:10 |
| stanley_ | I am not sure what driver, but I have an NVIDIA GeForce Go 6150 (UMA) | 21:11 |
| stanley_ | If i log into another profile the cursor works fine... | 21:13 |
| stanley_ | it there something I could reset in my profile to fix this or something I should reinstall? | 21:13 |
| tormod | stanley_, did you change Desktop Effects settings in your profile? | 21:17 |
| stanley_ | Thanks for all your help man, it literally hasn't worked all day and I guess just decided it will start working again now | 21:18 |
| Sarvatt | bdmurray: what GPU? what kernel version? try booting with pci=nomsi? | 21:23 |
| bdmurray | Sarvatt: I've trying to report the bug to Launchpad at the moment - getting OOPses though | 21:33 |
| bdmurray | Sarvatt: I finally got bug 564181 reported | 21:43 |
| ubottu | Launchpad bug 564181 in xserver-xorg-video-ati "GPU soft reset infinite loop" [Undecided,New] https://launchpad.net/bugs/564181 | 21:43 |
| Sarvatt | yep bdmurray try booting with pci=nomsi | 21:44 |
| bdmurray | Sarvatt: is this specific to 2.6.32-21? | 21:45 |
| Sarvatt | you bug is? | 21:48 |
| Sarvatt | ah hah you have a XFX RV730 too | 21:49 |
| bdmurray | I had not seen this before this kernel. So is the boot option specific to this kernel? | 21:49 |
| Sarvatt | darn the XFX rv730 quirk upstream doesn't look related - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=efa8450f6c93c9d4c99adfea2f52f1d02d878d5b | 21:50 |
| Sarvatt | if it's new to 2.6.32-21 thats definitely interesting | 21:51 |
| Sarvatt | the pci=nomsi probably doesn't apply, I thought that was an IGP card | 21:52 |
| Sarvatt | quite a bunch of those getting the same exact errors without disabling MSI | 21:52 |
| tormod | the MSI troubles, are they limited to x86_64? | 21:53 |
| bdmurray | Is there some better test case than using googleearth? | 22:10 |
| bdmurray | I mean is there something similar to googleearth that would be better for recreating the bug | 22:11 |
| jcristau | there isn't a generic "make my gpu hang" test-case i don't think :) | 22:11 |
| jcristau | depends on the particular bug | 22:11 |
| bryceh | jcristau, well there is gem_hang ;-) ;-) | 22:27 |
| jcristau | hehe | 22:27 |
| bryceh | bdmurray, mdz did a tool which we used to help trigger freezes on intel back in jaunty/karmic you could dig up | 22:28 |
| bryceh | bdmurray, found it - http://launchpadlibrarian.net/25683477/repro.sh | 22:29 |
| bryceh | bdmurray, the use cases that script exercises may not be relevant for your particular freeze but better than nothing | 22:29 |
| bryceh | bdmurray, back in jaunty we used that to help make some of the freeze bugs happen faster, for verification purposes. YMMV. | 22:30 |
| bdmurray | bryceh: I can make it happen very quickly! I was just thinking that googleearth was not the most accessible test case. ;-) | 22:31 |
| bryceh | if it happens quickly, it's probably a decent test case | 22:32 |
| bryceh | sometimes a 3D game or flash website will trigger bugs in a similar way as googleearth, but like jcristau says often the hangs are pretty situational | 22:33 |
| bdmurray | bryceh: so would getting a gdb backtrace be useful in this case? | 22:36 |
| bryceh | not really | 22:37 |
| bryceh | freezes tend to give stack traces that just show it's stuck waiting on the gpu | 22:37 |
| bryceh | which is like, duh ;-) | 22:37 |
| bryceh | bdmurray, what generally tends to be needed is a gpu dump - see the freeze page in X/Troubleshooting | 22:37 |
| bryceh | basically you run the reg dumper thingee to get a register dump, and also snag the error file from sysfs | 22:38 |
| jcristau | radeon has that too? | 22:39 |
| * jcristau is less familiar with it than with intel | 22:39 | |
| bryceh | jcristau, yep | 22:41 |
| jcristau | cool | 22:41 |
| bryceh | jcristau, there's two tools actually, one for pre-R500 and one for R500 and newer | 22:42 |
| jcristau | i meant the error state in sysfs | 22:42 |
| bryceh | oh, that I am not sure of, I think they may not have that yet | 22:42 |
| jcristau | ok | 22:42 |
| jcristau | thanks :) | 22:42 |
| bryceh | at least, it's not been something I've been told to collect from people | 22:42 |
| bdmurray | bryceh: I don't see anything about radeon freezes on that page - https://wiki.ubuntu.com/X/Troubleshooting/Freeze | 22:44 |
| bryceh | page needs updated... Well the directions are also at https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen - scan for 'Register Dumps for -ati" | 22:45 |
| bdmurray | bryceh: hrm, I've only been able to ssh into 1 time when it was hung | 22:56 |
| bryceh | bdmurray, tried with ethernet? | 22:58 |
| bryceh | bdmurray, when a system is frozen to the point that it's not ssh-able, it starts to smell kernel-ish | 22:58 |
| bryceh | but you could try sshing in and running top prior to triggering the bug, and see if the issue is caused driving the cpu load | 22:59 |
| bryceh | or tail -f on kernel logs to see if it issues any error messages before locking up | 22:59 |
| bdmurray | bryceh: I've updated the bug with the output I received from netconsole | 23:39 |
| bryceh | bdmurray, ok | 23:39 |
| bdmurray | don't get too excited! | 23:42 |
| bryceh | heh | 23:47 |
| Sarvatt | bdmurray: can you try booting with radeon.dynclks=0 added to the grub kernel command line? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!