Re: [PATCH 2.6.22-rc7] libata: fix assigned IRQ reporting
Francois Romieu wrote:
Tejun Heo [EMAIL PROTECTED] :
[...]
Apparently, I'm more confused than you are. My master was at 872aad45
but my index was at rc7. Can you please force checkout the head and
re-test? I've tested both native and legacy modes and it's fixed here.
I have done a forced checkout + mrproper before rebuild and there is no
difference.
Complete dmesg is attached.
H... Weird. Can you please apply the attached patch and post boot
dmesg? Thanks.
--
tejun
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index fa1c22c..1a5bd75 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1069,6 +1069,7 @@ int ata_pci_init_one(struct pci_dev *pdev,
rc = devm_request_irq(dev, pdev-irq, pi-port_ops-irq_handler,
IRQF_SHARED, DRV_NAME, host);
host-irq = pdev-irq;
+ printk(XXX native mode irq=%lu\n, host-irq);
} else {
irq_handler_t handler[2] = { host-ops-irq_handler,
host-ops-irq_handler };
@@ -1076,6 +1077,7 @@ int ata_pci_init_one(struct pci_dev *pdev,
void *dev_id[2] = { host, host };
rc = ata_request_legacy_irqs(host, handler, irq_flags, dev_id);
+ printk(XXX legacy mode irq=%lu irq2=%lu\n, host-irq,
host-irq2);
}
if (rc)
goto err_out;
Re: [PATCH 2.6.22-rc7] libata: quirk IOMEGA ZIP 250 ATAPI FLOPPY
Jeff Garzik wrote: Alan Cox wrote: but IDE simply ignores the error and continues to operate in MWDMA mode, so I guess we can remove the 'temporary fix' comment or add another quirk type - ATA_HORKAGE_SETXFER_MAY_FAIL - and use it. Should we warn in these cases ? Or issue a new identify and check the mode activated ? The latter, issuing a new identify, is really what you want to do. AFAICT that's the canonical method of querying the device's knowledge of its mode settings. How about just keep using PIO as the patch posted in this thread does? I'm not really sure adding more complexity is worth it considering it's only one device till now and it may not even be safe considering that some controllers snoop SETXFER and configure themselves accordingly. -- 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: [PATCH 0/10] libata: irq_on/off restructuring
Tejun Heo wrote: I like the whole series. Just a few nits. * 9 and 10 need to be oen patch. As it currently stands, compile will fail after 9. * Please don't include Patch n/10 in message body. * Add freeze/thaw to all, merge, kill freeze/thaw from all sequence is a bit odd. It would be better if we can do things more directly but I haven't thought about how that can be done too hard, so if it's too difficult, it's probably not worth it. Alan, Jeff, I think we'll need to do what IDE has been doing for IRQ masking to get acceptable PIO behavior after all and that will also make us more resistant against deadly IRQ storms on controllers which don't have pending IRQ bits (most SFF ones), and this change will ease our way toward that direction. What do you guys think? Thanks for the review/advice. Revised patches to follow. -- 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: Libata PATA status (pata_artop)
On 5 Jul 2007, at 23:27, Rod Whitby wrote: Alan Cox wrote: Chipsets ARTOP No reports, but nobody appears to be using one The NSLU2-Linux project (http://www.nslu2-linux.org) relies on the pata-artop driver for the arm/ixp4xx-based Iomega NAS100d and D-Link DSM-G600 NAS devices (both of which are supported in recent mainline kernels). Latest kernels (2.6.22-rc5 is the latest we've tested) have no reported problems with pata-artop. We have a handful of people (including myself) who we know are using 2.6.22-rc5 on those devices and are booting from the internal drive using the pata-artop driver. Though we have no reported problems, we are carrying a local patch to the pata_artop driver: http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.22/15- nas100d-pata-artop-single-port.patch This used to be because of a long delay when probing the non-existent second ATA port on these embedded ARM devices, but the comment in the patch has since been updated suggesting some negative interaction with USB (??). I don't have this machine so can't comment further on this issue, M-L - 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 2.6.20-stable] sata_vsc: fix 2.6.19 to .20 regression while refactoring vsc_sata_interrupt
From: Dan Williams [EMAIL PROTECTED]
Separate sata_vsc interrupt handling into a normal (per-port) path and an
error path with the addition of vsc_port_intr and vsc_error_intr
respectively. The error path handles interrupt based
hotplug events which requires the definition of vsc_freeze and vsc_thaw.
Note: vsc_port_intr has a workaround for unexpected interrupts that occur
during polled commands. This fixes a regression between 2.6.19 and 2.6.20.
Caused by 800b399669ad495ad4361d134df87401ae36f44f.
Changes in take2:
* removed definition of invalid fis bit
* let standard ata-error-handling handle the serror register
* clear all unhandled interrupts
* revert changes to vsc_intr_mask_update (vsc_thaw enables all interrupts)
* use unlikely() for the pci-abort and not-our-interrupt cases in
vsc_sata_interrupt
Changes in take3:
* Unify the add + hook-up patches into this single patch
[EMAIL PROTECTED]: clean up comments and suggestions]
Cc: Jeremy Higdon [EMAIL PROTECTED]
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/ata/sata_vsc.c | 123 +---
1 files changed, 74 insertions(+), 49 deletions(-)
diff --git a/drivers/ata/sata_vsc.c b/drivers/ata/sata_vsc.c
index 0fa1b89..bcfca62 100644
--- a/drivers/ata/sata_vsc.c
+++ b/drivers/ata/sata_vsc.c
@@ -96,11 +96,6 @@ enum {
VSC_SATA_INT_PHY_CHANGE),
};
-
-#define is_vsc_sata_int_err(port_idx, int_status) \
-(int_status (VSC_SATA_INT_ERROR (8 * port_idx)))
-
-
static u32 vsc_sata_scr_read (struct ata_port *ap, unsigned int sc_reg)
{
if (sc_reg SCR_CONTROL)
@@ -118,6 +113,28 @@ static void vsc_sata_scr_write (struct ata_port *ap,
unsigned int sc_reg,
}
+static void vsc_freeze(struct ata_port *ap)
+{
+ void __iomem *mask_addr;
+
+ mask_addr = ap-host-mmio_base +
+ VSC_SATA_INT_MASK_OFFSET + ap-port_no;
+
+ writeb(0, mask_addr);
+}
+
+
+static void vsc_thaw(struct ata_port *ap)
+{
+ void __iomem *mask_addr;
+
+ mask_addr = ap-host-mmio_base +
+ VSC_SATA_INT_MASK_OFFSET + ap-port_no;
+
+ writeb(0xff, mask_addr);
+}
+
+
static void vsc_intr_mask_update(struct ata_port *ap, u8 ctl)
{
void __iomem *mask_addr;
@@ -202,6 +219,36 @@ static void vsc_sata_tf_read(struct ata_port *ap, struct
ata_taskfile *tf)
}
}
+static inline void vsc_error_intr(u8 port_status, struct ata_port *ap)
+{
+ if (port_status (VSC_SATA_INT_PHY_CHANGE | VSC_SATA_INT_ERROR_M))
+ ata_port_freeze(ap);
+ else
+ ata_port_abort(ap);
+}
+
+static void vsc_port_intr(u8 port_status, struct ata_port *ap)
+{
+ struct ata_queued_cmd *qc;
+ int handled = 0;
+
+ if (unlikely(port_status VSC_SATA_INT_ERROR)) {
+ vsc_error_intr(port_status, ap);
+ return;
+ }
+
+ qc = ata_qc_from_tag(ap, ap-active_tag);
+ if (qc likely(!(qc-tf.flags ATA_TFLAG_POLLING)))
+ handled = ata_host_intr(ap, qc);
+
+ /* We received an interrupt during a polled command,
+* or some other spurious condition. Interrupt reporting
+* with this hardware is fairly reliable so it is safe to
+* simply clear the interrupt
+*/
+ if (unlikely(!handled))
+ ata_chk_status(ap);
+}
/*
* vsc_sata_interrupt
@@ -213,58 +260,36 @@ static irqreturn_t vsc_sata_interrupt (int irq, void
*dev_instance)
struct ata_host *host = dev_instance;
unsigned int i;
unsigned int handled = 0;
- u32 int_status;
-
- spin_lock(host-lock);
+ u32 status;
- int_status = readl(host-mmio_base + VSC_SATA_INT_STAT_OFFSET);
+ status = readl(host-mmio_base + VSC_SATA_INT_STAT_OFFSET);
- for (i = 0; i host-n_ports; i++) {
- if (int_status ((u32) 0xFF (8 * i))) {
- struct ata_port *ap;
+ if (unlikely(status == 0x || status == 0)) {
+ if (status)
+ dev_printk(KERN_ERR, host-dev,
+ : IRQ status == 0x,
+ PCI fault or device removal?\n);
+ goto out;
+ }
- ap = host-ports[i];
+ spin_lock(host-lock);
- if (is_vsc_sata_int_err(i, int_status)) {
- u32 err_status;
- printk(KERN_DEBUG %s: ignoring
interrupt(s)\n, __FUNCTION__);
- err_status = ap ? vsc_sata_scr_read(ap,
SCR_ERROR) : 0;
- vsc_sata_scr_write(ap, SCR_ERROR, err_status);
- handled++;
- }
+ for (i = 0; i host-n_ports; i++) {
+ u8 port_status = (status (8 * i)) 0xff;
+ if (port_status) {
+ struct ata_port *ap = host-ports[i];
RE: [PATCH 2.6.20-stable] sata_vsc: fix 2.6.19 to .20 regression whilerefactoring vsc_sata_interrupt
I put in this patch and I get: 00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in [ 1416.680306] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) [ 1416.723962] ATA: abnormal status 0xD0 on port 0xE100821C [ 1416.746129] ATA: abnormal status 0xD0 on port 0xE100821C [ 1416.768582] ATA: abnormal status 0xD0 on port 0xE100821C [ 1416.790738] ATA: abnormal status 0xD0 on port 0xE100821C [ 1416.812946] ATA: abnormal status 0xD0 on port 0xE100821C [ 1446.831480] ata1.00: qc timeout (cmd 0xec) [ 1446.839662] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 1446.851797] ata1.00: revalidation failed (errno=-5) [ 1446.861508] ata1: failed to recover some devices, retrying in 5 secs [ 1459.187364] ata1: port is slow to respond, please be patient (Status 0xd0) [ 1482.215332] ata1: port failed to respond (30 secs, Status 0xd0) [ 1482.227146] ata1: soft resetting port [ 1482.387350] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1482.411264] ATA: abnormal status 0xD0 on port 0xE100821C [ 1482.433434] ATA: abnormal status 0xD0 on port 0xE100821C [ 1482.455604] ATA: abnormal status 0xD0 on port 0xE100821C [ 1482.477759] ATA: abnormal status 0xD0 on port 0xE100821C [ 1482.499966] ATA: abnormal status 0xD0 on port 0xE100821C [ 1482.515381] ata1.00: revalidation failed (errno=-2) [ 1482.525090] ata1: failed to recover some devices, retrying in 5 secs [ 1487.539353] ata1: hard resetting port [ 1487.863369] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1487.891790] ata1.00: configured for UDMA/133 [ 1487.900364] ata1: EH complete [ 1517.903401] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 [ 1517.916286] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in [ 1517.916298] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) [ 1517.959964] ATA: abnormal status 0xD0 on port 0xE100821C [ 1517.982140] ATA: abnormal status 0xD0 on port 0xE100821C [ 1518.004311] ATA: abnormal status 0xD0 on port 0xE100821C [ 1518.026467] ATA: abnormal status 0xD0 on port 0xE100821C [ 1518.048676] ATA: abnormal status 0xD0 on port 0xE100821C [ 1548.055367] ata1.00: qc timeout (cmd 0xec) [ 1548.063547] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 1548.075681] ata1.00: revalidation failed (errno=-5) [ 1548.085390] ata1: failed to recover some devices, retrying in 5 secs [ 1560.411363] ata1: port is slow to respond, please be patient (Status 0xd0) [ 1583.439334] ata1: port failed to respond (30 secs, Status 0xd0) [ 1583.451146] ata1: soft resetting port [ 1583.611347] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1583.635257] ATA: abnormal status 0xD0 on port 0xE100821C [ 1583.657432] ATA: abnormal status 0xD0 on port 0xE100821C [ 1583.679602] ATA: abnormal status 0xD0 on port 0xE100821C [ 1583.701756] ATA: abnormal status 0xD0 on port 0xE100821C [ 1583.723962] ATA: abnormal status 0xD0 on port 0xE100821C [ 1583.755661] ata1.00: revalidation failed (errno=-2) [ 1583.765373] ata1: failed to recover some devices, retrying in 5 secs [ 1588.779357] ata1: hard resetting port [ 1589.103368] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1589.131792] ata1.00: configured for UDMA/133 [ 1589.140368] ata1: EH complete [ 1619.143401] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 [ 1619.156286] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in [ 1619.156298] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x20 (host bus error) [ 1619.199953] ATA: abnormal status 0xD0 on port 0xE100821C [ 1619.222128] ATA: abnormal status 0xD0 on port 0xE100821C [ 1619.244300] ATA: abnormal status 0xD0 on port 0xE100821C [ 1619.266458] ATA: abnormal status 0xD0 on port 0xE100821C [ 1619.288666] ATA: abnormal status 0xD0 on port 0xE100821C [ 1649.307479] ata1.00: qc timeout (cmd 0xec) [ 1649.315663] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 1649.327796] ata1.00: revalidation failed (errno=-5) [ 1649.337509] ata1: failed to recover some devices, retrying in 5 secs [ 1661.663364] ata1: port is slow to respond, please be patient (Status 0xd0) [ 1684.691331] ata1: port failed to respond (30 secs, Status 0xd0) [ 1684.703143] ata1: soft resetting port [ 1684.863349] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1684.887263] ATA: abnormal status 0xD0 on port 0xE100821C [ 1684.909433] ATA: abnormal status 0xD0 on port 0xE100821C [ 1684.931604] ATA: abnormal status 0xD0 on port 0xE100821C [ 1684.953759] ATA: abnormal status 0xD0 on port 0xE100821C [ 1684.975966] ATA: abnormal status 0xD0 on port 0xE100821C [ 1685.007380] ata1.00: revalidation failed (errno=-2) [ 1685.017089] ata1: failed to recover some devices, retrying in 5 secs [ 1690.031356] ata1: hard resetting port [ 1690.355368] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1690.383791] ata1.00: configured for UDMA/133 [ 1690.392371] sd 0:0:0:0: SCSI error: return code = 0x0802 [ 1690.403642] sda: Current
[BUG] pata_ali not working on a 64 bit system
Hello, I found out that pata_ali is not working with a 64 bit kernel, while a 32 bit kernel on the same machine works fine. I'm running a very recent kernel (872aad45, somewhere after 2.6.22-rc7). The problem is that as soon as the module is loaded I get a screaming interrupt: (initramfs) modprobe pata_ali ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 23 scsi10 : pata_ali scsi11 : pata_ali ata11: PATA max UDMA/133 cmd 0x0001c880 ctl 0x0001c802 bmdma 0x0001c080 irq 23 ata12: PATA max UDMA/133 cmd 0x0001c480 ctl 0x0001c402 bmdma 0x0001c088 irq 23 irq 23: nobody cared (try booting with the irqpoll option) Call Trace: IRQ [80258407] __report_bad_irq+0x30/0x72 [80258620] note_interrupt+0x1d7/0x21b [80258ccf] handle_fasteoi_irq+0xaf/0xd8 [8020c50c] do_IRQ+0xf4/0x164 [80208631] mwait_idle+0x0/0x51 [80209bc6] ret_from_intr+0x0/0xf EOI [80208631] mwait_idle+0x0/0x51 [80208677] mwait_idle+0x46/0x51 [802085b5] cpu_idle+0x95/0xcc [805bca4e] start_kernel+0x2d3/0x2df [805bc138] _sinittext+0x138/0x13c (with irqpoll it works, but probably the driver is expecting the interrupt on another line). The most interesting difference between 32 and 64 bit is probably this one: -ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 19 +ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 23 pata_ali is driving a PCI card with a PATA port and a SATA port (sata_uli, I also tried loading this one: it doesn't scream but the SATA port is currently not used). I also tried pci=nocpi but the card still gets IRQ 23 when using a 64 bit kernel. The card is this one (lspci on the 32 bit kernel). 05:02.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85) Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 128, cache line size 80 Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at c000 [size=8] Region 1: I/O ports at bc00 [size=4] Region 2: I/O ports at b880 [size=8] Region 3: I/O ports at b800 [size=4] Region 4: I/O ports at b480 [size=16] Expansion ROM at dfe0 [disabled] [size=64K] 00: b9 10 81 52 05 00 a0 02 a4 85 80 01 80 80 80 00 10: 01 c0 00 00 01 bc 00 00 81 b8 00 00 01 b8 00 00 20: 81 b4 00 00 00 00 00 00 00 00 00 00 b9 10 81 52 30: 00 00 7f ff 00 00 00 00 00 00 00 00 0e 01 00 00 40: 80 88 08 0f 00 00 55 b1 0a 00 b1 0e 68 00 68 00 50: 01 00 02 00 00 00 00 00 00 00 00 00 09 bc 44 00 60: 00 00 00 00 00 00 00 00 10 03 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 09 00 44 00 c0: 00 00 00 00 00 00 00 00 10 03 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05:02.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) (prog-if 85) Subsystem: ALi Corporation: Unknown device 5281 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 128 Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at c880 [size=8] Region 1: I/O ports at c800 [size=4] Region 2: I/O ports at c480 [size=8] Region 3: I/O ports at c400 [size=4] Region 4: I/O ports at c080 [size=16] 00: b9 10 28 52 05 00 a0 02 c6 85 80 01 00 80 80 00 10: 81 c8 00 00 01 c8 00 00 81 c4 00 00 01 c4 00 00 20: 81 c0 00 00 00 00 00 00 a0 00 00 00 b9 10 81 52 30: 00 00 00 00 00 00 00 00 00 00 00 00 0e 01 00 00 40: 00 00 00 7f 00 00 00 00 00 10 64 c9 00 00 ba 1a 50: 00 00 00 81 00 88 44 ad 00 00 00 00 01 31 31 31 60: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (the SATA part - M5281 - is not used). The only difference with a 64 bit kernel is: - Interrupt: pin A routed to IRQ 19 +
Re: Another Maxtor drive with broken NCQ
On 07/06/2007 03:09 PM, Jeff Garzik wrote:
{Maxtor 6B200M0, BANC1BM0, ATA_HORKAGE_NONCQ }
Or should *all* Maxtor 6B200M0 be blacklisted, since there's already
one of them in the list?
Wanna send that as a patch, with attribution and sign-offs? :)
For all revisions, or just that one new one?
-
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 2.6.22-rc6] ATA: add a PCI ID for Intel Santa Rosa PATA controller
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 1:30 PM To: Thorsten Leemhuis Cc: Thorsten Leemhuis; Chuck Ebbert; Jeff Garzik; IDE/ATA development list; Gaston, Jason D; Alan Cox; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [patch 2.6.22-rc6] ATA: add a PCI ID for Intel Santa Rosa PATA controller On Wednesday, 4. July 2007, Thorsten Leemhuis wrote: Maybe Alan or someone from Intel can answer that and thus tell us how to move forward; it would be really nice to get the patch that started this thread (it got posted by Chuck again today) could go into 2.6.22, but I assume the time runs away... Jeff is on holiday and Intel doesn't respond at all... So, if someone has a ICH5 or ICH7/7-R with a ATA133 captable HDD... could you please try the following patch? (Of course, I don't know if it works,... It may cause data loss, serve corruption, or damage your controller/hdd/pc, so make backups and keep a first-aid kit handy!) On the other hand, we can leave it, because of a off-by-one error in ata_piix.c, do_pata_set_dmamode, line ~770: [...] Thanks, Chr. I quickly tried this patch on an ICH7-R system with an ATA133 Maxtor HD and it did not seem to do anything bad. I see no difference in function or performance with the patch. Jason - 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
