Hi there, apologies for the delayed response.

Regarding the lock reversal, I can try to capture the screen showing the message.

The "Wil check go it goes...." it was my brain trying to multitask, obviously not in a successful way. What I meant to say was "I will check how it goes..... without the RAID".

Sure, I will test with the patch and let you know asap. hopefully by tomorrow night(BST).

Cheers

Santi


On 2020-06-09 19:20, Kashyap Desai wrote:
-----Original Message-----
From: Santiago Martinez [mailto:s...@codenetworks.net]
Sent: Tuesday, June 9, 2020 11:27 PM
To: Kashyap Desai <kashyap.de...@broadcom.com>; Don Lewis
<truck...@freebsd.org>; Andriy Gapon <a...@freebsd.org>
Cc: FreeBSD Current <curr...@freebsd.org>; Kashyap D. Desai
<kade...@freebsd.org>; Kenneth D. Merry <k...@freebsd.org>; Sumit Saxena
<sumit.sax...@broadcom.com>; Chandrakanth Patil
<chandrakanth.pa...@broadcom.com>
Subject: Re: MRSAS Panic during Install.

Hi! so it works but i got a lock order reversal warning, but it continue.
OK. So what is a warning ?

Wil check go it goes....
Could not get your point. Can you elaborate ?


Also can you try Raid - 1 VD with below patch ?

diff --git a/mrsas.c b/mrsas.c
index 3d33073..60f4b4d 100755
--- a/mrsas.c
+++ b/mrsas.c
@@ -1744,11 +1744,14 @@ mrsas_complete_cmd(struct mrsas_softc *sc, u_int32_t
MSIxIndex)
                                                         data_length =
r1_cmd->io_request->DataLength;
                                                         sense =
r1_cmd->sense;
                                                 }
+
+                                              mtx_lock(&sc->sim_lock);
                                                 r1_cmd->ccb_ptr = NULL;
                                                 if (r1_cmd->callout_owner) {

callout_stop(&r1_cmd->cm_callout);
                                                         r1_cmd->callout_owner
= false;
                                                 }
+                                              mtx_unlock(&sc->sim_lock);
                                                 mrsas_release_mpt_cmd(r1_cmd);

mrsas_map_mpt_cmd_status(cmd_mpt,
cmd_mpt->ccb_ptr, status,
                                                         extStatus,
data_length, sense);



Santi

On 2020-06-09 11:13, Santiago Martinez wrote:
Trying right now, will let you know.....


On 2020-06-09 11:07, Kashyap Desai wrote:
Hi Santi - Please try without Raid-1 VD. Most likely you will not
observe issue, but you can confirm from your end.

Kashyap

-----Original Message-----
From: Santiago Martinez [mailto:s...@codenetworks.net]
Sent: Tuesday, June 9, 2020 2:08 PM
To: Don Lewis <truck...@freebsd.org>; Andriy Gapon
<a...@freebsd.org>
Cc: FreeBSD Current <curr...@freebsd.org>; Kashyap D. Desai
<kade...@freebsd.org>; Kenneth D. Merry <k...@freebsd.org>
Subject: Re: MRSAS Panic during Install.

Hi Kashayp, that's correct, the servers has two raids. A raid 1 VD0
with 2xSSD on it and a RAID5 VD0.

Do you want me to break the raid and see i it does not trigger the
bug?

cheers

Santi


On 2020-06-09 07:51, Don Lewis wrote:
On  9 Jun, Andriy Gapon wrote:
On 09/06/2020 03:42, Santiago Martinez wrote:
Hi Everyone, today I tested with 12.1 and it works without any
issues (at least for now).

I will sync against current and see if it fails.

Santiago

On 2020-06-08 17:41, Santiago Martinez wrote:
Hi there, tried again and now i got it with UFS also.. that make
sense..
right...
On 2020-06-08 15:20, Santiago Martinez wrote:
Hi Everyone,

I'm installing FreeBSD current(361567) snapshot on a Lenovo
SR655
server.
After selecting ZFS, and the installer tries to make the
partitions, etc I get the following panic.

I tried selecting UFS and its works.

I uploaded a screenshot as I only have KVM access to it:

https://0bin.net/paste/4yn33GkSKiYto6m4#h78yCE6h80-
3DsApbXa1XLW9+b
hoKhOr3MVS+NRgA5A


The server is a ThinkSystem SR655, with the following
controller, RAID 930-8i 2GB Flash PCIe 12Gb Adapter
Lousy OCR of the picture:
...
nic: nutex mrsas_sin_lock not ouned at
/usr/src/sys/kern/kern_nutex.c:284
...
b_trace_self_urapper () at db_trace_self_urapper+8x2b/frane
BxfffffeB33c44a918
anic() at vpanic+Bx182/frane BxfffffeA33c44ad68
nic() at panic+Bx43/frame BxfffffeB33c44adcd
_mtx_assert() at __mtx_assert+@xb@/frane Bxfffffed33c44a9dd
callout_stop_safe() at _callout_stop_safe+Bx82/frane
Bxfffffe33c44aac
rsas_conplete_cnd() at mrsas_complete_cnd+8x1b8/frane
BxfffffeB33c4daaed
ithread_loop() at ithread_loop+@x279/frame BxfffffeB33c44ah78

This looks like a fallout from r342064.
cm_callout is initialized like this:
     callout_init_mtx(&cmd->cm_callout, &sc->sim_lock, 0); but in
mrsas_complete_cmd() it's stopped without holding the lock.

_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-
unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to