Date: Tue, 10 Mar 1998 09:30:45 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Matthew Thyer <thyerm@camtech.net.au> Cc: Mike Smith <mike@smith.net.au>, current@FreeBSD.ORG, Nate Williams <nate@mt.sri.com> Subject: Re: silo overflows (Was Re: 3.0-RELEASE?) Message-ID: <XFMail.980310093045.shimon@simon-shapiro.org> In-Reply-To: <350527AA.3139AD63@camtech.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-Mar-98 Matthew Thyer wrote: > My silo overflows seem to have disappeared. > > Unfortunately I've just changed 4 things at once! > > - I recompiled XFree86 3.3.1 (NOT 3.3.2) recently (whilst running a > system built from CTM src-cur.3261 [Feb 23] sources) That's not it here, No X at all and still silo overflows... > - I've just made the world at CTM src-cur.3281 [8 Mar 1998 23:07:21 -0800 > (PST)] That could be it > - I've turned on SoftUpdates on all but the root fs. ?? > - And I've taken Option "pci_retry" out of my /etc/XF86Config file. ** Again, sounds like X11 related. The problem may be agravated, or even manifested, by X11, but I have it regardless of X11. > > Did anyone change anything that could stop silo overflows between > CTM src-cur.3261 and CTM src-cur.3281 ? > > ** Personally I think this is the key but have not the time to try > it now (ie I am downloading XF86 3.3.2 in an xterm and thus cant > restart X for a while). I built XF86--3.3.2, XFSetup does not link, has lots of tk/tcl undefined stuff. When it is installed, it does funny things with interrupts; mouse events seem to be generated out of thin air. Because I get the silo overflows consistently, without any X11 on the machine, I doubt X11 is key to this. From Mike's excellent overview of interrupts, it is pretty clear that an interrupt is leaking someplace. I ALWAYS see this silo overflow associated wit ha DPT lost interrupt; Some time ago (several months) I noticed that the DPT driver is not getting certain interrupts. I simply did not get them. It was not a case where I receive them and not proces them. At first I suspected the hardware. It happens, under SMP, on two drastically different motherboards. I added a simple timer to the DPT driver that occasionally wakes up and checks the hardware for posted interrupt. If I find one, I process it and complain. I always get a silo overflow when using PPP. It always happens with a DPT lost interrupt recovery. Not every DPT lost interrupt recovery has an sio.c silo overflow, but every silo overflow has a DPT lost interrupt associated with it. Probably a race condition in interrupt handling. If X11 causes the video card to generate interrupts, this is our clue; A video card can generate interrupts very quickly. So can a DPT; Less than 2us between interrupts is not unusual. For all it's worth; Fast Interrupts remind me of Linux interrupts; You shutdown all interrupts, etc. Linux chronically loses interrupts. If you block all interrupts, there simply is no way to guarantee you will not lose one. This is how I understand it. I am probably wrong. Simon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980310093045.shimon>