silo overflows -- what can I do about this?

[Joseph Garcia]

Matthew Dillon wrote:
:It's just a serial console cable to a cisco device. It's a PIX in this 
:case. I'm using the cisco supplied blue roll over cable. Pretty much 
:normal. It seems to work fine when using my notebook.
:
:So it can either be a) the hardware on the DragonFly box, or b) 
:something in DragonFlyBSD. The notebook runs FreeBSD. I'm almost curious 
:enough to yank the hardrive out of the OpenBSD box (another box where it 
:works fine too) and put in the DragonFlyBSD hardrive to rule out the 
:hardware.
:
:I can do that if you want, that way we don't chase things that are 
:hardware related. You know what I mean?
:
:Joey

    It sounds to me like an interrupt is getting delayed too long.  It
    is possible to track things like that down, but it's a lot of work
    and I don't think I can spare the time (at least not before the next
    release).  Is this a SMP box?
					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>
No worries if you can't fix it. I was able to allow telnet login (yeah, 
I should use ssh, but it's just a test device) so I just not login via 
the network.

Maybe I should have mentioned it before, but I use 'cu' with the 
following command:

cu -l /dev/cuaa0 -s 9600

It connects and I can log in and enter commands. The problem pops up 
when receiving a lot of data quickly from the device (i.e. when I'm 
writing the configuration to the terminal).

I probably should have mentioned that earlier.

By the way, it's not an SMP box. The dmesg was posted earlier in case 
you might have misssed it. It's on older SMP PIII box that seems to run 
well otherwise.

Thanks for at least trying to see what the problem was. I'm still 
curious to see if it's just a hardware bug and not a software bug. When 
I have time I'm gonna swap the drives with to check (i.e. using a 
different drive with a different OS on this box to test if hardware bug 
or software bug).

Joey