[Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project

2013-09-23 Thread Oleg Sidorkin
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 1000 Hz quality 1000
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:0x804f444c
stack pointer   = 0x28:0xfe011df38610
frame pointer   = 0x28:0xfe011df38640
code segment= base 0x0, limit 0xf, 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:   movq0x20(%rbx,%rax,1),%rdx
db> bt
Tracing pid 0 tid 100046 td 0xf80001f20490
turnstile_broadcast() at turnstile_broadcast+0x8c/frame 0xfe011df38640
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame 0xfe011df38670
unlock_mtx() at unlock_mtx+0x2a/frame 0xfe011df38680
_sleep() at _sleep+0x18e/frame 0xfe011df38700
cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfe011df38800
storvsc_attach() at storvsc_attach+0x6d4/frame 0xfe011df388a0
device_attach() at device_attach+0x396/frame 0xfe011df388f0
hv_vmbus_child_device_register() at
hv_vmbus_child_device_register+0xdb/frame 0xfe011df38990
vmbus_channel_process_offer() at
vmbus_channel_process_offer+0x133/frame 0xfe011df389d0
work_item_callback() at work_item_callback+0x26/frame 0xfe011df389f0
taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame 0xfe011df38a40
taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame 0xfe011df38a70
fork_exit() at fork_exit+0x9a/frame 0xfe011df38ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe011df38ab0
--- trap 0, rip = 0, rsp = 0xfe011df38b70, 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/04.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-unsubscr...@freebsd.org"


RE: [Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project

2013-09-23 Thread Abhishek Gupta (LIS)
Hi Oleg,

Please give us some time. I shall look at it. Thanks for reporting.

Regards,
Abhishek

-Original Message-
From: owner-freebsd-virtualizat...@freebsd.org 
[mailto:owner-freebsd-virtualizat...@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 1000 Hz quality 1000 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:0x804f444c
stack pointer   = 0x28:0xfe011df38610
frame pointer   = 0x28:0xfe011df38640
code segment= base 0x0, limit 0xf, 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:   movq0x20(%rbx,%rax,1),%rdx
db> bt
Tracing pid 0 tid 100046 td 0xf80001f20490
turnstile_broadcast() at turnstile_broadcast+0x8c/frame 0xfe011df38640
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame 0xfe011df38670
unlock_mtx() at unlock_mtx+0x2a/frame 0xfe011df38680
_sleep() at _sleep+0x18e/frame 0xfe011df38700
cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfe011df38800
storvsc_attach() at storvsc_attach+0x6d4/frame 0xfe011df388a0
device_attach() at device_attach+0x396/frame 0xfe011df388f0
hv_vmbus_child_device_register() at
hv_vmbus_child_device_register+0xdb/frame 0xfe011df38990
vmbus_channel_process_offer() at
vmbus_channel_process_offer+0x133/frame 0xfe011df389d0
work_item_callback() at work_item_callback+0x26/frame 0xfe011df389f0
taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame 0xfe011df38a40
taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame 0xfe011df38a70
fork_exit() at fork_exit+0x9a/frame 0xfe011df38ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe011df38ab0
--- trap 0, rip = 0, rsp = 0xfe011df38b70, 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/04.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-unsubscr...@freebsd.org"
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"


Re: [Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project

2013-10-23 Thread Oleg Sidorkin
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:0x804f58cc
stack pointer   = 0x28:0xfe011dd5f5d0
frame pointer   = 0x28:0xfe011dd5f600
code segment= base 0x0, limit 0xf, 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:   movq0x20(%rbx,%rax,1),%rdx
db> bt
Tracing pid 0 tid 100047 td 0xf8000331e000
turnstile_broadcast() at turnstile_broadcast+0x8c/frame 0xfe011dd5f600
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame 0xfe011dd5f630
unlock_mtx() at unlock_mtx+0x2a/frame 0xfe011dd5f640
_sleep() at _sleep+0x18e/frame 0xfe011dd5f6c0
cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfe011dd5f7f0
storvsc_attach() at storvsc_attach+0x6d4/frame 0xfe011dd5f890
device_attach() at device_attach+0x3a2/frame 0xfe011dd5f8f0
hv_vmbus_child_device_register() at
hv_vmbus_child_device_register+0xdb/frame 0xfe011dd5f990
vmbus_channel_process_offer() at
vmbus_channel_process_offer+0x133/frame 0xfe011dd5f9d0
work_item_callback() at work_item_callback+0x26/frame 0xfe011dd5f9f0
taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame 0xfe011dd5fa40
taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame 0xfe011dd5fa70
fork_exit() at fork_exit+0x9a/frame 0xfe011dd5fab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe011dd5fab0
--- trap 0, rip = 0, rsp = 0xfe011dd5fb70, 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-virtualizat...@freebsd.org 
> [mailto:owner-freebsd-virtualizat...@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 1000 Hz quality 1000 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:0x804f444c
> stack pointer   = 0x28:0xfe011df38610
> frame pointer   = 0x28:0xfe011df38640
> code segment= base 0x0, limit 0xf, 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:   movq0x20(%rbx,%rax,1),%rdx
> d

Re: [Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project

2013-10-23 Thread Alexander Motin

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:0x804f58cc
stack pointer   = 0x28:0xfe011dd5f5d0
frame pointer   = 0x28:0xfe011dd5f600
code segment= base 0x0, limit 0xf, 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:   movq0x20(%rbx,%rax,1),%rdx
db> bt
Tracing pid 0 tid 100047 td 0xf8000331e000
turnstile_broadcast() at turnstile_broadcast+0x8c/frame 0xfe011dd5f600
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame 0xfe011dd5f630
unlock_mtx() at unlock_mtx+0x2a/frame 0xfe011dd5f640
_sleep() at _sleep+0x18e/frame 0xfe011dd5f6c0
cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfe011dd5f7f0
storvsc_attach() at storvsc_attach+0x6d4/frame 0xfe011dd5f890
device_attach() at device_attach+0x3a2/frame 0xfe011dd5f8f0
hv_vmbus_child_device_register() at
hv_vmbus_child_device_register+0xdb/frame 0xfe011dd5f990
vmbus_channel_process_offer() at
vmbus_channel_process_offer+0x133/frame 0xfe011dd5f9d0
work_item_callback() at work_item_callback+0x26/frame 0xfe011dd5f9f0
taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame 0xfe011dd5fa40
taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame 0xfe011dd5fa70
fork_exit() at fork_exit+0x9a/frame 0xfe011dd5fab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe011dd5fab0
--- trap 0, rip = 0, rsp = 0xfe011dd5fb70, 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-virtualizat...@freebsd.org 
[mailto:owner-freebsd-virtualizat...@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 1000 Hz quality 1000 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:0x804f444c
stack poin

Re: [Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project

2014-03-04 Thread Oleg Sidorkin
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:0x804f58cc
>> stack pointer   = 0x28:0xfe011dd5f5d0
>> frame pointer   = 0x28:0xfe011dd5f600
>> code segment= base 0x0, limit 0xf, 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 0xf8000331e000
>> turnstile_broadcast() at turnstile_broadcast+0x8c/frame 0xfe011dd5f600
>> __mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame 0xfe011dd5f630
>> unlock_mtx() at unlock_mtx+0x2a/frame 0xfe011dd5f640
>> _sleep() at _sleep+0x18e/frame 0xfe011dd5f6c0
>> cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfe011dd5f7f0
>> storvsc_attach() at storvsc_attach+0x6d4/frame 0xfe011dd5f890
>> device_attach() at device_attach+0x3a2/frame 0xfe011dd5f8f0
>> hv_vmbus_child_device_register() at
>> hv_vmbus_child_device_register+0xdb/frame 0xfe011dd5f990
>> vmbus_channel_process_offer() at
>> vmbus_channel_process_offer+0x133/frame 0xfe011dd5f9d0
>> work_item_callback() at work_item_callback+0x26/frame 0xfe011dd5f9f0
>> taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame
>> 0xfe011dd5fa40
>> taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame
>> 0xfe011dd5fa70
>> fork_exit() at fork_exit+0x9a/frame 0xfe011dd5fab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe011dd5fab0
>> --- trap 0, rip = 0, rsp = 0xfe011dd5fb70, 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-virtualizat...@freebsd.org
>>> [mailto:owner-freebsd-virtualizat...@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.
>>>
>>> 

Re: [Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project

2014-03-04 Thread Alexander Motin

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 = 30;
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:0x804f58cc
stack pointer   = 0x28:0xfe011dd5f5d0
frame pointer   = 0x28:0xfe011dd5f600
code segment= base 0x0, limit 0xf, 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 0xf8000331e000
turnstile_broadcast() at turnstile_broadcast+0x8c/frame 0xfe011dd5f600
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame 0xfe011dd5f630
unlock_mtx() at unlock_mtx+0x2a/frame 0xfe011dd5f640
_sleep() at _sleep+0x18e/frame 0xfe011dd5f6c0
cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfe011dd5f7f0
storvsc_attach() at storvsc_attach+0x6d4/frame 0xfe011dd5f890
device_attach() at device_attach+0x3a2/frame 0xfe011dd5f8f0
hv_vmbus_child_device_register() at
hv_vmbus_child_device_register+0xdb/frame 0xfe011dd5f990
vmbus_channel_process_offer() at
vmbus_channel_process_offer+0x133/frame 0xfe011dd5f9d0
work_item_callback() at work_item_callback+0x26/frame 0xfe011dd5f9f0
taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame
0xfe011dd5fa40
taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame
0xfe011dd5fa70
fork_exit() at fork_exit+0x9a/frame 0xfe011dd5fab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe011dd5fab0
--- trap 0, rip = 0, rsp = 0xfe011dd5fb70, 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-virtualizat...@freebsd.org
[mailto:owner-freebsd-virtualizat...@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 cam

Re: [Hyper-V][camlock] storvsc driver panics during boot with patches from camlock project

2014-03-04 Thread Oleg Sidorkin
gt;> storvsc_attach() at storvsc_attach+0x6d4/frame 0xfe011dd5f890
>>>> device_attach() at device_attach+0x3a2/frame 0xfe011dd5f8f0
>>>> hv_vmbus_child_device_register() at
>>>> hv_vmbus_child_device_register+0xdb/frame 0xfe011dd5f990
>>>> vmbus_channel_process_offer() at
>>>> vmbus_channel_process_offer+0x133/frame 0xfe011dd5f9d0
>>>> work_item_callback() at work_item_callback+0x26/frame 0xfe011dd5f9f0
>>>> taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame
>>>> 0xfe011dd5fa40
>>>> taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame
>>>> 0xfe011dd5fa70
>>>> fork_exit() at fork_exit+0x9a/frame 0xfe011dd5fab0
>>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe011dd5fab0
>>>> --- trap 0, rip = 0, rsp = 0xfe011dd5fb70, 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-virtualizat...@freebsd.org
>>>>> [mailto:owner-freebsd-virtualizat...@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 1000 Hz quality 1000 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:0x804f444c
>>>>> stack pointer   = 0x28:0xfe011df38610
>>>>> frame pointer   = 0x28:0xfe011df38640
>>>>> code segment= base 0x0, limit 0xf, 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 0xf80001f20490
>>>>> turnstile_broadcast() at turnstile_broadcast+0x8c/frame
>>>>> 0xfe011df38640
>>>>> __mtx_unlock_sleep() at __mtx_unlock_sleep+0x60/frame
>>>>> 0xfe011df38670
>>>>> unlock_mtx() at unlock_mtx+0x2a/frame 0xfe011df38680
>>>>> _sleep() at _sleep+0x18e/frame 0xfe011df38700
>>>>> cam_periph_runccb() at cam_periph_runccb+0x9e/frame 0xfe011df38800
>>>>> storvsc_attach() at storvsc_attach+0x6d4/frame 0xfe011df388a0
>>>>> device_attach() at device_attach+0x396/frame 0xfe011df388f0
>>>>> hv_vmbus_child_device_register() at
>>>>> hv_vmbus_child_device_register+0xdb/frame 0xfe011df38990
>>>>> vmbus_channel_process_offer() at
>>>>> vmbus_channel_process_offer+0x133/frame 0xfe011df389d0
>>>>> work_item_callback() at work_item_callback+0x26/frame
>>>>> 0xfe011df389f0
>>>>> taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame
>>>>> 0xfe011df38a40
>>>>> taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame
>>>>> 0xfe011df38a70
>>>>> fork_exit() at fork_exit+0x9a/frame 0xfe011df38ab0
>>>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe011df38ab0
>>>>> --- trap 0, rip = 0, rsp = 0xfe011df38b70, 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/04.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-unsubscr...@freebsd.org"
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Alexander Motin
>>
>>
>>
>>
>
>
> --
> Alexander Motin



-- 
Oleg Sidorkin
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"