Re: Xen 4.8 on -current

[Chavdar Ivanov]

Yes, it looks the same. Although somehow for the last couple of days it
stays on I don't have to ping anything from the laptop out (and it is
indeed that one has to ping the machine one wants to ssh from - the
Internet connection of the laptop with iwn appears to be working.

(the '? xci' seen is just the next prompt after the DOMU shutdown I was
refering to).

Chavdar

On Mon, 21 Aug 2017 at 11:32 Patrick Welche  wrote:

> Possibly an instance of PR kern/52106 ?
>
> On Sat, Aug 19, 2017 at 12:45:02PM +, 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  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  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
> > >> 

Re: Xen 4.8 on -current

[Patrick Welche]

Possibly an instance of PR kern/52106 ?

On Sat, Aug 19, 2017 at 12:45:02PM +, 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  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  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
> 

Re: Xen 4.8 on -current

[Chavdar Ivanov]

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  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  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() 

Re: Xen 4.8 on -current

[Chavdar Ivanov]

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  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).
>
>

Xen 4.8 on -current

[Chavdar Ivanov]

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).