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 <[email protected]> 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 <[email protected]> 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). > >> > >>
