Hi all,
This is a roll-up of all of my ATA related uncommitted patches against
libsas and aic94xx to date. Per James Bottomley's request, I'm pushing
these patches out for further review in aic94xx-sas. The big changes in
this patch set are a lot of bug and locking fixes, the conversion of the
Signed-off-by: Darrick J. Wong [EMAIL PROTECTED]
---
drivers/scsi/libsas/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/libsas/Kconfig b/drivers/scsi/libsas/Kconfig
index aafdc92..b64e391 100644
--- a/drivers/scsi/libsas/Kconfig
+++
ata_qc_complete and ata_sas_queuecmd require that the port lock be held
when they are called. sas_ata doesn't do this, leading to BUG messages
about qc tags newly allocated qc tags already being in use. This patch
fixes the locking, which should clean up the rest of those messages.
So far I've
The sas_ata_qc_issue function was incorrectly written to return error
codes such as -ENOMEM. Since libata OR's qc-err_mask with the
return value, It is necessary to make my code return one of the
AC_ERR_ codes instead. For now, use AC_ERR_SYSTEM because an error
here means that the OS couldn't
This patch adds a new field, lldd_task, to ata_queued_cmd so that libata
users such as libsas can associate some data with a qc. The particular
ambition with this patch is to associate a sas_task with a qc; that way,
if libata decides to timeout a command, we can come back (in
Since the aic94xx sequencer assigns its own NCQ tags to ATA commands, it
no longer makes any sense to copy the sactive field in the STP response
to ata_port-sactive, as that will confuse libata. Also, libata seems
to be capable of managing sactive on its own.
The attached patch gets rid of one
This patch requires libsas: Add a sysfs knob to enable/disable a phy
to be applied. It hooks the SControl write function to provide basic
SATA phy control for phy enable/disable and speed limits. Power
management is still broken, though it is unclear that libata actually
uses those SControl
A sas_task sent to an ATAPI devices returns SAM_GOOD if successful.
Therefore, we should treat this the same way we treat ATA commands
that succeed.
Signed-off-by: Darrick J. Wong [EMAIL PROTECTED]
---
drivers/scsi/libsas/sas_ata.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
When libsas encounters a STP device whose protocol isn't recognized (i.e.
not ATA or ATAPI), we should set the ata_device's class to ATA_DEV_UNKNOWN
instead of ATA_DEV_ATA.
Signed-off-by: Darrick J. Wong [EMAIL PROTECTED]
---
drivers/scsi/libsas/sas_ata.c |2 +-
1 files changed, 1
The SATL should connect the scsi_cmnd to the sas_task (despite the presence
of libata) so that requests to abort scsi_cmnds headed to the ATA device
can be processed by the EH and aborted correctly. The abort status should
still be propagated from sas - ata - scsi.
Signed-off-by: Darrick J.
ATA devices need special handling for sas_task_abort. If the ATA command
came from SCSI, then we merely need to tell SCSI to abort the scsi_cmnd.
However, internal commands require a bit more work--we need to fill the qc
with the appropriate error status and complete the command, and eventually
NOTE: I am not on the linux-scsi list, keep me in CC.
Andrew Morton wrote:
On Sun, 28 Jan 2007 14:46:20 -0500
Wakko Warner [EMAIL PROTECTED] wrote:
I have 2 machine that oops with these cards.
1) The bios has the option to enable/disable option roms on individual PCI
slots. I have
Hi,
Also seen on a NEC server, a 1068 chip with a jumper used to switch chip
PCI ID and its BIOS:
- PCI ID = 0054 = 'MPT Fusion' BIOS
- PCI ID = 0055 = 'MegaRAID' BIOS
I'm feeling that I submit this unusual chip ID to pciid DB some month ago...
More important: there's a driver for this chip
On Tue, 30 Jan 2007 07:18:20 -0500
Wakko Warner [EMAIL PROTECTED] wrote:
NOTE: I am not on the linux-scsi list, keep me in CC.
Andrew Morton wrote:
On Sun, 28 Jan 2007 14:46:20 -0500
Wakko Warner [EMAIL PROTECTED] wrote:
I have 2 machine that oops with these cards.
1) The
libsas: Don't BUG when connecting two expanders via wide port
When a device is connected to an expander, the discovery process goes through
sas_ex_discover_dev to figure out what's attached to the phy. If it is the
case that the phy being discovered happens to be the second phy of a wide link
to
One shortcoming of the driver relationship with the kernel is that there
is no standard means of having the insmod parameters associated with a
driver to also be parsed and set by the kernel parameter line. The
enclosed patch is a proposal for the aacraid driver to pick up the
kernel parameter
Darrick J. Wong wrote:
libsas: Don't BUG when connecting two expanders via wide port
When a device is connected to an expander, the discovery process goes through
sas_ex_discover_dev to figure out what's attached to the phy. If it is the
case that the phy being discovered happens to be the
Subject: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
driver for new sequence firmware.
Contribution:
Ed Chim [EMAIL PROTECTED]
Gilbert Wu [EMAIL PROTECTED]
Change Log:
1.Use dword instead of qword to display the value of Connection
State register for debug
If an EH command times out today, the LLDD's abort handler
will be called to abort the command. It is assumed that this
completes successfully, which can result in the command getting
completed later resulting in an oops. Improve the current
implementation by escalating all the way to host reset
NOTE: I am not on the linux-scsi list, keep me in CC.
Andrew Morton wrote:
On Tue, 30 Jan 2007 07:18:20 -0500
Wakko Warner [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Yes, getting the oops traces will help, thanks. And confirmation on a
more
recent kernel would be good.
I
What DMA for 16bit pcmcia card, anyway? We never do request_dma()
there and -dma_channel never changes since initialization to -1.
IOW, that call is dead code.
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
drivers/scsi/pcmcia/sym53c500_cs.c |2 --
1 files changed, 0 insertions(+), 2
On Mon, 29 Jan 2007 23:27:27 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Sun, 28 Jan 2007 11:25:42 +0100
Jiri Slaby [EMAIL PROTECTED] wrote:
Andrew Morton napsal(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc6-mm1/
I'm still seeing this during bootup:
Andrew Morton wrote:
A quick scan indicates that the following files might be buggy in this
regard:
drivers/mmc/wbsd.c
drivers/mmc/sdhci.c
This are probably even buggier than so. They really should be using
page_address(), it seems that kmap_atomic() gives the same result when
not using
Andrew Morton napsal(a):
On Mon, 29 Jan 2007 23:27:27 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Sun, 28 Jan 2007 11:25:42 +0100
Jiri Slaby [EMAIL PROTECTED] wrote:
Andrew Morton napsal(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc6-mm1/
I'm still seeing this
Hi Andrew,
Looks good for NTFS thanks! The only thing is that I think we
already have a variable unsigned long flags in the function
ntfs_end_buffer_async_read() so that could be used instead of
redefining it more locally in the if statements.
Could you send the patch to Linus?
Feel free to
Fixed for 80-columns, and copying linux-scsi this time.
In ancient kernels, the SCSI disk code used to continue after
encountering a MEDIUM_ERROR. It would complete the good
sectors before the error, fail the bad sector/block, and then
continue with the rest of the request.
Kernels since about
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the drives,
that's about 3 seconds per retry on average, or 12 seconds per failure.
Multiply that by the number of blocks past the error to
First off, please send SCSI patches to the SCSI list:
linux-scsi@vger.kernel.org
On Tue, 2007-01-30 at 19:47 -0500, Mark Lord wrote:
In ancient kernels, the SCSI disk code used to continue after
encountering a MEDIUM_ERROR. It would complete the good
sectors before the error, fail the bad
James Bottomley wrote:
First off, please send SCSI patches to the SCSI list:
linux-scsi@vger.kernel.org
Fixed already, thanks!
This patch fixes the behaviour to be similar to what we had originally.
When a bad sector is encounted, SCSI will now work around it again,
failing *only* the bad
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the
drives, that's about 3 seconds per retry on average, or 12 seconds
per failure. Multiply that by the number of blocks
On Tue, 2007-01-30 at 22:20 -0500, Ric Wheeler wrote:
Mark Lord wrote:
The number of retries is an entirely separate issue.
If we really care about it, then we should fix SD_MAX_RETRIES.
The current value of 5 is *way* too high. It should be zero or one.
Cheers
I think that drives
Ric Wheeler wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the
drives, that's about 3 seconds per retry on average, or 12 seconds
per failure. Multiply that by
32 matches
Mail list logo
