From owner-freebsd-hackers Wed Jun 7 05:11:32 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA15957 for hackers-outgoing; Wed, 7 Jun 1995 05:11:32 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA15951 for ; Wed, 7 Jun 1995 05:11:27 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4) id AA28706; Wed, 7 Jun 1995 08:11:25 -0400 Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA20749; Wed, 7 Jun 95 08:09:08 EDT Date: Wed, 7 Jun 95 08:09:08 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9506071209.AA20749@borg.ess.harris.com> To: freebsd-hackers@freefall.cdrom.com Subject: Re: silo overflows Sender: hackers-owner@FreeBSD.org Precedence: bulk Thanks for the info. The only bus hogging DMA I could think of is the 1542CF but it is at the default settings which I thought were safe. My root, usr, and home partitions are on IDE disks(VLB controller). Is there a "cleaner" way to adjust the fifo trigger levels than making another constant like FIFO_TRIGGER_10? perhaps a sysctl or stty option? I will tweek it to 10 for now and see what happens. I wish I could catch it when the this occurs but " a watched port never overflows" ha ha. Hmmm, it just seems strange that a DX4/100 cannot keep up with a 57600 line. Oh, the sio man page still describes the automatic adjusting as enabled is that going to be put back in or was it decided that it was not a good idea? Jim > From owner-freebsd-hackers@freefall.cdrom.com Wed Jun 7 06:43:40 1995 > Date: Wed, 7 Jun 1995 17:36:26 +1000 > From: Bruce Evans > To: freebsd-hackers@freefall.cdrom.com, jleppek@harris.com > Subject: Re: silo overflows > Sender: hackers-owner@freebsd.org > > >I have been seeing a number of silo overflows from a current > >kernel on a DX4/100 32Meg memory running ppp with > >the serial port rate at 57600. I had about 28 overflows > >in about an hour so nothing drastic. > > >I never saw the "reduce trigger" message which I thought > >was suppose to appear when "silo overflow" messages appeared but > >a little looking reveals that > >the reduce stuff seems to be "#if 0" excluded... > >sooo I guess the initial trigger is FIFO_TRIGGER_14 and stays. > > The "reduce trigger" stuff is ifdefed because it doesn't work very > well. On some systems it causes the trigger level to collapse from > 14 to 1 whenever a transient overload occurs. This is undesirable > if transient overloads are very rare. I think the collapse is > from buffering of overflows that occur while the trigger level is > at 14. A trigger level of 8 should be low enough for all systems > that aren't overloaded all the time (such as a 386SX/16 with more > than one port at 115200 bps, or a P900 (sic) with more than 8 > ports at 115200 bps sustained). > > Overruns for low speeds such as 57600 on one port may be caused by > bus hogging DMA controllers. There are two solutions: don't use bus > hogging DMA controllers, or reduce the initial trigger level to 8. > Reducing the trigger level only works for 16550's of course. For > 8250's and 16450's, don't use bus hogging DMA controllers. > > What type of DMA controller(s) do you have? > > >Is the current solution to change the FIFO_TRIGGER_14 > >value in sioreg.h to something lower ? > > No, FIFO_TRIGGER_14 is a constant, not an option. Change the one > place in sio.c where it is used to initialize com->ftl_init. Use > FIFO_TRIGGER_8 instead. > > Bruce >