lkml.org 
[lkml]   [1997]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Kernel Panic: aic7xxx_free
Date
From
--------
> 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. *
*****************************************************************************



\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.037 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site