Hi Carlos, > https://github.com/mirage/ocaml-conduit/blob/master/tests/mirage/http-fetch/unikernel.ml#L28 > > <https://github.com/mirage/ocaml-conduit/blob/master/tests/mirage/http-fetch/unikernel.ml#L28> > > create an empty conduit with protocols to be None (see the update > unikernel.ml in: > https://github.com/lcoviedo/mirage-http-fetch/blob/master/unikernel.ml > <https://github.com/lcoviedo/mirage-http-fetch/blob/master/unikernel.ml>) > > However, when make the build fails with the following error: > > File "unikernel.ml", line 30, characters 63-73: > Error: This expression is packed module, but the expected type is > 'e Conduit_mirage.stackv4 > Command exited with code 2.
The conduit API for 0.8.4 was in flux in the last few days, it should be stable now (and ready to release). I've just updated the http-fetch and http-server tests to the latest API, this should work fine now. Apologies for the breakages, we are still stabilising the API for the upcoming mirage 2.5.0 release (with TLS support) -- almost all good now. Best, Thomas > > Thanks > > ________________________________________ > From: Thomas Leonard [[email protected] <mailto:[email protected]>] > Sent: Monday, June 01, 2015 7:45 PM > To: Oviedo García Luis > Cc: [email protected] > <mailto:[email protected]> > Subject: Re: [MirageOS-devel] Routing.No_route_to_destination_address running > Mirage web server > > On 1 June 2015 at 18:02, Carlos Oviedo <[email protected]> > <mailto:[email protected]> wrote: > > Hi, > > > > I have a similar problem, please find the code (a revised http-fetch > > version) in the following repo: > > https://github.com/lcoviedo/mirage-http-fetch > > <https://github.com/lcoviedo/mirage-http-fetch> > > > > The unikernel only works fine when runs as a unix backend using socket > > network stack, otherwise I get the errors below (DHCP full process is run > > twice, and crashes after ARP timeout). > > > > Interestingly, packet capture on eth0 shows the gw replying to arp requests. > > Also, removing ctx from HTTP.get that makes use of default resolver builds > > and runs but results in "name resolution failed unknown endpoint type", > > however the arp timeout and twice-dhcp process problems do not persist. > > > > Help is much appreciated. > > > > > > Parsing config from http-fetch.xl > > Xen Minimal OS! > > start_info: 00000000004f6000(VA) > > nr_pages: 0x10000 > > shared_inf: 0x96cf4000(MA) > > pt_base: 00000000004f9000(VA) > > nr_pt_frames: 0x7 > > mfn_list: 0000000000476000(VA) > > mod_start: 0x0(VA) > > mod_len: 0 > > flags: 0x0 > > cmd_line: > > stack: 0000000000455780-0000000000475780 > > MM: Init > > _text: 0000000000000000(VA) > > _etext: 000000000025b1ff(VA) > > _erodata: 00000000002d3000(VA) > > _edata: 0000000000419460(VA) > > stack start: 0000000000455780(VA) > > _end: 0000000000475780(VA) > > start_pfn: 503 > > max_pfn: 10000 > > Mapping memory range 0x800000 - 0x10000000 > > setting 0000000000000000-00000000002d3000 readonly > > skipped 1000 > > MM: Initialise page allocator for 57f000(57f000)-10000000(10000000) > > MM: done > > Demand map pfns at 10001000-0000002010001000. > > Initialising timer interface > > Initialising console ... done. > > gnttab_table mapped at 0000000010001000. > > getenv(OCAMLRUNPARAM) -> null > > getenv(CAMLRUNPARAM) -> null > > getenv(PATH) -> null > > Unsupported function lseek called in Mini-OS kernel > > Unsupported function lseek called in Mini-OS kernel > > Unsupported function lseek called in Mini-OS kernel > > getenv(OCAMLRUNPARAM) -> null > > getenv(CAMLRUNPARAM) -> null > > getenv(TMPDIR) -> null > > getenv(TEMP) -> null > > Netif: add resume hook > > Netif.connect 0 > > Netfront.create: id=0 domid=0 > > MAC: aa:aa:aa:aa:aa:aa > > Attempt to open(/dev/urandom)! > > Manager: connect > > Manager: configuring > > DHCP: start discovery > > > > Sending DHCP broadcast (length 552) > > DHCP response: > > input ciaddr 0.0.0.0 yiaddr 10.0.20.67 > > siaddr 0.0.0.0 giaddr 0.0.0.0 > > chaddr aaaaaaaaaaaa00000000000000000000 sname file > > DHCP: offer received: 10.0.20.67 > > DHCP options: Offer : Broadcast(10.0.20.255), DNS > > servers(10.0.21.232,10.0.21.233,10.0.21.234,10.0.20.29), Routers(10.0.20.1), > > Subnet mask(255.255.255.0), Lease time(7200), Server identifer(10.0.23.135) > > Sending DHCP broadcast (length 552) > > DHCP response: > > input ciaddr 0.0.0.0 yiaddr 10.0.20.67 > > siaddr 0.0.0.0 giaddr 0.0.0.0 > > chaddr aaaaaaaaaaaa00000000000000000000 sname file > > DHCP: offer received > > IPv4: 10.0.20.67 > > Netmask: 255.255.255.0 > > Gateways: > > [10.0.20.1] > > sg:true gso_tcpv4:true rx_copy:true rx_flip:false smart_poll:false > > ARP: sending gratuitous from 10.0.20.67 > > DHCP offer received and bound to 10.0.20.67 nm 255.255.255.0 gw [10.0.20.1] > > Manager: configuration done > > Attempt to open(/dev/urandom)! > > Manager: connect > > Manager: configuring > > DHCP: start discovery > > > > Sending DHCP broadcast (length 552) > > DHCP response: > > input ciaddr 0.0.0.0 yiaddr 10.0.20.67 > > siaddr 0.0.0.0 giaddr 0.0.0.0 > > chaddr aaaaaaaaaaaa00000000000000000000 sname file > > DHCP: offer received: 10.0.20.67 > > DHCP options: Offer : Broadcast(10.0.20.255), DNS servers(10.0.21.232), > > Routers(10.0.20.1), Subnet mask(255.255.255.0), Lease time(7200), Server > > identifer(10.0.23.135) > > Sending DHCP broadcast (length 552) > > DHCP response: > > input ciaddr 0.0.0.0 yiaddr 10.0.20.67 > > siaddr 0.0.0.0 giaddr 0.0.0.0 > > chaddr aaaaaaaaaaaa00000000000000000000 sname file > > DHCP: offer received > > IPv4: 10.0.20.67 > > Netmask: 255.255.255.0 > > Gateways: > > [10.0.20.1] > > ARP: sending gratuitous from 10.0.20.67 > > DHCP offer received and bound to 10.0.20.67 nm 255.255.255.0 gw [10.0.20.1] > > Manager: configuration done > > Resolving in 1s using DNS server 8.8.8.8 > > Fetching http://anil.recoil.org <http://anil.recoil.org/> with Cohttp: > > Attempt to open(/dev/urandom)! > > ARP: transmitting probe -> 10.0.20.1 > > ARP: updating 10.0.20.1 -> 00:1b:d5:f4:1d:c4 > > ARP: transmitting probe -> 10.0.20.1 > > ARP: updating 10.0.20.1 -> 00:1b:d5:f4:1d:c4 > > ARP: retrying 10.0.20.1 (n=1) > > It looks like you're running two instances of the TCP/IP stack. One is > working and the other is failing. This is probably a bug in the mirage > tool, because you only created a single stack in your config.ml, but > check the generated main.ml to see what it actually did... > > As a work-around, you could just pass the stack to your unikernel and > have it create conduit and the resolver. > > > ARP: transmitting probe -> 10.0.20.1 > > ARP: updating 10.0.20.1 -> 00:1b:d5:f4:1d:c4 > > ARP: retrying 10.0.20.1 (n=2) > > ARP: transmitting probe -> 10.0.20.1 > > ARP: updating 10.0.20.1 -> 00:1b:d5:f4:1d:c4 > > ARP: retrying 10.0.20.1 (n=3) > > ARP: transmitting probe -> 10.0.20.1 > > ARP: updating 10.0.20.1 -> 00:1b:d5:f4:1d:c4 > > IP.output: arp timeout to gw 5.153.225.51 > > Fatal error: exception > > Ipv4.Make(Ethif)(Clock)(Time).Routing.No_route_to_destination_address(_) > > Raised at file "src/core/lwt.ml", line 788, characters 22-23 > > Called from file "lib/main.ml", line 58, characters 10-20 > > Called from file "main.ml", line 107, characters 2-77 > > Mirage exiting with status 2 > > Do_exit called! > > base is 0x46ff10 caller is 0x23e89d > > base is 0x418df0 caller is 0x0 > > base is 0x273c9b caller is 0x5241570000000000 > > base is 0x65676172696d Page fault at linear address 656761726975, rip > > 25a747, regs 000000000046fe28, sp 46fed0, our_sp 000000000046fdf0, code 0 > > RIP: e030:[<000000000025a747>] > > RSP: e02b:000000000046fed0 EFLAGS: 00010002 > > RAX: 0000000000000017 RBX: 000065676172696d RCX: 00000000000004ba > > RDX: 00000000000014bb RSI: 000000000046fd20 RDI: 0000000000000004 > > RBP: 000000000046ff10 R08: 00000000000014bb R09: 0000000000000020 > > R10: 0000000000000017 R11: 0000000000000010 R12: 0000000000000000 > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > base is 0x46ff10 caller is 0x23e89d > > base is 0x418df0 caller is 0x0 > > base is 0x273c9b caller is 0x5241570000000000 > > base is 0x65676172696d Page fault in pagetable walk (access to invalid > > memory?). > > > > > -- > Carlos Oviedo > PhD student > Network Systems Group > University of Nottingham > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > _______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
