To people that still persist in running their ALpha machine with a
SYM53C8XX chip under a pyxis-broken kernel version without having reversed
the pyxis changes, I say:
*$?!*$^£*%!;?.!! *%$+%^;?,!"! because I want to stay polite. :-)
but I think they donnot deserve to own an Alpha machine. ;-)
If they still want to waste their time, they may consider the following
and definitely the last informations from me that address the problem:
The latest 1.5d sym53c8xx driver should not perform PCI master mastering
at all for Alpha. By the way, this driver version has been qualified by
SYMBIOS themselves on Intel an Alpha.
My current patch series is broken for 2.2.10 and later 2.2 kernels, due to
patches that went directly to kernel tree and 1.5 series is not candidate
for 2.2, at least for the moment. If you want this driver for 2.2, you may
try the following:
1. Patch a fresh 2.2.9 and save drivers files using:
ftp://ftp.tux.org/pub/roudier/drivers/linux/experimental/patch-ncr53c8xx-1.5d-2.2.9.gz
2. Patch your 2.2.10*. You will get rejects for some driver
files.
3. Just ignore rejects, but restore the saved driver source files.
It takes 2 minutes for that.
If 1.5d fails with the pyxis changes, there is something I just missed
regarding the problem I am for sure unable to guess.
You also can apply the 1.3g patch I recently sent to the list for linux
stable (2.2.11-pre3) and remove manually from the sources the define of
SCSI_NCR_PCI_MEM_NOT_SUPPORTED for Alpha (read comments from the sources).
This driver will also not perform PCI self mastering any more with this
change (there are comments about this topic in the source). If this one,
with the define removed, also fails, then I missed something about the
problem, I am for sure unable to guess.
For the 860, all sym53c8xx drivers since day one donnot perform PCI self
mastering for the reason that this driver only uses LOAD/STORE SCRIPTS
intructions from/to memory to/from IO registers (and not MOVE MEMORY) and
this chip does not have on-chip RAM. This makes sym53c8xx+860 immune of
any breakage due to PCI self-mastering since day one of the sym driver.
Self mastering only occurs when loading the on-chip RAM or accessing the
on-chip RAM from SCRIPTS on sym53c8xx driver versions that donnot have the
appropriate changes. (Btw, the 875 has on-chip RAM)
As I wrote, the generic ncr53c8xx needs to perform PCI self-mastering to
access its IO registers in order to support earlier chips (all generic
drivers on the planet for the SYM53C8XX rely on this feature). So this
driver must be affected by the pyxis changes and just fail the CACHE TEST
check even with the 860.
On the other hand, it seems that the core_pyxis changes donnot have the
same effect on all pyxis-as platforms. And as I wrote many times, I am
an Alpha-ignorant and donnot have an alpha platform.
Normally, all SYM53C8XX chip driven (and supported) by any sym53c8xx
driver versions should succeed the CACHE TEST checkings on 2.2.10-* since
these checkings use only LOAD/STORE from/to memory to/from IO registers
that donnot involve any self-mastering. But they will not survive to be
jumped into the on-chip RAM, since the move of data assumed to hit the
on-chip RAM may have gone to hell, due to the pyxis changes.
-------
THE END (until august the 16th)
-------
Gérard.
On Tue, 27 Jul 1999, Dumb Kid wrote:
> We have an alpha w/ NCR53c860 boots fine on
> 2.2.10-ac12 without any modification.
>
> It might only affect ncr53c875 adapters.
>
> sym53c8xx: at PCI bus 0, device 9, function 0
> sym53c8xx: 53c860 detected with Symbios NVRAM
> sym53c860-0: rev=0x02, base=0x19000000, io_port=0x8800, irq=19
> sym53c860-0: Symbios format NVRAM, ID 7, Fast-20, Parity Checking
> sym53c860-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/ce/a0/00/00/00
> sym53c860-0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/ce/a0/00/08/00
> sym53c860-0: resetting, command processing suspended for 2 seconds
> sym53c860-0: restart (scsi reset).
> ncr53c8xx: at PCI bus 0, device 9, function 0
> ncr53c8xx: IO region 0x8800 to 0x887f is in use
> scsi0 : sym53c8xx - version 1.3c
> scsi : 1 host.
> sym53c860-0: command processing resumed
> Vendor: SEAGATE Model: ST34555N Rev: 0930
> Type: Direct-Access ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
> sym53c860-0-<0,0>: tagged command queue depth set to 8
> scsi : detected 1 SCSI disk total.
> sym53c860-0-<0,*>: FAST-20 SCSI 20.0 MB/s (50 ns, offset 8)
>
>
>
> >From: Gerard Roudier <groudier@club-internet.fr>
> >To: Ed Hall <edhall@screech.weirdnoise.com>
> >CC: Dumb Kid <dumbkid@hotmail.com>, linux-kernel@vger.rutgers.edu,
> >linux-scsi@vger.rutgers.edu
> >Subject: Re: Problem w/ 2.2.10-ac12 & NCR53c875
> >Date: Tue, 27 Jul 1999 19:45:12 +0200 (MET DST)
> >
> >
> >
> >On Mon, 26 Jul 1999, Ed Hall wrote:
> >
> > > > I am having trouble getting the 2.2.10-ac12 to boot. My system
> > > > is alpha LX164 w/ NCR53c875.
> > >
> > > I noticed this with 2.2.10-ac11. Reverting
> >"arch/alpha/kernel/core_pyxis.c"
> > > to the original 2.2.10 file fixes it for now. I'm sure a more
> > > permanent fix will be appearing shortly from Alan Cox and from the
> > > tireless Alpha contingent.
> > >
> > > The problem is a mismatch between where various patches assume the PCI
> > > windows are located, and not the SCSI driver itself.
> >
> >And, in case of people would ignore it, I have had to diagnose the problem
> >by myself and I donnot have an Alpha machine, neither really know of the
> >Alpha stuff, since the solution was very slow to come.
> >The solution is known since almost a week, and I didn't see any official
> >fix for it posted to the lists by the maintainers of the offending code.
> >
> >If the reason is that this bad changes in the pyxis_core stuff only affect
> >the sym53c8xx devices and only on Alpha machines and thus guys think it is
> >not important, then they just appear as not interesting people to me. I am
> >wondering about what would have happened facing a bad change that affected
> >also (or only) Adaptec devices on Intel platforms.
> >
> >Gérard.
> >
>
>
> _______________________________________________________________
> Get Free Email and Do More On The Web. Visit http://www.msn.com
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/