[03:46] would it be possible to run Ubuntu ARM on a EP93XX? They have ARMv920t processors with MaverickCrunch FPUs, although I wouldn't mind not being able to use the FPU. [03:59] debio264: Do you know which ARM instruction set those implement? A quick web search isn't answering this for me. [04:00] they run EABI, I know that much [04:00] beyond there, it's ARMv9 [04:00] not sure what you mean [04:01] I think ARM9 is ARMv5, but I'm not 100% sure. [04:01] Basically, there are several revisions of the ARM core (e.g. ARM9, ARM11, etc.) [04:01] And there are several revisions of the instruction set (e.g. ARMv5, ARMv6, etc.) [04:01] I'm not 100% sure of the mapping, although I remember wikipedia having a decent entry about it. [04:02] well, the Debian armel port apparently runs on these boards [04:02] But if it is ARMv5, then you would only be able to run Ubuntu 9.04, as 9.10 requires ARMv6 and 10.04 will require ARMv7. [04:02] I'm reading up on that [04:02] Debian armel is ARMv4 [04:02] ah [04:03] It's very loosely parallel to the differences between 486, 586, 686, etc. (but the specifics are completely different) [04:03] are there any plans to change the armel minimum instruction set? [04:03] There have been plans to do that for each release, but always in the direction of only supporting newer instruction sets, so it's unlikely that ARMv5 will be supported in future versions. [04:04] no, I mean on the Debian side [04:04] (I've already been stung by the Ubuntu changes as my ARMv5 Sheevaplug used to run Jaunty) [04:05] I guess I'm probably better off with Debian, actually, if the Ubuntu requirements are going to keep rising [04:07] I have heard some vague rumours that Debian may move to ARMv5 at some point, but nothing concrete, and I don't expect that would happen until there were vanishingly few devices still working that required ARMv4 [04:07] But yeah, if you're using ARMv5 devices, Debian is probably going to be more satisfying. [04:10] persia: okay, thanks for your help === asac_ is now known as asac [09:17] JamieBennett: In your casper perf branch, I think you can replace the "chroot /root cat " with just "cat " [09:18] Thanks for looking lool. The branch doesn't work at the moment as I got pulled of it for something else so there are probably other fundamental errors too but it gives an idea of the direction. [09:30] wow [09:31] * ogra just does the first SATA install on his babbage [09:31] ? [09:31] Bit faster that way, is it? [09:31] with a side-by-side resizing variant [09:31] i dont expect it to be much faster since its still routed through USB, but that everything just works is impressing :) [09:32] even though ... [09:32] it seems to be faster ... 32% after 2 min is something i havent seen yet [09:32] (32% of copying files) [09:33] 41 now [09:33] hmm,. its definately faster [09:33] USB isn't usually the bottleneck, it's that most people who install to "USB" are installing to flash, and the FTL tends to be slow. [09:33] i never managed to get more than 20MB/s throughput [09:34] ogra: very happy to know that [09:34] no matter if the attached disk was usb or sata [09:34] ogra: writing to what media? [09:34] persia, doesnt matter [09:34] rotary sata vs usb key [09:34] both always had the same speed [09:34] hrm. It ought to have mattered. rotary SATA *should* be faster than flash for bulk write. [09:34] that doesnt seem to be the case anymore [09:34] asac: You said in #506761 that you bumped the partition size; I guess the vfat one? Looks like another bug in the uboot vfat code (was already broken with fat16 versus 32) [09:35] 48% after 5 min install time is definately a new record though [09:36] lool, he said that at 6am ... i bet he'S asleep ;) [09:36] :) [09:37] wow, even the slideshow survived until 53% ... it is usually done at 15 :) [09:37] I think I nailed ffmpeg [09:37] \o/ [09:39] god that install is fast ... [09:42] 80% after 12min ! [09:42] * ogra wishes he had not chosen a german install ... downloading langpacks will slow everything down [10:12] ok, that was 42min ... (vs 75min in karmic to a USB key) ... lets see if it boots now :) [10:13] Probably your USB key isn't as fast as a hard disk though [10:14] There is a difference between SATA on board and over USB in my experience, but not big [10:14] at least on b2.5 [10:16] well, but 30min ? [10:16] i did SATA installs before in karmic (that couldnt start gdm) [10:16] they were not that fast [10:17] It's kind of a pitty that I can't dchroot on the porter box [10:18] why ? [10:18] It fails [10:18] are you using the right runes ? [10:18] ogra: Try it out :-) [10:18] I think cjwatson ran in the same issues when he looked into qt4-x11 [10:18] there was a trick i forgot about (since i never used the porter box) [10:18] something like dchoot -l lucid ? [10:19] or -c lucid ... dont know anymore [10:19] ogra: Try it! [10:19] It just aborts with a mutex assertion [10:19] I'm pretty sure we hadit in the past, but it would still login [10:20] yeah, that was the issue you can work around with the option [10:20] I bet our kernel is too old [11:05] Has anyone been getting slow networking with the new imx51 kernel? I'm now getting only ~100kB/s and package updates take an age. [11:05] I'm not sure if the kernel upgrade caused this, but my other boards are fine [11:05] works fine here, i'm just installing chromium [11:05] weird... maybe it's caused by something else [11:06] though i switched to a usb wlan key after about 1h but didnt notice any slowness before [11:06] I'll assume it's not a problem for now; I'll see if it keeps happening. [11:07] i'm using a fresh install from the 12.2 image though ... [11:07] might be userspace if you see it on an upgraded system [11:07] Does that work? I rsync'd it, but hadn't got as far as trying it yet... [11:08] works awesome, i just installed to a SCSI disk in about 40min [11:08] lots faster than the usb/karmic installs i tried [11:08] The casper improvements? [11:08] no, the SCISI driver :) [11:08] *SCSI [11:09] Oh... I don't have a board I can use that with yet :( [11:09] it boots as slow as before, i dont think JamieBennett uploaded the new casper changes yet [11:09] Oh, right. Well I'll look forward to those [11:09] though the install boots in about 30secs [11:10] the disk throughput really changed [11:10] When you say 30 secs, is that to gdm login, or to the desktop? [11:10] I had 80 secs to the desktop on 20100108, booting from SD [11:10] autologin to the desktop on third boot [11:10] asac: Pulled firefox-3.6, and trying the benchmark now. It seems to be working better than ff3.5 [11:11] hmm, hdparm disagrees with my personal feeling [11:11] Timing buffered disk reads: 54 MB in 3.05 seconds = 17.71 MB/sec [11:11] thats not a high throughput [11:11] ogra: I'll be working on that next week but there is an initial branch for casper changes at https://code.edge.launchpad.net/~jamiebennett/casper/debconf-speedup-work [11:12] not quite working yet though [11:14] yeah, i would have been surprised if it had made A2 [11:16] The pieces are there they just need putting together when I get time :) [11:16] yeah [11:17] When ogra said "it's faster" I just jumped to conclusions ;) [11:17] :) [11:22] chromium feels a lot smoother than FF ... i'm curious if the benchmarks will agree [11:24] ogra: if i wanna to try chromium on my board, need i add a PPA, right? [11:26] cooloney, see other channel ... [11:26] phew, scrolling in software center is unusably slow [11:26] * ogra installs banshee for the fun of seeing it crashing [11:27] * JamieBennett assign's ogra the "[jamiebennett] Banshee on ARM: TODO" task ;) [11:27] haha [11:27] no, thanks, i had that long enough during karmic :P [11:27] :D [11:28] but who knows, probably it magically works now ... [11:30] ogra: bug 506910 - Is that in the installed system or on the live-cd? [11:30] JamieBennett: Bug 506910 on http://launchpad.net/bugs/506910 is private [11:34] (if it ever finishes to install :P ) [11:34] hmm, audioCD and hardwareManager instances throw exceptions ... [11:34] UI comes up but then it crashes ... as it was in karmic [11:34] * JamieBennett changes that TODO to DONE now then ;) [11:37] JamieBennett, both [11:37] it persists after install [11:37] oh, funny [11:37] i had my headphone plugged to the mic input [11:37] that actually generates mono output [11:38] ogra: OK, its to be removed from the seeds after the alpha's [11:38] indeed [11:38] though someone (upstream) should really look into pybootchartgui [11:38] Indeed [11:38] its so broken on all arches [11:44] dmart, ok, i switched back to wired, wget'ing http://cdimage.ubuntu.com/ports/daily-live/20100112.2/lucid-desktop-armel+imx51.img gets me "358K/s ETA 30m 36s" seems to be fine [11:45] * ogra will leave it running for a while to see if the value persists [11:45] ok [11:46] note that i'm running the latest kernel from the archive, not cooloney's new test kernel yet [11:47] same here [11:47] ok [11:59] dmart: thanks [12:01] ogra: did you try the new uimage script? [12:01] that works [12:01] or didnt you read all my bug comments ;) [12:01] i will close the bug now if you dont say it doesnt work [12:06] Is anyone else seeing weird window corruption since the last xorg update? [12:07] My first guess was that there was a pixman bug, but pixman hasn't been rebuilt since last November [12:09] dmart: Someone reported it here on beagle [12:10] dmart: Someone else mentionned this was a kernel vfp state corruption for which the patch was pending a merge upstream [12:10] Do you know whether there's an lp bug? I have some xwds I could attach. [12:11] freenode-#ubuntu-arm-20100104.log:11:05 < ssvb> cwillu_at_work: for pixman it means that the signal handler responsible for input handling may corrupt NEON registers and as these are used for processing pixel data, it results in image artefacts which look as horizontal stripes [12:12] 09:00 < ssvb> lool: but I know for sure that such problem existed with problematic kernels and it resulted in a similar looking artefacts on screen [12:12] dmart: 10:35 < ssvb> lool: here is a testcase for kernel bug: http://siarhei.siamashka.name/files/20100104/test-sighandler-vfp-corruption-bug.c [12:12] I'm using babbage2 though... is CONFIG_NEON enabled in the kernel? Pixman should not be using NEON. [12:13] ...which leads to an interesting question: how do we handling enableing NEON on babbage3 but not on babbage2.x ? [12:14] dmart: that was supposed to be achieved as a kernel patch [12:14] But dont think anybody worked on that [12:14] dmart: do you have any first results from the benchmark yet? [12:15] like a rough direction? [12:16] Rough answer is that ff3.6 works and is maybe 30% faster than ff3.5 on this benchmark. [12:16] But chromium is up to ~90% faster than ff3.5 [12:16] ok cool [12:16] (The ff3.5 used in this comparison is ARM and karmic though, not T2 and lucid) [12:16] and mem consumption is sinmlarly better than 3.6? [12:16] yeah [12:17] anyway, looking forward to get the results :) [12:17] Don't know about that; we don't measure it. Is there a way to capture the peak memory use of a process? [12:17] I'll send a mail with more detail. [12:17] hmm [12:17] good question [12:17] i would be more interseted in memory if you open like 100 tabs in both [12:18] OK, I can try to do that. What figure would you use? The virtual memory load? [12:19] thats a good question ... folks usually look at RES mem [12:21] maybe not a real accurate figure, just understanding if either firefox or chromium make your system creep earlier would be helpful [12:28] creep or thrash? [12:32] depends on the load i guess ;) [12:43] lool: do we know for sure that there is a signal handler using VFP/NEON, and do we know where it is? [12:46] lool: Also, how do I see the IRC log? If I go to #ubuntu-arm-20100104.log:11:05 I just see an empty channel. [12:53] dmart: check if the log here is better: http://irclogs.ubuntu.com/2010/01/04/ [12:53] * asac lunch [12:53] Better, thanks. [12:55] asac, i havent tried your script yet, will doso now [12:59] dmart: Probably just my tz is one hour delta [12:59] lool: It may make sense that switching to another pixman resolves the corruption problem: pixman-0.14.x (karmic) doesn't have the NEON support so cannot fall victim to the neon state corruption. [12:59] dmart: That's my personal log, as asac pointed out, we have irclogs.u.c [12:59] #ubuntu-arm-20100104.log:10:05 [12:59] I use my logs for grepping [12:59] ...no, I don't see anything there either [12:59] dmart: Yes, it turned out to be a kernel bug in that case [13:00] dmart: http://irclogs.ubuntu.com/2010/01/04/%23ubuntu-arm.html you don't see the conversation on pixman? [13:00] Sorry... yes, on irclogs.ubuntu.com, I see it. [13:00] dmart: I certainly see the conversation at 10:05am in the log [13:00] The other isn't a real channel, just a local file [13:01] Ah [13:01] the other? [13:01] lool: The problem described is that the VFP/NEON regs are not saved and restored around signal handlers... but it still sounds unusual to use those features in a signal handler. Do we know where it's happening? [13:01] #ubuntu-arm-20100104.log:10:05 [13:01] That's my local log file [13:01] whats that? [13:01] yeah [13:01] but why does dmart have that ;)? [13:01] anyway. i am really out for lunch now [13:01] dmart: Well the patch would probably tell you; let me see [13:01] He doesn't: hence the confusion :) [13:02] Some random userspace app must have fp code in a signal handler? if so, the kernel patch won't explain where [13:02] dmart: http://www.spinics.net/lists/arm-kernel/msg67148.html [13:03] dmart: Oh dunno, I guess you could grep for signal() in pixman? [13:03] Or in xorg-server; I really have no idea which signal that is [13:04] It could be that some signal code gets built with cflags triggering the use of this code [13:04] Hmmm, maybe it would be hard to find out. [13:04] Maybe there are some apps which call pixman funcs from inside signal handlers. [13:05] dmart: This might be OMAP specific though [13:05] http://www.spinics.net/lists/arm-kernel/msg78429.html [13:06] Yes, there's two issues: VFP/NEON save-restore around signal handlers, and save-restore around pm suspend. I don't think they're OMAP-specific. [13:07] asac, did you test with dmart's uInitrd already ? [13:07] dmart, do you have the mkimage command handy you used to create that uInitrd ? [13:08] Sadly not... but it would have been something very similar to: [13:08] ogra: ónly kernel [13:09] mkimage -A arm -T initrd -C none -O linux -a 0x90800000 -d initrd.gz initrd.uImg [13:09] ogra: the mkimage is trivial [13:09] * ogra wonders if there is dirt on his screen or asac started speaking french [13:09] dmart: sure it needs the -a? [13:09] Kernel would be: [13:09] ogra: i have the same dirt ;) [13:09] heh [13:09] mkimage -A arm -T kernel -C none -O linux -a 0x90008000 -e 0x90008000 -d zImage uLinux [13:10] ok, i'll try with these [13:10] 0x90008000 was chosen to match what the linux/arch/arm/ makefiles to for babbage, but 0x90800000 was an arbitrary choice which seems to work. [13:10] yeah [13:11] ogra: try the script first ;) .. then we can look at initrd [13:11] argh [13:11] afaiu the -a isnt really needed :) [13:11] why do we use initrd.lz everywhere [13:11] but if its help, we are set [13:11] sigh [13:12] ogra: pick it from an install [13:12] there its a gzip [13:12] i want the live initrd [13:12] -a probably isn't needed for initrd; I couldn't remember [13:12] yes [13:12] just uImage [13:12] ogra: unpack it ;) [13:12] and pack it [13:12] gzipped or non-gzipped initrd should work, but I only tried gzipped. I never use U-Boot's own compression for this (but it probably works) [13:13] dmart, we now use lzma ... not gzip anymore [13:13] * ogra sighs about another special case we'll have to apply to armel image [13:13] s [13:13] ogra: should be easy to repack [13:13] asac, thats not the point [13:13] what is the point? [13:14] we have to maintain every special case on treh build machine in separate code [13:14] *the [13:14] you can repack in debian-cd ;) [13:14] hmmm... well I think I just pulled an initrd.bin image from karmic. Maybe is was lzma, maybe gz? [13:14] ogra: no. we can just repack when producing the mkimage ... in debian-cd [13:14] asac, yes, thats the point, extra code that misses changes made for other arches [13:14] thats not really special casing [13:14] ogra: we run mkimage there [13:14] its one more command [13:14] thats not a deal [13:14] if all other archs would use uboot, i would agree [13:15] Um, is there a reason we can't use lzma? [13:15] but that code is special cased already [13:15] still more extra code [13:15] persia: uboot doesnt support it [13:15] asac: And that can't be fixed easily? [13:15] ogra: i can write you that extra code ;) [13:15] persia, i doubt anyone every added it to uboot [13:15] and maintain it ;) [13:15] persia: we can make that a lucid+1 project [13:15] asac, its just that we try to keep the delts as small as possible [13:15] *delta [13:15] Linux will decompress the initrd: U-Boot doesn't need to understand it (surely?) [13:15] Yes [13:15] also uboot needs to be small [13:15] * persia thinks it's even odds adding it to uboot or the build scripts, and prefers consistency with other architectures for documentation advantages. [13:16] ogra: you miss the point [13:16] the +armel is separate anyway [13:16] its no maintainence overhead to modify that [13:16] The code to uncompress/interpret the initrd is in the kernel for sure [13:16] anyway [13:16] dmart: Good point. [13:16] we have no choice ;) [13:16] so not worth discussing [13:16] asac, no, it uses tons of existing non-arch specific scripts [13:16] asac: Except lool and dmart seem to imply that it doesn't matter how it's compressed. [13:16] U-Boot has its own image compression code, but it's redundant because Linux is more flexible :) [13:16] if it doesnt matter i am fine [13:16] and with these we just inherit changes made by the platform team [13:17] ogra: Let's do that then, and just use lzma. We don't need uboot to decompress it. [13:17] right, if it works i dont care, if we have to repack anything i'm unhappy [13:17] OK. Does it work? [13:17] It might be slower to use lzma though [13:17] Worth pointing out that you may need pass -C none to mkimage to make sure U-Boot doesn't do its own decompression pass [13:17] (someone with lucid-capable hardware should test) [13:17] Anyway, /me goes preparing for bunch of meetings [13:17] ogra: if we have to repack dont be unhappy. thats a one liner ;) [13:17] in a 100 lines arch specific file [13:17] anyway. i stop [13:17] ttyl [13:18] asac, one we have to care for, out of sync with the rest of the distro [13:19] It's not worth arguing about. One or the other of you should test passing "-C none" to mkimage to verify we don't need to care. [13:22] asac, boots (and dies with an oops at the end) [13:27] asac: 10:34 < lool> asac: You said in #506761 that you bumped the partition size; I guess the vfat one? Looks like another bug in the uboot vfat code (was already broken with fat16 versus 32) [13:27] ogra: kernel boots and oopses? What's the oops? [13:27] hey guys, since versatile arch came back in lucid, can i use qemu to test versatile lucid image now? [13:27] Maybe we have the wrong kernel options? [13:27] cooloney: Sure [13:27] Not sure we enabled the d-i arch though [13:27] *subarch rather [13:28] cooloney: If there's a versatile kernel, you ought be able to use it, but you're in a better position than most to tell if the versatile kernel is correct :) [13:29] https://wiki.ubuntu.com/ARM/QemuNetInstall is quite out of date [13:29] cooloney: however you cant use it to test *images* [13:29] lool, asac, persia: I didn't play much with fat myself. It would be handy if someone added ext4 support to uboot, but I don't think there's any plan to do it yet. [13:29] The images are meant to boot on this or that hardware [13:29] persia: frankly, i do not know where is versatile kernel [13:29] in practice, the images might be usable with special incantations though [13:30] cooloney: In the versatile .deb [13:30] Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 ip=off [13:30] lool: ok, got your [13:30] * ogra wonders where that comes from [13:30] its not in printenv [13:31] That explains the oops, at least. [13:31] ogra: that command line should be in the UBOOT code [13:32] lool: do you know the URL of the versatile .deb? [13:32] cooloney: https://launchpad.net/ubuntu/lucid/armel/linux-image-2.6.32-10-versatile/2.6.32-10.14 [13:32] Ah I was searching in main [13:32] lool: thx, a lot. [13:34] I cant find it on ports, weird [13:35] lool: no problem, thx [13:35] http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.32-10-versatile_2.6.32-10.14_armel.deb [13:35] Stupid proxy [13:38] hmm, kernel doesnt find the ramdisk [13:39] Does the kernel have lzma support? [13:39] its the one from the live image [13:39] so yes [13:42] RAMDISK: Couldn't find valid RAM disk image starting at 0. [13:42] GRR [13:42] What's your bootm command? [13:42] bootm 0x90007fc0 0x907fffc0 [13:42] i just copied yours from the bug for now [13:43] Did you supply -a to mkimage for the initrd image? I'm wondering whether U-Boot is using the load address parameter to tell linux where the initrd is. [13:43] i did [13:43] mkimage -A arm -T initrd -C none -O linux -a 0x90800000 -d ../initrd.lz ../uInitrd.lz [13:44] i'll try with -a 0x0 [13:44] Hmmm, not that then. Can you send me your kernel log? [13:44] lool: yes. its a vfat issue. i will check the code if i find time [13:44] ogra: -T ramdisk [13:45] cooloney: why is our vmlinuz so big? [13:46] RAMDISK: Couldn't find valid RAM disk image starting at 0. [13:46] sniff [13:46] did you pass initrd=0x.....,12M to kernel? [13:47] nope [13:47] i shouldnt need to [13:47] No, U-boot puts that info in the tagged list [13:47] Can you stick your kernel log in pastebin, ogra? I have vague memories of similar problems [13:47] its just that that is used everywhere on in u-boot docs [13:48] which i found odd too i have to admin [13:48] dmart, you mean the serial output ? [13:48] admit [13:48] ogra: if possible [13:48] * asac gets more coffee [13:48] http://paste.ubuntu.com/356054/ [13:48] ogra: thanks [13:49] ogra: [13:49] yep [13:49] Trying to unpack rootfs image as initramfs... rootfs image is not initramfs (junk in compressed archive); looks like an initrd [13:49] I guess that's wrong? lzma support missing (or something else?) [13:50] thats weird [13:50] oh, wait ! [13:51] * ogra checks asacs script again [13:51] my script? [13:51] the kernel boots ;) [13:51] my options to it [13:51] no, its definately the right kernel [13:51] ok [13:53] * asac remembers that this was the stage where his bbg3 died ;) [13:55] hmm, -C lzma is accepted, but doesnt fix it [13:55] i think it should be -C none [13:55] i AGREE [13:55] anyway [13:55] (I agree) [13:55] thats what i used before [13:56] asac, do we have a call now ? [13:56] or is that an IRC meeting [13:56] ogra: i will ping you ... have to call him first to tell him that we do a conference now ;) [13:56] * ogra needs to know if he needs to steal the phone :) [13:56] as he isnt online atm [13:56] so stay tuned [13:56] ok [14:05] ogra: Could you merge the two rootstock branches I proposed for merging? [14:06] They fix lucid support or running under lucid with default args, and would allow for less forks of the script [14:06] lool, will do before ending my day, whgy dont you have direct commit access ? [14:06] I might, let me check [14:07] ogra: Trunk is ~ogra/project-rootstock/trunk [14:07] ah, crap, i'll found a team [14:16] asac: sorry, just back from a meeting, [14:16] asac: are you asking about the size of vmlinuz? [14:32] cooloney: yes === jamie is now known as JamieBennett [15:07] asac: you guys are thinking the vmlinuz is too big? compare to karmic imx51 kernl? [15:12] asac: has https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/490792 already been fixed? Isn't that the same fix I tested a while back? [15:12] Launchpad bug 490792 in xulrunner "ARM/Thumb interworking support missing from nanojit" [Unknown,Fix released] [15:33] plars: firefox-3.5 is still SIGILL'ing in lucid, for reasons we don't fully understand yet... so maybe the problem wasn't fully fixed [15:35] Has anyone been able to install from 20100112.2 with manual partitioning? I'm having problems: see https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/506971 and https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/507012 [15:35] Launchpad bug 506971 in ubiquity "Partitions detection is wrong using manual partitioning" [Undecided,New] [15:35] (Come on ubot4, second link... https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/507012) [15:35] Launchpad bug 507012 in ubiquity "Attempt to create new partitions silently fails in manual partitioning" [Undecided,New] [15:35] dmart: according to iso tracker, ogra was able to get through it [15:37] I'm trying to reserve space to transfer the boot images to the installation medium. This is more convenient to use, and has worked in the past... but maybe it's confusing ubiquity [15:40] dmart: I'm using automatic partitioning on this test right now, will try with manual later [15:42] FYI, I create a 32MiB non-FS data partition (DA) at the start of the installation medium to put the boot images in. This can't be done through ubiquity, but the partition is displayed correctly after ubiquity has queried the device. [15:43]