On Thu, Apr 2, 2015 at 9:18 PM, Magnus Therning <[email protected]> wrote:

> On Tue, Mar 31, 2015 at 09:49:28PM +0100, Anil Madhavapeddy wrote:
> > On 31 Mar 2015, at 21:09, David Scott <[email protected]> wrote:
> > >
> > >
> > >
> > > On Tue, Mar 31, 2015 at 6:43 PM, Anil Madhavapeddy <[email protected]
> <mailto:[email protected]>> wrote:
> > > On 31 Mar 2015, at 07:37, Magnus Therning <[email protected]
> <mailto:[email protected]>> wrote:
> > >>
> > >> > After a clean rebuild on my cubieboard, I'm getting the assertion
> failures too, which is good. I notice the assert that's failing was added
> relatively recently[1] in tcpip v2.2.3 so it's possible that it's simply
> highlighting an old bug in mirage-net-xen. The hunt continues...
> >>>
> >>> Ah, that's "good" news indeed. I'll try, but won't make any promises,
> to look a bit at it too. More as a learning exercise then with an aim to
> actually find and fix the issue :)
> >>>
> >> Excellent bug report Magnus!  We didn't catch this due to the lack of
> regular automated testing on ARM.  We would catch this on x86 due to
> deploying our sites regularly, but we don't currently run ARM in
> production.  I'll rectify this when back in Cambridge with a version of
> www.openmirage.org <http://www.openmirage.org/> that runs on a
> Cubieboard2.
> > >
> > > In the meanwhile, would you be able to test if my point release of
> tcpip.2.3.1 fixes your issue? Do
> > >
> > >     opam pin add tcpip git://github.com/mirage/mirage-tcpip#v2.3.1 <>
> > >
> > > Once someone with a Cubie2 confirms that the regression has gone, I'll
> push this to OPAM.
> > >
> > > The mirage-skeleton/static_website works fine for me with that change.
> >
> > Thanks for confirming!  Tcpip.2.3.1 has now been released to OPAM with
> the fix.
>
> Hmm, I'm now wondering if I've done something completely wrong here.
> After the re-build with tcpip 2.3.1 I no longer get any asserts, but I
> also get absolutely nothing in reply on HTTP requests... that wasn't
> exactly what I expected.  I did expect a reply with a bit of HTML.
>
> ~~~ output on xen console on ARM
> Sending DHCP broadcast (length 552)
> DHCP response:
> input ciaddr 0.0.0.0 yiaddr 192.168.0.27
> siaddr 192.168.0.1 giaddr 0.0.0.0
> chaddr 00163e2128a900000000000000000000 sname  file
> DHCP: offer received: 192.168.0.27
> DHCP options: Offer : Unknown(59[4]), Unknown(58[4]), DNS
> servers(83.255.245.11,193.150.193.150), Subnet mask(255.255.255.0), Server
> identifer(192.168.0.1), Routers(192.168.0.1), Lease time(86400)
> Sending DHCP broadcast (length 552)
> DHCP response:
> input ciaddr 0.0.0.0 yiaddr 192.168.0.27
> siaddr 192.168.0.1 giaddr 0.0.0.0
> chaddr 00163e2128a900000000000000000000 sname  file
> DHCP: offer received
>                     IPv4: 192.168.0.27
>                                       Netmask: 255.255.255.0
>                                                             Gateways:
> [192.168.0.1]
>  sg:true gso_tcpv4:true rx_copy:true rx_flip:false smart_poll:false
> ARP: sending gratuitous from 192.168.0.27
> DHCP offer received and bound to 192.168.0.27 nm 255.255.255.0 gw
> [192.168.0.1]
> Manager: configuration done
> ARP responding to: who-has 192.168.0.27?
> ARP: transmitting probe -> 192.168.0.11
> ARP: updating 192.168.0.11 -> 00:c2:c6:0f:72:dd
> conn 1 closed
> conn 2 closed
> ARP responding to: who-has 192.168.0.27?
> conn 3 closed
> conn 4 closed
> ~~~
>
> ~~~ on my laptop
> % curl http://192.168.0.27/
> ~~~
>
> curl doesn't produce any output, but shortly after invoking it I see a
> `conn N closed` on teh Xen console.
>

Could you grab a tcpdump of that and post the .pcap file?

Thanks,
Dave


>
> I'm building as before:
>
> ~~~
> $ make configure MODE=xen FS=crunch NET=direct DHCP=true PORT=80
> ...
> $ make build
> ~~~
>
> with the same edits to `src/www.xl` as before (removing MAC, bridge is set
> to `xenbr0`).
>
> /M
>
> --
> Magnus Therning                      OpenPGP: 0xAB4DFBA4
> email: [email protected]   jabber: [email protected]
> twitter: magthe               http://therning.org/magnus
>
> The ultimate goal of all computer science is the program.  The
> performance of programs was once the noblest function of computer
> science, and computer science was indispensable to great programs.
> Today, programming and computer science exist in complacent isolation,
> and can be [rescued only] by conscious coöperation and collaboration
> of all programmers.
>
> _______________________________________________
> MirageOS-devel mailing list
> [email protected]
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>
>


-- 
Dave Scott
_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Reply via email to