Re: Linux 2.6.22-rc4 - sata_promise regression since -rc3

[Mikael Pettersson <mikpe@it.uu.se>]

On Wed, 06 Jun 2007 15:56:53 +0900, Tejun Heo wrote:
> Jeff Garzik wrote:
> > On Tue, Jun 05, 2007 at 11:31:46PM +0200, Mikael Pettersson wrote:
> >> I can easily reproduce the problem in 2.6.22-rc4. There are no
> >> sata_promise changes between rc3 and rc4, but Tejun's libata
> >> polling SETXFER change was included in rc4. Reverting it makes
> >> sata_promise work again for me.
> > 
> > Ugh.
> 
> Ugh...
> 
> >> I suspect that sata_promise.c:pdc_interrupt() should detect
> >> a qc w/ ATA_TFLAG_POLLING, treat the interrupt as spurious,
> >> and just call ata_chk_status(qc), similar to how sata_inic162x.c,
> >> sata_nv.c, sata_sil.c, and sata_vsc.c do things.
> > 
> > Yes, highly likely.
> 
> I'm not sure whether that will work.  I'll give a shot at it here.

I tried it and it didn't work. The qc:s never got completed, so
they timed out and the ports got disabled.

Calling pdc_host_intr() instead, which calls ata_qc_complete(),
did work (see hack below). However, this means that pdc_interrupt()
should ignore ATA_TFLAG_POLLING, which seems strange and unsafe.

I'm just guessing here, but maybe pdc_interrupt()'s clearing of
PDC_INT_SEQMASK also affects whatever legacy ATA status bit libata
is polling to detect completion of the qc?

--- linux-2.6.22-rc4/drivers/ata/sata_promise.c.~1~	2007-06-05 22:21:39.000000000 +0200
+++ linux-2.6.22-rc4/drivers/ata/sata_promise.c	2007-06-06 12:04:38.000000000 +0200
@@ -748,6 +748,11 @@
 			qc = ata_qc_from_tag(ap, ap->active_tag);
 			if (qc && (!(qc->tf.flags & ATA_TFLAG_POLLING)))
 				handled += pdc_host_intr(ap, qc);
+			else if (qc) {
+				printk("%s: stray irq on port %u\n", __FUNCTION__, i);
+				//ata_check_status(ap);
+				handled += pdc_host_intr(ap, qc);
+			}
 		}
 	}
 

> > SFF-like controllers (and in this case, Promise is included in that
> > list) with their own interrupt handlers need their own polling handling
> > code.
> 
> One thing I don't understand is why IDENTIFY works.  IDENTIFY uses
> polling too.  Hmm...

SETXFER is special: Promise chips snoop the commands and automatically
update internal timing registers when they see XFER MODE changes. They
may be hardwired to raise interrupts after these commands.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/