Date: Mon, 3 Jul 2017 09:42:15 +0200 From: Ben RUBSON <ben.rubson@gmail.com> To: freebsd-scsi@freebsd.org, Freebsd fs <freebsd-fs@freebsd.org> Subject: Re: I/O to pool appears to be hung, panic ! Message-ID: <A28D0E19-9220-42FF-AB5F-C2C53997E7F1@gmail.com> In-Reply-To: <acb4754f-fbf2-4c77-90fb-21317b7845b0@email.android.com> References: <acb4754f-fbf2-4c77-90fb-21317b7845b0@email.android.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 29 Jun 2017, at 20:40, Karli Sj=C3=B6berg <karli@inparadise.se> = wrote: >=20 >> Den 29 juni 2017 3:37 em skrev Ben RUBSON <ben.rubson@gmail.com>: >>=20 >> I also tried to look for some LSI SAS2008 error counters (on target = side), >> but did not found anything interesting. >> (sysctl -a | grep -i mps) >=20 > Here's a well kept secret I got from LSI once: >=20 > /boot/loader.conf: > dev.mps.0.debug_level=3D"0x1F" Thank you Karli for this tip ! I just noticed this is explained in MPS(4), DEBUGGING section. 0x1F is then : 0x0001 Enable informational prints (set by default). 0x0002 Enable prints for driver faults (set by default). 0x0004 Enable prints for controller events. 0x0008 Enable prints for controller logging. 0x0010 Enable prints for tracing recovery operations. Controller events are however extremely verbose. Perhaps 0x1B is then slightly better. Here is a useful link to "decode" logged messages : http://blog.disksurvey.org/blog/2014/08/10/decoding-lsi-loginfo-codes/ Ben=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A28D0E19-9220-42FF-AB5F-C2C53997E7F1>