Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Oct 2013 08:50:43 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        Oleg Sidorkin <osidorkin@gmail.com>
Cc:        "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org>
Subject:   Re: [Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project
Message-ID:  <5268B533.80408@FreeBSD.org>
In-Reply-To: <CAGw%2BupLhFNDB7T=ziiTBqYv3DPvDuQ=FZ89h=PM5NQVG%2BmrB-A@mail.gmail.com>
References:  <CAGw%2BupKNWa1gjXckU5=CnyUEX2FXES-fn1b0mDbrdJJBRzMzqw@mail.gmail.com> <794fb75db92a4df0991a147919727277@BL2PR03MB210.namprd03.prod.outlook.com> <CAGw%2BupLhFNDB7T=ziiTBqYv3DPvDuQ=FZ89h=PM5NQVG%2BmrB-A@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@freebsd.org [mailto:owner-freebsd-virtualization@freebsd.org] On Behalf Of Oleg Sidorkin
>> Sent: Monday, September 23, 2013 7:21 AM
>> To: freebsd-virtualization@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@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
>> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org"
>
>
>


-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5268B533.80408>