Hi Martin,
Uhm, I have now tracked down the problem to over 512K 10byte write
transfers via sd.c.
When I keep at 512K, it works without problems.
But, thanks for the hints.
see inline.
I have also to check if it works with more than one lun.
bye,
ingo flaschberger
geschaeftsleitung
crossip communications gmbH
------------------------------------------------------------------_------------
sebastian kneipp gasse 1 _____ _____ ____ _____ _____ (_)____
a-1020 wien / ___// ___// __ \ / ___// ___// // __ \
fix: +43-1-726 15 22-217 / /__ / / / /_/ /(__ )(__ )/ // /_/ /
fax: +43-1-726 15 22-111 \___//_/ \____//____//____//_// .___/
mob: +43-699-105 86 719 _______ / /
www.xip.at communications gmbh /______//_/
-------------------------------------------------------------------------------
On Wed, 29 Mar 2006, Martin K. Petersen wrote:
"Ingo" == Ingo Flaschberger <if@xxxxxx> writes:
Ingo> I'm now diging since one week in the scsi code and get no idea
Ingo> what fails. I have, when I dd more the 556K to an ext3 at sda1,
Ingo> an "Illegal Request"; "Invalid field in cdb"
I'm sorry I'm completely and utterly swamped right now - dealing with
a slipped product release schedule.
If I read your code correctly last week, all you've done so far is
mess with LUN scanning. And my guess is things blow up when you've
queued enough I/O and things start actually hitting the metal.
yep.
The real problem with the RA4100 is that you can't just send commands
(cdbs) to it directly. You need to mangle them and this is what we
currently have no good infrastructure to support.
but it works now like this.
The RA4100 supports two addressing modes VSA and PDA and depending on
which mode is used you need to mangle the cdb in different ways.
Judging from the comments in cpqfc it appears the mode depends on the
firmware of the RA4100 in question.
Below is what I sent to hch about the RA4100 a while ago...
Btw. SCC is the SCSI Controller Commands specification -
i.e. TYPE_RAID. The spec is at
http://www.t10.org/ftp/t10/drafts/scc2/scc2r04.pdf
---8<---
The LUN mangling takes place in cpqfcTSworker.c. Here's what happens:
- IssueReportLunsCommand() gets fired off to send a REPORT_LUNS to
the array SCSI ID.
- ScsiReportLunsDone() is called upon completion. If REPORT_LUNS
failed we need to use peripheral device addressing (PDA) and set
VolumeSetAddressing (VSA) to 0.
If REPORT_LUNS succeeded VSA is set to 1 and so is LunMasking
(which is a kludge becase we didn't do sparse LUNs).
- fcFindLoggedInPort() is a swiss army knife function that gets
called all over the place in cpqfc. It deals with mappings between
WWNs/port ids and SCSI channel/target/lun tuples. In this case we
need to map a Linux LUN to a fibre channel ID (AL_PA or WWN)
Look for /* This is not passthrough */ in that function:
The Scsi_Cmnd in transit has a few things changed. Specifically,
the scratch pad is abused:
- Cmnd->SCp.phase is set to contain either PDA or VSA
- Cmnd->SCp.Message is set to contain the device type snooped from
INQUIRY (check out cpqfcTSCheckandSnoopFCP())
- Cmnd->SCp.have_data_in is set to the real LUN
So far so good. Now we've got some extra fluff in the Cmnd. On
to...
- build_FCP_payload() which picks these pieces out of the supplied
Cmnd and builds an FCP transfer with the SCC addressing gunk
prepended to the cdb.
Now, all the sparse LUN stiff is obsolete. And the only place the
stored inquiry data is being used is to special case timeouts when
dealing with tape devices.
So the only state we need to keep is the real LUN # and the addressing
mode (VSA or PDA are probably the only relevant ones). Given that we
can use the LUN value directly, all we need to do is to get the
addressing blah prepended.
---8<---
--
Martin K. Petersen http://mkp.net/
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
