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,
Hi all,
I am seeing kernel messages like
[ 1284.48] hda: status timeout: status=0xd0 { Busy }
[ 1284.48] ide: failed opcode was: unknown
[ 1284.48] hda: no DRQ after issuing MULTWRITE_EXT
[ 1284.49] ide0: unexpected interrupt, status=0x80, count=1
[ 1284.83] ide0: reset:
On 2/1/07, Steven Scholz [EMAIL PROTECTED] wrote:
Hi all,
I am seeing kernel messages like
[ 1284.48] hda: status timeout: status=0xd0 { Busy }
[ 1284.48] ide: failed opcode was: unknown
[ 1284.48] hda: no DRQ after issuing MULTWRITE_EXT
[ 1284.49] ide0: unexpected interrupt,
Eric,
I am seeing kernel messages like
[ 1284.48] hda: status timeout: status=0xd0 { Busy }
[ 1284.48] ide: failed opcode was: unknown
[ 1284.48] hda: no DRQ after issuing MULTWRITE_EXT
[ 1284.49] ide0: unexpected interrupt, status=0x80, count=1
[ 1284.83] ide0: reset:
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,
Tejun Heo wrote:
Well, it's not any worse than what we're currently doing. We don't set
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
Florian Effenberger wrote:
Hi there,
I am not sure if the sata_sil-Module is the culprit, but I think so. We
ran a 2.6.15.1 kernel for months without any problems. Now I tried to
switch to 2.6.19.2, and every night when our backup routine runs, the
machine locks up. No log entry, no
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
Hi Sergei,
Looks like a spurious interrupt... Is your IDE IRQ shared with other
devices?
..
But IIUC then first the HDD times out, the ide driver handles this and
then an irq occurs which is probably the irq the driver was waiting for.
The driver is *not* waiting for any IRQ after
Hello.
Steven Scholz wrote:
Looks like a spurious interrupt... Is your IDE IRQ shared with other
devices?
..
But IIUC then first the HDD times out, the ide driver handles this and
then an irq occurs which is probably the irq the driver was waiting for.
The driver is *not* waiting for
Fix libata to perform CDB len validation per device
rather than per host. This way, validation still works
when we have a mix of 12-byte and 16-byte devices on
a common host interface.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
diff -u --recursive --new-file
This patch adds support for issuing ATA_16 passthru commands
to ATAPI devices managed by libata. It requires the previous
CDB length fix patch.
A boot/module parameter, ata16_passthru=1 can be used to
globally disable this feature, if ever desired.
Signed-Off-By: Mark :ord [EMAIL PROTECTED]
On Thu, 01 Feb 2007 11:58:09 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Fix libata to perform CDB len validation per device
rather than per host. This way, validation still works
when we have a mix of 12-byte and 16-byte devices on
a common host interface.#
Users can pass 16byte commands in
version 2.6.18, 2.6.19.1 and they give the same result. If I connect
the drive to my SiI 3114 controller and boot 2.6.20-rc6 the drive
works perfectly.
Very interesting it is tied to the controller, but that fits what Tejun
was seeing.
I also tried booting kernel version 2.6.17. It gives an
Hi there,
sata_sil hasn't seen as much change as other drivers and is one of
the more stable ones. I'm definitely interested. Please post the
pics. If the video contains useful info, can you host it somewhere?
I've uploaded the image at
I'm not sure I understand your point. To support SGPIO initiators
incorporated
into SATA host controllers, it is pretty much inevitable that some SGPIO
support
will have to be added directly into individual drivers for thoese
controllers;
the SGPIO standard does not define a register level
On Thu, 1 Feb 2007 11:55:35 -0800
Andy Currid [EMAIL PROTECTED] wrote:
I'm not sure I understand your point. To support SGPIO initiators
incorporated
into SATA host controllers, it is pretty much inevitable that some SGPIO
support
will have to be added directly into individual drivers for
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
Follow the old SRST rule and delay 150ms between completion of
hardreset and status checking. Debouncing delay should usually cover
this but debounce duration could be shorter than 150ms under certain
circumstances.
Usefulness depends on host controller implementation but it can't hurt
and
* Hardreset must not exit without actually performing reset regardless
of link status. We're resetting the link after all.
* Minor message update.
* 150ms delay is meaningful iff link is online after reset is
complete.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
Both ATA and ATAPI devices used the default timeouts defined by SCSI
high level driver. For both disks and ODDs, it was 30secs, which was
way too long for disks. This patch makes most ATA commands time out
after 7secs - the de facto ATA command timeout, while leaving ATAPI
timeout at 30secs.
Make ata_down_xfermask_limit() accept @sel instead of @force_pio0.
@sel selects how the xfermask limit will be adjusted. The following
selectors are defined.
* ATA_DNXFER_PIO: only speed down PIO
* ATA_DNXFER_DMA: only speed down DMA, don't cause transfer mode change
*
* Move forcing device to PIO0 on device disable into
ata_dev_disable(). This makes both old and new EHs act the same
way.
* Speed down only PIO mode on probe failure. All commands used during
probing are PIO commands. There's no point in speeding down DMA.
* Retry at least once after
Subject: [PATCHSET] put some intelligence into speed down sequence
Hello,
The current EH speed down code is more of a feature demonstration and
goes through rdiculously many meaningless steps when condition is met.
This patchset tries to put some intelligence into speed down sequence.
The goal
ATA_DNXFER_ANY isn't used anymore. Kill it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |9 -
drivers/ata/libata.h |1 -
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index
SDB FIS containing spurious NCQ completions is a clear protocol
violation. Currently, only some Maxtors with early firmware revisions
are showing this problem. Those firmwares have other NCQ related
problems including buggy NCQ error reporting and occasional lock up
after NCQ errors.
Consider
Tejun Heo wrote:
Eek, sorry.
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Move forcing device to PIO0 on device disable into
ata_dev_disable(). This makes both old and new EHs act the same
way.
* Speed down only PIO mode on probe failure. All commands used during
probing are PIO commands. There's no point in speeding down DMA.
* Retry at least once after
Make ata_down_xfermask_limit() accept @sel instead of @force_pio0.
@sel selects how the xfermask limit will be adjusted. The following
selectors are defined.
* ATA_DNXFER_PIO: only speed down PIO
* ATA_DNXFER_DMA: only speed down DMA, don't cause transfer mode change
*
The current EH speed down code is more of a proof that the EH
framework is capable of adjusting transfer speed in response to error.
This patch puts some intelligence into EH speed down sequence. The
rules are..
* If there have been more than three timeout, HSM violation or
unclassified DEV
Sorry, bad script day.
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
libata previously depended upon waits in prereset to get resets after
hotplug right for both spin up and device ready wait. This was
necessary both for reliablity and speed as reset was likely to fail if
initiated too early and each try usually took more than 30secs to
fail. Previous patches
This patch updates ata_std_prereset() as follows.
* Don't fail on phy resume failure. Just whine and continue. Failure
from prereset makes libata abort whole reset sequence and give up
the port, so prereset() should be best effort. This is more
important with the coming EH updates as
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm
38 matches
Mail list logo
