Possible mouse/ATA problems in -STABLE

[Mike Harding]

Sorry if this is confusing - the history, from my end at least, goes
like this:

- my mouse started getting 'flaky' around Sept. 1.  I was get 'psmintr'
sync errors, and sometimes the mouse would get disabled, necessitating a
reboot.  I have seen the psmintr errors occasionally before, but never
had the mouse disappear.  This started happening right after I saw some
ATA changes in my cvsup, so I suspect ATA changes, committed (by luoqi)
on Sept. 5 and after.  The mouse had been rock solid for at least a year
before this.
- The were some 'mfc' comments in the ATA code specifically in the DMA
code, sorry to rope Soren into this... the changes don't necessarily
have anything to do with -current, but the comments on ata-dma.c, rev
1.35.2.33 did say MFC.
- I was suprised to see -any- ATA changes during code slush...
- The mouse seems to fail during heaving IDE activity, such as when I do
a release build and the /usr/ports/distfiles gets copied.  This is a
high throughput situation, it's possible that the IDE code is now
hogging the interrupt.  When the mouse gets confused 'systat -vmstat'
shows a sustained rate of about 100KB/transfer.
- I do have a 'cursed' VIA 686b motherboard, which has caused mucho
problems (like silent disk corruption) in the past until I found a bios
(from Brazil!) that fixed it.  This problem may only occur on machines
like mine, but I did not have a problem until recently.

Sorry to make so much noise right now, I just know that things like this
tend to get fixed -right after- the release when a bigger population
actually uses the system.

- Mike H.

On Sat, 2003-10-25 at 13:12, Murray Stokely wrote:
> On Thu, Oct 23, 2003 at 09:46:31AM -0700, Mike Harding wrote:
> > I think that maybe the new ATA drivers are staying in the interrupt a
> > bit longer and causing data to be dropped.
> > 
> > I have reverted to 1-sep -STABLE and it seems stable (so far), I am
> > going to try a new -STABLE and look at the interrupt counts.
> > 
> > The -STABLE ATA drivers were MFC'd - after this merge I see the
> > following comment for a commit on ata-dma.c (revision 1.122)
> > 
> > ...
> > "This pushed the time spent between starting the ATA command and
> > starting the DMA engine over the hill for some controllers
> > (especially the Silicon Image DS3112a) and caused what looked
> > like lost interrupts."
> > 
> > - so possibly we need another MFC... ?
> 
> I think maybe we do.  Unfortunately Soeren is not working on ATA in
> -stable.  Is there anyone else (a committer?) who can verify that this
> analysis is correct?  Can we circulate a patch?
> 
>   - Murray