Re: Implement the technote about promise/maxtor drives
Albert wrote: > Alan wrote: > >>I don't have the hardware combination to test this one so would >>appreciate people testing it before it goes anywhere further >> > > > I've gotten two Maxtor UDMA/133 drives for testing with 2.6.20-git11. > Those Maxtors drives are quite old: the media access commands no longer > work, but device identify/configuration still works. > > Below is the test result: > > 1. Before the patch, both drives are configured to UDMA/133: > > > == > 2. After the patch, the slave drive is limited to UDMA/100: > > pata_pdc2027x :02:05.0: version 0.74-ac5 > ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10 > ACPI: PCI Interrupt :02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> > IRQ 10 > pata_pdc2027x :02:05.0: PLL input clock 16992 kHz > ata3: PATA max UDMA/133 cmd 0xe08497c0 ctl 0xe0849fda bmdma 0xe0849000 irq 10 > ata4: PATA max UDMA/133 cmd 0xe08495c0 ctl 0xe0849dda bmdma 0xe0849008 irq 10 > scsi2 : pata_pdc2027x > input: ImPS/2 Logitech Wheel Mouse as /class/input/input1 > ata3.00: ATA-5: MAXTOR 6L060L3, A93.0500, max UDMA/133 > ata3.00: 117266688 sectors, multi 16: LBA > ata3.01: ATA-7: Maxtor 6Y060L0, YAR41BW0, max UDMA/133 > ata3.01: 120103200 sectors, multi 16: LBA > ata3.00: configured for UDMA/133 > ata3.01: configured for UDMA/100 > scsi3 : pata_pdc2027x > ATA: abnormal status 0x8 on port 0xe08495df > === > So, it looks the patch works as designed/intended. > BTW, maybe we should print something similar to the "applying bridge limits" > message, > otherwise the end users might wonder why their slave drive is configured as > UDMA/100. > Some Maxtor drives have "Maxtor" and others have "MAXTOR" in the identify device data. If the slave is a "MAXTOR" one, the following code segment doesn't work. + /* If the master is a maxtor in UDMA6 then the slave should not use UDMA 6 */ + if(strstr(model_num, "Maxtor") == 0 && pair->dma_mode == XFER_UDMA_6) + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA)); Maybe we should check both "Maxtor" and "MAXTOR"? -- albert - 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
Re: Implement the technote about promise/maxtor drives
Alan wrote: > I don't have the hardware combination to test this one so would > appreciate people testing it before it goes anywhere further > I've gotten two Maxtor UDMA/133 drives for testing with 2.6.20-git11. Those Maxtors drives are quite old: the media access commands no longer work, but device identify/configuration still works. Below is the test result: 1. Before the patch, both drives are configured to UDMA/133: pata_pdc2027x :02:05.0: version 0.74-ac5 ACPI: PCI Interrupt :02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10 pata_pdc2027x :02:05.0: PLL input clock 16713 kHz ata5: PATA max UDMA/133 cmd 0xe09e97c0 ctl 0xe09e9fda bmdma 0xe09e9000 irq 10 ata6: PATA max UDMA/133 cmd 0xe09e95c0 ctl 0xe09e9dda bmdma 0xe09e9008 irq 10 scsi4 : pata_pdc2027x ata5.00: ATA-5: MAXTOR 6L060L3, A93.0500, max UDMA/133 ata5.00: 117266688 sectors, multi 16: LBA ata5.01: ATA-7: Maxtor 6Y060L0, YAR41BW0, max UDMA/133 ata5.01: 120103200 sectors, multi 16: LBA ata5.00: configured for UDMA/133 ata5.01: configured for UDMA/133 scsi5 : pata_pdc2027x ATA: abnormal status 0x8 on port 0xe09e95df scsi 4:0:0:0: Direct-Access ATA MAXTOR 6L060L3 A93. PQ: 0 ANSI: 5 SCSI device sdb: 117266688 512-byte hdwr sectors (60041 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 117266688 512-byte hdwr sectors (60041 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sd 4:0:0:0: Attached scsi disk sdb scsi 4:0:1:0: Direct-Access ATA Maxtor 6Y060L0 YAR4 PQ: 0 ANSI: 5 SCSI device sdc: 120103200 512-byte hdwr sectors (61493 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 120103200 512-byte hdwr sectors (61493 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sd 4:0:1:0: Attached scsi disk sdc == 2. After the patch, the slave drive is limited to UDMA/100: pata_pdc2027x :02:05.0: version 0.74-ac5 ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10 ACPI: PCI Interrupt :02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10 pata_pdc2027x :02:05.0: PLL input clock 16992 kHz ata3: PATA max UDMA/133 cmd 0xe08497c0 ctl 0xe0849fda bmdma 0xe0849000 irq 10 ata4: PATA max UDMA/133 cmd 0xe08495c0 ctl 0xe0849dda bmdma 0xe0849008 irq 10 scsi2 : pata_pdc2027x input: ImPS/2 Logitech Wheel Mouse as /class/input/input1 ata3.00: ATA-5: MAXTOR 6L060L3, A93.0500, max UDMA/133 ata3.00: 117266688 sectors, multi 16: LBA ata3.01: ATA-7: Maxtor 6Y060L0, YAR41BW0, max UDMA/133 ata3.01: 120103200 sectors, multi 16: LBA ata3.00: configured for UDMA/133 ata3.01: configured for UDMA/100 scsi3 : pata_pdc2027x ATA: abnormal status 0x8 on port 0xe08495df scsi 2:0:0:0: Direct-Access ATA MAXTOR 6L060L3 A93. PQ: 0 ANSI: 5 SCSI device sdb: 117266688 512-byte hdwr sectors (60041 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 117266688 512-byte hdwr sectors (60041 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sd 2:0:0:0: Attached scsi disk sdb scsi 2:0:1:0: Direct-Access ATA Maxtor 6Y060L0 YAR4 PQ: 0 ANSI: 5 SCSI device sdc: 120103200 512-byte hdwr sectors (61493 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 120103200 512-byte hdwr sectors (61493 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sd 2:0:1:0: Attached scsi disk sdc === So, it looks the patch works as designed/intended. BTW, maybe we should print something similar to the "applying bridge limits" message, otherwise the end users might wonder why their slave drive is configured as UDMA/100. -- albert - 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
Re: sata_nv ADMA controller lockup investigation
Jeff Garzik wrote:
Robert Hancock wrote:
It's curious that only the post-cache-flush command is having issues,
and normal NCQ operation seems fine. Maybe it's related to that tag 0
being reused repeatedly?
If you take cache flush out of the equation, what happens when NCQ is
enabled with a queue depth of 1 (to reproduce tag-0-used-repeatedly
condition)?
Jeff
I was able to reproduce it in my same test case with NCQ depth set to 1.
Of course, there were still some cache flushes going on there, so I'm not
certain that test really told us anything new. I'm rather doutbful that it's
related to reusing the same tag now, though, based on the tests I've been
doing. It may be something to do with switching between NCQ and non-NCQ
commands, maybe the controller isn't able to handle doing that too rapidly.
This patch seems to fix the problem - or at least it hasn't failed the tests
that
I've run so far. It's not really ideal though, so I'd like to do some more
investigation/testing before proclaiming it as a fix. Experimentally, it
appears that 10 microseconds is not enough delay, but 20 seems to work better.
Hints from the peanut gallery remain welcome.
--- linux-2.6.20-git6edit/drivers/ata/sata_nv.c.before_hacking 2007-02-15
18:19:13.0 -0600
+++ linux-2.6.20-git6edit/drivers/ata/sata_nv.c 2007-02-15 22:36:02.0
-0600
@@ -219,6 +219,7 @@
void __iomem * gen_block;
void __iomem * notifier_clear_block;
u8 flags;
+ int last_issue_ncq;
};
struct nv_host_priv {
@@ -1260,6 +1261,7 @@
{
struct nv_adma_port_priv *pp = qc->ap->private_data;
void __iomem *mmio = pp->ctl_block;
+ int curr_ncq = (qc->tf.protocol == ATA_PROT_NCQ);
VPRINTK("ENTER\n");
@@ -1274,6 +1276,14 @@
/* write append register, command tag in lower 8 bits
and (number of cpbs to append -1) in top 8 bits */
wmb();
+
+ if(curr_ncq != pp->last_issue_ncq) {
+ /* Seems to need some delay before switching between NCQ and
non-NCQ
+ commands, else we get command timeouts and such. */
+ udelay(20);
+ pp->last_issue_ncq = curr_ncq;
+ }
+
writew(qc->tag, mmio + NV_ADMA_APPEND);
DPRINTK("Issued tag %u\n",qc->tag);
-
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
Re: [git patches] libata updates (mostly fixes)
Linus Torvalds wrote: On Thu, 15 Feb 2007, Jeff Garzik wrote: diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index db185f3..d51f0f1 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -22,6 +22,7 @@ config IA64 config 64BIT bool + select ATA_NONSTANDARD if ATA default y Ok, this is just _strange_. Agreed. Tying ATA_NONSTANDARD into ia64 by tying it to the 64BIT config variable may work (well, I _assume_ it does), but it's just psychedelic. AFAICT it's an attempt to do an unconditional 'select'. I'm /not/ disputing its psychedilic properties, certainly, just figured that was the way that IA64 arch folks did stuff like this. How about adding a separate config entry like config IA64_ATA bool depends on ATA select ATA_NONSTANDARD default y which kind of makes sense when you squint just the right way.. Either way, that seems sane to me. I'd love to have some IA64 folks to comment though. Jeff - 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
Re: SiI 3114 and sata_sil
Robin H. Johnson wrote: No, that's not a correct assertion. We can only say that device-mapper is being used somehow. It could be LVM, EVMS2, dmraid, or a few other things. When using the stock open source ATA drivers, of those DM-related actors only dmraid can claim support for Sil 3114 proprietary "hardware RAID" as the user would see it. Jeff - 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
Re: SiI 3114 and sata_sil
On Thu, Feb 15, 2007 at 02:27:58PM -0500, Jeff Garzik wrote: > >So that means that the FC5 system is not actually on RAID? Even though > >it seems so? (using /dev/dm-* for filesystem volumes) > > > ># lspci | grep -i sata > >03:05.0 RAID bus controller: Silicon Image, Inc. SiI 3114 > >[SATALink/SATARaid] Serial ATA Controller (rev 02) > ># df -m > >Filesystem 1M-blocks Used Available Use% Mounted on > >/dev/dm-6 125931 2999116432 3% / > >/dev/dm-1 991381 14% /boot > >tmpfs 1012 0 1012 0% /dev/shm > >/dev/dm-2 9917 151 9254 2% /tmp > >/dev/dm-3 9917 237 9168 3% /var > ># lsmod | grep ata > >sata_sil 13897 2 > >libata 58321 1 sata_sil > >scsi_mod 129641 3 sg,libata,sd_mod > ># cat /etc/modprobe.conf | tail -n 1 > >alias scsi_hostadapter sata_sil > > > >So in fact /dev/dm-* are just on one disk each (not RAID1), or what is > >going on here? > The's dmraid providing /software/ RAID as noted in > http://linux-ata.org/faq-sata-raid.html#dmraid No, that's not a correct assertion. We can only say that device-mapper is being used somehow. It could be LVM, EVMS2, dmraid, or a few other things. Use dmsetup (info,ls,status,targets) as well as the sysfs block slave entries on dm-* to figure it out from scratch. (or at a higher level, try the LVM tools etc). -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpmKRizxiLQz.pgp Description: PGP signature
[PATCHSET] spidernet, sungem_phy: consolidated patch series
On Fri, Feb 16, 2007 at 07:46:32AM +1100, Benjamin Herrenschmidt wrote: > > > I can send a tested patch series (merging all three sources) > > Just send the blast to our list first so I can verify that the > sungem_phy doesn't adversely affect sungem and everybody By "our list", I assume you mean "[EMAIL PROTECTED]". I'm going to severely trim the cc list at this point, and send a patch series of 12 shortly. I'm going to pretend as if I was maintainer (formalities on this side pending) and attach a "signed-off-by" to each. Ben, it'll be up to you to go/no-go; if you say "go", I'll repost to eff Garzik (right?) > (especially Kou > sine you dn't have the Toshiba hardware, do you ?) can verify it all > works fine. I don't have Toshiba hardware. FWIW, I also don't have a ps3. --linas - 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
Re: BUG in libata from ata_sas_port_alloc
James Bottomley wrote: > The problem is that memory obtained by devm_kzalloc() cannot be returned > by kfree() ... they come from different allocation lists. The solution > is probably to have a corresponding ata_probe_ent_free(), I just don't > exactly see how to tell if the object came from the devm_kzalloc or not > (unless it gets marked). Just a shot in the dark, but could we simply make whatever changes are necessary to make all sas-ata LLDDs managed and then use devm_kzalloc? Though (and I may be totally wrong here) if it's the case that devres_head is made (or not made) to be part of a list _only_ before we reach ata_probe_ent_alloc, we could put a similar if check into the free function. --D - 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
Re: [git patches] libata updates (mostly fixes)
On Thu, 15 Feb 2007, Linus Torvalds wrote: > > Ok, this is just _strange_. Btw, I did pull, but I still think we shouldn't do those kinds of strange Kconfig file games. Linus - 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
Re: [git patches] libata updates (mostly fixes)
On Thu, 15 Feb 2007, Jeff Garzik wrote: > > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig > index db185f3..d51f0f1 100644 > --- a/arch/ia64/Kconfig > +++ b/arch/ia64/Kconfig > @@ -22,6 +22,7 @@ config IA64 > > config 64BIT > bool > + select ATA_NONSTANDARD if ATA > default y Ok, this is just _strange_. Tying ATA_NONSTANDARD into ia64 by tying it to the 64BIT config variable may work (well, I _assume_ it does), but it's just psychedelic. How about adding a separate config entry like config IA64_ATA bool depends on ATA select ATA_NONSTANDARD default y which kind of makes sense when you squint just the right way.. Linus - 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
Re: [git patches] libata updates (mostly fixes)
Jeff Garzik wrote:
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -352,7 +352,7 @@ static inline int ata_drive_40wire(const u16 *dev_id)
{
if (ata_id_major_version(dev_id) >= 5 && ata_id_is_sata(dev_id))
return 0; /* SATA */
- if (dev_id[93] & 0x4000)
+ if ((dev_id[93] & 0xE000) == 0x6000)
return 0; /* 80 wire */
return 1;
}
A thought: it seems to me that the major version check should be moved
into ata_id_is_sata().
Jeff
-
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
[git patches] libata updates (mostly fixes)
The pile that was waiting for post-conference, largely bug fixes.
As mentioned in the last push, were two other push points planned for
2.6.21:
1) merge libata support for ACPI
2) Remove ugly combined mode hacks in libata-sff and pci/quirks, now
that old-IDE and libata have the necessary improvements.
Depending on timing and the devres bug count, I may push #2 back to
2.6.22. The sum of devres + ACPI + remove-combined-mode-quirks
might be more change than should be in 2.6.21.
Both ACPI and remove-combined-quirks are ready to be pushed, it's just a
matter of staging. Comments welcome.
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:
arch/ia64/Kconfig |1 +
drivers/ata/libata-core.c | 11 ++-
drivers/ata/pata_legacy.c | 11 +-
drivers/ata/pata_qdi.c|4 ++-
drivers/ata/pata_sl82c105.c |3 ++
drivers/ata/sata_nv.c |6 +++-
drivers/ata/sata_promise.c| 64 +++--
drivers/ata/sata_vsc.c|8 +++-
include/asm-ia64/libata-portmap.h | 12 +++
include/linux/ata.h |2 +-
include/linux/libata.h|1 +
11 files changed, 63 insertions(+), 60 deletions(-)
create mode 100644 include/asm-ia64/libata-portmap.h
Alan Cox (1):
libata: Add a host flag to indicate lack of IORDY capability
Mikael Pettersson (2):
sata_promise: fix missing PATA cable detection
sata_promise: new EH conversion for 20619 chips, take 2
Nate Dailey (1):
sata_vsc: use default cache line size if non-zero
Olaf Hering (1):
add delay around sl82c105_reset_engine calls
Robert Hancock (1):
sata_nv: handle SError status indication
Tejun Heo (2):
libata: fix drive side 80c cable check, take 3
libata: clear TF before IDENTIFYing
Zhang, Yanmin (1):
ATA convert GSI to irq on ia64
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index db185f3..d51f0f1 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -22,6 +22,7 @@ config IA64
config 64BIT
bool
+ select ATA_NONSTANDARD if ATA
default y
config ZONE_DMA
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 25d8d3f..2cf8251 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1410,7 +1410,16 @@ int ata_dev_read_id(struct ata_device *dev, unsigned int
*p_class,
}
tf.protocol = ATA_PROT_PIO;
- tf.flags |= ATA_TFLAG_POLLING; /* for polling presence detection */
+
+ /* Some devices choke if TF registers contain garbage. Make
+* sure those are properly initialized.
+*/
+ tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
+
+ /* Device presence detection is unreliable on some
+* controllers. Always poll IDENTIFY if available.
+*/
+ tf.flags |= ATA_TFLAG_POLLING;
err_mask = ata_exec_internal(dev, &tf, NULL, DMA_FROM_DEVICE,
id, sizeof(id[0]) * ATA_ID_WORDS);
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 4223e10..98c1fee 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -89,9 +89,10 @@ static int probe_all;/* Set to check
all ISA port ranges */
static int ht6560a;/* HT 6560A on primary 1, secondary 2,
both 3 */
static int ht6560b;/* HT 6560A on primary 1, secondary 2,
both 3 */
static int opti82c611a;/* Opti82c611A on primary 1,
secondary 2, both 3 */
-static int opti82c46x; /* Opti 82c465MV present (pri/sec autodetect) */
+static int opti82c46x; /* Opti 82c465MV present (pri/sec
autodetect) */
static int autospeed; /* Chip present which snoops speed
changes */
static int pio_mask = 0x1F;/* PIO range for autospeed devices */
+static int iordy_mask = 0x;/* Use iordy if available */
/**
* legacy_set_mode - mode setting
@@ -113,6 +114,7 @@ static int legacy_set_mode(struct ata_port *ap, struct
ata_device **unused)
for (i = 0; i < ATA_MAX_DEVICES; i++) {
struct ata_device *dev = &ap->device[i];
if (ata_dev_enabled(dev)) {
+ ata_dev_printk(dev, KERN_INFO, "configured for PIO\n");
dev->pio_mode = XFER_PIO_0;
dev->xfer_mode = XFER_PIO_0;
dev->xfer_shift = ATA_SHIFT_PIO;
@@ -695,6 +697,7 @@ static __init int legacy_init_one(int port, unsigned long
io, unsigned long ctrl
void __iomem *io_addr, *ctrl_addr;
int pio_modes = pio_mask;
u32 mask = (1 << port);
+ u32 iordy = (iordy_mask & mask) ? 0: ATA_FLAG_NO_IORDY;
int ret;
pdev = platform_device_register_simp
Re: [PATCH 2.6.20] sata_vsc: use default cache line size if non-zero
Jeremy Higdon wrote:
On Wed, Feb 07, 2007 at 09:29:28AM -0500, Dailey, Nate wrote:
The attached patch modifies drivers/ata/sata_vsc.c to only set the cache
line size to 0x80 if the default value is zero. Apparently zero isn't
allowed due to a bug in the chip, but I've found performance is much
better with the (non-zero) default instead of 0x80.
Signed-off-by: Nate Dailey <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Higdon <[EMAIL PROTECTED]>
Here is the attachment from Nate, inline.
Content-Description: sata_vsc_CLS.patch
--- old/drivers/ata/sata_vsc.c 2007-02-04 13:44:54.0 -0500
+++ new/drivers/ata/sata_vsc.c 2007-02-07 09:13:17.0 -0500
@@ -345,6 +345,7 @@ static int __devinit vsc_sata_init_one (
int pci_dev_busy = 0;
void __iomem *mmio_base;
int rc;
+ u8 cls;
if (!printed_version++)
dev_printk(KERN_DEBUG, &pdev->dev, "version " DRV_VERSION "\n");
@@ -394,9 +395,13 @@ static int __devinit vsc_sata_init_one (
base = (unsigned long) mmio_base;
/*
-* Due to a bug in the chip, the default cache line size can't be used
+* Due to a bug in the chip, the default cache line size can't be
+* used (unless the default is non-zero).
*/
- pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x80);
+ pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &cls);
+ if (cls == 0x00) {
+ pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x80);
+ }
applied, after removing the superfluous braces :)
-
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
Re: [PATCH] sata_nv: handle SError status indication
Robert Hancock wrote: ADMA-capable controllers provide a bit in the status register that appears to indicate that the controller detected an SError condition. Update sata_nv to detect this and trigger error handling in order to handle the fault. Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> applied - 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
Re: [PATCH] add delay around sl82c105_reset_engine calls
Olaf Hering wrote: The hald media changed polling does really confuse things. Noone knows why the delays are needed, but they give us access to the CD. An udelay(50) will give reliable access to the drive, but there is still one (or more) EH reset. The drive works without EH resets with udelay(100). Signed-off-by: Olaf Hering <[EMAIL PROTECTED]> --- drivers/ata/pata_sl82c105.c |3 +++ 1 file changed, 3 insertions(+) applied - 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
Re: [PATCH] sata_promise: new EH conversion for 20619 chips, take 2
Mikael Pettersson wrote: This patch updates the sata_promise driver to use new-style libata error handling for 20619 (TX4000) chips. sata_promise already uses new EH for the other chips it supports, so the patch is quite simple: * remove ->phy_reset and ->eng_timeout ops from pdc_pata_ops, and instead bind ->freeze, ->thaw, ->error_handler, and ->post_internal_cmd to existing new EH functions * drop ATA_FLAG_SRST from board_20619's flags * remove now unused pdc_pata_phy_reset() and pdc_eng_timeout() Tested on a TX4000 with both modern working disks and old/quirky disks. Also used a CD-RW drive to test reading and writing CDs. Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]> --- Changes since first version: pdc_pata_cbl_detect() is not removed since it's now called from pdc_error_handler() via pdc_pre_reset(). drivers/ata/sata_promise.c | 55 +++-- 1 files changed, 4 insertions(+), 51 deletions(-) applied - 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
Re: [PATCH] ATA convert GSI to irq on ia64
Zhang, Yanmin wrote: On Thu, 2007-02-08 at 20:19 -0500, Jeff Garzik wrote: Zhang, Yanmin wrote: If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the fixed irq number. On ia64 platform, such numbers are GSI and should be converted to irq vector. Below patch against kernel 2.6.20 fixes it. Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]> IA64 should create its own libata-portmap.h, rather than modifying the one in asm-generic with arch-specific choices. powerpc is a current example of this (and currently the only non-asm-generic user) found in kernel 2.6.20. Thank Jeff. I worked out a new patch. If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the fixed irq number. On ia64 platform, such numbers are GSI and should be converted to irq vector. Below patch against kernel 2.6.20 fixes it. Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]> applied - 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
Re: [PATCH] libata: clear TF before IDENTIFYing
Tejun Heo wrote: Some devices chock if Feature is not clear when IDENTIFY is issued. Set ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE for IDENTIFY such that whole TF is cleared when reading ID data. Kudos to Art Haas for testing various futile patches over several months and Mark Lord for pointing out the fix. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Cc: Art Haas <[EMAIL PROTECTED]> Cc: Mark Lord <[EMAIL PROTECTED]> --- I think this should go into -stable but a little bit hesitant because the code hasn't been tested widely. This patch should really be harmless but who knows. Jeff, Mark, what do you think? applied - 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
Re: [PATCH] sata_promise: fix missing PATA cable detection
Mikael Pettersson wrote: This patch fixes an oversight which caused sata_promise to not perform cable detection on the TX2plus chips' PATA ports. Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]> --- This patch adds yet another is-PATA-or-SATA? check, but it's in a cold path so shouldn't matter much. This will be cleaned up if/when PATA ports and SATA ports start using different ops structures. applied - 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
Re: [PATCH libata-dev#upstream-fixes] libata: fix drive side 80c cable check, take 3
Tejun Heo wrote:
The 80c wire bit is bit 13, not 14. Bit 14 is always 1 if word93 is
implemented. This increases the chance of incorrect wire detection
especially because host side cable detection is often unreliable and
we sometimes soley depend on drive side cable detection. Fix the test
and add word93 validity check.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
Sure, updated as suggested.
diff --git a/include/linux/ata.h b/include/linux/ata.h
index 1df9416..939be94 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -347,7 +347,7 @@ static inline int ata_drive_40wire(const u16 *dev_id)
{
if (ata_id_major_version(dev_id) >= 5 && ata_id_is_sata(dev_id))
return 0; /* SATA */
- if (dev_id[93] & 0x4000)
+ if ((dev_id[93] & 0xE000) == 0x6000)
return 0; /* 80 wire */
applied
-
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
Re: [PATCH] libata: Report PIO/DMA status when overriding set_mode
Alan wrote: Currently we don't report PIO/DMA information in the case we are using firmware mode setup by drivers, or where the value is meaningless. Even when we don't know the mode, or the mode is meaningless it would be nice to report PIO or DMA and to keep stylistic consistency. For MW/UDMA we can report the actual firmware set mode and we add a helper for this. This patch for now is just a proposal for comment (and while we could guess the PIO mode by playing with the command registers and timing them I don't think its worth it) Signed-off-by: Alan Cox <[EMAIL PROTECTED]> Looks good to me. Dropped, since you say it's just a proposal Jeff - 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
BUG in libata from ata_sas_port_alloc
This is the bug sas: DOING DISCOVERY on port 1, pid:2009 INIT: slab error in verify_redzone_free(): cache `size-1024': memory outside object was overwritten [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x16/0x20 [] __slab_error+0x26/0x30 [] cache_free_debugcheck+0x141/0x1f0 [] kfree+0x7d/0xf0 [] ata_sas_port_alloc+0x5f/0x80 [libata] [] sas_ata_init_host_and_port+0x5e/0xa0 [libsas] [] sas_target_alloc+0x4d/0x60 [libsas] [] scsi_alloc_target+0x208/0x320 [scsi_mod] [] __scsi_scan_target+0x59/0x6d0 [scsi_mod] [] scsi_scan_target+0xa7/0xc0 [scsi_mod] [] sas_rphy_add+0xdf/0x110 [scsi_transport_sas] [] sas_discover_sata+0x79/0x480 [libsas] [] sas_discover_domain+0x3d1/0x490 [libsas] [] run_workqueue+0xe7/0x170 [] worker_thread+0x147/0x170 [] kthread+0xb7/0xe0 [] kernel_thread_helper+0x7/0x14 === f707398c: redzone 1:0xc023e580, redzone 2:0x6b6b6b6b. Just struck. This looks to be the problem: ent = ata_probe_ent_alloc(host->dev, port_info); [...] kfree(ent); However, if you look in ata_probe_ent_alloc() you see /* XXX - the following if can go away once all LLDs are managed */ if (!list_empty(&dev->devres_head)) probe_ent = devm_kzalloc(dev, sizeof(*probe_ent), GFP_KERNEL); else probe_ent = kzalloc(sizeof(*probe_ent), GFP_KERNEL); The problem is that memory obtained by devm_kzalloc() cannot be returned by kfree() ... they come from different allocation lists. The solution is probably to have a corresponding ata_probe_ent_free(), I just don't exactly see how to tell if the object came from the devm_kzalloc or not (unless it gets marked). James - 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
Re: [PATCHSET] libata: PATA driver for Celleb
> I can send a tested patch series (merging all three sources) > immediately, assuming you like the tree these would be based on. > Any special instructions or proceedures to follow, any secret > initiation rites, hazing, or change of citizenship required? Just send the blast to our list first so I can verify that the sungem_phy doesn't adversely affect sungem and everybody (especially Kou sine you dn't have the Toshiba hardware, do you ?) can verify it all works fine. Cheers, Ben - 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
Re: SiI 3114 and sata_sil
Florin Andrei wrote: Jeff Garzik wrote: Florin Andrei wrote: (I'm not subscribed to linux-ide) I've two almost identical systems (slightly different CPUs) that use SiI 3114 for SATA and RAID. One of them was installed a while ago with Fedora Core 5 (kernel 2.6.15-1.2054_FC5smp) and whoever installed it was able to turn on hardware RAID. This chip does not support hardware RAID. The capability simply isn't there in the silicon. http://linux-ata.org/faq-sata-raid.html#sii Wow! :-( So that means that the FC5 system is not actually on RAID? Even though it seems so? (using /dev/dm-* for filesystem volumes) # lspci | grep -i sata 03:05.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) # df -m Filesystem 1M-blocks Used Available Use% Mounted on /dev/dm-6 125931 2999116432 3% / /dev/dm-1 991381 14% /boot tmpfs 1012 0 1012 0% /dev/shm /dev/dm-2 9917 151 9254 2% /tmp /dev/dm-3 9917 237 9168 3% /var # lsmod | grep ata sata_sil 13897 2 libata 58321 1 sata_sil scsi_mod 129641 3 sg,libata,sd_mod # cat /etc/modprobe.conf | tail -n 1 alias scsi_hostadapter sata_sil So in fact /dev/dm-* are just on one disk each (not RAID1), or what is going on here? The's dmraid providing /software/ RAID as noted in http://linux-ata.org/faq-sata-raid.html#dmraid Jeff - 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
[PATCH] (pata-2.6 fix queue) cmd64x: procfs code fixes/cleanups
Fix several issues with the driver's procfs output:
- when testing if channel is enabled, the code looks at the "simplex" bits, not
at the real enable bits -- add #define for the primary channel enable bit;
- UltraDMA modes 0, 1, 3 for slave drive reported incorrectly due to using the
master drive's clock cycle resolution bit.
While at it, also perform some cleanups:
- don't read from the registers which are not used for dump;
- correct the chipset names (from CMDxxx to PCI-xxx);
- rework UltraDMA mode dump code;
- remove PIO mode dump code that has never been finished;
- remove the duplicate interrupt status dump (the MRDMODE register bits mirror
those in the CFR and ARTTIM23 registers);
- add spaces in the ?: operators...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
Warning: as usual, this has only been compile-tested. :-)
drivers/ide/pci/cmd64x.c | 99 ++-
1 files changed, 39 insertions(+), 60 deletions(-)
Index: linux-2.6/drivers/ide/pci/cmd64x.c
===
--- linux-2.6.orig/drivers/ide/pci/cmd64x.c
+++ linux-2.6/drivers/ide/pci/cmd64x.c
@@ -1,6 +1,6 @@
/* $Id: cmd64x.c,v 1.21 2000/01/30 23:23:16
*
- * linux/drivers/ide/pci/cmd64x.c Version 1.45Feb 14, 2007
+ * linux/drivers/ide/pci/cmd64x.c Version 1.46Feb 15, 2007
*
* cmd64x.c: Enable interrupts at initialization time on Ultra/PCI machines.
* Note, this driver is not used at all on other systems because
@@ -41,9 +41,10 @@
#define CFR0x50
#define CFR_INTR_CH0 0x04
#define CNTRL 0x51
-#define CNTRL_DIS_RA0 0x40
-#define CNTRL_DIS_RA10x80
-#define CNTRL_ENA_2ND 0x08
+#define CNTRL_ENA_1ST0x04
+#define CNTRL_ENA_2ND0x08
+#define CNTRL_DIS_RA00x40
+#define CNTRL_DIS_RA10x80
#defineCMDTIM 0x52
#defineARTTIM0 0x53
@@ -90,23 +91,15 @@ static int n_cmd_devs;
static char * print_cmd64x_get_info (char *buf, struct pci_dev *dev, int index)
{
char *p = buf;
-
- u8 reg53 = 0, reg54 = 0, reg55 = 0, reg56 = 0; /* primary */
- u8 reg57 = 0, reg58 = 0, reg5b; /* secondary */
u8 reg72 = 0, reg73 = 0;/* primary */
u8 reg7a = 0, reg7b = 0;/* secondary */
- u8 reg50 = 0, reg71 = 0;/* extra */
+ u8 reg50 = 1, reg51 = 1, reg57 = 0, reg71 = 0; /* extra */
p += sprintf(p, "\nController: %d\n", index);
- p += sprintf(p, "CMD%x Chipset.\n", dev->device);
+ p += sprintf(p, "PCI-%x Chipset.\n", dev->device);
(void) pci_read_config_byte(dev, CFR, ®50);
- (void) pci_read_config_byte(dev, ARTTIM0, ®53);
- (void) pci_read_config_byte(dev, DRWTIM0, ®54);
- (void) pci_read_config_byte(dev, ARTTIM1, ®55);
- (void) pci_read_config_byte(dev, DRWTIM1, ®56);
- (void) pci_read_config_byte(dev, ARTTIM2, ®57);
- (void) pci_read_config_byte(dev, DRWTIM2, ®58);
- (void) pci_read_config_byte(dev, DRWTIM3, ®5b);
+ (void) pci_read_config_byte(dev, CNTRL, ®51);
+ (void) pci_read_config_byte(dev, ARTTIM23, ®57);
(void) pci_read_config_byte(dev, MRDMODE, ®71);
(void) pci_read_config_byte(dev, BMIDESR0, ®72);
(void) pci_read_config_byte(dev, UDIDETCR0, ®73);
@@ -116,57 +109,43 @@ static char * print_cmd64x_get_info (cha
p += sprintf(p, "--- Primary Channel "
" Secondary Channel "
"-\n");
- p += sprintf(p, "%sabled "
- " %sabled\n",
- (reg72&0x80)?"dis":" en",
- (reg7a&0x80)?"dis":" en");
+ p += sprintf(p, "%sabled "
+ "%sabled\n",
+ (reg51 & CNTRL_ENA_1ST) ? "dis" : " en",
+ (reg51 & CNTRL_ENA_2ND) ? "dis" : " en");
p += sprintf(p, "--- drive0 "
"- drive1 drive0 "
"-- drive1 --\n");
p += sprintf(p, "DMA enabled:%s %s"
" %s %s\n",
- (reg72&0x20)?"yes":"no ", (reg72&0x40)?"yes":"no ",
- (reg7a&0x20)?"yes":"no ", (reg7a&0x40)?"yes":"no ");
+ (reg72 & 0x20) ? "yes" : "no ", (reg72 & 0x40)? "yes" : "no ",
+ (reg7a & 0x20) ? "yes" : "no ", (reg7a & 0x40)? "yes" : "no ");
- p += sprintf(p, "DMA Mode: %s(%s) %s(%s)",
- (reg72&0x20)?((reg73&0x01)?"UDMA":" DMA"):" PIO",
- (reg72&0x20)?(
- ((reg73&0x30)==0x30)?(((reg73&0x35)==0x35)?"3":"0
Re: [PATCHSET] libata: PATA driver for Celleb
On Thu, Feb 15, 2007 at 07:09:25PM +0100, Arnd Bergmann wrote: > On Thursday 15 February 2007 18:14, Linas Vepstas wrote: > > > Linas has done a pretty good job on improving the driver in the last half > > > year or so and he also has access to all the necessary hardware so I think > > > he would be the right person for the job. > > > > It seems I've been nominated twice. Since I'm expecting future activity > > to drop to zero, how hard can this be? :-) > > I fear that the hardest part is yet to come, Well, then, its a good thing I put a smiley face at the end of the sentence, eh? > when we integrate the > driver for the the PS3 (currently called gelic_net) into spidernet. > The trouble is that the hardware is sufficiently similar to share > all the high-level mechanisms like the DMA data structures and > descriptor chains, but the low-level mechanisms are hidden in the > hypervisor on the PS3. Someone will have to invest a significant > amount of time coordinating this so we don't break celleb and qs20 > in the process. Since I've got the driver more or less memorized, I don't expect this to be an intellectual challenge. Which sometimes has the side effect of my getting bored, and dropping things on the floor. > I also think that you'd do a good job doing this, but it may be > more that what you are willing to do without official funding of the > time you spend on it. (Ardnt knows that my spidernet work is "moonlighting", off-the-books work.) I'll ask my employer. > Of course the actual amount of work will > depend a lot on the quality of the spidernet patches coming from > Sony to the spidernet maintainer. I guess I'll have to ask my employer for a ps3 that I can do some "research" on. --linas - 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
Re: SiI 3114 and sata_sil
Jeff Garzik wrote: Florin Andrei wrote: (I'm not subscribed to linux-ide) I've two almost identical systems (slightly different CPUs) that use SiI 3114 for SATA and RAID. One of them was installed a while ago with Fedora Core 5 (kernel 2.6.15-1.2054_FC5smp) and whoever installed it was able to turn on hardware RAID. This chip does not support hardware RAID. The capability simply isn't there in the silicon. http://linux-ata.org/faq-sata-raid.html#sii Wow! :-( So that means that the FC5 system is not actually on RAID? Even though it seems so? (using /dev/dm-* for filesystem volumes) # lspci | grep -i sata 03:05.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) # df -m Filesystem 1M-blocks Used Available Use% Mounted on /dev/dm-6 125931 2999116432 3% / /dev/dm-1 991381 14% /boot tmpfs 1012 0 1012 0% /dev/shm /dev/dm-2 9917 151 9254 2% /tmp /dev/dm-3 9917 237 9168 3% /var # lsmod | grep ata sata_sil 13897 2 libata 58321 1 sata_sil scsi_mod 129641 3 sg,libata,sd_mod # cat /etc/modprobe.conf | tail -n 1 alias scsi_hostadapter sata_sil So in fact /dev/dm-* are just on one disk each (not RAID1), or what is going on here? -- Florin Andrei http://florin.myip.org/ - 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
Re: SiI 3114 and sata_sil
Florin Andrei wrote: (I'm not subscribed to linux-ide) I've two almost identical systems (slightly different CPUs) that use SiI 3114 for SATA and RAID. One of them was installed a while ago with Fedora Core 5 (kernel 2.6.15-1.2054_FC5smp) and whoever installed it was able to turn on hardware RAID. This chip does not support hardware RAID. The capability simply isn't there in the silicon. http://linux-ata.org/faq-sata-raid.html#sii Jeff - 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
SiI 3114 and sata_sil
(I'm not subscribed to linux-ide) I've two almost identical systems (slightly different CPUs) that use SiI 3114 for SATA and RAID. One of them was installed a while ago with Fedora Core 5 (kernel 2.6.15-1.2054_FC5smp) and whoever installed it was able to turn on hardware RAID. The other was installed with CentOS 4.4 (kernel 2.6.9-42.0.8.ELsmp) by myself. I tried many different things, but I couldn't activate RAID. The installer was always seeing two separate drives instead of one RAID volume. Is this caused by the sata_sil driver? Is the version used by CentOS too old to support RAID? BTW, on Fedora 5, how do I monitor the status of the RAID arrays? There doesn't seem to be anything in /proc to provide that info. Thanks, -- Florin Andrei http://florin.myip.org/ - 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
Re: [PATCHSET] libata: PATA driver for Celleb
On Thursday 15 February 2007 18:14, Linas Vepstas wrote: > > Linas has done a pretty good job on improving the driver in the last half > > year or so and he also has access to all the necessary hardware so I think > > he would be the right person for the job. > > It seems I've been nominated twice. Since I'm expecting future activity > to drop to zero, how hard can this be? :-) I fear that the hardest part is yet to come, when we integrate the driver for the the PS3 (currently called gelic_net) into spidernet. The trouble is that the hardware is sufficiently similar to share all the high-level mechanisms like the DMA data structures and descriptor chains, but the low-level mechanisms are hidden in the hypervisor on the PS3. Someone will have to invest a significant amount of time coordinating this so we don't break celleb and qs20 in the process. I also think that you'd do a good job doing this, but it may be more that what you are willing to do without official funding of the time you spend on it. Of course the actual amount of work will depend a lot on the quality of the spidernet patches coming from Sony to the spidernet maintainer. Arnd <>< - 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
Re: libata FUA revisited
On Tue, Feb 13 2007, Tejun Heo wrote: > >>So, actually, I was thinking about *always* using the non-NCQ FUA > >>opcode. As currently implemented, FUA request is always issued by > >>itself, so NCQ doesn't make any difference there. So, I think it > >>would be better to turn on FUA on driver-by-driver basis whether the > >>controller supports NCQ or not. > > > >Unfortunately not all drives that support NCQ support the non-NCQ FUA > >commands (my Seagates are like this). > > And I'm a bit scared to set FUA bit on such drives and trust that it > will actually do FUA, so our opinions aren't too far away from each > other. :-) > > >There's definitely a potential advantage to FUA with NCQ - if you have > >non-synchronous accesses going on concurrently with synchronous ones, if > >you have to use non-NCQ FUA or flush cache commands, you have to wait > >for all the IOs of both types to drain out before you can issue the > >flush (since those can't be overlapped with the NCQ read/writes). And if > >you can only use flush cache, then you're forcing all the writes to be > >flushed including the non-synchronous ones you didn't care about. > >Whether or not the block layer currently exploits this I don't know, but > >it definitely could. > > The current barrier implementation uses the following sequences for > no-FUA and FUA cases. > > 1. w/o FUA > > normal operation -> barrier issued -> drain IO -> flush -> barrier > written -> flush -> normal operation resumes > > 2. w/ FUA > > normal operation -> barrier issued -> drain IO -> flush -> barrier > written / FUA -> normal operation resumes > > So, the FUA write is issued by itself. This isn't really efficient and > frequent barriers impact the performance badly. If we can change that > NCQ FUA will be certainly beneficial. But we can't really change that, since you need the cache flushed before issuing the FUA write. I've been advocating for an ordered bit for years, so that we could just do: 3. w/FUA+ORDERED normal operation -> barrier issued -> write barrier FUA+ORDERED -> normal operation resumes So we don't have to serialize everything both at the block and device level. I would have made FUA imply this already, but apparently it's not what MS wanted FUA for, so... The current implementations take the FUA bit (or WRITE FUA) as a hint to boost it to head of queue, so you are almost certainly going to jump ahead of already queued writes. Which we of course really do not. > >>Well, I might be being too paranoid but silent FUA failure would be > >>really hard to diagnose if that ever happens (and I'm fairly certain > >>that it will on some firmwares). > > > >Well, there are also probably drives that ignore flush cache commands or > > fail to do other things that they should. There's only so far we can go > >in coping if the firmware authors are being retarded. If any drive is > >broken like that we should likely just blacklist NCQ on it entirely as > >obviously little thought or testing went into the implementation.. > > FLUSH has been around quite long time now and most drives don't have > problem with that. FUA on ATA is still quite new and libata will be the > first major user of it if we enable it by default. It just seems too > easy to ignore that bit and successfully complete the write - there > isn't any safety net as opposed to using a separate opcode. So, I'm a > bit nervous. I'm not too nervous about the FUA write commands, I hope we can safely assume that if you set the FUA supported bit in the id AND the write fua command doesn't get aborted, that FUA must work. Anything else would just be an immensely stupid implementation. NCQ+FUA is more tricky, I agree that it being just a command bit does make it more likely that it could be ignored. And that is indeed a danger. Given state of NCQ in early firmware drives, I would not at all be surprised if the drive vendors screwed that up too. But, since we don't have the ordered bit for NCQ/FUA anyway, we do need to drain the drive queue before issuing the WRITE/FUA. And at that point we may as well not use the NCQ command, just go for the regular non-NCQ FUA write. I think that should be safe. -- Jens Axboe - 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
Re: [PATCHSET] libata: PATA driver for Celleb
On Thu, Feb 15, 2007 at 11:41:49AM +0100, Jens Osterkamp wrote: > On Thursday 15 February 2007, Benjamin Herrenschmidt wrote: > > > I'm totally confused about who the heck is the spidernet maintainer. > > > > Me too :-) > > > > It's been a bit of a mess. I suggest we get our gear together (Linas, > > Jens, Kou) and provide you a single patch set from a single source in > > the upcoming couple of days coming from the designated maintainer. OK. However, I think the blast of paches is a statistical anomoly, I'm expecting future activity on spidernet to drop to just about zero. > > Jens ? Linas ? Is that ok with you guys ? Who gets to be that > > maintainer ? > > Linas has done a pretty good job on improving the driver in the last half > year or so and he also has access to all the necessary hardware so I think > he would be the right person for the job. It seems I've been nominated twice. Since I'm expecting future activity to drop to zero, how hard can this be? :-) I can send a tested patch series (merging all three sources) immediately, assuming you like the tree these would be based on. Any special instructions or proceedures to follow, any secret initiation rites, hazing, or change of citizenship required? --linas - 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
Re: [PATCHSET] libata: PATA driver for Celleb
We have had some discussions previously about Linas Vepstas taking over the maintainership of Spidernet from me. I will look into this and see if we can make it happen. Jim Lewis On Thu, 2007-02-15 at 11:41 +0100, Jens Osterkamp wrote: > On Thursday 15 February 2007, Benjamin Herrenschmidt wrote: > > > > > I'm totally confused about who the heck is the spidernet maintainer. > > > > Me too :-) > > > > > My > > > inbox is pelted by spidernet driver updates from multiple people, and > > > often the spidernet patches (regardless of author) receive comments that > > > give me pause. The MAINTAINERS file says > > > > > > > SPIDERNET NETWORK DRIVER for CELL > > > > P: Jim Lewis > > > > M: [EMAIL PROTECTED] > > > > L: netdev@vger.kernel.org > > > > S: Supported > > > > > > but I do not see patch roll-ups or much activity from him at all. In > > > practice, it seems like Linas does patchsets for spidernet, but there is > > > also Jakob Osterkemp(sp?) and Ishizaki and > > > > I think Jens Osterkampf should be the final ACK/NAK'er as he has all the > > hardware to test except the Toshiba gear :-) In fact, Jens, if you are > > ok with that, I'd like to have you be the maintainer of that driver, > > unless you think it's better for Linas to do it. > > > > > My overall impression of spidernet development is that EVERYBODY is > > > submitting patches at once, and expecting me to sort out the mess. No > > > thanks. > > > > It's been a bit of a mess. I suggest we get our gear together (Linas, > > Jens, Kou) and provide you a single patch set from a single source in > > the upcoming couple of days coming from the designated maintainer. > > > > Jens ? Linas ? Is that ok with you guys ? Who gets to be that > > maintainer ? > > > > _ALSO_ since spidernet uses (and modifies) sungem_phy.c, we need either > > DaveM or my ack there (DaveM is sungem maintainer but I wrote sungem_phy > > and most of it is only used on powermacs). > > > > Thus let's move that back to the cbe-oss-dev mailing list, our > > designated maintainer will post there a candidate patch set, I will > > verify the sungem_phy change is ok with powermac (I myself haven't > > followed enough to figure out what patch is the latest there), we'll all > > test on our respective hardware, and then that maintainer will send you > > one patch set to apply. > > > > That shouldn't take more than a few days. If we miss -rc1, well, then it > > will be in -rc2, as most of the patches have been around for long enough > > etc... it's really mostly a matter of getting our gear together. > > > > > Speaking with one voice would be much appreciated. And said speaker > > > should patch the MAINTAINERS file to reflect reality. > > Sounds reasonable. I fully agree. > > Linas has done a pretty good job on improving the driver in the last half > year or so and he also has access to all the necessary hardware so I think > he would be the right person for the job. > > Jens - 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
[PATCH] (pata-2.6 fix queue) cmd64x: interrupt status fixes (resend)
The driver's ide_dma_test_irq() method was reading the MRDMODE register even on
PCI0643/6 where it was write-only -- fix this by always reading the "backward-
compatible" interrupt bits, renaming dma_alt_stat to irq_stat as these interrupt
status bits are not coupled to DMA.
In addition, wrong interrupt bit was tested/cleared for the primary channel --
it's bit 2 in all the chip specs and the driver used bit 1... :-/
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
Warning: as usual, this has only been compile-tested. :-)
Grrr, lost signoff somewhere again, so resending...
drivers/ide/pci/cmd64x.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
Index: linux-2.6/drivers/ide/pci/cmd64x.c
===
--- linux-2.6.orig/drivers/ide/pci/cmd64x.c
+++ linux-2.6/drivers/ide/pci/cmd64x.c
@@ -1,6 +1,6 @@
/* $Id: cmd64x.c,v 1.21 2000/01/30 23:23:16
*
- * linux/drivers/ide/pci/cmd64x.c Version 1.43Feb 8, 2007
+ * linux/drivers/ide/pci/cmd64x.c Version 1.44Feb 13, 2007
*
* cmd64x.c: Enable interrupts at initialization time on Ultra/PCI machines.
* Note, this driver is not used at all on other systems because
@@ -39,7 +39,7 @@
* CMD64x specific registers definition.
*/
#define CFR0x50
-#define CFR_INTR_CH0 0x02
+#define CFR_INTR_CH0 0x04
#define CNTRL 0x51
#define CNTRL_DIS_RA0 0x40
#define CNTRL_DIS_RA10x80
@@ -510,19 +510,19 @@ static int cmd64x_ide_dma_end (ide_drive
static int cmd64x_ide_dma_test_irq (ide_drive_t *drive)
{
- ide_hwif_t *hwif= HWIF(drive);
- struct pci_dev *dev = hwif->pci_dev;
-u8 dma_alt_stat = 0, mask = (hwif->channel) ? MRDMODE_INTR_CH1 :
- MRDMODE_INTR_CH0;
- u8 dma_stat = hwif->INB(hwif->dma_status);
+ ide_hwif_t *hwif= HWIF(drive);
+ struct pci_dev *dev = hwif->pci_dev;
+ u8 irq_reg = hwif->channel ? ARTTIM23 : CFR;
+ u8 irq_stat = 0, mask = hwif->channel ? ARTTIM23_INTR_CH1 :
CFR_INTR_CH0;
+ u8 dma_stat = hwif->INB(hwif->dma_status);
+
+ (void) pci_read_config_byte(dev, irq_reg, &irq_stat);
- (void) pci_read_config_byte(dev, MRDMODE, &dma_alt_stat);
#ifdef DEBUG
- printk("%s: dma_stat: 0x%02x dma_alt_stat: "
- "0x%02x mask: 0x%02x\n", drive->name,
- dma_stat, dma_alt_stat, mask);
+ printk("%s: dma_stat: 0x%02x irq_stat: 0x%02x mask: 0x%02x\n",
+ drive->name, dma_stat, irq_stat, mask);
#endif
- if (!(dma_alt_stat & mask))
+ if (!(irq_stat & mask))
return 0;
/* return 1 if INTR asserted */
-
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
Re: [PATCH] sata_via: fix resource-managed iomap conversion
On 12-02-2007 21:10, Tejun Heo wrote: > Markus Trippelsdorf wrote: >> On Mon, Feb 12, 2007 at 10:51:44AM -0800, Tejun Heo wrote: >>> Conversion to resource-managed iomap was buggy causing init failures >>> on both vt6420 and 6421 - BAR5 wasn't mapped for both controllers >>> while on vt6420 sata_via tried to map BAR0-4 twice. Fix it. > > Great, can anyone verify this on vt6421? I'm sure they will. I can only confirm with vt6420 too and presume it can't be worse, so please apply. Thanks & regards, Jarek P. - 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
Re: Sata_via problems in a Vintage2-AE1: Resume
A Dimarts 13 Febrer 2007 17:19, Jean Delvare va escriure: > Le Mardi 13 Février 2007 17:11, Leopold Palomo-Avellaneda a écrit : > > A Dimarts 13 Febrer 2007 12:20, Jean Delvare va escriure: > > (...) > > > > > > > *If* the VT8251 needs the VIA IRQ quirk, then the attached patch > > > > > may help. Leopold, can you give it a try? > > > > > > > > Well, making your patch to the vanilla 2.6.20 the result is the same. > > > > The box doesn't boot. Always the same problem > > > > > > If it's not a VIA IRQ problem, then there's nothing more I can do, > > > sorry. Someone else will have to look into the problem. > > > > > > Out of curiosity, with my patch applied, did you see any "VIA VLink IRQ > > > fixup" messages on the console? > > > > No :-( > > OK, so maybe the VT8251 actually no longer needs the quirk. Thanks for > testing and reporting. Hi people, arriving to this state. What do you recommend? I have the box more or less working with irqpoll but with a lot of messages: APIC error on CPU0: 08(08) and the box doesn't boot without the irqpoll option. Do you think that the 2.6.21 have some kind of changes in this area? Thank's for all for you patience and your messages. Best regards, Leo - 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
Re: sata_nv ADMA controller lockup investigation
Robert Hancock wrote: It's curious that only the post-cache-flush command is having issues, and normal NCQ operation seems fine. Maybe it's related to that tag 0 being reused repeatedly? If you take cache flush out of the equation, what happens when NCQ is enabled with a queue depth of 1 (to reproduce tag-0-used-repeatedly condition)? Jeff - 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
Re: [PATCHSET] libata: PATA driver for Celleb
On Thursday 15 February 2007, Benjamin Herrenschmidt wrote: > > > I'm totally confused about who the heck is the spidernet maintainer. > > Me too :-) > > > My > > inbox is pelted by spidernet driver updates from multiple people, and > > often the spidernet patches (regardless of author) receive comments that > > give me pause. The MAINTAINERS file says > > > > > SPIDERNET NETWORK DRIVER for CELL > > > P: Jim Lewis > > > M: [EMAIL PROTECTED] > > > L: netdev@vger.kernel.org > > > S: Supported > > > > but I do not see patch roll-ups or much activity from him at all. In > > practice, it seems like Linas does patchsets for spidernet, but there is > > also Jakob Osterkemp(sp?) and Ishizaki and > > I think Jens Osterkampf should be the final ACK/NAK'er as he has all the > hardware to test except the Toshiba gear :-) In fact, Jens, if you are > ok with that, I'd like to have you be the maintainer of that driver, > unless you think it's better for Linas to do it. > > > My overall impression of spidernet development is that EVERYBODY is > > submitting patches at once, and expecting me to sort out the mess. No > > thanks. > > It's been a bit of a mess. I suggest we get our gear together (Linas, > Jens, Kou) and provide you a single patch set from a single source in > the upcoming couple of days coming from the designated maintainer. > > Jens ? Linas ? Is that ok with you guys ? Who gets to be that > maintainer ? > > _ALSO_ since spidernet uses (and modifies) sungem_phy.c, we need either > DaveM or my ack there (DaveM is sungem maintainer but I wrote sungem_phy > and most of it is only used on powermacs). > > Thus let's move that back to the cbe-oss-dev mailing list, our > designated maintainer will post there a candidate patch set, I will > verify the sungem_phy change is ok with powermac (I myself haven't > followed enough to figure out what patch is the latest there), we'll all > test on our respective hardware, and then that maintainer will send you > one patch set to apply. > > That shouldn't take more than a few days. If we miss -rc1, well, then it > will be in -rc2, as most of the patches have been around for long enough > etc... it's really mostly a matter of getting our gear together. > > > Speaking with one voice would be much appreciated. And said speaker > > should patch the MAINTAINERS file to reflect reality. Sounds reasonable. I fully agree. Linas has done a pretty good job on improving the driver in the last half year or so and he also has access to all the necessary hardware so I think he would be the right person for the job. Jens - 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
