From owner-freebsd-scsi Fri Dec 3 9:45:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id AD63F1504A; Fri, 3 Dec 1999 09:45:21 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id KAA11671; Fri, 3 Dec 1999 10:33:26 -0700 (MST) Date: Fri, 3 Dec 1999 10:33:26 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199912031733.KAA11671@narnia.plutotech.com> To: Mike Smith Cc: scsi@FreeBSD.ORG Subject: Re: Tape driver problems X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199912030632.WAA05573@mass.cdrom.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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