=== michaelh1_ is now known as michaelh1 [01:15] if i want to install ubuntu 9.04 on sd card for the sheevaplug do i need uInitrd? [01:16] this is the last line of the error: Kernel panic - not syncing: No init found. Try passing init= [01:16] basically it starts the boot process... [01:17] I have two partitions on the sd (boot partition is ext2 with uImage) and (root partition is ext3 with rootstock fs) === rsalveti-afk is now known as rsalveti [05:13] say, I'm interested in that spec about "port glxgears to OpenGL ES". [05:14] I want to try it on my Intel netbook with libgles1-mesa stuff and libkms and such. === rsalveti is now known as rsalveti-afk [05:46] join #panda [06:00] hello [07:55] cooloney: Hi! Did you see my email regarding the segfault patch? Is it ok for you? [08:03] npitre: rmk refused to optimize the u-boot related targets, my patch just results in a refusal to build a non-working image [08:35] sebjan, is there a reason for not printing "Uncompressing Linux... done" with the panda kernel ? it works fine, but its very irritating that it doesnt behave like other kernels [08:39] ogra: there is a patch to remove that printk? [08:39] amitk, no idea, but it doesnt print that line :) [08:39] on serial console? [08:39] it boots fine nontheless [08:39] ogra: you are right, I didn't notice that! [08:39] yeah [08:39] strange [08:40] http://paste.ubuntu.com/459728/ [08:40] then it switches to HDMI and moves on with booting [08:40] I don't know where it comes from (or does not come from :)) [08:42] Pretty sure it's from the first stage decompressor. [08:42] my target is anyway that endusers shouldnt have to touch serial at all, all config is done via boot.scr on the vfat, so it will only confuse devs but would be nice to have it back :) [08:42] head.S? Something like that? [08:43] "Uncompressing Linux... done" needs an implementation of putc in arch/arm/mach-xxx/include/mach/uncompress.h [08:45] ... and obviously it only appears if you boot a zImage. Do you? [08:47] well, uImage but made out of vmlinuz [08:48] so it is compressed, yes [08:48] the omap code has the right stubs in arch/arm/mach-xxx/include/mach/uncompress.h [08:48] the boot process and setup we use is identical to the beagleboard where we get that message [08:50] ogra: You can check if there are OMAP4 related patches to arch/arm/plat-omap/include/plat/uncompress.h [08:50] I don't have a tree handy ATM [08:51] heh, me neither [08:51] thats why i asked the tree admin above ;) [08:55] there is something related to machine registration into this file (debug uart registration depends on the machine type) [08:56] I see that the regular omap4 board is registered, but not the panda... I'll see if I can add the panda here [08:58] cool, thanks :) [09:10] ogra: i got it. [09:10] ogra: d9f5007491e3b6693dd00487981676b6b3005d72 in our git kernel tree [09:10] ah [09:11] t d9f5007491e3b6693dd00487981676b6b3005d72 [09:11] Author: vikram pandita [09:11] Date: Sun Nov 22 10:10:49 2009 -0800 [09:11] omap: introduce OMAP_LL_DEBUG_NONE DEBUG_LL config [09:11] [09:11] Zoom2/Zoom3 kind of boards do not use omap uarts for console. [09:11] These use external debug board for console. [09:11] [09:11] So these boards should not have "Uncompressing Kernel...." [09:11] log put on omap uarts. [09:11] [09:11] By interoducing OMAP_LL_DEBUG_NONE option, [09:12] sebjan: does our panda also affected by this patch? [09:16] cooloney: this is the function where the uart to use for the uncompressing trace gets selected [09:17] I just tested adding the panda registration here and I can now see the trace on my panda [09:17] I will post the patch to my tree (it's a 1 line) [09:20] sebjan: thanks, man [09:22] cooloney, sebjan, did one of you test the kernel with X ? [09:22] it freezes here no matter what i try [09:23] hmm, or not ... just seems extremely slow [09:24] i guess there is still some issue with the SD/MMC I/O [09:26] ogra: i am waiting for my hw. so never try that X before [09:26] cooloney, oh, sorry i tend to forget that you dont have the HW [09:26] sebjan: how about you? [09:27] seems the freezes happen if i dont specify mem=463M on the cmdline [09:27] now it works but is very slow [09:32] cooloney: do you have a beagle board? [09:32] amitk: no [09:32] cooloney: you will in Prague :) [09:32] amitk, he'll get a panda soon [09:32] i think its on its way already [09:32] amitk: yeah, i will. panda and prague, hehe [09:32] ogra: yeah, i hope it will arrive this week [09:32] cooloney: I'm bringing you a beagle as well [09:33] amitk: thanks a lot [09:33] we need more XMs in the team [09:33] XM support is still behind [09:34] lag has one now [09:34] yeah [09:34] i still havent found whats wrong with our u-boot yet [09:34] cool man [09:34] currently the XM doesnt boot with the archive u-boot [09:35] Mine does [09:35] Just not initrd [09:35] lag, thats equivalent to "doesnt boot" :) [09:35] initrd is a requirment for ubuntu images [09:35] :) [09:36] mine does boot with the binary from rcn, including initrd [09:36] but i cant find the difference in our sources, he seems to use the same i use [09:36] ogra: I have been doing some testing with the UNE UI, is that what you mean? [09:37] sebjan, well, i just wanted to know if X seems usable for you, here it freezes every time it accesses the SD [09:38] i'm currently testing the panda images from http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/ the oem-config screens take ages to show up [09:38] (note that only 20100706.1 will have the mem=463M fix in them, they are currently building) [09:39] I did not have such issues the last time I tested... It was not very fast, but I suspected it was because it seems that both UNE and the regular gnome desktop UI are started (bug 596004) [09:39] Launchpad bug 596004 in netbook-meta (Ubuntu) "with 2D UI (une-efl) selected, the gnome desktop toolbar is also visible and seems to be running (affects: 1) (heat: 242)" [Undecided,New] https://launchpad.net/bugs/596004 [09:39] would be helpful if the panda had some indicator LED for SD access, you never know if it reads or actually is dead [09:40] sebjan, yeah, that bug is on my list but shouldnt cause much slowdown [09:40] * ogra triages it properly [09:41] gah, now it seems to hang hard again [09:42] and i was already through oem-config and in the slideshow [09:43] sebjan, what kind of SD's do you use ? [09:43] * ogra currently has a class 4 [09:44] ogra: I also use class 4 cards (Kingston) [09:44] (micro SD with adapter) [09:45] hmm doesnt seem to come back to life [09:46] (regular SD card for me) [09:47] * ogra wishes he could at least get far enough to have a user created [09:47] so i could read any logs [09:49] cooloney, is the binary we have in the archive recent ? does it have all fixes and patches ? [09:58] ogra: the M ti-omap4 kernel? i we got lots for fixes and patches from sebjan except the syslink module patch [09:58] ogra: what's uname -a in your system [10:00] sebjan: Is syslink discoverable? [10:02] lag: you'll have to explain me what it means 'discoverable' :)... [10:04] sebjan: i am guess, it means probable? [10:04] At the moment (with the module patches applied) the kernel doesn't 'discover' the device and load the modules [10:06] lag: did you add the platform device and resource in the panda board files in mach-omapX? [10:07] Yes [10:08] If I register the device alone I get KERNEL and UDEV uevents [10:08] But I need a DRIVER uevent [10:09] I've tried registering a platform driver, but because the device is unknown to the kernel the .probe function is never called [10:15] lag: the .name field of the platform device in your board file should be the same of the driver platform name in syslink driver. IMHO [10:16] lag: I suppose that we are missing something either in the device declaration or in the driver... this is what we need to get sorted out [10:17] cooloney: It is [10:17] I've moved the .probe function to the same place as the __init function [10:17] The __init function is called and the driver is registered successfully [10:17] But .probe is still not called [10:18] .probe functions are not called if the kernel does not know about the device [10:18] Hence the discoverable question [10:18] sebjan: It's not even getting as far as the driver [10:19] sebjan: I think we need more information in my (__init) function to tell the kernel about the existence of the hardward [10:19] hardware* [10:19] cooloney, well, we only had one upload yet and i cant get to a point in the image to type in uname (i cant get past user creation before the board hangs hard) [10:20] I am in the process of putting the driver & device register code in the same place - see what that does [10:20] cooloney, so i cant really say what uname would give, but i'm pretty sure its 2.6.34-900.1 since that was the only upload we had yet [10:21] ogra: oh, please wait, i can provide a new testing kernel for you, [10:21] lag, arent there any other devices you could just steal from ? [10:21] cooloney, doesnt help, i'm testing images, they build from the archive [10:21] cooloney, we should rather kick leann to do a new upload if the tree has so many patches [10:21] ogra: ah, right [10:22] ogra: ok, i think rtg will upload that [10:22] lag, i could imagine rfkill to be a platform device doing something similar to what we need [10:22] cooloney, ah, right, he did the last upload too, i missed that [10:24] lag: send me patches of your current changes, and I'll tell you if I have an idea and try to play with it this afternoon [10:24] ogra: No, I can't find any other devices that do this [10:28] gah === amitk is now known as amitk-afk [10:36] the plymouth splash looks really good on the panda :) === hrw|gone is now known as hrw === amitk-afk is now known as amitk === jussi is now known as Guest7125 === jussi01 is now known as jussi [12:39] lag, could you paste the Hardware line of a beagle XM for me ? [12:39] lag, from /proc/cpuinfo [12:42] Yup - 2 mins [12:42] hrw, your openjdk build, how did you do the testbuild, in a clean chroot ? [12:42] ogra: no - in normal BB system [12:42] lag, no hurry, anytime you find the time is fine [12:42] hrw, definate 2normal BB system" [12:42] s/2/\" [12:42] It's okay - I'm waiting for an email from linux-hotplug [12:42] ogra: quite up-to-date maverick [12:43] openjdk needs itself to register the ca certificates but the lucid openjdk seems to segfault here, what openjdk version did you have installed for the build ? [12:44] (keytool is a java app and calls the former openjdk while installing the build deps) [12:44] ogra: I did "apt-get build-dep openjdk-6", then "apt-get source openjdk-6", "cd openjdk-6-*;debuild -b -uc -us" [12:44] hmm [12:44] ogra: did not looked at versions etc [12:45] LANG=C LC_ALL=C keytool -importcert -trustcacerts -keystore $KEYSTORE -providerClass sun.security.pkcs11.SunPKCS11 -providerArg '${java.home}/lib/security/nss.cfg' -noprompt -storepass "$storepass" -alias "$alias" -file "$cacertdir/$pem" > $log 2>&1 [12:45] thats the line that segfaults [12:45] and openjdk ships /usr/lib/jvm/java-6-openjdk/jre/bin/keytool [12:46] (which /usr/bin/keytool links to through an alternative) [12:46] keytool error: java.lang.RuntimeException: Usage error, sun.security.pkcs11.SunPKCS11 is not a legal command [12:46] i dont get how it could build for you while it doesnt on the buildd [12:46] ogra: want shell access to that beagle? [12:47] no [12:47] so it doesnt segfault for you apparently but just complains [12:48] does apt-get install --reinstall ca-certificates-java work for you without any errors ? [12:57] Setting up ca-certificates-java (20100412) ... [12:57] Processing triggers for initramfs-tools ... [12:58] very weird [12:59] http://hrw.pastebin.com/4ZSwj2zP [12:59] on the buildd /var/lib/dpkg/info/ca-certificates-java.postinst fails [13:00] root@beagle:/mnt/hrw/UBUNTU# /var/lib/dpkg/info/ca-certificates-java.postinst configure [13:00] creating /etc/ssl/certs/java/cacerts... [13:00] done. [13:01] http://hrw.pastebin.com/7KqebZ5e shows ver === rsalveti-afk is now known as rsalveti [13:04] morning [13:06] hrw, aha ... Setting up default-jre-headless (1.6-38) ... [13:06] from the build log [13:07] ogra@osiris:~/Devel/branches/jasper-initramfs-0.10$ apt-cache show ca-certificates-java|grep Depends [13:07] Depends: ca-certificates (>= 20090814), openjdk-6-jre-headless (>= 6b16-1.6.1-2) | java6-runtime-headless [13:08] ogra@osiris:~/Devel/branches/jasper-initramfs-0.10$ apt-cache search java6-runtime-headless [13:08] default-jre-headless - Standard Java or Java compatible Runtime (headless) [13:08] openjdk-6-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless) [13:08] sun-java6-jre - Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files) [13:08] so for whatever reason default-jre-headless gets installed on the buildd instead of openjdk-6-jre-headless [13:17] hrw, the versions in http://hrw.pastebin.com/4ZSwj2zP cant be right [13:17] hrw, 6b20~pre1-0ubuntu2 didnt build [13:18] where did you get it from ? [13:18] smells like you have your testbuild installed now [13:18] the last one that built on the buildd was 6b18-1.8-2ubuntu2 [13:19] I built and installed [13:20] yeah, i need to know what version was used during installation of ca-certificates-java [13:21] which indeed came in with your apt-get build-dep [13:21] probably 6b18 [13:22] * ogra doesnt get why it didnt segfault for you [13:48] ogra: do you know if for maverick we have different kernel trees for omap? or both omap3 and omap4 should work with the ti-omap4 branch? [13:48] * rsalveti looking at maverick's kernel [13:49] the omap3 binary is built from the normal ubuntu tree [13:49] rsalveti: I asked recently, and omap3 was broken in the omap4 branch [13:49] omap4 comes from the ti-omap4 branch [13:49] rsalveti, omap4 is maintained by cooloney, omap3 by lag and mpoirier [13:50] oh, ok, so different branches for both [13:50] or it should all work at the same branch? [13:50] well, only a different branch for omap4 actually [13:50] it's just that I just saw one ti-omap4 branch at the gitweb [13:51] the big target is that omap4 goes to mainline at some point, then both binaries will be built from the ubuntu branch [13:51] but since omap4 is over 700 patches that will take a while [13:51] oh, sure :-) [13:51] and is unlikely to happen for maverick [13:51] got it now, at least for omap 3 we're in a better situation [13:51] now the problem is just omap4 [13:52] yeah, don't think so [13:52] so currently TI takes the ubuntu maverick branch and rebases their patches on top of that [13:52] for omap4 [13:52] which makes it being a bit behind in versioning [13:52] ukleinek: I don't get why a non working image would be built [13:52] ukleinek: see my rational in my answer [13:53] ukleinek: uboot needs to be fixed [13:53] ogra: yeah, right [13:53] tons of patches, maybe for 36 or 37 [13:53] right [13:55] note: basic panda support is in tmlind's tree for 36.. not sure if it boots, waiting for ups myself.. [13:55] rcn-ee, "basic" isnt want we need for maverick :) [13:56] also the tree we use is blaze+panda capable [13:56] rcn-ee: yeah, just saw the commits [13:56] yeah, but not everyone use the default maverick kernel. ;) [13:57] * rsalveti is looking forward to put my hands at a panda board [13:57] rcn-ee, well ... [13:57] rsalveti, no fun yet ... multiple hangs etc [13:58] 700 patches, I believe maverick will be much more than the basic [13:58] definately [13:58] yay, sounds like fun.. ;) just like my custom imx515 board... [13:58] rsalveti: at any pandaboard or at own pandaboard? [13:58] ogra: hangs are always fun, at some way haha :-) [13:58] heh [13:59] hrw: the omap4 pandaboard :-) [14:00] rsalveti: by 'any' I meant 'not own' [14:01] ogra: That's not true [14:01] I am working on omap3 & omap4 [14:01] * ogra hangs his head in shame [14:02] rsalveti, correction: lag woprks on *all important kernels* :) [14:02] Now you're talking [14:03] rcn-ee: what custom imx515 board? [14:03] rcn-ee: want to send me patches to add board support? ;) [14:12] amitk: someone offered efikamx few days ago... [14:12] hrw: the board or code? [14:13] boards [14:14] #linaro:02:10 < zumbi> if someone fancies an efikamx board to test out linaro, let me know [14:14] Saturday 3rd July [14:15] hrw: oh, sorry :-) do you know when pandaboard will be public? like beagleboard [14:15] rsalveti: nope [14:16] rsalveti: should be Q4 [14:16] hrw: Do you know if the efiamx comes with documentation to enable in mainline? [14:17] Q4? wow [14:18] amitk: it doesnt [14:20] armin76: pity. I don't want to spend time on it then [14:26] amitk: no idea [14:55] npitre: I'm not sure anymore about ZRELADDR, IIRC something was broken with ZBOOT_ROM images for U-Boot [14:58] ogra: Sorry for the delay - I had to make and re-flash a new card [14:58] ogra: Hardware : OMAP3 Beagle Board [14:58] perfect [14:58] same as C4 [14:59] * ogra is happy he doesnt need to special case for XM [14:59] :) [14:59] I'm pleased you're pleased [14:59] :) [14:59] perisa [15:00] Doh [15:00] Actually: lol & ogra [15:00] I need a word ;) [15:00] * ogra pulls up the dictionary [15:00] You've wasted a working day! [15:00] a long one or rather a short one ? [15:00] Leading me up the garden path [15:01] REF: /lib/udev/rules.d/80-drivers.rules, DRIVER!="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -b $env{MODALIAS}" [15:01] Do you know what that means? [15:01] lool* [15:02] lool, ogra: Do you subscribe to linux-hotswap? [15:02] if DRIVER is set run modprobe ? [15:02] NOOOOOOOOOOOOOOOo [15:02] lag, nope, i'm no kernel guy [15:02] It doesn't mean that [15:02] It's what you told me it meant [15:02] so what does it mean ? [15:02] Arhgggggggggggggggggggggggggg [15:02] :) [15:02] educate me :) [15:04] ugh, it means if DRIVER is *not* set, right ? [15:04] It means: This rule is skipped only if DRIVER is set [15:04] Hang on [15:05] lag: Oh right, DRIVER!=, I missed this bit [15:05] right, i see that now, if DRIVER is not set but MODALIAS exists in the environment, call modprobe [15:06] Follow this: http://www.spinics.net/lists/hotplug/msg03946.html [15:06] lag: I read DRIVER= [15:06] * ogra too [15:06] Arrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr [15:06] :( [15:06] * lag crys [15:06] lag: But the MODALIAS bit is ok, right? [15:06] * lag cries* [15:06] Follow that link I posted [15:06] This has cost me a day :( [15:07] lag: But the upside is that we're all three educated on what DRIVER is used for, and you have a path forward! [15:07] I guess there's always an upside [15:07] and your MODALIAS is wrong i'D say [15:07] Why is it wrong? [15:07] "platform:" [15:08] What should it be? [15:08] the module name [15:08] Uh no [15:08] thats what modprobe -b calls in the rule above [15:08] The real MODALIAS is: platform:syslink [15:08] I ****'ed out the syslink [15:08] and the module name is syslink [15:09] that's ok, you just need to modalias the .ko now [15:09] /sbin/modprobe -b platform:syslink will error out, no ? [15:09] ogra: Well not if some module has an alias for platform:syslink ? [15:10] in sysfs ? [15:10] no, in the .ko [15:10] i.e. where would modprobe get that from ? [15:10] ogra: modinfo e1000e|grep alias [15:10] ah [15:10] oh, right [15:11] grep MODALIAS /var/log/udev [15:11] yeah yeah :) [15:11] * ogra admits again that he's no kernel guy [15:12] * lag goes to work [15:12] * lag takes a big breath then --^ [15:15] * ogra goes to eat some icecream [15:19] lool: The driver is called syslink_ipc.ko [15:19] module == driver [15:19] MODALIAS=platform:syslink_ipc [15:20] Surely there should be an association? [15:20] KERNEL[946692859.898376] add /devices/platform/syslink_ipc (platform) [15:20] lag: That doesn't work? [15:20] No [15:20] KERNEL[946692859.898376] add /devices/platform/syslink_ipc (platform) [15:20] UDEV_LOG=3 [15:20] ACTION=add [15:20] DEVPATH=/devices/platform/syslink_ipc [15:20] SUBSYSTEM=platform [15:20] MODALIAS=platform:syslink_ipc [15:20] SEQNUM=735 [15:20] That is my uevent [15:20] But udev isn't loading the module [15:20] lag: But platform:syslink_ipc != syslink_ipc [15:21] Correct [15:21] lag: Try modprobe platform:syslink_ipc for yourself [15:21] And modinfo syslink_ipc [15:21] ubuntu@panda:~$ modinfo syslink_ipc [15:21] filename: /lib/modules/2.6.34-901-omap4/kernel/drivers/dsp/syslink/multicore_ipc/syslink_ipc.ko [15:21] license: GPL [15:21] author: Texas Instruments [15:21] srcversion: 7329950ABDD680C3701426C [15:21] depends: syslink_proc,omap_notify,syslink_proc4430,syslink_platform,notify_ducatidriver,syslink_ipu_pm [15:21] vermagic: 2.6.34-901-omap4 SMP preempt mod_unload ARMv7 [15:21] parm: ipc_name:Device name, default = syslink_ipc (charp) [15:21] parm: ipc_major:Major device number, default = 0 (auto) (int) [15:21] parm: ipc_minor:Minor device number, default = 0 (auto) (int) [15:21] You probably want an actual alias then [15:21] I think you need to define that in your kernel module [15:22] So an alias | and entry in udev rules? [15:22] You shouldn't need an entry in udev [15:22] OR [15:22] AIUI, udev runs modprobe platform:syslink_ipc but that fails to find anything [15:22] lag: Right, but you probably dont want an udev rule, just an alias [15:23] I don't know how to do that [15:23] * lag looks [15:23] Or you change the kernel to emit another event which triggers the load, perhaps another rule would match; I think the modalias is the easiest path [15:24] MODULE_ALIAS("platform:" DRV_NAME); [15:24] Bingo! [15:25] Eh right, was grepping for something similar in drivers/, but I should have looked in arch/arm [15:25] arch/arm/mach-omap2/mailbox.c has another instance [15:26] That was in /drivers [15:27] lag: linux/mod_devicetable.h #defines PLATFORM_MODULE_PREFIX, not sure using it is worth though [15:27] I mean it would have been quicker to grep arch/arm [15:28] #define PLATFORM_MODULE_PREFIX "platform:" [15:28] Lol [15:28] ukleinek: Not widely used it seems (drivers/base/platform.c) [15:28] MODULE_ALIAS(PLATFORM_MODULE_PREFIX, DRV_NAME);# [15:28] :) [15:28] lag: no , please [15:28] ? [15:28] lool: yeah, I know, just stumbled over it some time ago [15:28] MODULE_ALIAS(PLATFORM_MODULE_PREFIX DRV_NAME); [15:29] Oh, I see [15:29] I'm not going to use it anyway [15:29] I was just messing :) [15:30] My first attempt is the most common === amitk is now known as amitk-afk === bjf[afk] is now known as bjf === rsalveti is now known as rsalveti-afk === rsalveti-afk is now known as rsalveti === fta is now known as fta_ === amitk-afk is now known as amitk [17:55] I'm trying to install ubunt-arm on the beagleboard via netinstall. Unfortunately, my usb-nic-adapter (it is a moschip type) is not recognized as a network device, although it worls perfectly on a x86 linux system. Where can I find the kernel sources/patches and kernel config in order tu build my own uImage file? [17:56] try maverick first? [17:59] robschi: do you know the module responsible for it at x86 already? [17:59] there is a fix for it but the netinst image hasnt been regenerated yet [18:00] either do a server install or use maverick [18:00] or wait for lucid .1 [18:02] rsalveti: lsmod replies with things like [18:02] mii 4032 3 mcs7830,usbnet,r8169 [18:02] ukleinek: I never used ZBOOT_ROM with U-Boot [18:03] ukleinek: I think U-Boot is getting too much in the way for that feature [18:04] server install does not work, becaus the installer insists on using a cd-rom drive [18:04] robschi: I had filed a bug on this in Lucid, but The number (and status) currently escapes me. [18:04] * npitre thinks that U-Boot is often too much in the way, period. [18:04] robschi, server install was tested by several people, it should just work [18:06] robschi, did you follow https://wiki.ubuntu.com/ARM/BeagleServerInstall ? [18:06] ogra_cmpc: yes, i did [18:07] thats strange, the released image was heavily tested [18:07] lag: I have my syslink modules auto-loading finally :). The implementation is not clean yet, but the mechanism is functional at least. I'll send you my changes so that we can discuss them together. [18:08] I have also finished :) [18:08] * ogra_cmpc thinks lag found the right solution too today :) [18:08] ogra_cmpc: i'm installing over serial port, but this should not influence the behaviour of the installer, or does it? [18:08] snap .... [18:09] lag: cool :) [18:09] What did you do? [18:09]