Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Apr 2008 14:42:22 +0200
From:      "Niclas Zeising" <niclas.zeising@gmail.com>
To:        "=?ISO-8859-1?Q?S=F8ren_Schmidt?=" <sos@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/dev/ata ata-all.h ata-chipset.c ata-dma.c ata-lowlevel.c
Message-ID:  <bc292860804150542w524995b2p6255da691d20f5cd@mail.gmail.com>
In-Reply-To: <1DFDA463-5E5E-4EE5-BF2D-E738D10E57F7@FreeBSD.org>
References:  <200804141834.m3EIYOXP044870@repoman.freebsd.org> <4803D34C.4030706@gmail.com> <1DFDA463-5E5E-4EE5-BF2D-E738D10E57F7@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 15, 2008 at 2:28 PM, S=F8ren Schmidt <sos@freebsd.org> wrote:
> Hi
>
>  Thats actually a separate problem. I've put in stops to check that the P=
RD
> table size doesn't get out of hand. Until now that wasn't a problem but n=
ow
> that we move to having more than on request flying pr channel it needs to=
 be
> within bounds.
>  The check correctly panic's as we outgrow the table, however thats not v=
ery
> usefull :)

Not really, no ;)
Just a (perhaps silly) question, is my hardware wierd as no-one else
has reported this problem (as I've seen anyway). I'm just curious.

>
>  Fix coming up with the next round of updates, I also need to go back to =
the
> old way of preallocing the SG tables etc, busdma is simply too cycle gree=
dy
> to be called for each request, as performance has been shown to decrease
> quite a bit.

Okay. I'll sit tight and wait for the fix. If you need some testing
just drop me a note. Thanks for the quick reply!

>
>  -S=F8ren
>
>

[SNIP old messages]

Regards!
Niclas



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