Minix 3.1.3a on VirtualBox 2.1.4, lance ethernet driver troubles

[Matthias Schmidt]

Hi *,

I'm trying to get the Minix lance driver running using VirtualBox
2.1.4 on Mac OSX 10.5.6. That's what i did so far:

(1) patched lance to get rid of the assertion as described here:
http://groups.google.com/group/comp.os.minix/browse_thread/thread/abb4a14da4ead487/b9c53bda8e3bcb3e?lnk=gst&q=virtual+box#

(2) changed random/lance load-order as described here:
http://groups.google.com/group/comp.os.minix/browse_thread/thread/1a682ed4b7c661f4#

(3) starting Minix small version.

Now the assertion is gone. Lance loads fine. I've got the expected
10.0.2.15 address. But that's all. No packets are travelling. No
nothing.

Now my questions:

(1) Is there any way to get the lance driver working in 3.1.3a, or do
i have to have this patch:
https://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=%2Ftrunk%2Fsrc%2Fdrivers%2Flance%2Flance.c&r1=2909&r2=3659

... which relies on alloc_contig() added to the kernel after
3.1.3a?

(2) How can i transfer the minix-currrent-tarball into the system
without a working network? I'm unable to mount ISO9660 images on
3.1.3a.

It seems, that I'm stucking in a chicken-egg situation here ...

cheers,

Matthias

[Rafael Vargas]

On Wed, Mar 25, 2009 at 3:12 PM, Matthias Schmidt
<matthias...@gmail.com> wrote:
> Now the assertion is gone. Lance loads fine. I've got the expected
> 10.0.2.15 address. But that's all. No packets are travelling. No
> nothing.

Are you using NAT?

--
Rafael Vargas
http://rafavargas.com

[Matthias Schmidt]

yepp. That's what i do.

cheers,

Matthias

On 25 Mrz., 15:36, Rafael Vargas <rafavar...@ieee.org> wrote:
> On Wed, Mar 25, 2009 at 3:12 PM, Matthias Schmidt
>

[Rafael Vargas]

On Wed, Mar 25, 2009 at 4:07 PM, Matthias Schmidt
<matthias...@gmail.com> wrote:
> yepp. That's what i do.

Do you have a firewall?

[Jens de Smit]

On Mar 25, 3:12 pm, Matthias Schmidt <matthias.schm...@gmail.com>
wrote:

> Hi *,
>
> I'm trying to get the Minix lance driver running using VirtualBox
> 2.1.4 on Mac OSX 10.5.6. That's what i did so far:
>
> (1) patched lance to get rid of the assertion as described here:

>      http://groups.google.com/group/comp.os.minix/browse_thread/thread/abb...

>
> (2) changed random/lance load-order as described here:

>      http://groups.google.com/group/comp.os.minix/browse_thread/thread/1a6...

>
> (3) starting Minix small version.
>
> Now the assertion is gone. Lance loads fine. I've got the expected
> 10.0.2.15 address. But that's all. No packets are travelling. No
> nothing.

If you get an address then DHCP is almost certainly working which
means the network is working (no network -> no DHCP -> no address).
What makes you conclude that "no packets are travelling"?.

Regards,

Jens

[Matthias Schmidt]

Hi Rafael,

no i don't have a firewall.

My problem is that the lance ethernet driver doesn't work when running
inside VirtualBox. It's an Guest/Host internal problem, since i can
not even ping my default gateway(which replies fine with other guest
os). There used to be an below 16MB/DMA issue with the driver itself.
This should be fixed with Minix r3659. But i can not get the latest
Minix sources into the VirtualBox since i can not mount plan ISO
images ...

cheers,

Matthias

On 25 Mrz., 17:01, Rafael Vargas <rafavar...@ieee.org> wrote:
> On Wed, Mar 25, 2009 at 4:07 PM, Matthias Schmidt
>

[Rafael Vargas]

On Wed, Mar 25, 2009 at 5:17 PM, Matthias Schmidt
<matthias...@gmail.com> wrote:
> This should be fixed with Minix r3659. But i can not get the latest
> Minix sources into the VirtualBox since i can not mount plan ISO
> images ...

This is blatant self-promotion, but I think this might helps you:
http://is.gd/oJMU (it's a link to a blog post I wrote yesterday where
I explain how to repair the issue with the LANCE driver).

Good luck!

[Matthias Schmidt]

Hi Jens,

exactly the fact that although i've got my ip-address from the DHCP
server I couldn't ping this very server made me wonder.

VirtualBox gives the first DHCP client the 10.0.2.15. It drives
10.0.2.2 as gateway and the DNS server runs on 10.0.2.3. It can't ping
them, let alone get names resolved.

What can i do to troubleshoot this further?

cheers,

Matthias

[Matthias Schmidt]

Hi Rafael,

thanks for this really nice write-up!

Alas - that's exactly what i did. Without succcess.

cheers,

Matthias

On 25 Mrz., 17:20, Rafael Vargas <rafavar...@ieee.org> wrote:
> On Wed, Mar 25, 2009 at 5:17 PM, Matthias Schmidt
>

> <matthias.schm...@gmail.com> wrote:
> > This should be fixed with Minix r3659. But i can not get the latest
> > Minix sources into the VirtualBox since i can not mount plan ISO
> > images ...
>

> This is blatant self-promotion, but I think this might helps you:http://is.gd/oJMU(it's a link to a blog post I wrote yesterday where

[Rafael Vargas]

On Wed, Mar 25, 2009 at 5:52 PM, Matthias Schmidt
<matthias...@gmail.com> wrote:
> What can i do to troubleshoot this further?

Can you run "ifconfig"? What does it say?

[Matthias Schmidt]

it gets me the ipaddress 10.0.2.15

cheers,

Matthias

On 25 Mrz., 18:19, Rafael Vargas <rafavar...@ieee.org> wrote:

[Rafael Vargas]

It may sound a bit paranoid but... are you using OpenDNS? I had a
similar problem with Minix under VMware and OpenDNS...

[Matthias Schmidt]

Hi Rafael,

it's not an DNS issue at all. I'm using various DNS servers from
within my company and from at home. They never had any issues.

cheers,

Matthias

[Tinghui Wang]

In my opinion, I still think maybe something in your host block the "ping"
Have you ever tried to ping your guest from host?

Regards.
Steven. Wang

2009/3/26 Matthias Schmidt <matthias...@gmail.com>

[Matthias Schmidt]

Hi Steven,

there is no way to ping from the host into the guest os. All one can
do is to configure inbound port forwarding/translation. This is done
in VirtualBox like this:

VBoxManage setextradata "Minix3-3.1.3a" "VBoxInternal/Devices/pcnet/0/
LUN#0/Config/guestssh/Protocol" TCP
VBoxManage setextradata "Minix3-3.1.3a" "VBoxInternal/Devices/pcnet/0/
LUN#0/Config/guestssh/GuestPort" 22
VBoxManage setextradata "Minix3-3.1.3a" "VBoxInternal/Devices/pcnet/0/
LUN#0/Config/guestssh/HostPort" 7722

But this doesn't work either.

cheers,

Matthias

On 26 Mrz., 00:03, Tinghui Wang <chinatopdra...@gmail.com> wrote:
> In my opinion, I still think maybe something in your host block the "ping"
> Have you ever tried to ping your guest from host?
>
> Regards.
> Steven. Wang
>

> 2009/3/26 Matthias Schmidt <matthias.schm...@gmail.com>

[Matthias Schmidt]

Hi *,

meanwhile I managed to get the latest subversion version of minix
(r4200) onto the system and build. No luck



On 25 Mrz., 20:01, Matthias Schmidt <matthias.schm...@gmail.com>
wrote:

[Matthias Schmidt]

Hi Jens,

as stated below I'm now running r4200, but still have no working lance
driver.

Anytime i do:

hostaddr -e

the lance driver restarts giving this on /dev/console:

lance buf: v 0x800000000 ph 0x3c1000

this is from do_init() so i suppose something must have gone terribly
wrong ...

cheers,

Matthias


On 25 Mrz., 17:52, Matthias Schmidt <matthias.schm...@gmail.com>

[Tinghui Wang]

I do not quite catch what you mean.
Since your ideal result is to successfully ping host in guest why cannot ping guest from host?
I install Minix on VMware. and the guest get an IP: 192.168.65.2 and the virtual network card  IP for my host is 192.168.65.1.
run cmd: ping 192.168.65.2
under the cmd line of host.

1. there is no firewall in minix3, ping-in is allowed.
2. I do not use Virtual Box but VMware instead. I wonder whether your virtual box network configuration is as follows:
        Your Guest: ip: 10.0.2.15
        Your Host: ip1: 10.0.2.* (in the same subnet with your guest)
                         ip2: *.*.*.* (to the outside world)
    In your last reply, it seems that you map the port from guest to host?
    If the NAT between your guest and your host is OK, definitely, your host can ping to your guest through the virtual network.

Regards.
Steven Wang

2009/3/26 Matthias Schmidt <matthias...@gmail.com>

[Matthias Schmidt]

Hi *,

thanks to Ben Gras, I've learned how to work around this problem.
After the bootup a:

service refresh lance

made the lance driver work. It was neither a routing nor a DNS issue,
but a faulty driver.
We are working to nail this down.

cheers,

Matthias

On 26 Mrz., 01:36, Matthias Schmidt <matthias.schm...@gmail.com>

[Ben Gras]

Hi Matthias,

Thanks for being so tenacious :-)

Debugging both or even either why the order of driver/inet starting
seems to matter in the case of lance (presuming it's that) and why the
driver is rather flakey thereafter (in my experience) under
virtualbox, making virtualbox networking stable out-of-the-box, would
be a huge contribution.

[Jens de Smit]

On Mar 26, 1:36 am, Matthias Schmidt <matthias.schm...@gmail.com>
wrote:
> Hi Jens,
>

> as stated below I'm now running r4200, but still have no working lance
> driver.
>
> Anytime i do:
>
> hostaddr -e
>
> the lance driver restarts giving this on /dev/console:
>
> lance buf: v 0x800000000 ph 0x3c1000
>
> this is from do_init() so i suppose something must have gone terribly
> wrong ...

Hi Matthias,

So the driver was working, up to a certain point. I hadn't considered
that possibility... Glad you found it, hope you can nail it!

Regards,

Jens

[Matthias Schmidt]

Hi guys,

i just wanted to give you an update about my findings so far.

I have disabled all network setup in /usr/etc/rc to figure out what
works when.
It seems to be a DHCPD issue, since refreshing the lance-driver is
only necessary after a dhcpd startup.

This works:

service up /usr/sbin/lance -args LANCE0=on
service up /usr/sbin/inet
# doing a 'service refresh lance' here, doesn't help!
/usr/bin/dhcpd &
# here dhcpd causes DL_CONF to be sent to lance 5 times, which in turn
calls do_init(). Multiple pci init's might be the root cause...
service refresh lance # refresh needs do be done right after dhcpd

Static IP-address configuration works out of the box:

service up /usr/sbin/lance -args LANCE0=on
service up /usr/sbin/inet
ifconfig -I /dev/ip0 -h 10.0.2.15

I'll try to take a look at the dhcpd code if i can spare the cycles in
the next couple of days ( unless some of you points me into the right
direction).

cheers,

Matthias

[Jens de Smit]

On Apr 1, 10:58 am, Matthias Schmidt <matthias.schm...@gmail.com>
wrote:

> Hi guys,
>
> i just wanted to give you an update about my findings so far.
>
> I have disabled all network setup in /usr/etc/rc to figure out what
> works when.
> It seems to be a DHCPD issue, since refreshing the lance-driver is
> only necessary after a dhcpd startup.
>
> This works:
>
> service up /usr/sbin/lance -args LANCE0=on
> service up /usr/sbin/inet
> # doing a 'service refresh lance'  here, doesn't help!
> /usr/bin/dhcpd &
> # here dhcpd causes DL_CONF to be sent to lance 5 times, which in turn
> calls do_init(). Multiple pci init's might be the root cause...
> service refresh lance # refresh needs do be done right after dhcpd

So, if I understand correctly, dhcpd correctly obtains an IP address,
but in the process "over-inits" the LANCE driver which then chokes....
And this only happens on VirtualBox (as far as we know).

Might be an interesting test case to see what happens in VMWare: does
the LANCE driver survive the 5 DL_CONFs or does dhcpd not send them? I
unfortunately don't have time to do this soon...

Regards,

Jens

[Matthias Schmidt]

>So, if I understand correctly, dhcpd correctly obtains an IP address,
>but in the process "over-inits" the LANCE driver which then chokes....
>And this only happens on VirtualBox (as far as we know).

yes, this is my understanding so far. As i said, static ip
configuration causes no troubles at all.

But I forgot to paste my diff againsted lance.c taken from r4200:

50a51
> #define nil ((void*)0)
311c312,321
<
---
>
> static void sig_handler(int sig)
> {
> int r, tasknr;
>
> switch(sig) {
> case SIGUSR1: lance_dump(); break;
> }
> }
>
316a327
> struct sigaction sa;
344a356,361
> sigemptyset(&sa.sa_mask);
> sa.sa_flags = 0;
> sa.sa_handler = sig_handler;
> sigaction(SIGUSR1, &sa, nil);
>
>
497a515
>
503c521
< printf("lance buf: v 0x%lx ph 0x%lx\n", lance_buf,
lance_buf_phys);
---
> printf("lance buf: v 0x%lx ph 0x%lx pid %d\n", lance_buf, lance_buf_phys, getpid());
641,645d658
< if (ec->ec_linmem != 0)
< {
< assert( 0 );
< /*phys2seg(&ec->ec_memseg, &ec->ec_memoff, ec->ec_linmem);*/
< }
647c660
< /* XXX */ if (ec->ec_linmem == 0) ec->ec_linmem= 0xFFFF0000;
---
> ec->ec_linmem= 0xFFFF0000;


This adds a signal-handler for USR1 to dump the stats to the
controlling tty and adds the pid to the do_init() log.
The last section (removing the assert & and setting ec_linmem) is
taken from an older conversation and absolutely necessary.
Otherwise lance won't load at all.

cheers,

Matthias

[Matthias Schmidt]

Some news from my lance troubleshooting discoveries. After playing
around with /usr/bin/dhcpd for some time, i managed to reproduce the
lance problem as easy as this:

$ hostaddr -e

just issue this command and lance is gone.

This command turns into this codepath (from /usr/src/commands/simple/
hostaddr.c) :
--------------------------------------------------------------------------------------------------------
eth_fd= open(eth_device, O_RDWR);
if (eth_fd == -1)
{
fprintf(stderr, "%s: Unable to open '%s': %s\n",
prog_name, eth_device, strerror(errno));
exit(1);
}
result= ioctl(eth_fd, NWIOGETHSTAT, &nwio_ethstat);
if (result == -1)
{
fprintf(stderr,
"%s: Unable to fetch ethernet address: %s\n",
prog_name, strerror(errno));
exit(1);
}
printf("%s%s", first_print ? "" : " ",
ether_ntoa(&nwio_ethstat.nwes_addr));
first_print= 0;
--------------------------------------------------------------------------------------------------------

I played around with it a bit (skipping the ioctl()) and now could
narrow it down to simply opening the ethernet device:

eth_fd= open(eth_device, O_RDWR);

Even opening the device read-only (O_RDONLY) kills lance. Stay tuned.