Hi there,
On Sat, Apr 03, 2004 at 10:19:51AM +0300, Kai Makisara wrote:
> On Fri, 2 Apr 2004, Christoph Hellwig wrote:
>
> > [linux-scsi is the right list for st problems, moving the thread there]
> >
> > On Fri, Apr 02, 2004 at 03:13:55PM +1000, Nathan Scott wrote:
> > > Hi all,
> > >
> > > I'm seeing a bunch of large allocation attempts failing from
> > > the SCSI tape driver when doing dumps and restores ... (this
> > > is with a stock 2.6.4 kernel).
> > >
> > > xfsdump: page allocation failure. order:8, mode:0xd0
> > > Call Trace:
> > > [<c013982b>] __alloc_pages+0x33b/0x3d0
> > > [<c03805ac>] enlarge_buffer+0xdc/0x1b0
> > > [<c03819a3>] st_map_user_pages+0x33/0x90
> > > [<c037cf24>] setup_buffering+0xb4/0x160
> >
> > This looks like the driver tries to pin down the userpages first
> > (st_map_user_pages) but then fails and needs to use an inkernel
> > buffer. Can you put some debug printks into st_map_user_pages
> > to see why it fails?
Apologies for the delay; after whacking in some printk's it looks
like the point st decides to not pin down the user pages for me is
here in sgl_map_user_pages:
/* Too big */
if (nr_pages > max_pages) {
return -ENOMEM;
}
In my cases nr_pages is always 256 and max_pages is always 96 (I
see this printk a fair few times, and its always from this point).
> Pinning down pages should not fail with most modern hardware except for
> the following three cases:
>
> 1) A change in 2.6.4 (*) mandates st (and sg) not to use direct transfers
> unless the user buffer is aligned at 512 byte boundary. This means, for
> instance, that in most cases transfers from/to malloced/calloced buffers
> are forced to use bounce buffers (alignment at 8 or 16 byte boundaries).
>
> 2) There is a bug in checking the allowed address range. Most SCSI
> adapters support 64-bit addresses and so even lots of memory should not
> prevent using direct transfers.
I guess its not either of these two, from the printk?
> 3) Some resource shortage that happened just now. This is not a bug.
Hmm... I see this alot, but I have a fair bit of memory in the machine
(its during stress and regression testing that I hit this, so not sure
about the exact memory usage at each particular printk I see).
Is this something we should be tuning in xfsdump/xfsrestore, Kai?
(to make smaller requests?)
cheers.
--
Nathan
|