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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
