physio split the request.. cannot proceed
Hi I am still working on porting LTFS to NetBSD. The thing now builds, and I am able to format a tape using the mkltfs utility. Next step is to mount the tape. It now fails within the NetBSD kernel. Here is ltfs output: LTFS20039D Backend read: 524288 bytes LTFS20010D SCSI request: [ 08 02 08 00 00 00 ] Requested length=524288 LTFS20089D Driver detail:errno = 0x5 LTFS20089D Driver detail: host_status = 0x0 LTFS20089D Driver detail:driver_status = 0x0 LTFS20089D Driver detail: status = 0x0 LTFS20011D SCSI outcome: Driver status=0xFF SCSI status=0xFF Actual length=0 LTFS20042E EIO in read On the console, the kernel says: st0(mpii0:0:2:0) physio split the request.. cannot proceed What does it meands, and how can I fix it? This is NetBSD 6.1.2. -- Emmanuel Dreyfus m...@netbsd.org
Re: physio split the request.. cannot proceed
On Dec 23, 2013, at 10:54 AM, Emmanuel Dreyfus wrote: > Hi > > I am still working on porting LTFS to NetBSD. The thing now builds, > and I am able to format a tape using the mkltfs utility. > > Next step is to mount the tape. It now fails within the NetBSD kernel. > > Here is ltfs output: > LTFS20039D Backend read: 524288 bytes > LTFS20010D SCSI request: [ 08 02 08 00 00 00 ] Requested length=524288 > LTFS20089D Driver detail:errno = 0x5 > LTFS20089D Driver detail: host_status = 0x0 > LTFS20089D Driver detail:driver_status = 0x0 > LTFS20089D Driver detail: status = 0x0 > LTFS20011D SCSI outcome: Driver status=0xFF SCSI status=0xFF Actual length=0 > LTFS20042E EIO in read > > On the console, the kernel says: > st0(mpii0:0:2:0) physio split the request.. cannot proceed > > What does it meands, and how can I fix it? This is NetBSD 6.1.2. In short: tape records bigger than MAXPHYS (most time 64k) don't work. It means physio() broke the request into MAXPHYS chunks and the tape driver needs the full request at once to read or write a record. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote: > In short: tape records bigger than MAXPHYS (most time 64k) don't work. Is it a NetBSD limitation that should be fixed in NetBSD, or an non standard assumption from LTFS that should be fixed in LTFS? -- Emmanuel Dreyfus m...@netbsd.org
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote: > In short: tape records bigger than MAXPHYS (most time 64k) don't work. I adjusted the function that detects tape block size so that it is capped to MAXPHYS. I also fixed the debug message so that I get the scsireq_t NetBSD field names correctly displayed and filled: LTFS20039D Backend read: 65536 bytes LTFS20010D SCSI request: [ 08 02 01 00 00 00 ] Requested length=65536 LTFS20089D Driver detail:errno = 0x0 LTFS20089D Driver detail: status = 0x2 LTFS20089D Driver detail: retsts = 0x4 LTFS20089D Driver detail:error = 0x0 LTFS20011D SCSI outcome: Driver status=0xFF SCSI status=0xFF Actual length=0 LTFS20042E EIO in read : I now get SCCMD_UNKNOWN / Check Condition. I would have expected it to issue a SENSE command afterward, but instaed it does this: LTFS20076I Triggering drive diagnostic dump LTFS20010D SCSI request: [ A4 1F 0C 00 00 00 00 00 00 00 00 00 ] Requested length=0 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=0 LTFS20010D SCSI request: [ A3 1F 08 00 00 00 01 00 00 00 00 00 ] Requested length=65536 LTFS20089D Driver detail:errno = 0x5 LTFS20089D Driver detail: status = 0x2 LTFS20089D Driver detail: retsts = 0x4 LTFS20089D Driver detail:error = 0x0 LTFS20011D SCSI outcome: Driver status=0xFF SCSI status=0xFF Actual length=0 LTFS20078W Unable to read drive dump LTFS20096I Diagnostic dump complete -- Emmanuel Dreyfus m...@netbsd.org
Re: physio split the request.. cannot proceed
On Dec 23, 2013, at 11:15 AM, Emmanuel Dreyfus wrote: > On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote: >> In short: tape records bigger than MAXPHYS (most time 64k) don't work. > > Is it a NetBSD limitation that should be fixed in NetBSD, or an non standard > assumption from LTFS that should be fixed in LTFS? It is a NetBSD limitation -- there is a branch `tls-maxphys' but it doesn't address st.c (yet). -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: physio split the request.. cannot proceed
On Dec 23, 2013, at 11:59 AM, Emmanuel Dreyfus wrote: > On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote: >> In short: tape records bigger than MAXPHYS (most time 64k) don't work. > > I adjusted the function that detects tape block size so that it is > capped to MAXPHYS. I also fixed the debug message so that I get the > scsireq_t NetBSD field names correctly displayed and filled: > > LTFS20039D Backend read: 65536 bytes > LTFS20010D SCSI request: [ 08 02 01 00 00 00 ] Requested length=65536 > LTFS20089D Driver detail:errno = 0x0 > LTFS20089D Driver detail: status = 0x2 > LTFS20089D Driver detail: retsts = 0x4 > LTFS20089D Driver detail:error = 0x0 > LTFS20011D SCSI outcome: Driver status=0xFF SCSI status=0xFF Actual length=0 > LTFS20042E EIO in read > : > > I now get SCCMD_UNKNOWN / Check Condition. I would have expected it to > issue a SENSE command afterward, but instaed it does this: > > LTFS20076I Triggering drive diagnostic dump > LTFS20010D SCSI request: [ A4 1F 0C 00 00 00 00 00 00 00 00 00 ] Requested > length=0 > LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=0 > LTFS20010D SCSI request: [ A3 1F 08 00 00 00 01 00 00 00 00 00 ] Requested > length=65536 > LTFS20089D Driver detail:errno = 0x5 > LTFS20089D Driver detail: status = 0x2 > LTFS20089D Driver detail: retsts = 0x4 > LTFS20089D Driver detail:error = 0x0 > LTFS20011D SCSI outcome: Driver status=0xFF SCSI status=0xFF Actual length=0 > LTFS20078W Unable to read drive dump > LTFS20096I Diagnostic dump complete According to T10.ORG scsi commands a3/a4 for sequential devices are optional: OP DTLPWROMAEBKVF Description A3 OOO O OOMOOOM MAINTENANCE IN A4 OOO O OOO MAINTENANCE OUT What are you trying to do here? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: physio split the request.. cannot proceed
J. Hannken-Illjes wrote: > According to T10.ORG scsi commands a3/a4 for sequential devices are optional: > > OP DTLPWROMAEBKVF Description > A3 OOO O OOMOOOM MAINTENANCE IN > A4 OOO O OOO MAINTENANCE OUT > > What are you trying to do here? I am trying to mount a LTFS formatted tape. But I assume you wonder what LTFS software is doing. The logs suggests it attempts to fetch an error log dump from the drive. It is not such a problem if it is not implemented, as it is just a consequence of the failed READ(6): > LTFS20010D SCSI request: [ 08 02 01 00 00 00 ] Requested length=65536 > LTFS20089D Driver detail:errno = 0x0 > LTFS20089D Driver detail: status = 0x2 > LTFS20089D Driver detail: retsts = 0x4 > LTFS20089D Driver detail:error = 0x0 I guess I will have to add the SENSE command to learn what happened. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: physio split the request.. cannot proceed
On Dec 23, 2013, at 1:54 PM, m...@netbsd.org (Emmanuel Dreyfus) wrote: > J. Hannken-Illjes wrote: > >> According to T10.ORG scsi commands a3/a4 for sequential devices are optional: >> >> OP DTLPWROMAEBKVF Description >> A3 OOO O OOMOOOM MAINTENANCE IN >> A4 OOO O OOO MAINTENANCE OUT >> >> What are you trying to do here? > > I am trying to mount a LTFS formatted tape. But I assume you wonder what > LTFS software is doing. > > The logs suggests it attempts to fetch an error log dump from the drive. > It is not such a problem if it is not implemented, as it is just a > consequence of the failed READ(6): > >> LTFS20010D SCSI request: [ 08 02 01 00 00 00 ] Requested length=65536 >> LTFS20089D Driver detail:errno = 0x0 >> LTFS20089D Driver detail: status = 0x2 This is XS_SHORTSENSE (it also matches retsts being 0x04). It is an atapi drive? You try to read a record being larger than the buffer (65536)? >> LTFS20089D Driver detail: retsts = 0x4 >> LTFS20089D Driver detail:error = 0x0 > > I guess I will have to add the SENSE command to learn what happened. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 02:54:42PM +0100, J. Hannken-Illjes wrote: > This is XS_SHORTSENSE (it also matches retsts being 0x04). > > It is an atapi drive? No, SAS through the mpii driver. > You try to read a record being larger than the buffer (65536)? And it will not be able to return me the truncated data? -- Emmanuel Dreyfus m...@netbsd.org
Re: physio split the request.. cannot proceed
On Dec 23, 2013, at 3:00 PM, Emmanuel Dreyfus wrote: > On Mon, Dec 23, 2013 at 02:54:42PM +0100, J. Hannken-Illjes wrote: >> This is XS_SHORTSENSE (it also matches retsts being 0x04). >> >> It is an atapi drive? > > No, SAS through the mpii driver. That doesn't make sense -- as far as I grep XS_SHORTSENSE is atapi-only. > >> You try to read a record being larger than the buffer (65536)? > > And it will not be able to return me the truncated data? My scsi tape knowledge is a bit rusty -- but as far as I remember you have to read one record in one request. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 10:59:09AM +, Emmanuel Dreyfus wrote: > On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote: > > In short: tape records bigger than MAXPHYS (most time 64k) don't work. > > I adjusted the function that detects tape block size so that it is > capped to MAXPHYS. I also fixed the debug message so that I get the The resulting performance will leave much to be desired... Thor
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 09:23:09AM -0500, Thor Lancelot Simon wrote: > > I adjusted the function that detects tape block size so that it is > > capped to MAXPHYS. I also fixed the debug message so that I get the > The resulting performance will leave much to be desired... I can imagine that. But it is better than a failure, and ir let me me make progress without wiating for your branch to be merged. -- Emmanuel Dreyfus m...@netbsd.org
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 02:54:42PM +0100, J. Hannken-Illjes wrote:
> > LTFS20010D SCSI request: [ 08 02 01 00 00 00 ] Requested length=65536
> > LTFS20089D Driver detail:errno = 0x0
> > LTFS20089D Driver detail: status = 0x2
> > LTFS20089D Driver detail: retsts = 0x4
> > LTFS20089D Driver detail:error = 0x0
>
> This is XS_SHORTSENSE (it also matches retsts being 0x04).
Is it? I found 08 was READ(6) here:
http://en.wikipedia.org/wiki/SCSI_commands
I added a REQUEST_SENSE command after the failure, and here I am:
LTFS20012D SCSI sense : 70 00 05 00 00 00 00 10 00 00 00 00 24 00 00 CC 00 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00
If I read it correctly, this is:
5-24-00 Illegal Request - invalid field in CDB (Command Descriptor Block)
I do not know how to decode the key specific data: CC 00 01
The READ(6) command is assembled this way (silion is passed from
a bool named unusal_size). The field usage does not fit what
Wikipedia says about that command.
static int _cdb_read(void *device, char *buf, size_t count, bool silion)
{
ltotape_scsi_io_type *sio = (ltotape_scsi_io_type*)device;
int status;
/*
* Set up the cdb:
*/
sio->cdb[0] = CMDread;
sio->cdb[1] = (silion) ? 0x02 : 0x00;
sio->cdb[2] = (unsigned char) (count >> 16 );
sio->cdb[3] = (unsigned char) (count >> 8 );
sio->cdb[4] = (unsigned char) (count & 0xFF);
sio->cdb[5] = 0;
sio->cdb_length = 6; /* six-byte cdb */
(...)
--
Emmanuel Dreyfus
m...@netbsd.org
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 02:41:29PM +, Emmanuel Dreyfus wrote: > On Mon, Dec 23, 2013 at 09:23:09AM -0500, Thor Lancelot Simon wrote: > > > I adjusted the function that detects tape block size so that it is > > > capped to MAXPHYS. I also fixed the debug message so that I get the > > The resulting performance will leave much to be desired... > > I can imagine that. But it is better than a failure, and ir let me > me make progress without wiating for your branch to be merged. To be clear, using small blocks on modern tapes will probably lead to a dramatic reduction in tape capacity, not just read and write speed. Tapes can get very, very expensive, so a warning seemed to be in order! For what it's worth, I've been *very* busy, but there's not actually much left to do on the maxphys branch -- one mechanical task (resync it with head) and a few head-scratchers: 1) What to do when a disk's maxphys becomes smaller? This can happen with virtual-disk devices like LVM or RAIDframe when a component is attached on a new bus. The simplest thing to do is to disallow such attaches. 2) Our read-ahead and write-behind logic needs to become smarter so it does not aggressively issue MAXPHYS sized I/Os unless a true sequential read or write pattern is detected! 3) A number of SCSI controller drivers (generally for RAID devices implementing SCSI target on the controller itself) like arcmsr are miscoded such that they cannot expose the optimal transfer size for a disk until well _after_ it's attached. These need to be reworked so that they do whatever look-aside they need to in order to discover the right transfer size (in arcmsr's case, this means matching the 'scsi disk' with a RAID volume in a separate datastructure) before telling NetBSD the target is there. 4) Most ports won't benefit until they get MACHINE_MAXPHYS increased and their bus drivers adjusted appropriately. I actually think it would be appropriate to merge the branch to -current with only #1 fixed, and at least a strategy in mind for dealing with #2. It's just that there's a fairly extensive literature on #2, and I haven't had time to read it! Thor
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 09:57:10AM -0500, Thor Lancelot Simon wrote: > To be clear, using small blocks on modern tapes will probably lead to > a dramatic reduction in tape capacity, not just read and write speed. > Tapes can get very, very expensive, so a warning seemed to be in order! Ad since the MAXPHYS limit also exists on plain tape access (without LTFS), this means no modern LTO drive can be used at all on NetBSD until you merge your branch? -- Emmanuel Dreyfus m...@netbsd.org
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 03:04:06PM +, Emmanuel Dreyfus wrote: > On Mon, Dec 23, 2013 at 09:57:10AM -0500, Thor Lancelot Simon wrote: > > To be clear, using small blocks on modern tapes will probably lead to > > a dramatic reduction in tape capacity, not just read and write speed. > > Tapes can get very, very expensive, so a warning seemed to be in order! > > Ad since the MAXPHYS limit also exists on plain tape access (without > LTFS), this means no modern LTO drive can be used at all on NetBSD until > you merge your branch? It certainly means there will be a considerable loss of efficiency. Thor
Re: physio split the request.. cannot proceed
m...@netbsd.org (Emmanuel Dreyfus) writes: >Ad since the MAXPHYS limit also exists on plain tape access (without >LTFS), this means no modern LTO drive can be used at all on NetBSD until >you merge your branch? The drives should work assuming that you restrict yourself to fixed block sizes <= MAXPHYS or that you use variable block mode. The "HP LTO Ultrium 5 technical manual" suggests that it supports either mode. But it also mentions that is best to use >= 128k in fixed block mode and >= 256k in variable block mode for performance reasons. Anything smaller will be slow and, as Thor said, will waste precious tape.
Re: physio split the request.. cannot proceed
On Mon, Dec 23, 2013 at 11:23:28AM +0100, J. Hannken-Illjes wrote: > On Dec 23, 2013, at 11:15 AM, Emmanuel Dreyfus wrote: > > > On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote: > >> In short: tape records bigger than MAXPHYS (most time 64k) don't work. > > > > Is it a NetBSD limitation that should be fixed in NetBSD, or an non standard > > assumption from LTFS that should be fixed in LTFS? > > It is a NetBSD limitation -- there is a branch `tls-maxphys' but it > doesn't address st.c (yet). Actually, it seems that it does. The tape read, write, and ioctl commands use the minphys routine from the adapter, so you should be able to test with tls-maxphys and see what happens (you may need to adjust your adapter driver if it's one I haven't got to yet -- and note some of the LSI cards are weird, seemingly supporting a strange maximum transfer size of 192K). Thor
Re: physio split the request.. cannot proceed
Thor Lancelot Simon wrote: > 4) Most ports won't benefit until they get MACHINE_MAXPHYS increased and >their bus drivers adjusted appropriately. I checked out the banch, and indeed it would be nice to avoir a kernel bebuild just to have MAXPHYS set to 256 kB. Especially if that becomes mandatory to use anything. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: physio split the request.. cannot proceed
Thor Lancelot Simon wrote: > For what it's worth, I've been *very* busy, but there's not actually much > left to do on the maxphys branch I gave it a try, and here is the result on i386: /netbsd: mpii0: error 27 loading dmamap /netbsd: st0(mpii0:0:3:0): passthrough: adapter inconsistency While the kernel says that, here is ltfs log: LTFS12015I Attempting to load the medium LTFS20010D SCSI request: [ 1B 00 00 00 01 00 ] Requested length=0 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=0 LTFS20010D SCSI request: [ 34 06 00 00 00 00 00 00 00 00 ] Requested length=32 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=32 LTFS20060D Backend ReadPosition: Partition=0, LogObject=0, FMcount=0 LTFS20061D Backend modesense: 0x1D LTFS20010D SCSI request: [ 5A 00 1D 00 00 00 00 00 40 00 ] Requested length=64 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=48 LTFS20010D SCSI request: [ 00 00 00 00 00 00 ] Requested length=0 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=0 LTFS12026D Locking medium in the drive LTFS20010D SCSI request: [ 1E 00 00 00 01 00 ] Requested length=0 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=0 LTFS20010D SCSI request: [ 34 06 00 00 00 00 00 00 00 00 ] Requested length=32 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=32 LTFS20060D Backend ReadPosition: Partition=0, LogObject=0, FMcount=0 LTFS20061D Backend modesense: 0x00 LTFS20010D SCSI request: [ 5A 00 00 00 00 00 00 00 10 00 ] Requested length=16 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=16 LTFS20010D SCSI request: [ 55 10 00 00 00 00 00 00 10 00 ] Requested length=16 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=16 LTFS20061D Backend modesense: 0x00 LTFS20010D SCSI request: [ 5A 00 00 00 00 00 00 00 08 00 ] Requested length=8 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=8 LTFS20010D SCSI request: [ 05 00 00 00 00 00 ] Requested length=6 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=6 LTFS11007D Tape is loaded LTFS20061D Backend logsense: 0x31 LTFS20010D SCSI request: [ 4D 00 71 00 00 00 00 04 00 00 ] Requested length=1024 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=68 LTFS20057D Backend capacity part0: (36750, 36750) LTFS20057D Backend capacity part1: (2425551, 2425551) LTFS11008D Reading partition labels LTFS20061D Backend modesense: 0x00 LTFS20010D SCSI request: [ 5A 00 00 00 00 00 00 00 08 00 ] Requested length=8 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=8 LTFS20010D SCSI request: [ 05 00 00 00 00 00 ] Requested length=6 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=6 LTFS20039D Backend read: 524288 bytes LTFS20010D SCSI request: [ 08 02 08 00 00 00 ] Requested length=524288 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=0 LTFS11175E Cannot read ANSI label: expected 80 bytes, but received 0 LTFS11170E Failed to read label (-1012) from partition 0 LTFS11009E Cannot mount volume: failed to read partition labels. LTFS14013E Cannot mount the volume I assume the kernel error happens on the read SCSI request [ 08 02 08 00 00 00 ], although this is difficult to be sure. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: physio split the request.. cannot proceed
On Wed, Dec 25, 2013 at 02:54:19AM +0100, Emmanuel Dreyfus wrote: > Thor Lancelot Simon wrote: > > > For what it's worth, I've been *very* busy, but there's not actually much > > left to do on the maxphys branch > > I gave it a try, and here is the result on i386: > /netbsd: mpii0: error 27 loading dmamap > /netbsd: st0(mpii0:0:3:0): passthrough: adapter inconsistency I didn't do any work on the mpii driver -- I don't really know much about it. I could probably put my hands on suitable hardware. It looks like the problem is that the driver has a bug -- it is only using enough bus_dma segments to support a transfer smaller than the requested 512K, but trying to set up the full transfer anyway. Looking at the driver I'm a little confused exactly where it's going wrong but I note a bunch of XXXes around its use of MAXPHYS. I also notice it has its own minphys() method which _should be_ constraining the size of this transfer (since it should be the minphys on the scsipi channel) but seemingly is not! That's also worrisome. Thor
Re: physio split the request.. cannot proceed
Thor Lancelot Simon wrote: > It looks like the problem is that the driver has a bug -- it is only > using enough bus_dma segments to support a transfer smaller than the > requested 512K, but trying to set up the full transfer anyway. The OpenBSD version seems to have fixed it: - iiq.system_request_frame_size = htole16(MPII_REQUEST_SIZE / 4); + iiq.system_request_frame_size = htole16(sc->sc_request_size / 4); and later: - if (len > MPII_REQUEST_SIZE - sizeof(struct mpii_msg_config_request) || - len < page_length * 4) + if (len > sc->sc_request_size - sizeof(*cq) || len < page_length * 4) return (1); > I also notice it has its own minphys() method which _should be_ > constraining the size of this transfer (since it should be the minphys > on the scsipi channel) but seemingly is not! That's also worrisome. The OpenBSD version just uses scsi_minphys. Updating from it will not be easy, the changeset between 1.51-1.73 is huge, and we have our own fixes. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: physio split the request.. cannot proceed
On Wed, Dec 25, 2013 at 08:07:16PM +0100, Emmanuel Dreyfus wrote: > > > I also notice it has its own minphys() method which _should be_ > > constraining the size of this transfer (since it should be the minphys > > on the scsipi channel) but seemingly is not! That's also worrisome. > > The OpenBSD version just uses scsi_minphys. Well, that's wrong. Impossible to get the actual max transfer size right that way. So in that respect we are better. But what bothers me is why with our version of the driver, a large transfer is ever making it down to the bus_dma code -- the driver's minphys method as it is currently in our driver should be chopping it up into 64K pieces. (I realize that's not what you want, but by reading the code it is what should be happening, so there is something going on that we do not understand).
Re: physio split the request.. cannot proceed
On Wed, Dec 25, 2013 at 02:54:19AM +0100, Emmanuel Dreyfus wrote: > I gave it a try, and here is the result on i386: > /netbsd: mpii0: error 27 loading dmamap I poked some debug inside bus_dmamap_load, and came to the conclusion that the error could be worked around by just increasing MPII_MAX_SGL (see patch below) The new value is a wild guess, as I do not really know what I am doing here (explanations welcome), but now it passes the first read command: LTFS20060D Backend ReadPosition: Partition=0, LogObject=2, FMcount=1 LTFS20039D Backend read: 524288 bytes LTFS20010D SCSI request: [ 08 02 08 00 00 00 ] Requested length=524288 LTFS20089D Driver detail: status = 0x0 LTFS20089D Driver detail:errno = 0x0 LTFS20089D Driver detail: retsts = 0x0 LTFS20089D Driver detail: status = 0x0 LTFS20089D Driver detail:error = 0x0 LTFS20089D Driver detail:senselen_used = 0x0 LTFS20011D SCSI outcome: Driver status=0x00 SCSI status=0x00 Actual length=494 The dirty patch: Index: sys/dev/pci/mpii.c === RCS file: /cvsroot/src/sys/dev/pci/mpii.c,v retrieving revision 1.1 diff -U1 -r1.1 mpii.c --- sys/dev/pci/mpii.c 19 Apr 2012 17:50:51 - 1.1 +++ sys/dev/pci/mpii.c 27 Dec 2013 09:46:58 - @@ -1755,3 +1755,3 @@ */ -#define MPII_MAX_SGL (32) +#define MPII_MAX_SGL (512) /* was 32 */ -- Emmanuel Dreyfus m...@netbsd.org
