Re: Couldn't get a free page

Jason Duerstock (
Mon, 10 Mar 1997 17:44:13 -0500 (EST)

On Mon, 10 Mar 1997, Richard B. Johnson wrote:

> On Mon, 10 Mar 1997, Leonard N. Zubkoff wrote:
> > From: "Richard B. Johnson" <>
> >
> > What #define do I change and were to get some more pages for Disc I/O?
> > I can't write a large amount of data to a raw SCSI device for testing.
> > I use the BusLogic driver. It gets memory for "DMA" from the kernel.
> > It runs out and hangs.
> >
> > The BusLogic driver itself should never hang waiting for DMA memory. The only
> > place it asks for memory after initialization is if it decides to expand the
> > number of CCBs. In that case, it calls with GFP_ATOMIC and should handle not
> > being able to create any.
> >
> > I would think the DMA memory allocations are coming from the SCSI disk driver
> > itself (sd.c). I think there are some magic files in /proc that can reserve
> > more free pages, but I've never tried them.
> Okay. I'll check some more. I am trying to isolate a possible file-system
> problem that occurs with _VERY_LARGE_ files. To isolate specific file-systems
> I am trying to write to a raw SCSI device just to make sure I can read
> what I write, i.e., is it a driver problem instead of a file-system problem.
> So far, I can't write directly to the raw device without a "free-page" hang.
> This may not be a problem in the "real" world because the kernel will get
> a chance to free up FS buffers to make more free pages. However, when I
> don't have the file-system cache, the SCSI interface has got to have
> enough buffers to fill it's cached-write SCB queue.

I notice this happens a lot with mke2fs and large drives.

Usually, the system will un-hang once I make another process start or stop
or do some memory de(allocation).

Other than this, I don't have much information. =/

Jason Duerstock