Hello,
> [ ... ]
> > I will test again with "#define PDC_MAXLASTSGSIZE 32*4" (just to see
> > if that makes a difference)
> >
> One thing to try is to loose any geom raid, if raid needed use ataraid
> instead.
Nope : i did a "newfs ad6" (the disk at the Promise TX4) and then an
rsync on it panic
Arno J. Klaassen wrote:
definitely an improvement, but not sufficient (for my setup ) :
amd64-releng_6 on an ASUS A8V UP (box ran rock-stable
for years i386-releng_5 with same hardware apart TX4 and
drives)
from dmesg :
atapci0: port 0xe000-0xe07f,0xd800-0xd8ff
mem 0xfbb0-0xfbb00fff,0xfb
Alexander Sabourenkov <[EMAIL PROTECTED]> writes:
> Arno J. Klaassen wrote:
> > definitely an improvement, but not sufficient (for my setup ) :
> >
> > amd64-releng_6 on an ASUS A8V UP (box ran rock-stable
> > for years i386-releng_5 with same hardware apart TX4 and
> > drives)
> >
> > from dmes
On Fri, 2 Nov 2007, 12:59-0500, Mark Tinguely wrote:
>
> Since eyeballs are in swap_page.c - is the putpages panic string mislabeled:
>
> swap_pager_putpages(vm_object_t object, vm_page_t *m, int count,
> boolean_t sync, int *rtvals)
> {
> int i;
> int n = 0;
>
> if (co
Arno J. Klaassen wrote:
> definitely an improvement, but not sufficient (for my setup ) :
>
> amd64-releng_6 on an ASUS A8V UP (box ran rock-stable
> for years i386-releng_5 with same hardware apart TX4 and
> drives)
>
> from dmesg :
>
Setup is identical to mine, except for the drives.
http://l
Since eyeballs are in swap_page.c - is the putpages panic string mislabeled:
swap_pager_putpages(vm_object_t object, vm_page_t *m, int count,
boolean_t sync, int *rtvals)
{
int i;
int n = 0;
if (count && m[0]->object != object) {
panic("swap_pager_getp
Hello,
Alexander Sabourenkov <[EMAIL PROTECTED]> writes:
> Hello.
>
> I have ported the workaround for the hardware bug that causes data
> corruption on Promise SATA300 TX4 cards to RELENG_7.
>
> Bug description:
> SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is
> larger th
On Thu, Nov 01, 2007 at 10:40:04AM +1100, James Healy wrote:
>The remaining op is not easily converted to fixed point math, and we're
>wondering what impact a single flop on the receipt of each ACK will
>have. We don't have a strong understanding of the amount of overhead
>involved in executing a f
On Thu, Nov 01, 2007 at 08:53:39AM -0700, David O'Brien wrote:
> On Thu, Oct 18, 2007 at 02:04:21AM +0400, Yar Tikhiy wrote:
> > On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote:
> > > I guess I'm not creative enough in the ways I've screwed up my systems
> > > and needed tools from /r
Søren Schmidt wrote:
Søren Schmidt wrote:
Good catch!
However from my quick glimpse at the Promise sources the limit seems
to be 32 Dwords ie 32*4 = 128bytes.
Please see driver named 4_sataii150-300_linux2.6-src_x86-64_v1.01.0.23
I'll investigate further and ask Promise for the gory details
Søren Schmidt wrote:
Good catch!
However from my quick glimpse at the Promise sources the limit seems
to be 32 Dwords ie 32*4 = 128bytes.
I'll investigate further and ask Promise for the gory details, stay
tuned...
I dont think the PRD count limitation is a real problem, I've newer
seen that
Alexander Sabourenkov wrote:
Hello.
I have ported the workaround for the hardware bug that causes data
corruption on Promise SATA300 TX4 cards to RELENG_7.
Bug description:
SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is
larger than 164 bytes. This was found while analysing
12 matches
Mail list logo
