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.021 / U:0.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site