Date: Tue, 04 Mar 2014 13:06:25 +0200 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: <5315B3B1.5080909@FreeBSD.org> In-Reply-To: <CAGw%2BupJOfFvG2u8HvbCJD4uzp_gGS18LvLeF8AZs4ARKuiYgUw@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> <5268B533.80408@FreeBSD.org> <CAGw%2BupJOfFvG2u8HvbCJD4uzp_gGS18LvLeF8AZs4ARKuiYgUw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5315B3B1.5080909>