Messages in this thread Patch in this message | | | Date | Wed, 6 Jun 2007 12:36:41 +0200 (MEST) | From | Mikael Pettersson <> | Subject | Re: Linux 2.6.22-rc4 - sata_promise regression since -rc3 |
| |
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/
| |