DragonFly users List (threaded) for 2006-10
Re: silo overflows -- what can I do about this?
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
:I can do that if you want, that way we don't chase things that are
:hardware related. You know what I mean?
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?
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
Maybe I should have mentioned it before, but I use 'cu' with the
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
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).