[Fwd: Crash dump on HP Proliant G6 broken as of V8.0]

Patrick Mahan pmahan at adaranet.com
Thu Sep 16 18:12:28 UTC 2010


Originally posted this to freebsd-hackers, now posting it to freebsd-scsi.

Any help is appreciated.

Thanks,

Patrick

-------- Original Message --------
Subject: Crash dump on HP Proliant G6 broken as of V8.0
Date: Wed, 15 Sep 2010 11:53:16 -0700
From: Paul Heyman <PHeyman at adaranet.com>
To: freebsd-hackers at freebsd.org <freebsd-hackers at freebsd.org>
CC: Patrick Mahan <PMahan at adaranet.com>
References: 
<32AB5C9615CC494997D9ABB1DB12783C024C8C5A95 at SJ-EXCH-1.adaranet.com>,<32AB5C9615CC494997D9ABB1DB12783C024C8DE83F at SJ-EXCH-1.adaranet.com>,<32AB5C9615CC494997D9ABB1DB12783C024C8C5A9C at SJ-EXCH-1.adaranet.com>

ALL,

The crash dump worked fine in V7.3.

I am debugging crash dump problem on a HP Proliant G6
which uses a SATA drive connected to a CISS Raid Controller.

I have tried this on a x86 box using a non-raid ATA/SATA disk controller
and it works well.

I noticed that in V8.0 there is a new SCSI operating method. In the v7.3 version there was only
CISS_TRANSPORT_METHOD_SIMPLE, but in v8.0 there has been  CISS_TRANSPORT_METHOD_PERF
method added. These methods have different function calls in
ciss_poll_request.

The dump comand starts with a call to dadump.
This function will setup a struct ccb_scsiio structure. This is done by calling scsi_read_write.
Then the meat of  dump happens when it calls xpt_polled_action, which manages and simualtes
interrupt functionality that is working fine. The disk operations work fine except during a
crash dump.

I have turned debug on for CISS and CAMDEBUG to debug this problem.

In xpt_polled_action (cam_xpt.c) we get past the first polling loop at line 3013, as
both devq->send_opening and dev->ccbq.dev_openings are > 0  ( 256 and 254 ).

But we do get stuck in the second one at line 3025. We eventually time out
setting start_ccb->ccb_h.status to CAM_CMD_TIMEOUT. The timeout is set with
DA_DEFAULT_TIMEOUT (scsi_da.c) which is set to 60, and is used in the call to scsi_read_write.

Here is the debug trace:

Dumping 1240 MB:
ciss_cam_action_io: XPT_SCSI_IO 0:0:0
ciss_get_request: called
ciss_start: post command 150 tag 600
ciss_map_request: called
ciss_request_map_helper: called
ciss_cam_poll: called
ciss_perf_done: completed command 150
ciss_perf_done: completed command 150

ciss_complete: called
ciss_unmap_request: called
ciss_cam_complete: called
_ciss_report_request: called
ciss_cam_complete: SCSI_STATUS_OK
ciss_release_request: called
ciss_complete: called
ciss_unmap_request: called
ciss0: WARNING: completing non-busy request
ciss_cam_complete: called
_ciss_report_request: called
ciss_cam_complete: SCSI_STATUS_OK
  .
  .
  .
  .
after about 60 seconds
ciss0: WARNING: completing non-busy request
ciss0: WARNING: completed command with no submitter
ciss_unmap_request: called
.
.
.
This goes on forever

Thanks
Paul


Paul Heyman
pheyman at adaranetworks.com


More information about the freebsd-scsi mailing list