> I just uploaded ncr53c8xx-2.6i patch to linux.wauug.org/roudier.
> I am currently using this driver version on my personal system:
>
> PII 233 / 64 MB SDRAM / ATI AGP 4MB
> SYM53C810A rev 18 -> Old Tosh 3401B
> SYM53C895 rev 1 -> Atlas I Wide 2.2 GB
> SYM53C875 rev 3 -> 2xAtlas Ultra Wide II 2.2 GB
>
> Using 32 tags for the Atlas'es II under linux-2.0.29.
>
> This driver version works quite fine for me and I am very happy of the
> performances and stability of this driver on my system.
> It is time to stabilize this driver version, since I an intending to buy
> some new high end disk soon. ;-)
>
> If you have a high end SCSI system using SYMBIOS controllers, you will
> help me making things stable by giving this driver version a try and
> reporting me how it behaves for you.
>
> Driver version 2.6i has been tested under Linux-2.0.29 but should work
> the same under linux-2.0.30/31/32/33. Only i386 architecture is supported
> for the moment.
Hi Gerard,
I'm using your 2.6i driver on a 2.0.34pre7 box and I guess I'm giving it a
real test drive :) The machine has 2 ncr 875 controllers and one buslogic
controllers, and a whole bunch of disks, some newer (seagate barracuda 4G)
and some older. I'm still fighting with it to bring it into a stable
state, but this is most probably because of the outdated hardware. It's
also getting a real beating since it's a news server receiving a full
feed.
A few comments and questions:
- 2.6i does not compile as a module. This is a minor problem, you're
missing a second argument to a m_free() call, no big deal since m_free
ignores it anyway. With that fixed, the module compiles and works fine.
- the driver (both 2.6 and 2.5) does not fill in the unique_id field in
the template, which makes it really hard to use scsidev with multiple ncr
controllers. Patch follows:
--- /src/moisil/unpack/linux-2.0.33/drivers/scsi/ncr53c8xx.c Mon Sep 8 18:14:11 1997
+++ ../drivers/scsi/ncr53c8xx.c Tue Jan 20 19:19:48 1998
@@ -4430,6 +4430,7 @@
#endif
instance->irq = device->slot.irq;
instance->io_port = device->slot.io_port;
+ instance->unique_id = device->slot.io_port;
instance->n_io_port = 128;
instance->dma_channel = 0;
#if LINUX_VERSION_CODE >= LinuxVersionCode(2,0,0)
- with the old driver (2.5?) I was getting repeated timeouts from one of
the barracuda's (I have four, two on each ncr, id's 5 and 6). With the new
driver I'm still getting the timeouts, but I'm also getting other messages
from another barracuda on another chain:
ncr53c875-1:6: ERROR (0:98) (1-21-75) (f/35) @ (script 8fc:19000155).
ncr53c875-1: script cmd = 88080000
ncr53c875-1: regdump: da 10 80 35 47 0f 06 0e 03 01 86 21 80 00 41 00.
ncr53c875-1: have to clear fifos.
etc, this happens every few minutes. What does ERROR (0:98) mean, is it
something I should be worried about? Cabling is good, but I suspect that
termination is not up to par on this particular chain, I'll check on it
later.
- I'm also getting other messages which are probably just debugging
left-overs:
ncr53c875-0:5: SIR 18, CCB done queue overflow
ncr53c875-0-<5,0>: ordered tag forced, umap/smap=dffdc9b7/12910001.
ncr53c875-1-<5,0>: ordered tag forced, umap/smap=41e7021b/4167021b.
- a few times the machine rebooted by itself, and once it locked up hard.
The reboots are probably caused by the software watchdog, but it must have
been in a really bad state not to run any userspace programs for over a
minute.
I will check the termination and let you know if anything changes - in
good or in bad. Also, if you want more information about the hardware,
feel free to ask.
Thanks,
Ionut
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu