[Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project
Oleg Sidorkin
osidorkin at gmail.com
Tue Mar 4 10:37:50 UTC 2014
Hi again.
Disabling scan_for_luns leaves drives undetected.
Calling xpt_rescan for each lun works for me. With the attached patch
system boots and detects all configured drives.
But also this patch introduces a race between drives detection and
boot process, so sometimes system tries to mount undetected drive.
I'm going to fix this by calling xpt_hold_boot() before xpt_rescan()
and calling xpt_release_boot() in callback.
Thanks
On Thu, Oct 24, 2013 at 9:50 AM, Alexander Motin <mav at freebsd.org> wrote:
> Hi.
>
> I took some look and think problems are in scan_for_luns() routine:
> - After the locking changes scanning normally uses different locks, not the
> SIM one. That probably caused panic.
> - But I think that scanning is simply not needed there -- FreeBSD CAM scans
> every new bus automatically on registration (Even for late registered buses
> it is done I think at least since FreeBSD 8). I think everything should just
> work if you remove scan_for_luns() at all.
> - If you still wish to force scan (due to having information about changed
> list of devices, etc), then you can make CAM do all the magic for you by
> calling xpt_rescan().
>
>
> On 24.10.2013 08:34, Oleg Sidorkin wrote:
>>
>> Hello again.
>>
>> Camlock patches are now committed and -CURRENT on Hyper-V now panics
>> with almost the same stacktrace:
>>
>> FreeBSD 11.0-CURRENT #16 r257016: Wed Oct 23 21:08:44 UTC 2013
>> olsi at current:/usr/obj/usr/src/sys/HYPERVKERNEL amd64
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>> CPU: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz (1309.57-MHz K8-class CPU)
>> Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a
>> Stepping = 7
>>
>> ......
>>
>> ZFS filesystem version: 5
>> ZFS storage pool version: features support (5000)
>> Timecounters tick every 10.000 msec
>> storvsc0 on vmbus0
>> kernel trap 12 with interrupts disabled
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 00
>> fault virtual address = 0x20
>> fault code = supervisor read data, page not present
>> instruction pointer = 0x20:0xffffffff804f58cc
>> stack pointer = 0x28:0xfffffe011dd5f5d0
>> frame pointer = 0x28:0xfffffe011dd5f600
>> code segment = base 0x0, limit 0xfffff, type 0x1b
>> = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = resume, IOPL = 0
>> current process = 0 (hv_control_1 taskq)
>> [ thread pid 0 tid 100047 ]
>> Stopped at turnstile_broadcast+0x8c: movq
>> 0x20(%rbx,%rax,1),%rdx
>> db> bt
>> Tracing pid 0 tid 100047 td 0xfffff8000331e000
>> turnstile_broadcast() at turnstile_broadcast+0x8c/frame 0xfffffe011dd5f600
>> __mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame 0xfffffe011dd5f630
>> unlock_mtx() at unlock_mtx+0x2a/frame 0xfffffe011dd5f640
>> _sleep() at _sleep+0x18e/frame 0xfffffe011dd5f6c0
>> cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfffffe011dd5f7f0
>> storvsc_attach() at storvsc_attach+0x6d4/frame 0xfffffe011dd5f890
>> device_attach() at device_attach+0x3a2/frame 0xfffffe011dd5f8f0
>> hv_vmbus_child_device_register() at
>> hv_vmbus_child_device_register+0xdb/frame 0xfffffe011dd5f990
>> vmbus_channel_process_offer() at
>> vmbus_channel_process_offer+0x133/frame 0xfffffe011dd5f9d0
>> work_item_callback() at work_item_callback+0x26/frame 0xfffffe011dd5f9f0
>> taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame
>> 0xfffffe011dd5fa40
>> taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame
>> 0xfffffe011dd5fa70
>> fork_exit() at fork_exit+0x9a/frame 0xfffffe011dd5fab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe011dd5fab0
>> --- trap 0, rip = 0, rsp = 0xfffffe011dd5fb70, rbp = 0 ---
>>
>>
>> Thanks
>>
>> On Tue, Sep 24, 2013 at 3:04 AM, Abhishek Gupta (LIS)
>> <abgupta at microsoft.com> wrote:
>>>
>>> Hi Oleg,
>>>
>>> Please give us some time. I shall look at it. Thanks for reporting.
>>>
>>> Regards,
>>> Abhishek
>>>
>>> -----Original Message-----
>>> From: owner-freebsd-virtualization at freebsd.org
>>> [mailto:owner-freebsd-virtualization at freebsd.org] On Behalf Of Oleg Sidorkin
>>> Sent: Monday, September 23, 2013 7:21 AM
>>> To: freebsd-virtualization at freebsd.org
>>> Cc: Alexander Motin
>>> Subject: [Hyper-V][camlock] storvsc driver panics during boot with
>>> patches from camlock project
>>>
>>> Hello.
>>>
>>> I'm running the latest current (amd64) under Hyper-V with hyper-v
>>> services enabled.
>>> If camlock patches are applied
>>> (http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch),
>>> I'm hitting the following kernel panic during boot:
>>>
>>> FreeBSD 10.0-ALPHA2 #5 r255762M: Sun Sep 22 16:48:21 UTC 2013
>>> olsi at current:/usr/obj/usr/src/sys/HYPERVKERNEL amd64 FreeBSD clang
>>> version 3.3 (tags/RELEASE_33/final 183502) 20130610
>>> CPU: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz (1309.17-MHz K8-class CPU)
>>> Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a
>>> Stepping =
>>> 7
>>> ....
>>> Timecounter "Hyper-V" frequency 10000000 Hz quality 10000000 ZFS NOTICE:
>>> Prefetch is disabled by default if less than 4GB of RAM is present;
>>> to enable, add "vfs.zfs.prefetch_disable=0" to
>>> /boot/loader.conf.
>>> ZFS filesystem version: 5
>>> ZFS storage pool version: features support (5000) Timecounters tick every
>>> 10.000 msec
>>> storvsc0 on vmbus0
>>> Netvsc initializing... SMP: AP CPU #3 Launched!
>>> SMP: AP CPU #2 Launched!
>>> SMP: AP CPU #1 Launched!
>>> kernel trap 12 with interrupts disabled
>>>
>>>
>>> Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03
>>> fault virtual address = 0x20
>>> fault code = supervisor read data, page not present
>>> instruction pointer = 0x20:0xffffffff804f444c
>>> stack pointer = 0x28:0xfffffe011df38610
>>> frame pointer = 0x28:0xfffffe011df38640
>>> code segment = base 0x0, limit 0xfffff, type 0x1b
>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags = resume, IOPL = 0
>>> current process = 0 (hv_control_1 taskq)
>>> [ thread pid 0 tid 100046 ]
>>> Stopped at turnstile_broadcast+0x8c: movq
>>> 0x20(%rbx,%rax,1),%rdx
>>> db> bt
>>> Tracing pid 0 tid 100046 td 0xfffff80001f20490
>>> turnstile_broadcast() at turnstile_broadcast+0x8c/frame
>>> 0xfffffe011df38640
>>> __mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame 0xfffffe011df38670
>>> unlock_mtx() at unlock_mtx+0x2a/frame 0xfffffe011df38680
>>> _sleep() at _sleep+0x18e/frame 0xfffffe011df38700
>>> cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfffffe011df38800
>>> storvsc_attach() at storvsc_attach+0x6d4/frame 0xfffffe011df388a0
>>> device_attach() at device_attach+0x396/frame 0xfffffe011df388f0
>>> hv_vmbus_child_device_register() at
>>> hv_vmbus_child_device_register+0xdb/frame 0xfffffe011df38990
>>> vmbus_channel_process_offer() at
>>> vmbus_channel_process_offer+0x133/frame 0xfffffe011df389d0
>>> work_item_callback() at work_item_callback+0x26/frame 0xfffffe011df389f0
>>> taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame
>>> 0xfffffe011df38a40
>>> taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame
>>> 0xfffffe011df38a70
>>> fork_exit() at fork_exit+0x9a/frame 0xfffffe011df38ab0
>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe011df38ab0
>>> --- trap 0, rip = 0, rsp = 0xfffffe011df38b70, rbp = 0 ---
>>> db>
>>>
>>>
>>> This patch is not commited yet (CFT thread with changes description is
>>> here:
>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2013-September/043333.html),
>>> but it is going to be commited till the end of the year.
>>>
>>> As far as I understand, the invocation chain is
>>> storvsc_attach->scan_for_luns->cam_periph_runccb
>>>
>>> Thanks
>>> --
>>> Oleg Sidorkin
>>> _______________________________________________
>>> freebsd-virtualization at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
>>> To unsubscribe, send any mail to
>>> "freebsd-virtualization-unsubscribe at freebsd.org"
>>
>>
>>
>>
>
>
> --
> Alexander Motin
--
Oleg Sidorkin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: storvsc.patch
Type: application/octet-stream
Size: 2741 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20140304/205ec0b0/attachment.obj>
More information about the freebsd-virtualization
mailing list