kern/189355: zfs panic on 10-stable

Thu May 15 15:00:02 UTC 2014

The following reply was made to PR kern/189355; it has been noted by GNATS.

From: Radim Kolar <hsn at sendmail.cz>
To: Steven Hartland <killing at multiplay.co.uk>, "freebsd-fs at FreeBSD.org"
	<freebsd-fs at freebsd.org>, "bug-followup at freebsd.org"
	<bug-followup at freebsd.org>
Cc:  
Subject: RE: kern/189355: zfs panic on 10-stable
Date: Thu, 15 May 2014 14:50:55 +0000

 --_eb78ed80-5e1c-4bbf-9389-5250a3119c5e_
 Content-Type: text/plain; charset="iso-8859-2"
 Content-Transfer-Encoding: quoted-printable

 > This could be something that has already has a fixed in head but wasn't e=
 xpected
 > to get triggered without TRIM queueing which isn't in 10-stable yet. The =
 fix
 > is also likely to change based on feedback from the openzfs guys=2C hence=
  isn't
 > in 10-stable yet.

 only workaround to get 10-STABLE boot without panic is to boot 10.0 and the=
 n import/export pool.

 265046 is already merged in 10-stable.
 Now building stable with 265152 and 265321 merged.
  		 	   		  =

 --_eb78ed80-5e1c-4bbf-9389-5250a3119c5e_
 Content-Type: text/html; charset="iso-8859-2"
 Content-Transfer-Encoding: quoted-printable

 <html>
 <head>
 <style><!--
 .hmmessage P
 {
 margin:0px=3B
 padding:0px
 }
 body.hmmessage
 {
 font-size: 12pt=3B
 font-family:Calibri
 }
 --></style></head>
 <body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B This could be something t=
 hat has already has a fixed in head but wasn't expected<br><div>&gt=3B to g=
 et triggered without TRIM queueing which isn't in 10-stable yet. The fix<br=
 >&gt=3B is also likely to change based on feedback from the openzfs guys=2C=
  hence isn't<br>&gt=3B in 10-stable yet.<br><br>only workaround to get 10-S=
 TABLE boot without panic is to boot 10.0 and then import/export pool.<br><b=
 r>265046 is already merged in 10-stable.<br>Now building stable with 265152=
  and 265321 merged.<br></div> 		 	   		  </div></body>
 </html>=

 --_eb78ed80-5e1c-4bbf-9389-5250a3119c5e_--