Date: Wed, 19 Oct 2016 17:10:31 +0200 From: geoffroy desvernay <dgeo@centrale-marseille.fr> To: Pete Wright <pete@nomadlogic.org>, current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: LOR in mpr(4) Message-ID: <9fc856a5-c91d-cdfa-5000-5d8fc8ea20f1@centrale-marseille.fr> In-Reply-To: <564B917E.4000205@nomadlogic.org> References: <5644D014.4080601@nomadlogic.org> <564B917E.4000205@nomadlogic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UDifcBq6JcAxma9IkvI9nI6cJpcWrqj9N Content-Type: multipart/mixed; boundary="U4VW04IbcVi4a8sNMqML5ekh2TMcPn22x"; protected-headers="v1" From: geoffroy desvernay <dgeo@centrale-marseille.fr> To: Pete Wright <pete@nomadlogic.org>, current@freebsd.org, freebsd-stable@FreeBSD.org Message-ID: <9fc856a5-c91d-cdfa-5000-5d8fc8ea20f1@centrale-marseille.fr> Subject: Re: LOR in mpr(4) References: <5644D014.4080601@nomadlogic.org> <564B917E.4000205@nomadlogic.org> In-Reply-To: <564B917E.4000205@nomadlogic.org> --U4VW04IbcVi4a8sNMqML5ekh2TMcPn22x Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/17/2015 21:43, Pete Wright wrote: >=20 >=20 > On 11/12/15 09:44, Pete Wright wrote: >> Hi All, >> Just wanted a sanity check before filing a PR. I am running r290688 a= nd >> am seeing a LOR being triggered in the mpr(4) device: >> >> $ uname -ar >> FreeBSD srd0013 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r290688: Wed Nov = 11 >> 21:28:26 PST 2015 root@srd0013:/usr/obj/usr/src/sys/GENERIC amd64= >> >> <dmesg snip> >> lock order reversal: >> 1st 0xfffff8000d26bc60 CAM device lock (CAM device lock) @ >> /usr/src/sys/cam/cam_xpt.c:784 >> 2nd 0xfffffe00012811c0 MPR lock (MPR lock) @ >> /usr/src/sys/cam/cam_xpt.c:2620 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe04608ee890 >> witness_checkorder() at witness_checkorder+0xe79/frame 0xfffffe04608ee= 910 >> __mtx_lock_flags() at __mtx_lock_flags+0xa4/frame 0xfffffe04608ee960 >> xpt_action_default() at xpt_action_default+0xb6c/frame 0xfffffe04608ee= 9b0 >> scsi_scan_bus() at scsi_scan_bus+0x1d5/frame 0xfffffe04608eea20 >> xpt_scanner_thread() at xpt_scanner_thread+0x15c/frame 0xfffffe04608ee= a70 >> fork_exit() at fork_exit+0x84/frame 0xfffffe04608eeab0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe04608eeab0 >> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- >> <snip> >=20 > FWIW I filed the following PR as I can still reproduce this on boot: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204614 >=20 > cheers, > -pete >=20 Hi all, Sorry for cross-posting, let me know where this should go please, I didn't figured it out :( On 11-RELEASE-p1 here (but replying on current@ where I found something around mpr(4)) Not sure if it's related, but on a fresh new machine with Avago SAS3008 and a 24 disks enclosure (single attached). I see a bunch of: mpr0: Found device <401<SspTarg>,End Device> <12.0Gbps> handle<0x001b> enclosureHandle<0x0002> slot 8 (da0:mpr0:0:8:0): UNMAPPED (da0:mpr0:0:8:0): CAM status: SCSI Status Error (da0:mpr0:0:8:0): SCSI status: Check Condition (da0:mpr0:0:8:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da0:mpr0:0:8:0): Error 22, Unretryable error 10:0): UNMAPPED (da0:mpr0:0:8:0): READ(10). CDB: 28 00 e8 e0 88 71 00 00 04 00 (da0:mpr0:0:8:0): CAM status: SCSI Status Error (da0:mpr0:0:8:0): SCSI status: Check Condition (da0:mpr0:0:8:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da0:mpr0:0:8:0): Error 22, Unretryable error ses0: da0: Element descriptor: 'Drive Slot 0' ses0: da0: SAS Device Slot Element: 2 Phys at Slot 0 ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 520474729974b57f addr 5000c50097ce8215 ses0: phy 1: SAS device type 1 id 1 ses0: phy 1: protocols: Initiator( None ) Target( SSP ) ses0: phy 1: parent 520474729974b5ff addr 5000c50097ce8216 (more complete dmesg.boot here: http://dgeo.perso.ec-m.fr/dmesg.boot ) Later, no way to use these disks with zfs: # zpool create tank da0 cannot create 'tank': invalid argument for this pool operation I can dd if=3D/dev/zero of=3D/dev/da0 though not tested until disk is ful= l=85 Can this be related ? Must I open a pr ? How can I help debugging this ? I'm not kernel/driver hacker, but I'd like to help this be figured out :)= Yours, --=20 *geoffroy desvernay* C.R.I - Administration syst=E8mes et r=E9seaux Ecole Centrale de Marseille --U4VW04IbcVi4a8sNMqML5ekh2TMcPn22x-- --UDifcBq6JcAxma9IkvI9nI6cJpcWrqj9N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYB4zrAAoJED/P9AlFh6DwErcP/2ZZwg4jr+wsC8NJHAxHbQXk rmWc1VucMbYDBEZDH3tjjcIm3wlCYXbklMUzPamRGWqU1WOC3YQ8YHsra467psls SVeaC2VNOr8/6vWEvpzjv8nwxVXDj84tVOb0bcHt3exkHff6F0OwE9pEHoxNblfq EqJzxO6A8r2nAHGAvnhdHNKxGlmfWeG7Tb9dRi9vhOwXbE5c55rjlKpul0JF63+A 9hMHNd0TyTk3uNTr9IDhAlbADMdYcCpqVyHfBIK37EwevK7zzakIPV9baDu/gl54 iRQYSW1h+Nuf3SlhlyU4I0ls1kHiBLkXTW7nvTSzbxVG0YZH317E+RKMt6bAyoeM G79tkQd+sOiEkQsyj+TohqsPSQd8Ai4uVvBxFJ8zS95nHnVMSyGFd71pOs1nmh/z sTOst78pxn0wR5HheCof22C/ijI0ivymk9+jCIB5fYuY9meq/vTz7DPK4vVvI9Mk bN2lniqot4F36ZCyC/sO8akNCzE8trLE9EMc4+IgKZJXQWBSSA7/8D7DiKdPH5Ex jZgY0U2Rfod49sp5vTaWFSovWsppSOIx7DarDfBzNCHdxVXbTc4/idLDtnND7atZ jARSpcF99SIWiPvAUWSn0nRECf1Gbn/x+6tbMro5+DYu2hGMKDoUdxCssi43TfK5 lGKR/MDejJJvJU6I2+kA =L047 -----END PGP SIGNATURE----- --UDifcBq6JcAxma9IkvI9nI6cJpcWrqj9N--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9fc856a5-c91d-cdfa-5000-5d8fc8ea20f1>