[test 1/2] this is a test, please ignore
blah blah blah sata sata sata blah blah blah - 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
[test 2/2] this is a test, please ignore
Jeff Garzik wrote: blah blah blah sata sata sata blah blah blah Now why in the world would you write that? Silly person. 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] drivers/ide/Kconfig IDEPCI_SHARE_IRQ and IDEDISK_MULTI_MODE
From: Matti Linnanvuori [EMAIL PROTECTED]
Correct IDEPCI_SHARE_IRQ description to keeping interrupts enabled
when calling the PCI IDE action handler.
Add IDEPCI_SHARE_IRQ and IDEDISK_MULTI_MODE help text from hdparm
manual page.
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
---
--- a/drivers/ide/Kconfig 2007-10-21 08:53:11.826349500 +0300
+++ b/drivers/ide/Kconfig 2007-10-21 09:21:48.29559 +0300
@@ -154,6 +154,18 @@ config BLK_DEV_IDEDISK
config IDEDISK_MULTI_MODE
bool Use multi-mode by default
help
+ Multiple sector mode is a feature of most modern IDE hard
+ drives, permitting the transfer of multiple sectors per I/O
+ interrupt, rather than the usual one sector per interrupt.
+ When this feature is enabled, it typically reduces operating
+ system overhead for disk I/O by 30-50%. On many systems, it
+ also provides increased data throughput of anywhere from 5%
+ to 50%. Some drives, however (most notably the WD Caviar
+ series), seem to run slower with multiple mode enabled. Some
+ drives claim to support multiple mode, but lose data at some
+ settings. Under rare circumstances, such failures can result
+ in massive filesystem corruption.
+
If you get this error, try to say Y here:
hda: set_multmode: status=0x51 { DriveReady SeekComplete Error }
@@ -367,11 +379,16 @@ config BLK_DEV_IDEPCI
bool
config IDEPCI_SHARE_IRQ
- bool Sharing PCI IDE interrupts support
+ bool Keeping interrupts enabled when calling the PCI IDE action
handler support
depends on BLK_DEV_IDEPCI
help
- Some ATA/IDE chipsets have hardware support which allows for
- sharing a single IRQ with other cards. To enable support for
+ A setting of Y permits the driver to unmask other interrupts
+ during processing of a disk interrupt, which greatly improves
+ Linux's responsiveness and eliminates serial port overrun
+ errors. Use this feature with caution: some drive/controller
+ combinations do not tolerate the increased I/O latencies
+ possible when this feature is enabled, resulting in massive
+ filesystem corruption. To enable support for
this in the ATA/IDE driver, say Y here.
It is safe to say Y to this question, in most cases.
__ Ihr erstes Baby? Holen Sie sich
Tipps von anderen Eltern. www.yahoo.de/clever
-
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: [2.6.22.5] irq X: nobody cared but X is successfully used by libata
Hello, On Fri, 19 Oct 2007 12:23:15 +0900 Tejun Heo [EMAIL PROTECTED] wrote: On 26/08/07, Paul Rolland [EMAIL PROTECTED] wrote: My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is reporting a : irq 23: nobody cared (try booting with the irqpoll option) together with a Call Trace, but : - irqpoll is present on the command line, - the irq is reported to be used by libata, - the irqpoll option is mandatory if I want _some_ of my SATA disks to be accessible. I've attached a file with : - dmesg, - cat /proc/interrupts - lspci - lspci -vvv - my .config I've tried mounting and accessing all the disks, and it works. The last weird thing : though reported as used by libata, the irq 23 counter seems to be fixed at 21, though I've mounted and accessed all the disks ! Does this still happen with 2.6.23? If so, please post boot log. Thanks. Built and booted already twice, and so far, no problem anymore. I'll continue to watch this carefully, and will report any problem that could be related to this. Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation - 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: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
On Saturday 20 October 2007 19:11:56 Sergei Shtylyov wrote: What I don't like is that both PIIX4 and PCI-648 are sharing IRQ15 (PIIX4 is in legacy mode, so it uses edge-triggered IRQ15 which is not shareable). You don't have drives connected to PIIX4, do you? However, it doesn't look like a glitch on IRQ15, it looks like MRDMODE reg. doesn't work as documented... Well, don't worry too much about the PIIX device. I have disabled it in the BIOS, and I haven't compiled the driver into the kernel. The IRQ sharing hasn't troubled any linux version yet, nor any OS from the other side. MOst likely you're on the right track with the mrdmode register. cu Martin - 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: Problems with frozen drives on sil3124 + sil3726
Lars Michael Jogbäck wrote:
Hi Tejun et. al.
I'm running a server with Linux 2.6.18.1+Debian's Xen-patches and the
sata+pmp-patches from
http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.18.1-20061020.tar.bz2
Unfortunately I can't upgrade to anything newer than 2.6.18 since there
is no Xen Dom0-patches that I'm aware of to anything newer.
I have successfully for a long time together, but a couple of weeks ago
my motherboard gave in, and I installed a new one (along with new
processor/memory).
I'm running the very same kernel, the same sil3124-controller and the
same sil3726-PMP-board. The only difference is that instead of a
Supermicro P4SC8 w/ Intel P4 (and PCI-X slot of 66MHz) I'm currently
using Supermicro PDSME+ w/ E6600 (and PCI-X slot of 133MHz)
There was a bug in PCI-X irq loss quirk code which went unnoticed for
quite some time bug was fixed recently. Patch attached. Patch might
not apply directly. Just hand edit and move WOC clearing before
SLOT_STAT reading.
--
tejun
From 228f47b959a0cf2e24c9696757c7e6510334e499 Mon Sep 17 00:00:00 2001
From: Tejun Heo [EMAIL PROTECTED]
Date: Sun, 23 Sep 2007 12:37:05 +0900
Subject: [PATCH] sata_sil24: fix IRQ clearing race when PCIX_IRQ_WOC is used
When PCIX_IRQ_WOC is used, sil24 has an inherent race condition
between clearing IRQ pending and reading IRQ status. If IRQ pending
is cleared after reading IRQ status, there's possibility of lost IRQ.
If IRQ pending is cleared before reading IRQ status, spurious IRQs
will occur.
sata_sil24 till now cleared IRQ pending after reading IRQ status thus
losing IRQs on machines where PCIX_IRQ_WOC was used. Reverse the
order and ignore spurious IRQs if PCIX_IRQ_WOC.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
diff --git a/drivers/ata/sata_sil24.c b/drivers/ata/sata_sil24.c
index ef83e6b..233e886 100644
--- a/drivers/ata/sata_sil24.c
+++ b/drivers/ata/sata_sil24.c
@@ -881,43 +881,51 @@ static void sil24_finish_qc(struct ata_queued_cmd *qc)
if (qc-flags ATA_QCFLAG_RESULT_TF)
sil24_read_tf(ap, qc-tag, pp-tf);
}
static inline void sil24_host_intr(struct ata_port *ap)
{
void __iomem *port = ap-ioaddr.cmd_addr;
u32 slot_stat, qc_active;
int rc;
+ /* If PCIX_IRQ_WOC, there's an inherent race window between
+ * clearing IRQ pending status and reading PORT_SLOT_STAT
+ * which may cause spurious interrupts afterwards. This is
+ * unavoidable and much better than losing interrupts which
+ * happens if IRQ pending is cleared after reading
+ * PORT_SLOT_STAT.
+ */
+ if (ap-flags SIL24_FLAG_PCIX_IRQ_WOC)
+ writel(PORT_IRQ_COMPLETE, port + PORT_IRQ_STAT);
+
slot_stat = readl(port + PORT_SLOT_STAT);
if (unlikely(slot_stat HOST_SSTAT_ATTN)) {
sil24_error_intr(ap);
return;
}
- if (ap-flags SIL24_FLAG_PCIX_IRQ_WOC)
- writel(PORT_IRQ_COMPLETE, port + PORT_IRQ_STAT);
-
qc_active = slot_stat ~HOST_SSTAT_ATTN;
rc = ata_qc_complete_multiple(ap, qc_active, sil24_finish_qc);
if (rc 0)
return;
if (rc 0) {
struct ata_eh_info *ehi = ap-eh_info;
ehi-err_mask |= AC_ERR_HSM;
ehi-action |= ATA_EH_SOFTRESET;
ata_port_freeze(ap);
return;
}
- if (ata_ratelimit())
+ /* spurious interrupts are expected if PCIX_IRQ_WOC */
+ if (!(ap-flags SIL24_FLAG_PCIX_IRQ_WOC) ata_ratelimit())
ata_port_printk(ap, KERN_INFO, spurious interrupt
(slot_stat 0x%x active_tag %d sactive 0x%x)\n,
slot_stat, ap-active_tag, ap-sactive);
}
static irqreturn_t sil24_interrupt(int irq, void *dev_instance)
{
struct ata_host *host = dev_instance;
void __iomem *host_base = host-iomap[SIL24_HOST_BAR];
unsigned handled = 0;
--
1.5.2.4
Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Yes, link - http://lkml.org/lkml/2007/10/8/93 add the AHCI legacy support to sata_nv when IDE/RAID mode been set in SBIOS and Device IDs are not in ahci.c at this moment. To do so, when a new chipset come out and DIDs haven't been submited to LKML,user still can use ahci driver to handle it when setting AHCI mode in BIOS, using sata_nv when setting RAID/IDE in BIOS. For example, ahci driver in Fedora 7 doesn't include the DIDs of MCP78, so if you set the IDE/RAID mode in BIOS, os installation onto SATA drive will fail. But if Fedora 7 include this patch, installation will be successful. 2007/10/19, Jeff Garzik [EMAIL PROTECTED]: peer chen wrote: Ok,I agree to use AHCI driver for our AHCI controllers no matter their class codes are IDE/RAID/AHCI. But for those new or upcoming AHCI controller which DIDs are not included in ahci.c and also IDE/RAID mode being set in BIOS, no driver will be loaded currently, so I hope the first patch http://lkml.org/lkml/2007/10/8/93 can be appied for this case. Any comments? hmmm is that the correct URL? That one updates sata_nv to support AHCI controllers?. I would think you would want to add the RAID class code to ahci.c instead? And just some regular PCI IDs? 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: ADS3GX4R5-E IO problem?
Hello, Didde Brockman wrote: Oct 20 13:49:00 infra kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for resync. Oct 20 13:49:00 infra kernel: md: using 128k window, over a total of 244195904 blocks. Oct 20 13:50:37 infra kernel: res 41/40:00:2e:1c:a1/9d:01:00:00:00/40 Emask 0x409 (media error) F Oct 20 13:50:37 infra kernel: ata4.00: configured for UDMA/100 Oct 20 13:50:37 infra kernel: ata4: EH complete Error messages from libata are truncated there should be more lines before the line starts with res. Please post full dmesg. From the above, it seems like a bad drive tho. Media error indicates that the drive reported the media (platter) is bad and can't be read or written. -- 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
BUG: sata_nv swncq cannot be disabled
Hi,
I stumbled over a bug in the sata_nv swncq code of the current
2.6.23-git kernel. ata_port_info.flags is always initialised with the
ATA_FLAG_NCQ flag set, but nv_swncq_host_init(...) is only called
if swncq=1 is passed to the driver (default is swncq=0).
I can can observe ata link resets under high load if I don't pass
sata_nv.swncq=1 to my kernel.
Former versions of the SWNCQ patch didn't have this problem as
ATA_FLAG_NCQ was set in nv_swncq_host_init(...). The appended patch
restores this behaviour (or was it changed for a good reason?)
We could also simply drop the option to enable/disable swncq.
I'm not subscribed to the list so please CC me on replies.
Gerhard
---
--- linux-2.6/drivers/ata/sata_nv.c 2007-10-22 00:07:40.0 +0200
+++ linux-2.4.24/drivers/ata/sata_nv.c 2007-10-22 03:40:06.132619662 +0200
@@ -622,8 +622,7 @@ static const struct ata_port_info nv_por
/* SWNCQ */
{
.sht= nv_swncq_sht,
- .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
- ATA_FLAG_NCQ,
+ .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
.link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
@@ -1831,6 +1830,9 @@ static int nv_swncq_port_suspend(struct
/* clear irq */
writel(~0, mmio + NV_INT_STATUS_MCP55);
+ if (!(ap-flags ATA_FLAG_NCQ))
+ return 0;
+
/* disable irq */
writel(0, mmio + NV_INT_ENABLE_MCP55);
@@ -1850,6 +1852,9 @@ static int nv_swncq_port_resume(struct a
/* clear irq */
writel(~0, mmio + NV_INT_STATUS_MCP55);
+ if (!(ap-flags ATA_FLAG_NCQ))
+ return 0;
+
/* enable irq */
writel(0x00fd00fd, mmio + NV_INT_ENABLE_MCP55);
@@ -1867,6 +1872,7 @@ static void nv_swncq_host_init(struct at
void __iomem *mmio = host-iomap[NV_MMIO_BAR];
struct pci_dev *pdev = to_pci_dev(host-dev);
u8 regval;
+ int i;
/* disable ECO 398 */
pci_read_config_byte(pdev, 0x7f, regval);
@@ -1878,6 +1884,9 @@ static void nv_swncq_host_init(struct at
VPRINTK(HOST_CTL:0x%X\n, tmp);
writel(tmp | NV_CTL_PRI_SWNCQ | NV_CTL_SEC_SWNCQ, mmio + NV_CTL_MCP55);
+ for (i = 0; i host-n_ports; i++)
+ host-ports[i]-flags |= ATA_FLAG_NCQ;
+
/* enable irq intr */
tmp = readl(mmio + NV_INT_ENABLE_MCP55);
VPRINTK(HOST_ENABLE:0x%X\n, tmp);
-
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 sil3114 vs. certain seagate drives results in filesystem corruptions
Helo, Soeren Sonnenburg wrote: I finally managed to find a *reproducible* setup and way to trigger random corruptions using a sata sil 3114 controller connected to 4 seagate drives port 1: ST3400832AS sda port 2: ST3400620AS sdb port 3: ST3750640AS sdc port 4: ST3750640AS sdd sda sdb form md0 via a raid1 setup followed by an additional devicemapper layer ( root ). sdc and sdb are separate and also have an additional device mapper layer ( public ) and ( backups ). Now when I write large files of zeros to root(sdasdb) and read the file back in it contains a few nonzero entries: # dd if=/dev/zero of=/foo bs=1M count=2000 # hexdump /foo 000 * after 1GB random parts, within large blocks of zeroes I can reliably trigger this on the md0 / devmapper-root setup when I write about 2GB of data (note that this machine has 1.5G of memory - and still 1GB is often enough to see this problem). Here it does not matter where in the filesystem I do these writes. Thanks. I'll try to reproduce the problem here. What's your motherboard? Now promise_sata is converted to new EH, so I simply gave it a go, i.e. I attached ST3400832AS and ST3400620AS to the promise controller and rebooted and redid the experiments from above. No data corruptions whatsoever. I even ran the dd on all three devmapped mount points simultaneously with a size of 30GB each, still no corruption. However the error messages I've seen a year ago are back for the ST3400832AS and ST3400620AS attached to the promise controller (see below). [--snip--] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x100 action 0x2 ata1.00: port_status 0x2020 ata1.00: cmd 25/00:00:c0:b6:74/00:01:20:00:00/e0 tag 0 cdb 0x0 data 131072 in res 51/0c:00:c0:b6:74/0c:01:20:00:00/e0 Emask 0x10 (ATA bus error) ata1: soft resetting port Yeah, still the same. Your drives don't like the way promise controller speaks to them (e.g. promise generates signals which are ) but now that sata_promise has proper EH. It can recover from those errors. As long as nothing worse happens, it should be okay. Thanks. -- 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
Re: BUG: sata_nv swncq cannot be disabled
Former versions of the SWNCQ patch didn't have this problem as ATA_FLAG_NCQ was set in nv_swncq_host_init(...). The appended patch restores this behaviour (or was it changed for a good reason?) We could also simply drop the option to enable/disable swncq. Outch - sorry, just found the thread where you're already discussing the problem. I'm not subscribed to the list so please CC me on replies. Gerhard -- Gerhard DirschlPGP-Key-ID: 0x7B95AE94 Germany - 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: sata_nv swncq cannot be disabled
Gerhard Dirschl wrote: Hi, I stumbled over a bug in the sata_nv swncq code of the current 2.6.23-git kernel. ata_port_info.flags is always initialised with the ATA_FLAG_NCQ flag set, but nv_swncq_host_init(...) is only called if swncq=1 is passed to the driver (default is swncq=0). I can can observe ata link resets under high load if I don't pass sata_nv.swncq=1 to my kernel. Seeing this, are there any guarantees about SWNCQ and MSI compatibility? I have sata_nv patched to use MSI, and since SWNCQ patch arrived to the kernel (and I've enabled it to work around Gerhard's problem) my root filesystem remounts read-only or disk completely disappears every now and then :-( --- linux-2.6/drivers/ata/sata_nv.c 2007-10-22 00:07:40.0 +0200 +++ linux-2.4.24/drivers/ata/sata_nv.c 2007-10-22 03:40:06.132619662 +0200 @@ -1878,6 +1884,9 @@ static void nv_swncq_host_init(struct at VPRINTK(HOST_CTL:0x%X\n, tmp); writel(tmp | NV_CTL_PRI_SWNCQ | NV_CTL_SEC_SWNCQ, mmio + NV_CTL_MCP55); + for (i = 0; i host-n_ports; i++) + host-ports[i]-flags |= ATA_FLAG_NCQ; + /* enable irq intr */ tmp = readl(mmio + NV_INT_ENABLE_MCP55); VPRINTK(HOST_ENABLE:0x%X\n, tmp); I believe that ATA_FLAG_NCQ should be set before call to ata_pci_prepare_sff_host so you do not play with flags after host was created. I cannot find any other reason... Petr - 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 sil3114 vs. certain seagate drives results in filesystem corruptions
On Mon, 2007-10-22 at 11:12 +0900, Tejun Heo wrote: Helo, Soeren Sonnenburg wrote: I finally managed to find a *reproducible* setup and way to trigger random corruptions using a sata sil 3114 controller connected to 4 seagate drives port 1: ST3400832AS sda port 2: ST3400620AS sdb port 3: ST3750640AS sdc port 4: ST3750640AS sdd sda sdb form md0 via a raid1 setup followed by an additional devicemapper layer ( root ). sdc and sdb are separate and also have an additional device mapper layer ( public ) and ( backups ). Now when I write large files of zeros to root(sdasdb) and read the file back in it contains a few nonzero entries: # dd if=/dev/zero of=/foo bs=1M count=2000 # hexdump /foo 000 * after 1GB random parts, within large blocks of zeroes I can reliably trigger this on the md0 / devmapper-root setup when I write about 2GB of data (note that this machine has 1.5G of memory - and still 1GB is often enough to see this problem). Here it does not matter where in the filesystem I do these writes. Thanks. I'll try to reproduce the problem here. What's your motherboard? It is an asus a7v8x with a AMD Athlon(TM) XP 3000+ and admittingly almost completely filled pci slots (4 dvb cards, 1 with the sil3114; 1 empty; in the agp slot a radeon 9200). Nevertheless I would not expect the power supply to be the problem (it got replaced recently by a 500W one), enough cooling (it is winter in germany + several fans). Now promise_sata is converted to new EH, so I simply gave it a go, i.e. I attached ST3400832AS and ST3400620AS to the promise controller and rebooted and redid the experiments from above. No data corruptions whatsoever. I even ran the dd on all three devmapped mount points simultaneously with a size of 30GB each, still no corruption. However the error messages I've seen a year ago are back for the ST3400832AS and ST3400620AS attached to the promise controller (see below). [--snip--] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x100 action 0x2 ata1.00: port_status 0x2020 ata1.00: cmd 25/00:00:c0:b6:74/00:01:20:00:00/e0 tag 0 cdb 0x0 data 131072 in res 51/0c:00:c0:b6:74/0c:01:20:00:00/e0 Emask 0x10 (ATA bus error) ata1: soft resetting port Yeah, still the same. Your drives don't like the way promise controller speaks to them (e.g. promise generates signals which are ) but now that sata_promise has proper EH. It can recover from those errors. As long as nothing worse happens, it should be okay. These errors only appear when I generate some stress (like with the dd). The machine is now up 2 days 8hrs and no further such warnings in the log. Soeren - 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
