Re: pg_clog woes with 7.3.2 - Episode 2 - Mailing list pgsql-hackers

From Dave Page
Subject Re: pg_clog woes with 7.3.2 - Episode 2
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B83AF047@mail.vale-housing.co.uk
Whole thread Raw
In response to pg_clog woes with 7.3.2 - Episode 2  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: pg_clog woes with 7.3.2 - Episode 2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 17 April 2003 04:40
> To: Kevin Brown
> Cc: pgsql-hackers@postgresql.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.



pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: pg_clog woes with 7.3.2 - Episode 2
Next
From: "Dave Page"
Date:
Subject: Re: Many comments (related to "Are we losing momentum?")