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
Thor Lancelot Simon t...@panix.com 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:
-
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
Thor Lancelot Simon t...@panix.com 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
Thor Lancelot Simon t...@panix.com 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
On Wed, Dec 25, 2013 at 02:54:19AM +0100, Emmanuel Dreyfus wrote:
Thor Lancelot Simon t...@panix.com 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
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
: 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
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
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
On Dec 23, 2013, at 11:15 AM, Emmanuel Dreyfus m...@netbsd.org 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
On Dec 23, 2013, at 11:59 AM, Emmanuel Dreyfus m...@netbsd.org 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
J. Hannken-Illjes hann...@eis.cs.tu-bs.de 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
On Dec 23, 2013, at 1:54 PM, m...@netbsd.org (Emmanuel Dreyfus) wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de 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
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
On Dec 23, 2013, at 3:00 PM, Emmanuel Dreyfus m...@netbsd.org 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
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.
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
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
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
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
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 =
On Mon, Dec 23, 2013 at 11:23:28AM +0100, J. Hannken-Illjes wrote:
On Dec 23, 2013, at 11:15 AM, Emmanuel Dreyfus m...@netbsd.org 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
23 matches
Mail list logo
