Re: pg_clog woes with 7.3.2 - Episode 2

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kevin Brown" <kevin(at)sysexperts(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_clog woes with 7.3.2 - Episode 2
Date: 2003-04-17 07:40:19
Message-ID: 03AF4E498C591348A42FC93DEA9661B83AF047@mail.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 17 April 2003 04:40
> To: Kevin Brown
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] pg_clog woes with 7.3.2 - Episode 2
>
>
> Considering that, I would bet a good deal that the problem is
> some kind of transfer timing error in some chunk of hardware
> that copies the data 64 bytes at a time. I withdraw my
> previous thought that it might be cabling --- there are no
> 64-byte-wide SCSI cables. It could easy be internal to the
> SCSI adaptor though.

I've now tried a 29160 and a 29160N both exhibiting the problem. I also
have a 29160 in the existing server I'm trying to replace and that works
fine.

> If his motherboard is high-end enough
> that the DMA path from adaptor to memory is 64 bytes wide,
> then DMA timing errors would be a possibility too.

This is a relatively low-end Gigbyte dual PIII board - GA6-VTXD rev 1.0.
Again, I have more of these that are working fine (though aren't running
PostgreSQL).

Do you think it's worth trying the older kernel that I know works? Could
a bug in 2.4.20 give this sort of error?

Regards, Dave.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2003-04-17 07:45:04 Re: Many comments (related to "Are we losing momentum?")
Previous Message Dave Page 2003-04-17 07:32:40 Re: pg_clog woes with 7.3.2 - Episode 2