lkml.org 
[lkml]   [2007]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2007-06-06 12:39    [W:0.025 / U:2.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site