From owner-freebsd-virtualization@FreeBSD.ORG Tue Mar 4 11:06:31 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CFDBA45 for ; Tue, 4 Mar 2014 11:06:31 +0000 (UTC) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCDB0229 for ; Tue, 4 Mar 2014 11:06:30 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id d17so4621211eek.18 for ; Tue, 04 Mar 2014 03:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0YAoDnhCERd05fOpEFcctcaiHGKNSyAjPOELIYx5f7A=; b=Z1CRWnvmJDN4g0ZWGUIrNXZjy34epiHE33EhlbU/F5JdcHG2rMI4xMdlhRSZv9pdwh Cvc9ZqdUrbsh4PiXD4fnms8zRo3UIqeHjp3FeFjA6VcbS0234x/LqkifJusR6RszdeLQ uI2DTBB+ymsx4/+NW0u8ob0Sy3sZQS0bDPqsaonMLuRb3UrrDr5EjkGH3H8Y5DN2VgfI G9KJI+zEuHZUwvK5pc0TIIAFUtK3RqDODdBN1YZpj5dT9sCT1yvxSK5hGh3r5FLRBKRH kFt7Nk/P6N/Ju+qFY5bBLrRQekv/Tv+8+ezLx2xO36xM1IQi9pcNr9w5rt75631mjFzV oEHg== X-Received: by 10.15.21.2 with SMTP id c2mr45645936eeu.77.1393931189181; Tue, 04 Mar 2014 03:06:29 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id q44sm61564656eez.1.2014.03.04.03.06.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 03:06:28 -0800 (PST) Sender: Alexander Motin Message-ID: <5315B3B1.5080909@FreeBSD.org> Date: Tue, 04 Mar 2014 13:06:25 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Oleg Sidorkin Subject: Re: [Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project References: <794fb75db92a4df0991a147919727277@BL2PR03MB210.namprd03.prod.outlook.com> <5268B533.80408@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-virtualization@freebsd.org" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:06:31 -0000 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 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) >>> 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