Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Dec 1999 10:33:26 -0700 (MST)
From:      "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
To:        Mike Smith <msmith@FreeBSD.ORG>
Cc:        scsi@FreeBSD.ORG
Subject:   Re: Tape driver problems
Message-ID:  <199912031733.KAA11671@narnia.plutotech.com>
In-Reply-To: <199912030632.WAA05573@mass.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <199912030632.WAA05573@mass.cdrom.com> you wrote:
>> > On Thursday, 2nd December 1999, Mike Smith wrote:
>> > 
>> > >Either the aha code needs to be fixed to allow more s/g entries, or the 
>> > >bounce buffer code needs to be fixed to allocate things in larger chunks 
>> > >and thus keep fragmentation down, or we should just abandon these useless 
>> > >10-year-old ISA SCSI controllers and worry about more useful things. 8)
>> > 
>> > Well, I'm for changing the buffer code or the aha code, whichever makes
>> > the most sense at the time.  Unfortunately I don't know that bit of the
>> > kernel yet.  But I will eventually work it out because I have too many old
>> > ISA SCSI cards to take you up on your last suggestion.
>> 
>> See other mail. I still believe that the AHA driver should work better,
>> but it's a low priority item now.
> 
> This particular issue is a defect in the bounce-buffering code; the 1542 
> is limited to 16 or maybe 17 s/g entries.  (We allow 17, the Linux driver 
> stops at 16.)  This isn't an issue for most things until you get up near 
> 64k, where fragmentation lets you run out of page-sized entries.  I'm not 
> sure how best we could work around this without clustering pages in 
> bounce-buffer memory.  If you've got any neat ideas I'll happily file 
> them for next time someone goes looking at that code.

The bounce buffering code doesn't perform coalessing of data yet because
I never found an algorithm I liked for it.  The NetBSD approach of
making the bounce buffer 64K big and copying the whole thing if any
portion needs to be bounced doesn't appeal to me (it doesn't scale
well and consumes much too much memory).  Still, I'm surprised
that this is the cause of this particular failure.  A kernel malloc
of 64K should return a page aligned chunk of memory.

--
Justin


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912031733.KAA11671>