Date: Sun, 26 Oct 2003 09:59:48 -0800 From: Mike Harding <mvh@ix.netcom.com> To: Murray Stokely <murray@FreeBSD.org> Cc: sos@FreeBSD.org Subject: Re: Possible mouse/ATA problems in -STABLE Message-ID: <1067191188.18799.58.camel@netcom1.netcom.com> In-Reply-To: <20031025201245.GD17410@freebsdmall.com> References: <20031023141503.4004C53C7@netcom1.netcom.com> <20031023092157.M79600@carver.gumbysoft.com> <1066927591.724.8.camel@netcom1.netcom.com> <20031025201245.GD17410@freebsdmall.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1067191188.18799.58.camel>