Re: SATA exceptions with 2.6.20-rc5

[Björn Steinbrink]

On 2007.01.22 17:12:40 +0100, Björn Steinbrink wrote:
> On 2007.01.21 18:17:01 -0600, Robert Hancock wrote:
> > Björn Steinbrink wrote:
> > >On 2007.01.21 13:58:01 -0600, Robert Hancock wrote:
> > >>Björn Steinbrink wrote:
> > >>>All kernels were bad using that approach. So back to square 1. :/
> > >>>
> > >>>Björn
> > >>>
> > >>OK guys, here's a new patch to try against 2.6.20-rc5:
> > >>
> > >>Right now when switching between ADMA mode and legacy mode (i.e. when 
> > >>going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just 
> > >>set the ADMA GO register bit appropriately and continue with no delay. 
> > >>It looks like in some cases the controller doesn't respond to this 
> > >>immediately, it takes some nanoseconds for the controller's status 
> > >>registers to reflect the change that was made. It's possible that if we 
> > >>were trying to issue commands during this time, the controller might not 
> > >>react properly. This patch adds some code to wait for the status 
> > >>register to change to the state we asked for before continuing.
> > >
> > >Just got two exceptions with your patch, none of the debug messages were
> > >issued.
> > >
> > >Björn
> > 
> > Hmm, another miss, apparently.. Has anyone tried removing these lines
> > >from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does?
> > 
> >     /* bail out if not our interrupt */
> >     if (!(irq_stat & NV_INT_DEV))
> >         return 0;
> 
> Running a kernel with the return statement replace by a line that prints
> the irq_stat instead.
> 
> Currently I'm seeing lots of 0x10 on ata1 and 0x0 on ata2.

40 minutes stress test now and no exception yet. What's interesting is
that ata1 saw exactly one interrupt with irq_stat 0x0, all others that
might have get dropped are as above.
I'll keep it running for some time and will then re-enable the return
statement to see if there's a relation between the irq_stat 0x0 and the
exception.

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