RAOF | mlankhorst: Time to trade SRU for mesa commits? :) | 01:09 |
---|---|---|
Sarvatt | lol | 01:16 |
mlankhorst | RAOF: Yeah I was blocked on that, I saw that someone replied with keithp's dri3 branch, which supposedly did the same thing | 07:29 |
mlankhorst | but looking at it didn't show up any conflicting commits, which puzzled me | 07:30 |
mlankhorst | at least nothing that conflicted on first sight | 07:31 |
RAOF | mlankhorst: IIRC keithp's dri3 branch contains an implementation for nouveau (which might even by *your* implementation for nouveau, can't remember), and will fail on everything else. | 07:35 |
mlankhorst | ah | 07:38 |
mlankhorst | but I didn't see it in that commit list any more for the dri3 branch, hm | 07:38 |
RAOF | It also got pointed out on the list that my patch series was more complete, and had been hanging around since April or so; keithp may have removed the partial work from his branch? | 07:40 |
mlankhorst | perhaps | 07:42 |
mlankhorst | RAOF: I'll try to grab the patches again, see if they apply and compile | 07:45 |
RAOF | Pretty sure they do. I don't *think* I touched them on my recent rebasefest. | 07:46 |
mlankhorst | there's 2 v3 of one commit too, what one do I take? :p | 07:48 |
mlankhorst | hm guess I'll try the newest one | 07:54 |
RAOF | Oh, really? Which patch has 2 v3s? | 07:55 |
mlankhorst | support dri image version 7 | 07:57 |
mlankhorst | hm they're identical | 08:29 |
mlankhorst | just why would you send it twice :o | 08:29 |
RAOF | I don't know. They're offset by significant times, too. | 08:36 |
RAOF | Maybe one got eaten in processing for a while? | 08:36 |
mlankhorst | probably | 08:41 |
mlankhorst | RAOF: hm, the nouveau patch failed to apply, i fixed it up. the radeon one fails with one hunk too, but it seems that one can be ignored :p | 08:42 |
RAOF | :) | 08:42 |
RAOF | Oh! | 08:42 |
RAOF | Has {r300,r600,radeonsi}/drm_target.c moved between patch submission and now? | 08:43 |
RAOF | Is that the failing hunk? | 08:43 |
mlankhorst | nah | 08:45 |
mlankhorst | was some va_size that got removed | 08:45 |
RAOF | Ah, coolio. | 08:45 |
mlankhorst | ok, trying build | 08:50 |
mlankhorst | ok it compiles, I guess that's all I can ask for | 08:53 |
RAOF | Oh. *That's* why the Mir platform bombs when I try to update it - intel preferentially calls image_get_buffers if it's non-null, and gbm always defines image_get_buffers, but returns 0 if the implementation hasn't defined that. | 08:53 |
RAOF | mlankhorst: There's a piglit test available! | 08:53 |
mlankhorst | too late :p | 08:53 |
RAOF | mlankhorst: Ta muchly | 08:56 |
mlankhorst | mir patch didn't apply and it failed at installing to debian/tmp stage somewhere, | 09:08 |
mlankhorst | but shrug | 09:08 |
tjaalton | mlankhorst: commit the arm fix to d-exp too | 09:15 |
tjaalton | or was that on ubuntu only | 09:15 |
mlankhorst | on ubuntu only for now | 09:15 |
mlankhorst | our packaging diverges a lot there | 09:16 |
tjaalton | ah ok | 09:16 |
tjaalton | yeah I guess jcristau would have spotted the failure too :) | 09:16 |
mlankhorst | oh actually it should fail on their packaging too. :P | 09:16 |
tjaalton | yeah looks like it | 09:18 |
jcristau | i won't spot arm failures until they hit the buildds | 09:20 |
jcristau | no arm kit here :) | 09:20 |
tjaalton | I tried to find build logs yesterday but couldn't find any for mesa 10 | 09:21 |
tjaalton | but yeah guess they do take some time.. | 09:21 |
mlankhorst | jcristau: http://paste.debian.net/70096/ does this look good? | 09:22 |
RAOF | mlankhorst: I've almost got the mir bit done; I've just realised why i965 dies on it. | 09:22 |
mlankhorst | hm I guess I should merge it and have it inside confflags_GALLIUM below.. | 09:23 |
jcristau | tjaalton: mesa 10 is in debian NEW | 09:23 |
jcristau | so no logs yet | 09:24 |
tjaalton | oh right | 09:24 |
mlankhorst | jcristau: http://paste.debian.net/70097/ v2 | 09:25 |
jcristau | mlankhorst: not quite sure if building radeon stuff on arm makes much sense | 09:25 |
mlankhorst | jcristau: well .. we already do it anyway :P | 09:25 |
mlankhorst | and lynxeye already had nouveau working on a tegra board with pci-e | 09:26 |
mlankhorst | granted, the leak current of the nvidia card was probably higher than the entire tegra board itself, but still! | 09:26 |
jcristau | need more context to understand v2. too many conditionals in that makefile. | 09:29 |
* jcristau tries to find a mesa checkout | 09:29 | |
mlankhorst | oh wait, i915/i965 is used outside linux right? | 09:31 |
jcristau | yes | 09:40 |
jcristau | i was just about to say that | 09:40 |
jcristau | need to still build them on kbsd | 09:40 |
RAOF | I win! | 09:42 |
mlankhorst | congratulations, you win a mir display | 09:43 |
jcristau | that sounds like losing | 09:47 |
mlankhorst | jcristau: http://paste.debian.net/70098/ hm this better? | 09:54 |
jcristau | you lose the extra_sed thing, is that on purpose? | 09:57 |
mlankhorst | yeah | 09:57 |
mlankhorst | libllvmradeon.so no longer exists | 09:57 |
mlankhorst | so it was a leftover in debian/rules | 09:57 |
tjaalton | confusing to remove it on the same commit | 09:57 |
mlankhorst | this is the diff I have. :P | 09:58 |
mlankhorst | didn't commit anything yet | 09:58 |
jcristau | in that case also remove the use of EXTRA_SED :) | 09:58 |
mlankhorst | ah right | 09:59 |
mlankhorst | RAOF: hm mir was broken with mesa 10? | 10:19 |
RAOF | mlankhorst: When switching to using gbm for the nested stuff, I think. | 10:22 |
mlankhorst | oh :p | 10:23 |
mlankhorst | didn't check nested | 10:23 |
=== debfx_ is now known as debfx | ||
mlankhorst | RAOF: oh btw for libdrm/pixman sru do I need to update quantal and raring or not? To make upgrading from precise to quantal and raring work | 11:23 |
mlankhorst | guess I will | 11:50 |
RAOF | mlankhorst: Yeah, we do like to keep upgrades working :) | 12:25 |
mlankhorst | ok | 12:25 |
mlankhorst | testbuild in ppa seems to work | 12:25 |
mlankhorst | pixman_0.30.2-1ubuntu0.0.0.0.1_source.changes | 12:37 |
mlankhorst | weee | 12:37 |
tjaalton | jollas available tomorrow.. bah. no benefit in preordering it other than getting a free cap | 13:51 |
tjaalton | which should arrive some time next week | 13:51 |
mdeslaur | mlankhorst: you just overwrote my previous xorg-server changes | 14:20 |
mlankhorst | oh :P | 14:21 |
mlankhorst | sorry | 14:21 |
mdeslaur | mlankhorst: np, can you fix it? | 14:21 |
mlankhorst | sure | 14:22 |
mdeslaur | mlankhorst: cool, thanks! | 14:22 |
=== jono is now known as Guest63303 | ||
mdeslaur | so...looking at http://nvidia.custhelp.com/app/answers/detail/a_id/3377 | 21:34 |
mdeslaur | seems there are new 331 319 and 304 drivers | 21:34 |
mdeslaur | but, I'm looking at the zillion packages we have to update in the archive | 21:34 |
mdeslaur | what do we do with the 310 and 313 packages? | 21:34 |
mdeslaur | update them to 319? | 21:34 |
mdeslaur | leave as-is without telling the user they have a security issue? | 21:35 |
mlankhorst | it's fairly theoretical | 23:02 |
mlankhorst | well it's still a gaping security hole but not everyone could exploit it ;) | 23:03 |
mlankhorst | mdeslaur: hm | 23:04 |
mlankhorst | The PGRAPH context switch microcode allows user to read/write arbitrary MMIO registers by submitting the firmware methods. The GF100+ video decoding etc. falcon microcodes allow you to just ask for physical instead of virtual addressing, and that includes physical system memory. Why did nVidia include such obviously security-breaking functionality in the firmware images? As I understand it, a user having access to just the FIFO submission interfac | 23:04 |
mlankhorst | Marcin KoĆcielnicki | 23:05 |
mlankhorst | sounds like it could be fun to figure out :P | 23:05 |
mlankhorst | mdeslaur: I guess nouveau developers could figure it out, but anyone else is going to have to try a lot harder | 23:11 |
mlankhorst | mdeslaur: but tseliot knows the nvidia binary drivers better than I do, ask him ;) | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!