New alpha 5.x bug

[Bernd Walter]

On Tue, Nov 04, 2003 at 11:18:26PM +0100, Wilko Bulte wrote:
> On Tue, Nov 04, 2003 at 11:12:51PM +0100, Bernd Walter wrote:
> > On Tue, Nov 04, 2003 at 09:55:52AM -0800, Kris Kennaway wrote:
> > > On Tue, Nov 04, 2003 at 01:48:27PM +0100, Bernd Walter wrote:
> > > > I can't speak for this problem yet, because my test systems are a bit
> > > > older, but speaking for the pipe corruption:
> > > > I did a lots of bzip1, tar, scp, nfs(client) without noticing any
> > > > sign of problem.
> > > > What is so special with the port cluster?
> > > > I have no clue about it's design.
> > > 
> > > It does lots of parallel package builds (untar, pkg_add, compile, tar) and NFS copying.
> > 
> > Any special NFS options?
> > tcp, udp, v2, v3, IPv4, IPv6?
> > 
> > Just to get the picture complete.
> > The build is local and the package is then copied to a NFS server on
> > which t has a corrupted CRC?
> > Is the bzip2 CRC wrong, or the tar CRC (does tar have a CRC?), or both?
> > Can you say how likely such a corruption is?
> > Are other packages compiled during copying a package file to the server?
> > Are the building machines memory stressed while creating the bz file or
> > while copying it?
> 
> Hmmm.. the package builders are Miatas right? 
> 
> Are they using a PCI add-in ethernet card?
> 
> I'm thinking of the Miata's rather fragile DMA stuff in the Pyxis
> core logic chip.

This is on one of my NFS servers:
[53]cicely9# uptime
11:38PM  up 73 days,  2:49, 4 users, load averages: 0.03, 0.02, 0.00
[54]cicely9# uname -a
FreeBSD cicely9.cicely.de 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Aug 23 03:25:04 CEST 2003     ticso at cicely9.cicely.de:/var/d2/obj/var/d7/builder/FreeBSD-2003-08-22-cicely9/src/sys/CICELY9  alpha

The system is a PC164 with a 3COM 3C905B (xl) card and has a lot of
NFS load.

Isn't the chipset the same as in miatas?
One importent difference is that PC164 systems still run with a
hack for blocking interupts, which effectively block more interrupts
then actually required and therefor massively reduce IO concurency.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso at bwct.de                                  info at bwct.de