Hi Tejun,
Tejun Heo wrote:
Were you able to reproduce it? If it actually is the same problem
(ATAPI DMA timing out on data transfers of certain size), it should be
reproducible when you repeat the same thing.
I tried several times this morning, but I couldn't reproduce it.
Maybe its really
On Mon, 29 Oct 2007 15:07:06 -0400, Jeff Garzik wrote:
Mikael Pettersson wrote:
@@ -155,7 +155,7 @@ static struct scsi_host_template pdc_ata
.queuecommand = ata_scsi_queuecmd,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
-
Mikael Pettersson wrote:
Unfortunately the name pdc_qc_prep() is already taken
[it switches on qc-tf.protocol], so that leaves either pdc_fill_sg()
[slightly imprecise as you noted], or uglies like __pdc_qc_prep(),
pdc_qc_prep2(), or pdc_qc_prep_and_fill_sg() as names for the new
procedure. I
On Mon, 29 Oct 2007 22:17:40 -0600
Robert Hancock [EMAIL PROTECTED] wrote:
In the sata_nv driver, when running in ADMA mode, we can do 64-bit DMA.
However, when an ATAPI device like a DVD drive is connected, we can't
use ADMA mode, and so we have to abide by the restrictions of a normal
jameshsu wrote:
Should be in TEXT/PLAIN mode. --- resend
Hello,
This driver has nothing changed since last time submit.
However recently we download 2.6.23.1 kernel and found Acard ATP8620 SATA
driver is still not there.
Resend this message to submit the same driver
Matheus Izvekov wrote:
Seagate drive ST3160023AS is correctly detected as supporting NCQ, but
when its used with moderate loads, libata keeps throwing error
messages until it finally decides to disable NCQ on it.
[]
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-6:
Tejun Heo wrote:
diego torres wrote:
Hi there,
This seagate drive ST3500630AS is being recognized as NCQ capable by
hdparm, and has the default queue_depth of 31, so i think it should
work ok. But there are some problems when using smartmontools (for
example in short test mode) as seen in
On Thursday 25 October 2007 22:41, Bartlomiej Zolnierkiewicz wrote:
-static const struct ide_port_info generic_chipsets[] __devinitdata = {
+static struct ide_port_info generic_chipsets[] __devinitdata = {
/* 0 */ DECLARE_GENERIC_PCI_DEV(Unknown, 0),
{ /* 1 */
I
On Tue, Oct 30, 2007 at 11:34:29AM +, Denys Vlasenko wrote:
On Thursday 25 October 2007 22:41, Bartlomiej Zolnierkiewicz wrote:
-static const struct ide_port_info generic_chipsets[] __devinitdata = {
+static struct ide_port_info generic_chipsets[] __devinitdata = {
/* 0 */
On Mon, 2007-10-29 at 11:20 +, Alan Cox wrote:
I really doubt if libata alone would do much for me, as the disk and
bios doesn't really want to know about ata at all. We're 1998 here,
remember. ATA has to be disabled for this to read the disk at all.
1998 is well into the world of
On 10/30/07, Michael Tokarev [EMAIL PROTECTED] wrote:
By the way, did you forget to remove a jumper on the drive
(the only jumper installed by default) that limits drive
usage to SATAI?
...
..etc. Try again without the jumper? Note that NCQ is NOT supported
in SATAI mode, or there were
Second-generation Promise SATA controllers have an ASIC bug
which can trigger if the last PRD entry is larger than 164 bytes,
resulting in intermittent errors and possible data corruption.
Work around this by replacing calls to ata_qc_prep() with a
private version that fills the PRD, checks the
Alan Cox wrote:
Some it821x RAID firmwares return 0 for the err return off both devices.
A similar issue occurs with the slave returning 0 not 1 if you plug a
gigabyte sata ramdisk into a controller that fakes two SATA ports as
master/slave on an SFF channel.
The patch does the following
-
Finally as with CPRM print a warning so that the user knows they may not
be able to full access and use the device.
Alan
Signed-off-by: Alan Cox [EMAIL PROTECTED]
seems fairly reasonable... 2.6.24-rc?
I think so yes.
Alan
-
To unsubscribe from this list: send the line
The other IT821x change is a bit ugly, we slightly abuse the cable type
hook to fiddle with the identify data for the devices. We could add a new
hook for this but as we have only one offender and no more seeming likely
it seems better to keep libata-core clean.
Please let this sit in
Tejun Heo wrote:
ATA_QCFLAG_IO is used to mark commands which are used to perform
regluar IO transfers via block layer. These commands are assumed to
be valid and taken more seriously during error handling. Cache flush
is used by regular IO path and necessary for data integrity. Mark it
with
Alan Cox wrote:
The other IT821x change is a bit ugly, we slightly abuse the cable type
hook to fiddle with the identify data for the devices. We could add a new
hook for this but as we have only one offender and no more seeming likely
it seems better to keep libata-core clean.
Please let this
Jeff Garzik wrote:
Tejun Heo wrote:
ATA_QCFLAG_IO is used to mark commands which are used to perform
regluar IO transfers via block layer. These commands are assumed to
be valid and taken more seriously during error handling. Cache flush
is used by regular IO path and necessary for data
Alan Cox wrote:
Historically word 48 in the identify data was used to mean 32bit I/O was
supported for VLB IDE etc. ATA8 reassigns this word to the Trusted
Computing Group, where it is used for TCG features. This means that an
ATA8 TCG drive is going to trigger 32bit I/O on some systems which
Minor sata_promise cleanups:
- use C99 array initialisers in pdc_port_info[]
- add myself in the file head's Maintained by note,
since users don't always read the MAINTAINERS file
- SG/PRD bug workaround warrants driver version bump
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--
Mikael Pettersson wrote:
Second-generation Promise SATA controllers have an ASIC bug
which can trigger if the last PRD entry is larger than 164 bytes,
resulting in intermittent errors and possible data corruption.
Work around this by replacing calls to ata_qc_prep() with a
private version that
It sounds like such a hook would be more appropriate here... can you
think of any other situation or driver that could make use of a
pre-dev-config hook?
No - which is why I didn't add one.
Alan
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message
Alan Cox wrote:
Some it821x RAID firmwares return 0 for the err return off both devices.
A similar issue occurs with the slave returning 0 not 1 if you plug a
gigabyte sata ramdisk into a controller that fakes two SATA ports as
master/slave on an SFF channel.
The patch does the following
-
Alan Cox wrote:
Historically word 48 in the identify data was used to mean 32bit I/O was
supported for VLB IDE etc. ATA8 reassigns this word to the Trusted
Computing Group, where it is used for TCG features. This means that an
ATA8 TCG drive is going to trigger 32bit I/O on some systems which
Brian King wrote:
The following three patches convert ipr to use the new libata EH APIs.
In the process of doing this, I first looked into implementing this
in a similar manner to how libata SAS is done today, which is hooking
into target_alloc/target_destroy to allocate/delete sata ports. While
On Tue, 30 Oct 2007 15:14:39 +
Daniel Drake [EMAIL PROTECTED] wrote:
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD
Commands sent to ATAPI tape drives via the SCSI generic (sg) driver are
limited in the amount of data that they can transfer by the max_sectors
value. The max_sectors value is currently calculated according to the
command set for disk drives, which doesn't apply to tape drives. The
default
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD writing utilities, I sometimes see this message in
the kernel logs:
Daniel Drake wrote:
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD writing utilities, I sometimes see this message in
the
Any ideas?
hrm
we may need to make that controller-specific, given that the code prior
to 2db78dd302d26d242d3e8e5c4c5024b6c3ea93c2 was working for most...
Removing it breaks some devices on any controller.
I don't think this one is a simple compatibility issue - its a behaviour
we have
Alan Cox wrote:
Not immediately - but if you've got wrong transfer lengths its a
candidate for this.
Ok lets start with the basics
If you mount a CD and use it does it work
Yep.
If you use cdrecord does it work ?
Yep (tested with wodim from debburn, effectively the same thing)
What
Daniel Drake wrote:
I have narrowed down the exact command submission which causes those
nasty messages in dmesg. The function which submits this is named
brasero_medium_get_page_2A_write_speed_desc.
Just as an extra data point...
I've compiled the test program an ran it on my ICH7/Pentium D
Of particular note is the sata_promise fix, which works around a
nasty hw errata. I need to push that to stable@
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
On Tue, 30 Oct 2007, Jeff Garzik wrote:
Mikael Pettersson (2):
sata_promise: ASIC PRD table bug workaround, take 2
sata_promise: cleanups
You and Mikael need to sort out the way you send/accept patches.
Both of these commits had stuff like this:
Signed-off-by: Mikael
The nutty app I was using for burning is Brasero, a GNOME app which does
some SG_IO directly with the drive. (I guess it has some bad error
handling and doesn't realise when some I/O path has failed)
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old
Linus Torvalds wrote:
On Tue, 30 Oct 2007, Jeff Garzik wrote:
Mikael Pettersson (2):
sata_promise: ASIC PRD table bug workaround, take 2
sata_promise: cleanups
You and Mikael need to sort out the way you send/accept patches.
Both of these commits had stuff like this:
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
Umm wtf is this data left over for ?, with the new code the drive is
likely to change state as it knows the transfer size and that will
On Tue, 30 Oct 2007, Jeff Garzik wrote:
Can we change git-am to accept two dashes as well as three? :)
It seems pretty common, not just with Mikael but several others who send
patches to me.
Well, git-am actually used to be a lot less strict about the dashes, and
we've made it *more*
Eric D. Mudama wrote:
On 10/30/07, Michael Tokarev [EMAIL PROTECTED] wrote:
By the way, did you forget to remove a jumper on the drive
(the only jumper installed by default) that limits drive
usage to SATAI?
...
..etc. Try again without the jumper? Note that NCQ is NOT supported
in SATAI
On Oct 30 2007 12:31, Linus Torvalds wrote:
On Tue, 30 Oct 2007, Jeff Garzik wrote:
Can we change git-am to accept two dashes as well as three? :)
It seems pretty common, not just with Mikael but several others who send
patches to me.
Well, git-am actually used to be a lot less strict
On Tuesday 30 October 2007, Ralf Baechle wrote:
On Tue, Oct 30, 2007 at 11:34:29AM +, Denys Vlasenko wrote:
On Thursday 25 October 2007 22:41, Bartlomiej Zolnierkiewicz wrote:
-static const struct ide_port_info generic_chipsets[] __devinitdata = {
+static struct ide_port_info
--- Declan Moriarty [EMAIL PROTECTED] wrote:
On Mon, 2007-10-29 at 11:20 +, Alan Cox wrote:
1998 is well into the world of ATA (IDE is just a confusing
othername)
Yeah I read it as 'faster ide' but the board/disk won't do it. The
disk
seems up to it, but something else is dodgy.
On 10/29/2007 03:41 AM, Tejun Heo wrote:
retry:
+ ata_link_for_each_dev(dev, ap-link) {
How do I backport these loops to 2.6.23?
I see something like this in the old code:
for (i=0; i ATA_MAX_DEVICES; i++) {
dev = ap-device[i];
if
Dear Sir,
I know, I am not the only one to find out that we can't upgrade to a
newer kernel when using SUSE 10.3. It seems that in 2.6.23 the sil
modules have been updated (newer versions) and thus render the current
system mostly unuseable. I noticed that in the sata_sil24.c source there
where a
Hi,
We hit an NMI watchdog on cpu lockup (trace below)
and I suspect it might be related to following string
termination bug. However I wonder why this bug fix is
not incorporated in latest mainline kernel (2.6.23.1
as I checked). The bug fix seems straightforward to
me. Did I miss anything ?
Is this a problem SUSE introduced, you forgot to take legacy into
account or is it a feature.
Is this problem adjusted in 2.6.24-rc1?
You don't provide enough information to guess.
If you are using the OpenSuSE kernel then please report this to SuSE
first (and include an lspci -vvxxx from a
I've had this problem since edgy, the whole system seems to be really
slow and i think it's the hard drives causing it, everything slows down
even more when doing certain tasks (such as checking a torrent file or
amarok updating my music collection).
In system log whenever i boot up i get the
Jan Engelhardt [EMAIL PROTECTED] writes:
On Oct 30 2007 12:31, Linus Torvalds wrote:
On Tue, 30 Oct 2007, Jeff Garzik wrote:
Can we change git-am to accept two dashes as well as three? :)
Well, git-am actually used to be a lot less strict about the dashes, and
we've made it *more* strict
On 10/30/07, Frans de Boer [EMAIL PROTECTED] wrote:
Dear Sir,
I know, I am not the only one to find out that we can't upgrade to a
newer kernel when using SUSE 10.3. It seems that in 2.6.23 the sil
modules have been updated (newer versions) and thus render the current
system mostly
Hi Jens
I just noticed, that my problem wasn't fixed by the new psu but by the
blacklist entry in libata in my currently installed kernel 2.6.23.
I guess besides me a few other people reported the freeze with the Samsung
HD401LJ and therefore they added my drive to the blacklist,
of course now
special_t is used only internally by the IDE subsystem (it isn't
related to hardware registers and isn't exported to the user-space).
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
include/linux/ide.h | 11 ---
1 file changed, 11 deletions(-)
Index:
Remove ata_status_t (unused) and atapi_status_t.
While at it:
* replace 'HWIF(drive)' by 'drive-hwif' (or just 'hwif' where possible)
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 14 +++---
drivers/ide/ide-lib.c| 21
Remove atapi_error_t.
While at it:
* replace 'HWIF(drive)' by 'drive-hwif'
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c |3 +--
drivers/ide/ide-lib.c| 21 ++---
drivers/ide/ide-tape.c |3 +--
include/linux/ide.h |
Remove atapi_feature_t.
While at it:
* replace 'HWIF(drive)' by 'hwif'
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 10 +-
drivers/scsi/ide-scsi.c | 11 ---
include/linux/ide.h | 27 ---
3 files
Remove ata_nsector_t, ata_data_t (unused) and atapi_bcount_t.
While at it:
* replace 'HWIF(drive)' by 'hwif'
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-disk.c | 12 +---
drivers/ide/ide-floppy.c | 37 ++---
ata_scsi_lpm_get() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
380046f657271be470566bb5c762c1599569bac6
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 93bd36c..c4f0c6c 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@
Remove atapi_ireason_t.
While at it:
* replace 'HWIF(drive)' by 'drive-hwif' (or just 'hwif' where possible)
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 25 -
drivers/ide/ide-tape.c | 27 +--
Add ide_pktcmd_tf_load() helper and convert ATAPI device drivers to use it.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-cd.c | 10 ++
drivers/ide/ide-floppy.c |9 ++---
Load IDE_CONTROL_REG before other registers in cdrom_start_packet_command().
It shouldn't affect anything (just a usual paranoia to separate changes
which change the way in which hardware is accessed from code cleanups).
While at it move misplaced FIXME comment in the right place.
Load IDE_BCOUNTL_REG before IDE_BCOUNTH_REG when issuing packet command.
It shouldn't affect anything (just a usual paranoia to separate changes
which change the way in which hardware is accessed from code cleanups).
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-iops.c |6 --
drivers/ide/ide-probe.c |5 -
include/linux/ide.h |1 -
3 files changed, 4 insertions(+), 8 deletions(-)
Index: b/drivers/ide/ide-iops.c
* Add 'data_buf' and 'nsect' variables in ide_taskfile_ioctl()
to cache data buffer pointer and number of sectors to transfer
(this allows us to have only one ide_diag_taskfile() call).
* Add IDE_TFLAG_WRITE taskfile flag and use it to check whether
the REQ_RW request flag should be set.
* Add IDE_TFLAG_IN_DATA taskfile flag to indicate the need of reading
IDE_DATA_REG in ide_end_drive_cmd().
Set the new flag in ide_taskfile_ioctl() if -in_flags.b.data is set.
* Add IDE_TFLAG_FLAGGED_SET_IN_FLAGS taskfile flag to indicate the
need of modifying -in_flags in
Given that:
* hpt366.c::hpt3xx_intrproc() is the only user of hwif-intrproc
* hpt366.c::hpt3xx_quirkproc() sets drive-quirk_list to 1 for quirky drives
which is a value unique to hpt366 host driver
we can remove hwif-intproc and just check for drive-quirk_list == 1
in ide_do_request().
Cc:
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-io.c |5 -
drivers/ide/ide-iops.c |8
include/linux/ide.h|1 -
3 files changed, 4 insertions(+), 10 deletions(-)
Index: b/drivers/ide/ide-io.c
Alan Cox wrote:
On Mon, 29 Oct 2007 22:17:40 -0600
Robert Hancock [EMAIL PROTECTED] wrote:
In the sata_nv driver, when running in ADMA mode, we can do 64-bit DMA.
However, when an ATAPI device like a DVD drive is connected, we can't
use ADMA mode, and so we have to abide by the restrictions
Chuck Ebbert wrote:
On 10/29/2007 03:41 AM, Tejun Heo wrote:
retry:
+ata_link_for_each_dev(dev, ap-link) {
How do I backport these loops to 2.6.23?
I see something like this in the old code:
for (i=0; i ATA_MAX_DEVICES; i++) {
dev = ap-device[i];
On 10/30/07, Michael Tokarev [EMAIL PROTECTED] wrote:
Eric D. Mudama wrote:
On 10/30/07, Michael Tokarev [EMAIL PROTECTED] wrote:
By the way, did you forget to remove a jumper on the drive
(the only jumper installed by default) that limits drive
usage to SATAI?
...
..etc. Try again
As jiffies changes asynchronously, it needs to be cached if unchanging
timestamp is needed. The code in ata_eh_reset() intended to do that
with @now but never actually did it. Fix it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-eh.c |2 +-
1 files changed, 1
There's nothing to be gained by configuring downstream links faster
than the upstream link and such configurations cause problems on
certain PMPs. Limit downstream link speed by the upstream link speed.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c | 22
In sata_set_spd_needed(), if SControl read failed, it returned 0 and
skipped PHY speed configuration. However, if SControl access fails,
it's far more logical to request PHY speed configuration. Reverse the
logic.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |2
Clean up and reorganize ata_eh_reset() to ease further changes.
* Cache ARRAY_SIZE(ata_eh_reset_timeouts) in @max_tries.
* Cache link-flags in @lflags.
* Move failure handling block to the end of the function and unnest
both success and failure handling blocks.
Signed-off-by: Tejun Heo [EMAIL
libata EH used to ignore errors not associated with commands when
determining whether speed down is necessary or not. This leads to the
following problems.
* Errors not associated with commands can occur indefinitely without
libata EH taking corrective actions.
* Upstream link errors don't
Reset failure is a critical error. It results in disabling the link
requiring user intervention to re-enable it. Make reset failure
handling more robust such that libata EH doesn't give up too early.
* Temporary glitches during hardreset may lead to classification
failure when there's no
Hello,
This patchset contains six small patches updating EH / configuration
behavior. This series is focused on improving corner case handling.
The following behavior changes are made.
* More robust handling classification failures.
* Improve host link speed down handling when PMP is
It would be interseting if any of the folks having power consumption
problems when suspended see an improvement with this patch.
Are there plans to refresh this patch and get it upstream?
Acked-by: Len Brown [EMAIL PROTECTED]
thanks,
-Len
On Thursday 20 September 2007 22:17, Shaohua Li wrote:
drivers/ata/libata-core.c:768: warning: 'ata_lpm_enable' defined but not used
drivers/ata/libata-core.c:784: warning: 'ata_lpm_disable' defined but not used
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |4
1 files changed, 4 insertions(+), 0
77 matches
Mail list logo
