Subject: Re: com rumblings...
To: Garrett D'Amore <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/19/2006 18:45:28
Content-Type: text/plain; charset=us-ascii
On Thu, Jun 15, 2006 at 09:10:42PM +0100, David Laight wrote:
> On Thu, Jun 15, 2006 at 12:54:53PM -0700, Garrett D'Amore wrote:
> > I need to verify what we are seeing though -- is it a hardware FIFO
> > overrun, or the ring buffer filling up? com(4) shows hardware fifo
> > overflows as "silo overflows" and ring buffer fills as "ibuf floods".
> They were silo overflows - which is why I suspect other ISR an/or splhi().
> And why it would be tricky to debug them...
> (The 'easy' way is to connect the IRQ line from the UART to a logic
> analiser timing port, set it to trigger on the signal being active
> for > some_time, connect the trigger-out of the analiser to the systems
> NMI line, and use the NMI to enter ddb, then look at the traceback.)
Actually, mac68k has seen the same issue. I've seen anticdotal problems=20
springing up in the 1.5/1.6 time frame.
Another way to test this is to instrument splx() so that it remembers the=
IPL it is dropping from. Then when you see an overflow, you ask the IPL=20
code what level splx last left, and you know what IPL is your issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----