Subject: Re: mesh timeout errors on 9500
To: Michael <macallan18@earthlink.net>
From: Riccardo Mottola <rollei@tiscalinet.it>
List: port-macppc
Date: 10/25/2004 01:39:06
Michael wrote:
> 
> Hello,
> 
> > somebody else suffers from
> >
> > mesh0: timeout state 3
> > mesh: resetting DMA
> I don't ( well, I have a S900, but that's more or less a modified 9500 )
> 
> > I think I already mentioned this once... The disk is correctly
> > terminated (and obviously connected to the internal controller). I have
> > 2 disks, cone macos and one NetBSD. I disovered that by swapping the two
> > disks and so making the NetBSD one closer to the beginning lesses the
> > frequencies of those errors, making the box almost usable...
> Definitely sounds like a cable problem - effects like this shouldn't happen if the bus is properly terminated and not too long. Did you try different cables?

no, this is the internal cable of the 9500, never touched it.
I enabled the internal scsi termination of the disk. It has enevr
givenme problems with other os's..

I assume mesh = internal controller right? I have nothing attached to
the external port.

> 
> > I experience something very similar on Mac68k, using plain 1.6.2: on a
> > very full scsi chain (which works perfectly under macOS amd even Linux)
> > netbsd reports errors as hell on disk, even if I use a high-grade active
> > termination. making the disk the only external disk (well, the box has 1
> > scsi bus anyway) lessened the problem. So the explanation that the "68k
> > scsi driver is buggy" might not be that satisfactory.
> Hmm, I have an SCA Barracuda (with adaptor) a ZIP drive and a CDROM connected to the mesh - I've never seen anything like that in normal operation. Even had two disks on it a while ago to move data around - still no problems. The S900 spent the last two days compiling loads of stuff from pkgsrc without errors so I guess mesh can be considered stable for me.

> Did you change the flags field in the kernel config? ( mesh0 at obio? flags 0xffff or so ) ? As far as I know these flags disable synchronous data transfers for all targets, I had all sorts of weird problems - pretty similar to yours - when I changed them. I've asked on this list what's wrong with the mesh driver and why we have to bog it down like that but didn't get any answer.

I did not touch those flags, they are... as in the precompiled kernel. I
will watch dmesg closer to see if some useful output is printed aout
sync/async.

-Riccardo