--/2994txjAzEdQwm5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >=20
> > 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".
>=20
> They were silo overflows - which is why I suspect other ISR an/or splhi().
> And why it would be tricky to debug them...
>=20
> (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=
=20
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.

Take care,

Bill

--/2994txjAzEdQwm5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEl1M4Wz+3JHUci9cRAkwsAJ4jpOgBUH61pka0EL5YUVnbxCkHagCfWZXG
Um5YXHGNhWjHerZtiw+yNbc=
=4yzb
-----END PGP SIGNATURE-----

--/2994txjAzEdQwm5--