| RAOF | Man, our session mediator is the cacheline killer. | 00:04 |
|---|---|---|
| RAOF | It appears to service each request on a different CPU. | 00:04 |
| racarr | RAOF: We are threading geniuses | 00:09 |
| RAOF | We should probably cut back on that :) | 00:10 |
| RAOF | But what are we threading geniuses *through*? | 00:10 |
| RAOF | The eye of a needle? | 00:10 |
| RAOF | The eye of a camel? | 00:10 |
| RAOF | Inquiring minds want to know! | 00:10 |
| racarr | haha | 00:11 |
| RAOF | I'm pretty sure we could trim a fair bit of fat from our RPC code. | 00:40 |
| RAOF | Wait. Are we sure we're reading from the socket in order? I seem to get multiple request messages interleaved. | 02:23 |
| duflu | RAOF: Surely that's something protobuf deals with? | 02:28 |
| RAOF | No, protobuf is purely encoding. | 02:28 |
| RAOF | It doesn't have anything to do with actually shipping the encoded bytes anywhere; that's all us. | 02:28 |
| duflu | RAOF: I do recall coming across documentation which said protobuf waits for all the bytes to reform a message. You can't just peak at headers etc | 02:29 |
| RAOF | We *do* peek at the headers :) | 02:29 |
| RAOF | Or, rather, we encode the size of the message as a header and then send that + the message. | 02:30 |
| duflu | RAOF: That's odd, because when I wanted to "peek" I found protobuf disallowed it | 02:30 |
| RAOF | Oh, I don't think you can peek at a bit of a protobuf message. | 02:30 |
| RAOF | But we wrap the protobuf message in a tiny extra protocol (ie: two byte msg size, followed by protobuf msg) | 02:31 |
| duflu | RAOF: Yes, both statements are true. Different layers | 02:31 |
| RAOF | Incidentally, the drm auth message is surprisingly big; it's 19 bytes. | 02:32 |
| RAOF | Sorry, 26 bytes. | 02:32 |
| RAOF | Presumably we're actually sending the string "drm_auth_magic" over the wire. | 02:32 |
| RAOF | Which seems totally unnecessary, but whatever. | 02:32 |
| duflu | RAOF: Yeah I had two branches that removed that. One I think got proposed, and rejected. At least I could never measure any performance benefit in removing it | 02:33 |
| RAOF | Yeah, it's not going to be a big performance problem. | 02:34 |
| RAOF | It's just something we could trivially not do. | 02:34 |
| duflu | RAOF: Actually, I think it was something like 1% CPU of something | 02:34 |
| RAOF | We additionally copy all the messages at least once more than I think is necessary. | 02:34 |
| duflu | RAOF: How performant are local sockets known to be? | 02:35 |
| RAOF | (We copy from the message into a buffer, then write that buffer to the socket) | 02:35 |
| RAOF | local sockets should be pretty good; to get better we'd need to do shared memory, I believe. | 02:35 |
| RAOF | Urgh. Couldn't we just appropriate Wayland's IPC mechanism? That's really nice ☺ | 02:46 |
| RAOF | Bah. For all that we use threads, mirclient is pretty terribly unthreadsafe. | 02:53 |
| duflu | RAOF: Does wayland use sockets? | 02:53 |
| RAOF | Yes | 02:53 |
| RAOF | In fact, I *think* it's unsafe to call any function from mirclient in more than one thread. | 02:54 |
| RAOF | (Because anything that writes to the mir socket does so in a thread unsafe way, so you can't call anything that could send a message from more than one thread at once) | 02:55 |
| duflu | RAOF: I'm fairly confident the thread safety aspects of libmirclient are now solved (recently in r827). Except bug 1194384 remains | 02:55 |
| ubot5 | bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged] https://launchpad.net/bugs/1194384 | 02:55 |
| RAOF | Ah, yes. We've got a big-old mutex around every call in MirConnection. | 03:00 |
| RAOF | Oh, no. Not around configure_display | 03:01 |
| duflu | RAOF: Heh, well it was right at the time. I can't check everyone's changes since all the time | 03:03 |
| duflu | RAOF: In other news, alf tells me that my bypass+radeon problems were just the old kernel I have here. It works in saucy, which means saucy can bypass intel+nouveau+radeon. I will do final testing before EOD | 03:07 |
| RAOF | Woot! | 03:08 |
| duflu | Might have to add a kernel version check :/ | 03:08 |
| duflu | Because slightly slower is better than corruption or crashes | 03:08 |
| duflu | And spurious bug reports | 03:09 |
| olli_ | morning RAOF | 03:38 |
| RAOF | olli_: Good morning | 03:39 |
| olli_ | thx for doing the call last night | 03:40 |
| olli_ | was well perceived :) | 03:40 |
| olli_ | do you have any good update on bug 1204939 | 03:40 |
| RAOF | Ah, good. | 03:40 |
| ubot5 | bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged] https://launchpad.net/bugs/1204939 | 03:40 |
| RAOF | No. | 03:40 |
| RAOF | I have a variety of things that it's *not*, and *maybe* it's a threadsafety issue in our IPC code. | 03:41 |
| RAOF | But I'll hopefully get another debug dump from a jenkins run later today when Didier's up, and then I'll hand off to alan_g | 03:42 |
| duflu | olli_, I am putting bypass on pause for the day and looking into the possibly-related bug too | 03:42 |
| olli_ | RAOF, do we have any other way to reproduce? | 03:43 |
| olli_ | w/o didrocks | 03:43 |
| olli_ | duflu, thx, I saw the note in the bug | 03:43 |
| olli_ | I'd really like to get this unblocked prior to the weekend (which is in a few hours for you lucky guys ;) | 03:44 |
| RAOF | olli_: As far as I can tell, the Jenkins ati box is the only one that reproduces. | 03:44 |
| olli_ | RAOF, sure, but you suggest you need didrocks to access it | 03:44 |
| * duflu wonders if headlessness helps | 03:44 | |
| RAOF | olli_: Ah, I see what you mean. | 03:44 |
| RAOF | Didier has done all the jenkins futzing for all of my previous debugging romps. I'm not sure what actually needs to be done to put the machine in the necessary state. | 03:45 |
| olli_ | RAOF, yeah, I don't think this is anything that would help today to speed things up but maybe somehting to consider for the next bug on his system (i.e. get access) | 03:47 |
| olli_ | RAOF, he might actually be out | 03:48 |
| olli_ | he was out for sure on Thu | 03:48 |
| olli_ | not sure if he is also taking Fri off | 03:48 |
| olli_ | RAOF, duflu, everybody, mind sending me & didrocks an update via mail before you EOW? we have a few interested parties that are curious if&when we can enable autolanding again | 03:49 |
| RAOF | olli_: Sure. | 03:49 |
| duflu | Yep | 03:49 |
| olli_ | thx guys | 03:49 |
| * duflu is struggling to reproduce said bug now | 03:50 | |
| olli_ | sounds like a tough nut to crack | 03:50 |
| RAOF | duflu: You're trying the valgrind bug? | 04:00 |
| RAOF | duflu: Because I think the drm_auth_magic failure in that requires you to run one of the previous, failing tests first. | 04:02 |
| duflu | RAOF: I'm doing exactly the same as yesterday, on multiple machines which had the bug yesterday. I shall have to bisect.... | 04:03 |
| RAOF | Hah! Surprise! | 04:04 |
| RAOF | Huh. The apple magic touchpad kernel panics my Galago after a couple of seconds' use. | 04:25 |
| * duflu pretends he wasn't the last person to touch that kernel driver | 04:39 | |
| duflu | Actually, I probably wasn't | 04:40 |
| RAOF | Dear OOM killer: where did my 16GB of RAM go? Did you really have to kill Xorg? | 04:59 |
| duflu | There's a SysRq combo for that | 05:04 |
| * duflu -> lunch | 05:04 | |
| tvoss_ | good morning | 05:12 |
| tvoss_ | olli_, ping | 05:14 |
| olli_ | tvoss_, wassup | 05:15 |
| === olli_ is now known as olli | ||
| RAOF | Mornang all. | 05:18 |
| tvoss_ | RAOF, hey there :) | 05:19 |
| tvoss_ | hmmm, I want a Mir logo and have it printed @http://www.unixstickers.com/ | 05:25 |
| RAOF | Hm. Why is whoopsie cycling between 1GB and 4GB resident size? | 05:28 |
| duflu | tvoss_: I want a better Mir logo too. Right now we only have examples/mir_image.h | 05:29 |
| tvoss_ | duflu, yeah | 05:33 |
| duflu | tvoss_, I was thinking about designs just yesterday :) | 05:33 |
| tvoss_ | duflu, I was thinking if we should name the different threads in Mir to make htop output more readable | 05:33 |
| tvoss_ | duflu, we could have something similar to the unity logo | 05:33 |
| duflu | tvoss_, I hope better than the Unity logo | 05:34 |
| duflu | Something the quality of the logo on https://launchpad.net/compiz, but obviously completely different | 05:35 |
| RAOF | tvoss_: Oh, yes please! Sensible names for threads! | 05:37 |
| * duflu would rather more careful design of threads. But has also suggested some names: https://bugs.launchpad.net/mir/+bug/1194384 | 05:39 | |
| ubot5 | Launchpad bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged] | 05:39 |
| tvoss_ | duflu, I was more thinking about a pthread_setname_np call | 05:42 |
| duflu | tvoss_: Yes should work: pthread_setname_np(t.native_handle(), "foo"); | 05:44 |
| tvoss_ | duflu, I'm a bit worried about _np (not posix)? :) | 05:44 |
| duflu | tvoss_: Or more generally explicitly depending on pthread, which we don't thanks to C++11 | 05:45 |
| === chihchun_afk is now known as chihchun | ||
| duflu | tvoss_: P.S. Lenovo released BIOS 1.39 for X220 with CPU microcode update. I'm not sure, but it feels like power and fan usage is lower | 05:55 |
| tvoss_ | duflu, woot :) time to get out my bios flash usb stick :) | 05:55 |
| smartboyhw | tvoss_, I didn't realize that you guys have a logo:P | 05:56 |
| duflu | smartboyhw: Not really. Just the image from mir_demo_{client_accelerated,standalone_render_surfaces} | 05:57 |
| * smartboyhw thought you guys can just ask from Canonical Design Team, weird | 05:57 | |
| tvoss_ | smartboyhw, well, yes, but they are quite busy these days :) | 06:01 |
| smartboyhw | tvoss_, oh:( | 06:01 |
| smartboyhw | BTW, any easy Mir bugs to fix? :P | 06:01 |
| tvoss_ | smartboyhw, let me have a look | 06:05 |
| tvoss_ | RAOF, duflu what's the status of https://bugs.launchpad.net/mir/+bug/1102757 | 06:06 |
| tvoss_ | ? | 06:06 |
| ubot5 | Launchpad bug 1102757 in Mir "System compositor children receive all input events" [High,In progress] | 06:06 |
| duflu | tvoss_: No idea. I don't have a dev env for USC. Never needed to yet | 06:07 |
| duflu | Maybe I could reproduce it with regular Mir and test Robert's branch... | 06:07 |
| RAOF | tvoss_: Blocked on https://code.launchpad.net/~robertcarr/mir/client-focus-notifications | 06:08 |
| RAOF | tvoss_: Plus I need to hook up the XMir bit to relinquish input once that's done. | 06:08 |
| tvoss_ | RAOF, ack | 06:08 |
| tvoss_ | RAOF, is that the same issues that prints passwords in clear text onto the terminal | 06:09 |
| tvoss_ | ? | 06:09 |
| RAOF | No; *that* issue should be fixed, I think. | 06:09 |
| RAOF | This is the issue that mirrors passwords across all the logged-in sessions :) | 06:09 |
| * duflu tests | 06:10 | |
| duflu | tvoss_: I can't reproduce any stray text going to other VTs. At least not any more now I'm updated | 06:11 |
| tvoss_ | RAOF, ack and thx | 06:11 |
| duflu | RAOF, alf__: Anyone know the exact commit of the famous "DMA-buf" fix? | 06:22 |
| alf__ | duflu: sorry, no | 06:34 |
| RAOF | Not me, either. | 06:35 |
| alf__ | RAOF: Hi! Yesterday I was spiking per-session modesetting, and I found that trying to apply the display config from within the display config change handler in the client caused the client to hang. Is this going to be an issue for the XMir use case? | 06:37 |
| RAOF | alf__: No; I have to proxy everything from the handler to the X main loop anyway. | 06:37 |
| alf__ | RAOF: ok, then we can leave the thread issue for later | 06:38 |
| RAOF | Oh, that reminds me. | 06:38 |
| * RAOF pushes mutex fix for display config setting | 06:38 | |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 06:50 |
| RAOF | alf__: The way to actually set a mode is to set the current_mode member of the config struct, right? | 06:52 |
| alf__ | RAOF: yes | 06:59 |
| alf__ | RAOF: to the index of the wanted mode in the modes array | 06:59 |
| RAOF | Cool, ta. | 06:59 |
| RAOF | alf__: Oh, and setting ‘used = 0’ should turn the display off? | 07:07 |
| alf__ | RAOF: well, not use it, which right now means just leaving there whatever was on screen before, but yes it should ideally turn it off | 07:08 |
| RAOF | I ask this merely because the kms way of dealing with this appears to be ‘set the mode, connecting it to 0 outputs’. | 07:09 |
| * duflu reboots to try for some more hardware testing | 07:09 | |
| RAOF | Also, I'll want to make DPMS work, too. | 07:10 |
| RAOF | Hm. That actually needs a different API though, doesn't it? We don't actually want to unset the mode, we want to turn off the monitor. | 07:11 |
| alf__ | RAOF: different api from our side? | 07:12 |
| RAOF | Yeah, maybe. | 07:12 |
| alf__ | RAOF: why isn't !used enough? | 07:13 |
| RAOF | For XMir I can actually just fake it by not adjusting the root window etc but unsetting the monitor. | 07:13 |
| RAOF | alf__: Because we need to be able to distinguish between ‘turning off a monitor, but keeping it logically present’ and ‘turning off a monitor and rearranging the desktop to support the new geometry’ | 07:14 |
| RAOF | As I say, I can fake that at the XMir level; maybe we can do the same at the Unity8 level. | 07:15 |
| alf__ | RAOF: I am not sure I see the problem... Can yous set an output to !used and arrange the others as if the output existed at some point in the virtual space? | 07:17 |
| alf__ | RAOF: (for the first case you describe) | 07:18 |
| RAOF | alf__: Yes, ish - the responses to a client querying the display state should be different, though. In the DPMS case the display is logically enabled (so, for example, it's fine to put windows on it). In the actually-off case the display is gone, and you need to do things like move all the windows that were on it somewhere else, etc. | 07:19 |
| RAOF | It basically means I'll be keeping some shadow display configuration in XMir that isn't quite the same as the display configuration that unity-system-compositor has; we'd likewise need to do the same for Unity8 | 07:21 |
| alf__ | RAOF: got it | 07:26 |
| RAOF | Bah. Why do we return "" for no error? | 07:37 |
| RAOF | Rather than, say, returning NULL. Which is more idiomatic to check for. | 07:38 |
| duflu | alf__, It appears I will not be able to test radeon on saucy --> bug 1212977 | 07:49 |
| ubot5 | bug 1212977 in Ubuntu "saucy daily-live images are unbootable on Dell Optiplex 990; stuck in BusyBox shell" [Undecided,New] https://launchpad.net/bugs/1212977 | 07:49 |
| alf__ | duflu: ok, just ping me if you need any radeon tests | 07:51 |
| duflu | mlankhorst: Can you think of a nicer way to detect the DMA-buf fix from userland, than comparing kernel versions? | 08:23 |
| duflu | RAOF: Can I get driver name from a drm fd? | 08:31 |
| === dholbach_ is now known as dholbach | ||
| duflu | Ah, drmGetVersion perhaps | 08:31 |
| RAOF | duflu: Yup. Are you after the kernel driver name or the mesa driver name? | 08:39 |
| duflu | RAOF: Either will do I guess | 08:39 |
| duflu | Just trying to figure out how/when the DRM version changed | 08:39 |
| RAOF | drmVersion will get the kernel name, which is fine. | 08:40 |
| RAOF | Won't get you a useful version number, though :) | 08:40 |
| duflu | RAOF: Has it changed at all recently? | 08:40 |
| RAOF | The version number? I don't think so. | 08:41 |
| duflu | I have to run. Sorry to leave you without much progress on the bugs... | 09:15 |
| alan_g | alf__: Do you want any more eyes on https://code.launchpad.net/~afrantzis/mir/session-events/+merge/180312? Or shall I top-approve? | 09:20 |
| alf__ | alan_g: I am OK, feel free to top-approve | 09:21 |
| mzanetti | hey, should mir_demo_server and mir_demo_client work on the Nexus 4? | 09:24 |
| mzanetti | The screen just stays black here | 09:24 |
| alan_g | mzanetti: they were working last time I looked (admittedly not this week). You are starting a mir_demo_client too? | 09:27 |
| mzanetti | alan_g: yes | 09:27 |
| greyback | alan_g: mzanetti is the second person with this problem. tsdgeos has it too | 09:28 |
| alan_g | greyback: mzanetti has a bug been logged? | 09:29 |
| tsdgeos | https://bugs.launchpad.net/mir/+bug/1211694 | 09:29 |
| ubot5 | Launchpad bug 1211694 in Mir "Black screen on Nexus4" [Undecided,Confirmed] | 09:29 |
| * alan_g hooks up N4 to try it out | 09:35 | |
| mzanetti | alan_g: thanks :) | 09:47 |
| === chihchun is now known as chihchun_afk | ||
| mzanetti | alan_g: I tried the exact same steps on a galaxy nexus. works fine there. so its really something on the Nexus 4. | 10:25 |
| mzanetti | alan_g: does it work for you? | 10:25 |
| alan_g | mzanetti: had to recharge N4 to use it. Still checking things with the image that's on it before reflashig | 10:27 |
| mzanetti | ok | 10:27 |
| === chihchun_afk is now known as chihchun | ||
| alan_g | Old and current mir versions works fine on the old image, reflashing... | 10:39 |
| === chihchun is now known as chihchun_afk | ||
| alan_g | alf__: Any ideas what might cause this? https://bugs.launchpad.net/mir/+bug/1211694/comments/4 | 11:38 |
| ubot5 | Launchpad bug 1211694 in Mir "Black screen on Nexus4" [Critical,Confirmed] | 11:38 |
| alf__ | alan_g: no, but I can pick up the investigation in an hour or so | 11:42 |
| alan_g | alf__: OK, I'll be off to lunch shortly - if I hit inspiration before then I'll let you know. | 11:44 |
| === alan_g is now known as alan_g|lunch | ||
| === dholbach_ is now known as dholbach | ||
| greyback | Hi folks, I reported this bug: https://bugs.launchpad.net/mir/+bug/1213047, but trying to use "apport-collect 1213047" returns no useful data, just the message "Package mir not installed and no hook available, ignoring" | 12:36 |
| ubot5 | Launchpad bug 1213047 in mir (Ubuntu) "[xmir] gnome-screenshot only gets black image" [Undecided,New] | 12:36 |
| smartboyhw | greyback, because you should pick a binary package to report I think | 12:36 |
| greyback | smartboyhw: yep, specifying a binary package helped, but a hook would be much more convenient for other users | 12:39 |
| === alan_g|lunch is now known as alan_g | ||
| ricmm | alan_g: ping | 13:49 |
| alan_g | ricmm: Hello | 13:49 |
| ricmm | morning o/, tvoss/racarr sent me to you for something | 13:50 |
| smartboyhw | tvoss_, hey, I asked if there's anything easy-peasy to fix and you didn't answer:P | 13:50 |
| ricmm | I need to pass from server to clients a Lifecycle event to trigger a higher level callback in the platform-api (clients) | 13:50 |
| ricmm | robert suggested using an interface like the under used for handle_display_config_change() | 13:50 |
| ricmm | s/under/one | 13:50 |
| tvoss_ | smartboyhw, sorry, got lost on the pile of things I'm doing right now | 13:51 |
| tvoss_ | smartboyhw, but I don't remember something off the top of my head | 13:51 |
| ricmm | but then there is also the general MirEvent with MirEventDelegate which I could extend with a new type of MirEvent | 13:51 |
| ricmm | what would you consider the best approach? my event right now just needs to pass a uint32 to identify the callback to issue | 13:51 |
| ricmm | later, it might have a couple more members | 13:51 |
| ricmm | one of those members might be a data stream, so protobuf bytes | 13:52 |
| ricmm | MirEvent might be a bit weak if I need to pass a stream to the client at some point | 13:53 |
| alan_g | ricmm: I have to look at how that stuff works to give a decent answer | 13:54 |
| ricmm | ah, who would be better to ask then? kevin? | 13:55 |
| ricmm | it was tvoss who suggested to ping you, robert actually asked me to try with the handle_() interface first | 13:55 |
| === dholbach_ is now known as dholbach | ||
| alan_g | There have been several versions (so I'm not sure what happens ATM) - I think duflu, racarr and kdub have worked on it. | 13:57 |
| ricmm | ok, ill follow roberts advise | 13:58 |
| Saviq | racarr, ping | 13:58 |
| ricmm | it just felt a bit overkill as the DisplayConfiguration class is rather large and complex, creates a quite nice protobuf message | 13:58 |
| ricmm | mine is just a single-member struct at the moment, with 2 more possible | 13:59 |
| ricmm | ill give it a shot and pass it for review | 13:59 |
| ricmm | Saviq: too early for him | 13:59 |
| Saviq | ricmm, I know, just hoping for him to pong as soon as he's back ;) | 14:00 |
| alan_g | ricmm: OK, if you're happy with that. (tvoss is remembering earlier in the project when I could track all the code changes.) | 14:03 |
| ricmm | alan_g: k, thanks for the help | 14:05 |
| racarr | Morning | 15:00 |
| racarr | ricmm: Saviq: pre pong. I will be back and awwake for real in 10 min though | 15:01 |
| Saviq | racarr, will be there! | 15:02 |
| Saviq | or here, actually | 15:03 |
| racarr | Saviq: ok back | 15:13 |
| Saviq | racarr, so, about https://bugs.launchpad.net/mir/+bug/1211694 | 15:14 |
| ubot5 | Launchpad bug 1211694 in Mir "Black screen on Nexus4" [Critical,Confirmed] | 15:14 |
| Saviq | racarr, can we help debug in any way? | 15:14 |
| Saviq | racarr, like give you ssh access to a device? | 15:14 |
| Saviq | racarr, did you try just flashing the latest cdimage-touch image and then the mir image? | 15:14 |
| Saviq | or just upgrading from the mir PPA if applicable? | 15:15 |
| racarr | Saviq: Oh sure. Uh no I did not try the mir image I just tried the PPA yesterday which was uninstallable | 15:15 |
| racarr | I tried building it | 15:15 |
| racarr | all | 15:15 |
| racarr | in it worked though | 15:15 |
| racarr | so I haven't been able to make any progress | 15:15 |
| racarr | maybe SSH access to a device would be good | 15:15 |
| Saviq | tsdgeos, would you be able to get racarr a broken device with ssh access? | 15:15 |
| Saviq | tsdgeos, broken as in "black screen on nexus4" | 15:16 |
| tsdgeos | i guess yes | 15:16 |
| tsdgeos | let me try | 15:16 |
| Saviq | racarr, sure, maybe something just requires rebuilding | 15:16 |
| racarr | Well | 15:16 |
| racarr | Maybe if it'scdimage + mir image | 15:16 |
| Saviq | racarr, but we don't know what that might be | 15:16 |
| racarr | then I should try again (I only tried PPA) | 15:16 |
| racarr | and I will be able to reproduce it | 15:16 |
| Saviq | racarr, that would be best, yeah, you know how to get that? | 15:16 |
| racarr | Saviq: tsdgeos Ok so one thing to check | 15:17 |
| racarr | is if the PPA is uninstallable | 15:17 |
| racarr | does that mean the image has the wrong packages too? | 15:17 |
| Saviq | racarr, it wouldn't build | 15:18 |
| racarr | by the PPA is uninstallable I mean dependency issues | 15:18 |
| Saviq | racarr, if you mean like unresolvable dependencies | 15:18 |
| racarr | force uninstall of unity8 | 15:18 |
| Saviq | racarr, and that seems to be the case indeed http://s-jenkins:8080/job/ubuntu-touch-phablet-image-saucy-mir/? | 15:18 |
| racarr | well | 15:18 |
| racarr | it has a version fight | 15:18 |
| racarr | but not unresolved | 15:18 |
| Saviq | racarr, so the last image built is from yesterday morning | 15:19 |
| Saviq | racarr, which built fine | 15:19 |
| Saviq | (last mir image, that is) | 15:19 |
| racarr | grr qalab vpn is broken | 15:20 |
| racarr | Saviq: I don't understand how it could build succesfully becuse | 15:20 |
| racarr | fresh install, then add phablet ppa | 15:20 |
| racarr | doesn't work as of yesterday | 15:21 |
| Saviq | racarr, yesterday morning | 15:21 |
| Saviq | racarr, as in 6am UTC | 15:21 |
| Saviq | racarr, vpn works for me | 15:21 |
| racarr | *starts flashing phone* | 15:27 |
| olli_ | racarr, needless to say, but this issue is starting to block more and more ppl and us in landing u8/mir... so pls work your magic :) | 15:33 |
| * olli_ hand racarr a triple espresso | 15:34 | |
| tsdgeos | racarr: did the ssh work now? | 15:36 |
| racarr | olli_: It seems to have become the fun of the day! | 15:38 |
| racarr | I just need to get to reproduce it | 15:38 |
| racarr | tsdgeos: Still no route eto host | 15:39 |
| tsdgeos | weird, was working for Saviq 5 min ago :-/ | 15:40 |
| tsdgeos | Saviq: does it work for you now? | 15:40 |
| racarr | tsdgeos: I am flashing a new image now with --wipe, then will try mir image instead of ppa | 15:40 |
| racarr | and it seems like that must reproduce it because | 15:40 |
| tsdgeos | oka | 15:41 |
| Saviq | racarr, tsdgeos +1, works | 15:41 |
| racarr | all nexus 4 are the same | 15:41 |
| racarr | Really? Why can't I ssh :( | 15:41 |
| tsdgeos | racarr: try again | 15:41 |
| tsdgeos | ? | 15:41 |
| racarr | oh there we go yeah | 15:41 |
| racarr | tsdgeos: sshed in and poking around..not totally obvious yet | 15:50 |
| racarr | by not totally obvious I mean totally unobvious lol | 15:50 |
| racarr | tsdgeos: I am installing the mir-demos package | 15:50 |
| racarr | just as a friendly I am installing packages on your phone warning XD | 15:50 |
| tsdgeos | racarr: sure, all yours | 15:51 |
| tsdgeos | just try not to hack on the rest of the network if possible :D | 15:51 |
| racarr | ok I am getting a strange error but I wonder | 15:51 |
| racarr | if it might be because I'm on ssh | 15:52 |
| racarr | tsdgeos: Wait was that do or don't | 15:52 |
| racarr | hack the rest of the network | 15:52 |
| racarr | :p | 15:52 |
| racarr | tsdgeos: http://pastebin.ubuntu.com/5993217/ | 15:52 |
| tsdgeos | errr wait | 15:53 |
| tsdgeos | is that the Nexus10 or the Nexus4 | 15:53 |
| racarr | ok surface flinger | 15:53 |
| racarr | is running right now | 15:53 |
| racarr | as well | 15:53 |
| racarr | is it the wrong device lol? | 15:53 |
| tsdgeos | no it's the nexus4 | 15:53 |
| tsdgeos | racarr: no it's the correct device | 15:53 |
| tsdgeos | i just was not trying to do any mir anymore | 15:53 |
| tsdgeos | so i went back to a working non mir image | 15:53 |
| tsdgeos | so yes, surface flinger is there | 15:54 |
| racarr | tsdgeos: Oh ok | 15:55 |
| racarr | in that case I just broke surface flinger | 15:55 |
| racarr | um I cant run mir_demo_server_shell still is the thing | 15:55 |
| racarr | I guess some sort of weird device node permissions | 15:55 |
| racarr | even as root | 15:55 |
| racarr | same no permission exception | 15:55 |
| racarr | ca you try running it locally? do you get that exception? | 15:56 |
| tsdgeos | let me see | 15:56 |
| tsdgeos | yeah, can't | 15:57 |
| tsdgeos | never got that | 15:57 |
| tsdgeos | reboot maybe? | 15:57 |
| racarr | Yeah lets try it | 16:00 |
| racarr | lemme know when its back | 16:00 |
| tsdgeos | racarr: back | 16:02 |
| racarr | tsdgeos: Is there anything onscreen? | 16:05 |
| tsdgeos | nope | 16:05 |
| tsdgeos | blackness | 16:05 |
| tsdgeos | well greyness | 16:05 |
| racarr | really thats too bad because its totally rendering at 60 fps lol | 16:05 |
| tsdgeos | :/ | 16:06 |
| racarr | tsdgeos: Still nothing? | 16:07 |
| tsdgeos | nope | 16:07 |
| tsdgeos | now it got blacker | 16:08 |
| racarr | mm killed the mir server | 16:08 |
| racarr | ugh I wish we had the render_to_fb demo | 16:09 |
| racarr | it seems though like | 16:09 |
| racarr | bringing up the display is working | 16:09 |
| racarr | client is connecting fine, perhaps even | 16:09 |
| racarr | bufferallocation, etc is working fine | 16:09 |
| racarr | well it is | 16:09 |
| racarr | but then | 16:09 |
| racarr | opengl just isnt producing | 16:09 |
| racarr | any results | 16:09 |
| racarr | I forget which | 16:11 |
| racarr | partition is the mir image? i.e. ho do I flash it | 16:11 |
| racarr | system, data...seems like system :p | 16:11 |
| racarr | ricmm: ^? | 16:11 |
| racarr | ok I think it is lashing now via bootloader thing | 16:17 |
| racarr | I am going to go walk around the block | 16:17 |
| racarr | HYPPPPPPPPEr | 16:17 |
| racarr | I dont have a black screen | 16:18 |
| racarr | so it cant have flashed very well :( | 16:18 |
| tsdgeos | :/ | 16:18 |
| racarr | ok no its just autodeploy.zip | 16:18 |
| racarr | doesnt work anymore | 16:18 |
| racarr | adb sideload it is! | 16:19 |
| tsdgeos | racarr: if yuo want i can tell you what i do | 16:19 |
| racarr | err...it doesn't work | 16:19 |
| racarr | tsdgeos: Yes! perfect | 16:19 |
| racarr | its just adb flash system/data *.zip right | 16:20 |
| racarr | but Ic an't remember if it's system or data | 16:20 |
| tsdgeos | racarr: http://paste.ubuntu.com/5993332/ | 16:21 |
| tsdgeos | this is not even using the unity-mir image anymore | 16:21 |
| tsdgeos | since that image i just the regular image + the ppas | 16:21 |
| tsdgeos | or so i've been told | 16:21 |
| tsdgeos | a reboot may be in order somewhere in the middle | 16:21 |
| racarr | :( I feel like that's just what I did | 16:21 |
| racarr | yesterday | 16:22 |
| racarr | maybe it's something silly like we have a color format bug | 16:22 |
| racarr | and nexus 4s made in october of 2012 return BGRA instead of RGBA as the first format | 16:22 |
| racarr | lol | 16:22 |
| racarr | I don't even know! | 16:22 |
| racarr | ok, back in 10 | 16:23 |
| ricmm | racarr: data partition | 16:23 |
| ricmm | tsdgeos: can you get someone else to try? | 16:23 |
| ricmm | chicken has a nexus 4 | 16:23 |
| tsdgeos | ricmm: mzanetti tried doing extractly the same on the nexus4 and on the gnexus | 16:24 |
| tsdgeos | can confirm the gnexus works and the nexus4 not | 16:24 |
| * mzanetti confirms | 16:24 | |
| tsdgeos | as written in the bug | 16:24 |
| ricmm | so what the hell is going on with robert's n4 | 16:24 |
| ricmm | what is the *exact same thing* | 16:24 |
| ricmm | updating from the ppa? or installing the image | 16:25 |
| tsdgeos | ricmm: the exact thing is doing the same on both devices | 16:25 |
| tsdgeos | ricmm: you'll have to ask him what he did | 16:25 |
| ricmm | oh I meant the exact same thing from your device to his | 16:27 |
| ricmm | I know what exact same thing means :) | 16:27 |
| mzanetti | ricmm: http://paste.ubuntu.com/5993351/ | 16:27 |
| mzanetti | ricmm: did exactly the same steps on a GNexus and a Nexus4 | 16:27 |
| ricmm | ok | 16:28 |
| ricmm | what version of mir do you have on the n4 | 16:28 |
| * mzanetti boots the Nexus 4 | 16:28 | |
| olli_ | alan_g, is usc in lp:mir? | 16:29 |
| alan_g | olli_: no | 16:29 |
| mzanetti | ricmm: Installed: 0.0.9+13.10.20130813-0ubuntu1 | 16:29 |
| mzanetti | this is mir-demos. need any other packages? | 16:30 |
| alan_g | olli_: lp:unity-system-compositor | 16:30 |
| olli_ | alan_g, thx! | 16:31 |
| Saviq | tsdgeos, racarr, gtg, will be back later this evening if you have any updates | 16:32 |
| racarr | ah stretching my legs felt good | 16:33 |
| racarr | wasnt olli saying something about how instead of fixing the nexus 4 I should walk to the ocean... | 16:33 |
| racarr | :p | 16:33 |
| racarr | ok | 16:34 |
| racarr | mir image produces a black screen of death... | 16:34 |
| tsdgeos | racarr: i need to do some real life stuff, my phone's still connected, if you reboot it, it ought to come back with the same ip... | 16:35 |
| tsdgeos | be back in two hours if nothing happens | 16:35 |
| racarr | tsdgeos: Cheers. Thanks :) | 16:37 |
| racarr | hopefully ill figre it out | 16:37 |
| ricmm | racarr: maybe something changed permissions-wise | 16:38 |
| ricmm | at the udev level, in the container | 16:38 |
| ricmm | can you strace the server? it might be failing to acquire something | 16:38 |
| ricmm | silently | 16:38 |
| racarr | ricmm: Seems like it must be... | 16:38 |
| racarr | oh good idea! | 16:38 |
| racarr | but still this doesn't make any sense | 16:39 |
| racarr | because the matrix looks like | 16:39 |
| racarr | tsdgeos: Building mir on latest image (fails), adding ppa on latest image (fails), using mir image (fails) | 16:39 |
| racarr | where for me it's building mir on latest image (suceeds), adding PPA (suceeds), using mir image (fails) | 16:40 |
| racarr | lol so many errors | 16:41 |
| racarr | the linking setup on phablet seems to be werid | 16:41 |
| racarr | its looking for every library in like | 16:41 |
| racarr | ten directories with weird numbers | 16:41 |
| racarr | before finding them | 16:41 |
| racarr | in /usr/ilb | 16:41 |
| racarr | ioctl(13, 0xc0f86d87, 0xbef5fef0) = -1 ENOMEM (Cannot allocate memory) | 16:45 |
| racarr | writev(8, [{"\6", 1}, {"hwcomposer\0", 11}, {"Failed to call ioctl MSMFB_OVERL"..., 66}], 3) = 78 | 16:45 |
| racarr | writev(8, [{"\6", 1}, {"hwcomposer\0", 11}, {"init: Failed to setup primary ba"..., 40}], 3) = 52 | 16:45 |
| racarr | writev(8, [{"\4", 1}, {"hwcomposer\0", 11}, {"Initializing Qualcomm Hardware C"..., 40}], 3) = 52 | 16:45 |
| racarr | writev(8, [{"\4", 1}, {"hwcomposer\0", 11}, {"MDP version: 440\0", 17}], 3) = 29 | 16:45 |
| racarr | that doesn't look great | 16:45 |
| ricmm | racarr: indeed, compare with your working scenario | 16:45 |
| ricmm | cleaning lady about to mop the whole house, so will be away for a bit | 16:46 |
| ricmm | lunch | 16:46 |
| racarr | Ok, see you soon | 16:48 |
| racarr | have to figure out a way to get my working scenario without iping back and forth all day lol | 16:48 |
| racarr | wiping | 16:48 |
| === alan_g is now known as alan_g|EOD | ||
| olli_ | alf__, ping | 17:21 |
| tvoss_ | ricmm, racarr ping | 20:46 |
| === bschaefer_ is now known as bschaefer | ||
| ricmm | tvoss_: sup | 20:50 |
| tvoss_ | ricmm, just wanted to check if I can help with the nexus4 issue? | 20:50 |
| ricmm | tvoss_: oh, well not sure how far rob got | 20:51 |
| ricmm | I dont have a nexus4 and im knee-deep into the mir work | 20:52 |
| tvoss_ | ricmm, ack | 20:52 |
| ricmm | so no idea where we stand | 20:52 |
| tvoss_ | ricmm, ack | 20:52 |
| tvoss_ | will wait for racarr to come back then | 20:52 |
| ricmm | ok | 20:52 |
| racarr | tvoss_: Oh Ive been here sorry | 21:03 |
| racarr | it didn't sho up as a ping | 21:03 |
| racarr | tvoss_: so I'm actively 'making progress' at discovering facts | 21:04 |
| racarr | but I can't make anything consistent out of what I have igured out so far | 21:04 |
| tvoss_ | racarr, mind walking me through what you are uncovering? | 21:04 |
| racarr | tvoss_: Ok. So, yesterday, just building mir and the stack on a clean nexus 4 I flashed worked | 21:05 |
| racarr | likewise this morningm it worked, but once you install the mir image, it breaks | 21:05 |
| racarr | everything seems to run | 21:05 |
| racarr | but things are just black | 21:06 |
| racarr | err, ok so I mentioned all those details about the stack because | 21:06 |
| racarr | tsdgeos built it on a normal image and it seemed to not ork | 21:06 |
| racarr | anyway, so things are all black, no errors or anything | 21:06 |
| racarr | but there is this suspiscious result from strace on mir_demo_server | 21:07 |
| racarr | 16:46 < racarr> ioctl(13, 0xc0f86d87, 0xbef5fef0) = -1 ENOMEM (Cannot allocate memory) | 21:07 |
| racarr | 16:46 < racarr> writev(8, [{"\6", 1}, {"hwcomposer\0", 11}, {"Failed to call ioctl MSMFB_OVERL"..., 66}], 3) = 78 | 21:07 |
| racarr | 16:46 < racarr> writev(8, [{"\6", 1}, {"hwcomposer\0", 11}, {"init: Failed to setup primary ba"..., 40}], 3) = 52 | 21:07 |
| racarr | 16:46 < racarr> writev(8, [{"\4", 1}, {"hwcomposer\0", 11}, {"Initializing Qualcomm Hardware C"..., 40}], 3) = 52 | 21:07 |
| racarr | 16:46 < racarr> writev(8, [{"\4", 1}, {"hwcomposer\0", 11}, {"MDP version: 440\0", 17}], 3) = 29 | 21:07 |
| racarr | tvoss_: So then I built mir | 21:08 |
| racarr | same results, but different strace errors interestingly enough | 21:08 |
| racarr | http://pastebin.ubuntu.com/5994179/ | 21:08 |
| racarr | there is this error on ioctl to fd 8 | 21:09 |
| racarr | which, as ar as I can tell from the strace logs is | 21:09 |
| racarr | /dev/socket/property_service | 21:09 |
| racarr | so, something has gone wrong with udev (except it doesn't seem to be udev) or apparmor (Except I unloaded apparmor) or permissions (except as root) | 21:10 |
| racarr | so I am guessing it is some sort of LXC environemtn thing I don't understand yet | 21:10 |
| racarr | what im currently doing is | 21:10 |
| racarr | 55% through building mir on hat I expect to be a working nexus 4 image | 21:10 |
| racarr | so I can | 21:10 |
| racarr | compare the strace logs | 21:10 |
| racarr | anyway though my leading theories are weird permissions on video devices, or this /dev/socket/property_service | 21:11 |
| racarr | but, again, it's not a "permission" so there is some other system coming in to play | 21:11 |
| racarr | or, I as wondering if the ENOMEM could have been meaningful | 21:11 |
| racarr | i.e. there was some restriction on the size of processes mapped address space through some system limit | 21:12 |
| racarr | and mapping the framebuffer isn't working | 21:12 |
| racarr | that seems | 21:12 |
| racarr | absurd | 21:12 |
| racarr | so im basically just waiting on the build right now | 21:12 |
| tvoss_ | racarr, ack | 21:12 |
| racarr | tvoss_: Oh I guess the other thing | 21:14 |
| racarr | is buffer swapping definitely works, the hwole IPC layer, input, everyone thinks they are happy | 21:14 |
| racarr | and the integration-tests pass, so OpenGL really renders | 21:14 |
| racarr | so either 1. The Framebuffer is broken or 2. GL is broken on the server side | 21:14 |
| racarr | but everything else is pretty much ruled out | 21:15 |
| racarr | there was some weirdness | 21:15 |
| racarr | about clients sometimes | 21:15 |
| racarr | getting reduced FPC | 21:15 |
| racarr | i.e. when I as testing clients it as either | 21:15 |
| racarr | 60 fps | 21:15 |
| racarr | 30 fps | 21:15 |
| racarr | or 1-2 fps | 21:15 |
| racarr | we use the HWC for vblank symbols | 21:16 |
| racarr | so it seems tied in | 21:16 |
| racarr | but very strange | 21:16 |
| tvoss_ | hmmm ... | 21:19 |
| racarr | tvoss_: One way or another the spinning triangle will come back ;) | 21:25 |
| tvoss_ | racarr, yeah, we need it ... | 21:26 |
| tvoss_ | it all started with it :) | 21:26 |
| racarr | tvoss_: It's so anticlimatic sometimes because it was so gradual XD | 21:29 |
| racarr | if you had asked me back in copenhagen what things would have been like, when it was finally time to land mir on the phone | 21:29 |
| tvoss_ | racarr, indeed :) | 21:29 |
| racarr | I feel like I was imagining like fireworks, peace on earth | 21:29 |
| racarr | goodill to all men, etc | 21:29 |
| racarr | but, it just sort of happens eventually | 21:30 |
| racarr | XD | 21:30 |
| racarr | and everything else is still the same | 21:30 |
| racarr | I got pretty stressed about all of it for a while ;) | 21:30 |
| tvoss_ | racarr, that's the beauty of it :) it just happens | 21:33 |
| racarr | tvoss_: XD ok my build finished | 21:37 |
| racarr | the one that was supposed to ork like it did this morning, i.e. flashing the latest image and building trunk | 21:37 |
| racarr | ERROR: /home/phablet/src/trunk/src/server/graphics/android/android_framebuffer_window.cpp(75): Throw in function virtual void* mir::graphics::android::AndroidFramebufferWindow::android_display_egl_config(EGLDisplay) const | 21:37 |
| racarr | Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> > | 21:37 |
| racarr | std::exception::what: could not select EGL config for use with framebuffer | 21:37 |
| tvoss_ | racarr, that's just weird ... | 21:38 |
| racarr | ok and integration-tests fail all over | 21:38 |
| tvoss_ | did libhardware change? | 21:39 |
| racarr | well test_accelerated_render hangs | 21:40 |
| racarr | seems like | 21:40 |
| racarr | it must have somewhere | 21:40 |
| racarr | or | 21:40 |
| racarr | some permissions are causing things to fail | 21:40 |
| racarr | inside libhardare | 21:40 |
| racarr | straceee | 21:40 |
| racarr | except network doesn't work anymore and I can't install strace....XD | 21:42 |
| racarr | reboot fixed it | 21:43 |
| racarr | *rambles* | 21:43 |
| racarr | ok also | 21:44 |
| racarr | after reboot | 21:44 |
| racarr | I don't get that EGL confic | 21:45 |
| racarr | g | 21:45 |
| racarr | exception anymore | 21:45 |
| racarr | but nothing on screen | 21:45 |
| racarr | it's this | 21:45 |
| racarr | ioctl(8, 0xc0f86d87, 0xbee5c110) = -1 ENOMEM (Cannot allocate memory) | 21:45 |
| racarr | again | 21:45 |
| racarr | oh the ENOMEM isn't on the properties_service it's | 21:46 |
| racarr | open("/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 8 | 21:46 |
| racarr | ok so | 21:47 |
| racarr | writev(3, [{"\6", 1}, {"hwcomposer\0", 11}, {"Failed to call ioctl MSMFB_OVERL"..., 66}], 3) = 78 | 21:47 |
| racarr | is the error for this ENOMEM and it matches up in dmesg to this thing [ 102.204578] msmfb_overlay_set: ioctl failed, rc=-12 | 21:47 |
| tvoss_ | racarr, right, seems like a memory limitation is hit | 21:48 |
| racarr | tvoss_: https://jira.cyanogenmod.org/browse/CYAN-1260 | 21:50 |
| racarr | how obscure | 21:50 |
| racarr | not exactly | 21:50 |
| racarr | but close | 21:50 |
| racarr | well the errors are exactly but why does using disk encryption trigger it in cyanogen mod | 21:50 |
| racarr | and it being friday trigger it on ubuntu touch :p | 21:51 |
| racarr | tvoss_: Is there an easy way to build Android.mk stuff from isnide the chroot or something | 21:52 |
| racarr | I want to try this liboverlay | 21:52 |
| racarr | ok its a worthwile test to see i things worked unsynced without | 21:54 |
| racarr | HWC to | 21:54 |
| racarr | narrow EGL out of the possibilities | 21:54 |
| ricmm | tvoss_: this problem isnt hit on surface flinger | 21:56 |
| ricmm | mir only | 21:56 |
| ricmm | so it has to be some sort of permissions thing | 21:56 |
| ricmm | check lxc-android-config for the udev rules | 21:57 |
| ricmm | maybe something changed recently | 21:57 |
| racarr | lxc-android-config that is | 21:57 |
| racarr | exactly hat I was looking for earlier but didnt know what it was :) | 21:57 |
| ricmm | https://code.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy-proposed | 21:58 |
| ricmm | shit | 22:01 |
| ricmm | where did my client library code go | 22:01 |
| ricmm | :( | 22:01 |
| racarr | non HWC mode doesn't get anything | 22:03 |
| racarr | on the screen either | 22:03 |
| racarr | except no apparent errors in strace and FPS is unbound | 22:03 |
| racarr | can't find any lxc-android-config things yet but exploring | 22:06 |
| tvoss_ | ricmm, did we upgrade anything in the android side of things? I do see adjusted permissions for certain devices | 22:07 |
| ricmm | im not aware of any updates | 22:08 |
| ricmm | ogra is the best one to ask about those | 22:08 |
| racarr | ogra_: Ping if you happen to come by :) | 22:09 |
| racarr | the only perhaps relevant ulimit is max locked memory (kbytes, -l) 64 | 22:16 |
| racarr | what sort of access control things are there besides | 22:16 |
| racarr | posix permissions, apparmor, limits, and LXC | 22:17 |
| racarr | android magic? | 22:17 |
| racarr | this time the whole phone crashed :( | 22:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!