[9fans] 9atom & virtualbox 4.0.10 networking issue

[9fans] 9atom & virtualbox 4.0.10 networking issue

[Bakul Shah]

Good news: 9atom installs fine on virtualbox 4.0.10 (the
   latest) and most everything works
Bad news: network access fails

Since DHCP failed I hardwired an IP address and tried pinging
the gateway. tcpdump on the host shows that ARP request goes
out and the gateway sends its ARP response but this response
is never seen by plan9!  Curiously, ether0/stats shows that
packet receive count goes up as expected -- seems the driver
is dropping received packets for some reason.

FWIW, FreeBSD works fine with the *exact* same h/w emulation
settings -- this seems to rule out the vbox logic.

The virtual machine's network adapter in the `bridged' mode
with the host's network adapter. I tried emulating AM79C73 as
well as Intel Pro 1000/MT Desktop with the same symptom.  This
happens on both Linux and MacOS VBox with the same h/w
emulation settings.

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[Fernan Bolando]

On Thu, Jul 7, 2011 at 2:40 AM, Bakul Shah <bakul@bitblocks.com> wrote:
> Good news: 9atom installs fine on virtualbox 4.0.10 (the
>   latest) and most everything works
> Bad news: network access fails
>
> Since DHCP failed I hardwired an IP address and tried pinging
> the gateway. tcpdump on the host shows that ARP request goes
> out and the gateway sends its ARP response but this response
> is never seen by plan9!  Curiously, ether0/stats shows that
> packet receive count goes up as expected -- seems the driver
> is dropping received packets for some reason.
>
> FWIW, FreeBSD works fine with the *exact* same h/w emulation
> settings -- this seems to rule out the vbox logic.
>
> The virtual machine's network adapter in the `bridged' mode
> with the host's network adapter. I tried emulating AM79C73 as
> well as Intel Pro 1000/MT Desktop with the same symptom.  This
> happens on both Linux and MacOS VBox with the same h/w
> emulation settings.

My network settings which I have been using since 3.1X of virtualbox is this
Host-Only
nic: Intel Pro 1000/MT Server
Host: Mac osx and Windows xp

This allows the host to drawterm to the virtual machine. I failed to
get it to work as NAT or Bridge. Running the nic as host only is ok if
you just want to run plan9 without internet access.

I hope you get NAT or host running. It would  be nice.

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[Bakul Shah]

On Thu, 07 Jul 2011 09:10:49 +0800 Fernan Bolando <fernanbolando@mailc.net>  wrote:
>
> This allows the host to drawterm to the virtual machine. I failed to
> get it to work as NAT or Bridge. Running the nic as host only is ok if
> you just want to run plan9 without internet access.
>
> I hope you get NAT or host running. It would  be nice.

With Erik's help I tried various things. As per his suggestion
hardwiring igbe's irq to 9 made networking work (adding
    ether0=type=igbe irq=9
didn't work).  While he was trying to figure out the irq
problem, I accidentally stumbled upon the "right" solution.
The key is to enable USB 2.0. But the open source version of
virtual box doesn't have builtin support for usb 2. For that
You have install their extension pack.

Fetch it from
http://download.virtualbox.org/virtualbox/4.0.10/Oracle_VM_VirtualBox_Extension_Pack-4.0.10-72436.vbox-extpack

Then from cmd line:

VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.0.10-72436.vbox-extpack

Now enable the USB2.0 controller.

To summarize:
- Make sure you use the current 9atom.iso.bz2 from Erik's ftp site.
- Use chipset piix3, ide piix4. Enable IO Apic (else things get slow)
- Enable USB controller and USB 2.0 controller. (should be the default)
- connect to `bridged adapter', emulate Intel PRO/1000 MT Desktop (82540EM).

NAT may work too but I haven't tried it.

If you have a working image except for networking, just change
the USB setting!

Thanks to Erik for all his help.

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[erik quanstrom]

On Fri Jul  8 02:21:12 EDT 2011, bakul@bitblocks.com wrote:
> On Thu, 07 Jul 2011 09:10:49 +0800 Fernan Bolando <fernanbolando@mailc.net>  wrote:
> >
> > This allows the host to drawterm to the virtual machine. I failed to
> > get it to work as NAT or Bridge. Running the nic as host only is ok if
> > you just want to run plan9 without internet access.
> >
> > I hope you get NAT or host running. It would  be nice.
>
> With Erik's help I tried various things. As per his suggestion
> hardwiring igbe's irq to 9 made networking work (adding
>     ether0=type=igbe irq=9
> didn't work).  While he was trying to figure out the irq
> problem, I accidentally stumbled upon the "right" solution.

the problem is in the $PIR routing.  there is the correct entry
mapping irq 10 -> 9, but it does the mapping for 0.7.0, the acpi fn,
and not 0.3.0.  there isn't a lot of organized documentation on the quirks
of $PIR routing, and most other implementation are so riddled
with workarounds that it's hard to tell for a desk check (i don't
have a mac) why they might accidently work.

i suspect the $PIR link for acpi and for the nic are the same.
devices with the same link need to apply the same mapping.
it's a bug in the $PIR table, but this is a bug handled by so
many oses, it's not clear that the vbox guys would know about
the problem.

if this is the case, a small reorg of the $PIR handling code
should be able to recognize and handle this case.  if someone
could send me a dump of a problematic vbox $PIR table that would
be great.  you can dump it by changingthe if(0) to if(1) in
pci.c:/^pcirouting\( — /sys/src/9/pc/pci.c:811,813.

> Thanks to Erik for all his help.

no problems.  too bad it still doesn't work quite right.

- erik

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[ron minnich]

Many PIR tables on many platforms are just flat-out wrong. As
mentioned here in earlier years, something like 50% of the geode
platforms out there had incorrect PIR tables, and Linux had incorrect
interpretation of those tables inserted which made the 1/2 boards that
were working break (this was all 10 years ago)

Why is it not fixed? Because, nowadays, the thing you're supposed to
use is the ACPI table. We've seen cases where both PIR and _MP_ were
copied from a different motherboard, with no change, and were
completely wrong. It's obvious that most vendors don't care to take
the time to make these tables right.

ron

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[erik quanstrom]

> Why is it not fixed? Because, nowadays, the thing you're supposed to
> use is the ACPI table. We've seen cases where both PIR and _MP_ were
> copied from a different motherboard, with no change, and were
> completely wrong. It's obvious that most vendors don't care to take
> the time to make these tables right.

so why are acpi tables also broken?

☺

- erik

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[ron minnich]

On Fri, Jul 8, 2011 at 10:04 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> Why is it not fixed? Because, nowadays, the thing you're supposed to
>> use is the ACPI table. We've seen cases where both PIR and _MP_ were
>> copied from a different motherboard, with no change, and were
>> completely wrong. It's obvious that most vendors don't care to take
>> the time to make these tables right.
>
> so why are acpi tables also broken?

Because, by and large, the vendors don't understand ACPI very well
either, and they tend to just copy and paste.

But it's still the case for me that PIR and MPI are far less reliable than ACPI.

It's why I've gotten to hate PC hardware so much.

ron

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[Bakul Shah]

On Fri, 08 Jul 2011 10:43:06 PDT ron minnich <rminnich@gmail.com>  wrote:
> On Fri, Jul 8, 2011 at 10:04 AM, erik quanstrom <quanstro@quanstro.net> wrote
> :
> >> Why is it not fixed? Because, nowadays, the thing you're supposed to
> >> use is the ACPI table. We've seen cases where both PIR and _MP_ were
> >> copied from a different motherboard, with no change, and were
> >> completely wrong. It's obvious that most vendors don't care to take
> >> the time to make these tables right.
> >
> > so why are acpi tables also broken?
>
> Because, by and large, the vendors don't understand ACPI very well
> either, and they tend to just copy and paste.
>
> But it's still the case for me that PIR and MPI are far less reliable than AC
> PI.
>
> It's why I've gotten to hate PC hardware so much.

Virtual box is open source. If you guys know how to fix its
emulated PC, I think they will be open to the idea.

Erik, I have sent you the $PIR table data you wanted (with and
without USB enabled).

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[andrey mirtchovski]

reporting success with the latest extension pack

http://download.virtualbox.org/virtualbox/4.1.4/Oracle_VM_VirtualBox_Extension_Pack-4.1.4-74291.vbox-extpack

and the Plan 9 VBox image available online here:
http://downloads.sourceforge.net/virtualboximage/Plan9.vdi.7z

bridged networking with dhcp handled by other infrastructure.

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[Bakul Shah]

On Wed, 06 Jul 2011 11:40:08 PDT Bakul Shah <bakul@bitblocks.com>  wrote:
> Good news: 9atom installs fine on virtualbox 4.0.10 (the
>    latest) and most everything works
> Bad news: network access fails

It seems igbe never gets an interrupt (as per ether0/ifstats
rintr == 0, rsleep == 1).  Pkts received count going up may
have to do with some emulated h/w counter incremented by vbox.

To test this theory I changed code to call igbeinterrupt()
every 4 ticks instead of a real interrupt. In igberproc() I
replaced

        sleep(&ctrl->rrendez, igberim, ctlr);
with
        tsleep(&up->sleep, return0, 0, 4);
        igbeinterrupt(0, edev);

And things seem to be working well enough for '9fs sources'
etc.!  Note: this is just a test hack. Ideally interrupt
handling under vbox is fixed up by someone knowledgeable (I
haven't dealt with this stuff in ages).

Re: [9fans] 9atom & virtualbox 4.0.10 networking issue

[erik quanstrom]

> It seems igbe never gets an interrupt (as per ether0/ifstats
> rintr == 0, rsleep == 1).  Pkts received count going up may
> have to do with some emulated h/w counter incremented by vbox.
>
> To test this theory I changed code to call igbeinterrupt()
> every 4 ticks instead of a real interrupt. In igberproc() I
> replaced
>
>         sleep(&ctrl->rrendez, igberim, ctlr);
> with
>         tsleep(&up->sleep, return0, 0, 4);
>         igbeinterrupt(0, edev);
>
> And things seem to be working well enough for '9fs sources'
> etc.!  Note: this is just a test hack. Ideally interrupt
> handling under vbox is fixed up by someone knowledgeable (I
> haven't dealt with this stuff in ages).

can you send me the output of /dev/irqalloc?

- erik