From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 21 17:29:40 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E359016AA53; Tue, 21 Nov 2006 17:28:30 +0000 (UTC) (envelope-from Johannes.Kruger@nokia.com) Received: from mgw-ext12.nokia.com (mgw-ext12.nokia.com [131.228.20.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id D387543D82; Tue, 21 Nov 2006 17:27:59 +0000 (GMT) (envelope-from Johannes.Kruger@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kALHR313008894; Tue, 21 Nov 2006 19:28:18 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 19:26:38 +0200 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 11:26:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Nov 2006 11:26:25 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CAM_NEW_TRAN Thread-Index: Acb5/hoYxESEZOImQZqhF+h26wUNXgAEbNCgBN/5wBA= From: To: , X-OriginalArrivalTime: 21 Nov 2006 17:26:23.0716 (UTC) FILETIME=[2AC30A40:01C70D92] X-Nokia-AV: Clean Cc: Johannes.Kruger@nokia.com Subject: RE: CAM_NEW_TRAN X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2006 17:29:40 -0000 Hi Matthew. I tried forcing a core dump on the LSI-1064 and LSI-1064E controller. It does not seem to work via the mpt driver. The core dump is set to go to the usual place, the swap partition. # mount /dev/da0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/da0s1e on /tmp (ufs, local, soft-updates) /dev/da0s1f on /usr (ufs, local, soft-updates) /dev/da0s1d on /var (ufs, local, soft-updates) No RAID setup, just normal SATA disk on PHY0, works fine except for core dump. Did a bit of debug checking: I see that interrupts are turned of when doing a core dump. This looks ok since I see there is polling routines registered, and I can see them being called also. The message with what it fails is: ------------------ snip --------------------- Aborting dump due to I/O error. status =3D=3D 0x58, scsi status =3D=3D 0x0 i/o error Rebooting... ------------------ snip --------------------- I added some debugging code and it looks like it calls mpt_intr lots of times, and also mpt_action, which is correct. After looping (or entering via polling) the mpt_intr routine multiple times, the bit MPI_ADDRESS_REPLY_A_BIT is set. The execution path in "mpt_scsi_reply_handler" changes from a "context only reply" to a call to do "mpt_scsi_reply_frame_handler". In this "mpt_scsi_reply_frame_handler" call the ioc_status =3D 0x4b = which is: #define MPI_IOCSTATUS_SCSI_IOC_TERMINATED (0x004B) Any idea why this happens ? Thanks Johan .