Date: Wed, 5 Mar 2014 09:58:15 +0400 From: Oleg Sidorkin <osidorkin@gmail.com> To: Alexander Motin <mav@freebsd.org> 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: <CAGw%2Bup%2BR387c%2BKRUUfb6Rs4Pe9y4Ygq95CPPE=%2BBs%2BvjJhARVg@mail.gmail.com> In-Reply-To: <5315B3B1.5080909@FreeBSD.org> References: <CAGw%2BupKNWa1gjXckU5=CnyUEX2FXES-fn1b0mDbrdJJBRzMzqw@mail.gmail.com> <794fb75db92a4df0991a147919727277@BL2PR03MB210.namprd03.prod.outlook.com> <CAGw%2BupLhFNDB7T=ziiTBqYv3DPvDuQ=FZ89h=PM5NQVG%2BmrB-A@mail.gmail.com> <5268B533.80408@FreeBSD.org> <CAGw%2BupJOfFvG2u8HvbCJD4uzp_gGS18LvLeF8AZs4ARKuiYgUw@mail.gmail.com> <5315B3B1.5080909@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
That's great! Thanks a lot. On Tue, Mar 4, 2014 at 3:06 PM, Alexander Motin <mav@freebsd.org> wrote: > Oleg, > > It was found that real problem is not there. You do not need manual > scanning. You should remove it. All you really need is to properly report > bus to CAM: > > @@ -1147,7 +1062,7 @@ > cpi->hba_eng_cnt = 0; > cpi->max_target = STORVSC_MAX_TARGETS; > cpi->max_lun = sc->hs_drv_props->drv_max_luns_per_target; > - cpi->initiator_id = 0; > + cpi->initiator_id = cpi->max_lun + 1; > cpi->bus_id = cam_sim_bus(sim); > cpi->base_transfer_speed = 300000; > cpi->transport = XPORT_SAS; > > Default scanner skips initiator from the process, so initiator_id = 0 > excluded from scan the only really used target. > > > On 04.03.2014 12:37, Oleg Sidorkin wrote: >> >> 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@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@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 >> >> >> >> > > > -- > Alexander Motin -- Oleg Sidorkin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGw%2Bup%2BR387c%2BKRUUfb6Rs4Pe9y4Ygq95CPPE=%2BBs%2BvjJhARVg>