How much memory is in the system, when did it panic (relative to boot up),
and where there any other messages? FWIW, this message means that the
driver couldn't get any memory when it needed it (a GFP_ATOMIC allocation in
aic7xxx_allocate_scb() ). The question is, why was it allocating memory?
Are you sure the reset hadn't already completed and the driver was just
getting ready to start things going again when this happened? That would
make a certain amount of sense if the full possible number of SCBs needed at
one time had not already been allocated. Specifically, if the mid level
SCSI code had queued all the commands up for a re-try, then released them
into the low level driver en-masse, then it could use a higher number of
commands than before due to the simple fact that none of the commands would
complete for a certain period of time and in that lag, all of the commands
actually become active where as usually there are some active, some in
the process of becoming active, etc. If there was no memory when the
commands all got released en-masse, then this could indeed create a problem.
As it stands, I'm planning on doing something to change that problem in my
next patch, but haven't gotten around to it yet (scb pre-allocation at
startup based on devices found). It doesn't usually effect systems because
they usually have *all* of their SCBs allocated before any timeouts might
occur (if the timeouts ever do occur, which tends to be very device
specific). In your case I would guess there was a timeout/reset cycle
fairly soon after bootup and that the devices had not been pushed very hard
up to that point resulting in only a partial allocation of SCBs prior to the
reset, and an attempt at full allocation (or at least a larger allocation)
after the reset when no memory was available.
----------------------------------
E-Mail: Doug Ledford <dledford@dialnet.net>
Date: 17-Dec-97
Time: 06:04:23
----------------------------------