Messages in this thread | | | Subject | Re: Kernel Panic: aic7xxx_free | Date | Thu, 29 May 1997 14:09:30 -0500 | From | Doug Ledford <> |
| |
-------- > On Wed, 28 May 1997, Doug Ledford wrote: > > > > > Couldn't Get A Free Page ..... > > > > Kernel Panic: aic7xxx_free (aic7xxx_free) Couldn't find a free SCB. > > > > > > I experienced the same problem wit 2.0.30. > > > 2.0.30 brings a lot more i/o performance than version < 2.0.30 > > > AFAIK due to enhancements I've seen in the buffer management. > > > > The enhancement in the buffer management that you speak of has been > > resulting in a *lot* more "Couldn't get a free page..." errors than it used > > to. When these happen at the wrong time....well....you get what we have > > here. In this case, all of the currently allocated SCBs in the aic7xxx > > driver were in use, the mid level SCSI code queued out another command, > > aic7xxx_queue() attempted to allocate another SCB to handle the request, the > > allocation failed with a couldn't get a free SCB message, and the driver > > paniced. It currently doesn't know what to do if it can't get memory for an > > The simple solution here is to increase the numbers in > /proc/sys/vm/freepages, such that your "couldn't get a free page" messages > stop happening. Just echo 3 bigger numbers into that file. Depending on > how much RAM you have available, and how busy the system is, you might > want to reserve a few MB of atomic allocations, just to be safe.
Ahhh, if only that were true :) It helps, no doubt about it, but under the right load conditions I can still cause Couldn't get a free page... errors even with somewhat huge values in the /proc/sys/vm/freepages file and with 64MB of RAM. It almost seems as though things aren't getting flushed properly in the kernel. For instance, running several bonnies simultaneously on several disks I can cause this error. The problem is, I'm writing *way* too much info into the buffer cache for a 10 second delayed write to suffice. Somewhere, the kernel needs to be smart enough to know that if it is filling up buffer cache extremely quick, then it needs to flush things faster. I think that currently, it occasionally misses this situation so you get into a psuedo deadlock situation where you can't write anymore since the buffer cache is full, and the write outs aren't occuring like they are supposed to. I've actually had bonnie psuedo wedge on me under 2.0.30 where the only way to get it going again was to switch over to another vt and repeatedly run sync. That would flush things out and get the kernel going again for a few seconds, then I would have to run sync again. I know that can't be right.
-- ***************************************************************************** * Doug Ledford * Unix, Novell, Dos, Windows 3.x, * * dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician * * PPP access $14.95/month ***************************************** * Springfield, MO and surrounding * Usenet news, e-mail and shell account.* * communities. Sign-up online at * Web page creation and hosting, other * * 873-9000 V.34 * services available, call for info. * *****************************************************************************
| |