Messages in this thread | | | Date | Tue, 27 Jul 1999 22:37:44 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: Problem w/ 2.2.10-ac12 & NCR53c875 |
| |
Well,
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/
| |