On Thursday, September 16, 2004 1:56 pm, Andrew Vasquez wrote:
> On Thu, 2004-09-16 at 13:05, Jesse Barnes wrote:
> > On Thursday, September 16, 2004 12:56 pm, Paul Jackson wrote:
> > > Andrew Vasquez has been looking at this, via private email with just
> > > me (no progress yet).  Figured I update the larger list with this much
> > > ...
> >
> > It seems to be failing on one of the accesses to PCI_COMMAND in config
> > space in qla2x00_reset_chip().  I'm checking now to see if we're
> > accessing the card right after a reset but before the card has finished.
> > That would cause a master abort, the symptom I'm seeing at least.
>
> Interesting, the only changes in reset_chip() are for PCI posting
> issues.  Relevant diff attached.

Yeah, I think one of these is the culprit.  Before I got your message, I fixed
some of them in my tree already (see attached) and things seem to work.

        WRT_REG_WORD(&reg->hccr, HCCR_CLR_RISC_INT);
+       RD_REG_WORD(&reg->hccr);                        /* PCI Posting. */
        WRT_REG_WORD(&reg->hccr, HCCR_CLR_HOST_INT);
+       RD_REG_WORD(&reg->hccr);                        /* PCI Posting. */

        /* Reset ISP chip. */
        WRT_REG_WORD(&reg->ctrl_status, CSR_ISP_SOFT_RESET);
+       RD_REG_WORD(&reg->ctrl_status);                 /* PCI Posting. */

In particular, are the above ok?  If the chip is resetting, won't doing a read
cause a machine check (or at the very least, a device select timeout, which
will return all ones on friendlier platforms).

        WRT_REG_WORD(&reg->ctrl_status, CSR_ISP_SOFT_RESET);
+       RD_REG_WORD(&reg->ctrl_status);                 /* PCI Posting. */

Same here?
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>