Bug 234341 - [Hyper-V] accessing hn0 when running CURRENT under Hyper-V on Windows 10 Pro crashes the machine
Summary: [Hyper-V] accessing hn0 when running CURRENT under Hyper-V on Windows 10 Pro ...
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-24 10:42 UTC by Martin Birgmeier
Modified: 2019-02-08 16:01 UTC (History)
1 user (show)

See Also:


Attachments
core.txt.0 created by savecore (64.33 KB, text/plain)
2019-02-02 16:16 UTC, Martin Birgmeier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2018-12-24 10:42:48 UTC
Scenario 1:
- Running CURRENT (r341726) under Hyper-V on Windows 10 Professional
- Using legacy networking in Hyper-V
- loading if_de in boot/loader.conf

Result 1:
- Working fine.

Scenario 2:
- Running CURRENT (r341726) under Hyper-V on Windows 10 Professional
- Using virtualized networking in Hyper-V
- loading hv_netvsc, hv_storvsc, hv_utils, hv_vmbus in boot/loader.conf

Result 2:
- Sending single packets across hn0 works (single-user, using ping)
- When accessing hn0 with a little higher load, the machine crashes (Hyper-V reverts to nun-running state)
- No core dump etc.

Scenario 3:
- Running openSUSE 15.0 under Hyper-V on Windows 10 Professional
- Using virtualized networking in Hyper-V

Result 3:
- Working fine.

For the FreeBSD kernel configuration, I have a few settings which might influence the crash in result 2:
options         DEVICE_POLLING          # helped with some old hardware
options         NO_ADAPTIVE_MUTEXES     # helps with running in VirtualBox
options         NO_ADAPTIVE_RWLOCKS     # ...
options         NO_ADAPTIVE_SX          # ...

Could any of these be the reason for the issue I see? Anything else I should look out for?

-- Martin
Comment 1 Martin Birgmeier 2019-02-02 15:50:34 UTC
I just tried this again with head as of r343663, again with an immediate panic when accessing the virtual network interface.

I can run FreeBSD under Hyper-V only using the legacy network adapter. Alas, this is de(4) which is slated for removal soon. So the problem is becoming more pressing.

Is there anyone running FreeBSD successfully under Hyper-V on Windows 10 Pro? If yes, are there any special settings needed?

Here is a kgdb session of the crash dump written from ddb. Note that if_de was not loaded when the crash occurred, I guess it is only read by kgdb because I changed /boot/loader.conf back to using it.

[0]# /usr/libexec/kgdb /boot/kernel/kernel /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
<118>Clearing /tmp (X related).

Fatal double fault
rip 0x226489 rsp 0x7fffffffe3d0 rbp 0x7fffffffe3d0
rax 0 rdx 0 rbx 0x80072f005
rcx 0x80072ba18 rsi 0x80079b000 rdi 0x80072b9e7
r8 0x1 r9 0x80072ba88 r10 0x80072ba00
r11 0 r12 0 r13 0x7fffffffe4e0
r14 0x80072b9c0 r15 0 rflags 0x10206
cs 0x43 ss 0x3b ds 0x3b es 0x3b fs 0x13 gs 0x1b
fsbase 0x8002548d0 gsbase 0xffffffff80e14500 kgsbase 0
cpuid = 1; apic id = 01
timeout stopping cpus
panic: double fault
cpuid = 1
time = 1549121393
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00012f5da0
vpanic() at vpanic+0x1b4/frame 0xfffffe00012f5e00
panic() at panic+0x43/frame 0xfffffe00012f5e60
dblfault_handler() at dblfault_handler+0x1de/frame 0xfffffe00012f5f30
Xdblfault() at Xdblfault+0xc3/frame 0xfffffe00012f5f30
--- trap 0x17, rip = 0x226489, rsp = 0x7fffffffe3d0, rbp = 0x7fffffffe3d0 ---
KDB: enter: panic

Reading symbols from /boot/kernel/agp.ko...Reading symbols from /usr/lib/debug//boot/kernel/agp.ko.debug...done.
done.
Loaded symbols for /boot/kernel/agp.ko
Reading symbols from /boot/kernel/ataintel.ko...Reading symbols from /usr/lib/debug//boot/kernel/ataintel.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ataintel.ko
Reading symbols from /boot/kernel/atapci.ko...Reading symbols from /usr/lib/debug//boot/kernel/atapci.ko.debug...done.
done.
Loaded symbols for /boot/kernel/atapci.ko
Reading symbols from /boot/kernel/ata.ko...Reading symbols from /usr/lib/debug//boot/kernel/ata.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ata.ko
Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /usr/lib/debug//boot/kernel/ahci.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ahci.ko
Reading symbols from /boot/kernel/smb.ko...Reading symbols from /usr/lib/debug//boot/kernel/smb.ko.debug...done.
done.
Loaded symbols for /boot/kernel/smb.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /usr/lib/debug//boot/kernel/smbus.ko.debug...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/intpm.ko...Reading symbols from /usr/lib/debug//boot/kernel/intpm.ko.debug...done.
done.
Loaded symbols for /boot/kernel/intpm.ko
Reading symbols from /boot/kernel/speaker.ko...Reading symbols from /usr/lib/debug//boot/kernel/speaker.ko.debug...done.
done.
Loaded symbols for /boot/kernel/speaker.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /usr/lib/debug//boot/kernel/snd_hda.ko.debug...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from /usr/lib/debug//boot/kernel/sound.ko.debug...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/if_le.ko...Reading symbols from /usr/lib/debug//boot/kernel/if_le.ko.debug...done.
done.
Loaded symbols for /boot/kernel/if_le.ko
Reading symbols from /boot/kernel/hv_netvsc.ko...Reading symbols from /usr/lib/debug//boot/kernel/hv_netvsc.ko.debug...done.
done.
Loaded symbols for /boot/kernel/hv_netvsc.ko
Reading symbols from /boot/kernel/hv_vmbus.ko...Reading symbols from /usr/lib/debug//boot/kernel/hv_vmbus.ko.debug...done.
done.
Loaded symbols for /boot/kernel/hv_vmbus.ko
Reading symbols from /boot/kernel/geom_label.ko...Reading symbols from /usr/lib/debug//boot/kernel/geom_label.ko.debug...done.
done.
Loaded symbols for /boot/kernel/geom_label.ko
Reading symbols from /boot/kernel/geom_md.ko...Reading symbols from /usr/lib/debug//boot/kernel/geom_md.ko.debug...done.
done.
Loaded symbols for /boot/kernel/geom_md.ko
Reading symbols from /boot/kernel/procfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/procfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/procfs.ko
Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from /usr/lib/debug//boot/kernel/pseudofs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/pseudofs.ko
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/fdescfs.ko
Reading symbols from /boot/kernel/if_de.ko...Reading symbols from /usr/lib/debug//boot/kernel/if_de.ko.debug...done.
done.
Loaded symbols for /boot/kernel/if_de.ko
#0  doadump (textdump=<value optimized out>) at pcpu.h:230
230     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) where
#0  doadump (textdump=<value optimized out>) at pcpu.h:230
#1  0xffffffff80343dcb in db_dump (dummy=<value optimized out>, 
    dummy2=<value optimized out>, dummy3=<value optimized out>, 
    dummy4=<value optimized out>)
    at /.../hal/z/SRC/FreeBSD/head/sys/ddb/db_command.c:574
#2  0xffffffff80343b99 in db_command (cmd_table=<value optimized out>, 
    dopager=1) at /.../hal/z/SRC/FreeBSD/head/sys/ddb/db_command.c:481
#3  0xffffffff80343914 in db_command_loop ()
    at /.../hal/z/SRC/FreeBSD/head/sys/ddb/db_command.c:534
#4  0xffffffff80346b5f in db_trap (type=<value optimized out>, 
    code=<value optimized out>)
    at /.../hal/z/SRC/FreeBSD/head/sys/ddb/db_main.c:252
#5  0xffffffff804fcc14 in kdb_trap (type=3, code=0, tf=<value optimized out>)
    at /.../hal/z/SRC/FreeBSD/head/sys/kern/subr_kdb.c:692
#6  0xffffffff8073fcbc in trap (frame=0xfffffe00012f5cd0)
    at /.../hal/z/SRC/FreeBSD/head/sys/amd64/amd64/trap.c:619
#7  0xffffffff8071c445 in calltrap ()
    at /.../hal/z/SRC/FreeBSD/head/sys/amd64/amd64/exception.S:232
#8  0xffffffff804fc31b in kdb_enter (why=0xffffffff807fea12 "panic", 
    msg=<value optimized out>) at cpufunc.h:65
#9  0xffffffff804b2781 in vpanic (fmt=<value optimized out>, 
    ap=0xfffffe00012f5e40)
    at /.../hal/z/SRC/FreeBSD/head/sys/kern/kern_shutdown.c:866
---Type <return> to continue, or q <return> to quit---
#10 0xffffffff804b25a3 in panic (fmt=<value optimized out>)
    at /.../hal/z/SRC/FreeBSD/head/sys/kern/kern_shutdown.c:804
#11 0xffffffff807406ce in dblfault_handler (frame=<value optimized out>)
    at /.../hal/z/SRC/FreeBSD/head/sys/amd64/amd64/trap.c:970
#12 0xffffffff8071c573 in Xdblfault ()
    at /.../hal/z/SRC/FreeBSD/head/sys/amd64/amd64/exception.S:294
#13 0x0000000000226489 in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb)
Comment 2 Martin Birgmeier 2019-02-02 16:16:11 UTC
Created attachment 201637 [details]
core.txt.0 created by savecore
Comment 3 Mark Millard 2019-02-03 00:23:20 UTC
(In reply to Martin Birgmeier from comment #1)

Not that I've done much besides defaults off of basic selections but:

# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
	inet6 . . .
	inet6 . . .
	inet 127.0.0.1 netmask 0xff000000 
	groups: lo 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
hn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8051b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,LRO,LINKSTATE>
	ether . . .
	inet6 . . . 
	inet6 . . . 
	inet . . . 
	media: Ethernet autoselect (10Gbase-T <full-duplex>)
	status: active
	nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

# uname -apKU
FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #6 r343670M: Fri Feb  1 16:17:07 PST 2019     markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG  amd64 amd64 1300010 1300010

# kldstat
Id Refs Address                Size Name
 1    9 0xffffffff80200000  2dac788 kernel
 2    1 0xffffffff8321a000     2678 intpm.ko
 3    1 0xffffffff8321d000      b40 smbus.ko
 4    1 0xffffffff8321e000     1600 imgact_binmisc.ko
 5    1 0xffffffff83220000     1ce8 filemon.ko

So no explicit use of any of: hv_netvsc, hv_storvsc, hv_utils, hv_vmbus . However
the manpages say things like:

NAME
     hv_vmbus -- Hyper-V Virtual Machine Bus (VMBus) Driver

SYNOPSIS
     To	compile	this driver into the kernel, place the following lines in the
     system kernel configuration file:

	   device hyperv
	   device pci

And there are (from grep):

/usr/src/sys/amd64/conf/NOTES:device 		hyperv		# HyperV drivers
/usr/src/sys/amd64/conf/GENERIC:device		hyperv			# HyperV drivers 
/usr/src/sys/amd64/conf/MINIMAL:device		pci
/usr/src/sys/amd64/conf/GENERIC:device		pci

where I include the standard GENERIC in my conf file that I use. So I expect that
the 4 are built-in instead of dynamically loaded and so are impliictly in use.


Previously I was at head -r341836 . I've never had problems, going much farther back.
Comment 4 Martin Birgmeier 2019-02-03 12:04:59 UTC
Hi Mark,

Thank you for your feedback.

I have now booted using the GENERIC kernel, and indeed this works fine.

So the question is whether the Hyper-V kernel stuff cannot be loaded as modules, or whether there is an issue with my custom kernel config.

-- Martin
Comment 5 Martin Birgmeier 2019-02-08 16:01:02 UTC
I have modified my custom kernel to include "device hyperv", and indeed this boots successfully.

So the simple answer is that despite some Hyper-V related modules being available they do not seem to be usable. Once could deduce this from the fact that the manpages for the Hyper-V do not mention anything about modules, but it would still be nice if it were stated explicitly.

As it is, the availability of the modules led me to believe that they work, which they don't.

-- Martin