| bjsnider | Sarvatt, add the blob for lucid/mav too, k? | 00:42 |
|---|---|---|
| bryce_ | bjsnider, he's left | 00:49 |
| RAOF | Hah. Just when you thought that nvidia driver would do us, we get Xserver 1.10 RC3… with a video ABI bump :) | 03:49 |
| bjsnider | RAOF, you had better be joking | 03:49 |
| RAOF | No, not at all. Reverting XRandR 1.4, which needs a bit more protocol & code review, which means a video ABI bump. | 03:50 |
| bjsnider | i don't find that amusing | 03:51 |
| bjsnider | violence must ensue | 03:51 |
| bryce_ | RAOF, at this point I think we either revert that change or hold off updating xserver and give the binary drivers a chance to catch up | 04:28 |
| bryce_ | lest we start getting pitchforks brandished our way | 04:29 |
| bjsnider | bryce_, i think it's a good idea to wait | 04:29 |
| bjsnider | i suppose there are no rules on how many release candidates they'll produce? | 04:30 |
| bryce_ | there's still time until release to let things shake out, and we can always do cherrypicks from the upstream tree (I imagine there won't be that many patches from here on out) | 04:30 |
| bryce_ | bjsnider, nope | 04:30 |
| bjsnider | is there a final release date? | 04:30 |
| RAOF | Yeah; today, from memory :) | 04:31 |
| bjsnider | seems like they just do whatever they want and don't give a damn about their users | 04:32 |
| kklimonda | any idea where does it come from: http://paste.ubuntu.com/572050/ ? | 05:13 |
| kklimonda | with 270.29 | 05:13 |
| RAOF | That's a bug in the nvidia kernel module. | 05:15 |
| RAOF | It looks like it's in an error-recovery path, too. | 05:15 |
| RAOF | The first message is ‘your card's gone crazy’, the second is ‘woah, the nvidia module did something wrong’. | 05:16 |
| kklimonda | I can't remember last time I've had so much fun during alpha ;) | 05:17 |
| kklimonda | oh well, back to nouveau for now - maybe I'll manage to get some logs for the gpu lockup I''ve been encountering for the last few days | 05:18 |
| RAOF | Oh, huh? That's actually killing your graphics, is it? | 05:19 |
| * RAOF thought nvidia was generally better at error-recovery than that. | 05:19 | |
| kklimonda | RAOF: it doesn't kill it | 05:19 |
| kklimonda | RAOF: it just locks for a second or two | 05:20 |
| RAOF | Ah. Heh. | 05:20 |
| kklimonda | but I've had four locks in 5 minutes ;) | 05:20 |
| kklimonda | it does seem related to flash | 05:20 |
| RAOF | Well, there's a nice change of pace. Problems with flash‽ | 05:20 |
| kklimonda | maybe the new flash which was supposed to have some kind of gpu acceleration is breaking something | 05:20 |
| RAOF | Shocking! | 05:20 |
| kklimonda | isn't it? | 05:21 |
| RAOF | Flash has had gpu acceleration on nvidia for quite some time, IIUC. | 05:21 |
| kklimonda | really? and it still sucks so much? | 05:21 |
| RAOF | Apparently it sucks pretty much everywhere? | 05:23 |
| kklimonda | well, it's usable on Windows | 05:23 |
| kklimonda | (by usable I mean that you can watch 720p without boiling your laps) | 05:24 |
| === yofel_ is now known as yofel | ||
| tseliot | tjaalton: did they break the ABI again??? http://www.phoronix.com/scan.php?page=news_item&px=OTEzMA | 12:40 |
| tjaalton | yes | 12:40 |
| tjaalton | randr-1.4 was removed | 12:40 |
| tseliot | this is not good for fglrx and nvidia | 12:40 |
| tjaalton | it's trivial for them to fix | 12:41 |
| tjaalton | and aaronp was aware of that | 12:42 |
| tseliot | I'll talk them, just in case | 12:42 |
| tjaalton | we don't have to pull rc3 until they've released newer versions for it | 12:43 |
| tseliot | new versions as in new open drivers? | 12:44 |
| tseliot | or new X? | 12:44 |
| tjaalton | new blobs | 12:45 |
| tseliot | ok, this is good to know | 12:45 |
| tseliot | as I'm about to upload nvidia | 12:45 |
| ricotz | bjsnider, ftp://download.nvidia.com/XFree86/Linux-x86_64/270.29/ :) | 14:04 |
| ricotz | tseliot, hi, you are already on update nvidia? | 14:05 |
| ricotz | nvm, just saw the upload ;) | 14:07 |
| tseliot | ricotz: yep, I uploaded nvidia. I'm working on nvidia-settings now | 14:08 |
| ricotz | mhh, i think IgnoredABI might be still needed | 14:08 |
| tseliot | have you tried the driver? | 14:08 |
| ricotz | with 1.10rc3 | 14:08 |
| ricotz | no havent tried it, just saw the message in #nvidia | 14:09 |
| tseliot | right, that broke the ABI again | 14:09 |
| ricotz | yes :( | 14:10 |
| bjsnider | ricotz, bryce said they won't be uploading rc3 to natty until amd/nvidia release updates for it | 14:20 |
| ricotz | bjsnider, yeah that's reasonable | 14:23 |
| bjsnider | tseliot, "#Blacklist some card ids from GRUB gfxpayload=keep" is only appropriate for natty, correct? | 14:30 |
| tseliot | bjsnider: yes but it won't hurt since it does "which update-grub-gfxpayload" and works only if this returns true | 14:31 |
| bjsnider | tseliot, "#DIRNAME#/libnvcuvid*.so* #PKGLIBDIR#" is missing from the .install file | 14:33 |
| bjsnider | how about just #DIRNAME#/libnv*.so* #PKGLIBDIR# | 14:33 |
| bjsnider | that would cover all of it | 14:34 |
| tseliot | let me check | 14:34 |
| bjsnider | plus anything else nvidia sneaks in there in the future | 14:34 |
| yofel | can someone retry the amd64 build of nvidia 270.29 in natty please? failed with chroot problem | 14:35 |
| bjsnider | it's in the links file though. so you're linking a file that doesn't exist | 14:35 |
| tseliot | yofel: I might upload a new revision with some changes | 14:36 |
| yofel | ah ok | 14:36 |
| tseliot | bjsnider: yes, I guess I forgot to put it int the install.in file. Thanks for reporting, I'll fix it now | 14:37 |
| bjsnider | tseliot, it looks like all you need to do is shorten line 9 | 14:38 |
| bjsnider | you could remove line 12 | 14:38 |
| tseliot | hmm... I'd rather not catch libnvidia-tls | 14:42 |
| bjsnider | it's in a subdirectory, isn't it? | 14:45 |
| tseliot | it seems to be in two places | 15:04 |
| tjaalton | tseliot: "Depend on ${xinpdriver:Depends}", really?-) | 15:08 |
| tseliot | tjaalton: no, I don't think so | 15:09 |
| tjaalton | that's on your changelog | 15:09 |
| tseliot | ${xviddriver:Depends} | 15:09 |
| tseliot | so the changelog is wrong | 15:10 |
| tjaalton | yep | 15:10 |
| tseliot | the control file is not | 15:10 |
| jcristau | better than the other way around | 15:10 |
| tseliot | definitely | 15:10 |
| tseliot | bjsnider: on a second thought, I guess I'll do as you suggested | 15:23 |
| bjsnider | why? | 15:23 |
| tseliot | that tls library won't hurt | 15:24 |
| tseliot | and this saves me some work | 15:24 |
| === njpatel_ is now known as njpatel | ||
| LLStarks | i think vsync might be broken on my machine | 18:28 |
| LLStarks | i'm getting tearing during video | 18:28 |
| LLStarks | all outputs and players | 18:29 |
| cnd | bryce_, why isn't there an evdev-dbgsym package? | 20:01 |
| jcristau | because evdev doesn't crash, basically | 20:03 |
| jcristau | until now, that is ;) | 20:03 |
| cnd | jcristau, but the dbgsym packages should be built automatically in ubuntu | 20:03 |
| cnd | and uploaded to ddebs.archive.ubuntu.com | 20:03 |
| jcristau | ah. that. | 20:04 |
| jcristau | no idea. | 20:04 |
| cnd | hmmm... so the atoms array is failing to be initialized | 20:08 |
| bryce_ | cnd, yeah I'm wondering the same | 20:09 |
| cnd | bryce_, also, that backtrace is rather odd | 20:09 |
| bryce_ | cnd, I've added to my todo list to look into adding a -dbg for evdev | 20:09 |
| cnd | it says the address of an instantiated array is 0x11b | 20:10 |
| cnd | which shouldn't be a valid address | 20:10 |
| bryce_ | bad pointer arith? | 20:10 |
| bryce_ | ptr = NULL + offset | 20:10 |
| cnd | not that I can think of | 20:10 |
| cnd | let me paste the code | 20:10 |
| cnd | bryce_, http://pastebin.ubuntu.com/572328/ | 20:11 |
| cnd | I don't know exactly which XIChangeDeviceProperty call is dying | 20:11 |
| cnd | but I know it's one of these two | 20:11 |
| cnd | and the address of atoms is wrong when it's called | 20:12 |
| tjaalton | bryce_: re -dbg; maybe first ask around why -dbgsym isn't built? getting that fixed is less work (for you :) | 20:13 |
| cnd | tjaalton, yeah, I don't think we need a -dbg package | 20:14 |
| bryce_ | Atom atoms[pEvdev->num_vals]; | 20:17 |
| bryce_ | is pEvdev->num_vals a variable? If so, then is ^ valid? | 20:19 |
| cnd | the previous line has an if for num_vals > 0 | 20:19 |
| cnd | so it must be valid | 20:19 |
| cnd | and if it's something crazy, like a huge number | 20:19 |
| cnd | then I would think it would die allocating it | 20:19 |
| cnd | and using it before we get to the crashing function | 20:20 |
| bryce_ | but I mean, doesn't the C standard require arrays be allocated with const numbers not variables? | 20:20 |
| cnd | bryce_, not c(( | 20:20 |
| cnd | C99 | 20:20 |
| bryce_ | ahh | 20:20 |
| bryce_ | shows how recently I've read a C book ;-) | 20:21 |
| cnd | bryce_, I can't say I've ever really read a C book :) | 20:21 |
| cnd | the interwebs are my friend | 20:21 |
| jcristau | i think i read k&r when i was 16 or something. didn't have variable length arrays :) | 20:22 |
| cnd | so, assuming I'm not missing something obvious | 20:22 |
| cnd | then either he's got hardware issues | 20:22 |
| cnd | or he's got a corrupted stack/heap | 20:22 |
| cnd | well, the former implies the latter too I suppose :) | 20:22 |
| bryce_ | well, I'm curious what the length on atoms is | 20:23 |
| bryce_ | EvdevInitButtonLabels() appears to have some built in assumptions about the minimum length of it | 20:23 |
| bryce_ | actually no, looks like it's ok | 20:24 |
| bryce_ | cnd, yeah I don't see anything either | 20:24 |
| cnd | bryce_, the other possibility is that maybe XIChangeDeviceProperty is modifying the "value" variable that was passed in? | 20:24 |
| cnd | or does the backtrace give the value of the variable as it's passed in unmodified | 20:25 |
| cnd | that seems unlikely | 20:25 |
| bryce_ | yeah I think it shows initial values | 20:25 |
| cnd | bryce_, how would it? | 20:25 |
| cnd | that would require two copies of the variable | 20:26 |
| cnd | one to show the passed in value | 20:26 |
| bryce_ | hm true | 20:26 |
| cnd | and one to be used, and maybe modified, in the function | 20:26 |
| cnd | time to take a look at XIChangeDeviceProperty :) | 20:26 |
| cnd | bryce_, can't see anything there | 20:28 |
| cnd | it's used in exactly one line | 20:28 |
| cnd | as the source of a memcpy | 20:28 |
| bryce_ | memcpy ((char *) new_data, (char *) value, len * size_in_bytes); | 20:28 |
| cnd | yep | 20:29 |
| cnd | so the only thing I can think of is that there's stack corruption | 20:30 |
| LLStarks | bryce, should i file about the tearing? | 20:31 |
| cnd | bryce_, as fta noted in #ubuntu-desktop, this occurred with -1ubuntu6! | 20:31 |
| cnd | though the bug occurred elsewhere | 20:31 |
| cnd | he says | 20:31 |
| cnd | hmmm | 20:32 |
| cnd | I'm going to recommend running a daily iso from monday | 20:32 |
| cnd | before the new X changes | 20:32 |
| bryce_ | ok | 20:32 |
| cnd | RAOF, can you sync your changes to the x packages to git when you get a chance? | 21:11 |
| cnd | I pushed up evdev for you | 21:17 |
| cnd | bryce_, it's a bug in pkg-create-dbgsym | 21:28 |
| cnd | debian added a new arch "linux-any" | 21:28 |
| cnd | but it only looks for "any" and each specific architecture | 21:28 |
| cnd | I'll get that fixed up | 21:29 |
| bryce_ | ah yes the "linux-any" bug | 21:30 |
| cnd | is it a known bug? | 21:30 |
| bryce_ | well, something I keep running into with pbuilder | 21:31 |
| cnd | ahh | 21:31 |
| bryce_ | see deb bug 600823 | 21:31 |
| ubot4 | Launchpad bug 600823 in firefox (Ubuntu) "Flash doesn't work after Firefox 3.6.6 upgrade (affects: 2) (heat: 15)" [Undecided,Invalid] https://launchpad.net/bugs/600823 | 21:31 |
| bryce_ | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600823 | 21:32 |
| ubot4 | Debian bug 600823 in pbuilder "[pbuilder] Doesnt support "any" wildcards in debian/control" [Important,Fixed] | 21:32 |
| bryce_ | but that's probably unrelated | 21:32 |
| yofel | iirc that's debian bug 363193 | 21:38 |
| ubot4 | Debian bug 363193 in pbuilder "pbuilder-satisfydepends does not support new style architecture specifications" [Important,Fixed] http://bugs.debian.org/363193 | 21:38 |
| bryce_ | yofel, thanks | 21:55 |
| cnd | bryce_, if I have a fix for a package and linked it in a bug | 22:30 |
| cnd | but it's a package in main | 22:30 |
| cnd | do I subscribe ubuntu-sponsors? | 22:30 |
| cnd | or some core dev specific team? | 22:31 |
| bryce_ | ubuntu-sponsors is sufficient | 22:32 |
| cnd | I had been wondering for a while if I was subscribing the right team :) | 22:34 |
| cnd | I've got dbgsym packages again :) | 22:35 |
| cnd | so you can scratch that issue off your todo list | 22:35 |
| bryce_ | awesome thanks :-) | 22:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!