Mark Lord wrote:
For example, I think all existing ATAPI drives only speak 12-byte packet
protocols, and so if we tell SCSI we're good for 16-byte, then won't the
SCSI layer suddenly start sending us READ_16 and the like?
Speaking strictly about the device, IDENTIFY PACKET DEVICE data page
Tejun Heo wrote:
SCSI always uses the smallest command it can use, so we're safe. Most
other commands are issued directly from the userland and it's their
responsibility not to feed disallowed commands to a device (or we need
more advanced filter). Anyways, this has never been guaranteed
Mark Lord wrote:
Tejun Heo wrote:
Anyways, this has never been guaranteed because
the limit is host wide.
But until very very recently, host wide meant just a single device
for libata. I was just assuming we did all of the fiddling to ensure
a minimal value there for some real reason.
But,
James Bottomley wrote:
On Wed, 2007-01-31 at 15:54 -0700, Eric Moore wrote:
static int
+mptscsih_cmp_scsilun(struct scsi_lun * lun1, struct scsi_lun * lun2)
+{
+ int i;
+
+ for (i = 0; i 8 ; i++)
+ if (lun1-scsi_lun[i] != lun2-scsi_lun[i])
+
Jeff Garzik wrote:
Mark Lord wrote:
For example, I think all existing ATAPI drives only speak 12-byte packet
protocols, and so if we tell SCSI we're good for 16-byte, then won't the
SCSI layer suddenly start sending us READ_16 and the like?
Speaking strictly about the device, IDENTIFY
Jeff Garzik wrote:
Tejun Heo wrote:
SCSI always uses the smallest command it can use, so we're safe. Most
other commands are issued directly from the userland and it's their
responsibility not to feed disallowed commands to a device (or we need
more advanced filter). Anyways, this has never
Tejun Heo wrote:
Jeff Garzik wrote:
Mark Lord wrote:
For example, I think all existing ATAPI drives only speak 12-byte packet
protocols, and so if we tell SCSI we're good for 16-byte, then won't the
SCSI layer suddenly start sending us READ_16 and the like?
Speaking strictly about the device,
sg3_utils is a package of command line utilities for sending
SCSI (and some ATA) commands to devices. This package targets
the linux kernel (lk) 2.6 and lk 2.4 series. In the lk 2.6
series these utilities (except sgp_dd) can be used with any
devices that support the SG_IO ioctl. Ported to FreeBSD,
On Thu, 2007-02-01 at 04:54 -0500, Jeff Garzik wrote:
Agreed... but that doesn't make it the /right/ thing to do ;-)
The logic behind the current code, which limits to the maximum size
allowed by an attached device on the port, is mainly to leverage the
SCSI layer as a filter for bad CDB
James Bottomley wrote:
But you're requesting code changes in the SCSI layer because of this
incorrect usage. max_cdb is supposed to be the *host* limit. The mid
layer finds out and respects device limits separately from this.
I never requested any such thing.
Jeff
-
To unsubscribe
On Wednesday, January 31, 2007 6:52 PM, James Bottomley wrote:
what's wrong with
memcmp(lun1-scsi_lun, lun2-scsi_lun, 8)
rather than introducing a wrapper? The compiler can even optimise
memcmp for a fixed size nicely.
James
Changed to using memcmp. This replaces the prevous
Use a newly added PCI API to issue a PCI Fundamental reset
(warm reset) to a new ipr PCI-E adapter. Typically, the
ipr adapter uses the start BIST bit in config space to reset
an adapter. Issuing start BIST on this particular adapter
results in the PCI-E logic on the card losing sync, which
Adds a new API which can be used to issue various types
of PCI-E reset, including PCI-E warm reset and PCI-E hot reset.
This is needed for an ipr PCI-E adapter which does not properly
implement BIST. Running BIST on this adapter results in PCI-E
errors. The only reliable reset mechanism that
Eric Moore wrote:
On Wednesday, January 31, 2007 6:52 PM, James Bottomley wrote:
what's wrong with
memcmp(lun1-scsi_lun, lun2-scsi_lun, 8)
rather than introducing a wrapper? The compiler can even optimise
memcmp for a fixed size nicely.
James
Changed to using memcmp. This replaces the
On Thu, Feb 01, 2007 at 11:30:21AM -0600, Brian King wrote:
Adds a new API which can be used to issue various types
of PCI-E reset, including PCI-E warm reset and PCI-E hot reset.
This is needed for an ipr PCI-E adapter which does not properly
implement BIST. Running BIST on this adapter
Matthew Wilcox wrote:
On Thu, Feb 01, 2007 at 11:30:21AM -0600, Brian King wrote:
Adds a new API which can be used to issue various types
of PCI-E reset, including PCI-E warm reset and PCI-E hot reset.
This is needed for an ipr PCI-E adapter which does not properly
implement BIST. Running
On Thu, 1 Feb 2007 15:34:29 -0800
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7919
Summary: Tape dies if wrong block size used
Kernel Version: 2.6.20-rc5
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
James Bottomley wrote:
On Thu, 2007-02-01 at 04:54 -0500, Jeff Garzik wrote:
Agreed... but that doesn't make it the /right/ thing to do ;-)
The logic behind the current code, which limits to the maximum size
allowed by an attached device on the port, is mainly to leverage the
SCSI layer as
Douglas Gilbert wrote:
It is the ATAPI _transport_ that has the 12 byte cdb
limit *** (at least according to MMC-5 rev Annex A;
is S-ATAPI any better?).
Then the spec is wrong.
1) The transport does not limit the CDB size.
2) The ATAPI device limits the CDB size, and it exports this limit
James Bottomley wrote:
On Tue, 2007-01-30 at 19:47 -0500, Mark Lord wrote:
Kernels since about 2.6.16 or so have been broken in this regard.
They complete the good sectors before the error,
and then fail the entire remaining portions of the request.
What was the commit that introduced the
James Bottomley wrote:
On Thu, 2007-02-01 at 15:02 -0500, Mark Lord wrote:
..
One thing that could be even better than the patch below,
would be to have it perhaps skip the entire bio that includes
the failed sector, rather than only the bad sector itself.
Er ... define skip over the bio. A
On Mon, 22 Jan 2007 10:35:10 -0800 Andrew Vasquez [EMAIL PROTECTED] wrote:
All,
We've been trying to track down a nagging regression seen during some
port-disable/enable testing. The problem occurs anywhere from
20 minutes to 120 minutes of testing under very minimal I/O load:
[
22 matches
Mail list logo
