[1008] in linux-scsi channel archive
Re: more scsi errors :(
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Sun Nov 24 06:05:51 1996
Date: Sun, 24 Nov 1996 13:03:13 +0000 (GMT)
From: Gerard Roudier <groudier@club-internet.fr>
To: Jon Lewis <jlewis@inorganic5.fdt.net>
cc: ncr53c810@colorado.edu,
Linux SCSI Mailing List <linux-scsi@vger.rutgers.edu>
In-Reply-To: <Pine.LNX.3.95.961123154311.174A-100000@inorganic5.fdt.net>
Jon,
On Sun, 24 Nov 1996, Jon Lewis wrote:
> In my news server running 2.0.25 with a pair of NCR 810's using the BSD
> ported driver, I just noticed these in the kernel message buffer.
Dir entries corruptions come back.
This problem has been reported and debated severall months ago.
The real cause have not been found.
It seems to me that same problem has been reported with another
controller family.
> EXT2-fs error (device 08:31): ext2_find_entry: bad entry in directory
> #757318: rec_len % 4 != 0 - offset=1552, inode=3941569338, rec_len=43694,
> name_len=16580
>
> The device in question is:
> /dev/sdd1 2399101 1788717 590384 75% /var/spool/news/alt
>
> It's the majority of a Micropolis 3243-19MZ Q4D Rev: HT02. I used to get
> errors in the news server fairly frequently, so I talked the boss into
> blowing a fortune on Granite Digital SCSI cables which are supposed to be
> the best (probably just most expensive) cables money can buy. After
> installing them, I saw no problems that I can recall...until this.
It was gurus's diagnostic. Obviously excellent cables must be tried if it
was possible for you to buy such expensive things.
I remember that my opinion was that cable quality was only one
possibility among lots of possible causes.
The problem with people who know everything is that they probably do not. :)
> At this point, the problem is almost definitely not cable related.
> Termination is passive on the 810 but active on the other end via a DEC
> DSP5300S at the end of this channel. I suppose I could improve things by
Hmmm... It is probably not the source of the problem, but expensive high
quality cables with mixed active and passive terminators .....
Some 810 controllers have active termination, why to not replace controllers,
or use a hard disk with active termination at each end of the bus?
> removing the card's terminators and put an active terminator on the card's
> external connector. Anyone know what kind of terminators Buslogic uses?
> I'm getting close to wanting to start over and build a new news server on
> wide or ultra SCSI with more spool anyway...if only we had the $$.
Expensive boards use active terminators even when they are obsolete (1542).
But some cheap boards have active terminators. My Tyan S1365 (about $120
including VAT) use a NCR53C825 (Wide) and have active terminators.
I read that ASUS SC200 (at least some models) too.
Ultra SCSI data transfers are a lot more sensitive to devices and bus flaws.
If you intend to upgrade for very fast scsi solutions, it is probably
better to buy Ultra Wide components. 20 MB/sec Wide SCSI-2 is very
probably easier with "normal quality" scsi components that 20 MB/sec Ultra
Narrow scsi. And if 40 MB/sec Ultra Wide works, it will be a lot better.
About $$:
- Hard disks models are about the same price with Ultra Narrow and Ultra
Wide connector.
- Ultra Wide controllers are just a little more expensive than Ultra
Narrow ones.
- If one have problems of scsi bus with 10MHz/sec data speed, Ultra SCSI
data transfers will have every chance to not work at all.
> I'm a bit confused by the messages...especially inode=3941569338. I have
> a lot of inodes...but not that many.
File system drivers check inode entries integrity in data buffer prior to
get informations from those entries.
This message displays what has been found in the buffer where a good
inode number was expected. If data is corrupted at the corresponding
offset, the value is just a 32 bit integer value that may have nothing to
do with a possible inode number value.
I will now try to retrieve articles about this ext2 dir entry problems,
and reply to you as soon as I have a new idea or new information.
[ ... lines deleted, but read with attention and archived ...]
Gerard.
