From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 22 16:16:18 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D59C516A51E; Wed, 22 Nov 2006 16:16:18 +0000 (UTC) (envelope-from Johannes.Kruger@nokia.com) Received: from mgw-ext13.nokia.com (mgw-ext13.nokia.com [131.228.20.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC1A843D45; Wed, 22 Nov 2006 16:15:48 +0000 (GMT) (envelope-from Johannes.Kruger@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAMEktJZ027876; Wed, 22 Nov 2006 16:48:59 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 16:46:59 +0200 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 08:46:55 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 22 Nov 2006 08:46:54 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Core dumps not working via scsi_da and mpt driver Thread-Index: Acb5/hoYxESEZOImQZqhF+h26wUNXgAEbNCgBN/5wBAALQTVMA== From: To: , , , X-OriginalArrivalTime: 22 Nov 2006 14:46:55.0301 (UTC) FILETIME=[0DF48750:01C70E45] X-Nokia-AV: Clean X-Mailman-Approved-At: Wed, 22 Nov 2006 16:32:30 +0000 Cc: Subject: Core dumps not working via scsi_da and mpt driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2006 16:16:18 -0000 Forcing a graceful panic, the exact message I get is: --------------- snip -------------------- # sysctl -w debug.kdb.panic=3D1 debug.kdb.panic: 0panic: kdb_sysctl_panic cpuid =3D 0 KDB: enter: panic [thread pid 3438 tid 100053 ] Stopped at kdb_enter+0x2b: nop db> panic cpuid =3D 0 Uptime: 21h29m12s Physical memory: 501 MB Dumping 75 MB:Aborting dump due to I/O error. status =3D=3D 0x58, scsi status =3D=3D 0x0 ** DUMP FAILED (ERROR 5) ** Automatic reboot in 15 seconds - press a key on the console to abort --------------- snip -------------------- The string "Aborting dump due to I/O error" is reported by scsi_da.c Johan -----Original Message----- From: Kruger Johannes (Nokia-ES/Boston)=20 Sent: Tuesday, November 21, 2006 12:26 PM To: 'mjacob@freebsd.org'; 'freebsd-scsi@freebsd.org' Cc: Kruger Johannes (Nokia-ES/Boston) Subject: RE: CAM_NEW_TRAN 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 .