svn commit: r249939 - head/sys/cam/scsi
Steven Hartland
killing at multiplay.co.uk
Thu May 2 17:09:00 UTC 2013
----- Original Message -----
From: "Kenneth D. Merry" <ken at freebsd.org>
> On Tue, Apr 30, 2013 at 04:16:49 +0100, Steven Hartland wrote:
>> ----- Original Message -----
>> From: "Steven Hartland"
>> >>On Fri, Apr 26, 2013 at 16:17:05 +0000, Steven Hartland wrote:
>> >>>Author: smh
>> >>>Date: Fri Apr 26 16:17:04 2013
>> >>>New Revision: 249939
>> >>>URL: http://svnweb.freebsd.org/changeset/base/249939
>> >>>
>> >>>Log:
>> >>> Added available delete methods discovery during device probe,
>> >>> including the
>> >>> maximum sizes for said methods, which are used when processing
>> >>> BIO_DELETE
>> >>> requests. This includes updating UNMAP support discovery to be based on
>> >>> SBC-3 T10/1799-D Revision 31 specification.
>> >>> Added ATA TRIM support to cam scsi devices via ATA Pass-Through(16)
>> >>> sys/cam/scsi/scsi_da.c:
>> >>> - Added ATA Data Set Management TRIM support via ATA
>> >>> Pass-Through(16)
>> >>> as a delete_method
>> >>>
>> >>
>> >>This adds a lot of unnecessary verbosity for devices that don't support
>> >>ATA
>> >>passthrough. For example:
>> >>
>> >>(da7:iscsi4:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02
>> >>00 00 00 00 00 00 00 40 ec 00
>> >>(da7:iscsi4:0:0:0): CAM status: SCSI Status Error
>> >>(da7:iscsi4:0:0:0): SCSI status: Check Condition
>> >>(da7:iscsi4:0:0:0): Retrying command (per sense data)
>> >>(2:2:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02 00 00 00
>> >>00 00 00 00 40 ec 00
>> >>(2:2:0:0): Tag: 0x00f6, Type: 1
>> >>(2:2:0:0): CTL Status: SCSI Error
>> >>(2:2:0:0): SCSI Status: Check Condition
>> >>(2:2:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command
>> >>operation code)
>> >>(2:2:0:0): Command byte 0 is invalid
>> >>
>> >>(da8:iscsi4:0:0:1): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02
>> >>00 00 00 00 00 00 00 40 ec 00
>> >>(da8:iscsi4:0:0:1): CAM status: SCSI Status Error
>> >>(da8:iscsi4:0:0:1): SCSI status: Check Condition
>> >>(da8:iscsi4:0:0:1): Retrying command (per sense data)
>> >>(da8:iscsi4:0:0:1): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 02
>> >>00 00 00 00 00 00 00 40 ec 00
>> >>(da8:iscsi4:0:0:1): CAM status: SCSI Status Error
>> >>(da8:iscsi4:0:0:1): SCSI status: Check Condition
>> >>(da8:iscsi4:0:0:1): Error 5, Retries exhausted
>> >>
>> >>That is with CTL and and trasz's new iSCSI initiator, but you should see
>> >>it
>> >>with any CTL configuration. (And probably with any controller or device
>> >>that doesn't support ATA passthrough.)
>> >>
>> >>So, please:
>> >>- Check for the presence of VPD page 0x89 before sending an ATA
>> >> passthrough command. The spec (sat3r03 in this case) says that
>> >> it "shall" be implemented, so I think we can count on that.
>> >>- If the target returns an illegal request sense key, don't retry
>> >> again. The target will keep returning illegal request
>> >
>> >Thanks for the report Ken I'll check this on a card I know doesn't support
>> >pass-through.
>>
>> I checked with an areca controller, which I know doesn't support pass16, and
>> all is quiet during boot / probe.
>>
>> I can provoke output at the app layer with camcontrol identify da0, which is
>> to be expected, but nothing in /var/log/messages.
>>
>> daerror handler in scsi_da.c definitely has SF_QUIET_IR so Illegal Request
>> should never be output.
>
> You're correct, it should not print out any messages.
>
>> I can't provoke this using standard CAM devices even when they don't support
>> ATA Pass-Through (16) so I think this is actually an issue with CTL:
>> 1. Being verbose when it shouldn't (ctl_process_done - line 12571?)
>
> That part at least is by design -- it prints out rate-limited messages so
> you know when the initiator is sending commands CTL doesn't support. It
> comes in handy for figuring out initiator problems sometimes.
>
>> 2. Retrying Illegal Request commands when it shouldn't (I didn't experince
>> this on r250032)
>
> CTL doesn't do any retries, it leaves that up to the initiator.
>
> I finally tracked down the problem. The issue is that the iSCSI initiator
> wasn't setting the CAM_AUTOSNS_VALID flag in the CCB status field. As a
> result, only the CAM status and SCSI status fields were being printed.
> SF_QUIET_IR
>
>> The attached patch implements a check for ATA Information VPD before
>> using ATA Pass-Through (16). It's had limited testing but I have
>> confirmed it eliminates the use of pass16 under CTL and still enables
>> ATA TRIM under on mpt for SATA disks, so looks promising.
>>
>> If you could test and let me know if it works for you Ken that would
>> be appreciated.
>
> Yes, it does work and eliminates the error message, thanks! I think it is
> also a better way to go, just in case we run into a target that has an
> issue with the ATA passthrough CDB.
A slightly modified version of this is now in the current r250181
http://svnweb.freebsd.org/changeset/base/250181
>> The test case I used for CTL was:-
>> kldload ctl
>> ctladm create -b ramdisk -s 10485760
>> ctladm port -o on
>>
>> As a side note while test "kldload ctl" caused kernel panic the once.
>
> What was the panic message?
Unread portion of the kernel message buffer:
ctl: CAM Target Layer loaded
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0xffffffff8029c860
stack pointer = 0x28:0xffffff823b8dc840
frame pointer = 0x28:0xffffff823b8dc910
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 4 (xpt_thrd)
> This doesn't look like a CTL-specific problem (not on the surface), but
> rather a more general CAM problem:
>
>> #8 0xffffffff8073e1f2 in calltrap () at
>> /usr/home/smh/freebsd/base/head/sys/amd64/amd64/exception.S:228
>> #9 0xffffffff8029c860 in cam_periph_alloc (periph_ctor=0xffffffff802af410
>> <proberegister>, periph_oninvalidate=0xfffffe0019cfa200, periph_dtor=<value
>> optimized out>, periph_start=0xfffffe0015980a90, name=<value optimized
>> out>, type=2159638184,
>> path=0xfffffe0015ad79a0, ac_callback=<value optimized out>, code=<value
>> optimized out>) at /usr/home/smh/freebsd/base/head/sys/cam/cam_periph.c:227
>> #10 0xffffffff802aed6b in scsi_scan_lun (request_ccb=<value optimized out>)
>> at /usr/home/smh/freebsd/base/head/sys/cam/scsi/scsi_xpt.c:2266
>> #11 0xffffffff802b2859 in scsi_scan_bus (periph=0x0,
>> request_ccb=0xfffffe00234df000) at
>> /usr/home/smh/freebsd/base/head/sys/cam/scsi/scsi_xpt.c:1969
>> #12 0xffffffff802a66c5 in xpt_scanner_thread (dummy=<value optimized out>)
>> at /usr/home/smh/freebsd/base/head/sys/cam/cam_xpt.c:2411
>> #13 0xffffffff8055cde4 in fork_exit (callout=0xffffffff802a6650
>> <xpt_scanner_thread>, arg=0x0, frame=0xffffff823b8dcc00) at
>> /usr/home/smh/freebsd/base/head/sys/kern/kern_fork.c:991
>> #14 0xffffffff8073e72e in fork_trampoline () at
>> /usr/home/smh/freebsd/base/head/sys/amd64/amd64/exception.S:602
>> #15 0x0000000000000000 in ?? ()
>
> If this is on a stock FreeBSD/head, it looks like it failed on this line in
> cam_periph_alloc():
Apart from those patches yes stock FreeBSD/head.
> cur_periph = TAILQ_FIRST(&(*p_drv)->units);
>
> Perhaps there's an issue with the ctl peripheral driver getting added to
> the list of peripheral drivers (via periphdriver_register()). The topology
> lock isn't held in periphdriver_register(), so it's possible that the
> thread was in between the peripheral driver list traversal and the line
> above when the peripheral was added.
>
> It's more likely that the scan request was generated as a result of the CTL
> ports going online. And that means that the peripheral driver registration
> should have long since been done.
>
> If you can reproduce the problem, you can probably figure out where the
> issue is.
I've not been able to reproduce I'm afraid, seems you cant kldunload ctl
so needs a reboot between loads, tried 3 times but nothing.
I did however notice the following after turning ports off, which may
indicated a reference leak:-
May 2 17:06:25 head kernel: (da2:ctl2cam0:0:1:0): lost device - 0 outstanding, 2 refs
May 2 17:06:25 head kernel: (pass6:ctl2cam0:0:1:0): lost device
May 2 17:06:25 head kernel: (pass6:ctl2cam0:0:1:0): removing device entry
May 2 17:06:25 head kernel: (da2:ctl2cam0:0:1:0): removing device entry
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster at multiplay.co.uk.
More information about the svn-src-head
mailing list