| mlankhorst | morning | 06:02 |
|---|---|---|
| RAOF | Yo yo! | 06:03 |
| mlankhorst | no luck yet, did manage to scan for all storage modes yesterday and rediscovered some missing in the enumeration :P | 06:03 |
| mlankhorst | need something else to do for today, any suggestions? | 06:04 |
| tjaalton | nouveau bugs? :) | 06:04 |
| mlankhorst | I mean, something not nouveau so I can focus my mind on something else then try with fresh view in a few days | 06:05 |
| tjaalton | server bugs then | 06:05 |
| RAOF | Yeah, server bugs are often good. | 06:06 |
| mlankhorst | hm, do we have that evdev and synaptics memory corruption sru'd yet? | 06:06 |
| tjaalton | it's not in quantal even | 06:07 |
| tjaalton | i think | 06:07 |
| mlankhorst | yikes | 06:07 |
| tjaalton | no wait | 06:07 |
| tjaalton | different thing maybe | 06:07 |
| RAOF | What was the synaptics memory corruption? | 06:14 |
| RAOF | Dear mesa: kindly build, love, Chris.\ | 06:14 |
| tjaalton | RAOF: 8.0.3? builds here | 06:15 |
| tjaalton | or built | 06:15 |
| RAOF | 8.1 | 06:15 |
| tjaalton | ahh | 06:15 |
| tjaalton | no comments | 06:15 |
| mlankhorst | RAOF: the one where X dies a slow death, or sudden death on unplug :) | 06:15 |
| RAOF | I think the -evdev one which was that got accepted, didn't it? | 06:16 |
| tjaalton | was it the silent abi change? | 06:16 |
| mlankhorst | yeah might, but basically all patches from xf86-input-synaptics 1.6.2 | 06:16 |
| tjaalton | or where it looked like one | 06:16 |
| RAOF | I *think* it ended up being miscompiled code on i386 under certain circumstances? | 06:17 |
| tjaalton | yeah that | 06:17 |
| RAOF | tjaalton: Incidentally, do you have any idea what 101_mesa_hidden_glname.patch is *for* ? | 06:18 |
| mlankhorst | RAOF: do we have plans to sru synaptics 1.6.3 yet? haven't seen any reports of regressions in quantal with it | 06:20 |
| RAOF | It's not on my TODO list; this is something that you could usefully do today, if you wanted :) | 06:21 |
| mlankhorst | i want to move synaptics to 1.6.2 first, since it basically is. Only thing lacking is the 2 version changing commits. | 06:24 |
| tjaalton | RAOF: looks like we've lost all the history before 8.0-rc2.. | 06:25 |
| tjaalton | oh it goes way back | 06:26 |
| RAOF | tjaalton: The earliest reference I can find to it is in your changelog from 7.1~rc1 | 06:26 |
| RAOF | Although you don't seem to have known what it did then :) | 06:27 |
| tjaalton | neither did kyle mcmartin five years ago | 06:27 |
| tjaalton | in 6.5.3-1u1 | 06:27 |
| tjaalton | so, DEP-3 has a true purpose :P | 06:29 |
| mlankhorst | drop it for quantal ? :> | 06:29 |
| RAOF | As far as I can tell that would break ABI by hiding a symbol that was previously unhidden. | 06:30 |
| RAOF | On the other hand, I have absolutely no idea what anyone would *do* with that symbol. | 06:31 |
| tjaalton | http://old-releases.ubuntu.com/ubuntu/pool/main/m/mesa/mesa_6.5.1~20060817-0ubuntu3.diff.gz | 06:36 |
| tjaalton | back in the golden days there was no patch-system.. | 06:36 |
| tjaalton | being used | 06:36 |
| tjaalton | ah, not true. but that change was done directly to the source it seems.. | 06:37 |
| mlankhorst | later than in dapper? | 06:37 |
| tjaalton | looks like I put that in a patch Feb 21st '07 | 06:40 |
| tjaalton | and no comment about why it was there | 06:41 |
| tjaalton | mlankhorst: right, it was introduced in edgy | 06:42 |
| tjaalton | but reading between the changelog lines.. | 06:42 |
| tjaalton | might just as well been a temporary hack that remained in the package | 06:42 |
| RAOF | It doesn't do anything to x86-64. I think we can probably drop it in quantal and see if anything explodes. I don't think it will. | 06:47 |
| tjaalton | yeah | 06:48 |
| mlankhorst | well, i ran dapper fine without it ;) | 07:02 |
| RAOF | You know what would be *totally awesome*? If make wasn't saying “no target to make depend”. | 07:19 |
| mlankhorst | didn't it use 'makedepend' ? :P | 07:28 |
| RAOF | Ah, no. | 07:34 |
| RAOF | It turns out that if makedepend doesn't work, it says “No rule to make target depend” | 07:35 |
| RAOF | Because it's GODDAMNED RIDICULOUS, that's why. | 07:35 |
| mlankhorst | RAOF: btw I'm still RE'ing even if to the casual observer it may look like I'm preparing synaptics 1.6.2 (just a version bump, we already have all the patches) | 07:39 |
| RAOF | If we've already got all the patches why are we getting the version bump? | 07:39 |
| mlankhorst | RAOF: shrug, there will probably be a new release at one point, i need to get my mind off reverse engineering for a bit so I can subconsciously process information and think of things you cant when staring too long :) | 07:41 |
| RAOF | Fair enough :) | 07:41 |
| mlankhorst | plus it was just merging debian and dropping the patches-that-were-commits series | 07:43 |
| RAOF | Fair enough. | 07:49 |
| RAOF | Mmm. Hardlinks. | 07:52 |
| RAOF | JUST TO MAKE IT MORE DIFFICULT. | 07:52 |
| mlankhorst | 'thou shalt not built from tmpfs with package on a real fs'? | 07:54 |
| RAOF | No, in this case “be careful when editing files in ./build/dri, because they're hardlinks to files in ., and different editors will break those hardlinks. | 07:55 |
| RAOF | GrrrrAAAAARCGH! | 08:00 |
| mlankhorst | I build intree with git anyhow :) | 08:01 |
| mlankhorst | mesa make clean is broken enough to justify using git clean instead | 08:02 |
| RAOF | Well, you're *required* to build mesa in-tree; out of tree builds are broken. | 08:02 |
| RAOF | ...that's retarded. | 08:09 |
| mlankhorst | there's another build system you can use too | 08:09 |
| mlankhorst | scons iirc | 08:09 |
| RAOF | Yeah, but we don't use that. And I'd be surprised if it isn't a bit broken. | 08:10 |
| RAOF | So, make can't seem to determine that a rule for main/api_exec_es1.c can be used to make ../../src/mesa/main/api_exec_es1.c | 08:11 |
| mlankhorst | I'm pretty sure out of tree shouldn't even be attempted atm unless you want to fix things | 08:12 |
| RAOF | That's what I'm doing now; attempting to fix things. | 08:13 |
| RAOF | Because we'll probably want 8.1, and that means we'll want out-of-tree to work. | 08:13 |
| mlankhorst | hm, where can I see the stable queue for 3.2.21? | 08:16 |
| mlankhorst | stable-queue.git doesn't list it | 08:17 |
| jcristau | probably not started yet | 08:19 |
| RAOF | Oh, man. Out-of-tree builds are so utterly broken. | 08:34 |
| tjaalton | mlankhorst: git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git | 08:55 |
| tjaalton | but nothing there yet | 08:55 |
| tjaalton | I'll add some commits though | 08:55 |
| mlankhorst | multi arch is funny, took a bit to figure out how to install libdrm2 amd64 | 09:10 |
| Sarvatt | RAOF: that problem is because of galliumcore | 09:18 |
| Sarvatt | RAOF: dget -u -x http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/pool/main/m/mesa/mesa_8.1~git20120529.f92b2e5e-0ubuntu0sarvatt.dsc , that was the last time mesa built | 09:19 |
| Sarvatt | llvmcore was broken because of https://bugs.freedesktop.org/show_bug.cgi?id=49504 , now it fails with https://bugs.freedesktop.org/show_bug.cgi?id=50604 | 09:21 |
| ubottu | Freedesktop bug 49504 in Mesa core "[Bisected] Mesa master compilation broke when built with --with-llvm-shared-libs" [Normal,New: ] | 09:21 |
| ubottu | Freedesktop bug 50604 in Mesa core "[compile error] ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory" [Critical,New: ] | 09:21 |
| aissen | Sarvatt: is there a reason your cedarview ppa is private ? | 10:07 |
| Sarvatt | aissen: i got asked to delete it, the packages are going straight into precise in the next few days though | 10:08 |
| aissen | Sarvatt: alright ! | 10:09 |
| aissen | Sarvatt: I tried it on two different hardware (D2500 and N2600), and I only have a black screen on X startup. | 11:56 |
| aissen | Sarvatt: will there be an updated version from the latest code drops ? | 11:56 |
| Sarvatt | aissen: if you're using ubuntu you need to remove vt.handoff=7 from the kernel command line to get around that, can do GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub and update-grub to do it | 12:05 |
| Sarvatt | sysrq-v works too, or vt switch and stop/start the dm | 12:07 |
| aissen | Sarvatt: thanks | 12:24 |
| aissen | Sarvatt: the screen is filled with garbage. Even the "kms" side doesn't work, it doesn't seem to find the right refresh rate. | 12:26 |
| aissen | Sarvatt: yes, I'm on ubuntu, running precise | 12:26 |
| Sarvatt | aissen: unity 2d or gnome fallback session instead of unity or gnome-shell | 12:39 |
| Sarvatt | aissen: arent these drivers fun? :P | 12:40 |
| aissen | Sarvatt: yeah I love that :-) | 12:40 |
| Sarvatt | 2d deceleration, broken GL support, but video acceleration works ok | 12:41 |
| aissen | Sarvatt: how can I enable unity 2d ? Isn't the problem at the modesetting level, since the display is already scrambled before X starts ? | 12:42 |
| Sarvatt | its scrambled on the lightdm login screen? | 12:42 |
| aissen | yes | 12:43 |
| Sarvatt | err, thats a new one | 12:43 |
| aissen | I could "find" unity 2d choice in lightdm, but I'm guessing this won't help much | 12:43 |
| aissen | let me try on the other hardware (D2500) the grub options, I'll tell you if it helps. | 12:44 |
| Sarvatt | aissen: are you using your own kernel? you dont have psb_gfx loaded right? | 12:45 |
| aissen | Sarvatt: nope, clean precise install. | 12:46 |
| aissen | Sarvatt: let me check. | 12:46 |
| Sarvatt | did you dkms the kernel patch or something? | 12:46 |
| aissen | hum, I installed the dkms package from your ppa - wrong move ? | 12:47 |
| aissen | cedarview-drm | 12:47 |
| Sarvatt | oh yeah | 12:47 |
| Sarvatt | that wont work | 12:47 |
| aissen | oh, ok. | 12:47 |
| rohan | hello.. anyone here from the x-swat x-updates ppa team? | 14:03 |
| mlankhorst | yes? | 14:05 |
| rohan | mlankhorst: I was wondering about the 295.59 nvidia driver -- has it been deliberately kept to the 259.3x version due to some issue? | 14:07 |
| mlankhorst | 259? | 14:08 |
| rohan | sorry, 295.3x | 14:08 |
| mlankhorst | think there were some regressions indeed :) | 14:08 |
| rohan | ah.. looks that way, because even the page here http://www.nvidia.com/object/unix.html lists 295.53 as the latest | 14:09 |
| rohan | i hope it's resolved soon because the .53 version doesn't support my card | 14:10 |
| tjaalton | which is.. ? | 14:10 |
| rohan | PCI ID 0fd3 | 14:11 |
| rohan | GT 640M LE | 14:11 |
| tjaalton | it's up to nvidia to provide that | 14:11 |
| rohan | yes, I realise :) I know it's not something x-swat / x-updates can fix :) | 14:12 |
| rohan | It looks like 295.59 was supposed to be a "long-lived branch release".. i can't imagine how they could release it with regressions! | 14:15 |
| tjaalton | there was a security fix that broke stuff | 14:16 |
| rohan | I see, thank you, tjaalton , mlankhorst | 14:17 |
| rohan | I will wait for the next iteration | 14:17 |
| tjaalton | nvidia-current is at 295.40, nvidia-current-updates at 295.49 | 14:17 |
| mlankhorst | plus it didn't fix the gaping hole :( | 14:18 |
| tjaalton | ah that | 14:18 |
| rohan | mlankhorst: which gaping hole? [just curious] | 14:19 |
| tjaalton | oh now there should be 295.59 | 14:19 |
| mlankhorst | rohan: from what i read from the patch, it seems whole io space is open to user | 14:19 |
| tjaalton | with support for 640m le | 14:19 |
| mlankhorst | now whole io space minus 100kb is | 14:19 |
| tjaalton | http://www.nvidia.com/object/linux-display-amd64-295.59-driver.html?ClickID=d2mtm2tsoxksbkobmcnznsx20bn22ytbcymy | 14:20 |
| rohan | [10:17] <tjaalton> nvidia-current is at 295.40, nvidia-current-updates at 295.49 ==> are we looking at different repos? I am looking at the x-updates PPA and the version of nvidia-graphics-drivers is 295.53 | 14:20 |
| tjaalton | ah | 14:21 |
| mlankhorst | ftp://download.nvidia.com/XFree86/patches/security/CVE-2012-0946/nvidia-blacklist-register-mapping-290-295.diff | 14:21 |
| ubottu | The NVIDIA UNIX driver before 295.40 allows local users to access arbitrary memory locations by leveraging GPU device-node read/write privileges. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0946) | 14:21 |
| rohan | yes, but isn't 295.59 the one with the security hole? | 14:21 |
| tjaalton | it's the latest of the series.. | 14:21 |
| mlankhorst | look at that patch.. there is no reason for userspace to map ANY register from the device in that range.. | 14:21 |
| mlankhorst | if (IS_REG_OFFSET(nv, NV_VMA_OFFSET(vma), NV_VMA_SIZE(vma))) | 14:22 |
| tjaalton | so if they all are affected then yes | 14:22 |
| mlankhorst | that whole branch needs to be removed if nvidia cared about security | 14:22 |
| tjaalton | is it fixed in 302?-) | 14:22 |
| mlankhorst | nope | 14:22 |
| tjaalton | heh | 14:22 |
| rohan | [10:19] <mlankhorst> now whole io space minus 100kb is ... ? | 14:23 |
| rohan | oh you were referring to the patch you linked? | 14:23 |
| mlankhorst | yeah that was their 'fix' turns out userspace needed it so it broke on a few | 14:23 |
| rohan | oh this 'fix' is what's holding 295.59 up? | 14:25 |
| rohan | I guess that's also why they removed it from the main download page | 14:25 |
| tjaalton | no | 14:25 |
| tjaalton | the hole is old | 14:25 |
| rohan | yes, but the fix is breaking userspace, like mlankhorst said, right? or am I just not following? | 14:25 |
| mlankhorst | it's in all nvidia drivers ever released up to 295.40, and even there still open. :S | 14:25 |
| rohan | so does 295.59 fix it, and by fixing it, cause issues? or were the regressions you mentioned separate? | 14:40 |
| mlankhorst | i cant say since i dont look into nvidia drivers | 14:54 |
| tjaalton | they tried to fix it in .40, which caused issues, and at least some got fixed later | 14:54 |
| tjaalton | aiui | 14:54 |
| rohan | ah i see | 14:55 |
| rohan | guess my best option atm is just wait, then :) | 14:55 |
| mlankhorst | there's no point in just updating for the sake of updating | 14:55 |
| tjaalton | right, but .59 adds support for 640mle.. | 14:57 |
| tjaalton | and a bunch of other cards | 14:57 |
| mlankhorst | that's a valid point :) | 14:59 |
| rohan | so should i file a request or just wait? | 15:18 |
| tjaalton | tseliot probably has it on his todo-list already | 15:19 |
| tseliot | yep | 15:20 |
| tjaalton | :) | 15:20 |
| rohan | great, thank you :) | 15:35 |
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!