[Bug 226562] [stable/10] backport pci/cardbus hot-remove support from FreeBSD 11 to 10

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Mon Mar 12 21:53:18 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226562

Dexuan Cui <decui at microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |decui at microsoft.com

--- Comment #1 from Dexuan Cui <decui at microsoft.com> ---
How to reproduce the issue:

1. build & install a stable/10 kernel in a VM running on Windows Server 2016
with Mellanox ConnectX-3 device that supports SR-IOV: 

2. Enable SR-IOV for the VM by assigning a VF to the VM:

[root at decui-103 ~]# hn1: vmbus0: chan34 subidx0 offer
got notify, nvs type 128
vmbus0: chan34 assigned to cpu0 [vcpu0]
pcib1: <Hyper-V PCI Express Pass Through> on vmbus0
pcib0: allocated type 3 (0xfe0000000-0xfe0001fff) for rid 0 of pcib1
vmbus0: allocated type 3 (0xfe0000000-0xfe0001fff) for rid 0 of pcib1
pcib1: gpadl_conn(chan34) succeeded
pcib1: chan34 opened
pci1: <PCI bus> on pcib1
pci1: domain=2, physical bus=0
found-> vendor=0x15b3, dev=0x1004, revid=0x00
        domain=2, bus=0, slot=2, func=0
        class=02-00-00, hdrtype=0x00, mfdev=0
        cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords)
        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
        MSI-X supports 52 messages in map 0x18
        map[18]: type Prefetchable Memory, range 64, base 0, size 23, memory
disabled
pci1: <network, ethernet> at device 2.0 (no driver attached)

[root at decui-103 ~]#
[root at decui-103 ~]# pciconf -l
...
none1 at pci2:0:2:0:       class=0x020000 card=0x61b015b3 chip=0x100415b3 rev=0x00
hdr=0x00

3. disable the VF for the VM:

[root at decui-103 ~]# pcib1: chan34 revoked
hn1: pcib1: got notify, nvs type 128
chan34 detached
pci1: detached
pcib1: chan34 closed
pcib1: detached
vmbus0: chan34 freed

[root at decui-103 ~]#
[root at decui-103 ~]# pciconf -l
...
none1 at pci2:0:2:0:       class=0x020000 card=0x61b015b3 chip=0x100415b3 rev=0x00
hdr=0x00

Here 'pciconf -l' should not show the VF any more while it does.

4. Repeat steps 2 and 3 a few times (usually I only need to repeat them 2~5
times), the VM will panic:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 14; apic id = 0e
instruction pointer     = 0x20:0xffffffff809bac4a
stack pointer           = 0x28:0xfffffe00002f48d0
frame pointer           = 0x28:0xfffffe00002f48f0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 0 (vmbusdev)
trap number             = 9
panic: general protection fault
cpuid = 14
KDB: stack backtrace:
#0 0xffffffff809c64c0 at kdb_backtrace+0x60
#1 0xffffffff80986c86 at vpanic+0x126
#2 0xffffffff80986b53 at panic+0x43
#3 0xffffffff80da647d at trap_fatal+0x35d
#4 0xffffffff80da6104 at trap+0x784
#5 0xffffffff80d8b5dc at calltrap+0x8
#6 0xffffffff809bab05 at device_delete_child+0x15
#7 0xffffffff809bab18 at device_delete_child+0x28
#8 0xffffffff80e3ad2c at hv_pci_delete_device+0x9c
#9 0xffffffff80e3b113 at hv_eject_device_work+0x23
#10 0xffffffff809d7a05 at taskqueue_run_locked+0xf5
#11 0xffffffff809d8858 at taskqueue_thread_loop+0xb8
#12 0xffffffff8094d61a at fork_exit+0x9a
#13 0xffffffff80d8bb1e at fork_trampoline+0xe

I suspect the VM is accessing some free()'d memory when it hits the panic.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list