Possibly an instance of PR kern/52106 ?
On Sat, Aug 19, 2017 at 12:45:02PM +0000, Chavdar Ivanov wrote:
> Hi,
>
> I went through my configuration with a fine comb, comparing it with a
> multitude of setups one can easily find on the net - and with the fine
> manuals, of course. I could not find anything apparently wrong. For the
> sake of the test I added another DOMU, this time 64 bit, with the same
> results - the DOMUs communicate fine with the DOM0 and between themselves,
> but they see only arp traffic from the rest of the wireless network (and
> the rest of the network also can see their arp requests).
>
> Today it came to me that it might be a peculiarity of the wireless router (
> a Virgin SuperHub 3 ) or with the driver wireless interface - iwn - so I
> switched to wired interface (wm), connected to the same SuperHub 3. The
> guest networking through the bridge now works as expected, but I am none
> the wiser as to where the problem is with the wireless interface (I'd
> rather keep it wireless, don't like CAT5 cables across the room...).
>
> One weird peculiarity of the iwn interface on this laptop is that - while
> it is kept running all the time and (almost) never loses network
> connection, the other hosts lose connection to it after they are restarted
> or came from sleep, the only way of restoring the connection from them to
> the NetBSD machine is to do a ping from the NetBSD machine to the others...
> Go figure.
>
> The (almost) above refers to the occasional firmware error this interface
> gives, perhaps once a week, which is resolved by downing and upping it.
>
> So the question (finally) is: should we expect bridging to work when using
> a wireless device (especially a iwn driver).
>
> Chavdar Ivanov
>
> On Mon, 31 Jul 2017 at 11:47 Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>
> > One more hang shutting down the DOMU, happens with 'xl shutdown foo' in
> > the DOMU console:
> >
> > ---
> > foo# xenbus_shutdown_handler: xenbus_rm 13
> >
> > *** FINAL System shutdown message from root@foo ***
> > System going down IMMEDIATELY
> >
> > power button pressed
> >
> > Jul 31 10:43:13 foo shutdown: poweroff by root: power button pressed
> > Jul 31 10:43:21 foo syslogd[189]: Exiting on signal 15
> > syncing disks... done
> > xenbus: can't get state for device/suspend/event-channel (2)
> > ? xci
> > ----
> >
> > From this moment onward the system responds to ping and the CR is echoed,
> > but that is all. Only hard reset clears it.
> >
> > On Mon, 31 Jul 2017 at 09:28 Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
> >
> >> Hi,
> >>
> >> After I managed - with the help of few - to get my old Thinkpad T61p to
> >> work fine under -current (with two separate downgrades) I decided -
> >> following a recent discussion about hypervisors here - to try again Xen
> >> with NetBDSD-current amd64 as DOM0, largely following the Howto document
> >> (which is in need of an update - at least to mention that Xen48 is now in
> >> pkgsrc). Apart from a few minor problems (i.e. incorrect placement of the
> >> ocaml output files in the work tree during compilation, I just copied them
> >> where they were expected) all went as expected. I am running now a
> >> NetBSD-i386 DOMU which is able to communicate with the DOM0, but for the
> >> helll of it I can't figure out how to configure the bridge to pass IP
> >> traffic. Bridge(4) says:
> >> ...
> >> Transparent filtering for IP and IPv6 packets can be added with the
> >> kernel configuration option options BRIDGE_IPF.
> >>
> >> When filtering is enabled, bridged packets will pass through the filter
> >> inbound on the originating interface and outbound on the appropriate
> >> interfaces. ARP and REVARP packets are forwarded without being filtered
> >> and others that are not IP nor IPv6 packets are not forwarded when
> >> filtering is enabled.
> >> ---
> >>
> >> So with the original netbsd-XEN3PAE_DOMU kernel I can see ARP traffic
> >> coming and going (i.e. when an external host tries to ping the DOMU I cn
> >> see the arp packet coming into the DOMU, when the DOMU tries to ping an
> >> external host I can see its arp packet on that host interface - with
> >> tcpdump). As I said earlier, the networking between the DOM0 and DOMU works
> >> fine. Then I modified the XEN3PAE kernel to include BRIDGE_IPF and also the
> >> options for pf - but I could not get any third party packets to or from the
> >> DOMU.
> >>
> >> The ifconfig.bridge0 is as follows:
> >>
> >> create
> >> up
> >> !brconfig bridge0 add iwn0
> >>
> >> I don't know if it is significant that the interface in this case is
> >> wireless.
> >>
> >> Besides that, I got one panic apparently ACPI related of the DOM0:
> >>
> >> ---
> >> crash crash -M netbsd.1.core -N netbsd.1
> >> Crash version 8.99.1, image version 8.99.1.
> >> System panicked: trap
> >> Backtrace from time of crash is available.
> >> crash> bt
> >> _KERNEL_OPT_NARCNET() at 0
> >> _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x5
> >> vpanic() at vpanic+0x149
> >> snprintf() at snprintf
> >> trap() at trap+0xc6b
> >> --- trap (number 6) ---
> >> ahci_intr_port() at ahci_intr_port+0x1e
> >> ahci_intr() at ahci_intr+0xa5
> >> intr_biglock_wrapper() at intr_biglock_wrapper+0x1d
> >> Xintr_ioapic_level3() at Xintr_ioapic_level3+0xf2
> >> --- interrupt ---
> >> x86_mwait() at x86_mwait+0xd
> >> acpicpu_cstate_idle_enter() at acpicpu_cstate_idle_enter+0xdb
> >> acpicpu_cstate_idle() at acpicpu_cstate_idle+0xb6
> >> idle_loop() at idle_loop+0x18c
> >> ----
> >> There are a lot of ACPI error messages in the DOM0 dmesg, so I wasn't too
> >> bothered with it, and it happened only once, I have since been able to do a
> >> full sysbuild under the DOM0 kernel). There were also a couple of hangs of
> >> the DOM0, apparently taking place when the DOMU is being shut down or
> >> poweroff-ed, resulting in a system responding to pings, but otherwise
> >> unable to do anything - just echoing the CR (I've interrupted this and took
> >> a screenshot of the trace here - http://bit.ly/2tVxnvX ).
> >>
> >> Any ideas?
> >>
> >> Chavdar Ivanov
> >>
> >> (I don't know if current-users is the best list to post this, but as both
> >> domains are
> >>
> >> NetBSD nt61p 8.99.1 NetBSD 8.99.1 (MYXEN) #0: Sun Jul 30 23:46:27 UTC
> >> 2017 root@nt61p:/usr/src/sys/arch/amd64/compile/MYXEN amd64
> >>
> >> and
> >>
> >> NetBSD foo 8.99.1 NetBSD 8.99.1 (XEN3PAE_DOMU) #1: Tue Jul 25 17:56:26
> >> UTC 2017 sysbuild@nt61p:/home/sysbuild/i386/obj/home/sysbuild/src/sys/arch/i386/compile/XEN3PAE_DOMU
> >> i386
> >>
> >> it probably is).
> >>
> >>