Re: [parisc-linux] Hanging with kernels >= 2.4.22

[Joel Soete <soete.joel@tiscali.be>]

Riccardo wrote:
> Carlos O'Donell wrote:
> 
>>>Thanks! Changing NCR_700_MAX_TAGS to 1 in drivers/scsi/53c700.h did the
>>>trick. Will I now have poor disk performance? If so, might I get away
>>>with setting it to something higher, like 2 or 4, maybe?
>>
>>I could never run IO stably at anything higher than 1. The drives don't
>>seem to handle it properly, the error recovery mechanisms seem less
>>than perfect, and the box just hangs.
> 
> It really depends on the drive. I have a Fujitsu Enterprise and it has a
> specified tag queue of 128 commands. So if something fails, it is the
> driver or HP's hardware.
> 
> I have a 715 scorpio and when I used ext2 or reiser with a tag queue of
> 16 I had very frequent freezes up to a point were the system wouldn't
> even mount the partition.
> 
> There was a discussion that hp set it to 2 for workstations and to 8 for
> servers. I have set it right now to 8 (since mavbe the NCR 7100 I have
> doesn't even support more) and I use XFS instead of reiser. I had no
> more problems...
> 
> I would set the tag queue as default to 8 and not to 16, to stay on the
> safe side. Couldn't it be made configurable from the kernel
> configuration menu?
> 
Good idea.
> 
> What I notivced that some drives seem to be incompatible. I had 2 hard
> disks that worked together (an original quantum divre rebranded HP and
> an IBM disk). Since my ibm disk died I substitued it with the Fujitsu,
> used a new Filesystem and a newer kernel. There was no way to see both
> disks when linux booted.
And you are sure that scsi id are well different and scsi chain well terminated, I supose.
> I had to remove the original HP disk and
> substitute it (a nuisance, since it contained the home directories).
> Attaching each time only one of the two disks recognized the correct
> disk respectively but both disk weren't. Another disk had no problem.
> 
hmm, I leaved the same experience but with two external disks of exactly the same type (same supplier: hp, same manufactor: 
seagate, same product reference) but with a small firmware revision difference. Unfortunately, this pb only occured under linux 
:(. Now the disk is broken again; so no chance to test it with more recent kernel 2.4 or 2.6 :(

Joel